source: rtems/doc/supplements/arm/timeBSP.t @ 8d7393a

4.104.114.84.9
Last change on this file since 8d7393a was 8d7393a, checked in by Joel Sherrill <joel.sherrill@…>, on Jul 30, 2002 at 9:43:53 PM

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

  • BSP_TIMES, ChangeLog?, Makefile.am, arm.texi, bsp.t, callconv.t, cpumodel.t, cputable.t, fatalerr.t, intr_NOTIMES.t, memmodel.t, preface.texi, stamp-vti, timeBSP.t, timing.texi, version.texi, wksheets.texi: New files as ARM supplement initial version added.
  • 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 MYBSP Timing Data
15
16@section Introduction
17
18The timing data for the ARM 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 ARM 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
30MYBSP CPU board.  The MYBSP is a RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ
31Mhz board with SDRAM and no numeric coprocessor.  A
32countdown timer on this board was used to measure
33elapsed time with a 20 nanosecond resolution.  All
34sources of hardware interrupts were disabled, although the
35interrupt level of the ARM microprocessor allows all interrupts.
36
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 ARM9DTMI 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 TBD to simulate a TBD Mhz processor.  It
45should be noted that the worst case instruction times
46assume that the internal cache is disabled and that no
47instructions overlap.
48
49@section Interrupt Latency
50
51The maximum period with interrupts disabled within
52RTEMS is less than RTEMS_MAXIMUM_DISABLE_PERIOD
53microseconds including the instructions
54which disable and re-enable interrupts.  The time required for
55the processor to vector an interrupt and for the RTEMS entry
56overhead before invoking the user's interrupt handler are a
57total of RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK
58microseconds.  These combine to yield a worst case
59interrupt latency of less than
60RTEMS_MAXIMUM_DISABLE_PERIOD + RTEMS_INTR_ENTRY_RETURNS_TO_PREEMPTING_TASK
61microseconds at RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ
62Mhz.  [NOTE:  The maximum period with interrupts
63disabled was last determined for Release
64RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.]
65
66It should be noted again that the maximum period with
67interrupts disabled within RTEMS is hand-timed and based upon
68worst case (i.e. CPU cache disabled and no instruction overlap)
69times for a RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ Mhz processor. 
70The interrupt vector and entry
71overhead time was generated on an MYBSP benchmark platform
72using the Multiprocessing Communications registers to generate
73as the interrupt source.
74
75@section Context Switch
76
77The RTEMS processor context switch time is RTEMS_NO_FP_CONTEXTS
78microseconds on the MYBSP benchmark platform when no floating
79point context is saved or restored.  Additional execution time
80is required when a TASK_SWITCH user extension is configured.
81The use of the TASK_SWITCH extension is application dependent.
82Thus, its execution time is not considered part of the raw
83context switch time.
84
85The ARM processor benchmarked does not have a floating point
86unit and consequently no FPU results are reported.
87
88@c Since RTEMS was designed specifically for embedded
89@c missile applications which are floating point intensive, the
90@c executive is optimized to avoid unnecessarily saving and
91@c restoring the state of the numeric coprocessor.  The state of
92@c the numeric coprocessor is only saved when an FLOATING_POINT
93@c task is dispatched and that task was not the last task to
94@c utilize the coprocessor.  In a system with only one
95@c FLOATING_POINT task, the state of the numeric coprocessor will
96@c never be saved or restored.  When the first FLOATING_POINT task
97@c is dispatched, RTEMS does not need to save the current state of
98@c the numeric coprocessor.
99
100@c The exact amount of time required to save and restore
101@c floating point context is dependent on whether an XXX or
102@c XXX is being used as well as the state of the numeric
103@c coprocessor.  These numeric coprocessors define three operating
104@c states: initialized, idle, and busy.  RTEMS places the
105@c coprocessor in the initialized state when a task is started or
106@c restarted.  Once the task has utilized the coprocessor, it is in
107@c the idle state when floating point instructions are not
108@c executing and the busy state when floating point instructions
109@c are executing.  The state of the coprocessor is task specific.
110
111The following table summarizes the context switch
112times for the MYBSP benchmark platform:
113
Note: See TracBrowser for help on using the repository browser.