: [hw-dev] RISC V - trap/interrupt flow

[David Darmon (ddarmon)]

Hi,

Sorry for the basic question but someone may describe (or guide me to a doc) that describe the flow done in the CPU to generates an async interrupt/sync trap or breakpoint.

In the privilege doc there are all the HW support (xRET instruction, ECALL, EBREAK) but w/o real flow description (Not in the interrupt controller but in the CPU).


Regards,

David D

[Stefan O'Rear]

ECALL and EBREAK are basically just illegal instructions with fancy
names. If you've got illegal instruction support working, you can
support ECALL and EBREAK by changing the mecause value.

Async interrupts are handled in Rocket by injecting an illegal
instruction in the instruction fetch unit.

Synchronous faults (which, as described, encompass the other
categories) are handled in the writeback stage by updating the various
control registers and then generating a kill signal which invalidates
the instructions already in the pipeline (so instructions after the
ECALL, trap, or interrupt will be fetched and executed, but their
register and memory writes are ignored).

-s

[David Darmon (ddarmon)]

Hi Stephan

Can you elaborate:

The CPU fetch an illegal instruction in the fetch then the CPU generates an exception then the PC jump to the MTVEC address (I am right ?)

If yes , how I can differentiate between 2 different interrupts (e.g. UART / SPI ) as the PC shall be different to have different handler.


Regards,

David D

[Stefan O'Rear]

On Thu, Mar 16, 2017 at 1:20 AM, David Darmon (ddarmon)
<dda...@cisco.com> wrote:
> Hi Stephan
>
> Can you elaborate:
>
> The CPU fetch an illegal instruction in the fetch then the CPU generates an exception then the PC jump to the MTVEC address (I am right ?)
>
> If yes , how I can differentiate between 2 different interrupts (e.g. UART / SPI ) as the PC shall be different to have different handler.

The PC is the same, the value written into MCAUSE is different. See
table 3.6 on https://content.riscv.org/wp-content/uploads/2016/11/riscv-privileged-v1.9.1.pdf#page=46
. (Note that per the previous page, high bit clear = trap high, bit
set = interrupt.)

If you have two interrupt pins on your core, you should assign each of
them a separate cause above 12. For instance you might decide that
mcause=0x8000_000c is the UART and mcause=0x8000_000d is SPI.

You would write PC and MCAUSE at the same time when taking the jump.

-s

[Mauro Olivieri]

Hello,

a doubt about writing a cause code above 12 in the MCAUSE CSR in case of many irq pins: according to Priv. ISA 1.9.1, values above 12 are defined as "reserved", which doesn't seem equivalent to "available for custom-defined codes".
I wonder if defining an additional, non-standard register e.g. MIRQ that maps irq pin values and is visible to software is more cleanly compliant to the RISCV specification. I assume that extending the CSR set is more compliant to the specification than using reserved values of a standard CSR for custom purposes.

thanks in advance

M

[Stefan O'Rear]

On Fri, Mar 17, 2017 at 9:55 AM, Mauro Olivieri
<olivieri...@gmail.com> wrote:
>
> Hello,
>
> a doubt about writing a cause code above 12 in the MCAUSE CSR in case of
> many irq pins: according to Priv. ISA 1.9.1, values above 12 are defined as
> "reserved", which doesn't seem equivalent to "available for custom-defined
> codes".
> I wonder if defining an additional, non-standard register e.g. MIRQ that
> maps irq pin values and is visible to software is more cleanly compliant to
> the RISCV specification. I assume that extending the CSR set is more
> compliant to the specification than using reserved values of a standard CSR
> for custom purposes.

It is my understanding that the foundation intends to reserve a large
portion of the range above 12 for custom use by platform designers.

Depending on your timing constraints using standard cause 11 and a new
MIRQ register may be preferable.

CCing Andrew for possibly more specific guidance.

-s

[Andrew Waterman]

We have always intended that mcause values correspond numerically to mip/mie bit positions. We have not been clear about which bits/causes are reserved for nonstandard use. The MSBs are probably safe to use for nonstandard interrupts, but we may reserve some more of the lower ones for future standard use (e.g., 12-15).