完善资料让更多小伙伴认识你，还能领取20积分哦， 立即完善>
3天内不再提示
电子发烧友论坛
1992
|
大家好，
我在这里发出警告说我无法解决。 当出现此警告时，PAR会花费额外的时间来解决它，这使得我的实现非常耗时。 这是警告信息： 警告：路由：466 - 在324个连接中检测到异常高的保持时间违规。 前20个这样的实例打印在下面。 路由器将继续并尝试修复itU_inner_logic / U_qdr_ctl0 / c0_qdr_wr_dat：DQ - > U_qdrii_sramc / c0_u_user_top / u_qdr_phy_top / u_phy_write_top / u_phy_write_data / iob_data_rise1：DX -3031U_inner_logic / U_qdr_ctl0 / c0_qdr_wr_dat：BQ - > U_qdrii_sramc / c0_u_user_top / u_qdr_phy_top / u_phy_write_top / u_phy_write_data / iob_data_rise1：BX -3031U_inner_logic / U_qdr_ctl0 / c0_qdr_wr_dat：CQ - > U_qdrii_sramc / c0_u_user_top / u_qdr_phy_top / u_phy_write_top / u_phy_write_data / iob_data_rise1：CX -3017U_inner_logic / U_qdr_ctl0 / c0_qdr_wr_dat：BQ - > U_qdrii_sramc / c0_u_user_top / u_qdr_phy_top / u_phy_write_top / u_phy_write_data / iob_data_rise1：BX - 3015U_inner_logic / U_qdr_ctl0 / c0_qdr_wr_dat：CQ - > U_qdrii_sramc / c0_u_user_top / u_qdr_phy_top / u_phy_write_top / u_phy_write_data / iob_data_fall0：CX -3014U_inner_logic / U_qdr_ctl0 / c0_qdr_wr_dat：AQ - > U_qdrii_sramc / c0_u_user_top / u_qdr_phy_top / u_phy_write_top / u_phy_write_data / iob_data_rise1：AX -3014U_inner_logic / U_qdr_ctl0 / c0_qdr_wr_dat：DQ - > U_qdrii_sramc / c0_u_user_top / u_qdr_phy_top / u_phy_write_top / u_ph y_write_data / iob_data_rise1：DX -3013U_inner_logic / U_qdr_ctl0 / c0_qdr_wr_dat：BQ - > U_qdrii_sramc / c0_u_user_top / u_qdr_phy_top / u_phy_write_top / u_phy_write_data / iob_data_fall0：BX -3012U_inner_logic / U_qdr_ctl0 / c0_qdr_wr_dat：AQ - > U_qdrii_sramc / c0_u_user_top / u_qdr_phy_top / u_phy_write_top / u_phy_write_data / iob_data_fall0： AX -3011U_inner_logic / U_qdr_ctl0 / c0_qdr_wr_dat：DQ - > U_qdrii_sramc / c0_u_user_top / u_qdr_phy_top / u_phy_write_top / u_phy_write_data / iob_data_fall0：DX -3010U_inner_logic / U_qdr_ctl0 / c0_qdr_wr_dat：DQ - > U_qdrii_sramc / c0_u_user_top / u_qdr_phy_top / u_phy_write_top / u_phy_write_data / iob_data_rise1：DX -2995U_inner_logic / U_qdr_ctl0 / c0_qdr_wr_dat：BQ - > U_qdrii_sramc / c0_u_user_top / u_qdr_phy_top / u_phy_write_top / u_phy_write_data / iob_data_rise1：BX -2995U_inner_logic / U_qdr_ctl0 / c0_qdr_rd_adr：CQ - > U_qdrii_sramc / c0_u_user_top / u_qdr_phy_top / u_phy_write_top / u_phy_write_control / iob_addr_fall0：C5 -2956U_inner_logic / U_qdr_ctl0 / c0_qdr_wr_dat： DQ - > U_qdrii_sramc / c0_u_user_top / u_qdr_phy_top / u_phy_write_top / u_phy_w rite_data / mux_data_fall1_2r_27_BRB1：AX -2956U_inner_logic / U_qdr_ctl0 / c0_qdr_wr_dat：AQ - > U_qdrii_sramc / c0_u_user_top / u_qdr_phy_top / u_phy_write_top / u_phy_write_data / mux_data_fall1_2r_28_BRB1：AX -2955U_inner_logic / U_qdr_ctl0 / c0_qdr_rd_adr：CQ - > U_qdrii_sramc / c0_u_user_top / u_qdr_phy_top / u_phy_write_top / u_phy_write_control / iob_addr_fall0： C5 -2954U_inner_logic / U_qdr_ctl0 / c0_qdr_rd_adr：AQ - > U_qdrii_sramc / c0_u_user_top / u_qdr_phy_top / u_phy_write_top / u_phy_write_control / iob_addr_fall0：A5 -2950U_inner_logic / U_qdr_ctl0 / c0_qdr_wr_dat：AQ - > U_qdrii_sramc / c0_u_user_top / u_qdr_phy_top / u_phy_write_top / u_phy_write_data / iob_data_rise1：AX -2950U_inner_logic / U_qdr_ctl0 / c0_qdr_wr_dat：DQ - > U_qdrii_sramc / c0_u_user_top / u_qdr_phy_top / u_phy_write_top / u_phy_write_data / iob_data_fall0：DX -2943U_inner_logic / U_qdr_ctl0 / c0_qdr_wr_dat：AQ - > U_qdrii_sramc / c0_u_user_top / u_qdr_phy_top / u_phy_write_top / u_phy_write_data / iob_data_fall0：AX -2943 我该怎么做才能解决这个问题？ 谢谢。 以上来自于谷歌翻译 以下为原文 Hi all, I have a warning here that I can't fix. When this warning shows up, PAR takes extra time to try to work around it, making my implementation very time-consuming. here is the warning message: WARNING:Route:466 - Unusually high hold time violation detected among 324 connections. The top 20 such instances are printed below. The router will continue and try to fix it U_inner_logic/U_qdr_ctl0/c0_qdr_wr_dat<83>:DQ -> U_qdrii_sramc/c0_u_user_top/u_qdr_phy_top/u_phy_write_top/u_phy_write_data/iob_data_rise1<11>:DX -3031 U_inner_logic/U_qdr_ctl0/c0_qdr_wr_dat<83>:BQ -> U_qdrii_sramc/c0_u_user_top/u_qdr_phy_top/u_phy_write_top/u_phy_write_data/iob_data_rise1<11>:BX -3031 U_inner_logic/U_qdr_ctl0/c0_qdr_wr_dat<95>:CQ -> U_qdrii_sramc/c0_u_user_top/u_qdr_phy_top/u_phy_write_top/u_phy_write_data/iob_data_rise1<23>:CX -3017 U_inner_logic/U_qdr_ctl0/c0_qdr_wr_dat<95>:BQ -> U_qdrii_sramc/c0_u_user_top/u_qdr_phy_top/u_phy_write_top/u_phy_write_data/iob_data_rise1<23>:BX -3015 U_inner_logic/U_qdr_ctl0/c0_qdr_wr_dat<115>:CQ -> U_qdrii_sramc/c0_u_user_top/u_qdr_phy_top/u_phy_write_top/u_phy_write_data/iob_data_fall0<7>:CX -3014 U_inner_logic/U_qdr_ctl0/c0_qdr_wr_dat<95>:AQ -> U_qdrii_sramc/c0_u_user_top/u_qdr_phy_top/u_phy_write_top/u_phy_write_data/iob_data_rise1<23>:AX -3014 U_inner_logic/U_qdr_ctl0/c0_qdr_wr_dat<95>:DQ -> U_qdrii_sramc/c0_u_user_top/u_qdr_phy_top/u_phy_write_top/u_phy_write_data/iob_data_rise1<23>:DX -3013 U_inner_logic/U_qdr_ctl0/c0_qdr_wr_dat<115>:BQ -> U_qdrii_sramc/c0_u_user_top/u_qdr_phy_top/u_phy_write_top/u_phy_write_data/iob_data_fall0<7>:BX -3012 U_inner_logic/U_qdr_ctl0/c0_qdr_wr_dat<115>:AQ -> U_qdrii_sramc/c0_u_user_top/u_qdr_phy_top/u_phy_write_top/u_phy_write_data/iob_data_fall0<7>:AX -3011 U_inner_logic/U_qdr_ctl0/c0_qdr_wr_dat<115>:DQ -> U_qdrii_sramc/c0_u_user_top/u_qdr_phy_top/u_phy_write_top/u_phy_write_data/iob_data_fall0<7>:DX -3010 U_inner_logic/U_qdr_ctl0/c0_qdr_wr_dat<79>:DQ -> U_qdrii_sramc/c0_u_user_top/u_qdr_phy_top/u_phy_write_top/u_phy_write_data/iob_data_rise1<7>:DX -2995 U_inner_logic/U_qdr_ctl0/c0_qdr_wr_dat<79>:BQ -> U_qdrii_sramc/c0_u_user_top/u_qdr_phy_top/u_phy_write_top/u_phy_write_data/iob_data_rise1<7>:BX -2995 U_inner_logic/U_qdr_ctl0/c0_qdr_rd_adr<19>:CQ -> U_qdrii_sramc/c0_u_user_top/u_qdr_phy_top/u_phy_write_top/u_phy_write_control/iob_addr_fall0<19>:C5 -2956 U_inner_logic/U_qdr_ctl0/c0_qdr_wr_dat<27>:DQ -> U_qdrii_sramc/c0_u_user_top/u_qdr_phy_top/u_phy_write_top/u_phy_write_data/mux_data_fall1_2r_27_BRB1:AX -2956 U_inner_logic/U_qdr_ctl0/c0_qdr_wr_dat<31>:AQ -> U_qdrii_sramc/c0_u_user_top/u_qdr_phy_top/u_phy_write_top/u_phy_write_data/mux_data_fall1_2r_28_BRB1:AX -2955 U_inner_logic/U_qdr_ctl0/c0_qdr_rd_adr<7>:CQ -> U_qdrii_sramc/c0_u_user_top/u_qdr_phy_top/u_phy_write_top/u_phy_write_control/iob_addr_fall0<7>:C5 -2954 U_inner_logic/U_qdr_ctl0/c0_qdr_rd_adr<19>:AQ -> U_qdrii_sramc/c0_u_user_top/u_qdr_phy_top/u_phy_write_top/u_phy_write_control/iob_addr_fall0<19>:A5 -2950 U_inner_logic/U_qdr_ctl0/c0_qdr_wr_dat<83>:AQ -> U_qdrii_sramc/c0_u_user_top/u_qdr_phy_top/u_phy_write_top/u_phy_write_data/iob_data_rise1<11>:AX -2950 U_inner_logic/U_qdr_ctl0/c0_qdr_wr_dat<111>:DQ -> U_qdrii_sramc/c0_u_user_top/u_qdr_phy_top/u_phy_write_top/u_phy_write_data/iob_data_fall0<3>:DX -2943 U_inner_logic/U_qdr_ctl0/c0_qdr_wr_dat<111>:AQ -> U_qdrii_sramc/c0_u_user_top/u_qdr_phy_top/u_phy_write_top/u_phy_write_data/iob_data_fall0<3>:AX -2943 What can I do to fix this? Thank you. 
0
|
|
相关推荐
4个回答
|
|
|
实例名称暗示这是QDR2控制器的一部分。
这是您创建的东西，Xilinx核心还是您从第三方获得的东西？ 在布局和路线之后，时间报告对这些路径有何评论？ ------您是否尝试在Google中输入问题？ 如果没有，你应该在发布之前。太多结果？ 尝试添加网站：www.xilinx.com 以上来自于谷歌翻译 以下为原文 The instance names imply that this is part of a QDR2 controller. Is this something you created, a Xilinx core or something that you obtained from a 3rd party? After place and route, what did the timing report say about these paths? ------Have you tried typing your question into Google? If not you should before posting. Too many results? Try adding site:www.xilinx.com |
|
|
|
|
|
你好，
实现DDRII SRAM控制器时我遇到了类似的问题。 电路板已经存在，因此在没有首先实现代码的情况下定位引脚。 我怀疑引脚的放置与它正在使用的BUFG之间存在问题......它们可能位于芯片的相反两半或其他部分，从而产生大的路由延迟？ 我也希望能够自己解决这个问题，我现在还在弄清楚现在发生了什么。 以上来自于谷歌翻译 以下为原文 Hello, I have similar issues when implementing a DDRII SRAM controller. The board already existed so the pins are loc'ed without first implementing the code. I suspect there is a problem between placement of the pins and the BUFG's it's using... they might be on opposite halves of the chip or something, creating large routing delays? I hope to get to work around this myself too, I'm still figuring out what is going on at this moment. |
|
|
|
|
|
检查时钟路径中的异常高延迟。
在时钟放置期间，非最佳时钟配置通常会导致“时钟专用路由”错误。 你绕过了这些错误吗？ 如果是这样，请返回并重新读取生成的警告消息。您的所有时钟都在时钟缓冲区上吗？ 检查.par文件中的时钟报告并查找本地时钟。 这是一个例子：**************************生成时钟报告***************** ********* + --------------------- + -------------- + --- --- + ------ + ------------ + ------------- + | 时钟网| 资源|锁定|扇出|净偏差（ns）|最大延迟（ns）| + --------------------- + --------- ----- + ------ + ------ + ------------ + ------------- + | clk_backplane_27M | 本地| | 623 | 7.221 | 8.163 | + --------------------- + -------------- + ------ + --- --- + ------------ + ------------- +如果时钟路径没有明显问题，那么你需要检查时间 报告以查看保留错误的来源。 以上来自于谷歌翻译 以下为原文 Check for unusually high delay in the clock path. Non-optimal clock configurations will often result in "clock dedicated route" errors during clock placement. Have you bypassed any such errors? If so, go back and reread the resulting warning message. Are all of your clocks on clock buffers? Check the Clock Report in the .par file and look for local clocks. Here's an example: ************************** Generating Clock Report ************************** +---------------------+--------------+------+------+------------+-------------+ | Clock Net | Resource |Locked|Fanout|Net Skew(ns)|Max Delay(ns)| +---------------------+--------------+------+------+------------+-------------+ | clk_backplane_27M | Local| | 623 | 7.221 | 8.163 | +---------------------+--------------+------+------+------------+-------------+ If there are no obvious issues with clock paths, then you'll need to examine the timing reports to see where the hold errors are coming from. |
|
|
|
|
|
当使用Xilinx / AVnet为ML605板提供的Virtex6 DSP套件参考设计时，我遇到了同样的问题。
组件是： ila0_data0-> U_ila_pro_0 / U0 / iData 这样的事情。 ila0是chipcope ila内核的参考。 当使用Xilinx开发板和xilinx / Avnet参考设计时，有没有其他人处理过这个问题？ 以上来自于谷歌翻译 以下为原文 I have this same problem, when using the Virtex6 DSP kit reference design provided by Xilinx/AVnet for the ML605 board. The components are: ila0_data0<30>-> U_ila_pro_0/U0/iData And things like this. ila0 are references to chipscope ila cores. Has anybody else dealt with this, specfically when using the Xilinx development board and xilinx/Avnet reference design? |
|
|
|
|
只有小组成员才能发言，加入小组>>
2380 浏览 7 评论
2797 浏览 4 评论
Spartan 3-AN时钟和VHDL让ISE合成时出现错误该怎么办？
2262 浏览 9 评论
3335 浏览 0 评论
如何在RTL或xilinx spartan fpga的约束文件中插入1.56ns延迟缓冲区？
2428 浏览 15 评论
有输入，但是LVDS_25的FPGA内部接收不到数据，为什么？
755浏览 1评论
请问vc707的电源线是如何连接的，我这边可能出现了缺失元件的情况导致无法供电
543浏览 1评论
求一块XILINX开发板KC705，VC707，KC105和KCU1500
364浏览 1评论
1960浏览 0评论
681浏览 0评论
/6 
关注我们的微信
下载发烧友APP
电子发烧友观察
版权所有 © 湖南华秋数字科技有限公司
电子发烧友 （电路图） 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证：合字B2-20210191
工商网监
湘ICP备2023018690号
评论
淘帖
1205
