10-16-2014 01:26 PM
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:
Nets with Routing Errors:
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.
10-16-2014 10:28 PM
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.
10-17-2014 08:47 AM
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.
10-17-2014 12:57 PM
The "report_route_status" show the follwoing message:
Nets with Routing Errors:
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/
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?
10-28-2014 07:32 PM
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.
10-29-2014 09:43 AM - edited 10-29-2014 10:10 AM
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.
10-29-2014 10:13 AM - edited 10-29-2014 10:21 AM
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.
10-29-2014 10:18 AM
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.
10-29-2014 10:21 AM - edited 10-29-2014 10:23 AM
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.