[tonykorycki]

depends on #23

After PR #23, the limiting path ran through o_read_ready:

buffer compares -> shift-valid scan -> m_rd_rdy / h_rd_rdy -> o_read_ready -> user command vs pull/evict -> heap buffer decode -> shift-valid scan -> buffer register enables

The buffers' command-dependent control is now computed for both values of o_read_ready in parallel, and the real value
selects between them last. Readiness and decode run side by side instead of end to end. This is an exact rewrite (f(r) = r ? f(1) : f(0)), so behaviour is identical cycle for cycle.

xcau25p-1, 11 × 2047 trees	PR #23	This PR
Fmax, 128 bit (best of 3 placer directives)	110–115 MHz	125.0 MHz (met at 8.0 ns)
Fmax, 128 bit (sweep script)	101.3 met / best 111.0	102.3 met / best 120.3
Fmax, 16 bit (sweep script)	175 met / best 181.7	176.8 met at 175 / best 187.8
Cycles per enqueue / dequeue	3.34 / 4.59	3.34 / 4.59 (identical)
Operations per µs, enqueue / dequeue	~34 / ~25	~37.4 / ~27.2
CLB LUTs	81.1k	80.3k

Against the original design, that's 2.1x Fmax and 2.0–2.1x throughput at 128b .

Changes

hybrid_systolic_heap.sv:

• Pull and evict split into a state-only condition (pull_ok / evict_ok) and the command-dependent part
• A two-iteration loop computes, for each value of o_read_ready:
  • the per-buffer user/pull/evict choice;
  • the enqueue-forward and write-IB[0] decisions;
  • both 14-bit shift-valid scans.

o_read_ready then selects. Only narrow control is duplicated - 128-bit data and compares are computed once.

In the region slack table, the main->heap and heap->heap buffer paths go from about −1.0 ns to +0.1 ns at 125 MHz.

Notes

• The gain depends on the tool keeping the late select, which it did in every run. If Fmax falls back to about 115 MHz after a tool or setting change, check this first.
• The 11-way tree max is now the limiting path again (about −0.7 ns at 133 MHz).