Arbitration Cost

Chapter 17 established that an arbiter grants correctly. It never costed the grant. This chapter does.

A master waiting because another master owns the bus, and a master waiting because the slave is slow, look identical from the master and have completely different fixes.

1. Two Costs That Must Never Be Added

A faster slave does nothing for handover. A better arbiter does nothing for slave-wait. The probe that measures them is built so it cannot mix them:

// ─────────────────────────────────────────────────────────────────────────
// wb_arb_cost — clocks lost to HANDOVER, separated from clocks lost to
// the slave.
//
// Chapter 17 measured that an arbiter grants correctly. It did not cost
// the grant. This module does, and the separation is the entire point:
// a master waiting because another master owns the bus and a master
// waiting because the slave is slow look identical from the master and
// have completely different fixes.
//
//   HANDOVER  clocks a master asserted [CYC_O] while NOT the owner.
//             It is ready; the bus is not its to use. A faster slave
//             does not help.
//
//   SLAVE     clocks the OWNER had [STB_O] asserted with no termination.
//             A better arbiter does not help.
//
// ── THERE IS NO ARBITRATION COST MODEL IN B3 ────────────────────────────
// Nothing in the specification says what a grant should cost. These
// numbers are a property of wb_owner_arb3 from Chapter 17.5, reused

2. Three Masters, One Slave, One Beat Each

  === SIM F - arbitration cost, one master against three ===
    Chapter 17.5's wb_owner_arb3, reused unchanged. B3 has
    no arbitration cost model at all, so every number below
    is a property of THAT arbiter and not of Wishbone.

      all three masters issue a 1-beat burst at once

        master  grants  owned  handover  slave-wait  beats
          m0      1      2       1         0         1
          m1      1      2       3         0         1
          m2      1      2       5         0         1

      HANDOVER is clocks a master asserted [CYC_O] while
      not the owner. SLAVE-WAIT is clocks the OWNER had
      [STB_O] up with no termination. They are different
      costs with different fixes and this probe never adds
      them together.

      total handover across three masters  9
      total slave-wait                     0
      -> slave-wait is 0, as it must be with a
         zero-wait-state slave. The whole cost is
         handover.

Read the handover column: 1, 3, 5.

That is a fixed-priority signature and it is exactly what Chapter 17.1 predicted qualitatively. m0 waits one clock, m1 three, m2 five — each master waits for every master ahead of it to finish. The arbiter was never asked to be fair and is not.

And slave-wait is 0 across all three, because this slave has no wait states. If it were not zero, the probe would be broken — which is why the testbench checks it rather than assuming it.

3. Does A Longer Burst Amortise The Handover?

  === SIM G - does a longer burst amortise the handover? ===

      beats  total clocks  handover  clocks/beat  handover/beat
        1          6           18        2.00          6.00
        2          9           30        1.50          5.00
        4         15           48        1.25          4.00
        8         27           78        1.12          3.25

      BOTH THINGS ARE TRUE AND THEY POINT OPPOSITE WAYS.

      The TOTAL handover column grows - 18, 30, 48, 78 -
      because a longer burst makes the two masters that do
      not own the bus wait longer. That is contention, and
      it is the cost of sharing.

      The PER-BEAT handover column falls - 6.00, 5.00,
      4.00, 3.25 - because the grant is paid once per
      [CYC_O] and RULE 3.25 makes one [CYC_O] span the
      whole block: "MASTER interfaces MUST assert [CYC_O]
      for the duration of SINGLE READ / WRITE, BLOCK and
      RMW cycles." A 1-beat burst pays one grant for one
      beat; an 8-beat burst pays one grant for eight.

      SO THE HANDOVER DOES AMORTISE, per unit of work moved,
      while the wall-clock wait for the losing masters gets
      longer. Which number you care about depends on whether
      you are optimising throughput or worst-case latency -
      and Chapter 17.4's starvation analysis is the other
      half of that question.

