悲剧了，要做eco。。。

不是这意思，就是不改了。。。
加法器少1bit位宽这个无解啊。。。

这个bug难度不小啊，为啥到P&R搞定的时候RTL还没验证完？

交给新人做的独立功能，有些地方他自己也不清楚
就是本来取值是最大128，但是只留了7bits因为他以为是到127
然后去做加减法

我算是服了你了
你作为他的Mentor，
这个边界效应肯定要做Cover
无论设计，验证做的都不到位，功能也许做过验证，
但是边界Cover就是自己造Case都要考虑的~

rtl freeze之前没做rtl QA吗？
芯片质量是靠flow各个环节保证的，不要把宝都压在验证上面。

他这个问题完完全全就是验证问题
和后端没关系

从哪看出来我说后端了？
真要说问题，design，verification各50%吧

问题当然是design引起的
但verification的目的就是发现design的问题，它的前提就是假设design是有问题的
像楼上的这样问题没有发现我觉得就是verif的问题
在一个team里，如果真要追究责任的话，就是verifer的全责

不知道你们公司给做verification多少钱，整个chip的成败全看DV team的。
如果是这样的，只能说你们老板胆儿挺大，懂IC flow的人不会这么干，
一个产品质量的好坏，不是靠一个环节去保证，是靠流程，制度。

就这事来说，我估计楼主公司前端设计没有做lint,
是人都会出错，工具帮忙check会靠谱的多，如果flow里没有这步，这种问题还会发生。

哎不谈这个了，我反正扛下来了，现在没动加法器在外围做了些近似
做这块开发和验证的都是新人
有些地方的细节他们到最近才知道是这么回事
部分文档管控的有点严格，其实是有权限的但是没有特别宣贯某些条目
所以做的时候没考虑到的话什么工具都没法检查到

我们这逻辑核心是个累加器，还有很多其他逻辑，不好改，在输入那边动动得了

关键是plan是谁制定的，谁验收的。
设计者的superviser也要付责任，128是一个不寻常的边界，在rtl review的时候应该特别检查的。
验证工程师只会对列出来需要cover的feature负责。