Fix CBO load hazard granularity

[124107157-KV]

• I have searched for similar pull requests
• I am a human engaging in an interpersonal interaction. During this interaction, my words are my own and are not generated. If relevant, I provide links to my sources.

Why is this PR needed?

The store-buffer hazard check currently treats all pending store-buffer
entries at the existing 8-byte address granularity using address bits
[11:3].

This is sufficient for ordinary stores, but it is too fine-grained for
CBO.INVAL, CBO.CLEAN, and CBO.FLUSH. These operations affect an entire
cache block.

As a result, when a CBO is pending for one address, a younger load to a
different 8-byte word within the same cache block can fail the existing
[11:3] comparison and issue before the CBO has completed.

For example, with a 16-byte cache block:

• CBO at 0x1000
• load at 0x1008

The addresses differ in bit 3, so the previous [11:3] comparison does
not detect a hazard even though both accesses belong to the same cache
block.

This is the behavior reported in #3432.

What does this PR change?

Add a CBO-aware store-buffer address-matching helper.

For ordinary stores, the existing behavior is preserved:

load_page_offset[11:3] == store_address[11:3]

For cache-block operations, the comparison instead uses the configured
D-cache block granularity:

load_page_offset[11:CVA6Cfg.DCACHE_OFFSET_WIDTH] ==
    cbo_address[11:CVA6Cfg.DCACHE_OFFSET_WIDTH]

The CBO-aware comparison is applied consistently to all three places
examined by the store-buffer hazard logic:

• committed queue entries
• speculative queue entries
• the entry currently being inserted

This keeps ordinary-store behavior unchanged while ensuring that a
younger load to any word in the same cache block stalls while
CBO.INVAL, CBO.CLEAN, or CBO.FLUSH is pending.

Regression test

Add store_buffer_cbo_hazard_test.sv together with a unit-test
Makefile target.

The regression checks ordinary stores as well as CBO.INVAL,
CBO.CLEAN, and CBO.FLUSH.

For each operation it checks the relevant store-buffer locations:

• current/incoming entry
• speculative queue
• commit queue

The address cases include:

• same address
• different 8-byte word in the same cache block
• address in the next cache block

The ordinary-store cases also verify that the existing 8-byte hazard
granularity is preserved and is not unnecessarily widened to the whole
cache block.

Verification

The CBO-enabled CVA6 target successfully elaborates with the change:

make verilate target=cv64a6_imafdc_sv39_hpdcache_wb

The focused regression passes with the fix:

make -C verif/tb/unit store_buffer_cbo_hazard_test

Result:

PASS: store-buffer CBO load hazard regression

The same regression was also run against the original upstream
store_buffer.sv. It fails on the reported case:

CBO.INVAL/current entry, different word in same block:
expected page_offset_matches=1, got 0

Restoring the patched RTL makes the regression pass again.

The final changes also pass:

git diff --check

Limitations

The focused unit test uses the CBO-enabled
cv64a6_imafdc_sv39_hpdcache_wb configuration, which has a 16-byte
D-cache block.

The RTL change itself does not hard-code that block size. It uses
CVA6Cfg.DCACHE_OFFSET_WIDTH, so the hazard comparison follows the
configured D-cache block granularity.

Fixes #3432