logo资料库

IC验证经验《总结我的思路-如何在验证中发现和定.pdf

发布时间：2022-06-14 发布人：admin 分类：说明书 资料大小：1.45M 资料格式：pdf 举报 版权申诉
第1页 / 共16页
第2页 / 共16页
第3页 / 共16页
第4页 / 共16页
第5页 / 共16页
第6页 / 共16页
第7页 / 共16页
第8页 / 共16页
资料共16页，剩余部分请下载后查看
    DocumentTitleSecurityLevel:2014-04-22HUAWEIConfidentialPage1,Total16有人认为我验证做得很牛，也有人认为我的验证早就丢下了；有人认为我发现了各个项目的不少问题，也有人认为我在CMM库的几百个问题单大部分属纯净水。好吧，无论怎样，我还是把我在验证中如何发现和定位Bug的思路稍微描述总结一下，纯属灌水。以前华仔曾经叫我写过一次，我随手写了一点点，这次还是详细一点吧，主要分几点：视角、技巧、思路、经验。这里主要还是共享给验证的同志们，但对设计的同志其实我觉得是没有什么差别的。目的：发现Bug，发现所有的Bug，或者证明没有Bug，是验证存在的唯一目的。无论任何验证语言、任何验证环境、任何验证方法学、任何FeatureList，都是为了达成这一目的而使用的方法，或者所手段。偏离了这一目的任何工作和努力，都是屎、大便、Shit。绝对不要被任何华丽的技巧、方法、经验所迷惑，无论验证环境有多么美丽，无论验证语言有多么的HighLevel，都不要迷惑。不要为了追求完美、高效的环境而沉迷其中，陷阱往往就在美丽的后面。有时候，最简单的，才是最直接的，任何武术，直拳最有效。以SV为例，SV有高层次的语法和结构，能够更大限度发挥激励的控制和Random测试的效率。但是对于发现Bug的目的而言，它只对其中的20%目标达成有突出贡献，而剩余的80%，其作用和普通的Verilog并无二致。当然，我不是指要放弃SV，因为其有效贡献的20%工作，是普通Verilog很难或者无法完成的工作。OK，所以顺便涉及另一个问题，设计人员需要学习SV吗？有多少设计人员能够在检视或简单UT中发现80%的Bug，而需要SV去完成最后20%？不要看见别人用SV，就屁颠屁颠地跟潮流，想清楚SV能为达成最终的目的带来什么贡献才是关键。设计人员和验证人员相互沟通，真正的障碍是验证方法学，而不是验证语言。以TC为例，对于一个验证人员，跑通全部TC，意味什么？代码覆盖率100%，意味什么？验证差不多完成？在我看来，相当于验证工作大致完成了90%，而有一句老话怎么说的？行百里路，半九十。也就是所，实际上剩下10%，才是最艰辛的工作。也许某条TC什么也没干，然后因为什么也没干而Pass了，或者没有实现验证者的意图，所以也Pass了。只有，而且也只有，有充足信心证明全部Bug被发现、或者没有Bug。但这个充足的信心怎样说明？后面我再详细说明。视角：有多大的视角，就能发现多少的Bug。引用CCTV的一句台词，心有多大，舞台就有多大。我比较不喜欢看到的，就是一个验证人员跑来告诉设计人员，说某某TCFail了，波形在XXX，请分析。我不能认定这位验证人员的工作是否合格，只能表达强烈的情绪，特别是最后发现Fail的原因是验证环境问题的时候。这种验证人员，对设计人员、项目经理，都是巨大的风险。因为设计和验证，是一定需要有交集的，并且耦合越大，风险越小，只能提Feature、写TC的验证人员，就像初三的新月一样，反而需要别人去耦合，如果设计人员视野不足，野心不够，就存在空隙了。
    DocumentTitleSecurityLevel:2014-04-22HUAWEIConfidentialPage2,Total16一个验证人员，如果能够发现设计中的CriticalPath并告诉PR，一定不会得到批评，反而会在实现工作中得到更多的发言权，和更多的发展。一个验证人员，如果仅仅只能跑写TC、跑TC，那么多年得不到晋升恐怕也怨不得别人。OK，回到原点。验证人员必须要懂得代码，懂得分析逻辑，甚至能够通过代码分析出可能的疑点，更好的，能够理解整个系统的运作，理解前端后端的实现，找出设计人员视角的盲区，才能更好的发现Bug，解决Bug。当然，某些同志会认为，验证人员，发现实现的问题耽误了主业，而且实现的问题，实现人员更容易发现。OK，这里同样存在一个视角的问题，你的视角和实现人员的视角是不一样的，也许觉得很容易发现的问题，恰好别人不容易发现呢？反过来说，实现人员或设计人员还可以觉得代码Bug对于验证人员是很容易发现的呢。此外还有一个时间成本的问题，任何问题，遗留的时间约长，代价越大。所以我说一句，验证人员，一定要放开视角，努力去看你所能够看到的，然后，你能够看得更多。然后再补充不务正业的说明，验证人员的目的是发现Bug，这是唯一的目的，不仅仅是一个TC所能发现的Bug，而是整个芯片可能存在于任何环节、任何位置的Bug。只有芯片的成功，才是真正的成功，而一个Bug，就可以毁掉一个芯片，而覆巢之下，安有完卵？当然，验证人员会问，整个芯片太大了，扩展视角，不是不努力，而是看不到啊。OK，我再说一句，对于验证人员，最简单，最真切的视角就在脚下。TC，每一条TC，每一个TC的波形，都代表了芯片中的全部或部分，真实运作的场景，有血有肉。如果把波形当作TCPass的附属物，那么，恭喜，验证人员，你拿了芝麻丢了西瓜。波形真的可以告诉你很多、很多。我甚至可以公布我做验证的时间分布（不包括最初搭建环境的时间），20%时间写TC，10%时间调环境，50%时间看波形，确认TC达到我想要的意图（TCLog中的Pass？噢，对不起，这种狗屎信息我向来忽略），剩余20%时间？对，剩余20%的时间，是我固定的，从当前表面上正确运行的波形中，对照代码，寻找其他可能发现的时间。不要跟我说现在系统太复杂，看波形效率太低。OK，Hi1380的系统复杂不？整个波形我也从头到尾看过啊。而且，就在我看波形的第一天，就是从一个已经Pass的，好像是GIC的系统验证波形中，拿到了超过20个问题单（加上代码检索的30个问题单，创造了下图中陡升的曲线，不过可惜了，没能突破300）。
    DocumentTitleSecurityLevel:2014-04-22HUAWEIConfidentialPage3,Total16淘金的执念：缺陷就在哪里，静静地躺在哪里。没错，一定在，而且马上就能看到！！执念，这是一种执念！！作为验证人员，一定要有这种强烈的，不可动摇的执念或者说饥渴感，而且是和设计人员强烈对抗的执念。实际上，目前看到的所有芯片，都已经证明，投片后，依旧有缺陷遗留在其中，没有被发现。所以，这种执念，无比正确。只有疯子，才能发现隐藏得最深的金子。我开始做设计之后，这种执念消失了很多，总是希望系统确实在完美地运行，失败，很是失败。不过对他人设计的模块，以及不是我负责的项目，这种执念还是非常强烈，呵呵，这也是我在1380和P600中疯狂创造问题单的原动力。这跟淘金的人，可能是差不多的。金子就在这里，一切的希望都在这里，再挖一锄头，就找到了。只有疯子，才能成功。淘金的技巧：指定找一块地，疯狂地朝下挖？No，No，疯子都会B4你，淘金也是有技巧的。很多方法，其实说白了，很简单的。表层的土是最容易挖的，那么，别人没有挖过的地方，最有可能在表层找到金子。为什么别人没有挖？很简单，盲区。两种盲区：1）明明每天都能看到，却没有人想到去挖一挖的地方。以1380为例，天天都有人跑ARM，就硬是没有人去分析一下ARM，如果最开始，就能多看看ARM的ACP代码，宝藏啊，宝藏啊，ACP虽然没有错，可是上游会冲下来多少金子积累在这里啊。2）别人不屑于去挖的地方。IO_CFG简单吧？TEST_MUX简单吧？TOP层的IO互联简单吧？不屑啊，多少验证人员对此不屑一顾啊，那眼神就是在说，真TMD没技术含量。是啊，再TMD没有技术含量，也是金子啊。对于表层土的挖掘，不要太固执于一点，广撒网，多捕鱼。如果十锄头都没有挖到金子，马上换地方，对于别人刚挖过，还没深挖的地方，也来上几锄头，说不定就可以让前一个家伙悔到死。表层土都差不多了，就需要找关键部分深挖了。如何找关键部分，是非常讲究的事情，兼顾风水、心理、外交、直觉等多方面知识，很难给出综合性的分析。下面几点可作为Hint：1）如前面所说的，只知道跑TC，跑错后让设计人员定位的验证人员负责的区域；
    DocumentTitleSecurityLevel:2014-04-22HUAWEIConfidentialPage4,Total162）对实现没什么概念的设计人员设计的模块；3）责任人变来变去的地方；4）DFT相关的地方（验证人员的DFT知识严重缺乏）；5）规格老是变来变去的地方及其可能影响的地方；6）第一次做代码集成人员连接的顶层位置；7）浮浮躁躁、毛毛糙糙的新员工负责的地方；8）时钟域（几乎当前所有的验证人员都不关心时钟正确性，只要能跑TC）；9）所有人都认为没有问题的地方；10）验证人员宣称放弃的地方；11）技术难度比较高的地方；12）你以前项目发生过问题的地方（相同或类似的问题很大几率存在）；13）整个系统中相关性非常高的一连串区域；14）协议和时钟转换的区域；15）其他隐藏在内心深处的秘密。需要注意的是，在挖掘这些Hint点的时候，并不一定能保证挖到金子，而且即使有金子，你也并不一定能够挖到，人品，人品很重要。OK，关键部分都挖得差不多了，剩余的金子基本上就埋藏得比较深了，这个时候发现的金子都将比较可观。再不济，也能够成为荣誉奖、星星奖之类，要搞得恰当了，直接拿A也不是梦想。当然，如果没能发现金子，一无所获的可能性也很大。收益和风险是成正比的，淘金人在这个阶段一定要能够沉下心来，冷静思考。楼上提了这么多Hint，那个地方还比较薄弱？整个项目统观下来，还有哪里有薄弱的？你在思考，项目经理也在思考，验证经理也在思考，SE也在思考。如何超越项目经理、SE、验证经理的思考发现金子？我非常、非常难以回答。提供我已有的两个经验是：1）反向思考。最后阶段，大部分人员的思路都已经固化了，像一条绳子一样，不断的朝一个方向缠绕、缠绕。反向的思考往往能突破这个限制。当然，反向思考这个东西，很多时候就是忽悠，难以做到。我的一个经验是可以多听取一下局外人的一些意见，例如软件人员的意见。当然，这其中大部分的意见都是无关痛痒的瞎扯，但偶尔、偶尔会出现一些能够引发进一步思索的缺口。2）和谐。这里没有任何问题，芯片运作一切正常，没有任何差错。但是你拿着架构图看、或者拿着时钟结构图看、或者打开最复杂的ST波形看，心中却总是有一种说不清道不明的感觉，没错，虽然一切正常，但是某个地方，却有那么一点点不和谐，就像合唱团中插入了一个走调的家伙一样。可能是非常微妙的一个路径，可能是波形上非常诡异的一个脉冲。对了，就是这个地方，追下去，即使工作正常，这里也可能存在和设计意图不符的东西存在。书签开门红：根据规格分解FeatureList，根据FeatureList对应TC，然后再一条一条仿真TC反过来
    DocumentTitleSecurityLevel:2014-04-22HUAWEIConfidentialPage5,Total16映射FeatureList和规格。没错，这是最通常的做法，可惜我不这样做。世间有80：20原则，验证也是，80%的问题都可以通过20%的测试和时间去发现和解决，而剩余20%的问题需要80%的测试和时间去解决。所以，按照我的思路，会有几个最初级的TC，可以用来测试最基本的通路能否冒烟，这几条TC，可以划归到TCList中，也可以不划归。然后，一定有一条开门的TC，这是一条复杂的DirectedTC，一条可以覆盖70%的Feature的TC。这条TC并不负责任何Corner、异常覆盖，不做任何特殊的思考，一切都是直接对Feature的连续描述（也可以是若干条TC的直接串联），因此即使有些许问题，修改的难度也比较低。这条TC能够帮助设计人员定位超过70%的问题，如果设计人员足够聪明，这个TC可以解决90%的问题。这条TC的寿命可能将超过一个月，这一个月足够设计人员在其中沉沉浮浮，使得代码达到95%的交付情况。而验证人员在这一个月中，有足够的时间完善Corner的TC、Random的TC和环境，然后集中精力完成剩下10%问题的解决。检视：代码检视是最容易发现问题的步骤，从写第一行代码开始，到最后一个Tag结束，都是如此。代码检视不仅仅是设计人员的事，也是验证人员的事。我知道很多人都不认同这样的观点，正如我不明白为什么有些扫一遍代码就能发现的问题，有些验证人员还那么兴致勃勃、废寝忘食地编写TC，然后再辛辛苦苦跑TC来发现一样。正因为我做过设计人员，所以我感受非常深刻，设计人员绝对都是极度乐观、自信的，特别是代码刚刚完成那一霎那，瞬间的快感，Oh，凤姐啊，芙蓉啊，让设计人员全身都在颤抖。破绽啊，这里有太多的破绽了。所以对于新交付的代码，按照我的经验，建议验证人员先检视（尤其是设计人员是两年以内设计经验的），不过，这个检视绝对不要是傻看代码，要跑一条TC，最简单的，就一个读写就可以了，保存所有信号的波形，然后打开Verilog代码，对照着波形检视。1）所有信号全部抓出来看一遍，红色的（X）、黄色的（Z），简单确认一下，然后Alt+Tab，切换到CMM页面即可（百试百灵，至今为止从未失手，nLint不是万能的）。2）模块间的握手信号，全部抓出来看一下，是脉冲信号还是电平信号（98.765%的设计人员，都不会在信号名上注明是脉冲或电平），脉冲信号是必须立刻采样的，电平信号是需要鉴沿的，如果握来握去，如果还有异步，基本上，检视出问题的概率非常高。3）在一个always中，对多个信号赋值的；在一个always中，elsif数量超过6个的；在一个always中，if的条件组合中包括超过5个信号的；都是高产田。4）协议理解上和自己理解相异的，例如对于我，AXI相关设计未按照我《AXI总线设计的二十一条忠告》的。代码，是设计人员思路的直接映射，而设计人员的思路，有时候真的是一根筋。通过检视，或者加上设计人员的讲解，可以直接了解一下到设计人员的思路、逻辑思维模式，非常有助于去构造一些检测其思路正确或不正确的点，验证人员的思维其实很简单，抬竹杠就好。请读者回忆一下刚刚经历过的项目，在100%网表之后，是否有好几个ECO，都是从检
    DocumentTitleSecurityLevel:2014-04-22HUAWEIConfidentialPage6,Total16视中出现的（代码或脚本或TC）。而每一个这样的事件，都是那么神奇的偶然。可能是某位新员工周末偶然在学习老员工的代码时发现异常；可能是某人在项目经理逼迫下第三次检视某个模块时，惊讶地发现了一个低级错误；可能是某个IP交付团队某天突然想起说有一个连接的错误忘了改正，但幸好在ECO前发现。反正，总是奇迹一般，让项目经理觉得自己是世界上最幸运的项目经理。明白了吗？我经历的多个项目，每次都有这样的奇迹，其比例占ECO的约30%～50%，这不是偶然，是一个说不清，道不明的必然。也许，只是100%后，同志们有更多的时间投入检视而已。怎么能不检视？检视，在任何时候进行，都不算早，也不算晚。OK，这里就扯到另一个话题，某些同志经常反馈，检视工作非常不受待见。不做，没人管，做了，看不到绩效，即使检视出问题，也会有人跳出来说，“这么简单的问题啊”，特没成就。OK，我认为这是管理问题，典型的。无论对于海思的投资团队，还是对于项目经理本身，用最小的投资，或者说最小的人力、最短的时间，努力去发现项目中的问题的活动，难度不是最应该鼓励的吗？OK，如果你真有这样的感觉，我的建议是，将检视问题提问题单，再不济也是一个严重，发现阶段为ST，不用觉得害臊，害臊的应当是管理者。此外，到最后阶段的检视，对于验证人员，可能需要更加地扩大视角，围绕代码为核心，TC、波形、脚本都需要涉及。对于这里，我还是再强调一遍吧。验证人员拥有设计人员所不同的视角，所以一定能够发现潜藏在其中的问题，对于单个项目而言，验证人员会认为是一个偶然，而从多个项目而言，我的经验，这是一个必然。检视的经验：OK，这里我可以再补充一下我个人检视代码的经验，我的步骤如下：1）hdl_stat统计整个模块代码行数，及各个子模块代码行数分配；2）打开代码顶层，快速浏览整个代码，获取这几个信息：代码风格、设计人员的思维成熟度、代码结构、重用度、逻辑类代码和集成类的分布、关键CPath和关键DPath的位置；3）按照现有的经验，其实已经大致能够推断出该模块整体的缺陷数量和缺陷分布了；4）先简后难，先扫除直接就能够看出的Bug，这种Bug分布比较散，没什么特别的依据，但很多问题，真的很简单，就在设计人员鼻子底下（不要超过2小时）；5）用Verilog构造最简单激励给模块，保留波形供对照，如有疑问，更改激励再仿（不要超过3小时）；6）然后，因为我有设计经验，我就会思考如果自己是设计人员，我会怎样划分模块、描述关键控制逻辑，如果和设计者不符的地方，着重分析；对识别出来的关键控制逻辑，例如异步握手、堆栈、链表、数据拼接，静下心来，慢慢看，慢慢看。对于疑点，构造简单激励，出波形对比。OK，我拿我曾经的一个模块SecurityEngine代码作为实例，如果我进行检视如何进行。1）代码行数约17000，行数最多的集中在几个整体控制模块：sec_ctrl（2235）、sec_slave（2121）、sec_channel（1669）、sec_master（1193），除了这几个大模块，几个算法都分散为非常多小模块，相互调用搭成aes_core、kasumi_core等算法模块被顶层调用。
    DocumentTitleSecurityLevel:2014-04-22HUAWEIConfidentialPage7,Total162）第一轮检视，快速浏览。各个算法模块的输入输出非常干净，都是通过run、done进行握手，其内部都是轮运输，通过round控制，其中aes_core还是纯复用以前项目的模块，而顶层几个ctrl模块，则相互交互非常复杂，特别是代码数量最多的模块，数据交互特别复杂的sec_ctrl和set_master，居然没有状态机，看起来设计人员是希望通过自己的逻辑思维，直接描述其控制；而sec_slave，纯寄存器描述，而且是大量复制代码搭建，技术含量低；结构上，sec_channel是一级控制，sec_ctrl和set_master是二级控制，各个算法Core是三级控制。代码风格上，设计人员部分遵守代码规范，但很多地方自以为是，为了自己方便写了不少擦边球的代码。3）分析，aes_core理论上缺陷将很少，而其他几个算法Core，如果round控制上没有发现错误，那么错误通过RM比对验证，效率更高；然后，sec_channel，可以着重关注状态机和状态机对应的控制信号是否正确；最后，sec_ctrl和set_master的交互，一定是关键，特别是代码量大的部分。4）第二轮检视，对算法Core的各个round控制信号检视，是否符合run、done控制；对sec_slave的寄存器读写控制检视，是否有笔误和拷贝的错误；检视整个代码集成和互联；简单查看其它代码中if和else比较复杂的地方，记录可能的疑点。5）构造一条TC，正常而言，是通过sec_channel调配sec_ctrl完成一次算法运算（用最简单的Verilog搭建TB，超过2小时是否非常失败的事情）。根据波形，将sec_channel、sec_ctrl和set_master主要逻辑，全部过一遍。6）关键逻辑，重点关注，关键疑点，修改TC，重点覆盖。再谈检视：首先引用一个对检视的不同观点：review真的最有效吗or导致更多的BUG?review:中文叫评审。本人见过这个做法的最早出处是朱兰的质量手册。在很长一段时间被软件行业认为是最有效的保证代码质量的手段。这段时间的质量高压之下,我们再次见到了红红火火的各种代码vreview,自检,互检,飞检,X检。这让我想起了考试,考试完了都要自己检查几遍再交卷。(当然是在能够把题目做完的情况下),偶尔我们也会在考场上互检(不过这个可能属于作弊)。不过从以上最简单的例子可以看出,互检应该比自检效果好很多,不然也不会有很多学生冒着风险去互检了。但是:上周在和敏捷顾问一起参加一个项目组的回顾会议的时候,发生了这样一个状况,大家在讨论下轮迭代需要改进的时候,都提出来要加强LLT测试用例的review,顾问一直追问我们为什么要这么做？是不是上轮迭代的结果出了什么问题？我们这样做能够带来哪些改善？我们的UT一直做得很弱,顾问非常奇怪为什么我们不多花些时间做UT？而要花时间去做LLT用例的review？当问到从迭代结果上除了什么问题而导致我们想加强LLT用例的检视的时候,大家都找不出直接的证据,只是说:如果不评审,风险会很大。(但是上轮迭代的最大问题大家已经搞清楚了——是:低层BSP没有人力投入,导致其中4个相关的Story无法全部完成。我也很差异顾问提出来这个问题,他继续讲:review有可能是一种浪费。myladygaga!我自己从来没有听说过review可能是一种浪费。顾问为什么能够提出这样的疑问？其实这段时间经常会收到不少项目组发的邮件,宣称自己团队组织封闭检视又发现了几
    DocumentTitleSecurityLevel:2014-04-22HUAWEIConfidentialPage8,Total16百个问题,似乎是这样做还能得到一些表扬。当时,我内心深处觉得有那么些不对劲,团队1个月的编码工作,怎么能在短短半天的时间里面就可以检视出这么多问题？这也许说明了检视有效,但是是不是更加说明我们前面的工作并没有做好呢？(再次Oh,myladygaga,我自己怎么都对review产生了怀疑。)后来忽然在温伯格(«软件程序开发心理学»«顾问工作的秘密»等书的作者)的一本书籍目录中看到了这样一句话,“任何质量措施,益早不益重”。但是非常遗憾,我没有看到全文,只能根据这句话来进行推测和分析(在信息不完整的情况下进行分析是敏捷教练应该具备的能力之一——someonesaid)。好吧,我们来看看REVIEW的效果吧。优点:review能够发现问题。缺点:review无法象测试一样可以重复性地保证缺陷没有被引入。另外:我们可以按照下图方式画出review和BUG的系统控制图:如果我们在如下场景下加强REVIEW,将会进入一个非常有意思的循环,加强REVIEW->发现问题->占用了时间,更没有时间做测试等等->生产更多的问题->review会发现更多的问题->大家认为vreview很有效果->大家会用更多的时间REVIEW->于是产生更多的BUG^^^^^^^^^^神啊，GAGA啊，感谢这些不同的观点吧，正是有了不同的观点，才让我们能够更加深入讨论的机会。在我写完前一期的经验总结后，接收到了很多关于检视的不同的观点，很耐人寻味的是，这些反面的观点，基本上全部来自于从Intel、BroadCom等公司背景的高端同事（当然也包括了我引用的这位外籍专家），在这些外来的，充满魅力、经验丰富的男人们看来，强调检视是属于海思（从引用的专家的指向，整个华为也是如此）的专利，而被人直接用肉眼发现代码中的缺陷，简直就是人生中的奇耻大辱，真正保证设计正确的，只能是有激励的仿真。其实我非常赞成楼上最好的一个描述，真的，非常赞成。检视，只是检视，只是能偶尔地，发现一些错误而已，检视什么也保证不了，检视既不能保证Bug被全部发现，也不能保证这些偶尔发现的Bug能被修正或不被重犯，更重要的是，检视根本无法保证设计最终能够正确运行，最终能够保证设计正确运行的，只有仿真。
    分享到：
    赞 收藏

    相关推荐

    资料库

    开发技术

    共收录19306份资料，累计14个分类，关注成员有19位，主要包括：Actionscript,Javascript,PHP,VB,Perl,Delphi,Python,C#,C,Java,C++,Web开发,硬件开发,其它

    热门标签

    Actionscript Javascript PHP VB Perl Delphi Python C# C Java C++ Web开发 硬件开发 其它

    最新资料