A network-on-chip link carries both requests and responses. One day a burst of requests fills the input buffer at the next router, and the responses behind them, the very responses that would let those requests complete, cannot get in. The link is idle and the system is stuck. A second set of buffers for responses, on the same wires, removes the problem completely.
How can one physical link behave like several independent ones, and why would you want it to?
The obvious link has one buffer at its receiving end and one flow-control loop: whatever arrives first goes first. Every kind of traffic shares that buffer, so any kind can block any other: bulk traffic delays urgent traffic (lesson 8.7), a blocked packet stops everything behind it (lesson 4.14), and requests can block the responses they depend on (Part 9). Adding more wires for each kind of traffic would fix it, at a high cost in area.
A virtual channel (VC) is a separate buffer at the receiver with its own credit loop, sharing the physical link's wires with other VCs. Each flit carries a VC number; the sender may send a flit on a VC only if that VC has credit; each cycle, an arbiter chooses which VC's flit uses the wires. A VC that is blocked holds only its own buffer; the others keep moving.
Benefit | How |
|---|---|
Isolation between traffic classes | Urgent traffic has its own buffer and is never queued behind bulk (lesson 8.7) |
Less head-of-line blocking | A packet blocked in one VC does not stop packets in another (lesson 4.14) |
Deadlock freedom | Requests and responses in separate VCs cannot block each other (lesson 9.4); extra VCs break cyclic dependencies in rings and meshes (lesson 9.6) |
Higher link use | When one VC is blocked, another can use the wires |
Buffers: each VC needs enough buffer to cover its own credit round trip for the rate it must sustain (lesson 4.5); V VCs multiply buffer area.
Credit loops: one counter and one credit-return path per VC.
Arbitration: a VC arbiter on each link output, and VC allocation in each router (which VC a packet uses on the next link).
A VC field in every flit or packet.
VCs are therefore assigned for a purpose (one per message class that must not block another, plus what deadlock avoidance needs), not handed out freely.
Protocol | Virtual channels |
|---|---|
PCI Express | Traffic classes map onto virtual channels, each with its own buffers and its own posted, non-posted and completion credits. |
On-chip networks | VCs per message class (requests, responses, snoops) and extra VCs for deadlock-free routing on rings and with adaptive routing. |
AXI | No VCs: independent channels per direction and kind (lesson 5.6) give some of the same isolation. |
The opening network (illustrative) carried requests and responses in one buffer per link. Under a request burst, buffers filled with requests whose targets could not accept more until they sent responses, and the responses had nowhere to go. Moving responses to their own VC removed the cycle of dependencies; nothing else changed.
36 flits: each VC has its own buffer and credits.
Each VC has its own credits; the sender stops sending on the full VC only, and the arbiter gives the wires to VCs that have credit.
A virtual channel is a separate buffer and credit loop sharing one physical link's wires.
VCs isolate traffic classes, reduce head-of-line blocking and break deadlock cycles.
Each VC costs buffers, credits and arbitration; assign them for a purpose and keep them end to end.