English
20th Anniversary article: Full simulations with partial hardware
By Diehl H. Martin, III
Embedded.com
(05/11/08, 02:00:00 PM EDT)
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.
Embedded.com
(05/11/08, 02:00:00 PM EDT)
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.
|
E-mail This Article | 
|
|
Printer-Friendly Page |
Related Articles
- High-performance hardware models for system simulation
- Accelerate partial reconfiguration with a 100% hardware solution
- Application Hardware Modeling: Selective modeling for early prediction of subsystem performances through simulation
- Multi Chip, Multi Environment Simulation, Bringing Software Closer to Hardware and Saving Money
- Understanding Timing Correlation Between Sign-off Tool and Circuit Simulation