Understanding the Difference Between a Monolithic SoC and a Chiplet

I am often asked, "What is the difference between a traditional SoC die and a chiplet die?" At a high level, the answer is that a traditional SoC is designed as a standalone single-die packaged chip, while a chiplet is part of a larger system of multiple dies packaged together. This simple answer inevitably leads to a more involved answer. To facilitate a system of chiplets, each chiplet must understand how to manage itself within the system. One common misconception is that adding a die-to-die interface to a design equals a "chiplet." While that is part of the chiplet function, it is nowhere near solving all the associated challenges.

To operate as a chiplet, a design must first address a number of considerations. These include how it boots (secure or insecure?), how it's debugged (standalone or across chiplets?), how common resources (such as memory) are managed, how clocking and resets are distributed, how it communicates with other chiplets, and, for designs where safety is crucial, how faults are captured. Finally, all these capabilities should be designed to a common specification, such as the new Foundational Chiplet System Architecture (FCSA), being developed as part of the Open Chiplet Economy (OCE), to ensure multi-chiplet interoperability. The FCSA specification defines common interfaces and protocols between different types of chiplets.

Figure 1. Common Chiplet Interfaces

The Cadence Chiplet Framework

The good news for chiplet designers is that Cadence has been pondering the problems of multi-die chiplet integration and interoperability, and the need for specific chiplet management capabilities, for a couple of years now, and has developed a solution. The Cadence Chiplet Framework is a comprehensive hardware and software solution designed to make this transition seamless. The Cadence Chiplet Framework accelerates chiplet development and ensures cross-chiplet interoperability by standardizing common interfaces.

The Cadence Chiplet Framework provides a pre-verified and integrated set of subsystems that manage everything from boot-up and security to die-to-die communication. It acts as the foundational blueprint for creating complex multi-chiplet systems. Let's explore the key subsystems that compose this powerful framework and understand how each component contributes to a successful chiplet-based design.

Figure 2. Cadence Chiplet Framework

CSCP Subsystem

The system and security control processor (CSCP) subsystem is at the heart of the Cadence Chiplet Framework. This critical component acts as the central control system for each chiplet, and every chiplet in the system should include, at a minimum, one CSCP. It is responsible for orchestrating the boot process, managing system-level functions, and ensuring robust security within and across chiplets.

Figure 3. CSCP subsystem

The CSCP includes an efficient and lower-power control processor, which executes dedicated firmware. One of its primary roles is to manage the chiplet boot flow, ensuring that each die powers up correctly and in the proper sequence. It initializes essential components like interconnects, memory controllers, and the UCIe^™ interface, setting the stage for communication between chiplets. For security, the CSCP interfaces with a built-in root of trust (RoT), the Cadence Securyzr solution, which handles secure boot, attestation, and lifecycle management, establishing a secure foundation for the system's operation.

Figure 4. Cadence Securyzr, the secure root of trust solution

Key functions of the CSCP firmware include:

• System-level control: Distributes clock and power control across all chiplets.
• Communication: Establishes communication pathways between chiplets and supports the system control and management interface (SCMI) for interaction with other components.
• Security and recovery: Provides mechanisms for secure execution, secure firmware upgrades, and device recovery, crucial for maintaining device integrity in the field.

Figure 5. CSCP firmware

DBG Subsystem

Complex systems require robust debugging capabilities, and multi-chiplet designs are no exception. The debug (DBG) subsystem is housed in an always-on power domain, providing standalone debugging capabilities that are independent of the main system's operational state.

This is particularly important during development and when diagnosing issues in the field. The DBG facilitates debug communication between chiplets and allows an external debugger to be used even when the primary die-to-die interface (UCIe Mainband) is not active. It also supports a debug cross-trigger interface, enabling engineers to synchronize debug events across different chiplets for more effective system-wide analysis.

Figure 6. DBG subsystem

CON Subsystem

While the CSCP manages the overall system, local control within each subsystem is handled by dedicated control (CON) subsystems. These configurable blocks are implemented throughout the design, providing granular control over local functions.

