Arm SystemReady Compliance Using Emulation

Yesterday in my post Cadence and Arm I wrote about how Cadence has worked with Arm over the last decade or more. Well, it is Arm again today since there is an Arm event at which Cadence is giving one of the presentations.

Today is the second day of the Linaro and Arm SystemReady Virtual Tech Event. In case you don't know, let me explain a couple of things:

• Linaro is an organization that is driving open-source development on Arm. Arm is a member of Linaro, along with other members such as Microsoft, Google, and Oppo.
• SystemReady is an Arm program aimed to help partners design successfully for system requirements. In the context of Linaro, that is bringing up SoC chips that support existing software stacks. Amongst other aspects.

Obviously, one way to see if your SoC can bring up all the appropriate software is to build the chip and see, and then adjust the software until it runs correctly. There are a lot of obvious problems with that approach, not just that it stretches out the development schedule unnecessarily, but more seriously in the worst case it may not be possible to adapt the software without hardware changes and a respin. When a prototype takes several months to manufacture in the fab, and costs several million dollars, this is clearly...let's just say not the optimal approach.

Today, at the event, Arm's Francisco Socal and Cadence's Pankaj Kakkar presented Enabling SystemReady Compliance Early in Design Using Emulation and Controllable End Point.

There are a number of aspects to Arm SystemReady, and, this being high-tech, lots of acronyms. The idea is that common components like operating systems, hypervisors, and middleware "just works". Starting from the bottom, the Arm SystemReady stack is:

• Base System Architecture (BSA/SBSA). The S in SBSA stands for Server since that can be used if the design is "server-like"
• Base Boot Requirements(BBR/SBBR)
• Architecture Compliance Suite (ACS)
• Certification program

These specifications enable hardware and firmware compatibility. Certification provides evidence and confidence.

The basic flow for developing an Arm SystemReady system is above. It can't be emphasized enough that BSA/SBSA compliance is required to be SystemReady. Let's dig in a little:

BSA is a hardware architecture. System compliance testing is needed during design and verification. Pre-silicon exercisers provide complete BSA compliance covering, including of PCIe subsystems. Integration and hardware compliance issues are common and lead to software-visible defects and interoperability issues.

Sometimes BSA issues can be resolved in software, but there are several problems with this:

• it is costly, challenging, and not always feasible
• it is time-consuming to upstream to the official source, and the changes are not always approved by the maintainers even so
• solutions are often suboptimal even when they are possible...and sometimes they are not acceptable in the end-market
• it may be impossible and the worst-case scenario is a respin

The above table shows some of the typical hardware compliance issues. The basic message is that these issues can be detected early in the design cycle using emulation, long before building any silicon. Let's look at the flow to do that.

This allows you to run bare-metal tests early, and then bring up UEFI (Unified Extensible Firmware Interface, what BIOS is called these days). Later, everything should come up immediately on the silicon and get certified.

The above diagram shows the BSA/SBSA compliance solution using the Cadence Perspec BSA/SBSA Traffic Library to drive the compliance tests. A bare-metal platform abstraction layer (PAL) is generated to interface to the bare-metal software. This software contains simple drivers for PCIe, SMMU, GIC, and some other required peripherals such as a timer. 

Summary

Arm SystemReady helps design groups in early pre-siilicon compliance to BSA/SBSA specification.

Cadece provides a solution in the form of the Perspec BSA/SBSA Traffic Library to enable compliance testing on Palladium Z1 or Z2. For groups who have no Palladium, Cadence also offers Palladium Cloud.

Cadence and Arm are actively engaging with early partners (and seeking more) to further deploy this solution.

Learn More

The Arm SystemReady page.

The Cadence Emulation (Palladium) product page. The Perspec System Verifier product page. 

I Googled "bsa traffic library" to see if we had a product page for that. I got the Boy Scouts of America traffic safety merit badge. I guess this post is similar, all about getting the Arm SystemReady merit badge. But I'm afraid Arm SystemReady Certification doesn't come with an actual badge to sew on your sleeve.

Sign up for Sunday Brunch, the weekly Breakfast Bytes email.

.