Should we make the smclicshv (Selective Hardware Vectoring) extension mandatory in CLIC 1.0?

[james-ball-qualcomm]

We are getting the CLIC spec ready for Internal Review and then ARC review. Towards that end, I wanted to see if there is an opportunity to make the SHV feature (allows faster interrupt response for selected interrupts) mandatory? That would simplify the spec since SHV makes changes in a variety of CLIC sections and would simplify certification (less optional extensions is better).

The hardware overhead is about 1 additional CSR bit per interrupt and some fixed cost for hardware state machines to perform the SHV behaviors. For implementations that don't want this overhead, they can just tie the shv CSR bit to 0.

[allenjbaum]

If the reason for this is to simplify certification, then keeping it optional in the spec, but making it mandatory in the profile will enable the certification, and the cases that care about minimum code size.

[aswaterman]

The general RISC-V trend is to give names to architecturally visible features whenever possible, including e.g. whether features truly exist or are gated off by hardwired CSR fields. So, if we took this route, we'd still end up assigning a new name to implementations that [dis]allow that CSR field to be written to 1, i.e. right back where we started. I think it's OK as-is.

[james-ball-qualcomm]

The main goal of my suggestion was towards simplifying the documentation. Namely, for people who start to read the spec at the beginning, they'll see the CLIC features explained in detail and then come across this smclicshv extension chapter that impacts what they've read already in multiple places. If we make smclicshv mandatory, we can explain it behaviors in an integrated fashion in the earlier chapters and then just come up with a new option name to say whether an implementation hardwires shv to 0 or makes it writable with 0 or 1. That's a lot easier to document.

[christian-herber-nxp]

I think we need to separate functionality and documentation. The clarity in documentation could be improved, but i will focus on the functionality.

I am in favor of keeping the option, to have more clarity in SW. You want to know if HW vectoring is supported at compile time. Therefore, you need the architectural option, to have access to a compiler defined macro. Discovering at run-time is not enough.

[james-ball-qualcomm]

Closing since consensus is to leave it the way it is.