AM3351: DDR2 JEDEC compliance issues

Hi James,

Thank you for pointing this out, we are updating the design as we speak. I'll let you know if this solves the problems when we have the new boards.

During qualification I also needed to tune the clock to comply to JEDEC. To comply I added a 100R parallel termination between p and n and 10R series termination in p and n signal. From measurements this is now pass but it is nowhere mentioned in the datasheet or in reference designs this termination I added should be added. Can you comment on this?

We did found that our implementation on the differential DQS and CK is 90um trace width and 210um airgap to get the 100R differentials. After reviewing the datasheet we are now thinking of updating it to 100-100-100 um differentials. In this case we do also comply to the datasheet 2w spacing and impedance. Can you comment on this as well?

Thank you in advance!

Regards,

Francois

Francois, 

all of the read timing are signals generated by the DDR memory, not the AM335x.  Most likely timing distortion  would result from PCB layout and termination impedance issues.  JEDEC signal levels and requirements are defined at the pins of the DDR memory.  Taking these measurements close to the CPU will give you misleading results.  You should take these measurement at or near the DDR pins.

Also, be sure to follow all of the guidance on stackup, placement, trace widths, etc from the datasheet.  Things like split ground planes or routing not adjacent to ground planes can cause impedance mismatches which will distort your signal.  This may be the reason you need to add series and/or parallel termination. 

Regards,

James

James,

Sorry I may be a bit unclear in my previous reply.

The question of adding parallel and series termination was not about a measurement mentioned above (from my first post), but is an additional question.

The differential signal where I added the termination is only to the CK_p/n, which I believe is an output only on the AM335x side. We are measuring this signal at the DDR2 device side. In the DDR2 device there is no on-die termination (as far as I could find) so the signal was to strong at the DDR2 device. With the termination added I was able to get the signal within JEDEC requirements. I was wondering about this because there is no termination inside the DDR2 Device, shouldn't this be stated in the datasheet of the Sitara?

The other question about the implementation of the differential signals we have a problem with the requirements stated in the datasheet (I miss interpret my colleague who drawing the PCB).

Our implementation is 90-210-90 um to get 100R impedance differential. We use 100um to get 50R impedance single ended. This violates the requirement of center-to-center (2w) of the datasheet.

If we do want to follow the datasheet we can implement the differentials like 100-100-100 um which satisfies the center-to-center requirement. With our stack-up we satisfy the impedance requirement for the single ended signal trace of 50R. But the impedance of the differential will be lower than 100R which violates the 2x Zo requirement stated in the datasheet. What is in your opinion the best way to implement the differentials?

Regards,

François

Hi Francois, if the CK signal was too strong, have you tried adjusting the drive strength for it from the AM335x side?  What are your drive strength settings?  If you have JTAG access, run the script below and send back the resulting file:

git.ti.com/.../am335x-ddr-analysis.dss 

Instructions for running the file can be found here:  http://git.ti.com/sitara-dss-files/am335x-dss-files/blobs/master/README

As for your differential impedance, how is CK and CKn routed?  Ideally, they should be routed on an outer layer with no layer transitions.  This will allow you to control the impedance mismatches much easier.  I believe you can move slightly wider that 2w to achieve the 2x Zo if needed.

Regards,

James  

Hi James,

I have run the script on a board and the following output it printed: 

Switched to DAP_DebugSS
Read value of 2b94402e from Device_ID register.
CONTROL: device_id = 0x2b94402e
  * AM335x family
  * Silicon Revision 2.1

CONTROL: control_status = 0x008c0356
  * SYSBOOT[15:14] = 10b (25 MHz)
CM_CLKSEL_DPLL_DDR = 0x00010a18
  * DPLL_MULT = 266 (x266)
  * DPLL_DIV = 24 (/25)
CM_DIV_M2_DPLL_DDR = 0x00000201
  * CLKST = 1: M2 output clock enabled
  * DIVHS = 1 (/1)

DPLL_DDR Summary
 -> F_input = 25 MHz
 -> CLKOUT_M2 = DDR_PLL_CLKOUT = 266 MHz

EMIF: SDRAM_CONFIG = 0x43845732
  * Bits 31:29 (reg_sdram_type) set for DDR2
  * Bits 28:27 (reg_ibank_pos) set to 0
  * Bits 26:24 (reg_ddr_term) set for 50 Ohm (011b)
  * Bit  23    (reg_ddr2_ddqs) set to differential DQS.
  * Bits 19:18 (reg_sdram_drive) set for weak drive (01b)
  * Bits 15:14 (reg_narrow_mode) set to 1 -> 16-bit EMIF interface
  * Bits 13:10 (reg_cl) set to 5 -> CL = 5
  * Bits 09:07 (reg_rowsize) set to 6 -> 15 row bits
  * Bits 06:04 (reg_ibank) set to 3 -> 8 banks
  * Bits 02:00 (reg_pagesize) set to 2 -> 10 column bits

