F-Tile PCIe Root Port 1x Gen3x4 - Configuration Read Type 0 receives no answer
Hello Support, I am using the Agilex 7F Dev Kit with F-Tile configured in Root Port Gen3x4. When I am doing a Configuration Write Type 0 to write the End Point BAR0 with FFFF_FFFFh, the end point send an answer , when I follow this write with a Configuration Read type 0 to read the BAR 0 of the End point I do not receive any answer. Is there any configuration which avoid the read data to go through the F-Tile ? Is there any problem with my Configuration Read type 0 command I have attached the STP file as well. Thank you for help. Serge
DDR2 license Question
The customer obtained the DDR2 license through the Altera website. Does this IP license have any time limitation or other usage restrictions? When generating the project for the EP4CE75U19I7N device, Quartus only generates project.sof and does not generate project_time_limited.sof.
Cyclone 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.
Altera Agilex PCIe core
Hi Altera Team, We have developed a user reset controller based on the "Cold Reset Entry and Exit Sequence" described in the "GTS AXI Streaming IP for PCI Express User Guide for Agilex® 5 and Agilex® 3 FPGAs and SoCs". Currently, our implementation is stalled at Step 2 of the reset sequence. Our user reset logic is waiting for the PCIe IP to assert the p<n>_initiate_warmrst_req signal; however, this signal is never asserted during simulation. Our current PCIe configuration is as follows: * PCIe x 4lanes * AXI Streaming interface: 128-bit * PLD clock: 200 MHz * Reference clock: 100 MHz * System PLL configured as required Could you please advise on the possible reasons why p<n>_initiate_warmrst_req may not be asserting? Additionally, are there any configuration settings or reset timing requirements that must be satisfied before the PCIe IP generates this signal?
How to handle tx_st_ready for Cyclone V PCIe
I'm using a Cyclone V GT with PCIe core using Gen 1 Avalon-ST 64-bit endpoint interface. Everything works pretty well including sending and receiving data, DMA transfers etc. But so far I've ignored the situation where tx_st_ready is deasserted during a packet transmission. Time to deal with it, but the docs are a bit confusing. For example, the following implies I have some sort of control over the readyLatency, but I see nothing in the core generator to set that. How to I know what the readyLatency is? And what to they mean the "typical case"? In the above, are they saying I should register them? I see nothing in the core generator to say if they should be registered or not. They give a timing diagram below which is a bit confusing.Can an Application Ignore PCIe flow Control Credits?
I'm using a Cyclone V GT with PCIe core using Gen 1 Avalon-ST 64-bit endpoint interface. Occasionally packet sending would stall and I had thought it was because I was ignoring the flow control credits. But after properly handling tx_st_ready going low, the problem seems to have gone away. So the question is can I ignore the flow control signals as long as I throttle the sending when tx_st_ready goes low? In the flow control section of the UG-011110 dated 2020.06.02, it says That is not important for our application. But then after spending several paragraphs explaining how the PCIe Hard IP tracks and checks credits, it make says: Can I assume that is only in the case described in the yellow highlight? Also, in the flow control update loop description, is says: Is that where the Hard IP is lowering tx_st_ready so the App is indirectly handling credits? If so, one odd thing is that sometimes tx_st_ready does not go low until toward the end of a packet write (ie closer to the EOP and the SOP). I would think it would do the credit check as soon as it had the TLP headers which contain the type, number of dwords etc. Just a suggestion, but for Apps that did want to optimize throughput, it would have been helpful to just expose the credit limits to the App instead of making it independently keep track of them. The credit system is a bit confusing.
PCIe bringup in Agilex 5
Hi, I am working on PCIe bring-up on an Intel Agilex 5 SoC FPGA platform using the Altera PCIe Root Port IP in Root Port mode. Current status: PCIe root port is detected properly NVMe endpoint is also enumerated correctly lspci shows both root port and NVMe device successfully However, I am facing two major issues: During NVMe probe, I sometimes get: nvme nvme0: I/O tag 0 (1000) QID 0 timeout, completion polled If probe succeeds and I try actual read/write operations on the NVMe drive, the system crashes/hangs with RCU stall or timeout related logs. I have already checked: PCIe link comes up correctly BARs are assigned Bus master enabled Endpoint enumeration looks fine I also tried: pci=nomsi but then NVMe probe fails with error -22. This makes me suspect the issue may be related to: MSI/MSI-X interrupt handling DMA configuration outbound address translation or cache coherency issues Has anyone seen similar behavior on Agilex 5 or Altera PCIe Root Port IP where: enumeration works but NVMe probe times out or crashes during I/O? Any suggestions on what to debug next would be very helpful. Thanks.R_Tile PCIE
I am using Quartus 26.1 and Questa 2024.1 to simulate the PCIe IP example. The selected IP is R-Tile Avalon Streaming IP for PCI Express. The example design is generated in PIPE mode. I slightly modified the example driver to make the EP transmit 100 MWr TLPs with 128-byte payload each and 100 MRd TLPs with 128-byte payload each. Currently issues occur with the CplD responses from the RP. In the 100-packet test, 96 out of 100 CplD packets have correct payload data, while 4 packets show data mismatch. The faulty packets are not fully corrupted. Their first three payload beats are valid, yet the final 256-bit beat turns into all zeros. There is another issue. When modifying the EP to send MWr TLPs longer than 128 bytes to the RP in the example design, no CplD frames will be responded by the RP after transmitting subsequent MRd TLPs.
