This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

dMAX - EMIF concurrence

 

Hi,

We are designing an external asynchronous memory interface which is quite slow (Dozens of 32 bits words in a c6727 - 8 bit EMIF FPGA)

Our solution to meet our real time constraints is processing these external access by dMAX in such a way that we can process in parallel using an internal buffer of such data.

We have one question about this.

If we are using EMIF interface to exchange data between our internal buffer and that external memory, and at the same time in our main code we require another EMIF access (let's say just a single write), will the EMIF remain blocked until the end of the DMAX transfer, or instead, main code access will be processed in the middle of dMAX and then dMAX will resume from that point?

If the dMAX blocks EMIF until it finishs, then I will get no improvement in my code since it will be stuck at this single access, isn't it?

There is a Quantum Transfer Size Limit but we are not sure if this only works among differente dMAX requests but  doesn't work with single access vs dMAX.

Thanks for your help...

 

 

 

 

 

 

 

  • Alex,

    I do not have a real answer, but you deserve some kind of response after waiting through the holidays. This is a very detailed question that may be hard to find anyone who knows the design details well enough to predict a 100% answer. Maybe someone has worked with this issue, and if you are lucky they may have posted something similar on this forum or on the Wiki. Please search both of those for some keywords like dmax emif contention or conflict, using the right syntax, of course.

    The EMIF peripheral will "decide" which memory command to send through at any time. The EMIF User's Guide should talk about how it arbitrates for simultaneous accesses, so there may be some priority settings you can configure to change the behaviour.

    If I were you and I was building a board, I would probably have an EVM of some type to try things out on. And I would strongly recommend you try some test cases and see if your CPU writes slip in between the dMAX accesses.

    There could be different results between using the dMAX burst read/write commands and the dMAX single read/write commands. It is possible that a burst will hold off other bus masters (DSP core) for the duration of the burst. But it is unlikely (in my guessing opinion) that a series of single read/write commands would hold off the DSP core. If single accesses go too much slower, then you could try doing shorter bursts, like 4 words at a time, for example.

    And the Quantum Transfer Size Limit would be a good thing to try varying to see how it affects any blocking you get. it is all worth a try.

    I know you wanted a clear and direct and complete answer. Sorry, but so far you have my comments and suggestions instead. Please let us know if you try some things and find some results.

    Regards,
    RandyP

  • Hi, Alex,

     

    Generally, if your async EMIF is slow, it means that all your accesses to that CSx space will block the entire EMIF, whether dMAX-powered or programmed-IO.  For slow interfaces, I would generally try to use interrupt-driven programmed I/O rather than a DMA channel. 

     

    Since you have only one EMIF on this part, and you need other CSx spaces, perhaps the best solution is to move the FPGA register access to a serial interface, SPI or I2C, or even McASP.  This would free up your EMIF for your faster accesses (also save pins on your FPGA, and headaches of multi-point routing of the EMIF bus).  Another solution is to move to a part with two EMIFs.

     

    best regards,

    Cameron