Terasic P16E-FMCP PCIE Express 3.0 compatibility issues with AMD processors
Hi I bought the Terasic P16E-FMCP to use on my Terasic Apollo S10 SOM board for PCI Express 3.0 implimentation. However after testing the included program, it did not work, so I emailed Terasic Support and they told me it was only tested on Intel CPU and it appears never tested on AMD. So they made me run a simple program called System Information Viewer from rh-software.com which tested the information sent and received from the PCI endpoint and it appears there are errors stimming back from the demo program does not natively run on AMD processors. So for the past 6 months, Terasic has been dragging there feet on this issue, telling me they will work on a solution but I must go out and purchase another computer by Intel, then run several versions of Quartus Pro, starting from 19.1, through 23.3, I must download them individually. I told them I am not doing this, I am not being paid to test out your code, I simply purchased the board direct from you for $650, and NOWHERE on the website does it publish it works only with Intel CPU. Instead they are pointing the fingers at me saying I'm delayin a resolution on this issue by not testing out there code, I told them that IS YOUR JOB! I AM NOT EMPLOYED BY TERASIC! Terasic is a partner program of Intel, they have all the means to reach out and contract a device driver writer and solve this incompatiblity issue. This is beyond my expertise. They simply won't do it. Does anyone have a solution to this problem? Why are they passing the buck at me?[PCIE_DESIGN_EXAMPLE][AGILEX7][QUARTUS25.3.0] - failed at elaboration process
Hello, I am trying to simulate with questa fe the pcie design example (with pipe mode for external dma controller) based on agilex7 generated with quartus pro 25.3.0 but i am facing these issues when i run this script under "pcie_ed_sim_tb/pcie_ed_sim_tb/sim/mentor" as follow : vsim -do run_msim.tcl # ** Warning: (vsim-3008) [CNNODP] - Component name (i_pclk__x16_l0) is not on a downward path. # Time: 0 fs Iteration: 0 Instance: /pcie_ed_sim_tb/dut_pcie_tb_ip/dut_pcie_tb/tile File: ../../../../support_logic/pcie_ed_sim_auto_tiles.sv Line: 34589 # ** Error: (vsim-3043) Unresolved reference to 'i_pclk__x16_l0' in ftile_s20_v0__pcie__tile_0.z1577b.z1577b_inst.i_pclk__x16_l0. # Time: 0 fs Iteration: 0 Instance: /pcie_ed_sim_tb/dut_pcie_tb_ip/dut_pcie_tb/tile File: ../../../../support_logic/pcie_ed_sim_auto_tiles.sv Line: 34589 # ** Warning: (vsim-3008) [CNNODP] - Component name (i_pclk__x4_l12) is not on a downward path. # Time: 0 fs Iteration: 0 Instance: /pcie_ed_sim_tb/dut_pcie_tb_ip/dut_pcie_tb/tile File: ../../../../support_logic/pcie_ed_sim_auto_tiles.sv Line: 34589 # ** Error: (vsim-3043) Unresolved reference to 'i_pclk__x4_l12' in ftile_s20_v0__pcie__tile_0.z1577b.z1577b_inst.i_pclk__x4_l12. # Time: 0 fs Iteration: 0 Instance: /pcie_ed_sim_tb/dut_pcie_tb_ip/dut_pcie_tb/tile File: ../../../../support_logic/pcie_ed_sim_auto_tiles.sv Line: 34589 # ** Warning: (vsim-3008) [CNNODP] - Component name (i_pclk__x4_l4) is not on a downward path. # Time: 0 fs Iteration: 0 Instance: /pcie_ed_sim_tb/dut_pcie_tb_ip/dut_pcie_tb/tile File: ../../../../support_logic/pcie_ed_sim_auto_tiles.sv Line: 34589 # ** Error: (vsim-3043) Unresolved reference to 'i_pclk__x4_l4' in ftile_s20_v0__pcie__tile_0.z1577b.z1577b_inst.i_pclk__x4_l4. # Time: 0 fs Iteration: 0 Instance: /pcie_ed_sim_tb/dut_pcie_tb_ip/dut_pcie_tb/tile File: ../../../../support_logic/pcie_ed_sim_auto_tiles.sv Line: 34589 # ** Warning: (vsim-3008) [CNNODP] - Component name (i_pclk__x8_l8) is not on a downward path. # Time: 0 fs Iteration: 0 Instance: /pcie_ed_sim_tb/dut_pcie_tb_ip/dut_pcie_tb/tile File: ../../../../support_logic/pcie_ed_sim_auto_tiles.sv Line: 34589 # ** Error: (vsim-3043) Unresolved reference to 'i_pclk__x8_l8' in ftile_s20_v0__pcie__tile_0.z1577b.z1577b_inst.i_pclk__x8_l8. # Time: 0 fs Iteration: 0 Instance: /pcie_ed_sim_tb/dut_pcie_tb_ip/dut_pcie_tb/tile File: ../../../../support_logic/pcie_ed_sim_auto_tiles.sv Line: 34589 # ** Warning: (vsim-3008) [CNNODP] - Component name (i_rxpipe0__dirfeedback) is not on a downward path. # Time: 0 fs Iteration: 0 Instance: /pcie_ed_sim_tb/dut_pcie_tb_ip/dut_pcie_tb/tile File: ../../../../support_logic/pcie_ed_sim_auto_tiles.sv Line: 34589 # ** Error: (vsim-3043) Unresolved reference to 'i_rxpipe0__dirfeedback' in ftile_s20_v0__pcie__tile_0.z1577b.z1577b_inst.i_rxpipe0__dirfeedback. # Time: 0 fs Iteration: 0 Instance: /pcie_ed_sim_tb/dut_pcie_tb_ip/dut_pcie_tb/tile File: ../../../../support_logic/pcie_ed_sim_auto_tiles.sv Line: 34589 # ** Warning: (vsim-3008) [CNNODP] - Component name (i_rxpipe0__linkevaluationfeedbackfiguremerit) is not on a downward path. # Time: 0 fs Iteration: 0 Instance: /pcie_ed_sim_tb/dut_pcie_tb_ip/dut_pcie_tb/tile File: ../../../../support_logic/pcie_ed_sim_auto_tiles.sv Line: 34589 # ** Error: (vsim-3043) Unresolved reference to 'i_rxpipe0__linkevaluationfeedbackfiguremerit' in ftile_s20_v0__pcie__tile_0.z1577b.z1577b_inst.i_rxpipe0__linkevaluationfeedbackfiguremerit. # Time: 0 fs Iteration: 0 Instance: /pcie_ed_sim_tb/dut_pcie_tb_ip/dut_pcie_tb/tile File: ../../../../support_logic/pcie_ed_sim_auto_tiles.sv Line: 34589 ..... I also have followed the Altera recommendations : Note: Due to a problem in the Quartus ® Prime Pro Edition Software version 25.3, you are required to add "-suppress 2732" to USER_DEFINED_COMPILE_OPTIONS and "-suppress 10000 " to USER_DEFINED_ELAB_OPTIONS in the run_msim.tcl simulation script manually for a successful simulation with the Questa simulator. But i am still facing these above issues. What can i do ? Regards, Frederic
Introducing the Altera Community AI Responder — Beta
Altera is introducing the AI Responder, an assistant built into the Altera Community to help provide faster, context-aware guidance for Altera product questions. It uses relevant public Altera documentation and Knowledge Database content, with coverage continuing to expand. The AI Responder may provide source references and can hand off complex or out-of-scope questions to an Altera subject-matter expert. As a beta feature, responses may contain errors or omissions, so please review the sources and verify technical guidance against official Altera documentation before implementation. If the response does not fully address your question, add more context and tag ai_responder to continue the discussion. We welcome your feedback as we improve the Community experience.
Agilex-7 AXI MCDMA for PCIe hang
Hi! I'm working with AGIB023R18A1E1VC device and having issues with AXI Multichanned DMA IP for PCIe. Since I require a PCIe bridge, I configured the IP in MCDMA+BAS+BAM mode (PCIe Gen 4, 512-bit), generated an example design, and integrated the subsystem into my project. Although I do not use MCDMA, I rely heavily on the BAS and BAM functionality. The issue I’m seeing is that writing more than 448 bytes to the BAS causes the host to hang and subsequently reset. Notably, between the write transaction and the host reset, the FPGA internal logic is still able to write to the BAS, indicating no hang on the AXI bus. There are no issues with read transactions. We observe this issue not with only one card. At first we run into it in Q25.1 but still have it in Q25.3.1 If you need some captures from the signal tap or any additional details I may provide them. Thank you in advance! Mikhail.
R-TILE PIPE DIRECT MODE SIMULATION PHY STATUS ISSUE IN RESET RELEASE SEQUENCE
HI, I am currently working on r-tile pipe direct mode simulation in questasim. So, initially i have generated r-tile ip with configuration of pipe direct mode, 16x1. I have generated hdls using generate hdl option(enabling verilog,questasim). I have written pipe control fsm to provide control inputs to r-tile ip. Ref_clock1,ref_clock2 frequency is 100mhz. Reconfig_clock frequency is 100mhz. pipe_direct_pld_tx_clk_out_o from ip is 500mhz(validated in sim) So, i start with providing ninit_done using reset release ip. once nint_done goes low, i am providing pin_perst_n to high. then pin_perst_n_o goes high. After sometime, pipe_direct_pld_tx_clk_out_o becomes active. So, i am waiting for ln0_pipe_direct_tx_transfer_en_o to goes high. once this signal goes high, i will release ln0_pipe_direct_pld_pcs_rst_n_i to high. I am checking the phy signal to toggle. but from beginning itself it stays low, it never toggles. Along with this standard procedure, i tried 2 more possibilities i tried, After i released the ln0_pipe_direct_pld_pcs_rst_n_i to high. I provided the ln0_pipe_direct_txdetectrx_i to high. No response from phy_status. After i released the ln0_pipe_direct_pld_pcs_rst_n_i to high. I provided the ln0_pipe_direct_txdetectrx_i , rx_standby to high. still No response from phy_status I am attaching some screenshots of waveforms. Kinly look into it and help me out. I am really stuck at midway..
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
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
