How can we generate an ARM DS5 DStream format DDR initialization script using the DRAM Register Programming Aid?
Some RPAs include a "DStream .ds file" tab for the ARM DS5 debugger specific commands. The i.MX6UL/ULL/ULZ DRAM Register Programming Aids for example already has this supported. However, the user can easily create the .ds format from the existing .inc format. The basic steps to convert .inc files to .ds format are as follows:
1) Replace the one instance of setmem /16 with mem set
2) In that same line, replace 0x020bc000 = with 0x020bc000 16
3) Use a Replace All command to change setmem /32 with mem set
4) Use a Replace All command to change = with 32
5) Use a Replace All command to change // with #
6) Save as a .ds file.
When using a 528MHz DRAM Controller interface with a DDR memory of a faster speed bin, which speed bin timing options should one use?
For example, let’s assume our MX6DQ design is using a DDR3 memory from a DDR3-1600 speed bin. However, the maximum speed of the MMDC interface for the MX6DQ using DDR3 is 528MHz. Should we use the 1600 speed bin (800MHz clock speed) or the 1066 speed bin (533MHz clock speed)? In short, the user should use the timings rated for the maximum speed (frequency) with which you are running, in this case DDR3-1066 (533MHz). In some cases, like when using the MX6DL, the maximum DDR frequency is 400MHz. In this case, you would want to try and use 800 timings found in the AC timing parameters table. However, most DDR3 devices have speed bin tables that may go only as low as 1066, in which case you would use the closest speed bin to your operational frequency (i.e. the 1066 speed bin table).
Some timing parameters may specify a min and max number, which should I use?
In most cases, you will want to choose the minimum timings. Some DRAM controllers may have a tRAS_MAX timing parameter, in which case you would obviously use the maximum tRAS parameter given in the DRAM data sheet.
Also, for timing parameters tAONPD and tAOFPD, we also want to use the maximum values given in the DDR3 data sheet. These represent the maximum amount of time the DDR3 device takes to turn on or off the RTT (termination), therefore, we should wait at least this amount of time before issuing any commands or accesses.
Some timing parameters state things like “Greater of 3CK or 7.5ns”; which should I use?
This depends on your clock speed. Say you are running at 533MHz. At 533MHz, 7.5ns equates to 4CKs. In this case, 7.5ns at 533MHz is GREATER than 3CK, so we would use the 7.5ns number, or 4CKs. At 400MHz, 7.5ns equates to 3CKs. In this case, we’d simply use 3CKs.
I have a design that will throttle the DDR frequency (dynamic frequency scaling). At full speed, I plan to run at 533MHz, and then I plan to throttle down to say 400MHz whenever possible. Do I need to re-calculate my 400 MHz timing parameters that were initially set for 533MHz?
It is not necessary to re-calculate timing parameters for 400MHz, and you can re-use the ones for 533MHz. The timings at 533 MHz are much tighter than 400 MHz, and the key here is to NOT violate timings. Also, it may be a bit of a hassle maintaining two sets of timing parameters, especially if later in the design, you swap DDR vendors that might require you to re-calculate some timing parameters. It’s easier to do it once and to come up with a combined worse-case timing parameters for 533MHz, which you know will work at 400MHz. But, if you don’t mind maintaining two sets of timing parameters, and really want to optimize timings down to the last pico-second for 400MHz, then knock yourself out.
Can I use these Register programming aids for both Fly by and T- Topology ?
The DDR register programming aid is agnostic to the DDR layout. The same spreadsheet works for both topologies.
We recommend running write leveling calibration for both topologies and the values returned by the Write Leveling routine from the Freescale DDR stress test should be incorporated back to the customer specific initialization script.
The DDR stress test also has a feature whereby it evaluates the write leveling values returned from calibration and increments WALAT to 1 if the values exceed a defined limit. The DDR stress test informs the user when the Write Additional latency (WALAT) exceeds the limit and should be increased by 1, and reminds the user to add it back in the customer specific initialization script if required.
WALAT: Write Additional latency. Recommend to clear these bits. Proper board design should ensure that the DDR3 devices are placed close enough to the MMDC to ensure the skew between CLK and DQS is less than 1 cycle.
Can I use the DEFAULT Register programming aid values for MDOR when using an Internal OSC instead of the recommended 32.768 KHZ XTAL ?
No, NXP recommends reprogramming these values based on the worse case frequency (Max clock) of the internal OSC of the device to guarantee JEDEC timings are met. Please refer to Internal Oscillator Accuracy considerations for the i.MX 6 Series for more details
View full article