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.

  • TI Thinks Resolved

SITARA-DDR-CONFIG-TOOL: DDR4 memory configurations issues with EMIF tool

Intellectual 900 points

Replies: 5

Views: 307


Dear TI Team,

we're using the EMIF configuration tool (AM65x/DRA80xM EMIF Tool Spreadsheet (ZIP 326 KB) 12 Oct 2018) to configure DDR controller settings for our custom AM6548 board.

So far we've noticed three (four) issues:

  • The EMIF tool is unable to cope with comma as the decimal separator (e.g. german notation). What is problematic is that the tool "silently" fails in that case, and for example just calculates tRC=tRAS+tRP=35+13,75=35
  • The EMIF tool puts "error" into certain register values if the C/A latency is specified as 4. The register values are fine if zero is used for c/a latency.
  • A follow up to the previous issue: The tool apparently hard codes the C/A parity latency enable bit in DDRCTL_CRCPARCTL1 to 0.
  • The EMIF tool is able to export a GEL file for use in CCS and a dtsi file for use in U-Boot but can't generate the necessary header file for the RTOS SDK SBL/board library.

We've managed to work around the first issue (after figuring out what's going wrong) by switching to a dot as the decimal separator in our Excel settings.

We believe we can ignore the second issue for now, since the third issue means that C/A parity is disabled anyway. Is that correct?

Our current issue is that our DDR settings "work" for when using them via the GEL file (not thoroughly tested) and as part of our SBL (at least a brief automated RAM test succeeds), but fails when using them as part of U-Boot (based on ti-u-boot-2018.01). So far we've noticed that the U-Boot DDR initialization fails during the call to read_dqs_training() since the QSGERR (DQS gate training error) bit gets set.

We're still in the process of verifying all of the timing settings, but your colleagues suggested to inform you about issues with the EMIF tool early on. It would also be nice to know if there are any further (known) issues with the EMIF tool.

