cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
491 Views
Registered: ‎10-16-2020

Large negative slack on IOBUFDS on Ultrascale

Hello,

got some serious issue trying to route IOBUFDS (for bidirectional point to point LVDS) on Virtex Ultrascale 440. I made sure that all outputs to the primitive are registers that are connected only to the primitive's ports. Still the Path from the tristate Flipflop to input is failing with a huge negative slack.

Which constraints are necessary to fix this or is there another issue i don't recognize? Using Vivado 2020.1.

Instructions are very much appreciated!

Thanks

 

 

 

Screenshot from 2020-10-16 10-40-21.png
0 Kudos
14 Replies
Highlighted
Explorer
Explorer
481 Views
Registered: ‎05-11-2015

 

How did you constrain it?

 

---------------------------------------------------------------------------------------------------
Have you tried upgrading the operating system of your spirit level?
-------------------------------------------------------------------------------------------------
0 Kudos
Highlighted
Visitor
Visitor
477 Views
Registered: ‎10-16-2020

set_property IOB TRUE [get_ports p162_lvds_p]

But it fails saying that it can't place the data and the tristate FlipFlop in the IOB and that the tristate FlipFlop is not directly connected to an IO which is wrong as there are no other

connections (as you can see on the Schematic)... very strange.

0 Kudos
Highlighted
Explorer
Explorer
463 Views
Registered: ‎05-11-2015

 

So there is more than a time closure issue.

I think IBUF, OBUF are meant to connect to physical pins, you cannot have them inside the FPGA.

---------------------------------------------------------------------------------------------------
Have you tried upgrading the operating system of your spirit level?
-------------------------------------------------------------------------------------------------
0 Kudos
Highlighted
Visitor
Visitor
460 Views
Registered: ‎10-16-2020

Not using them inside the FPGA. As you can see, IOBUFDS is the final stage between input / output registers and FPGA pads.

0 Kudos
Highlighted
Explorer
Explorer
437 Views
Registered: ‎05-11-2015

 

True. Those output and input blocks are not trivial things (delay-wise) and IDELAY/ ODELAY are used to keep signals synced with any incoming/ outcoming clock. So I suppose, independently of OBUF being connected to pins, that the path between registers is simply too long. You could explore using IDELAY/ODELAY and maybe a multicycle constraint.

---------------------------------------------------------------------------------------------------
Have you tried upgrading the operating system of your spirit level?
-------------------------------------------------------------------------------------------------
0 Kudos
Highlighted
Visitor
Visitor
427 Views
Registered: ‎10-16-2020

Fortunately, the clock for flipflops even on the other side of the pads is same as used on the Schematic picture. The other side of the pads is also on the same FPGA. The pads are just connected via an external cable for testing a board.

Ok i will have a look into multicycle constrantis. Never used them before.

0 Kudos
Highlighted
Explorer
Explorer
409 Views
Registered: ‎05-11-2015

 

Just wondering, LVDS, being asynchronous, doesn't care about clock because it's recovered by the Rx.

So, whatever you want to implement, if you have some LVDS back int othe FPGA, couldn't you ignore the clock and implement an LVDS receiver? Maybe you want to save that hassle, but you might as well need to go that way.

Also, that sort of feedback is kind of weird to me. You have your data, you send it out, why do you want it back in again?

---------------------------------------------------------------------------------------------------
Have you tried upgrading the operating system of your spirit level?
-------------------------------------------------------------------------------------------------
0 Kudos
Highlighted
Visitor
Visitor
393 Views
Registered: ‎10-16-2020

You are right about LVDS, but as the failing PATH is dependent of the Tristate Control and data reception, i thought it would be better not to just ignore that path and seek for help in this forum.

Yes, i'm testing a daughterboard which is connected via cable to a known good daugtherboard on the same FPGA to see if the data sent via the device under test (and the cable) is received as expected.

0 Kudos
Highlighted
339 Views
Registered: ‎01-22-2015

@microdevel 

On my computer, your timing report is too small for me to read.  However, I think you are seeing the delay, TOUTBUF_DELAY_TD_PAD = 890ns for LVDS  - see Table 28 of the datasheet, DS893(v1.12) for your Virtex UltraScale.

This amazingly large delay is the time it takes to switch your IOBUFDS in/out of tristate - and is not the propagation delay of a signal through IOBUFDS.

One way to handle TOUTBUF_DELAY_TD_PAD is to place a timing exception on the timing path thru the T-pin of IOBUFDS and ensure that your HDL switches the T-pin well in advance of when IOBUFDS is going to be used.

Cheers,
Mark

Highlighted
Guide
Guide
323 Views
Registered: ‎01-23-2009

So there are potentially three problems here...

The first (which is probably the least one) is that the tristate flip-flop is not packed into the IOB. This is referenced in the UltraScale SelectIO Resources guide UG571 in the section "ODDR with Serialized 3-State"; the tools do not appear to pack a "regular" flip-flop driving the tristate into the IOB, but if you instantiate an ODDR (with the D1 and D2 tied to the same value to effectively get a single data rate change) it will pack it into the IOB. There are some things to be careful with:

  • Each output needs its own ODDR for the tristate - they can't be shared
    • You may need to put a DONT_TOUCH on them to make sure the identical ones aren't declared redundant
  • This will have timing paths from the negative edge of the clock - these will have to be disabled. Something like
    • set_false_path -fall_from [get_clocks <driving_clock>] -to [get_ports <output_port>]

