hirner 3.2
`
`http://web.archive.org/web/20020927070327/http://vasc.ri.cmu.edulold_...
`
`Chimera 3.2
`
`A real-time operating system developed at CMU which isßr better than anything else you'lljmnd on
`the market.
`
`Table of Contents
`
`Overview
`Examples
`Cool Stuff
`Refe ren e e s
`See Also
`VASC Contact
`Ilistory
`
`Overview
`
`The Chimera 3.2 Real-Time Operating System has its own HTML page which more than adequately
`covers what it does, and how to use it. Let me therefore take this opportunity to answer the question,
`"Why use Chimera instead of VxWorks?" (Besides the fact that it has a wonderful graphical interface
`called Onika , I mean.)
`
`Here's what Chimera inventor David B. Stewart has to say on the subject:
`
`Frequently Asked Questions about Chimera vs. VxWorks
`
`Q: What are the similarities and differences between the VxWorks and Chimera real-time kernels?
`
`A: As with most other commercial real-time operating systems, VxWorks only provides a basic
`real-time kernel which gives you task management, low-overhead context switching and local
`semaphores, static highest priority first scheduling, and an interface to program the hardware timers
`for periodic events.
`
`Chimera provides an extended real-time kernel. h addition to all the basic functions that VxWorks
`provides, it also gives you both static and dynamic real-time scheduling, virtual timers which eliminate
`the need to explicitly program hardware timers, the novel deadline failure handling and global error
`handling mechanisms, and two-level device driver support.
`
`Q: Chimera claims it is a "multiprocessor operating system", while VxWorks only claims it has
`"multiprocessor support". What is the difference?
`
`A: VxWorks is only a single-processor operating system with multiprocessor extensions. Those
`
`)f7
`
`l0/7/20133:I6PM
`
`Page 1 of 7
`
`

`

`hirner 3.2
`
`http://web.archive.org/web/20020927070327/http://vasc.ri.cmu.edulold_...
`
`Chimera 3.2
`
`A real-time operating system developed at CMU which isßr better than anything else you'lljmnd on
`the market.
`
`Table of Contents
`
`Overview
`Examples
`Cool Stuff
`Refe ren e e s
`See Also
`VASC Contact
`Ilistory
`
`Overview
`
`The Chimera 3.2 Real-Time Operating System has its own HTML page which more than adequately
`covers what it does, and how to use it. Let me therefore take this opportunity to answer the question,
`"Why use Chimera instead of VxWorks?" (Besides the fact that it has a wonderful graphical interface
`called Onika , I mean.)
`
`Here's what Chimera inventor David B. Stewart has to say on the subject:
`
`Frequently Asked Questions about Chimera vs. VxWorks
`
`Q: What are the similarities and differences between the VxWorks and Chimera real-time kernels?
`
`A: As with most other commercial real-time operating systems, VxWorks only provides a basic
`real-time kernel which gives you task management, low-overhead context switching and local
`semaphores, static highest priority first scheduling, and an interface to program the hardware timers
`for periodic events.
`
`Chimera provides an extended real-time kernel. h addition to all the basic functions that VxWorks
`provides, it also gives you both static and dynamic real-time scheduling, virtual timers which eliminate
`the need to explicitly program hardware timers, the novel deadline failure handling and global error
`handling mechanisms, and two-level device driver support.
`
`Q: Chimera claims it is a "multiprocessor operating system", while VxWorks only claims it has
`"multiprocessor support". What is the difference?
`
`A: VxWorks is only a single-processor operating system with multiprocessor extensions. Those
`
`)f7
`
`l0/7/20133:I6PM
`
`Page 1 of 7
`
`

