A naive man’s attempt to understand the efficiency of a NoC.

It all started with a simple question:

How many body flits is too many body flits?

Is having 100 body flits in a packet okay? Sure, but then the resources associated with that flow remain occupied for a brutal amount of time.

It’s crazy to get all that transmission efficiency from sending just one head flit and one tail flit, only for a small packet to be trapped behind it waiting for its turn.

This is called serialization delay.

So the naive man thought, let’s improve fairness in the arbiter.

But alas! Fairness doesn’t make the packet shorter. The arbiter can be perfectly fair, and the Virtual Channel (VC) is still held hostage while all those body flits slowly make their way through.

The naive man was naive again.

A 100-flit packet simply consumes more cycles, and in a wormhole-style design, the VC allocation remains locked until the tail flit finally passes. At first glance, this looks like a purely temporal problem: the packet simply exists for too long.

The obvious solution is to give the router more choices. If one VC is occupied, let another packet use a different VC, assuming the required downstream buffers are available.

“Then increase the VCs,” he said.
“But SRAM is costly,” they said.

This is capitalism baring its fangs.

And then the arbitration logic bites back, too. Every additional VC adds another possible request that the allocator has to consider. More VCs mean more state, and wider, far more complex allocation logic. The exact cost depends on the router architecture, but eventually, the hardware needed just to decide who gets the resource starts becoming part of the bottleneck itself.

Which makes this feel like a temporal problem disguising a spatial one.

We started by worrying about how much time a packet spends holding a resource. But the only way to escape that temporal delay is by spending physical hardware: more buffers, more VCs, more arbitration gates. The delay is temporal, but the way we buy concurrency is spatial. And the cost of that solution is spatial, too.

So perhaps the real problem was never just that the packet takes too many cycles. It is that we have a finite amount of hardware trying to force temporal contention into spatial concurrency.

We have gone in a full circle, and the original question returns:

How many body flits is too many?

Apparently, there is no magic number.

Just a collection of tradeoffs waiting to bite you.