DDR3 initialization sequence issue

[promach]

besides, should I use DATAOUT , DATAOUT2 or DOUT ?

How shall the logic for CAL and INC inputs signals look like ?

Note: The RX pipeline is   RAM -> IOBUF (for inout)  -> IDDR2 (input DDR buffer) -> ISERDES   

[promach]

on page 72 of UG381 appnote, it says : Calibration takes between 12 and 20 global clock cycles depending on the ratio between the global clock and the I/O clock

If it is taking 12 cycles to just shift the dqs strobe to the center of dq bits, then it seems that IODELAY2 is not a suitable candidate to do this kind of high-speed DDR3 RAM work ?

Please correct me if wrong.

[NorthGuy]

I have a feeling that none of these two clocks should be used for port 'CLK' of IODELAY2 because READ DQS strobe itself is sort of already acting as clock activity.

CLK port is for the control logic, such as INC pin. You certainly cannot use DQS for this.

besides, should I use DATAOUT , DATAOUT2 or DOUT ?

How shall the logic for CAL and INC inputs signals look like ?

Note: The RX pipeline is   RAM -> IOBUF (for inout)  -> IDDR2 (input DDR buffer) -> ISERDES   

DATAOUT and DATAOUT2 are the same except for routing. You use DATAOUT for IDDR, but you would use DATAOUT2 if you wanted to route the signal to the fabric.

on page 72 of UG381 appnote, it says : Calibration takes between 12 and 20 global clock cycles depending on the ratio between the global clock and the I/O clock

If it is taking 12 cycles to just shift the dqs strobe to the center of dq bits, then it seems that IODELAY2 is not a suitable candidate to do this kind of high-speed DDR3 RAM work ?

You can do calibration at startup. You read a test pattern from the DDR3 chip and calibrate. Once it's calibrated, you can read the real data.

[promach]

As for CAL and INC input signals for IODELAY2 primitive during DQS centering calibration process,
how shall the logic for CAL and INC inputs signals look like ?

Strange, my current TX and RX pipeline paths do not fall under any of the categories inside the following table : Possible Clock Structures for Bidirectional I/O ?

RX :     RAM -> IOBUF (for inout) -> IDELAY (DQS Centering) -> IDDR2 (input DDR buffer) -> ISERDES      

TX :     OSERDES -> ODDR2 (output DDR buffer) -> ODELAY (DQS Centering) -> IOBUF (for inout) -> RAM

[promach]

Besides, in the case of DQS strobe centering, should I use VARIABLE_FROM_ZERO or VARIABLE_FROM_HALF_MAX for the attribute IDELAY_TYPE in IODELAY2 primitive ?

[promach]

@BrianHG

What do you exactly mean by "Even DQ Groups may be ignored, however, I still recommend wiring them properly" in your previous reply ?

[BrianHG]

When using the dedicated DQS clock circuitry inside the FPGA, each DQS group has a hard-wired 8 DQ pins which are paired with it.  Same with the DDR3 ram chip, there are 8 data bits for each each DQS pair.  When wiring and programing your DDR3 controller, you need to match each 8 bit DQ group with it's connected DQS since only those DQ's are wired to that 1 DQS input inside the FPGA.  This is where they get the ability to shift adjust timing specifically for each group of 8 data bits without having a PLL with another set dedicated tuned output for every 8 bits.

In my design, I do not derive the read DQ clock from the DQS inputs with it's dedicated wiring to the shared 8 DQ pins.  My DQ read clock is generated by the FPGA PLL instead, so, as long as all your inputs on your FPGA can be clocked by the PLL instead of the DQS inputs, any DDR input may be used with my controller.  The only caveat is that all your DQ and DQS wiring lengths to the DDR3 memory need to be fairly closely matched.  Otherwise, for every 8 bits, I would need a separately phase tuned PLL output where in a 64 bit system, this would mean 8 pll outputs for 8 read clocks as well as another 8 pll outputs for 8 write clocks.


The simplicity of my system using exclusive DDR in and DDR out buffers means easy cross vendor and cross FPGA type compatibility with the same code except for the DDR buffers and the tuning size step depending on pll precision.

[promach]

My DQ read clock is generated by the FPGA PLL instead

Sure, but this dynamic phase shift approach is not allowed due to some underlying PLL hardware limitations for Xilinx Spartan-6 FPGA chip.


By the way, why do I face the following tDLLK timing violation after MPR System Read Calibration is enabled ?

[BrianHG]

My DQ read clock is generated by the FPGA PLL instead

Sure, but this dynamic phase shift approach is not allowed due to some underlying PLL hardware limitations for Xilinx Spartan-6 FPGA chip.

I don't think so.
You are probably using a buffer or peripheral which is not compatible with it, or, the buffer/peripherals you are using are actually using the feature behind your back to achieve their function, so, they wont let you do it manually.

[NorthGuy]

As for CAL and INC input signals for IODELAY2 primitive during DQS centering calibration process,
how shall the logic for CAL and INC inputs signals look like ?\

For example, you can use INC and CE to go through all possible values of the delay and find the best position.

Besides, in the case of DQS strobe centering, should I use VARIABLE_FROM_ZERO or VARIABLE_FROM_HALF_MAX for the attribute IDELAY_TYPE in IODELAY2 primitive ?

It depends on path delays. The best way is to determine this empirically  when you have your design.

Strange, my current TX and RX pipeline paths do not fall under any of the categories inside the following table : Possible Clock Structures for Bidirectional I/O ?

RX :     RAM -> IOBUF (for inout) -> IDELAY (DQS Centering) -> IDDR2 (input DDR buffer) -> ISERDES      

TX :     OSERDES -> ODDR2 (output DDR buffer) -> ODELAY (DQS Centering) -> IOBUF (for inout) -> RAM

These are data paths. The table lists the clock source.

BTW: You use either IDDR or ISERDES (similarly either OSERDES or ODDR), but not both.

[BrianHG]

By the way, why do I face the following tDLLK timing violation after MPR System Read Calibration is enabled ?

You must fully initialize the DDR3 chip, right past the ZQCL before you can read the MPR.

[NorthGuy]

Looking at this table, the input and output clocks must be the same. Therefore you cannot use DQS as a clock.

So, your only choice is the BrianHG's method.

However, I think you can use their calibration mechanism to maintain the DQS alignment to CK dynamically and adjust the DQ delay in sync with DQS.

[promach]

@BrianHG Why does the following error occur for PREA command inside STATE_ACTIVATE ?

[BrianHG]

@BrianHG Why does the following error occur for PREA command inside STATE_ACTIVATE ?

It is as it says...

[promach]

@BrianHG  However, I have already explicitly issue a PREA command, so I do not understand why that error still occur ?

Code: [Select]

if(MPR_ENABLE)  // MPR System Read Calibration
begin
// need to do PRECHARGE after ACTIVATE

ck_en <= 1;
cs_n <= 0;
ras_n <= 0;
cas_n <= 1;
we_n <= 0;
address[A10] <= 1;  // precharge ALL banks
                        main_state <= STATE_PRECHARGE;
           
                        wait_count <= 0;
end

[promach]

@BrianHG It seems that the root cause for the failure to enter MPR_Read_function mode is the vicious dependency cycle between ACTIVATE and PRECHARGE commands as shown in the following two screenshots.

[promach]

Looking at this table, the input and output clocks must be the same. Therefore you cannot use DQS as a clock.

So, your only choice is the BrianHG's method.

However, I think you can use their calibration mechanism to maintain the DQS alignment to CK dynamically and adjust the DQ delay in sync with DQS.

@NorthGuy

Where did you see that the input and output clocks must be the same ?

and how does this translate to need for BrianHG's method ?

[NorthGuy]

Where did you see that the input and output clocks must be the same ?

It says "Only possible when the two BUFGs are common for both input and output" or similar

and how does this translate to need for BrianHG's method ?

If the clocks must be the same, you must use the same clock for input as you used for output. So, this cannot be DQS.

BrianHG samples both DQS and DQ with a clock. This clock is different from the output clock - it is shifted by PLL. You cannot do exactly this because your input and output clocks must be the same. But you can do similar. You can delay DQ inputs so that they can be sampled with the output clock.

[promach]

@BrianHG The DDR3 RAM still fail to enter MPR_Read_function mode.

Did the MPR sequence look wrong to you ?

[promach]

@BrianHG The MPR_Read_function mode is working now in Modelsim simulation.

