[BUG] Update interrupt vector table description

[DanieleParravicini-Synthara]

Bug Description

The CVE2 documentation read online at ReadTheDocs at cve2-user-manual/en/latest/internal says that CVE2 should start at [boot_addr_i + 0x80] (https://docs.openhwgroup.org/projects/cve2-user-manual/en/latest/02_user/integration.html#interfaces) but I do not find any information on the interrupt vector table.

We tried to use a vector table that was compatible with this other version of Ibex and used its documentation on ReadTheDocs. But it does not work,

As you can see boot_addr_i is set to 0x80000, and the crush_dump_o.current_pc and crush_dump_o.next_pc goes to 0x80000, then to 0x80004, and then 0x800a6 and not to 0x80000+0x80 as indicated in (https://docs.openhwgroup.org/projects/cve2-user-manual/en/latest/02_user/integration.html#interfaces).

Where can I find more information on the interrupt vector table description?

If you are ok we could submit a PR to fix the simple-system firmware to reflect the change.

[DanieleParravicini-Synthara]

MAYBE: comparing cve2_if_stage.sv with ibex_if_stage.sv it seems that the CVE2 starts boot_addr_i and not at boot_addr_i+0x80.

looking further it seems that the old ibex has 32 irq, or 32 addresses in the IRQ vector table whereas the CVE2 seems to have 64 "IRQS": 32 dedicated to actual IRQ and other 32 for exc, right?

so we can say that IRQ[0] is actually the boot address. correct?

[DanieleParravicini-Synthara]

If you are ok with that I could create a PR that updates the documentation

[davideschiavone]

yes that would be very welcome :)

[DanieleParravicini-Synthara]

Noice, but do you think that the intuition is correct?

MAYBE: comparing cve2_if_stage.sv with ibex_if_stage.sv it seems that the CVE2 starts boot_addr_i and not at boot_addr_i+0x80.

looking further it seems that the old ibex has 32 irq, or 32 addresses in the IRQ vector table whereas the CVE2 seems to have 64 "IRQS": 32 dedicated to actual IRQ and other 32 for exc, right?

so we can say that IRQ[0] is actually the boot address. correct?

[davideschiavone]

yes it has been done here: https://github.com/openhwgroup/cve2/commit/be70b262f6ade7c14e022272af6c609f739a8d4b

[DanieleParravicini-Synthara]

so combining page 43 of Volume 2, Privileged Specification version 20240411 and [cve2 repo e.g. cve2_pkg, cve2_controller]:(https://github.com/openhwgroup/cve2/blob/42f76f433c596e5127ea62b9679975f527c3ca61/rtl/cve2_pkg.sv#L299):

• IRQ0 is reserved
• IRQ3 is software IRQ
• IRQ7 is for timer
• IRQ11 is for machine external interrupts
• IRQ>16 and above are considered customs and in the case of CVE2:
• IRQ16-IRQ31 are used for 16 irq_fast
• IRQ32 is non maskable IRQ

so the vector interrupt table is as follows ( the addresses are indicated as word offset from the mtvec or boot_addr):	offset	description
0	boot
1-2	reserved
3	IRQ
4-6	reserved
7	irq timer
8 - 10	reserved
11	irq external
12-15	reserved
16-31	16 fast local interrupt
32	non maskable interrupt

so the vector table starts at boot_addr and arrives till 0x7C (included)

[DanieleParravicini-Synthara]

can you please confirm?

[DanieleParravicini-Synthara]

a wait, the exception are also "multiplexed" on this vector table, right?

[DanieleParravicini-Synthara]

I am not so sure because I can see some overlapping in the exc_cause_e:

• EXC_CAUSE_BREAKPOINT = {1'b0, 6'd03} and EXC_CAUSE_IRQ_SOFTWARE_M = {1'b1, 6'd03},
• EXC_CAUSE_STORE_ACCESS_FAULT = {1'b0, 6'd07} and EXC_CAUSE_IRQ_TIMER_M = {1'b1, 6'd07},
• EXC_CAUSE_ECALL_MMODE = {1'b0, 6'd11} and EXC_CAUSE_IRQ_EXTERNAL_M = {1'b1, 6'd11},

[davideschiavone]

interrupts are not related to the boot address, when an interrupt occurs you jump to the address pointed by the mtvec CSR

https://github.com/openhwgroup/cve2/blob/main/rtl/cve2_if_stage.sv#L124C23-L124C29

[DanieleParravicini-Synthara]

but mtvec is set to boot_addr at boot right, no? https://github.com/openhwgroup/cve2/blob/42f76f433c596e5127ea62b9679975f527c3ca61/rtl/cve2_cs_registers.sv#L502

[davideschiavone]

only at reset state, so you can imagine the boot_address being the reset value of the mtvec, the reason that is not the reset value itself is that you do not want to reset a flip flop with a NON CONSTANT (as boot address is an input signal) value

[DanieleParravicini-Synthara]

very right, thanks. The vector table itself, you think I got the gist?

You have entries in the vector interrupt table that mix exceptions and interrupts?

[DanieleParravicini-Synthara]

I think I made a mistake: so the vector table starts at boot_addr and arrives till 0x80 (included)

[DanieleParravicini-Synthara]

Something like this https://github.com/openhwgroup/cve2/pull/273 ?

[davideschiavone]

273 seems indeed correct, but you modifed the RTL of the controller - can you pls revert it back? thanks @DanieleParravicini-Synthara

[DanieleParravicini]

Sure, my bad apologies

[DanieleParravicini-Synthara]

Hello @davideschiavone, I fixed a typo and added a new line of comments on cve2_controller.sv. I think my editor config got in the way and used LF instead of CRLF, so that was the reason it seemed the entire cve2_controller.sv was touched. I reformatted the file and pushed, if you prefer I can remove it. Maybe this will trigger some regression on CI. Let me know

[DanieleParravicini-Synthara]

I am not sure I understand correctly, so apologies if I don't get it right.

https://github.com/openhwgroup/cve2/blob/cd43ee5dbf1b8315fb655f8678be7f7fe51b0939/rtl/cve2_if_stage.sv#L125

is used only for IRQs.

If an exception happens it gets stored in exc_req_q and then during FLUSH,

https://github.com/openhwgroup/cve2/blob/cd43ee5dbf1b8315fb655f8678be7f7fe51b0939/rtl/cve2_controller.sv#L589

depending on debug_mode_q

https://github.com/openhwgroup/cve2/blob/cd43ee5dbf1b8315fb655f8678be7f7fe51b0939/rtl/cve2_controller.sv#L592

exc_pc_mux_o is set to a value that then results in one of the following two:

https://github.com/openhwgroup/cve2/blob/cd43ee5dbf1b8315fb655f8678be7f7fe51b0939/rtl/cve2_if_stage.sv#L124 https://github.com/openhwgroup/cve2/blob/cd43ee5dbf1b8315fb655f8678be7f7fe51b0939/rtl/cve2_if_stage.sv#L127

This reflects The RISC-V Instruction Set Manual: Volume II: Priviledged Architecture: When MODE=Vectored, all synchronous exceptions into machine mode cause the pc to be set to the address in the BASE field, whereas interrupts cause the pc to be set to the address in the BASE field plus four times the interrupt cause number

So, https://github.com/openhwgroup/cve2/pull/273 is wrong and https://github.com/openhwgroup/cve2/blob/2a9f3c669ae71240ff86b5de78131ff05d54a2eb/doc/03_reference/exception_interrupts.rst?plain=1#L180 should be exception handler. Correct?