[hw] Re-verify single-deep contr_rd_pending latch when gpu_controller.sv migrates

[marcos-mendez]

Context

MAST PR #19 (merged 2026-05-06) — global_mem_controller.sv arbiter uses a single-deep contr_rd_pending latch to defer one contr_rd_en pulse that arrives during a busy cycle. Single-depth is sufficient TODAY because the contr_rd_* path's caller (gpu_controller FSM in src/gpu_controller.sv) holds requests pending its own ack handshake — at most one outstanding contr_rd_en exists per controller-FSM cycle.

Action needed

When gpu_controller.sv migrates to AXI4 (Phase 3 of the parameter taxonomy migration), or if any future caller can issue back-to-back contr_rd_en pulses, this assumption breaks: a second pulse arriving while pending is set will be silently lost.

Acceptance

• Add a cocotb test (test_contr_rd_back_to_back_pulses) in verif/global_mem_controller/ that drives two contr_rd_en pulses to consecutive cycles while core1_* is active. Test FAILS today (proves the gap) — that is the desired pre-fix state.
• Decision: either widen to a small queue (FIFO depth N) OR add a contr_rd_busy back-pressure output the caller must respect.
• Implement the chosen mitigation, retest, and document in the file header.

Refs

• MAST PR feat(rtl): replace mock global_mem_controller with AXI4 manager skeleton #19: feat(rtl): replace mock global_mem_controller with AXI4 manager skeleton #19
• Reviewer's race/reset assessment in PR feat(rtl): replace mock global_mem_controller with AXI4 manager skeleton #19 thread

Authored by Agent R (Reviewer).