赛灵思
直播中

曹光辉

7年用户 191经验值
私信 关注
[问答]

连接到planAhead以运行Map和PAR时会影响路由时间吗

我做部分可重构项目。
首先我用ISE写一些verilog。
将它们连接到planAhead以运行Map和PAR时。
它将花费大量时间来进行路由。
它最快需要38分钟。
有时它可能会在相同的代码中运行4~5个小时。
所以我想知道这个因素可能会影响路由时间。
当它运行很长时间。
它将在下面显示这些消息。
启动路由器
阶段1:153678未布线;
实时:1分10秒
阶段2:145352未布线;
实时:1分18秒
阶段3:85557未布线;
实时:2分6秒
阶段4:85557未布线;
(511183)实际时间:2分9秒
阶段5:131414未布线;
(80875)实际时间:29分钟43秒
阶段6:132351未布线;
(81631)实际时间:30分钟4秒
中级状态:未通过881;
实时:1小时21秒
中级状态:5未布线;
实时:1小时30分28秒
中级状态:6未布线;
实时:2小时35秒
中级状态:6未布线;
实时:2小时30分37秒
中级状态:2未布线;
实时:3小时45秒
中级状态:11未布线;
实时:3小时30分48秒
中级状态:4未布线;
实时:4小时54秒
阶段7:0未布线;
(184250)实际时间:4小时8分47秒
阶段8:0未布线;
(184250)实际时间:4小时9分4秒
将设计写入文件top_routed.ncd
启动RouterPhase 1:153678 unrouted;
实时:1分10秒
阶段2:145352未布线;
实时:1分18秒
阶段3:85557未布线;
实时:2分6秒
阶段4:85557未布线;
(511183)实际时间:2分9秒
阶段5:131414未布线;
(80875)实际时间:29分钟43秒
阶段6:132351未布线;
(81631)实际时间:30分钟4秒
中级状态:未通过881;
实时:1小时21秒中级状态:5未布线;
实时:1小时30分28秒
中级状态:6未布线;
实时:2小时35秒
中级状态:6未布线;
实时:2小时30分37秒
中级状态:2未布线;
实时:3小时45秒中级状态:11未布线;
实时:3小时30分48秒
中级状态:4未布线;
实时:4小时54秒
阶段7:0未布线;
(184250)实际时间:4小时8分47秒相分离8:0未通过;
(184250)实际时间:4小时9分4秒写作设计文件top_routed.ncd

以上来自于谷歌翻译


以下为原文

I do the partial reconfigurable project.
first i use ISE to write some verilog.
when join them to the planAhead to run the Map and PAR.
it will spend a lot of time to do the routing.
Its takes 38 minutes in fastest.
sometimes it may run 4~5 hours in the same code.
So i wonder know the factor might affect the routing time.

when  it run very long time.
It will show these message below.


Starting RouterPhase 1: 153678 unrouted;       REAL time: 1 mins 10 secs Phase 2: 145352 unrouted;       REAL time: 1 mins 18 secs Phase 3: 85557 unrouted;       REAL time: 2 mins 6 secs Phase 4: 85557 unrouted; (511183)      REAL time: 2 mins 9 secs Phase 5: 131414 unrouted; (80875)      REAL time: 29 mins 43 secs Phase 6: 132351 unrouted; (81631)      REAL time: 30 mins 4 secs   Intermediate status: 881 unrouted;       REAL time: 1 hrs 21 secs   Intermediate status: 5 unrouted;       REAL time: 1 hrs 30 mins 28 secs   Intermediate status: 6 unrouted;       REAL time: 2 hrs 35 secs   Intermediate status: 6 unrouted;       REAL time: 2 hrs 30 mins 37 secs   Intermediate status: 2 unrouted;       REAL time: 3 hrs 45 secs   Intermediate status: 11 unrouted;       REAL time: 3 hrs 30 mins 48 secs   Intermediate status: 4 unrouted;       REAL time: 4 hrs 54 secs Phase 7: 0 unrouted; (184250)      REAL time: 4 hrs 8 mins 47 secs Phase 8: 0 unrouted; (184250)      REAL time: 4 hrs 9 mins 4 secs Writing design to file top_routed.ncdStarting Router
Phase 1: 153678 unrouted;       REAL time: 1 mins 10 secsPhase 2: 145352 unrouted;       REAL time: 1 mins 18 secs Phase 3: 85557 unrouted;       REAL time: 2 mins 6 secs Phase 4: 85557 unrouted; (511183)      REAL time: 2 mins 9 secs Phase 5: 131414 unrouted; (80875)      REAL time: 29 mins 43 secs Phase 6: 132351 unrouted; (81631)      REAL time: 30 mins 4 secs   Intermediate status: 881 unrouted;       REAL time: 1 hrs 21 secs
  Intermediate status: 5 unrouted;       REAL time: 1 hrs 30 mins 28 secs   Intermediate status: 6 unrouted;       REAL time: 2 hrs 35 secs   Intermediate status: 6 unrouted;       REAL time: 2 hrs 30 mins 37 secs   Intermediate status: 2 unrouted;       REAL time: 3 hrs 45 secs
  Intermediate status: 11 unrouted;       REAL time: 3 hrs 30 mins 48 secs   Intermediate status: 4 unrouted;       REAL time: 4 hrs 54 secs Phase 7: 0 unrouted; (184250)      REAL time: 4 hrs 8 mins 47 secs
