06-26-2017 07:19 AM
We are trying to better constrain our input SerDes lines, 580Mb/s DDR 14bit.
We have a solution that works, but yields glitches in the final data.
From wp237, we are going using the first option, to define the period than two input offset groups for rising and falling edges.
The example gives 3ns and -2ns for these offsets.
However I have a few questions.
1) That same white paper states that "If the clock that clocks a synchronous element does not come through an input pad – for example, it is derived from another clock – then the OFFSET constraint will fail to return any paths during timing analysis", therefore when we use the input SerDes clocking resources to generate the DDR clock, we wouldn't expect any analysis or even notification of a setup/hold violation.
2) From the same white paper, "The OFFSET constraint does not optimize paths clocked by an internally generated clock", if this is the case, what use is the offset constraint for the case of DDR SerDes. I can understand the logic, as the DDR clock runs on a dedicated internal line only to the IOB blocks of that bank, hence already optimized and quite static.
3) All our LVDS lines are matched to within 2.5mm with respect to the clock. So in terms of delays as a product of the UI we are talking 100s of ps rather than 2ns. We suspect impedance changes or differences, so the natural question is how to estimate the required offset input delay?
4) We are probably going to need to use the iDELAY resources to scan the delay until the glitches are not present. However it would be good to constrain as much as possible in the .ucf prior to going down this line as we have many many LVDS lines on this board.
06-26-2017 09:48 AM
First, this whitepaper is over a decade old. It isn't incorrect, but is written as a basic introduction to OFFSET constraints...
Looking at (what little) you have told us, though, this is probably not going to help you. This is on the Spartan forum board, so I assume you are using a Spartan-6. You have told us that you are trying to do 580Mbps (I presume that is 290MHz DDR). At this speed, each Unit Interval (UI - or bit period) is 1.7ns. Even assuming your sending device is "perfect" (i.e. there is no clock data skew and the clock data relationship is in the "perfect" place for the sampling flip-flops), this is bordering on (or past) impossible to capture statically, even in one of the faster speed grades. In all likelihood you will need to use some kind of dynamic capture for this interface (and dynamic capture interfaces don't use constraints).
This is either out of date or wrong. It is completely legal to define an OFFSET IN constraint with respect to a clock port of the FPGA, even if the clock goes through a DCM. The tools will propagate the clock through the DCM and time the input properly.
Again, same thing. You definitely can and should (when using static timing) define the DDR OFFSET IN with respect to the port of the FPGA, even if the DCM is used.
Determining the correct value for the OFFSET IN is based on a whole bunch of things outside the FPGA
- the clock to data skew on the device that is putting out the interface
- even the very best interfaces don't don't specify less than +/-100ps
- the traces on the board
- this includes not just trace length mismatch but
- signal integrity
- edge rates
- board variation across PVT (same layer)
- board variation across PVT (different layers)
- All of this probably needs spice or IBIS simulations to get "accurate" values for
- if you don't do this, then you need to put in margin
All of this ultimately means you have already lost a portion (maybe even a significant portion) of the 1.72ns you have in a UI
As I mentioned above, you will almost certainly have to use dynamic calibration at this speed. This is more than just choosing values of the IDELAY, but likely a mechanism to constantly adjust the value of the IDELAY to track PVT. Designing an "appropriate" scheme is complicated. Although for some applications, the "Phase Detector" describe in UG381 may be appropriate...
06-27-2017 01:03 AM
Thanks for letting me know that WP is so out of date.
The problem we are having actually looks like the below image. This is the data capture of a 14bit ADC using DDR SerDes. The input frequency is sinusoidal at 200kHz, which as you can see is certainly there rather than random samples all over the bit space.
Many of the bits are being received correctly, however periodically (matching the input frequency), we get two kinds of jump. One is on bit 10 yielding a jump of 1024, the other is on the MSB allowing the data to erroneously cross to the other side of the zero level (two's complement).
We have discussed solutions internally, having settled on the iDELAYs as a start. We know about dynamic capture, but that is a little more lengthy. In the mean time, I'll try to estimate some of the trace delays and see if it improves matters.