Zero-delay combinatorial loop between backend and cache (Iteration limit reached in Vivado XSIM)

[filmil]

Describe the bug

When simulating the Muntjac core using an event-driven simulator like Vivado XSIM, the simulation fails immediately at $t=0$ with a fatal iteration limit error: Fatal Error: Iteration limit reached. Possible zero delay oscillation detected where simulation time can not advance.

This is caused by a circular combinatorial dependency violating standard valid/ready handshake rules: the backend's req_valid signal combinationally depends on the cache's req_ready signal, but the cache's req_ready signal combinationally depends on req_valid through its internal arbiter.

While cycle-based simulators like Verilator may mask this zero-delay loop, event-driven simulators (like XSIM) get stuck in an infinite evaluation loop within a single delta cycle.

Steps to Reproduce

1. Instantiate muntjac_core in a testbench.
2. Simulate using Vivado XSIM.
3. The simulator immediately aborts at time 0 ps with an iteration limit error.

Root Cause / Trace

The combinatorial loop can be traced as follows:

1. muntjac_backend.sv (Cache Ready blocks Request Valid):

• Line 1074: assign mem_ready = dcache_d2h_i.req_ready;
• Line 335: In the OP_MEM case of always_comb, if !mem_ready, struct_hazard is asserted: if (!mem_ready) struct_hazard = 1'b1;
• Line 407: ex_issue depends on !struct_hazard.
• Line 1058: dcache_h2d_o.req_valid is gated by ex_issue: assign dcache_h2d_o.req_valid = ex_issue && de_ex_decoded.op_type == OP_MEM;
  (Result: The backend waits for the cache to be ready before asserting valid).

2. muntjac_dcache.sv / muntjac_icache.sv (Request Valid drives Cache Ready):

• Line 330: wire req_valid = cache_h2d_i.req_valid;
• Line 2024: (and others) req_valid feeds into mem_a_valid_mult.
• Line 389-393: mem_a_valid_mult feeds into openip_round_robin_arbiter's request and enable ports.
• Line 407: The arbiter's grant output (mem_a_arb_grant) drives mem_a_selected (and ultimately mem_a_select).
• Line 419: mem_a_ready_mult[i] = mem_a_select[i] && mem_a_ready;
• Line 1248/1802+: mem_a_ready_mult combinationally drives cache_d2h_o.req_ready.
  (Result: The cache waits for a valid request to arbitrate before asserting ready).

[filmil]

Hi folks, this is something I stepped on while massaging the apparent xsim lockup using Gemini. Hence the possibly overly confident bug root cause description in the preceding comment. I did check the part in muntjac_backend.sv and the claim seems plausible in that there is indeed a combinatorial path there. But, of course, since it's a conditional path, it might end up being inconsequential. Still, it seems like a potential issue for the handshake protocol.

I'll continue poking at this to see if there's actual substance but thought that maybe reporting early could be useful.

[nbdd0121]

The ready-on-valid dependency in muntjac_dcache.sv is a false one, because the ready signal does not actually depend on valid. However it is true that syntactically the ready signal is sensitive to valid signal. For tools that I've used (Verilator/Questa Sim/Model Sim/Vivado Synthesizer/Synopsys Synplify), they all seem to be able to handle that.

Event driven simulator could handle it by loops until values converge, but I guess Vivado XSIM isn't actually checking if values have actually changed.

Breaking the ready signal part to a separate always_comb block should do the trick (duplicating the if and case conditions).

[filmil]

Do I understand correctly, then, that I might be the first to attempt to simulate muntjac under Vivado's xsim?

(As to why, I have a mixed language SoC and xsim is the only simulator I have which supports that. I'm looking into ModelSim or Questa licenses, but buying a license is more confusing than I expected.)

[nbdd0121]

I think I used it in very early days of Muntjac's development (before the multiplexer in the cache was added; in fact, perhaps before the cache is added at all). But when after the Verilator flow was set up I stopped using it.

Most people in industry use one of the commercial simulators, while open-source community typically just use Verilator. You might be in a niche scenario where you need VHDL so Verilator won't work :)

[filmil]

Thanks for letting me know. I'll check how to remove the issue.

[filmil]

Workaround: TCL add_force before run

We found a practical workaround for this issue when simulating with Vivado xsim. The delta cycle oscillation at time 0 can be broken by forcing key uninitialized registers to defined values via TCL before calling run.

Several registers in the pipeline use async reset (always_ff @(posedge clk or negedge rst_ni)) but have no SystemVerilog variable initialization (no = 0 after declaration). At time 0, no clock or reset edge has occurred, so these registers hold X. The always_comb blocks then evaluate with X inputs and create the non-converging delta cycle loop.

Minimum set of forces needed

# Force reset active and initialize the two critical registers
add_force /tb/uut/pipeline/frontend/resp_latched 0
add_force /tb/uut/pipeline/backend/de_ex_valid 0

run 1ns

(Adjust /tb/uut/ to match your testbench hierarchy.)

Affected registers

Signal	Module	Why it matters
resp_latched	muntjac_frontend	Feeds align_valid → align_ready → icache_h2d_o.req_valid
de_ex_valid	muntjac_backend	Gates fetch_ready_o = !de_ex_valid || de_ex_ready

Other registers without variable initialization (miss_state_q in icache, wb_state_q in dcache, valid in openip_regslice REVERSE mode) exist but didn't need forcing in our case — possibly optimized by xelab or not part of the feedback loop.

Notes

• set_value does not work — it doesn't trigger always_ff re-evaluation the way add_force does.
• xelab has no --initreg flag (unlike some other simulators).
• The proper fix would be adding variable initialization to these registers (e.g., logic resp_latched = 1'b0;), which wouldn't affect synthesis but would give event-driven simulators defined initial values.

[filmil]

The above, of course, is a finding from Claude. It seems to unwedge xsim indeed. Claude's approach was really masterful: it first ran the simulation for 0s to see which signals are available, then constructed a TCL simulation run script which listed critical signals and their values. From there it concluded that the issue was that some signals were 'X' even after reset.

From here, it somehow figured out the signals which are implicated, which to me seemed like magic. But then, it required help to figure out how to force values initially. This was needed because the reset clock value does not, in fact, trigger async reset @always_ff blocks to be re-evaluated in xsim. I suppose this is not an issue in Verilator which is a 2-value sim. With those changes, the sim continued to run as it was originally instructed.

Hope this is helpful for anyone who steps on this in the future.