`

`Chimera 3.2
`
`hEtp://web.arcliive.org/weh/20020927070327/hLtp://vasc.ri.cmu.ednluld
`
`extensions involve networking multiple VxWorks systems over the backplane using the TCP/IP
`protocol. The only difference is that the communication medium is the backplane, and not ethernet.
`This setup is no more a multiprocessor setup than two SLIn workstations on the same local area
`ne t work.
`
`Chimera is a multiprocessor operating system because the kernels on multiple Real-Time Processing
`Units (RTPUs -- i.e. single board computers) can communicate with each other via Chimera's high
`performance system-level communication, called express mail. Without such kernel-level
`interprocessor communication, an operating system cannot make interprocessor communication
`transparent to the user's programs running on each RTPU, and limit both the types of higher-level
`communication mechanisms that can be designed and their performance.
`
`Q: We have written a communications layer above VxWorks? Will this work with Chimera?
`
`A: Because Chimera is a multiprocessor operating system, there is no need for such a
`communications layet. Almost anyone using multiple processors and VxWorlcs is required to write
`such a layer, because 01' VxWorks' lack of multiprocessor support. In Chimera, all the communication
`mechanisms are built-in to the operating system. so you don't have to write them. Because they are
`built-in, everyone uses the same ones as opposed to what happens today with projects using
`VxWorks. where every project or institution has their own custom layer. thus limiting any potential
`software reuse or technology transfer.
`
`Q: What are the communication mechanisms available in Chimera, and how does each compare to
`V xWorlcs?
`
`A: Here is a quick rundown of most of them:
`
`- Express Mail: thïs is a high-performance real-time non-blocking communication mechnism between
`the kernels on each RTPU and (he host workstation. This mechanism allows the other interprocessor
`communicauon and synchronization mechanism to operate ti-ansparently across multiple processors.
`
`- Global Shared Memory: tasks can dynamically create and attach to shared memory on any
`processor, and access that shared memory, BecaLise of the inter-kernel communication in Chimera, all
`the VMEhus address offsets can be calculated automatically during the initialization of the shared
`memory. and all operations are transparent to which processor the segment is actually on. In
`VxWorks. addresses of shared memory segments mLtst he hard-coded into user's code, with the
`olisets (with are RTPLJ dependent) also added manLtally. This makes the code non-portable. and
`dikhcu lt ro maintain if the hard ware con figurations are changed, as each hard ware change requires a
`mod itication o f the soLlrce code. The only reason this is available in V xWorks is becaLise the
`V M [bus allows it: i.e. V xWTorks makes no special provisions for global shared memory. In Ch niera.
`no such modifications are req Li ired. and thc same executable can he run even i f the hase addresses of
`any of the RTPLs in the system arc changed.
`
`- Spin Locks: This is a front end to the lowest-level of interprocessor communicatioil using the
`atomic test-and-set (TAS) instructions. VxWorks lets you use the TAS instructions, hut do not
`provide a con ven cnt front-end [or using them and LILI tomatically timing out if the lock cannot be
`ohtLli ied.
`
`2u17
`
`In/7/20133:lop
`
`Page 2 of 7
`
`

`

`himer 3.2
`
`http://web.archive.org/web/20020927070327/http://vasc.ri.cmu.edu/old_...
`
`- Remote Semaphores: In addition to local semaphores, Chimera provides remote semaphores which
`allow tasks on all RTPUs to use a semaphore. VxWorks has only local semaphores; interrupts must
`explicitly be sent by the user if multiprocessor synchronization is required.
`
`- Prioritized Message Passing: Chimera's message passing is multiprocessor. Any task on any RTPU
`can send or receive a message to/from any queue. Messages can be retrieved either first-in-first-out,
`last-in-first-out, or highest-priority-first. In VxWorks, message passing is local to an RTPU. To send a
`message to a remote RTPU, either sockets must be used, or a communications layer must implement
`the message passing on top of shared memory with interrupts for signaling. It is not clear from
`VxWorks literature, but queues might only be first-in-first-out.
`
`- Global State Variable Table: Chimera provides this communication mechanism for predictable
`real-time communication and making efficient use of the VMEbus bandwidth. One global table
`exists, and every task which attaches to the table has a local copy of the parts of the table it needs.
`Updates of the local and global tables are done periodically and predictably. This is a 'must'
`communication mechanism for developing reconfigiirable software. VxWorks does not provide
`anything comparable.
`
`- Subsystem Multiprocessor Task Control: Chimera allows a task on one RTPU to control tasks (i.e.
`spawn, block, etc.) on multiple RTPUs. This is another feature required when developing
`reconfigurable software which must execute on multiple processors. VxWorks does not provide
`anything comparable.
`
`- Triple Buffer Comnunication Mechanism. This predictable real-time communication mechanism
`allows Chimera to communicate with other subsystems which may or may not be running Chimera,
`or to communicate with intelligent memory mapped 110 devices or special purpose processors. The
`code for the mechanism is extremely portable, so that it can be compiled to execute on any
`non-Chimera platform. VxWorks does not provide any such mechanisms.
`
`- Host Workstation Interface: Chimera allows processes on the host workstation to attach to the
`real-time environment by appearing to the RTPUs as just another RTPU. This allows communication
`between the host and RTPUs to occur in the same transparent manner that RTPUs communicate
`with each other. For example, a graphics application on the host can display real-time data by reading
`from a shared memory segment on one of the RTPUs. In VxWorks, any host-to-RTPU
`communication must be done through the ethernet, which is slow, less predictable, and much more
`difficult to program.
`
`- Transparent Host Procedure Calls: RTPUs can execute remote procedure calls on the host
`workstation, either to execute some non-real-time code or to obtain information that is otherwise not
`available on the RTPUs. For example, RTPUs have a physical clock, but they don't have a
`time-of-day clock. So callthg the function 'gettimeofdayo' is automatically transfered into a remote
`procedure call, and the time-of-day from the host is returned. An RTPU can also execute programs
`like 'ls, 'emacs', etc. These programs "appear" to run on the RTPU, but in fact execute on the host
`workstation, but the results are sent to the RTPU's 'stdout', and input is received from the RTPU's
`'stdin'.
`
`- Special Purpose Processors (SIP): Chimera treats special purpose processors, such as floating point
`
`)17
`
`lO/7/20133:I6PM
`
`Page 3 of 7
`
`

`

`Chimera 3.2
`
`http://web.archive.orglweh/20020927070327/hup://vasc.ri.cmu.ethr/old
`
`accelerators, LISP machines, and image processors. as slaves, which execute a short, efficient,
`non-preemptive executive. A programming running under Chimera can then execute a procedure
`remotely. The SPP drivers automatically handle the communication and synchronization between the
`RTPU and the SPR VxWorks has no equivalent interfaces.
`
`- Interrupts: Chimera provides a hardware indepedent interface for generating and handling both
`YMEbus and mailbox interrupts. Chimera also gives yOU 256 mailbox interrLtpts per RTPU. even if
`the RTPU only supports one or two mailbox interrupts (as is the case with most RTPUs). VxWorks
`does not provide any special support for interrupts; you are at the mercy of whatever the hardware
`gives you. and must program the hardware using non-portable code.
`
`Q: How does the hardware support compare between Chimera and VxWorks?
`
`Chimera has concentrated on providing as much functionality as possible along a single line of
`RTPUs. initially. However nothing precludes poviding support for multiple RTPU's. We expect that
`this will happen in due time. At present, though, VxWorks supports several different models of
`RTPUs.
`
`Chimera provides several device drivers for off-the-shelf I/O hardware, such as DAC, ADC, parallel
`I/O and serial I/O. VxWorlcs does not provide such drivers.
`
`Chimera also provides device drivers for some special purpose processors, allowing user's to access
`the S PP's through the Chimera generic SPP interface. VxWorks does not have any such drivers.
`Several SPP hardware vendors do sell VxWorks drivers; however, those drivers always have custom
`interfaces. thus making them non-portable with the interfaces of other SPPs.
`
`Q: How does the technical sLLlJport for Chimera software compare to the support given for VxWorks
`by Wind River Systems?
`
`Chimera Il did not have any official sLipport; however, those using Chimera Il can usually get an
`answer or bug fixes within a couple of days directly from the authors. With Chimera 3.0, similar
`support will be available from the authors. However, when the software is commercialized, it will be
`possible to buy a software support contract, in which case there will be officiai support.
`
`Q: What is the performance of Chimera vs. other RTOS?
`
`A: The biggest strength of Chimera is in all the added featu res which are not available in other
`real-time operating systems RTOS ) . However. despite the additional fLlnct ionality, Chimera's
`performance is at par with V xWorks and other RTOS. Some benchmarks for real-time kernels were
`puhlished comparïng a few commercial RTOS ( A. Topper, 'A compLiting architecture for a nuiltiple
`robot controller, M.S. Thesis, McGill Universïty). Those same benchmarks were executed on
`Chimera. lollowing are the results:
`
`F NOTE: The authors are providing these resLilts without any explicit or implied warranties.]
`
`4017
`
`!O/7/20[33:IÚP
`
`Page 4 of 7
`
`

`

