Avoiding Multi-Die System Re-spins with New Early Architecture Exploration Technology

Key Considerations in Multi-Die System Architecture Design

For monolithic SoCs, the architecture design exploration phase carries an array of considerations: hardware/software partitioning, IP selection configuration and connectivity, macro architecture, interconnect and memory dimensioning, and power analysis, just to name a few. These are among the parameters that have a first-order effect on the system’s performance and power consumption, so they need to be analyzed early to ensure that you can meet your design’s performance goals and power budgets.

Multi-die systems, which integrate heterogenous dies in a single package, come with additional considerations, such as:

• What kinds of dies, or chiplets, will be assembled to build a system that meets your architecture requirements?
• Where do you draw the cutlines between the dies?
• What protocol(s) will you use for die-to-die connectivity?
• What is the impact of die-to-die boundaries on power and performance?
• How will you configure memory utilization and coherency, since potentially many dies will be accessing and sharing a common area of memory?
• Will you reuse any existing dies as part of the overall system?

These decisions could potentially introduce bandwidth bottlenecks with different performance, power, and latency impacts. Decisions around packaging and configuration of the die-to-die interconnects also must be determined at this phase.

Given these considerations, there are three main tasks to achieve during the early architecture design phase of multi-die systems:

• Partition the system functionality into dies and into the components inside the dies
• Optimize the multi-die system, particularly the communication across die boundaries
• Accelerate overall architecture realization, enabling downstream implementation tasks by silicon, package, and software teams

Static spreadsheets and in-house tools can be used to track power, performance, and thermal KPIs. This is often how such KPIs are managed for monolithic SoCs, with different teams sharing their spreadsheets as the design moves through each phase. However, a spreadsheet-based approach, which can be error-prone, does not lend itself to enabling multi-die system design teams to meet their KPIs. If the multi-die system, or any of its underlying components, doesn’t align with its power or performance requirements, then the resulting architecture design delay could trigger late redesigns or a costly design respin.

Identifying Performance and Power Bottlenecks Early On

Platform Architect for Multi-Die Systems enables early, model-based architecture exploration—6 to 12 months before register-transfer level (RTL) availability—allowing you to identify performance, power, and thermal bottlenecks early on. The solution provides fast capture of software workloads and efficient design space sweeping and sensitivity analysis of KPIs and tradeoffs. It removes risk from multi-die system architecture designs, while also reducing the cost of respins. The technology also enables:

• Optimal partitioning of the multi-die system into dies
• Intuitive distribution of functions and memory to limit chip-to-chip traffic
• Efficient dynamic analysis of latency and performance based on die choices
• Faster die-to-die connectivity decisions
• Validation of the impact of integration of dies as well as disaggregation
• Higher abstraction power analysis

As a model-based solution, Platform Architect for Multi-Die Systems captures an executable specification of the multi-die system. This is constructed from models of the application workload and the hardware architecture. The workload model represents the processing and communication requirements of the application. The hardware architecture model provides the available resources to execute the workload, including all the dies and how they are connected with each other and with the shared memory subsystem. The mapping of the workload model onto the hardware model defines the partitioning of the application tasks into the dies. Similarly, the mapping of data structures into the memory location determines the resulting traffic streams across the system.

The large library of models that comes with Platform Architect for Multi-Die Systems supports creation of the system model. Once available, the system model can be used for rapid design space exploration and fast analysis of the impact of design and configuration parameters on performance and power KPIs.

Platform Architect for Multi-Die Systems is part of the comprehensive Synopsys Multi-Die System Solution for accelerated heterogeneous integration. The solution includes EDA and IP products for early architecture exploration, rapid software development and system validation, efficient die/package co-design, robust and secure die-to-die connectivity, and enhanced manufacturing and reliability. Data from Platform Architect for Multi-Die Systems can be fed  into Synopsys 3DIC Compiler, a unified exploration to signoff platform that examines physical architecture considerations, and vice versa to ensure that physical aspects are accounted for during the architecture specification phase.