On Sat, Apr 21, 2012 at 04:02:46PM +0100, Julius Baxter wrote: > On Sun, Jan 29, 2012 at 10:09 PM, Stefan Kristiansson > <[email protected]> wrote: > > The current options for locations of the exception vectors > > are not very flexible, the only two possible locations are at > > address 0x0 or address 0xf0000000. > > > > I would like to propose an addition of an (optional) SPR register (EVBA) > > in group 0 (System Control and Status registers) at address 1536 > > (right after the last possible GPR mapped into SPR space), > > which would hold the (upper part of the) base address of the exception > > vectors. > > > > Hi Stefan > > Sounds fine. Can you go and flesh out this section on the wiki on this: > > http://opencores.org/or1k/Architecture_Specification#Exception_Vector_Base_Address > > Basically write up what you think the section should look like in the manual. >
I've added the following text to the wiki: [31:13] Exception Vector Base Address Location for the start of exception vectors. Reset value: 0 [12:0] Reserved / Constant 0 This register is optional, and in case EPH is asserted, it should be OR'ed together with the value in EVBA. The presence of EVBA can be detected in software by writing a value to it and see if the same value reads back. > Can you address some questions I have: > > * How wide will it be (how many bits of the address will it hold?) see above > * Where is the presence bit going to be? I'm not sure if a presence bit will be necessary, I presented a way to check for it's presence above. > * Will there be an enable bit somewhere to control whether this > register is obeyed or not? (ie. will it be a synthesis-time or > run-time option?) I don't see that as necessary, if it's implemented, you can "disable" it by writing 0 to it, that way it'd act the same way as if it wouldn't exist at all > * Is SR[EPH] ignored when this system is in use? > SR[EPH] becomes a bit redundant with this system is in use, I agree, I however proposed above that it should just simply be OR'ed together with EVBA, I'm open for discussion on this though. Stefan _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
