Understanding input/output constraints in a FPGA

[pigtwo]

Hello all,

I've been working on rounding out some of my knowledge of FPGAs so I've been trying to understand all the common constraints used.  One I'm having a little trouble with the OFFSET constraint in regards to inputs and outputs.  My basic understanding of why OFFSET is used is to compensate for delays on inputs/outputs that happen outside of the FPGA.  Is this correct?

Assuming the above was correct, an example of OFFSET being used would be when I have an external clock that drives logic in the FPGA and clocks an external chip which communicates with the FPGA.  So say I have a data line between the FPGA and the external chip.  The OFFSET constraint would allow me to compensate for the travel time between the FPGA and external chip.  Correct?  Or am I misunderstanding this.  To further the example, say the clock arrives at the FPGA and external chip at the same time.  Then say the path from the FPGA to the external chip is 10ns.  I would put this 10ns in for my OFFSET constraint(ignoring the more complex syntax) which would tell the FPGA that it needs to compensate for 10ns of travel time.

In the above example the data could be going in either direction.  If the FPGA is writing, it just needs to get the data to the pad 10ns earlier than without the constraint.  And if the external chip is writing then the FPGA has to assume the data is arriving 10ns late(IE behind the clock).  Please correct me if I'm wrong somewhere.

Where I get a little confused is how you can determine the constraint value.  How do you figure out how much delay there is?  Is it measured or just calculated? 

One final scenario, say an external clock is given to the FPGA.  Then the FPGA drives another chip giving it both the data and the clock as its outputs.  In this case I shouldn't have to use the OFFSET constraint because the data and clock will arrive at the external chip at the same time(IE in phase).  Correct? 

But in the opposite scenario where the FPGA is driving the clock but reading the output from the external chip I actually have twice the delay because I have to wait for the clock to get to the external chip then the data from the external chip to get back to the FPGA. 

I think I have the basic gist of it but I've started to think about it for too long and confused myself. 

Thank you for any input!

[a59d1]

Usually, timing inside the FPGA is solved by the place and route during implementation. AIUI, the timing offsets at IOs are generally for adjustments like skew, i.e. to compensate for traces outside of the FPGA being of incorrect lengths.

[radar_macgyver]

That's mostly correct.

Let's look at the case where an external device is driving a signal 'A' (synchronous to a clock 'CLK') into an FPGA input. Inside the FPGA, we must use CLK to clock a flip flop FF1 whose D input is connected to the IO pad. The output of FF1 is another signal 'B' that goes to a second FF (FF2), also clocked by CLK. The signal has some propagation delay from the IOB to FF1, let's call that t_PD1. Delay from FF1 to FF2 is t_PD2. Each FF's outputs change state t_CO after the clock edge - this is the clock to out time.

When you apply a PERIOD constraint to the CLK signal, you are telling the FPGA tools what the clock period of CLK is, so that any signal always arrives at a FF within some setup time of the next clock edge. In our example, the tools would ensure that t_CO (of FF1) + t_PD2 + t_SETUP is always less than t_PERIOD. This is easy enough for signals that stay inside the FPGA, since t_HOLD t_CO is well known.

An OFFSET IN constraint is the equivalent of specifying t_CO of the device that is driving the signal 'A', plus any propagation delays of the circuit board trace carrying that signal. Once this is known, the tools can ensure that t_OFFSET + t_PD2 + t_SETUP is less than t_PERIOD, and if this is not feasible the tools let you know by failing timing.

https://www.xilinx.com/support/answers/10020.html

You will need to know the value of t_CO of the device driving the FPGA, and also the board delays. Board delays can be calculated from signal integrity analysis. For the most part, you won't need to specify OFFSET constraints unless you're dealing with rather high speed signals (like a wide parallel bus) but even there they can be skipped unless your board is messing up. I've done designs at ~200 MHz that didn't need any OFFSET constraints. The rule I follow is to always use FFs in the IOB, which makes the delay time (t_PD1 in the example) fixed and very small. It is however always a good idea to add a PERIOD constraint based on actual clock frequencies. In either case, the constraints are not used to 'adjust' any delays, they are merely constraints to pick an optimum solution for placement and routing.


Now one might ask why a similar thing doesn't occur with the CLK signal - it does, but the CLK signal is assumed to be input into the device using a global clock input, and clocked to all device FFs using the global clock tree. If that's true, then the skew between the CLK IOB and the input to each FF is carefully controlled and known to the place-and-route tools and can therefore be subtracted out of all the measurements. In other words, the constraint is actually (t_CO + t_PD + t_SETUP) < (t_PERIOD - t_CLOCKSKEW). In some cases, t_CLOCKSKEW can be made zero, by using the Digital Clock Managers (or MMCMs in newer devices) to implement a zero delay clock buffer.

Also, when you drive a clock off chip, you should use a DDR FF in the IOB (ODDR2) with C0 and C1 fed clocks 180 degree out of phase, D0 = '1' and D1 = '0'. This ensures that the clock skew between the internal clock net and the IOB pad is both minimized and deterministic. Otherwise, the clock signal ends up taking a random route from somewhere inside the FPGA to the IOB, which changes each time your resynthesize. If you do this, and make sure your data signal goes through output FFs in the IOBs the skew between them will be minimal and deterministic.

Edit: fixed notation

[pigtwo]

Your description definitely makes it much more clear to me.  Thank you for the detailed post. 

