ISA Cross Coverage Waiver for CV32E40P

[MikeOpenHWGroup]

In the CV32E40P verification status meeting today we discussed the state of coverage. You can look at the latest coverage report here. Under cov_model/isa_covg in the coverage report, you will see a few holes in functional coverage of instructions, specifically cross-coverage of the following types of instruction sequences:

• <any_instr>, mret
• <any_instr>, dret
• <any_instr>, ecall
• <any_instr>, ebreak
• <any_instr>, c.jal
• <any_instr>, c.jalr

I have coded up a truly ugly directed testcase which will cover the <instr>,c.jal and <instr>,c.jalr sequences, so let's consider those "covered". The question here is, are we comfortable waving the other instruction sequence coverage holes for RTL Freeze? I see several possible options:

1. No. If this is the consensus, then we must cover these holes and that will delay RTL Freeze to mid-December.
2. Yes. If this is the consensus, then we make a best-case attempt to cover some of these holes and expect to achieve RTL Freeze 2020-12-01 or earlier.
3. Partially. In this case, we identify several categories of crosses that should be hit, but agree to waive others. For example, maybe its important to hit div, dret, but addi, dret is less important. We will attempt to hit these in time for 12-01 freeze date.

I like option 3, but lack the knowledge of the micro-architecture to says which are the higher risk sequences we should cover and which are lower risk that we may waive.

@davideschiavone and @jm4rtin, please update this issue with your specific comments on the topic.

[strichmo]

A report has been generated for all cross coverage waivers as mentioned above. For purposes of freezing the CV32E40P RTL this issue will track acceptance of the waiver for freeze.

https://openhwgroup.github.io/core-v-verif/Waivers/cv32e40p_cg_waiver/html_07-12-2020_08~07~17/index.html

[MikeOpenHWGroup]

Updated URL to waivers.

[MikeOpenHWGroup]

This Issue should have been closed when the CV32E40P v1.0.0 was signed-off.