Potential Logic Error in Flushed Register Update during FsmInitFlush (Line 453) : axi_llc_config module

[dongkouxiaochuan]

I have identified a potential logic error in the way the flushed status register is updated within the FsmInitFlush state of the axi_llc_config module. This issue seems to prevent the correct accumulation of the flushed status for non-SPM ways during a multi-way flush operation, which could cause the FSM to cycle incorrectly or fail to completely mark ways as flushed.The line in question is in proc_axi_llc_cfg (around Line 453):Verilog// Current code in FsmInitFlush:
conf_regs_o.flushed = conf_regs_i.cfg_spm & conf_regs_i.flushed;
Problem If a Way is not configured as SPM (i.e., conf_regs_i.cfg_spm is 0 for that bit), the AND logic forces the corresponding bit in conf_regs_o.flushed to 0.
If the FSM successfully flushed a non-SPM way (Way X) in a previous cycle and set flushed[X] = 1 in FsmEndFlush, this line will immediately reset flushed[X] to 0 when the FSM returns to FsmInitFlush. This effectively erases the "flushed" status before the entire operation is complete.This corrupted flushed status then leads to an incorrect calculation of the ways still needed to be flushed.
Since the flushed status is cleared prematurely, the to_flush_d signal will repeatedly select the same non-SPM way for flushing, potentially leading to an infinite or incorrect FSM loop.Suggested FixThe logic should be changed from the AND operation to the OR operation to ensure that all ways that were already flushed (either as persistent SPM ways or as ways completed in previous FSM cycles) maintain their flushed status:Verilog// Suggested fix for FsmInitFlush:
conf_regs_o.flushed = conf_regs_i.cfg_spm | conf_regs_i.flushed;
This change successfully resolved the issue in my simulation environment, allowing the FSM to correctly track and complete the full flush sequence.Thank you!