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.