EMIF: PWR_MGMT_CTRL = 0x00000000
 * Bits 10:8 reg_lp_mode set to 0, auto power management disabled
 * Warning: Bits 7:4 (reg_sr_tim) are in violation of Maximum Self-Refresh Command Limit
   -> Please see the silicon errata (DDR3: JEDEC Compliance for Maximum Self-Refresh Command Limit) for more details.
   -> This is only an issue if used in conjunction with reg_lp_mode=2.

DDR PHY: DDR_PHY_CTRL_1 = 0x00100306
  * Bits 9:8 (reg_phy_rd_local_odt) to 3 -> half thevenin termination
  * Bits 4:0 (reg_read_latency) set to 6
    -> If PHY_INVERT_CLKOUT=0, this is an appropriate value.
    -> If PHY_INVERT_CLKOUT=1, this is too small.
    -> PHY_INVERT_CLKOUT is a write-only register, so this needs to be
    -> inspected closely in the code and RatioSeed spreadsheet.

*********************
*** Register Dump ***
*********************

*(0x4c000000) = 0x40443403
*(0x4c000004) = 0x40000004
*(0x4c000008) = 0x43845732
*(0x4c00000c) = 0x00000000
*(0x4c000010) = 0x2000040d
*(0x4c000014) = 0x0000040d
*(0x4c000018) = 0x0666a392
*(0x4c00001c) = 0x0666a392
*(0x4c000020) = 0x142431ca
*(0x4c000024) = 0x142431ca
*(0x4c000028) = 0x0000021f
*(0x4c00002c) = 0x0000021f
*(0x4c000038) = 0x00000000
*(0x4c00003c) = 0x00000000
*(0x4c000054) = 0x00ffffff
*(0x4c000058) = 0x8000140a
*(0x4c00005c) = 0x00021616
*(0x4c000080) = 0x003f9180
*(0x4c000084) = 0x00026ee7
*(0x4c000088) = 0x00010000
*(0x4c00008c) = 0x00000000
*(0x4c000090) = 0x89526de3
*(0x4c000098) = 0x00050000
*(0x4c00009c) = 0x00050000
*(0x4c0000a4) = 0x00000000
*(0x4c0000ac) = 0x00000000
*(0x4c0000b4) = 0x00000000
*(0x4c0000bc) = 0x00000000
*(0x4c0000c8) = 0x00000000
*(0x4c0000d4) = 0x00000000
*(0x4c0000d8) = 0x00000000
*(0x4c0000dc) = 0x00000000
*(0x4c0000e4) = 0x00100306
*(0x4c0000e8) = 0x00100306
*(0x4c000100) = 0x00000000
*(0x4c000104) = 0x00000000
*(0x4c000108) = 0x00000000
*(0x4c000120) = 0x00000305

************************
*** IOCTRL Registers ***
************************

CONTROL: DDR_CMD0_IOCTRL = 0x00000373
  * ddr_ba2 Pullup/Pulldown disabled
  * ddr_wen Pullup/Pulldown disabled
  * ddr_ba0 Pullup/Pulldown disabled
  * ddr_a5 Pullup/Pulldown disabled
  * ddr_ck Pullup/Pulldown disabled
  * ddr_ckn Pullup/Pulldown disabled
  * ddr_a3 Pullup/Pulldown disabled
  * ddr_a4 Pullup/Pulldown disabled
  * ddr_a8 Pullup/Pulldown disabled
  * ddr_a9 Pullup/Pulldown disabled
  * ddr_a6 Pullup/Pulldown disabled
  * Bits 9:5 control ddr_ck and ddr_ckn
    - Slew slowest
    - Drive Strength 8 mA
  * Bits 4:0 control ddr_ba0, ddr_ba2, ddr_wen, ddr_a[9:8], ddr_a[6:3]
    - Slew fast
    - Drive Strength 8 mA
CONTROL: DDR_CMD1_IOCTRL = 0x00000373
  * ddr_a15 Pullup/Pulldown disabled
  * ddr_a2 Pullup/Pulldown disabled
  * ddr_a12 Pullup/Pulldown disabled
  * ddr_a7 Pullup/Pulldown disabled
  * ddr_ba1 Pullup/Pulldown disabled
  * ddr_a10 Pullup/Pulldown disabled
  * ddr_a0 Pullup/Pulldown disabled
  * ddr_a11 Pullup/Pulldown disabled
  * ddr_casn Pullup/Pulldown disabled
  * ddr_rasn Pullup/Pulldown disabled
  * Bits 4:0 control ddr_15, ddr_a[12:10], ddr_a7, ddr_a2, ddr_a0, ddr_ba1, ddr_casn, ddr_rasn
    - Slew fast
    - Drive Strength 8 mA
CONTROL: DDR_CMD2_IOCTRL = 0x00000373
  * ddr_cke Pullup/Pulldown disabled
  * ddr_resetn Pullup/Pulldown disabled
  * ddr_odt Pullup/Pulldown disabled
  * ddr_a14 Pullup/Pulldown disabled
  * ddr_a13 Pullup/Pulldown disabled
  * ddr_csn0 Pullup/Pulldown disabled
  * ddr_a1 Pullup/Pulldown disabled
  * Bits 4:0 control ddr_cke, ddr_resetn, ddr_odt, ddr_csn0, ddr_[a14:13], ddr_a1
    - Slew fast
    - Drive Strength 8 mA
