DDR3 initialization sequence issue

[promach]

It is this '1' tuning transition point which should give you the idea as the timing errors between the 16 bits.

@BrianHG

What do you exactly mean by this '1' tuning transition point ?

[BrianHG]

[These values are now correct...]

Example: at 300MHz, there are 7 of 16 tuning steps where all the bits and the DQS pattern is valid, but, there is also an 8th tuning step where the DQS still reads valid, but half of the read data bits have random noise between the previous byte and next byte being read.

8 out of 16 means a perfect 180 degrees of tuning where read data is error free.  And since the DQS is a single differential bit being received, it is fairly clear why I am able to get a proper read from the DQS for the entire 180 degrees, 8 tuning steps.

360/16 = 22.5 degrees per tuning step.
@300 MHz, 3333ps clock, each tuning step is 208ps.
@500 MHz, 2000ps clock, each tuning step is 125ps.


So, within 208ps, 1 tuning step, there is junk data.  Tune 1 before and everything reads good.  Tune 1 after and everything reads bad.

@300Mhz, there are 7 steps with all good data.  That's a 1458ps valid data read window.

@500MHz, there are only 5 good tuning steps.  That's a 625ps read window.  The MAX 10 is showing it's IO limit here as well a trace length matching on the PCB and IO trace cross-talk.  If it had 7 good tuning steps, the read window would be 875ps out of a perfect 1000ps.

[BrianHG]

Note that my read clock is parallel for all DQ bits as well as the DQS.  I do not have any individual tuning skew adjustments on any of the IO pins.  Everything is sampled and transmitted in parallel.

[BrianHG]

ERROR ABOVE:

Example: at 300MHz, there are 7 of 16 tuning steps where all the bits and the DQS pattern is valid, but, there is also an 8th tuning step where the DQS still reads valid, but half of the read data bits have random noise between the previous byte and next byte being read.

8 out of 16 means a perfect 180 degrees of tuning where read data is error free.  And since the DQS is a single differential bit being received, it is fairly clear why I am able to get a proper read from the DQS for the entire 180 degrees, 8 tuning steps.

360/16 = 22.5 degrees per tuning step.
@300 MHz, 3333ps clock, each tuning step is 208ps.
@500 MHz, 2000ps clock, each tuning step is 125ps.


So, within 208ps, 1 tuning step, there is junk data.  Tune 1 before and everything reads good.  Tune 1 after and everything reads bad.

@300Mhz, there are 7 steps with all good data.  That's a 1458ps valid data read window.

@500MHz, there are only 5 good tuning steps.  That's a 625ps read window.  The MAX 10 is showing it's IO limit here as well a trace length matching on the PCB and IO trace cross-talk.  If it had 7 good tuning steps, the read window would be 875ps.

Also, remember,@300MHz 3333.3ps, the valid data is held for 1666ps where my valid tuning window is 1458ps.  That's 208ps in the junk zone, or 1458ps out of a theoretical perfect 1666ps.

[NorthGuy]

What if the following skew situation also happens between those parallel incoming READ DQ bits ?

If your DQ lines are not synchronized, you can adjust delays on each of them. But they're length matched, so you can assume that the skew between them is small enough.

And in such high working frequency of DDR3 RAM, it might be impossible to calibrate skew phase between incoming DQ bits.  In other words, COMBINATIONAL logic comparison between those DQ bits would not be feasible in this case.

Sure combinatorial logic is impossible. You try to achieve alignments to 50-100 ps. Routing to any combinatorial logic and combinatorial delays will be around 1 ns at best.  This will destroy time relationship between signals to the point where your analysis is totally useless. You must calibrate timing using the same structures that you're going to use for sampling real data - ISERDES or IDDR.

All you can do is tweak delays and clock phases and observe what you sample.

Note: pairwise comparison between DQS and a particular single DQ bit would not work in all corner test cases, therefore ^DQ xor operation is needed ...

Your memory is DDR3 not QDR II. Using materials about QDR II will only confuse things.

[BrianHG]

Sure combinatorial logic is impossible. You try to achieve alignments to 50-100 ps. Routing to any combinatorial logic and combinatorial delays will be around 1 ns at best.  This will destroy time relationship between signals to the point where your analysis is totally useless. You must calibrate timing using the same structures that you're going to use for sampling real data - ISERDES or IDDR.

Attempting to use combinational is such a way can even makes things worse as each time you compile, minute movement of logic due to surrounding gates can throw this strategy completely off.  Even that best 1ns figure wouldn't be guaranteed.  Get your read and writes directly on the IO pin's dedicated hardware DDR registers without any added logic tied to the pin, and work out a way to analyze the data and tune after that data has been converted to your main system clock.

[promach]

@NorthGuy On Possible Clock Structures for Bidirectional I/O and also the next page, it seems that only the same clock is needed at the IO interface, not the entire Tx/Rx pipeline.  Please correct me if wrong.

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

Also, remember,@300MHz 3333.3ps, the valid data is held for 1666ps where my valid tuning window is 1458ps.  That's 208ps in the junk zone, or 1458ps out of a theoretical perfect 1666ps.

@BrianHG I am bit confused with what you meant by junk zone.  How did you come up with the value of 1458ps ?

[promach]

@NorthGuy Figure 2-2 on page 50 explains it all. The whole Tx/Rx pipeline needs to use the same clock.

By the way, how to modify the following code related to IDDR and ISERDES for same clock restriction ?

Code: [Select]

always @(dq_r_q0, dq_r_q1, delayed_dqs_r)
dq_r_iserdes <= (delayed_dqs_r) ?  dq_r_q0: dq_r_q1;

[BrianHG]

Also, remember,@300MHz 3333.3ps, the valid data is held for 1666ps where my valid tuning window is 1458ps.  That's 208ps in the junk zone, or 1458ps out of a theoretical perfect 1666ps.

@BrianHG I am bit confused with what you meant by junk zone.  How did you come up with the value of 1458ps ?

