Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
16 years ago

Cyclone 3 DDR2 controller - capture clock FIFO

Hello,

I'm using the Cyclone III 3C120 eval.board to evaluate a design for a customer. I am planning to use my own DDR2 controller using a capture clock, in a similar way to what it's explained in this app:

"cyc3_ciii51009.pdf" (I can't post the link :( because I'm new to the forum)

This doc says in page 11:

"The data from the DDR input register is fed to two registers, sync_reg_h and sync_reg_l, then the data is typically transferred to a FIFO block to synchronize the two data streams to the rising edge of the system clock"

That's fine... but how do you know when you "push" data into the FIFO? The DQS signals are markers to indicate when the data from the DDR2 to the FPGA is valid... but this app. doesn't use DQS when using a "capture clock". So do you just push data into the FIFO continously...? Do you pipe the RD command sent to the DDR2 in the CK clock domain and use it to qualify the data read...?

Any help is greatly appreciatted.

Thanks in advance,

-Ulises

4 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    Yes, you basically have to know when to expect the read to know when to capture data. The Altera generated DDR2 controller provides you with an open-source datapath so you can see exactly how they do it.

    Jake
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    Thanks for your quick response Jake,

    But how do u know when to expect the data? I suppose you either:

    a) use DQS as an input (Altera doesn't use it when using the capture clock, so there must be another way).

    b) use a pipelined version of the RD command (issued in the system clock domain) then transfer it to the capture clock domain, which doesn't seem safe as you need to cross a clock domain which could add/delete an extra clock cycle in case of metastability.

    I've had a look at the Verilog code of Altera's DDR controller, unfortunately I'm a VHDL guy and can't follow it... :(

    Regards,

    -Ulises
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    Keep in mind that there is only a phase difference between your system clock and capture clock. You should continually pass data through the FIFO ("push" and "pop" on every clock). You just need to know (in the system clock domain), the latency between when you expect the read data and when it actually arrives (the output of your FIFO). You discard any samples between valid samples.

    So yes, pipeline your RD command (or an expect command from your controller). Then you just need to do the work to find out when valid data arrives back in the system clock domain. By the way, that latency may change depending on frequency.

    Coincidentally, I've never used the FIFO approach. I've always used a 3rd clock (resync clock) between the capture and system clock domains. But the FIFO would actually likely be easier.

    Jake
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    Thanks Jake,

    Ok, so I issue a RD command, pipe it a fix number of clock cycles (based in 1: the DDR2 CAS Latency, 2: the number of cycles that takes to cross the asynchronous FIFO and 3: tAC, tco and a few other delays). Let's say it's 6 system clock cycles, at that point I set "RD_VLD" and mark the data popped from the FIFO as valid. In parallel with this the calibration logic is adjusting the phase of the capture clock, once calibration is done we should ideally have:

    - a fixed phase offset between the capture clock and the system clock

    - a fixed pipeline length for the RD_VLD signal

    uhmm, 2 questions here:

    a) the number of system clock cycles that takes for a data to cross the asynchronous FIFO, is it fixed?

    b) do we need to change the RD_VLD pipe length as part of the calibration process? SLOW and FAST corner models vary a lot in timing, maybe more than a whole DDR2 clock, so I was wondering if a FAST silicon could actually sample the data one clock earlier than an SLOW silicon, i.e. the calculation of 5 system clocks for RD_VLD could be for a FAST corner models and maybe 6 for a SLOW corner model. So the calibration should run a 1st phase shifting cycle with a pipe of 5 and a 2nd (if needed) with a pipe of 6...

    Regards,

    -Ulises