基于Xilinx FPGA用于ASIC前端验证的问题总结-FPGA本身是有专门的时钟cell的，以xilinx FPGA为例，就是primitive库中的BUFG。

本文是自己对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看上去没问题，但实践功用却不能确保。