Developing the Blueprint for Multi-Die Systems with Virtual Prototyping Tools

If you were building a house, you’d want a solid blueprint outlining a carefully planned layout of where every room, hallway, window, and door should be. Making changes later, while the home is under construction, would be costly and time consuming. Similar considerations apply to chip design, including multi-die systems, where the foundation is built through meticulous architecture planning.

For complex multi-die systems, the stakes are even higher to get the architecture as close to right as possible from the very beginning.

Multi-die systems have emerged in response to the scale and systemic complexities that are threatening the efficacy of Moore’s law. Through heterogeneous integration of dies in a single package, multi-die systems enable accelerated scaling of system functionality, reduced risk and time to market, lower system power, and faster creation of new product variants. They’re becoming the architecture of choice for compute-intensive applications such as high-performance computing, automotive, and mobile.

Moving into the mainstream of the semiconductor world, multi-die systems require a new approach at the architecture planning phase. Even early in the architecture specification process—while drawing the blueprint of the new house—chip designers can’t ignore physical effects such as layout, power, temperature, or even IR-drop. In this blog post, we’ll discuss architecture planning considerations and challenges, and provide insights on methodologies and technologies to achieve multi-die system success. You can also gain additional insights by watching our on-demand, six-part webinar series, “Requirements for Multi-Die System Success.” The series covers multi-die system trends and challenges, early architecture design, co-design and system analysis, die-to-die connectivity, verification, and system health.

How Virtual Prototyping Tools Uncover Architecture Insights

One of the biggest challenges at the architecture planning phase is, so many important decisions must be made at the start of a project, when only a minimal amount of design data is available. It is also quite risky to rely solely on static spreadsheet analysis, given that many key performance indicators (KPIs), such as performance, power, and thermal, depend on dynamic effects of the application workload running on limited processing and communication resources.

How can design teams overcome this particularly vexing challenge?

Virtual prototyping of the multi-die system architecture presents an answer. Like an early electronics digital twin, a virtual prototype can be used to analyze the impact of architecture design decisions. The process begins with a definition of the workload and architecture: Which applications need to be executed? What are the non-functional requirements, like end-to-end latency and throughput? Which hardware components should execute this workload, and what are their power and performance properties?

For a realistic estimation of what the answers to these questions mean for the multi-die system, these functional and non-functional requirements need to be translated into the physical hardware properties of the system. The properties include the target process technology for the dies, their area, and the aspect ratios of the different components.

From this initial assessment, the design team can progress to a virtual assembly of the multi-die system. During this step, there are some important questions to answer: How are the components partitioned into dies?​ How are the workload and data structures mapped onto these components? The answers together determine the traffic across the die boundaries. ​

There are, of course, many trade-offs to consider. For example, larger on-chip memories and caches are more expensive in terms of die area, but can help to reduce die-to-die traffic. ​By building an executable model of how the workload is running on the multi-die system architecture resources, the chip architects can collect a lot of data on how the actual system will behave. There are many key considerations here, including:

• What is the resulting utilization of resources?
• What are end-to-end latencies to execute a certain task?
• How much data needs to be transferred between the different chiplets?

Based on all the analysis, the team can modify all the aspects of the system architecture, quickly arriving at a feasible specification that meets the product requirements in an optimized way.

Insights into Root Causes

There are, fortunately, technologies from the monolithic SoC world that can be applied to multi-die systems. SoC architecture analysis and optimization technology, for instance, can be used for system analysis and optimization of multi-die systems. These technologies can quickly model the expected performance early on to help engineers arrive at a feasible architecture concept. Such early architecture analysis can yield data to be used in downstream implementation tasks by silicon, package, and software teams.

Of course, ​power, temperature, IR-drop effects, and such must be analyzed early and systematically during the architecture definition phase. The classic SoC design flow, where design phases are decoupled and can be considered in isolation, simply doesn’t work in the multi-die arena. A multi-die architecture must be designed and verified from a system-wide lens through functional and physical architecture co-optimization. By capturing the physical architecture early during the architectural specification phase, designers can validate their assumptions in the functional architecture. If the initial proposal isn’t feasible for any reason, the results and guidance from the physical architecture analysis can be fed back to the functional architects to determine a better specification.

Synopsys Platform Architect is an example of such an analytical solution, providing a virtual prototyping environment for early architecture analysis. The solution allows design teams to capture the hardware resources of their multi-die system, including key processing elements, the communication fabric, and the memory hierarchy. The solution also captures the die-to-die interfaces, which represent the effect of the cutline between the chiplets on latency and bandwidth.

Processing and communication requirements of the end application are captured by Platform Architect as workload models. Mapping the workload models on the architecture model creates an executable specification of the multi-die system architecture that enables the efficient analysis KPIs. Through the mapping process, designers can optimize their system for KPIs such as power and cost.

The system performance model representing the executable specification is highly configurable and simulates 1000x to 10,000x faster than RTL. The turnaround time for changing the partitioning of the system or an IP configuration is short, and many simulations can run in parallel on normal compute hosts. The solution provides a variety of analytical views that helps teams investigate root causes of performance and power issues.

Platform Architect is part of the comprehensive Synopsys Multi-Die Solution, including EDA and IP products, designed for fast heterogenous integration. With this solution, teams can architect, design, verify, and test their multi-die systems holistically, accounting for interdependencies that can impact PPA.