val_comb cover points are not accounted in the coverage report - Issue on the eval

[ptprasanna]

https://github.com/riscv-software-src/riscv-isac/blob/b3f81efa81c0f02ae846c221ae2fe9142f5d7f1e/riscv_isac/coverage.py#L874

Issue Description: Pythons eval function takes the optional arguments as dictionary variable locals, which contains the local variables and it's values, which eventually be used to evaluate the expression that we are passing (in this context it is the cover point expression with the combination of sign, exponent and mantissa values) as referenced here. This cannot be replaced by an ordinary dictionary variable (instr_vars) with it's keys and values. Those keys and it's values are not considered as a variable and it's values, hence isac failed to evaluate the given cover-points, this resulted in ignoring the val_comb of the tests that we run.

Possible Solution: Fix for this issue is to have the local variable dictionaries passed as is (or a copy of it), and it should be incrementally updated with all the necessary variables required, rather emptying the dictionary depends on where we invoke the function define_sem.

CC: @neelgala @allenjbaum @pawks

[pawks]

The local variables can be passed as a dictionary to the eval function(documentation). The defined mechanisms work for all RV64IMAFDC tests and this has been tested. The coverage function never "ignores" the coverpoints under the val_comb node. They are always evaluated to check for coverage. If the coverage is reported to be 0, there are 3 possible scenarios -

• The coverpoint is wrong
• The coverpoint is not being met by the tests
• The different variables in the coverpoint are not being assigned correctly.

[ptprasanna]

possibly the third one could be the issue, as i continue to investigate this. Can rule out the first two as the tests were passing through successfully on the floating-point-dev. Facing the issue now on the latest master.

The value of fm is possibly be wrong as of i understood the code.

[pawks]

I don't think this issue exists now. Feel free to reopen if you see the behavior again.