[hankhsu1996]

I'm running RTLMeter on a 4-state simulator, and VeeR-EL2 takes more cycles there than on Verilator for the same program. dhry at one iteration retires the same 14,260 instructions in 17,532 cycles instead of 15,248, so the timings stop being comparable, even though the test still passes.

error_injection_mode is declared with no initial value, so on a 4-state simulator it starts as x.

rtlmeter/designs/VeeR-EL2/src/tb_top.sv

Line 525 in f63e557

tb_top_pkg::veer_sram_error_injection_mode_t error_injection_mode;

The DCCM injection block then never takes its "injection off" branch, so every DCCM write gets a bit flipped, and the core spends the extra cycles correcting them. On Verilator the mode starts at 0, so nothing is injected.

rtlmeter/designs/VeeR-EL2/src/tb_top.sv

Lines 1748 to 1756 in f63e557

	always_ff @(el2_mem_export.clk) begin : inject_dccm_ecc_error
	if (~error_injection_mode.dccm_single_bit_error && ~error_injection_mode.dccm_double_bit_error) begin
	dccm_wdata_bitflip <= '{default:0};
	end else if (el2_mem_export.dccm_clken & el2_mem_export.dccm_wren_bank) begin
	for (ii=0; ii<pt.DCCM_NUM_BANKS; ii++) begin: dccm_bitflip_injection_loop
	dccm_wdata_bitflip[ii] <= get_bitflip_mask(error_injection_mode.dccm_double_bit_error);
	end
	end
	end

Upstream VeeR-EL2 has since fixed this by resetting the mode to 0 (chipsalliance/Cores-VeeR-EL2@21c5e9b), after the revision this copy was taken from. This change gives it an initial value of 0 instead, which leaves Verilator's behaviour unchanged and makes the 4-state cycle counts match it. VeeR-EL2:default:hello, cmark and dhry still pass on Verilator.