4. When The Arbiter Is Even Asked

Handover cost is not a property of the policy alone. It is a property of how often the policy runs, and wb_owner_arb3 runs it only when the current owner has finished:

  logic [1:0] owner_q;
  logic own0, own1, own2;
  assign own0 = (owner_q == 2'd1);
  assign own1 = (owner_q == 2'd2);
  assign own2 = (owner_q == 2'd3);

  logic cur_cyc;
  assign cur_cyc = (own0 && m0_cyc_i) || (own1 && m1_cyc_i)
                || (own2 && m2_cyc_i);

  assign elig_o = {m2_cyc_i, m1_cyc_i, m0_cyc_i};

  logic arb_event;
  assign arb_event = PREEMPT ? 1'b1
                             : ((owner_q == OWN_NONE) || !cur_cyc);
  assign arb_event_o = arb_event;

arb_event is the whole cost model in one expression. The arbiter re-decides when there is no owner, or when the owner has negated [CYC_O]. While a master holds [CYC_O], nothing is re-decided — which is RULE 3.25 doing its work:

"MASTER interfaces MUST assert [CYC_O] for the duration of SINGLE READ / WRITE, BLOCK and RMW cycles." — B3, RULE 3.25

So a burst is one arbitration event, whatever its length. That is why §3's per-beat handover falls while its total rises: the numerator is bounded by the burst and the denominator is the burst.

5. What The Cost Looks Like As The Master Count Grows

With fixed priority and N masters all requesting at once, master k waits for every master ahead of it. §2 measured 1, 3, 5 for three masters at one beat each — two clocks apart, because each predecessor occupies the bus for two clocks of wall time.

This is why the chapter refuses to publish a general formula. A handover cost model needs the policy, the master count, the phase relationship between requesters and the arbiter's own register depth. That is a model of one arbiter, and Chapter 17.5 is where that arbiter is described.

6. The Trade This Chapter Actually Describes

There is no setting that optimises all three, and B3 does not choose for you — it has no arbitration rules at all beyond [CYC_O] ownership.

This is the same shape as Chapter 17.3's finding, now with numbers attached: fairness, throughput and latency are three different objectives and an arbiter can serve at most two well.

7. Where The Formula From Chapter 22.1 Stops Holding

Chapter 22.1 §3 derived clocks(N, W) = N × (1 + W) and §8 confirmed it exactly at five wait-state settings. That formula has no term for another master.

The formula describes a bus with one master and is silent about any other. Extending it would mean modelling the arbiter's policy, the number of contenders and their phase relationship — which is a model of wb_owner_arb3 and nothing more general.

That is the honest boundary of the arithmetic, and it is the first of the two places Chapter 22.1 §8 predicted the formula would break. Chapter 22.5 is the second.

9. What Fairness Would Cost

Chapter 17.3 established that fairness must be defined before it can be claimed, and Chapter 17.4 separated starvation from a merely long wait. Neither costed the alternative, and §2's numbers make the shape of that cost visible.

Fixed priority gave 1, 3, 5. The lowest-priority master waits five clocks; the highest waits one. That spread is the unfairness — and it is also where the throughput comes from, because a fixed-priority arbiter never spends a clock reconsidering a decision it has already made.

The last row is the honest summary and it is not a measurement. wb_arb_policy supports both policies and Chapter 17.5 built them — but this module measured only the fixed-priority configuration, so the right-hand column above is a structural expectation rather than a result.

9. What Was Not Measured

Fairness, starvation bounds and priority inversion — all of which Chapter 17 covered and none of which are clock counts. This chapter measures cost, not justice.

Arbiter area, or the frequency impact of a wider grant tree. No synthesis was run; Chapter 22.1 §1 has the complete refusal list.

Any arbiter other than wb_owner_arb3. The 1/3/5 pattern is fixed priority's. Round-robin would give a different one, and this module did not build it.