Bad timings for MSGDMA IP on Agilex 7 FPGA

[Mikhail_a]

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.

[RichardTanSY_Intel]

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]

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.

[RichardTanSY_Intel]

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]

Thank you for your answer. 

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

[RichardTanSY_Intel]

Noted, I will wait for your design. 

Best Regards,

Richard Tan

[RichardTanSY_Intel]

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

Best Regards,

Richard Tan

[Mikhail_a]

Hello Richard!

Yes I've created a new design from scratch and got the same issue with timings. Here is a project archive in attachments.

[RichardTanSY_Intel]

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

[RichardTanSY_Intel]

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

Apologies for any inconvenience caused.

Best Regards,

Richard Tan

[RichardTanSY_Intel]

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

[Mikhail_a]

Thank you Richard.

[RichardTanSY_Intel]

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.

[RichardTanSY_Intel]

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

[RichardTanSY_Intel]

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]

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.

[RichardTanSY_Intel]

I apologize for any inconvenience caused by the design functionality not meeting your requirements.

Indeed, you are correct. Without changing the IP configuration setting to Aligned Mode, achieving timing closure with a 512-bit data width becomes very challenging, even with the design pipelined.

Just fyi, though it may not be your desired functionality, it is still possible to meet timing requirements with a smaller 32-bit data width in unaligned mode.

Best Regards,

Richard Tan

[Mikhail_a]

Anyways thank you for your help. At least I was able to get rid of some timing issues. 

[RichardTanSY_Intel]

Thank you for the acknowledgment. Since there are no further questions regarding this case, I will transition this thread to community support.

If you have any further questions or concerns, please don't hesitate to reach out. Thank you and have a great day!

Best Regards,

Richard Tan