tdd - 在Verilog或VHDL中进行逻辑(芯片)设计的测试驱动开发(TDD)的经验

Question

我已经在网上查看过，讨论/示例似乎是针对传统软件开发的。由于Verilog和VHDL(用于芯片设计，例如FPGA和ASIC)与软件开发C和C++类似，因此似乎很有意义。但是，它们在本质上是并行的并且需要硬件进行完全测试之间存在一些差异。

您有什么经验，好与坏？您可以在此特定应用程序上建议任何链接吗？

编辑/说明:
2009年10月28日:我特别想询问TDD。我熟悉测试台，包括自检台。我也知道SystemVerilog具有一些针对测试台的特殊功能。

2009年10月28日:隐含的问题包括1)编写任何功能的测试，从不使用波形进行仿真，以及2)首先编写测试/测试台。

2009年11月29日:在Empirical Studies Show Test Driven Development Improves Quality中，他们报告了(软件)TDD:“以每千行代码的缺陷来衡量，四种产品的预发布缺陷密度相对于未发布的项目，降低了40％至90％团队的管理人员主观上报告说，使用TDD的团队的初始开发时间增加了15–35％，尽管团队一致认为这被降低的维护成本所抵消。”减少的错误减少了流片的风险，但以适度的进度影响为代价。 This也有一些数据。

2009/11/29:我主要在做控制和数据路径代码，而不是DSP代码。对于DSP，典型的解决方案涉及Matlab位精确仿真。

2010年3月2日:TDD的优点是您可以确保测试首先失败。我想这也可以通过断言来完成。

Answer 1

我为FPGA而不是ASICS编写代码，但是TDD仍然是我的首选方法。我喜欢对我编写的所有功能代码进行一整套测试，然后尝试(并非总是成功)首先编写测试代码。调试时总是会凝视波形，但这不是验证代码(IMHO)的好方法。

考虑到在实际硬件中执行适当测试的困难(刺激极端情况特别困难)，并且VHDL编译需要几秒钟(与“到硬件”编译需要几分钟(甚至几小时)相比)，我不知道看不到任何人可以以任何其他方式操作!

在编写RTL时，我还将其声明置入其中，以捕获我不应该发生的事情。显然，这被认为有些“怪异”，因为人们普遍认为验证工程师会编写断言，而RTL设计人员却不会。但是大多数情况下，我是我自己的验证工程师，所以也许这就是原因!