本文是本人对Xilinx XC7V系列FPGA用于ASIC前端验证遇到问题的为自己记录并分享给大家，如果有歧义或错误请大家在评论里指出。
将FPGA用于ASIC验证和实现传统RTL设计的主要区别就是ASIC会根据应用场景有大量的门控时钟（clokc gate）和电源开关（power gate），其中power gate不需要在FPGA上实现并且也无法实现，是来源与IP供应商或foundry提供的基本库文件，属于不可综合的类型，前端仿真会有对应的仿真model，当然这个model也不能在FPGA上实现。clock gate即门控时钟也有对应的仿真model，并且稍加修改就可以综合并在FPGA上实现。
FPGA本身是有专门的时钟cell的，以xilinx FPGA为例，就是primitive库中的BUFG。当使用BUFG时，FPGA tool是能保证时钟树到各个Flip-Flop的时钟输入端C的路径相对等长，这能有效保证Clk_skew在一个合理的值内，所以进行“综合——优化——布局——布线”的流程时，基本不会出现hold volation的问题，我们只需要重点解决setup volation的问题就行了。BUFG资源在xilinx FPGA上有限且宝贵，所以传统FPGA设计都要求避免门控时钟的代码，并且对时钟域的划分要非常清晰干净，尽可能的让整个设计工作在同步时钟，这会有利于timing的收敛。
但是当FPGA用来实现ASIC的验证时，门控时钟就是不可避免的，比如ASIC上电复位时，不是所有的逻辑都同时工作起来，即只有一部分Flip-Flop开始工作，很大一部分可能根本没有收到有效的时钟，这种情况符合ASIC上电boot的流程，所以在FPGA上验证时要保留的；再比如ASIC工作在某一场景下需要降低功耗，会关闭某个Module的时钟，这种为了降低功耗功能而存在的clock gate就可以直接优化掉，并不会影响FPGA验证ASIC的功能。所以在拿到ASIC RTL后要先将这种可以优化掉的clock gate挑拣出来并处理，再对处理后的RTL进行综合，查看各种资源的使用情况是否合理，LUT，FF，RAM等资源只要不超过FPGA容量限制就没问题，当然在使用率特别高的情况下，会造成后面P&R速度慢并且有失败的风险，可以酌情对RTL进行剪裁。BUFG的使用情况就要重点检查了，XC7V系列的FPGA单片BUFG不超过32个，而XC7V2000T这种多Die的FPGA会有32x4个BUFG，但BUFG的使用是越少越好，当BUFG使用特别多时，在place时就有可能报错了，各种时钟之间的关系也要逐个分析，都是跨时钟域问题。
当BUFG使用量很多时，在综合完优化前就可以把工程停住了，用vivado打开dcp文件搜索所有BUFG例化的地方，人为增加的MMCM这种IP消耗掉的BUFG可以不管，综合产生的BUFG要逐个检查，并且掉过头来修改原始的时序约束文件，对每一个BUFG的输出O增加generated_clock的约束，并找到source clock，我的经验是这个时候还不要对跨时钟域进行约束处理，这样vivado的分析工具会认为每两个时钟之间都是有关系的，在报告中都会分析setup和hold。在vivado里source修改后的时序约束文件，进行第一轮的P&R，在布线完成之后report_timing_summary命令得到整个design的时序检查报告，在这个timing报告里会详细列出你定义的所有时钟，各个时钟的关系，intra报告和inter报告：
1. 其中intra报告是单时钟内部的setup和hold问题，通常只会有setup问题，如果有hold问题，你就要检查你的clock代码是不是用错了BUFG，从而导致clock skew太大，当有setup问题时可以看下critical path，如果logic level层数是合理的，但data path延时却很大，造成了setup无法满足，就要打开vivado的版图工具，找到明显不合理的走线，如果某两个LUT之间的空间位置很近，走线延时却很大，比如超过2ns，那这个走线很有可能进行了多余的绕线，当然这是route工具自己实现的，这个绕线的目的可能是因为这条path还存在于另外一个时钟timing约束里，有可能就是跨时钟域的情况，所以可以先不管这种setup的violation，但如果logic level本身就很大，比如已经超过了60，但你这条path的clock却要求跑到80M，那这很难满足要求了，要掉过头来去看RTL的问题，最好是对RTL进行修改，增加打拍；
2. 而inter报告则显示了所有的跨时钟域问题，通常第一轮P&R得到的inter报告timing violation会很惨，不用每一条path都去看，但每两个报出violation的时钟都要看，可以只看violation最严重的那条path，先检查工具要求的setup时间是不是合理，因为我们还没有对这两个时钟加约束，所以这里的检查是最严格的的，工具就会按照时钟推移，找到延时最小的两个上升沿来检查setup问题，如果这个延时目标不合理咱们就可以增加multicycle的约束，这个延时目标很可能非常小，只有几ns。
根据上面这第一轮的报告再次修改时序约束文件，对有相关性的时钟增加clock group约束，通常每一个group都包含source clokc和由generated的所有clock，在上面报告中有跨时钟域路径的时钟也要放到同一个group里，不同的group就可以是async关系了。再对上面报告中发现目标延时不合理路径时钟增加clock multisysle约束，增加1个clock的setup约束，同时hold检查的沿保持不变，这里的写法可以根据xilinx的constraint约束指导文档来写，是从快的时钟进入慢的时钟，另是从慢的时钟进入快的时钟，这两种情况写法不一样。
还有个问题要注意，在解决单一时钟的setup violation问题时，要慎重使用multicycle约束，首先是RTL功能确实是采用了multicycle，我们才能增加这种约束，否则虽然让timing看上去没问题，但实际功能却不能保证。
