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

[aes,dv] Randomly drive invalid operation values to fix coverage hole #20941

Closed
vogelpi opened this issue Jan 23, 2024 · 2 comments · Fixed by #24623
Closed

[aes,dv] Randomly drive invalid operation values to fix coverage hole #20941

vogelpi opened this issue Jan 23, 2024 · 2 comments · Fixed by #24623
Assignees
Labels
Component:DV DV issue: testbench, test case, etc. IP:aes Milestone:V3

Comments

@vogelpi
Copy link
Contributor

vogelpi commented Jan 23, 2024

Description

Fixing #20753 (erroneous covergroup sampling function declaration) revealed that there has been coverage hole in AES DV: we were not driving invalid operation values and thus not testing the inherent resolution to the encryption mode in case of an invalid value.

I am not worried at all about this, the logic is super simple an very similar to other config fields where we check the resolution and also have coverage. But we still should solve this for M5.

@vogelpi vogelpi added Component:DV DV issue: testbench, test case, etc. IP:aes labels Jan 23, 2024
@vogelpi vogelpi added this to the Earlgrey-PROD.M5 milestone Jan 23, 2024
@vogelpi vogelpi self-assigned this Jan 23, 2024
This was referenced Feb 22, 2024
@andreaskurth
Copy link
Contributor

After discussing with @vogelpi, we're deferring this to V3 / M7 because it's about completing coverage under invalid operation

vogelpi added a commit to vogelpi/opentitan that referenced this issue Sep 23, 2024
This commit properly randomizes the operation values to fix a coverage
hole. Previously, the operation field of the main control register
was only written with valid one-hot encoded values but not with invalid
values leading to a small DV coverage hole.

This resolves lowRISC#20941.

Signed-off-by: Pirmin Vogel <vogelpi@lowrisc.org>
@vogelpi
Copy link
Contributor Author

vogelpi commented Sep 23, 2024

The PR closing this is now here: #24623.

vogelpi added a commit to vogelpi/opentitan that referenced this issue Sep 23, 2024
This commit properly randomizes the operation values to fix a coverage
hole. Previously, the operation field of the main control register
was only written with valid one-hot encoded values but not with invalid
values leading to a small DV coverage hole.

This resolves lowRISC#20941.

Signed-off-by: Pirmin Vogel <vogelpi@lowrisc.org>
vogelpi added a commit to vogelpi/opentitan that referenced this issue Sep 23, 2024
This commit properly randomizes the operation values to fix a coverage
hole. Previously, the operation field of the main control register
was only written with valid one-hot encoded values but not with invalid
values leading to a small DV coverage hole.

This resolves lowRISC#20941.

Signed-off-by: Pirmin Vogel <vogelpi@lowrisc.org>
vogelpi added a commit to vogelpi/opentitan that referenced this issue Sep 25, 2024
This commit properly randomizes the operation values to fix a coverage
hole. Previously, the operation field of the main control register
was only written with valid one-hot encoded values but not with invalid
values leading to a small DV coverage hole.

This resolves lowRISC#20941.

Signed-off-by: Pirmin Vogel <vogelpi@lowrisc.org>
vogelpi added a commit that referenced this issue Sep 25, 2024
This commit properly randomizes the operation values to fix a coverage
hole. Previously, the operation field of the main control register
was only written with valid one-hot encoded values but not with invalid
values leading to a small DV coverage hole.

This resolves #20941.

Signed-off-by: Pirmin Vogel <vogelpi@lowrisc.org>
venkatk-ot pushed a commit to venkatk-ot/opentitan that referenced this issue Oct 1, 2024
This commit properly randomizes the operation values to fix a coverage
hole. Previously, the operation field of the main control register
was only written with valid one-hot encoded values but not with invalid
values leading to a small DV coverage hole.

This resolves lowRISC#20941.

Signed-off-by: Pirmin Vogel <vogelpi@lowrisc.org>
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:aes Milestone:V3
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants