cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
jasminetifei
Adventurer
Adventurer
13,589 Views
Registered: ‎06-24-2011

Routing Conflict detected in Vivado 2014.2 but no problem in ISE 14.6

I have a proven design running and working perfectly with ISE 14.1 and 14.6. With the same source code on the same Kintex-7 FPGA migrating to Vivado 2014.2 but routing errors poped up:

 

  • [Route 35-279] Routing Conflict Detected. Wire INT_R_X95Y98/CLK1 needed to route design_1_i/gsi_ip_0/inst/gsi_ip_v1_0_S00_AXI_inst/core/cq_kd[0].ip_CQ_cal/ODIV is used up by design_1_i/gsi_ip_0/inst/gsi_ip_v1_0_S00_AXI_inst/core/user_sys_clk
  • [Route 35-279] Routing Conflict Detected. Wire INT_R_X95Y97/CLK1 needed to route design_1_i/gsi_ip_0/inst/gsi_ip_v1_0_S00_AXI_inst/core/cq_kd[0].ip_CQ_cal/ODIV is used up by design_1_i/gsi_ip_0/inst/gsi_ip_v1_0_S00_AXI_inst/core/user_sys_clk

 

Nets with Routing Errors:
  design_1_i/gsi_ip_0/inst/gsi_ip_v1_0_S00_AXI_inst/core/cq_kd[0].ip_CQ_cal/ODIV
    Unrouted Pins:
      design_1_i/gsi_ip_0/inst/gsi_ip_v1_0_S00_AXI_inst/core/d_q[0].ip_Q_cal/idelay/C
      design_1_i/gsi_ip_0/inst/gsi_ip_v1_0_S00_AXI_inst/core/d_q[1].ip_Q_cal/idelay/C
      design_1_i/gsi_ip_0/inst/gsi_ip_v1_0_S00_AXI_inst/core/d_q[2].ip_Q_cal/idelay/C
      design_1_i/gsi_ip_0/inst/gsi_ip_v1_0_S00_AXI_inst/core/d_q[3].ip_Q_cal/idelay/C
      design_1_i/gsi_ip_0/inst/gsi_ip_v1_0_S00_AXI_inst/core/d_q[4].ip_Q_cal/idelay/C
      design_1_i/gsi_ip_0/inst/gsi_ip_v1_0_S00_AXI_inst/core/d_q[5].ip_Q_cal/idelay/C

 

 

If ISE can fully route the design, it makes little sense that the Vivado can not do it.I checked the forum found some people does have similar experience but there is no solid suggestions. I need a starting point to figure this out.

 

I was wondering if timing constrians with effect the implementation. Setting clock groups -asynchrouse or -logically_exclusive seems make the result slightly different.

 

Please advices, thanks. 

0 Kudos
10 Replies
siktap
Scholar
Scholar
13,571 Views
Registered: ‎06-14-2012

There could be some changes in the way things have been implemented in Vivado. I would suggest to check the clock path in Vivado. user_sysclk and the ODIV nets. From the error message, it seems they are fighting for the same routing resource.

 

Another thing that you could try is to compare with the components and routed nets in ISE. This will give a better picture.

You can try with some strategies to get some variations in the runs.

 

I would  also try to run report_route_status to get some detailed information on this conflicting nodes.

 

Regards

Sikta

0 Kudos
jasminetifei
Adventurer
Adventurer
13,562 Views
Registered: ‎06-24-2011

The result of " report_route_status" was already shown at the original post. Interesting it only printed out 6 unrouted pins, but when I do to the device viewer, there are actually 18 of them. Is there any way to set the error message display more lines?

 

Thanks for the reply. I will use FPGA editor and Vivado Device viewer to compare ISE reslut and Vivado result. Will get back here if found something. Attached DCP file if you have some time to kill.

 

 

0 Kudos
jasminetifei
Adventurer
Adventurer
13,554 Views
Registered: ‎06-24-2011

The "report_route_status" show the follwoing message:

 

Nets with Routing Errors:
  design_1_i/gsi_ip_0/inst/gsi_ip_v1_0_S00_AXI_inst/core/cq_kd[0].ip_CQ_cal/ODIV
    Unrouted Pins:
      design_1_i/gsi_ip_0/inst/gsi_ip_v1_0_S00_AXI_inst/core/d_q[0].ip_Q_cal/idelay/C
      design_1_i/gsi_ip_0/inst/gsi_ip_v1_0_S00_AXI_inst/core/d_q[1].ip_Q_cal/idelay/C
      design_1_i/gsi_ip_0/inst/gsi_ip_v1_0_S00_AXI_inst/core/d_q[2].ip_Q_cal/idelay/C
      design_1_i/gsi_ip_0/inst/gsi_ip_v1_0_S00_AXI_inst/core/d_q[3].ip_Q_cal/idelay/C
      design_1_i/gsi_ip_0/inst/gsi_ip_v1_0_S00_AXI_inst/core/d_q[4].ip_Q_cal/idelay/C
      design_1_i/gsi_ip_0/inst/gsi_ip_v1_0_S00_AXI_inst/core/d_q[5].ip_Q_cal/idelay/C

 

The Routing shows this critical warning:

 

[Route 35-279] Routing Conflict Detected. Wire INT_R_X95Y98/CLK1 needed to route design_1_i/gsi_ip_0/inst/gsi_ip_v1_0_S00_AXI_inst/core/cq_kd[0].ip_CQ_cal/ODIV is used up by design_1_i/gsi_ip_0/inst/gsi_ip_v1_0_S00_AXI_inst/core/user_sys_clk

 

However, when I check the DCP through Device viewer, pin C is connected, but showing "Unrouted". Compare to the cell next to it, it shows "Routed". Both of these cell pins are driven by the same wire. I don't understand why the pin is showing connected but report shows the other way. Please check the attached pictures.

 

Any direction suggest?

 

pic01.png
pic02.png
0 Kudos
zhangwei0814
Participant
Participant
13,480 Views
Registered: ‎10-08-2014

Hi 

       The ISE synthesis and implementation are true, finally  resource utilization analysis report is normal. Now in the Vivado,  in the first step(Implementation) to realize the logic optimization (opt_design) put a lot of resources to optimize away the module (suggests logical unit not load), but when the ISE implementation has not been optimized away, now  how to ensure the logic module resources are not optimized  in the  Vivado implementation stage?

      Now in vivado 2014.2 , the synthesized design the connectivity of the elements getting trimmed is proper.So synthesis is normal,resource utilization is also normal .However ,in the implementation phase,most of the resources are optimized away and resource utilization is not normal .I can't achive desired functionality with the optimized design because of losing too much ogic modules .I want to know how to solve the problem for ensuring the logic module resources are not optimized in the Vivado implementation stage?

      The following two picture indicata the resource utilization.

      Thanks.

D74`_NVXD1@EHR]LZKB]P}I.jpg
6TL}OD[HYO(TZWP6VSRN83U.jpg
0 Kudos
bwade
Scholar
Scholar
13,461 Views
Registered: ‎07-01-2008

I've examined the DCP provided and I see that the problem is that there is a conflict for a shared routing resource. The CLK pins of the IDELAYand ODELAY components in the same tile share the same switchbox path and so need to be driven by the same clock net. This resource is also shared with the OLOGIC CLKDIV pin. 

 

The documention describes this somewhat on page 134 of UG471 where it states that the ODELAY CLK pin shares connectivity with the OLOGIC CLKDIV pin. The documentation fails to mention that IDELAY CLK also shares this resource. I'll file a CR against the documentation to correct that.

 

The ISE toolset would have had the same hardware restriction. In fact ISE and Vivado share the same device model files so there isn't even a possibility that they modeled the connections differently. If you can share the routed NCD file from ISE I could explain why it didn't have the same conflict. Something must be different about the implementation. Maybe a different IO placement.

 

Bret

bwade
Scholar
Scholar
13,451 Views
Registered: ‎07-01-2008

I'm going to post a series of screenshots to demonstrate the basic techinique for debugging a routing conflict such as this.

 

First in the device view of Vivado, identify the unrouted pin and highlight the routing resource that drives it.

debug1.png
0 Kudos
bwade
Scholar
Scholar
13,450 Views
Registered: ‎07-01-2008

Second, zoom in on the switchbox pin driving the routing resource above.

debug2.PNG
0 Kudos
bwade
Scholar
Scholar
13,449 Views
Registered: ‎07-01-2008

Third, select the switchbox pin until it displays the possible switchbox paths. Typically there are multiple paths to examine but in this case there is just one. Zoom out so that the other end is in view.

debug3.PNG
0 Kudos
bwade
Scholar
Scholar
13,446 Views
Registered: ‎07-01-2008

Finaly, zoom in to the input side of the switchbox path and note that the input pin is alread in use by another signal. Similar analysis can be performed on that other signal's load pins to confirm that no alternative path exists for them. This information is all that's needed to understand the routing conflict.

debug4.PNG
bwade
Scholar
Scholar
8,617 Views
Registered: ‎07-01-2008

CR 831865 filed against UG471.

0 Kudos