A couple more things I'm a little unclear about:
1. Do you need to compensate for the skew of the external clock.  Say, for example, the clock source is much closer to the external chip than it is to the FPGA.  The clock would be arriving late to the FPGA and thus the data would leave late from the FPGA.   Should this be compensated for also using the OFFSET constraint?

2. Consider something like an ADC with an SPI interface driven by a FPGA where the FPGA drives the SPI clock with the internal FPGA logic clock.  In this case the SPI clock output is really just a data line because it isn't what's actually clocking the FFs in the ADC.  But the ADC won't clock any data out to the FPGA until the rising edge of the ADC clock reaches the ADC.  So I have to wait until the SPI clock reaches the ADC then for the ADC to output its data and finally for that data to reach the FPGA again.  The sum of all of that would be my OFFSET value(t_CO).  Is that the basic idea of how you would do a calculation for the OFFSET value for an SPI interface?

I ask because I've been doing job interviews focusing on FPGAs and I frequently get asked about what constraints I put on my IO.  Currently I do none(other than basic location and voltage level) and everything works fine but I only go up to 50-100MHz.  Most of my projects don't have external chips clocked from the same clock as the FPGA.  Most of them are like the SPI interface described above. 

[kony]

Just $0.02 note about sourcing clock from FPGA - bad idea if it is data converter sampling clock or anything sensitive to jitter. Dedicated (cheap) PLL or XCO is usually at least five times better.

[pigtwo]

Just $0.02 note about sourcing clock from FPGA - bad idea if it is data converter sampling clock or anything sensitive to jitter. Dedicated (cheap) PLL or XCO is usually at least five times better.

I would assume that this doesn't apply for thing where you need a gated clock.  Like an SPI interface.  Or maybe a slower clock that the FPGA can generate.  But for the situation like the one in the link radar_macgyver linked I see why it would be bad to bring that into the FPGA first then output it to everything else. 

[Bassman59]

Also, when you drive a clock off chip, you should use a DDR FF in the IOB (ODDR2) with C0 and C1 fed clocks 180 degree out of phase, D0 = '1' and D1 = '0'. This ensures that the clock skew between the internal clock net and the IOB pad is both minimized and deterministic. Otherwise, the clock signal ends up taking a random route from somewhere inside the FPGA to the IOB, which changes each time your resynthesize. If you do this, and make sure your data signal goes through output FFs in the IOBs the skew between them will be minimal and deterministic.

Another reason to use the output DDR flip-flop is that on some FPGA architectures, you can't even route from the global clock net to an output pin.

[radar_macgyver]

1. Do you need to compensate for the skew of the external clock.  Say, for example, the clock source is much closer to the external chip than it is to the FPGA.  The clock would be arriving late to the FPGA and thus the data would leave late from the FPGA.   Should this be compensated for also using the OFFSET constraint?

You will need to take the difference between the clock edge at the global clock input pad and the data edge at the input pad. Both these numbers can be obtained from SI analysis. In case the data takes multiple clock periods to reach the FPGA, one must only take the delay modulo the period of the clock.

2. Consider something like an ADC with an SPI interface driven by a FPGA where the FPGA drives the SPI clock with the internal FPGA logic clock.  In this case the SPI clock output is really just a data line because it isn't what's actually clocking the FFs in the ADC.  But the ADC won't clock any data out to the FPGA until the rising edge of the ADC clock reaches the ADC.  So I have to wait until the SPI clock reaches the ADC then for the ADC to output its data and finally for that data to reach the FPGA again.  The sum of all of that would be my OFFSET value(t_CO).  Is that the basic idea of how you would do a calculation for the OFFSET value for an SPI interface?

I suppose - except that all the SPI interfaces I've implemented don't treat the SCK line as a 'clock' line, they are always a fraction of the FPGA clock frequency. For example, if my FPGA clock is 100 MHz, I would implement an FSM that produces SCK from transitions between states. At the appropriate state, a shift register is enabled to clock data from the peripheral.

In any case, the ADC would use SCK to clock a set of FFs that form a shift register to hold the data from the FPGA. The data sheet would specify the setup and hold time requirements for the data line with respect to SCK, so thats what you would use for the OFFSET OUT constraint. From the attached timing diagram for an ADS1118 SPI ADC, that would be t_DIST (note: it's to the falling edge of SCLK). In the other direction (ADC to FPGA) the OFFSET IN constraint would be obtained from t_DOPD.

I ask because I've been doing job interviews focusing on FPGAs and I frequently get asked about what constraints I put on my IO.  Currently I do none(other than basic location and voltage level) and everything works fine but I only go up to 50-100MHz.  Most of my projects don't have external chips clocked from the same clock as the FPGA.  Most of them are like the SPI interface described above.

Yes, in such projects you would rarely need to specify OFFSET constraints. You would do well to include a PERIOD constraint as I mentioned earlier. Adding the OFFSET constraints, (especially generous ones like for the ADS1118) won't do any harm, but you will generally not need them.

Just $0.02 note about sourcing clock from FPGA - bad idea if it is data converter sampling clock or anything sensitive to jitter. Dedicated (cheap) PLL or XCO is usually at least five times better.

Usually applies to data converters used to sample RF/IF. The clock trees inside FPGAs are quite noisy and clocks output from FPGAs are not suited for this. This is also why FPGAs with gigabit transceivers have dedicated clock inputs.