diff options
author | Joel Sherrill <joel.sherrill@OARcorp.com> | 2008-12-04 22:54:32 +0000 |
---|---|---|
committer | Joel Sherrill <joel.sherrill@OARcorp.com> | 2008-12-04 22:54:32 +0000 |
commit | 276abbf6c6b26eac3e61f9f7f16eb6c29fa1252a (patch) | |
tree | d552e352d9c96b0cb421ba1b04e5ce1bff4efb2d /doc/cpu_supplement/lm32.t | |
parent | 2008-12-04 Jukka Pietarinen <jukka.pietarinen@mrf.fi> (diff) | |
download | rtems-276abbf6c6b26eac3e61f9f7f16eb6c29fa1252a.tar.bz2 |
2008-12-04 Jukka Pietarinen <jukka.pietarinen@mrf.fi>
* cpu_supplement/.cvsignore, cpu_supplement/Makefile.am,
cpu_supplement/cpu_supplement.texi: Add Lattice Mico32 support.
* cpu_supplement/lm32.t: New file.
Diffstat (limited to 'doc/cpu_supplement/lm32.t')
-rw-r--r-- | doc/cpu_supplement/lm32.t | 187 |
1 files changed, 187 insertions, 0 deletions
diff --git a/doc/cpu_supplement/lm32.t b/doc/cpu_supplement/lm32.t new file mode 100644 index 0000000000..6befa7a9df --- /dev/null +++ b/doc/cpu_supplement/lm32.t @@ -0,0 +1,187 @@ +@c +@c COPYRIGHT (c) 1988-2002. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c +@c $Id$ +@c +@c Jukka Pietarinen <jukka.pietarinen@mrf.fi>, 2008, +@c Micro-Research Finland Oy +@c + +@ifinfo +@end ifinfo +@chapter Lattice Mico32 Specific Information + +This chaper discusses the Lattice Mico32 architecture dependencies in +this port of RTEMS. The Lattice Mico32 is a 32-bit Harvard, RISC +architecture "soft" microprocessor, available for free with an open IP +core licensing agreement. Although mainly targeted for Lattice FPGA +devices the microprocessor can be implemented on other vendors' FPGAs, +too. + +@subheading Architecture Documents + +For information on the Lattice Mico32 architecture, refer to the +following documents available from Lattice Semiconductor +@file{http://www.latticesemi.com/}. + +@itemize @bullet +@item @cite{"LatticeMico32 Processor Reference Manual"} +@file{http://www.latticesemi.com/dynamic/view_document.cfm?document_id=20890} +@end itemize + +@c +@c +@c +@section CPU Model Dependent Features + +The Lattice Mico32 architecture allows for different configurations of +the processor. This port is based on the assumption that the following options are implemented: + +@itemize @bullet +@item hardware multiplier +@item hardware divider +@item hardware barrel shifter +@item sign extension instructions +@item instruction cache +@item data cache +@item debug +@end itemize + +@c +@c +@c +@section Register Architecture + +This section gives a brief introduction to the register architecture +of the Lattice Mico32 processor. + +The Lattice Mico32 is a RISC archictecture processor with a +32-register file of 32-bit registers. + +@multitable {Register Name} {general pupose / global pointer} +@headitem Register Name @tab Function +@item r0 @tab holds value zero +@item r1-r25 @tab general purpose +@item r26/gp @tab general pupose / global pointer +@item r27/fp @tab general pupose / frame pointer +@item r28/sp @tab stack pointer +@item r29/ra @tab return address +@item r30/ea @tab exception address +@item r31/ba @tab breakpoint address +@end multitable + +Note that on processor startup all register values are undefined +including r0, thus r0 has to be initialized to zero. + +@c +@c +@c +@section Calling Conventions + +@subsection Calling Mechanism + +A call instruction places the return address to register r29 and a +return from subroutine (ret) is actually a branch to r29/ra. + +@subsection Register Usage + +A subroutine may freely use registers r1 to r10 which are @b{not} +preserved across subroutine invocations. + +@subsection Parameter Passing + +When calling a C function the first eight arguments are stored in +registers r1 to r8. Registers r1 and r2 hold the return value. + +@c +@c +@c +@section Memory Model + +The Lattice Mico32 processor supports a flat memory model with a 4 +Gbyte address space with 32-bit addresses. + +The following data types are supported: + +@multitable {unsigned half-word} {Bits} {unsigned int / unsigned long} +@headitem Type @tab Bits @tab C Compiler Type +@item unsigned byte @tab 8 @tab unsigned char +@item signed byte @tab 8 @tab char +@item unsigned half-word @tab 16 @tab unsigned short +@item signed half-word @tab 16 @tab short +@item unsigned word @tab 32 @tab unsigned int / unsigned long +@item signed word @tab 32 @tab int / long +@end multitable + +Data accesses need to be aligned, with unaligned accesses result are +undefined. + +@c +@c +@c +@section Interrupt Processing + +The Lattice Mico32 has 32 interrupt lines which are however served by +only one exception vector. When an interrupt occurs following happens: + +@itemize @bullet +@item address of next instruction placed in r30/ea +@item IE field of IE CSR saved to EIE field and IE field cleared preventing further exceptions from occuring. +@item branch to interrupt exception address EBA CSR + 0xC0 +@end itemize + +The interrupt exception handler determines from the state of the +interrupt pending registers (IP CSR) and interrupt enable register (IE +CSR) which interrupt to serve and jumps to the interrupt routine +pointed to by the corresponding interrupt vector. + +For now there is no dedicated interrupt stack so every task in +the system MUST have enough stack space to accommodate the worst +case stack usage of that particular task and the interrupt +service routines COMBINED. + +Nested interrupts are not supported. + +@c +@c +@c +@section Default Fatal Error Processing + +Upon detection of a fatal error by either the application or RTEMS during +initialization the @code{rtems_fatal_error_occurred} directive supplied +by the Fatal Error Manager is invoked. The Fatal Error Manager will +invoke the user-supplied fatal error handlers. If no user-supplied +handlers are configured or all of them return without taking action to +shutdown the processor or reset, a default fatal error handler is invoked. + +Most of the action performed as part of processing the fatal error are +described in detail in the Fatal Error Manager chapter in the User's +Guide. However, the if no user provided extension or BSP specific fatal +error handler takes action, the final default action is to invoke a +CPU architecture specific function. Typically this function disables +interrupts and halts the processor. + +In each of the architecture specific chapters, this describes the precise +operations of the default CPU specific fatal error handler. + +@c +@c +@c + +@section Board Support Packages + +An RTEMS Board Support Package (BSP) must be designed to support a +particular processor model and target board combination. + +In each of the architecture specific chapters, this section will present +a discussion of architecture specific BSP issues. For more information +on developing a BSP, refer to BSP and Device Driver Development Guide +and the chapter titled Board Support Packages in the RTEMS +Applications User's Guide. + +@subsection System Reset + +An RTEMS based application is initiated or re-initiated when the processor +is reset. |