Cascaded Avalon Stream Multiplexer in Platform Design does not forward valid data packets
Hello community, I have a DSP system with 32 independent 256-bit output channels using Avalon-ST (or AXI-Stream) on an AGX FPGA. To transfer packetized data to the HPS, I implemented a cascaded Avalon Streaming Multiplexer architecture. The 32 channels are divided into two groups of 16. Each group connects to a 16-to-1 Avalon-ST Multiplexer IP. The outputs of these two multiplexers are then connected to a final 2-to-1 Avalon-ST Multiplexer IP, forming an overall 32-to-1 mux structure. At the output of the final 2-to-1 mux, I also added another 2-to-1 Avalon-ST mux with a selectable input for a data packet emulator. Using the emulator path, I verified that the FPGA-to-HPS data path is functioning correctly. However, after switching from the emulator path to the DSP output path, I only receive packets from channel 0. No packets from the other DSP channels are observed by the HPS. For debugging, I intentionally generated valid packets on non-zero channels. In SignalTap, I observed that channel 28 was asserting valid packet data (valid = 1) while ready = 0. This capture was taken at the input of the second 16-to-1 mux, since channel 28 belongs to the upper 16-channel group. Next, I changed the SignalTap trigger condition to the rising edge of the output valid signal of the second 16-to-1 mux. However, the trigger condition was never met, even after repeated acquisitions. The ready signals throughout the mux stages remain asserted, which suggests there is no downstream backpressure from the FIFO path to HPS. The downstream FIFO status also indicates that it is empty. The confusing part is the following: After enabling channel 0 again, both channel 0 and channel 28 should have had valid packets simultaneously. In this case, packets from channel 0 were forwarded correctly to the HPS. I verified this by reading 8 words from the memory FIFO and reconstructing the original packet; all received packets contained the channel ID corresponding to channel 0. However, after disabling channel 0 again, no new packets were received from any channel, including channel 28. Based on these observations, it appears that the internal round-robin scheduler of the Avalon-ST mux may not be operating correctly. The two 16-to-1 muxes and the final 2-to-1 mux are all configured identically in Platform Designer. Does anyone have suggestions on what could cause this issue, or recommendations on how to further debug the Avalon-ST mux behavior? I noticed an interesting behavior on channel 28 related to the Avalon-ST handshake. The ready signal for channel 28 remains asserted during idle cycles, but it becomes deasserted exactly when valid is asserted. In other words: | Cycle | valid | ready | | ---------- | ----- | ----- | | Idle | 0 | 1 | | Data cycle | 1 | 0 | | Next cycle | 0 | 1 | This differs from channel 0, where both valid and ready are asserted simultaneously, forming a successful Avalon-ST handshake. My DSP source currently only pulses `valid` for one cycle when data is available. Could the Avalon-ST Multiplexer scheduling size setting (Scheduling Size = 2) contribute to this behavior? Specifically, can the mux arbitration latency caused by the scheduling configuration prevent non-zero channels from completing a handshake if valid is only asserted for one cycle? Thank you very much.
GTS Transceiver Simulation Model Encrypted file - unable to decrypt with Cadence Xcelium
Hi everyone, I am working on integrating the generated simulation models of the Agilex-5 GTS PMA/FEC Direct PHY IP with our main IP. I have encountered an issue where an encrypted file within the models cannot be decrypted by the Cadence Xcelium Simulator. The file is located at: <ip>/n_channel_superset_2100/sim/intelfpga/intel_src_flow_ctrl.sv I have tested this with Cadence Xcelium versions 19.x, 20.x, and 22.x, but the decryption error persists across all versions. We are currently using Quartus Pro Edition 2026.1.0 with an evaluation license. Could you please provide guidance on how to resolve this decryption issue? Thanks, Arun
Avalon Transaction Responses & Bridges
Hello I have a question about the behavior of Avalon-MM Pipeline Bridges concerning the response signals. I have the following setup: 2 (or more) Avalon-MM Masters Master cmd_ctrl (supports Avalon responses) Master B (no response support) global_mm_bridge (pipeline Bridge IP Core) with Support for Transaction Responses Multiple Slaves Slave global_reg (simple register read & write access) other Slaves do not have Avalon response signals (neither readdatavalid, nor writeresponsevalid) My understanding of Avalon-MM bridges was always that they act as kind of "transparent bridge", i.e. they do not sent responses by themselves, but only transfer/route the responses of the addressed slave behind the bridge. However, when I capture the transactions using Signaltap I noticed that the Bridge is creating a writerepsonse valid before, this is even processed by the addressed slave. In the signaltap capture, you can see the writereponse (highlighted in yellow) arriving at the initiating master (cmd_ctrl) before, the addressed slave (global_reg) even generates it. Hence I would assume this is generated by the mm_bridge directly after it accepts the write command. Now my questions are: Is this the intended behavior of a pipeline bridge? If yes, is there any way to modify the settings of the bridge, to make sure the master (cmd_ctrl) only receives a writeresponsevalid after the respective slave has sent it? Background is: cmd_ctrl also needs to write/read from slave B, however this must not be done, before the slave global_reg has fully processed the write command, as it must prepare some glue logic. Is there any other option to realize a fully transparent Avalon-MM bridge? best regards Fabian
Technical Inquiry regarding DPCU Block for CPRI IP Single-Trip Delay Calibration
I am currently implementing the "single-trip delay calibration" feature using the Intel CPRI IP core. According to the User Guide (ID: 683595, Version: 2021.11.11), this feature requires the Dynamic Phase Control Unit (DPCU) block. The documentation states that "Intel provides the DPCU block with the CPRI IP." However, I am having difficulty locating this specific module. Could you please clarify where this DPCU block is located or how it should be instantiated? My design environment is as follows: Quartus Prime Version: 20.4 Pro Device Part Number: Arria 10 (10AS032H2F34I2SG) CPRI IP Version: 19.4.0 Reference Document: CPRI Intel FPGA IP User Guide (ID: 683595) Best regards!
Agilex 7 I Series Development Kit: External hardware access error when programming
I have a compiled design that I would like to test that implements Ethernet on F-Tile. When I try to program the FPGA with my bitstream, it stops and prompts me with the following errors: Would anyone know how to fix this or have insight on why this is happening?
Connecting Intel Agilex FPGA to DE1-SoC via Hub
Hello, I have an Intel Agilex FPGA with QSFP-DD 10 GbE PHY, a DE1-SoC board with 1 GbE PHY, and an Ethernet Hub 1 GbE. I want to connect the Agilex to the DE1-SoC through this hub. I understand the DE1-SoC only supports 1 GbE while the Agilex PHY is capable of 10 GbE. I would like to know the best way to communicate between these boards. Is it possible to configure the Agilex Ethernet IP and PHY to 1 GbE so it can communicate directly through the hub without a physical adapter? If not, would a media converter or adapter be needed to downspeed from 10 GbE to 1 GbE? Are there any recommended best practices for connecting an Agilex to a slower device like the DE1-SoC via Ethernet? Any guidance or experience would be greatly appreciated. Thank you!ALT PLL GUI MESSDED UP ON INVOCATION
Hi All ALTERA Experts, I have a problem setting up a new PLL due to the GUI looking like the mess you can see in my attached screenshot. I am using Quartus Standard edition Version 25.1 I am on a windows 10 machine and all of the other IP GUIs seem to work fine, its just this PLL IP GUI that seems to get messed up. I am using a MAX10 FPGA. Both my PC and Graphics card are working fine. Can anybody suggest why this occurs ? Thanks, BarryTransceiver data corruption
I am trying to externally loopback a simple data-stream using the GTS on the Agilex 5, over an external QSFP loopback module. The GTS is configured as followed: External clock chip: Outputs 156.25 MHz clock verified using an oscilloscope. System PLL: Outputs 125 MHz to the GTS. GTS: Basic PMA Direct System PLL freq: 125 MHz PMA speed: 1250 Mbps PMA width: 10 TX/RX PLL/CDR: 156.25 MHz TX/RX core interface FIFO: single width TX/RX clock: System PLL clock /1 The RTL used to transfer data over TX: module top( input CPU_RESET_n, input REFCLK, output gts_o_tx_serial_data, output gts_o_tx_serial_data_n, input gts_i_rx_serial_data, input gts_i_rx_serial_data_n ); // gts logic gts_pma_cu_clk_i; logic gts_tx_reset, gts_rx_reset; logic gts_tx_reset_ack, gts_rx_reset_ack; logic gts_tx_ready, gts_rx_ready; logic tx_coreclkin, rx_coreclkin; (* noprune *) logic gts_tx_clkout, gts_rx_clkout; logic gts_rs_grant_i; logic gts_rc_rs_req_o; (* noprune *) logic gts_tx_pll_locked /* synthesis keep */; (* noprune *) logic gts_rx_is_lockedtodata /* synthesis keep */; (* noprune *) logic gts_rx_is_lockedtoref /* synthesis keep */; logic o_refclk2core; (* noprune *) logic [79:0] gts_i_tx_parallel_data /* synthesis keep */; (* noprune *) logic [79:0] gts_o_rx_parallel_data /* synthesis keep */; assign gts_pma_cu_clk_i = srcss_bank1_pma_cu_clk_o; assign tx_coreclkin = gts_tx_clkout; assign rx_coreclkin = gts_rx_clkout; assign gts_rs_grant_i = srcss_bank1_rs_grant_o; // reset sequencer signals logic srcss_bank1_rs_grant_o; logic srcss_bank1_rs_priority; logic srcss_bank1_rc_rs_req; logic srcss_bank1_pma_cu_clk_o; assign srcss_bank1_rs_priority = '0; assign srcss_bank1_rc_rs_req = gts_rc_rs_req_o; // system pll signals logic gts_systempll_refclk_rdy; assign gts_systempll_refclk_rdy = 1'b1; gts_top u0 ( // gts .gts_top_clock_bridge_rx_in_clk_clk (QSFP_REFCLK_p), .gts_top_clock_bridge_tx_in_clk_clk (QSFP_REFCLK_p), .intel_directphy_gts_0_i_pma_cu_clk_clk (gts_pma_cu_clk_i), .intel_directphy_gts_0_i_tx_reset_tx_reset (gts_tx_reset), .intel_directphy_gts_0_i_rx_reset_rx_reset (gts_rx_reset), .intel_directphy_gts_0_o_tx_reset_ack_tx_reset_ack (gts_tx_reset_ack), .intel_directphy_gts_0_o_rx_reset_ack_rx_reset_ack (gts_rx_reset_ack), .intel_directphy_gts_0_o_tx_ready_tx_ready (gts_tx_ready), .intel_directphy_gts_0_o_rx_ready_rx_ready (gts_rx_ready), .intel_directphy_gts_0_i_tx_coreclkin_clk (tx_coreclkin), .intel_directphy_gts_0_i_rx_coreclkin_clk (rx_coreclkin), .intel_directphy_gts_0_o_tx_clkout_clk (gts_tx_clkout), .intel_directphy_gts_0_o_rx_clkout_clk (gts_rx_clkout), .intel_directphy_gts_0_i_src_rs_grant_src_rs_grant (gts_rs_grant_i), .intel_directphy_gts_0_o_src_rs_req_src_rs_req (gts_rc_rs_req_o), .intel_directphy_gts_0_o_tx_serial_data_o_tx_serial_data (gts_o_tx_serial_data), .intel_directphy_gts_0_o_tx_serial_data_n_o_tx_serial_data_n (gts_o_tx_serial_data_n), .intel_directphy_gts_0_i_rx_serial_data_i_rx_serial_data (gts_i_rx_serial_data), .intel_directphy_gts_0_i_rx_serial_data_n_i_rx_serial_data_n (gts_i_rx_serial_data_n), .intel_directphy_gts_0_o_tx_pll_locked_o_tx_pll_locked (gts_tx_pll_locked), .intel_directphy_gts_0_o_rx_is_lockedtodata_o_rx_is_lockedtodata (gts_rx_is_lockedtodata), .intel_directphy_gts_0_o_rx_is_lockedtoref_o_rx_is_lockedtoref (gts_rx_is_lockedtoref), .intel_directphy_gts_0_o_refclk2core_o_refclk2core (o_refclk2core), .intel_directphy_gts_0_i_tx_parallel_data_i_tx_parallel_data (gts_i_tx_parallel_data), .intel_directphy_gts_0_o_rx_parallel_data_o_rx_parallel_data (gts_o_rx_parallel_data), // reset sequencer signals .intel_srcss_gts_0_o_src_rs_grant_src_rs_grant (srcss_bank1_rs_grant_o), .intel_srcss_gts_0_i_src_rs_priority_src_rs_priority (srcss_bank1_rs_priority), .intel_srcss_gts_0_i_src_rs_req_src_rs_req (srcss_bank1_rc_rs_req), .intel_srcss_gts_0_o_pma_cu_clk_clk (srcss_bank1_pma_cu_clk_o), // system pll signals .intel_systemclk_gts_0_i_refclk_rdy_data (gts_systempll_refclk_rdy) ); // syncronise reset logic gts_tx_system_reset; altera_reset_synchronizer #( .ASYNC_RESET (1), .DEPTH (2) ) gts_tx_rst_sync ( .reset_in (~CPU_RESET_n), .clk (gts_tx_clkout), .reset_out (gts_tx_system_reset) ); // generate test data stream logic [7:0] counter; logic [7:0] test_stream; always_ff @(posedge gts_tx_clkout or posedge gts_tx_system_reset) begin if (gts_tx_system_reset) begin counter <= 8'b0; test_stream <= 8'b0; end else begin counter <= counter + 1; case (counter) 8'd0: test_stream <= 8'h3C; 8'd1: test_stream <= 8'h7F; 8'd2: test_stream <= 8'h11; 8'd3: test_stream <= 8'h07; default: test_stream <= 8'h00; endcase end end // detect and transform idle data, and mark control symbols logic [7:0] idle_data_transform; logic control_symbol_detect; always_comb begin idle_data_transform = (test_stream == 8'h00) ? 8'hBC : test_stream; control_symbol_detect = (idle_data_transform == 8'h1C) || (idle_data_transform == 8'h3C) || (idle_data_transform == 8'h5C) || (idle_data_transform == 8'h7C) || (idle_data_transform == 8'h9C) || (idle_data_transform == 8'hBC) || (idle_data_transform == 8'hDC) || (idle_data_transform == 8'hFC) || (idle_data_transform == 8'hF7) || (idle_data_transform == 8'hFB) || (idle_data_transform == 8'hFD) || (idle_data_transform == 8'hFE); end // pipline combinational logic to ensure timings are met logic [7:0] idle_data_transform_r; logic control_symbol_detect_r; always_ff @ (posedge gts_tx_clkout or posedge gts_tx_system_reset) begin if(gts_tx_system_reset) begin idle_data_transform_r <= 8'b0; control_symbol_detect_r <= 1'b0; end else begin idle_data_transform_r <= idle_data_transform; control_symbol_detect_r <= control_symbol_detect; end end // --- 8b/10b Encoding --- // https://libsv.readthedocs.io/en/latest/encoder_8b10b.html logic [9:0] encoded_out; logic code_error; encoder_tx encoder_inst ( .i_clk (gts_tx_clkout), .i_reset_n (~gts_tx_system_reset), .i_en (1'b1), .i_8b (idle_data_transform_r), .i_ctrl (control_symbol_detect_r), .o_10b (encoded_out), .o_code_err (code_error) ); // pipeline encoded outputs to ensure timing is met logic [9:0] encoded_out_r; always_ff @(posedge gts_tx_clkout or posedge gts_tx_system_reset) begin if (gts_tx_system_reset) encoded_out_r <= 10'b0; else encoded_out_r <= encoded_out; end // send data over TX logic data_path_rdy_tx; always_ff @(posedge gts_tx_clkout or posedge gts_tx_system_reset) begin if (gts_tx_system_reset) begin gts_i_tx_parallel_data <= 80'b0; data_path_rdy_tx <= 0; end else begin data_path_rdy_tx <= gts_tx_ready && gts_tx_pll_locked; case (data_path_rdy_tx) 1: gts_i_tx_parallel_data <= {1'b1, 39'b0, 1'b0, 1'b1, 28'b0, encoded_out_r}; 0: gts_i_tx_parallel_data <= 80'b0; endcase end end endmodule This RTL passes timing standalone, but when signal tap is used, it does produce warnings. In SignalTap I take the following measurments: Instance TX: data: gts_i_tx_parallel_data[79:0] clock domain: gts_tx_clkout Instance RX: data: gts_i_rx_parallel_data[79:0] clock domain: gts_rx_clkout The issue I am seeing is intermitted failures upon bitstream-re-configure: On the TX side, after the encoder has encoded, the TX data reads as folowed: (EXPECTED): ... 283, 17C, 283, 17C, 183, 335, 0B1, 347, 283, 17C, 283, 17C, ... This is the expected pattern on the RX side (post-framing) However, in my experiments so far, I have found that it only sometimes works: Here are the framing results after 5 different re-flashes: (FAILURE): ... 283, 17C, 283, 17C, 383, 135, 0B1, 347, 083, 37C, 283, 17C, ... (FAILURE): ... 283, 17C, 283, 17C, 383, 135, 0B1, 347, 083, 37C, 283, 17C, ... (FAILURE): ... 283, 17C, 283, 17D, 183, 335, 0B1, 346, 283, 17C, 283, 17C, ... (SUCCESS): ... 283, 17C, 283, 17C, 183, 335, 0B1, 347, 283, 17C, 283, 17C, ... (FAILURE): ... 283, 17C, 283, 175, 1B1, 307, 083, 37C, 283, 17C, 283, 17C, ... If anyone has any idea of what else to try, it would be much appreciated!
IO Standard for GTS Transceiver REFCLK
Hi, We use on the Agilex 5 and 3 Transceivers with AC coupling. Agilex 5 requires CML, HCSL in Agilex 5 datasheet. However, Agilex 5 Premium kit uses LVDS Clock for some Transceiver REFCLK. Is it possible to use LVDS as REFCLK for XCVRs when we use with AC Coupling ?
