System-on-Chip Integration Complexity And Hardware/Software Contracts

From the earliest days of my career, when designing chips, I have always navigated the interface between hardware and software for semiconductor design in my roles. My initial chip designs included video and audio encoding and decoding, supporting standards like MPEG and H.261. As acceleration parts of hardware/software systems, these had many Control and Status Registers (CSRs) to program. Their management was critical even in the 1990s, and they stood out as both a cornerstone and a potential pitfall.

As I wrote in “Design Complexity In The Golden Age Of Semiconductors,” modern SoC designs are mind-bogglingly complex, often housing hundreds of IPs, each with millions of gates. When diving deeper, one finds CSRs within these IPs in the hundreds of thousands. The numbers skyrocket because each CSR can consist of multiple fields—with an average of five fields per CSR. These aren’t just abstract numbers; they represent a precise choreography between software and hardware, demanding flawless execution.

CSRs are the contract between hardware and software developers.

SoC integration complexity using the Texas Instruments OMAP family as an example.

To visualize that contract complexity, I overlaid the Texas Instruments public versions of some OMAP processors over the classic growth chart of transistors. I also downloaded the Technical Reference Manuals (TRMs) of the Texas Instruments OMAP 35x Application Processor, OMAP 4460, and OMAP 54x Multimedia Devices and counted pages and CSR definitions. To make complexity growth personal, I also included a derivative of the last chip I was involved in in the late 1990s, the Fujitsu MB86H20 MPEG-2 Decoder for Set-Top-Boxes.

We are looking roughly at a 2x increase in TRM pages and registers from OMAP 35x to OMAC 54X in about a decade. And – yes, it’s apples and oranges – compared to the Fujitsu MB86H20, we are looking at an order of magnitude of increased complexity. And, of course, Texas Instruments developed the last versions of OMAP almost a decade ago, so complexity has increased, and designs now often are chiplets, with complex crossing across chiplet boundaries.

Arteris FlexNoC interconnect in OMAP54x TRM. Source: Texas Instruments

As an aside, while doing the late-night studying of TRMs, it was great to run into the reference to Arteris FlexNoC in the OMAP54X TRM and the chart above.

Back to registers. So what can go wrong?

When leading emulation, virtual, and FPGA prototyping product management teams earlier, I was exposed to many hardware/software interface issues with customers. One memorable example included a case filed as a bug in the emulator. The software developer had programmed a register in the hardware residing in the emulator. The hardware didn’t react. The hardware developer who had created the RTL wasn’t sure what happened, pointing to the hardware/software CSR interface spec. They did not know each other – the running joke is that when you get your customer’s hardware and software teams into one meeting room, they will likely pull out business cards to introduce themselves. They were both violently aligned that the issue must have been the emulator’s fault.

After 10+ iterations of finger-pointing, we finally managed to get to a joint debug session. Following the trace in detail, it was not the emulator’s fault. The emulator worked the CSRs correctly, but the hardware modules didn’t react. Escalation led to more finger-pointing until, merely by accident, the low-power team lead read the email thread and identified that this particular domain was in shut-down mode for this test case, and the hardware correctly didn’t react. Oops.

CSRs, the contract between hardware and software developers, are complex in their interactions.

The stakes?

The stakes are very high. CSR mismanagement can lead to expensive oversights. Consider the possibility of a device requiring a total respin, an endeavor that can cost millions and jeopardize market launch schedules. The ramifications are not just financial. Missteps can compromise a company’s competitive edge. With CSRs, we’re looking at a staggering 6,000 combinations of hardware/software behavior for each field—a veritable maze of configurations. My AE colleagues dealing with SoC Integration Products at Arteris tell me that domain-specific SoCs see CSRs occupying up to 15% of the total die area. And as technology progresses, this figure is only set to increase, further emphasizing the need for CSR proficiency. In-house IPs present another layer of complexity. Unlike third-party IPs with established guidelines, custom IPs—often a company’s unique selling proposition—are in constant flux. These frequent CSR modifications necessitate vigilant management to prevent catastrophic errors.

Automation, here we come!

Can a design team specify 1000s of registers manually? Maybe. But do you want to risk it, given the stakes? You don’t need to.

Arteris’s CSRCompiler is a seasoned tool designed to address the challenges of Hardware/Software Interfaces (HSI) in system-on-chip (SoC) designs. After over 15 years of refinement, Arteris acquired it in January 2023 and started integration into the Magillem SoC Integration Automation tools. CSRCompiler’s core functionality revolves around its CSRSpec format — a compact language developed to swiftly capture design intent, offering a centralized source for defining register behavior and address map hierarchies. CSRSpec supports over 200 unique properties and over 6,000 hardware/software register behavior combinations.

Beyond CSRSpec, CSRCompiler boasts a versatile range of inputs, including the ability to process IP-XACT, SystemRDL files, and even data from standard spreadsheet applications like Microsoft Excel. Upon execution, the tool meticulously analyzes input data, leveraging over 1,000 built-in checks to catch inconsistencies and errors, ensuring the integrity of the address map.

Recognizing the diverse needs of engineering teams, CSRCompiler offers multiple output formats tailored to different audiences: RTL views in SystemVerilog or VHDL for hardware engineers, software header files in Verilog or C for software developers, and documentation formats like Word, FrameMaker, and HTML web pages. Furthermore, it supports standard outputs like IEEE 1685 IP-XACT and IEEE 1800.2-2020 UVM.

To summarize, minor changes in CSR definitions can trigger significant repercussions in the SoC and chiplet-based design realm. A solitary tweak in a CSR might spell disaster if not diligently tracked and communicated. Given their essential role, CSRs aren’t just about engineering precision; they’re at the heart of successful SoC business strategies.

And CSR automation is no longer an option. It is a necessity.