怎样写Testbenches【2】-- 序言

目录

为什么这本书如此重要

这本书讲什么

您应该具备的先修知识

VHDL VS Verilog

想要获得更多的信息

致谢

---

本文是对Janick Bergeron的《Write Testbenched:Functional verification of HDL models》的翻译。在翻译过程中，因为译者水平原因和基础知识所限，会导致部分错误，如发现错误请读者参考原文。译者不理解的部分也会重点标注，并标注出在原书的位置。

 

如果对任何一个硬件设计团队进行调查，我们会发现，验证工作占据了他们60%到80%的工作量。与可综合的编码不同，验证不需要特定的编码风格。使用这些语言的任何特性可以产生各种各样的验证技术和方法。在验证中，缺少约束和缺乏可用的专业知识以及参考，会导致工程师在工作中使用许多临时的验证方法。非正规的验证过程所带来的后果，其从需要多次重新返工的非功能性设计，到仅符合预期功能的部分逻辑设计，再到导致延迟发货。

 

为什么这本书如此重要

---

如果我们翻看市场上介绍Verilog或VHDL的书籍就会发现，书中绝大多数页面都在解释语言的语法等详细信息。其他的页面介绍可综合的编码风格，以及一些具体实例。有一些书甚至完全在介绍如何进行RTL编码。在介绍验证时，仅仅有一到两章专门讨论该主题。通常情况下，验证主要关注的是引入更多的语法结构。在这些书中，验证章节介绍的浅显，粗略，介绍的都是简单的技术，这些技术在进行大规模集成电路设计中变得乏善可陈。

自从上世纪80年代中期硬件描述语言和逻辑综合技术诞生以来，为了达到期望的综合效果，人们设计了许许多多关于编码风格和综合方法的专业知识。这些知识中，许多已经在重要的会议上提出，并被编入了教科书，作为了入门阶段和高级阶段的培训课程。而现在的书籍，是在早期以语言介绍为重点的书籍的基础上重新编辑，包含了可综合编码的章节。综合过程虽然比较复杂，但现在对设计工程师和相关技术人员来说已经很好理解，并且现在有许多资源可以帮助相关技术人员理解综合。同时，现在也有许多标准程序和技术，可以预测综合结果。

在“我”开始编写这本书的时候，它是第一本专门用于硬件模型验证技术的书。此书将会向读者介绍最新的验证技术，这些技术已经成功用于生产ASIC，SoC，电路板和整个系统。

 

这本书讲什么

---

“我”将首先介绍验证的必要概念和工具，然后“我”将描述对设计进行有效功能验证的过程。并且将会介绍那些在综合语法中经常被忽略或过度简化的语法含义。这些不熟悉的语义，在理解什么是优良的设计实现，什么是强大的测试平台设计，以及在提供必要的控制和监测功能方面将会变得非常重要。

同时，“我”还将通过使用总线功能模型的抽象操作来应用外部激励和监控设计相应技术。围绕这些总线功能模型构建的测试平台架构，将会最大限度地减少开发和维护工作。

行为建模是本书中所提出的另一个重要概念。它用于并行化设计的实现和验证，并执行更有效的仿真。许多人认为，行为建模和可综合或RTL建模是相同的。在本书中，术语“行为”用于描述任何可以充分仿真的设计功能的模型，通常使用不可综合的结构和代码风格。

 

您应该具备的先修知识

---

本书着眼于介绍使用VHDL或Verilog语言进行硬件设计的功能验证。“我”希望读者至少掌握着两种语言中的至少一种。读者最好应该具备用VHDL或Verilog编写可综合模型的经验，同时熟悉使用任何一种硬件描述语言进行仿真。这本书中涉及到的内容不会有语言语法相关的介绍和描述，所以读者可以使用一本以介绍硬件描述语言为中心的书与本书配套使用。

同时，“我”还希望读者对数字硬件设计有基本的了解。本书使用了来自不同应用领域（视频、数据通信、计算等）的集中假设设计。这些设计该如何设计详细设计，使用何种架构，以及如何实施均不在本书的讨论范围之内。本书的内容侧重于规范，架构，以及这些相似设计的验证该如何实现。

