完善资料让更多小伙伴认识你,还能领取20积分哦, 立即完善>
扫一扫,分享给好友
最近我们将项目从2015.4版本移至2018.2版,我们对2018.2与2015年相比给出的糟糕结果感到震惊。
2018.2的实施时间增加了约6倍 所以实施时间: 2015.4:00:19:56 2018.2:01:52:06 我们使用相同的条件,即相同的策略,相同的机器,相同的设计,相同的IP。 并且这些工具在具有相同螺纹量的同一台机器上并行运行。 没有其他资源使用我们的机器,只有这2个vivados。 比我们检查的时间,2018.2的结果稍好一些。 WNS: 2015.4:-4.638 2018.2:-4.777 TNS: 2015.4:-1703.105 2018.2:-548.562 WNS: 2015.4:-0.064 2018.2L -0.052 资源利用率: 2018.2 -------- LUT 22024 134600 16.362555 LUTRAM 4441 46200 9.612555 FF 33019 269200 12.265602 BRAM 277.5 365 76.0274 IO 186 400 46.5 MMCM 2 10 20.0 PLL 1 10 10.0 2015.4 -------- LUT 23818 134600 17.695395 LUTRAM 4443 46200 9.616883 FF 31999 269200 11.886701 BRAM 278 365 76.16438 IO 220 400 55.0 BUFG 18 32 56.25 MMCM 2 10 20.0 PLL 1 10 10.0 如果你看到非常小的,几乎可以忽略不计的好处。 有人可以解释一下这有可能吗? 就像我们更新了近3年的旧工具版本,并使用新工具获得了更糟糕的结果。 这是预期的吗? 附: 2018.2有内部文本编辑器的问题,当我们修改工具外的代码时,工具有时文本编辑器无法识别我们的编辑。 以上来自于谷歌翻译 以下为原文 Recently we moved our project from 2015.4 version to 2018.2 and we were really shocked with the bad results that 2018.2 gives in comparison to 2015.4. The implementation time of 2018.2 increased around 6 times So Implementation time: 2015.4 : 00:19:56 2018.2: 01:52:06 We used the same conditions i.e. same strategy, same machine, same design, same IPs. And the tools were run in parallel on same machine with same amount of threads. No other resource was using our machine, only these 2 vivados. Than we checked the timing, slightly better results for 2018.2. WNS: 2015.4: -4.638 2018.2: -4.777 TNS: 2015.4: -1703.105 2018.2: -548.562 WNS: 2015.4: -0.064 2018.2L -0.052 Than resource utilization: 2018.2 -------- LUT 22024 134600 16.362555 LUTRAM 4441 46200 9.612555 FF 33019 269200 12.265602 BRAM 277.5 365 76.0274 IO 186 400 46.5 MMCM 2 10 20.0 PLL 1 10 10.0 2015.4 -------- LUT 23818 134600 17.695395 LUTRAM 4443 46200 9.616883 FF 31999 269200 11.886701 BRAM 278 365 76.16438 IO 220 400 55.0 BUFG 18 32 56.25 MMCM 2 10 20.0 PLL 1 10 10.0 If you see very small, almost negligible benefit. Can someone please explain how is this possible? Like we updated almost 3 years older tool version and got worse results with the new tool. Is it expected? P.S. 2018.2 has issue with internal text editor, when we modify the code outside of tool, the tool sometimes text-editor does not recognize our edits. |
|
相关推荐
5个回答
|
|
为什么两个设计使用不同数量的I / O引脚?
我能相信的任何其他东西,但缺少I / O引脚意味着某些事情非常混乱。 时间结果在很大程度上是无关紧要的 - 两种工具在满足时序(或决定它们无法满足时序)之前工作,然后停止。 如果必要的话,其中一个人很可能已经满足了更严格的时间要求,但事实上两者都符合时间并没有真正告诉我们任何事情。 除此之外,这只是实施吗? 或者你也重新运行合成? 在我看来,如果您在Vivado 2018.2中打开Vivado 2015.4项目并立即运行实施,它可能会决定首先重新运行合成 - 这可能很容易占用大量时间。 以上来自于谷歌翻译 以下为原文 Why are your two designs using different numbers of I/O pins? Anything else I can believe, but missing I/O pins means that something is very messed-up. The timing results are largely irrelevant - both tools work until they meet timing (or decide that they cannot meet timing) and then stop. It's quite possible that one of them could have met tighter timing requirements if it had to, but the fact that both did meet timing doesn't really tell us anything. Apart from that, was this just implementation? Or did you re-run synthesis too? It occurs to me that if you opened a Vivado 2015.4 project in Vivado 2018.2 and run implementation immediately, it might decide to re-run synthesis first - which could easily account for a lot of time. |
|
|
|
你提到的文本编辑器问题,
有可能不同的文件在不同的机器上有不同的时钟/时间吗? 我没有看到它与编辑器,但vivado的其他部分这似乎是一个功能, 确保所有文件所在的机器和运行vivado的机器都锁定在同一时间主机上 以上来自于谷歌翻译 以下为原文 re the text editor problem you mention, is it possible different files are on different machines with different clock / times ? Ive not seen it with the editor, but other parts of vivado this seems to be a feature, ensure all your machines where files are located and you run vivado on are locked to the same time master |
|
|
|
关于IO,真的很奇怪。
还在调试 我重新运行综合而不是实现 以上来自于谷歌翻译 以下为原文 Regarding to IOs, really strange. Still debugging I re-run synthesis and than implementation |
|
|
|
|
|
|
|
由于这种设计似乎是失败的时间安排,可能是旧的版本只是早些时候放弃了,而较新版本试图更难以满足时机要求。
你似乎两次报告WNS - 你能解释一下这里的区别 - 是一个保持松弛吗? 无论哪种方式,都值得重新运行设计,其中实际上可以满足时间,因为这提供了更真实的运行时视图。 以上来自于谷歌翻译 以下为原文 As this design appears to be failing timing, it may be that the older release simply gave up earlier while the newer release tried much harder to meet timing. You seem to report WNS twice - can you explain the difference here - is one the hold slack? Either way, it would be worth re running with a design where the timing can actually be met as that gives a much more realistic view of actual runtime. |
|
|
|
只有小组成员才能发言,加入小组>>
2384 浏览 7 评论
2800 浏览 4 评论
Spartan 3-AN时钟和VHDL让ISE合成时出现错误该怎么办?
2264 浏览 9 评论
3336 浏览 0 评论
如何在RTL或xilinx spartan fpga的约束文件中插入1.56ns延迟缓冲区?
2431 浏览 15 评论
有输入,但是LVDS_25的FPGA内部接收不到数据,为什么?
757浏览 1评论
请问vc707的电源线是如何连接的,我这边可能出现了缺失元件的情况导致无法供电
547浏览 1评论
求一块XILINX开发板KC705,VC707,KC105和KCU1500
369浏览 1评论
1965浏览 0评论
684浏览 0评论
小黑屋| 手机版| Archiver| 电子发烧友 ( 湘ICP备2023018690号 )
GMT+8, 2024-11-25 10:19 , Processed in 1.361914 second(s), Total 85, Slave 68 queries .
Powered by 电子发烧友网
© 2015 bbs.elecfans.com
关注我们的微信
下载发烧友APP
电子发烧友观察
版权所有 © 湖南华秋数字科技有限公司
电子发烧友 (电路图) 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证:合字B2-20210191 工商网监 湘ICP备2023018690号