又收到一个刚刚通过语法检查的验证项目

.................................

通过语法检查..............

我经常拿到还没通过语法检查甚至只完成部分功能设计的代码的验证任务，为了赶项目进度，小编你知足吧

知足吧，没让你“裸奔”已经不错了

testbench的悲哀啊》。

哈哈，听起来真的是悲哀啊

恩是啊 都挺悲剧的啊

国内大都这样！

那做设计的不是很轻松?

这种事还真是大材小用啊

fgfdg dsf gdfgdf

悲剧啊，拒绝接收

流程不对都这样啊

验证和设计就是并行的呀. 他通过了语法检测说明你能编译通过了, 当然要给你让你先搭验证环境.
我最喜欢这样的人了, 我可以提很多的bug, 很有成就感....哈哈哈

十分正常，也十分合理，甚至有的时候rtl还没完成，testbech已经ready了。
designer要自己搭testbench的话，要验证工程师做什么，重复劳动?
有的项目，rtl写完了，自己写的testbench已经开始跑corner case了，验证平台还没有完，甚至还需要designer去帮忙debug testbench。这种项目流程才是失败！

回复楼上，像你这么想的designer或者manager可能挺多的。
但是我认为这是不对的。
你这种想法是完全从designer的角度考虑问题，而非从团队的角度，更不要提考虑验证人员的效率了。
这样做的结果是designer的schedule很好看，验证的时间很长。
designer做 basic function debug的时候，验证人员的时间就浪费掉了。
验证的效果呢，因为schedule压力，coverage，corner case等等就要减低标准了。

回复楼上，像你这么想的designer或者manager可能挺多的。
但是我认为这是不对的。
你这种想法是完全从designer的角度考虑问题，而非从团队的角度，更不要提考虑验证人员的效率了。
这样做的结果是designer的schedule很好看，验证的时间很长。
designer做 basic function debug的时候，验证人员的时间就浪费掉了。
验证的效果呢，因为schedule压力，coverage，corner case等等就要减低标准了。

回复楼上，像你这么想的designer或者manager可能挺多的。
但是我认为这是不对的。
你这种想法是完全从designer的角度考虑问题，而非从团队的角度，更不要提考虑验证人员的效率了。
这样做的结果是designer的schedule很好看，验证的时间很长。
designer做 basic function debug的时候，验证人员的时间就浪费掉了。
验证的效果呢，因为schedule压力，coverage，corner case等等就要减低标准了。

不错啦，都通过语法错误啦，如果你是专门做验证的，这个也是你的责任和义务了，
毕竟不管设计有木有做充分的自测，检查bug还是验证的主要任务。
态度决定一切

同情小编。