排名前十的验证忠告

排名前十的验证忠告

1.这是遗留下的代码，所以不用验证
-小心！你能 100%保证你面对的是经过硅验证的代码吗？你能保证没有在上次工作之后
没有任何人碰过这代码吗？

2.我可以在 5 分钟内就把补丁加上
-只要你能保证你的验证环境不像是一大堆补丁堆在一起形成的，这样做到也可以。但
是想一下从今天起用一周时间来修改和修正你的验证环境是一件容易的事吗？难道多用几
分钟时间来写一个更健壮的代码不是更好吗？

3.随心所欲地计划和开始测试
-这是大大地错了！即使你的工作是小菜一碟你也要提前做好计划。你会惊讶地发现可
以避免多少无谓的问题。铭记 5 个 P:合适的计划排除差的性能。(proper planning prevents
poor performance)

4.这工作很简单，不必作测试计划
-将测试计划当作你的工作合同。你加入其中的定义了你当前所要做的工作，如果工作
真的很简单，就用半页纸把测试计划写下来。

5.验证不是产品，所以不必遵循软件标准
-验证的确不是产品，但是你仍需处理数千行的代骊，所以你最好可以确保一定程度的
一致性，更不用说可能存在代码错误的可能了。

6.别花时间在写注释上
-还记得最近一次你花费半天时间在反向研究别人的代码上吗？那么对于你自己写的代
码呢？更好的做法是，在开始每个测试前，保证代码中有足够的注释解释程序步骤，并要保
证注释的更新。

7.我知道了！让我们从外部强制这个信号的值就 OK 了
-强制的信号值往往会在整个流程中被遗忘，并在最后阶段才被发现，这时通常只有一周就
tapout 了！所以要极端的小心。

8.必须在后台一直运行回归运行(regression running)
-单纯的回归运行不能完成所有工作。你必须有一个分析人员(Regression Sitter)来监
视和分析运行结果-否则就是在白白磨损服务器！

9.我们己经实现了 100%的覆盖率真，所以没有必要再运行更多的测试了！
-实际上并不是这样。你的覆盖率模型只能捕捉到你提前想到的东西。很明显随机测试
平台可以产生能揭示出 bug 的额外情景。所以不要在 100%时停止。相反，要在这时加强覆
盖率模型。

10.验证应该寻找 bugs-这是一个很普遍的对验证工作的误解。验证者应该将注意力放在建立一个构建得很好的，强健和完整的测试平台上。bugs 将会自己被检测出来。

驗證計畫(十)

 测试例設計上的分组

把有相似验证需求的功能分为一组
功能分组是很自然的。一些功能需要相似的配置、粒度或验证策略来进行验证。为了最大
化生产效率，这些功能应该被分到同一组，并分配给同一位验证工程师。例如，所有和CPU接
口有关的功能应该被分到一起。不論是直接或隨機的測試力設計皆需要依照測試的功能來分組，

分組的方式如下


1. 功能清单中的交叉引用
每个测试用例应该有一个标签和对目标的一小段描述。描述应该包括测试用例中已验证功
能的清单。功能的清单应该链接到验证这个功能的测试用例。如果一个功能没有指向一个测试
用例的交叉引用，那么这个功能就没有验证。

2. 定义从属关系
对测试用例的描述应该包括被认为可操作并功能正确的功能的清单。依靠它们的从属关
系，可以决定测试用例编写的顺序，并确认在测试平台开发中是否有并行的机会。

3. 指定测试用例的激励
必须描述测试用例激励的顺序和特性。例如，要描述必须进行的各种操作或总线周期。用
随机数据或随机事务来填充所有不相关数据或背景数据是个好方法。

4. 指定可接受的准则
除了期望的响应，测试规范还必须说明如何判定响应是正确的。这包括期望的值、时序和
协议。例如，路由包处理器的输出的目标地址如果和它显示的输出端口是匹配的，那就可以判
定是正确的。或者可以用一些更严格的判定方法，例如，不同来源的包以一定的顺序排列并以
一定分布交织排列。

