AM3352: AM3352 ZQ tuning

Christian,

Christian Schuler said:

SDRAM_CONFIG Register (7.3.5.3 in spruh73l.pdf)

reg_sdram_drive
reg_ddr_term

The SDRAM_CONFIG register is what gets written to the DDR to configure its drive strength.  The AM335x DDR drive strength is configured independently.  I have a script which reads all the pertinent registers, decodes them, and displays the corresponding pins that are impacted.  I think that it will make it fairy easy for you to debug your issue.  You can download the script here:

http://git.ti.com/sitara-dss-files/am335x-dss-files/blobs/raw/main/am335x-ddr-analysis.dss

Directions on how to run the script are here:

http://git.ti.com/sitara-dss-files/am335x-dss-files/blobs/main/README

It will output a text file to your desktop.  There's a section in the output file called IOCTRL Registers.  Here's an example showing one of the associated registers (there are several):

CONTROL: DDR_DATA0_IOCTRL = 0x0000018b
  * 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 slow
    - Drive Strength 9 mA
  * Bits 4:0 control ddr_d[15:8], ddr_dqm1
    - Slew slow
    - Drive Strength 8 mA

I've highlighted the last bit as that's the critical part you'll want to examine.  It shows you for each register which bits pertain to which pins.  It correspondingly provides the configured slew rate and drive strength.  More info on these registers can be found in the AM335x Technical Reference Manual in Section 9.2.5 DDR PHY.

Best regards,
Brad

Hi Brad,

thanks a lot for your quick reply. We will try out new setting and will feedback our result, but it will take some time...

Best regards,
Christian

Christian,

Generally speaking you should be performing IBIS analysis to determine the optimal settings for your platform.  You would then implement those settings in the code and use the script to validate that you implemented it correctly.  The IBIS analysis allows you to simulate corners of process and temperature, i.e. it is possible to check all the extremes to come up with the best set of parameters.  If you're just doing trial and error testing you might inadvertently improve one scenario while making another worse.

Best regards,
Brad

Brad,

I would be happy to do this process, but I would have a lot of question marks how to proceed here.

1.     I can't find an IBIS model for AM3352 ZCZ package on TI site. Can you please forward a link.
2.     Is there some guide you can provide, who would explain the procedures?
3.     Which tools do I need for it?

• I can import IBIS model inside my ECAD tool (Altium Designer), but I'm not sure how reliable the output will be. I have done this long time ago (> 10 years), just to get an idea, how it works, but it was not very satisfing at this time.

Just in addition, we have done all DDR3 rules on the transmission lines. All impedance controlled and also checked initial by the pcb manufacturer.
I have also measured some signals and signal integrity looks really well. But I can't do eye measurement with my equipment.
However, all the issue is now appearing with a second source SRAM, we did not have any issues with the previous used ones (ISSI & Micron).

I would be very happy, if you could further assist to go throug the IBIS modelling process.

Thank you

Christian

Christian,

The IBIS model can be found in the AM3352 product folder if you go to Design & Development -> Design Tools & Simulation.  Here's a direct link to the AM335x ZCZ IBIS model:

https://www.ti.com/lit/zip/sprm552

I can give a few general guidelines, but giving full guidance through IBIS modeling is outside what we can achieve in the forum.  A few considerations:

1. Reads: You will simulate reads as observed at the AM335x data pins (i.e. it is important to make sure you're modeling the proper end of the bus).  The main "knobs" are Thevenin termination on the processor, as well as drive strength on the DDR.
2. Writes: You will simulate writes as observed at the DDR data pins.  The main "knobs" are Thevenin termination on the DDR as well as drive strength of the processor.
3. Addr/Ctrl signals are unidirectional and should be simulated at the DDR end of the bus.
4. Simulations should be performed for corners of process and temperature to make sure you have a robust configuration.
5. Avoid non-monotonic edges, especially on CLK/DQS signals.  If you have a glitch in the signal, you likely need to increase your drive strength.  Of course increasing your drive strength too much might lead to over/undershoot, so you're trying to find the best overall compromise.  In other words you want to turn up the drive strength just enough to avoid non-monotonic edges, but probably not any stronger or else you introduce other issues.
6. You are simulating signal integrity, not timing...  Do not try to perform any timing analysis.  It cannot be done in an IBIS environment since the IBIS models cannot simulate things like DLL's.  Your goal is strictly to look at signal integrity.

I'm attaching a pdf of wiki page that I previously wrote on this topic.  It might provide further help in understanding the IBIS models themselves.

How to use the AM335x IBIS Models.pdf

Best regards,
Brad

Christian, is your second source DDR JEDEC compatible with the working ones?  You should compare the timings of the working and non-working DDR datasheets.  

It also sounds like you are working with fairly old software which may not have optimal DDR configuration values.  It is possible that increasing the drive strength helps because your timings are marginal.  I would recommend using the latest AM335x EMIF tool found here:  https://www.ti.com/lit/pdf/sprack4  Link to the latest spreadsheet is in the app note.  This should produce the most optimal DDR configurations.  If the devices are JEDEC compatible, you should be able to come up with a common configuration for all.

Regards,

James

Hi James,

yes, the DDR is absolutely JEDEC compatible. I have also talked already to the DDR vendor support. They gave the hint to reducing the ZQ and said, we need to increasing driving strength and confirmed that this have solved equally troubles from other customers.

Thank you very much for the updated pdf and excel spreadsheet link. It looks much better then the old version I'm using. Well, the DDR integration is already 4 years ago and I just rewind to all the stuff I had used in the past. I will now go through again all the stuff with the new spreadsheet and will try that values with out linux developer. We already moved a step forward with changing settings in the driving strength, but it's still not reliable.

One thing I'm confused with is the CMD_PHY_INVERT_CLKOUT. We have currently a 0 configured here (no clock invertion). How is the link to the DDR datasheet given here?

Will let you know our results, once we have tested.

Best regards,
Christian

Hi Christian, yes the invert_clkout=1 setting is one of the major differences between the older spreadsheet and the newer one.  This was found to provide more timing margin in the PHY delays in the slave_ratio settings.  The new spreadsheet fixes this to 1 and changes a few other parameters accordingly.  Be sure to use all of the settings from the new spreadsheet in your testing.  

Regards,

James