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.
Why the Error Response Slave IP cannot work for Agilex 5 SOC FPGA?
I test the GHRD and corresponding linux image on Terasic DE25-Nano board， however, when I access the FPGA peripheral device, like SW, I use md.l 0x20010060 1 command in U-Boot console, it reports the register value; when I use md.l 0x2fffffff 1 (the H2F ummapped address) or md.l 0x4fffffff 1 (the LWH2F ummapped address), the system will hang up, report Please reset the board! then I added a Error Response Slave IP and tested, but it still report the same message, then, I need reboot my system every time. I set the IP as follows: after this, I added two Error Response Slave IPs in the system, one is for H2F, another is for LWH2F: Unfortunately, the problem still remains unsolved.
Stratix 10 fPLL is cascade source mode doesn't lock
Hello everyone. I use fPLL cascading with Stratix 10 FPGA: fPLL in cascade source mode is connected to fPLL in transceiver mode. In my design reference clock for fPLL in cascade source mode is not stable after power-up and I apply user recalibration to it. But after user recalibration when reference clock is stable, fPLL doesn't set lock signal. After some investigation of the issue, I found that my design works fine with Quartus Pro 21.2 but doesn't work with newer versions like Quartus Pro 23.4/25.1/26.1. Is there any known issue about fPLL is cascade source mode? Any suggestions about how to overcome this issue are welcomed.SerialLite II license for Arria10 FPGA
I purchased a SerialLite II license and received the license file. However, I need a special license to support Arria 10 FPGAs. In previous years, I obtained this license by contacting Altera technical support through a sales representative. This year, I was advised to contact Altera through the forum. Please help me find the correct way to obtain the necessary license file.
Accessing registers in the PCIE IP beyond MCDMA using system console
Hi, I have compiled the MCDMA IP (R-Tile based) in EP mode. I have a custom controller IP interfaced with MCDMA IP. There is a CSR Lite Interface on the port list which is a master interface. I have a JTAG to Avalon master bridge through which I want to access the registers in the MCDMA as well as the controller beyond the MCDMA. As JTAG is a master interface and the CSR Lite is also a master interface, they can't be interfaced together. Please suggest how can I interface the JTAG master so that I can access the registers inside the controller as well as MCDMA IP. Also is there any way to access the registers inside MCDMA IP without using JTAG to Avalon master bridge?
AI Suite Docker Update?
Hello Community, I see the 2026.1.1 version of the AI Suite is available - https://www.altera.com/downloads/add-development-tools/fpga-ai-suite-version-2026-1-1 Is there an expected delay or expected date for the Docker to reflect this version? - https://hub.docker.com/r/alterafpga/fpgaaisuite Thank you,
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 Fabiantennm_mac in m18x18_sumof2 mode on Agilex 7 - spurious systolic register inserted in Quartus 25.3
Device: Intel Agilex 7 Quartus version: Quartus Prime Version 25.3.0 Build 109 09/24/2025 SC Pro Edition Atom: tennm_mac Mode: m18x18_sumof2 with pre-adder (operand_source_may = "preadder") Description I am directly instantiating tennm_mac atoms in m18x18_sumof2 mode for a high-throughput multiplications. The design uses the pre-adder on both multipliers (az/bz ports) and has all four pipeline stages enabled (ax_clken, input_pipeline_clken, second_pipeline_clken, output_clken all set to "0"). I observe incorrect result at the output of the multiplier. Inspecting the Resource Property Viewer confirms that systolic registers have been placed on the A* path inside the DSP block, even though: input_systolic_clken is explicitly set to "no_reg" Systolic mode is not selected — the operation mode is m18x18_sumof2 The systolic register is architecturally present only on the A* datapath; the B* datapath has no equivalent register, so the skew is asymmetric by design. The result is incorrect sum of multiplies output on hardware - the coefficient and data samples presented to the multiplier are misaligned by one clock cycle. Minimal defparam set that reproduces the issue: tennm_mac u_mac ( .ax(ax), .ay(ay), .az(az), .bx(bx), .by(by), .bz(bz), .clk(clk), .ena(3'b111), .clr(2'b00), .resulta(result) ); defparam u_mac.operation_mode = "m18x18_sumof2", u_mac.operand_source_may = "preadder", u_mac.operand_source_mby = "preadder", u_mac.ax_clken = "0", u_mac.bx_clken = "0", u_mac.ay_scan_in_clken = "0", u_mac.by_clken = "0", u_mac.az_clken = "0", u_mac.bz_clken = "0", u_mac.input_pipeline_clken = "0", u_mac.second_pipeline_clken = "0", u_mac.output_clken = "0", u_mac.input_systolic_clken = "no_reg", // <-- ignored u_mac.clear_type = "none"; Questions Are my assumptions that systolic registers are placed incorrectly correct? Is this a known issue in Quartus 25.3 / with Agilex 7 devices? Similar design compiled correctly on Quartus 17.1 for Arria 10. Any guidance to resolve this issue would be appreciated.
