有什么做C语言的网站,腾讯微博做网站外链步骤,网站建设网络推广seo,广告公司的网站建设1. 有效的验证需要验证工程师使用不同于设计者的思维方式思考问题。具体来说#xff0c;验证更加关心在严格遵循协议的基础上发现设计里面的bug#xff0c;搜索corner cases#xff0c;对设计的不一致要保持零容忍的态度。mindset#xff1a;一套人们应该持有的确定的态度验证更加关心在严格遵循协议的基础上发现设计里面的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 clock2. It avoids any possibility of the testbench masking a problem because the CDR algorithm is too tolerant3. It has better simulation performance than doing costly checks on data rates4. 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 identification1. Function Input Parametersa. 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 th1. 首先我们应该很容易想到测试如下的情况 x Write ‘1’ to the low-power bitx Check that the device enters low-power mode x Write ‘0’ to the low-power bit x Check that the device exits low-power mode2. 但是有另外一种情况没有考虑到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?...NoDUT发送数据没有附带时钟- 我的VC是否需要做Clock-Data-RecoveryThe 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本身。对于logfile1. 要有适当的和一致的消息模式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 outx 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 them3. 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?... Yes10. 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)转载于:https://www.cnblogs.com/bob62/p/4050968.html