5. 指定要查找的错误
一种更直接的描述可接受准则的方法是描述要查找什么样的错误。例如，确认一个包有正
确的 CRC 校验值。另一个例子是描述不能同时发生的事件，如FIFO 中 full 标志和 empty 标志
的置位。直接描述要查找的错误可以让一个不太熟悉设计的验证工程师实现高度可靠的测试
平台。


6. 注入错误以确定它们被检测到
永远不要相信一个不生成错误信息的测试平台。每个测试用例应该包括一些错误注入机制
来确保测试平台可以发现并且报告错误。缺乏错误信息可能会成为测试用例的一个失败条件。
比如，一个用于验证串口奇偶位生成的测试用例应该能故意错误地配置奇偶位，以确保测试平
台能够检测到一个错误的奇偶位。当然，测试平台不能一发现错误信息就退出仿真。

7. 为每個分组的测试用例分配一名工程师
不管测试用例是如何分组到测试平台的，每一分组测试用例应该分配给一名验证工程师。同
一组测试用例有相似的实现需求。它们可以在同组中前一个测试用例的实现基础上完成。第一
个测试平台要花费最长的时间来完成。但是随着负责每组测试用例的工程师的经验增长和对基
础结构验证的调试，很多工作可以被重复使用。在接下来的测试平台中，只要剪切复制就可以
完成工作。每个测试平台被分配的人员名字应该被记录在验证计划中。那个人根据验证计划的
规范文档负责完成测试平台。

驗證計畫(八)

可验证的设计

1. 确认那些难以验证的功能
在验证计划的这一步，我们要确认那些难以验证的功能。它们之所以难以验证，是因为所
选择的设计划分缺乏对这些功能的可控制能力或可观察能力。將特別難以驗證的部份IP化，

在整合前就將內部細節完整的驗證過，是解決此類問題的良好方法歐。

2. 修改设计来帮助验证
将验证计划提前的好处是你仍有机会修改设计的实现。如果一些功能被证明在目前设计的
结构和功能集里是难以验证的，就可以修改设计，增加一些附加的功能来辅助验证。硬件工程
师无疑会抱怨这些实际并不需要增加的功能，但他们还能有什么选择呢？这些功能在系统集成
的实验里被证明总是有用的。這是大部分Designer最討厭作的事，因為普通designer都會直覺得認為自己設計的已經是最佳化的，無法再去改變了。其實最大的原因是懶的改了。
針對驗證所修改的設計才是真正可以當作ＩＰ來reuse 。因此所需花的心力就會成倍數增加，

最好是在ＲＴＬ 中嵌入block 的assertion，以確保內部自我測試的完整性。

3. 提供状态预加载功能
如果设计中包含很长的计数器或复位后成百上千个周期后才能达到的状态条件，那么就要
确保它们可以通过内存映射的寄存器预先加载任意值。理想情况下，可以通过相同的寄存器组
回读它们的值。提供可轉入特殊模式或狀態的觸發方法，此法可以針對可能的狀態作直接的測試。如Green/test/sleep mode 的直接進入方法。此法最好不要用force的方式來介入。


4. 提供数据通道旁通的路径
如果没有对所有操作数详细控制，那么很长的数据通道的正确实现也会难以验证。例如，
语音合成器是一个简单的数字信号处理设计，它有对随机噪声整形的数据通道  。虽然可以
控制完整的系数并应用到数据样本上以形成特定的声音，但无法控制一个关键元素：最先的
输入数据。那是一个随机数。为了正确验证这个数据通道的操作，需要控制它的初始输入值。

此法有點類似法3，但是此法是為了加快或直接測試一個大型運算系統的中後部的單元。在直接使用旁通的方法來注入測試值到某一系統單元，可以節省不少測試的時間。此時最好有完整的比對模型可以針對此類驗證提供良好的比對數值。

5. 提供采样点
如果可观察能力而不是可控制能力是个难点，可以通过内存映射的寄存器加入一些可读出
的采样点，这样可以方便一些功能的验证。如果分配给设计的地址空间很宝贵，这些采样点可
以用多路选择器共享同一地址空间，用第二个地址来选择当前的采样点。

針對某一資料區塊，可以在測試中提供不同的讀取方法，以利作比對之用。

