• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 2608 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

AM5726: GPMC to FPGA interface timings

Michael Shklyarman
Genius 12670 points
Part Number: AM5726

Champs,

Customer is connecting an FPGA to AM5726 over GPMC using synchronous multiplexed 16-bit NOR flash mode. The timing diagram for this mode depicted on Fig 7-7 in Data Manual is not sufficinetly clear to
implement the FPGA side of the interface. The relation between gpmc_oen_ren and the data signals (gpmc_ad[15:0]) appear quite logical and consistent
while it is not clear at all how the timing of the gpmc_wait fits in with the other two.Couple of questions:

1. What is the polarity of the gpmc_wait signal on this diagram: active high or active low?
2. if it is active low - why gpmc_oen_ren activates before gpmc_wait deactivates? Shouldn't it be the other way around?
3. if it is active high - why wait activates during data transfer?
4. is it possible to share any design/simulation files customer could utilize in their design? Or simulation waveforms/logic analyzer captures?

And another question on the CPU-FPGA interface topic: customer would like to have gpmc_clk to run continuously so as it can be used by the FPGA. The GPMC activates the clock only during the transaction
but it looks like gpio6_16.clkout1 can be used as a continuously running replica of the gpmc_clk. Question: is there any way to use gpio6_16.clkout1 AS gpmc_clk, i.e. have it drive the
GPMC transactions while running continuously?

