1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
|
@c
@c COPYRIGHT (c) 1988-1997.
@c On-Line Applications Research Corporation (OAR).
@c All rights reserved.
@c
@c $Id$
@c
@include ../common/timemac.texi
@tex
\global\advance \smallskipamount by -4pt
@end tex
@ifinfo
@node ERC32 Timing Data, ERC32 Timing Data Introduction, Memory Requirements RTEMS RAM Workspace Worksheet, Top
@end ifinfo
@chapter ERC32 Timing Data
@ifinfo
@menu
* ERC32 Timing Data Introduction::
* ERC32 Timing Data Hardware Platform::
* ERC32 Timing Data Interrupt Latency::
* ERC32 Timing Data Context Switch::
* ERC32 Timing Data Directive Times::
* ERC32 Timing Data Task Manager::
* ERC32 Timing Data Interrupt Manager::
* ERC32 Timing Data Clock Manager::
* ERC32 Timing Data Timer Manager::
* ERC32 Timing Data Semaphore Manager::
* ERC32 Timing Data Message Manager::
* ERC32 Timing Data Event Manager::
* ERC32 Timing Data Signal Manager::
* ERC32 Timing Data Partition Manager::
* ERC32 Timing Data Region Manager::
* ERC32 Timing Data Dual-Ported Memory Manager::
* ERC32 Timing Data I/O Manager::
* ERC32 Timing Data Rate Monotonic Manager::
@end menu
@end ifinfo
@ifinfo
@node ERC32 Timing Data Introduction, ERC32 Timing Data Hardware Platform, ERC32 Timing Data, ERC32 Timing Data
@end ifinfo
@section Introduction
The timing data for RTEMS on the ERC32 implementation
of the SPARC architecture is provided along with the target
dependent aspects concerning the gathering of the timing data.
The hardware platform used to gather the times is described to
give the reader a better understanding of each directive time
provided. Also, provided is a description of the interrupt
latency and the context switch times as they pertain to the
SPARC version of RTEMS.
@ifinfo
@node ERC32 Timing Data Hardware Platform, ERC32 Timing Data Interrupt Latency, ERC32 Timing Data Introduction, ERC32 Timing Data
@end ifinfo
@section Hardware Platform
All times reported in this chapter were measured
using the SPARC Instruction Simulator (SIS) developed by the
European Space Agency. SIS simulates the ERC32 -- a custom low
power implementation combining the Cypress 90C601 integer unit,
the Cypress 90C602 floating point unit, and a number of
peripherals such as counter timers, interrupt controller and a
memory controller.
For the RTEMS tests, SIS is configured with the
following characteristics:
@itemize @bullet
@item 15 Mhz clock speed
@item 0 wait states for PROM accesses
@item 0 wait states for RAM accesses
@end itemize
The ERC32's General Purpose Timer was used to gather
all timing information. This timer was programmed to operate
with one microsecond accuracy. All sources of hardware
interrupts were disabled, although traps were enabled and the
interrupt level of the SPARC allows all interrupts.
@ifinfo
@node ERC32 Timing Data Interrupt Latency, ERC32 Timing Data Context Switch, ERC32 Timing Data Hardware Platform, ERC32 Timing Data
@end ifinfo
@section Interrupt Latency
The maximum period with traps disabled or the
processor interrupt level set to it's highest value inside RTEMS
is less than RTEMS_MAXIMUM_DISABLE_PERIOD
microseconds including the instructions which
disable and re-enable interrupts. The time required for the
ERC32 to vector an interrupt and for the RTEMS entry overhead
before invoking the user's trap handler are a total of
RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK
microseconds. These combine to yield a worst case interrupt
latency of less than RTEMS_MAXIMUM_DISABLE_PERIOD +
RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK microseconds at
RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ Mhz.
[NOTE: The maximum period with interrupts disabled was last
determined for Release RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.]
The maximum period with interrupts disabled within
RTEMS is hand-timed with some assistance from SIS. The maximum
period with interrupts disabled with RTEMS occurs during a
context switch when traps are disabled to flush all the register
windows to memory. The length of time spent flushing the
register windows varies based on the number of windows which
must be flushed. Based on the information reported by SIS, it
takes from 4.0 to 18.0 microseconds (37 to 122 instructions) to
flush the register windows. It takes approximately 41 CPU
cycles (2.73 microseconds) to flush each register window set to
memory. The register window flush operation is heavily memory
bound.
[NOTE: All traps are disabled during the register
window flush thus disabling both software generate traps and
external interrupts. During a normal RTEMS critical section,
the processor interrupt level (pil) is raised to level 15 and
traps are left enabled. The longest path for a normal critical
section within RTEMS is less than 50 instructions.]
The interrupt vector and entry overhead time was
generated on the SIS benchmark platform using the ERC32's
ability to forcibly generate an arbitrary interrupt as the
source of the "benchmark" interrupt.
@ifinfo
@node ERC32 Timing Data Context Switch, RTEMS_CPU_MODEL Timing Data Directive Times, ERC32 Timing Data Interrupt Latency, ERC32 Timing Data
@end ifinfo
@section Context Switch
The RTEMS processor context switch time is 10
microseconds on the SIS benchmark platform when no floating
point context is saved or restored. Additional execution time
is required when a TASK_SWITCH user extension is configured.
The use of the TASK_SWITCH extension is application dependent.
Thus, its execution time is not considered part of the raw
context switch time.
Since RTEMS was designed specifically for embedded
missile applications which are floating point intensive, the
executive is optimized to avoid unnecessarily saving and
restoring the state of the numeric coprocessor. The state of
the numeric coprocessor is only saved when an FLOATING_POINT
task is dispatched and that task was not the last task to
utilize the coprocessor. In a system with only one
FLOATING_POINT task, the state of the numeric coprocessor will
never be saved or restored. When the first FLOATING_POINT task
is dispatched, RTEMS does not need to save the current state of
the numeric coprocessor.
The following table summarizes the context switch
times for the ERC32 benchmark platform:
@include timetbl.texi
@tex
\global\advance \smallskipamount by 4pt
@end tex
|
