Showing results for 
Show  only  | Search instead for 
Did you mean: 
Registered: ‎07-26-2013

Setup failure for IOB register


 I have a system in which a SOC sends source sync data to FPGA (Virtex7 330t) at 150MHz (6.667ns).

Considering the o/p pad delay of SOC and board routing, i allocated 5ns as set_input_delay to all input data paths.

set_input_delay -clock [get_clocks fxt_clk] 5 [get_ports fxt_tx_bus*] is the constraint in xdc.

Also the clock and data paths are lenght matched to have min or no skew.


I register the i/p bus multiple times in FPGA and ensure the first register is in IOB.


The input clock coming clock capable pin goes through a PLL and 150MHz is recovered.

The COMPENSATION attribute is set to "ZHOLD"


My expectation is that the recoverd clock should phase match the input clock and i should not have a Setup issues.

However the timing report shows a Setup slack of -1.7ns and Clock Skew of -2.5ns on input pads to IOB register path.


Attached is the snapshot of the same.

The data path delay is barely 0.64ns from pad to IOB.

So i would expect the setup timing to meet.

May i know if i am doing something wrong or i am just reading it incorrectly?






0 Kudos
3 Replies
Registered: ‎01-23-2009

So, a couple of things...


First, where did you get this 5ns set_input_delay - this seems WAY WAY too big for a source synchronous interface.


If the system is source synchronous, that means that the SOC generates the clock and the data through the same path; some clock internal to the SOC generates both the data going out and the clock going out using the same output resources. If this is the case then the skew between the forwarded clock and the forwarded data should be extremely small.


Your FPGA constraints should always be derived from your external devices and your board. So you need to go look at the datasheet for the SOC and find out how the data is spec'ed with respect to the clock. But in general you would expect a source synchronous interface to have the clock-to-data propagation be small numbers, with the min being negative and the max being positive. As an example, they would be Tpd_min=-1, Tpd_max=+1.



Lets say your board skew between clock and and data is very small (say +/-100ps), then this would translate to XDC constraints of


set_input_delay -clock <forwarded_clock>  1.1          [get_ports <forwarded_data]

set_input_delay -clock <forwarded_clock> -1.1 -min   [get_ports <forwarded_data]


The data arrives at the pin of the FPGA as early as 1.1ns before the rising edge of clock and as late as 1.1ns after the rising edge of clock.


By saying 5ns, you are saying the data arrives 5ns after the clock, giving it only 1.67ns to be captured.


Of course, this is an example only. Depending on what the SOC does, the numbers can be very different. For example, the SOC might do something to center the clock in the middle of the data window (in an SDR interface, this could be done by inverting the outgoing clock), which result in entirely different numbers. You MUST extract the timing from the SOC datasheet.


Second, you are specifically forcing the ZHOLD compensation. This is primarily intended for a system synchronous interface where you have to worry about hold time - it means "Zero Hold". What this does is intentionally change the PLL timing to bring the internal clock earlier (negative skew) to ensure that there is a 0 hold time requirement at the pin. While 2.5ns seems like a lot, that is what you are asking for. Since this reduces the hold time requirement for the pin, it, therefore, increases the setup time requirement for the pin (there is no free lunch).


For source synchronous interfaces, you specifically don't want ZHOLD.




0 Kudos
Registered: ‎07-26-2013

Hi Avrum,

 Thanks for the reply.So what you are saying is set_input_delay value is the DIFFERENCE between the clock edge and data launch.

I thought it is the amout of delay the data takes from being launched to FPGA pad input pin. (soc clk2out + pad delay of data is approx 5ns. But it is the same for the clock that comes with it).clock and data are launchd together.

So i realize that  set_input_delay value i should have given be like 1 ns at best because by design they are gaurateed to come together (min skew).

I shall fix that.


However, i think i disagree as to why ZHOLD value. As far as i understand PLL compensation attribute of ZHOLD is for source sync interface not for system sync interface.

Also can you explain the meaning of "While 2.5ns seems like a lot, that is what you are asking for" . How did i ask for 2.5ns of skew?


Thanks a lot!!


0 Kudos
Registered: ‎01-23-2009

So the "COMPENSATION" attribute in the 7 series is confusing. The User Guide says "Must be set to ZHOLD" - I don't know why (previous generations didn't do this).


It then goes to say "ZOLD: Indicates the MMCM is configured to provide a negative hold time at the I/O registers". Generally this is required for system synchronous interfaces. To guarantee negative hold times at the I/O it needs add some negative skew to the destination clock in order to ensure that it captures the data before it has a chance to change (that is how negative hold works). It does this at the expense of increasing the setup time required.


Unfortunately, it seems like you are not allowed to change the compensation (and none of the other compensation modes seem to make sense here), so you will just have to fix it by playing with the CLKOUTx_PHASE (or use the fine phase shift) to skew the clock to where you want it. This is generally required for a source synchronous interface; the SU/H requirement of the FPGA is rarely centered in the provided data window from the driving device, so you have to adjust the clock/data relationship between at the receiver.


As for the "what you are asking for" - its just the ZHOLD. By specifying ZHOLD you are asking for negative clock skew, which is not what you actually want here. But, as I mention above, you don't seem to have a choice...


As for the set_input_delay, it is really simple - you tell the tool which clock you are using as a reference for this input, and how much delay there is from that clock to that data. In a system synchronous interface (where the source device and the FPGA share the same clock source), then this would be determined by the clk2out + route_delay of the source device, but in a source synchronous interface, these are irrelevent (since, as you pointed out, the forwarded clock has the same attributes). So, when a device has a forwarded clock, it always should give you the forwarded clock to forwarded data skew - this is what you need to derive the set_input_delay for the FPGA.



0 Kudos