在不同级别测试 FPGA 设计
Testing FPGA Designs at Different Levels
SO 上讨论了 FPGA 测试策略的各个方面，但我找不到以下问题asked/discussed/answered：
您应该在什么级别上模拟您的 FPGA 设计以及在每个级别验证什么？
如果您使用 x 级测试等概念回答，其中 x = 块、子系统、函数或其他，请描述 x 对您来说是什么。诸如典型大小、复杂性或示例之类的东西。
9 月 14 日
对于实际问题，给出的两个答案是相同的，但我会接受@kraigher 的答案，因为它是最短的答案。
9 月 10 日
这是对@Paebbles 和@kraigher 的两个答案的总结和比较。其中一个答案很长，所以希望这能帮助任何想要贡献自己答案的人。请记住，悬赏悬而未决！
- 它们都模拟所有级别的所有组件。至少@Paebbles 对功能内容很少的组件进行了例外处理，例如 MUX。
- 他们都致力于测试自动化
- 他们都开发了"tools"来简化板级测试
- 他们都避免在一个级别上测试已经在下面的级别上测试过的东西
- 最大的区别似乎在于模拟测试平台的频率。 @Paebbles 直接在 HW 中进行测试，除非有重大的设计更改，在这种情况下模拟也是 运行。 @kraigher 运行s 随着设计的发展，模拟更加连续。我认为这也是一个非常重要的问题，我个人更喜欢@kraigher 表达的方式。但是，这不是原始问题的一部分，因此我认为两个答案之间存在共识。关于应该多久测试一次的问题 运行 之前也已经在 SO 上讨论过，例如 how often should the entire suite of a system's unit tests be run?
他们进行的实验室测试多少有所不同，但这似乎主要与项目的具体情况有关（有多少东西无法通过模拟进行有效测试）。我碰巧对@kraigher 的上一个项目有所了解，所以我可以说这两个项目都属于 1 年以上的类别。听一个小项目的人讲故事会很有趣。据我所知，远非所有项目在模拟功能覆盖方面都是完整的，因此肯定还有其他故事。
9 月 7 日
这是@peabbles 的一些后续问题，太长了，无法放在评论中。
是的@peabbles，你提供了我想要的大部分内容，但我还有其他问题。恐怕这可能是一个冗长的讨论，但考虑到我们在验证上花费的时间以及人们应用的各种策略，我认为它值得引起很多关注。希望我们能得到更多答案，以便可以比较各种方法。您的赏金一定会有所帮助。
我认为您的故事包含许多好的和有趣的解决方案，但我是一名工程师，所以我会专注于我认为可以挑战的部分；-)
您花费了大量时间在硬件上进行测试，以解决您遇到的所有外部问题。从实际的角度来看（因为他们不打算解决违反 SATA 标准的问题），这就像有一个有缺陷的需求规范，以至于您开发的设计解决了错误的问题。这通常是在您“交付”时发现的，这激发了您为什么应该经常交付并尽早发现问题。不过，我对一件事很好奇。当您在实验室中发现需要更改设计的错误时，您会在可以测试的最低级别更新测试平台吗？不这样做会增加错误在实验室中再次出现的风险，并且随着时间的推移，它还会降低测试平台的功能覆盖率，使您更加依赖实验室测试。
您说大部分测试都是在实验室中完成的，这是由于您必须调试的外部问题数量众多。如果你只看你自己的内部代码和错误，你的答案是一样的吗？
当您像以前一样处理较长的周转时间时，您会找到各种利用时间的方法。您描述说，您在测试第一个设计时开始综合下一个设计，如果您在一个驱动器中发现错误，您将开始为该驱动器综合修复，同时继续使用当前设计测试其他驱动器。您还描述了在实验室进行测试时的可观察性问题。我将对此进行一些怀疑的解释，你必须提供积极的解释！
如果您可以在开始测试第一个设计时立即综合下一个设计，那么您似乎正在以非常小的增量工作，但仍然努力 运行 每个级别的每个测试一直到硬件。这似乎有点 overkill/expensive，尤其是当您在硬件测试上没有完全自动化时。另一种持怀疑态度的解释是，您正在寻找错误，但由于可观察性差，您正在生成随机试验和错误类型的构建，希望它们能为您试图隔离的问题提供线索。从每次构建都增加价值的意义上说，这真的是对时间的有效利用，还是更像是“做某事总比什么都不做好”？
在设计更高的协议层时，您是否考虑过将更高层的通信堆栈短路以加快仿真速度？毕竟下层已经测试过了
您重复使用了一些组件并假定它们没有错误。那是因为它们附带了证明这一点的测试台吗？在使用中证明往往很薄弱，因为重用通常发生在另一个上下文中。 Arianne 5 火箭是一个引人注目的例子，您将 XAPP 870 重新用于 Virtex 5 另一个。
由于您在不同级别进行了模拟，我假设您重视较低级别的更快 运行 时间和较短的反馈循环，当您可以在较大的结构之前验证设计的一部分时已经完成。您仍然拥有足够重要的代码片段，可以授予它们自己的组件，但仍然太简单，无法授予它们自己的测试平台。你能举一个这样的组件的例子吗？他们真的没有错误吗？就我个人而言，我不会在犯错误之前写很多行代码，所以如果我有一段像组件一样打包好的代码，出于上述原因，我会抓住机会在该级别进行测试。
一个Serial-ATA控制器的故事
我将尝试通过示例来解释我的测试策略。
简介：
我为我最后的学士项目开发了一个 Serial-ATA Controller，它在我毕业后的几个月内发展成为一个非常庞大的项目。测试要求变得越来越难，并且每一个新的错误或性能缺陷都更难发现，所以我需要更聪明的调试工具、策略和解决方案。
开发步骤：
第 1 阶段：准备使用的 IP 核示例
我开始使用 Virtex-5 平台（ML505 板）和带有示例代码的 Xilinx XAPP 870。此外，我还获得了 SATA 和 ATA 标准、Xilinx 用户指南以及 2 个测试驱动器。不久之后，我注意到示例代码主要是为 Virtex-4 FPGA 编写的，并且 CoreGenerator 生成了无效代码：未连接的信号、未分配的输入、关于 SATA 规范的错误配置值。
Rule #1: Double check generated code lines, they may contain systematic faults.
第 2 阶段：完全重写收发器代码并设计新的物理层
我开发了一个新的收发器和一个物理层来执行基本的 SATA 握手协议。在我写学士报告时，没有好的 GTP_DUAL 收发器仿真模型，我也没有时间自己写。所以我在真正的硬件上测试了一切。可以模拟收发器，但 OOB 握手协议所需的电气空闲条件未实现或不工作。在我完成报告后，Xilinx 更新了仿真模型，我可以仿真握手协议，但不幸的是一切都是 运行ning（见第 5 阶段）。
如何在没有仿真的情况下测试 FPGA 硬宏？
幸运的是，我有一个 Samsung Spinpoint HDD，它只有在有效的握手序列后才能启动。所以我有一个声学反应。
FPGA 设计配备了大型 ChipScope ILA，它使用 98% 的 BlockRAM，以监控收发器行为。这是猜测高速串行线上发生了什么的唯一可能性。我们还有其他无法解决的困难：
- 我们没有能够处理 1.5 和 3.0 GHz 信号的示波器。
- 在电线上添加探针很困难（反射，...）
- 我是计算机科学家，不是高频电气工程师:)
Rule #2: If your design has space left, us it for ILAs to monitor the design.
第 3 阶段：A link 层
在使用 2 个 HDD 成功 link 后，我开始设计 link 层。
这一层有大的 FSM、FIFO、扰码器、CRC 发生器等。像 FIFOs 这样的一些组件是为我的学士项目提供的，所以我认为这些组件没有错误。否则我可以自己启动提供的模拟并更改参数。
我自己的子组件在测试台中通过模拟进行了测试。 （=> 组件级测试）。之后我写了一个上层测试台，可以作为主机或设备，所以我能够构建一个 4 层堆栈：
1.测试台（类型=主机）
2.LinkLayer（类型=主机）
3.延迟线
4.LinkLayer（类型=设备）
5.测试台（类型=设备）
SATA link层传输和接收数据帧。因此，用于刺激生成的正常过程语句是相当多的代码并且不可维护。我用 VHDL 开发了一个数据结构，用于存储测试用例、帧和数据字，包括流控制信息。 (=> 子系统级仿真)
Rule #3: Building a counterpart design (e.g. the device) can help in simulations.
阶段 4：在真实硬件上测试 link 层
host-side 测试平台层形式 (3) 也被编写为可综合的。所以我把它插在一起：
1.测试台（类型=主机）
2.LinkLayer（类型=主机）
3.物理层
4.收发层
5.SATA数据线
6. 硬盘
我将启动序列作为 SATA 帧列表存储在测试台的 ROM 中，并使用 ChipScope 监控 HDD 响应。
Rule #4: Synthesizeable testbenches can be reused in hardware. The formerly generated ILAs could be reused, too.
现在是时候测试不同的 HDD 并监控它们的行为了。经过一段时间的测试后，我可以与一些磁盘和 SSD 进行通信。一些特定于供应商的解决方法已添加到设计中（例如，除了来自 WDC 驱动器的双重 COM_INIT 响应 :)）
此时合成需要大约 30-60 分钟才能完成。这是由中档 CPU、>90% 的 FPGA 利用率 (BlockRAM) 和 ChipScope 内核中的时序问题引起的。 Virtex-5 的某些部分 运行 设计为 300 MHz，因此缓冲区 git 填充得非常快。另一方面，握手序列可能需要 800 微秒（通常 < 100 微秒），但市场上有些设备会休眠 650 微秒直到它们响应！所以我研究了存储资格、cross-triggering 和数据压缩领域。
虽然综合 运行ning，但我用 di 测试了我的设计ferent 设备并为每个设备写下测试结果 sheet。如果合成完成并且 Map/P&R 非常出色，我会使用修改后的代码重新启动它。所以我在飞行中有几个设计:)。
阶段 5：更高层：
接下来我设计了传输层和命令层。每层都有一个独立的测试台，以及用于复杂子模块的子组件测试台。 （=> 组件和子系统级测试）
所有模块都插入到 multi-layer 测试台中。 A 设计了一个新的数据生成器，所以我不必对每一帧进行手工编码，只需编写帧序列即可。
- 测试台（启动器）
- 数据生成器
- 指挥层
- 传输层
- LinkLayer（类型=主机）
- 有延迟的电线
- LinkLayer（类型=设备）
- 测试台（检查器）
我还在两个 LinkLayer 实例之间添加了一个线延迟，这是之前在 ChipScope 中测得的。检查器测试台与上面相同，充满了预期的帧顺序和准备好的响应帧。
Rule #5: Some delays let you find protocol/handshake problems between FSMs.
阶段 6：回到 FPGA
堆栈再次合成。我将 ILA 策略更改为每个协议层一个 ILA。我通过 CoreGenerator 生成了 ILA，这允许我使用新的 ChipScope 内核类型，即 VIO (VirtualInputOutput)。此 VIO 通过 JTAG 将简单的 I/O 操作（按钮、开关、led）传输到 FPGA 板或从中传输。所以我可以自动化我的一些测试过程。 VIO 还能够对 ASCII 字符串进行编码，因此我将设计中的一些错误位解码为可读消息。这使我无需搜索综合报告和 VHDL 代码。我将所有 FSM 都切换为灰色编码，以节省 BlockRAM。
Rule #6: Readable error messages save time
**第 7 阶段：ChipScope 调试的进步
一层的每个 ILA 都有一个触发输出 put，它连接到其他 ILA 上的触发输入。这会启用 cross-triggers。例如。可以使用这个复杂的条件：如果帧中止，在 LinkLayer 收到第三个 EOF 序列后，在 TransportLayer 中触发。
Rule #7: Use multiple ILAs and connect their triggers cross-wise.
复杂的触发器允许人们隔离故障而无需耗时的重新综合。我还开始从综合报告中提取 FSM 编码，这样我就可以将提取的数据作为令牌文件加载到 ChipScope 中，并使用真实名称显示 FSM 状态。
第 8 阶段：一个严重的错误
接下来，我遇到了一个严重的错误。 3 帧后，我的 FSM 卡住了，但我无法在 ChipScope 中找到原因，因为一切正常。我无法添加更多信号，因为 Virtex-5 只有 60 个 BlockRAM……幸运的是，我可以转储从 HDD 启动到 ChipScope 出现故障的所有帧事务。但是，ChipScope 可以将数据导出为 *.vcd 转储。
我编写了一个 VHDL 包来解析和导入 iSim 中的 *.vcd 转储文件，因此我可以使用转储数据来模拟完整的主机 <-> 硬盘交互。
Rule #8: Dumped inter-layer transfer data can be used in simulation for a more detailed look.
暂停
到那时，SATA 堆栈已经相当完整并通过了我所有的测试。我被分配到另外两个项目：
- 通用UDP/IPv4/IPv6堆栈和
- 一个"remote controllable testdesign controller"
第一个项目重用了基于帧的测试平台和每层/协议 ILA。第二个项目使用 8 位 CPU (PicoBlaze) 构建一个名为 SoFPGA 的交互式测试控制器。它可以通过标准终端（Putty、Kitty、Minicom、...）进行远程控制。
当时一所大学将 SATA 控制器移植到 Stratix II 和 Stratix-IV 平台上。他只是交换了收发层并设计了一些适配器。
SATA 第二部分：
SATA 控制器应该升级：(a) 支持 7 系列 FPGA 和 6.0 Gb/s 传输速度。新平台是 Kintex-7 (KC705)。
阶段 9:
用按钮和 LED 测试如此大的设计是不可行的。第一种方法是第 6 阶段的 VIO 内核。因此我选择包括之前开发的 SoFPGA。我添加了一个 I²C 控制器，它需要重新编程一个 on-board 时钟发生器，从 156.25 到 150 MHz。我还实现了测量模块来测量传输速率、运行时间等。来自控制器的错误位连接到 SoFPGA 的中断引脚，错误显示在 Putty 屏幕上。我还添加了用于故障注入的SoFPGA可控组件。例如，可以将位错误插入 SATA 原语，但不能插入数据字。
通过这种技术，我们可以证明多个 SATA 设备（HDD 和 SSD）中的协议实现错误。有可能导致部分设备的link层FSM死锁。这是由 LinkLayer FSM 转换图中缺少边引起的:)
有了SoFPGA的方法，修改起来很容易y 测试、重置设计、报告错误，甚至基准测试。
Rule #9: The usage of a soft core allows you to write tests/benchmarks in software. Detailed error reporting can be done via terminal messages. New test programs can be uploaded via JTAG -> no synthesis needed.
可是我犯了一个大错
第0阶段：回到起点：
我的重置网络非常非常糟糕。所以我在两个学院的帮助下重新设计了reset network。新的时钟网络具有单独的时钟线和 MMCM 复位以及稳定信号以指示正确的时钟信号和频率。这是必需的，因为外部输入时钟在 运行 时间重新编程，SATA 生成更改可能导致时钟分频器在 运行 时间切换，收发器中的重置序列可能导致收发器的时钟输出不稳定。此外，我们实施了一个断电信号，从零开始。因此，如果 SoFPGA 触发了一个 powerdown/powerup 序列，SATA 控制器就像对 FPGA 编程后一样新。这样可以节省大量时间！
Rule #0: Implement proper resets to every test behaves in the same way. No reprogramming of the FPGA is needed. Add cross clock circuits! This prevents many random faults.
备注：
我们的 PoC-Library. There are also testbench packages and scripts to ease testing. The SoFPGA core is published, too. My PicoBlaze-Library 项目中发布了 SATA 控制器的一些子组件，简化了 SoC 开发。
来自@lasplund 的问题 - 第一部分：
可以说你们的测试水平是
组件级（CRC 仿真、复杂 FSM）、子系统级（仿真
你的一层），top-level 模拟，实验室测试 w/o 软件，实验室测试
使用 SW（使用 SoFPGA）?
是，我对中型 components.Some 使用了组件测试，其中已经 ready-to-use 我信任开发人员。小组件在子系统级测试中进行测试。我相信我的代码，所以没有单独的测试台。如果出现错误，我会在更大的测试台上看到它。
当我开始开发的第二部分时，我使用了 top-level 测试台。一方面，有可用的仿真模型，但速度非常慢（简单的帧传输需要数小时）。另一方面，我们的控制器充满了 ILA，而 Kintex-7 提供了数百个 BlockRAM。合成大约需要 17 分钟（包括 10 个 ILA 和一个 SoFPGA）。所以在这个项目中，实验室测试比模拟要快。许多改进（令牌文件、SoFPGA、交叉 ILA 触发）显着简化了调试过程。
你能给出一个大概的数字来说明你的验证工作（开发
并且运行在那个关卡上进行测试和调试）分布在你的关卡中？
我觉得这很难说。我在 SATA 上工作了 2 年，在 IPv6 / SoFPGA 上工作了一年。我认为大部分 (>60%) 时间花在 "external debugging" 上。例如：
- 调试 VHDL 工具（XST、CoreGenerator、iSim、Vivado、ModelSim、Quartus、GHDL……）
我在这些工具中发现了大量错误，其中大部分都得到了报告。有些是无解的。
- 第二大部分时间用于 FPGA-device 调试。
我在设备中发现了几个未报告的 'secret/silenced' 错误（尤其是在 7 系列 FPGA 中）。一段时间后，您开始相信该设备存在错误，您只针对此错误开发了硬件测试。您可以证明这一点，但 Xilinx 会忽略您所有的错误报告...!
- 然后是对不同设备的测试。
所有设备都符合 SATA 规范，但有些设备不与我们的 SATA 'conform' 控制器通信。然后你开始尝试不同的计时、超时、控制字……直到你找到设备中的错误。如果发现此问题，您将开始制定解决方法，但它也必须适用于所有以前测试过的设备！
类似的分布，你在哪里检测你的bug，你在哪里
隔离根本原因？我的意思是你在实验室检测到的东西可能
需要模拟来隔离。
所以如前所述，大多数测试都是实验室测试，Espei
不同级别的典型周转时间是多少？我的意思是
从你决定尝试某事到你完成所花费的时间
完成了一项新测试 运行 并有新数据要分析。
因为合成需要很长时间，所以我们使用了流水线测试。因此，当我们在 FPGA 上测试一个设计时，一个新的设计已经在合成中了。或者当一个错误得到修复和综合时，我们用其他磁盘 (7) 和 SSD (2) 测试了设计。我们创建了磁盘故障和未故障的矩阵。
大多数调试解决方案都是前瞻性发明的：可重用性、可参数化……
最后一段：
让 Kintex-7 为 SATA 做好准备是一项艰巨的工作。发布了几个问题，例如Configuring a 7-Series GTXE2 transceiver for Serial-ATA (Gen1/2/3)。但是我们找不到 GTXE2 收发器的正确配置。因此，借助我们的嵌入式 SoFPGA，我们开发了 PicoBlaze 到 DRP 适配器。动态重配置端口 (DRP) 是从 FPGA 架构到收发器配置位的接口。一方面，我们监测收发器中的频率滑动单元，同时适应串行线。另一方面，我们通过 SoFPGA 在 运行 时间重新配置了收发器，由 putty 终端控制。我们在 4 小时内测试了 > 100 个配置，仅使用 3 个合成 运行s。合成每个配置花费了我们数周的时间...
来自@lasplund 的问题 - 第二部分：
当您在实验室中发现需要更改设计的错误时，您是否会在可以测试的最低级别更新测试平台？
是的，我们更新了测试平台以反映更改后的实现，因此我们希望不会 运行 再次陷入同样的陷阱。
您说大多数测试都是在实验室中完成的，这是由于您必须调试的外部问题数量多所致。如果只看自己的内部代码和bug，答案是一样的吗？
我设计了具有相同安全性的状态机。例如，总有其他或其他情况。因此，如果其中一位开发人员（现在我们是四人一组）添加新状态并遗漏边缘等，这些转换就会被捕获。每个 FSM 至少有一个错误状态，由转换错误或子组件报告错误进入。每层生成一个错误代码。错误条件冒泡到最顶层的 FSM。根据错误严重性（可恢复、不可恢复……），上层 FSM 执行恢复过程或暂停。所有 FSM 的状态加上错误条件由 ChipScope 监控。因此在大多数情况下，可以在不到一分钟的时间内发现故障。 (FSM State; Error Code) 的元组大部分都非常准确地标识了原因，因此我可以命名模块和代码行。
我们也花了很多时间设计层/FSM交互协议。我们将其命名为 protocol/interface Command-Status-Error。上层可以通过Status监控下层。如果 Status = STATUS_ERROR，则 Error 有效。上层可以通过Command.
控制下层
它的资源效率可能不是很高（LUT、Regs），但它对调试（时间、错误定位）非常有效。
[...]我将对此进行一些怀疑的解释，你必须提供积极的解释！
分段开发SATA是一件很郁闷的事情。特别是收发器的参数搜索:)。不过我们也脑补了美好的时刻：
- 新的工作复位/断电电路 - 不再通过 FPGA 重新编程进行复位
- PicoBlaze / SoFPGA 系统通过 UART 通信 :)
- 在运行时间
重新编程SoFPGA
- 自动远程测试
如果您在开始测试第一个设计时可以立即综合下一个设计，那么您似乎正在以非常小的增量工作，但仍然努力 运行 每个级别的每个测试一直到硬件。这似乎有点overkill/expensive，尤其是当你在硬件测试上不是完全自动化的时候。
我们并不是每次都运行模拟。在设计发生重大变化之后。在我们测试一项功能的同时，我们开始测试一项新功能。这有点像晶圆生产。目前的芯片已经承载了下一代或下一代之后的电路用于测试。 => pipelining :) 一个缺点是如果发生重大错误，则必须清除管道并且必须单独测试每个功能。这种情况非常罕见。
开发过程一直是个问题：我能否在接下来的 5 天内使用我当前的工具集找到错误/解决方案，或者我应该花 1-2 周时间设计一个更好的工具可观测性？
所以我们专注于自动化和脚本，以减少人为错误。详细解释它会破坏这个答案:)。但是，例如我们的 SoFPGA 直接从 VHDL 导出 ChipScope 令牌文件。它还会在每次综合 运行 时更新汇编文件。因此，如果更改 SoFPGA 设计，所有 *.psm 文件都会更新（例如设备地址）。
另一种持怀疑态度的解释是，您正在寻找错误，但由于可观察性差，您正在生成随机试验和错误类型的构建，希望它们能提供线索你试图隔离的问题。从每次构建都增加价值的意义上说，这真的是对时间的有效利用，还是更像是“做某事总比什么都不做好”？
关于正确的 GTXE2 设置，我们没有从 Xilinx 获得任何帮助。内部设计也大多不为人知。所以在某个时候它是 trial-and-error。所以唯一的办法就是缩小搜索范围 space.
在设计更高的协议层时，您是否考虑过将更高层的通信栈短路以加快仿真速度？毕竟下层已经测试过了
是的，之后link 层已完成，我们保留了所有较低层（物理收发器）以加速仿真。只剩下线路延迟了。
您重复使用了一些组件并假定它们没有错误。那是因为它们附带了证明这一点的测试台吗？
重用的测试台组件被编写为正常的可综合代码。因此，在经过测试后，它在模拟和设备上运行良好。测试台组件由测试台本身测试。
您仍然有一些代码片段足够重要，可以授予它们自己的组件，但仍然太简单，无法授予它们自己的测试平台。你能举一个这样的组件的例子吗？
例如Primitive_Mux和Primitive_Detector。 SATA 将数据字、CRC 值或原语插入到 32 位数据流中。 Primitive_Mux 是一个简单的多路复用器，但要内联到其他组件中太大了 => 可读性、封装性。
就我个人而言，我不会在犯错误之前写很多行代码，所以如果我有一段像组件一样打包好的代码，我会抓住机会进行测试由于上述原因，该级别。
我认为没有人写出没有错误的代码，但我认为我的 MTBF 多年来一直在增加 ;)。
这里有一个关于如何用大锤敲碎坚果的例子:
这张由连接到 RX 相位插值器的 ChipScope 捕获的图片显示了 GTXE2 如何调整其时钟相位以保持位对齐。我们需要大约一周的时间来实施它，这样我们才能看到 GTXE2 中发生了什么。我们还需要一周时间来实施 DRP 适配器，因为选择图中显示的值的多路复用器只能通过动态重新编程来更改！幸运的是我们有我们的 SoFPGA :)
大部分线性图显示 FPGA 和 HDD 运行 以几乎相同的速度运行，具有低抖动和恒定漂移，因为使用了 2 个振荡器。三星 840 Pro 向我们展示了扩频时钟 (SSC) 行为。例如 SATA 线路频率使用三角调制可以将 6 GHz 降低多达 0.5%。谷底向我们表明内部滤波器系数无法应对 SSC。它无法处理三角调制的转折点。 => 所以现在我们需要找到新的过滤器参数。
我在各个层面进行行为模拟。即所有实体都应该有一个相应的测试平台，旨在实现完整的功能覆盖。如果实体 A、B 和 C 的特定细节已经在其相应的测试平台中被隔离测试，则它们不必包含在实例化 A、B 和 C 的实体 D 的测试平台中，实体 D 应该专注于证明集成。
我还有设备或板级测试，在实际设备或板上验证实际设计。这是因为当模型开始变得不精确并且需要很长时间时，您不能相信设备级模拟。在真实设备上测试可以达到小时而不是毫秒。
我尽量避免执行任何 post 综合模拟，除非在设备级测试中出现故障，在这种情况下，我会执行它以查找综合工具中的错误。在这种情况下，我可以对 post-综合网表进行一个小包装，并重新使用行为仿真中的测试平台。
我努力避免任何形式的手动测试，而是依靠测试自动化框架进行模拟和设备级测试，以便可以连续执行测试。
为了自动化模拟，我使用了 VUnit 测试自动化框架，@lasplund 和我本人是其作者。
SO 上讨论了 FPGA 测试策略的各个方面，但我找不到以下问题asked/discussed/answered：
您应该在什么级别上模拟您的 FPGA 设计以及在每个级别验证什么？
如果您使用 x 级测试等概念回答，其中 x = 块、子系统、函数或其他，请描述 x 对您来说是什么。诸如典型大小、复杂性或示例之类的东西。
9 月 14 日
对于实际问题，给出的两个答案是相同的，但我会接受@kraigher 的答案，因为它是最短的答案。
9 月 10 日
这是对@Paebbles 和@kraigher 的两个答案的总结和比较。其中一个答案很长，所以希望这能帮助任何想要贡献自己答案的人。请记住，悬赏悬而未决！
- 它们都模拟所有级别的所有组件。至少@Paebbles 对功能内容很少的组件进行了例外处理，例如 MUX。
- 他们都致力于测试自动化
- 他们都开发了"tools"来简化板级测试
- 他们都避免在一个级别上测试已经在下面的级别上测试过的东西
- 最大的区别似乎在于模拟测试平台的频率。 @Paebbles 直接在 HW 中进行测试，除非有重大的设计更改，在这种情况下模拟也是 运行。 @kraigher 运行s 随着设计的发展，模拟更加连续。我认为这也是一个非常重要的问题，我个人更喜欢@kraigher 表达的方式。但是，这不是原始问题的一部分，因此我认为两个答案之间存在共识。关于应该多久测试一次的问题 运行 之前也已经在 SO 上讨论过，例如 how often should the entire suite of a system's unit tests be run?
他们进行的实验室测试多少有所不同，但这似乎主要与项目的具体情况有关（有多少东西无法通过模拟进行有效测试）。我碰巧对@kraigher 的上一个项目有所了解，所以我可以说这两个项目都属于 1 年以上的类别。听一个小项目的人讲故事会很有趣。据我所知，远非所有项目在模拟功能覆盖方面都是完整的，因此肯定还有其他故事。
9 月 7 日
这是@peabbles 的一些后续问题，太长了，无法放在评论中。
是的@peabbles，你提供了我想要的大部分内容，但我还有其他问题。恐怕这可能是一个冗长的讨论，但考虑到我们在验证上花费的时间以及人们应用的各种策略，我认为它值得引起很多关注。希望我们能得到更多答案，以便可以比较各种方法。您的赏金一定会有所帮助。
我认为您的故事包含许多好的和有趣的解决方案，但我是一名工程师，所以我会专注于我认为可以挑战的部分；-)
您花费了大量时间在硬件上进行测试，以解决您遇到的所有外部问题。从实际的角度来看（因为他们不打算解决违反 SATA 标准的问题），这就像有一个有缺陷的需求规范，以至于您开发的设计解决了错误的问题。这通常是在您“交付”时发现的，这激发了您为什么应该经常交付并尽早发现问题。不过，我对一件事很好奇。当您在实验室中发现需要更改设计的错误时，您会在可以测试的最低级别更新测试平台吗？不这样做会增加错误在实验室中再次出现的风险，并且随着时间的推移，它还会降低测试平台的功能覆盖率，使您更加依赖实验室测试。
您说大部分测试都是在实验室中完成的，这是由于您必须调试的外部问题数量众多。如果你只看你自己的内部代码和错误，你的答案是一样的吗？
当您像以前一样处理较长的周转时间时，您会找到各种利用时间的方法。您描述说，您在测试第一个设计时开始综合下一个设计，如果您在一个驱动器中发现错误，您将开始为该驱动器综合修复，同时继续使用当前设计测试其他驱动器。您还描述了在实验室进行测试时的可观察性问题。我将对此进行一些怀疑的解释，你必须提供积极的解释！
如果您可以在开始测试第一个设计时立即综合下一个设计，那么您似乎正在以非常小的增量工作，但仍然努力 运行 每个级别的每个测试一直到硬件。这似乎有点 overkill/expensive，尤其是当您在硬件测试上没有完全自动化时。另一种持怀疑态度的解释是，您正在寻找错误，但由于可观察性差，您正在生成随机试验和错误类型的构建，希望它们能为您试图隔离的问题提供线索。从每次构建都增加价值的意义上说，这真的是对时间的有效利用，还是更像是“做某事总比什么都不做好”？
在设计更高的协议层时，您是否考虑过将更高层的通信堆栈短路以加快仿真速度？毕竟下层已经测试过了
您重复使用了一些组件并假定它们没有错误。那是因为它们附带了证明这一点的测试台吗？在使用中证明往往很薄弱，因为重用通常发生在另一个上下文中。 Arianne 5 火箭是一个引人注目的例子，您将 XAPP 870 重新用于 Virtex 5 另一个。
由于您在不同级别进行了模拟，我假设您重视较低级别的更快 运行 时间和较短的反馈循环，当您可以在较大的结构之前验证设计的一部分时已经完成。您仍然拥有足够重要的代码片段，可以授予它们自己的组件，但仍然太简单，无法授予它们自己的测试平台。你能举一个这样的组件的例子吗？他们真的没有错误吗？就我个人而言，我不会在犯错误之前写很多行代码，所以如果我有一段像组件一样打包好的代码，出于上述原因，我会抓住机会在该级别进行测试。
一个Serial-ATA控制器的故事
我将尝试通过示例来解释我的测试策略。
简介：
我为我最后的学士项目开发了一个 Serial-ATA Controller，它在我毕业后的几个月内发展成为一个非常庞大的项目。测试要求变得越来越难，并且每一个新的错误或性能缺陷都更难发现，所以我需要更聪明的调试工具、策略和解决方案。
开发步骤：
第 1 阶段：准备使用的 IP 核示例
我开始使用 Virtex-5 平台（ML505 板）和带有示例代码的 Xilinx XAPP 870。此外，我还获得了 SATA 和 ATA 标准、Xilinx 用户指南以及 2 个测试驱动器。不久之后，我注意到示例代码主要是为 Virtex-4 FPGA 编写的，并且 CoreGenerator 生成了无效代码：未连接的信号、未分配的输入、关于 SATA 规范的错误配置值。
Rule #1: Double check generated code lines, they may contain systematic faults.
第 2 阶段：完全重写收发器代码并设计新的物理层
我开发了一个新的收发器和一个物理层来执行基本的 SATA 握手协议。在我写学士报告时，没有好的 GTP_DUAL 收发器仿真模型，我也没有时间自己写。所以我在真正的硬件上测试了一切。可以模拟收发器，但 OOB 握手协议所需的电气空闲条件未实现或不工作。在我完成报告后，Xilinx 更新了仿真模型，我可以仿真握手协议，但不幸的是一切都是 运行ning（见第 5 阶段）。
如何在没有仿真的情况下测试 FPGA 硬宏？
幸运的是，我有一个 Samsung Spinpoint HDD，它只有在有效的握手序列后才能启动。所以我有一个声学反应。
FPGA 设计配备了大型 ChipScope ILA，它使用 98% 的 BlockRAM，以监控收发器行为。这是猜测高速串行线上发生了什么的唯一可能性。我们还有其他无法解决的困难：
- 我们没有能够处理 1.5 和 3.0 GHz 信号的示波器。
- 在电线上添加探针很困难（反射，...）
- 我是计算机科学家，不是高频电气工程师:)
Rule #2: If your design has space left, us it for ILAs to monitor the design.
第 3 阶段：A link 层
在使用 2 个 HDD 成功 link 后，我开始设计 link 层。
这一层有大的 FSM、FIFO、扰码器、CRC 发生器等。像 FIFOs 这样的一些组件是为我的学士项目提供的，所以我认为这些组件没有错误。否则我可以自己启动提供的模拟并更改参数。
我自己的子组件在测试台中通过模拟进行了测试。 （=> 组件级测试）。之后我写了一个上层测试台，可以作为主机或设备，所以我能够构建一个 4 层堆栈：
1.测试台（类型=主机）
2.LinkLayer（类型=主机）
3.延迟线
4.LinkLayer（类型=设备）
5.测试台（类型=设备）
SATA link层传输和接收数据帧。因此，用于刺激生成的正常过程语句是相当多的代码并且不可维护。我用 VHDL 开发了一个数据结构，用于存储测试用例、帧和数据字，包括流控制信息。 (=> 子系统级仿真)
Rule #3: Building a counterpart design (e.g. the device) can help in simulations.
阶段 4：在真实硬件上测试 link 层
host-side 测试平台层形式 (3) 也被编写为可综合的。所以我把它插在一起：
1.测试台（类型=主机）
2.LinkLayer（类型=主机）
3.物理层
4.收发层
5.SATA数据线
6. 硬盘
我将启动序列作为 SATA 帧列表存储在测试台的 ROM 中，并使用 ChipScope 监控 HDD 响应。
Rule #4: Synthesizeable testbenches can be reused in hardware. The formerly generated ILAs could be reused, too.
现在是时候测试不同的 HDD 并监控它们的行为了。经过一段时间的测试后，我可以与一些磁盘和 SSD 进行通信。一些特定于供应商的解决方法已添加到设计中（例如，除了来自 WDC 驱动器的双重 COM_INIT 响应 :)）
此时合成需要大约 30-60 分钟才能完成。这是由中档 CPU、>90% 的 FPGA 利用率 (BlockRAM) 和 ChipScope 内核中的时序问题引起的。 Virtex-5 的某些部分 运行 设计为 300 MHz，因此缓冲区 git 填充得非常快。另一方面，握手序列可能需要 800 微秒（通常 < 100 微秒），但市场上有些设备会休眠 650 微秒直到它们响应！所以我研究了存储资格、cross-triggering 和数据压缩领域。
虽然综合 运行ning，但我用 di 测试了我的设计ferent 设备并为每个设备写下测试结果 sheet。如果合成完成并且 Map/P&R 非常出色，我会使用修改后的代码重新启动它。所以我在飞行中有几个设计:)。
阶段 5：更高层：
接下来我设计了传输层和命令层。每层都有一个独立的测试台，以及用于复杂子模块的子组件测试台。 （=> 组件和子系统级测试）
所有模块都插入到 multi-layer 测试台中。 A 设计了一个新的数据生成器，所以我不必对每一帧进行手工编码，只需编写帧序列即可。
- 测试台（启动器）
- 数据生成器
- 指挥层
- 传输层
- LinkLayer（类型=主机）
- 有延迟的电线
- LinkLayer（类型=设备）
- 测试台（检查器）
我还在两个 LinkLayer 实例之间添加了一个线延迟，这是之前在 ChipScope 中测得的。检查器测试台与上面相同，充满了预期的帧顺序和准备好的响应帧。
Rule #5: Some delays let you find protocol/handshake problems between FSMs.
阶段 6：回到 FPGA
堆栈再次合成。我将 ILA 策略更改为每个协议层一个 ILA。我通过 CoreGenerator 生成了 ILA，这允许我使用新的 ChipScope 内核类型，即 VIO (VirtualInputOutput)。此 VIO 通过 JTAG 将简单的 I/O 操作（按钮、开关、led）传输到 FPGA 板或从中传输。所以我可以自动化我的一些测试过程。 VIO 还能够对 ASCII 字符串进行编码，因此我将设计中的一些错误位解码为可读消息。这使我无需搜索综合报告和 VHDL 代码。我将所有 FSM 都切换为灰色编码，以节省 BlockRAM。
Rule #6: Readable error messages save time
**第 7 阶段：ChipScope 调试的进步
一层的每个 ILA 都有一个触发输出 put，它连接到其他 ILA 上的触发输入。这会启用 cross-triggers。例如。可以使用这个复杂的条件：如果帧中止，在 LinkLayer 收到第三个 EOF 序列后，在 TransportLayer 中触发。
Rule #7: Use multiple ILAs and connect their triggers cross-wise.
复杂的触发器允许人们隔离故障而无需耗时的重新综合。我还开始从综合报告中提取 FSM 编码，这样我就可以将提取的数据作为令牌文件加载到 ChipScope 中，并使用真实名称显示 FSM 状态。
第 8 阶段：一个严重的错误
接下来，我遇到了一个严重的错误。 3 帧后，我的 FSM 卡住了，但我无法在 ChipScope 中找到原因，因为一切正常。我无法添加更多信号，因为 Virtex-5 只有 60 个 BlockRAM……幸运的是，我可以转储从 HDD 启动到 ChipScope 出现故障的所有帧事务。但是，ChipScope 可以将数据导出为 *.vcd 转储。
我编写了一个 VHDL 包来解析和导入 iSim 中的 *.vcd 转储文件，因此我可以使用转储数据来模拟完整的主机 <-> 硬盘交互。
Rule #8: Dumped inter-layer transfer data can be used in simulation for a more detailed look.
暂停
到那时，SATA 堆栈已经相当完整并通过了我所有的测试。我被分配到另外两个项目：
- 通用UDP/IPv4/IPv6堆栈和
- 一个"remote controllable testdesign controller"
第一个项目重用了基于帧的测试平台和每层/协议 ILA。第二个项目使用 8 位 CPU (PicoBlaze) 构建一个名为 SoFPGA 的交互式测试控制器。它可以通过标准终端（Putty、Kitty、Minicom、...）进行远程控制。
当时一所大学将 SATA 控制器移植到 Stratix II 和 Stratix-IV 平台上。他只是交换了收发层并设计了一些适配器。
SATA 第二部分：
SATA 控制器应该升级：(a) 支持 7 系列 FPGA 和 6.0 Gb/s 传输速度。新平台是 Kintex-7 (KC705)。
阶段 9:
用按钮和 LED 测试如此大的设计是不可行的。第一种方法是第 6 阶段的 VIO 内核。因此我选择包括之前开发的 SoFPGA。我添加了一个 I²C 控制器，它需要重新编程一个 on-board 时钟发生器，从 156.25 到 150 MHz。我还实现了测量模块来测量传输速率、运行时间等。来自控制器的错误位连接到 SoFPGA 的中断引脚，错误显示在 Putty 屏幕上。我还添加了用于故障注入的SoFPGA可控组件。例如，可以将位错误插入 SATA 原语，但不能插入数据字。
通过这种技术，我们可以证明多个 SATA 设备（HDD 和 SSD）中的协议实现错误。有可能导致部分设备的link层FSM死锁。这是由 LinkLayer FSM 转换图中缺少边引起的:)
有了SoFPGA的方法，修改起来很容易y 测试、重置设计、报告错误，甚至基准测试。
Rule #9: The usage of a soft core allows you to write tests/benchmarks in software. Detailed error reporting can be done via terminal messages. New test programs can be uploaded via JTAG -> no synthesis needed.
可是我犯了一个大错
第0阶段：回到起点：
我的重置网络非常非常糟糕。所以我在两个学院的帮助下重新设计了reset network。新的时钟网络具有单独的时钟线和 MMCM 复位以及稳定信号以指示正确的时钟信号和频率。这是必需的，因为外部输入时钟在 运行 时间重新编程，SATA 生成更改可能导致时钟分频器在 运行 时间切换，收发器中的重置序列可能导致收发器的时钟输出不稳定。此外，我们实施了一个断电信号，从零开始。因此，如果 SoFPGA 触发了一个 powerdown/powerup 序列，SATA 控制器就像对 FPGA 编程后一样新。这样可以节省大量时间！
Rule #0: Implement proper resets to every test behaves in the same way. No reprogramming of the FPGA is needed. Add cross clock circuits! This prevents many random faults.
备注：
我们的 PoC-Library. There are also testbench packages and scripts to ease testing. The SoFPGA core is published, too. My PicoBlaze-Library 项目中发布了 SATA 控制器的一些子组件，简化了 SoC 开发。
来自@lasplund 的问题 - 第一部分：
可以说你们的测试水平是 组件级（CRC 仿真、复杂 FSM）、子系统级（仿真 你的一层），top-level 模拟，实验室测试 w/o 软件，实验室测试 使用 SW（使用 SoFPGA）?
是，我对中型 components.Some 使用了组件测试，其中已经 ready-to-use 我信任开发人员。小组件在子系统级测试中进行测试。我相信我的代码，所以没有单独的测试台。如果出现错误，我会在更大的测试台上看到它。
当我开始开发的第二部分时，我使用了 top-level 测试台。一方面，有可用的仿真模型，但速度非常慢（简单的帧传输需要数小时）。另一方面，我们的控制器充满了 ILA，而 Kintex-7 提供了数百个 BlockRAM。合成大约需要 17 分钟（包括 10 个 ILA 和一个 SoFPGA）。所以在这个项目中，实验室测试比模拟要快。许多改进（令牌文件、SoFPGA、交叉 ILA 触发）显着简化了调试过程。你能给出一个大概的数字来说明你的验证工作（开发 并且运行在那个关卡上进行测试和调试）分布在你的关卡中？
我觉得这很难说。我在 SATA 上工作了 2 年，在 IPv6 / SoFPGA 上工作了一年。我认为大部分 (>60%) 时间花在 "external debugging" 上。例如：
- 调试 VHDL 工具（XST、CoreGenerator、iSim、Vivado、ModelSim、Quartus、GHDL……）
我在这些工具中发现了大量错误，其中大部分都得到了报告。有些是无解的。 - 第二大部分时间用于 FPGA-device 调试。 我在设备中发现了几个未报告的 'secret/silenced' 错误（尤其是在 7 系列 FPGA 中）。一段时间后，您开始相信该设备存在错误，您只针对此错误开发了硬件测试。您可以证明这一点，但 Xilinx 会忽略您所有的错误报告...!
- 然后是对不同设备的测试。
所有设备都符合 SATA 规范，但有些设备不与我们的 SATA 'conform' 控制器通信。然后你开始尝试不同的计时、超时、控制字……直到你找到设备中的错误。如果发现此问题，您将开始制定解决方法，但它也必须适用于所有以前测试过的设备！
- 调试 VHDL 工具（XST、CoreGenerator、iSim、Vivado、ModelSim、Quartus、GHDL……）
类似的分布，你在哪里检测你的bug，你在哪里 隔离根本原因？我的意思是你在实验室检测到的东西可能 需要模拟来隔离。
所以如前所述，大多数测试都是实验室测试，Espei
不同级别的典型周转时间是多少？我的意思是 从你决定尝试某事到你完成所花费的时间 完成了一项新测试 运行 并有新数据要分析。
因为合成需要很长时间，所以我们使用了流水线测试。因此，当我们在 FPGA 上测试一个设计时，一个新的设计已经在合成中了。或者当一个错误得到修复和综合时，我们用其他磁盘 (7) 和 SSD (2) 测试了设计。我们创建了磁盘故障和未故障的矩阵。
大多数调试解决方案都是前瞻性发明的：可重用性、可参数化……
最后一段：
让 Kintex-7 为 SATA 做好准备是一项艰巨的工作。发布了几个问题，例如Configuring a 7-Series GTXE2 transceiver for Serial-ATA (Gen1/2/3)。但是我们找不到 GTXE2 收发器的正确配置。因此，借助我们的嵌入式 SoFPGA，我们开发了 PicoBlaze 到 DRP 适配器。动态重配置端口 (DRP) 是从 FPGA 架构到收发器配置位的接口。一方面，我们监测收发器中的频率滑动单元，同时适应串行线。另一方面，我们通过 SoFPGA 在 运行 时间重新配置了收发器，由 putty 终端控制。我们在 4 小时内测试了 > 100 个配置，仅使用 3 个合成 运行s。合成每个配置花费了我们数周的时间...
来自@lasplund 的问题 - 第二部分：
当您在实验室中发现需要更改设计的错误时，您是否会在可以测试的最低级别更新测试平台？
是的，我们更新了测试平台以反映更改后的实现，因此我们希望不会 运行 再次陷入同样的陷阱。
您说大多数测试都是在实验室中完成的，这是由于您必须调试的外部问题数量多所致。如果只看自己的内部代码和bug，答案是一样的吗？
我设计了具有相同安全性的状态机。例如，总有其他或其他情况。因此，如果其中一位开发人员（现在我们是四人一组）添加新状态并遗漏边缘等，这些转换就会被捕获。每个 FSM 至少有一个错误状态，由转换错误或子组件报告错误进入。每层生成一个错误代码。错误条件冒泡到最顶层的 FSM。根据错误严重性（可恢复、不可恢复……），上层 FSM 执行恢复过程或暂停。所有 FSM 的状态加上错误条件由 ChipScope 监控。因此在大多数情况下，可以在不到一分钟的时间内发现故障。 (FSM State; Error Code) 的元组大部分都非常准确地标识了原因，因此我可以命名模块和代码行。
我们也花了很多时间设计层/FSM交互协议。我们将其命名为 protocol/interface Command-Status-Error。上层可以通过
控制下层Status监控下层。如果Status = STATUS_ERROR，则Error有效。上层可以通过Command.它的资源效率可能不是很高（LUT、Regs），但它对调试（时间、错误定位）非常有效。
[...]我将对此进行一些怀疑的解释，你必须提供积极的解释！
分段开发SATA是一件很郁闷的事情。特别是收发器的参数搜索:)。不过我们也脑补了美好的时刻：
- 新的工作复位/断电电路 - 不再通过 FPGA 重新编程进行复位
- PicoBlaze / SoFPGA 系统通过 UART 通信 :)
- 在运行时间 重新编程SoFPGA
- 自动远程测试
如果您在开始测试第一个设计时可以立即综合下一个设计，那么您似乎正在以非常小的增量工作，但仍然努力 运行 每个级别的每个测试一直到硬件。这似乎有点overkill/expensive，尤其是当你在硬件测试上不是完全自动化的时候。
我们并不是每次都运行模拟。在设计发生重大变化之后。在我们测试一项功能的同时，我们开始测试一项新功能。这有点像晶圆生产。目前的芯片已经承载了下一代或下一代之后的电路用于测试。 => pipelining :) 一个缺点是如果发生重大错误，则必须清除管道并且必须单独测试每个功能。这种情况非常罕见。
开发过程一直是个问题：我能否在接下来的 5 天内使用我当前的工具集找到错误/解决方案，或者我应该花 1-2 周时间设计一个更好的工具可观测性？
所以我们专注于自动化和脚本，以减少人为错误。详细解释它会破坏这个答案:)。但是，例如我们的 SoFPGA 直接从 VHDL 导出 ChipScope 令牌文件。它还会在每次综合 运行 时更新汇编文件。因此，如果更改 SoFPGA 设计，所有 *.psm 文件都会更新（例如设备地址）。
另一种持怀疑态度的解释是，您正在寻找错误，但由于可观察性差，您正在生成随机试验和错误类型的构建，希望它们能提供线索你试图隔离的问题。从每次构建都增加价值的意义上说，这真的是对时间的有效利用，还是更像是“做某事总比什么都不做好”？
关于正确的
GTXE2设置，我们没有从 Xilinx 获得任何帮助。内部设计也大多不为人知。所以在某个时候它是 trial-and-error。所以唯一的办法就是缩小搜索范围 space.在设计更高的协议层时，您是否考虑过将更高层的通信栈短路以加快仿真速度？毕竟下层已经测试过了
是的，之后link 层已完成，我们保留了所有较低层（物理收发器）以加速仿真。只剩下线路延迟了。
您重复使用了一些组件并假定它们没有错误。那是因为它们附带了证明这一点的测试台吗？
重用的测试台组件被编写为正常的可综合代码。因此，在经过测试后，它在模拟和设备上运行良好。测试台组件由测试台本身测试。
您仍然有一些代码片段足够重要，可以授予它们自己的组件，但仍然太简单，无法授予它们自己的测试平台。你能举一个这样的组件的例子吗？
例如
Primitive_Mux和Primitive_Detector。 SATA 将数据字、CRC 值或原语插入到 32 位数据流中。 Primitive_Mux 是一个简单的多路复用器，但要内联到其他组件中太大了 => 可读性、封装性。就我个人而言，我不会在犯错误之前写很多行代码，所以如果我有一段像组件一样打包好的代码，我会抓住机会进行测试由于上述原因，该级别。
我认为没有人写出没有错误的代码，但我认为我的 MTBF 多年来一直在增加 ;)。
这里有一个关于如何用大锤敲碎坚果的例子:
这张由连接到 RX 相位插值器的 ChipScope 捕获的图片显示了 GTXE2 如何调整其时钟相位以保持位对齐。我们需要大约一周的时间来实施它，这样我们才能看到 GTXE2 中发生了什么。我们还需要一周时间来实施 DRP 适配器，因为选择图中显示的值的多路复用器只能通过动态重新编程来更改！幸运的是我们有我们的 SoFPGA :)
大部分线性图显示 FPGA 和 HDD 运行 以几乎相同的速度运行，具有低抖动和恒定漂移，因为使用了 2 个振荡器。三星 840 Pro 向我们展示了扩频时钟 (SSC) 行为。例如 SATA 线路频率使用三角调制可以将 6 GHz 降低多达 0.5%。谷底向我们表明内部滤波器系数无法应对 SSC。它无法处理三角调制的转折点。 => 所以现在我们需要找到新的过滤器参数。
我在各个层面进行行为模拟。即所有实体都应该有一个相应的测试平台，旨在实现完整的功能覆盖。如果实体 A、B 和 C 的特定细节已经在其相应的测试平台中被隔离测试，则它们不必包含在实例化 A、B 和 C 的实体 D 的测试平台中，实体 D 应该专注于证明集成。
我还有设备或板级测试，在实际设备或板上验证实际设计。这是因为当模型开始变得不精确并且需要很长时间时，您不能相信设备级模拟。在真实设备上测试可以达到小时而不是毫秒。
我尽量避免执行任何 post 综合模拟，除非在设备级测试中出现故障，在这种情况下，我会执行它以查找综合工具中的错误。在这种情况下，我可以对 post-综合网表进行一个小包装，并重新使用行为仿真中的测试平台。
我努力避免任何形式的手动测试，而是依靠测试自动化框架进行模拟和设备级测试，以便可以连续执行测试。
为了自动化模拟，我使用了 VUnit 测试自动化框架，@lasplund 和我本人是其作者。