source: rtems/doc/supplements/sh/timeBSP.t @ 0b93b978

4.104.114.84.95
Last change on this file since 0b93b978 was 0b93b978, checked in by Joel Sherrill <joel.sherrill@…>, on Jul 31, 2002 at 12:17:12 AM

2002-07-30 Joel Sherrill <joel@…>

  • intr_NOTIMES.t, timeBSP.t: Replaced XXX's with real info.
  • Property mode set to 100644
File size: 4.7 KB
Line 
1@c
2@c  COPYRIGHT (c) 1988-2002.
3@c  On-Line Applications Research Corporation (OAR).
4@c  All rights reserved.
5@c
6@c  $Id$
7@c
8
9@include common/timemac.texi
10@tex
11\global\advance \smallskipamount by -4pt
12@end tex
13
14@chapter BSP_FOR_TIMES Timing Data
15
16@section Introduction
17
18The timing data for the SH version of RTEMS is
19provided along with the target dependent aspects concerning the
20gathering of the timing data.  The hardware platform used to
21gather the times is described to give the reader a better
22understanding of each directive time provided.  Also, provided
23is a description of the interrupt latency and the context switch
24times as they pertain to the SH version of RTEMS.
25
26@section Hardware Platform
27
28All times reported except for the maximum period
29interrupts are disabled by RTEMS were measured using a Motorola
30BSP_FOR_TIMES CPU board.  The BSP_FOR_TIMES is a RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ
31Mhz board with one wait
32state dynamic memory and a XXX numeric coprocessor.  The
33Zilog 8036 countdown timer on this board was used to measure
34elapsed time with a one-half microsecond resolution.  All
35sources of hardware interrupts were disabled, although the
36interrupt level of the XXX allows all interrupts.
37
38The maximum period interrupts are disabled was
39measured by summing the number of CPU cycles required by each
40assembly language instruction executed while interrupts were
41disabled.  The worst case times of the XXX microprocessor
42were used for each instruction.  Zero wait state memory was
43assumed.  The total CPU cycles executed with interrupts
44disabled, including the instructions to disable and enable
45interrupts, was divided by 20 to simulate a RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ
46Mhz processor.  It
47should be noted that the worst case instruction times for the
48processor assume that the internal cache is disabled and that no
49instructions overlap.
50
51@section Interrupt Latency
52
53The maximum period with interrupts disabled within
54RTEMS is less than RTEMS_MAXIMUM_DISABLE_PERIOD
55microseconds including the instructions
56which disable and re-enable interrupts.  The time required for
57the processor to vector an interrupt and for the RTEMS entry
58overhead before invoking the user's interrupt handler are a
59total of RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK
60microseconds.  These combine to yield a worst case
61interrupt latency of less than
62RTEMS_MAXIMUM_DISABLE_PERIOD + RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK
63microseconds at RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ
64Mhz.  [NOTE:  The maximum period with interrupts
65disabled was last determined for Release
66RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.]
67
68It should be noted again that the maximum period with
69interrupts disabled within RTEMS is hand-timed and based upon
70worst case (i.e. CPU cache disabled and no instruction overlap)
71times for a RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ
72Mhz processor.  The interrupt vector and entry
73overhead time was generated on an BSP_FOR_TIMES benchmark platform
74using the Multiprocessing Communications registers to generate
75as the interrupt source.
76
77@section Context Switch
78
79The RTEMS processor context switch time is RTEMS_NO_FP_CONTEXTS
80microseconds on the BSP_FOR_TIMES benchmark platform when no floating
81point context is saved or restored.  Additional execution time
82is required when a TASK_SWITCH user extension is configured.
83The use of the TASK_SWITCH extension is application dependent.
84Thus, its execution time is not considered part of the raw
85context switch time.
86
87Since RTEMS was designed specifically for embedded
88missile applications which are floating point intensive, the
89executive is optimized to avoid unnecessarily saving and
90restoring the state of the numeric coprocessor.  The state of
91the numeric coprocessor is only saved when an FLOATING_POINT
92task is dispatched and that task was not the last task to
93utilize the coprocessor.  In a system with only one
94FLOATING_POINT task, the state of the numeric coprocessor will
95never be saved or restored.  When the first FLOATING_POINT task
96is dispatched, RTEMS does not need to save the current state of
97the numeric coprocessor.
98
99The exact amount of time required to save and restore
100floating point context is dependent on whether an XXX or
101XXX is being used as well as the state of the numeric
102coprocessor.  These numeric coprocessors define three operating
103states: initialized, idle, and busy.  RTEMS places the
104coprocessor in the initialized state when a task is started or
105restarted.  Once the task has utilized the coprocessor, it is in
106the idle state when floating point instructions are not
107executing and the busy state when floating point instructions
108are executing.  The state of the coprocessor is task specific.
109
110The following table summarizes the context switch
111times for the BSP_FOR_TIMES benchmark platform:
112
Note: See TracBrowser for help on using the repository browser.