6. 提供错误注入机制
如果设计包含错误和异常检测机制，你可能想提供一种方法强制发生错误检测或异常检
测。例如，在验证中断屏蔽能力时，如果要强制设计进入每一个异常条件，那么验证是十分费
时的。如果一个简单的寄存器写操作可以手工地触发相同的中断，那么验证起来就容易多了。

基本上注入的數值我們是採用隨機方式，但如果我們已大約知道某一數值範圍是較容易出錯的地方，可將隨機比重加強於較易出錯之處。又如果設計中有加入容錯機制，我們可以將注入的數值再加上一個隨機的高斯雜訊值，來測試設計的強健性。

当然，异常条件对中断的触发仍然需要验证。要仔细地考虑把错误注入包含进设计的决定。如果这仅仅是为了硬件的验证，那么可能不会出现在给软件工程师的说明书里。当一个器件的驱动程序写入一个它认为无害的值时，这个功能可能会被偶然地打开。

此文中的藍色部分的，是本人工作上所遇到的情況與想法。若是有誤請勿見怪

驗證計畫(七)

给功能驗證分配优先级

1. 一些功能对于设计功能的正确性或满足市场要求来说是“必须拥有”的，完成这些功能的验证开启了成功完成整个项目的大门，而验证这些功能的测试平台是最关键的部分。“必须拥有”的功能需要对所有可能的配置和使用选项进行彻底的验证。

2. “应该拥有”的功能对于商业上成功的设计来说是第二位的。它们也许只是简单地提供功
能上的扩展或与其他竞争产品的差别。它们的主要验证目标是验证基本功能的正确操作，在时
间和资源允许的条件下对这些功能进行更详细的验证。如果时间进度压力很大，迫使资源都被
分配去验证更为重要的功能，那么这些功能的验证会被取消。

3. “最好拥有”的功能是可选的。只有在时间允许的条件下，才会用最简单的方式验证它们。
按照现实的设计进度表，这些功能永远不会被验证！

如果迫于进度压力需要取消计划中的一些验证项目，那么对待验证的功能划分优先级可以
使项目经理做出明智的决定。削减验证任务可以先从不重要的功能开始。如果项目完成的日期
对进度提出了更高的要求，使我们要放弃一些“必须拥有”功能的验证，那要保持清醒的头脑
来做这些决定，因为这些功能定义的优先级和最初的市场目标一样重要。削减对“必须拥有”
的功能的验证需要小心认真地对项目的市场目标进行重新评估。

驗證計畫(六)

从设计规范到功能驗證

编写验证计划的第一步是确定要被验证的功能。从规范文档中可以列举出它所描述而且
要被验证的所有功能。其他的项目组成员，尤其是系统结构和RTL设计师，进一步补充待验证
的功能，对不熟悉设计目的和特点的人，这些新增的功能在设计规范中可能不是非常明显。在
选择了某个特定的实现后，其他的某些功能可能会变得重要起来。

在“The Art of Verification”一书中，提出了一种系统的方法来提取有意义和相关的功能，首先观察1. 接口(interface)，然后是2. 功能，最后是由3. 选定结构确定的边界情况(boundary)。

1. 列举基于接口的功能
对于待验证设计的每个接口，列举出必须验证的每个功能。基于接口的功能可以由以下问
题获得：
● 必须采用哪些事务激励？(input value)
● 值的范围是多少？ (contraints)
● 事务的次序是怎样的？ (sequence order)
● 相关的事务比例是多少？ (weight)
● 设计应该能承受什么样的协议违返？ (assertion)
● 这个接口与其他接口之间，或与内部设计结构之间有什么相关的相互影响？(assertion)
● 一个接口的事务是否需要与其他接口同步？(async )


2. 确定基于用途的功能
根据设计中的主要数据通路 (spec. define)，列举出每个必须验证的变换和选择。基于用途的功能可以由以下问题获得：
● 所有有关的配置是什么？
● 可能发生的数据变换有哪些？
● 变换的顺序是什么？
● 触发变换的敏感数据值是什么？(event /irq)
● 影响每个变换的敏感值是什么？
● 变换后的数据在哪里终止？
● 数据顺序是怎样被影响的？
● 存在着什么错误检测机制，它们是怎样触发的？
● 错误机制怎样报告错误？
● 对错误的数据会发生什么？(anti-error value)

