哦! Vivado 2016.1博文的笔迹还没干,2016.2版本已经出来了!
2016年的年初看到Vivado 2016.1的发布。从测试用户和开发者听到的,我们自然认为这将是比以前的版本更好。
在许多情况下,用户通常从单一的设计结果给出他们的意见:例如,Vivado 2015.x给你N个总负松弛(Total NegativeSlack TNS)或最坏的松弛(Worst Slack WS)的毫微秒ns。如果Vivado 2016.1给你一个更好的结果,新版本的性能更好,否则是相反的。一般的用户是根据此简单的反推结果所形成的意见,因为他们所需花的时间和担忧更多的是竟快完成项目,而不是去评估工具的真正效率。
我们Plunify扮演了(如热门电视剧里)流言终结者- 我们提问了“是否2016.1比2015.4更好”的问题。
我们的计划:使用InTime软件运行100编译配合多套不同InTime产生的综合和布局布线参数的设计,首先在2015.4,然后在2016.1。在这两个实验中的参数和设计源保持相同。
l 如果在2016.1有整体更好的效果,那么这个神话确认;
l 如果他们是稍好,或者如果只有特定时序方面是更好的,它被认为是可行的;
l 最后,如果结果是2016.1一般还要差,那么神话视为捣毁。
而结论是
...*击鼓*...
“确认”!
Vivado2016.1比2015.4更好!
(免责声明:我们只测试1个设计,详情如下)。
试验设计
设备:XCVU095-2FFVB2104
逻辑利用率:28.38%
目标时钟速度:290兆赫
测试总结及结果
| 2015.4 | 2016.1 |
TNS | 325.4ns | 324.67ns |
WS | 0.462ns | 0.456ns |
编译总数:100次
TNS的结果的75.95%在2016.1更好
在WS结果的63.29%在2016.1更好
这里显示的不同的图表。道理很明显2016.1(“2016”),产生更好的时序结果超过2015.4(“2015”)。
图1:时序结果VS不同的编译设置
有趣的结论是,虽然原来的结果与默认的综合和布局布线设置在2016.1略有改进,有效的采用InTime设置提供了重大改进,因此更有理由使用InTime!
有问题?
如果您有任何疑问,请随时与我们联系。如果你想贡献测试设计,我们甚至可以做到根据要求更多的测试。
现在到回到2016.2 ...
本帖最后由 plunify 于 2016-6-23 11:13 编辑