Open side-bar Menu
 Embedded Software
Colin Walls
Colin Walls
Colin Walls has over thirty years experience in the electronics industry, largely dedicated to embedded software. A frequent presenter at conferences and seminars and author of numerous technical articles and two books on embedded software, Colin is an embedded software technologist with Mentor … More »

Simulation – better than the real thing?

 
January 16th, 2014 by Colin Walls

At Mentor Graphics I have to be careful what I say – I am treading on thin ice. The problem is that I am a software engineer. A very large proportion of my colleagues in the company have a hardware design background. Now I would not say that the two disciplines are at war, but there has always been a tension between hardware and software developers. In an embedded design, if something goes wrong, both parties tend to assume that the other is at fault. Worse still, if a hardware design flaw is located late in the development process, it may be too late to fix it economically, so the only option is to accommodate the problem in software. And gosh, does that rankle.

So, I tend to regard hardware as a necessary evil that allows me to run my software. It is probably no surprise, therefore, to learn that a favorite technology of mine is simulation …

The first issue is what does the term “simulation” mean? If a customer asks me whether we have a simulation solution, I always quiz them to ascertain exactly what they are looking for. Broadly, a simulator for embedded software development is some kind of environment which enables software to be run without having the final hardware available. This can be approached in a number of ways:

  • Logic simulation – The hardware logic is simulated at the lowest level [gates]. Although this is ideal for developing the hardware design [using a tool like Mentor’s ModelSim], modeling a complete embedded system and executing code would be painfully slow.
  • Hardware/Software Co-verification – Using an instruction set simulator [see below] linked to a logic simulator [see above], a compromise performance may be achieved. This makes sense as, typically, the CPU design is fully proven, so having a gate-accurate model is overkill.
  • Instruction Set Simulation – An ISS reads the code, instruction by instruction, and simulates the execution on the chosen CPU. It is much slower than real time, but very precise and can give useful execution time estimates. Typically the CPU simulator is surrounded by functional models of peripheral devices. This can be an excellent approach for debugging low level code like drivers.
  • Host [Native] Code Execution – Running the code on the host [desktop] computer delivers the maximum performance – often exceeding that of the real target hardware. For it to be effective, the environment must offer functional models of peripherals and relevant integration with the host computer’s peripherals [like networking, serial I/O, USB etc.]. For larger applications, this approach enables considerable progress to be made prior to hardware availability and offers an economic solution for larger, distributed teams.

These technologies are not competitive with one another. Each one offers a combination of precision and speed, which may be appropriate at different times in the design cycle. This can be visualized if I plot them on a graph.

You can change the rules and deviate from this nice relationship by “cheating” – i.e. using hardware acceleration, which is special electronics designed to “turbo-charge” the logic simulation [like Mentor’s Veloce range]. But that is no longer simulation – that is emulation, which is another story.

Related posts:

2 Responses to “Simulation – better than the real thing?”

  1. Gary Dare (@GaryDare) says:

    Simulation and/or emulation have enabled us to virtualize the design of embedded systems. These virtual prototypes in varying levels of functional and timing accuracy have allowed for earlier software development rather than waiting on a minimum viable hardware prototype (and the generations of such prototypes are a hardware project within a project!). However, this does not remove the dependence of software development on the hardware definition and development. So eventually you have an integration phase and all the risks entailed … modifying the software to run correctly on the hardware target or worse, having to modify the hardware and thus introducing a long iteration loop!

    What is needed is a true hardware/software co-design approach using these various levels of virtual prototyping in order to modify the hardware/software partitioning in an agile manner. In other words, integration from the very start (or at least close to it) so that the tasks that make up your application are properly targeted for hardware or software implementation to achieve goals in performance, power and silicon area (i.e., form factor – an important consideration for IoT, the next big thing in embedded).

Leave a Reply

Your email address will not be published. Required fields are marked *


*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

CST Webinar Series



Internet Business Systems © 2016 Internet Business Systems, Inc.
595 Millich Dr., Suite 216, Campbell, CA 95008
+1 (408)-337-6870 — Contact Us, or visit our other sites:
TechJobsCafe - Technical Jobs and Resumes EDACafe - Electronic Design Automation GISCafe - Geographical Information Services  MCADCafe - Mechanical Design and Engineering ShareCG - Share Computer Graphic (CG) Animation, 3D Art and 3D Models
  Privacy Policy