Architecture_Specification_1.0_Changes_Summary.mw

This page outlines the changes made for OR1K 1.0. It does not give the full details of all the changes at present. Please refer to [http://opencores.org/websvn,filedetails?repname=openrisc&path=%2Fopenrisc%2Ftrunk%2Fdocs%2Fopenrisc-arch-1.0-rev0.pdf the architecture manual document] (table 1-2) for full details.

= Summary =

== New SPRs ==

* VR2 (Version register 2), group 0, number 9
* AVR (Architecture Version register), group 0, number 10
* EVBAR (Exception Vector Base Address register) (optional), group 0, number 11
* AECR (Arithmetic Exception Control register) (optional), group 0, number 12
* AESR (Arithmetic Exception Status register) (optional), group 0, number 13
* ISR0-ISR7 (Implementation-specific registers) (optional) group 0, numbers 21-28

== Modified SPRs ==

* VR (Version Register) - bit 6 now indicates the presence of the VR2
* CPUCFGR - several bits added indicating
** bit 10, ND, whether CPU implements delay slot
** bit 11, AVRP, AVR present
** bit 12, EVBARP, EVBAR present
** bit 13, ISRP, ISRs present
** bit 14, AECSRP, AECR & AESR present

== VR ==

The VR is deprecated in OR1K 1.0, software can check for the new version register, (VR2) by checking if bit 6 of VR is set. Bit 6 (previously reserved) of the VR is now defined as the <tt>Updated Version Register Present</tt> bit. This indicates the presence of the VR2 register.

== VR2 ==

The VR2 now holds 2 fields.

* 8-bit CPU identifier - these are unique identifiers and there is one per CPU implementation as per [[OR1K_CPU_Cores#CPU_ID_Table|this table]]
* 24-bit CPU implementation version number (meaning is implementation-specific but version number overall should increment with newer versions)

== CPUCFGR bits ==

There have been additional bits added to the CPUCFGR SPR indicating features and presence of optional architectural features.

== AECR, AESR ==

These registers make it possible to configure and determine which arithmetic exceptions trigger the range exception.

The addition of these registers, in combination with clarifying the signed and unsigned overflow conditions setting the carry and overflow flags for the add/subtract and multiplication instructions, now make OR1K's arithmetic exception handling clearer and more configurable.

== ISRs ==

The implementation-specific registers allow CPU implementations to embed up to 256-bits of information. This space can be used for any purpose, but it's intended to be used to store things such as
* implementation-level configuration information (ie, synthesis-time configuration settings)
* local build version/date information
* debug features 

= Updates to implementations =

It's suggested the following is done to bring implementations into line with OR1k 1.0:

== SPRs ==

* Add new VR2, indicating the CPU implementation, and its version
** Also requires adding the UVRP bit in VR (set VR[6])
* Add new AVR, indicating the architectural version
** Also requires adding the ARVP bit in CPUCFGR
* If implementation does not implementation delay-slots on branches/jumps, set the CPUCFGR[ND] bit
* Unimplemented SPR space (SPR addresses for which there are no registers) should read as zero and writing should have no effect

== Arithmetic operations ==

Carry and overflow handling should now behave like so:

* for all integer addition, subtraction and multiplication instructions, SR[CY] (the carry bit) should only be set on '''unsigned''' overflow, and SR[OV] should only be set for '''signed''' overflow
* integer divide by zero has the following behaviour:
** on l.div sets SR[OV]
** on l.divu sets SR[CY]
* If the implementation supports the MAC instructions
** add similar overflow/carry setting logic for the addition stage

== Other new features ==

These are all optional.