在线咨询
eetop公众号 创芯大讲堂 创芯人才网
切换到宽版

EETOP 创芯网论坛 (原名:电子顶级开发网)

手机号码,快捷登录

手机号码,快捷登录

找回密码

  登录   注册  

快捷导航
搜帖子
楼主: rhythm1988

[原创] 验证漫谈

[复制链接]
发表于 2011-7-3 09:42:49 | 显示全部楼层
一直在潜水,本帖虽然是验证漫谈,但是rhythm1988通篇只做了3件事:抱怨国内的环境,重复10年一本老书的观点,最后又崇拜了一下洋人。
看到rhythm1988的团队成员居然看中文资料,我简直要喷饭了。我和同事都是中国人,但是我们写文档发工作mail都用英文,有时候需要用中文写文档反而写不出来。仔细看了rhythm1988的回帖,确实有领导风范,就是说你不行,你的层次不够,具体那不行就要靠自己的慧根了,真是牛人!记得当年打cs的时候,大家都讨论那种枪厉害,突然有人说真正的牛人就是用匕首也能杀人,你们的讨论层次太低,于是被大家无比崇拜,结果打起来却发现水平so so。所以大家得到一个结论,要想做牛人,绝对不能展现出自己的实力,要说些似是而非的话,最重要的是要掩饰自己的观点。比如大家在讨论肉车的时候,明明你非常赞同,但是你也要说:没有肉车只有肉人。语言只是工具,vmm只是应用,这样一说,别人就不好意思问你这方面的问题了,即便是你一窍不通别人也无法察觉,对你只有仰视。rhythm1988从业10多年了,应该是管理层了吧。这些人对技术细节并不了解,也不屑于了解,不是说这些人水平低,而是说在这个层次的人关心的是flow和宏观问题。但是这些问题不是engineer关心的,flow追求的终极目标就是同样的任务任何人做出来效果都一样,记住体制中是培养不出牛人的。
不过看到下面hover99的帖子倒是觉得有些新意,特别注册一个id来谈谈我的观点。本人是designer,也懂一点vmm,不过我们soc的验证环境还是verilog的。以我的经验来看,bug往往出现在你认为不会出现bug的地方,让designer自己验自己的design,总觉得不靠谱。其次,hover99所说的只改testcase不该testbench,我觉得过于理想化了,假设设计要求增加错误检测功能需要driver产生error injection,这个时候除了改testbench还有别的方法吗?
 楼主| 发表于 2011-7-3 12:59:53 | 显示全部楼层
本帖最后由 rhythm1988 于 2011-7-3 18:26 编辑

回复 11# hover99

