06-05-2013 03:07 PM
I know this question has been asked in many ways, but I think I have yet another twist.
I have a source synchronous edge-aligned DDR input at 125MHz (8ns period) that I am trying to properly constrain/implement. Assume that due to various external tolerances/skews the data at the FPGA pin can transition anywhere from 100ps BEFORE to 100ps AFTER a clock edge at the clock pin of the FPGA.
For setup time, the worst case would be if the data transitioned 100ps AFTER the clock edge, and so we could constrain this as:
OFFSET = IN -100 ps VALID 4 ns BEFORE clock RISING; OFFSET = IN -100 ps VALID 4 ns BEFORE clock FALLING;
However, for hold time, the worst case would be if the data transitioned 100 ps BEFORE the clock edge, so we could constrain this as:
OFFSET = IN 4 ns VALID 3.9 ns BEFORE clock RISING; OFFSET = IN 4 ns VALID 3.9 ns BEFORE clock FALLING;
My concern is that unless I am able to apply both constraints, it seems as if either the setup analysis or the hold analysis will not be perfomed under the worst case conditions. For instance, how do I know the hold timing under the first constraint won't be analzed to the first clock edge after which there is a comfertable 3.9ns of hold time provided at the input.
Also, given the specifications of this interface and a constraint that neither variable IDELAYs nor DCMs/PLLs can be used, is there a suggested implementation (for a Virtex-4) in order to optimize timing closure on this interface?
06-05-2013 05:48 PM
The constraint of this interface is relatively clear
OFFSET = IN -0.1ns VALID 3.8ns BEFORE clock RISING;
OFFSET = IN -0.1ns VALID 3.8ns BEFORE clock FALLING;
Thus it will become valid 100ps after the rising edge of clock, and remain valid until 100ps before the falling edge of clock, then become valid again 100ps after the falling edge of the clock and remain valid until 100ps before the next rising edge of clock.
The above constraints tell the tool that you are planning to capture the first data window with the rising edge of the clock and the second window with the falling - that you are planning to push the clock into the data window.
If, instead you use
OFFSET = IN 3.9ns VALID 3.8ns BEFORE clock RISING;
OFFSET = IN 3.9ns VALID 3.8ns BEFORE clock FALLING;
Then this specifies the exact same timing, but informs the tool that you are planning to capture the first window with the falling edge of the clock, and the second with the next rising edge of the clock - that you are planning to push the data over the next clock edge.
From a system point of view, this is pretty close to an idea interface - its actually somewhat hard to believe that the interface is this good. Have you factored in
- duty cycle of the clock - this assumes that the driving device and the FPGA both have perfect 50/50 duty cycle
- including the difference in edge rate of the clock if it isn't differential at the driver and receiver
- the variation in routing delay between the clock and data, including the length delay and the derating if they are not routed on the same layer of the PCB
- signal integrity derating for the signals...
As for your last question - if you can't use IDELAYs (on either the data or the clock) and you can't use PLLs/DCMs, I don't think there is any way to capture this interface - at least not with IOB FFs. If you use fabric flip-flops, the tool might be able to insert enough routing delay to make this work (using the second constraint) - in theory you could capture the input in both rising edge and falling edge flip-flops in the fabric. But I can't see how this would be preferable to using the IDELAY and the IDDRs.
The best way to capture this interface is to use the first constraints, have the clock on a clock-capable I/O, run the clock through an IDELAY to push it into the data window, then use a BUFIO to capture the data in an IDDR in the IOB.
06-06-2013 03:45 AM
Thanks Avrum, great response.
The timing parameters I had provided were intentionaly generic andnearly ideal only for the sake of simplicity. In fact, my worst case clock edge/data transition alignment is closer to -0.5ns to +0.28ns (data transition to clock edge). The 1/2 period of the source clock will range from 3.4ns to 4.6ns, while the 1/2 period of the capture clock (due to DCD of the BUFR) will range from 3.15ns to 4.85ns.
For simplicity though, let's stick with the numbers I gave before (100ps skew), but assume the 1/2 period of the source clock will range from 3.8ns to 4.2ns, and the1/2 period of the capture clock will range from 3.5ns to 4.5ns. This would then be constrained as follows (using you suggested constraints as a baseline):
# 3.8ns valid window reduced to 3.6ns to account for srsource clock pulse width
OFFSET = IN -0.1ns VALID 3.6ns BEFORE clock RISING;
OFFSET = IN -0.1ns VALID 3.6ns BEFORE clock FALLING;
I assume then that I should constrain this worst case duty cycle of my source clock in the clock period constraint so that ISE knows not to compare the 3.6ns valid window against an ideal 4ns 1/2 period (yeilding a -300ps hold timeinstead of the actual -100ps hold time). This would be done as follows:
NET "clk_in" TNM_NET = clk;
TIMESPEC TS_CLK = PERIOD clk 8.0 ns HIGH 3.8 ns;