驗證計畫(二)

验证的层次

验证可以在多種层次上进行
在考虑验证计划时，首要的问题是确定验证任务的粒度层次。一个设计可能由多个层次组
成，
有些具有物理划分，例如，印制电路板、FPGA、ASIC。
还有一些具有逻辑划分，例如，综合后的单元，可重用的元件或子系统。


验证的每个层次都对一个特定的应用或目的是最适合的。与传统的设计过
程相比，在物理层次上的单元级验证结束和系统级验证开始的时候，带有可重用元件的设计的
特性发生了转变。可重用设计并没有减少验证的必要性，而是单元与系统之间的边界由物理边
界转变为逻辑边界。

在决定不同粒度的层次时要考虑到折中
较小的划分比较容易验证，因为它们提供了更大的可控性和可观测性，建立感兴趣的条件
和状态组合，也比较容易观察结果是否与期望的相同。在更大的划分下，只有它包含的小划分
的组合体才被验证，但以牺牲可控性和可观测性为代价。

在一个给定的粒度层次下进行验证需要稳定的接口

由于验证的实现需要耗费巨大的精力，所以任何待验证的划分都应该有稳定的接口和预期

的功能。如果接口不断变动，或者在功能上总是从一种划分变为另一种划分，那么测试平台也
需要不断改变而整个验证过程却没有什么进展。一旦确定了将要验证的特定划分，它们的接口
和总体功能也应该尽早确定，而且要尽可能不做改动。最理想的情况是，每个被验证的划分有

它自己的规范文档，或者至少在规范文档中有它专属的一部分。

驗證計畫(一)

design spec.通常包括两个在不同抽象级别上的文档。
● 第一个是结构级的规范，其中详细定义了器件的功能要求。
● 第二个是设计规范，它详细描述系统结构在模块级的具体实现。

当结构级规范文档完成后，就可以开始写验证计划书。当模块级的实现文档完成后，可以
用特定的测试用例来扩充完善验证计划书。

验证计划就是验证部分的规范文档。

验证计划为整个设计组提供了一个讨论平台，用于定义什么是首步成功。它是一种确保所
有基本功能都被适当地验证的机制。如果想看是否取得了首步成功，就应该确定在哪些条件下
哪些功能需要测试，还要看期望的结果是怎样的。验证计划中列出了哪些功能是首要的，哪些
是可选的。面对时间安排表的压力，在做丢弃某些功能的决定时需要格外留意。与此相反的做
法是保留所有可能的功能，那么当提交设计时就会将验证工作突然打断，而某些对市场来说相
当重要的功能可能就被错过了。

根据验证计划可以得到一个详细的时间表
验证计划为验证任务划出了一条线，从市场角度看，如果超出这条线就可能会威胁到项目
的成功。一旦计划制订完毕，就可以清楚地知道需要有多少个测试用例，还可以知道这些测试
用例的复杂程度及它们之间的相关程度。可以定义一个详细的验证时间表，将任务逐一分配，
尽可能让验证并行。一旦 RTL 设计通过了所有的测试用例，而且对覆盖度和出错率也满意的
话，就可以提交生產了，在这之前绝对不可以。

项目组要对验证计划负责
让与项目相关的每个人都认识到自己对验证计划负有责任，这是很重要的。RTL工程师的
职责并不只在 RTL 代码的设计，那只是实现最终目的的一种方式而已，他或她的责任是完成
一个能够工作的设计。整个项目组都应该对验证计划有所贡献，以保证它是完全并且正确的。

这个过程并不是创新性的
编写验证计划的过程并不新鲜。NASA、FAA和一些航空航天公司采用这个方法已经有几
十年的历史，目的是要确保他们想要实现的可靠性超高的系统满足最终的指标要求。这个过程
同时被用在软件设计和硬件设计中。

Digital Circuit Functional Verification(二十)

 验证工具總結

1. 尽管 Lint 和其他静态代码检查工具可能报告很多的伪错，但它们对于某些错误仍然是最
有效的检测工具。

2. 仿真器的好坏取决于被仿真的模型。同时仿真器还提供了许多提高仿真性能的选项，可以
支持联合仿真或者混合语言仿真。

3. 基于断言的验证对任何验证方法都是强大的工具，通过它可以很快地发现问题的位置和
发生时间。(SVA)

