UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Visitor kiliaa01
Visitor
600 Views
Registered: ‎02-06-2019

IOBUFDS "T" input related timing violation

I have a timing error thru an IOBUFDS. I have a clk and data serial interface (both differential) I'm forwarding outside my FPGA. Data is bi-directional

For the clock, i use an ODDR + OBUFDS combo for forwarding. I have a "create_generated_clock" constraint on this clock with source being the output ("C") of the ODDR. Since this clock is used to clock the capturing device (external to FPGA), I also have "set_output_delay" constraints account for setup/hold times of the capturing device

For data, I use an IOBUFDS. The timing violation is from the source FF of the tri-state "T" input on the IOBUFDS to the output port of the IOBUFDS as illustrated below. I think this is a valid path, so I don't want to ignore it. I have tried various techniques to close this violation to no avail. Any thoughts?

Capture.JPG
0 Kudos
4 Replies
Historian
Historian
590 Views
Registered: ‎01-23-2009

Re: IOBUFDS "T" input related timing violation

In general this path is real and cannot be ignored...

But you haven't showed us much - to help we need to see:

  • The family, device and speedgrade you are using
  • The constraints (you described them, but it would be best to see the actual constraints)
  • The detailed timing report of the failing timing path - this is really the most important
  • The schematic always helps (which you supplied)
  • A description of the destination device - the datasheet would be best, but at least a description of the interface;
    • SDR/DDR? Source/System synchronous (you seem to indicate source)? Data in one direction only or in both directions?

But, assuming that this is a clock forwarded interface (although clock forwarded interfaces with tristate data are an unusual combination), then how are you handling the data - are you trying to put the output flip-flops in the IOB? Is the other path (through the I) passing? If so, then it is likely a problem with getting the enable flip-flop into the IOB. The IOB does have a flip-flop for the enable path (there are 3 sets of logic resources in the IOB - one for the input path, one for the data output path and one for the enable path). However, it can be a bit complicated to get the enable flip-flop into the IOB.

First (and most often the problem) there must be one enable flip-flop per output pin. The enable flip-flop for a given pin cannot go anywhere other than the T input of the IOBUF, so multiple pins cannot share an enable flop. Often if you have a bus of outputs, the enable is described as one register, regardless of the width of the interface - this prevents the tool from packing the enable FF into the IOB. So, you need your RTL to describe one enable flip-flop per output bit. But, even this can be complicated, since synthesis sees these as redundant flops and removes all but one, so you need to put a "DONT_TOUCH" attribute on the enable flip-flops. You also have to make sure that these enable FFs are not used for anything other than enabling the IOBUF - they cannot (for example) be used to enable the capture flip-flop (when not asserted).

If this isn't enough, you may need to put the IOB property on the enable FF. If your data FF is already in the IOB then you must already have the IOB property set on the port. However, the IOB property can also be set on a flip-flop; so you can explicitly set it on the enable flip-flops.

Avrum

0 Kudos
Visitor kiliaa01
Visitor
562 Views
Registered: ‎02-06-2019

Re: IOBUFDS "T" input related timing violation


@avrumw wrote:

In general this path is real and cannot be ignored...


Agreed!


@avrumw wrote:

But, assuming that this is a clock forwarded interface (although clock forwarded interfaces with tristate data are an unusual combination), then how are you handling the data - are you trying to put the output flip-flops in the IOB? Is the other path (through the I) passing? If so, then it is likely a problem with getting the enable flip-flop into the IOB.


Interface Data is not tristate, it's Bi-directional. Both Data and Clock leave my device as differential LVDS pairs so to accomodate this, clock (sourced by my device/Zynq) goes thru ODDR (to assure clocking resources are used) then an OBUFDS. Since Data is bi-directional, I route Data thru an IOBUFDS and this should mean that output flip-flops are in an IOB. I have an enable signal (control signal) that dictates the direction of Data (Input or Output); this control signal ("en_N" as shown on previous schematic) connects to the "T" input of the IOBUFDS.

And yes, the other path thru "I" of IOBUFDS is passing, see attached Table2_I_path.xls for details

Capture2.JPG


@avrumw wrote:
The IOB does have a flip-flop for the enable path (there are 3 sets of logic resources in the IOB - one for the input path, one for the data output path and one for the enable path). However, it can be a bit complicated to get the enable flip-flop into the IOB.

First (and most often the problem) there must be one enable flip-flop per output pin. The enable flip-flop for a given pin cannot go anywhere other than the T input of the IOBUF, so multiple pins cannot share an enable flop. Often if you have a bus of outputs, the enable is described as one register, regardless of the width of the interface - this prevents the tool from packing the enable FF into the IOB. So, you need your RTL to describe one enable flip-flop per output bit. But, even this can be complicated, since synthesis sees these as redundant flops and removes all but one, so you need to put a "DONT_TOUCH" attribute on the enable flip-flops. You also have to make sure that these enable FFs are not used for anything other than enabling the IOBUF - they cannot (for example) be used to enable the capture flip-flop (when not asserted).

If this isn't enough, you may need to put the IOB property on the enable FF. If your data FF is already in the IOB then you must already have the IOB property set on the port. However, the IOB property can also be set on a flip-flop; so you can explicitly set it on the enable flip-flops.


Enable flip-flop ONLY route to "T" input of IOBUFDS, nothing else is connected on the path (implementation schematic shows this as well). I tried to assure enable flip-flop was in an IOB by using the the constraint: set_property IOB TRUE [get_cells sio_en_N_Q_reg]. This however did not make a difference in my timing violation. I'll attempt this again with the "DONT_TOUCH" attribute as you indicated

 

 

 

 

0 Kudos
Visitor kiliaa01
Visitor
556 Views
Registered: ‎02-06-2019

Re: IOBUFDS "T" input related timing violation


@kiliaa01 wrote:

Enable flip-flop ONLY route to "T" input of IOBUFDS, nothing else is connected on the path (implementation schematic shows this as well). I tried to assure enable flip-flop was in an IOB by using the the constraint: set_property IOB TRUE [get_cells sio_en_N_Q_reg]. This however did not make a difference in my timing violation. I'll attempt this again with the "DONT_TOUCH" attribute as you indicated

 


I rebuilt the design with the set_property IOB TRUE [get_cells sio_en_N_Q_reg] constraint again, and the properties of the Enable Flip-flop (sio_en_N_Q_reg) shows IOB as true:

Capture4.JPG

but.....

the flip-flop doesn't appear to be om an actual IOB, just a standard SLICEM:

Capture3.JPG

0 Kudos
Visitor kiliaa01
Visitor
526 Views
Registered: ‎02-06-2019

Re: IOBUFDS "T" input related timing violation

@Avrum, have you seen my other replies?
0 Kudos