`:himerp 3.2
`
`http://web.archive.org/web/20020927070327/hLtp://vasc.ri.cmu.edu/old_...
`
`Queue Fill
`Queue Drain
`Queue Fill/Drain
`Queue Fill, Urgent
`Alternate Queue F/D
`Allocate Memory
`Deallocate Memory
`
`46
`43
`91
`47
`238
`40
`38
`
`26
`29
`59
`27
`252
`27
`33
`
`140
`132
`278
`170
`867
`57
`20
`
`20*
`22*
`44*
`72*
`371*
`68
`83
`
`66*
`61*
`120'
`67'
`570'
`42
`36
`
`* VxWorks does not support message passing. These times are from simulating message passing
`through the use of shared memory. Note: the times above are as quoted in the thesis. This must have
`been an older version of VxWorks, since VxWorks now has a message passing mechanism described
`in their sales brochures. The numbers given in the sales brochure are the following:
`
`msgQSend
`o no tasks pending: 77
`o task pending: 129
`o queue full: 68
`o msgQReceive
`o message avai1able 73
`o message unavai1ab1e 65
`
`Based on these numbers, we would expect the Queue Fifi to be 77, Queue Drain to be 73, Queue
`to be at least 450. It is unclear whether "Queue Fifi,
`FiIJJDrain to be 150, and Alternate Queue F
`Urgent" is possible, as the sales brochure does not specify if messages can have priorities.
`
`A Chimera's message passing is a multiprocessor mechanism. Chimera's kernel does not have built-in
`message passing. The timings are for local messages when using the multiprocessor message passing
`mechanism in the Chimera communication library.
`
`Q: With VxWorks, an RTPU can communicate directly with a different computer system on the
`network Can I do anything hice that in Chimera, considering you don't yet support ethet net in the
`bacicplane?
`
`A: Yes, you can. Chimera allows communication by an RTPU over ethernet with other systems by
`using the host workstation's ethernet. An easy to use interface is a front end to the awkward socket()
`interface required to send and receive messages over ethernet. Going through the host workstation is
`completely tiansparent to the programmer With this setup, you have not lost any performance as
`compared to VxWorks, which does support an ethernet in the backplane in VxWorks, one RTPU
`still has to communicate to the RTPU hostmg the ethernet However, the Chimeia design iemains
`consistent with the globalllocal operatmg system decomposition, where the local opeiatmg system
`peifoims all the real-time stuff, and the global operatmg system takes care of the non-i eal-time or
`soft-real-time stuff HIce the file system, workstation graphics, and networking.
`
`Q: Chimera 3.0 is advertised as a real-time operating system for "reconfigurable sensor-based control
`systems". Why is it preferred to use Chimera over VxWorks for reconfigurable systems?
`
`A: In order for a software module to be reconfigurable, it must satisfy the two following conditions:
`I - the module is independent of target hardware 2- the module is independent of target application
`
`Because multiprocessor operations on VxWorks are not transparent, and VxWorks does not provide
`any generic interfaces to special purpose processors or sensors and actuators, the first condition
`
`)f7
`
`IO/7/20133:IÓPM
`
`Page 5 of 7
`
`

