This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM4376: EMIF tool issue

Part Number: AM4376

Hello Forum,

we are using a MICRON DDR3L MT41K64M16TW-107 IT together with the AM4376. In an earlier project, the EMIF Tool was not yet available. At this time i was using the AM43xx DDR3 Timing Configuration Tool which was an EXCEL spreadsheet as well.

With a new project, I started to use the AM43xx EMIF Tool V21 to setup up the configuation register values and to review the values I derived in the earlier project. Especially in Step 2 where i need to enter timing values from the part datasheet, some fields are turning red because of deviations from the JEDEC bitfield values assuming a DDR3-800@400MHz. I also get differences in some of the bitfields I deternined earlier with the AM43xx DDR3 Timing Configuration Tool.

The earlier desig is working very stable on the DRAM over temperature since 2015, after we fixed some trouble with the HW leveling. But probably there is some room for optimization here as well.

The part we are using is from speed grade DD3L-1866 and we are operating at 400MHz. Currently I entered the timing specifications for this specific device/speed grade (1866), but because of the red fields and the differences I get,  I am not sure anymore about what to enter.

Here my questions:

Do i need to enter the values for a speed grade 800 device, even we are using a speed grade 1866 device?

Or do I need to enter the timing values for 1866?

The user guide for the tool doesn't answer this question.

Thank you very much in advance for your support.

Best regards