占个位置先!待续。。。
很不幸,本人就在楼主所说的M公司,而且在最核心的部门和美国工程师合作了2年,至少在去年我们最先进的产品仍然是使用verilog来验证的。非常不幸,你对大公司的评价和对我个人的评价完全陷入了悖论。在M公司(楼主说的纯洋鬼子)和以前的公司(楼主说的土财主),都遇到这么一个问题,当我们试图用新的验证技术去替换旧的验证环境时,会发现有大量的test case需要大量的人力去移植,结果时间和人力上都无法满足,好的情况就是两套环境并存并持续若干个项目,最终转移到新的平台,有一个有趣的现象在两套环境并存的过程中,几乎所有以前抱怨过老环境的人都认为老环境还是可以接受的。验证的最终就是追求功能覆盖率,新老技术都能做到这一点,只不过新技术效率更高并且更不依赖于验证工程师的素质。结果就是在新老技术交换过程中,效率更低下。所谓大公司的包袱救治指的这个。
LZ:你看问题说具体了,就有讨论的空间了。你说的比较典型,OK!上面转换策略是你们具体执行的方式和碰到的问题,我提一个思路你看会不会好点?比如:你们的平台能否提前一到两年实现,并做好平台的测试工作呢(包括VIP)?团队的manager和leader能否深入产品去提前挖掘需求,做到一个提前量,也许抱怨的人就会少一些。
另外还有一个问题,即上面提到的大量的test case需要大量的人力去移植的说法。呵呵!上次有意没有点这个问题,看你这么执着,就说一说解决方案,非常遗憾的是,业界已经更新了大量test case的做法,具体的做法是少量的test case(少到多少有讲究)+自动更新随机种子+部分的定向测试的方式来完成覆盖率要求。
你仔细去看8楼的回答中,我压根就没有提所谓的大量test case的说法!!!你可以想象得到我看到这句话时的表情,应该说你在一个封闭的环境中,天空就那么大一点。
为了防止你吹毛求疵,我再把相关问题说透彻一些。
其实,我贯穿整个讨论一直在明确关于语言和验证工作的问题,只是没有显性的说出来。说了多少次了,开始就说牛人的做事情方式和思路,说了两个验证方法学的不存在优劣的问题,说了要把基础打扎实一些,其实都是在说这个问题,目的是希望看帖子的人自己能够有所悟!当你自己有悟的时候,才能够改变验证工作被动和地位不高的问题。
你没有悟出来吧,还把自己的一知半解给拿出来做理由,这就怪不得我下重手了。
我来解释一下最先进的产品仍然可以用VerilogHDL和VHDL来验证的理由吧。如果我们可以不怕麻烦的话呢,所有的问题都可以用C/C++,再源头就是汇编了,但很明显,有牛人用的不爽,干脆自己编一个出来,同时也造福象我等这样的平庸人士,VerilogHDL之类的就是这么出来的。
那好了,既然有牛人造出了Verilog,使C语言插上了时间性和并发性的翅膀,难道还有什么问题不可以用c加上verilog来解决呢?甚至更极端的,你们公司有大牛,干脆用c甚至汇编来解决问题,不是不可以哦!
所以说,方法学没有什么优劣的,既然systemverilog是半吊子的面向对象的方法,那么我VMM用CALLBACK,你OVM就没有资格来批评我,咱们都是半斤八两,有本事你OVM干脆搞个纯oop的硬件描述语言生态圈出来?这就是我为什么说没有优劣的原因。
不告诉你,是你整体还没有上这个台阶,贪多嚼不烂,后面居然成为攻击我不了解方法学的原因,彻底无语了。。。
最后说说M公司,不知道我说的“M”公司是不是你说的M公司,几年前听说M公司是唯一把核心业务放到中国来做的公司。我在多年(接近十年)前看看的一篇关于集成多子系统在单SOC芯片的论文,就是M公司的,文章应该是99年的DAC论文。记得看的时候是十一,没别的事,干脆仔细看看,应该承认“M”公司在新千年之前,就已经是业界领先了,想不到十年之后,还是如此而已,难怪没落得要私有化的程度,唉。。。



其实这种例子有的是,最典型的莫过于塞班,诺基亚算不算大公司?大家都知道塞班落伍了,但是提高技术甚至推到重来,诺基亚偏偏就是做不到。
LZ:这个问题我是外行,但尽量交流一下。其实类似的情况业界也有,新千年的时候是网络股火爆的时候,Intel花了60多亿美刀买了个做网络处理器的公司,Intel公司的技术实力不可以质疑吧,结果呢?一塌糊涂,最后公司好像不到7亿卖给了Marvell!
关于塞班的问题可能很复杂,但和Intel类似,根本上应该是高层在不熟悉的子领域中的策略有问题,一个正面的例子是Apple,其实我们看IPAD的硬件成本和售价,对比IMAC的成本和售价,就知道,在数据业务这个移动子领域中,商业模式发生了很大的变化。诺基亚的策略上没有苹果的策略合适,不是技术问题。
个人理解不应该拿来支持你的看法。

