clarify writes to dinfc

[tariqkurd-repo]

#416

[arichardson]

Not sure if we need to restrict it to infinite caps, but might make more sense?

Alternatively I'd suggest using permissions encoding includes the <<m_bit>> instead of has a valid <<m_bit>>.

[tariqkurd-repo]

We've had an internal review on this, and what it would really take to be able to write debug software.

Note that the previous spec didn't specify whether MODESW.* updated the execution of the next instruction, or delayed the update to the next entry into debug mode - so this is now specified as part of the commit.

We spent some time discussing how to update dinfc, as checking for a full infinite-cap is quite expensive in hardware.
Our conclusion was to not update dinfc, and require MODESW.* in debug mode

The point is that not requiring MODESW.* means that the debugger won't be able to rely on them. It will have to try and execute one, see if it gets an error and then fall back to doing the CSR RMW sequence to update dinfc. Or just not bother with them at all, in which case they are a waste of time.

So we've gone for the simple approach of requiring them, having them update M in dinfc, and making that observable by reading dinfc. This gives us a single simple mechanism for controlling the mode.

[arichardson]

I like this simplification