Forum Discussion

Ashoo's avatar
Ashoo
Icon for New Contributor rankNew Contributor
1 month 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
1 month ago

Hi Wincent,

 

Thanks for your reply

 

I am using the Altera MCDMA IP example design. When I test this example design with the software custom driver provided by Altera, everything works perfectly fine.

 

The issue only happens when I use our custom software driver. Here is exactly what is happening:

 

The first channel allocates perfectly and performs its read work without any issues.

However, when I try to allocate a second channel while the first one is still working, it fails.

It shows a "queue reset failed" and "channel allocation failed" error.

 

Could you please let me know:

 

Why does this happen when adding a second channel in our custom software?

What could I have done wrong in my custom driver logic?

What are the exact register steps or conditions I need to check in my code to rectify this?

 

Thanks for your help, Ashoo

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

Hi Ashoo ,

Is there anything else I can better assist you ?

Regards,

Wincent

  • Ashoo's avatar
    Ashoo
    Icon for New Contributor rankNew Contributor
    24 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
      22 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
        21 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