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.