New Contributor
Super Contributor
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.
