AnsweredAssumed Answered

How to increase speed EIM consecutive acces on iMx6S

Question asked by Poussemousse on Jun 5, 2015
Latest reply on Jan 18, 2016 by Poussemousse



We are using an iMX6S and we are interfacing a 16bits parallel 45ns asynchronous SRAM.


I mention that we can't use it with Burst access, neither Page access.


EIM bus registers :

EIM_CS1GCR1 00010001

EIM_CS1GCR2 00000000

EIM_CS1RCR1 03000000

EIM_CS1RCR2 00000008

EIM_CS1WCR1 03000000

EIM_CS1WCR2 00000000


Our trouble is that we have not yet been able to perform same fast consecutive accesses as described in Reference Manual

22.8.3 Asynchronous Read/Write Memory Accesses Timing Diagram


22.8.5 Consecutive Asynchronous Write Memory Accesses Timing Diagram

In our application, between each CS activation, we have to wait a rather long time.


The only way to have consecutive accesses is to widen the bus, but dead time is always there if we are performing more than one Read ou Write.

I explain :

With a 16 bits configuration : reading or Writing 2 different words of 16 bits, imply to wait for about 250/280ns between the 2 accesses.


In the following pictures, we observe CS signal.

With a 32 bits configuration : reading 2 different words of 16 bits, through 2 consecutive accesses doesn't any dead time (90ns time  = 2 very consecutive access of our 45ns SRAM)  , but than we have to wait again for about 270ns between the 2 words of 32 bits.



With a 64 bits configuration: writing 1 words of 64bits = 4x 16bits word, through 4 consecutive accesses doesn't any dead time (180ns = 4x45ns) , but then we have to wait again for about 332ns for next 64 bits word Write


We are wondering if it is due to internal bus Exchange into the iMx6 which could explain this pain :


Data it going through AHB bus (Memory System Bus) to SPB bus (which is related to EIM Bus) callin AIPSTZ bridge.

Therefore, we have : 45ns latency because of the SRAM itself, which becomes 48ns because of clock synchronisation with EIM clock, plus at best 82ns (no idea where it comes from, maybe time between SPB to EIM) + 3 hclk clock (150ns) for each AIPSTZ bridge walkthrough.

Total : 48 + 82 + 150 = 280ns (we have not figured why we see 332ns).

We know that we can reduce access time staying on AMBA bus to go from AHB to APB and not going through AIPSTZ, by using SDMA or L2 cache (thanks to the MMU).


This solution rises 3 problems :

  • 1) It is tricky to set it up
  • 2) We always keep a dead time with the first walkthrough AHB to APB bus, and for each next access.
  • 3) We have no idea if transfer is started/finished


Any help would be very gratefully appreciated, we are lacking of new ideas.