core-v-verif
core-v-verif copied to clipboard
openhwgroup
Improvements: Coverage
Use this issue to gather all ideas to improve or highlight long-term issues with any of the following:
- Code coverage
- Functional coverage methodology
- Functional coverage definitions
- Cover property methodology
Add comments for all ideas to this issue. Please try to refrain from deeper discussion of inidividual items. A separate issue should be opened to enable and record that discussion.
Use the common tracer or pipeline monitor as the source of data for the functional coverage model. This monitor report all instructions in an ISA-native format (I.e. the monitor should alleviate the need to translate pseudo-ops to ISA instructions in the current coverage model).
In each opcode's functional coverage model, add more intra-instruction crosses (I.e. combinations of register source, destination)
Add coverpoints to the model with each instruction type (based on pipeline units, architecture, latency) and cross those.
The team at SiLabs reported the following: functional coverage of operand on individual instructions is missing. For example, the coverage model itself had no idea if we actually did a negative_num times a negative_num operation.
The first iteration of our new coverage model will probably not have this info (fed from OBI) however the RVFI version absolutely could encapsulate and deliver the input operand values for each register into the instruction functional coverage. At that point it would not be difficult to define a few bins to ensure that operands are at the very least behind randomized with a reasonable distribution and that we are hitting some interesting extremes.
