Ibex Inside: How and Why We Built OpenTitan’s RISC-V Core

OpenTitan® recently announced the RTL freeze of Earl Grey, the first chip tapeout of its open source silicon root of trust (RoT). The first engineering samples should be in our hands before the end of the year.

OpenTitan’s mission is to provide a secure root of trust, which is complemented by a secure processor core. To address this need, we elevated one of the most widely deployed, highest quality RISC-V cores in academia to the industrial-level of quality characteristic of this project. While we were at it, we added additional hardening and security features of broad utility to all who may want to reuse Ibex in other designs.

More specifically, the development of a processor core, such as Ibex, goes beyond the RTL design itself. In order for the design to be viable for commercial usage, several additional aspects need to be considered and addressed. This blog post highlights the importance of comprehensive design verification (DV), how we utilized DV in the development of Ibex, and the role of regressions. This blog is based on a speaking session I presented at the RISC-V summit if you want to watch the video.

What is Ibex?

Ibex is an open-source 32-bit RISC-V core, designed with extensions specifically tailored for security, IoT, and embedded applications. Some of the notable features of Ibex include its ePMP (Enhanced Physical Memory Protection) support, debug capability, instruction cache, and a flexible 2 or 3 stage pipeline.

One of the key strengths of Ibex lies in its highly configurable nature. Developers can tailor Ibex to meet their specific requirements, enabling them to optimize the core for different use cases. This configurability ensures that Ibex can be seamlessly integrated into a variety of systems and scenarios.

Ibex is integrated within the Earl Grey chip in a dual-lockstep configuration as a fault-injection mitigation mechanism, adding an additional layer of physical attack protection to the platform. This feature is particularly relevant for use in OpenTitan, where a robust and secure foundation is even more important for building trustworthy systems.

Why does design verification and testing matter?

While RTL design is a crucial component of a processor core, it is only one aspect of the overall development process. Like all OpenTitan components, Ibex emphasizes the importance of design verification (DV) processes, which ensures the reliability of the core, and allows developers to choose Ibex as the foundation for their projects with confidence.

Design verification needs to be credible to demonstrate the core’s robustness. This requires the development of complete test plans and coverage plans that encompass a wide range of scenarios and potential corner cases. Nightly regressions with published results enable ongoing monitoring of the core’s performance and progress, providing valuable insights into its stability and reliability.

In addition to verification, the RTL needs to be consumable by a variety of EDA (Electronic Design Automation) tools to ensure compatibility with different developer toolchains. Additionally, having a lint clean RTL helps identify and eliminate potential coding issues that could impact performance or functionality.

How does Ibex facilitate design verification and testing?

Ibex’s DV strategy involves specifying tests that focus on different scenarios, enabling thorough coverage of the code and functionality. By systematically designing tests for different scenarios, our developers have ensured that the core performs as intended across a wide range of use cases.

Ibex leverages randomized programs generated by RISC-V DV. The RISC-V DV tool generates programs that stress different features of the core, enabling comprehensive testing and bug detection, by generating stimuli to test the core’s behavior under various scenarios.

In addition to these randomized tests, Ibex employs a UVM (Universal Verification Methodology) testbench with configurable sequences for constrained randomized stimulus. This provides a framework for generating stimuli that target specific aspects of the core’s behavior. The sequences are configurable, allowing developers to control the input parameters and stimuli generation, such as instruction and data memory accesses, interrupts, and debug requests.

Co-simulation with Spike ISS (Instruction Set Simulator) is utilized to ensure the core behaves as expected. This involves running the same stimuli in both the RTL implementation of Ibex and the Spike ISS, and comparing their outputs. Co-simulation also includes checking all data memory accesses to verify the integrity of memory operations.

Functional coverage is gathered at both an architectural level (e.g. checking every implemented instruction has been tested) and a microarchitectural level (e.g. checking we’ve seen all combinations of pipeline stalls and instruction types). Full coverage includes everything specified in the coverage plan, which is achieved with a combination of randomized and directed tests.

Directed tests are carefully crafted to target specific scenarios that might be challenging to achieve through randomized programs alone. By designing directed tests, developers can explore corner cases and edge conditions that could be missed by random stimuli, ensuring comprehensive testing coverage.

What is the role of regression testing?

Regression testing plays a crucial role in ensuring the consistency and correctness of the Ibex design. As part of lowRISC’s working practices, these tests are run regularly to monitor the project’s status.

The results of these regressions are carefully monitored and triaged. Any failures or issues that arise during the regression tests are investigated and addressed by the project team. This proactive approach ensures that issues and bugs are identified and resolved in a timely manner, preventing potential problems from accumulating and affecting the overall project health.

To provide transparency and accessibility to the regression test results, lowRISC maintains a public website where the latest reports can be accessed. This report provides comprehensive information about the regression test results, allowing stakeholders and developers to review the project’s status, track improvements, and monitor any ongoing issues.

Why work with Ibex?

Ibex began as a high quality academic core, zero-riscy, which lowRISC adopted from our OpenTitan partners ETH Zürich, because of its strong alignment with the project’s principles of transparency, high-quality and flexibility. By adding DV and regression testing to Ibex, we have taken an already high-quality design to the next level.

The open source nature of Ibex provides developers with the freedom to configure the core as they see fit. Like all collaboratively developed IP supported by the OpenTitan project, Ibex is permissively licensed and provides a strong foundation for others to build both non-profit and commercial designs upon.

Open source projects rely on contributing partners to thrive: support and contributions from the community are essential for success and sustainability. By engaging with contributing partners, Ibex can continue to evolve and improve, benefiting from the collective effort of those who are actively involved.

If you are already using Ibex or are interested in supporting its development, there are opportunities to get involved and make a difference. By reaching out to us at lowRISC via email at info@lowrisc.org, you can express your interest in supporting our work or contributing to the ongoing development of Ibex. Your involvement can help shape the future of Ibex and contribute to the advancement of open source hardware!