验证漫谈

seekerlee

顶起啊

seekerlee

顶起啊

zhang_zhiquan

学习啦！什么都是浮云啊！呵呵！

yuanwolf2008

小菜，，，表示压力很大

pcalexhero

高手啊

sonicsun

回复 1# rhythm1988
我是一名刚从学校走出来参加工作的一个菜鸟，非常感谢您能够抽出时间写这些东西，给大家一个指引。

看了你们这么多论战，我觉得核心有两个问题。

第一，求实，严谨。

我觉得您倒不是崇洋媚外，而是佩服老外求实、严谨的态度。国人缺乏的就是这个，从做事一直延伸到做人。"差不多”工程的例子屡见不鲜（ps：包括书的翻译）。态度决定一切。

第二，世界观。

众所周知，世界观的不同，造成了对事物的理解上的偏差。况且，自然语言是不精确的，对于某个词的定义，理解甚至都会有偏差。有些时候争论到最后，发现其实说的是一个道理，表达的是一个意思。

方法学是一个世界观的问题，跟随项目的经验和自身的思考逐渐形成的，有些共性的东西被人总结出来，这些东西有人甚至没有体会到或者根本没有机会去体会（譬如菜鸟我），偏差在所难免。

至少我目前掌握的知识来看，验证的水非常深，不仅需要对硬件设计了解，还需要扎实的软件功底，如果还需要提高工作效率，还需要能够精通脚本语言，层次再上升，需要对硬件体系架构的深层次了解。把这些东西融会贯通，世界就大同了。可以说，涉及到了计算机领域从底到上的各个领域。

我现在还是有个困惑，面对这么个汪洋大海，我不知道该从哪个地方开始下水，一个人能够掌握，尤其是精通一个技术的能力是有限的，况且，时间也有限。那么，应该从哪个方面入手呢？都说基础要打扎实，基础又指的是什么呢？怎么样才算基础扎实呢？望赐教。

loglong

好久没来论坛, 终于第一次看到了一篇有营养的验证文章, 说什么也要回复.
向楼主学习, 也八卦一下经历, 只有让别人了解自己的背景, 很多话才能说清楚. 我毕业4年, 全职接触IC6年, 设计验证都做过, 但主要还是做验证, 在假洋鬼子和纯洋鬼子的公司都呆过, 现使用specman+e...好了, 很多人知道了....

首先感谢楼主无私的分享, 从回复中的谢谢就看出楼主对我们新人的帮助了. 再次谢谢楼主!!!
当然我也不是只进不出, 下面谈谈我不太明白的地方或者我看了楼主的帖子后提高的地方, 算是读书笔记, 帮助像我一样还不能完全理解楼主的人, 应该很多吧. :-)

1. 翻译的问题. 这个我有体会, 本科时使用XIA老师的书, 没看明白他想说什么.后来一直坚持看英文原版的书, 突然有一天, 看了一下XIA老师的书, 发现如果你看完了英文版的话, 去看中文版没问题. 但是你先看的中文版, 能不能理解就要靠你的悟性了, 因为一个专业名字一翻译, 就有了很多专业名字, 你要确保你理解了这个词的背后啥意思才行啊.而且这是一个外国人主导的行业, 和他们使用一样的语言有助于今后讨论问题的时候减少歧义, 当然现在的中文翻译越来越多, 也越来越规范, 只要大家说的是一个东西, 说什么话我觉得不关键. 但是为了更好的理解作者的意思, 我建议用作者的语言阅读, 就像你用英语读唐诗, 你确定你知道他要说什么吗?

2. 验证的现状由于我经历太少, 没啥好讨论的.

3. 验证的技术, 我觉得方法学和语言都是相通的, 都是对一些验证方法的不同实现, 无所谓谁好谁坏, 看你用什么顺手吧. 以前我觉得OOP好, 结构清晰, 巨不适应E的AOP方法, 但现在用习惯了, 觉得各有优劣, 有灵活性就要牺牲一些可读性.

1）IC上所有的工作都是殊途同归，唯一限制你的只有你的眼界，把眼光放远一点；
    --- 很认同, 我觉得要花更多的时间去了解设计, 和设计的应用(application).
2）做事情要踏实，贪多嚼不烂，学多，不如学精，等能力上了一个台阶后，其它基本上触类旁通了，就好像武打小说的任督二脉，没打通，什么都白搭；    --- 在突破, 发现验证要做好, 真的是博大精深啊, 起码像我这样非软件背景的, 对C++等都只是略知皮毛, 还有很长的路要走.
3）把基础打扎实，多看看老外的书，深入体会一下老外的思路和想法，比如：把VMM之类的搞懂了，还得想想为什么？本来想讲讲学习路线图，不过这属于技术经验，只供BOSS使用，另外讲了对初学者没有好处，这是一个复杂的多方位的学习体系，必须由leader来领路；    --- 这样行不行: SystemVerilog for verification -> A Practical Guide to adoping UVM -> The C++ Programming Language -> 用C++作为testbench, 用SV作为BFM搭建平台, 和UVM或者eRM比较孰优孰劣.
4）IC这个行当学习曲线漫长而陡峭，刚开始的几年内就讲待遇，只能事倍功半。
    --- 看来我事倍功半了. :-)

loglong

-> hover99, 我觉得我们的经历比较相似, 所以你说的话我理解了, 但是我对C和VMM的水平明显不如你, 以后请多指教. 呵呵.
本来也想写一篇关于验证的文章，没想到被楼主抢先了。
    --- 你也可以开贴啊, 就像验证, 没有说我写了这个case了, 就不能其他人来cross cover.

