- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Intel,
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.
Thank you!
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Can you let us know where do you download the ref design? Also, did you make changes to the ref design?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
We got the ref design here:
https://rocketboards.org/foswiki/Projects/Arria10PCIeRootPortWithMSI
Exact link:
http://releases.rocketboards.org/release/2016.02/pcierd/hw/a10_pcie_soc_devkit.tar.gz
The changes we made were minimal:
- Set the PCIe HIP to Gen-3 x8 as it was compiled originally at Gen-2 x4 in Qsys (found in its "subsys".qsys file)
- Regenerated Qsys files (both subsys and top).
- Changed .qsf file to expose the pin-outs of the additional 4 xcvr ports both for RX and TX, following the same xcvr pin settings as the original.
The additional HW pin-outs were referenced to the GHRD schematic file of the PCIe Root Port XCVRs
.
Thanks!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
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)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
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?
Thanks!
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page