SimBricks Integration Possibilities

Virtual prototyping is fundamentally a means to an end, a tool to use with other tools and integrate into processes and infrastructure. With SimBricks we have always placed particular emphasis on flexible and easy integration and have further improved both with our recent re-design. In this post we outline two integration challenges and how we address them.

Challenge 1: Integrating Your System Components into Virtual Prototypes

Virtual prototyping requires a concrete system, typically some combination of software and hardware component. While some of these components may be standard off-the-shelf components, others come from the user — at the very least typically some applications and software configuration, but also be a custom hardware SystemC or RTL implementation. To run a virtual prototype, these components somehow need to be integrated into SimBricks.

Integrating software into a SimBricks virtual prototype is simple. The user first builds their software components using their usual process. Next the user needs to integrate the binaries and configuration files into a disk (or other storage media format) image for the virtual prototype. If users already have images, e.g. for testing in simulators or other testbeds, they can reuse these images . Otherwise, users can either build custom images from scratch or extend and customize the default SimBricks disk images. To make this as easy as possible, we provide two pre-configured and automated means of doing this. Simple changes, such as copying a few files into an image, can be made directly through the SimBricks orchestration framework as the virtual prototype prepares to execute. For more complex changes, we provide templates for customizing disk images ahead of time through Packer.

Hardware component implementations such as SystemC or RTL components can be integrated similarly. Users build these using their usual process, and then pass the built component to a corresponding simulator, either right when the virtual prototype runs, or beforehand in case of long simulation build times.

Challenge 2: Integrating Virtual Prototyping into Your Processes and Infrastructure

More generally, virtual prototyping integrates into existing processes and infrastructure depending on the problem to solve for the specific use-case. During development, engineers may interactively run and debug virtual prototypes from the command line or their IDE. For automated testing of hardware and software components, virtual prototypes may run test suites from within continuous integration (CI) pipelines. Or for sales demos, virtual prototypes may be run by your customers directly from their devices. On the other end, larger virtual prototypes are often too computationally intensive to run on user laptops, and should instead run on shared servers or managed clusters. For all of this virtual prototyping needs to integrate in different ways with existing processes, tooling, and infrastructure. Inputs come from elsewhere, virtual prototypes are controlled and runs initiated from elsewhere, and output is also consumed and processed elsewhere.

The new SimBricks architecture provides a very flexible mechanism to cover a broad range of different use-cases and integrations with one solution. The new architecture completely decouples the configuration and control of virtual prototype runs, from where the actual virtual prototype simulators execute. Virtual prototype runs may be started from within an IDE, the browser, or a CI pipeline with inputs passed along, to then execute on runners running elsewhere on different machines potentially even managed by separate teams, before receiving outputs back and processing them depending on the use case. Engineers may inspect output interactively in the IDE or a terminal, a CI pipeline may parse output for expected patters, and customers running a sales demo may only see simplified outputs in a browser rendered by a custom frontend. During all of this, the separation in the new architectures also enables you to enforce policies, such as who can run what configurations, access which simulator licenses, or preventing any access to confidential simulation models.

Stay tuned for more future posts, including concrete example use-cases, and interactive demos! Until then: