We are having timing violations reported by TimeQuest when using PCIe HIP configured as Root Port @ Gen-3 x8 256bit using your downloadable GHRD (w/ pcie) files for Arria 10 SOC DevKit as reference.
We intend to use A10 SOC Devkit for our testing and we always encounter negative slacks on the following:
Slow 900mV 100C Model Setup Summary
Slow 900mV 0C Model Setup Summary
The A10 Device Model selected is 10AS066N3F40E2SGE2 (from GHRD)
We are using Quartus 17.1 with the latest patches for this version.
Also, attached is our .sta.rpt file (converted to .txt) for your reference.
I'll attach more files for more details of our problem on your request.
We got the ref design here:
The changes we made were minimal:
The additional HW pin-outs were referenced to the GHRD schematic file of the PCIe Root Port XCVRs
I would assume that the original design from the rocket board do not have timing violation. can you confirm that?
What you can do is try number 1 first and number 3 to see which causes the timing violation.
But, you should understand how does the timing behave in the FPGA and make the timing closure. Otherwise, you might ended up writing the wrong constrain and run the full compilation.
Make sure you go through the module https://www.intel.com/content/www/us/en/programmable/support/training/course/odsw1115.html and all the follow on courses before you start looking on timing closure on your design. You will be understand why time quest reporting negative slack on your design.
Thanks for the tips. We compiled the original design without any changes. It only had minimal timing violations, specifically on "Recovery" only, unlike when we compiled it to Gen-3 x8 which yielded more timing violations as was found on the sta.rpt file I attached previously. We also have tried the steps you mentioned. So far, we still have no clues to what causes the violations.
The GHRD in the link was compiled using Q15.1 and we are using 17.1. Could it be possible that different versions of Quartus will also yield different results?
I will go through the module you suggested. (thanks for this)
Yes, changing the quartus version will yield different result.
I see that your report failing is soc_inst|pcie256_0|pcie_a10_hip_avmm|coreclkout
You have to check where does this clock connected to? Usually it would user logic clock.
I have attached one of the paths reported by TimeQuest and a screenshot of Timequest while viewing (RAR file). The path chosen has the longest delay among the rest for "SETUP".
I tried reporting 1000 paths, and even 10k paths, but TimeQuest filled them all up with violated paths.
From the looks of the report, seems that the components outside connected the PCIe HIP (particularly, the bridges) are the ones containing the violated paths. Do you have any suggestions as to how we should get around them?