具有 Verilog 或 VHDL 逻辑（芯片）设计测试驱动开发 (TDD) 经验
我在网上查看过，讨论/示例似乎是针对传统软件开发的。由于Verilog 和VHDL（用于芯片设计，例如FPGA 和ASIC）与软件开发C 和C++ 类似，因此这似乎是有道理的。然而，它们有一些差异，本质上是并行的，并且需要硬件进行全面测试。
你有过哪些经历，无论是好的还是坏的？您可以建议有关此特定应用程序的任何链接吗？
编辑/澄清： 2009 年 10 月 28 日：我特别询问 TDD。我熟悉测试台，包括自检台。我还知道 SystemVerilog 有一些针对测试平台的特殊功能。
2009 年 10 月 28 日：隐含的问题包括 1) 为任何功能编写测试，切勿使用波形进行仿真，以及 2) 首先编写测试/测试平台。
2009 年 11 月 29 日：实证研究表明测试驱动开发可以提高质量 他们针对（软件）TDD 报告“四种产品的预发布缺陷密度（以每千行代码的缺陷来衡量）相对于未使用 TDD 的项目下降了 40% 到 90%。团队的管理层主观报告使用 TDD 的团队的初始开发时间增加了 15-35%，尽管团队一致认为这被维护成本的降低所抵消。”错误的减少降低了流片风险，但代价是对进度造成适度影响。 这也有一些数据。
2009 年 11 月 29 日：我主要负责控制和数据路径代码，而不是 DSP 代码。对于 DSP，典型的解决方案涉及 Matlab 位精确仿真。
03/02/10：TDD 的优点是确保测试首先失败。我想这也可以通过断言来完成。
I have looked on the web and the discussions/examples appear to be for traditional software development. Since Verilog and VHDL (used for chip design, e.g. FPGAs and ASICs) are similar to software development C and C++ it would appear to make sense. However they have some differences being fundamentally parallel and requiring hardware to fully tests.
What experiences, good and bad, have you had? Any links you can suggest on this specific application?
Edits/clarifications:
10/28/09: I'm particularly asking about TDD. I'm familiar with doing test benches, including self-checking ones. I'm also aware that SystemVerilog has some particular features for test benches.
10/28/09: The questions implied include 1) writing a test for any functionality, never using waveforms for simulation and 2) writing test/testbenches first.
11/29/09: In Empirical Studies Show Test Driven Development Improves Quality they report for (software) TDD "The pre-release defect density of the four products, measured as defects per thousand lines of code, decreased between 40% and 90% relative to the projects that did not use TDD. The teams' management reported subjectively a 15–35% increase in initial development time for the teams using TDD, though the teams agreed that this was offset by reduced maintenance costs." The reduced bugs reduces risk for tape-out, at the expense of moderate schedule impact. This also has some data.
11/29/09: I'm mainly doing control and datapath code, not DSP code. For DSP, the typical solution involves a Matlab bit-accurate simulation.
03/02/10: The advantage of TDD is you make sure the test fails first. I suppose this could be done with assertions too.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
我为 FPGA 编写代码，而不是 ASICS……但 TDD 仍然是我的首选方法。我喜欢对我编写的所有功能代码进行全套测试，并且我尝试（并不总是成功）首先编写测试代码。当您调试时，总会在某个时刻盯着波形看，但这不是验证代码的好方法（恕我直言）。
考虑到在真实硬件中执行正确测试的难度（刺激极端情况尤其困难）以及 VHDL 编译需要几秒钟的事实（相对于“硬件”编译需要花费几分钟（甚至几小时）），我不认为不明白怎么会有人以其他方式进行操作！
我还在编写 RTL 时将断言构建到 RTL 中，以捕获我知道不应该发生的事情。显然，这被认为有点“奇怪”，因为人们认为验证工程师会编写断言，而 RTL 设计人员不会。但大多数情况下，我是自己的验证工程师，所以也许这就是原因！
I write code for FPGAs, not ASICS... but TDD is my still my preferred approach. I like to have a full suite of tests for all the functional code I write, and I try (not always successfully) to write testcode first. Staring at waveforms always happens at some point when you're debugging, but it's not a good way of validating your code (IMHO).
Given the difficulty of performing proper tests in the real hardware (stimulating corner cases is particularly hard) and the fact that a VHDL-compile takes seconds (vs a "to hardware" compile that takes many minutes (or even hours)), I don't see how anyone can operate any other way!
I also build assertions into the RTL as I write it to catch things I know shouldn't ever happen. Apparantly this is seen as a bit "weird", as there's a perception that verification engineers write assertions and RTL designers don't. But mostly I'm my own verification engineer, so maybe that's why!
我使用 VUnit 通过 VHDL 进行测试驱动开发。
VUnit是一个Python库，它调用VHDL编译器和模拟器并读取模拟结果。它还提供了几个不错的 VHDL 库，使编写更好的测试平台变得更加容易，例如 通信库、日志库和检查库。
因为它是从 Python 调用的，所以有很多可能性。可以生成测试数据，也可以在 Python 中检查测试的输出数据。前几天我看到了这个例子，他们使用了 Octave - Matlab 副本 -用于绘制测试结果。
VUnit 似乎非常活跃，我已经好几次能够直接向开发人员提出问题并很快获得帮助。
缺点是调试编译错误比较困难，因为库中有很多同名的函数/过程变体。此外，有些事情是通过预处理代码在幕后完成的，这意味着一些错误可能会出现在意想不到的地方。
I use VUnit for test driven development with VHDL.
VUnit is a Python library that invokes the VHDL compiler and simulator and reads the results of the simulation. It also provides several nice VHDL libraries that makes it a lot easier to write better test benches, such as a communication library, logging library and a checking library.
There are many possibilities since it is invoked from Python. It is possible to both generate test data, as well as check the output data from the test in Python. I saw this example the other day where they used Octave - a Matlab copy - for plotting test results.
VUnit seems very active and I have several times been able to actually ask questions directly to the developers and gotten help quite quickly.
A downside is that it is harder to debug compilation errors since there are so many function/procedure variations with the same name in the libraries. Also, some stuff is done behind the scene by preprocessing the code, which means that some errors might show up in unexpected places.
我对硬件/芯片设计了解不多，但我对TDD很感兴趣，所以我至少可以和你讨论一下流程的适用性。
我认为最相关的问题是：您的测试能够多快为您提供设计反馈？与此相关：您添加新测试的速度有多快？您的工具对设计重构（改变结构而不改变行为）的支持程度如何？
TDD 过程在很大程度上取决于软件的“柔软度”——良好的自动化单元测试可以在几秒钟内（外部是几分钟）运行，并指导短暂的集中构建和重构。您的工具是否支持这种工作流程 - 在编写和运行测试之间快速循环以及在短迭代中构建被测系统？
I don't know a lot about hardware/chip design, but I am deeply into TDD, so I can at least discuss suitability of the process with you.
The question I'd call most pertinent is: How quickly can your tests give you feedback on a design? Related to that: How quickly can you add new tests? And how well do your tools support refactoring (changing structure without changing behavior) of your design?
The TDD process depends a great deal on the "softness" of software - good automated unit tests run in seconds (minutes at the outside), and guide short bursts of focused construction and refactoring. Do your tools support this kind of workflow - rapidly cycling between writing and running tests and building the system under test in short iterations?
SystemVerilog 对 IEEE Verilog 标准的扩展包括
各种有助于创建全面测试套件的构造
用于验证复杂的数字逻辑设计。 SystemVerilog 是其中之一
用于验证 ASIC 芯片的硬件验证语言 (HVL)
通过仿真进行设计（与仿真或使用 FPGA 不同）。
与传统硬件设计语言 (Verilog) 相比，显着优势包括：
关键是可以访问支持以下功能的仿真软件：
最近的（2005 年）标准。并非所有模拟器都完全支持
更高级的功能。
除了 IEEE 标准之外，还有一个开源 SystemVerilog 库
VMM Central (http://www.vmmcentral.com) 提供的验证组件。它为创建测试环境提供了合理的框架。
SystemVerilog不是唯一的HVL，VMM也不是唯一的库。
但是，我会推荐两者，如果您可以访问适当的
工具。我发现这是寻找设计的有效方法
在成为硅之前存在错误。
The SystemVerilog extensions to the IEEE Verilog Standard include
a variety of constructs which facilitate creating thorough test suites
for verifying complex digital logic designs. SystemVerilog is one of
the Hardware Verification Languages (HVL) which is used to verify ASIC chip
designs via simulation (as opposed to emulation or using FPGA's).
Significant benefits over a traditional Hardware Design Language (Verilog) are:
The key is to have access to simulation software which supports
this recent (2005) standard. Not all simulators fully support
the more advanced features.
In addition to the IEEE standard, there is an open-source SystemVerilog library
of verification components available from VMM Central (http://www.vmmcentral.com). It provides a reasonable framework for creating a test environment.
SystemVerilog is not the only HVL,and VMM is not the only library.
But, I would recommend both, if you have access to the appropriate
tools. I have found this to be an effective methodology in finding design
bugs before becoming silicon.
关于硬件语言的重构工具，我想向您推荐我们的工具Sigasi HDT。 Sigasi 提供了一个带有内置 VHDL 分析器和 VHDL 重构的 IDE。
菲利普·费斯，西加西
With regard to refactoring tools for hardware languages, I'd like to point you to our tool Sigasi HDT. Sigasi provides an IDE with built-in VHDL analyzer and VHDL refactorings.
Philippe Faes, Sigasi
ANVIL——另一个 Verilog 交互层对此进行了一些讨论。我没试过。
ANVIL– ANother Verilog Interaction Layer talks about this some. I haven't tried it.
我从未在 RTL 设计上积极尝试过 TDD，但我对此有自己的想法。
我认为有趣的是尝试这种与断言相关的方法。基本上，您首先会以断言的形式写下您对模块的假设/期望，编写 RTL，然后您可以使用正式工具和/或模拟来验证这些断言。与“正常”测试用例（您可能需要编写定向测试用例）相比，您应该有更好的覆盖范围，并且断言/假设也可能在以后使用（例如在系统级别）。
不过我不会完全依赖断言，这可能会变得非常棘手。
也许你也可以表达一下你的想法，因为你在要求它，我想你脑子里有一些想法？
I never actively tried TDD on an RTL design, but I had my thoughts on this.
What I think would be interesting is to try out this approach in connection with assertions. You would basically first write down in form of assertions what you assume/expect from your module, write your RTL and later you can verify these assertions using formal tools and/or simulation. In contrast to "normal" testcases (where you probably would need to write directed ones) you should have much better coverage and the assertions/assumptions may be of use later (e.g. on system level) as well.
However I wouldn't fully rely on assertions, this can become very hairy.
Maybe you can express your thoughts on this as well, as you are asking for it I guess you carry some ideas in your head?
TDD 对您来说是什么？您的意思是让所有代码始终通过自动测试来执行，还是进一步意味着测试是在代码之前编写的，除非测试失败，否则不会编写新代码？
无论您喜欢哪种方法，HDL 代码测试与软件测试没有太大区别。它有其优点（更好的测试覆盖范围和深度）和缺点（相对于软件而言难以设置且麻烦）。
我在使用 Python 和通用 HDL 事务处理程序对可综合 HDL 模块实施全面和自动测试方面拥有非常丰富的经验。这个想法有点类似于 Janick Bergeron 在他的书中提出的，但不是 SystemVerilog，而是使用 Python (1) 从用 Python 编写的测试场景生成 VHDL 代码，以及 (2) 验证在仿真期间接受设计波形的监控事务处理程序编写的结果。
关于这项技术还有很多东西要写，但我不确定你想关注什么。
What is TDD for you? Do you mean having all your code exercised by automatic tests at all times, or do you go further to mean that tests are written before the code and no new code is written unless tests fail?
Whichever approach you prefer, HDL code testing isn't very different from software testing. It has its pluses (much better coverage and depth of testing) and minuses (difficult to set up and cumbersome relatively to software).
I've had very good experience with employing Python and generic HDL transactors for implementing comprehensive and automatic tests for synthesizable HDL modules. The idea is somewhat similar to what Janick Bergeron presents in his books, but instead of SystemVerilog, Python is used to (1) generate VHDL code from test scenarios written in Python and (2) verification of results written by the monitoring transactors that accept waveforms from the design during simulation.
There's much more to be written about this technique, but I'm not sure what you want to focus on.