NXP 1052 and HyperRAM

[michaelrooker]

I am currently using a 1052 core in a design in conjunction with an Altera Cyclone 5 FPGA. One of the things that take place in this design is that the ARM core using the smart memory controller accesses a piece of memory within the FPGA made to look like SRAM and transfers the data into SDRAM also attached to the ARM. The SRAM block is roughly 90K in size and I actually use the DMA to move the data on fixed intervals (every 4msec). The transfer speeds seem to be sluggish but acceptable for now but going forward that transfer rate requirement might drop to every 900usec. This leaves me with an issue because I can not move the data that fast currently. The hardware engineer and I are looking at other solutions and we stumbled on the ISSI IS66/67WVH8M8ALL/BLL 8Mx8 HyperRAM. We were thinking that by placing 2 on the board and ping ponging between them (the FPGA is filling one while I am reading the other) we would get the performance we need and then some. I was just wondering if anyone has any experience with these parts and this processor, are there any issues I should be aware of? Clearly the processor has the interface since it can execute in place from Cypress Hyperflash and since the controller is a dual unit I should be able to use the other channel for this. I have attached the PDF on this part if anyone is curious.

[Hui_Ma]

Hi,

First of all, sorry for the later reply.

NXP provides AN12239 about how to enable HyperRAM with i.MX RT.

Please check here for the related software demo.

And please check below test performance about i.MXRT1050 works with HyperRAM (S27KS0641@1.8v):

Enabling cache to improve Hyper RAM performance more:

Test 1: Disable Cache (HyperRAM MPU config: non-shareable; Cacheable; Write back; Disable Dcache)

Test 2:  Enable Cache (HyperRAM MPU config: non-shareable; Cacheable; Write back; Enable Dcache)

Wish it helps.

best regards,

Mike

[michaelrooker]

I pulled the information you provided and it is clear that the HyperRAM is supported. In my original description I mentioned that we would be moving a 90KB data block every 4msec. This is just moving the data, I then have to process it and be ready for the next block. The data in this block will be continually changing so it is unlikely that the caching will help that much (or maybe my understanding of caching is not so good). That being said I looked at the performance charts and am having trouble understanding why the performance is so slow. The parts themselves are rated at 333MB/sec at 1.8V, if I give up 50% of this performance it is still well above the 65MB/sec (uncached) in your table. Is this a limitation within the flex spi controller in the RT MCU? If it is then this is not a viable solution to my problem.

[Hui_Ma · Accepted solution]

Hi Michael,

When enable DCache, the HyperRAM performance increased to 281MB/s, that shows the bottleneck is not at FlexSPI controller itself. The RT system design affect the performance, which is quite complicated. We can optimize the system configuration and enhance the system integrated performance.

best regards,

Mike

[michaelrooker]

I read the entire  document you provided AN12239 and towards the end I read the paragraph below, particularily the line I have highlighted in red. This does explain how the Dcache could have such an impact, I now understand and feel this is viable for my future goal. 

"Even with the FlexSPI read prefetch enabled, the read access performance is not as good as it could be. The key reason is the invalidation of the internal AHB read burst. The disabled Dcache will limit the AHB read access in the single mode. When the Dcache is enabled, the AHB read access can be implemented in the INCR burst mode and the performance improves, as shown in Table 5 and Figure 16."

Thank you and best regards

Hui_Ma