FPGA Intellectual Property
PCI Express*, Networking and Connectivity, Memory Interfaces, DSP IP, and Video IP
6424 Discussions

Bad timings for MSGDMA IP on Agilex 7 FPGA

Mikhail_a
Novice
2,405 Views

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. 

msgdma_timings.png

utilization_report.png

 

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.

0 Kudos
18 Replies
RichardTanSY_Intel
2,360 Views

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

 

0 Kudos
Mikhail_a
Novice
2,347 Views

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).

retsd_0-1684148012019.png

Prefetcher is disabled.

 

0 Kudos
RichardTanSY_Intel
2,327 Views

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


0 Kudos
Mikhail_a
Novice
2,292 Views

Thank you for your answer. 

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

 

 

0 Kudos
RichardTanSY_Intel
2,273 Views

Noted, I will wait for your design. 

 

Best Regards,

Richard Tan

 

0 Kudos
RichardTanSY_Intel
2,198 Views

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


Best Regards,

Richard Tan


0 Kudos
Mikhail_a
Novice
2,184 Views

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.

0 Kudos
RichardTanSY_Intel
2,122 Views

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.

RichardTanSY_Intel_0-1685099385580.png

 

Best Regards,

Richard Tan

 

0 Kudos
RichardTanSY_Intel
2,088 Views

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

Apologies for any inconvenience caused.


Best Regards,

Richard Tan



0 Kudos
RichardTanSY_Intel
2,023 Views

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


0 Kudos
Mikhail_a
Novice
2,009 Views
0 Kudos
RichardTanSY_Intel
1,961 Views

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.


0 Kudos
RichardTanSY_Intel
1,952 Views

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

 

0 Kudos
RichardTanSY_Intel
1,925 Views

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


0 Kudos
Mikhail_a
Novice
1,918 Views

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.

0 Kudos
RichardTanSY_Intel
1,895 Views

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


0 Kudos
Mikhail_a
Novice
1,889 Views

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

0 Kudos
RichardTanSY_Intel
1,872 Views

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



0 Kudos
Reply