Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[rv_dm,dv] Add a task that injects TL errors to the smoke sequence #24533

Merged
merged 1 commit into from
Oct 1, 2024

Conversation

rswarbrick
Copy link
Contributor

This is to fill a coverage hole, where the rom_intg_error signal is never seen going high in the coverage.

The signal does go high in the rv_dm_tl_intg_err test, but that test uses the "cover_reg_top" build_mode (in tl_access_tests.hjson). This build mode is intentionally configured not to collect coverage for anything but the TL-focused modules. This is done for VCS in cover_reg_top.cfg. The point is that if the block doesn't have a model against which we're checking, then the register tests might trigger weird behaviour that they don't notice. Therefore we shouldn't be tracking coverage of the non-TL-related signals for these tests, because they might not be testing the blocks that they exercise.

In the very specific case of TL integrity errors, it doesn't really matter: the only behaviour we expect is a fatal alert. This is tested by the register tests! But making it happen very occasionally in the smoke sequence is probably easier than reasoning about what coverage should be included in the existing generic tests. Do that.

This is to fill a coverage hole, where the rom_intg_error signal is
never seen going high in the coverage.

The signal *does* go high in the rv_dm_tl_intg_err test, but that test
uses the "cover_reg_top" build_mode (in tl_access_tests.hjson). This
build mode is intentionally configured not to collect coverage for
anything but the TL-focused modules. This is done for VCS in
cover_reg_top.cfg. The point is that if the block doesn't have a model
against which we're checking, then the register tests might trigger
weird behaviour that they don't notice. Therefore we shouldn't be
tracking coverage of the non-TL-related signals for these tests,
because they might not be testing the blocks that they exercise.

In the very specific case of TL integrity errors, it doesn't really
matter: the only behaviour we expect is a fatal alert. This *is*
tested by the register tests! But making it happen very occasionally
in the smoke sequence is probably easier than reasoning about what
coverage should be included in the existing generic tests. Do that.

Signed-off-by: Rupert Swarbrick <rswarbrick@lowrisc.org>
@rswarbrick rswarbrick added Component:DV DV issue: testbench, test case, etc. IP:rv_dm labels Sep 6, 2024
@rswarbrick rswarbrick requested a review from a team as a code owner September 6, 2024 17:31
@rswarbrick rswarbrick requested review from eshapira and removed request for a team September 6, 2024 17:31
@rswarbrick rswarbrick merged commit fa82c8f into lowRISC:master Oct 1, 2024
38 of 40 checks passed
@rswarbrick rswarbrick deleted the rv-dm-intg-error branch October 1, 2024 15:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Component:DV DV issue: testbench, test case, etc. IP:rv_dm
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants