Pawel,
[quote user="Pawel Dabrowski"]4) "... the EDMA needs to wait until the previous
operation is completed."[/quote]
I am really not sure what you are asking with the reference and the statements here. Please continue with more clarification of your concern or question.
[quote user="Pawel Dabrowski"]DDR3 EMIF is much more complex than EMIF16, but isn't it similar ? [/quote]
Yes, they are similar. Both are EMIFs. Again, I am not sure what is the concern or question.
[quote user="Pawel Dabrowski"]
5) Yes I have already seen this bit, and already tested it. It seems that it adds some performance to EMIF. It doesn't generate any issues?
[/quote]
No, this fixes a problem. It does not add others.
[quote user="Pawel Dabrowski"]6) Regarding wrong comments . . [/quote]
For your benefit and any other posters, the quality of the advice you get is proportional to the quality of information you present. I tend to read comments for often than numerical code values, so I suspect others do, too. I tend to lose heart when I realize the lack of value of my time spent on a thing. Of course, I would say something similar if there were no comments at all.
[quote user="Pawel Dabrowski"]
7) DSP is simply reading sequential registers - informations from these registers are used for some decisions. After that it writes sequential sequential registers to set operation of FPGA..
[/quote]
My recommendation is to use a DMA operation (or QDMA) to read the FPGA registers into a buffer, then another DMA/QDMA to do the writes, too. This would be the most efficient way to get those operations done even if you were not running into this problem.
DSP reads will run one-at-a-time, waiting for the first to complete before moving to the next read. In the case where each read has to slip in between DMA read bursts, the delay for each DSP read will get extended a long time.
[quote user="Pawel Dabrowski"]Is there anything else that I can do to determine the issue ?[/quote]
To definitely state what the problem is, we would need a lot more detail on exactly when the DSP instructions occur relative to when the associated EMIF operation occurs. Since you have not been offering any logic analyzer traces showing these relationship, that may not be an option in your lab. So we will have to go more with educated speculation. What I mean is that I agree that you are getting stalls on the DSP accesses due to the DMA reads from the slow EMIF.
How often does the WAIT0 line go active extending the FPGA reads and writes? This could affect my understanding so far of the timing relationships. If WAIT0 is used often, or only when certain things happen, or when switching from one address range to another, etc., that can matter for a solution.
In general terms, it would be good to understand the timing relationships between the DMA requests and the duration of those transfers. I would expect that if you created a self-chaining DMA that will breakup the transfers in lots of short bursts, the timing should not get hurt by much. But there will be some fixed delay between the bursts. I would run experiments with shrinking the burst size (ACNT for A sync or ACNT*BCNT for AB sync) down to pretty small.
If you use a DMA/QDMA for the DSP accesses and use the same EDMACC and EDMATC, you will get that transfer to slip in between the FPGA reads once the current short burst completes.
Regards,
RandyP