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.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.
PCIe stuck at reset Agilex5
Hi Altera Team, I'm trying to get PCIe connection working on our custom board. We had some problems with our design. Reset pin (CF128) is connected to CF121 on board (we forgot to connect it). At the start i set CF121 to '1', to get PCIe out of reset. When fpga boots, all clocks should be up and stable. Based on "Link Training Debugging Flow" my IP core is in reset and i should check pin_perst_n. Pin is set to '1', but IP is still in reset? What could be the couse? Is there a chance for this behaviour if core can't detect root? Do i need IO_Pll to lock for core to get out of reset? I use example design for PCIe, with different pinout. Device: A5ED065BB32AE6S - Common clock architecture
Agilex 7 R-Tile PCIe Gen5: Avalon-ST DMA MWr TLP accepted by HIP but never received by Root Port
I am debugging a design using the Intel mSGDMA Read Master IP connected to the Intel Agilex 7 R-Tile PCIe Gen5 Hard IP through the Avalon-ST TX interface.The design uses the Intel mSGDMA Read Master to read data from memory. The Avalon-MM read data is then packetized into PCIe Memory Write (MWr) TLPs and transmitted through the R-Tile PCIe HIP. The transmit path is: Intel mSGDMA Read Master → dma_mwr_txc_gen → txc_mux_2to1 → pcie_bam_avst_intf → pcie_pio → Agilex 7 R-Tile PCIe HIP The endpoint enumerates correctly, the PCIe link trains successfully to Gen5 x16, configuration space accesses work correctly, BAR accesses work correctly, and normal MMIO/PIO operations function as expected. The only issue occurs when transmitting DMA-generated Memory Write TLPs. We have spent considerable time verifying the transmit path using both simulation and Signal Tap, and everything appears to be correct up to the HIP interface. Specifically, we have verified the following: The Avalon-ST TX interface follows the R-Tile User Guide. SOP/EOP placement is correct. Segment valid signals are correct. Header valid and payload valid are correct. ready remains asserted throughout the transfer. No Avalon-ST protocol violations are observed. The ACC signal gets asserted after the TLP is sent to the HIP The generated Memory Write header decodes correctly (128-byte MWr, correct addresses, requester ID, and length field). Payload contents are correct. Address increments correctly between successive packets. Signal Tap shows the expected TLP immediately before entering the HIP. The HIP accepts the packet (valid and ready handshake completes). No HIP or protocol error indications are observed. However, the Root Port never appears to receive the Memory Write TLP. The expected data never becomes visible to the host software, even though the packet appears to have been accepted by the HIP. After several DMA attempts, the Root Port—or sometimes the entire server—eventually becomes unresponsive and requires a reboot. We do not observe any AER messages, completion timeout messages, or other PCIe errors reported by the operating system. We also investigated timing closure to rule out timing-related corruption. At this point, we are trying to determine whether there is something beyond the Avalon-ST interface that could cause the HIP to silently discard or otherwise fail to transmit a posted Memory Write TLP. Has anyone encountered a similar issue on the Agilex R-Tile PCIe HIP where: the Avalon-ST interface appears completely correct, the HIP accepts the packet (ready/valid handshake completes), no protocol or PCIe errors are reported, but the Root Port never receives the posted Memory Write? Are there any additional HIP status registers, debug signals, credit counters, packet validation checks, alignment requirements, or other R-Tile-specific conditions that should be examined? Are there any known situations where a posted Memory Write can be silently drop after being accepted on the Avalon-ST interface? Any suggestions on additional debug points or known R-Tile HIP behaviors would be greatly appreciated. Thank you. Reza
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?
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.
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.