Ok, at 303MHz, my read clock is 3333ps.
I have 16 tuning steps for 360 degrees, IE one complete rotation, so, 3333ps divided by 16 steps means 208.3ps per step.
Since the data is DDR, this means a 16bit word is coming out of the DDR3 every 3333ps/2 = 1666.5ps.
You can also see that 208.3ps * 1/2 of 16 steps is also 1666.5ps.

Now, within the correct sampling phase, IE, not 180 degrees out of phase, if my DDR3 has dead perfect tuning and the IO pins had better than 208ps precision, I would get 8 tuning steps with error free data, but I am not.  I'm only getting 7 tuning steps with perfect data, and the last one tuning step where some of the data bit have noise in the data I read.  This means somewhere in that 208ps, there are transitions right on the edge.

If I were to employ the advanced IO features in Altera's DDR_IO to tune each data DQ wire with the up to +/-50ps delay, with 1ps resolution increments, I would be able to tune out those few data error bit and get a full perfect 8 tuning steps with no read errors.  However, already having 7 good tuning steps and choosing the center of the 7, I have 3 good steps up and 3 good steps down.  This means that the DDR3 would have to drift +3x208ps=924ps, or drift -924ps since I calibrated on power-up before my data becomes corrupt.  And reading in the data sheet the extent which the DQS and DQ outputs of the DDR3 can move over the entire operating range of voltage and temperature, this is unlikely to happen.  At 1GHz, 2000mtps, that tuning window is so tight that you will want occasional re-tuning and perhaps a thermo-couple on you PCB to know when to do so.

[NorthGuy]

@BrianHG I am bit confused with what you meant by junk zone.  How did you come up with the value of 1458ps ?

Google "eye diagram". When you sample a signal, there will be a windows where the signal is stable and can be sampled, and jitter zone where the signal is transitioning and sampling yields random results.

By the way, how to modify the following code related to IDDR and ISERDES for same clock restriction ?

I use VHDL. I simply instantiate primitives and connect their pins.

[asmi]

Depending on the DDR3 chip speed bin, DQS can be up to 400 ps before CK to up to 400 ps after, for most commonly used DDR3L-1600 chips it's ±225ps. DQ can appear anytime from tLZDQ(min) (450ps for DDR3L-1600) before DQS to tDQSQ(max) (225ps) after it, and each transition can happen anywhere within this interval, so you can not calibrate this out. The hold time for DQ is defined as 0.38*tCK minimum from the DQS edge (tQH), so your data valid window is tQH - tDQSQ(max), so for DDR3L-1600 running at 400 MHz it is 0.38*2000ps - 225ps = 760 ps. For the same device running at 300 MHz it will be 1042 ps. For comparison's sake, that device running at it's max frequency of 800 MHz would leave a window of only 250 ps. Now, all of that is assuming you sample using actual DQS signal as a clock (the way it's designed and intended to work), if you use the main clock, you will have to reduce your window by the tDQSCK time (225 ps), and compensate for possible DQS duty cycle variation (it can be as short as 0.4 tCK), so the worst case for 400 MHz can be 760 ps - 225 ps - 200 ps (0.1 tCK for duty cycle shortfall) - 128 ps (cumulative error derating) = 207 ps, and the window will be fully closed for 800 MHz. I don't know if DQS to CK offset is stable for specific chip (so it can be calibrated out), if so, the window will be wider by tDQSCK, but this will only work for a single x8 chip and a perfect routing (which is way beyond DDR3's routing guidelines). For anything other that x8 CK-to-DQS time will almost always be different for different DQ groups, unless - again - you go that extra mile while routing to ensure perfect matching. For off-the-shelf boards it will likely to NOT be the case, as DDR3 routing guidelines only call for matching within DQ groups, and there is no requirement of any of these groups to be matched to ADDR/CTRL/CK group.

[promach]

@Northguy

Code: [Select]

// IODDR2 primitives are needed because the 'dq' signals are of double-data-rate
// [url]https://www.xilinx.com/support/documentation/sw_manuals/xilinx14_7/spartan6_hdl.pdf#page=123[/url]

// IDDR2: Input Double Data Rate Input Register with Set, Reset and Clock Enable.
// Spartan-6
// Xilinx HDL Libraries Guide, version 14.7

