Managing SoC Hardware/Software Interface With CSRCompiler

Author: Rich Weber

Richard Weber is a fellow at Arteris following the acquisition of Semifore, the company he founded and managed for 17 years as CEO. He has served as a committee member for the IEEE Standards Association and the Accellera Systems Initiative. Rich holds a B.S. in computer engineering and an M.S. in electrical engineering from the University of Illinois Urbana-Champaign.

Many people fail to fully appreciate the difficulties of managing the Control and Status Registers (CSRs) that permeate today’s system-on-chip (SoC) devices. Similarly, they fail to comprehend the catastrophic consequences if the CSRs are not managed correctly and completely. These consequences may result in the device needing to be respun, costing millions, and the delay may cause a more severe outcome by completely missing the market. Today’s SoC can contain hundreds of IPs, each containing millions of gates. Furthermore, these IPs may contain hundreds of thousands or even millions of CSRs featuring a sophisticated combination of software and hardware. The hardware/software interface (HSI) accounts for a large proportion of the problems that arise during SoC development. In fact, the data presented in a recent study from a leading research firm suggested that as many as 1-in-7 SoCs must be respun due to HSI errors stemming from CSR mismanagement.

Grasping the Scale of the Problem

In many ways, it’s difficult for a non-engineer to fully grasp the scale of the CSR problem. Each CSR is composed of multiple fields, and on average, there are five fields per CSR, each consisting of multiple bits. So, an IP with 100,000 CSRs will have approximately 500,000 CSR fields and several million CSR bits

with a universal format to exchange and reuse information about IP and subsystems.

Things have changed with the IEEE 1685 (IP-XACT) standard, which is an eXtensible Markup Language (XML) format to exchange and reuse information about IPs and subsystems that defines and describes, among others, the interfaces associated with IPs. IP-XACT models natively cover only the software side of the interface. Even so, the 2014 version of the standard documents 104 different combinations of software access behavior associated with CSRs. When the hardware side of the interface is also accounted for, over 6,000 combinations of hardware/software behavior can be associated with each field in a CSR.

This would be bad enough if an IP contained only a few CSRs, but some design domains make extensive use of these registers. In the case of an IP in an SoC intended for use in the networking domain, for example, there is usually a very large CSR interface between the core logic (network accelerators) and the software device drivers. Graphics is another application area where the software interface can be enormous. In fact, in the case of some domain-specific SoCs, the CSRs can account for anywhere from 5% to 15% of the total die area. And, just in case things weren’t bad enough, the industry is currently seeing a doubling or tripling of the number of CSRs with each new technology node coupled with each new SoC generation.

Managing CSRs is complex enough when working with proven IPs provided by reputable third-party vendors equipped with associated IP-XACT models. The problem is exponentially more complex when working with IPs that are designed and developed from the ground up in-house. These are the secret sauce IPs that will differentiate this SoC from the competition, which means they tend to be the largest and most complex IPs in the SoC.

During the initial stages of developing in-house IPs, the CSRs associated with the IP may be modified hundreds or thousands of times daily. Bits are added, removed or renamed in fields; fields are added, removed or renamed in CSRs; and the hardware/software behaviors of fields may be modified at any stage of the game. Even when things start to slow down as the design progresses, a single modification to an individual bit in a solitary field in an obscure CSR could lead to disaster if not all interested parties are made aware that this change has taken place.

Many activities need information about the HSI. These include device drivers and firmware, hardware design and verification, technical documentation, system diagnostics and application software. All of them need accurate, up-to-date HSI information in many different and specialized formats. A lack of unified, up-to-date information results in poor collaboration and an increased opportunity for design errors. Changes made to the HSI as the design matures introduce additional opportunities for error.

The Solution Is CSRCompiler

The CSRCompiler was developed to design and implement hardware/software interfaces, addressing the CSR challenges faced in each and every SoC. The tool has evolved over more than 15 years and has become the trusted solution in the field. In January 2023, Arteris announced the acquisition of Semifore, and CSRCompiler became part of the company’s portfolio of network-on-chip (NoC) interconnect IP and SoC integration automation tools, helping to better address SoC connectivity challenges all engineers face.

Figure 1. CSRCompiler’s Inputs and Outputs (Source: Arteris)

CSRCompiler can accept CSR definitions in multiple formats (Figure 1). First and foremost, it has its own CSRSpec format, which is a compact, easy-to-use language to quickly capture design intent. CSRSpec provides a single source to specify register behavior and address map hierarchy. In addition to powerful parameterized templates, CSRSpec supports over 200 unique properties and more than 6,000 hardware/software register behavior combinations.

As alternatives to CSRSpec, CSRCompiler can read and write IP-XACT, process and produce open-source SystemRDL files and import data from typical spreadsheet applications like Microsoft Excel. When CSRCompiler is executed, it performs a strict lexical analysis, parse tree evaluation and semantic and syntactic checks on the incoming CSR data. This extensive error checking and validation, with over 1,000 built-in checks, allows users to identify issues before they become problems that lead to catastrophes, ensuring the address map is self-consistent.

It is important to understand that although there is only one HSI for an IP, different groups have very different and unique ways of looking at that HSI. Hardware design engineers want to be presented with a register-transfer level (RTL) view, software developers wish to see software header files, and verification engineers require yet another view in a different format. For this reason, CSRCompiler, which can run in a matter of seconds, generates RTL in SystemVerilog or VHDL, header files in Verilog or C, HTML web pages, documentation in Word or FrameMaker, and a variety of other file formats (e.g., IEEE 1685 IP-XACT and Accellera/IEEE 1800.2-2020 UVM).

Figure 2. CSRCompiler’s Design Work Flow (Source: Arteris)

Conclusion

Creating a complex SoC requires contributions from multiple teams, including RTL architects, software developers, verification engineers and the technical publications group in charge of documenting everything.

Arteris CSRCompiler addresses the requirements of all these parties (Figure 2). For RTL architects, the ability to capture CSR definitions in a standardized self-checking form that generates 100% correct by construction RTL makes their lives easier. The benefits for software developers include a single-source specification that generates consistent documentation combined with RTL and C header files. Verification engineers also benefit from consistent documentation and a single-source specification that generates the required SystemVerilog testbench register model and register information. The technical publications team benefits from having access to 100% accurate documentation automatically generated in multiple views in Word or FrameMaker.

Visit Arteris to learn more about the benefits of CSRCompiler, as well as Arteris NoC IPs and SoC integration automation tools and technologies.

Categories: IP, SOC

This entry was posted on Wednesday, October 25th, 2023 at 11:25 am. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.