source: rtems/doc/supplements/mips/timeBSP.t @ 891d63bd
Last change on this file since 891d63bd was 891d63bd, checked in by Joel Sherrill <joel.sherrill@…>, on 02/14/02 at 22:14:59

2002-02-04 Joel Sherrill <joel@…>

  • bsp.t, BSP_TIMES, callconv.t, ChangeLog?, cpumodel.t, cputable.t, fatalerr.t, intr_NOTIMES.t,, memmodel.t, mips.texi, preface.texi, stamp-vti, timeBSP.t, version.texi: New files.
  • Property mode set to 100644
File size: 4.5 KB
2@c  COPYRIGHT (c) 1988-2002.
3@c  On-Line Applications Research Corporation (OAR).
4@c  All rights reserved.
6@c  $Id$
9@include common/timemac.texi
11\global\advance \smallskipamount by -4pt
12@end tex
14@chapter BSP_FOR_TIMES Timing Data
16@section Introduction
18The timing data for the XXX 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 XXX version of RTEMS.
26@section Hardware Platform
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 20Mhz board with one wait
31state dynamic memory and a XXX numeric coprocessor.  The
32Zilog 8036 countdown timer on this board was used to measure
33elapsed time with a one-half microsecond resolution.  All
34sources of hardware interrupts were disabled, although the
35interrupt level of the XXX allows all interrupts.
37The maximum period interrupts are disabled was
38measured by summing the number of CPU cycles required by each
39assembly language instruction executed while interrupts were
40disabled.  The worst case times of the XXX microprocessor
41were used for each instruction.  Zero wait state memory was
42assumed.  The total CPU cycles executed with interrupts
43disabled, including the instructions to disable and enable
44interrupts, was divided by 20 to simulate a 20Mhz XXX.  It
45should be noted that the worst case instruction times for the
46XXX assume that the internal cache is disabled and that no
47instructions overlap.
49@section Interrupt Latency
51The maximum period with interrupts disabled within
53microseconds including the instructions
54which disable and re-enable interrupts.  The time required for
55the XXX to vector an interrupt and for the RTEMS entry
56overhead before invoking the user's interrupt handler are a
58microseconds.  These combine to yield a worst case
59interrupt latency of less than
61microseconds at 20Mhz.  [NOTE:  The maximum period with interrupts
62disabled was last determined for Release
65It should be noted again that the maximum period with
66interrupts disabled within RTEMS is hand-timed and based upon
67worst case (i.e. CPU cache disabled and no instruction overlap)
68times for a 20Mhz XXX.  The interrupt vector and entry
69overhead time was generated on an BSP_FOR_TIMES benchmark platform
70using the Multiprocessing Communications registers to generate
71as the interrupt source.
73@section Context Switch
75The RTEMS processor context switch time is RTEMS_NO_FP_CONTEXTS
76microseconds on the BSP_FOR_TIMES benchmark platform when no floating
77point context is saved or restored.  Additional execution time
78is required when a TASK_SWITCH user extension is configured.
79The use of the TASK_SWITCH extension is application dependent.
80Thus, its execution time is not considered part of the raw
81context switch time.
83Since RTEMS was designed specifically for embedded
84missile applications which are floating point intensive, the
85executive is optimized to avoid unnecessarily saving and
86restoring the state of the numeric coprocessor.  The state of
87the numeric coprocessor is only saved when an FLOATING_POINT
88task is dispatched and that task was not the last task to
89utilize the coprocessor.  In a system with only one
90FLOATING_POINT task, the state of the numeric coprocessor will
91never be saved or restored.  When the first FLOATING_POINT task
92is dispatched, RTEMS does not need to save the current state of
93the numeric coprocessor.
95The exact amount of time required to save and restore
96floating point context is dependent on whether an XXX or
97XXX is being used as well as the state of the numeric
98coprocessor.  These numeric coprocessors define three operating
99states: initialized, idle, and busy.  RTEMS places the
100coprocessor in the initialized state when a task is started or
101restarted.  Once the task has utilized the coprocessor, it is in
102the idle state when floating point instructions are not
103executing and the busy state when floating point instructions
104are executing.  The state of the coprocessor is task specific.
106The following table summarizes the context switch
107times for the BSP_FOR_TIMES benchmark platform:
Note: See TracBrowser for help on using the repository browser.