SEMC SRAM Performance

[michaelrooker]

In a previous post I mentioned that I am using a 1052 core in a design in conjunction with an Altera Cyclone 5 FPGA.
The ARM core using the SEMC accesses a piece of memory within the FPGA made to look like SRAM.
I now have it transferring into the ARMS internal ram instead of SDRAM avoiding 2 transfers through the SEMC.
The performance on the SEMC seems sluggish and I would like to optimize it if possible (future designs will incorporate HyperRam to increase performance) but I do not have time to re-spin the hardware at this point.

The SRAM configuration is setup to appear as ADMUX, 16 bit wide and we are using a 166Mhz clock.
I have a while(1) loop that takes a pointer and reads the memory location over and over so I get minimal overhead from CPU instructions.
The read access for a single 16 bit word seems to be around 80ns (CE active low), this is acceptable but the problem is the idle state time. No matter what I do this time will not drop below 70 to 80ns. I can make it longer by introducing
processing between accesses but under normal conditions I am doing nothing else in this loop but a read. I do not see a configuration parameter to shorten this time but it seems that a hit like that every read is excessive.
I have tried a write in the same loop and the idle time is much shorter so I do not know what I am missing at this point. Any help would be appreciated.

[Yuri]

Hello,

  App note AN12437 (i.MX RT Series Performance Optimization)

provides performance data and recommendations.

https://www.nxp.com/docs/en/application-note/AN12437.pdf

https://www.nxp.com/docs/en/application-note-software/AN12437SW.zip 

Have a great day,

Yuri.

-------------------------------------------------------------------------------

Note:

- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored

Please open a new thread and refer to the closed one, if you have a related question at a later point in time

[michaelrooker]

Unfortunately Yuri after looking at this document I still see no answer, the setup for the SEMC is married to the device it is attaching to and in my case the best fit would be PSRAM (I did call it SRAM in the original post, not much of a difference but sorry for any confusion).

The SDK allows me to alter the entries in the 3 control registers (SRAMCR0, SRAMCR1, and SRAMCR2) but as far as I can tell there is nothing that controls the minimum time between reads. Additionally there are timing diagrams that supply the needed information for running in AYSNC mode but there are no diagrams regarding PSRAM synchronus mode of operation, yet in the control registers for SRAM there are fields (i.e. LC-latency count and RD-Read cycle time that clearly say they are for SYNC mode only). Are these errors in documentation or is there missing information? If the PSRAM interface (BR6 - Base Register 6) can run in SYNC mode are there complete timing diagrams anywhere that did not make it into the Reference Manual?

[Yuri]

Hello,

  The most quick accesses are expected between so called back-to-back ones,

when there are no gaps between transfers. Really additional pauses for arbitration,

bus turn-arounds are added, in particular - because of latency to go through internal

cross bars and AIP peripheral bridge.

  Recommendations and settings in AN12437 (and corresponding example) are quite

optimal.

Regards,

Yuri.

[michaelrooker]

Yuri,

Normally I would expect memory writes to be slightly longer than reads, but in this case I am seeing the opposite.

This is the code actually doing the test, as you can see it is very simple. I have attached a oscilloscope trace of 1 pass through and as you can see the reads are taking much longer because of the idle time between reads (which I have no control over). The write is actually slower but its idle state is around 15nsec as opposed to the 75nsec idle state between reads. If you start incurring this kind of pause between reads over 100k it adds up quickly. That does not even account for increment pointers etc. I am not executing code out of this PSRAM, this is just pure data reads. The access to the SDRAM does not seem to exhibit this behavior.

int cnt;
unsigned short *pdstptr;    
unsigned short tmpdata;

pdstptr = (unsigned short*)  0x84000000;    // Where our PSRAM starts
while(1)
{
    tmpdata = *pdstptr;                                       // 2 back to back reads
    tmpdata = *pdstptr;    

    for(cnt = 0; cnt < 4; cnt++)                         // short pause between tests
        tmpdata = cnt;

    *pdstptr = tmpdata;                                      // 2 back to back writes
    *pdstptr = tmpdata;    

    tmpdata = 0;                                                  // set break point here     
}

[Yuri]

Hello,

  Note, for back-to-back accesses, mentioned earlier special Load Multiple and Store Multiple

(assembler) instructions should be applied.  

Regards,

Yuri.