# Ch422 — registered bilinear output boundary (prefit)

## Trigger

Ch421 closed the 310 MHz EMIF/request family at `+0.155 ns`, but its owner GUI
fit exposed a design-clock path from a captured bilinear tap through both lerp
levels, the texture output mux, TEX0 vertex modulation, and finally
`raster_pixel_color_q`.  The worst of ten identical-family paths had 30 logic
levels, 41.955 ns data delay, and `-1.993 ns` slack against the 40 ns clock.

## Root cause

`gs_texture_unit` already captured `tex_color_blend` into `tex_color_hold` while
leaving `BS_DONE`.  However, during that same `BS_DONE` cycle its external
`tex_color` selected the live combinational blend and `out_valid` asserted.
Consequently, the perspective palette-bilinear emit path could consume the
unregistered value and append four channel-modulation multipliers before the
`raster_pixel_color_q` register.  The intended hold register was present but
was bypassed at the only cycle that mattered for this caller.

## Structural cut

The bilinear FSM now has a distinct `BS_OUT` state after `BS_DONE`:

1. `BS_DONE` evaluates the unchanged two-stage bilinear math and captures it in
   `tex_color_hold`;
2. `BS_OUT` asserts `out_valid` and exposes only `tex_color_hold`;
3. the FSM then returns to `BS_IDLE`.

This adds one internal sampler cycle but changes no pixel arithmetic and no
external handshake.  Existing consumers already wait on `out_valid` or the
`busy` level, so their natural stalls absorb the cycle.  The former 30-level
tap-to-emit path is split at `tex_color_hold`: bilinear arithmetic ends there,
while TEX0 modulation starts from a register on the following cycle.

## Prefit verification

- standalone PSMCT32/PSMT8/PSMT4 bilinear suite: all 12 cases PASS;
- tile PSMCT32 bilinear integration: PASS;
- tile palette-bilinear integration: PASS;
- full 283-epoch production-control replay: PASS;
- 1,177,489 fragments fed, 984,845 passed Z, zero drops/errors;
- final Z mismatch `0 / 307,200`, color mismatch `0 / 235,963`;
- framebuffer SHA-256 remains exactly
  `a88f1f6c926dd0db2b72ae2873c399e7dc5666f8003190184c34d360b13a5f44`.

## Owner fit gate

Ready for one owner-controlled Quartus 26.1 GUI compile.  Acceptance requires:

- no `g_bilinear.tap[*] -> raster_pixel_color_q[*]` setup family;
- bilinear tap paths terminate at `tex_color_hold` and close at 25 MHz;
- the already-clean 310 MHz EMIF/request family remains non-negative;
- setup, hold, recovery, removal, and minimum pulse all close;
- RAM inference and device fit remain within the existing budget.

Do not deploy the timing-unclean Ch421 RBF.  Deploy and board-test Ch422 only if
the complete timing report is clean.

## Owner fit result

The owner-controlled Quartus 26.1 GUI fit confirmed that the Ch422 structural
cut worked.  The design clock closed at `+8.604 ns`, the reference clock closed
at `+7.564 ns`, and hold, recovery, removal, and minimum-pulse checks were
clean.  The former bilinear tap-to-`raster_pixel_color_q` family was absent.

The only remaining failure was the 310 MHz EMIF clock at WNS `-0.012 ns`, TNS
`-0.047 ns`, across six endpoints.  Five endpoints were color-align tuple data
register enables (`ca_wdata_q[21/24/25/28/30]|ena`) reached through
`ca_tail -> ca_full -> feed_ok`.  The sixth was
`req_stage_packet[79]|ena`, whose enable cone included the synchronized EMIF
calibration reset.  These are independent control-to-data-enable artifacts;
Ch423 removes both in one combined structural closeout.

Ch422 is therefore functionally verified and its intended timing family is
closed, but its RBF remains non-deployable because the complete fit was not
timing-clean.