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

Getting an early jump on architecture exploration of multi-die systems can yield valuable benefits, such as preventing costly design respins. However, the exploration process has traditionally been rather manual, with most designers relying on static spreadsheets and ad-hoc in-house tools. As a result, it’s challenging to meet key performance indicators (KPIs) or even project schedules.

Now, there’s a new dynamic, early system architecture exploration solution designed to accelerate architecture realization for multi-die systems: Synopsys Platform Architect for Multi-Die Systems.

The solution is built on the industry leading Synopsys Platform Architect?, which provides SystemC? transaction-level modeling-based tools for early analysis and optimization of SoC architectures for performance and power. This new tool, validated by designers of AI and automotive multi-die systems, accounts for the complex interdependencies of multi-die systems. Read on to learn more about how this dynamic, model-based performance and power analysis and simulation technology can help mitigate the risks of system architecture decisions while enhancing turnaround times for multi-die system designs.?

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.