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.

About EDMA controller on C64x

Good morning everybody.

I have a question about the EDMA controller queues.

In fact I had some problem related to the EDMA that I fixed increasing the size of queues (I changed the PQAR2 register for Q1).

Since chapter 4 of  spra994.pdf "TMS320C64x EDMA_Architecture" states that the default queue size Q2 is the following one:

 

 

So the queues have set of configurations for "Requestor Default Queue  Length" that generate a sum equal to 8.

Furthermore spraa994 states also:

"Keep in mind that the queue length per requestor is programmable, but the total queue length is not. The sum of all requestor lengths on a given priority must not exceed the total queue length of 16"

 

So my question is: why the default configuration uses only 8 of the 16 max queue length? I think that it could be useful in order to avoid EDMA controller stalls and (even better) to make more uncommon to incur a loss of a edma events.

What am I missing?

Any help will be very useful.

Giovanni Parodi

  • The total queue length of 16 per Priority Queue gives you a lot of capability. At least 50% of users do not have to change the default value, and it could easily that most users do not have to change from the defaults, which means that a queue depth of 8 would have been adequate for those users.

    But the "power users" like yourself will run into situations where you need more depth than 8, so the available depth of 16 becomes vital to the success of your project. Having the flexibility to increase the queue length for one or more Requestors makes it possible to meet your real-time goals with ease. You might specifically need to max out the Master Peripherals on Q2 (Medium) and also the QDMA on Q0 (Urgent) to get the queue depth to the point where you will not hit and TR (Transfer Request) stalls which can be devastating to a system.

    Since you can come up with many more scenarios that would need to adjust the queue depths than the designers could ever predict, a tradeoff was made to set the default queue lengths where they are, as shown in Table 6. Please consider the two options:

    • With the defaults as they are today, if you need to adjust the queue depth for one Requestor in each Queue, you need to change the parameter only for that one Requestor and can increase it by up to 8 for a huge increase in queue depth. No other concerns for the other Requestors exist as long as this additional 8 entries is enough.
    • If all of the defaults were instead doubled, such as going from 2/6/0 for Q1 to 4/12/0, then some users might be saved from any further adjustments. This is what you may have encountered. But if you still needed to adjust some parameter, such as adding 2 for Master Peripherals for Q1, then you would also have to adjust one of the other Requestors' queue depth. This puts the responsibility on you to make twice as many adjustments, plus leaves you at risk of undefined behavior if you were to accidentally increase one without decreasing another, and that could be a very difficult problem to debug.

    In my opinion, the defaults that we provide give adequate performance for many users and leave an easy task for the power users to adjust the queue depths to meet their specific needs. It is a tradeoff which we hope did not cause you too much problem in your system. The EDMA is a very powerful tool that can make your application run significantly leaner in terms of DSP MIPS required for data movement. Linking allows you to set up and repeat transfers without any further action by the CPU. Chaining allows you to setup complex transfer sequences involving multiple channels.

  • Hi, thanks a lot for your explaination, now I'm able to  understand the default settings and the problem involved in a wrong selection of these parameters.

    Thanks again,

    Giovanni