Ralph

  • Hello Again,

    sometimes it helps to look twice.

    I found the bug. By accident i was selecting the wrong Data Rate in section 1B.

    Sorry for confusion...

    Best regards

    Ralph

  • Hello Again,

    my uncertainties with the entires in the EMIF Tool are now fixed. The red fields turned green and i am quite confident, that the settings are correct now.

    I read in another forum thread, that a lot of experience with the EMIF from the past was put into the current EMIF Tool (I am currently using V21). In the development phase, i was using the former AM43xx_DDR_register_calc_tool as mentioned above to derive the register settings for the Uboot SPL.

    My colleague from the software department was doing a DDR3/EMIF register dump for me and i was comparing the actual settings from the boot code with the register set calculated from the EMIF Tool and there are several deviations i try to evaluate about the effects to the operation of the DDR3 memory interface. The AM437x User Manual is not going into detail about the settings, so i post my questions here to get support.

    We are utilizing a single rank 16Bit DDR3L-1866 interface at 400MHz with a AM4376 as mentioned before. The refresh interval is set to 3.9us because we are operating at extended temperature range.

    1) SDRAM_TIM_3:


    Value from EMIF Tool was 0x5F7F82BF and our current value is 0x107F82B8, which meets the value from AM43xx_EMIFconfig_HWlvl.gel as well. The differences are marked in red, so there are deviations in PHY DLL unlock time (0x1 vs. 0x5). The phase differnce between different CS i don't understand (0x0 vs. 0xF), because i specified a single rank 16Bit interface in the EMIF Tool, so only CS0 is used. For T_RAS_MAX, the value should be 0xF according to the user manual and the EMIF_Tool, but the value from the former calc tool was 0x8, same as in the AM43xx_EMIFconfig_HWlvl.gel.

    2) EMIF4D_SDRAM_OUTPUT_IMPEDANCE_CALIBRATION_CONFIG:


    Here, the ZQ_REFINTERVAL is different between the the register setting from the EMIF Tool and what we are currently using. My expectation is that a lower value is resulting in a shorter interval, that means in a more frequent calibration. It is not specified more in detail in the user manual how to set this value.

    3) EMIF4D_DDR_PHY_CTRL_1:

    Here the value of the read latency is different. There description in the user manual of how to set this value is not clear to me. There are various different statements as listed in the screenshot. Finaly we have a difference of 1 compared to the value from the EMIF tool and also from the AM43xx_EMIF_config_HWlvl.gel. Physical measurements on the memory interface are showing a CL of 6 and a CWL of 5 as expected and already specified in the timing registers. What effect does the register setting have here? Would you recommend to change this value from 10 to 9 when we assume 6 + 3 = 9 would be the correct value here.

    4) EMIF4D_EXT_PHY_CTRL_36:


    Here there are different values for numbers of DQ0 for write leveling and gate leveling. I expect a larger number of DQ0 transitions to be used for the initioal training. The value from the EMIF tool is lower than the value from our implementation and from the AM43xx_EMIF_config_HWlvl.gel as well. What is the effect and what is the recommendation from TI.

    5) CTRL_DDR_DATA2_IOCTRL/CTRL_DDR_DATA3_IOCTRL:

    Since we are ulilizing a 16Bit interface, we do not use DQS2 and DQS3, so the related IOCTRL registers are currently in the reset state in our implementation. From the EMIF Tool, all IOCTRL registers are are set with same value 0x84, even the interface is specified as 16Bit

    Could you please shortly explain the physical effects of the differences to the memory interface and if you would recommend to adapt some of these and which values in our boot code.

    I would like to get a feeling about differences which a really recommended from TI to be changed, because the memory interface in the design is working stable over temperature and temperature changes, but we would adapt values if there could be a potential risk of malfunction with the currently implemented settings shown above.

    Best regards and thank you in advance for your support

    Ralph

  • 20200401 PM50xx SPRAC70A_AM437x_EMIF_Configuration_Tool_V21.xlsx

    For reference i add the EMIF Tool Spreadsheet i have been using.

    Best regards

    Ralph

  • Hi Ralph, here are some explanations.  I know there's usually a high resistance to change what has been working, so i tried to give you my recommendations along the way

    1) T_RAS_MAX: this field was only applicable for mDDR devices. The controller spec states a value of 0xF for all other DDR types
    T_CSTA: 2 chip selects are only applicable when using LPDDR2 on AM437x, this bit field is irrelavant for DDR3 one chip select designs. The tool just uses 0xF for simplicity for both types
    PDDL_UL: this was changed based on PHY spec recommendations and adding margin for process/voltage/temp variations

    Recommendation: keep what you have. The 1st two bitfields are really irrelavant to your design. Since you have done temp testing, the PLL_UL setting looks like it suffices for your design

    2) OUTPUT_IMPEDANCE_CALIBRATION_CONFIG: This was changed to better align with calculations provided for the DDR based on temp and voltage drift rates that are input in the ZQ calibration settings in the spreadsheet. You can find more explanation and how to calculate this in this Micron app note: https://www.micron.com/-/media/documents/products/technical%20note/dram/tn4102.pdf

    Recomendation: You can probably keep the value you have since you have not seen any issues. If you have frequent temp/voltage changes in your design, the optimal value will better align with the necessary frequency of ZQ calibrations during normal operation

    3) PHY_CTRL_1: The read latency has an effect on the read gate on the controller. An incorrect setting here will result in read failures. The spreadsheet takes into account the invert_clkout setting as well. This is the main reason why the value is +1 from what you had previously

    Recommendation: Your value of 10 is not necessarily wrong, but the spreadsheet value should give you slightly better timing margins. Again, since you have not seen any failures, it seems like you have plenty of margin with either setting

    4) This value was optimized based on spec recommendations. The original value was mainly carried over from initial training debug and is unnecessarily conservative.

    Recommendation: keep what you have. This will only slightly affect training time

    5) DATA2/3 IOCTRL
    These values are mainly a blanket setting for all 4 bytes. I see that 16-bit designs weren't really taken into account specifically for these IO settings (i will have to fix that for future version of the spreadsheet).

    Recommendation: Enable a weak pull down on all signals and keep the rest of the bitfields at default. Based on your reg settings, this has already been implemented, so i would keep what you have

    Hopefully this clears things up.  If you have further questions, let me know

    Regards,

    James

  • Hi James,

    thank you very much for your quick response and your recommendations. Yes, we would like to be conservative here with changes. As i understood , you wouldn't change anything in the currennt settings.

    Yes, from board level measurments, it seems we have a good SI and timing margin.

    I was looking into the app note for the ZQ calibration. In our environmental tests, we have a temperature change rate of 3K/min and i think in practical applications this should not be significantly faster, so i think the 75ms calibration interval might be more then enough, so we will keep the current value.

    The only thing i struggle a bit is the setting of the read latency in the EMIF PHY CTRL Register. All timing values given in the SDRAM TIMING registers 1 and 2 and also the SDRAM CONFIG are based on RL = 6 and WL = 5. The scope plot of a READ burst is showing 6 clocks from the READ command to the first Bit driven from the DRAM, well edge aligned with the DQS. So from the physics it looks correct. From your description, the setting is affecting the time the receiver expects the first Bit to be at the controller. With our value, the controller seems to expects the bit one tCK later than it should be. That we don't have got problems doen't tell how close we are at the limit where we could get failures. If a setting of 9 would give a better margin, we should probably change this, if 9 would be the correct value for a RL of 6 (6+3). I will discuss this intenally and then we will decide if we would change this value.

    Regards and have some nice easter days, even in the current situation

    Ralph