SDRAM performance bottleneck

Hi AQ,

Do you have any intention to run DSP at 160MHz ?

I hope that you would get good results if you drive the DSP in high speed, say 300MHz, 456MHz.

What interface are you using for SDRAM ?

Thanks Stalin for a reply. My application is required to run at 80 MHz or lower. Apart from that I am using EMIFB with a Micron 128Mb SDR SDRAM ( 2M x 16bit x 4banks). 

Hi AQ,

Have you probed/measured the EMIFB clock (80MHz) through CRO that confirm that you are running at 80MHz ?

May be it could clocked from SYSCLK5 or DIV4P5_CLK through "CFGCHIP3[EMB_CLKSRC]" register bit.

Although you need 80MHz, To confirm the EMIFB clock is the bottleneck,  Please have a try to increase the performance of SDRAM with new higher EMIFB clock say 150MHz (DSP at 300MHz)

http://processors.wiki.ti.com/index.php/OMAPL137,_AM17x,_C6747/5/3,_DA83x/2x/1x/0x_IO_Buffer_Premature_Aging_Assessment#Safely_Modifying_the_EMIFB_frequency_in_application

Thanks Stalin, 

I have hooked up the entire interface between SDRAM and OMAP on logic analyzer now. 

The clock is at 80Mhz.

I think at higher speed it for sure would perform better (ill try that tomorrow), but the question is, how to improve it at 80Mhz. With EMFIB controller, i don't have a control over burst size and auto precharge. 

One of the problem is see is that code space and data space both would be accessed over the same interface. The problem would be worse when both code and data are in the same bank and different rows. You would have to go through a precharge and activate cycle before the data could be accessed. This would stall the whole process.

Any idea ?

Hi Stalin,. 

We probed the sdram and attached is a screen capture of activity on the pins. CMD consists of (CS, WE, RAS and CAS). BANK is (BA0 & BA1). Red lines show READ and green lines show BURST TERMINATE. 

What we are unable to comprehend is the time in between those READs which is highlighted by red circle. Why does the ARM take so long to read the SDRAM again (almost 5us). 

Right now ARM is running at 80Mhz. If we run ARM at 160Mhz, this time becomes 250ns and if we run it at 40Mhz, this time becomes 1us. 

I would appreciate if you guys can shed some light. 

Thanks, 

AQ

Are you using any kind of OS?  You need the following to improve the performance:

1. Enable the cache
2. Configure the external memory as cacheable.

Without both of these items you'll get very long CPU stalls between every access and performance will be awful.  I suspect that's what's happening here.

I'm not clear whether you're testing from the ARM or the DSP and whether this is bare metal or with an OS.

Hi Brad, thanks for the time.

We are using ARM and no OS. We are trying to enable the cache now but why is the memory stalling in the first place ? We don't understand why the CPU has to wait certain amount of cycles before reading the next instructions (even though the timing control registers are set in EMIFB controller to numbers far less than the kind of stall we see).

Thanks, 

AQ

Thanks Brad, 

The wiki clears a lot of doubt. So now that we would try to enable the cache, i am still not sure how DMA would help the situation ? 

Apart from that, how can we use the DMA ? It would be responsible for both Instruction reads and Data read/write ? If so, any wiki on how the DMA needs to be configured etc ?

Thanks, 

AQ

Enabling cache is one solution. Using DMA is a different solution. If you're not familiar with DMA please do some research as it is a common building block of any processor architecture. 

Brad,

I was working with AQ on this performance.

We actually performed some performance comparision between OMAPL137 ARM9 processor and an ARM7 processor from our old product, under same condition. (Same running frequency, Same code, execute from external memory, data from external memory. the only difference is that ARM7 uses SRAM). The comparison result showed that OMAPL137 ARM runs much slower (a few times slower) that ARM7. Do you know if any difference between ARM7 and ARM9 contribute to performance slow down?

guosheng jin said:

Do you know if any difference between ARM7 and ARM9 contribute to performance slow down?

Yes.  ARM9 has an MMU, deeper pipeline, etc.  Per the wiki article, if you don't configure the MMU table and cache then you should expect poor data access speed to the external memory.