首页 > 代码库 > Verification Mind Games---how to think like a verifier像验证工程师一样思考
Verification Mind Games---how to think like a verifier像验证工程师一样思考
1. 有效的验证需要验证工程师使用不同于设计者的思维方式思考问题。具体来说，验证更加关心在严格遵循协议的基础上发现设计里面的bug，搜索corner cases，对设计的不一致要保持零容忍的态度。
mindset：一套人们应该持有的确定的态度，有时候又被描述为心里惯性，群体思维，范式，在分析和决策过程中很难抵消mindset的影响。
举一个简单的例子，当你看到任何verification engineer的职位，你会发现这是一个关于语言，方法学，工具以及某种领域的知识集合。
很多有经验的工程师可以学习阅读一个规范，建立验证规范，以及编写充分的代码去实现，但是却在某个关键的点达不到验证的目的。
本文将试图使用能够出现在验证环境中的一系列关键的选择揭示验证心态：
1. Is it the verification environment’s duty to accurately replicate the real world？
验证环境是否有责任复制真实的环境？
2.Is it acceptable for the testbench and/or testcases to make use of design signals?
是否允许TB或者testcase使用设计的信号
3. Is it worthwhile to target corner cases that designers consider invalid?
考虑设计者认为无效的corner cases是否值得
合格的验证mindset跟设计mindset有很大的不同，需要多年的经验，指点，以及在困难中摸索的经历才能培养出来。
这贯穿在：每一个决定，每一行代码，每一次会议，每一个项目。对设计为中心的验证方法说不！！！
当前，验证思维，依旧是一个被低估和弱势的产业。在本文中,我们将分析为什么这个验证有效性的话题如此关键。我们也将讨论影响一个TB debuggability的决策。在这个文章里面，我们将介绍一个验证工程师应该做的，而不是他们应该如何做。
1. INTEROPERATING VERSUS STRESSING（互操作对抗强调）
验证里面最重要的挑战就是划出设计强调的重点，并与设计进行互操作。只有怀有正确的mindset，才可以正确的划分验证重点， 这些里面比较常见的有：
1. clock and data recovery (CDR) 时钟和数据恢复
2. 错误情况下的握手
3. 状态指标，例如fifo的空满
A. 时钟数据恢复
1. 一些协议规定，数据在发送和接收的时候没有附带的时钟信号。在这种情况下，设计需要实现这个协议需要实现一个时钟数据恢复功能，以便在传输过来的数据里面提取时钟。针对这个设计，开发VC验证组件，也有一个相似的需求，没有时钟信号发送和接收，只有数据。
如图所示，当实现VC的监控,验证工程师必须决定以哪种方法收到来自DUT的数据。是否应该在monitor实现一个CDR算法，而这个算法已经在设计中实现过。当然不是这样，更好的解决办法是实现一个路差分(锁相环)算法基于相同的参考时钟DUT使用作为参考,并利用锁相环的输出样本输入数据。
This approach accomplishes the following:
1. It verifies that the DUT’s data stream is in sync with the reference clock
2. It avoids any possibility of the testbench masking a problem because the CDR algorithm is too tolerant
3. It has better simulation performance than doing costly checks on data rates
4. It is faster and simpler to implement than CDR
我们来看看验证视角和设计视角有什么不同：
当构建一个RTL CDR组件,设计师努力用最健壮的方式构建算法,能够与广泛的外部设备交互。而验证工程师反而试图尽量创建不够强健的算法。so it stresses the design and fails on the slightest deviation from the protocol specification.
因此，验证的目标不是为了复制现实，而是尽可能全面的验证设计，虽然可能这有可能不是很现实。
B. Handshaking Error Handling
大部分的协议要求使用一组反馈信息 ACK/NACK报文来指示在最近接受的传输中是否有错误产生。
1. 如果按照设计的思维，VC的实现应该遵循协议规范，也就是说自动发送ACK，当接受到一笔没有错误的传输，自动发送NACK当接收到一笔错误的传输。
2. 上面的似乎忽视一种情况，正常情况下DUT永远不会产生错误的传输。那么TB也就会永远不会返回NACK。
3. 而验证组件需要负责产生这么一个错误，the testcase writer must be able to manually control the VC to send a NACK in response.
4. 还有另外一种情况，就是握手异常的情况，就是握手信号没有返回给design。这要求VC需要support 错误插入的功能。
5. 验证VC如果实现完整的协议会导致验证失败以及浪费精力。
C. Status Indicators and Clocks （这是大家都知道的典型，这里省略）
OUTSIDE-THE-BOX VERIFICATION PLANNING
A. Corner case identification：
1. Function Input Parameters
a. whether or not something is valid or invalid is in fact irrelevant; what is important is, can such a scenario ever happen, and if the answer it “yes”, then it must be simulated to ensure that the design recovers from it.
b. It was the responsibility of the verification engineer to take a higher-level view of things in order to build the best possible verification environment.
2. Register Accesses:
考虑这种情况：a design is specified to have a low-power mode that can be activated by writing a ‘1’ to a given register bit. The bit’s default value is ‘0’, making the device be in normal mode by default. In th
1. 首先我们应该很容易想到测试如下的情况：
x Write ‘1’ to the low-power bit
x Check that the device enters low-power mode
x Write ‘0’ to the low-power bit
x Check that the device exits low-power mode
2. 但是有另外一种情况没有考虑到：
what happens when a ‘0’ is written to the bit when the bit is already ‘0’ (or a ‘1’ when it is already ‘1’)?
这里面会隐含一个关键性的错误，说不定在0的情况下写0回不正确的进入低功耗模式。
验证计划包括所有可能发生的事情,不管是否DUT旨在处理它们,和无论设计师可能会说什么。
As you can imagine, doing error injection in creative ways greatly expands the search space for finding bugs, and so experience and a degree of gut-feeling is required to target those areas most likely to be concealing real bugs. Where is the line between inter-operating with the design and stressing it?
PRIORITIZING DEBUGGABILITY
1. 一个良好的TB强调可调试性！！
A. Protocols with Bi-Directional Ports
Some devices try to save on pins and board trace routing by employing bi-directional ports for data and/or clock signals. 这种协议的本质，至少有两个设备负责驱动数据和时钟信号，否则也不会使用双向端口。
上面是一种接口的实现方式，这种方式的可调试很低，因为所有的DUT和VC连接在同一个双向端口，但是很难确定到底是哪个组件在驱动总线。
Using a verification mindset, we make use of both unidirectional and bi-directional signals to achieve both ease of debug and adherence to the protocol.
(In Figure 10, “(highz1, strong0)” means “when signal is assigned with a ‘1’, it takes on ‘Z’; when it is assigned to with a ‘0’, it takes on ‘0’ ”).
在DUT里面，使用如下方式驱动：
ROUNDING OUT THE MINDSET
To what extent must the verification component follow the design protocol?
验证组件在多大程度上必须遵循设计协议？
The DUT is sending data without an accompanying clock - should my VC do Clock-Data-Recovery?...No
DUT发送数据没有附带时钟- 我的VC是否需要做Clock-Data-Recovery
The protocol has bi-directional signals with the potential for multiple masters. Should I split each signal into two at the VC interface level?... Yes.
?V. ROUNDING OUT THE MINDSET
A. No coverage without Checking:没有检查就没有覆盖率
以前面对一个low-power使能位写0当这个bit为0的时候为例，突出了另一个验证心态，就是never do coverage on anything in the absence of doing checks. This rules out doing register value coverage, because it is misleading at best and a waste of compute resources in a large system-on-a-chip (SOC).
B Approach to Debugging 调试的方法：
1. 使用waveform的方式debug并不适合VC，因为很多操作并不消耗任何时间，在发送激励的时候使用动态数据结构。应该有一种心态，最好的debug 工具应该是logfile本身。对于logfile：
1. 要有适当的和一致的消息模式
2. 当然这并不是说，可以不用波形去调试，但是更应该依靠日志。
3. 如果不能够使用logfile去debug，那只能说明消息机制需要提高。
C. Zoom-In, Zoom-Out Thinking
When zoomed-in the engineer does tasks such as:
x Understand design specifications
x Write verification plans based on the specification
x Write code to implement the verification plan
x Write testcase code
x Debug failing testcases
Verification engineers must also do a series of tasks while zoomed-out such as:
x Decide which design features to focus on to maximize bug discovery Devise creative ways to tease bugs out
x Allocate time so as to get the most important checking and coverage for the effort
The main reason for this is difference is that verifiers need to deal with a larger scope than designers do.
1. 不同于设计必须在tapeout之前完成他们的工作，验证可以再tapeout之后继续进行，或者放弃
2. 验证人员想做到这一点，必须要接触广泛的信息
3. system architecture, design hot-spots, project schedule, and client deliverables.
D. What Are We Trying to Accomplish Here?
E. Coverage, Not Testcases
F. Liaison between Design Architect and Design Engineer
G Quitting on First Error
最后简单的总结一下：
1. The protocol says that when an error condition is detected, the design must send a NACK packet. Should my VC automatically send NACK too?... No.
协议说,当检测到一个错误条件,设计必须发送NACK包。应该我的VC也自动发送NACK吗?…不。
2. The design indicates FIFO fullness with signals “full” and “empty”. Can my VC or testcase make use of them to prevent overflow/underflow?... Yes, but only if checks are made on them
3. Is it sufficient to limit error injection to the scenarios for which the DUT has detection capabilities?... No.
4. A design has a register bit that defaults to ‘0’, and causes the DUT to enter low-power mode when written with ‘1’. Is writing ‘0’ when it is already at ‘0’ important to test?... Yes.
5. Can I snoop the design’s internal clock to synchronize my VC to?... No.
6. Should I ask myself “what is it I’m trying to accomplish here?” when embarking on a new verification task... Yes
我应该问自己“是什么我想完成吗?“当开始一个新的验证任务……是的
7. Is it my responsibility to ensure that the design architect and design engineer are on the same page?... Yes.
这是我的责任,以确保设计建筑师和设计工程师在同一页面吗?…是的。
8. Should I regularly step back from low-level implementation and take a high-level view of the verification effort as a whole?... Yes.
9. A design draws circles of radius given by an input parameter. Is testing a radius of zero important?... Yes
10. Should I implement coverage on individual register values?...No.
11. Should I be relying mainly on waveforms to debug my VC?...No.
12. Is coverage closure more important than testcase passing rate?... Yes.
13. Is it necessary to allow a simulation to continue running after it has encountered an error?... No.
来自为知笔记(Wiz)
Verification Mind Games---how to think like a verifier像验证工程师一样思考
声明：以上内容来自用户投稿及互联网公开渠道收集整理发布，本网站不拥有所有权，未作人工编辑处理，也不承担相关法律责任，若内容有误或涉及侵权可进行投诉： 投诉/举报 工作人员会在5个工作日内联系你，一经查实，本站将立刻删除涉嫌侵权内容。