[test-triage] `flash_ctrl_error_prog_type` flakey
- Dominant language
- SystemVerilog
- Stars
- 3.6k
- Forks
- 1.1k
- Avg merge
- 2d 22h
- Merged PRs (30d)
- 141
Description
### Hierarchy of regression failure
Block level
### Failure Description
`flash_ctrl_error_prog_type` has been partly timing-out regularly since around 21st August 2024 ([34b8fc33e3](https://github.com/lowrisc/opentitan/tree/34b8fc33e36b3ed2a32e6cd50b451a47f16b202d)).
e.g.:
```
Job timed out after 60 minutes
```
### Steps to Reproduce
- GitHub Revision: 25b1acbf68
- dvsim invocation command to reproduce the failure, inclusive of build and run seeds:
`util/dvsim/dvsim.py hw/ip_templates/flash_ctrl/dv/flash_ctrl_sim_cfg.hjson -i flash_ctrl_error_prog_type --build-seed 115096073277204595231937901342804627564470767004707790242822318429579153097636 --seed 102494197276331117854647828649867813498500803795535853914362770085625559508697`
### Tests with similar or related failures
Also mentioned in https://github.com/lowRISC/opentitan/issues/24425
Contributor guide
Research direction
Start with hw/ip_templates/flash_ctrl/dv/flash_ctrl_sim_cfg.hjson and the flash_ctrl_error_prog_type test. Run the supplied dvsim invocation at revision 25b1acbf68 with its build and run seeds, then compare the timeout with the related failures in issue #24425. Done means the recurring 60-minute timeout is explained and the test completes reliably.
Written by the indexing model from the issue text.
Assessment
- Domain
- embedded-iot, testing-qa
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100