ChippendaleMupp
commented
4 years ago +1 for improved SweRV verification
I am happy with the quality of the core as delivered from WD, but I have real concerns that anyone can modify SweRV without verifying that their code change hasn't either:
- broken the functionality (introducing a bug),
- reduced the performance (taking more clock cycles), or
- broken the timing (only achiving a slower clock rate)
So adding a coremark test would be great and would test the performance and a reasonable amound of the functionality.
We need to identify configuration combinations to be tested. (Most configs that are not the ones used by WD have got issues that need ironing out).
In a longer running test we should aim to test all forwarding paths and hit all hazard classes.
Are there any open source synth tools and libraries we can check timing against?
ZvonimirBandic
aprnath
wsnyder
I suggest that the SweRV repo add a "make benchmark", that runs a binary that e.g. runs CoreMark for about 30-60 seconds.
Background:
I'm using Cores-SweRV as part of the Verilator regressions, see https://github.com/verilator/verilator_ext_tests. This runs the SweRV repo's test, which is basically a hello world test. This is good to make sure that nothing simple is broken in the simulator (e.g. Verilator), or SweRV itself, and has found a few issues in both.
However, what is missing is a longer running SewRV test that can be used to benchmark the simulator, for both ensuring that the simulator does not introduce a performance bug, and as an experimental case for potential performance enhancements. I thus request a binary and "make benchmark" that would have a simulation runtime (as opposed to simulated time) in the 30-60 second range, with a tuneable number of iterations. Tuning the iterations shouldn't need to recompile the binary, as the toolchain needed to make an equivalent binary might not be easily reproducible.
What should be the longer running test? Ideally it should hit a good cross section of the CPU logic, with a somewhat realistic usage pattern (e.g. not just running reset a bunch of times). A great possibility would be the CPU is running a benchmark. If this longer running test was e.g. the core running the main loop of the coremark binary (https://github.com/eembc/coremark), this would add another benefit, namely allowing the core itself to be benchmarked as part of the same process. This would be useful for those experimenting on the core itself. This also would ensure that a reasonable amount of logic in the core is lighting up.
Thanks