Forum Discussion

Mikhail_a's avatar
Mikhail_a
Icon for Occasional Contributor rankOccasional Contributor
2 years ago

Bad timings for MSGDMA IP on Agilex 7 FPGA

Hello!

I have a design based on AGFB014R24B2E2V FPGA device. This design implements a simple general NIC functionality and PCIe for connection to the host. Design is clocked by PCIe user clock and it is 250 MHz. I use two MSGDMA IPs core for moving data to and from host memory (one for stream to MM translation and one for MM to stream). The problem is that according to timing report there are a plenty (~60k) of failing paths in MSGDMA IP. I've attached a piece of timing report and utilization report below.

So my question is are there any ways to fix those timing issues? I couldn't find any performance data for this IP so I cant even learn whether I can use it in my design or not.

18 Replies

  • RichardT_altera's avatar
    RichardT_altera
    Icon for Super Contributor rankSuper Contributor
    2 years ago

    In the timing analyzer report, do you see any issue in the Fmax Summary report?

    Also, the configuration of the IP may impact the timing closure of this IP.

    Could you please provide me with your .qar project file so that I can investigate the issue further?

    This will help me analyze the design and provide you with more accurate insights.

    Thank you in advance.

    Best Regards,

    Richard Tan

    • Mikhail_a's avatar
      Mikhail_a
      Icon for Occasional Contributor rankOccasional Contributor
      2 years ago

      Hello Richard.

      Thank you for your answer.

      Unfortunately I can not provide you .qar file, but the design is pretty simple as there are 2 MSGDMA (stream to MM and MM to stream) directly connected from one side to MCDMA (PCIe) IP configured as BAM+BAS and from the other side to Avalon Stream Pipeline stage IP.

      Fmax report shows something like 170MHz max frequency.

      MSGDMA config is shown below. It is the same for both IPs (except of course the DMA mode).

      Prefetcher is disabled.

  • RichardT_altera's avatar
    RichardT_altera
    Icon for Super Contributor rankSuper Contributor
    2 years ago

    Understood that you are unable to provide the full .qar design. In that case, would it be possible for you to create a simplified version of the design that replicates the issue? As I am not expert in PCIE IP, so it may takes times to duplicate the issue.

    This will allow us to focus specifically on the problem area.

    Thank you for your understanding.


    Best Regards,

    Richard Tan


    • Mikhail_a's avatar
      Mikhail_a
      Icon for Occasional Contributor rankOccasional Contributor
      2 years ago

      Thank you for your answer.

      I will provide you with such design as soon as possible.

  • RichardT_altera's avatar
    RichardT_altera
    Icon for Super Contributor rankSuper Contributor
    2 years ago

    Are you able to create a simplified design with the replicated issue?


    Best Regards,

    Richard Tan


  • RichardT_altera's avatar
    RichardT_altera
    Icon for Super Contributor rankSuper Contributor
    2 years ago

    Thank for the design, I have received it.

    I am able to compile it in Quartus and see the setup failing path.

    Please allow me some time to investigate on this.

    Best Regards,

    Richard Tan

  • RichardT_altera's avatar
    RichardT_altera
    Icon for Super Contributor rankSuper Contributor
    2 years ago

    Sorry for the delay. It appears that I require additional time to conduct some testing.

    Apologies for any inconvenience caused.


    Best Regards,

    Richard Tan



  • RichardT_altera's avatar
    RichardT_altera
    Icon for Super Contributor rankSuper Contributor
    2 years ago

    Just a quick update to let you know that I'm still actively investigating the issue. I understand the importance of resolving it and I'm dedicated to finding a solution.

    I'll keep you informed of any progress made. Thank you for your patience.


    Best Regards,

    Richard Tan


  • RichardT_altera's avatar
    RichardT_altera
    Icon for Super Contributor rankSuper Contributor
    2 years ago

    I am close to finding what might causing the timing fail and I think it might be due to the msgdma IP limitation.

    I need to run a few more tests to confirm my finding.


  • RichardT_altera's avatar
    RichardT_altera
    Icon for Super Contributor rankSuper Contributor
    2 years ago

    The timing can be met by changing the msgdma configuration setting, with the "Aligned Accesses" option checked for the TX mSGDMA, and "Aligned Accesses" option + "No Byteenables During Writes" option selected for RX mSGDMA.

    The data width of the DMA is set to a very wide 512-bit, making it difficult to meet timing requirements.

    1) In unaligned mode, the input mux will be synthesized for the data path to perform a barrel shift and align the data correctly. This will result in a logic depth of a few layers and a width of 516 bits. Leading to increased logic utilization within the DMA and in the Qsys fabric.

    2) In aligned mode, this requires the byte enable generator logic to post Avalon supported byte enables to the fabric. It support hardcoded high byte enables which should make this logic go away.

    Best Regards,

    Richard Tan

  • RichardT_altera's avatar
    RichardT_altera
    Icon for Super Contributor rankSuper Contributor
    2 years ago

    Dropping a note to ask if my last reply was helpful to you?

    Do you need any further assistance from my side?


    Best Regards,

    Richard Tan


    • Mikhail_a's avatar
      Mikhail_a
      Icon for Occasional Contributor rankOccasional Contributor
      2 years ago

      Hello Richard.

      Your recommendation did help me to improve timing issues, not WNS is only -0.2, but unfortunately it affected the functionality of my device and with these settings it stopped working. As I understood there are no ways to improve timings without changing DMA IP settings? If yes then I thing this topic can be closed.