读者应该从头到尾认真地阅读本书。但是，如果您时间紧迫，这里提供一下建议的阅读路径。

如果您将本书用作为大学教材，那么您应该关注第4章（Chapter 4），第5章（Chapter 5）和附录A（Appendix A）。如果您是刚刚入门硬件设计的初级工程师，您可以跳过第3章（Chapter 3），第6章（Chapter 6），第7章（Chapter 7）。如果您是有经验的工程师，请务必记得阅读这几个章节。

对负责定义项目验证策略的高级工程师来说，他们会对第3章（Chapter 3），第6章（Chapter 6）以及附录A（Appendix A）感兴趣。如果您是经验丰富的工程师，您可能希望跳到第3章（Chapter 3）。如果您是经验丰富的Verilog或VHDL用户，您可能希望跳到第4章（Chapter 4）。但无论如何，请您阅读前面的章节，这只是为了确保我们对“经验丰富”的定义相匹配。

如果您有软件设计的背景，第7章（Chapter 7）和附录A（Appendix A）对您来说会容易理解。如果您有硬件设计和RTL编码思维经验，第4章（Chapter 4）和第7章（Chapter 7）将可能是您最好的朋友。如果您的职责仅限于管理硬件验证项目，请您更多地专注于第3章（Chapter 3），第6章（Chapter 6）和第7章（Chapter 7）。

 

VHDL VS Verilog

---

一个设计团队经常面临的第一个决定是使用哪种硬件描述语言。作为本书的作者，“我”也面临同样的困境。答案通常由设计者个人自己的知识或者个人偏好决定。

“我”对这两种语言都很了解，“我”同时都在使用这两种语言，“我”也同时在教授这两种语言。当“我”被问到更喜欢哪种语言的时候，“我”通常会回答这是错误的问题，正确的问题应该是“‘我’最不喜欢哪一个语言？”针对这个问题的答案是：“‘我’目前还没有使用过的那一个。”

但在我看来，两种语言本身都具有不足之处，特别是在验证时。它们对于可综合的描述一样的差。有些东西在一种语言比在另一种语言中要更容易实现。对于一个特性模型，这样一种语言优于另外一种语言：其具有更好的映射到要建模的功能的能力。但是一般来说，VHDL和Verilog两者都没有比对方更好。

验证技术超越了所使用的语言。VHDL和Verliog都只是实施的工具。两者都在本书中使用，但这并不是说这本书是双语言的。书中的例子只用一种语言表示，我相信只能进行VHDL阅读的编译器或只能进行Verilog阅读的编译器都能理解另一种语言的例子，即使语法略有不同。

本书中的有些部分只用了verilog语言，根据“我”的经验，Verilog是一种使用更加广泛的语言。它具有比VHDL更易于学习的特点，并且它的学习曲线不那么陡峭。但是这两种语言都有类似的概念：顺序语句，并行结构，结构构造和illsion of parallelism.（此处翻译有障碍）

（……）（接下来此段不用翻译，序言部分的此处略有啰嗦）

 

想要获得更多的信息

---

如果您想了解本书中提到的主题的更多信息，可以在以下网址中找到相关资源的链接：

http://janick.bergeron.com/wtb

在以上网址的resource区域，您可以找到公共可用的实用程序，文件和工具的链接。以便更轻松地完成验证任务。您还将会找到一个勘误表，该表列出并纠正在书中出现的错误。

该网站还有一套与本书每章都相应的测验。“我”建议您完成它们以验证您对书中内容的理解。您设置可以选择从测验开始，以确定是否需要阅读该章节。

 

致谢

---

（……）（本部分作者感谢了其妻子一起其他相关人员，还感谢了一款软件。不做翻译。我要感谢作者的这本很棒的关于验证的书）

 

原文位置：《Writing Testbench:Functional verification of HDL Models》 xvii-xxii

版权归原作者所有，如有侵权，请联系删除。