Starterware/AM4377: GPMC delay between two commands

This actually could be caused by a number of factors. It is very difficult to optimize pipelining of single access commands to the GPMC (or really any peripheral). The code may be running from slow memory or may not be cached, so the ARM fetches and pipelining may be affecting the timing of the commands to the GPMC. You would have to check the assembly code produced to see if you are truly sending a write immediately followed by a read command. Also, a write followed by a read from the same location may incur some intentional latency by the GPMC.
Another possible source of the delay is that It is unclear what value you have for the CYCLE2CYCLESAMECSEN bit field, which will impact cycle to cycle timing.
It is easier to get single cycle read/write accesses by setting up DMAs

Thanks,
James

James,
Thanks for your reply and suggestions.
For CYCLE2CYCLESAMECSEN bit field, it was checked, returned 0 as expected.
For the DMA solution, customer can hardly accept the DMA usage in this application. Because it was not only consecutive read/write operation, the data write/read has the consequent relationship, which required strong sequence. So DMA is not acceptable in this case.
I think we might think about the cache usage . This is mainly because we experience similar issues on the AM335x platform, then it was solved by enable the data cache. So i'm trying to ask for help to figure out whether this is a way to deal with the current issue.

Below is the latest update from our SH FAE side. feel free to let us know if there's any additional info is required:

Customer config GPMC read/write 32bit data is 140ns. But customer find if they continuous read and write GPMC, there will be a 170~200ns interval time. They hope this interval time can be removed.
Customer use GPIO and oscilloscope to do the test. And the GPIO delay time has been removed.

The times to read GPMC(32 bit once) time
1 188ns
2 600ns
3 960ns
4 1290ns

Steven, I'm not sure I'm clear on exactly what they are expecting. Are they trying to get the best possible performance from a read/write/read sequence (or a write/read/write sequence)? Have they tried my suggestion of assembly code above. Certainly enabling instruction and data caches will help to reduce latency through the device.

Regards,
James

James,
They're expecting the low latency for the GPMC-FPGA read&write operation. As this is a real-time operation use scenario, for motor control, which was implemented by MCU before, such as M3/M4, they do have the requirement on low latency operation not only on GPMC but also on GPIO. We just closed the GPIO latency issue, now the GPMC-FPGA part still can hardly make a good latency number for their applications. So that's the customer asking for.
I listed the sequence between each operation just tried to claim that why they don't want to use the DMA function.
For the assembly part, I'm not sure they've done it or not. I'll check that soon. May I know by checking this, is it possible to optimizing the assembly code to solve this problem?

Steven, my real objective with the assembly code is to ensure the latency isn't caused by something else in the system. Their goal is to ensure commands sent to the GPMC controller are pipelined well enough to reduce the latency. As i mentioned in my first post, things like executing from slow memory, or code which is not initiating accesses sequentially (which can be caused by poor C compiling), can increase latency and make the commands to the GPMC controller less efficient.

Regards,
James

James,
Got it with thanks!
I'll check the feedback in tomorrow's morning call.

BTW, I know it is very hard to guarantee anything about the GPMC controller latency, is there any methods we can try to improve it?
I saw you mentioned slow memory, does that mean operating the GPMC sending/receiving data with OCMC RAM would help to make the performance better? What could be the most efficient trail? Do you have any idea?