Digital Circuit Functional Verification(八)

现代功能测试环境中所用到的工具

•  模拟程序：对功能测试来说是必不可少的。

•  代码覆盖工具：可以使得测试中某些单调的任务自动执行，并增加
功能测试输出结果的可信度。

•  测试人员任务：使用必要的工具来保证测试结果并非II型错误，也
即确保不出现代码错误不被发现。

•  项目主管：保证用预定的资金，按预定的计划出产品，责任是使
手下的开发人员用恰当的工具，以充份的自信来完成自己的工
作。同时要判断寻找功能缺陷的花费是否已经超过了改进功能所
带来的效益，而这个工作尤为重要，某些工具能帮住找到这个临界点。

1 检错工具 ( LlNTING TOOLS )

2 模拟 (SIMULATORS) 

3 第三方模型 (THIRD-PARTY MODELS)

4 示波器 (WAVEFORM VIEWERS)

5 代码覆盖CODE COVERAGE

6 测试语言( VERIFICATlON  LANGUAGES)

7 版本控制 (REVISION CONTROL)

8 ISSUE TRACKING问题追踪

看看你的部落格值多少錢

這是本土MIT的產品

它可以幫你估價你的網站值新台幣多少錢

還有每日瀏覽頁數及每日收入預估

方法極為簡單

點擊連結  http://seo.holyfree.org/www.freegroup.org 

再把你的網址貼上即可

Digital Circuit Functional Verification(七)

测试费用(THE COST OF VERIFICATION )

• 测试是一个看似永远都不会结束的过程。
• 测试的目的是保证一个设计不出错，但任何人都不能证明设计完全没错。
• 测试只能证明有错，而不能证明无错，多花点时间，总能找到错误的。
问题是：
a)  错误是否严重到值得花时间去寻找的地步？
b)  在测试上花的时间越多，在一定时间内能找到的错误就越少。
c)  到了后来，就几乎没有错误了。
d)  最后，花的时间越来越多，找出的错误越来越少，甚至找不出错误了。

功能测试判断
类似统计假设检验。检验的假设条件是：设计是否能正确实现其功
能？答案可以是“是” 或“否” ，但两种答案都有可能出错。
两种错误答案分别是II型错误和I型错误

什么时候才算测试完？
了解测试过程的大致进度，尽管不可能精确知道，但由此
可以推算出完成整个工作需要多长时间。

Digital Circuit Functional Verification(六)

检测与测试的比较( TESTING VERSUS VERIFICATION )

Verification => 保证在功能上实现设计要求
Testing       => 最后的硬件结构和制造工艺中的网表一致

1. 扫描测试(Scan-Based Testing ) (DFT-ATPG)

目的：扫描检测在某种程度上解决检测覆盖问题
方法：把所有的寄存器组成一个很长的串行链。在正常的状态下，
寄存器正常工作，在扫描状态下，寄存器则表现为一个很长的移位寄存器。

• 进行扫描检测时，检测对象必须置于扫描状态，再用一个输入量移位通
过所有的寄存器。
• 把检测对象置为正常状态，外加一个单时钟周期，把扫描状态下的正常
运行结果载入寄存器。
• 再一次把检测对象置为扫描状态。由寄存器输出结果（同时输入下一个
变量），并把它和期望值比较。
为了能插入扫描链和自动产生检测形式，设计必须受到一些限制。这些
限制包括：完全的同步性，没有导出时钟和门控时钟，只能使用时钟的
单个边沿，等等。

2. 为测试而设计 (BIST...)

• 设计方案作某些修订，以适应测试的要求。
• 因为功能测试所花的时间是设计本身的两倍，所以完全有必要在设计
上多花点时间，以简化测试过程。
• 正如设计中插入扫描链可以增加可检测性而不增加功能一样，应该在
设计中加入非功能性结构和特征以适应测试的需要。
• 要求在一个项目的开始就考虑到测试，尤其是在制定要求的阶段。
• 设计本身不仅要回答“要实现什么功能？”，而且要回答“如何来进行测
试？”。
• 典型的技术包括: 额外提供可软件编码的的寄存器，以控制和观察内部
地址，或用另外的可编程器件来隔离或绕过某些功能部件。

3 测试与设计方案再用(IPs)

设计能够被再用的关键是取得别人的信任： 设计再用最大的障碍是人为差
异，设计人员都不大愿意在自己的设计过程中引进不熟悉的方法和结果，他
们认为别人设计的没有自己亲自设计的好，或着不如自己设计的可靠。
是否值得信任的特征是看有没有一个适当的测试过程。如果能向用户证明该
设计曾按照要求从头到尾认真测试过，那么就能取得用户的信任。
再用一项设计，只能通过功能测试来证明其正确性。因此，可再用设计和一
般的设计比起来，更需要通过测试来取得信任。
可再用设计需更加结构化，更具有可编程性，方能满足不同的环境条件和不
同的应用，所以所有可能的结构和应用都要测试到。可再用设计所有的特点
都要展示给用户，并作出测试。

