cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
trenz-al
Scholar
Scholar
10,882 Views
Registered: ‎11-09-2013

UltraScale+ Dsiplayport: untrouted net, new BUG?

Jump to solution

it seems that in 2015.4.1 Displayport IP core has major problem causing the GTREF clock to be unroutable, there are answer records that indicate that similar problems existed, and have been solved, but it seems that in the case of Displayport there is still as showstopper bug in 2015.4.1

 

or is there some trick or patch to get the clock rouiting to pass DRC ?

0 Kudos
1 Solution

Accepted Solutions
trenz-al
Scholar
Scholar
20,324 Views
Registered: ‎11-09-2013

it passes bitgen with 2016.1, so the issue is solved.

View solution in original post

0 Kudos
8 Replies
athandr
Xilinx Employee
Xilinx Employee
10,839 Views
Registered: ‎07-31-2012
Can you paste the exact error? If possible the XCI file and the project which should help reproduce this?
Thanks,
Anirudh

PS: Please MARK this as an answer in case it helped resolve your query.Give kudos in case the post guided you to a solution.
0 Kudos
trenz-al
Scholar
Scholar
10,832 Views
Registered: ‎11-09-2013

[Route 35-54] Net: zsys_i/displayport_0/inst/support_inst/clocking_inst/gtrefclk0_in[0] is not completely routed.

 

it is very simple to reproduce, just select ZU9EG as device and try to implement anything that includes Displayport IP core..

0 Kudos
athandr
Xilinx Employee
Xilinx Employee
10,642 Views
Registered: ‎07-31-2012
hI Trens, I am checking on this locally and will get back with the results.
Thanks,
Anirudh

PS: Please MARK this as an answer in case it helped resolve your query.Give kudos in case the post guided you to a solution.
0 Kudos
athandr
Xilinx Employee
Xilinx Employee
10,634 Views
Registered: ‎07-31-2012

Hi trenz,

 

I tested this locally with the same XCI file and the device name and do not see any such routing issues. I did this with the example design using IP Catalog and not in the IP Integrator. In any case this should not be an issues.

 

 

Please try with the example design at your end and let me know if you see failures. This was tested with 2015.4.1

test1.PNG

 

Thanks,
Anirudh

PS: Please MARK this as an answer in case it helped resolve your query.Give kudos in case the post guided you to a solution.
0 Kudos
trenz-al
Scholar
Scholar
10,624 Views
Registered: ‎11-09-2013

well we need the IPI flow, I can try the IP catalog to see if has routing problems

 

I am currently trying to back-port the DisplayPort 7.0 from Vivado 2016.1 to Vivado 2015.4, well this does not to be a good idea either.. :(

0 Kudos
trenz-al
Scholar
Scholar
20,325 Views
Registered: ‎11-09-2013

it passes bitgen with 2016.1, so the issue is solved.

View solution in original post

0 Kudos
athandr
Xilinx Employee
Xilinx Employee
10,589 Views
Registered: ‎07-31-2012

2016.1 is not yet released. How do you have access to this version of the tool?

Thanks,
Anirudh

PS: Please MARK this as an answer in case it helped resolve your query.Give kudos in case the post guided you to a solution.
0 Kudos
trenz-al
Scholar
Scholar
10,494 Views
Registered: ‎11-09-2013

I have tested again on 2015.4 also, the problem was in our design, I had connected an on-chip frequency counter IP core to lnk_clk_ibufds_out pin !! This is a no-go of course, it caused unroutable error that looked like it is on the INPUT path but the problem was in the clock consumer. The link clock can only be used in general fabric using lnk_clk output in ultrascale+

 

I think fpr 7 series would the second direct output also have path to PL, well with ultrascale its different.

0 Kudos