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.

[L138] EMIFA Extended Wait Async mode timing issue

Expert 1070 points
Other Parts Discussed in Thread: OMAP-L138, TMS320C6424

Hi TI,

Q1) Parameter #14 "Setup Time, EM_WAIT asserted before end of Strobe Phase" in table 6-23 (and figure 6-16) of the OMAP-L138 datasheet has the minimum value of (4E+3) for all operating points, where E is the EMA_CLK period. There is a violation of this time that I have observed at least at two of our custom boards.

These boards have OMAPL138BZWTD4 (rev 2.0) running at 24x18=432MHz with EMA_CLK of 432/3=144MHz (Tc=6.944ns). CVDD=RVDD=1.30V, DVDD18=DDR_DVDD18=1.80V, DVDD3318_(A,B,C)=3.30V.  Tamb=23°C, Tc=43°C, estimated Tj<55°C.

EMIFA_CE3CFG settings: R_SETUP=R_HOLD=1(2E), R_STROBE=7(8E), SS=0(normal), EW=1(enabled), WP1=1(active high), CS3_WAIT=1(WAIT[1]), MAX_EXT_WAIT=3(64E=444.4ns).

Nominal EMA_OE is 8E=55.56ns. That (4E+3) value for Tc=144MHz should be 30.78ns. Observed value is 34.5ns or ~5E, that is 3.7ns more, but there are no extended strobe cycles inserted as shown above. These cycles are inserted as normal when I increase that setup time for ~1ns. This violation time seems increasing when temperature is rising. Scope probes are 5mm away from OMAP balls, estimated delay is 2x35ps.

By the way, this parameter #14 in table 6-23 seems named incorrectly: "tsu(EMOEL-EMWAIT)" instead of "tsu(EMWAIT-EMOEH)".

Q2) Parameter #11 "Delay time from EMA_WAIT deasserted to EMA_OEn high" in table 6-24 (and figure 6-16) has the range of (3E-3ns)...(4E+3ns) for all operating points, or (17.8...30.8)ns at 144MHz. The delay I'm observing is (28.8...42.0)ns as shown below, that is (4.1E...6.1E) or (4E+1ns)...(6E+0.3ns). Maximum EMA_WAIT[1] asserted time is 408ns, that is lower than maximum wait time (444.4ns) set in EMIFA_CE3CFG.

I have reported this issue earlier (2 years ago), but there's no response yet. There was (4.6E to 5.6E) or (4E+6ns to 5E+6ns) delay (46ns to 56ns with EMIFA @ 100MHz) both for read and write transactions.

BR,

    Denis

Q2 UPDATE:   in rare cases MAX_EXT_WAIT time (444ns) was slightly exceeded.