CONTROL: DDR_DATA0_IOCTRL = 0x00000373
  * ddr_d8 Pullup/Pulldown disabled
  * ddr_d9 Pullup/Pulldown disabled
  * ddr_d10 Pullup/Pulldown disabled
  * ddr_d11 Pullup/Pulldown disabled
  * ddr_d12 Pullup/Pulldown disabled
  * ddr_d13 Pullup/Pulldown disabled
  * ddr_d14 Pullup/Pulldown disabled
  * ddr_d15 Pullup/Pulldown disabled
  * ddr_dqm1 Pullup/Pulldown disabled
  * ddr_dqs1 and ddr_dqsn1 Pullup/Pulldown disabled
  * Bits 9:5 control ddr_dqs1, ddr_dqsn1
    - Slew slowest
    - Drive Strength 8 mA
  * Bits 4:0 control ddr_d[15:8], ddr_dqm1
    - Slew fast
    - Drive Strength 8 mA
CONTROL: DDR_DATA1_IOCTRL = 0x00000373
  * ddr_d0 Pullup/Pulldown disabled
  * ddr_d1 Pullup/Pulldown disabled
  * ddr_d2 Pullup/Pulldown disabled
  * ddr_d3 Pullup/Pulldown disabled
  * ddr_d4 Pullup/Pulldown disabled
  * ddr_d5 Pullup/Pulldown disabled
  * ddr_d6 Pullup/Pulldown disabled
  * ddr_d7 Pullup/Pulldown disabled
  * ddr_dqm0 Pullup/Pulldown disabled
  * ddr_dqs0 and ddr_dqsn0 Pullup/Pulldown disabled
  * Bits 9:5 control ddr_dqs0, ddr_dqsn0
    - Slew slowest
    - Drive Strength 8 mA
  * Bits 4:0 control ddr_d[7:0], dqm0
    - Slew fast
    - Drive Strength 8 mA
CONTROL: DDR_IO_CTRL = 0x00000000
  * Bit 31: DDR_RESETn controlled by EMIF.
  * Bit 28 (mddr_sel) configured for SSTL, i.e. DDR2/DDR3/DDR3L operation.
CONTROL: VTP_CTRL = 0x00010167
  * VTP not disabled (expected in normal operation, but not DS0).
CONTROL: VREF_CTRL = 0x00000000
  * VREF supplied externally (typical).
CONTROL: DDR_CKE_CTRL = 0x00000001
  * CKE controlled by EMIF (normal/ungated operation).

From this output I see that our clock settings are:

- Slew slowest
- Drive Strength 8 mA

So do you recommend to reduce the drive strength of the clock signal? (The same settings are used for DQSx, this signal is near the 1V - VSWING(max) parameter, only here the ODT is present where it is not for the clock.). Without my added parallel and series termination on the clock differential the VSWING(max) is almost 1.8V.

Additionally for your information we have updated the board on the violations pointed out and re-checked the board. Within a few weeks I will have updated boards to test.

Thank you.

Regards,

François

Francois, yes you can try to reduce the clock drive strength and see the effects.  Also, i noticed you are mixing and matching slew rates for the signals.  I think i would at least match up the addr/clk slew rates, and then the data/DQS/DM slew rates.  

REgards,

James

Hi James,

We received the boards and have updated the settings so we are at the point of remeasuring the DDR2.

One thing we noticed when I used the am335x-ddr-analysis.dss to read the settings through JTAG is that we see different settings between u-boot and Linux. When we booted to u-boot the settings we set are correct, but when the boot continues and loads Linux it sets the DDR2 settings to different settings.

I'm not a software engineer so I hope it is not a trivial question but does Linux uses its own DDR2 settings? Or do I overlook something here with the JTAG script, where the registers are blocked from reading? I do get a lot of 0x00 from the registers back but the system does work.

Thank you for the support!

Regards,

François

Francois Veger said:

One thing we noticed when I used the am335x-ddr-analysis.dss to read the settings through JTAG is that we see different settings between u-boot and Linux. When we booted to u-boot the settings we set are correct, but when the boot continues and loads Linux it sets the DDR2 settings to different settings.

That's unexpected.  Can you please zip up the output of the script as observed during u-boot and Linux?  I'd like to better understand precisely what is changing, e.g. is it a few isolated registers or does it appear to be fully reconfigured?

JTAG_read.zip

In the added zip 2 logs are present. First I read the settings through JTAG when I halted boot at the U-boot stage. Second read was after entire boot sequence.

I checked the reads but when Linux is booted I appears that JTAG is not able to read the settings anymore. Maybe Linux blocks JTAG reads? 

Execute this command from the Linux console before running the script:

devmem2 0x44e00414 w 0x12500002