3. 列出基于结构的功能
在对设计的结构有了详细了解的基础上，给设计增加压力，将其推向极限的条件。
基于结构的功能可以由以下问题获得：
● 可以使一个缓冲器发生溢出或下溢吗？如果可以，会发生什么现象？(overflow )
● 哪里是资源的瓶颈？(bottleneck)
● 对这些资源的多个请求可能同时发生吗？(multi-request)
● 一个变换的路径是否会影响、阻止或阻塞其他的变换？


在驗證items标注各个功能
应该对每个功能进行标注，并加上简短的描述，描述部分要包括需要验证的条件和期望的
结果，而不是它是如何实现的。每个功能都应该与规范文档中详细描述它的那个部分或段落相

对应，规范文档最好也能与验证计划中的功能列表相对应。为每个功能确定适当的验证级别，
当出现问题时，功能标签应该以错误信息形式给出，把功能标签包含到错误信息中将有助于确
定哪部分可能出错和最终评定是否真正出错。(assertion items description)

为功能确定适当的验证级别
在列举功能时，要注意将它们包含在验证计划的适当验证级别中。有些功能适合在元件
（单元、可重用或ASIC）级验证，而有些必须在系统级验证。多数情况下，验证设计中的一个关键功能或模块总是与大量功能相关。如果实现那个功能或包含那个模块的单元没有被单独验\证，就需要重新考虑你的验证方法了，这可能暗示着为达到必要的可信度这个单元需要被单独验证。

驗證計畫(五)

系统级验证

验证的重点是交互
单独的元件在由个人或组来规划和设计的过程中，都要假设它们将与其他元件相互影响。
这些由不同人给出的假设是错误的主要来源之一。系统级的验证因而着重考虑各个元件之间的
交互，而不是每个元件的功能实现问题，后者在元件级验证中会得到更好的验证。系统验证工
程师假设每个元件在功能上都是正确的。

因此各個單獨components/IPs的驗證要先完成，才有可能作系统级验证。

由于系统是逻辑划分的，它可以由任意个数的元件组成，而不必在意它们的物理位置。使
用和验证哪个系统取决于当前感兴趣和有意义的测试用例。为了减少前面的仿真过程，最好采
用可能的最小系统来执行指定的测试用例。然而，系统的数量有可能非常巨大，这时候需要定
义一组“标准”系统。在多个测试用例中可以采用相同的系统，即使这个系统包含了在某些情
况下并不需要的元件。(這是指Platfrom IP的觀念)

在系統級的驗證中包含了 FPGA及ASIC 設計的整合驗證

FPGA驗證中也一併需考慮到量產時的系統版的問題考量，

而ASIC驗證中則需考慮到除Normal狀態下的可能Power問題

驗證計畫(四)

可重用元件的验证Reusable Components Verification

只要可以不被修改地用于不同的设计中，就可以被稱作Reusable元件，
元件可以是RTL, Verification Unit, Firmware Codes, Layout Block ...

可重用元件被用在许多设计中，当对它们进行修改、问题修复或者增强扩展时，必须确保
它们向后兼容。这可以由一个回归套件完成，回归套件用于验证元件在修改后的兼容性。除非
修改不是功能上的，否则无法采用常规的验证方法来比较修改前后是否相同。由于加入了新功
能或者修复了问题，新版本的设计与先前的设计不再等同。
也就是說，如果沒有向後相容的機制，就不會是可Reusable Component.

如果潜在的用户对一个元件的性能和可靠性的信任程度低于他们自己能够设计的元件，那
么这个元件是不可能被重用的。只有通过详尽、记录完好的验证过程，对元件正确性和健壮性
的展示才可能提升用户对产品的信任度。如此才可真正稱作為Reusable IP

驗證計畫(三)

单元级验证 Unit-Level  Verification

设计单元是逻辑上的划分。它们被用于帮助实现或综合过程，它们可小（例如FIFO 或状
态机）可大（PCI从接口或 DSP 数据路径）。由于实现的细化能够突出初始设计中的各个缺陷，设计单元的接口和功能也会随时间而改变。通常没有独立的规范文档来对每一个设计单元进行核实。

