20th Anniversary article: Full simulations with partial hardware - Embedded.com

20th Anniversary article: Full simulations with partial hardware

This article first appeared in the May 1989 issue of Embedded Systems Programming magazine.

One of the challenges the embedded systems developer faces is writing software for custom hardware when that hardware exists only on paper. Unlike the development of applications for general-purpose machines, there's initially no platform on which to test the software as it's developed. Historically, the only recourse has been to use simulation software or an emulator without the hardware. Both cases offer limited help in refining such critical areas as operator interfaces and target system interaction, and both make it hard for the customer to see early on how the system will behave.

In the last few years I've solved this problem by building and using partially operational simulator hardware, or POSH for short. POSH was used to simulate a 500-IC, 68000- based embedded system, but it fit on a single six-by-nine-inch, wire-wrapped circuit card built at the start of the software development cycle. The POSH device was then hooked up to the Microtek Mice-II emulator, allowing the software development team to test much of their software months before the full breadboard system was available.

There's currently a move toward completely simulating the hardware environment with software. While this approach is certainly useful, it lacks the ability to conveniently attach existing hardware and fully test the interaction. Nothing is more frustrating than designing software to work with a device as it was specified, only to discover that the hardware has one or more features that weren't implemented as stated in the specification. POSH allows such devices to be hooked up and tested with real software so that hardware peculiarities can be found and circumvented quickly. This is something no existing simulator can do.

Use of the POSH device cut months from our actual development time. One advantage was that the hardware and software teams had to hammer out the interfaces in the first weeks of the contract rather than putting it off. The most commonly used parts of the code were thoroughly tested by use in a real environment. The real-time operating system initially ran with nothing but stub tasks; as code was completed, it was inserted and could be run in the actual target environment. The customers were able to see early in the project how the final system would behave, suggest improvements, and approve such details as the operator interface months before the final hardware was completed. POSH more than paid for itself by reducing the delays we had experienced in the past as a result of inevitable last-minute surprises and changes.

What's needed
Before designing a POSH device, you need to know several things. First, you must know what the final embedded application system will do. In a big company, this data may come in the form of a preliminary specification document, whereas a small shop may reduce it to an idea in the heads of one or two key individuals. Either way, the POSH designer must have this information. Next, the hardware and software teams need to determine how much and what needs to be simulated. This can usually be reduced to a very limited number of functions. The fewer the functions simulated, the less hardware there is to build. Of course, taking this to extremes can be false economy.

System functions can usually be divided into the “real needs,” the “very handy,” and the “might also like.” The real needs are generally very few, allowing room on a small circuit card for those needs plus a couple from the “handy” category. Once this much is determined and agreed upon by the participants, the box can be sized to determine its projected cost and schedule.

Next, several decisions must be made: how the interfaces to these functions will work, where in memory or I/O space they're located, and how they'll be accessed. The key here is to hammer out a definition that will hold for the final product so changes won't impact schedules later. Probably the best scheme is to take the time to design the actual interfaces to these functions and see if they can be used in the POSH device. When this is possible, it provides further assurance that the software and hardware interfaces are well understood and will probably work in the final product. Of utmost importance at this point are the cooperation and communication of the hardware and software teams. The best case is when each team comes to the meeting willing to listen to what the other side can offer and what it needs.

Once the interfaces are hammered out, the POSH hardware can be designed. Ideally, it would be an enclosed, self-powered, freestanding unit (see Figure 1 ). The enclosure prevents most of the falling-paper-clip sort of damage that can short out and ruin the hardware. The fact that the power supply is contained in the unit makes it unlikely that it will have to be retrieved periodically from some technician's bench. And a freestanding unit makes it much more convenient to place the system and emulator in the offices where the software team actually works. This way, they'll have constant and ready access to the device.

View the full-size image

In most cases, the active electronics can be put on a single wire-wrapped board. The board should be mounted inside the enclosed in such a way that it can be easily removed when modifications are required. Connectors should be used to connect the board to the enclosure wiring and to any outside wiring necessary for the application. The connectors make the system easier to disassemble and reassemble, whether to make changes or to take the whole system to the sales area for a demonstration. The emulator socket should have a zero-insertion-force (ZIF) connector to put the least possible strain on the emulator cables and connectors.

