KennyT_altera
Super ContributorJoined 5 years ago
User Profile
Super Contributor
User Widgets
Contributions
Re: Cascaded Avalon Stream Multiplexer in Platform Design does not forward valid data packets
--- ## Solutions ### **Solution 1: Fix the DSP Source (Best Practice)** Modify your DSP output interface so that `valid` remains asserted until `valid & ready = 1`: ``` If (data_available): valid <= 1 data <= <packet_data> Else If (valid & ready): valid <= 0 // Only deassert after successful handshake Else: valid <= valid // Hold valid asserted ``` This is the protocol-compliant solution and requires no additional IP. --- ### **Solution 2: Add Input FIFOs (Practical for Complex DSP Pipelines)** Insert an **Avalon Streaming FIFO** before each of your 32 DSP channels at the mux inputs: ``` DSP_Channel_0 --> [FIFO] --> 16-to-1 Mux Input 0 DSP_Channel_1 --> [FIFO] --> 16-to-1 Mux Input 1 ... DSP_Channel_31 --> [FIFO] --> 16-to-1 Mux Input 15 (Second group) ``` **Benefits:** - The FIFO accepts your single-cycle pulse - Holds `valid` asserted until the mux grants `ready` - Completely decouples your DSP timing from the scheduler - Adds minimal latency (typically 1–2 cycles per FIFO) - Works with any scheduling configuration **Configuration in Platform Designer:** - FIFO depth: 16–32 (sufficient for burst absorption) - Single-clock FIFO (matches your system clock domain) - No packet support needed unless your DSP already uses it --- ### **Solution 3: Increase Scheduling Size (Mitigation Only)** Increasing from Scheduling Size = 2 to a higher value (e.g., 8–16) gives each channel a longer arbitration window, but **does not solve the underlying protocol issue**. Your sources should still not pulse `valid` for a single cycle. This is a workaround, not a solution. --- ## Verification Approach After implementing Solution 1 or 2, verify with SignalTap: 1. **At mux inputs**: Confirm that `valid` remains high until `valid & ready = 1` on the same cycle for all channels. 2. **At mux output**: Set trigger on rising edge of output `valid` for each channel and confirm triggers fire for all 32 channels. 3. **Data integrity**: Verify that packets from all channels contain correct channel IDs and data. --- ## Why Cascaded Muxes Don't Hide the Issue Your 32-to-1 cascaded architecture is sound, but the scheduler starvation propagates through each stage: - If channels 1–31 don't transfer at the first 16-to-1 mux stage, they never reach the second stage. - The final 2-to-1 mux then only multiplexes channels from whichever group wins arbitration. The data path to HPS works (proven by your emulator), so this is purely an input arbitration issue. --- ## So in summary **Root Cause**: Your DSP sources violate the Avalon-ST protocol by pulsing `valid` for only 1 cycle. The mux scheduler cannot guarantee that `ready` will be presented during that 1-cycle window—especially for non-zero channels that must wait for scheduler rotation. **Recommended Fix**: Add input FIFOs (Solution 2) for minimum disruption to your existing DSP logic. This is the standard approach for integrating DSP modules with streaming interconnect in Quartus designs. **Expected Outcome**: All 32 channels will forward packets to the HPS correctly. ---0Views0likes1CommentRe: Cascaded Avalon Stream Multiplexer in Platform Design does not forward valid data packets
Thank you for the detailed problem description and SignalTap analysis. I've thoroughly investigated this issue using the Quartus Prime Pro Platform Designer documentation (section 7.12.2), and I can suggest **the root cause and provide a some solution**. https://docs.altera.com/r/docs/683609/26.1/quartus-prime-pro-edition-user-guide-platform-designer/axi-streaming-adapter-parameters ## Potential Root Cause: Scheduler Behavior vs. Protocol Violation Your issue is caused by a **race condition between the scheduler's round-robin arbitration and your DSP source's single-cycle valid pulse**. ### The Scheduler's Operating Principle According to Platform Designer documentation (section 7.12.2), the Avalon-ST Multiplexer uses a round-robin scheduler that processes input interfaces sequentially. The scheduler continues granting `ready` to an input interface until **one of these conditions occurs**: 1. The specified number of cycles have elapsed (your Scheduling Size = 2) 2. **The input interface has no more data to send and the valid signal is deasserted on a ready cycle** ← **This is the problem** 3. When packets are supported, endofpacket is asserted ### Why Channel 0 Works But Others Don't - **Channel 0**: The scheduler starts with channel 0. When your DSP pulses `valid`, `ready` is already being presented to channel 0 (or arrives at the front of the rotation), so the handshake completes immediately: `valid & ready = 1` on the same cycle. - **Channels 1–31**: The scheduler must rotate through prior channels first. By the time the scheduler reaches channel 28 and presents `ready`, your source has already deasserted `valid` (after 1 cycle). The scheduler detects `valid = 0` on the ready cycle and skips to the next channel per condition #2 above. ### Your Observed SignalTap Pattern Explained ``` | Cycle | valid | ready | |-------|-------|-------| | Idle | 0 | 1 | | Data | 1 | 0 | | Next | 0 | 1 | ``` This happens because: - **Idle**: Scheduler is granting `ready` to a different channel - **Data**: Your source pulses `valid`, but the scheduler hasn't yet selected channel 28 → `ready = 0` for that channel - **Next**: You've deasserted `valid`, and the scheduler is rotating forward → `ready = 1` but too late to capture your data The scheduler sees condition #2 (valid deasserted on a ready cycle) and moves on. ### Why Enabling Channel 0 "Temporarily Helped" When both channels were enabled, the scheduler kept cycling, but only channel 0's packets completed handshakes. Channels 28+ were still missing their arbitration window because your DSP timing didn't align with the scheduler's rotation. --- ## The Protocol Issue This behavior reveals an **Avalon-ST protocol violation** in your DSP source: > **Avalon-ST Specification**: A source must hold `valid` asserted until `ready` is also asserted in the same cycle. A source is not permitted to deassert `valid` before the handshake completes. Your DSP sources pulse `valid` for exactly 1 cycle, which breaks this contract. The multiplexer is behaving correctly—it simply cannot accommodate sources that don't comply with the protocol.0Views0likes0CommentsRe: List of available patches for specific Quartus version
Hi, You may refer to https://docs.altera.com/r/docs/683706/26.1/quartus-prime-pro-edition-version-26.1-software-and-device-support-release-notes/software-patches-included-in-this-release For the latest information about issues that affect Quartus® Prime Pro Edition Version 26.1, review the FPGA Knowledge Base articles that apply to Quartus® Prime Pro Edition Version 26.1 . We understand that there are currently limitations with filtering in the knowledge base. Please be assured that this will be addressed in a future update. Thanks1View0likes0CommentsRe: Modifying and/or hiding interfaces based on component parameters?
After refer to https://docs.altera.com/r/docs/683609/26.1/quartus-prime-pro-edition-user-guide-platform-designer/answers-to-top-faqs You can do this, but not through ongoing Component Editor edits. Platform Designer supports parameter-dependent interface visibility via ELABORATION_CALLBACK (see Section 4.7, “Control Interfaces Dynamically with an Elaboration Callback” in the link above). The expected flow is: create the component once in Component Editor, then manually edit _hw.tcl for callbacks/custom Tcl (Section 4.3). If you reopen that customized component in Component Editor, your custom Tcl is overwritten (Section 4.3 note / 4.3.2). For loading/testing without “New Component”: Platform Designer discovers _hw.tcl from IP search paths during Discovery (Section 4.2). So put your component directory in IP Catalog Search Locations / SEARCH_PATH / user_components.ipx (Sections 2.6.5.1.x and 2.6.5.2), reopen Platform Designer, and instantiate from IP Catalog. So in short: your approach is valid; use manual _hw.tcl + IP search path discovery, not repeated Component Editor edits.9Views1like0CommentsRe: Recommendations for Quartus Prime File Cloud Storage
Hi, You may refer to https://docs.altera.com/r/docs/683498/17.1/quick-start-guide-for-development-tools-on-the-microsoft-azure-platform/quick-start-guide-for-intel-fpga-development-tools-on-the-microsoft-azure-platform for the details. Thanks7Views0likes0CommentsRe: retiming issue
Enabling the ignore_power_up_initialization setting may cause abnormal behavior in on-board testing, because it allows the compiler to ignore defined power-up conditions that may be required for correct startup operation. This is especially risky for altera_scfifo, which contains internal state and control logic beyond simple memory, so using this setting as a workaround for retiming restrictions is not recommended.4Views0likes0Comments