interconnect
The POQ Is the Interconnect
2026 · 7 min read
Cache-coherent interconnects are advertised by their snoop filters and system level caches. They are bottlenecked by a queue nobody puts on a slide. If your model doesn't track the transaction queue, it doesn't track the performance.
Take a modern coherent interconnect: CPU clusters, GPUs, and accelerators all issuing CHI requests into a home node (HN-S) that owns a snoop filter and a system level cache (SLC). The architecture diagram draws the request paths, the snoop fanout, the memory interface. What it doesn't draw is the piece of state that every one of those transactions has to pass through: the transaction queue — the POQ, in Arm's HN-S terminology.
What the POQ actually does
The POQ is not a FIFO. It's the tracking structure for every transaction in flight through the home node:
- CPU CHI requests, waiting for snoop responses or memory,
- SLC writebacks and evictions,
- snoop filter evictions,
- requests stalled on a downstream resource — memory, or a far-side port toward another chip.
It plays three roles at once: a tracker (what is in flight and at what state), a data buffer (payloads waiting for their counterpart), and a serialization point — transactions to the same or overlapping addresses are ordered through it. That third role is the one that makes the POQ a correctness structure, not just a performance one.
Depth is a PPA decision, not a knob
A POQ is sized somewhere in the 32–128 entry range. Past roughly 64 entries, the lookup and ordering logic starts to fight the block's target frequency — the CAM-like structures that make same-address ordering work don't scale for free. So depth is bought with timing closure, which means it's scarce, which means everything downstream of it is about allocation policy.
Two structural details matter more than the raw number:
- The eviction queue is not a separate resource. It's a reservation within the POQ — some entries are dedicated to evictions so that a burst of fills can't starve the drain path. If your model treats eviction as free, it will predict throughput the silicon can't deliver.
- One entry is kept for internal use. The credit count advertised to requesters is the queue size minus one. Model the advertised number, not the register value, or your credit accounting will be off by one in exactly the corner cases where credits matter.
Credits and retry: the flow control that isn't in the spec
Requesters don't get to push transactions into the home node and hope. They hold credits, and the handshake is simple: if an entry is available, the transaction is accepted and tracked; if not, the home node retries it and the requester waits. All of the interesting behavior lives in the policy around that handshake:
- Are credits managed per requester, or globally?
- Is a credit returned when the transaction completes, or when the POQ entry frees — which can be much earlier?
- When a requester retries, does it keep its place, or go to the back of a conceptual line?
These are exactly the questions a spec answers ambiguously and a model has to answer precisely. Get the credit-return point wrong and your model is either pessimistic (credits held too long) or optimistic (a requester that never stalls) — and both errors look like a correlation mismatch in a full-system test, not in a unit test.
QoS: reserving your way out of a monopoly
The last defense against one traffic class eating the POQ is classification. Transactions are sorted into QoS classes, and the class configuration decides who can contend:
- Dedicated entries — reserved for a class, so it can always make progress,
- Contention mode — whether the class may also grab shared entries, or only its own,
- Maximum allowed — a cap, so a class can contend but not monopolize,
- with classification driven by QoS value or transaction type.
The subtlety: dedicated entries are capacity that other classes can't use even when idle. A configuration that guarantees progress for real-time traffic also statically removes those entries from everyone else. That trade is invisible in a functional model and glaring in a performance model — which is why we model the reservation, not just the acceptance.
Remote chips change the shape of the problem
Add a coherent chip-to-chip fabric and the POQ problem gets worse in a specific way: a transaction that misses locally and goes remote now occupies a POQ entry for a latency measured in hundreds of nanoseconds, not tens. The address mapping — which addresses route to local memory and which cross the link — determines what fraction of your traffic becomes the slow kind.
This is where we push clients hardest on modeling priorities. The remote path is where ordering, retry, and credit policy interact: a retried remote transaction holds requester state longer, remote responses arrive out of order with local evictions, and the QoS reservation that looked generous in a single-chip workload becomes the constraint in a two-chip one. If the model doesn't represent the remote latency class at all, the first full-system bring-up will find problems the model swore weren't there.
What this means for a model
A transaction-level model of a coherent interconnect that only implements the protocol — states, snoop responses, data flow — is a functional model, and it will pass every protocol test. The performance truth of the system lives in resource policy: queue depth, entry reservation, credit issue and return, retry arbitration, QoS classing. None of it is optional detail. All of it is the difference between a model that agrees with the architecture diagram and one that agrees with the silicon.
Our rule of thumb: when a client asks "can this interconnect sustain X bandwidth," the answer is never in the bandwidth numbers. It's in whether the POQ — at its real depth, with its real reservations, under its real credit policy — drains fast enough to keep accepting. That's a modeling question, and it's answerable before RTL exists. That's the point of the model.