RM48L952: Recommended EMIF architecture for external NOR Flash and SDR SDRAM

Part Number: RM48L952
Other Parts Discussed in Thread: RM46L852, , TMDSRM48HDK

Background

I am designing a new device around the Hercules family. Before committing the PCB design, I performed a detailed analysis of the EMIF architecture to identify the most suitable external memory architecture.

 

Initially I selected the RM46L852, but after studying the EMIF Technical Reference Manual I found an important architectural limitation regarding the asynchronous memory interface.

According to the RM46L852 documentation, the asynchronous EMIF provides:

  • 16-bit data bus.
  • Up to 13 dedicated EMIF address lines.
  • Three asynchronous chip selects.
  • Maximum asynchronous address space of 32 KB per chip select.

After analysing the address mapping for 16-bit memories, I understood that:

  • EMIF_A provides the address bus.
  • EMIF_BA is used to generate the least significant address bit for 16-bit memories.
  • Therefore the available address pins only allow the controller to generate addresses covering a 32 KB linear address space for each chip select.

During this analysis I also investigated possible methods to increase the accessible NOR Flash capacity, including:

  • GPIO-controlled bank switching.
  • External CPLD address translation.
  • Automatic bank switching hardware.

However, after analysing the EMIF operation I concluded that every bank transition would still require firmware intervention, since the EMIF itself cannot automatically generate addresses beyond its native address space.

Therefore any external hardware solution would still require firmware support and additional software complexity.

For this reason I decided to evaluate the RM48L952 instead.

 

RM48L952 EMIF analysis

According to the RM48L952 Technical Reference Manual, the asynchronous EMIF provides:

  • 22 dedicated address lines.
  • 16-bit data bus.
  • Three asynchronous chip selects.
  • Up to 16 MiB address space per chip select.

For a x16 NOR Flash, the address mapping becomes:

  • BA1 → Flash A0
  • EMIF_ADDR[21:0] → Flash A1...A22

This results in:

  • 23 effective address bits.
  • 2²³ halfwords.
  • 2²³ × 2 bytes = 16 MiB

Therefore the entire NOR Flash can be linearly addressed without requiring any bank switching logic or GPIO intervention.

This architectural difference was the main reason for selecting the RM48L952 instead of the RM46L852.

 

I also analysed the SDRAM controller.

According to the Technical Reference Manual, the SDRAM controller supports:

  • One SDRAM chip select.
  • 16-bit SDR SDRAM devices.
  • One, two or four internal banks.
  • 8, 9, 10 or 11 column address bits.
  • Up to 128 MiB SDRAM address space.

The controller implements a standard JEDEC SDR SDRAM interface and therefore supports commercially available x16 SDR SDRAM devices.

 

NOR Flash selection

For firmware storage I selected:

Infineon S29GL128S10DHB020

The reasons are:

  • Parallel x16 interface.
  • Compatible with the EMIF asynchronous controller.
  • Capacity = 128 Mbit (16 MiB).

The selected capacity exactly matches the maximum linear address space provided by one asynchronous chip select on the RM48L952.

Therefore no external bank switching hardware is required.

 

SDRAM selection

For execution memory I selected:

ISSI IS45S16320F-6BLA1

Reasons:

  • SDR SDRAM.
  • x16 data bus.
  • Four internal banks.
  • Capacity = 512 Mbit (64 MiB).

Intended architecture

The intended memory architecture is:

Internal Flash
      |
      v
Bootloader
      |
      v
External NOR Flash (16 MiB)

Permanent firmware storage
      |
      v
Copy during boot
      |
      v
External SDR SDRAM (64 MiB)

Program execution

Stack

Heap

Global variables

etc

 

The firmware would be permanently stored in the NOR Flash.

During boot the firmware would be copied into SDRAM.

Afterwards the complete application would execute from SDRAM while the NOR Flash would only be used as non-volatile storage.

 

Conclusion

Based on the analysis presented above, I believe this memory architecture provides the best compromise between hardware simplicity, software complexity, execution performance and long-term maintainability.

The selected architecture consists of:

  • Internal Flash: bootloader and system initialization.
  • External NOR Flash (S29GL128S10DHB020): permanent firmware storage.
  • External SDR SDRAM (IS45S16320F-6BLA1): application execution after copying the firmware during boot, together with runtime data.

