Developing software to run directly on hardware is hard. Implementing a simulator for the target hardware can help alleviate much of this pain. Techniques and best practices learned from several simulation environments for vastly different hardware will be presented.
Hardware is funny stuff. It is often documented to work one way when it actually works a slightly different way. Different revisions of the hardware may have different bugs that require different sets of work-arounds. Programming it even slightly incorrectly can lead to software crashes or system hangs. Sometimes some versions of the hardware work fine, but the version not on the developer's desk crashes. Failure modes are often opaque and give no clues for fixing the problem. Writing robust, reliable software to run directly on hardware is hard.
Software simulation of hardware is a technique that, in many cases, can alleviate some of this pain. Teams that develop hardware will often create a simulator as a by-product of hardware synthesis. Not ever developer is fortunate to have access to such tools. Those who do have access often find them slow or difficult to use. After all, these simulators are generally created as an aid for the hardware developers themselves. Much of the benefit of a full hardware simulator can be attained by developing the simulator independently from the hardware development. When the correct techniques are applied, it's not even that hard.
This talk will present a variety of techniques based on experience with several "home grown" simulation environments. Techniques for both developing and validating the simulator and techniques for integrating simulation in the regular development process will be described.
Speakers: Ian Romanick