Embedded Systems Design - June 2008 - (Page 25)

+++ N O R O Y A LT I E S +++ embeddedsoftware 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 fit in with the virtual-prototype environment. Hand-generated 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 solutions embOS ® Ev a av l ver ail si ab on le s (RTOS) +++ 8/16/32 bits +++ Preemptive multitasking Zero interrupt latency Easy to use start project included Profiling support included Object/source code available Automatically created virtual models enable the designer to reuse components from previous designs. 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 benefit 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 modified. 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 file. As you may module. This parsed description is then subjected to a number of different optimizations. These are initially Model compilation flow. The model and its wrapper are both generated automatically by the compiler. VHDL/Verilog RTL emWin ® (GUI) +++ 8/16/32 bits +++ ANSI "C" source code, no C++ required Supports b/w, grayscale and color 2D graphic library included Variety of fonts included PC simulation included Window Manager/Widgets (opt) Parser emFile (File system) +++ 8/16/32 bits +++ Local optimizations ANSI "C" source code MS-DOS/MS-Windows compatible FAT12, FAT16 and FAT32 support Multiple media support Non FAT file system available Global optimizations Design scheduling Model compilation For ARM Chips: JTAG debug solution with flash programming Generated model Model wrapper Figure 1 phone: 978-874-0299 www.segger.com www.embedded.com | embedded systems design | JUNE 2008 25 http://www.segger.com http://www.embedded.com

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

Embedded Systems Design - June 2008 Contents #Include Party Bit Programmer's Toolbox Cover Feature: Virtual Hardware Platforms for Embedded Software Validation Allocating Memory in MATLAB-to-C Code MDD and IDEs: Making the Twain Meet in Embedded Systems Design Avoid a Thrashing Guest Editor Advertising Index Break Points Marketplace

Embedded Systems Design - June 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.