source: rtems/doc/supplements/sparc/cpumodel.t @ aa84e20
Last change on this file since aa84e20 was aa84e20, checked in by Ralf Corsepius <ralf.corsepius@…>, on May 22, 2003 at 8:10:04 AM

Merger from rtems-4-6-branch

  • Property mode set to 100644
File size: 4.9 KB
2@c  COPYRIGHT (c) 1988-2002.
3@c  On-Line Applications Research Corporation (OAR).
4@c  All rights reserved.
6@c  $Id$
9@chapter CPU Model Dependent Features
11@section Introduction
13Microprocessors are generally classified into
14families with a variety of CPU models or implementations within
15that family.  Within a processor family, there is a high level
16of binary compatibility.  This family may be based on either an
17architectural specification or on maintaining compatibility with
18a popular processor.  Recent microprocessor families such as the
19SPARC or PA-RISC are based on an architectural specification
20which is independent or any particular CPU model or
21implementation.  Older families such as the M68xxx and the iX86
22evolved as the manufacturer strived to produce higher
23performance processor models which maintained binary
24compatibility with older models.
26RTEMS takes advantage of the similarity of the
27various models within a CPU family.  Although the models do vary
28in significant ways, the high level of compatibility makes it
29possible to share the bulk of the CPU dependent executive code
30across the entire family.
32@section CPU Model Feature Flags
34Each processor family supported by RTEMS has a
35list of features which vary between CPU models
36within a family.  For example, the most common model dependent
37feature regardless of CPU family is the presence or absence of a
38floating point unit or coprocessor.  When defining the list of
39features present on a particular CPU model, one simply notes
40that floating point hardware is or is not present and defines a
41single constant appropriately.  Conditional compilation is
42utilized to include the appropriate source code for this CPU
43model's feature set.  It is important to note that this means
44that RTEMS is thus compiled using the appropriate feature set
45and compilation flags optimal for this CPU model used.  The
46alternative would be to generate a binary which would execute on
47all family members using only the features which were always
50This section presents the set of features which vary
51across SPARC implementations and are of importance to RTEMS.
52The set of CPU model feature macros are defined in the file
53cpukit/score/cpu/sparc/sparc.h based upon the particular CPU
54model defined on the compilation command line.
56@subsection CPU Model Name
58The macro CPU_MODEL_NAME is a string which designates
59the name of this CPU model.  For example, for the European Space
60Agency's ERC32 SPARC model, this macro is set to the string
63@subsection Floating Point Unit
65The macro SPARC_HAS_FPU is set to 1 to indicate that
66this CPU model has a hardware floating point unit and 0
69@subsection Bitscan Instruction
71The macro SPARC_HAS_BITSCAN is set to 1 to indicate
72that this CPU model has the bitscan instruction.  For example,
73this instruction is supported by the Fujitsu SPARClite family.
75@subsection Number of Register Windows
78indicate the number of register window sets implemented by this
79CPU model.  The SPARC architecture allows a for a maximum of
80thirty-two register window sets although most implementations
81only include eight.
83@subsection Low Power Mode
85The macro SPARC_HAS_LOW_POWER_MODE is set to one to
86indicate that this CPU model has a low power mode.  If low power
87is enabled, then there must be CPU model specific implementation
88of the IDLE task in cpukit/score/cpu/sparc/cpu.c.  The low
89power mode IDLE task should be of the form:
92while ( TRUE ) @{
93  enter low power mode
95@end example
97The code required to enter low power mode is CPU model specific.
99@section CPU Model Implementation Notes
101The ERC32 is a custom SPARC V7 implementation based on the Cypress 601/602
102chipset.  This CPU has a number of on-board peripherals and was developed by
103the European Space Agency to target space applications.  RTEMS currently
104provides support for the following peripherals:
106@itemize @bullet
107@item UART Channels A and B
108@item General Purpose Timer
109@item Real Time Clock
110@item Watchdog Timer (so it can be disabled)
111@item Control Register (so powerdown mode can be enabled)
112@item Memory Control Register
113@item Interrupt Control
114@end itemize
116The General Purpose Timer and Real Time Clock Timer provided with the ERC32
117share the Timer Control Register.  Because the Timer Control Register is write
118only, we must mirror it in software and insure that writes to one timer do not
119alter the current settings and status of the other timer.  Routines are
120provided in erc32.h which promote the view that the two timers are completely
121independent.  By exclusively using these routines to access the Timer Control
122Register, the application can view the system as having a General Purpose
123Timer Control Register and a Real Time Clock Timer Control Register
124rather than the single shared value.
126The RTEMS Idle thread take advantage of the low power mode provided by the
127ERC32.  Low power mode is entered during idle loops and is enabled at
128initialization time.
Note: See TracBrowser for help on using the repository browser.