博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
DV 以后的路
阅读量:6205 次
发布时间:2019-06-21

本文共 2245 字,大约阅读时间需要 7 分钟。

<一代宗师> 里, 宫二对叶问说'拳不能只有眼前路,没有身后身', 从字面上来看,这只是拳术之间的交流。咏春切中路,所以看到的都是眼前路,八卦掌擅迂回,所以还要看到身后的招式变化。推进一层,这应当是宫二对自己的感慨,还有对叶问的劝告:学武的,不能只自己追寻,更要推己及人,留下后人。

那DV呢??   在技术做到一定阶段之后, 总还是有需要提升的空间; 就像古时打仗的士兵, 利刃虽然可以上场杀敌, 但在无战事的时候还是要继续将刀磨的更锋利, 一为更快的杀敌致胜, 二为更加快捷的直指敌人心脏..

我现在就需要将这把刀打磨的更加适用.. 适用不只是对今天战场上的敌人, 还包括明天对未知的猛兽..

为了将刀打磨的更好, 首先还是仔细的看下这把刀目前的状况.. 

 这篇博文里, 记录了目前DV team 在Question, Solution 以及 Process Management 方面的涉猎;

广度上参考对比project execution control table. 可以看到, control table中额外包含了下面各项: PDCA, project release环境搭建, regression, Netlist simulation, Performance 评估, CoSim等.. 其中, PDCA由DV coordinator 来做, 目前有toggle到; regression 的话目前正在建立DV QA flow, 里面会自带定期regression 及report 机制, 所以这部分不成问题; Netlist Simulation ENV的搭建比较多的需要design 的背景, 目前尚未toggle 到; Performance 评估这一块会被系统Bus结构的验证cover到; CoSim 的cowork model中, DV更多负责的是环境搭建的部分, 已经cover到, 实际case的trial run, 本来就应该是SW的责任...  所以, 剩下来的就是project 执行最为基本的一个步骤: project release 环境的搭建, 这部分由于代码加密的原因, 更多是由本部同仁负责, 但可以请同仁Z 去看下..  同时, 配合IC SB 之后的PDCA, 有在持续的对这个control table item 做enhance, 所以应付目前的project DV来说, 前面博文里面所说的已经够完整了...  

深度上主要考量的是, 目前这些做法是否真正挖掘到了项目中的各种各样的问题??  透过数十个project IC SB 之后的SW测试来看, 目前这些DV topic 的确有挖掘到沟深的问题; 同时, 对比DV与SW 抓到的RTL issue 种类与数量,也可以看出, 只要某个部分有DV 涉及, 那么即使出问题也是designer与DV错到一起了; 反而更容易出问题的是那些DV没有涉及到的问题点, 比如debug电路, 比如一些clock connection 等等.  这应该是广度上, 对project 需要验证的item 的完整分析, 这的确是一个问题.. 同时, 即使很多部分的DV深度做的够深, 但一颗老鼠屎坏一锅汤, 所以需要保证所有DV交付的quality, 这说明流程管理的东西需要持续深入下去..

通过对广度和深度的分析可以看到, 有几个点需要深化:

 

  • project release 环境搭建的部分需要了解,, 这样整个DV就形成闭环了..
  • 如何更完整的对project 需要验证的item 做分析, 确保每个点均有pattern cover到足够深??
  • 如何确保DV交付的quality, 特别是, 流程上如何确保??

第一点很简单, 根据目前的某个project, 去了解即可..

 

第三点目前正在推一下IPCRV的flow, 包含QA flow 等, 配合充分的DV Plan review 以及regression 机制, coverage review 机制, 适当的code review 机制, 应该可以确保不出现大的偏差..

第二点会是一个比较麻烦的点.. 可以从两方面入手: 

 

  1. 根据一系列的IC SB 之后的验证, 对目前的做法做PDCA, enhance 目前的做法, 这也是一直在做的
  2. 找到whole chip上需要验证的具体点, 开发更适合whole chip 验证的方法,  这也许是后面需要着重考虑的.

whole chip 上具体点 及验证方法的分析,, 其实应该有一个更宏观的分析, 这刚好就是那个UVM whole chip DV 文档所涵盖的范围... 所以, 后续也许要对这个点进行猛攻.. 而且, 从block 到system 建立统一的环境, 建立统一的checking机制, 将目前涉及到的零散的方法揉合到一个统一方法里面, 而且这个统一的方法能更加直接的暴露出各个验证阶段所需要解决的问题,,, 想想这个前景就觉得美好..

@2016.6.7: 与另外两位资深同仁讨论, 确定要做这件事的决心; 分头下来sync 各自手头的resource

@2016.6.8: 确认SW, NJ, K 会join 进来这个topic, 由SW来统领大家进行...

 

转载于:https://www.cnblogs.com/uestckui/p/DV_future_road.html

你可能感兴趣的文章
谈Find指令
查看>>
c/c++多参数的问题
查看>>
android软键盘上推ui解决
查看>>
WPR-007:WPF中窗体的透明设置
查看>>
error: Refusing toundefine while domain managed save image exists
查看>>
wordpress在新窗口打开留言者链接
查看>>
DataUml Design 介绍8-DataUML 1.2版本正式发布
查看>>
我的友情链接
查看>>
mysql主从复制
查看>>
Linux下压缩某个文件夹(文件夹打包)
查看>>
理解Lucene/Solr的缓存
查看>>
java开发过程中的命名规范
查看>>
一夜暴富之前的漫漫长路
查看>>
Oracle EXP/IMP参数详解
查看>>
PHP 正则表达式分割 preg_split 与 split 函数
查看>>
windows清理剪切板
查看>>
mysql索引随记
查看>>
在Brackets中使用jsHint遇到的问题
查看>>
freemarker 分页逻辑
查看>>
关于Pac-Man,你所要了解的 一切
查看>>