Skinpress Rss

Thursday, June 5, 2014

Real Time System Design – Hardware Consideration

0



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.

0 comments:

Post a Comment