请教，fpga验证中的bug
verify环境下没有发现的问题在fpga上大量出现，一个一个确认下来基本都是RTL里面的
问题，目前基本上就是依赖于fpga发现bug然后一个一个解掉，整个模块一个主干数据通
路上的大feature改了两个多月了，fpga终于快要验稳定了，但是小弟心理极其担心，这
样的RTL流片后再asic上能正常工作吗，会不会有安全隐患，毕竟fpga没法发现所有的问
题。
这种在FPGA上出现的问题一般都是什么问题呀？
前端代码如果代码风格好的话一般不会出现FPGA上跑出问题来的呀
可以用nlint等之类的工具查看查看
问一个问题，你们在FPGA上发现的bug能在verification环境中复现吗？
fpga稳定问题不是太大，有问题也是隐藏很深的，看运气能不能发现了
不过关注下代码是否完全和asic一致
后面还有后仿，但是那只能检测很小一部分的问题
看你们的流程似乎验证工作做的不太好
验证方案，验证用例都是要仔细做好的
知道原因肯定能构造出来吧。。。
一般fpga出问题而且不好拖信号基本就只能猜了
尤其是性能上不去的时候。。。
大部分工作是写firmware的，之前使用其他供应商的SOC，以后陆续用公司自己的SOC了
，所以现在要和ic配合搞验证，代码porting等等一大堆事情
代码的话现在fpga和SOC在controller这个层次是一致的，只是phy不同，在fpga上发
现的问题基本上都是controller这个层面的RTL问题，有一部分后来ic通过仿真复现出来
了，还有一部分没有复现出来，通过fpga抓singal分析，然后看代码ic认定是RTL问题就
直接修复了，然后。。。。。。fpga就这样一步一步稳定下来了。。。。。。
验证工作做的不够
不过controller，如果不是数据流的逻辑，用形式验证是很好用的
我记得华为代码规范里面对断言还是有要求的
这主要是timing的问题吧,我们这玩意也是,纯仿真一点的问题都没有.FPGA上问题一大堆,最后全是timing的问题,FPGA上面的一些约束没有ASIC好实现,还有一些metastability,跨时钟域同步的玩意也得用CDC工具好好查查.
但是CDC这些个玩意最大的问题就是给你报个几千个错误,然后你看看是误报,然后就一屏一屏的waive,最后一不小心就把真的错误给放过去了
FPGA确实不如ASIC稳定，而且timing报告经常我感觉不准。。。
真不是楼上两位说的这个。。。timing的问题在最早phy连接稳定后就没有爆发了。。。
或许我应该描述更清楚一些，这个模块是买的，之前的基础版本在fpga上跑是ok的，已经
流过片了，下一代SOC规划的时候要在上层DMA这边加数据保护，把整个DMA这边的数据主
干通路动了一遍，最开始是想让供应商改的，结果价格没谈拢，然后ic就自己改了，然后
。。。ic还是仿真了几个case的。。。恩。。。然后就是各种的上层RTL错误。。。比如
计算，协议相关的各种bit置位。。。
另外请教一下各位：ic仿真的时候一般是通过多个case来做覆盖么？会不会跑stress稳
定性这类的东西
逻辑类，非数据流类的，可以考虑断言辅助验证，不过这个要买lic的，而且也要有高层领导用力推才能普遍起来，我知道的公司里面，改变习惯推行形式验证成功的好像就华为一个
还有你们可能验证做的太简单了，我们的研发流程我都感觉挺山寨的，不知道外面怎么做的，但即使这样，我们验证组的流程，验证环境，验证用例，验证规程和验证报告都是有详细文档要过的
只跑了几个case。。。。。。
定向的测试和随机测试都做完了才敢说这个没问题了吧。。。
你们的constraint random test 不过关。
另外，test plan有问题，肯定有漏洞。
如果是买的商业IP,FPGA verification不应该有什么问题，除了performance上不去。而且，SOC级的FPGA验证，重点也不应该在IP,而是系统架构，连接，以及driver
你现在的情况，肯定是在验证IP。严格点说，是在debug IP。因为IP在RTL阶段没有验证充分，就直接上FPGA了。这种情况发现的bug，在RTL仿真也许能够重现，但是花费的代价也许很大。如果公司自身的验证比较山寨，RTL之后的仿真肯定不充分，然后就直接仍给FPGA了。这种情况下，design肯定比你强势了。你只能发现问题就给他打电话，把他叫来拉线或者跑仿真。当然，有的问题也许不是bug，是你对user guide理解的不够充分。
是啊，fpga目的就是功能验证和软件调试，发现bug很正常，所以要软硬件协同调试
eda验证不充分。问一下，你们fpga发现的问题，有没有体现在验证人员的测试点表单里？我现在做的项目大部分bug都在eda的block级验证中排掉了，fpga发现的rtl问题不多。
ic和sw之间的协作还是