完善资料让更多小伙伴认识你，还能领取20积分哦， 立即完善>
3天内不再提示
电子发烧友论坛|
我做部分可重构项目。
首先我用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 
0
|
|
相关推荐
3个回答
|
|
|
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 |
|
|
|
|
|
我自己没有使用部分重新配置，但在这种情况下似乎
真正的问题是找到足够的路由路径来完成路由。 通常当时间是问题时，路由器将被取消路由到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 |
|
|
|
|
|
的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. |
|
|
|
|
只有小组成员才能发言，加入小组>>
2384 浏览 7 评论
2800 浏览 4 评论
Spartan 3-AN时钟和VHDL让ISE合成时出现错误该怎么办？
2264 浏览 9 评论
3336 浏览 0 评论
如何在RTL或xilinx spartan fpga的约束文件中插入1.56ns延迟缓冲区？
2431 浏览 15 评论
有输入，但是LVDS_25的FPGA内部接收不到数据，为什么？
759浏览 1评论
请问vc707的电源线是如何连接的，我这边可能出现了缺失元件的情况导致无法供电
548浏览 1评论
求一块XILINX开发板KC705，VC707，KC105和KCU1500
371浏览 1评论
1966浏览 0评论
685浏览 0评论
/6 
关注我们的微信
下载发烧友APP
电子发烧友观察
版权所有 © 湖南华秋数字科技有限公司
电子发烧友 （电路图） 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证：合字B2-20210191
工商网监
湘ICP备2023018690号
1178
评论
淘帖
1236