One issue that must not be overlooked is safety. Most of us who work with embedded systems get used to the fact that there's a small risk of injury from the electronics in a project. Usually the low-power electronics are unlikely to be of much danger to anyone, but a unit like POSH can be quite dangerous if not built with safety in mind. One danger is the exposed wiring in the power supply area. That 120-volt AC input must be shielded in such a way that no one can inadvertently come in contact with it.

Furthermore, if the devices with which you interface use high voltages or currents, the connections must also be carefully shielded. Never assume that anyone will be extra careful around POSH, since you never know what your chief salesman (or his client) may do when showing off your system.

The basic POSH
The first POSH was a fairly simple unit. The software team needed a way to perform initial tests of their application code along with Ready Systems' VRTX on a 68000. The VRTX code resides in a pair of PROMs in the final system, which needed to reside in system memory. VRTX also needed a periodic interrupt to drive its scheduler.

We agreed that POSH needed an oscillator to act as the system clock, circuitry to generate the required 68000 data transfer acknowledge (DTACK) signal, a full power-on interrupt circuit to exercise the start-up code, and LEDs to indicate that the multitasking system was running (see Figure 2 ). The entire circuit took up about 12 square inches on an Augat universal wire-wrapped board and fit into an unpainted rectangular chassis along with its small power supply. We plugged the Microtek Mice-II 68000 emulator into the ZIF socket on the POSH, and the whole assembly came to reside on the lead software person's conference table hooked up to his IBM AT. RAM for the target system resided in the emulator and was used for both the application program and the data-storage needs of the system.

View the full-size image

The reaction to this first POSH was gratifying. While it took less than a week to plan, design, and build, it allowed immediate testing of parts of the software that would otherwise have had to wait for months. POSH allowed us to experiment with the DTACK timing to see how much speed could be gained. It also allowed us to prove that VRTX would work for our system application and, since VRTX could run on POSH, let us test each module as it was coded, running as it would in its final configuration. POSH saved at least 10 times its cost by accelerating development and reducing last-minute confusion.

An advanced POSH
The second POSH was actually an extension of the concept of the first. After using the first POSH for more than a year, we added an interface for a user display. This modification proved exceedingly handy as it allowed the software staff to see what the system user interface would look like. The old POSH was still in daily use at the start of the next project, so we built a new one based on its design but designed it from the start to simulate the complete user interface.

To make it as realistic as possible, we designed and built the final breadboard for the control panel first with connectors so the new POSH could plug in the way the full breadboard would later. The full user interface was supported with keyboard, display, switches, and LEDs. We then designed the bread-board user interface circuitry; this design was also used in POSH. All the other features of the old POSH were incorporated as well. The circuitry took about 50 square inches on a six-by-nine-inch Augat VME-type universal bread-board, mounted along with its small power supply in a painted, slopingpanel chassis. The front-panel breadboard plugged into POSH along with the Microtek Mice-II emulator.

The new POSH lived up to our expectations and provided the facilities we needed to fully check out the user interfaces. An added benefit was that the real user interface could then be used to check out the rest of the application code. Furthermore, we caught and rectified a major error in the design of the control panel circuitry well before committing the design to a printed circuit board.

POSH provided us with the capabilities that a demonstration program offers for the developer of applications for general-purpose machines. We were able to bring in our customers, try out our operator interfaces on them, and get their feedback early enough to incorporate their suggestions into release 1.0 of the software. The customers could see that there was progress on the contract, that their input was being heard, and that they were getting their money's worth. The latter was an added and unexpected benefit as it allowed the unfinished product to begin selling itself long before release.

An unexpected benefit of using POSH was that it could be used on multiple projects. Because multiple projects are customarily built around one processor architecture or even one board set, we were able to begin work on new projects using the POSH from a previous job. Sometimes we had to add features for the new application, but the basic POSH hardware and most of its design could be used again and again.

Simulating with partial hardware can be a very useful way to check the interfacing of embedded systems to key hardware devices. The cost is minimal; the payback in both reduced difficulty of hardware/software integration and improved customer relations is substantial. For any project with custom hardware being developed simultaneously with the software, POSH is worth investigating.

Diehl Martin worked as an engineer for more than thirty years and designed analog and mixed-signal electronic and software-driven devices and systems. In 1989, his bio read “Diehl Martin is a senior engineer at SCI Technology Inc. in Huntsville, Ala. He has been working with embedded systems–hardware, software, design, and integration–for more than 10 years.” Diehl Martin passed away in October 2007. For more information about him, go to diehlmartin.com/work.html.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.