`

`Chimera 3.2
`
`hnp://weh.arehive.org/web/20020927070327/hitp://vasc.ri.cniu.ethJold
`
`above is violated.
`
`All Chimera multiprocessor communication is hardware independent. Chimera also has two-level
`device driver support ['or I/O devices and sensor-actuator interfaces, and a generic SPP interface.
`providing additional hardware independence to non-general-purpose-CPU hardware.
`
`Chimera has many tools built-in to the operating system to support the reconfigurable software
`framework being developed at CMU. The state variable table mechanism, configuration tile reading
`utility, and subsystem task control mechanisms are but a sample of those tools, which simplify the
`task of writing reconfigurable software modules which are independent of the target application.
`Since VxWorks does not have any such tools, it is easier to satisfy the second condition using
`Chimera than it is when using VxWorks.
`
`Q: Our managers say that we should use VxWorks because it would keep us compatible with other
`institutions and other projects. Why should we break this trend and use Chimera?
`
`A: Unfortunately this is a myth that far too many people believe. Jtist because multiple
`projects/centers use the same operating system does not mean that they will have *any* code that is
`reusable or compatible between them. lt is a standard software architecture, and not the operating
`system. that provides compatibility between mii Itiple projccts. Since VxWorks does not provide
`support for any specific software architecture, every project uses its own architecture, and hence
`despite using the same operating system, the applications are not at ail compatible.
`
`Here is an example of a similar situation. Consider two projects, each tising Sun SPAkCstations with
`SILnOS 4.0. One of them uses SunView, while the other is uses X windows. You develop a graphics
`application for X windows. It is NOT compatible with the other project using SLinView, even though
`both are running under the same operating system. However, a third project is using u DEC PMAX,
`rLlnning Ultrix 3.2, and X windows. The graphics application DOES run on the DEC. even though it
`is using a completely different hardware architecture and a completely different operating system.
`The reason is they are both Lising the X li R5 standard protocol, which is a standard software
`architecture for window apphcations.
`
`When developing applications under Chimera, we recommend that the reconfigurahie software
`framework he used, so that multiple applications at multiple institutions are compatible with each
`other. If one project uses the framework, and the other doesn't, then you won't have compatibility
`between those projects. The advantage of Chimera over VxWorks in this case is that Chimera gives
`VOLI all the tools necessary to easily uric! qu icklv imp lernen t an application based on the recon figurable
`software framework. V xWorks, on the other hand, has no corresponding so ftware architecture, and
`no correspond ing tools. Every project must then develop their own architecture and tools. and hence
`application development takes a lot more time, and the application is nor compatible with the
`applications in other projects or centers.
`
`In su mmary. maintaining consistency between nui Itiple project is NOT a function o f the operating
`system: it is a function o f the software architecture.
`
`Examples
`
`óof7
`
`iO/7/20i33:i6P
`
`Page 6 of 7
`
`

`