Each CON includes a local controller for power, clock, and resets. It communicates with the central SCP to ensure its operations are synchronized with the rest of the system. Additionally, the CON features generic control and status registers (CSRs) that are used to configure IP interfaces and manage miscellaneous functions. For advanced designs, a CON can also integrate optional components like local phase-locked loops (PLLs) for clock generation, on-die sensors for monitoring, and a fault management unit (FMU) for detecting local errors.

Figure 7. CON Subsystem

NoC Subsystem

Modern designs require efficiently moving vast amounts of data between different functional blocks. The network-on-chip (NoC) subsystem serves as the data highway both within and between subsystems. It provides a high-performance data network that connects various components, such as processors, memory, and I/Os.

The framework is flexible, offering the choice of non-coherent and coherent networks, including a mix of each, catering to a wide range of application needs. To manage memory access, the NoC subsystem supports an optional I/O memory management unit (IO-MMU) to translate virtual addresses to physical addresses, along with an address translation cache to speed up this process.

Die-to-Die Interface (UCIe) Subsystem

The core of a chiplet-based design lies in its ability to connect multiple dies so they function as a single, cohesive system. The die-to-die interface subsystem makes this possible using the UCIe IP from Cadence. This configurable subsystem includes the necessary controllers and PHYs to establish a reliable, high-bandwidth link between chiplets.

The die-to-die subsystem supports a variety of industry standards, including the AMBA CHI-C2C, ACE-lite + DVM C2C, and AXI C2C protocols, ensuring interoperability. A critical function of this subsystem is managing interrupts across chiplets. It includes an interrupt encoder and decoder that can translate MSI messages, allowing a core on one chiplet to efficiently signal an interrupt to a core on another.

Figure 8. Cadence UCIe subsystem

Optional CSMP Subsystem

For applications that require functional safety, such as automotive or industrial systems, the framework offers an optional safety management processor (CSMP) subsystem. This processor with a firmware-driven subsystem is dedicated to monitoring the health of the entire system and managing fault collection and action-taking.

Figure 9. SMP subsystem

The CSMP subsystem works in conjunction with the FMUs distributed across the chip. Its firmware performs system-level distributed fault monitoring and can aggregate error reports from all chiplets.

Key responsibilities of the CSMP firmware include:

• Power-On Self-Test (POST): Establishes an acceptable initial safety state upon boot.
• Error handling: Determines the system's safety state based on events from all FMUs and coordinates system-wide error handling based on fault type and severity.
• Recovery and notification: Can trigger recovery actions, communicate with the SCP to reset IP, or notify high-level software of faults.
• Logging: Captures all faults in system logs for diagnostics and compliance.

Benefits of the Cadence Chiplet Framework

By providing a pre-integrated and verified set of hardware and software subsystems, the Cadence Chiplet Framework offers significant advantages for companies developing next-generation chiplet-based systems.

• Modularity and flexibility: The framework allows designers to focus on their unique value-add, knowing that the foundational chiplet control, security, and communication infrastructure is already in place.
• Reduced time to market: By starting with a proven chiplet management foundation, design teams can dramatically shorten development cycles and reduce verification effort.
• Enhanced efficiency: The integrated chiplet framework approach addresses key challenges in multi-chiplet design, such as system-level power management, security, and debug, resulting in a more efficient and robust final product.
• Interoperability: Based on mature, open, chiplet system architecture specifications, the framework ensures interoperability across chiplet designs.

The Cadence Chiplet Framework provides the essential building blocks for navigating the complexities of multi-die chiplet integration. It empowers engineers to harness the full potential of chiplet-based design, paving the way for a new era of semiconductor innovation.

Resources

• Download our eBook, Cadence Chiplet Solutions: Helping You Realize Your Chiplet Ambitions
• Watch our webinar: Cadence Chiplet Solutions: Helping You Realize Your Chiplet Ambitions
• Read our news release: Cadence Launches Partner Ecosystem to Accelerate Chiplet Time to Market
• Blog: From Spec to Silicon: Successful Physical AI System Chiplet Bring-Up

Learn more about the Cadence Chiplet solutions.