Forums » Software Development »
MITYDSP OMAP-L138 EMIF FPGA / NAND shared bus access
Added by Mads Lind Christiansen over 13 years ago
Hi
This is NOT a problem we are seeing (yet?), but we are wondering whether this is a problem we might be seeing in the future.
We have the OMAP-L138 module where the ARM side will be running Linux and DSP side SYS/BIOS.
Our concern is when the ARM side is accessing the NAND flash reading and writing, how this will affect our DSP<->FPGA communication. The FPGA will trigger an EDMA transfer lets say a 10khz (might be faster or slower), causing data to copied from the memory mapped FPGA to internal memory in the DSP.
Will Linux and writing/reading of NAND flash give us a problem if we need very low (<1us) latencies in the above DMA transfer?
Thanks,
Mads
Replies (3)
RE: MITYDSP OMAP-L138 EMIF FPGA / NAND shared bus access - Added by Michael Williamson over 13 years ago
Hi Mads,
NAND does share the EMIF bus with the FPGA and you may run into a potential latency issue if you do not manage the accesses. NAND acceses, particularly writes, may be rather slow as the device can stall the bus (it uses the EDA_WAIT line). Sub-usec latencies are pretty tight, especially when you consider the time from interrupt notification through the ISR chaining to queuing the resulting read transaction. Is it really latency you are after or through-put? The EMIFA bus is only capable of 100 MHz operation. That's only 10 clocks total.
In any case, here are some thoughts (for what they are worth):
- If you only need NAND for a root filesystem, you might be able to use a RAM filesystem (loaded from NAND at startup). We have used RAM filesystems that are less than 12 MBytes footprint. This would keep the EMIFA bus clear for FPGA transactions. You might also consider SD/MMC (different bus).
- You could consider using the UPP interface between the FPGA and the OMAP-L138 DSP. This is a separate bus from the EMIFA, and provides up to 150 MBytes / second (75 MHz @ 16 bits wide interface). The latency would be about as good as you can do combined with the additional bullet below.
- You can adjust the EDMA priority settings for the various OMAP-L138 bus master engines. See section 11.3 of the Processor System Reference Guide. You could bump up the EDMA transfer priority over the ARM Data priority. This should ensure pending DSP transfers are queued first over ARM NAND transfers.
-Mike
RE: MITYDSP OMAP-L138 EMIF FPGA / NAND shared bus access - Added by Mads Lind Christiansen over 13 years ago
Hi Mike
Many thanks for your reply.
It is really latency we are worried about. We won't be transferring a lot of data, but timing is important.
We will have a look at the UPP interface.
Thanks,
Mads
RE: MITYDSP OMAP-L138 EMIF FPGA / NAND shared bus access - Added by Mads Lind Christiansen over 13 years ago
Hi Mike
I have a few questions regarding the NAND flash and EMIFA.
As you earlier mentioned I could try adjusting the EDMA priority settings.
From the EDMA priority settings below (which I just dumped directly from the registers)
MSTPRI0 = 0x44442222
MSTPRI1 = 0x44440000
MSTPRI2 = 0x54604404
It seems EDMA3_0 TC0 and TC1 has the highest priority (over EDMA3_1).
I am using the EDMA3 LLD driver on queue 0. I assume Queue 0 is EDMA3_0_TC0, queue 1 is EDMA3_0_TC1, queue 2 is EDMA3_1_TC0?
Is this correct?
What I cannot figure out is how the NAND Flash Controller/Linux driver is using the EMIFA interface.
Is it using the EDMA controller?
Is it doing simple IO read/write access?
We will sometimes in our system be dumping a file which contains a large amount of data (>MB) received from the DSP.
This will of course cause many writes to the NAND flash, so I would very much like to keep each NAND access as quick as possible
Many thanks for your help,
Mads
