Arria 10 GX Dev Kit PCIe HIP root port PERST connection problem

[lcy2000]

Hello,

I'm using a A10GX1150 dev kit to develop a PCIe RC on its FMC-A connector, which is corresponding to the (Low, Right) PCIe HIP. And the PCIe Edge connector of the board is used as a EP.

In the AvalonST IP User Guide, it indicates that the Hard IP's PHY has to be resetted through a dedicated pin nPERSTR0. But after checking the schematics of the board, it shows that these PERST pins are connected to LEDs for the PCIe edge connector.

Fig. Page 7 of A10GX_PCIE_E3P1_Release.pdf

Fig. Page 24 of A10GX_PCIE_E3P1_Release.pdf

My question is that is there a way to workaround this limitation without hardware modifications? I have tried to mark the top level PERST pin as an inout so that I can controll its value internally in FPGA. But Quartus still complains as follows:

Error (18105): Port pin_perst of PCI Express hard IP block
rc|rc|pcie_a10_hip_0|altpcie_a10_hip_pipen1b|wys is not connected to a top-level pin.
Connect the pin_perst port to a top-level pin.

Is there any other workaround to drive this pin through internal io fabric? 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?

[lcy2000]

BTW: I have seen a post regarding S10 Root Port. It seems that PCIe HIP PHY has to be externally resetted through another GPIO nearby.

Ref: Can nPERST pins be used as PCIe reset if Intel® Stratix® 10 PCI Express* Hard IP is used as Root Complex? 

[Wincent_Altera]

Hi 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

[lcy2000]

Hi 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

[Wincent_Altera]

Hi 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

[lcy2000]

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

[Wincent_Altera]

Hi 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

[Wincent_Altera]

Hi Chenyang,

Do you think is there anything else I could help ?

Else do I have your permission to transition this forum into community support ?

If you have any further question in future, you may file a new forum loop, some will be there to suppor tyou.

Regards,

Wincent

[Wincent_Altera]

Hi

We have not hear from you and this Case is idling. It is not recommended to idle for too long.

Therefore following our support policy, I have to put this case in close status. My apologies if any inconvenience cause

Hence, This thread will be transitioned to community support.

If you have a new question, feel free to open a new thread to get support from Altera experts.

Otherwise, the community users will continue to help you on this thread. Thank you

If your support experience falls below a 9 out of 10, I kindly request the opportunity to rectify it before concluding our interaction. If the issue cannot be resolved, please inform me via this forum page of the cause so that I can learn from it and strive to enhance the quality of future service experiences. 

Regards,

Wincent_Altera

p/s: If any answer from the community or Altera Support is helpful, please feel free to give the best answer or rate 9/10 survey.