Firmware people are scum.
At least, that's the way we're treated. The hardware will be late.It's always late. And then we're supposed to make up the schedule?
At best it's very hard to seriously test the code till the hardwareis ready. So developers come up with a variety of schemes to do somelevel of testing before the EEs release finished PCBs. Maybe one canuse a previous iteration of the product that shares much of the sameI/O as the new version. Or use a CPU vendor's evaluation board, whichmight have only ten or twenty percent commonality with our product butis at least a start.
Then there's simulation. For decades vendors have touted varioussimulators. Most were just awful. Few ever garnered much market share.Even fewer developers take simulation seriously, having been burned bytoo many promises and too little performance.I've played with Keil's 8051 simulator, which is the first I've seenthat accurately and easily handles both the CPU and the part's manyvaried peripherals.
Now the operative word is “virtualization,” which means abstractingout the physical aspects of computing using software. To us embeddedheads that's still simulation.Recently Virtutechsent me a demo of their simulation/virtualization product called”Simics,” which promises an environment so faithful to reality that theapplication can't tell whether it's running live or on the simulator.And the demo is seriously cool.
Like many of us I use another virtualization environment that isavailable free from VMware on my main Windowsmachine to run Linux. That by itself is pretty amazing. VMwareharnesses the awesome and usually neglected power of the Pentium tocreate a new virtual machine on the PC. (I think the Pentium's 3GHzprocessing is used mostly to wait for keypresses and download Windowsupdates). It's fun to watch Linux boot in its own Windows window. Thesimulation is so accurate that the filesystems aren't shared; one usesnetworking utilities to move files between Windows and Linux.
Simics runs under Linux, so I started Debian up in the VMwarewindow. Then, under Debian, I fired up Simics. Within that environmentI then started MontaVista Linux.
So MontaVista was simulated by Simics, running on top of Debianwhich VMware simulated under Windows. Amazingly, the performance waspretty reasonable.
Simics makes no attempt to be cycle-accurate. It's an environmentaimed at software developers, to help us get our code running onvirtualized hardware. Libraries offer a large number of standardsimulated peripherals, and a sort of macro-language lets onefairly-easily build models of other I/O devices. Since the entireenvironment is virtual, it can even run backwards in time (like GreenHills' TimeMachine).
Simulation is no panacea. Costs can be high. But the idea isintriguing and now, after decades of vendor promises, actually works.One agony I'm hearing more often in recent years is from developers whono longer have access to development platforms since the hardwarebecame obsolete yet they still have to maintain a product. Some stuffa complete development system in a closet, ready to be resurrected whenneeded. But components do go bad; electrolytic caps, for instance, dryout over the years. Simulated hardware never ages or fails.
What do you think? What's the future for simulation in yourenvironment?
Jack G. Ganssle is a lecturer and consultant on embeddeddevelopment issues. He conducts seminars on embedded systems and helpscompanies with their embedded challenges. Contact him at . His website is .
Simulation is a mixed bag. There is definitely a Laffer-style curve here. It tends to go thusly:
– The higher the risk, the more tendency to attempt some form of simulation, (e.g. remote vehicles, and exotic environments)
– The easier to do simulation, the more tendency to attempt some form of simulation.
The market tendencies are along the ease-of-simulation side. The vast majority of projects tend not to fall in the high-risk category… therefore, simulation needs to be readily, and easily accessible.
For me? In general, the code is written for a specific platform, and some crude form of stimulus-response is attempted… just to make sure the ISR's and the core algorithm work ok. Not too much effort is really invested… that is because there is usually much pressure to get our hands on the hardware … coupled with my tendency to tell the clients to “just spin the hardware right away”.
Jack finished his piece with “Simulated hardware never ages or fails.” Now that's an interesting point. Exactly because it's simulated, its failure and aging can also be simulated. So you can simulate the electrolyte drying out of that capacitor and see what the software makes of it. How much possibility will there be for improving the robustness of the software to failures and aging in the hardware if a good simulation is available throughout the design?
– Paul Tiplady
Virtutech's web site won't let you download any information without first coughing up personal contact information; no downloadable evaluation version of the package; no open platform for adding new devices/CPUs to the system, so users are totally dependant upon what they want to provide; no screen shots available; no posted prices
I trust your opinion Jack, but This company has some smelly' marketing practices! Too bad, because I was really intrigued by your review of it.
– Chris Gates
Jack Replies Chris, I'm with you on this. It seems to be more and more common. I recently filled out one of those forms on Wind River's site and now get a couple of automated emails a day from them.
When you said “simulation” I thought perhaps you were talking about simulating the kinds of processes we find in the REAL WORLD, since frequently we find ourselves needing to develop algorithms or models to help us do control applications. (By the way you can find a lot of interesting simulations online implemented as “calculators” at http://www.martindalecenter.com/Calculators.html,
if you haven't been there it's worth a look to see what Java can really do.) As far as my desktop why would you want to “simulate” an OS when you can just install Cygwin and have a full set of GNU dev tools sitting right there in WIndows, you don't even need to have admin rights to put it on, you can even develop Windows apps, and the SPEED is simply amazing!
– Jeff Lawton
Recently, for lack of convenient hardware access, I wrapped a bunch of embedded code with a thin windows' shell. That gave it a primitive GUI for testing, and Visual Studio for a development environment. Within hours, several bugs were resolved that had remained elusive for a corresponding number of days (using the burn-and-learn cycle that is so common on embedded devices without JTAG, or have largely outgrown an emulator). This worked so well, I wished we could just obsolete the hardware and ship the virtualized product – oh, but there's those cost, packaging, environment and size issue of shoving a pentium into the 16-bit world…
– Dave Smart
I want to see processor simulators that will let you hook those peripherals up to your simulated hardware. When I'm working on a motion control application the consequences of hitting a breakpoint can range from an inconvenient loss of system state to metal smacking into metal. MatLab and SciLab are both at the point that I can control a simulated plant with C code running in a native Windows environment — now if I could just do that with a simulated DSP, I'd be happy.
– Tim Wescott
That's something all of the tools mentioned in the article lets you do. Yousimulate the processor, hook it up to simulated computer peripherals. Andthen these peripherals can hook up to simulated mechanics/environmentmodels. In this case, some simulated A/D and D/A converters plus aconnection between the computer simulation tool and Matlab/Scilab wouldaccomplish exactly the goal.
– Jakob Engblom
Does anyone here have experience building simulations using SystemC? If so, I'd love to get your take on it.
– Shawn Price