1 |
1026 |
ivang |
@c
|
2 |
|
|
@c Timing information for the DMV177
|
3 |
|
|
@c
|
4 |
|
|
@c COPYRIGHT (c) 1988-2002.
|
5 |
|
|
@c On-Line Applications Research Corporation (OAR).
|
6 |
|
|
@c All rights reserved.
|
7 |
|
|
@c
|
8 |
|
|
@c timeDMV177.t,v 1.7 2002/01/17 21:47:46 joel Exp
|
9 |
|
|
@c
|
10 |
|
|
|
11 |
|
|
@include common/timemac.texi
|
12 |
|
|
@tex
|
13 |
|
|
\global\advance \smallskipamount by -4pt
|
14 |
|
|
@end tex
|
15 |
|
|
|
16 |
|
|
@chapter RTEMS_BSP Timing Data
|
17 |
|
|
|
18 |
|
|
@section Introduction
|
19 |
|
|
|
20 |
|
|
The timing data for RTEMS on the DY-4 RTEMS_BSP board
|
21 |
|
|
is provided along with the target
|
22 |
|
|
dependent aspects concerning the gathering of the timing data.
|
23 |
|
|
The hardware platform used to gather the times is described to
|
24 |
|
|
give the reader a better understanding of each directive time
|
25 |
|
|
provided. Also, provided is a description of the interrupt
|
26 |
|
|
latency and the context switch times as they pertain to the
|
27 |
|
|
PowerPC version of RTEMS.
|
28 |
|
|
|
29 |
|
|
@section Hardware Platform
|
30 |
|
|
|
31 |
|
|
All times reported in this chapter were measured using a RTEMS_BSP board.
|
32 |
|
|
All data and code caching was disabled. This results in very deterministic
|
33 |
|
|
times which represent the worst possible performance. Many embedded
|
34 |
|
|
applications disable caching to insure that execution times are
|
35 |
|
|
repeatable. Moreover, the JTAG port on certain revisions of the PowerPC
|
36 |
|
|
603e does not operate properly if caching is enabled. Thus during
|
37 |
|
|
development and debug, caching must be off.
|
38 |
|
|
|
39 |
|
|
The PowerPC decrementer register was was used to gather
|
40 |
|
|
all timing information. In the PowerPC architecture,
|
41 |
|
|
this register typically counts
|
42 |
|
|
something like CPU cycles or is a function of the clock
|
43 |
|
|
speed. On the PPC603e decrements once for every four (4) bus cycles.
|
44 |
|
|
On the RTEMS_BSP, the bus operates at a clock speed of
|
45 |
|
|
33 Mhz. This result in a very accurate number since it is a function of the
|
46 |
|
|
microprocessor itself. Thus all measurements in this
|
47 |
|
|
chapter are reported as the actual number of decrementer
|
48 |
|
|
clicks reported.
|
49 |
|
|
|
50 |
|
|
To convert the numbers reported to microseconds, one should
|
51 |
|
|
divide the number reported by 8.650752. This number was derived as
|
52 |
|
|
shown below:
|
53 |
|
|
|
54 |
|
|
@example
|
55 |
|
|
((33 * 1048576) / 1000000) / 4 = 8.650752
|
56 |
|
|
@end example
|
57 |
|
|
|
58 |
|
|
All sources of hardware interrupts were disabled,
|
59 |
|
|
although traps were enabled and the interrupt level of the
|
60 |
|
|
PowerPC allows all interrupts.
|
61 |
|
|
|
62 |
|
|
@section Interrupt Latency
|
63 |
|
|
|
64 |
|
|
The maximum period with traps disabled or the
|
65 |
|
|
processor interrupt level set to it's highest value inside RTEMS
|
66 |
|
|
is less than RTEMS_MAXIMUM_DISABLE_PERIOD
|
67 |
|
|
microseconds including the instructions which
|
68 |
|
|
disable and re-enable interrupts. The time required for the
|
69 |
|
|
PowerPC to vector an interrupt and for the RTEMS entry overhead
|
70 |
|
|
before invoking the user's trap handler are a total of
|
71 |
|
|
RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK
|
72 |
|
|
microseconds. These combine to yield a worst case interrupt
|
73 |
|
|
latency of less than RTEMS_MAXIMUM_DISABLE_PERIOD +
|
74 |
|
|
RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK microseconds at
|
75 |
|
|
RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ Mhz.
|
76 |
|
|
[NOTE: The maximum period with interrupts disabled was last
|
77 |
|
|
determined for Release RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.]
|
78 |
|
|
|
79 |
|
|
The maximum period with interrupts disabled within
|
80 |
|
|
RTEMS is hand-timed with some assistance from the PowerPC simulator.
|
81 |
|
|
The maximum period with interrupts disabled with RTEMS has not
|
82 |
|
|
been calculated on this target.
|
83 |
|
|
|
84 |
|
|
The interrupt vector and entry overhead time was
|
85 |
|
|
generated on the PSIM benchmark platform using the PowerPC's
|
86 |
|
|
decrementer register. This register was programmed to generate
|
87 |
|
|
an interrupt after one countdown.
|
88 |
|
|
|
89 |
|
|
@section Context Switch
|
90 |
|
|
|
91 |
|
|
The RTEMS processor context switch time is RTEMS_NO_FP_CONTEXTS
|
92 |
|
|
bus cycle on the RTEMS_BSP benchmark platform when no floating
|
93 |
|
|
point context is saved or restored. Additional execution time
|
94 |
|
|
is required when a TASK_SWITCH user extension is configured.
|
95 |
|
|
The use of the TASK_SWITCH extension is application dependent.
|
96 |
|
|
Thus, its execution time is not considered part of the raw
|
97 |
|
|
context switch time.
|
98 |
|
|
|
99 |
|
|
Since RTEMS was designed specifically for embedded
|
100 |
|
|
missile applications which are floating point intensive, the
|
101 |
|
|
executive is optimized to avoid unnecessarily saving and
|
102 |
|
|
restoring the state of the numeric coprocessor. The state of
|
103 |
|
|
the numeric coprocessor is only saved when an FLOATING_POINT
|
104 |
|
|
task is dispatched and that task was not the last task to
|
105 |
|
|
utilize the coprocessor. In a system with only one
|
106 |
|
|
FLOATING_POINT task, the state of the numeric coprocessor will
|
107 |
|
|
never be saved or restored. When the first FLOATING_POINT task
|
108 |
|
|
is dispatched, RTEMS does not need to save the current state of
|
109 |
|
|
the numeric coprocessor.
|
110 |
|
|
|
111 |
|
|
The following table summarizes the context switch
|
112 |
|
|
times for the RTEMS_BSP benchmark platform:
|
113 |
|
|
|