This is supplemental course information, designed to give you a fuller picture of the course and an expanded look at the topics covered. This is an unofficial document. The USC Course Catalog is the binding description of all university courses. Information such as books, materials covered, and the order of topics is subject to change. Please consult instructor for this semseter to get more upto date course information. 554 Real Time Computer Systems (3, Sp) Structure of real-time computer systems; analog signals and devices; scheduling, synchronization of multiprocessors; reliability, availability; serial/parallel computations; real-time operating systems and languages; design examples. Prerequisite: EE 457Lx and CSCI 455x. Prof Ung, Professor of Electrical Engineering

NOTE : This is a project-oriented course. Lectures are devised to support and enhance students' ability to do a real-time (R/T) semester project. When an architecture is covered, only its real-time aspects are emphasized. The same procedure is applied to software discussion.

1) Structure of R/T Systems : R/T Clocks & its modes of operation. Interrupt organiza- tion & hierarchy. Communication between processes & computers, synchronous & asynchronous modes. Data format and data acquisition. Shared-bus organization. Example of a R/T bus: the MIL-STD 1553.

2) Hardware/Software Review : Example of processor chip made forR/T applications. I/O strategy. Parallel & distributed architecture for R/T applications. All about interrupts. Multiprocessing mode and context switching.

3) Analog Signals : Analog Digital converters (principles of operation, specs, idio-syncrasies, integration into microprocessors). Data sampling & reconstruction. Phase & magnitude errors in ZOH and FOH reconstruction strategies. Compensation methods to minimize errors.

4) Scheduling & Synchronization : Deadlines, laxities & overruns. Dependent and independent tasks. Non-preemptive & preemptive scheduling in multi-processor environment. Task priority and priority scheduling. Processor sharing algorithms.
Guaranteed Response Times. Real-Time Operating Systems (RTOS) revisited.

5) Queueing Applications in R/T Systems : Review of M/M/1 and M/G/1 models. Multi-server systems . Task overrun analysis . Time-sharing model. Priority queues,
preemptive and non-preemptive scheduling.

6) Reliability & Availability : Series/parallel models. Methods for estimating system
reliability. Active/standby components. Hybrid models. DMR and TMR (Triple-
Modular Redundancy). Voter designs. Dynamic reconfiguration for R/T applications.
Example: Mil. standard for predicting system reliability.

7) Systems planning, specs and evaluation.
Benchmarks, their uses and their pitfalls
Design Examples : Discussion of various student semester projects towards the end,
if time permits.

TERM PROJECTS

In EE554 the term project is the most important component of the course. It must be shared equally among the group partners. There is no restriction on topics, so long as they address one of the subjects discussed in class.

If you want to know what kinds of projects were done in the past, you may come by and peruse on past reports at Professor Ung's office. Here is a partial list of past projects:

1) Game-playing machines : backgammon, blackjack, TV pingpong.
2) On-line character recognizer, pattern recognition.
3) Traffic controller @ several intersections. Real-time navigation aids .
4) Digital music synthesizer, recording, playback, . . .
5) Robot control. Reconfigurable systems. Network traffic.
6) On-board navigation system, missile guidance in 2-D and
in 3-D. Battlefield management, control and training.
7) Software survey, analysis, validation, comparative studies of Real-Time OS.
8) Analysis of existing systems in terms of real-time performance or fail-safe
operation: LAX, San Onofre, Air traffic control center, . .
9) R/T Issues on the Internet : An infinite source of subjects.

FORMAT

a) A brief discussion of your system. This is where some groups fail miserably because they devote half of their report on this "brief discussion". Say enough here so that the reader has an idea what kind of system you're dealing with and what you want to do with it -- No more! This brief description should not become a user's manual for your system.

b) What do you want to do in your project? Spell out clearly your objective(s). Any subject will do, as long as it addresses one (or more) aspect of real-time computation: data sampling/reconstruc-tion; analog signal processing; queueing analysis/ scheduling ; reliability/availability; multiprocessor/special architecture for R/T applications; H/W-S/W fault tolerant design ; . . .

c) The vast majority of your report should be devoted to your accomplishment, discussion and conclusion. If you're designing a gadget and if you have time, make it functional and demonstrate it. If a S/W package exists (such as a RTOS), use it and relate your experience on your report.

d) References: Make sure you include a copy of critical journal papers that you use. Without them, there is no time for your professor to check out the validity of your references. Average length of your report should be 25 pages, excluding appendices. A report of 30+ pages in length only weighs you down.

Last Updated by Ung 12/2003