另外一个例子,synopsys的vip很多都是vera的,在大家看来太落后了,为什么还能存在?这是因为这些vip已经经过了大规模的验证,重写虽然可能提高效率甚至不用花费大量的时间开发,但是必须要重新花费大量的时间来验证vip本身的可靠性。所以这些vip从vera时代一直延续过vmm时代,最终到uvm终于无法适应了,只能重写。
LZ:这是你们自己的内部矛盾,按理我没有发言权。反证一下吧,但业界推出UVM来统一方法学,难道是推UVM的那帮人走路集体撞墙了,或者在集体梦游!业界大公司M明明发现VMM过渡不到UVM,还要硬推融合?
唉,都是我在给你们出主意,你们是什么公司啊?说得都有点不耐烦了!
有空请你们的leader多看看书和资料,去查查DAC2011的UVM主题,讲UVM中的tlm2的就是伯格龙老兄,synopsys公司的,实在不行请你们高层协调一下新思的资源,给你们制定一个转换路线。
路线大致说两句:vera是捐献给SV的,所以synopsys在VMM上特别用心(所有早一点推出来),从vera到vmm再到uvm,怎么可能走不通呢?UVM还要不要基于SV来开发了?
你说了这么多,除了证明你们的团队不思进取,我真看不出来还有什么内容!!!



所以说,技术上的革新都是被动的。革命在西方就是贬义词,大家更喜欢用进化,而进化本来就有被动适应的意思。
验证方法学只是一个手段,产品才是目的。对于pm来讲,最好是可以使用最简单的技术来完成任务。这就是工程和研究的区别!

LZ:请不要说一些似是而非的东西,我自认为想引导大家走向一个正确的职业道路,不希望象这种水平的来浑水摸鱼!

如果你的验证平台在设计freeze之后,每一周都能找出若干个bug,我想pm不会觉得你的工作有多出色而是对你的验证感到绝望。
LZ:很不好意思,pm是对你的工作感到绝望的,一个正规的验证过程的bug/时间曲线是个指数曲线,而不是你现在的状况!

我这里所说的验证可靠性,是指的是在流片之前pm有多大的信心来保证芯片回来是work的。
LZ:请不要越描越黑,我们是做技术的,说话要有依据。流片成功不是靠PM的信心,而靠科学地客观地设置一些流片条件来保证!合理而有效地设置这些条件,是PM应该因地制宜的或者坚定不移地执行的。回来能不能工作很大程度上依赖整个团队能否有效地执行PM设置的条件。

如果我的验证平台一个bug都没发现,但是我能保证所有的可能情况都测试过了,你能说这个验证平台不合格吗?
LZ:你还真会钻牛角尖!说句实话,帖子回到这基本上比较完整地了解了你的一个侧面。有一个感觉,你在验证原理和验证技术的学习方面没有形成系统观点,学习中思考量不够,特别是在基础理论上,可以预见你的知识体系相当零散,非常不幸的是,你用自己的臆想去填补了你知识体系中的空余部分,可惜非常遗憾的是,这些臆想绝大多数都是海市蜃楼!我对你的忠告在5年之内还绝对有效!!!
这样的问题我还是留给初学者思考吧,记住,这种问题在你学习验证理论的时候就应该解决,也就是说在你做学生的时候就应该解决了,可以看看这个问题问的方式,条件这么绝对,答案甚至不是选择题,你以为是本科生考试啊!
BTW:这个问题跟你们团队中的2个精通人士去讨论讨论,看看他们有什么看法吧!

