串行 ATA 控制器故事
我将尝试通过示例来解释我的测试策略。
简介：
我为我的最后一个学士项目开发了一个Serial-ATA Controller，在我毕业后的几个月里，它演变成了一个非常庞大的项目。测试要求越来越高，导致每一个新的错误或性能缺陷都更难找到，所以我需要更聪明的工具、策略和解决方案来进行调试。
开发步骤：
第 1 阶段：即用型 IP 核示例
我从 Virtex-5 平台（ML505 板）和带有示例代码的 Xilinx XAPP 870 开始。此外，我还获得了 SATA 和 ATA 标准、Xilinx 用户指南以及 2 个测试驱动器。不久之后，我注意到示例代码主要是为 Virtex-4 FPGA 编写的，并且 CoreGenerator 生成了无效代码：未连接的信号、未分配的输入、有关 SATA 规范的错误配置值。
规则 #1：仔细检查生成的代码行，它们可能包含系统错误。
第 2 阶段：收发器代码的全面重写和新物理层的设计
我开发了一个新的收发器和一个物理层来执行基本的 SATA 握手协议。在我写学士报告时，没有好的GTP_DUAL收发器仿真模型，我没有时间自己写。所以我在真实硬件上测试了所有东西。可以模拟收发器，但 OOB 握手协议所需的电气空闲条件未实现或无法正常工作。在我完成报告后，Xilinx 更新了仿真模型，我可以仿真握手协议，但不幸的是一切都在运行（参见第 5 阶段）。
如何在没有仿真的情况下测试 FPGA 硬宏？
幸运的是，我有一个三星 Spinpoint HDD，它只有在有效的握手序列后才会启动。所以我有一个声音响应。
FPGA 设计配备了使用 98% 的 BlockRAM 的大型 ChipScope ILA，以监控收发器行为。这是猜测高速串行线上发生了什么的唯一可能性。我们还有其他无法解决的困难：
- 我们没有能够处理 1.5 和 3.0 GHz 信号的示波器。
- 在导线上添加探针很困难（反射，...）
- 我是计算机科学家，不是高频电气工程师 :)
规则 #2：如果您的设计还有剩余空间，请让 ILA 监督设计。
第 3 阶段：链接层
在与 2 个 HDD 成功链接后，我开始设计链接层。
这一层有大的 FSM、FIFO、加扰器、CRC 生成器等。我的本科项目提供了一些像 FIFOs 这样的组件，所以我认为这些组件没有错误。否则我可以自己启动提供的模拟并更改参数。
我自己的子组件在测试台中通过模拟进行了测试。 （=> 组件级测试）。之后我写了一个可以充当主机或设备的上层测试平台，所以我能够构建一个 4 层堆栈：
1. 测试台（类型=主机）
2. LinkLayer(Type=Host)
3. 有延迟的电线
4. LinkLayer（类型=设备）
5. 测试台（类型=设备）
SATA 链路层传输和接收数据帧。因此，用于刺激生成的正常过程语句是相当多的代码并且不可维护。我用 VHDL 开发了一个数据结构，它存储了测试用例、帧和数据字，包括流控制信息。 （=>子系统级模拟）
规则 #3：构建对应的设计（例如设备）有助于模拟。
第 4 阶段：在真实硬件上测试链路层
主机端测试平台层形式 (3) 也被编写为可综合的。所以我把它插在一起：
1. 测试台（类型=主机）
2. LinkLayer(Type=Host)
3. 物理层
4. TransceiverLayer
5. SATA线
6.硬盘
我将启动序列作为 SATA 帧列表存储在测试台的 ROM 中，并使用 ChipScope 监控 HDD 响应。
规则 #4：可综合的测试平台可以在硬件中重复使用。以前生成的 ILA 也可以重复使用。
现在是测试不同 HDD 并监控其行为的时间点。经过一段时间的测试，我可以与少数磁盘和 SSD 进行通信。一些供应商特定的解决方法已添加到设计中（例如，来自 WDC 驱动器的双 COM_INIT 响应除外 :)）
此时合成需要大约 30-60 分钟才能完成。这是由中端 CPU、> 90% 的 FPGA 利用率 (BlockRAM) 和 ChipScope 内核中的时序问题引起的。 Virtex-5 设计的某些部分以 300 MHz 运行，因此缓冲区 git 填充得非常快。另一方面，握手序列可能需要 ob 到 800 us（通常
在运行综合时，我使用不同的设备测试了我的设计，并为每个设备编写了测试结果表。如果合成完成并且 Map/P&R 非常出色，我会使用修改后的代码重新启动它。所以我有几个设计在飞行中:)。
第 5 阶段：更高层：
接下来我设计了传输层和命令层。每一层都有一个独立的测试平台，以及用于复杂子模块的子组件测试平台。 （=> 组件和子系统级别测试）
所有模块都插入到一个多层测试平台中。 A 设计了一个新的数据生成器，因此我不必对每一帧进行手动编码，只需编写帧序列即可。
- 测试台（发起者）
- 数据生成器
- 指挥层
- 传输层
- LinkLayer(Type=Host)
- 有延迟的电线
- LinkLayer(Type=Device)
- 测试台（检查器）
我还在两个 LinkLayer 实例之间添加了线路延迟，这是之前在 ChipScope 中测量的。检查器测试台与上面相同，填充了预期的帧顺序和准备好的响应帧。
规则 #5：一些延迟让您发现 FSM 之间的协议/握手问题。
第 6 阶段：回到 FPGA
堆栈再次合成。我将 ILA 策略更改为每个协议层一个 ILA。我通过 CoreGenerator 生成了 ILA，它允许我使用新的 ChipScope 内核类型，即 VIO (VirtualInputOutput)。该 VIO 通过 JTAG 将简单的 I/O 操作（按钮、开关、指示灯）传入和传出 FPGA 板。所以我可以自动化我的一些测试过程。 VIO 还能够编码 ASCII 字符串，因此我将设计中的一些错误位解码为可读消息。这使我免于搜索综合报告和 VHDL 代码。我将所有 FSM 切换为灰色编码，以节省 BlockRAM。
规则 #6：可读的错误消息节省时间
**第 7 阶段：ChipScope 调试的进步
一个层的每个 ILA 都有一个触发输出 put，它连接到其他 ILA 上的触发输入。这启用了交叉触发器。例如。可以使用这种复杂的条件：如果在 LinkLayer 收到第三个 EOF 序列后中止帧，则在 TransportLayer 中触发。
规则 #7：使用多个 ILA 并交叉连接它们的触发器。
复杂的触发器允许人们隔离故障而无需耗时的重新综合。我还开始从综合报告中提取 FSM 编码，因此我可以将提取的数据作为令牌文件加载到 ChipScope 并显示 FSM 状态及其真实名称。
第 8 阶段：一个严重的错误
接下来，我遇到了一个严重的错误。 3 帧后，我的 FSM 卡住了，但我在 ChipScope 中找不到原因，因为一切正常。我无法添加更多信号，因为 Virtex-5 只有 60 个 BlockRAM……幸运的是，我可以从 HDD 启动转储所有帧事务，直到 ChipScope 出现故障。但是，ChipScope 可以将数据导出为 *.vcd 转储。
我编写了一个 VHDL 包来解析和导入 iSim 中的 *.vcd 转储文件，因此我可以使用转储的数据来模拟完整的主机 硬盘交互。
规则 #8：转储的层间传输数据可用于模拟以获得更详细的外观。
暂停
到那时，SATA 堆栈已经相当完整，并通过了我所有的测试。我被分配到另外两个项目：
- 通用 UDP/IPv4/IPv6 堆栈和
- “远程可控测试设计控制器”
第一个项目重用了基于框架的测试平台和每层/协议 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 控制器，需要将板载时钟发生器从 156.25 重新编程到 150 MHz。我还实现了测量模块来测量传输率、经过的时间等。来自控制器的错误位连接到 SoFPGA 的中断引脚，错误显示在 Putty 屏幕上。我还为故障注入添加了 SoFPGA 可控组件。例如，可以将位错误插入 SATA 原语，但不能插入数据字。
使用这种技术，我们可以证明多个 SATA 设备（HDD 和 SSD）中的协议实现错误。它可能导致某些设备的链路层 FSM 死锁。这是由 LinkLayer FSM 转换图中的缺失边引起的 :)
使用 SoFPGA 方法，可以轻松修改测试、重置设计、报告错误，甚至进行基准测试。
规则 #9：使用软核允许您在软件中编写测试/基准测试。详细的错误报告可以通过终端消息完成。可以通过 JTAG 上传新的测试程序 -> 无需综合。
但我犯了一个大错误
第 0 阶段：回到起点：
我的重置网络非常非常糟糕。所以我在两所学院的帮助下重新设计了重置网络。新的时钟网络对时钟线和 MMCM 具有单独的复位，以及用于指示正确时钟信号和频率的稳定信号。这是必要的，因为外部输入时钟在运行时被重新编程，SATA 生成变化可能导致运行时时钟分频器切换，收发器中的复位序列可能导致收发器的时钟输出不稳定。此外，我们实现了一个断电信号，从零开始。因此，如果 SoFPGA 触发断电/上电序列，则 SATA 控制器与对 FPGA 编程后一样新。这样可以节省大量时间！
规则#0：对每个测试以相同的方式执行正确的重置。无需对 FPGA 重新编程。添加交叉时钟电路！这可以防止许多随机故障。
注意事项：
SATA 控制器的一些子组件发布在我们的PoC-Library 中。还有一些测试平台包和脚本来简化测试。 SoFPGA 内核也已发布。我的PicoBlaze-Library 项目简化了 SoC 开发。
来自@lasplund 的问题 - 第一部分：
-
可以公平地说你的测试水平是
组件级（CRC、复杂 FSM 的模拟）、子系统级（模拟
您的一层），顶级模拟，无软件实验室测试，实验室测试
带软件（使用 SoFPGA）？
是的，我对中型组件进行了组件测试。其中一些已经可以使用，我信任开发人员。小组件在子系统级测试中进行了测试。我相信我的代码，所以没有单独的测试平台。如果有问题，我会在更大的测试台上看到它。
当我开始开发的第二部分时，我使用了顶级测试平台。一方面有一个可用的模拟模型，但速度很慢（一个简单的帧传输需要几个小时）。另一方面，我们的控制器充满了 ILA，而 Kintex-7 提供了数百个 BlockRAM。合成大约需要 17 分钟（包括 10 个 ILA 和一个 SoFPGA）。所以在这个项目中，实验室测试比模拟更快。许多改进（令牌文件、SoFPGA、跨 ILA 触发）大大简化了调试过程。
-
您能否大致说明您的验证工作（开发
并在该级别上运行测试和调试）在您的级别之间分配？
我认为这很难说。我在 SATA 上工作了 2 年，在 IPv6 / SoFPGA 上工作了一年。我认为大部分（> 60％）时间都花在“外部调试”上。例如：
- 调试 VHDL 工具（XST、CoreGenerator、iSim、Vivado、ModelSim、Quartus、GHDL，...）
我在这些工具中发现了大量的错误，其中大部分都被报告了。有些是无法解决的。
- 第二大部分时间花在了 FPGA 设备调试上。
我在设备中发现了几个未报告和“秘密/沉默”的错误（尤其是在 7 系列 FPGA 中）。一段时间后，您开始相信设备存在错误，您只针对此错误开发了硬件测试。您可以证明这一点，但赛灵思会忽略您的所有错误报告......！
- 还有不同设备的测试。
所有设备都遵循 SATA 规范，但有些设备不与我们的 SATA 'conform' 控制器通信。然后你开始尝试不同的计时、超时、控制字……直到你找到设备中的错误。如果发现这种情况，您将开始开发一种解决方法，但它也必须适用于所有以前测试过的设备！
-
使用类似的分布，你在哪里检测到你的错误，你在哪里
找出根本原因？我的意思是你在实验室检测到的可能
需要模拟来隔离。
如前所述，大多数测试都是实验室测试，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 终端控制。我们仅用 3 次综合运行在 4 小时内测试了超过 100 种配置。合成每个配置花费了我们数周的时间......
来自@lasplund 的问题 - 第二部分：
-
当您在实验室中发现需要更改设计的错误时，您会在可以测试的最低级别更新测试平台吗？
是的，我们更新了测试台以反映更改后的实现，因此我们希望不会再次陷入同样的陷阱。
-
您说大多数测试都是在实验室中完成的，这是由您必须调试的大量外部问题引起的。如果你只看你自己的内部代码和错误，你的答案是一样的吗？
我设计了具有相同安全性的状态机。例如，总是有其他情况或其他情况。因此，如果其中一个开发人员（现在我们是四人组）添加了新状态并错过了边缘左右，这些转换就会被捕获。每个 FSM 至少有一个错误状态，由转换错误或子组件报告错误进入。每层生成一个错误代码。错误条件冒泡到最顶层的 FSM。根据错误的严重性（可恢复、不可恢复、..），上层 FSM 执行恢复过程或暂停。所有 FSM 的状态加上错误条件由 ChipScope 监控。因此，在大多数情况下，可以在不到一分钟的时间内发现故障。 (FSM State; Error Code) 的元组大部分都非常准确地确定了原因，所以我可以命名一个模块和代码行。
我们还花费大量时间来设计层/FSM 交互协议。我们将此协议/接口命名为 Command-Status-Error。上层可以通过Status监控下层。如果Status = STATUS_ERROR，则Error 有效。上层可以通过Command控制下层。
它的资源效率可能不是很高（LUT、Regs），但它对于调试（时间、错误定位）非常有效。
-
[...]我将对此进行一些怀疑的解释，你必须提供积极的解释！
分段开发 SATA 是一项非常令人沮丧的任务。尤其是收发器的参数搜索:)。但我们也会迎来美好的时刻：
- 新的有效复位/断电电路 - 不再通过 FPGA 重新编程进行复位
- PicoBlaze / SoFPGA 系统通过 UART 通信 :)
- 在运行时重新编程 SoFPGA
- 自动化远程测试
-
如果您可以在开始测试第一个设计时立即综合下一个设计，那么您似乎在使用非常小的增量，但仍然努力在每个级别上运行每个测试，一直到硬件。这似乎有点矫枉过正/昂贵，尤其是当您没有完全自动化硬件测试时。
我们并非每次都运行模拟。就在设计发生重大变化之后。当我们测试一项功能时，我们开始测试一项新功能。这有点像晶圆生产。目前的芯片已经承载了下一代或下一代之后的电路进行测试。 => 流水线 :) 一个缺点是如果发生重大错误，则必须清除流水线并且必须单独测试每个功能。这种情况非常罕见。
开发过程始终是一个问题：我能否使用我当前的工具集在接下来的 5 天内找到错误/解决方案，还是应该投入 1-2 周的时间来设计一个具有更好可观察性的更好工具？强>
因此，我们专注于自动化和脚本编写以减少人为错误。详细解释它会破坏这个答案:)。但例如我们的 SoFPGA 直接从 VHDL 导出 ChipScope 令牌文件。它还在每次综合运行时更新汇编文件。因此，如果更改 SoFPGA 设计，所有 *.psm 文件都会更新（例如设备地址）。
-
另一种怀疑的解释是，您正在寻找一个错误，但由于可观察性差，您正在生产随机试验和错误类型的构建，希望它们能为您试图隔离的问题提供线索。从每次构建都增加价值的意义上说，这是否真的有效地利用了时间，还是“做某事总比什么都不做更好”？
关于正确的GTXE2 设置，我们没有从赛灵思获得任何帮助。内部设计也大多是未知的。所以在某些时候，它是反复试验的。所以唯一的办法就是缩小搜索范围。
-
在设计更高的协议层时，您是否考虑过在更高级别上短路通信堆栈以加快仿真速度？毕竟底层已经测试过了。
是的，在链路层完成后，我们放弃了所有较低层（物理收发器）以加快仿真速度。只剩下线路延迟。
-
您重用了一些组件并假设它们没有错误。那是因为它们附带的测试台证明了这一点吗？
重用的测试台组件被编写为普通的可综合代码。因此，经过测试后，它在模拟和设备上运行良好。测试台组件由测试台本身测试。
-
您仍然有足够重要的代码片段被授予他们自己的组件，但仍然太简单而无法获得他们自己的测试平台。你能举一个这样的组件的例子吗？
例如Primitive_Mux 和Primitive_Detector。 SATA 将数据字、CRC 值或原语插入 32 位数据流。 Primitive_Mux 是一个简单的多路复用器，但要内联到其他组件中 => 可读性、封装性。
-
就我个人而言，在我犯错之前我不会写很多行代码，所以如果我有一个像组件这样打包好的代码，出于上述原因，我会借此机会在该级别进行测试。
我认为没有人编写没有错误的代码，但我认为我的 MTBF 多年来一直在增加 ;)。
这是一个关于如何用大锤敲碎坚果的例子：
这张由连接到 RX Phase Interpolator 的 ChipScope 捕获的图片显示了 GTXE2 如何调整其时钟相位以保持位对齐。我们需要大约一周的时间来实现它，所以我们可以看到 GTXE2 中发生了什么。我们需要一周时间来实现 DRP 适配器，因为选择图中显示的值的多路复用器只能通过动态重新编程来更改！幸运的是我们有我们的 SoFPGA :)
大部分线性图显示 FPGA 和 HDD 以几乎相同的速度运行，具有低抖动和恒定漂移，因为使用了 2 个振荡器。三星 840 Pro 向我们展示了扩频时钟 (SSC) 行为。例如 SATA 线路频率使用三角调制可以将 6 GHz 降低多达 0.5%。谷值向我们表明内部滤波器系数无法应对 SSC。它无法处理三角调制的转折点。 => 所以现在我们需要找到新的过滤器参数。