其实楼主有点把大公司神话了，越是大公司技术越保守，尤其是验证，历史沉淀越厚，包袱越重。ic公司关心的是产品，工程师反而没有太多精力去搞什么方法学，即便搞出来也会受到项目组的抵制（假如现有的平台已经成功流片了多个产品，你会推翻它再搞一套新的吗）。
    --- 大公司的技术确实保守, 但是是居于已有项目的保守, 他没必要说设计不变, 且成功流片了, 再采用新的验证方法来再验证一遍吧, 我们公司也想从e转到VMM或者UVM, 但是对已有项目可能不太现实, 因为很多VIP都稳定了. 但是不能说大公司没有实力去采用新的验证方法, 像IBM, 我用过他们的后端的一些工具, 其实挺强大的, 也是现在市面上没有的. 而我们公司是设计公司, 核心技术也是设计上, 验证就采用了Cadence的标准流程, 我觉得Cadence的验证水平很高啊.

验证的目的是保证产品在多大程度上是可靠的，而不是找到bug。另外，本人认为验证工程师水平比较低的原因大部分验证工程师将大部分的时间花在建test case上，结果大致大部分人认为验证是一个技术含量比较低的工作，有一两年经验马上转去做设计。如果把debug能力作为验证工程师的重要素质，那么培养验证工程师的方向完全错了。
    --- 我觉得验证的目的就是找BUG. 你想说的是不是验证水平和项目中找到bug的数量不成正比?

个人认为验证方法学主要解决三个问题，复用；testbench和test case的分离；testbench的鲁棒性。第一个问题（不仅包括项目之间的横向复用更包括自底向上的垂直复用）没啥好说的，无非就是节省工作量。第二个问题的本质就是分工，建test case的工程师需要对产品本身有更深入的了解，甚至就是设计工程师。第三个问题最关键，高效率的工作写testbench和设计基本上同步进行，这样就会导致写testbench的时候，设计是不确定的，极端情况是你的验证工作已经完成，这个时候设计突然改动了，这个时候就能体现出一个高水平的验证工程师的价值。所以从这一点上看，OVM比VMM1.1先进一代（VMM1.2基本上和OVM没啥区别），OVM比VMM晚了2年，技术上先进也是合理的。
    --- 很同意你的观点, 也说明我俩水平差不多哈:-), 或者说我们都是Synopsis和Cadence的受害者, 因为他们就是这样教我们的.

loglong

-> hongjian77

专业论坛和一般论坛还是有区别的, 因为这里都是学历比较高的, 最受不了别人的冷嘲热讽, 你是我老板也不行. 别人用中文, 像海思, 像很多本土公司, 是为了交流方便, 你一下得出那么多结论来, 说明你是一个很好的工程师(联想丰富), 但是还不会尊重别人, 或者说自视过高.

假设设计要求增加错误检测功能需要driver产生error injection，这个时候除了改testbench还有别的方法吗？
    --- 在specman+e的AOP环境中, 你可以在case中扩展(extend)出一个新的类型, 然后发下去, 我觉得specman最灵活的地方就在这了, 哪里都可以随意的修改源代码, 但是就是太乱了, 不熟悉架构的人, 完全不知道哪里drive的. 如果一些checker报错了, 可以在case中把这些checker关掉, 或者把checker从error改成warning, 再在case结束时使用关键字匹配看看这些checker是不是报过warning出来.
    --- 在OOP的环境中, 例如UVM的书上, 使用factory, 但是factory换的东西比较多, 如果在class中预留一些callback, 那么就很容易实现AOP的对于代码的增加和修改, 我对UVM仅停留在实习阶段, 对VMM一窍不通, 所以错了不要怪我.

我现在觉得eRM/UVM/VMM这些方法学都很好, 都能用constraint random + functional coverage来保证验证的可靠性, 使用virtual sequencer, signal map等来保证reuse, 且把验证的人分成testbench developer和testcase writer对工作进行细分, 让我感觉很不错啊, 但是好像很多本土公司都喜欢采用C++/C/SC作为验证平台, 使用SV/Verilog作为BFM(bus function model), 是不是因为license要花钱的原因? 还是希望把技术掌握在自己手里? 我列了几点不理解的地方, 希望懂得人给我介绍一下:
    1. 用C能实现random, 但是其random能像specman那么强大吗? 就是如果A random 到了一个值, B根据这个A的random范围再random, 当然要实现肯定是可以的, 但是如果环境是verilog, 然后通过DPI去调C的话, 是不是调用太多次C之后导致速度下降. 能给我详细介绍下C+SV平台的random激励产生过程吗?
    2. Coverage在那一层实现? 应该要在transaction level吧, 那就是C里面了, 怎么实现的?
    3. 像ncsim和vcs都对其支持的语言做了优化, 例如specman+ncsim就比specman+vcs快很多, 而且使用方便, 不知道C+ncsim或C+vcs, 只用DPI接口调用函数会不会导致仿真速度下降? 一般跑一个SOC subsystem的block level的测试平台速度怎么样? (我也不知道怎么衡量啊....)

rhythm1988

有意思，碰到了用AOP的人，有个疑问：为什么你特别关注仿真的速度问题，要知道准备好testbench后，debug的时间远大于仿真执行的时间，难道你们的IC的门数业界领先了不成，仿真速度已经是瓶颈了？

没仔细看，碰到了AOP和OOP兼修的人士，失敬失敬！