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.

AM6421: AM6421: GPMC Multi CS configuration Capacitive loading

Part Number: AM6421
Other Parts Discussed in Thread: TMDS64EVM

Hi TI Team,

This post is a follow-up to our earlier software query on GPMC multi-CS configuration, where a TI engineer Mr. Anil recommended we raise a separate thread for hardware design guidance:

e2e.ti.com/.../6326115

To summarise the problem points from that thread:

We have not tested this pattern, and my suggestion is to raise a new e2e for the specific use case of GPMC so that hardware experts can provide proper HW design recommendations.

Signal integrity concern remains: Multiple devices sharing GPMC_A[n:0], GPMC_D[15:0], GPMC_OE, GPMC_WE, and GPMC_BE lines increase capacitive loading.

Our Hardware Configuration

Custom board with the following devices connected to the GPMC bus:

1. FPGA — Microsemi Igloo2 M2GL090-FG676
   - CS0 and CS2
   - Non-Multiplexed 16-bit NOR Asynchronous
   - 3.3V I/O

2. NV_SRAM — Cypress CY14B116N-ZSP25XI (1M × 16-bit, 25ns)
   - CS3
   - Non-Multiplexed 16-bit Asynchronous SRAM
   - 3.3V I/O

Shared signals across all three CS lines:
- GPMC_A[21:0] — 22 Address lines
- GPMC_D[15:0] — 16-bit Data bus
- GPMC_OE, GPMC_WE, GPMC_BE0, GPMC_BE1

Hardware Questions:

Q1 — PCB Layout Recommendations for Shared GPMC Bus

we want to understand what to look for during board bring-up from a signal integrity standpoint:
- Are there specific signal groups (e.g., GPMC_OE, GPMC_WE) that are more susceptible to capacitive loading issues and should be prioritised for oscilloscope verification?
- What are the acceptable signal rise/fall time limits on GPMC address and data lines in Asynchronous NOR mode?
- Are stub lengths to each device a concern in async mode, and if so what is an acceptable stub length?

Q2 — Recommended Bring-Up Sequence for Multi-CS Validation

Since TI's EVM only validates CS0, we want to establish a safe bring-up sequence to validate CS2 and CS3 independently before enabling all three simultaneously:
- Is there a recommended bring-up and validation sequence for a multi-CS GPMC configuration?
- Are there any specific GPMC diagnostic registers or loopback test modes on the AM6421 that can assist in isolating per-CS signal integrity issues during bring-up?

Thank you for your support. Do let us know what is required from our side to get started on this.

Regards,
Harshith
Phytec

  • Hi Harshith,

    Good questions.

    Q1 — PCB Layout Recommendations for Shared GPMC Bus

    Except for the 16-bit 133MHz synchronous mode, we actually ran timings analysis for GPMC from 3pF to 30pF  (the datasheet reads 5 to 20pF of loading.

    You might want to try simulating the design first to evaluate the stub reflections and experiment with placement of signal branching.
    TI IBIS files and Infineon IBIS files are availble. You may be able to get IBIS from MicroChip for the IGLOO FPGA.

    GPMC has separate timings for each chip select. You may need to slow down the on all chip selects to give time for the signals to settle and have robust timings.

    If you know one endpoint is going to run with faster rates than the other, then you may try to route fly-by from with the slower memory in the middle. That might let you achieve better timings for the faster memory. Adding buffers may be an option to consider.

    Q2 — Recommended Bring-Up Sequence for Multi-CS Validation


    All 4 GPMC Chip selects are routed to the AM64x EVM (TMDS64EVM/ PROC101) 
    HIGH SPEED EXPANSION CONNECTOR (SEAF-30-06.0-L-05-2-A-K-TR)
    https://www.ti.com/tool/TMDS64EVM 

    AM64 IO LINK/BREAKOUT BOARD
    The GPMC address bus for IOSET2 is routable to the headers
    Use Datasheet Table 6-64. GPMC0 IOSETs
    https://www.ti.com/tool/TMDS64DC01EVM

    Schematics for that board /cfs-file/__key/communityserver-discussions-components-files/234/PROC102E1_5F00_SCH.pdf

    Since GPMC is so configurable with per-chip-select timings, I recommend starting with very relaxed timings for all chip selects. Then increase speed incrementally while performing write read verify operations across voltage and temperature ranges if you can.

    You might try building some boards with one of the GPMC endpoints removed to evaluate the impact on loading.

    I am aware of no in-built loopback tests. Write read verify from the memory is the loopback test.

    I'm willing to work with you to get this working.

    Regards,
    Mark