diff --git a/hw/ip/rv_dm/dv/cov/rv_dm_cov_excl.el b/hw/ip/rv_dm/dv/cov/rv_dm_cov_excl.el
index 0f950cf5f7316..2851c854ce6f3 100644
--- a/hw/ip/rv_dm/dv/cov/rv_dm_cov_excl.el
+++ b/hw/ip/rv_dm/dv/cov/rv_dm_cov_excl.el
@@ -25,6 +25,24 @@ State DMIOPFailed "2"
 Transition DMINoError->DMIOPFailed "0->2"
 Transition DMIOPFailed->DMINoError "2->0"
 
+// In tlul_lc_gate, there is an FSM state called StFlush. The intention is that when the gate is
+// open (in state StActive), a flush request causes us to go into the StFlush state, where we block
+// commands. The u_tlul_lc_gate_sba instance has the flush_req_i input wired to zero but UNR doesn't
+// mark the StFlush state as unreachable. We could get there by disabling and enabling debug on two
+// consecutive cycles (going through states StActive, StOutstanding, StFlush, StActive). Disabling
+// debug a second time on the third cycle would replace the last state (StActive) with StError.
+//
+// While this sequence is theoretically possible, the "glitchy" transition between StActive and
+// StError doesn't really correspond to something we expect to see. We're testing this state and its
+// transitions for other instances of the module (where flush_req_i is not always zero), so we don't
+// have any risk of a bug in the module not being seen.
+INSTANCE: tb.dut.u_tlul_lc_gate_sba
+Fsm state_q "3443824386"
+State StFlush "76"
+Transition StFlush->StActive "76->289"
+Transition StFlush->StError "76->186"
+Transition StOutstanding->StFlush "231->76"
+
 // The following exclusions were generated by UNR.
 //
 //==================================================