4. 硬件验证语言由于其对验证任务和覆盖率驱动的随机验证的支持，它对提高设计效率很有
帮助。(UVM, systemverilog, systemC...)

5. 由代码和功能覆盖数据可以对设计质量进行量化的评估。但要注意的是：不必付出所有
代价去达到 100% 的覆盖率，即使达到了预期的覆盖率目标也不能说明设计工作已经完成。
(spec. -> functional items -> function coverage -> code coverage)

6. 源码控制系统和问题追踪系统可以管理代码并报告错误。(Project manager 要試著與member 討論可行的作法)

ARM 的技術文檔中心

有很詳細的ＡＲＭ相關的技術文件
方便參考ARM的相關設計資料

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0243c/ch03s10s01.html

Digital Circuit Functional Verification(十九)

METRICS 指标

指标是最基本的管理工具
管理者都希望看到指标和报告，因为他们没有时间亲自跟踪项目的进展情况，而是根据一
些重要的指标来掌握当前的情况。


指标可以评估验证的效果
很多指标都可以用来评估功能验证的状态、进度和效率，code coverage就是其中之一。


code coverage并非适合所有情况
代码覆盖测试的是源代码被验证的程度，一般它会随着时间的流逝和设计的进展不断增
加，最终趋向 100%。

并不是所有的项目都适合用代码覆盖率来评估。代码覆盖率对于独立的小的设计单元是有效的
（例如，FPGA、ASIC 或可重复利用的元件），但却不适于由单独验证过的模块构成的大型设计项目。验证这些大型设计的目的是为了检查各个模块的接口是否正常工作，而不是验证每个模块的功能，因此没必要运行所有的语句。


测试用例的代码行数可以反映测试效率
执行验证过程所需的代码行数可以有效地反映执行该过程的代价，所以可以用它来比较新
的验证语言或方法的效率。如果新方法能减少需要编写的代码行数，那么它也可以降低验证过
程的花费。

代码行的比率可以反映设计的复杂性
被验证的设计的代码行数与测试用例的代码行数的比率可以反映设计的复杂程度，这个比
率还可用于预测某个新设计的复杂度和验证花费。


从版本控制系统可以了解到随时间变化的源代码修改程度。在项目的初期，随着新功能的
不断加入和版本的变化，代码会以很快的速度变化。在验证的初期阶段，修复错误也会导致代
码的变化。而随着验证过程的进行，错误越来越少，代码的变化也不断减少。

 与品质相关的指标
品质是主观判断的，但可以通过测试指标来间接反映
与品质相关的指标与功能验证的关系比其他指标与其的关系更加密切。虽然品质是主观
值，但它可以由与设计质量相关的指标来反映，这就好比零售服务的质量可以由顾客投诉次数
和重复投诉的数量来反映。


功能覆盖(function coverage)可以反映测试用例的完整性
功能覆盖测试的是设计中观测到的输入、输出和内部信号的组合。对这些数据赋予不同的
权重，可以得到一个功能覆盖指标，反映设计的功能被执行的程度。如果增加重要指标的权重，它还可以作为功能验证进展情况的一种度量。在项目的初始阶段，覆盖率以很快的速度朝着100% 的目标增长，随着项目的进行，由于存在一些难以达到的功能点，它的增长速度明显放慢。





最简单的指标就是已知问题的数目
最容易收集的数据就是未解决的问题的数量，在统计时可以把问题的重要程度作为权重。
在使用计算机化的问题追踪系统时，可以很容易地得到这个指标以及它的趋势和变化速率，由
此可以判断问题是在不断增加还是在减少并趋向于零？

 解释指标

用什么来评估已经完成的工作
管理者在很大程度上依靠指标来判断设计者的工作业绩（作为奖惩的依据），这导致所有
设计人员都十分关注指标，也是为什么要慎重选择那些可以客观反映当前情况和所付出的努力
的指标的原因。如果评估的是已发现和修改的错误数，你很快会看到这个数目在增加，但你会
看到代码的质量在提高吗？错误以前没有被报告吗？如果只要有效地发现并修改错误就能得到
管理者的肯定，这会不会导致设计者编写代码时过于马虎和草率呢？

Digital Circuit Functional Verification(十八)

ISSUE TRACKING  问题追踪

Issue Tracking 為何也要導入？ 只要是超過兩人以上的開發，必然會有溝通(其實，一個人也會有溝通的問題，與內心自己的溝通)，也必然會有問題的紀錄與回應。

簡單的說，版本控管是設計產中的一種共享；Issue Tracking 則是大量溝通的機制。

应该对错误进行修改
一旦发现了问题，就要解决它。所有的设计小组都有一些非正式的系统来追踪这些问题并
解决它们，但是这些非正式系统的性能和可扩展性还有待改进。

哪些是值得解决的问题
在讨论追踪问题的各种方法之前，首先要明确哪些问题是值得追踪的，这在很大程度上取
决于使用的追踪系统。追踪某个问题的代价不应该高过这个问题本身带来的价值。另外，是否
需要追踪系统判断问题的类别？或者是否应该先判断什么构成了一个值得追踪的问题，然后再
运行合适的追踪系统？后一个问题才是与最终目标紧密联系的：保证设计功能的正确性。

有待解决的问题是指任何能影响设计功能的因素：
1. 在测试平台运行过程中发现的错误显然是值得追踪的问题。
2. 规范文件中出现的模棱两可的情况或不完善的地方也是值得追踪的问题，但是拼写错
误不属于此类。
3. 结构上的考虑和折中也属于待解决的问题。
4. 在设计的各个阶段发现的错误，无论是设计本身还是验证环境都应该予以追踪。
5. 如果有新的相关测试方案，也应该归为值得考虑的问题。

要对所有值得追踪的问题列出清单是不可能的。当问题出现时，判断它是否值得追踪的惟
一标准就是它是否会影响最终设计的正确性。如果某个问题不解决就会导致失败的设计，那么
它就必须被追踪。当然，并非所有的问题都是平等的，其中一些会直接影响设计的功能，另外
一些只是有一些小的负面影响。所以应该对问题的优先级进行分类并依次解决。

一些不太重要的问题，可以不去解决。设计人员可以决定某些特定的问题或缺点在该项目
里是可以接受的，可以将其留至产品的下一个版本再改进和解决。这种判断最主要的难点是必
须保证放弃这些修改是有意义和有充分理由的。

最简单也是最普遍的问题追踪方法是讨论。在发现问题以后，你可以到硬件设计师工作室
中讨论这个问题（假设你不是硬件设计师）。其他感兴趣的设计者也可以加入到讨论中来，一
些简单的问题往往可以在这里解决。对于一些较大的问题，可能还需要更多设计者进一步讨
论，那么问题的解决实际上就取决于你是否会坚持与硬件设计者进行深入的讨论和交流。

讨论法只在小型的集中式设计组中才能有效地工作，设计人员必须非常接近。如果设计组
里有临时或兼职的工程师，或者设计人员在不同的地理位置工作，这个方法就会出问题，因为
即时的口头交流并不十分可靠。虽然问题达成了口头的解决方案，但没有人能保证会如期去
执行。

这个方法也不能为问题的解决过程保留历史记录。虽然某个问题解决了，但是没有办法将
解决问题的过程追溯记录下来。如果解决方案的实施严重推迟，还可能导致同样问题的反复出
现。如果提议的解决方案被证明是不恰当的，设计组可能会重头再来，不断重复以前的解决方
案。没有历史记录，就不得不频繁地重复以前的操作，设计组将无法从错误中吸取教训。对个
人来说，从失败中吸取教训的能力是有限的。

问题可以通过小组会议来追踪解决
对问题追踪的方法的进一步改进就是程序法。在这种方法里，问题通常由电子邮件信息
之类的自由格式文件正式报告出来，一些重点问题可以在小组会议时讨论和解决。

只有最大的问题才被追踪
由于在该方法中涉及到整个设计组的人员，并且会议的细节问题往往都被记录下来，所以
它对设计组的交流学习是很有帮助的。但这种方法也会占用小组会议的宝贵时间和精力，因此
通常只用于那些特别重要或有争议的问题。那些为数众多的细小问题一般就采用讨论法或张
贴法。

问题可以通过数据库来追踪解决
对问题追踪系统的再进一步改进就是基于计算机处理的方法。在这种方法里，首先对问
题进行深入的分析，未解决问题被重点、多次重复报告。解决问题的任务被正式地分配给某
个或某几个相关的设计者，计算机系统可以自动地将每天或每周的工作报告发送给相关的责
任人。
各种不同的解决方案和效果、问题的最终解决方法和过程都被记录下来，这样同样的问题
就不会再次发生，而且任何人都可以参照以前的方案来解决或避免发生类似问题。

