[dv/chip] LC_CTRL related chip level coverage

[cindychip]

• [ ] [cindy] lc_otp_vendor_test_i/o: Move to connectivity test, tied off in open source chip level test. ---> Check if block level checked output from CSR, check if connectivity is done in chip level. Block level check here: https://github.com/lowRISC/opentitan/blob/master/hw/ip/lc_ctrl/dv/env/lc_ctrl_scoreboard.sv#L163

• [ ] lc_otp_program_o.count/program: sparsely encoded. So some of the toggle values are unreachable. But since we are changing build-seeds to generate different encoding pattern, it is very hard to find the unreachables on the fly. Are we comfortable to exclude the entire outputs?

• [ ] otp_lc_data_i.state/count: same issue as above

• [x] [cindy] lc_otp_program_i.err: We have a testbench, but it only forces the value to be 1. Will fix it to release the force.

• [ ] kmac_data_i.error: No test currently cover this scenario. Test issue: https://github.com/lowRISC/opentitan/issues/16069

• [ ] [cindy] otp_manuf_state_i: design constant, other values can be excluded.

• [x] [cindy] hw_rev_o.chip_rev/chip_gen: design constant, can just check connectivity.

FYI @msfschaffner @sriyerg

[msfschaffner]

• Are we comfortable to exclude the entire outputs?

This should be OK since we are testing this with life cycle transition tests at the top-level.

[msfschaffner]

The remaining action items above only affect toggle coverage at the top-level. Since that is already above 90%, the suggestion is to move this issue to V3/M3.

CC @sriyerg

[sriyerg]

We decided to merge coverage across nightlies which will have different build constants, which is an M3 task.

[johngt]

Spoke with @vogelpi - unsure if we have time for this. Discuss later at triage meeting

[vogelpi]

Discussed in the triage meeting and agreed to place this in Backlog.

[vogelpi]

@moidx this would be a reason for collecting coverage over time.