The frustrating reality for device makers is that the only way to deliver the new and innovative features, greater security, and better performance that their customers are asking for, is to engage in “whole stack” co-design, evolving hardware, firmware, runtime (OS), and development toolchain in tandem. Doing so allows hardware and software teams to address complex tradeoffs around where in the stack to implement functionality and optimizations.
Unfortunately, co-designing is often the key driver of lengthening design cycles—and therefore, costs—when proper simulation tools are not in place.
In this article, we explain how the use of open-source functional simulators like Antmicro’s Renode can be an integral part of hardware-software co-design efforts. Further, we’ll show you an example of how Renode users are able to leverage the tool to drastically reduce the length of their design cycles, provide a simple and effective means for customers to evaluate their solutions, and to begin adapting software collateral in parallel with hardware integration efforts.
Where Software Simulators Can Fall Short
The importance of picking the right simulation tool is best illustrated in the case of Dover Microsystems.
Dover’s CoreGuard® technology is the only solution that prevents the exploitation of software vulnerabilities and enables processors to defend themselves against network-based attacks. Dover was able to accomplish this through eight years of research and development—first as the largest performer in the DARPA Crash Program, and then at Draper Labs—which resulted in a unique hardware/software hybrid solution for embedded systems.
This hybrid solution requires tight integration between both hardware and software components. CoreGuard silicon IP is a sentry processor that acts as a bodyguard, protecting embedded systems from cyber attacks. It monitors every instruction executed by the host processor to ensure that it complies with a defined set of security, safety, and privacy rules called micropolicies—the software component of CoreGuard. If an instruction violates an existing rule, CoreGuard stops it from executing before any damage can be done.
To accomplish this, CoreGuard needs to keep up with the execution of the host processor. That is, on average, it must be able to retire (approve via micropolicies) instructions at the same rate as the host processor being protected. It is also desirable that CoreGuard minimize the amount of memory required for metadata management.
Therefore, meeting the performance, power, and area demands requires a complex interplay of optimizations from both hardware and software layers.
The hardware team at Dover uses a standard SystemVerilog-based process and toolchain. Initial prototypes of the CoreGuard system are built on RISC-V based SoCs. Because CoreGuard has a substantial software component in addition to the hardware IP, it was important that the software team be able to start well before any hardware prototypes were available.
The software team at Dover initially used the Spike RISC-V ISA software simulator that is available from the RISC-V GitHub repos. They encountered two problems basing their commercial development of CoreGuard around Spike:
- Spike does not provide any realistic peripherals; that is, Spike is an ISA simulator, not an SoC simulator. The Dover team started adding peripherals such as UARTs and persistent storage to Spike, and this was a lot of work.
- Spike, by definition, is RISC-V specific, but Dover Microsystems’ initial customers are both RISC-V and Arm-based.
These shortcomings highlighted Dover’s need for a flexible multi-architecture simulator with the concept of peripheral models to be used in place of Spike.
How Renode Addresses Important Co-Design Needs
Facing similar heterogeneous hardware/software co-design engineering challenges stemming from work with open-source softcores, early software for leading-edge computing platforms, FPGA SoCs, and emerging CPU architectures such as RISC-V, Antmicro—an open-source-focused technology and services provider—developed a flexible simulation framework called Renode.
Renode is a hierarchical, modular simulation framework aimed at running real production (i.e., unmodified) firmware in a variety of complex systems, including interconnected multi-node, multi-architecture, heterogeneous, MCU-level and Linux-capable systems.
To tackle these various levels of complexity, Renode is built around a strong notion of abstraction and adopts an object-oriented, modular approach to system simulation. Cores and peripherals are seen as building blocks that can be connected over interfaces in different configurations, reflecting how real SoCs are built.
Figure 1. An example of a simulated RISC-V SoC.
Figure 1 shows an example of a simulated RISC-V SoC. Each building block, including the CPU, has a set of properties and APIs which can be used to construct the simulation model of the entire SoC. Similarly, single nodes can be further combined into a multi-node system using virtualized wireless and wired connections (6LoWPAN, UART, Ethernet etc). All this does not require changes to Renode’s codebase but is done via configuration and scripting, diminishing the learning curve and limiting codebase fragmentation.
The Renode framework’s flexible nature, its open-source availability, and the existence of commercial support provided by its authors made it easy for Dover to first build a prototype implementation of their desired workflow and then contract Antmicro to implement (and release into the open-source domain) functionalities that made Renode even better suited for their use case, such as per-instruction execution.
In particular, using Renode, Dover engineers are now able to:
- Switch between Arm and RISC-V based integration efforts using the same setup.
- Prototype SoC’s (both reference/minimal and customer-defined) at different levels of detail/fidelity.
Model the hardware architecture specification from Dover’s hardware group, then write and test firmware against those models, all while the hardware is under development.
How Renode Significantly Decreased Dover's Design Cycle
Dover’s CoreGuard technology is a hybrid cybersecurity product in which both hardware and software designs are evolving. As a result, it is important Dover’s development process allow for parallel development and testing of both hardware and software.
Figure 2. The development process used by Dover.
Dover is using the development process outlined in Figure 2. The hardware and software teams collaborate on the hardware interface (which of course will continue to evolve). As the hardware team starts implementing blocks in SystemVerilog, the software team creates models of the new blocks in C#, the native language underlying Renode. The software team is then able to write firmware that communicates with the new hardware interfaces, and test that software under Renode simulation. Eventually, the software is run on an FPGA emulator.
This development process, made possible by Renode, has helped Dover optimize both “low fidelity” and “high fidelity” simulations.
While this “low fidelity” simulation abstracts away all of CoreGuard’s hardware logic, Dover still finds this setup useful in the following contexts:
- Micropolicy Debugging: When new CoreGuard micropolicies are being developed, we want to quickly iterate against a variety of software tests, to check behavior.
- Demos and Customer Previews: For CoreGuard demonstrations, pure software simulation is often sufficient to educate a potential customer about CoreGuard’s® capabilities and to stimulate interest in further discussion. Furthermore, Dover will often deliver an “SDK” to customers consisting of this “low fidelity” simulator with a few predefined micropolicies, in order for the customer to “play” with CoreGuard, including possibly running CoreGuard micropolicies against the customer’s software.
In “high fidelity” simulations, which replicate a more accurate hardware model, the Dover engineering team has been able to recognize a number of benefits with Renode, including:
- Integrating with various non-ELF (e.g., scatter-load) binary formats used by hardware boot ROMs.
- Developing and testing the boot process; copying from flash to RAM, initializing devices.
- Debugging bus traffic using Renode instrumentation.
- Debugging peripherals (UARTs, PICs, the CoreGuard interface itself) by instrumentation.
- Playing with the memory map.
- Implementing HDMI video firmware, before the hardware was working.
As indicated earlier, there are some challenging performance and area constraints that next-generation solutions like CoreGuard place on SoC design teams during implementation.
In order to increase performance and reduce memory usage, there is a wide range of optimizations that need to be made, which frequently cross the hardware/software boundary.
It is critical that design teams able to explore a large range of possible hardware/software co-optimization techniques and tradeoffs, without a large, serialized “first-hardware-then-software development process.” A flexible software functional simulator such as Renode allows Dover engineers to collaborate across the hardware-software divide to find optimal trade-offs between hardware and software complexity, making it integral to their efforts.
To learn more about how Renode can streamline co-design projects, visit renode.io. To learn more about how CoreGuard can protect embedded systems from network-based attacks, request a demo to see CoreGuard in action.
This article was co-authored by Michael Gielda, VP Business Development and co-founder of Antmicro.
Industry Articles are a form of content that allows industry partners to share useful news, messages, and technology with All About Circuits readers in a way editorial content is not well suited to. All Industry Articles are subject to strict editorial guidelines with the intention of offering readers useful news, technical expertise, or stories. The viewpoints and opinions expressed in Industry Articles are those of the partner and not necessarily those of All About Circuits or its writers.