I chose this architecture because current automotive-grade MRAM devices with comparable capacities are still significantly more expensive than SDR SDRAM, making them difficult to justify for this design.

I would greatly appreciate TI's opinion on whether this architecture is appropriate for the RM48L952 EMIF and whether it is consistent with the memory architectures typically recommended or used in Hercules-based designs.

  • Hi Francisco,

    Thanks for your detailed write up. The EMIF address size limitations you've captured are accurate. You can refer to https://www.ti.com/lit/sprac96 also as a reference, but if 32 KB Flash is not sufficient for your use, then you will need to use RM48L952 to enable higher Flash. This is based on your system design requirements though

    I believe the Infineon S29GL128S10DHB020 is also automotive qualified to AEC-Q100 so can help meet your requirements for safety critical application. Plus you can meet the maximum capabilities of the EMIF.

    Regards,

    Peter

  • Hi  , thanks for you reply, but I have a new question.

    I am configuring an asynchronous NOR Flash interface using the EMIF controller of the RM48L952.

    According to section 17.4.2.2 "Configuring the Asynchronous Interface" of the RM48L952 User Guide, the timing calculation are:
    R_STROBE >= (tD + tELQV + tSU) × fEMIF_CLK - 1

    R_HOLD > = tH × fEMIF_CLK - 1

    R_HOLD + TA >= (tD + tEHQZ) × fEMIF_CLK - 2

    W_STROBE >= tELEH × fEMIF_CLK - 1

    W_SETUP + W_HOLD > = tEHEL × fEMIF_CLK - 2

    W_SETUP + W_STROBE + W_HOLD >= tAVAV × fEMIF_CLK - 3

    However, I have some doubts about the meaning and origin of the parameters used in this equation.

    In the EMIF switching characteristics table of the RM48L952 datasheet, parameters such as:

    tsu(EMDV-EMOEH). Setup time, EMIFDATA[15:0] valid before EMIFnOE high are specified with a fixed value (for example 30 ns).

    My questions are:

    1. In the equation above, does tSU correspond to the EMIF switching characteristic:
      tsu(EMDV-EMOEH)

      or is it a different parameter?
    1. The parameter tD is described as "Output delay time". Should this value be taken from the RM48L952 EMIF switching characteristics or from the external asynchronous memory datasheet?
    2. For asynchronous NOR Flash compatibility analysis, should the calculation use:

      • the fixed electrical timing parameters of the EMIF (tsu, th, output delays), together with the Flash AC characteristics,

      or

      • only the programmable EMIF timing parameters (R_SETUP, R_STROBE, R_HOLD) derived from the Flash timing requirements?
    3. Could you provide an example of the recommended calculation procedure for configuring R_SETUP, R_STROBE and R_HOLD for an asynchronous NOR Flash device using the RM48L952 EMIF controller, including the relevant RM48L952 EMIF timing parameters and equations from the TRM?

    The reason for this question is that the TRM equations appear to require fixed EMIF timing characteristics (tSU, tH, tD), while the EMIF configuration fields (R_SETUP, R_STROBE, R_HOLD) are programmable values, so I would like to understand the correct design flow.

    Thank you.

  • Hi   , could you help me with these questions?
    On the other hand, I need the Bill of Materials (BOM) for the TMDSRM48HDK because it does not appear in the downloaded zip file.

  • Hi Francisco,

    In the equation above, does tSU correspond to the EMIF switching characteristic:

    tSU stands for the setup-time, this is time that the data bus must be valid before EM_OEn goes high (indicating the start of the strobe phase). For reads you are correct it should represent tsu(EMDV‑EMOEH). For writes though, it is tsu(EMWEL‑EMWAIT)

    • The parameter tD is described as "Output delay time". Should this value be taken from the RM48L952 EMIF switching characteristics or from the external asynchronous memory datasheet?

    tD is delay time, but let me clarify this with team

    • For asynchronous NOR Flash compatibility analysis, should the calculation use:

      • the fixed electrical timing parameters of the EMIF (tsu, th, output delays), together with the Flash AC characteristics,

      or

      • only the programmable EMIF timing parameters (R_SETUP, R_STROBE, R_HOLD) derived from the Flash timing requirements?

    For compatibility, you only need the Flash timing parameters which are used to size the programmable EMIF fields (R_SETUP, R_STROBE, R_HOLD, W_SETUP, etc.

    1. Could you provide an example of the recommended calculation procedure for configuring R_SETUP, R_STROBE and R_HOLD for an asynchronous NOR Flash device using the RM48L952 EMIF controller, including the relevant RM48L952 EMIF timing parameters and equations from the TRM?

    There is example here you can reference since the peripheral is shared: https://www.ti.com/lit/an/sprac96a/sprac96a.pdf 

    Regards,

    Peter

  • Hi ,

    Thank you for your response and for confirming the meaning of tSU.

    For compatibility, you only need the Flash timing parameters which are used to size the programmable EMIF fields (R_SETUP, R_STROBE, R_HOLD, W_SETUP, etc.

    However, I would like to point out that, according to the timing equations in the RM48L952 TRM, the calculations appear to require parameters from both the EMIF controller and the external memory device.

    For example, you confirmed that tSU corresponds to the EMIF switching characteristic (tsu(EMDV-EMOEH) for read operations), while other parameters such as tELQV come from the external NOR Flash datasheet. Therefore, the timing analysis seems to involve parameters from both devices rather than only the Flash timing parameters.

    tD is delay time, but let me clarify this with team

    I will wait for your clarification regarding the tD parameter, as this is the only remaining point preventing me from fully understanding the calculation procedure described in the TRM.

    If possible, I would also appreciate a quicker response, as this information is currently blocking the completion of my hardware design documentation.

    Finally, I have another question. Could you please provide the Bill of Materials (BOM) for the TMDXRM48HDK evaluation board? I downloaded the hardware design package available on the TI website, but I could not find the BOM file in the ZIP archive.

    Thank you very much for your support.

    Best regards,
    Francisco Vera

  • Hi Francisco,

    tD is the output delay of the EMIF: the time from the internal EMIF clock edge until the address, chip select and strobe signals are valid at the RM48L952 pin

    For the BOM, the design files are older from Allegro I believe. But we use Altium at this time and I tried uploading the .brd file to the importer but it seems Altium is not able to extract the BOM data from this. If you have access to Allegro license, then it may be possible to do it that way but I am not able to test. 

    Regards,

    Peter

  • Hi Peter,

    Thank you for the clarification.

    However, I am still unable to identify the numerical value of tD.

    The RM48L952 datasheet contains several delay parameters such as:

    • td(TURNAROUND)

    • td(EMWAITH-EMOEH)

    • td(EMWAITH-EMWEH)

    but none of them seems to match the definition:

    "the time from the internal EMIF clock edge until the address, chip select and strobe signals are valid at the RM48L952 pin."

    Could you please indicate which specific timing parameter in the RM48L952 datasheet corresponds to tD used in the equations of Section 17.4.2.2, or confirm whether tD is an internal timing parameter that is not explicitly specified in the datasheet?

    After waiting for quite a long time and opening a support case to obtain assistance, I was hoping to reach a definitive answer so that this thread could finally be closed. I would therefore appreciate if this remaining point could be clarified.

    Regarding the TMDXRM48HDK BOM, I understand the explanation about the legacy Allegro design files. However, since this is an official TI evaluation board, I would have expected the Bill of Materials to be available as a separate document (for example, in CSV, XLS or PDF format), without requiring customers to have access to an Allegro license. Could you please check whether the original BOM is available internally or if there is any way it can be shared?

    Thank you again for your support.

    Best regards,

    Francisco Vera

  • Hi Francisco,

    Peter is currently out of office. Please expect a delayed response.

    Best Regards,

    Delaney

  • Hi Delaney,

    Thank you for letting me know.

    Is there another engineer who could help with this issue while Peter is out of the office?

    I have been waiting for almost a month for clarification on these questions, including opening a support case, and unfortunately several of the responses so far have not fully resolved the issues. At this point, the clarification regarding the tD parameter and the availability of the TMDXRM48HDK BOM are the only remaining topics preventing me from closing this thread and completing my hardware documentation.

    I would really appreciate it if another member of the team could review these remaining questions so that this matter can finally be resolved.

    Thank you very much.

    Best regards,

    Francisco Vera