- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
We are having trouble bringing up the PCIe Hard IP on our custom board. The hard IP is set up for gen 1 x1. It appears that coreclkout is stuck low and not toggling.
Current setup:
We are using a FPGA project based on
https://fpgacloud.intel.com/devstore/platform/18.0.0/Pro/cyclone-10-gx-pcie-gen1-x1-avl-st/
The only changes we made are pin assignments for the general IO to match our custom board, and using Quartus Pro 20.4.0.
The custom board uses the Cyclone 10 GX and the hardware is set up for up to 2 lanes. The TX and RX lanes location have been verified to be correct using pin planner. They are located at bank 1C ch4 (lane0) and 5 (lane1). We also verified that the refclk is 100MHz coming from another custom board generated from a CDCM9102RHBT clock generator.
nPERST is controlled by the root complex and located at the dedicated pin (NPERSTL0) with VCCIO at 1.8, and we can see the signal goes high using signaltap
The pcie RX lane and refclk are set as CML I/O standard, and the TX lane is set at "high speed differential IO"
From our root complex, we can see that the lttsmstates changes from 0x00 > 0x01 > 0x06 > 0x01 > 0x02 > 0x03 and it stays there.
From the Cyclone 10 GX endpoint side using signaltap, the coreclockout/pld_clk, lttsmstates, and currentspeed are all stuck low.
Any suggestions on how we can go about debugging this would be greatly appreciated, or possible reasons why coreclkout is stuck low.
Thank you
Link Copied
- « Previous
-
- 1
- 2
- Next »
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi
This is glad to see there is good progress.
Questions:
1) After the fixed the clkusr pin, does the coreclkout work correctly with and without the following QSF setting?
set_global_assignment -name VERILOG_MACRO "ALTERA_XCVR_A10_DISABLE_RESET_CONNECTED_TO_CAL_BUSY=1
2) Does the PCIe refclk come from the gold finder? Or it is using a separate clock from your board?
3) What happens if you reboot the Host server after the program of the FPGA? Does the LTSSM behave the same?
Regards -SK
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Answers to your questions:
1) After the fixed the clkusr pin, does the coreclkout work correctly with and without the following QSF setting?
set_global_assignment -name VERILOG_MACRO "ALTERA_XCVR_A10_DISABLE_RESET_CONNECTED_TO_CAL_BUSY=1
I no longer need this setting. I removed this from my qsf file and coreclkout_hip still functions properly (verified with counter), and I can also use coreclkout_hip as my sampling clock now.
2) Does the PCIe refclk come from the gold finder? Or it is using a separate clock from your board?
Yes, the PCIe refclk comes from the gold fingers.
3) What happens if you reboot the Host server after the program of the FPGA? Does the LTSSM behave the same?
Rebooting the root complex after programming the FPGA doesn't change the result. The LTSSM still behaves the same way. It toggles between state 0 (Detect.Quiet), 1 (Detect.Active), 2 (Polling.Active)
Something I noticed on the signaltap:
rx_is_lockedtodata and rx_is_lockedtoref are both toggling
Does this mean that the receiver isn't seeing data?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Your design only has 1 lane, if this lane unable to lock, which means it can’t receive the TS1 and TS2 during the polling.active, and after 24ms timeout, it will return to the detect state, and NOT move to polling.configuration. Assuming the refclk is alright since both RP and EP are sharing the same clock source. If the rx_is_lockedtodata is toggling, it could be related to the board design where the incoming data has high BER or the board has introduced high jitter on the PCIe lane.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you for all the help you provided, and helping me through the debugging process.
The problem was with my root complex PCB that I was testing with. After using a different board, everything works properly now.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This is glad to see the problem is resolved. Thanks.
Regards -SK
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If further support is needed in this thread, please post a response within 15 days. After 15 days, this thread will be transitioned to community support. The community users will be able to help you with your follow-up questions.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- « Previous
-
- 1
- 2
- Next »