Digital Circuit Functional Verification(五)

功能测试方法

FUNCTIONAL VERIFICATION APPROACHES
功能测试可以用三种不同但互补的方法：
黑箱测试 (black-box )
白箱测试 (white-box )
灰箱测试 (grey-box )

黑箱测试(black-box Verification )
黑箱测试是在对设计的具体情况一无所知的前提下进行的，所有的
测试都是利用外部接口，而不考虑起内部状态，更不知道其结构和
实现方法。
缺点 : 缺乏可视性和可控性，很难进行状态组合或独立测试某些功
能，也难以观察它对输入的反应或找到问题所在之处。从出现问题
到它在输出结果中表现出来通常都有很长的延时。
优点 : 不用考虑测试对象是如何实现其功能的，无论它是用ASIC，
FPGA，电路板，还是用软件实现的，都无关紧要。黑箱测试可以
不考虑一项设计的实现方法，而只检测它是否实现了其功能

改进：在一些大型复杂设计中，黑箱测试可以作些非功能性的改进，
以便实现某种程度的可视性和可控性。
例: 可以用一些可软件读写的寄存器来控制或观察内部状态，或修改
所处理数据的长度，以尽可能减少测试时间。这些寄存器在正常运行
时并不起作用，它们只是在原始系统的组合阶段才用到。

黑箱测试方法的建立可以和设计同步进行，因为它是唯一可以事前
对设计本身一无所知的测试方法。

白箱测试 White-Box Verification

白箱测试就是对测试对象的内部结构完全可见和可控。
优点：可以很快对状态和输入结果进行组合，或独立测试某项功能。
它能在测试的过程中随便观测任何结果，并能立即发现运行中出现的
错误。
缺点：和测试对象本身联系太紧密，换一个测试对象就不行了，也不
能用于将来的重新设计。它要求对设计过程有详细的了解，才能知道
要预设什么样的条件，要观察什么样的结果。

白箱测试和黑箱测试具有很强的互补性。
白箱测试能保证设计特定功能的实现，例如计数器到达计数终值翻
转，以及数据正确的传输过程和顺序。

灰箱测试(grey-box Verification)

灰箱测试是在黑箱测试的独立性和白箱测试的依赖性之间取一个
折中。
因为前者不能完全测试设计的每一个部份，而后者太麻烦了。
灰箱测试可以通过最高级接口来控制和观测设计对象，这一点和
黑箱测试是相同的。同时也有针对设计特定功能的专门测试。
它对别的测试对象也可能适用，但这时候充其量也就只能当黑箱
测试用了

Digital Circuit Functional Verification(四)

形式测试及功能测试


形式测试(formal verification) 又分为两类：
等效测试(Equivalence  Checking) 和模型测试(Model Checking)。

等效测试 (Equivalence Checking )

Equivalence checking compares two models(使用LEC或Formality)

1. 比较两个netlist，以确保扫描链的插入，时间树的综合，以及人
为修改等，不会改变电路的功能

2. It can detect bugs in the synthesis software
• 验证网表是否正确实现了原来 RTL代码的功能。
• 等效测试可以用来检验合成工具的可靠性。在少数场合，等量测试
可以检验手写RTL代码是否实现了门级设计要求。
• 等效测试可以证明两种RTL编码在逻辑上等价。为了获得更好的合成效果，
对源代码作了一些小的修改，而又不影响其功能，就可以通过证明等价而避
免繁琐的模拟。

3. Equivalence checking found a bug in an arithmetic operator
可以用較少的時間來找出錯誤點


模型测试Model Checking (Assertion 如SVA)
模型测试技术是形式测试技术的最新发展成果，采用这种技
术可以检验一种设计的断言和特征。比方说，设计中的所有状态
机可以独立检测。还有一种功能更为强大的测试可以预测是否会
发生死锁。
另外一种可以进行形式测试的断言跟接口有关。首先用形式
描述语言来描述接口，然后用工具来检测它。例如，一个断言可
能会作如下定义，一旦产生了ALE信号，就会随之产生DTACK或
ABORT信号。

模型测试技术困难之处在于利用对设计要求所作的说明，来鉴别所要检测的
断言。
在所有的断言中，只有一个子集可以进行检测。现有技术不能检测高级断
言，因此也不能保证能正确实现其复杂功能。
一种理想的情况是，在特定的寄存器状态下，异步传输（ATM）信元以相关
顺序输出。但模型测试技术不能做到这一点。(SVA 可測Async-fifo)


功能测试 (Functional Verification )
功能测试的主要目地是确保设计能实现预期功能。功能测
试就是为了使设计符合其所要
•  除非设计要求以精确的语法诉诸于正规的语言，否则无法证明设计
是否符合要求。
•  描述设计要求的文件是由人用自然语言写成的，而各人正确表达自
己意思的能力又各不相同，人们可以对同一文件作出不同的解释。
•  功能测试能够显示设计是否符合要求，但无法完全证明这一点。
•  我们可以因为一点小小的不一致就说设计没有实现预期功能，反之
则不然：没有人能证明它完全一致。

