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.

  • Resolved

Starterware/TM4C129XNCZAD: EPI Bus Read and Write Priority

Mastermind 8695 points

Replies: 25

Views: 6838

Part Number: TM4C129XNCZAD

Tool/software: Starterware

I am reaching some timing limit for my LCD display. The TM4C129X LCD module is set to read from external SRAM through the EPI bus. The graphics libarary is configured to write to the same SRAM through the EPI bus.

Writing 1200 pixels seems to be my problem. Trying to writing this number of pixels results in an LCD interrupt, LCD_INT_UNDERFLOW. Writing 1,100 pixels give no problems. I am using 4BPP so writing a pixel is actually a read-modify-write because I only change 4 bits of a byte at a time.

Is there a way to prioritize reads from the EPI bus? Rendering the current frame is much more important than drawing the next frame. I would like a way to tell the writes to "chill" with the read FIFO is running low.

Other ideas are welcome.

  • In reply to Ralph Jacobi:

    Hi Ralph,

    Could you seek out a more objective answer? Everything is slow or fast compared to something else. 30 miles an hour is fast for a bicycles, but slow for a car on the interstate. These terms don't mean anything without context. If you insist a more expensive chip is essential, then I need an objective bandwidth to justify cost and effort.

    The RAM speed should work by the numbers. The LCD screen needs 12 megabytes per second to avoid underflow. The EPI bus is configured for 60 megabytes per second. The EPI bus spends ~80% of its time idle while the screen is being fed pixel data. Why can this idle time not be used efficiently for writing new data?

    This idle time can be used for writing ~500 bytes before the FIFO runs dry. Why can't I pend on a semaphore when the FIFO is low? What is stopping this configuration from working?

  • In reply to Peter Borenstein:

    Hi Peter,

    SRAM access speed via EPI with TM4C will depend on the device being used, so it would be specific to your system. For a setup like yours though the Asynchronous nature of SRAM results in latency which slows the process from peak speed. Also you are limited to the 60MHz EPI clock.

    As far as helping to provide a objective bandwidth to compare/contrast (fully understand the need for justification) I will need a bit of help on your end to help us understand the interaction between your SRAM and the TM4C.

    Can you measure the data access timing on the EPI bus? The signals of most interest will be the CSn and RDn signals.

    I am still following up on the EPI and FIFO specific questions, they haven't fallen deaf on my ears.

    Best Regards,

    Ralph Jacobi

  • In reply to Ralph Jacobi:

    Ralph,

    Looking at the RAM timing on a scope relieved that the signals were not going as fast as I thought they were.

    Changing EPIDividerSet(EPI0_BASE, 1); to EPIDividerSet(EPI0_BASE, 0); speeds up the bus and makes everything work.

    I am not sure what this line of code is doing because the API documentation seems to contradict the data sheet. The Tiva C API description says the function sets the EPI clock to the system clock, but the data sheet says you can only run up to 60MHz. What is actually happening when the system clock is faster than 60MHz and you write EPIDividerSet(EPI0_BASE, 0);?

    The 60MHz limit is mentioned in table 32-40 and 32-43 for modes other than Host Bus 8.

    The datasheet says in table 32-41 that the write signal is 1 EPI clocks. The RAM data sheet says it needs a write pulse width of 7ns. Therefore the board would work even if the EPI bus was set to 120MHz (8.3ns pulse width). On the scope, I see 22ns. I assume this means I am running near the max 60MHz. I feel safe regardless of how the divider is being set, but a through understanding would be appreciated.
  • In reply to Peter Borenstein:

    Hello Peter,

    Sorry for the delay, wanted to fully verify the following information before commenting.

    The TivaWare API is correct and also is in line with the datasheet if you look at the EPIBAUD register on Page 895.

    Peter Borenstein
    What is actually happening when the system clock is faster than 60MHz and you write EPIDividerSet(EPI0_BASE, 0);?

    Unfortunately, by doing this you are actually causing the device to operate out of specification in this situation. The dividers must be utilized correctly to get the correct frequency per data sheet specifications. The way the library API's are setup make this dependent on the user to do so (whether that's the right approach is a different story, but that is just how it is setup with the API). So that line is actually forcing the EPI Clock to operate at 120MHz and thus out of specification.

    While it may be the case that one device still works with the out of spec configuration, there is absolutely no guarantee such operation would be retained across devices in production. Therefore, I'm sorry to say but that is not a reliable solution to the issue you are facing with the timing constraints...

    Best Regards,

    Ralph Jacobi

  • In reply to Ralph Jacobi:

    That's depressing to read, but I'm glad you said it...
  • In reply to Peter Borenstein:

    Ralph,

    Could you clarify the timing retirements? The datasheet gives different EPI max speeds for different modes and doesn't specify Host Bus 8 mode, which is what I use.

    From the datasheet,
    Table 32-39 says SDRAM mode has max 60MHz.
    Table 32-42 says General Purpose has max 60MHz
    Table 32-43 says PSRAM has max 50MHz.
    Table 32-41 discusses Host-Bus 8, but gives no max.

    Host Bus 8 mode may not share this limit because the clock signal is not used in the external interface. Compare figure 32-20 with figure 32-21. There clock signal is not used! I think this reasoning is my saving grace.

    The lower 4 bits of EPICFG define these modes.

  • In reply to Peter Borenstein:

    Hello Peter,

    The EPI interface as a whole is not specified to operate at a clock speed higher than 60MHz. On Page 858, Table 11-2 shows all EPI Interface Options and what the Maximum Frequency's permitted are. Even for a single SRAM, the limit of maximum frequency is 60MHz. The datasheet does a poor job at connecting the dots on this, but the single SRAM mention on this table refers to both Host Bus Mode for 8 and 16 bits (which are detailed in Section 11.4.3).

    Best Regards,

    Ralph Jacobi

  • In reply to Ralph Jacobi:

    Well then back to the original issue.

    How can chip writes to EPI not impact the LCD controller's reads from EPI?
  • In reply to Peter Borenstein:

    I was able to confirm the EPI clock through the ALE. Table 32-41 says this signal should be 1 EPI clock.

    The duration is ~17ns or 60MHz with EPIDividerSet(EPI0_BASE, 1);
    The duration is ~8ns or 120MHz with EPIDividerSet(EPI0_BASE, 0); //too fast

    This 60MHz limit casts doubt on the SDRAM speed. TI's TIDM-TM4C129XSDRAM dev kit features the SDRAM chip ISSI S42S16320D . I use the SRAM chip, Cypress' CY7C1049GN30.

    The SDRAM chip has 5.4ns access time, but we know that doesn't matter due to the EPI's max clock limit. You cannot strobe faster than 16ns when running at 60MHz. The TM4C129X chip is incapable of leveraging the speed that makes SDRAM and SRAM different. There is a speed difference between these chips, but the TM4C129X does not use it.

    Both chips read out 8 bits at a time.

    I still want to understand the minimum bandwidth that makes SDRAM a necessity, but by these numbers, SDRAM wouldn't be faster...
  • In reply to Peter Borenstein:

    Hello Peter,

    Our expert who had past success with the SDRAM for this sort of application used 16-bit SDRAM, so whether 8-bit SDRAM would work for that size of a display isn't 100% clear. Furthermore, he stated that while the access times are the same, SDRAM does burst support which therefore allows it to read and write longer data sequences and that results in getting better throughput compared to SRAM (tested with 16-bit SRAM vs 16-bit SDRAM).

    Best Regards,

    Ralph Jacobi

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.