cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
dreadedhill
Observer
Observer
772 Views
Registered: ‎01-26-2019

Proper binding to pci_express on VCU118?

Jump to solution

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.

dreadedhill_0-1621230236006.png

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.

dreadedhill_1-1621230756984.png

The Methodology report looks like it might be complaining of the same root cause.

dreadedhill_2-1621230949658.png

Looks like I am missing something as to the binding of the pci_express interfaces, but have not yet figured out what...

0 Kudos
1 Solution

Accepted Solutions
nmanitri
Xilinx Employee
Xilinx Employee
537 Views
Registered: ‎06-13-2018

Hi @dreadedhill ,

Please follow the attached pin location.

nmanitri_0-1621513522323.png

Regards,

Naveen

View solution in original post

10 Replies
nmanitri
Xilinx Employee
Xilinx Employee
708 Views
Registered: ‎06-13-2018

Hi @dreadedhill,

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.

Regards,

Naveen 

0 Kudos
dreadedhill
Observer
Observer
685 Views
Registered: ‎01-26-2019

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?

dreadedhill_0-1621351126818.png

 

0 Kudos
nmanitri
Xilinx Employee
Xilinx Employee
673 Views
Registered: ‎06-13-2018

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.

Regards,

Naveen

0 Kudos
dreadedhill
Observer
Observer
645 Views
Registered: ‎01-26-2019

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

dreadedhill_0-1621362459313.png

 

0 Kudos
nmanitri
Xilinx Employee
Xilinx Employee
641 Views
Registered: ‎06-13-2018

Hi @dreadedhill,

Can i get your XCI and XDC files?

 

Regards,

Naveen

0 Kudos
dreadedhill
Observer
Observer
610 Views
Registered: ‎01-26-2019

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.

0 Kudos
dreadedhill
Observer
Observer
563 Views
Registered: ‎01-26-2019

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:

dreadedhill_0-1621406149351.png

The Methodology report from Synthesis (and same from Implementatio:

dreadedhill_1-1621406346804.png

Pretty sure I am missing some common element.

0 Kudos
nmanitri
Xilinx Employee
Xilinx Employee
538 Views
Registered: ‎06-13-2018

Hi @dreadedhill ,

Please follow the attached pin location.

nmanitri_0-1621513522323.png

Regards,

Naveen

View solution in original post

nmanitri
Xilinx Employee
Xilinx Employee
485 Views
Registered: ‎06-13-2018

Hi @dreadedhill ,

Does above solution helps you in resolving the issue? Please update us.

Regards,

Naveen 

0 Kudos
dreadedhill
Observer
Observer
338 Views
Registered: ‎01-26-2019

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:

  1. Power-off the PC containing the FPGA card (VCU118).
  2. Power-on the PC.
  3. Run Vivado Hardware Manager.
  4. Connect from Vivado on my development machine, and program the FPGA.
  5. Run tests. 

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.

0 Kudos