由于这些设计单元通常总是处于持续的变化状态，它们最好采取一种自组织的验证过程。
设计者自己验证该单元的基本操作，这种验证的目的是为了保证RTL级代码中没有语法错误，
它的基本功能也是有效的。并不需要创建一个可回归的测试套件和达到高的代码覆盖率。

在任何项目中设计单元的数目都是巨大的，因而在该层次上实现验证将会非常浪费时间，前面的验证资源将会花超长的时间用于对无数常常变化的接口创建激励发生器和响应监视器，编写众多简单测试平台的工作量并不比编写几个复杂测试平台的工作量小。而且ASIC 或 FPGA 级的验证仍然需要验证这些设计单元的合成。

在当今大规模和复杂的 ASIC 和 FPGA 中，很可能无法在 ASIC 或 FPGA 划分的验证中获
得必要的功能覆盖，而且不是所有的单元都是等同创建的。对于敏感性和功能复杂度高的单元
来说，进行单元级验证从而获得足够的可控性和可观测性，以达到所要求的可信度可能会更有
效。最理想的是每个在单元级被验证的功能单元都有它自己的规范文档。

如果设计特别复杂，需要进行一些单元级验证，那么在设计时就应该尽可能考虑到单元级
验证的相关性和完整性。要将设计合理划分，使待验证的功能被完整地包含在单元内，而且可
以在单个基础上进行验证。验证完成后，可以假设这些功能能够工作在更高层次的验证任务
中。如果单元层次的待验证功能需要与其他单元相交互，那么需要在完全包含这些功能的更高
层次中进一步验证，以确保在合并后仍能正确实现。

 

驗證計畫(一)

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(十七)

版本控制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(十一)

第三方模型 (THIRD-PARTY MODELS)

—Board-level designs should also be simulated.
板级的设计通常都包括从第三方买来的部件，有时
这些部件是可编程的，如存储器，PLD，和FPGA。必
须对设计进行测试，以保证ASIC之间，和第三方部件之
间能够兼容。
—You can buy models for standard parts
—It is cheaper to buy models than write them yourself
—Your model is not as reliable as the one you buy.


1 硬件模块 (Hardware Modelers)
—What if you cannot find a model to buy?
You may be faced with procuring a model for a device that is
so new or so complex, that no provider has had time to develop
a reliable model for it.
—You can "plug" a chip into a simulator.
A hardware modeler is a small box that connects to your
network. A real physical chip that needs to be simulated is
plugged in it.

Hardware modelers  are  also  very  useful  when  simulating  a  model
of  the  part  at  the  required  level  of  abstraction.  A  full-functional
model  of  a  modern  processor  that  can  fetch,  decode  and  execute
instructions  could  not  realistically  execute  more  than   1000  to  5000
instructions  within  an  acceptable  time  period.  The  real  physical
device  can  perform  the  same  task  in  a  few  milliseconds.  Using  a
hardware  modeler  can  greatly  speed  up  board-  and  system-level
simulation.

IP核互连策略的歷史

參考網頁http://www.dzsc.com/data/html/2007-4-30/34764.html

我之所以稱它為歷史，是因為目前基本上都被ARM的AMBA所吃掉
其它規格所佔的百分比太小，以至於基本的IP都會支援ARM BUS

PCI BUS主要在PC系統

ARM BUS主宰Mobile系統

文中轉貼

主要的IP核互连规范

目前有较大影响的IP核互连规范有IBM的CoreConnect　总线、ARM的AMBA(Advanced MicroController Bus Architecture)、Silicore Corp的Wishbone、开放核心协议国际联合（OCP-IP）的OCP (Open Core Protocol)与虚拟插座接口连盟VSIA　(Virtual Socket Interface Alliance)的VCI（Virtual Component Interface）、Altera的Avalon　总线，　以及PlamchIP的CoreFrame 、MIPS的EC(tm) Interface，　Altera的Atlantic(tm) Interface、IDT的IPBus(tm) (IDT Peripheral Bus)　、Sonics的SiliconBackplane(tm) uNetwork等等，新的互连方案如基于PCI的方案也在积极发展中



