Interrupt information needed

[alexrp]

Hey.

The architecture reference manual does an excellent job of explaining how the interrupt system works. However, it does not actually detail very well what things trigger interrupts. For some interrupts, I can figure it out by cross-referencing, but others are not clear, such as alignment faults, memory protection fault, etc.

Any chance you guys could go through the manual and add information where appropriate if an instruction can cause an interrupt? I'm asking because I'm writing a concurrent architecture simulator. This information is rather essential for correct semantics.

Thanks!

[Gravis]

[alexrp]

The one thing the manual doesn't seem to answer anywhere is: What happens if you read from or write to some arbitrary, nonsensical address? Does a memory protection fault happen? Or does "garbage in; garbage out" apply? Or something else entirely?

[Gravis]

[aolofsson]

[alexrp]

Regarding software exceptions, the following needs clarification:

* Is there any current functionality in the architecture that can trigger an unimplemented exception?
* What triggers an illegal access exception?

[alexrp]

[aolofsson]

Here is some more information regarding illegal operations resulting in a software exception. Let me know if you have any issue understanding the verilog code below: Any excause value that is not 0000 generates a software exception. Note that the illegal instruction is still experimental and not officially supported. Hopefully the code is self explanatory. When in doubt go to the source:-)

assign sq_excause_e1[3:0] = de_unimplemented_e1 ? 4'b1111 :
de_swi_e1 ? 4'b1110 :
sq_ldst_unaligned_e1 ? 4'b1101 :
core_illegal_access_e1 ? 4'b1100 :
sq_fpu_exception_e1 ? 4'b0111 :
4'b0000;


assign sq_illegal_instr_e1 = ~sq_supervisor_mode &
iab_instr0_valid_e1 &
(de_rti_reg_e1 | de_wand_reg_e1 | de_sync_reg_e1 | de_gie_reg_e1 | de_gid_reg_e1 |
(de_bkpt_reg_e1&~sq_debug_mode) | (de_mbkpt_reg_e1&~sq_debug_mode)
);

assign core_mmr_write_enable = de_movts_e1 & sq_supervisor_mode;

assign core_illegal_access_e1 = sq_illegal_instr_e1 |
(de_movts_e1 & ~core_mmr_write_enable);


assign sq_fpu_exception_e1 = (sq_fpu_invalid_e3e4 & sq_ien_mode ) |
(sq_fpu_overflow_e3e4 & sq_oen_mode ) |
(sq_fpu_underflow_e3e4 & sq_uen_mode );

assign sq_ldst_unaligned_e1 = (core_ldst_access_e1) &
(
(core_ldst_datamode_e1[1:0]==2'b01) & core_ldst_addr_e1[0] | //short
(core_ldst_datamode_e1[1:0]==2'b10) & (|core_ldst_addr_e1[1:0]) | //word
(core_ldst_datamode_e1[1:0]==2'b11) & (|core_ldst_addr_e1[2:0]) //double
);

[alexrp]

Thanks, Andreas!

This leaves me with two questions:

1. Does writing to EXCAUSE immediately cause a software exception to be generated? I.e. you wouldn't have to 'trigger' it with SWI or something similar? In this case, what purpose will SWI serve when it's published fully?
2. When is EXCAUSE reset by the hardware, if at all?

And by the way, are the Verilog sources available on GitHub somewhere?

[timpart]