Spartan® Family FPGAs

[watman]

It's just irritating that it _should_ work without a PLL.

When I have more time I'll try again without the PLL and modify the counter logic to reset everything when there's no clock.

Things probably just got into a wierd state when the clock stopped and restarted before.

[eteam00]

I'm guessing there is more at play than simple PLL vs. no PLL.

Clock vs. data timing, combined with clock buffering and distibution, are likely to be of major consequence.  The ability of the PLL to phase align the (buffered and distributed) sampling clock to the input clock (at the IBUFG output) is a significant simplification of the distribution skews.

I assume that you are not using the IDELAY2 dynamically variable input delay blocks to align the input data to the IO clock.

-- Bob Elkind

[watman]

I assume that you are not using the IDELAY2 dynamically variable input delay blocks to align the input data to the IO clock.

No just an IBUFG. I am testing with a 20MHz input clock, the data is perfectly aligned, and the electrical path is only 20mm so I don't think an IDELAY2 should be needed. I know there will be some skew, but 20MHz is very slow compared to what the FPGA can do.

[eteam00]

No just an IBUFG. I am testing with a 20MHz input clock, the data is perfectly aligned, and the electrical path is only 20mm so I don't think an IDELAY2 should be needed. I know there will be some skew, but 20MHz is very slow compared to what the FPGA can do.

In the Static Timing Report, what are the "datasheeet" numbers for input data vs. input clock?

How do they compare with actual (worst-case) data vs. clock timing as measured with a 'scope?  If they match up, you should have no problem -- and the head-scratching begins.

-- Bob Elkind

[bassman59]

---

watman wrote:

I guess I'm not clear on why you need a DCM (or a PLL) at all. I assume that the clock is synchronous with your incoming sensor data. If you're not using frequency synthesis or other DCM features, then you don't need a DCM.

That is what I thought, and what I originally tried. On an oscilloscope I can see that data is stable on the rising edge of the clock, but the image data received by the FPGA was pretty messed up. Adding the DCM/PLL fixed it immediately.

The image is processed a bit (interpolation of bayer pattern etc) using the pixel clock before it is FIFOed, would it maybe be better to just capture the data then FIFO it immediately and process it with another clock?

Daniel

---

Oh, it sounds like you're not meeting input setup without the DCM -- was the DCM providing delay/phase shift? If it wasn't, then the DCM output would line up with the DCM input and you would still lose. 

Instead of the DCM, use a simple input delay on the clock so that the rising edge of the clock is in the middle of the bit time. I'm working with an image sensor which does exactly that -- the serial data bits are output on a DDR clock and the bits change coincident with the clock. Adding a few nanoseconds of delay on the clock put the sample point where it needed to be.

[watman]

In the Static Timing Report, what are the "datasheeet" numbers for input data vs. input clock?

How do they compare with actual (worst-case) data vs. clock timing as measured with a 'scope?  If they match up, you should have no problem -- and the head-scratching begins.

I couldn't find info on the input data/input clock in the static timing report, and I realised that there isn't a timing constraint on that clock! I have been developing this project in modules and must have forgotten to copy the UCF into the larger design.

Perhaps the only effect of the DCM/PLL was to add a timing contraint to the clock net...

I have added a constraint at the highest expected clock frequency now.

Oh, it sounds like you're not meeting input setup without the DCM -- was the DCM providing delay/phase shift? If it wasn't, then the DCM output would line up with the DCM input and you would still lose.

The data is SDR so I wasn't using a phase shift, it shouldn't be necessary right?

On an oscilloscope I can see the data changes on the falling edge, so sampling on the rising edge with no delay should be perfect I would think (?).

[eteam00]

Oh, it sounds like you're not meeting input setup without the DCM -- was the DCM providing delay/phase shift? If it wasn't, then the DCM output would line up with the DCM input and you would still lose.

The data is SDR so I wasn't using a phase shift, it shouldn't be necessary right?

Reading this makes me cringe.  Setup and hold time (data input timing with respect to the register clock edge) must be observed equally for SDR (a single clock edge is used) and DDR (both clock edges are used) interfaces.  Agreed?

On an oscilloscope I can see the data changes on the falling edge, so sampling on the rising edge with no delay should be perfect I would think (?).

The only timing comparison which is important is inside the FPGA at the input registers.  Without knowing the clock frequency and the path delays from package pin to input register (for both clock and data), setup and hold time cannot be calculated or evaluated.

• At very low clock frequencies, the internal delays will be insignificant, and timing should be safe.

• At very high frequencies, the internal clock delay is enough to shift the clock edge to the point where data is switching, which will guarantee inconsistent and indeterminate behaviour.

-- Bob Elkind

[watman]

Setup and hold time (data input timing with respect to the register clock edge) must be observed equally for SDR (a single clock edge is used) and DDR (both clock edges are used) interfaces.  Agreed?

Yes I agree, what I meant was that SDR data is already aligned with the rising edge of the clock in the middle of the data. So I thought that no additional alignment would be needed...

I replaced the PLL with an IBUFG and added a timing constraint, but now I am getting 2 timing errors which seem to be due to very high skew and I don't understand why:

 Paths for end point CAM_IN/DISP_SEL/data_B_b_6 (SLICE_X23Y103.C5), 31 paths
 --------------------------------------------------------------------------------
 Slack:                  -1.317ns (requirement - (data path - clock path skew + uncertainty))
   Source:               CAM_IN/CALC_GRADS/GRADCALC/GRAD_Y_4 (FF)
   Destination:          CAM_IN/DISP_SEL/data_B_b_6 (FF)
   Requirement:          12.500ns
   Data Path Delay:      4.580ns (Levels of Logic = 4)
   Clock Path Skew:      -9.202ns (4.261 - 13.463)
   Source Clock:         CAM_IN/CLK_1 rising at 0.000ns
   Destination Clock:    PCLK rising at 12.500ns

The clock goes to an IBUFG -> PCLK, and everything in CAM_IN uses PCLK.

In the map messages there is a warning which seems to be repeated for all the modules clocked by PCLK:

PhysDesignRules:372 - Gated clock. Clock net CAM_IN/CLK_1 is sourced by a combinatorial pin. This is not good design practice. Use the CE pin to control the loading of data into the flip-flop.

I don't know what this "combinatorial pin" is, the clock comes from a clock-capable pin straight to an IBUFG then to the clock input. I assume CLK_1 is the clock going into the CAM_IN module, but that is PCLK. Any ideas what might be going on?

[eteam00]

The largest part of the problem is the 9nS or so of clock interconnect skew.

Are the data input registers located in the FPGA fabric, or in the IO blocks?

• If they are in the IO blocks in a single IO bank, then use a BUFIO2 to buffer and distribute the input clock.
• If they are in the main fabric logic, then use a BUFG to buffer and distribute the input clock.

An IBUFG is not a clock distribution buffer.  It is only a plain IBUF input buffer, with an additional constraint that it be located at a GCLK pin.  The output of an IBUFG (or IBUF) is a simple logic signal.  Either a BUFIO2 or BUFG will be needed to provide low-skew clock distribution.

-- Bob Elkind

[watman]

An IBUFG is not a clock distribution buffer.  It is only a plain IBUF input buffer, with an additional constraint that it be located at a GCLK pin.

Oh I see I misunderstood the function then, I thought it was the same as a BUFG but connected to an input pin.

Changing that fixed the clock skew, thanks for the information.

Daniel