[LSU] Store Queue newest metadata aliases different pages with the same offset

[YzhDDDing]

Summary

The Store Queue updates its same_addr_newest ownership metadata using only physical-address bits [11:4]. Stores to different pages with identical page offsets therefore alias and can clear ownership metadata for one another. A later load from the first address sees multiple real forwarding candidates but no newest-owner mask, causing a false multi-forward replay.

I independently reproduced this on current OpenC910 main, b91c90914c19f114d35c8f6b73408eb241ed847c, without modifying the RTL.

Reproducer

The exact assembly and VCD checker are available here:

https://gist.github.com/YzhDDDing/a7f5c540cb1aee6e6022a6cfac5cd50e

The two physical addresses differ in bit 12 but have identical bits [11:4]:

  li    x20, 0x00090100       # A
  li    x21, 0x00091100       # B: different page, same [11:4]

  sd    x0, 0(x20)
  sd    x0, 0(x21)
  fence

  li    x11, 0x111
  sd    x11, 0(x20)           # older A store
  li    x12, 0x222
  sd    x12, 0(x20)           # newest A store
  li    x13, 0x333
  sd    x13, 0(x21)           # unrelated B store
  ld    x14, 0(x20)           # must select the second A store

Build sq_same_offset_newest.S with smart_run/tests/lib/Makefile, using CPU_ARCH_FLAG_0=c910 CASENAME=sq_same_offset_newest FILE=sq_same_offset_newest, and run with VCD dumping:

python3 validate_sq_same_offset_newest.py test.vcd > result.json

Expected behavior

The B store must not change newest-owner metadata belonging to the A stores. The subsequent A load should identify the second A store as the unique newest same-address forwarding source without a multi-forward replay.

Observed behavior

The checker confirms A=0x90100, B=0x91100, addr_alias_bits_11_4_match=true, and addr_full_match=false.

At VCD time 16507, creation of the B store clears entry 0, whose full stored address is A:

previous_same_addr_newest = 0x3
current_same_addr_newest  = 0x2
new_store_addr            = 0x91100
cleared_entry_addr        = 0x90100

At times 16511-16512, the A load has:

sq_entry_fwd_req          = 0x3
sq_ld_dc_fwd_id           = 0x3
sq_ld_dc_fwd_multi        = 1
sq_ld_dc_fwd_multi_mask   = 0

Both forwarding entries have the full address A; there are no nonmatching forwarding entries. At times 16513-16514, ld_da_fwd_sq_multi_req=1 and ld_da_sq_fwd_multi_vld=1. The architectural value remains 0x222 and the self-check reports TEST PASS, but the metadata and replay behavior are incorrect.

RTL analysis

ct_lsu_sq_entry.v:1107 defines the ownership hit as:

assign sq_entry_addr_11to4_hit_st_dc =
    (sq_entry_addr0[11:4] == st_dc_addr0[11:4]);

That partial comparison drives both sq_entry_same_addr_newest_clr and sq_entry_st_dc_same_addr_newer. The resulting bit is used to create and select the newest forwarding owner in ct_lsu_sq.v and ct_lsu_sq.v:2932-2934.

Suggested fix direction

Use the full translated physical block identity (for example [PA_WIDTH-1:4], together with byte overlap) before destructively clearing or creating same-address ownership metadata. If the partial comparison is needed for timing, treat it only as an early candidate match and validate the full physical tag before committing the metadata update.

An assertion should ensure that a store at B cannot change an A entry's same_addr_newest bit when their full physical blocks differ.

Impact

The reproduced effect is incorrect SQ attribution and an unnecessary multi-forward replay. The supplied test does not show architectural data corruption.