Embedded Systems Design Europe - June/July 2008 - (Page 15)

cover feature and ﬁx system issues. If the designer ﬁnds that the problem lies in another area or with another designer’s code, the virtual prototype can be sent to the appropriate engineer as an e-mail attachment. Virtual prototypes are more easily debugged than their physical counterparts. When a problem is detected, it’s a simple task to simultaneously halt the execution of both the hardware and software. Halting execution is not nearly as simple with real hardware and is sometimes even impossible. Once the system is stopped, debugging the virtual prototype is simpler than debugging the real hardware as well. Unlike physical hardware where visibility into the model is conﬁned to the visible pins and the few registers that are made available via JTAG, virtual prototypes have visibility into all components of the system. In fact, virtual prototypes often ﬁnd and help debug problems when the actual hardware has already been built. CREATING PROTOTYPES A variety of options are available for creating virtual prototypes. SystemC is an IEEE standardized language targeted at system-level modeling. Armed with the language reference manual (LRM) and a freely downloadable proof-of-concept simulator, many engineers have created full system prototypes. Complete virtual-prototyping environments are also available from a number of companies. Environments from ARM, CoWare, Synopsys, and Virtutech tend to be the most common. These companies will supply models and services to help complete a virtual-system prototype. Regardless of which virtual-prototype environment is chosen, however, all environments share one fundamental need: They all need models to represent the functionality of the various system components. Models are needed for each portion of the design touched by the software. While instruction-set models for processors are readily available from the processor vendor, obtaining models for the rest of the components in the system can be less straightforward. There are three options for obtaining models for the remaining components for a virtual prototype: 1. Designers can obtain them from an intellectual property (IP) or prototype vendor; 2. They can write the models themselves; or, 3. They can generate them automatically from the hardware implementation. Many pieces of IP, especially commodity IP such as memories, interrupt controllers, and other simple logic have virtual models already created and readily available. Care must be taken to be sure that the IP model is compatible with the chosen virtualprototype environment. Standards in this area have been slow to emerge and are not universally followed. Manually creating the models for a virtual prototype helps ensure that the model will ﬁt in with the virtual-prototype environment. Hand-generated models execute quite quickly and, if the model doesn’t exist from the IP vendor or any other implementable form, it may be the only path to obtaining a virtual model. Unfortunately, manually created models require a large effort to create and validate. A great deal of time and work may need to be invested to learn the requirements for the model, code it, and then verify that it properly executes the required functionality when integrated with the rest of the system. When the design requirements change, as they inevitably seem to do, the model must be changed and then revalidated. Automatically created virtual models enable the designer to reuse components from previous designs. Model compilers enable you to compile the hardware design language used to implement the model directly into a high-speed, implementation-accurate virtual model that can plug directly into multiple prototyping environments. Automatically generated models have the beneﬁt of complete implementation accuracy, which means that the only step necessary to account for design changes is a model recompilation after the register transfer level (RTL) is modiﬁed. In many ways, a model compiler is just like a traditional software compiler. Its input is a language description that must be parsed and its output is an object or library ﬁle. As you may expect, though, many of the steps required to compile a hardware description are quite different from those taken when compiling software. The underlying theories, however, apply to hardware and software compilers alike. As you can see by looking at Figure 1, a model compiler starts by parsing the RTL description of the hardware module. This parsed description is then subjected to a number of differ15 www.embedded.com/europe | embedded systems design europe | JUNE – JULY 2008 http://www.embedded.com/europe

Table of Contents Feed for the Digital Edition of Embedded Systems Design Europe - June/July 2008

Embedded Systems Design Europe - June 2008 Contents Work in Progress to Define Compact PCI Plus Power.org Demonstrates New Tools Project Supports Multi-core System Programming Altium Links Electronic to Mechanical Design PLDs Look to Cut Power Budget and Costs Project to Provide Coverage Analysis Tool Microsoft Details Windows Embedded Update Cover Feature: Leveraging Virtual Hardware Platforms for Software Allocating Memory in MATLAB-to-C Code MDD & IDEs: Making the Twain Meet in Embedded System Designs Debugging Mixed Signal Designs for Infrequent & Random Events Why Open Source is the Natural Choice for High-security Systems Bringing the Benefits of Low Power CPUs to Modular Design New Products Advertising Contacts

Embedded Systems Design Europe - June/July 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.