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.
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.
Agilex 7 R-Tile CXL IP: D2H write bandwidth does not scale with dual CAFU AXI-MM ports
Device: Agilex 7 I-Series AGI027 Software: Quartus Prime Pro 24.3 IP Core: CXL Type 2 IP Issue Description: We are attempting to increase CXL Device-to-Host (D2H) write bandwidth by utilizing both CAFU AXI-MM ports (port 0 and port 1) provided in the CXL Type 2 IP design example. However, our measurements show that enabling both AXI ports does not improve bandwidth as expected. For Non-cacheable writes, bandwidth remains unchanged when moving from one port to two ports. For Cacheable Owned writes, bandwidth decreases when using two ports. Please refer to the figures blow for detailed results. We are using the design example configured with two DCOH slices. To avoid potential DCOH contention, we've implemented address interleaving such that: - AXI port 0 only accesses addresses corresponding to "even number × 64B" - AXI port 1 only accesses addresses corresponding to "odd number × 64B" Despite this, no bandwidth improvement is observed for either Non-cacheable or Cacheable Owned traffic. Additionally, the non-cacheable bandwidth curve remains almost identical regardless of whether one or both AXI ports are used. This suggests that the exercised hardware path may contain a bottleneck or contention point within (either soft or hard part of) the CXL Type-2 IP. We would like to understand how to resolve this bandwidth limitation. If it cannot be improved, we would appreciate clarification on the underlying cause of this behavior. Thank you for your time and support.PCIe Hard IP - Can 'valid' De-assert Between SOP and EOP During DMA Read Completion?
Product / IP: Intel PCIe Hard IP (Avalon-ST Interface Device Family: Cyclon 10 GX Reference Manual: https://docs.altera.com/r/docs/683647/18.0/arria-10-and-cyclone-10-gx-avalon-streaming-interface-for-pci-express-user-guide/datasheet I am an FPGA Design Engineer currently working on verifying the application layer logic interfacing with Intel's PCIe Hard IP over the Avalon Streaming (Avalon-ST) interface. As part of the verification effort, I have developed an Avalon-ST Bus Functional Model (BFM) that mimics the RX-side behavior of the PCIe Hard IP — specifically, how it presents TLP data (DMA Read Completions) to the downstream application logic. During simulation, my BFM generates scenarios where the 'valid' signal is de-asserted between 'startofpacket (SOP)' and 'endofpacket (EOP)' — i.e., mid-packet gaps or "bubbles" are introduced within a single TLP transfer. When this occurs, the application layer logic does not handle it correctly, causing functional failures. Before proceeding with fixing the application logic to handle this case, I need to confirm from Intel whether this behavior is actually possible on the real PCIe Hard IP hardware Question 1: On the RX Avalon-ST interface, when the PCIe Hard IP is acting as the SOURCE (driving TLP completion data toward user application logic), is it possible for the 'valid' signal to be de-asserted between SOP and EOP within the same TLP packet? Question 2: If yes, under what conditions can this occur? Question 3: Does the Intel PCIe Hard IP Reference Manual explicitly document this behavior anywhere? If so, could you point to the relevant section?
MCDMA IP D2H Queue Reset Failure during Channel Re-allocation
After successfully loading the binary and launching D2H (Device-to-Host) operations on my FPGA, the first channel is allocated successfully and transfers data without issue. However, when I try to allocate another channel, it fails with a "queue reset failed" error. Initially, during the initialization phase, all 512 channels were checked and appeared available. Environment: Device Family: [Agilex 7] Quartus Version: [24.1] Driver/Software: VFIO based IP Config: MCDMA configured with 512 channels Why is this happening? How to rectify the same ?
Agilex 7 R-Tile PIPE Direct Mode: Raw Rx Data Misalignment - Is Soft Word Alignment Needed?
Hello, I am designing a custom PCIe Logical PHY using Agilex 7 R-Tile in PIPE Direct Mode. My goal is to implement the PCS/MAC layer in soft logic (FPGA fabric). I have established a link with the Host, but I am unable to detect the COM symbol (K28.5). Instead, I observe the following two repeating patterns on the 10-bit RxData bus via Signal Tap: Observed Raw Data (Repeating 10-bit Hex values): Pattern A (RD-): 0x3E5, 0x142, 0x147, 0x267, 0x30E, 0x236, 0x156, 0x155, 0x155, ... Pattern B (RD+): 0x01D, 0x2BD, 0x2B8, 0x198, 0x0F1, 0x1C9, 0x151, 0x155, 0x155, ... My Analysis: The trailing 0x155 matches D10.2 (TS1 Link/Lane ID), which is symmetric (0101010101), so it looks correct even if bit-reversed. The header 0x3E5 (Pattern A) and 0x01D (Pattern B) do not match K28.5 directly. However, if I apply Bit Reversal and a 3-bit Shift to 0x3E5, it perfectly matches the K28.5 comma pattern. This strongly suggests the data is valid but is coming in as Raw, Bit-Reversed, and Misaligned bits. My Questions: In PIPE Direct Mode, is it standard behavior for the R-Tile Hard IP to bypass Word Alignment and output raw, unaligned data? Does this mean the user is strictly responsible for implementing Bit Reversal and a Soft Word Aligner (Bit Slip / Barrel Shifter) in the FPGA fabric to achieve Symbol Lock? Is there any IP parameter or configuration to enable Hard Word Alignment while keeping the PIPE Direct interface? I would appreciate any confirmation or advice from those experienced with R-Tile PIPE Direct mode. Thank you.
agilex 7 Platform Designer PIO addr width
I am using the PIO example design of the P-Tile AVST PCIe IP on Intel Agilex 7. The original design maps a 16KB RAM to BAR0. Since my design requires a larger address space, I modified the PCIe IP's BAR configuration to increase BAR0 size to 2MB. However, I soon discovered that in the "PIO Design Example for PCI Express Gen4," the module converting AVST to AVMM only supports a 16KB address space after conversion. I then replaced it with the "PCIe PIO" IP core, but found that it can only access a 1MB region. What should I do?Agilex-7 MSI-X missing om AXI MCDMA for PCIe
Hi! We are using AGIB023R18A1E1VC device and AXI MCDMA for PCIe IP core. We set it to MCDMA+BAS+BAM mode as we want to use MSI-X interrupts. Our driver register for example 2 MSI-X interrupts in Linux with no issues, after that FPGA logic sends request to user_msix interface and observes handshake. But then we see no interrupt happening in host, and interrupts counter stays at zero value. In lspci we see that MSI-X capability exists and the number of MSI-X vectors is not zero. Capabilities: [b0] MSI-X: Enable+ Count=53 Masked- Vector table: BAR=0 offset=00100000 PBA: BAR=0 offset=00180000 We use Q25.3.1. Could you please help us with understanding what may be wrong and why we don't see interrupts in our host system? Thank you in advance. Mikhail.