Thanks
Michael

  • 0
    TI__Guru**** 393215 points
    The factory team have been notified. They will respond here.
  • 0
    TI__Mastermind 30110 points
    Hi Michael,

    I am looking into these questions and should respond within 24 hours.

    Regards,
    Mark
  • 0
    TI__Mastermind 30110 points

    Hi Michael,

    First of all, the WAIT signal is not required to be used if the read latency is deterministic. The GPMC is cycle-based - counters (like OEONTIME and OEOFFTIME) are programmed to activate and deactivate each control signal. Similarly, data is latched when the RDACCESSTIME counter expires. If a memory is not deterministic, then it can drive the WAIT signal to delay the latching of data it puts onto the data bus. The effective access time is a logical AND combination of the RDACCESSTIME timing completion and the wait-deasserted state detection.

    TRM Figure 15-61. Wait Behavior During a Synchronous Read Burst Access (see below) shows more detail about the control signal ON/OFF times, read access time, and the involvement of the WAIT signal.

    =-=-
    1. What is the polarity of the gpmc_wait signal on this diagram: active high or active low?

    MM: Active low is shown. WAIT can be configured as active low or active high.

    The polarity of the wait pin is defined through the WAITxPINPOLARITY bit of the GPMC_CONFIG register. A wait pin configured to be active low means that low level on the WAIT signal indicates that the data is not ready and that the data bus is invalid. When a wait pin is inactive, data is valid.

    =-=-
    2. if it is active low - why gpmc_oen_ren activates before gpmc_wait deactivates? Shouldn't it be the other way around?

    MM: OEn (driven by the memory controller) must be low to give the memory permission to drive data on the bus.

    Some NOR flash devices also require OEn to be low before WAIT is valid (tGHTV).

    WAIT and data must be valid before the programmed RdAccessTime (which can be stalled by an active WAIT signal).

    Let me investigate if it is permissible to allow OEn to go active low after the WAIT signal has been released by the memory, and if its OEOnTime counter is also stalled by the WAIT signal.

    =-=-
    4. is it possible to share any design/simulation files customer could utilize in their design? Or simulation waveforms/logic analyzer captures?

    MM: TRM Figure 15-61 is a better figure.

    See also the below flops used to latch the WAIT input. It may help to understand the different Waitmontime settings that are shown in Figure 15-61. note that the Ret_clock is the retiming GPMC_CLK after it is looped back from the IO pad. It helps the timing requirements.

    =-=-
    Question: is there any way to use gpio6_16.clkout1 AS gpmc_clk, i.e. have it drive the GPMC transactions while running continuously?

    gpio6_16.clkout1 can be used as a continuously running copy of the GPMC_CLK, but it cannot be used to latch data from the bus. The pad-loopback GPMC_CLK (not free-running) is the only available clock that is used to latch data from the bus. But the datasheet provides the skew (delay) between these clocks. This range of delays must be accounted for in during timing closure to ensure that timings are satisfied relative to the GPMC_CLK. Stated another way, when launching data with the gpio6_16.clkout1 sufficient margin must exist to ensure that the data can be latched with the GPMC_CLK.

    Refer to F23 td(CLK-GPIO) Delay time, gpmc_clk transition to gpio6_16.clkout1 transition under datasheet Table 7-26. GPMC/NOR Flash Interface Switching Characteristics - Synchronous Mode - Default.

    Hope this helps,
    Mark

  • 0 in reply to Mark M
    TI__Genius 12670 points

    Mark,

    Thank you for the thorough response. Once clarification wrt gpmc_clk: the pin P7 allows to also bring out clkout1 which is presumably the same that would appear on gpio6_16.clkout1 if it is configured to do so. If the FPGA side properly account for the skew between gpmc_clk and clkout1 - do you think the interface would work with the pinmux configured such that clkout1 signal present on the P7 (instead of gpmc_clk) and used as gpmc_clk?

    thanks
    Michael

  • 0 in reply to Michael Shklyarman
    TI__Mastermind 30110 points
    Hi Michael,

    While I agree that the same free-running clkout1 is pin-muxable from P7, I don't know if the published delay is valid for this ball. I will have to ask. I have my doubts - see below.

    Since the datasheet specifically specifies gpio6_16.clkout1, I am inclined to believe that the delay published in Table 7-26 and 7-28 is specifically from GPMC_CLK at ball P7 to clkout1 at ball F21 with the following note: (13) gpio6_16 programmed to MUXMODE=9 (clkout1), CM_CLKSEL_CLKOUTMUX1 programmed to 7 (CORE_DPLL_OUT_DCLK), CM_CLKSEL_CORE_DPLL_OUT_CLK_CLKOUTMUX programmed to 1.

    By using separate balls, we (and the customer) can verify the skew between these clocks. But if the two clocks share the same ball, then it is difficult to measure the skew (must switch mux modes between measurements).

    But yes, once the timing analysis accounts for the skew between GPMC_CLK and CLKOUT1, then CLKOUT1 can be used for data transactions.

    Hope this helps,
    Mark
  • 0 in reply to Mark M
    TI__Genius 12670 points

    Hi Mark,

    I have been looking into it on my side as well and my biggest concern is the range of the skew between gpmc_clk and gpio6_16.clkout1 that can be between 1.2 to 6.1 ns ( F23 interval in table 7-26). Does this range represent variability across devices? Also across years of usage and temperatures? Based on your comment it seems that once the skew is measured it is safe to use, but if , for example, ( and taking it to extreme) after 3 years of usage the skew changes from 2ns to 5 ns it may start causing IO errors, right? Is this correct interpretation or I am missing something?

    thanks

    Michael

  • 0 in reply to Michael Shklyarman
    TI__Mastermind 30110 points
    Hi Michael,

    Yes, the datasheet range accounts for allowable process, voltage, and temperature deviations across devices.
    Silicon process is fixed after the device is made, but voltgage and temperature can change leading to different skews.
    The published delay does include worst case asymmetrical aging, but that is a small factor. And there is some padding so we are able to avoid characterization (it is "guaranteed by design").

    I think to be safe, the customer needs to assure that timings are met with both extremes of the skew range. This may be accomplished by reducing output delay (for reads) or the setup time requirement (for writes), reducing trace length, and maybe reducing clock frequency.

    I hadn't considered measuring the skew and screening parts that dont satisfy the timings. Let me ask if that is feasible.

    Regards,
    Mark