Hardware support for stack overflow checking

[Silabs-ArjanB]

In #161 Haugoug proposed an enhancement for stack overflow checking during simulations. This enhancement request is also about support for stachk overflow checking, but this time it is aimed at an RTL implementation aimed at providing stack overflow checking support on silicon.

The proposal below is described 'relative to the proposal in #161.' As #161 is aimed at simulation whereas this ticket is aimed at RTL implementation, difficult requirements/constraints apply, leading to a different proposal.

- We would make key assumptions / simplifications:

- Stack limit checking only needs to check for **stack overflow during stack frame creation**
    - Only overflow needs to be checked, i.e. there is no need to perform checks during unstacking.
    - Only 1 limit CSR is therefore needed
- Stack limit checking only needs to work **compiler-generated code** that modifies (i.e. decrements) the stack pointer before performing any stores to the reserved space when performing a stack frame creation, e.g. as follows:

    addi sp,sp,-framesize                     # Create stack frame 
    sw a1,OFFSET(sp)                           # Push register onto stack
    sw a2,OFFSET(sp)                           # Push register onto stack
    …
- Stack frame creation will always start with an ‘addi sp,sp,-framesize’ (with sp == r2) and we propose that the stack overflow check is **only** performed on the result of such an ‘addi’ instruction.

  So, for example the following instructions/values will not be used in the stack overflow check:
     - Access address of store instructions
     - Access address of load instructions
     - Instructions (other than ‘addi sp,sp,-framesize’) writing to sp (so also not for RI5CY’s post-increment load/store)

- CSR usage

- Only **1 CSR** is needed, splimit
    - If resulting sp of ‘addi sp,sp,framesize’ < splimit, then a stack overflow is detected.
- Stack overflow detection can be disabled by setting splimit to 0 (default value) (e.g. by ‘csrwi splimit, 0’)

- Upon a stack overflow detection:

- Cause a synchronous ‘stack overflow’ exception for the addi instruction (mepc would point to the address of the addi instruction; mtval would contain the offending stack address)
    - Exception code 24 in mcause can be used for this (or another free exception code that is reserved for future custom use) (the priority of this exception versus other exceptions is not relevant as addi cannot cause other synchronous exceptions).
- Automatically disable further stack overflow checking (so splimit=0)

Reason for this is to not further complicate the exception handler code (which itself would normally start with ‘addi sp,sp,framesize’ which would then also cause an exception). (The actual splimit therefore needs to be set a little above the actual lower boundary of the stack such that this exception itself can do its work.)

It is the duty of the exception handler to re-initialize splimit once it has taken its other corrective actions.

- ‘addi sp,sp,framesize’ which caused the overflow actually performs ‘sp = splimit’ (this gives the exception handler a predictable stack pointer)

- TBD:

- Should stack overflow checking be automatically disabled for other scenarios (e.g. during NMI)?
- Are any special provisions needed for cores that have Machine mode + User mode (my initial reaction would be that we only need a Machine-mode CSR)?
- Above proposal limits the stack overflow checking to only the 'addi sp, sp, framesize' instruction. Should this be extended to check every write to sp (e.g. also my MUL, XOR, load with post increment, etc.)? (If so, what are the implications on critical path and how would we prioritize instructions causing multiple synchronous exceptions (e.g. stack overflow exception plus store access violation)?)

I am very interested in hearing further opinions on this.

Best regards,
Arjan