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
    30 days ago

    Hi Ashoo ,

    Your custom driver most likely has a flaw in the channel initialization, reset, or resource management sequence. 
    Carefully compare your register access flow to the reference driver and the our design example
    Paying special attention to channel reset, status polling, and queue setup. 

    BUT to confirm that , please do check your dmesg log.

    Regards,

    Wincent

  • 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