Our setup uses a single 16 bit DDR4 memory chip (MT40A256M16).



  • Dominic, please use the v1.5 of the spreadsheet that I sent via email through one of our employees visiting this past week. That version of the spreadsheet should be linked in the external app note by next week.

    If you still have problems, please send the spreadsheet so I can double check it here.

    As for your other questions:
    -the period vs comma is a difference in number representation between US and Europe. I will log it as an enhancement request and try to put in better error highlighting, but please work around it for now.
    -CA parity is not fully comprehended in the EMIF tool yet, and the tool assumes it is disabled. A future revision will be able to handle this.
    -Currently there is no output for RTOS in the tool (only uboot and GEL). This is also planned for a future release.

  • In reply to JJD:

    Dominic, as of this morning, v1.5 of the spreadsheet is available from the link in the appnote on

  • In reply to JJD:

    Hello James,

    thanks for the newer version of the EMIF tool.

    Unfortunately with the newer EMIF tool our results are actually worse.

    We manually copied all our timings to the newer spreadsheet, since the .txt files that you can export are apparently incompatible. With the GEL file generated from these settings the GEL files fail, too, with errors in all of the training steps. There are quite a few differences in the GEL files generated by the EMIF tool v1.1 and v1.5, but we narrowed it down to the register values for PHY_DCR (bit UBG set) and PHY_ACIOCR3 (field BGOEMODE from 0x0->0x2). If we used the values for these registers generated with the tool v1.5 we get the training failures, if we use the values that were previously set with 1.1 (ACIOCR3 wasn't set at all) the training works.

    We played around with the EMIF tool and noticed that switching "Total number of banks" between 16 and 8 changes exactly these two registers. Unfortunately the documentation doesn't really tell us what these mean. Can you tell us what the changes to PHY_ACIOCR3 and PHY_DCR mean? Is there a bug in the EMIF tool, or are we missing something?

    We're also not really sure abut the right address mapping for our DDR4 memory:

    We're using a single x16 chip with Column[9:0], Row[14:0], BA[1:0] and BG[0]

    With tool V1.1, the address mapping suggested by the tool after configuring width, column and row counts didn't really make sense, since it configured Row15 even though we set it to 15 rows total.

    With tool V1.1 after manually changing the mapping to what we "thought" was right we had aliasing at offset 0x800: R[14:0], BG[0], BA[1:0], C[9:2]

    With tool V1.1 we had a working GEL file with no aliasing after using the following mapping: R[14:0], BG[0], BA[1:0], C[8:2]

    With tool V1.5, the mapping suggested by the tool (for total banks = 8) is what I'd expect: R[14:0], BG[0], BA[1:0], C[9:2], but we had the aliasing (after manually fixing PHY_ACIOCR3 and PHY_DCR)

    With tool V1.5, the mapping that worked with V1.1 also worked, i.e. R[14:0], BG[0], BA[1:0], C[8:2]

    The new tool V1.5 writes several additional registers that weren't set with V1.1. Can you tell us what the functional changes are from V1.1 to V1.5? For example the GEL produced by V1.5 writes the register DDRPHY_DX0GTR0 to 0x00020002 (from the reset default of 0x00020000). This sounds like something that could affect our original problem of DQS gate training failing within U-Boot, but the documentation just says "4-0 DGSL R/W 0h DQS Gating System Latency".

    The documentation for the DDRSS registers in general is a bit chaotic, for example in terms of line breaks within the register field descriptions for fields like ADDRMAP_COL_B11, which makes it hard to tell which of the cases described in the description maps to which condition. The documentation also seems to copy too much from the (Synopsys(?)) IP core documentation, e.g. the documentation for DDRCTL_MSTR.DATA_BUS_WIDTH says

    "Note that half bus width mode is only supported when the SDRAM
    bus width is a multiple of 16, and quarter bus width mode is only
    supported when the SDRAM bus width is a multiple of 32 and the
    configuration parameter MEMC_QBUS_SUPPORT is set."

    I doubt that MEMC_QBUS_SUPPORT is a configuration parameter in the sense of the AM654x's programming capabilities, but rather something that had to be configured when synthesizing the DDRSS for the AM65x.

    -> Is the EMIF Tool supposed to be useable for a AM65x with a single x16 chip and the geometry described above?

    Regarding my issue about decimal separators:

    The EMIF tool seems to operate correctly after switching my Excel from , to ., but the .txt files exported by tool use , again. If you want to import the tool settings you need to search&replace the .txt file and changes , back to .



  • In reply to Dominic Rath:

    We've made some progress, our original issue (that U-Boot fails in DQS gate training) wasn't due to a problem in the EMIF tool but because the U-Boot code apparently isn't prepared to handle a 16-bit wide DDR memory bus.

    The other issues remain, e.g. we're not sure why we need to change DDRPHY_DCR and DDRPHY_ACIOCR3, or why we need the seemingly wrong address map.
  • In reply to Dominic Rath:

    Hi Dominic,
    Thank you for your detailed response.

    Since you are using a x16 device with only one BG pin (BG0), the tool sets DCR.UBG=1 to indicate that BG1 is unused and not connected to the memory. Additionally, since BG1 is unused, its output enable is disabled in ACIOCR3.BGOEMODE. BGOEMODE is bits 29:26, where 29:28 correspond to BG1, and bits 27:26 correspond to BG0, with the following definition
    2b00 = OE Dynamic
    2b01 = OE always ON
    2b10 = OE always OFF
    2b11 = Reserved

    After reviewing the formulas in the tool, it looks like there is a bug in BGOEMODE setting, in which the tool is erroneously setting it to 0x2 (which incorrectly disables BG0). The value for that bit field should be 0x8 (to disable BG1) if your total number of banks is 8. I will get this corrected in the next revision of the tool.

    As for address mapping, with your configuration:


    You should be using R[14:0], BG[0], BA[1:0], C[8:2], and as you suggest, this works for you. The MSB of the column address is not needed in x16 mode. This is described in the Synopsis spec, but is absent in the TRM. I will get the TRM updated with this info. BTW, the tool attempts to define a default address mapping based on your configuration, but it doesn’t take care of the x16 case well. I will get this updated in a future revision. With the above mapping, ensure that you don't have any aliasing and that you can access the full capacity of the DDR.

    As for additional registers, the tool handles a few different DDR types with varying configurations. I added some registers to accommodate the configurations that are supported, but sometimes these registers are not necessarily needed for all configs, so they are written with a default value. V1.1->v1.5 is mostly just adding new features, fixing bugs, and refining the configurations for each DDR type.

    In the case of DXnGTR0, these are general timing registers for byte n. It handles system latencies for DQS gate and write leveling. A default value is written before training, and then these values are updated after training based on training results. Ensure that you are performing this update after training (see Cleanup_Training() function in the GEL)

    We are aware of the TRM issues and are trying to get them fixed. The tool is intended to shield the user from all of the details of the controller and PHY configuration, so that is why this type of feedback is very valuable to get the EMIF tool in good shape.

    About the decimal separators, I’ve noted the issue with the import/exporting, and will get that into a future enhancement.

    I will feedback to our software team about the x16 incompatibility. Initially, uboot supported the DDR configuration on our EVM (x32), and we are still working to get the uboot structure in a state where it can easily be adjusted to support multiple configuration types for customers.

    If you have further questions or problems, let me know.


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.