By Jakob Engblom
My blog posts about Simics tend to focus on how virtual platforms are used and what you can do with them. However, underlying all Simics use is the issue of getting a virtual platform in place. You need some kind of platform to run your software on in order to get the full benefit of Simics. Thus, creating virtual platforms is an important part of practical Simics use for many of our users.
We have been working with Simics for more than a decade, and we have learnt a lot about modeling along the way. The approach we have ended up with is a top-down methodology, where we start by investigating the target system as a whole from the perspective of the intended use cases, and then explore the details of each subsystem in order to determine how best to model it. We then switch to bottom-up, applying an iterative modeling flow that delivers something useful as quickly as possible. During development, the goal is to always keep a useful (albeit probably incomplete) platform available at all times.
It is easy to get distracted by the details when creating a virtual platform. If you start with a list of all the components of a system without considering the system context, you are likely to assume you need to model everything, as well as every function of everything. This is usually an overwhelming task, resulting in a protracted development project without clear focus or any chance of delivering something early. So, we need a better way.
The method we typically use with Simics is to start by investigating how the system is going to be used, and which hardware units are involved in these use cases. In this way, we can often exclude parts of the target system from consideration. Certain subsystems or subsystem functions might not be needed at all, or needed only at a later stage of the project. Even when modeling an SoC with the eventual goal of a complete model, it is possible to create a priority list and staging sequence that quickly gets something into the hands of users that applies to their initial use cases.
Once this analysis is complete, the existing library of Simics models might well cover a large part of what is needed. There could also be "near misses", where a small adjustment to an existing model is all that is needed. In this way, the ever-growing library of Simics models provides significant short-cuts towards a final system model.
Next, it is time to start building the new models needed to complete the target system. This process is run in an iterative, agile way. We strive to define a minimal subset of the target system that we start with, so that software can be run on the target as soon as possible. The outer loop of the modeling effort is the extension of the overall system model and the testing of software on it. The inner loop is the creation and changing of individual device models, using both model-level unit tests and software tests to drive the development.
The net result is an flexible project where the virtual platform can be updated in reaction to changes to the target system design. Often, modeling projects are begun before the details of the eventual target hardware are completely known. As shown in the picture below, the result is a series of incremental model deliveries that represent the current design state of the hardware.
This modeling method applies regardless of whether the modeling being performed is pre-hardware (for a new chip that might not even be announced yet or a new board built on existing components), post-hardware for a board or system that exists right now, or post-obsolence for an old system that still needs to be maintenaned.
Modeling can be done by Wind River, Simics users themselves, or third-party services firms. All Simics users are equal in what they can model and their access to the Simics modeling tools and APIs.
To learn more about system modeling with Simics, please read our new white paper on creating virtual platforms with Simics.
Happy modeling! And remember - resistance is futile, you will be simulated!