However, why at time = 702051705 ps , simulation waveform shows 0 , but the modelsim console transcript log shows 1 instead ?

I have thought about DQS centering in this case, but phase-shifting DQ to both left and right by 90 degrees still give contradictory result.

Remember that timing cursor corresponds to the fourth piece of data being read during MPR_Read_function mode.

[promach]

If the clocks must be the same, you must use the same clock for input as you used for output. So, this cannot be DQS.

BrianHG samples both DQS and DQ with a clock. This clock is different from the output clock - it is shifted by PLL. You cannot do exactly this because your input and output clocks must be the same. But you can do similar. You can delay DQ inputs so that they can be sampled with the output clock.

@NorthGuy 

Thanks for pointing this similar clock issue out.
I suppose I still could feed in DQS for 'CLK' inputs of both IDELAY and ODELAY, but I need to delay-shifting DQ bits signals instead of DQS signals.

Please correct me if wrong.


By the way, should IODELAY primitive be placed between IODDR and IOBUF ?


Rx : RAM -> IOBUF (for inout) -> IDELAY (DQS Centering) -> IDDR2 (input DDR buffer) -> ISERDES      
Tx : OSERDES -> ODDR2 (output DDR buffer) -> ODELAY (DQS Centering) -> IOBUF (for inout) -> RAM

[BrianHG]

@BrianHG The MPR_Read_function mode is working now in Modelsim simulation.

However, why at time = 702051705 ps , simulation waveform shows 0 , but the modelsim console transcript log shows 1 instead ?

I have thought about DQS centering in this case, but phase-shifting DQ to both left and right by 90 degrees still give contradictory result.

Remember that timing cursor corresponds to the fourth piece of data being read during MPR_Read_function mode.

What are your contradictory results?
The DQS and data coming out of the ram look normal.
You cannot affect the DQS timing here as the ram is generating it for you.

FPGA inputs aren't instant.  You will need to read up on how your input buffers work.  What you see on the IO pins of the ram in models sim is the instant output, not what the internal logic in the FPGA sees.  Modelsim is a functional simulator, unless you have compiled a real FPGA with your project with set FPGA and every IO pin in Xilinx and provided a gate-level simulation with cell timing information.  Here you loos access to your exact net names and you need to do a full FPGA compile every-time lasting minutes per compile just to see any results.  Xilinx may not even support this feature withing Modelsim as even newer Altera FPGAs have dropped support for timing gate level simulations in Modelsim.

[NorthGuy]

I suppose I still could feed in DQS for 'CLK' inputs of both IDELAY and ODELAY, but I need to delay-shifting DQ bits signals instead of DQS signals.

You cannot use DQS as a clock for OSERDES. DQS is not a clock, it's a strobe. It is not present when you write. You could for ISERDES, but since you must use the same for both OSERDES and ISERDES, you can't use DQS as a clock.

By the way, should IODELAY primitive be placed between IODDR and IOBUF ?

Rx : RAM -> IOBUF (for inout) -> IDELAY (DQS Centering) -> IDDR2 (input DDR buffer) -> ISERDES      
Tx : OSERDES -> ODDR2 (output DDR buffer) -> ODELAY (DQS Centering) -> IOBUF (for inout) -> RAM

Rx : RAM -> IOBUF (for inout) -> IDELAY -> ISERDES      
Tx : OSERDES -> ODELAY -> IOBUF (for inout) -> RAM

or

Rx : RAM -> IOBUF (for inout) -> IDELAY -> IDDR2 -> Your own serdes(x2)
Tx : Your own serdes(x2) -> ODDR2 -> ODELAY -> IOBUF (for inout) -> RAM

If you try to connect something in a way that cannot be connected, it won't let you.

[promach]

You cannot use DQS as a clock for OSERDES. DQS is not a clock, it's a strobe. It is not present when you write. You could for ISERDES, but since you must use the same for both OSERDES and ISERDES, you can't use DQS as a clock.

@NorthGuy  I mean  'CLK' input for IODELAY2 , not IOSERDES2

[NorthGuy]

@NorthGuy  I mean  'CLK' input for IODELAY2 , not IOSERDES2

CLK input is only for control. You use the same clock as for the logic which drives CE, INC pins.