cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
5,561 Views
Registered: ‎02-25-2015

IDELAY_CTRL vs multiple idelay ctrl blocks

Everything I find on here and via google says that one only needs to instantiate a single idelay_ctrl block and multiple iodelays and "the tool" (meaning the vivado router/bitstream phase) will automatically replicate delay controls as needed.

 

However, when we do this with one delay_ctrl and 2 iodelays, we get a routing error (part of the pathnames replaces with ..... here):

 

 

CRITICAL WARNING: [Route 35-54] Net: core_i/......../rx_deser_clk_gen_xilinx/bit_clk_idly is not completely routed.
Resolution: Run report_route_status for more information.

Unroutable connection Types:
----------------------------
Type 1 : IDELAYE2.DATAOUT->BUFR.I
-----Num Open nets: 1
-----Representative Net: Net[36] core_i/.....x/rx_deser_clk_gen_xilinx/bit_clk_idly
-----IDELAY_X0Y172.DATAOUT -> BUFR_X0Y12.I
-----Driver Term: core_i/...../clk_iodly/DATAOUT Load Term [4497]: core_i/...../clk_bufr/I
Type 2 : IDELAYE2.DATAOUT->BUFIO.I
-----Num Open nets: 1
-----Representative Net: Net[36] core_i/...../bit_clk_idly
-----IDELAY_X0Y172.DATAOUT -> BUFIO_X0Y12.I
-----Driver Term: core_i/...../clk_iodly/DATAOUT Load Term [4496]: core_i/...../bit_clk_buf/I
Phase 3.1 Initial Routing Verification | Checksum: eebb0a98

 

It says critical warning, which ultimately doesnt' route:

 

ERROR: [DRC 23-20] Rule violation (RTSTAT-1) Unrouted net - 1 net(s) are unrouted. The problem bus(es) and/or net(s) are core_i/......./bit_clk_idly.

 

Since it's unclear what the requirement is and what is not allowed here, I don't know what to do about this.   We've tried various IODELAY_GROUP variations, setting one delay_ctrl per output group, etc, with different errors each.

 

Any hints or pointers appreciated.  I'm happy to do something more manual, since the automatic version doesn't seem to work.

 

0 Kudos
4 Replies
Highlighted
Xilinx Employee
Xilinx Employee
5,504 Views
Registered: ‎04-16-2012

Re: IDELAY_CTRL vs multiple idelay ctrl blocks

Hi @base13

 

Can you share the connectivity of the signal which is erroring out. ie., bit_clk_idly

Share a schematic snapshot to investigate this routing issue.

 

Thanks,

Vinay

--------------------------------------------------------------------------------------------
Have you tried typing your question in Google? If not you should before posting. Also, MARK this is as an answer in case it helped resolve your query/issue.Give kudos to the post that helped you to find the solution.
0 Kudos
Highlighted
Visitor
Visitor
5,154 Views
Registered: ‎02-25-2015

Re: IDELAY_CTRL vs multiple idelay ctrl blocks

I'm doing a bit of cleanup and forgot to answer this.   This was solved by an AE from NorthWest Logic (Hi Andy :).  Basically one must manually place the idelays closer to the delay control, or rather if placed manually and properly it will route.  I'll add more detail when I get back to the office on monday (adding this as a self reminding place holder :)

0 Kudos
Highlighted
Guide
Guide
5,149 Views
Registered: ‎01-23-2009

Re: IDELAY_CTRL vs multiple idelay ctrl blocks

I don't think this has anything to do with the IDELAY_CTRL. It seems to be telling you that the net frmom the IDELAY to the BUFR and BUFIO cannot be routed (so you can stop messing with the IDELAY_CTRL and IOGROUPs).

 

Now the question is whay can't it route these nets...

 

To drive the BUFIO and BUFR, the connection must come from one of the four clock capable pins in a bank, and be connected through the IDELAY in that IO directly to the BUFIO and BUFR in the same bank. No other connection is legal. So, make sure

   - your clock input is on a clock capable I/O (MRCC or SRCC)

   - you are not trying to LOC the IDELAY - let the tool place it with the clock input

   - do not LOC the BUFR or BUFIO

   - make sure that all the loads of the BUFIO are in the same bank as the clock capable pin bringing the clock in

   - nothing driven by the BUFR is LOC'ed outside the clock region that the clock capable pin is in

 

If all of these things are correct, then I don't know why it would be having trouble with these nets.

 

I think the tool still generates a DCP even with a failed net - so you should be able to open the design and look at the net (which will show as a logical net instead of a placed one) and the source and destination cells...

 

Avrum

0 Kudos
Highlighted
Visitor
Visitor
5,093 Views
Registered: ‎02-25-2015

Re: IDELAY_CTRL vs multiple idelay ctrl blocks

Here's what we finally had to do..  We had a series of selectio deserializers (for a big network switch of sorts), and the IODELAY blocks needed to be manually placed.  Once this was done (in this case on our artix 7), routing succeeded.  Here's what we added (with irrelevant details removed).

 

set_property LOC IDELAY_X0Y174 [get_cells ......................./clk_iodly]

set_property LOC IDELAY_X0Y172 [get_cells ......................./clk_iodly]

set_property LOC IDELAY_X0Y228 [get_cells ......................./clk_iodly]

set_property LOC IDELAY_X0Y222 [get_cells ......................./clk_iodly]

set_property LOC IDELAY_X1Y24 [get_cells ......................./clk_iodly]

... etc

 

I don;t have time to add too much detail now, but I will soon just so it's documented here.

0 Kudos