楼主认为test case是testbench的一部分(看来你不是这样认为!而我认为除了DUT/DUV外,都是testbench,下面有人说的十年前的老书第一张图就表达了这个意思,你没有看出来,说你基础知识不到位不为过吧,OK!我孤陋寡闻了,你要不把你的理论基础说说吧?原创还是借鉴),我觉得你并没有理解vmm或者ovm的精髓(理由呢?理由呢?一句话就打发了,情何以堪!),。如果仔细研究vmm或者ovm,你就会发现,vmm/ovm花了很大的努力去把二者分开(My God!你把VMM/OVM也算验证平台的一部分了吧!要不把操作系统也算进testbench去算了,怎么说操作系统也是软件哪!CPU就不算了,毕竟是硬件,上面开个玩笑,回去看看OVM的白皮书,有个层次图,以你的起点一定会得到你的结论)。楼主说的大客户支持(CAE)里面的工程师是验证架构工程师,所谓验证架构就是开发testbench的人(不知道啊!我看干脆以后IC公司的BOSS给伯格龙他们发工资算了)。而且按照vmm或者ovm的理念,在testbench完成之后,需要改变的只是test case而不是testbench(你这个意见有没有和EDA的AE或者FAE交流过,如果是的话,把这个(些)AE和FAE的名字发给我,我们公司以后他们不用来了)。我们用oop技术去屏蔽验证平台的实现细节,只开放最顶层的部分给test case,就像操作系统向开发者提供api一样。我们把写test case的人看做是验证平台的用户。我们部门20多人精通验证的只有2个人,但是却可以同时支持3个全新项目的验证工作。而这两个人又在很短的时间内积累了3种不同应用的验证架构经验。如果testbench和test case由同一个人完成,那么当他用1个月的时间写完testbench之后,又要花费3个月去建test case来验证。如果很快有第二版出来,那么他又不得不重复上面的工作,试想在这种情况下,验证工程师除了对他所验证的模块更熟悉之外,在验证方法学上有学到了什么?更可悲的是,当他对设计熟悉到一定程度的时候,很可能会把他熟悉的这部分交给他设计,然后又找一个新人给他做验证,如此循环。你们组织的现状我可能需要花更长的时间去理解,感觉有几个问题:1)精通验证的人比例太少,我对团队成员的要求是所有人都通晓几个基础,但个人有所突出,有方法学源码精通的、有覆盖率精通的、有脚本精通的、还有其它方面,你们组织的形态很古怪,是历史原因还是人文原因?你是不是2人之一?2)简略解释一下platform、testbench和VIP的概念,假设testcase属于testbench,通过下面的解释,大家会知道为什么有这个属于关系,platform是基于语言和验证方法学而言,范围比后两者更广泛,testbench和VIP是在platform的基础上针对某个IC而言,但后两者有联系也又有区别,按照testbench的定义是完成DUV的输入和观察对应的输出(可选),那么testcase就是完成testbench工作的一个步骤,所以有这个归属关系,为什么说VIP和testbench有联系也有区别呢?我们说testbench一直没有说到RM,只有RM可以不属于testbench,讲到这里应该明白为什么platform的范围更广了吧!当然RM可以不存在,也可以很复杂,如果复杂到可以多个项目重用就快接近VIP了,当然这还不是一个完整意义上的VIP。VIP和testbench的这种我中有你,你中有我的特点决定了要复用,必须基于某个flatform来做,因为必须基于某个具体方法学和语言来做,现在不是十年前个人英雄的时代了,一个人可以从汇编一直做到界面,甚至硬件,基于平台来做可以做到事半功倍。3)现在可以讲讲OVM等等的意义了,方法学提供了一个使用语言的套路,具体讲应用方法学可以很快地搭建好testbench(这话不是我讲的是Mentor的人讲的!相关资料很好找,网上到处都是),使工程师可以尽快投入到RM的开发中,而RM的开发才是验证工程师需要重点投入的部分,如果是多项目的复用,那么RM的开发需要遵照VIP的方式来实现,这个过程当然需要精通验证的人来把握咯,呵呵,换做港台的讲法就是“拿捏”。最后我们来大致分析一下结合hover99的部门情况,只是我觉得很悲哀,有18个人在做可以简化、没有技术含量的工作,另外两个人基本上是神仙,包罗万象,无所不能是其次,还能身体力行地做到做完做好,证据是“我们部门20多人精通验证的只有2个人,但是却可以同时支持3个全新项目的验证工作。而这两个人又在很短的时间内积累了3种不同应用的验证架构经验”,顺便明码一下,能不能把那两人的电话给我,我给业界的朋友们推荐推荐!中国IC界太需要这样的人才了!,。
实际情况是,相当一部分验证工程师在工作1,2年后会转为设计,还有一部分会专注于写test case,对他们来讲debug是一个重要能力(话说回来,写RTL和debug自己的RTL都不是什么技术活(如果你维持这种观点的话,对你的忠告也没有什么意义!)。对于那些验证架构工程师来讲更重要的是用软件方式对testbench debug,两种debug根本就不是一回事。
LZ:说句实话我不想回复这部分内容,但为了防止半瓶水害人,也为了防止有人借此来评价我不了解技术细节,算了!好事就做到底了。
本来想写在整段下面,后来发现错误太多,一句一句写算了!这里最后总结一下为什么你错误这么多吗?
因为你开始就错了,开始就把test case和testbench分开看,所以你后来看所以的后续资料都带了个有色眼镜,最惨绝人寰的是,你在错误的轨道中,还不断地用错误的思路来强化错误,诸位围观者不要以为这会负负得正,只能是技术地狱再往下一层。
 楼主| 发表于 2011-7-3 13:02:21 | 显示全部楼层
本帖最后由 rhythm1988 于 2011-7-3 20:11 编辑

回复 12# hongjian77


很厌烦换马甲出来的行为,是谁我不猜了,但这是阴险小人的行径,只能让人鄙视你
对于这个回帖,我只会毫不留情!
这里把底线划在这里,注册马甲进行攻击的,一律BS加鄙视!
有能耐你就真刀实枪地站出来讲,总想躲在阴暗的角落,不是有健康心理的人的行径。
下次有类似情况,先问侯你家人!


一直在潜水,本帖虽然是验证漫谈,但是rhythm1988通篇只做了3件事:抱怨国内的环境
(I服了you,你用“抱怨”这个词QJ了所有做验证的人,很遗憾的是,也许是这个工作QJ了你,而不是我们所有人。
我写这个帖子,是为了有志于做好验证工作,进而可以有尊严地做个工程师的人提供一个思路。
只有那些整天躲在阴暗角落、苟延残喘的人才会用抱怨这个词!)
,重复10年一本老书的观点
( 这更好笑了,诸位这辈子学的书有几本小于十年的!或者你给大家指导一本新一些的验证基础的书,说说感想?敢不敢?)
,最后又崇拜了一下洋人。
(“崇拜洋人”,我还以为你是义和团呢?
自己从来都是得过且过,还妄想出来装B,装了还想高薪,天底下那有那么好的事情。
群众的眼睛是雪亮的,就你这点能耐,还敢站出来撒野!)
(我先问大家一个问题,所谓70%的工作量在验证上,有谁去认真统计或者找过资料来印证的,做过了的不妨举个手。这个提法大概就是97年提出来的,北电有位老兄在98年DAC,发表一篇论文是关于多芯片复杂协议系统的开发和验证的,其中说到了这个问题,起先他肯定也怀疑过,怎么办?就在项目中统计一下,所以文章中专门列了一个小节来说明统计了那些,结果是什么?说到这大家都可以猜的到结果。说这个往事的目的是希望大家对自己的职业生涯要严谨和认真,做个有自尊的工程师(人),不要信口开河,知道了一点,可以吹出一头大象来)
看到rhythm1988的团队成员居然看中文资料,我简直要喷饭了。我和同事都是中国人,但是我们写文档发工作mail都用英文,有时候需要用中文写文档反而写不出来。
(惭愧呀!惭愧!我们的团队只想站着当人,不想趴着当狗!只针对一个人!这话还能拿出来显摆,这不是阿Q吗!

仔细看了rhythm1988的回帖,确实有领导风范,就是说你不行,你的层次不够,具体那不行就要靠自己的慧根了,真是牛人!记得当年打cs的时候,大家都讨论那种枪厉害,突然有人说真正的牛人就是用匕首也能杀人,你们的讨论层次太低,于是被大家无比崇拜,结果打起来却发现水平so so。所以大家得到一个结论,要想做牛人,绝对不能展现出自己的实力,要说些似是而非的话,最重要的是要掩饰自己的观点。比如大家在讨论肉车的时候,明明你非常赞同,但是你也要说:没有肉车只有肉人。
(多年前我也玩CS,后来玩不动了,主要是费时间,体力也更不上了,其实大家都知道CS最吸引人的地方是团队,上面的说法也只能忽悠一下子猪头三而言,明眼人那能上这当啊,这个道理就像是江湖骗术,从古到今都有,为什么还常盛不衰,道理很简单猪头三不是年年都有,而是天天都有!

语言只是工具,vmm只是应用,这样一说,别人就不好意思问你这方面的问题了,即便是你一窍不通别人也无法察觉,对你只有仰视。rhythm1988从业10多年了,应该是管理层了吧。这些人对技术细节并不了解,也不屑于了解,不是说这些人水平低,而是说在这个层次的人关心的是flow和宏观问题。但是这些问题不是engineer关心的,flow追求的终极目标就是同样的任务任何人做出来效果都一样,记住体制中是培养不出牛人的。
(我一开始就说了我绝非牛人、高手!VMM/OVM可以很坦诚地和大家讲,我不是专家,专家是厂商的AE和FAE们。任何人有技术问题都可以和厂商联系,即使是没有厂商的学习者,比如:OVM可以上OVMworld去,是个开放论坛,其实Mentor和Cadence的那些专家特别喜欢回答问题,如果是有质量的问题,他们是绝对欢迎的,比如vi的做法就是先在OVM World中讨论出来,最后写到OVM COOKBOOK里去的。这就是心态开放的好处,三人行必有我师!当然问得都是文档和手册已经讲过的问题或者是一些初级问题,回答就不一定那么积极了,也许是让你再看看书或给个链接等
(既然说到本人的工作内容,就八卦一下。本人不是管理层,那不是兴趣所向,管理的工作繁琐,管理者是我沟通来投钱和投人的,其它的事情我一切帮他搞定的人,到时候就收结果的人,兴趣所在,没办法!
你对管理者和管理工作的理解太肤浅了,幼稚并可笑,不要以为你跟过几个废物点心,就好象看穿了世事一样。
我诚意地奉劝看过本帖的人士,把管理者看成是女(男)朋友,不是对立面,想想你和女(男)朋友还有个互相支持和体谅呢,和管理者不妨也这样。
管理者有其缺点,一定也有优点,人都是这样。这就像是找朋友,如果你实在是容忍对方的缺点,就天涯何处无芳草吧!如果你是个大帅哥,富二代,还怕没有女朋友,工程师的工作是类似的。
最可发一笑的是井底之蛙,总是流着口水,在YY!

不过看到下面hover99的帖子倒是觉得有些新意,特别注册一个id来谈谈我的观点。本人是designer,也懂一点vmm,不过我们soc的验证环境还是verilog的。以我的经验来看,bug往往出现在你认为不会出现bug的地方,让designer自己验自己的design,总觉得不靠谱。其次,hover99所说的只改testcase不该testbench,我觉得过于理想化了,假设设计要求增加错误检测功能需要driver产生error injection,这个时候除了改testbench还有别的方法吗?
(你这个马甲比hover99还差一些,error注入的问题,是要改testbench吗?有没有学过OOP,有没有学过设计模式?错误注入类总的思路采用工厂模式在testbench中调用的,还修改testbench?以你的经验来看,验证这两个字都不知道怎么写的,还来谈验证!
为了防止你还是无中生有,错误注入的问题可以多说两句,整个错误注入的策略是以工厂模式为基础,可能包括其它设计模式,动静结合的复合策略。如何实现好,可以算是一个验证平台实现的亮点!
这么基础的思路你都不了解,还敢说懂一点VMM,VMM的那本书很怀疑有没有认真看啊!
BTW:soc的验证环境是不是verilog或SV不重要,重要的是你们的人才是否能支撑达到验证的那些目的,如果你是Leader,很悬,具体原因看上面一个回复的内容)
发表于 2011-7-3 21:17:30 | 显示全部楼层
看牛人争吵,很有新意。
不过error injection确实不需要改动testbench。
发表于 2011-7-3 21:22:25 | 显示全部楼层
都是牛人啊!
发表于 2011-7-3 21:38:22 | 显示全部楼层
我已经说了我是designer,在验证上面你怎么挖苦我都无所谓。要不是我们的团队需要做正规的verification,我才懒得注册id呢,没那个闲工夫。hover99,我已经把我的联系方式短消息给你了。如果有兴趣可以和我联系。
vmm除了generator之外有工厂模式吗?我知道error injection可以通过callback来实现,但是事先没有加callback,如何来实现error injection。

没想到对楼主冷嘲热讽了一下,楼主居然气急败坏到要问候我的全家。还好楼主没啥权利,否则我恐怕还有灭门的危险。
发表于 2011-7-3 21:58:08 | 显示全部楼层
还是讨论问题本身吧。
VMM需要callback来实现才能实现error injection,OVM和UVM用factory 可以实现。
 楼主| 发表于 2011-7-3 22:25:57 | 显示全部楼层
本帖最后由 rhythm1988 于 2011-7-3 22:51 编辑

回复 17# hongjian77


   1)不要以为本人在design上就没有资格批评你,本人的设计生涯只比验证要长,是单纯的时间跨度,不是夹杂的时间段哦!要不你也写个设计体会,让我也冷嘲热讽一次,也做一次小人?很不好意思本人是跨界发展!
2)下面回答begineer001的问题也顺便帮你解个疑惑,让你占个便宜,因为你的人格我很鄙夷!
3)小人以退为进的风格不是没见过,哦!你说过很忙的,估计也没时间写设计体会了,又是我多情了。
 楼主| 发表于 2011-7-3 22:51:32 | 显示全部楼层
回复 18# beginner001


你已经到门口了,如果VMM是callback,而ovm是工厂,又没有人规定VMM只能在一个地方用工厂模式,那么你就把工厂套在VMM上面就行了,这就是平台的工作。
其实,VMM的错误注入就是工厂模式,callback只是实现手段而已,只是VMM的错误注入方式,包括OVM的工厂,我还嫌不够灵活,在目前的错误注入的基础上,已经对此进行了创新,在回马甲的帖子中已经写出来策略了,不具体讲,这是吃饭的家伙。已经指了路,有悟性的人只好自己去琢磨,抱歉!
BTW:
有个怀疑希望是错觉,hongjian77是不是你的马甲?因为你们都太关心错误注入的问题,而这个问题我说过了是平台的亮点部分,很考验设计平台人员的综合素质。
任何验证平台只要一天没有在错误注入上有突破,那永远是瘸腿的验证平台。
诸位有没有注意到几个方法学上,在错误注入上都没有说具体,老外也很鬼的,吃饭的家伙哦!

当然是不是马甲,都无所谓啦,我这个帖子是诺亚方舟,但也只给有缘人。
发表于 2011-7-3 23:29:32 | 显示全部楼层
讨论还蛮激烈的,好像每个人都说的有道理呢,可能只是出发的角度不一样哩,还在慢慢的摸索验证,讨论了才能出新意,让自己看到工作中暂时无法看到的一面,不管怎样,都是为了提高工作效率,完善验证工作。
很早以前刚刚入行的时候是想着未来能有个验证公司,专门做大公司的外包验证,可是自己能力一直都不够哎,讨论归讨论,没有错的也没有对的,有的只是实践中出的真理,是驴子是马拉出来溜溜,希望在众多的高手中能有人干的多点,开个自己的专门验证公司,到时候自然也就牛B了。
您需要登录后才可以回帖 登录 | 注册

本版积分规则

关闭

站长推荐 上一条 /1 下一条

小黑屋| 手机版| 关于我们| 联系我们| 在线咨询| 隐私声明| EETOP 创芯网
( 京ICP备:10050787号 京公网安备:11010502037710 )

GMT+8, 2024-11-5 21:49 , Processed in 0.028566 second(s), 7 queries , Gzip On, Redis On.

eetop公众号 创芯大讲堂 创芯人才网
快速回复 返回顶部 返回列表