Using Wind River* Simics* for running software and system tests has many advantages over using hardware—for debugging, variation, scaling, fault injection, automation, pre-silicon software readiness, and more. In this is second part of my interview with Mambwe Mumba, we look at how to make it easier to realize those advantages in your workflows by leveraging containerization and associated technologies. In part one, we introduced the concept of containers and how Simics runs in containers. In this part, we look deeper into the workflows enabled by containerized Simics setups.
JE: Mambwe, what are the advantages to running Simics inside a container compared to using a Simics installed natively?
MM: Independently of Simics, if we look at container technology we see that it offers a compelling list of advantages: portability, immutability, low resource usage foot print, scalability, host agnosticism and setup time, and reproducibility time savings. Simics now inherits all these advantages, once containerized. Somewhat like wearing a magical cloak that bequeaths its wearer with all its magical properties.
JE: What do these properties mean for Simics?
MM: It means a lot of different things including resolution of pain points currently experienced in Simics workflows.
Benefits from putting Simics in a container.
This is illustrated above. Starting from the center, we consider the core properties of container technology that Simics would benefit from:
- Scalability: Containers are at home in a cloud environment, and individual containers can be spun up or down on demand, depending on need and use case. This has interesting implications for continuous integration (CI), for example, any CI workflow—such as BIOS development and testing--that is refactored in a server farm would be able to simply use a containerized Simics instance like a disposable application that can be swapped in and out, without having to maintain a local Simics installation on the server.
- Immutability: Each layer of a Container image is immutable. Any changes or extensions to these layers are written on top of them as a new layer, so that underlying layers are never changed. Once an application has been containerized, there is no need to worry about what it takes to reinstall a specific version of the app. Just use the container as it is. You can maintain multiple clearly-defined and reusable Simics setups that are known to work and use them as needed.
- Low resource utilization: As discussed in our last blog post, containers encapsulate an application like Simics with very little overhead in terms of memory consumption and processing performance. Thus, the resource overhead from the encapsulation is not a factor in deciding how to run Simics.
- Host independence: Regardless of the host a Simics user has, as long as a container engine is running, the user should be able to efficiently run any containerized Simics setup. Note that this only applies for containers within a single type of underlying operating system, like Linux – containers are not an efficient means to cross between Windows and Linux hosts.
- Portability: Container images can be quite small and easy to share, provided one doesn’t try to pack so much functionality into one container. Because the Docker* container engine and system already comes with a means of uploading and sharing, you have an easy way to share images that you can move around from one host to the next. A regular Simics installation is even smaller, but the size overhead from a container is rather small.
- Reduced operating cost: reclaiming time spent wrestling with environment setup can be a big saver, whether setting up for the first time, or trying to replicate a customer’s buggy setup by first replicating their environment. Furthermore, instead of every engineer going through a setup process with all the resulting variety, use of container images means that every engineer can benefit from the initial effort expended in creating an image. The work of one engineer goes much further, benefiting other engineers who no longer have to work through the setup themselves.
All this is compelling enough, but I think the most important aspects of this container encapsulation is the immutability, portability, and platform agnosticism that containerization enables for Simics. The ability to reproduce a setup can be a considerable time sink in light of the various host operating systems that Simics can be installed on, coupled with the fact that there are usually specific versions of Simics packages—virtual platforms for specific hardware—installed on top of the base Simics package.
Containerization enables a user to side-step these environment reproduction issues. Once a container image is compiled, it is made up of immutable layers encapsulating all that the Simics setup needs to run; it is portable, a customer or engineer can share this image with anyone running any similar kernel host OS or just upload the image to a container registry and point anyone to it. Containers are platform agnostic, and for the price of adding a thin layer of complexity, one can run the very same image on any host platform.
JE: Indeed, it sounds like a rather good idea to put Simics in a container. Thus, given that we have a set of containerized Simics setups, what can we do next?
MM: Putting Simics in a container means it can take advantage of all the tools, features, and infrastructure designed and built for containers in the broader ecosystem:
Containerized Simics in the tool context.
To begin with, we can step back and look at how and where containers are used. By far the biggest usage has been in the cloud environment, where containers have been used for encapsulating services known as microservices. The use of containers is more widespread in certain fields, such as in data science and AI, where there has been adoption of containers not just for cloud applications, but for desktop usage as well.
At the desktop, just as in the cloud, users can forgo the struggle to get software to work, while having multiple dependencies on other software, framework, and libraries, by obtaining and running a pre-built container with all the dependencies bundled in. For the specific case of Docker images, the infrastructure that comes with Docker allows any engineers, regardless of their host platforms, to all work with the same tools in consistent setups.
JE: Basically, we get a lot of new deployment options, ranging from automated usage to interactive personal use on a desktop. But how do I get the container images onto a particular host machine? Is it just copying files around?
MM: No, there is infrastructure in place to handle that. Using Docker containers specifically, there are Pooled Community Resources and the Docker Registry. The Docker Registry is a searchable storage location for Docker images – whether created on the host running the registry or pushed to it from another host. Images can be pushed by any engineer who has been given access to it within an organization, and the fact that any user can create his/her own Registry of Docker images means these images can be shared easily. It can be done company-wide or restricted to a specific group. It is even possible to share Simics Docker images across multiple organizations using shared Docker Registries.
External services and Simics containers.
Setting up a Docker Registry means you now have a location, accessible to any number of engineers, from which a pre-packaged Simics application can be downloaded and run. It treats Simics as a downloadable application that runs instantly, like an Android* application downloaded from the Android Market* and automatically installed on a phone.
This also has implications for saving substantial time in supporting Simics and Simics models; a specific user setup can be shared between teams and organizations. All that is needed is to pull the image from the appropriate Docker Image Registry. Alternatively, users could share the Docker file they are using and an equivalent setup will be reproduced.
Using a shared Docker Registry to collaborate and share Simics container images.
The ability to have Simics container images created by and hosted in internal organizational registries also lowers the barrier for sharing knowledge. Should a specific organization wish to share its work, saving other engineers the time it would have taken to do it themselves, the organization can easily give anyone outside the organization access to their Simics container image registry. Friction is removed, increasing efficiency and freeing up engineers’ time for less mundane tasks. As illustrated in the figure above, the process of containerizing and pushing a Simics container image into a company registry amounts to creating an App Store with Simics setups.
Knock-on effects of containerizing Simics.
Beyond the walls of any given organization is the public Docker Hub*. It works in a similar way as GitHub. Just as a public or private GitHub repository exists for source control and sharing of code, you can think of Docker Hub as a means of checking in and checking out images that is open to the wider community.
The final ring shown above summarizes the knock on benefits of containerizing Simics: from easy setup, sharing, and ease of reproducing a setup environment for the individual engineers; access to a shared repository for images both within the company and the wider Docker community; and if the intent is to use containerized Simics images in the public or private cloud, the ability to use Simics in an orchestrated environment such as Kubernetes, with the ability to use Simics containers as an easily swappable piece that is part of a continuous integration pipeline.
In an orchestrated cloud environment, this also implies that the simulation services offered, or the deployed continuous integration, would be more fault tolerant: should a Simics container fail, the orchestrator, say Kubernetes, could just spin up an exact same container to take its place, as no state is saved within any given container. Remember that results are typically saved outside the container.
JE: Thank you, Mambwe. This has been a very informative interview, packing a lot of information. Let me summarize my key takeaways:
By containerizing an application like Simics, you can take advantage of a huge ecosystem of existing tools and flows that add value on top of the application “for free.” In particular, distribution, management, and automation can benefit from containerization, making it easier to build workflows around Simics – without really having to build anything new into the Simics product as such.
Container systems provide a tool to use for integrating Simics into existing and new workflows and automations systems, bringing the advantages at a low overhead cost. It is typically better to use a container compared to using a full virtual machine (VM) for the same job, thanks to the much higher execution efficiency of containers. Compared to a standard Simics installation, containers simplify and increase the reliability of reuse of the same Simics setup, while getting close to the same efficiency.
Running Wind River Simics in containers makes sense for many use cases, especially to ensure consistency and ease of deployment across many users and groups.
Related Content
Containerizing Wind River Simics® Virtual Platforms (Part 1): Mambwe Mumba and I discuss how developers can use containers together with Wind River Simics® virtual platforms. Part 1 deals with the technology of containers and how to use them with Simics.
Simplify Hardware Simulation with Containers: How and where a containerized approach for Simics® simulation improves the general workflow, and the impact of organization-wide adoption of a Simics containerized workflow.
The Early Days of Simics – An Interview with Bengt Werner: A look back at what happened before Simics went commercial in June 1998.
Intentional and Accidental Fault Injection in Virtual Platforms: Once nominal functionality is established, questions come up about how to test abnormal and faulty system behaviors.
1000 Machines in a Simulation: Feats from the past and how they reflect into current technology and best practices.
Running “Large” Software on Wind River* Simics® Virtual Platforms, Then and Now: A look at the past, present, and future of Wind River® Simics® virtual platforms.