IDDR2 #(
.DDR_ALIGNMENT("NONE"),  // Sets output alignment to "NONE", "C0" or "C1"
.INIT_Q0(1'b0),  // Sets initial state of the Q0 output to 1'b0 or 1'b1
.INIT_Q1(1'b0),  // Sets initial state of the Q1 output to 1'b0 or 1'b1
.SRTYPE("SYNC")  // Specifies "SYNC" or "ASYNC" set/reset
)
IDDR2_dq_r(
.Q0(dq_r_q0[dq_index]),  // 1-bit output captured with C0 clock
.Q1(dq_r_q1[dq_index]),  // 1-bit output captured with C1 clock
.C0(ck),  // 1-bit clock input
.C1(ck_180),  // 1-bit clock input
.CE(1'b1),  // 1-bit clock enable input
.D(delayed_dq_r[dq_index]),    // 1-bit DDR data input
.R(reset),    // 1-bit reset input
.S(1'b0)     // 1-bit set input
);
// End of IDDR2_inst instantiation
Remember that my verilog coding needs to adhere to the similar clock restriction imposed by xilinx. 

Which of the following code snippet should I use to transfer both dq_r_q0, dq_r_q1 signals to my own deserializer module ?

Code: [Select]

always @(dq_r_q0, dq_r_q1, delayed_dqs_r)
dq_r_iserdes <= (delayed_dqs_r) ?  dq_r_q0: dq_r_q1;

Code: [Select]

always @(dq_r_q0, dq_r_q1, delayed_dqs_r)
  dq_r_iserdes <= (ck) ?  dq_r_q0: dq_r_q1;

Code: [Select]

        always @(posedge ck, negedge ck)
dq_r_iserdes <= (ck) ?  dq_r_q0: dq_r_q1;

delayed_dqs_r is almost similar to ck clock signal after initial MPR_Read_function phase calibration.

Note: dq_r_q0, dq_r_q1 signals are outputs from IDDR2 primitive which takes in delayed_dq_r as input

[NorthGuy]

Remember that my verilog coding needs to adhere to the similar clock restriction imposed by xilinx.

This requirement simply says that C0/C1 inputs of IDDR/ISERDES and C0/C1 inputs of ODDR/OSERDES are the same (most likely physically connected to the same wire).

Which of the following code snippet should I use to transfer both dq_r_q0, dq_r_q1 signals to my own deserializer module ?

None of these. The best way, of course, is to use ISERDES instead of IDDR (and OSERDES instead of ODDR). This way all is done in hardware and there's nothing to worry about.

However, if you want to build your own serdeses feeding from IDDR,  you cannot clump dq_r_q0 and dq_r_q1 back into a single signal and feed this signal to your serdes. You will need to build two separate serdeses - one for dq_r_q0, and another one for dq_r_q1.

[BrianHG]

You will need to build two separate serdeses - one for dq_r_q0, and another one for dq_r_q1.

?  Xilinx DDR input doesn't translate the 180 degree clocked input over to the 0 degree clock in with it's own internal 180 degree shift d-latch at the input pin?

This would mean 2 serdes running on 2 different clocks instead of 1 serdes with double width data running on 1 clock.

It would look funny if having an IO serdes function where you always had to un-zipper the data coming in or out with 2 clock domains instead of the function with dedicated hardware doing it for you.

[NorthGuy]

?  Xilinx DDR input doesn't translate the 180 degree clocked input over to the 0 degree clock in with it's own internal 180 degree shift d-latch at the input pin?

This would mean 2 serdes running on 2 different clocks instead of 1 serdes with double width data running on 1 clock.

You can configure IDDR to produce both outputs in the same clock domain (either original clock C0 or inverted original clock C1). So, both of the home-made serdeses would be in the same clock domain.

Xilinx also has built-in hardware ISERDES which can take DDR signal and produces the results in a new clock domain (aligned with original clock but divided). IMHO, It would be better to use this ISERDES instead of using fabric.

[BrianHG]

?  Xilinx DDR input doesn't translate the 180 degree clocked input over to the 0 degree clock in with it's own internal 180 degree shift d-latch at the input pin?

This would mean 2 serdes running on 2 different clocks instead of 1 serdes with double width data running on 1 clock.

You can configure IDDR to produce both outputs in the same clock domain (either original clock C0 or inverted original clock C1). So, both of the home-made serdeses would be in the same clock domain.

Xilinx also has built-in hardware ISERDES which can take DDR signal and produces the results in a new clock domain (aligned with original clock but divided). IMHO, It would be better to use this ISERDES instead of using fabric.

Original clock domain is fine as it would be a compatible buffer with Altera's DDRIO and Lattice DDRIO buffers.  My software serdes can run over 500MHz on the slower Altera FPGA and should run faster on Lattice ECP5 & even a lot faster on any Xilinx spartan as it is nothing more than a serial chain of parallel latches with a reset-able 2 bit counter to latch enable the final 4 into 1 bunch.

[promach]

For now, I am using different clock domain for the two separate deserializer.

I will change that once code compilation finished smoothly inside ISE tool.

By the way, why do I have the following error with clk signal inside pll_ddr ?

Code: [Select]

Mapping all equations...
ERROR:Xst:2035 - Port <clk> has illegal connections. This port is connected to an input buffer and other components.
Input Buffer:
   Port <I> of node <clkin1_buf> (IBUFG) in unit <pll_ddr>
Other Components:
   Port <C> of node <_i000050> (FDRE) in unit <test_ddr3_memory_controller>
   Port <C> of node <_i000051> (FDRS) in unit <test_ddr3_memory_controller>
   Port <C> of node <_i000049> (FDRE) in unit <test_ddr3_memory_controller>
   Port <C> of node <_i000047_0> (FDRE) in unit <test_ddr3_memory_controller>
   Port <C> of node <_i000047_1> (FDRE) in unit <test_ddr3_memory_controller>
   Port <C> of node <_i000047_2> (FDRE) in unit <test_ddr3_memory_controller>
   Port <C> of node <_i000047_3> (FDRE) in unit <test_ddr3_memory_controller>
   Port <C> of node <_i000047_4> (FDRE) in unit <test_ddr3_memory_controller>
   Port <C> of node <_i000047_5> (FDRE) in unit <test_ddr3_memory_controller>
   Port <C> of node <_i000047_6> (FDRE) in unit <test_ddr3_memory_controller>
   Port <C> of node <_i000047_7> (FDRE) in unit <test_ddr3_memory_controller>
   Port <C> of node <data_to_ram_24> (FDRE) in unit <test_ddr3_memory_controller>
   Port <C> of node <data_to_ram_23> (FDRE) in unit <test_ddr3_memory_controller>
   Port <C> of node <data_to_ram_22> (FDRE) in unit <test_ddr3_memory_controller>
   Port <C> of node <data_to_ram_21> (FDRE) in unit <test_ddr3_memory_controller>
   Port <C> of node <data_to_ram_20> (FDRE) in unit <test_ddr3_memory_controller>
   Port <C> of node <data_to_ram_19> (FDRE) in unit <test_ddr3_memory_controller>
   Port <C> of node <data_to_ram_18> (FDRE) in unit <test_ddr3_memory_controller>
   Port <C> of node <data_to_ram_17> (FDRE) in unit <test_ddr3_memory_controller>
   Port <C> of node <data_to_ram_16> (FDRE) in unit <test_ddr3_memory_controller>
   Port <C> of node <data_to_ram_5> (FDRE) in unit <test_ddr3_memory_controller>
   Port <C> of node <data_to_ram_7> (FDRE) in unit <test_ddr3_memory_controller>
   Port <C> of node <data_to_ram_6> (FDRE) in unit <test_ddr3_memory_controller>
   Port <C> of node <data_to_ram_2> (FDRE) in unit <test_ddr3_memory_controller>
   Port <C> of node <data_to_ram_4> (FDRE) in unit <test_ddr3_memory_controller>
   Port <C> of node <data_to_ram_3> (FDRE) in unit <test_ddr3_memory_controller>
   Port <C> of node <_i000048> (FDRSE) in unit <test_ddr3_memory_controller>
   Port <C> of node <data_to_ram_40> (FDRE) in unit <test_ddr3_memory_controller>
   Port <C> of node <data_to_ram_71> (FDRE) in unit <test_ddr3_memory_controller>
   Port <C> of node <_i000074_0> (FDRE) in unit <test_ddr3_memory_controller>
   Port <C> of node <_i000074_1> (FDRE) in unit <test_ddr3_memory_controller>
   Port <C> of node <_i000074_2> (FDRE) in unit <test_ddr3_memory_controller>
   Port <C> of node <_i000074_5> (FDRE) in unit <test_ddr3_memory_controller>
   Port <C> of node <_i000074_3> (FDRE) in unit <test_ddr3_memory_controller>
   Port <C> of node <_i000074_4> (FDRE) in unit <test_ddr3_memory_controller>
   Port <C> of node <_i000074_6> (FDRE) in unit <test_ddr3_memory_controller>
   Port <C> of node <_i000074_7> (FDRE) in unit <test_ddr3_memory_controller>
   Port <C> of node <_i000074_10> (FDRE) in unit <test_ddr3_memory_controller>
   Port <C> of node <_i000074_8> (FDRE) in unit <test_ddr3_memory_controller>
   Port <C> of node <_i000074_9> (FDRE) in unit <test_ddr3_memory_controller>
   Port <C> of node <_i000074_11> (FDRE) in unit <test_ddr3_memory_controller>
   Port <C> of node <_i000074_12> (FDRE) in unit <test_ddr3_memory_controller>
   Port <C> of node <_i000074_13> (FDRE) in unit <test_ddr3_memory_controller>
   Port <C> of node <_i000074_14> (FDRE) in unit <test_ddr3_memory_controller>
   Port <C> of node <_i000074_15> (FDRE) in unit <test_ddr3_memory_controller>
   Port <C> of node <_i000074_16> (FDRE) in unit <test_ddr3_memory_controller>
   Port <CLK> of node <ila_write_enable> (ila_1_bit) in unit <test_ddr3_memory_controller>
   Port <CLK> of node <ila_done> (ila_1_bit) in unit <test_ddr3_memory_controller>
   Port <CLK> of node <ila_ck_n> (ila_1_bit) in unit <test_ddr3_memory_controller>
   Port <CLK> of node <ila_dq_w> (ila_16_bits) in unit <test_ddr3_memory_controller>
   Port <CLK> of node <ila_states_and_commands> (ila_16_bits) in unit <test_ddr3_memory_controller>
   Port <CLK> of node <ila_states_and_wait_count> (ila_64_bits) in unit <test_ddr3_memory_controller>
   Port <C> of node <idelay_is_busy_previously> (FD) in unit <ddr3_control>
   Port <C> of node <iodelay_startup_counter_0> (FD) in unit <ddr3_control>
   Port <C> of node <iodelay_startup_counter_1> (FD) in unit <ddr3_control>
   Port <C> of node <iodelay_startup_counter_2> (FD) in unit <ddr3_control>
   Port <C> of node <iodelay_startup_counter_3> (FD) in unit <ddr3_control>
   Port <C> of node <iodelay_startup_counter_4> (FD) in unit <ddr3_control>
   Port <C> of node <iodelay_startup_counter_5> (FD) in unit <ddr3_control>
   Port <C> of node <iodelay_startup_counter_6> (FD) in unit <ddr3_control>
   Port <C> of node <iodelay_startup_counter_7> (FD) in unit <ddr3_control>
   Port <C> of node <iodelay_startup_counter_8> (FD) in unit <ddr3_control>
   Port <C> of node <iodelay_startup_counter_9> (FD) in unit <ddr3_control>
   Port <C> of node <iodelay_startup_counter_10> (FD) in unit <ddr3_control>
   Port <C> of node <iodelay_startup_counter_11> (FD) in unit <ddr3_control>
   Port <CLK> of node <iodelay_dqs_r> (IODELAY2) in unit <ddr3_control>
   Port <CLK> of node <dq_io[0].iodelay_dq_r> (IODELAY2) in unit <ddr3_control>
   Port <CLK> of node <dq_io[1].iodelay_dq_r> (IODELAY2) in unit <ddr3_control>
   Port <CLK> of node <dq_io[2].iodelay_dq_r> (IODELAY2) in unit <ddr3_control>
   Port <CLK> of node <dq_io[3].iodelay_dq_r> (IODELAY2) in unit <ddr3_control>
   Port <CLK> of node <dq_io[4].iodelay_dq_r> (IODELAY2) in unit <ddr3_control>
   Port <CLK> of node <dq_io[5].iodelay_dq_r> (IODELAY2) in unit <ddr3_control>
   Port <CLK> of node <dq_io[6].iodelay_dq_r> (IODELAY2) in unit <ddr3_control>
   Port <CLK> of node <dq_io[7].iodelay_dq_r> (IODELAY2) in unit <ddr3_control>
   Port <CLK> of node <dq_io[8].iodelay_dq_r> (IODELAY2) in unit <ddr3_control>
   Port <CLK> of node <dq_io[9].iodelay_dq_r> (IODELAY2) in unit <ddr3_control>
   Port <CLK> of node <dq_io[10].iodelay_dq_r> (IODELAY2) in unit <ddr3_control>
   Port <CLK> of node <dq_io[11].iodelay_dq_r> (IODELAY2) in unit <ddr3_control>
   Port <CLK> of node <dq_io[12].iodelay_dq_r> (IODELAY2) in unit <ddr3_control>
   Port <CLK> of node <dq_io[13].iodelay_dq_r> (IODELAY2) in unit <ddr3_control>
   Port <CLK> of node <dq_io[14].iodelay_dq_r> (IODELAY2) in unit <ddr3_control>
   Port <CLK> of node <dq_io[15].iodelay_dq_r> (IODELAY2) in unit <ddr3_control>



[promach]

I solved the above pll_ddr error by setting "No Buffer" for input clock inside PLL clocking wizard.




However, I got some "tri-state" related errors during mapping process.

Code: [Select]

NGDBUILD done.

Process "Translate" completed successfully

Started : "Map".
Running map...
Command Line: map -intstyle ise -p xc6slx16-ftg256-3 -w -logic_opt off -ol high -t 1 -xt 0 -register_duplication off -r 4 -global_opt off -mt off -ir off -pr off -lc off -power off -o test_ddr3_memory_controller_map.ncd test_ddr3_memory_controller.ngd test_ddr3_memory_controller.pcf
Using target part "6slx16ftg256-3".
Mapping design into LUTs...
ERROR:LIT:675 - In Spartan-6 devices when the data path on a TBUF is driven by
   an ODDR2, tri state path of the same TBUF must also be driven by an ODDR2.
   TBUF symbol "ddr3_control/dq_io[0].IO_dq/OBUFT" (output signal=dq<0>) has its
   I input pin driven by
   'ddr3_control/physical_group_dq_w<0>/dq_io[0].ODDR2_dq_w/D1' which is a D1
   pin of an ODDR2. However, no ODDR2 was found driving the corresponding T
   input pin 'ddr3_control/dq_io[0].IO_dq/OBUFT/E', which will result in only
   half of the ODDR2's data path being enabled. This will cause the design to
   not work in hardware. Please ensure that TBUF symbol
   "ddr3_control/dq_io[0].IO_dq/OBUFT" (output signal=dq<0>) has its T input pin
   driven by an ODDR2.
ERROR:LIT:675 - In Spartan-6 devices when the data path on a TBUF is driven by
   an ODDR2, tri state path of the same TBUF must also be driven by an ODDR2.
   TBUF symbol "ddr3_control/dq_io[1].IO_dq/OBUFT" (output signal=dq<1>) has its
   I input pin driven by
   'ddr3_control/physical_group_dq_w<1>/dq_io[1].ODDR2_dq_w/D1' which is a D1
   pin of an ODDR2. However, no ODDR2 was found driving the corresponding T
   input pin 'ddr3_control/dq_io[1].IO_dq/OBUFT/E', which will result in only
   half of the ODDR2's data path being enabled. This will cause the design to
   not work in hardware. Please ensure that TBUF symbol
   "ddr3_control/dq_io[1].IO_dq/OBUFT" (output signal=dq<1>) has its T input pin
   driven by an ODDR2.
ERROR:LIT:675 - In Spartan-6 devices when the data path on a TBUF is driven by
   an ODDR2, tri state path of the same TBUF must also be driven by an ODDR2.
   TBUF symbol "ddr3_control/dq_io[2].IO_dq/OBUFT" (output signal=dq<2>) has its
   I input pin driven by
   'ddr3_control/physical_group_dq_w<2>/dq_io[2].ODDR2_dq_w/D1' which is a D1
   pin of an ODDR2. However, no ODDR2 was found driving the corresponding T
   input pin 'ddr3_control/dq_io[2].IO_dq/OBUFT/E', which will result in only
   half of the ODDR2's data path being enabled. This will cause the design to
   not work in hardware. Please ensure that TBUF symbol
   "ddr3_control/dq_io[2].IO_dq/OBUFT" (output signal=dq<2>) has its T input pin
   driven by an ODDR2.
ERROR:LIT:675 - In Spartan-6 devices when the data path on a TBUF is driven by
   an ODDR2, tri state path of the same TBUF must also be driven by an ODDR2.
   TBUF symbol "ddr3_control/dq_io[3].IO_dq/OBUFT" (output signal=dq<3>) has its
   I input pin driven by
   'ddr3_control/physical_group_dq_w<3>/dq_io[3].ODDR2_dq_w/D1' which is a D1
   pin of an ODDR2. However, no ODDR2 was found driving the corresponding T
   input pin 'ddr3_control/dq_io[3].IO_dq/OBUFT/E', which will result in only
   half of the ODDR2's data path being enabled. This will cause the design to
   not work in hardware. Please ensure that TBUF symbol
   "ddr3_control/dq_io[3].IO_dq/OBUFT" (output signal=dq<3>) has its T input pin
   driven by an ODDR2.
ERROR:LIT:675 - In Spartan-6 devices when the data path on a TBUF is driven by
   an ODDR2, tri state path of the same TBUF must also be driven by an ODDR2.
   TBUF symbol "ddr3_control/dq_io[4].IO_dq/OBUFT" (output signal=dq<4>) has its
   I input pin driven by
   'ddr3_control/physical_group_dq_w<4>/dq_io[4].ODDR2_dq_w/D1' which is a D1
   pin of an ODDR2. However, no ODDR2 was found driving the corresponding T
   input pin 'ddr3_control/dq_io[4].IO_dq/OBUFT/E', which will result in only
   half of the ODDR2's data path being enabled. This will cause the design to
   not work in hardware. Please ensure that TBUF symbol
   "ddr3_control/dq_io[4].IO_dq/OBUFT" (output signal=dq<4>) has its T input pin
   driven by an ODDR2.
ERROR:LIT:675 - In Spartan-6 devices when the data path on a TBUF is driven by
   an ODDR2, tri state path of the same TBUF must also be driven by an ODDR2.
   TBUF symbol "ddr3_control/dq_io[5].IO_dq/OBUFT" (output signal=dq<5>) has its
   I input pin driven by
   'ddr3_control/physical_group_dq_w<5>/dq_io[5].ODDR2_dq_w/D1' which is a D1
   pin of an ODDR2. However, no ODDR2 was found driving the corresponding T
   input pin 'ddr3_control/dq_io[5].IO_dq/OBUFT/E', which will result in only
   half of the ODDR2's data path being enabled. This will cause the design to
   not work in hardware. Please ensure that TBUF symbol
   "ddr3_control/dq_io[5].IO_dq/OBUFT" (output signal=dq<5>) has its T input pin
   driven by an ODDR2.
ERROR:LIT:675 - In Spartan-6 devices when the data path on a TBUF is driven by
   an ODDR2, tri state path of the same TBUF must also be driven by an ODDR2.
   TBUF symbol "ddr3_control/dq_io[6].IO_dq/OBUFT" (output signal=dq<6>) has its
   I input pin driven by
   'ddr3_control/physical_group_dq_w<6>/dq_io[6].ODDR2_dq_w/D1' which is a D1
   pin of an ODDR2. However, no ODDR2 was found driving the corresponding T
   input pin 'ddr3_control/dq_io[6].IO_dq/OBUFT/E', which will result in only
   half of the ODDR2's data path being enabled. This will cause the design to
   not work in hardware. Please ensure that TBUF symbol
   "ddr3_control/dq_io[6].IO_dq/OBUFT" (output signal=dq<6>) has its T input pin
   driven by an ODDR2.
ERROR:LIT:675 - In Spartan-6 devices when the data path on a TBUF is driven by
   an ODDR2, tri state path of the same TBUF must also be driven by an ODDR2.
   TBUF symbol "ddr3_control/dq_io[7].IO_dq/OBUFT" (output signal=dq<7>) has its
   I input pin driven by
   'ddr3_control/physical_group_dq_w<7>/dq_io[7].ODDR2_dq_w/D1' which is a D1
   pin of an ODDR2. However, no ODDR2 was found driving the corresponding T
   input pin 'ddr3_control/dq_io[7].IO_dq/OBUFT/E', which will result in only
   half of the ODDR2's data path being enabled. This will cause the design to
   not work in hardware. Please ensure that TBUF symbol
   "ddr3_control/dq_io[7].IO_dq/OBUFT" (output signal=dq<7>) has its T input pin
   driven by an ODDR2.
ERROR:LIT:675 - In Spartan-6 devices when the data path on a TBUF is driven by
   an ODDR2, tri state path of the same TBUF must also be driven by an ODDR2.
   TBUF symbol "ddr3_control/dq_io[8].IO_dq/OBUFT" (output signal=dq<8>) has its
   I input pin driven by
   'ddr3_control/physical_group_dq_w<8>/dq_io[8].ODDR2_dq_w/D1' which is a D1
   pin of an ODDR2. However, no ODDR2 was found driving the corresponding T
   input pin 'ddr3_control/dq_io[8].IO_dq/OBUFT/E', which will result in only
   half of the ODDR2's data path being enabled. This will cause the design to
   not work in hardware. Please ensure that TBUF symbol
   "ddr3_control/dq_io[8].IO_dq/OBUFT" (output signal=dq<8>) has its T input pin
   driven by an ODDR2.
ERROR:LIT:675 - In Spartan-6 devices when the data path on a TBUF is driven by
   an ODDR2, tri state path of the same TBUF must also be driven by an ODDR2.
   TBUF symbol "ddr3_control/dq_io[9].IO_dq/OBUFT" (output signal=dq<9>) has its
   I input pin driven by
   'ddr3_control/physical_group_dq_w<9>/dq_io[9].ODDR2_dq_w/D1' which is a D1
   pin of an ODDR2. However, no ODDR2 was found driving the corresponding T
   input pin 'ddr3_control/dq_io[9].IO_dq/OBUFT/E', which will result in only
   half of the ODDR2's data path being enabled. This will cause the design to
   not work in hardware. Please ensure that TBUF symbol
   "ddr3_control/dq_io[9].IO_dq/OBUFT" (output signal=dq<9>) has its T input pin
   driven by an ODDR2.
ERROR:LIT:675 - In Spartan-6 devices when the data path on a TBUF is driven by
   an ODDR2, tri state path of the same TBUF must also be driven by an ODDR2.
   TBUF symbol "ddr3_control/dq_io[10].IO_dq/OBUFT" (output signal=dq<10>) has
   its I input pin driven by
   'ddr3_control/physical_group_dq_w<10>/dq_io[10].ODDR2_dq_w/D1' which is a D1
   pin of an ODDR2. However, no ODDR2 was found driving the corresponding T
   input pin 'ddr3_control/dq_io[10].IO_dq/OBUFT/E', which will result in only
   half of the ODDR2's data path being enabled. This will cause the design to
   not work in hardware. Please ensure that TBUF symbol
   "ddr3_control/dq_io[10].IO_dq/OBUFT" (output signal=dq<10>) has its T input
   pin driven by an ODDR2.
ERROR:LIT:675 - In Spartan-6 devices when the data path on a TBUF is driven by
   an ODDR2, tri state path of the same TBUF must also be driven by an ODDR2.
   TBUF symbol "ddr3_control/dq_io[11].IO_dq/OBUFT" (output signal=dq<11>) has
   its I input pin driven by
   'ddr3_control/physical_group_dq_w<11>/dq_io[11].ODDR2_dq_w/D1' which is a D1
   pin of an ODDR2. However, no ODDR2 was found driving the corresponding T
   input pin 'ddr3_control/dq_io[11].IO_dq/OBUFT/E', which will result in only
   half of the ODDR2's data path being enabled. This will cause the design to
   not work in hardware. Please ensure that TBUF symbol
   "ddr3_control/dq_io[11].IO_dq/OBUFT" (output signal=dq<11>) has its T input
   pin driven by an ODDR2.
ERROR:LIT:675 - In Spartan-6 devices when the data path on a TBUF is driven by
   an ODDR2, tri state path of the same TBUF must also be driven by an ODDR2.
   TBUF symbol "ddr3_control/dq_io[12].IO_dq/OBUFT" (output signal=dq<12>) has
   its I input pin driven by
   'ddr3_control/physical_group_dq_w<12>/dq_io[12].ODDR2_dq_w/D1' which is a D1
   pin of an ODDR2. However, no ODDR2 was found driving the corresponding T
   input pin 'ddr3_control/dq_io[12].IO_dq/OBUFT/E', which will result in only
   half of the ODDR2's data path being enabled. This will cause the design to
   not work in hardware. Please ensure that TBUF symbol
   "ddr3_control/dq_io[12].IO_dq/OBUFT" (output signal=dq<12>) has its T input
   pin driven by an ODDR2.
ERROR:LIT:675 - In Spartan-6 devices when the data path on a TBUF is driven by
   an ODDR2, tri state path of the same TBUF must also be driven by an ODDR2.
   TBUF symbol "ddr3_control/dq_io[13].IO_dq/OBUFT" (output signal=dq<13>) has
   its I input pin driven by
   'ddr3_control/physical_group_dq_w<13>/dq_io[13].ODDR2_dq_w/D1' which is a D1
   pin of an ODDR2. However, no ODDR2 was found driving the corresponding T
   input pin 'ddr3_control/dq_io[13].IO_dq/OBUFT/E', which will result in only
   half of the ODDR2's data path being enabled. This will cause the design to
   not work in hardware. Please ensure that TBUF symbol
   "ddr3_control/dq_io[13].IO_dq/OBUFT" (output signal=dq<13>) has its T input
   pin driven by an ODDR2.
ERROR:LIT:675 - In Spartan-6 devices when the data path on a TBUF is driven by
   an ODDR2, tri state path of the same TBUF must also be driven by an ODDR2.
   TBUF symbol "ddr3_control/dq_io[14].IO_dq/OBUFT" (output signal=dq<14>) has
   its I input pin driven by
   'ddr3_control/physical_group_dq_w<14>/dq_io[14].ODDR2_dq_w/D1' which is a D1
   pin of an ODDR2. However, no ODDR2 was found driving the corresponding T
   input pin 'ddr3_control/dq_io[14].IO_dq/OBUFT/E', which will result in only
   half of the ODDR2's data path being enabled. This will cause the design to
   not work in hardware. Please ensure that TBUF symbol
   "ddr3_control/dq_io[14].IO_dq/OBUFT" (output signal=dq<14>) has its T input
   pin driven by an ODDR2.
ERROR:LIT:675 - In Spartan-6 devices when the data path on a TBUF is driven by
   an ODDR2, tri state path of the same TBUF must also be driven by an ODDR2.
   TBUF symbol "ddr3_control/dq_io[15].IO_dq/OBUFT" (output signal=dq<15>) has
   its I input pin driven by
   'ddr3_control/physical_group_dq_w<15>/dq_io[15].ODDR2_dq_w/D1' which is a D1
   pin of an ODDR2. However, no ODDR2 was found driving the corresponding T
   input pin 'ddr3_control/dq_io[15].IO_dq/OBUFT/E', which will result in only
   half of the ODDR2's data path being enabled. This will cause the design to
   not work in hardware. Please ensure that TBUF symbol
   "ddr3_control/dq_io[15].IO_dq/OBUFT" (output signal=dq<15>) has its T input
   pin driven by an ODDR2.
Errors found during logical drc.

Design Summary
--------------
Number of errors   :  16
Number of warnings :   0

Process "Map" failed

The root cause is at the T input port of IOBUF which has to be made to use ODDR primitive as well, but I am not sure how to do this exactly.

Code: [Select]

IOBUF IO_dq (
.IO(dq[dq_index]),
.I(dq_w[dq_index]),
.T(((wait_count > TIME_RL) && (main_state == STATE_READ_AP)) ||
  (main_state == STATE_READ_DATA)),
.O(dq_r[dq_index])
);

[promach]

Now that adding ODDR2 for dq_iobuf_enable signal got me into another different error :

ERROR:Pack:2531 - The dual data rate register "ddr3_control/ODDR2_dq_iobuf_en"
   failed to join the "OLOGIC2" component as required.  The output signal for
   register symbol ddr3_control/ODDR2_dq_iobuf_en requires general routing to
   fabric, but the register can only be routed to ILOGIC, IODELAY, and IOB.

I tried to solve this new error using (* IOB = "FORCE" *), but it is NOT helping.

Any advice ?

[NorthGuy]

ERROR:Pack:2531 - The dual data rate register "ddr3_control/ODDR2_dq_iobuf_en"
   failed to join the "OLOGIC2" component as required.  The output signal for
   register symbol ddr3_control/ODDR2_dq_iobuf_en requires general routing to
   fabric, but the register can only be routed to ILOGIC, IODELAY, and IOB.

I tried to solve this new error using (* IOB = "FORCE" *), but it is NOT helping.

Any advice ?

Each DQ line will require its own ODDR for T pin. If you want to use one ODDR for all this would require its output to be routed through the fabric to multiple T pins. This is impossible, ODDR belongs to the specific IOB.

[promach]

Each DQ line will require its own ODDR for T pin. If you want to use one ODDR for all this would require its output to be routed through the fabric to multiple T pins. This is impossible, ODDR belongs to the specific IOB.

@NorthGuy

So in this particular case, how do I get around this issue with ODDR for T pin ?

[promach]

@NorthGuy  I followed your suggestion that each DQ line will require its own ODDR for T pin,  and then half of the errors are gone with the remaining errors related to ODDR2_dq_w as shown below:

Code: [Select]

Started : "Map".
Running map...
Command Line: map -intstyle ise -p xc6slx16-ftg256-3 -w -logic_opt off -ol high -t 1 -xt 0 -register_duplication off -r 4 -global_opt off -mt off -ir off -pr off -lc off -power off -o test_ddr3_memory_controller_map.ncd test_ddr3_memory_controller.ngd test_ddr3_memory_controller.pcf
Using target part "6slx16ftg256-3".
Mapping design into LUTs...
Running directed packing...
ERROR:Pack:2531 - The dual data rate register "ddr3_control/dq_io[0].ODDR2_dq_w"
   failed to join the "OLOGIC2" component as required.  The output signal for
   register symbol ddr3_control/dq_io[0].ODDR2_dq_w requires general routing to
   fabric, but the register can only be routed to ILOGIC, IODELAY, and IOB.
ERROR:Pack:2531 - The dual data rate register "ddr3_control/dq_io[1].ODDR2_dq_w"
   failed to join the "OLOGIC2" component as required.  The output signal for
   register symbol ddr3_control/dq_io[1].ODDR2_dq_w requires general routing to
   fabric, but the register can only be routed to ILOGIC, IODELAY, and IOB.
ERROR:Pack:2531 - The dual data rate register "ddr3_control/dq_io[2].ODDR2_dq_w"
   failed to join the "OLOGIC2" component as required.  The output signal for
   register symbol ddr3_control/dq_io[2].ODDR2_dq_w requires general routing to
   fabric, but the register can only be routed to ILOGIC, IODELAY, and IOB.
ERROR:Pack:2531 - The dual data rate register "ddr3_control/dq_io[3].ODDR2_dq_w"
   failed to join the "OLOGIC2" component as required.  The output signal for
   register symbol ddr3_control/dq_io[3].ODDR2_dq_w requires general routing to
   fabric, but the register can only be routed to ILOGIC, IODELAY, and IOB.
ERROR:Pack:2531 - The dual data rate register "ddr3_control/dq_io[4].ODDR2_dq_w"
   failed to join the "OLOGIC2" component as required.  The output signal for
   register symbol ddr3_control/dq_io[4].ODDR2_dq_w requires general routing to
   fabric, but the register can only be routed to ILOGIC, IODELAY, and IOB.
ERROR:Pack:2531 - The dual data rate register "ddr3_control/dq_io[5].ODDR2_dq_w"
   failed to join the "OLOGIC2" component as required.  The output signal for
   register symbol ddr3_control/dq_io[5].ODDR2_dq_w requires general routing to
   fabric, but the register can only be routed to ILOGIC, IODELAY, and IOB.
ERROR:Pack:2531 - The dual data rate register "ddr3_control/dq_io[6].ODDR2_dq_w"
   failed to join the "OLOGIC2" component as required.  The output signal for
   register symbol ddr3_control/dq_io[6].ODDR2_dq_w requires general routing to
   fabric, but the register can only be routed to ILOGIC, IODELAY, and IOB.
ERROR:Pack:2531 - The dual data rate register "ddr3_control/dq_io[7].ODDR2_dq_w"
   failed to join the "OLOGIC2" component as required.  The output signal for
   register symbol ddr3_control/dq_io[7].ODDR2_dq_w requires general routing to
   fabric, but the register can only be routed to ILOGIC, IODELAY, and IOB.
ERROR:Pack:2531 - The dual data rate register "ddr3_control/dq_io[8].ODDR2_dq_w"
   failed to join the "OLOGIC2" component as required.  The output signal for
   register symbol ddr3_control/dq_io[8].ODDR2_dq_w requires general routing to
   fabric, but the register can only be routed to ILOGIC, IODELAY, and IOB.
ERROR:Pack:2531 - The dual data rate register "ddr3_control/dq_io[9].ODDR2_dq_w"
   failed to join the "OLOGIC2" component as required.  The output signal for
   register symbol ddr3_control/dq_io[9].ODDR2_dq_w requires general routing to
   fabric, but the register can only be routed to ILOGIC, IODELAY, and IOB.
ERROR:Pack:2531 - The dual data rate register
   "ddr3_control/dq_io[10].ODDR2_dq_w" failed to join the "OLOGIC2" component as
   required.  The output signal for register symbol
   ddr3_control/dq_io[10].ODDR2_dq_w requires general routing to fabric, but the
   register can only be routed to ILOGIC, IODELAY, and IOB.
ERROR:Pack:2531 - The dual data rate register
   "ddr3_control/dq_io[11].ODDR2_dq_w" failed to join the "OLOGIC2" component as
   required.  The output signal for register symbol
   ddr3_control/dq_io[11].ODDR2_dq_w requires general routing to fabric, but the
   register can only be routed to ILOGIC, IODELAY, and IOB.
ERROR:Pack:2531 - The dual data rate register
   "ddr3_control/dq_io[12].ODDR2_dq_w" failed to join the "OLOGIC2" component as
   required.  The output signal for register symbol
   ddr3_control/dq_io[12].ODDR2_dq_w requires general routing to fabric, but the
   register can only be routed to ILOGIC, IODELAY, and IOB.
ERROR:Pack:2531 - The dual data rate register
   "ddr3_control/dq_io[13].ODDR2_dq_w" failed to join the "OLOGIC2" component as
   required.  The output signal for register symbol
   ddr3_control/dq_io[13].ODDR2_dq_w requires general routing to fabric, but the
   register can only be routed to ILOGIC, IODELAY, and IOB.
ERROR:Pack:2531 - The dual data rate register
   "ddr3_control/dq_io[14].ODDR2_dq_w" failed to join the "OLOGIC2" component as
   required.  The output signal for register symbol
   ddr3_control/dq_io[14].ODDR2_dq_w requires general routing to fabric, but the
   register can only be routed to ILOGIC, IODELAY, and IOB.
ERROR:Pack:2531 - The dual data rate register
   "ddr3_control/dq_io[15].ODDR2_dq_w" failed to join the "OLOGIC2" component as
   required.  The output signal for register symbol
   ddr3_control/dq_io[15].ODDR2_dq_w requires general routing to fabric, but the
   register can only be routed to ILOGIC, IODELAY, and IOB.

Mapping completed.
See MAP report file "test_ddr3_memory_controller_map.mrp" for details.
Problem encountered during the packing phase.

Design Summary
--------------
Number of errors   :  16
Number of warnings :   0

Process "Map" failed

[asmi]

In 7 series there is a special mode of a SERDES which takes in x4 DQ signal as well as x4 TQ signal, allowing edge-by-edge control of tristate. Not sure if it's a thing in S6.

[promach]

@asmi I am coding my own serdes due to some placement blockage restriction issues.

@NorthGuy The reason for the remaining errors are due to the fact that my coding bypasses ODELAY since for write operation to RAM, the controller could just make use of PLL to generate the required phase-shifted clock instead of using ODELAY in order to drive dq_w bits

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

What do you think in this case ?

[NorthGuy]

@NorthGuy The reason for the remaining errors are due to the fact that my coding bypasses ODELAY since for write operation to RAM, the controller could just make use of PLL to generate the required phase-shifted clock instead of using ODELAY in order to drive dq_w bits

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

What do you think in this case ?

Logically, both O and T pin should be delayed the same. It is most likely hardwired somehow, so you cannot connect it differently than it is already connected.