New Contributor
Regular ContributorHi ChenYang,
Regardless of the hard IP being configure as rootport or endpoint, pin_perstn is defined as input pin.
If you configure the HIP as rootport, the rootport is responsible to provide the reset input to the PCIe core.
This rootport reset could be a reset control by the software driver at rootport side which intiates the system reset.
It does not make sense that pin_perst is an input when endpoint and then change to output when rootport, because the software driver is not contain in the Hard IP, thus it can't control when to drive high or low for a specific duration (ms).
Regarding the error, you must connect the pin_perst reset signal to the correcsponding nPERST pin of the device.
It cannot be tied to high or low.
Arria 10 PCIe User Guide, Table 6-6, described pin_perst as below:
https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/ug/ug_a10_pcie_avst.pdf
"Arria 10 devices can have up to 4 instances of the Hard IP for PCI Express. Each instance has its own pin_perst signal.
You must connect the pin_perst of each Hard IP instance to the corresponding nPERST pin of the device.
These pins have the following locations:
• NPERSTL0: bottom left Hard IP and CvP blocks
• NPERSTL1: top left Hard IP block
• NPERSTR0: bottom right Hard IP block
• NPERSTR1: top right Hard IP block
For example, if you are using the Hard IP instance in the bottom
left corner of the device, you must connect pin_perst to NPERSL0."
In between, link below has some examples of PCIe rootport and endpoint reference designs.
http://rocketboards.org/foswiki/view/Projects/ArriaVPCIeRootPortWithMSI
http://www.rocketboards.org/foswiki/Projects/PCIeRootPort
Regards,
Wincent
New ContributorHi Wincent,
Thank you for your timely and detailed response.
I have checked the rocketboard example design and I understood that the PERST# pin (1) must be driven externally (2) has a fixed pin assignment. Because they are Hard IPs, just like a regular PHY chip.
In your provided design, it seems the PCIe RC PERST has a external circuit which can be driven by another GPIO pin of FPGA. And I believe Rahul from Intel in the S10 thread I mentioned before has confirmed that setting.
But in my case, the A10GX1150 dev kit (from Intel, https://www.intel.com/content/www/us/en/products/details/fpga/development-kits/arria/10-gx.html) has an LED attached to this PERST# pin, used as a 1.8V output. I believe this is a design defect which hinder the use of other hard ips on board.
My initial question is that, since this pin can be driven from the FPGA frabic through some kind of pinmux, and the pin are shared with PHY RESET inside FPGA, is there a way to drive PERST# internally (through some on-chip short circuit) from FPGA to reset the PHY?
If not, what are the PCB modifications has to be made to enable the hard ip on FMC-A? My current idea is to short circuit PCIE_LED_X1 and PCIE_LED_X4 by soldering a wire. So that I can create a external reset circuit (use GPIO output to drive PERST input) as described in S10 thread.
Best regards,
Chenyang
Regular ContributorHi Chenyang ,
I think i wrote the wrong link for the rootport design for Arria 10 please check below.
Perhaps you can check the design example implementation, and see if it is full-fill your current requirement or not.
https://www.rocketboards.org/foswiki/Projects/A10AVCVPCIeRootPortWithMSILTS
https://www.rocketboards.org/foswiki/Projects/Arria10PCIeRootPortWithMSI
In your provided design, it seems the PCIe RC PERST has a external circuit which can be driven by another GPIO pin of FPGA. And I believe Rahul from Intel in the S10 thread I mentioned before has confirmed that setting.
>> S10 and Arria 10 is different architecture, hence we are not suggest you to refer both as the same
>> hence, i am recommended to follow Design example for Arria 10 for more accurate settings.
In the AvalonST IP User Guide, it indicates that the Hard IP's PHY has to be resetted through a dedicated pin nPERSTR0
>> Yes this is correct, those features is well tested internally.
Or the best chance is to short circuit PCIE_LED_X4 with any other FPGA controlled io port (e.g. PCIE_LED_X1) nearby through a jumping wire?
>> In normal case we are not recommended to perform any hardware modification, as it is bring some potential risk to damage the board.
>> to be honest, I never try that before, and I cannot 100 % sure that this will be work
Let me know if you have any further question.
Regards,
Wincent
New ContributorHi Wincent,
Thank you for the example designs. I noticed that your A10 example design is targeting Arria 10 SoC Dev Kit, which is different from mine in hand (Arria 10 GX 1150 Dev Kit). So I downloaded the schematics of this board to see how PERST is connected there.
My finding is that the PERST# in your design is driven by the MAX5 CPLD, so both sides of the PCIe link gets resetted when the CPLD asserts PERST#.
Fig. Page 35 of a10_soc_devkit_03_31_2016.pdf
But in my case, these PERST is not connected to any of controllable GPIO outputs. Thus, based on both A10 and S10 schematics, I believe hardware modifications are inevitable.
Regular ContributorHi Chenyang,
In Arria 10 GX dev kit, there are Transceiver channels being routed to FMC connector for non-PCIe protocols as stated below.
But for PCIe Hard IP, the dedicated Transceivers, clock and reset are routed to PCIe edge connector so that it is compatible with rootport CPU pcie slot, which is the usual PCIe use case.
Normally user will choose the SoC devkit to act as Rootport, for the Devkit (without SoC) normally will be act as endpoint.
In your cases, some customization might be needed, please accept my apology that we does not have much information about that. At the meantime, if you have any further question that you think I can clarified, please let me know
Regards,
Wincent
