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.

 

---

## 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.

---