另可參考http://tw.myblog.yahoo.com/renaissance-flyingsquirrel/article?mid=33&prev=34&next=29&page=1

IP再用方法手冊Reuse Methodology Manual (RMM)是個不錯的參考文件
 

Digital Circuit Functional Verification(九)

检错工具 ( LlNTING TOOLS )

•  检错（lint）一词源于一个专门用来检测C语言程序错误的UNIX设
备。当Dennis Ritchie最开始发明C语言的时候，它并不象现在的
ANSI-C和C++这么安全可靠，也比不上Pascal和ADA。检错程序
允许编程者尽可能快的发现常规错误，而不是在测试的过程中发
现了致命错误以后才知道。

—Linting tools find common programmer mistakes.
• 检错程序能够找到错误，使编程者能在执行程序或发生重大错误
之前改正它们。运行时检错将需要一个运行时的调试程序，并且
要花好几分钟，而检错程序则只需要几秒钟，后者效率更高。

检错程序的优点：
不需要激发，也不要说明期望的输出结果。它们的检错完全是静
态进行的，本身就自带了期望的输出结果。

在IC設計上， 我們一般使用Linting tools 來找出設計上對映到合成器上的錯誤，
就是在未使用合成器時，就可以很簡單的找出設計上的不可合成點。
以減少後面作合成後再回來修正設計的時間。

检错程序的局限性
•    检错程序并不能找出源代码中的所有错误，它只是通过分析源代
码的结构来判断何处出错，而算法错误和数据流错误则发现不
了。
•    检错程序在检错时有时表现得很固执。为了避免犯II型错误—即肯
定为错，常常犯检查出并不存在的错误，结果导致I型错误—否定
为错。

解决方法
•  细心过滤错误信息 ：分析输出结果，把那些事实上不存在的错
误排除掉，就不必为查找根本没有的错误而浪费时间。更重要
的是，它可以避免一个真正的错误随着众多的假错误被忽略。
•  正确的命名习惯有助于判断一个警告是否值得注意
•  对于检查潜在的真实错误来说，逐行检查仍具有不可替代的作
用。
•  编写源代码时就应该检错。判断一个错误的真假的最好时间是
在刚写完代码的时候。
•  保证代码的可读性和可维护性
此處包含了coding Style的必要性與實用性。在許多的小型設計公司，
扔會忽略了此處的重要性，以至於發生了許多奇怪的錯誤現象。 

代码检查 (Code Reviews)  • 代码检查是由人工完成的
• 作用：在测试和模拟之前找出功能错误和编码格式错误。
• 为了找出自动检错工具发现不了的错误，源代码将由多人过目。
• 可通过代码检查来评估一个源文件的可维护性以及其代码的正确
性，还能发现编码格式方面的问题。
• 能完全读懂代码，很容易找到功能错误及疏忽遗漏之处。
此處由Designer互相檢查，或由manager來實行

一個clock switch glitch free的參考圖

Glitch protection for unrelated clock source

雖然是針對Glitch protection for unrelated clock sources
但也是可以用在related clock sources，只是設計稍大一點(多兩個latch)

DFT再了解(二十)

Architecture of Reset_manage Module

1. The function of Reset Manage Module is mainly used to integrate all of hardware
set/reset signals、software set/reset and test reset .

2, The signal multiplexer delivers the function set/reset out and the test reset out
mutually.

3, When the scan Atpg mode is enabled , the signal multiplexer delivers the test reset
signal out.

DFT再了解(十九)

Architecture of Clock_manager Module























1. The function of Clock Manage Module is mainly used to integrate all of internal
function clocks、external function clocks and test clocks .

2.The signal multiplexer delivers the function clock out and the test clock out mutually.

3. When the scan Atpg mode is enabled , the signal multiplexer delivers the test clock
signal out.

乘加器

Subtraction by e becomes addition with its one’s complement plus 1.
Subtraction by f becomes addition with its one’s complement plus 1.
~e and ~f take priority to be summed since they should arrive earlier than the MULT_P outputs.
Two’s complement inversion of e and f generates two ‘1’s. Adding these two ‘1’s costs zero area
since the addition is accomplished by connecting two Cin inputs to Logic1.
Unused Cin inputs are connected to Logic0.