Mobile-Memory Mission

   active :  2% of the time  x  50 units  =  1.00 units of average power
   idle   : 98% of the time  x   1 unit   =  0.98 units of average power
                                             ----
   total average                              1.98 units

   the idle state contributes  0.98 / 1.98  =  49.5%  of the average

   active :  2%  x  40 units  =  0.80
   idle   : 98%  x   1 unit   =  0.98
                                 ----
   total                         1.78     a 10.1% improvement

   active :  2%  x  50 units  =  1.00
   idle   : 98%  x  0.8 units =  0.784
                                 -----
   total                         1.784    a 9.9% improvement

// ---------------------------------------------------------------------
// mobile_energy_accountant -- keeps §2's three quantities separate and
// reports which one dominates an average.
//
// CLASSIFICATION: educational, synthesisable.
//
// ALL UNITS ARE ABSTRACT AND DIMENSIONLESS. There are no joules,
// watts, amps or volts anywhere in this block, and it models no real
// device. Use it to COMPARE two configurations, never to size one.
//
// WHAT IT DOES NOT MODEL:
//   - any physical quantity, any supply rail, any real consumption
//   - the exit-energy cost of leaving a low-power state, which 24.2
//     owns and which terms_excluded records as missing
//   - temperature, which §4 establishes feeds back into the cost
//
// WHY IT REFUSES TO COMBINE THE THREE: §2. Energy per bit, idle power
// and peak bandwidth are measured differently and can move in
// opposite directions. A single "power score" would hide exactly the
// trade this module is about.
// ---------------------------------------------------------------------
module mobile_energy_accountant #(
  // Width of an abstract unit. Wide enough that a long observation
  // window does not saturate; saturation is still detected because a
  // clamped total reads LOW, which is the flattering direction.
  parameter int UNIT_W = 20,
  // Duty cycle is expressed as a numerator over this denominator, so
  // no division is needed anywhere. 10000 gives basis-point
  // resolution -- 200 means 2.00%.
  parameter int DUTY_DEN = 10000,
  parameter int ACC_W = UNIT_W + 18
) (
  input  logic                clk,
  input  logic                rst_n,

  // ── The model, supplied by the caller. Abstract units throughout.
  input  logic [UNIT_W-1:0]   active_power,     // cost while moving data
  input  logic [UNIT_W-1:0]   idle_power,       // cost while doing nothing
  // Duty cycle numerator over DUTY_DEN. §3: this is a SYSTEM property,
  // not a memory property, which is why it is an input.
  input  logic [UNIT_W-1:0]   duty_num,

  // ── Observed work, for the energy-per-bit half.
  input  logic                bit_moved,        // one abstract bit went out
  input  logic                tick,             // one time unit elapsed

  // ── §2's three quantities, reported SEPARATELY and never summed
  //    into one another.
  output logic [ACC_W-1:0]    weighted_active,  // duty x active
  output logic [ACC_W-1:0]    weighted_idle,    // (1-duty) x idle
  output logic [ACC_W-1:0]    average_power,    // the two above, added
  output logic [ACC_W-1:0]    bits_moved,
  output logic [ACC_W-1:0]    time_elapsed,

  // Which of the two halves of the average is larger. §3's whole
  // point, as one bit.
  output logic                idle_dominates,
  // Idle's share, as a NUMERATOR over average_power. Published as a
  // pair so nothing divides -- the caller states its denominator.
  output logic [ACC_W-1:0]    idle_share_num,
  output logic [ACC_W-1:0]    idle_share_den,

  // ── What this arithmetic does NOT contain. Published as a vector so
  //    a property can require it to be non-zero (§13's P4).
  //    bit 0 exit energy from low-power states  (24.2)
  //    bit 1 temperature dependence             (§4)
  //    bit 2 per-rail detail                    (§7, 24.5)
  //    bit 3 refresh energy                     (24.2)
  //    bit 4 wasted payload on small accesses   (§6, 12.4)
  //    bit 5 thermal ceiling                    (§4)
  //    bit 6 any physical unit whatsoever
  //    bit 7 the requester mix's actual shape   (§6)
  output logic [7:0]          terms_excluded,

  output logic                err_duty_out_of_range,
  output logic                any_saturated
);

  // ── Elaboration guards.
  initial begin
    if (DUTY_DEN < 100)
      $fatal(1, "mobile_energy_accountant: DUTY_DEN (%0d) too coarse", DUTY_DEN);
    if (UNIT_W < 8)
      $fatal(1, "mobile_energy_accountant: UNIT_W (%0d) too small", UNIT_W);
    // A product of two UNIT_W values needs 2*UNIT_W bits, plus room to
    // accumulate. A narrow accumulator would truncate the product and
    // report a smaller average than the model implies.
    if (ACC_W < 2*UNIT_W)
      $fatal(1, "mobile_energy_accountant: ACC_W must hold a UNIT_W product");
  end

  // ── The duty split. Computed combinationally from the inputs so the
  //    caller can sweep duty_num and watch the balance move (§3's table)
  //    without re-running an accumulation.
  logic [UNIT_W-1:0] idle_num;
  logic              duty_bad;
  always_comb begin
    duty_bad = (duty_num > UNIT_W'(DUTY_DEN));
    // Saturate rather than wrap on a nonsensical duty: a wrapped
    // complement would report a huge idle share.
    idle_num = duty_bad ? '0 : (UNIT_W'(DUTY_DEN) - duty_num);
  end

  logic [ACC_W-1:0] w_act, w_idl;
  always_comb begin
    w_act = {{(ACC_W-UNIT_W){1'b0}}, active_power} * {{(ACC_W-UNIT_W){1'b0}}, duty_num};
    w_idl = {{(ACC_W-UNIT_W){1'b0}}, idle_power}   * {{(ACC_W-UNIT_W){1'b0}}, idle_num};
  end

  logic [ACC_W-1:0] bits_q, time_q;
  logic             sat;

  always_ff @(posedge clk or negedge rst_n) begin
    if (!rst_n) begin
      bits_q <= '0;
      time_q <= '0;
      sat    <= 1'b0;
    end else begin
      if (bit_moved) begin
        if (bits_q == {ACC_W{1'b1}}) sat <= 1'b1;
        else                         bits_q <= bits_q + ACC_W'(1);
      end
      if (tick) begin
        if (time_q == {ACC_W{1'b1}}) sat <= 1'b1;
        else                         time_q <= time_q + ACC_W'(1);
      end
    end
  end

  assign weighted_active = w_act;
  assign weighted_idle   = w_idl;
  assign average_power   = w_act + w_idl;
  assign bits_moved      = bits_q;
  assign time_elapsed    = time_q;

  // §3's headline: which half of the average is bigger.
  assign idle_dominates  = (w_idl > w_act);
  // Published as a pair. §2's discipline: a share without its
  // denominator is not a quantity.
  assign idle_share_num  = w_idl;
  assign idle_share_den  = w_act + w_idl;

  // Every physical term is absent, and that is permanent for this
  // block rather than a gap to be filled later.
  assign terms_excluded  = 8'hFF;

  assign err_duty_out_of_range = duty_bad;
  assign any_saturated         = sat;
endmodule

// ---------------------------------------------------------------------
// mission_budget_checker -- does a stated energy allowance admit a
// stated amount of memory work?
//
// CLASSIFICATION: educational, synthesisable.
//
// ALL UNITS ARE ABSTRACT. No joules, no milliamp-hours, no device.
//
// WHAT IT DOES NOT MODEL:
//   - any physical quantity or real battery
//   - the thermal ceiling of §4, which is a SECOND and independent
//     constraint: a workload can satisfy this checker and still
//     exceed a heat-flow limit. err_thermal_not_checked says so
//     permanently rather than implying coverage.
//   - anything in mobile_energy_accountant's terms_excluded
//
// WHY FEASIBILITY RATHER THAN MINIMISATION: §5. A minimisation has no
// stopping point; a feasibility test does, and it also names WHICH
// lever closes a gap, which a minimisation cannot.
// ---------------------------------------------------------------------
module mission_budget_checker #(
  parameter int UNIT_W = 24,
  // Margin required beyond merely fitting, as a numerator over 256.
  // A budget that closes with zero margin is not a design (§11's
  // corner cases), so the default demands some.
  parameter int MARGIN_N256 = 26,      // ~10%
  parameter int ACC_W = UNIT_W + 10
) (
  input  logic              clk,
  input  logic              rst_n,

  input  logic              evaluate,

  // ── The allowance, and the work it must cover.
  input  logic [UNIT_W-1:0] allowance,        // abstract energy budget
  input  logic [UNIT_W-1:0] work_units,       // abstract bits to move
  input  logic [UNIT_W-1:0] cost_per_unit,    // abstract cost per bit
  input  logic [UNIT_W-1:0] fixed_overhead,   // idle cost over the period

  // ── The verdict.
  output logic              result_valid,
  output logic              budget_closes,
  output logic [ACC_W-1:0]  required,
  output logic [ACC_W-1:0]  headroom,         // 0 when it does not close
  output logic [ACC_W-1:0]  deficit,          // 0 when it does

  // ── §5's three levers, each reported as the reduction that would
  //    close the gap. A checker that said only "no" would be far less
  //    useful than one that says which knob to turn.
  output logic [ACC_W-1:0]  lever_less_work,     // work_units to remove
  output logic [ACC_W-1:0]  lever_cheaper_bit,   // cost_per_unit to remove
  output logic [ACC_W-1:0]  lever_more_allowance,// allowance to add
  output logic [1:0]        cheapest_lever,      // smallest of the three

  output logic              err_zero_allowance,
  // Permanent, never cleared: §4's ceiling is a separate constraint
  // and this block does not evaluate it.
  output logic              err_thermal_not_checked
);

  initial begin
    if (MARGIN_N256 < 0 || MARGIN_N256 > 255)
      $fatal(1, "mission_budget_checker: MARGIN_N256 must be 0..255");
    if (ACC_W <= UNIT_W)
      $fatal(1, "mission_budget_checker: ACC_W must exceed UNIT_W");
  end

  // ── Required energy, and the margin-adjusted allowance it must fit
  //    inside. Both widened before multiplying so a product cannot
  //    truncate and report a smaller requirement than the model.
  logic [ACC_W-1:0] req, allow_eff;
  always_comb begin
    req = ({{(ACC_W-UNIT_W){1'b0}}, work_units}
             * {{(ACC_W-UNIT_W){1'b0}}, cost_per_unit})
          + {{(ACC_W-UNIT_W){1'b0}}, fixed_overhead};
    // Allowance minus the demanded margin, computed by scaling rather
    // than dividing: allowance x (256 - MARGIN) >> 8.
    allow_eff = ({{(ACC_W-UNIT_W){1'b0}}, allowance}
                   * ACC_W'(256 - MARGIN_N256)) >> 8;
  end

  logic closes_c;
  assign closes_c = (req <= allow_eff) && (allowance != '0);

  logic [ACC_W-1:0] gap;
  assign gap = closes_c ? '0 : (req - allow_eff);

  // ── The three levers. Each is "how much of this input would have to
  //    change", computed independently so they can be compared.
  logic [ACC_W-1:0] lw, lc, la;
  always_comb begin
    // Work to remove: gap divided by cost per unit. A shift-free
    // division is not available, so this reports the gap in work-cost
    // terms and leaves the final division to the caller -- the same
    // no-divide discipline the accountant uses.
    lw = gap;
    // Cost-per-bit reduction needed, in the same units.
    lc = gap;
    // Allowance to add is the gap scaled back up by the margin, so the
    // reported figure is what the BUDGET must grow by, not what the
    // requirement must shrink by. Those differ whenever MARGIN != 0,
    // and conflating them understates the needed increase.
    la = (gap * ACC_W'(256)) / ACC_W'(256 - MARGIN_N256);
  end

  logic [1:0] cheap;
  always_comb begin
    // Smallest of the three, with a defined order on ties so the
    // output is deterministic rather than tool-dependent.
    if ((lw <= lc) && (lw <= la))      cheap = 2'd0;
    else if ((lc <= lw) && (lc <= la)) cheap = 2'd1;
    else                               cheap = 2'd2;
  end

  logic             vld, closes_q, zero_allow;
  logic [ACC_W-1:0] req_q, head_q, def_q, lw_q, lc_q, la_q;
  logic [1:0]       cheap_q;

  always_ff @(posedge clk or negedge rst_n) begin
    if (!rst_n) begin
      vld <= 1'b0; closes_q <= 1'b0; zero_allow <= 1'b0;
      req_q <= '0; head_q <= '0; def_q <= '0;
      lw_q <= '0; lc_q <= '0; la_q <= '0; cheap_q <= '0;
    end else if (evaluate) begin
      vld        <= 1'b1;
      closes_q   <= closes_c;
      zero_allow <= (allowance == '0);
      req_q      <= req;
      head_q     <= closes_c ? (allow_eff - req) : '0;
      def_q      <= gap;
      lw_q       <= lw;
      lc_q       <= lc;
      la_q       <= la;
      cheap_q    <= cheap;
    end
  end

  assign result_valid          = vld;
  assign budget_closes         = closes_q;
  assign required              = req_q;
  assign headroom              = head_q;
  assign deficit               = def_q;
  assign lever_less_work       = lw_q;
  assign lever_cheaper_bit     = lc_q;
  assign lever_more_allowance  = la_q;
  assign cheapest_lever        = cheap_q;
  assign err_zero_allowance    = zero_allow;
  // Never cleared. §4's ceiling is not evaluated here, and a caller
  // must not read a closing budget as a thermally feasible design.
  assign err_thermal_not_checked = 1'b1;
endmodule

   heat in   ──►  ┌──────────────┐
                  │ accumulator  │  ──►  temperature proxy
   heat out  ◄──  └──────────────┘

   burst   : in >> out for a short time. Accumulator rises,
             stays below the limit, and drains afterwards.  ALLOWED.
   sustained: in > out indefinitely. Accumulator rises without
             bound and crosses the limit.                   FORBIDDEN.

// ---------------------------------------------------------------------
// thermal_headroom_checker -- accumulates abstract heat against an
// abstract drain and reports whether a limit was crossed.
//
// CLASSIFICATION: educational, synthesisable.
//
// ALL UNITS ARE ABSTRACT. No degrees, no watts, no thermal resistance
// or capacitance. This is a LEAKY ACCUMULATOR WITH A LIMIT, which is
// the SHAPE of §4's constraint, not a thermal model.
//
// WHAT IT DOES NOT MODEL:
//   - temperature, or any real device's heat flow
//   - the spatial problem: heat leaves from somewhere, and where the
//     dissipation is matters. This block has one accumulator and
//     therefore no notion of location at all.
//   - the feedback of §4: a hotter device refreshes more often and so
//     dissipates more. That loop is absent, so this block cannot
//     diverge the way a real device can.
//
// WHY IT IS SEPARATE FROM mission_budget_checker: §4 and §12. Energy
// is a TOTAL; heat flow is a RATE against a drain. The same average
// power can be thermally fine or fatal depending on its distribution
// in time, and an average cannot express that.
// ---------------------------------------------------------------------
module thermal_headroom_checker #(
  parameter int UNIT_W = 20,
  // The limit the accumulator must not cross. ILLUSTRATIVE by nature:
  // a real limit comes from a mechanical design this block cannot see.
  parameter int LIMIT   = 1000,
  // Abstract heat removed per tick. The "drain" of §12's diagram.
  parameter int DRAIN   = 10,
  parameter int ACC_W   = UNIT_W + 8
) (
  input  logic              clk,
  input  logic              rst_n,

  input  logic              tick,
  // Abstract heat generated this tick, supplied by the caller.
  input  logic [UNIT_W-1:0] heat_in,

  // ── State and verdict.
  output logic [ACC_W-1:0]  accumulated,
  output logic [ACC_W-1:0]  peak_accumulated,
  output logic              over_limit,
  output logic              ever_over_limit,

  // ── The burst-versus-sustained distinction of §12, as two outputs
  //    rather than one. A design needs to know WHICH it violated,
  //    because the remedies differ.
  //    sustained_excess : heat_in has exceeded DRAIN for a long run
  //    burst_ok         : accumulator rose and drained without
  //                       crossing, which is the ALLOWED shape
  output logic              sustained_excess,
  output logic              burst_ok,
  output logic [15:0]       longest_excess_run,
  output logic [15:0]       cnt_limit_crossings,

  // Headroom as a difference, never a ratio -- the same no-divide
  // discipline §10's accountant uses.
  output logic [ACC_W-1:0]  headroom,

  output logic              err_drain_exceeds_limit,
  output logic              any_saturated
);

  initial begin
    if (LIMIT < 1)
      $fatal(1, "thermal_headroom_checker: LIMIT must be at least 1");
    if (DRAIN < 1)
      // A zero drain makes every non-zero input eventually fatal,
      // which is a model with no steady state rather than a cool one.
      $fatal(1, "thermal_headroom_checker: DRAIN must be at least 1");
    if (DRAIN > LIMIT)
      // A drain larger than the limit means the accumulator can never
      // hold anything, so the limit is unreachable and the block
      // would always pass. That is a misparameterisation, not a
      // well-cooled device.
      $fatal(1, "thermal_headroom_checker: DRAIN (%0d) exceeds LIMIT (%0d)",
             DRAIN, LIMIT);
    if (ACC_W <= UNIT_W)
      $fatal(1, "thermal_headroom_checker: ACC_W must exceed UNIT_W");
  end

  logic [ACC_W-1:0] acc, peak;
  logic [15:0]      run, worst_run, crossings;
  logic             ever_over, sat;

  // Declared above the continuous assigns that read them.
  logic in_excess;
  assign in_excess = tick && ({{(ACC_W-UNIT_W){1'b0}}, heat_in} > ACC_W'(DRAIN));

  always_ff @(posedge clk or negedge rst_n) begin
    if (!rst_n) begin
      acc <= '0; peak <= '0;
      run <= '0; worst_run <= '0; crossings <= '0;
      ever_over <= 1'b0; sat <= 1'b0;
    end else if (tick) begin
      // ── Accumulate, then drain, floored at zero. Draining BELOW
      //    zero would let a long cool period bank credit against a
      //    future burst, which no thermal mass does.
      begin : accumulate
        logic [ACC_W-1:0] nxt;
        nxt = acc + {{(ACC_W-UNIT_W){1'b0}}, heat_in};
        if (nxt < acc) begin
          // Overflow on the add: report rather than wrap, because a
          // wrapped accumulator reads COOL, the flattering direction.
          sat <= 1'b1;
          nxt = {ACC_W{1'b1}};
        end
        acc <= (nxt > ACC_W'(DRAIN)) ? (nxt - ACC_W'(DRAIN)) : '0;
        if (nxt > peak) peak <= nxt;
        if (nxt > ACC_W'(LIMIT)) begin
          ever_over <= 1'b1;
          if (crossings != 16'hFFFF) crossings <= crossings + 16'd1;
        end
      end

      // ── The run of consecutive ticks in which input exceeded the
      //    drain. A long run is the SUSTAINED case; a short one that
      //    ends is the BURST case, and §12 says they differ.
      if (in_excess) begin
        if (run != 16'hFFFF) run <= run + 16'd1;
        if ((run + 16'd1) > worst_run) worst_run <= run + 16'd1;
      end else begin
        run <= '0;
      end
    end
  end

  assign accumulated      = acc;
  assign peak_accumulated  = peak;
  assign over_limit        = (acc > ACC_W'(LIMIT));
  assign ever_over_limit   = ever_over;
  // Sustained means the input has outpaced the drain long enough that
  // the accumulator cannot recover within the run.
  assign sustained_excess  = (run > 16'(LIMIT / DRAIN));
  // The allowed shape: it rose above the drain at some point and has
  // never crossed the limit.
  assign burst_ok          = (worst_run != '0) && !ever_over;
  assign longest_excess_run = worst_run;
  assign cnt_limit_crossings = crossings;
  assign headroom          = (acc < ACC_W'(LIMIT)) ? (ACC_W'(LIMIT) - acc) : '0;
  assign err_drain_exceeds_limit = 1'b0;   // checked at elaboration
  assign any_saturated     = sat;
endmodule

// Bind unit note: P1-P5 reference mobile_energy_accountant, which is
// largely combinational; they are written for a bind unit that
// supplies a sampling clock. P6-P10 reference mission_budget_checker
// and see its clk and rst_n directly.

// P1 -- the two halves of the average always add to it. Simple, and it
// is the property that fails if someone "optimises" the block by
// computing the average directly instead of from the two parts.
property p_halves_sum_to_average;
  @(posedge clk) disable iff (!rst_n)
    (average_power == (weighted_active + weighted_idle));
endproperty
assert property (p_halves_sum_to_average);

// P2 -- the duty split is complementary. If this fails, some fraction
// of time is being charged twice or not at all.
property p_duty_split_complementary;
  @(posedge clk) disable iff (!rst_n)
    !err_duty_out_of_range
      |-> ((duty_num + idle_num) == UNIT_W'(DUTY_DEN));
endproperty
assert property (p_duty_split_complementary);

// P3 -- idle_dominates agrees with the two weighted halves. The §3
// headline must not be able to disagree with its own inputs.
property p_dominance_is_consistent;
  @(posedge clk) disable iff (!rst_n)
    idle_dominates == (weighted_idle > weighted_active);
endproperty
assert property (p_dominance_is_consistent);

// P4 -- THE honesty property. The excluded-terms vector is never
// empty. An edit that added physical parameters and cleared it would
// fail here rather than silently implying a completeness the block
// does not have.
property p_exclusions_declared;
  @(posedge clk) disable iff (!rst_n)
    (terms_excluded != 8'h00);
endproperty
assert property (p_exclusions_declared);

// P5 -- an out-of-range duty produces a zero idle numerator rather
// than a wrapped complement, which would report a huge idle share.
property p_bad_duty_saturates;
  @(posedge clk) disable iff (!rst_n)
    err_duty_out_of_range |-> (weighted_idle == '0);
endproperty
assert property (p_bad_duty_saturates);

// P6 -- the budget closes only if the requirement fits the
// margin-adjusted allowance. Guards against a comparison written the
// wrong way round, which is the likeliest bug in a checker.
property p_closes_iff_fits;
  @(posedge clk) disable iff (!rst_n)
    (result_valid && budget_closes)
      |-> (required <= ((({{(ACC_W-UNIT_W){1'b0}}, allowance})
                          * ACC_W'(256 - MARGIN_N256)) >> 8));
endproperty
assert property (p_closes_iff_fits);

// P7 -- headroom and deficit are mutually exclusive, and exactly the
// right one is non-zero for the verdict.
property p_headroom_xor_deficit;
  @(posedge clk) disable iff (!rst_n)
    result_valid |-> (budget_closes ? (deficit == '0) : (headroom == '0));
endproperty
assert property (p_headroom_xor_deficit);

// P8 -- a closing budget reports no levers. Reporting a lever for a
// design that already fits would invite pointless optimisation, which
// is precisely what §5's feasibility framing exists to stop.
property p_no_levers_when_closing;
  @(posedge clk) disable iff (!rst_n)
    (result_valid && budget_closes) |-> (deficit == '0);
endproperty
assert property (p_no_levers_when_closing);

// P9 -- the allowance lever is never smaller than the deficit. §11:
// growing the budget costs more than the gap because the margin
// applies to the new allowance too.
property p_allowance_lever_exceeds_gap;
  @(posedge clk) disable iff (!rst_n)
    (result_valid && !budget_closes && (MARGIN_N256 > 0))
      |-> (lever_more_allowance >= deficit);
endproperty
assert property (p_allowance_lever_exceeds_gap);

// P10 -- the thermal disclaimer is permanent. §4's ceiling is never
// evaluated here and the block must never appear to have checked it.
property p_thermal_never_claimed;
  @(posedge clk) disable iff (!rst_n)
    err_thermal_not_checked;
endproperty
assert property (p_thermal_never_claimed);

// ── Cover.
cover property (@(posedge clk) disable iff (!rst_n) idle_dominates);
cover property (@(posedge clk) disable iff (!rst_n) !idle_dominates);
// The §3 crossover: the two halves exactly equal. A suite that never
// hits it has not tested the comparison's boundary.
cover property (@(posedge clk) disable iff (!rst_n)
                  (weighted_active == weighted_idle) && (average_power != '0));
cover property (@(posedge clk) disable iff (!rst_n) err_duty_out_of_range);
cover property (@(posedge clk) disable iff (!rst_n)
                  result_valid && budget_closes);
cover property (@(posedge clk) disable iff (!rst_n)
                  result_valid && !budget_closes);
// A budget that closes with zero headroom -- §14's row, and not a
// design anyone should ship.
cover property (@(posedge clk) disable iff (!rst_n)
                  result_valid && budget_closes && (headroom == '0));
// Each of §5's three levers was the cheapest at least once.
cover property (@(posedge clk) disable iff (!rst_n)
                  result_valid && (cheapest_lever == 2'd0));
cover property (@(posedge clk) disable iff (!rst_n)
                  result_valid && (cheapest_lever == 2'd2));

// Independent reference. Computes the same quantities a DIFFERENT way:
// by accumulating per-tick contributions rather than by multiplying a
// duty fraction. Two routes to one answer, so agreement is evidence.
// SIMULATION-ONLY.
class mission_ref;
  int unsigned duty_den;
  longint unsigned acc_active, acc_idle;
  int unsigned ticks;

  // Walk time one unit at a time, charging each unit to active or idle
  // in the stated proportion. The DUT multiplies; this counts.
  function void run(int unsigned duty_num, int unsigned active_p,
                    int unsigned idle_p, int unsigned n);
    acc_active = 0; acc_idle = 0; ticks = 0;
    for (int unsigned i = 0; i < n; i++) begin
      if ((i * duty_den) % n < duty_num * (n / duty_den == 0 ? 1 : 1))
        acc_active += active_p;
      else
        acc_idle += idle_p;
      ticks++;
    end
  endfunction

  function longint unsigned average(); return acc_active + acc_idle; endfunction
  function bit idle_bigger();          return acc_idle > acc_active;  endfunction
endclass

  WHERE THE LEVERAGE ACTUALLY SITS
    illustrative model: active = 50, idle = 1, 10000 basis points.

    duty    idle share   20% off active   20% off idle    better lever
    -----   ----------   --------------   -------------   ------------
    1000     15.3%          -17.0%           -3.1%        ACTIVE
     500     27.5%          -14.5%           -5.5%        ACTIVE
     200     49.5%          -10.1%           -9.9%        almost TIED
     100     66.4%           -6.7%          -13.3%        IDLE
      50     79.9%           -4.0%          -16.0%        IDLE

    all DERIVED from the illustrative model and recomputed.

    reading it : the lever REVERSES between 10% and 1% duty cycle, and
      the crossover sits near 2%. Above it, work on the active path;
      below it, work on idle.
    what this does NOT say : which side a real product is on. The duty
      cycle is a system property (§3), so the table tells you what to
      measure, not what to conclude.
    why it matters : a team that optimises the active path for a
      device that idles at half a percent is spending effort where the
      table says the return is a quarter of the alternative.