How to Automatically Create a Semiconductor C/C++ API for Embedded Code

System-on-chip (SoC) projects, by their very nature, involve both hardware and software. Most people define an SoC as a chip containing one or more processors that run embedded code. The total functionality of the chip is dependent upon this software; the hardware alone can’t do the job. Automating the development flow for an SoC requires automating not just the design and verification of the hardware, but also certain aspects of the software as well.

The HSI and its API

Since the hardware and software in the SoC must work together to enable functionality, some sort of interface is required. The hardware-software interface (HSI) fits the bill. It is the mechanism by which the embedded software (or firmware) configures and controls the hardware, and by which it gathers results and status back in return. Defining a complete yet efficient HSI is one of the key aspects of SoC development, starting from the earliest stages of design.

The hardware side of the HSI is a set of architecturally-defined, memory-mapped addressable registers. A modern SoC may have thousands of such registers, each with multiple fields. There are many special types of registers in common use, including indirect, indexed, read-only/write-only, alias, lock, shadow, interrupt, counter, paged, virtual, and read/write pairs. Some registers and fields are used for configuration and control, while others are dedicated to reporting status.

Rather than the embedded software addressing these registers as regular memory locations, an application programming interface (API) provides the access mechanism. For example, a call to an API function such as “diable_floating_point_mode” might set or clear the relevant bits in the proper fields of the proper registers. This makes for much more readable embedded code than simply writing binary values to a binary register address in memory space.

The SoC Consistency Challenge

Since the functionality of the SoC depends on hardware and software, it is essential that both remain in sync. This is a challenge for several reasons. For a start, both the register set and the API are defined in specifications written in a natural language such as English. Such specifications are subject to different interpretations by different project teams. The engineers designing the register transfer level (RTL) hardware might not be fully aligned with the embedded programmers writing C/C++.

Just keeping the register and API definitions in sync within the written specifications can be an issue since register definitions evolve many times over the course of the project. Product requirements change, competitors introduce new features that must be matched, and issues are found during design implementation. Some changes in the registers require changes in the APIs, and it is easy for the specifications to fall into internal inconsistency.

All these changes must also ripple downstream on the project. Any register change requires updates to the RTL design as well as the C/C++ header file that defines the registers and their fields. Any changes in the API require further changes in the embedded code. Many other files used in the development flow, such as verification tests and testbenches, must also be updated whenever specification changes occur. The resulting chaos can cost precious resources and delay the project schedule.

The Specification Automation Solution

The only answer for this dilemma is specification automation, the process of generating as many project files as possible from golden executable specifications. In the case of programmable registers, specification automation is well established. Industry standards such as SystemRDL and IP-XACT provide unambiguous formats to define all registers and fields, and recent advances in artificial intelligence (AI) have made even some natural language register specifications executable.

From the executable register specification, the SoC team can generate the RTL design, verification and validation tests and testbenches, bringup tests for the actual chip in the lab, and end user documentation. Further, they can generate C/C++ header files that include the API to define and control the registers. This code can be used in any type of software that uses the API, from firmware, device drivers, and diagnostics to complete applications.

With this level of automation, the hardware and software parts of the SoC remain in sync. Whenever the registers change, all the hardware, verification, validation, documentation, and software files can be automatically regenerated. This save an enormous amount of manual effort and ensures consistency at all stages of the project. No time need be spent in debugging test failures due to inconsistencies from different interpretation or file versions.

 

SystemRDL Input:

Header Output:

Conclusion

Any SoC, by its very nature, consists of a combination of hardware and embedded software. The best way to ensure a consistent, automated flow is with specification automation. The Agnisys IDesignSpec™ Suite is the industry’s most powerful and robust solution for specification automation of SoC designs, including the programmable registers. All teams should be using it to save resources, shrink schedules, and improve quality.