The second problem is one of timing - the Low-Z-> High-Z arc of the OBUFT is timed with a huge delay. This has been discussed on the forums before - see this thread. Based on this thread, Xilinx claims that this is "real", but I have no idea how that's possible... I suspect this is a characterization thing - how long does it take the termination resistors to bring the P&N "close enough" to the bias voltage, but that's not really a useful measure... It also doesn't tell us if this is only on Low-Z -> High-Z transition or also on the High-Z -> Low-Z; I suspect its only the former, but that doesn't really give us useful information on the latter...

The third problem is - what do need this to do? Are you (for example) expecting to turn off the driver on one clock edge, and sample the input from the external device on the next edge? It is uncommon to expect bus-turnaround to be done between active data transfers - there is usually one or more clocks of turnaround time between (although some things like ZBT RAMs do try and do "Zero Bus Turnaround" - hence the name). If your protocol does have dead cycles on the turnaround, then this path - from the flip-flop driving the T to the external device - is a multicycle path and should be declared as such (although it won't matter with the huge timing arc, which is the 2nd problem...). Similarly the path from the T flip-flop to the capture flip-flop (which is what you are showing here) is also a multicycle path...

Avrum

Highlighted
Visitor
Visitor
267 Views
Registered: ‎10-16-2020

Thanks for your responses! This is relly starting to clarify now.

I think it shouldn't be a problem switching the Tristate early enough from TX to RX - timing is not an issue at this point.

What i am really doing is sending a certain amount of data out via LVDS, then immediately switching LVDS to input (Tristate HIGH) and waiting for the other side to send the data back to me. I can configure the time the other side waits before sending the data back so this is not time critical at all (some sort of PING-PONG with 1 data transfer). The reason i was posting here was because i didn't understand that immense negative slack. The other thing was that in no way tools were able to pack the Tristate FF in the IOB.

Would you still recommend using multicycle path constraints on that?

 

0 Kudos
Highlighted
250 Views
Registered: ‎01-22-2015

@microdevel 

Would you still recommend using multicycle path constraints on that?
If you have implemented the "wait after switching the T-pin" (as you describe) then you have ensured that this path meets timing "by design".   You can now put a timing exception (set_max_delay -datapath_only) on the path so that the register driving the T-pin is held near the T-pin and timing analysis will no longer complain about the path.

The other thing was that in no way tools were able to pack the Tristate FF in the IOB.
I struggled with this over the years using 7-Series devices.  It is possible to do this with 7-Series devices, but some versions of Vivado made it difficult (see <this> post).

There are different ways of packing a register into the IOB.  You can place the IOB=TRUE property on the register itself or you can place it on the port that is connected to the register.  For each of these ways, you can use a Tcl constraint in the xdc file of the Vivado project or you can use an attribute statement in your HDL.  Depending on the version of Vivado, some of these ways work and some don't.   So, try them all for your UltraScale device and you may find that one works.

 

 

 

0 Kudos
Highlighted
Visitor
Visitor
131 Views
Registered: ‎10-16-2020

Thanks for help, ive now come up with the following constraints:

set_false_path -from .../lvds_t_r_reg/C -through .../IOBUFDS_inst -to .../lvds_din_r_reg/D
set_max_delay 1 -datapath_only -from .../lvds_t_r_reg/C -to .../IOBUFDS_inst/T

The design works and the Timing is closed.

0 Kudos
Highlighted
113 Views
Registered: ‎01-22-2015

@microdevel 

I’ve done some testing of IOBUFDS using Vivado v2018.3 and a Kintex UltraScale+.   I tried VHDL attribute statement and Tcl constraints on both the register feeding the T-pin of IOBUFDS and on the LVDS port connected to IOBUFDS – and (as you said) it does not seem possible to pull the register feeding the T-pin of IOBUFDS into the IOB.

I know you have modified your HDL so that the timing path through the T-pin of IOBUFDS will pass timing analysis "by design".  Your HDL modification assumes that it takes about 890ns=TOUTBUF_DELAY_TD_PAD to switch the T-pin of IOBUFDS.  To ensure that your assumption of 890ns remains correct, the register feeding the T-pin of IOBUFDS needs to be held near the IOBUFDS.  Also, you want a timing exception telling Vivado to not perform full timing analysis on the path through the T-pin.  Fortunately, set_max_delay -datapath_only can do all of this for you. 

You have used both a set_false_path and a set_max_delay -datapath_only constraint.  I think you will find that the set_false_path is overwriting the set_max_delay -datapath_only – because set_false_path has higher priority (see Chapter 7 of UG903(v2020.1)).

I recommend that you use only the set_max_delay -datapath_only constraint and it will look something like the following for you:

 

set_max_delay 895 -from [get_pins {lvds_t_r_reg/C}] -to [get_pins {lvds_din_r_reg/D}] -datapath_only

 


Note that the above constraint defines a valid timing path and that 895 if a little more than the value, 890=TOUTBUF_DELAY_TD_PAD, from Table 28 of the datasheet, DS893(v1.12).

Cheers,
Mark

0 Kudos