Forum Discussion

Ashoo's avatar
Ashoo
Icon for New Contributor rankNew Contributor
23 days ago

MCDMA IP D2H Queue Reset Failure during Channel Re-allocation

After successfully loading the binary and launching D2H (Device-to-Host) operations on my FPGA, the first channel is allocated successfully and transfers data without issue. However, when I try to al...
Pcie
Ashoo's avatar
Ashoo
Icon for New Contributor rankNew Contributor
9 days ago

Hi Wincent

We checked the sequence of channel initialization, queue reset, and resource management and made sure it was according to the official guide, but still the problem persists, nothing unusual was found in desmg log. Therefore we used gdb to check the actual line of code where the problem was occuring.

According to our analysis, problem occured in queue_reset function of ifc and mostly due to timeout being exeeded. Therefore we commented out the timeout block and re-compiled the libmqdmasoc.so lib and the problem resolved, and we are able to create the desired number of channels.

The natural doubt which occured to us was why was the timeout present in the code in the first place ?, Why is that value defined to be 2048 micro seconds?
If we comment it what drawbacks we will get ?

Please give us concrete reasoning.
I am attaching the screenshot of snippet of queue reset function call which is present in ifc_mcdma.c file.
Regards,

Ashoo 

Wincent_Altera's avatar
Wincent_Altera
Icon for Regular Contributor rankRegular Contributor
7 days ago

Hi Ashoo ,


Glad to hear that you are able to bypass the error, thanks for sharing with me how you work on it.

Based on my understanding.

  1. reasons for its presence - Without a timeout, if the queue reset bit never deasserts (for example, due to hardware malfunction or misconfiguration), the process would get stuck in an infinite loop. The timeout allows the software to detect hardware problems and handle them gracefully (log, clean up, alert the user, etc.).
  2. Why 2048 Microseconds - The value (2048 µs) is likely chosen based on typical hardware reset response times, with a margin for variability. Most hardware queue or register resets are expected to complete in a few microseconds to low milliseconds.
  3. If you comment out the timeout - that could potentially cause the hardware or logic ever fails to deassert the reset bit, your code will hang forever at that point, leading to a stuck process or system.

I recommend you to consider to increase the timeout value that suit with you system , for example 10000us or more.

Regards,
Wincent

  • Ashoo's avatar
    Ashoo
    Icon for New Contributor rankNew Contributor
    7 days ago

    Hi Wincent_Altera​ ,

    Thanks for your explanation regarding the queue reset timeout. We will increase the timeout value as suggested.

    However, we are currently observing a different issue during runtime testing.

    Previously, all channels were working correctly in D2H mode when initialized one by one. But now, during testing of same design and same application with/without timeout added:

    • When we initialize Channel 1 -> it works fine.
    • When we initialize Channel 2 -> it starts reading initially, but after 1-2 seconds, DMA gets stuck.
    • If we stop Channel 1 -> Channel 2 immediately resumes normal operation.

    Please provide insights regarding the same.

    I have a few questions regarding MCDMA behaviour as well:

    1. How does channel scheduling or balacing work internally in multi channel mode in AVMM configuration? Is there any mechanism and how to configure it, or do we need to manage balancing from software?
    2. Is it possible for one active chanel to starve other channel requests (e.g., due to descriptor fetch or AVMM bandwidth sharing)?
    3. We also observe that during each channel initialization, the queue reset sequence for each new channel initialized takes even more time.

    Please provide concrete reasoning.

    Regards,
    Ashoo

    • Wincent_Altera's avatar
      Wincent_Altera
      Icon for Regular Contributor rankRegular Contributor
      6 days ago

      Hi Ashoo ,

      Based on my understanding..

      Question 1 - The behavior where Channel 2 gets stuck when Channel 1 is active, but resumes once Channel 1 stops, is classic evidence of resource contention or starvation. This typically happens at the memory bus (AVMM) or descriptor fetch interface, where one channel monopolizes shared hardware resources, preventing others from proceeding.

      Question 2 - MCDMA typically using round-robin for channel access. This can depend on your IP configuration, but in most cases, the arbitration policy is not designed for strict fairness or bandwidth balancing.

      Question 3 - As more channels are initialized, each new queue reset takes longer. This is likely due to the reset logic waiting for access to shared hardware (e.g., AVMM, state machines, FIFOs). These delays are aggravated when other channels are active and holding bus resources.

      Hope that able to help you to move forward.
      I am just trying to share some experience based on what I understand from your issue, do correct me if there is anything I misunderstand.

      Regards,

      Wincent

    • Wincent_Altera's avatar
      Wincent_Altera
      Icon for Regular Contributor rankRegular Contributor
      2 days ago

      Hi Ashoo ,

      Is there anything else I can better assist you ?

      Regards,
      Wincent_Altera

      • Ashoo's avatar
        Ashoo
        Icon for New Contributor rankNew Contributor
        3 hours ago

        Hi Wincent_Altera​ ,

        Regarding bandwidth balancing: What are the best practices for efficient bandwidth distribution across channels to ensure high line-rate efficiency and minimum latency, while maintaining arbitration fairness to prevent channel starvation?

        Sincerely,
        Ashoo