`hirnera 3.2
`
`http://web.archive.orglweb/20020927070327/http://vasc.ri.cmu,edulold_...
`
`For visual examples, check out the Onilca HTML pa2e. If you want to use Chimera, here's what you
`need to do to your paths and environment
`
`setenv CHIMERA_ARCH $ARCH
`setenv CHIMERA_DIR -chimeralchim_3.2
`setemv CHIMERA_CONFIG $CHIMERA_DIR/config/chìmera.config. $HOST
`setenv CHIMERA_LOCAL your_top_directory_of_Chimera_software
`setpath PATH -i $CHIMERA_DIR/$CHIMERA_ARCH/bin
`
`Then it's just a matter of entering (on a machine which runs Chimera -- remember, only one one user
`at a time can run Chimera on any given machine):
`
`% chini
`
`Cool Stuff
`
`I really can't mention them all here; it's best for you to check out the Chimera 3.2 Real-Time
`Operating System page There's a huge manual on-line which gives programming examples, function
`definitions, and much more.
`
`References
`
`The Onika User's Manual, the Chimera 3.2 Users Manual.
`
`See Also
`
`Chimera, VxWorks, Onilca.
`
`History
`
`10/14/94 Created by Matt Gertz
`
`This page has been accessed
`
`4 i times.
`
`)f7
`
`I0/7f20133:IGPM
`
`Page 7 of 7
`
`