• State TI Thinks Resolved
  • Locked Locked
  • Replies 12 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 2490 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.

RM57L843: Odd EMIF async timing behavior

Brian Viele94
Prodigy 180 points
Part Number: RM57L843

Asynchronous EMIF accesses have some really odd behaviors. 

For all below operations, we are operating on CE2 with the CE2CFG value set to 0x00360230 and bus clock is 96MHz

1) Running a writeb (strb) operation on an 8-bit configured chip select with Setup/Strobe/Hold set to 1/4/4 and a 96MHz bus clock gives the following plot (Green: /CS, Yellow: /WE). The /CS pulse seems to span 4 bus-cycles. A writel (str) operation takes the same amount of time but has 4 /WE cycles in the same time. 

2) Read operations seem to have the correct /CS and /OE periods (again Green: /CS Yellow: /OE) for 1/5/4 settings, but there is a huge delay in back-to-back transfers. As you can see in this case, the delay time is roughly double that of the single byte bus transaction!

This is all very surprising for a RT MCU with "Tightly Coupled Memories" as these delays are huge when pulling high amounts of bandwidth across the bus (say from a high-speed UART). Are there any configurations that we're missing which can remove these artifacts (seemingly always 32-bit ops on writes, large delays between transactions on reads).?

Thanks

  • 0
    TI__Guru**** 196616 points

    Hello Brian,

    The RevA silicon has the issue of "Extra WE/OE pulses in asynchronous EMIF access". This is listed on ERRATA:

    The issue has been fixed in RevB silicon.

  • 0 in reply to QJ Wang
    Prodigy 180 points

    We are using RevB silicon.There are no additional /OE or /WE pulses (as you can see from the scope screenshots).  Thanks for this reference, but it doesn't apply to this issue.

  • 0 in reply to Brian Viele94
    TI__Guru**** 196616 points
    Hi Brian,

    When interfacing to a 8-bit asynchronous memory, the EMIF_BA[1] and EMIF_BA[0] pins provide the least-significant bits of the byte address. They should be connected to ADDR[1] and ADDR[0] of the memory chip.

    Can you try different setting for EMIF_CS2 (0x60000000) region? For example, use device mode or strongly-ordered mode.
  • 0 in reply to QJ Wang
    Prodigy 180 points
    Hi QJ,

    I'm not sure how your comment applies. We understand the addressing of an 8-bit bus, this is not the issue. The devices attached to the EMIF (in our case UARTs) are functioning fine. Our issue is _not_ that the bus isn't working, rather that it is very inefficient. A read to a device that should have a 60ns bus cycle takes 260ns, and a write which should take 50ns takes 400ns. This means the bus utilization is terribly low, and CPU access on the bus take extra clock cycles.

    We have already mapped this region in the MPU to device mode. This was required early on due to the "Low Interrupt Latency (LIL)" feature of the Cortex-R5 which would abandon and re-issue read operations when device interrupts would occur to reduce latency. For a UART, this would cause FIFO data to get dropped on abandoned reads. Device and Strongly Ordered modes disable this.

    I would encourage you to re-read the issue. The short summary is

    - Read operation on the EMIF have a huge delay between accesses (175ns) that have nothing to do with the configuration
    - Write operations seem to take the bus for a 32-bit cycle. The /WE signal cycles the correct number of times, but the /CE pulse is much longer than the configuration specified. ex. A strb on a configured 8-bit CECFG gives a single cycle of /WE, but /CE remains asserted for the time of 4x cycles.
  • 0 in reply to QJ Wang
    Prodigy 180 points
    I'm curious, did you attempt to attempt to setup an EMIF connection and reproduce this behavior?
  • 0 in reply to Brian Viele94
    TI__Guru**** 196616 points
    Hello Brian,

    I am sorry for the delay. I am trying to reproduce the issue on a ASYNC SRAM. I haven't make the memory board work, and I will post my test result later.
  • 0 in reply to QJ Wang
    TI__Guru**** 196616 points

    Hello Brian,

    As I mentioned, there was a bug on EMIF nOE/nWE, and it was fixed on RevB silicon. This is my test result on revB silicon. It works as expected. I use max value for setup (7), strobe (63), and hold (7).   

    In the graph, Channel 1 is CS2, Channel 2 is nOE, channel 3/4: nDQM0/1. 

    1. Byte read: read 4 times

    2. Half word (16-bit) read: read 4 times

    3. Read word: read 4 times

  • 0 in reply to QJ Wang
    TI__Guru**** 196616 points

    Hello Brian,

    In RevA silicon, there is one extra nOE or nWE pulse when reading or writing data from/to the asyn memory.  

    1. write one 32-bit data to 16-bit async memory with RevA silicon. One extra nWE pulse is inserted (3rd one), and the nCS keeps low for the 3rd extra nWE pulse.

    2. Write 32-bit data to 16-bit Async memory using RevB silicon. The 3rd nWE pulse is gone, but the nCS still takes the same time as in RevA. Writing data to async memory will take longer than expected. 

  • 0 in reply to QJ Wang
    Prodigy 180 points

    Thanks for getting this setup so that you could test. While at a high-level glance, the bus is working, I think your statement that it "works as expected" isn't fully accurate. I think you're still ignoring the two points I have brought up. 

    1) By making the bus operate as slowly as possible, you have minimized the presentation of the read issue. Your zoom level makes it difficult to see exactly, but it looks like the /CS de-assert time (time between subsequent reads when /CS goes high) is on the order of 150 - 200ns. Since your bus cycle is configured to around 800ns ((8 + 64 + 8) x 10ns), the 150ns-200ns delay looks small. If you look back at my example, which has much shorter setup, strobe and hold times, the same delay is more than double the length of the actual read cycle. I suggest you change your setup/strobe/hold times to the shortest values to accentuate the issue I'm speaking of.

    2) You did not run the same test with writes. 

    As a note, you have the bus configured as 16-bits. Setting the bus to 8-bits will make the write issue more apparent. 

  • 0 in reply to Brian Viele94
    TI__Guru**** 196616 points
    Hello Brian,

    I did many measurement, and saw the big delay (CS high).
  • 0 in reply to QJ Wang
    Prodigy 180 points
    Would you call this delay "expected behavior" of an external memory interface? This drastically limits the usability of this interface as it really slows control flow of the attached peripherals. Is there any way this can be addressed in future silicon?