Members can download this article in PDF format.
What you’ll learn:
- Today's SoCs include hundreds of complex IP blocks with millions of transistors each.
- CSRs are essential for managing these IPs, with some systems having up to a million CSRs.
- IP-XACT standards help simplify SoC design and automate hardware interfaces.
- Safety standards like ISO 26262 ensure the reliability of SoCs in industries like automotive and aerospace.
System-on-chip (SoC) design has changed dramatically in the last decade, especially in terms of size, complexity, and number of intellectual-property (IP) blocks. Meeting functional-safety requirements like ISO 26262 adds to this challenge.
At a high level, the view of a SoC design is conceptually simple. Logical functions are captured and described as functional blocks called IP blocks. SoC designers typically acquire processor IP from one vendor and additional IPs, such as memory interfaces (e.g., double-data-rate, or DDR, controllers), as well as communications interfaces like USB, Ethernet, and PCIe, from other trusted vendors.
In the past, a typical SoC might consist of a dozen or so IPs, each containing thousands to tens of thousands of transistors. In comparison, current SoCs can have hundreds of IP blocks, each incorporating millions of transistors.
Current trends in SoC design have designers adding their own domain expertise such as audio/image/signal processing, artificial-intelligence (AI) accelerators, radio frequency (RF), analog, and sensors to enable product differentiation, and then integrating the aforementioned “off-the-shelf” third-party IP.
Another aspect of change is complexity. Configuration and management of IP, design configurations, and operational modes are performed using control and status registers (CSRs). IPs from earlier times were largely fixed concerning core functionality. For example, a universal asynchronous receiver/transmitter (UART) IP block might contain only a few tens of CSRs (Fig. 1).
By comparison, a modern DDR memory controller can have thousands or even tens of thousands of CSRs. These registers enable the DDR controller to provide maximum flexibility regarding how data is communicated with the external memory, but they drastically increase the IP management and integration complexity. Modern large processor designs alone can contain upwards of a million or more CSRs. Welcome to SoC design in the 21st century!
Managing CSRs in Complex SoCs
CSRs describe the software interface to the hardware internals of the IP. They perform multiple roles, including:
- Control (software write): Starting, stopping, and pausing operations.
- Status (software read): Detecting interrupt pending, data received, and error conditions.
- Configuration (software write): Setting data-transfer rates and operating mode.
- Capabilities (software read): Identifying supported speeds and data formats.
- Data (software read and write): Handling low-bandwidth IP functions.
- Security features (software reads and writes): Protected access, enabling encryption engines.
Each CSR can have many fields, with each field containing multiple bits and distinct characteristics. Historically, these characteristics were limited to read, write, or both. Today, more than 100 different combinations of software access behaviors associated with CSRs are used depending on the application.
Managing CSRs can be challenging if not handled appropriately. In the past, the best options available were spreadsheets. Unfortunately, it was common to have separate spreadsheets with multiple pages for each IP block. Internally developed IPs often end up with multiple versions due to the design team and architects making simultaneous or conflicting edits. The lack of a central document and data format only compounded the problem.
To this end, Accellera developed the IP-XACT/IEEE 1685 standard. This machine-readable extensible markup language format defines and describes the interfaces associated with IPs. Among myriad other things, a full IP-XACT model can also include definitions of all CSRs associated with that IP.
An IP-XACT Memory Map describes the content visible from a bus interface, while an IP-XACT Address Block represents a contiguous block of memory (physical memory, registers, or reserved blocks of memory) within a Memory Map (Fig. 2).
Tools have been developed that let SoC designers access the CSR definitions from all of the IPs forming the device, gathering them together into a sole source of truth shared by all members of the design and verification teams. Moreover, these tools can generate the RTL descriptions in VHDL, Verilog, System Verilog, and C Header files corresponding to the CSRs associated with each of the IPs for incorporation into the SoC.
Applying FuSa Concepts to CSRs
One aspect of CSR automation that remains largely unaddressed is functional safety (FuSa). The underlying concept of FuSa is that SoCs will automatically respond to any changes in their inputs or internal failures in a predictable, fail-safe manner. Examples of FuSa-related standards include DO-254, which guides the development of airborne electronic hardware, and ISO 26262, an international standard for electrical and electronic systems installed in road vehicles.
It would be great to apply the highest levels of FuSa to every aspect of every system in the world. This isn’t feasible, though, because of the costs involved, such as design time, system size, and power consumption.
In the case of vehicles, for example, ISO 26262 defines a risk classification system called the Automotive Safety Integrity Level (ASIL). This spans from ASIL A, which is the lowest degree, such as a taillight malfunction, to ASIL D, the highest degree, exemplified by the complete loss of the braking system, in the classification of automotive hazards. Each ASIL level requires a different degree of response.
Similarly, applying FuSa concepts in the case of CSRs requires that each register is classified in terms of the potential hazards associated with any failures. Based on this classification, the next step is to determine the appropriate way to implement each register to satisfy its FuSa requirements.
Implementing CSR Functional Safety
There are multiple possibilities for implementation. The lowest level is to perform a byte-level parity check, where an error will raise a flag. Another possibility is register duplication, where each register is duplicated, the contents of both registers are compared, and any discrepancy causes a flag to be raised.
The next level of sophistication would be triple mode redundancy (TMR), which involves triplicating the register and then using a majority-voting system to produce a single output. If any one of the three registers fails, the other two can correct and mask the fault (Fig. 3). Yet another possibility is to use a shadow register, in which the software writes to a primary register, a secondary shadow register is loaded from the primary register by a sync signal, and the hardware accesses the secondary register.
Errors detected by any of these options will raise a flag that can be polled by software or trigger a hardware interrupt to be serviced by software. Furthermore, each CSR may be serviced by none, one, or a combination of these options, depending on its FuSa classification.
Automating Functional Safety for CSRs
As previously discussed, existing tools can gather CSR definitions from IP-XACT models and generate corresponding RTL descriptions. The ideal solution would be for a tool that enables designers to associate FuSa-related requirements with each CSR, incorporating techniques such as byte-level parity, register duplication, register TMR, and other user-defined options. A corresponding RTL and documentation would then be generated (Fig. 4).
Such tools do exist, including Magillem Registers and CSRCompiler from Arteris. These solutions enable quick and scalable automation, drastically reducing the time to generate the hardware/software interface for SoCs, especially if the design requires FuSa-enhanced CSRs.
