[hw] Add core1_rd_data stable-cycle-after-ack regression test in calling module testbenches #22

Context

In MAST PR #19 (merged 2026-05-06), core1_rd_data in src/global_mem_controller.sv changed from output reg (registered) to output wire (combinational assign core1_rd_data = cm_rd_data). All upstream callers (gpu_die.sv, test/behav/compute_unit_and_mem.sv, test/behav/core_and_mem.sv) connect via plain wire assignments and the round-trip cocotb tests in PR #19 pass — so functionally OK today.

Concern

If any caller relies on core1_rd_data being stable for one cycle AFTER core1_ack, the new combinational drive may glitch when cm_rd_data changes (next AXI4 read result lands).

Action

Add a regression test in verif/gpu_die/ (or an integration testbench wherever core1_rd_data is consumed) that:

1. Issues a core1_rd_req and waits for core1_ack
2. On the cycle AFTER core1_ack, samples core1_rd_data
3. Asserts the sampled value matches the value driven during the ack cycle

Test should FAIL if a future PR reintroduces a downstream caller that expects post-ack stability without explicitly capturing the data.

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
• Review thread, real finding [hw] Replace mock global_mem_controller with AXI4 memory subsystem skeleton #2

Authored by Agent R (Reviewer).