On October 20, I will be speaking at the Design and Verification Conference and Exhibition Europe 2016 (known as DVCon Europe), presenting a paper titled “Integrating Different Types of Models into a Complete Virtual System – The Simics SystemC* Library”, which I authored together with Intel colleagues Andreas Hedström, Xiuliang Wang, and Håkan Zeffer. The problem we address in the paper is how to efficiently and effectively use models written using SystemC inside of Simics, typically for the purpose of building a complete system platform using a mix of native Simics models and SystemC models. My talk at DVCon will focus on how to create and use virtual platforms in a world of heterogeneous models.
What follows is a fairly technical post aimed at developers and other technologists who care about virtual platforms and modelling languages.
As told in the paper, we have built a new and rich framework for running SystemC models inside of Simics. It is more than just a basic integration that lets models written in SystemC run in Simics, like we have done in the past. We have gone beyond simple execution to ensure that SystemC models that run in Simics are first-class members in the Simics simulation system. The internal hierarchy of a SystemC model is visible in Simics, and the Simics user interface allows inspection and control of SystemC-language models alongside Simics native models. The new SystemC integration is known as the Simics SystemC Library, which replaces the previously used SystemC Bridge.
Here is a quick walk-through of the most visible features.
The picture below shows how a SystemC model looks in the Simics System Editor in Eclipse. The “dut” is a Simics component – which contains a set of SystemC components, all in the same namehierarchy. The System Editor knows about SystemC and shows SystemC concepts such as ports, exports, and bindings.
We can set breakpoints and trace models from the System Editor and control the log settings for SystemC objects. Logs printed from SystemC are handled through the Simics log system, providing a single system-wide log. The picture below shows how the GUI provides easy access to basic operations on the SystemC objects:
There is also a SystemC editing mode in Eclipse based on the standard CDT (C/C++ Development Tools), and debug support for SystemC has been integrated into the Simics-aware gdb (GNU debugger) that we use to debug Simics and Simics modules. We can profile the memory and time of the execution of SystemC models, and users can build custom tools to observe, trace, and control the execution of a SystemC subsystem. VCD output is available to visualize hardware signals.
One use case for the Simics SystemC Library is actually to run stand-alone SystemC models in Simics to get the UI features and take advantage of the Simics command-line and scripting system.
The SystemC Library is one example of how Simics supports heterogeneous simulation systems. Over the course of two decades of building full-system simulators and virtual platform with Simics, we have integrated a large variety of simulators with the tool. Sometimes it comes down to talking with external simulators (see aWind River blog post on the Trinity of Simulation for more on this topic), but quite often the models are run inside of Simics itself as part of the target system hardware model.
The picture below illustrates how this can look in practice:
In the somewhat contrived example, we have models in SystemC and various other simulation frameworks integrated into a single Simics system. Some models are written using transaction-level modeling (TLM) methods, some are detailed architecture models. Firmware is being executed on quite a few subsystems, since embedded microcontrollers are a common feature of modern hardware design. Simics models are written using both DML (Device Modeling Language) and the Simics C/C++ API and Python. Hardware components like buses, disks, and memories are implemented using Simics standard models.
While this is admittedly a bit extreme, the reality is that a virtual platform is usually built from a heterogeneous set of models. The models are written using different languages and frameworks, and by different teams with different goals. In the end, the tools and languages used to write models is up to each time that produces models – and we can build a combined model in Simics no matter what.
Our talk is scheduled for October 20, 2016, in the “TLM and IP-XACT” session. DVCon Europe is being held in the beautiful city of München, but despite being held in October, the famed Oktoberfest is over when we get there. In any case, I am looking forward to the conference, as it is a good chance to talk simulation and verification with a host of knowledgeable people from industry and academia. I hope to see you there.
Intel's compilers may or may not optimize to the same degree for non-Intel microprocessors for optimizations that are not unique to Intel microprocessors. These optimizations include SSE2, SSE3, and SSSE3 instruction sets and other optimizations. Intel does not guarantee the availability, functionality, or effectiveness of any optimization on microprocessors not manufactured by Intel. Microprocessor-dependent optimizations in this product are intended for use with Intel microprocessors. Certain optimizations not specific to Intel microarchitecture are reserved for Intel microprocessors. Please refer to the applicable product User and Reference Guides for more information regarding the specific instruction sets covered by this notice.
Notice revision #20110804