喜
我有这个大设计,我已经在
FPGA(virtex 6设备)上实现了。
其中一个设计时钟(clk xyz)需要运行@ 125MHz。
然而,实现该设计仅提供约88MHz。
我尽可能地限制了设计(无论我有什么关于虚假路径的信息)。
所以我使用SmartXplorer并以下列方式运行它 -
1)时序改进策略 - 12次运行 - 这将迭代各种MAP选项以获得最佳性能
- 这为时钟xyz提供了97MHz的最佳情况(使用MapLogicOpt策略)
2)仅在成本表上迭代 - 12次运行 - 尝试不同的PAR。
- 这为时钟xyz提供了104MHz的最佳情况
现在,当我在FPGA上尝试位文件时,104MHz位文件没有按预期工作。
但是97MHz位文件确实有效。
我的问题是 - 这可能是一个“侥幸”,即较慢的位文件正在工作,但不是一个时间更好的时间?
可能是它背后的原因,我在哪里可以看到它?
我可以在两次运行之间比较的任何文件?
将运行smartxplorer与成本表上的更多迭代有助于改善clk xys的时间?
如果我想从最好的smartxplorer运行其他实现运行的PAR,那么最好的方法是什么?
现在,我使用planahead并锁定BRAM实例(xilinx文档说像DSP,BRAMS,arith单元等锁定原语),这给了我ucf文件中新的loc约束。
然后,我在其他xilinx实现运行中使用这些约束来尝试在某种程度上保留PAR。
这是保留PAR的方法还是有更好的方法可以做到这一点?
我可以尝试使用smartxplorer来改善时序并使位文件更加可靠吗?
所有上述内容都在xilinx 14.1 ISE中。
以上来自于谷歌翻译
以下为原文
hi,
i have this BIG design which i have implemented on the fpga (a virtex 6 device).
one of the clocks of the design (clk xyz) needs to run @ 125MHz. however implemen
ting the design only gives about 88MHz. I have constrained the design the best I can (with whatever info I had regarding false paths etc.).
so i used SmartXplorer and ran it in the following manner -
1) timing improvement strategy - 12 runs - this would iterate through the various MAP options for best performance
-this gave a best case of 97MHz for clock xyz (using the MapLogicOpt strategy)
2) iterate only on cost table - 12 runs - to try different PAR.
-this gave a best case of 104MHz for clock xyz
Now when I tried the bit files on the FPGA, the 104MHz bit file did not work as expected. However the 97MHz bit file did work.
My question is - could this be a "fluke" i.e. a slower bit file is working but not the one with a slighlty better timing?
what could be the reasons behind it and where can i look to zero in on it? any files that i can compare between the two runs?
will running smartxplorer with more iterations on the cost table help improve the timing of clk xys?
If I want to retian the PAR from the best smartxplorer run for some other implementation run, what is the best way to do that?
for now, i use planahead and lock the BRAM instances (xilinx document says lock primitives like DSP, BRAMS, arith units etc.), which gives me new loc constraints in the ucf file. I then use these constraints in other xilinx implementation runs to try and retain the PAR to some extent. is this the way to retain PAR or is there some better method to do so?
any other things I can try with smartxplorer to improve timing and make the bit file more relaible?
all of the above in xilinx 14.1 ISE.