05-16-2021 11:01 PM
Have a simple/basic block design with a PCIe bridge on a VCU118. (Also a JTAG/AXI bridge and some GPIOs to the board LEDs.) But something appears to be missing.
Getting what I suspect is one underlying error, having somehow to do with the pci_express_x16 external interface. Looking for a hint, not for someone else to do my work.
Fairly sure this is a stupid question. Also there is a fair chance I will solve this eventually. (Still very much on the learning curve.) But a hint would be appreciated.
Pushed the current project up the Github as: https://github.com/pbannister/2_vcu118_pcie_2
The DRC report is perhaps most succinct.
The Methodology report looks like it might be complaining of the same root cause.
Looks like I am missing something as to the binding of the pci_express interfaces, but have not yet figured out what...
05-17-2021 10:03 PM
For me it sounds like you haven't provide the constraints for tx and rx pin location. Could you please open the Synthesis Design. Change the layout to IO Planning and check does the pins are assign for MGT pins or NOT? If not, please assign there manually.
05-18-2021 08:23 AM
This design is for a VCU118, using stock PCIe IP. The IP chose the quads (hard IP block?) and I have not tried to override. Would expect the PCIe tx and rx pins to be chosen by default. So slightly bemused as to why these might not be assigned.
View from IO Planning - does this confirm your suspicion?
05-18-2021 08:46 AM
Hi @dreadedhill ,
Could you please create an example design for same configuration and see how tools is placing these constants? For me pins 0:15 the correct arrange of bank will be Bank 224:bank 227. It seems that the constraints are NOT correct.
Also please share your xci file with us.
05-18-2021 11:35 AM
Updated the Github repository: https://github.com/pbannister/2_vcu118_pcie_2
(Still working on the .gitignore rules - not yet convinced.)
When I drop down to Run Implementation is seems to be assigning to pins properly. I did check the board schematic from the PCIe card edge to the FPGA pins. Expecting banks 224-227 to be used - and from the Implemented | Package view, it appears that they are.
My original confusion comes from running the reports under RTL ANALYSIS. Perhaps the warnings emitted there are a red herring? Or perhaps I am meant to constraint the package pins / port placement manually? Or ... ??
05-18-2021 02:35 PM
Sure. Attached all the XDC and XCI files in a ZIP.
Note this is something of a moving target. Wanted to get a clean build, so did Project|Save As... and am re-building from the new project -in Github as: https://github.com/pbannister/2_vcu118_pcie_3 . Aim is to collect the DRC and Methodology reports at each stage, to see what that tells me.
Again, this is very much a learning-curve exercise. There is something going on around the PCIe Express IP. (Also getting warnings around TXOUTCLK?) Aim is to try and tease out the pattern.
05-18-2021 11:48 PM
Re-generated the project through Implementation. The reported complaints have changed - no notion why. Ran and saved reports (methodology, DRC, and others) at stage. From comparing I see the reports (for example: report_methodology) are run with different options, so that explains the differing reports.
The theme remains with the pci_express_x16_rxn and pci_express_x16_txn path through the design.
The DRC report from RTL Analysis:
The Methodology report from Synthesis (and same from Implementatio:
Pretty sure I am missing some common element.
06-12-2021 09:38 AM
Yeh. The "accepted solution" has nothing to do with my problems.
First, I was massively side-tracked by testing wrong. My current (corrected) testing cycle is:
Before I was re-loading the FPGA while powered-on and containing my previous design. Seemed to work ... but did not. Linux does not handle the changed device well. Also I am unsure if the re-programmed FPGA carries over any (improper?) state from the prior design. The state of the PCIe interface on both host and card are dubious. Got all sorts of confusing results, before.
At present, my design is seen on the PCIe bus, and my Linux driver module can find and initialize the PCIe interface. This is great!
My first attempt by the host to read from the card (via PCIe) causes Linux to re-boot ... so not there yet. Whether the complaints from Vivado point to the cause, I do not know. (This is single-stepping through the test program, and the line of code that reads a word from the memory-mapped BAR causes the crash.)
Trying to figure out my next step, is today's exercise.