exception/interrupt handlers optimizations

[algrobman]

Hi the tool creates very long interrupt handlers, significantly reducing the tests efficiency. Having often interrupts or exceptions (testing illegals)
more than 90% of time the same exception/interrupt handlers code will be executed.
I see few areas where these can be optimized:

1. the handlers save/restore all GPRs, although only very few (in most cases just only 2 GPRs are used in the handlers) - so only these two to be saved/restored
2. most often exception is illegal instruction one, but its check is placed as last in the mcause checks chain. Move the illegal to the beginning of the chain saves a lot of simulation cycles (time),
3. not sure what the kernal SP exchange with reserved sp register at the beginning and the end of the handler is for, why can't the kernal SP be used as a base register directly for saving GPRs?

[MikeOpenHWGroup]

Hi @algrobman. As a long-time user of riscv-dv, I agree with you. Generally speaking, in functional verification of RTL models (which is largely what OpenHW use riscv-dv for) test efficiency is less of a concern that test coverage, so we tend not to worry about it. If efficiency is important to you, try extending riscv_instr_pkg.sv::push_gpr_to_kernel_stack or even riscv_asm_program_gen::gen_trap_handler_section to produce the behaviors you want. Our use of riscv-dv extends a lot of methods in multiple methods.

If you have success with that, you could even suggest a pull-request based on your extension. We have done this a few times and the riscv-dv team is very happy to review these.

[algrobman]

problem is when I'm regressing I have to wait 10x time for 2% of the tests - outliners, which have a lot of exceptions in them.
Or when I enable relatively frequent interrupts.
I published this issue, wondering why nobody cares of this ..

[MikeOpenHWGroup]

Sounds like a regression management issue to me. Send me and email (available on my GitHub profile) if you'd like to discuss.