[rom_ctrl, dv] Removal of a signal to cover cond coverage hole

[KinzaQamar]

rom_ctrl coverage report shows a coverage hole for the conditional statement as 110 not covered. The description below explains why we can't cover the case counter_lnt and !kmac_rom_vld_o

Starting with counter_lnt = 1 means that we get the last address of a non top word. counter_lnt is delayed by a cycle through last_nontop_d in rom_ctrl_counter.sv.

Next is kmac_rom_vld_o which also delayed by a cycle through kmac_rom_vld_d. The kmac_rom_vld_d signal depends on counter_read_req which goes immediately high after reset. Then checker fsm state should be in state ReadingLow and
!counter_lnt meaning we haven't reached to the top.

Now assuming that we are out of reset, first request to the ROM has been sent, checker fsm is sending nontop data to KMAC and we still haven't reached to the top; makes kmac_rom_vld_d go high. But when we reach to the last address of the nontop data, we get counter_lnt go high and kmac_rom_vld_d go low. Since kmac_rom_vld_o delayed through kmac_rom_vld_d, we get counter_lnt with kmac_rom_vld_o.

[rswarbrick]

This looks right to me, and thanks for adding the assertion at the bottom.

@andreaskurth: would you mind taking a look? I think this has zero risk (especially because the first symptom of a mistake will be a test failure)

[rswarbrick]

CHANGE AUTHORIZED: hw/ip/rom_ctrl/rtl/rom_ctrl_fsm.sv

Carefully reasoned (and I agree with the logic!). And there's an assertion to make sure we find out if we made a mistake.