即使有上述明显的优点，计算机化的方法仍不是很有成效，它最主要的缺点就是不方便使
用。讨论法和张贴法在任何情况下都能轻易地使用，设计工程师们面对着紧张的工作日程，如
果有以下几项可以选择，你会选哪一个相对简便的方法？
1. 直接面对负责解决问题的人并口头向他报告问题。
2. 在方便贴纸上描述该问题，然后交给上述责任人（如果他不在，则将该纸条贴到他的电
脑显示器上）。
3. 将关于该问题的描述输入数据库，然后在计算机上密切关注进展情况。


提交问题所用的时间应该比解决问题所用的时间短
当然你会选择一种最节约时间和精力的方法。如果希望设计小组有效地使用计算机化的
问题追踪方法，那么就应该选择一种对设计人员的正常工作影响程度最小的方式，最好是他们
的日常工作方式或已在使用的工具的简单扩展。

使用最广的是基于电子邮件的系统
最成功的计算机化问题追踪系统一般都采用电子邮件界面的方式，通常还带有网页界面来
管理任务和报告问题。因为每个设计者都会使用电子邮件，所以电子邮件界面成为了首选，它
可以使位于不同地理位置，不同时区的设计者方便地讨论同一个问题。只需要对这些电子邮件
信息进行分析、分类，随时跟踪问题的状态和解决方案（通常是对电子邮件正文或标题的特定
区域进行简单的设置），就可以有效地实现问题追踪系统。


以下參考 http://kenming.blog.ithome.com.tw/post/296/10052

在Survey 了一下 Open Source 的 Solution讓我比較感興趣的是這一套： 螳螂(Mantis)！
 官網  www.mantisbt.org
wiki  : http://en.wikipedia.org/wiki/Mantis_Bug_Tracker

它可以整合 dokuwik 與 subversion 。這挺重要的，尤其是 wiki 功能，使得 Issue Tracking 工具又同時可兼任 Portal，具有文件分享與基本留言討論的功能，讓溝通的機制更加地順暢。 蠻適合於中小專案的團隊，中的規模多大呢？ 4,50 人以內吧，我的直覺是使用這套工具是綽綽有餘，沒有什麼問題的。

幾個比較有意思的功能：

• 容易安裝(這可重要)。
• 多國語言支援，當然包括繁體中文介面。
• 全文檢索與報表功能。
• 版本控管(CVS and Subversiion) 與 wiki(dokuwiki) 的整合。
• 權限驗證的支援(Defatlt, HTTP, LDAP, Active Directory service)，不過，這塊可能要有相當的客製化技術能力才能整合得起來。
• 提供 WebService(SOAP) 的溝通介面。
  這可真不錯，網站上還提供了 Eclipse, .Notifier, Ant Task 等 plug-in，當然，你也可以自行寫 .NET or Java 的 plug-in 外掛，彈性很大。

 

Digital Circuit Functional Verification(十七)

版本控制REVISION  CONTROL

验证工作的一大难题就是要保证待验证和被验证的是同一个设计。当编译一个 Verilog 源
文件时，如何保证设计人员在综合时使用同一个文件呢？
当验证和综合由同一名设计人员完成时，只要他对文件进行了有效的管理，这个问题发生
的可能性就较小。但是，在实际工作中，在功能验证过程中由同一名设计者完成这两项工作是不可靠的。通常是由不同的设计者分别进行验证和综合。

文件必须集中管理

在小型设计队伍中，有可能所有设计者都在同一个目录下工作，也有可能将设计文件分布
在少数几个独立的目录下，每个人管理自己的目录同时了解其他人的文件位置。这种情况很普
遍也很危险   ：你很难了解其他设计者是否修改了源文件？是否在你刚刚验证完后又产生了其
他的功能性错误？

在同一位置获取文件是很方便的

这种方法不具备可扩展性，一旦设计组增加到两三个人以上就难以实现了。而当设计人员
的工作环境不在同一地理位置时，这种方法就完全不适用了。验证工程师是这个问题的主要面
对者。一个被恰当划分的设计一般不需要涉及到其他人目录下的资源，设计者只需要独立地工
作在自己的目录下，而验证工程师的首要工作就是将这些零散的设计组合成一个整体。显而易
见，把分散在多个文件服务器上的不同工作环境下的零散文件组合起来是很困难的工作。
這個地方的寫法有個模糊點，通常integrator 會將design整合成一個Chip/platform的架構，然後驗證的人才會開始進入來驗證。

HDL 模型的管理实际上是软件管理的课题

软件工程师们用源码控制系统来管理文件，其中一些是免费的软件，工作于UNIX操作系
统下（RCS、CVS、SCCS），或由 GNU 项目发布（RCS、CVS），可以从以下网址找到相关的源代码：ftp://prep.ai.mit.edu/pub/gnu。也有相应的商用系统，但往往都非常复杂。

現在比較流行的tools為Subversion，簡稱SVN，是一個開放原始碼的版本控制系統，相對於的RCS、CVS，採用了分支管理系統，它的設計目標就是取代CVS。
而且有很多的圖形介面的配套軟體可以支援，方便使用者來使用

可參考維基百科http://zh.wikipedia.org/wiki/Subversion

发行版本的管理

当文件的新版本被输入到源码管理系统的数据库并改变了标记符时，以前的视图就过
期了。

发行版本是一种特定的配置
设计中某部分 RTL 代码的设计者一般总是使用该文件的最新版本，并不断地修改和更新
它们（通常是在代码开发过程中的某些关键点和每个工作日结束时）。一旦源码通过了语法正
确性测试并且功能达到了设计要求（通过一些特定的测试平台），那么该文件的相应版本就被
标记为“等待验证”。

用户必须将文件更新至合适的发行版本
作为一名验证工程师，你必须不断地观察并及时更新文件的版本。有可能花费好几天时间
来编写一个特别复杂的测试平台，以至于没有及时将待验证的设计文件更新到最新版本。这
样，可以对待测试的设计保持有连续的思路，并不断修改测试平台。但只要真正的验证和调试
工作一开始，在运行这个测试平台之前必须将文件更新至最新的“等待验证”发行版本。

随时更新
当多个设计者同时使用同一个文件进行设计时，应该经常检查文件并不断更新，以合并对
文件的并发修改。如果停滞时间过长，很可能会需要人工干预来解决更新冲突。这种对文件并
行修改后立即合并更新文件的方法看似冒险，但实际经验表明，不同的函数或错误修正极少位
于源代码的同一行内。只要这类修改被两三行未修改的代码分割开来，合并操作就没有任何问
题。并行开发是一种发展方向。

可以通知设计者新版本发布
一些源码管理系统的一个重要特性就是可以通过发电子邮件的方式告知设计者何时发生了
重要的事件。例如，当“等待验证”的标记符发生变化时，系统就给所有的验证工程师发电子
邮件，在电子邮件中还可以有选择地包含一些对于源文件变化描述的信息。由此用户就可以判
断是否要立即更新当前的文件版本。

Digital Circuit Functional Verification(十六)

 测试语言( VERIFICATlON  LANGUAGES)

•  Verification languages can raise the level of abstraction.

驗證語言的重要功能需求

1. Multiple runs, Multiple seeds

2. Random Generation

3. Functional Coverage

4. Minimal code modifications

5. Identify holes

6. Constraints

•  VHDL and Verilog are simulation languages, not verification
languages.
Verilog偏重的是初级应件结构，所以它不能支持高级数据结
构，也不具备面向对象的特征。VHDL比较适合于大型项目，它
封装了所有的信息，并严格按定义好的接口传送。有必要创造一
能克服Verilog和VHDL的这些缺点的专门的测试语言 。

•  Proprietary verification languages exist.
三种企业专用的测试语言：Verisity的elSpecman, Synopsys
的VERA,Chronology的Rave。(2005)

另外有以C為基礎所開發的systemC，亦是另一種驗證語言

為了因應驗證的需求，verilog加入了一些C語言的精神，

延生出systemverilog，為了充分利用systemverilog來驗證IC design，

又開發出了驗證方法從VMM/OVM而到了統一的UVM(2011)

systemverilog也提供 DPI的介面，可以方便的連結其它的語言來做
聯合驗證(co-sim)