Open cindychip opened 1 year ago
- 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.
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
We decided to merge coverage across nightlies which will have different build constants, which is an M3 task.
Spoke with @vogelpi - unsure if we have time for this. Discuss later at triage meeting
Discussed in the triage meeting and agreed to place this in Backlog.
@moidx this would be a reason for collecting coverage over time.
[ ] [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