赛灵思
直播中

刘文娟

8年用户 165经验值
私信 关注
[问答]

ISE 14.7 PAR路由与GLOBAL_LOGIC1冲突

嗨,大家好,
对于partxc7k325t-1ffg900,我在ISE 14.7中面临以下问题:
错误:路线:472  -  
这种设计是不可能的。
要评估此问题,请使用FPGA_editor。
路由冲突1:
Net:inst_SGSO_PCIe / gen_V7.inst_SGSO_PCIe_Endpoint / cfg_err_cor_int_n在引脚ADDRBtiEHIGH1上的位置RAMB18_X3Y65
Net:位于RAMB18_X3Y64位置的引脚ADDRBTIEHIGH1上的GLOBAL_LOGIC1
在线上检测到冲突:PINFEED(63874,-40949)
路由冲突2:
网络RAMB18_X3Y65上的引脚ADDRATIEHIGH1上的网络:inst_SGSO_PCIe / gen_V7.inst_SGSO_PCIe_Endpoint / cfg_err_cor_int_n
Net:位于RAMB18_X3Y64位置的引脚ADDRATIEHIGH1上的GLOBAL_LOGIC1
在线上检测到冲突:PINFEED(63890,-41397)
路由冲突3:
网络RAMB18_X3Y65上的引脚ADDRATIEHIGH1上的网络:inst_SGSO_PCIe / gen_V7.inst_SGSO_PCIe_Endpoint / cfg_err_cor_int_n
Net:位于RAMB18_X3Y64位置的引脚ADDRATIEHIGH1上的GLOBAL_LOGIC1
在线上检测到冲突:PINFEED(65661,-37000)
路由冲突4:
Net:inst_SGSO_PCIe / gen_V7.inst_SGSO_PCIe_Endpoint / cfg_err_cor_int_n在引脚ADDRBTIEHIGH1上的位置RAMB18_X3Y65
Net:位于RAMB18_X3Y64位置的引脚ADDRBTIEHIGH1上的GLOBAL_LOGIC1
在线上检测到冲突:PINFEED(65661,-36936)
信号“cfg_err_cor_int_n”在代码中通过一个或两个反相器设置为常数“1”。
涉及的RAMB18与实例化的PCIe模块无关,并且在XST的综合中自动推断:
首先:找到1024x16位只读RAM用于信号然后用:INFO:Xst:3226  -  RAM将实现为BLOCK RAM,吸收以下寄存器:----------
--------------------------------------------------
-----------
ram_type |
块|
|
--------------------------------------------------
--------------------- |
港口A |
|
纵横比|
1024字x 16位|
|
|
模式|
先写|
|
|
clkA |
连接到信号|
上升|
|
weA |
连接到信号|
高|
|
addrA |
连接到信号|
|
|
diA |
连接到信号|
|
|
doA |
连接到信号|
|
--------------------------------------------------
--------------------- |
优化|
速度|
|
--------------------------------------------------
---------------------
如果您有任何建议,我将不胜感激!
问候,
萨科

以上来自于谷歌翻译


以下为原文

Hi everyone,

I am facing the following issue with PAR in ISE 14.7 for the part xc7k325t-1ffg900:

ERROR:Route:472 -    This design is unrouteable.   To evaluate the problem please use fpga_editor.Routing Conflict 1: Net:inst_SGSO_PCIe/gen_V7.inst_SGSO_PCIe_Endpoint/cfg_err_cor_int_n on pin ADDRBTIEHIGH1 on location RAMB18_X3Y65 Net:GLOBAL_LOGIC1 on pin ADDRBTIEHIGH1 on location RAMB18_X3Y64     Conflict detected on wire: PINFEED(63874,-40949)Routing Conflict 2: Net:inst_SGSO_PCIe/gen_V7.inst_SGSO_PCIe_Endpoint/cfg_err_cor_int_n on pin ADDRATIEHIGH1 on location RAMB18_X3Y65 Net:GLOBAL_LOGIC1 on pin ADDRATIEHIGH1 on location RAMB18_X3Y64     Conflict detected on wire: PINFEED(63890,-41397)Routing Conflict 3: Net:inst_SGSO_PCIe/gen_V7.inst_SGSO_PCIe_Endpoint/cfg_err_cor_int_n on pin ADDRATIEHIGH1 on location RAMB18_X3Y65 Net:GLOBAL_LOGIC1 on pin ADDRATIEHIGH1 on location RAMB18_X3Y64     Conflict detected on wire: PINFEED(65661,-37000)Routing Conflict 4: Net:inst_SGSO_PCIe/gen_V7.inst_SGSO_PCIe_Endpoint/cfg_err_cor_int_n on pin ADDRBTIEHIGH1 on location RAMB18_X3Y65 Net:GLOBAL_LOGIC1 on pin ADDRBTIEHIGH1 on location RAMB18_X3Y64     Conflict detected on wire: PINFEED(65661,-36936)  
The signal "cfg_err_cor_int_n" is set to constant '1' in the code, through one or two inverters. The RAMB18 involved has nothing to do with the PCIe module instantiated and was automatically inferred at synthesis by XST:

First with:

Found 1024x16-bit Read Only RAM for signal

And then with:

INFO:Xst:3226 - The RAM will be implemented as a BLOCK RAM, absorbing the following register(s):
-----------------------------------------------------------------------
| ram_type     | Block                             |                  |
-----------------------------------------------------------------------
| Port A                                                              |
| aspect ratio | 1024-word x 16-bit                 |                 |
| mode         | write-first                        |                 |
| clkA         | connected to signal       | rise            |
| weA          | connected to signal           | high            |
| addrA        | connected to signal |                 |
| diA          | connected to signal           |                 |
| doA          | connected to signal |                 |
-----------------------------------------------------------------------
| optimization | speed                              |                 |
-----------------------------------------------------------------------
If you have any suggestions, I would appreciate it!

Regards,

Nicolas

回帖(8)

石俊梅

2018-11-6 11:59:48
你好@ nicosilicom
BRAM磁贴中的两个RAMB18站点共享ADDRATIEHIGH1 ADDRBTIEHIGH1资源。
当我们在这两个站点放置两个BRAM 18时,我们需要确保这些引脚上的信号是相同的。
在这种情况下,两个引脚具有不同的信号,因此路由器失败。
尝试将冲突的BRAM锁定到另一个不同的BRAM站点,看看它是否有帮助。
您可以在FPGA编辑器中打开部分路由设计,以查找当前位于RAMB18_x3Y64站点的BRAM实例。
如果您需要帮助,请在此处附上.ncd和.pcf文件。
谢谢,
迪皮卡。
谢谢,迪皮卡.----------------------------------------------
---------------------------------------------- Google之前的问题
张贴。
如果某人的帖子回答了您的问题,请将帖子标记为“接受为解决方案”。
如果你看到一个特别好的和信息丰富的帖子,考虑给它Kudos(左边的明星)
在原帖中查看解决方案

以上来自于谷歌翻译


以下为原文

Hi @nicosilicom
 
The Two RAMB18s sites in a BRAM tile share ADDRATIEHIGH1 ADDRBTIEHIGH1 resources. When we place two BRAM 18s in these two sites, we need to ensure that the signal on these pins are the same. In this case, the two pins have different signal, because of which the router fails.

Try locking one of the conflicting BRAMs to a different BRAM site and see if it helps.
 
You can open the partially routed design in FPGA editor to find the BRAM instance which is currently sitting in site RAMB18_x3Y64.
 
If you need help in doing this please attach .ncd and .pcf files here.
 
Thanks,
Deepika.
Thanks,
Deepika.
--------------------------------------------------------------------------------------------
Google your question before posting. If someone's post answers your question, mark the post as answer with "Accept as solution". If you see a particularly good and informative post, consider giving it Kudos (the star on the left)View solution in original post
举报

石俊梅

2018-11-6 12:14:15
你好@ nicosilicom
BRAM磁贴中的两个RAMB18站点共享ADDRATIEHIGH1 ADDRBTIEHIGH1资源。
当我们在这两个站点放置两个BRAM 18时,我们需要确保这些引脚上的信号是相同的。
在这种情况下,两个引脚具有不同的信号,因此路由器失败。
尝试将冲突的BRAM锁定到另一个不同的BRAM站点,看看它是否有帮助。
您可以在FPGA编辑器中打开部分路由设计,以查找当前位于RAMB18_x3Y64站点的BRAM实例。
如果您需要帮助,请在此处附上.ncd和.pcf文件。
谢谢,
迪皮卡。
谢谢,迪皮卡.----------------------------------------------
---------------------------------------------- Google之前的问题
张贴。
如果某人的帖子回答了您的问题,请将帖子标记为“接受为解决方案”。
如果你看到一个特别好的和信息丰富的帖子,考虑给它Kudos(左边的明星)

以上来自于谷歌翻译


以下为原文

Hi @nicosilicom
 
The Two RAMB18s sites in a BRAM tile share ADDRATIEHIGH1 ADDRBTIEHIGH1 resources. When we place two BRAM 18s in these two sites, we need to ensure that the signal on these pins are the same. In this case, the two pins have different signal, because of which the router fails.

Try locking one of the conflicting BRAMs to a different BRAM site and see if it helps.
 
You can open the partially routed design in FPGA editor to find the BRAM instance which is currently sitting in site RAMB18_x3Y64.
 
If you need help in doing this please attach .ncd and .pcf files here.
 
Thanks,
Deepika.
Thanks,
Deepika.
--------------------------------------------------------------------------------------------
Google your question before posting. If someone's post answers your question, mark the post as answer with "Accept as solution". If you see a particularly good and informative post, consider giving it Kudos (the star on the left)
举报

李林松

2018-11-6 12:29:37
你好@ vemulad
感谢您的指示,我在另一篇文章(路由冲突)上找到了使用BLKNM约束的建议。
实际上,通过在所涉及的BRAM之一上使用XBLKNM约束,问题得以解决。
然而,两个不同的信号应该是相同的,因为信号“cfg_err_cor_int_n”等于'1'。
那么,为什么这个工具看不到呢?
问候,
萨科

以上来自于谷歌翻译


以下为原文

Hi @vemulad
 
 
Thanks to your indications, I found the suggestion on another post (routing conflict) to use BLKNM constraint. In fact, by using the XBLKNM constraint on one of the BRAM involved, the problem is solved.
 
However, the two different signals should be the same because the signal "cfg_err_cor_int_n" is equal to '1'. So, why the tool does not see that?
 
 
Regards,
 
Nicolas
 
举报

胡书琴

2018-11-6 12:37:21
您好@nicosilicom您最终如何解决问题?
我最近也发生了同样的错误,我也不知道!你能给我一些建议吗,我很感激!
罗文

以上来自于谷歌翻译


以下为原文

Hi @nicosilicom
   How do you slove the problem finally? The same errors have occured to me recently,and I have no idea for it!Can you give me some suggestions,I would appreciate it!

Rowen
举报

更多回帖

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