Forum Discussion
New ContributorCyclone IV GX PCIe Hard IP behaves differently on Intel Core I7 vs Xeon root complexes
Hello,
I am working with a Cyclone IV GX (EP4CGX22) using the Altera PCIe Hard IP configured as PCIe Gen1 x1 with an Avalon-MM interface.
The same FPGA image shows different behavior depending on the host platform.
Platforms Tested
Working Platform
- Intel Core i7-13700
- Windows 11
Platforms Where the Issue Is Observed
- Supermicro X10SRA + Xeon E5-1620 v3
- Supermicro X12SPL-F + Xeon Silver 4309Y
PCIe Configuration
The FPGA endpoint is configured as PCIe Gen1 x1
The Xeon platforms provide newer PCIe root complexes:
Xeon E5-1620 v3 -> PCIe Gen3/4 capable slot
Xeon Silver 4309Y -> PCIe Gen3/4 capable slots
However, the link correctly negotiates down to:
- Link Width : x1
- Link Speed : Gen1 (2.5 GT/s)
which matches the FPGA endpoint capability.
Common Observations
On all platforms:
- PCIe enumeration succeeds
- Vendor ID and Device ID are detected correctly
- BAR resources are assigned correctly
- The device driver loads successfully
- The PCIe link is established successfully
TLP as data input getting unexpected value
Observed Difference
Although the PCIe link is established correctly on all systems, the FPGA observes different transaction behavior on the Xeon platforms compared to the Intel Core i7 platform.
The same FPGA image and software stack operate as expected on the Intel Core i7-13700 system, while different behavior is observed on both Xeon-based systems.
Questions
- Are repeated accesses to BAR-space offsets after boot expected from BIOS/UEFI, Windows PCI bus enumeration, or other background PCIe activity?
- Has anyone observed different behavior between Intel Core desktop root complexes and Xeon/server root complexes when using the Cyclone IV GX PCIe Hard IP?
- Are there known interoperability issues between older Cyclone IV GX PCIe endpoints and modern Gen3/Gen4 server root complexes, even when the link successfully negotiates to Gen1 x1?
- Is there a recommended way to distinguish firmware/OS-generated PCIe accesses from accesses generated by the application or function driver?
Any feedback or similar experience would be greatly appreciated.
Thank you.
6 Replies
Wincent_AlteraRegular Contributor
Hi SharmaUmesh278 ,
Are repeated accesses to BAR-space offsets after boot expected from BIOS/UEFI, Windows PCI bus enumeration, or other background PCIe activity?
>> In our user guide mentioned that, the RX logic processes requests from the root complex, and that the Avalon-MM RX master issues the corresponding Avalon-MM read/write transactions into the FPGA fabric. It also states that some bridge register regions are typically intended for access by PCI Express processors only, and that the PCI Express root complex typically requires write/read access to certain mailbox registers. So the guide supports the idea that root-complex-originated accesses are normal
>> detail please refer to IP Compiler for PCI Express User Guide
Has anyone observed different behavior between Intel Core desktop root complexes and Xeon/server root complexes when using the Cyclone IV GX PCIe Hard IP?
>> Our PCIe IP is following PCI-SIG compliance
>> As long as the Laptop is PCI-SIG compliance, by right it shall be no problem.
>> But in your case, I would suggest to switch to another different host and check if the error is follow. I suspect is individual host issue.
Are there known interoperability issues between older Cyclone IV GX PCIe endpoints and modern Gen3/Gen4 server root complexes, even when the link successfully negotiates to Gen1 x1?
>> Are you using Gen1 design if I understand correctly ?
>> I would suggest to set the BIOS PCIe speed from "auto" into "gen1", I did experience certain brand of host actually cannot perform auto negotiation.
Is there a recommended way to distinguish firmware/OS-generated PCIe accesses from accesses generated by the application or function driver?
>>From what I understand , the RX block processes requests from the root complex, passes header information to the Avalon-MM master, and the RX master generates the corresponding Avalon-MM transactions to the connected slaves.
Regards,
Wincent_Altera
SharmaUmesh278a { text-decoration: none; color: #464feb; } tr th, tr td { border: 1px solid #e6e6e6; } tr th { background-color: #f5f5f5; }
Hi Wincent_Altera,
Let me clarify my observation.
When a PCIe read or write transaction occurs, SignalTap captures the transaction correctly and I can see the expected activity and data values.
However, only for a short period after the transaction. A few moments later, the observed data bus returns to 0xFFFFFFFF (all bits = 1) again.
In other words, the correct value is visible only while the transaction is active and captured by SignalTap. After that, the signal returns to its default state of all 1's.
Because of this, it appears that the driver is reading 0xFFFFFFFF, while SignalTap shows the expected value during the actual transaction.
Is 0xFFFFFFFF the expected idle/default value on the Avalon-MM read data interface when no valid read response is present, or could this indicate a completion/read response issue?
I have already forced the PCIe link speed to Gen1 and confirmed successful Gen1 x1 link negotiation. The behavior remains the same.
Could you also let me know which PCIe driver/test application is used for Cyclone IV GX PCIe validation?
Regards,
Umesh Sharma- Wincent_Altera
Hi SharmaUmesh278 ,
Can you please try out below design https://docs.altera.com/r/docs/683541/current/an-456-pci-express-high-performance-reference-design/software-requirements
You can download via PCI Express High-Performance Reference Design in Cyclone IV GX DevicesIf SignalTap shows correct data only during the valid window, your main problem is probably handshake/timing at the AVMM read interface, not the idle 0xFFFFFFFF itself.
Regards,
Wincent_Altera
