Xilinx DCM Reset

I have been reading through UG331 for information on the DCM, especially in the case with external clock feedback. On a previous project we used a Microblaze with an SDRAM controller, but did not have the external feedback. On this project, I have the board designers giving me a feedback clock path so I can deskew the SDRAM signals with a DCM.

The basic setup is (forgive the ASCII art; you probably need a fixed font to see it correctly):

+-----------------+ +------------------+ +-------+ clk -->| CLKIN CLK90 |-+--->| CLKIN CLK0 |--->|> | | DCM | | | DCM | | DDR Q|--
sdram clk
+->| CLKFB | | +->| CLKFB CLK180 |-->o|>

| | | +-----------------+ | | +------------------+ +-------

  • | | | | | +----------------------+
+------------------------------------------+

This follows the recommendation on p. 7 of DS492 (the MC OPB SDRAM Controller) in the EDK. The addition of the DDR register was a suggestion from our FAE and follows the recommendation on p. 111 of UG331. The DDR register is packed into the I/O and gives a clean, sharp clock signal.

The issue is how to reset the second DCM appropriately to make sure it locks onto a clean signal. I understand the need for the SRL16, so that the SDRAM DCM can get a clean lock. However, on p. 101 of UG331, Figure 3-19 shows the clock to the SRL16 being connected to CLKIN. At high speeds (100MHz or so) it only takes 160ns for the SRL16 to clear out. This means from the time from the end of the startup sequence to GTS deasserting must be less than 160ns. However, I cannot find any reference to the actual time from DCM startup to GTS deassertion.

It seems to me that the SRL16 in Figure 3-19 should be clocked by the feedback clock. This way the reset pulse occurs after the feedback clock is present, which is after GTS deasserts.

Any thoughts?

Reply to
pladow
Loading thread data ...

pladow,

Use the Locked signal from the first DCM to release resetting the second DCM.

Locked ---> invert -----> Reset

Austin

Reply to
austin

That is what we were doing. However, the input clock, clk, and the associated DCM may lock before GTS is released. As such, the second DCM may try to aquire before the feedback clock is present.

I guess the real question is: "How long after GSR is GTS released?" This really determines how long to wait until the reset on the second DCM should released.

Reply to
PlayDough

PlayDough,

I don't see the issue: If the DCM locks, that implies that everything is present in order for it to lock.

Austin

Reply to
austin

That's precisely the problem: everything is not necessarily there for it lock, i.e. the feedback clock.

I am using external feedback. That is, the sdram clock is output to the SDRAM, then fed back into the FPGA and finally to the DCM. Since the sdram clock is an output, it is not driven until GTS is released. If GTS is released during the DCM aquisition, then it can lock incorrectly.

"Why is this extra reset pulse required? For an optimum locking process, a DCM configured with external feedback requires both the CLKIN and either the CLK0 or CLK2X signals to be present and stable when the DCM begins to lock. During the configuration process, the external feedback, CLKFB, is not available because the FPGA's I/O buffers are not yet active.

At the end of configuration, the DCM begins the capture process once the device enters the startup sequence. Because the FPGA's global 3- state signal (GTS) still is asserted at this time, any output pins remain in a 3-state (high-impedance, floating) condition. Consequently, the CLKFB signal is in an unknown logic state. When CLKFB eventually appears after the GTS is deasserted, the DCM proceeds to capture. However, without the reset pulse, the DCM might not lock at the optimal point, which potentially introduces slightly more jitter and greater clock cycle latency through the DCM.

Without the reset, another possible issue might occur if the CLKFB signal, while in the 3-state condition, cross-couples with another signal on the board due to a printed-circuit board signal integrity problem. The DCM might sense this invalid cross-coupled signal as CLKFB and use it to proceed with a lock. This possibly prevents the DCM from properly locking once the GTS signal deasserts and the true CLKFB signal appears."

Reply to
PlayDough

PlayDough,

Yes, external source of CLKFB requires that you tell the (first) DCM when to LOCK.

You need to provide a reset signal, that informs the DCM when the CLKFB signal is present, and valid.

If you do this with a counter, or SRL, you need to be sure your counter is long enough, or SRL's are long enough, or clocks are slow enough to account for the time required.

The configuration is not smart enough to know when an external signal is 'good'.

Austin

Reply to
austin

And how long is that (ignoring any issues external to the FPGA)? How long is it from when configuration is complete until GTS is released? Given my clock frequency I can derive how long to hold the DCMs in reset after configuration. I just can't find a spec anywhere on the Xilinx website that says how long after configuration that GTS is released.

The problem is that the documentation seems to think that 16 clock cycles is enough. But without reference to frequency, I don't know how long that actually is. In fact, I found reference to this in Xilinx Answer Record #14425 (see

formatting link
, and this hints at 4 clocks. But when running at, say, 200 MHz, this is only 20ns! What clock frequency are they assuming when the say that 4 clocks is enough?

Absolutely. However, Xilinx should be able to specify how long after configuration the GTS is released. Take this number, add some pad to account for the delay before the feedback clock has a chance to stablize, and keep the DCMs reset until this occurs.

Reply to
PlayDough

PlayDough ,

page 234,

formatting link

details the start up sequence. If you use the default, and you must not wait for DCM to LOCK (as they won't), then you need to know the CCLK rate, and you will see the delay from GTS. Table 12-7. The state machine for the start up progresses as shown. Using bitgen options, you may re-arrange the start up sequence, if for some reason you wish one even to happen before another (should have a really good reason, however, as the default sequence is the easiest to debug and understand because it is the default).

Inputs are active before GTS is released (GTS affects outputs).

If the feedback is from an output of the device, back to an input, then you also need to know how long it takes from GTS is released, and the output is toggling, until the feedback comes back into the input. Is there an external buffer, PLL, or other component in series with the feedback path?

Essentially, once GTS is released, one may assume that the output is immediately active.

Page 235 details the source of the startup clock (CCLK is the default).

Austin

Reply to
austin

As you may see,

Even delaying a few clocks after GTS is released should be completely adequate for the feedback signal to get back into the device, unless an external PLL or other component is in series. Speed of light on pcb wires is pretty fast...

Hence the reason why the SRL16 solution is considered "bulletproof" for just about every design requiring any delay at all.

Austin

Reply to
austin

Thank you! This is what I was looking for.

This I understand. I do NOT have STARTUP_WAIT set on any of the DCMs.

And looking at Figure 12-12, it makes sense that even 1 CCLK would be adequate. Since GWE is released after GTS, the reset SRL16 won't even begin clocking until 1 CCLK after GTS is released. Thus it allows for the feedback clock to stabilize.

Thank you very much for your help! That is the exact information I was looking for.

Pete

Reply to
PlayDough

PlayDough,

No problem. Sorry it took so long to find what you needed.

Austin

Reply to
austin

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.