為了應對以上的測試

我們需要建立测试平台(Testbench Generation )

•  测试平台生成程序：按照代码覆盖规律，或利用某些经过证明的
结果，对源代码进行分析。
•  生成测试平台，可以用来增加代码覆盖，或检验设计方案的某些
性质。

测试平台生成程序局限及用途
—Designer input is still required.
—The jury is still out on the usefulness at these tools.
测试对象通常都是RTL代码，没有重重会聚点。测试人员要判
断测试平台所给的激发信号是否有效，如果有效，则要知道预期的
输出结果，并把它和设计的输出比较
模型测试产生的测试平台不仅能用来描述某项特性可能不符
合要求，或者什么样的输入顺序可能引起错误。而且可以用来检
测到设计要求中没有考虑到的非正常状态，或者为解决问题提供
调试环境。

Digital Circuit Functional Verification(三)

 人的因素

• 同一个人负责RTL编码和测试，测试又需要对测试要求作出具体说明，那么其
所根据的往往是这个说明，而非测试要求本身。
• 可以通过测试来验证设计是否符合设计人员对测试要求所作的说明。
• 如果说明本身是错误的，则测试永远都无法达到其要求。

任何人为介入都会导致不稳定和不可重复

因此有了下面的弥补措施
• 自动化
• 简化
• 冗余

自动化 (Automation )

•  自动化可以消除人为错误，因为它完全排除了人为介入。
•  并不是所有的过程都可以实现自动化，尤其是那些没
有很好定义，仍然需要人的创造性的场合，比如硬件设计

简化(Poka-Yoka ) 

• 把整个过程分解为简单可靠的步骤，只有在需要取得期望结果的特定步
骤才引进人为介入。
• 这种技术在质量管理领域又叫poka-yaka。
• 其离完全的自动化也只有一步之遥，所以它也只适用于严格定义了标准
转换步骤的过程。

冗余(Redundancy) 

• 求每个传输对象都是一式两份，传输过程则由两个人分别独立完
成，或对两个完全独立的传输过程的每一个输出结果进行比较，来
验证其结果是否一致。
• 只有在高度可靠的情况下才使用，比如空运系统。
• 在某些方面如果对产品的重新设计和更新成本更大，也可以采用这
种方法，例如ASIC设计。

Digital Circuit Functional Verification(二)

测试的重要性

一. 测试占去总投入的70%以上
•   集成电路上可能集成数以百万计的门电路。
•   在可再用IP和片上集成系统（SoC）中，测试占去总投入的70%以上。
•  设计人员中要分出专门的人去进行测试，其中包括专职从事
测试的人员。测试人员通常是RTL设计人员的两倍。
•  设计方案完成以后，建立测试平台的代码占代码总量的80%。


二. 同步作业可以缩短测试时间 (?)
•  如果能同步作业，就可以有效的使用闲置的人力物力以缩短测试时间。
•  测试中采用同步作业的方法是建立测试平台和功能测试的过程与
设计的实现过程同时进行。(有其困難之處, Spec.必須在開始Design前已經完成)

三. 提高抽象可以缩短测试时间(?)

• 提高抽象程度，开发人员就可以不必顾及某些细节而提高效率。(?)
• 提高抽象程度通常就意味着减少控制，因此必须慎重采用。
• 较高的抽象程度也要求开发人员懂得一些抽象技术以及如何取得
理想的效果。(designer未必有時間及能力去了解這些技術)

四. 自动化技术能减少测试时间(Reuse Verification IP) 
•  自动化技术要求过程规范，预先明确定义输入和输出。(constraints)
•  并非所有的过程都能自动完成。
•  测试面临同样的问题。因为功能，接口，协议和转换格式的不
同，不可能从已有方法中找到一种普遍适用的自动测试技术。
•  测试过程部份实现自动化还是可能的，尤其在应用领域不是那么
宽广的情况下，更是如此。
•  对测试进行了一些标准定义，可能有助于在不久的将来实现自动化。

Computer Vision的一些不錯的網站

Ballard and Brown's Computer Vision的電子書

http://homepages.inf.ed.ac.uk/rbf/BOOKS/BANDB/bandb.htm

http://homepages.inf.ed.ac.uk/rbf/BOOKS/BANDB/toc.htm

另外一本

http://szeliski.org/Book/

http://szeliski.org/Book/drafts/SzeliskiBook_20100903_draft.pdf

Berkeley

http://www.eecs.berkeley.edu/Research/Projects/CS/vision/

http://www.cs.cmu.edu/~cil/vision.html

http://www.cs.ubc.ca/~lowe/vision.html

http://www.cvl.isy.liu.se/research