chipsalliance / chipsalliance/rocket-chip
TinyConfig Fails Some AMO Tests
- Dominant language
- Scala
- Stars
- 3.9k
- Forks
- 1.3k
- Avg merge
- 5d 13m
- Merged PRs (30d)
- 1
Description
I was using TinyConfig to debug post-synthesis simulations and found that it was failing some tests. It turns out these are failing upstream for TinyConfig. They're not run on Travis, so I don't know how long they've been broken for.
````
[ FAILED ] output/rv32ua-p-amoadd_w.out (tohost = 669)
[ FAILED ] output/rv32ua-p-amoadd_w.out (exit code = 669)
[ FAILED ] output/rv32ua-p-amoand_w.out (tohost = 669)
[ FAILED ] output/rv32ua-p-amoand_w.out (exit code = 669)
[ FAILED ] output/rv32ua-p-amoor_w.out (tohost = 669)
[ FAILED ] output/rv32ua-p-amoor_w.out (exit code = 669)
[ FAILED ] output/rv32ua-p-amoxor_w.out (tohost = 669)
[ FAILED ] output/rv32ua-p-amoxor_w.out (exit code = 669)
[ FAILED ] output/rv32ua-p-amoswap_w.out (tohost = 669)
[ FAILED ] output/rv32ua-p-amoswap_w.out (exit code = 669)
````
Contributor guide
Research direction
Start by reproducing the listed rv32ua-p-amoadd_w.out, rv32ua-p-amoand_w.out, rv32ua-p-amoor_w.out, rv32ua-p-amoxor_w.out, and rv32ua-p-amoswap_w.out failures with TinyConfig. Compare their behavior with the upstream tests and determine the relevant failing subsystem; done means the AMO tests pass and the results are covered by the test workflow.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- scala
- Domain
- testing
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100