Emulation, Simulation and Native Development
There are many ways to develop applications for embedded Linux devices. The obvious method is to cross-compile on your host and debug on real hardware. This is probably how most people think of embedded development. But there are alternatives worth considering.
One problem with the using real hardware is that it is not always readily available. There may only be a handful of prototypes built or you may even want to start development before any hardware is available. In today's highly competitive environment waiting for hardware may delay a project and why not have your hardware and software teams working in parallel anyway?
So what are the alternatives?
I am going to take a quick look at using Emulators, Simulators and developing natively on your host machine - a regular desktop or laptop PC - using Linux.
Since I am going to talk about both Emulators and Simulators I should define what I mean by each. These words are often used interchangeably to mean the same thing as they both provide a software implementation of a piece of hardware. For the purposes of this article though I am going to define a Simulator as something which tries to reproduce the hardware operation to a very fine level of detail, to the point that it is cycle accurate. An Emulator on the other hand only tries to look like the hardware at the op-code and I/O level.
So lets start with Emulation. Probably the best known open source emulator is QEMU though there are others. It can be configured to look like an x86 based PC, a PowerPC board, an ARM or a MIPS board. It uses some on-the-fly compilation, much like a Java virtual machine, to give a reasonable level of performance. In some cases it may even be possible to emulate a target close to (or even better than) the real hardware. There are emulated network ports, graphics cards and other peripherals allowing a full Linux system to run.
This is an ideal system for developing applications. You can use the same compiler toolchain to build your application as you would for the real hardware and you can run everything on one PC, including debuggers or a complete IDE if you wish.
Sometimes however you need very precise timing information and this is where Simulators come in. Simulators tend to be very much more specialised in order to be a truly accurate representation of the hardware. Typically they are developed by a silicon manufacturer to help their customers get the most from their designs. I recently used a simulator which included the ability to not only view, with clock cycle accuracy, execution of the code on the processing core but also see exactly how various hardware offload engines were being utilised. It would be impossible to see this level of detail in any other way, but there is of course a cost incurred. Simulation tends to be very slow compared to real hardware or an emulated system. Just booting a Linux kernel can take several tens of minutes.
If network throughput, encryption, image processing or any other high-performance application is what you are working on, where you need to get the absolute best out of the hardware, then a simulator is the way to go.
The simplest environment to develop an application on is the host PC itself. There are no worries about setting up a cross-compiled environment or virtual networks. You can bring all the native development tools to bear on the problem and every engineer has the possibility to run the code since they will all have a PC. But this too has its limitations.
First, we are assuming you are developing for an OS like Linux which can run on a PC and which can be used for self-hosted development. Then there are endian issues. A PC is little-endian, if you are developing an application for a MIPS in big-endian mode then you may find you have problems when you later run on real hardware. Increasingly there are also many 64-bit PCs whilst most low-end embedded devices are still running 32-bit processors, this too can cause problems.
Graphical application development lends itself well to this kind of environment.
There is one other form of emulation which I have not mentioned since it is very rare outside silicon development. That is the use of programmable logic and other hardware blocks to implement a prototype hardware design before it is fabricated. These systems can run software at acceptable performance, but they are aimed specifically at finding and ironing out problems with the silicon design. They may also cost many millions of pounds/dollars/euros to build!
So whilst working with real device hardware is usually the best option, there are alternatives worth considering. I personally find QEMU especially useful.
For more information on QEMU see the web site here: http://www.nongnu.org/qemu/
Categories:
Tags:
No TrackBacks
TrackBack URL: http://www.electronicsweekly.com/cgi-bin/mt/mt-tb.cgi/48380
2 Comments
There is an alternative option available: CoWare(www.coware.com) is involved in development of Virtual platform and virtual platform tools. They have a big set of tools available for development of emulator and simulators. CoWare provides a big range of tools to develop prototypes of Instruction accurate as well as cycle accurate models of any processor core and peripherals. All of these models are developed Open source simulation language SystemC. I have ported Symbian OS on a virtual platform of a mobile and I found it very usefull.
Instruction accurate platforms are quite fast in execution while Cycle accurate pays a price of detailed information with the speed of execution.
Thanks for bringing up an important topic! I personally think that host-based compilation is becoming increasingly less useful as time goes by, due to the increased complexity of target software. Maintaining that extra build is often a large pain, and you will not get the right word-length, endianness, compiler version, or binary-only libraries. Not to mention OS scheduler version. Add in some virtualized multicore devices running a mix of Linux, VxWorks, OSE, QNX, LWE, and home-made bare-bones operating systems, and it is clear that it is simpler to just run the actual binaries than to try to fake it on the host in some way.
As an example, I have observed significant differences across targets even with "the same version of Linux". The ppc kernel task structures are not quite like the x86 kernel task structures, for example. And behaviors do differ. Configurations can be quite different, and watch out for the #ifdef __POWERPC__ stuff that tends to pop up...
There is a useful principle to keep in mind: "fly what you test and test what you fly" -- the closer you can be to the real thing during development, the better.
Based on the above, emulation as you call it comes in very handy. It gives you the right system, running the right binaries, and fast enough to be useful for real development work. With added bonuses like checkpointing and reverse execution, if you seek out some of the more advanced commercial offerings in the space. Simulation, i.e., pretty detailed models of hardware, is useful for small-scale detailed performance analysis, but is not fast enough for large-scale work, much as one would wish for a 100% accurate model running as quickly as the final hardware... but that is like wishing not for the moon but for pluto or something :)
As Manish Jain notes in the comment above, OS porting is one common use case in addition to application development. I have a longer write-up on use cases and what can be done at http://jakob.engbloms.se/archives/651 , check that out for more on virtual platforms and software development.
WindRiver itself has actually used emulation tools from Virtutech for operating system ports to some recent Freescale devices, see http://www.virtutech.com/casestudies/windriver_multicore.html for some more on that. It is in the VxWorks department, not Linux, but the principle is the same. And we are seeing Linux ports also, in particular for the QorIQ family of chips.
Finally, not that I want to discuss vendors and tools in a partisan way... but CoWare is far from the only game in town when it comes to commercial tools in roughly the same category as Qemu. There is also VaST, Virtio/Synopsys, ARM, and Virtutech.
Sorry for the long comment, but this is a really important topic to me. And one that more embedded developers need to be aware of.
I gave a presentation at the ESC in 2008 that addresses the issue, see http://www.engbloms.se/jakob_publications.html and the ESC 2008 talk slides and document for more.
没有评论:
发表评论