SOFTWARE DEVELOPMENT

DEMONSTRATION SYSTEM

The original code for the "lab bench" Localizer demonstration system received both clock and synchronization signals over an fiber optic cable from a PC. After the demo code was switched over to the new development system, enhancements were made to do the synchronization in software. Much like a totally wireless Localizer will have to do, the receiver now searches for a beacon signal from the transmitter. This enhancement allowed us to gain some experience writing more complete protocols for Localizers in a real-world environment.

TOOLS

For chip design, we use several different programs to enter schematics and simulate the circuits (PSpice), lay out the circuits (ICED), and compare the IC layouts to the schematics and check for design rule errors in the layout (ICED:DRC and DRACULA). Unfortunately, there are no hard and fast standards for file formats for these programs, and they cannot quite read each other's formats. Originally, hand work with a text editor was necessary to convert schematic files from PSpice into a form that the DRACULA program could use for schematics vs. layout checks. As the chips and circuits became more complex, this hand editing task became too cumbersome, and a program to automate the task was written. (This program is called GARLIC to compound the whimsy in the names of some of the commercial programs.) At first this was a simple filter that converted name fields from one form to the other. But over the last year and a half, additional functionality was added bit by bit. This program now evaluates expressions, extracts sub-circuits from libraries, checks for several common errors, and handles multi-page schematics and off-page node references. We are now able to use more of the features of our schematic capture program, and still export them to the layout vs. schematic checking program.

Several automatic placement/routing packages were evaluated for their potential ability to expedite the cumbersome process of custom physical design, including analog cell development, (i.e. physical transistor placement) block placement, and routing.

Our largest effort went to evaluating the package which held the most promise, Carnegie Mellon's Acacia. It features transistor placement and automatic wiring for analog cells, and attempts to minimize parasitics and wiring length. Unfortunately, it lacked features we needed, (such as the ability to layout cells for wiring by abutment) and the cells it produced were more than twice the size of what we could do by hand (with significant reduction in performance).

RANGING SIMULATOR

To allow software to be developed in parallel with the hardware, a software simulator was written. The environment chosen for this was the Microsoft Windows operating system on a PC. Each simulated Localizer is a separate task under Windows, and the Windows message queuing system is used to simulate the transmission and reception of code sequences. A special task (called the Aether) acts as a clearinghouse, calculating transmission times between Localizers, and keeping track of event times. This program informs each Localizer task whether or not its reception events were successful, and when it is free to schedule another transmission or reception. Using a multitasking operating system like this allows us to spawn reasonably large numbers of copies of Localizer tasks (several dozen) and debug problems with synchronization and collisions.

To use this system, a small set of routines was written to look very much like the low level routines we will use to talk to the actual hardware. Such routines include "load the code sequence generator Linear Feedback Shift Register," "schedule a transmission event," and "sleep until triggered". Using these calls, code to implement simple protocols was written that will be re-compiled for the Motorola 683xx computers that we have chosen for the portable demo hardware.

Under this environment, the protocol layer of code for the first Localizer demo has been written. Both synchronization and simple ranging protocols have been written and debugged. The synchronization is done with a "beacon" Localizer that broadcasts a special code on a periodic basis. In "searcher" mode, Localizers hunt for a beacon, then switch to a simple ranging protocol. The current code finds distances to the nearest meter, but does not yet use any of the advanced protocols to get greater accuracy.

All these tasks (Aether, Beacon, and Searcher) display their current status in small text windows on the Windows screen. The Aether task logs Localizers being turned on and off, and displays the known simulated distance (a piece of information denied to the Localizer tasks). The Beacon tasks indicate when they get an acknowledgment of their beacon, but do not have enough information to calculate any ranges. The Searcher Localizers display their current mode, and the range estimate when available. A typical test would be to run several Beacon tasks and one Searcher. When the Searcher finds and ranges to one of the Beacons, that Beacon task is terminated. The Searcher detects loss of the ranging codes, recovers, goes back into synchronization mode, and finds the second Beacon.

The current simulation does not simulate the effect of noise. The code sequence and arrival time of signals is the only information currently communicated. Simulations of the effect of time domain noise on the correlators have been done, and this information will be used to add noise to ideal correlation values. This will be used to debug peak detection algorithms in the Localizer code.
 

Back