Creating Virtual Platforms with Wind River Simics Jakob Engblom, Technical Marketing Manager, Wind River Simics Executive Summary Virtual platforms have the potential to transform how Wind River Simics is a full system simulator used by systems embedded software products are developed, by making and software developers to simulate the target hardware of hardware availability issues nonissues and reducing everything from a single processor to large, complex, and development time and schedule risk. Virtual platforms connected electronic systems. Referred to as a virtual platform, have been found to reduce capital expenditure (CAPEX) it simulates the functional behavior of the target hardware. This costs by 45%, time-to-market by 66%, and debug time by enables the target software (same board support package, 35% or more. firmware, real-time operating system, middleware, and A virtual platform for a particular system or application application) to run on the virtual platform the same way it does allows you to quickly develop the system model. This is on the physical hardware. The simulation is fast enough that it the task of system modeling. This paper discusses how can be used interactively by developers. system modeling is supported in Wind River Simics. At the Within this fast and accurate virtual environment, engineering, core, Simics is an extremely fast transaction-level model integration, and test teams can use approaches and techniques (TLM) simulator. Simics features an efficient simulation that are simply not possible on physical hardware. For example, infrastructure that has been honed by active use for more developers can freeze, save, email, and restore the whole than 10 years. It includes very fast processor simulators, system; they can view and modify every device, register, or optimized target memory handling, and a proven API for memory location; and they can run the whole system in reverse device modeling. All Simics models have transaction-level to find the source of a bug. Virtual platforms provide software interfaces, so they communicate via transaction not signals. debugging and analysis features that are not possible to implement on physical hardware. Table of Contents More Detailed Models....................................................7 Anatomy of a System Model ..............................................7 Executive Summary ............................................................1 Memory Maps ................................................................8 Modeling a Target System ..................................................2 Hierarchical Components ...............................................9 Evolving Hardware Designs............................................3 Extensions .................................................................... 10 Software Setup ...............................................................3 Anatomy of a Device Model ............................................. 10 Chip-Level Modeling ......................................................4 Model Implementation Languages ................................... 11 System-Level Strategy ....................................................4 Device Modeling Language .......................................... 11 Model Creation ..................................................................4 C, C++, and Python ...................................................... 13 TLM Modeling of the Hardware- SystemC ....................................................................... 13 Software Interface ..............................................................4 IP-XACT ........................................................................ 13 Time Management .........................................................5 Other Models ............................................................... 14 Interfaces Between Models ............................................6 Conclusion ........................................................................ 14 Processor Models ...........................................................6 Modeling a Target System have to be accurately represented in the simulation, and the Modeling a system in Wind River Simics is an iterative easiest way to ensure this is to design the simulation model process, where the aim is to start with a minimal but still using the same component and communications structure as testable system and build out from there. During the the physical hardware. modeling process, you gather more and more information on Figure 1 shows an outline of the process that takes place the requirements of the model and use it to drive modeling when modeling a new system in Simics. The thick arrows are to the right areas of the overall platform. It is typical to model the most common feedback loops in the system, where most only the functionality needed to fulfill certain use cases, not of the iteration time is spent. The dashed arrows are paths all the hardware devices in a system and all its functionality. that occur less often (but are just as important). The goal is to run a certain software stack on the model. Over The following is a classic iterative software-development time, the platform model will become more complete as methodology, where the software being developed—the more functions and devices are added, making more use hardware model—is tested early and often to explore the cases available. Using a combination of unit tests and system precise requirements. It goes by many names, such as spiral tests with the target software, the correctness of the model is model, agile, or test-driven development: progressively proven. 1. Collect information about the target system to get an idea Note that even when the eventual goal is a model with of what needs to be modeled. Typically, this includes complete device and functionality coverage for a piece of design specifications, programmer’s reference manuals, hardware (e.g., when bringing a new system-on-chip to and other relevant documents. For new hardware, it might market), the model can be built iteratively and incrementally. involve interviewing designers and looking at early design Key customers can be seeded early with the functions they documents. need, and the ecosystem players such as operating system vendors can start porting operating systems long before the 2. Map the outline of the target system, creating an initial model (or the underlying design) is complete. list of devices and processors that make up the system and how they are connected and grouped. Based on an Simics models tend to follow the structure of the physical analysis of foreseen system usage and software load, hardware closely, while abstracting functionality where make a preliminary decision on the necessary level of possible. The overriding goal is to ensure that the software modeling of each device. Can it be ignored or stubbed developed on the simulated system will run on the physical out, or does it need to be fully implemented? hardware and vice versa. Thus, all software-visible functions Collect Information Map System Reuse Existing Adapt Similar Create Register Map Create Dummy and Create Target Devices Devices for New Devices Stubs Devices Memory Maps Write and Run Unit Build Hierarchical Tests on Devices Components Fix Bugs, Implement Functionality, Add Functions Add Any Missing Devices, Correct Misunderstanding Test System with of System Layout Target Software Problems Running Yes Change or Add to the Software? Hardware Design No Integrate into System Fully Functioning Use as Base for Next- of Systems Target Model Generation System Figure 1: Modeling process 2 | Creating Virtual Platforms with Wind River Simics 3. Where possible, reuse existing device models and processor models from the Wind River model library or Physical your own existing simulation model library. Hardware 4. If a new device is similar to an existing device, adapt the existing device rather than starting from scratch. Virtual Board Virtual Board Virtual Board RAM RAM RAM Flash Virtual Model of New SoC Virtual Model of New SoC Virtual Model of New SoC Virtual CPU CPU PIC CPU CPU CPU PIC CPU CPU CPU PIC MC Timer Timer Timer RTC 5. Create simple dummies for devices that are not really UART UART Flow Control UART Flow Control Ethernet Pattern Ethernet TCP Buffer Crypto Buffer Pattern Matching Offload Memory Memory Matching Hardware Ethernet Ethernet needed. 6. Create initial models for the devices that need to be Figure 2: Evolution of a virtual platform along physical hardware modeled, which usually involves creating the register maps and some values for important ID registers. This can 15. Once there is a complete model, it can be integrated to be done very quickly using Wind River’s device modeling form part of a bigger system or used as the starting point language (DML) tool. Registers that are not yet for modeling the next generation of the hardware. The implemented are marked and will generate warnings if model is an asset that will be maintained and probably accessed by the software. used for many years to come. 7. Create the system memory map, indicating where devices The iterative approach can be applied to the development are mapped in memory and any configurable options in and debugging of the hardware design itself, using the the memory layout. Simics model of the hardware as a design artifact. The Simics 8. Create unit tests for any new or adapted devices. Tests model can be modified to try ideas and check how things will typically be designed