Cover "debug_request asserted while dret executing while not in debug mode" scenario

[MikeOpenHWGroup]

Task Outcome

Ensure functional verification of the following scenario:

• core is in debug mode.
• a dret instruction is fetched, and begins working its way through the execution pipeline.
• before the dret instruction completes, a debug_request is asserted.

Task Outcome

1. Update DVplan(s) for the above scenario.
2. Implement functional coverage (either covergroup or cover property) to ensure the scenario happens.

If the coverage is written as a cover property, it should run in both simulation and formal verification. However, it need only be covered in one of simulation or formal.

Background information

See cv32e40p issue 548.

Additional context

For now this issue is assigned to CV32E40S. Once an implementation path is determined, related tasks will be required for all other cores verified in CORE-V-VERIF.

[silabs-robin]

Ensure functional verification of the following scenario:

• core is in debug mode.
• a dret instruction is fetched, and begins working its way through the execution pipeline.
• before the dret instruction completes, a debug_request is asserted.

According to the original ticket (https://github.com/openhwgroup/cv32e40p/issues/548), I'm wondering if it should be:

• Core in non-debug
• dret finishes execution
• Haltreq (as early as possibly) with grant, before exception handler

[MikeOpenHWGroup]

Thanks for the clarification @silabs-robin. You are right, and it is even a bit more nuanced than that. The sequence appears to be:

1. The core is executing in non-debug mode.
2. The next instruction is a dret, which is an illegal instruction exception when not in debug mode. Therefore the next properly retired instruction (in normal operation) should be the first instruction of the mtvec handler.
3. An external debug request occurs during the illegal instruction (dret), but before the dret retires.
4. The external debug request is granted so the next instruction should be the first instruction of the debug handler.

In the issue that sparked this debate, the CV32E40P had a bug such that it switched dpc to point to the first address of the mtvec handler and mepc to point to the dret (reflecting the "execution" of the illegal instruction).

Given the above, I've edited the title of this issue.

Of course, we need to keep in mind that the above sequence was specific to the CV32E40P v1.0.0 and other cores (which may adhere to newer privileged and debug specs) may be subtly different.