Picture below has been obtained after extending MAX_EXT_WAIT to 555.5ns. Now that delay is (35.2...41.9)ns that is (5E+3ns)...(6E+3.3ns).

  • Hello Denis,

    We are working with the team to get this answered.

    Thanks for your patience.

    Regards,
    Senthil
  • Hello Denis,

    Sorry for the late response.

    1. Are you seeing this timing violation in only 2 of your custom boards or all boards ? Did you see this violation in TI provided EVM ?

    2. Do you see any functional issues due to this timing violations ?

    Regards,

    Senthil

  • Hello Senthil,

    1. I've seen these violations in every board I've checked - 5 boards for issue 1 (3 of them were checked with oscilloscope and another 2 with software test only) and 4 boards for issue 2. I didn't try to observe these violations in EVM.
    2. We have to increase the strobe phase duration compared to previously calculated values to avoid the board malfunction due to issue 1. Both issues lead to some decrease of the EMIFA throughput. We have 5 devices connected to the EMIFA (such as FPGA and TMS320C6424 HPI), so that slowdown is highly undesirable. These issues are even more hindering in our another device, where the EMIFA clock is only 100MHz.

    BR,
        Denis

  • Hello Denis,

    We are investigating this issue to figure out the cause.

    Meanwhile could you please clarify the test scenario that you carried out two years ago. I see a difference in EMA_CLK between the current test and old test.

    Are you using same boards now and then ?

    Regards.

    Senthil

  • Hello Senthil,

    These boards I've used for tests are two h/w revisions of the same device with very similar schematics.

    Pictures with EMA_CLK=144MHz in this thread were taken within a board running slightly modified version of release-to-manufacturing software.

    In 2012 it was simple low-level non-OS software test.  EMA_CLK=100MHz was only one of EMIFA clock rates I'd tried, and result - td(EMWAITH-EMOEH) expressed in terms of the clock period - was essentially the same at frequencies in approx. 66MHz to 148MHz range.

    BR,
        Denis

  • Hi Denis,

    I don’t see that the waveform you posted in your question violates the spec. The maximum time, 4E+3,  from the rising edge of the wait signal to the rising edge of the OE only applies if the wait is used during the access. The read access you defined include an OE time of 8E or ~56nsec. That is the length of the OE displayed in your scope capture. The wait signal is rising too early for the access to register an active wait state and delay the rising edge of the OE. Note that an early rising wait signal can’t shorten an access to less than the values defined by the R_STOBE signal. It can only extend an access. The image below is a rough representation of the access in your scope capture. The wait is only activated if an active wait signal is latched two clocks before the strobe counter is latched with a count of 1. The wait is going to an inactive state before that two clock interval so the state machine will treat the access as if the wait signal was never active. Do you have any cases where the time between the rising edge of wait is greater than 4E+3 and the OE is greater than 8E?

    Regards,

    Bill

  • Hi Bill,

    It seems the image you attached and all of your explanations are for active-low polarity of the wait signal.

    I've noted in the very beginning of my 1st post that the WP1 bit (in EMIFA_AWCCR, I just didn't mention that register's name) has the value of 1, that is, according to RM, "the EMIFA will wait if the EMA_WAIT pin is high". It will (must) wait if the setup time between (in my case) the rising edge of EMA_WAIT and nominal end time of the EMA_OE is not less than the minimum 4E+3 value of the parameter #14. In the 1st waveform I've posted this time is greater than that minimum (34.5ns vs. 30.78ns), but there's no wait states inserted. When I'm increasing this setup time to ~35.5ns, that is (4E+3)+4.7ns, the read strobe is lengthen as it should be.

    The maximum time of 4E+3 is for the another parameter - #11. The violation of this time is shown at the 3rd waveform of my initial post in this thread and in my older post. Again, WP1=1 selects active-high polarity of the EMA_WAIT signal. That's the case where "the time between the risinginactive edge of wait is greater than 4E+3 and the OE is greater than 8E" is greater than it should be.

    BR,
        Denis

  • Hi Denis,
    I see where I was mistaken. I'm writing up this question and passing it to the design team. I'll try and get an explanation for you.
    Regards, Bill
  • Hi TI,

    Is there any progress on this issue?

  • Hi TI,
    Is there any info from the design team? Did you even try to reproduce this issue?
  • Hi all E2E users,

    has anybody else observed these issues?

    I suppose that many of TI processors equipped with the same or similar memory controller may potentially be affected too. The silence from TI seems telling...

    BR,
        Denis

  • Hi Denis,

    Do you have LCDK board or Logic PD EVM with you?

    Is it possible for you to try reproducing the same issue with our boards? We haven't heard this issue from any of the prospective customers and other users. We are interested to investigate and scope this further internally and figure the corrective action.

    How you’re reproducing this issue? Your own custom code for read /Write or you’re using TI starter ware

    We do have your EMIF configuration, PLL and core voltage settings, can you please share the snap shot of your code flow and the hardware PCB layout topology.

    Regards

    Antony

  • Hi Antony,

    Our programmers have worked with Logic PD EVM four years ago, but unfortunately I have no access to this board now.

    I suppose it would be more convenient for you to use e.g. MityDSP-L138F SOM or another board which has an FPGA connected to the EMIFA. In our board we have Altera's Cyclone II FPGA so I can generate WAITx signals inside that FPGA with any required timings relatively to the read/write strobes.

    That LogicPD EVM has OMAP's EMIFA interface connected to the NOR (CS2n,WAIT1) and NAND (CS3n/CS4n,WAIT0) flash chips and to the EMIF expansion connector. I think it is possible to reproduce these issues at EVM - just by observing NAND/NOR access cycles that have WAITx asserted. The simplest test case would be just to read data from flash memory in the endless cycle after EMIFA initialization in Extended Wait Async mode. To reproduce issue #1 the nominal duration of the strobe phase should be decreased to the minimum and then increased step by step until extended strobe cycles will be inserted. 

    BR,
        Denis

  • Hi Denis,
    I have some more details from the design team concerning the setup to OE specification and the delays associated with this signal. The specification currently in the data manual defines the minimum as 4E+3. This is based on the number of clock periods needed once the wait signal has been synchronized plus the I/O buffer delay for the OE signal. Unfortunately the specification doesn't account for the delay of the Wait signal entering the part. The Wait signal is asynchronous and is driven externally. There is an I/O buffer delay associated with the signal between the pin and the internal IP similar to the I/O buffer delay for the OE signal exiting the part. In addition, the signal must be synchronized using the IP clock and there is a setup requirement between when the WAIT signal is present at the IP and the rising edge of the IP clock. When you include these delays, the specification is the following.
    WAIT su (EMWAIT - EMOEL) min = IODly + setup + 4E + IODly where IODly = 3ns and setup = ~2ns.
    If the clock is operating at 144MHz then E = 6.95ns and the spec becomes the following
    WAIT su (EMWAIT - EMOEL) min = 3 + 2 + 4*6.95 + 3 = 35.8ns
    The maximum should be the minimum + E to include the shortest time between the synchronization of WAIT to the longest time for the synchronization of wait or 42.75ns with a 144MHz clock.
    The setup time is approximate at this point. The design team is still checking on that parameter. Once I get an answer from them, I will try and get the data manual updated.
    Regards,
    Bill
  • Hi Bill,

    This information seems consistent with my observations with regard to the parameter #14 "Setup Time, EM_WAIT asserted before end of Strobe Phase".

    But in the case of the parameter #11 "Delay time from EMA_WAIT deasserted to EMA_OEn high" there's an additional delay of (at least) 1E.
    OMAP-L138 TRM (p.20.2.5.7) says that "The EMIFA will then return to the last cycle of the programmed strobe period and the operation will proceed as usual from this point". I suppose it is the cycle that wasn't taken into account in the specification.

    BR,
       Denis

  • Hi Denis,

    Both of these statements are incorrect.

    Parameter 11 lists the nominal delay as 4E but this would be the absolute minimum if the IO delays were zero. There isn't a nominal value for this parameter since the wait signal will enter the device asynchronous to the internal clock. The maximum value would be the 5E +3 +3 +2 that I described above where 3ns is the IO delay and 2ns is the internal setup from the wait to clock. The IO delay can change with process so the absolute minimum would be 4E+2. 

    The EMIF state machine will pause when the strobe counter reaches one. Once the wait is removed, three clock edges are needed to restart the counter. The fourth clock edge decrements the count to zero and the fifth clock edge will clock the OE or WE high. This equates to the 4E absolute minimum based on the state machine operation. 

    I'll add these to the list of changed needed.

    Regards,

    Bill

  • Hi Bill,

    Let me summarize to check my understanding:

    Parameter Description  № 

    Min

    Max

    Min
    (corrected)

    Max
    (corrected)
    td(EMWAITH-EMOEH)
    td(EMWAITH-EMWEH)
    Delay time from EMA_WAIT deasserted to EMA_OE high
    Delay time from EMA_WAIT deasserted to EMA_WE high
    11
    25
    3E-3 4E+3 4E+(tsu_int) 5E+2(tiodly)+(tsu_int)
    tsu(EMOEL-EMWAIT)(EMWAIT-EMOEH)
    tsu(EMWEL-EMWAIT)(EMWAIT-EMWEH)
    Setup Time, EM_WAIT asserted before end of Strobe Phase

    14
    28

    4E+3 - 5E+2(tiodly)+(tsu_int) -

    where tiodly(max)=3ns and tsu_int(min)=~2ns.

    Should the parameter #2 "Pulse duration, EM_WAIT assertion and deassertion"  tw(EM_WAIT)(min)=2E be corrected also?

    Should these changes be applied to other ARM/DSPs equipped with the same EMIF controller?

    BR,
       Denis