Skip to content

Fix BIST val/dit comparison in gen_tag_macros (axi_llc_tag_store)#29

Open
gm-openchip wants to merge 1 commit into
pulp-platform:masterfrom
gm-openchip:master
Open

Fix BIST val/dit comparison in gen_tag_macros (axi_llc_tag_store)#29
gm-openchip wants to merge 1 commit into
pulp-platform:masterfrom
gm-openchip:master

Conversation

@gm-openchip

Copy link
Copy Markdown

The original code performed a bitwise XNOR between a temporary packed struct and ram_rdata, then re-sliced the result back into a tag_data_t struct:

    assign ram_compared = tag_data_t'{val: ..., dit: ..., tag: ...} ~^ ram_rdata;
    assign bist_res[i]  = ram_compared.val & ram_compared.dit & tag_equ[i];

Per IEEE 1800-2017, ~^ on packed structs operates on the flattened bit vector. Re-slicing the result into struct fields is valid but error-prone: for single-bit fields(val, dit), I observed that even though the compilation passes, the XNOR result was consistently 0 regardless of the actual values, confirmed in simulation (ram_rdata.val == bist_pattern.val == 1, but ram_compared.val == 0).
This was putting the LLC in SPM mode, as BIST was failing.

Replaced with explicit per-field comparisons:

  • tag: XNOR reduction on the tag field only, with an explicit mux on Bist vs Lookup
  • val, dit: == comparison directly on the relevant struct fields

Functionally equivalent for Lookup/Flush (tag_equ unchanged), fixes BIST result accumulation in axi_llc_tag_pattern_gen.

…mparison

Root cause: bitwise ~^ between a temporary tag_data_t struct and ram_rdata
produces a flattened XNOR result. Re-slicing it back into a packed struct
causes single-bit fields (val, dit) to read 0 regardless of actual values in some compilators (VCS + Simon).

Fix: drop ram_compared, replace with:
- tag: XNOR reduction with explicit Bist/Lookup mux on tag field
- val, dit: direct == comparison against bist_pattern

Affected signal: bist_res[i], which feeds axi_llc_tag_pattern_gen.
Lookup/Flush behavior unchanged (tag_equ unaffected).

Verified in simulation: ram_compared.val was 0 with both operands == 1.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant