topic Re: i.MX6 DQS gating delay in i.MX Processors

i.MX6 DQS gating delay

tomsaluzzo — Fri, 11 Apr 2014 16:16:47 GMT

AN4467 page 21 states that The DQS gating includes a delay of up to 7.875 cycles. Delay value is combined from the DQS gating delay fields: (DG_DL_ABS_OFFSET/256 * cycle) + (DG_HC_DEL * half cycle).

When I review the register definition for Read DQS Gating Control Register 0 (MMDCx_MPDGCTRL0) it appears that I can only select a maximum of 7.0 cycles of delay.

DG_HC_DEL1 = 6.5 cycles [27:24]=1101. Note: The values 1110 and 1111 are reserved.

DG_DL_ABS_OFFSET1 = 0.5 cycle [22:16]=0x7F.

How I can set the register for > 7.0 cycles? Why are these upper two values reserved?

Does production silicon eliminate the limitation for MMDCx_MPDGCTRL0?

DG_HC_DEL1 = 1110 (7.0 cycles) and 1111 (7.5 cycles) are both reserved.

Re: i.MX6 DQS gating delay

gusarambula — Fri, 18 Apr 2014 17:58:42 GMT

Unfortunately the two reserved values cannot be used and that the maximum value given on the Application Note needs to be updated.

This discrepancy has already being escalated. Thank you for pointing it out!

Re: i.MX6 DQS gating delay

tomsaluzzo — Tue, 22 Apr 2014 12:07:00 GMT

When operating the i.MX6 DDR3 interface at its maximum clock frequency (532 MHz), then given the MPDGCTRL0 limitations, the CAS LATENCY MUST BE <= 7 cycles. This limitation forces the deployment of only the fastest speed grade Memory ICs (-187E speed). That could be considered fully acceptable,...BUT...when operating the -187E speed grade devices at 532 MHz and CL=7, then 7.0 cycles of Read DQS Gating maximum delay is still insufficient. The Read DQS Gating delay value must account for (3) distinct elements of memory system delay that must all be summed together:

The CAS Latency value
The READ command time of flight (TOF) from the i.MX6 to the Memories
The DQS time of flight (TOF) delay from the Memories to the i.MX6

Given that even with the fastest CAS latency of 7.0 cycles, then the MPDGCTRL0 Register setting limitation of 7.0 cycles max read DQS Gating delay would require that the memory system be designed such that the signal TOFs are 0 nsec between the iMX6 and the Memories. Of course this is impossible to implement. So, please review and let me know if I have overlooked something in my analysis. If my analysis is correct, then please opine on how Freescale believes it is acceptable to eliminate / bar the use of (2) largest delay settings in the MPDGCTRL0? I do not see how this provides a robust solution for the DDR3 memory implementation.

Re: i.MX6 DQS gating delay

gusarambula — Wed, 30 Apr 2014 19:18:36 GMT

The DQS timing begins at the point that the MMDC controller takes the DQS strobe out of High-Z state in anticipation or receiving data. The DQS strobe is not taken out of High-Z state until one clock cycle before the timing value of CAS latency after the read command is issued. (The one clock cycle is automatically subtracted from the CAS delay to make up for the Read Preamble timing) Therefore DQS timing does not have to account for CAS latency, which is set in a separate register (MMDCx_MDCFG0[tCL])