BASIC ARCHITECTURE
In its simplest form,
a computer system consists of a CPU and memory interconnected by a bus
(Figure2.1).
There are three system wide buses: power, address, and data.
The power bus refers to the distribution of power to the various components of
the computer system; the address bus is the medium for exchanging individual
memory addresses, and therein the data bus is used to move data between the
various components in the system. When referring to the system bus, the address
and data buses collectively are generally what are meant.
For the most part, this book deals with single-processor
(uniprocessing) systems. Some real-time systems are multiprocessing in the
sense that there are many processors distributed in the system, and that these
are loosely coupled through messaging. Other real-time systems use
multiprocessing in a way that allows the processing system to schedule tasks
across the different processors. These types of systems are far more complex,
and the theory and tools available are generally impractical. Therefore, this
text will concentrate on uniprocessing real-time systems. Even here the
challenges are significant.
HARDWARE INTERFACING
The following sections contain discussions that are slanted
toward the software or systems engineer rather than the electrical engineer.
That is, the intent is not to be able to design these hardware structures, but
rather to understand their behavior in the context of embedded real-time systems.
Latching
In signaling between devices is it is important to have a
mechanism for “recording” the appearance of that signal for later processing.
This process is called latching. In essence, latching involves setting a flip
flop corresponding to some event. For example, interrupt signals are latched
into the programmable interrupt controller so that they can be serviced at an
appropriate time.
Once the latch is read, it needs to be reset so that a new
signal can be received. Thus, for example, in the case of an interrupt, if a
second interrupt is signaled on the same input but the previous interrupt has
not been serviced (and the latch reset), the second interrupt will be lost,
leading to a missed deadline. Therefore, in servicing latched inputs of any
kind it is important to read and clear the latch as soon as possible.
Edge versus Level
Triggered
Logic devices can either be edge or level triggered, and the
difference matters in the sense that it can affect the way the system
recognizes true events or false ones. A transition from low to high is called a
rising edge, and from high to low it is called a falling edge (Figure 2.2).
In other cases, the signal is represented by the voltage
exceeding a certain threshold. When the signal reaches that level, an event is
triggered and latched so that another event cannot be triggered until the latch
is reset. For example, in Figure 2.2 if such level-triggered logic is used,
only a single event will be recorded unless the latch is reset during the time
period shown.
The differences between edge-based and level-based logic are
important, because in the course of manipulating certain signals it is possible
to create “false” events by prematurely resetting logic, which will be shown
shortly.
Tristate Logic
When multiple devices are connected to the same bus
structure it is important that those devices that are not currently involved in
data interchange remain, essentially, unconnected. To achieve this effect,
those devices that are not involved are placed into a high-impedance state at
their bus interconnections, that is, they are “tristated.” Hence a particular
electrical signal can be in one of three levels, high, low, or tristated.
Tristate logic is essential in the design of computer systems.
Signals that are improperly tristated will be in an unknown
state in which the signal is “floating,” that is, arbitrarily high or low.
Floating signals can be the source of many insidious problems, such as falsely
indicated interrupts and improper setting of switches.
Wait States
When a microprocessor must interface with a slower
peripheral or memory device, the normal timing of the microprocessor may need
to be altered. Specifically, in some cases a wait state may need to be added to
the bus cycles that access that peripheral or memory. Wait states extend the
microprocessor read or write cycle by a certain number of processor clock
cycles to allow the device or memory to “catch up.”
For example, in a certain system EEPROM, RAM, and ROM all
have different memory access times. These memory technologies will be discussed
shortly. Since RAM memory is typically faster than ROM, wait states would need
to be inserted when accessing RAM if the timing is to be made uniform across
all regions of memory. Of course, wait states degrade overall systems
performance, but do preserve determinism because it can be assumed that each
memory access takes the same amount of time.
Systems Interfaces
and Buses
A typical microprocessor-based system will have a common
group of 8, 16, 32, or 64 or more signals for reading and writing data. These
signals are collectively referred to as the system bus. Within the CPU there is
another common bus for intraprocessor communication between components. The
system bus is used for communication between the CPU, memory, and device.
Transmit/receive hybrid devices, or transceivers, provide communication
services to other devices joined by a common bus.
When accessing devices that require serial interfacing, or
if the number of lines on the bus is less than
those internal to the device, then a multiplexer (or MUX) is needed to
enable communication to the serial device over the parallel bus. The MUX
circuitry is responsible for ensuring that all transmitted and received data
conform to an appropriate protocol. This process includes parallel to serial
conversion for transmittal and vice versa with receipt and other circuitry
(Figure 2.3). The standard universal asynchronous relay terminal (UART) is
typically used for parallel-to-serial-bus interfaces and is seen in many
commercial applications. Such a scheme is compatible with 8-, 16-, 32-bit
parallel buses and any device-internal representation.
Of course, there are numerous standardized and customized
systems interfaces and bus types. Three particularly common ones for embedded
real-time systems are introduced.
MIL-STD-1553B A widely used standard in both military and
commercial avionics applications is the MIL STD-1553B bus standard that
specifies a hardware configuration and transmission and receipt protocols. The
1553B bus protocol is a master –slave protocol. “Master –slave” indicates that
one device orchestrates all activities on the bus through directives and the
other devices simply follow those directives, that is, they cannot initiate
activity on their own.
The 1553B standard is arranged so that one module on the bus
acts as a bus controller (the master) and the others respond to its commands
(the slaves). This type of configuration is common in many commercial networks
and computer subsystems, and is illustrated in Figure 2.4.
The 1553B protocol is based on a list of activities to be
performed by each of the devices connected to the bus. The master device
maintains this list. Each message essentially consists of a device ID number, a
directive and, possibly, a set of data. All devices are listening to the bus at
all times, awaiting broadcast of a message directive with their unique bus ID
(or a broadcast message intended for all devices on the bus).
The following example is a slightly modified version of how
the 1553B works. Suppose the master wants device number 5 to send 10 packets of
data to device number 6. The master puts a message out on the bus that
essentially says, “Device number 5 put 10 packets of data on the bus for device
number 6.” Device number 5 then places the data on the bus. When device number
6 sees the data on the bus with their ID in the header, it captures them. All
other devices on the bus can “see” the data, but only device number 6 takes the
data.
Besides electrical fault-tolerance provisions, the 1553B
protocol provides for fault tolerance in that if the master device is disabled,
provisions can be made for another device in the system to take over as master.
Small Computer Systems Interface The small computer systems
interface (SCSI) or “scuzzy” is a widely used, PC-based, parallel interface
that supports many kinds of devices. There have been three generations of SCSI
(1, 2, and 3) and other variants such as Narrow, Wide, Fast, Ultra, Ultra-2, and
Ultra160 SCSI.
This synopsis focuses on SCSI 3, which is made up of at
least 14 separate standards documents. These standards resolve many of the
conflicts in previous versions and add significant functionality and
performance improvements. SCSI 3 also supports Fiber Channel, and FireWire
instead of the familiar ribbon cable connection. The new interfaces are
backward compatible with SCSI-2 as well as SCSI-1 via the single-ended
interface. SCSI supports devices connected in a daisy-chained fashion (Figure
2.5).
Although the devices are daisy chained and appear to be
dependent, they are independent and each can directly communicate with the
others as well as with the host. Each device is uniquely configured by
connecting one end to the host adapter and then setting the device ID with a
plug-in terminator, jumpers, or switches. Id number 0 (zero) is set for the
boot device, and the higher the ID number, the higher the priority of the
device in bus access arbitration.
IEEE 1394 Firewire The IEEE 1394 bus standard describes a very
fast external bus standard that supports data transfer rates of up to 400
megabits per second (Mbps) (in 1394a) and 800 Mbps (in 1394b). Products
supporting the 1394 standard assume different names, depending on the company.
Apple, which originally developed the technology, uses the trademarked name
FireWire.
FireWire is easy to use, and a single 1394 port can be used
to connect up 63 external devices. The standard defines 100-, 200-, and
400-Mbps devices and can support the multiple speeds on a single bus, and is
flexible – the standard supports freeform daisy chaining and branching for
peer-to-peer implementations. It is also hot pluggable, that is, devices can be
added and removed while the bus is active.
FireWire supports two types of data transfer: asynchronous
and isochronous. For traditional computer memory-mapped, load, and store
applications, asynchronous transfer is appropriate and adequate. Isochronous
data transfer provides guaranteed data transport at a predetermined rate. This
is especially important for multimedia applications where uninterrupted
transport of time-critical data and
just-in time delivery reduce the need for costly buffering. This makes
it ideal for devices that need to transfer high levels of data in real time,
such as cameras, VCRs, and televisions.