Phase 8: 0 unrouted; (184250)      REAL time: 4 hrs 9 mins 4 secs
Writing design to file top_routed.ncd

回帖(3)

潘晶燕

2018-10-10 11:14:15
N,
您的设计对时序有一些限制,可能只是一个简单的周期约束。
在硬件中,信号必须在时钟(设置)之前到达目的地并且在时钟之后持续(保持)。
每个连接都需要一个有限的时间来传播信号:路径太长(有太多的段)还是满足时序约束?
设计选择基于固定资源的放置,它不能移动,例如您希望使用的IO引脚。
然后它必须路由所有布线以满足周期约束。
它不能满足约束,它必须撕裂,移动,重新路由,并再试一次。
此过程可能会失败:您可能会将约束条件设置得太紧(如果没有更快的速度等级部件就无法满足,或者使用管道阶段修改设计等)。
这些工具也可能过于愚蠢,无法通过手动干预找到最佳路由和放置(请参阅下面的PlanAhead)。
消息显示您的进度。
如果删除任何.ucf(约束)并让工具选择IO引脚,只是放置和布线设计,忽略时序,它将运行得非常快。
设计越受限制,找到满足所有约束的布局和布线所需的时间就越长。
PlanAhead用于那些真正想要更快地满足其约束条件的人,以预先规划主要元素和IO引脚的位置。
将逻辑上的东西放在接近他们将要使用的东西上是有意义的,并且只有人类才能做到(HDL代码不告诉工具如何满足时序,只有设计工程师能够洞察这个问题
)。
Austin Lesea主要工程师Xilinx San Jose

以上来自于谷歌翻译


以下为原文

n,
 
Your design has some constraints for timing, probably just a simple period constraint.  In hardware, signals have to get to their destination ahead of the clock (setup) and last after the clock (hold).  Each connection takes a finite time to propagate the signal:  is the path too long (has too many segments) or does it meet the timing constraints?

The design chooses a placement based on fixed resources which it can not move, such as what IO pins you wish to use.  Then it has to route all the wiring to meet the period constraint.  It is can not meet the constraint, it has to rip up, move things, reroute, and try again.
 
This process may fail:  you may have the constraints too tight (can not be met without going to a faster speed grade part, or modifying your design by using pipeline stages, etc.).
 
It is also possible that the tools are just too stupid to find the optimal routing and placement without some manual intervention (see PlanAhead, below).

The messages show your progress.

If you remove any .ucf (constraints) and let the tools pick the IO pins, and just place and route the design, ignoring timing, it will run very fast.
 
The more constrained the design, the longer it will take to find a placement and routing that meets all constraints.
 
PlanAhead is used by those who really want to meet their constraints much more quickly to pre-plan the placement of major elements, and IO pins.  Placing things logically close to what they are going to use just makes sense, and is something that only human beings seem able to do (the HDL code doesn't tell the tool how to meet timing, only the design engineer has insight into that problem).
 
Austin Lesea
Principal Engineer
Xilinx San Jose
举报

杨玲

2018-10-10 11:24:55
我自己没有使用部分重新配置,但在这种情况下似乎
真正的问题是找到足够的路由路径来完成路由。
通常当时间是问题时,路由器将被取消路由到0
在30分钟之前很长时间(具有大的计时分数)。
我认为
它,部分配置需要一些相当严格的路由规则
在重新配置芯片的一部分时防止出现问题。
这个
绑定路由器的手甚至不仅仅是组件放置
单独。
问候,
的Gabor
-  Gabor

以上来自于谷歌翻译


以下为原文

I haven't played with partial reconfiguration myself, but it seems in this case
the real problem is finding enough routing paths to complete the route.
Usually when timing is the problem the router will get to the 0 unrouted
case (with a large timing score) long before 30 minutes.  As I understand
it, partial configuration requires some fairly strict routing rules to
prevent problems when re-configuring a portion of the chip.  This
ties the hands of the router even more than just component placement
alone.
 
Regards,
Gabor
-- Gabor
举报

张荷

2018-10-10 11:30:02
的Gabor,
是的,您已准确描述了该方案。
部分重配置流需要对路由资源进行限制,以确保设计的整个可重新配置部分完全包含在您定义的区域中。
这保证了硅在完成重新配置时的行为与预期一致。
虽然我们预计运行时间比扁平流量更长,以适应这些额外的检查,但是有一些像这样的异常值,我们预计会有更快的结果,我们已经在ISE 12.2中实现了改进。
谢谢,
大卫。

以上来自于谷歌翻译


以下为原文

Gabor,

Yes, you have described the scenario accurately.  Partial Reconfiguration flows require restrictions to the routing resources to ensure the entire reconfigurable portion of the design is fully contained in the region you have defined.  This guarantees that the silicon behaves as expected as reconfiguration is done.  While we expect the runtimes to be longer than flat flows to accommodate these additional checks, there are some outliers like this, for which we anticipate quicker results with improvements we have implemented in ISE 12.2.
 
thanks,
david.
举报

更多回帖

发帖
×
20
完善资料,
赚取积分