1 | @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 $Id$ |
---|
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 | |
---|