EMA_WAIT and bus contention on L138F
Added by Mostafa Afgani almost 11 years ago
We have a project which uses CS4 and CS5 to write and read data from a pair of FPGA FIFOs respectively. CS4 is used exclusively for writing while CS5 is used exclusively for reading. The config register settings are:
/* CS4 config /
AEMIF_A3CR = (0 << 31) | / Select Strobe /
(0 << 30) | / Extended Wait /
(0 << 26) | / Write Setup-1 in EMA_CLK /
(0 << 20) | / Write strobe-1 in EMA_CLK /
(0 << 17) | / Write Hold-1 in EMA_CLK /
(0 << 13) | / Read Setup-1 in EMA_CLK /
(4 << 7) | / Read Strobe-1 in EMA_CLK /
(0 << 4) | / Read Hold-1 in EMA_CLK /
(0 << 2) | / Turn-Around in EMA_CLK /
(1); / Bus Width (16 bits data bus) *//* CS5 config /
AEMIF_A4CR = (0 << 31) | / Select Strobe /
(0 << 30) | / Extended Wait /
(0 << 26) | / Write Setup-1 in EMA_CLK /
(0 << 20) | / Write strobe-1 in EMA_CLK /
(0 << 17) | / Write Hold-1 in EMA_CLK /
(0 << 13) | / Read Setup-1 in EMA_CLK /
(4 << 7) | / Read Strobe-1 in EMA_CLK /
(0 << 4) | / Read Hold-1 in EMA_CLK /
(0 << 2) | / Turn-Around in EMA_CLK /
(1); / Bus Width (16 bits data bus) */Given that we don't use WAIT, both WAIT_0 and WAIT_1 were ignored from the design and the FPGA automatically configured them as inputs with pull-down. With this, CS4 and CS5 transfers worked perfectly but we noticed a significant slowdown in data transfer to/from the NAND flash (CS3) whenever there was concurrent data transfer to/from the FPGA. The reason for this must be WAIT_0 being an active low signal and pulling it down sets it to always active.
To fix this, we tried two things:
1. Leave the WAIT signals tri-stated on the FPGA,
2. Set them low (i.e., active) when CS4 or CS5 is active, tri-stated otherwise.
However, in both cases, the JFFS2 driver spits out a whole bunch of warnings and CRC errors whenever there is concurrent access to the bus -- seemingly indicating contention. We just can't figure our why this should happen.
Any suggestions? Thanks in advance.
Replies (6)
RE: EMA_WAIT and bus contention on L138F - Added by Michael Williamson almost 11 years ago
Hello,
How much bandwidth are you using for the FPGA accesses? Have you looked with any sort of bus analyzer (perhaps in chip scope) to assess the access logic? If the WAIT pin is getting hit, the slowdown could also be the ECC logic and error handling in the NAND driver. You of course are sharing a common data bus, so there will be a slow down of either NAND or FPGA activity while the other is occurring (you can't do both access concurrently, they are queued transactions by the EMIFA controller, of course).
For the WAIT pins, you need to ensure to disable the pull-downs completely on the WAIT lines and make those pins high impedance ('Z's). The FPGA pull downs/ups are fairly strong and the NAND likely tri-states when not asserting WAIT (I need to confirm this). If you interfere with the WAIT logic at all, it will create problems with the ECC logic and the NAND access state machine. Do not pull them up or down, leave them tri-stated with no pullup options and it should work ok.
Make sure that your constraints file does not include a PULLDOWN or PULLUP option on those pins and that you float unused IOBs in the bitstream generation options in the event that the logic is stripped from your design by the synthesis/place and route tools.
You should be able to support what you are trying to do (we've done it here on several occasions).
-Mike
RE: EMA_WAIT and bus contention on L138F - Added by Mostafa Afgani almost 11 years ago
Hi Mike,
Thanks for the suggestions.
Not sure I understand what you mean by FPGA access bandwidth. It is being used to implement the frontend of a high speed wireless communication system so we are using the the bus pretty much continuously. It is being used to transfer 16bit words with the OMAP running at 456MHz. I understand that the access by NAND and FPGA cannot be truly concurrent since it is a shared bus but I would have thought that when the processor switches over to a CS line (say 4), data on the EMIF or the state of the WAIT line should not have any effect on peripherals on the other CS lines (e.g., 3).
We did try making the pins outputs tied to a constant 'Z' but that still caused the JFFS2 driver to report CRC/Read errors during periods of heavy FPGA activity -- and that is something which is baffling us completely. The constraint file is also free of any PULLDOWN/PULLUP directives on the WAIT lines. Haven't tried setting unused I/O to float yet so will give that a go and report back.
Best regards,
Mostafa
RE: EMA_WAIT and bus contention on L138F - Added by Michael Williamson almost 11 years ago
One thought:
Is it possible the tri-state drive logic for the data lines off the FPGA is creating bus contention? Perhaps there is a bug in the EMIFA interface that is not parking/tri-stating the data lines soon enough after OE is deasserted? Wondering if you need to set a higher TA in the EMIFA configuration.
-Mike
RE: EMA_WAIT and bus contention on L138F - Added by Mostafa Afgani over 10 years ago
Hi Mike,
I've now also tried setting unused I/O to float and increasing both the TA and Read Hold to 4 cycles. I've verified the timing change with ChipScope but unfortunately it has had no effect on the JFFS2 warnings.
Attaching a copy of the bare-bones ISE project I am using to debug the EMIF interface. The CS4 and CS5 configs are currently:
AEMIF_A3CR = (0 << 31) | /* Select Strobe /
(0 << 30) | / Extended Wait /
(0 << 26) | / Write Setup-1 in EMA_CLK /
(0 << 20) | / Write strobe-1 in EMA_CLK /
(0 << 17) | / Write Hold-1 in EMA_CLK /
(0 << 13) | / Read Setup-1 in EMA_CLK /
(4 << 7) | / Read Strobe-1 in EMA_CLK /
(2 << 4) | / Read Hold-1 in EMA_CLK /
(3 << 2) | / Turn-Around in EMA_CLK /
(1); / Bus Width (16 bits data bus) */AEMIF_A4CR = (0 << 31) | /* Select Strobe /
(0 << 30) | / Extended Wait /
(0 << 26) | / Write Setup-1 in EMA_CLK /
(0 << 20) | / Write strobe-1 in EMA_CLK /
(0 << 17) | / Write Hold-1 in EMA_CLK /
(0 << 13) | / Read Setup-1 in EMA_CLK /
(4 << 7) | / Read Strobe-1 in EMA_CLK /
(2 << 4) | / Read Hold-1 in EMA_CLK /
(3 << 2) | / Turn-Around in EMA_CLK /
(1); / Bus Width (16 bits data bus) */Thanks for taking a look. Do you see anything out of place?
Best regards,
Mostafa
| EMIFTest.zip (1.24 MB) EMIFTest.zip | ISE Project for probing/testing EMIF interface |
RE: EMA_WAIT and bus contention on L138F - Added by Michael Williamson over 10 years ago
Just for sanity,
Have you confirmed you are writing to the correct AEMIF registers? CE3 is the NAND, and you are hitting "AEMIF_A3CR" in the above. I get a little confused about the register numbering vs. the CS numbering. Just want to make sure that you aren't whacking the NAND timings instead of the two FPGA chip selects (CS4 and CS4)....
-Mike
RE: EMA_WAIT and bus contention on L138F - Added by Mostafa Afgani over 10 years ago
Hi Mike, relevant definitions from the header:
# define AEMIF_BASE 0x68000000 # define AEMIF_AWCCR *( volatile Uint32* )( AEMIF_BASE + 0x04 ) # define AEMIF_A1CR *( volatile Uint32* )( AEMIF_BASE + 0x10 ) # define AEMIF_A2CR *( volatile Uint32* )( AEMIF_BASE + 0x14 ) # define AEMIF_A3CR *( volatile Uint32* )( AEMIF_BASE + 0x18 ) # define AEMIF_A4CR *( volatile Uint32* )( AEMIF_BASE + 0x1C )
this matches the register addresses given in the OMAP-L138 datasheet.
-Mostafa
