Standardization of Chiplet Models for Heterogeneous Integration

The emergence of 2.5D packaging technology for heterogeneous die integration offers significant benefits to system architects.  Functional units may be implemented using discrete die – aka “chiplets” – which may be fabricated in different process nodes.  The power, performance, and cost for each unit may be optimized separately.

In particular, the potential to use chiplets fabricated in an older process node may save considerable cost over an equivalent system fabricated in a large SoC die using an advanced node, if only a subset of the overall functionality requires leading-edge performance, power dissipation, and/or circuit density.  The fabrication yield of the monolithic SoC will be adversely impacted by the larger die area due to full integration of the chiplet functionality.

Additionally, cost savings will accrue if chiplets are re-used in multiple products, amortizing the development expense across a larger shipped volume.  And, product time-to-market may be accelerated if existing specialty chiplets are used, rather than incur the time (and NRE) to design, fabricate, and qualify a new circuit block in a test shuttle for an advanced process node.

The disadvantages to a 2.5D heterogeneous package design relative to a monolithic implementation are:

• • larger overall package area
  • higher power dissipation from chiplet-to-chiplet data interface switching, due to the larger inter-die signal loading
  • design and NRE cost to develop the interposer: the internal die-to-die signals, the through-interposer vias from the die to package pins, and the power delivery to the die
  • (potential) difficulty in partitioning the system design to manage the number of interconnects to be routed on the interposer, with a coarser routing pitch

Parenthetically, a number of interposer technologies for 2.5D package design are available, with different relative tradeoffs in the list above: (full area) silicon interposer;  (full area) organic-based interposer; and, (reduced area) embedded bridges spanning die-to-die edges.

Also, note that chiplets are not intended to be packaged individually.  The I/O circuitry incorporated on the chiplet for intra-package connections is intended for the low loading of very short reach signals.  And, the chiplet I/Os for internal signals may have unique specifications for exposure to ESD and overshoot/undershoot events.

Chiplets incorporated into a 2.5D package design share many characteristics with “hard IP” offerings for direct SoC integration.  Perhaps the best example of the similarities is the availability of hard IP for industry-standard interfaces, both parallel and high-speed SerDes lanes.  The opportunities for chiplets to provide these package-level interfaces are great, as opposed to hard IP integration in a large SoC.

The SoC IP market relies on the delivery of models to compile into EDA flows.  Industry (and de facto) standards have emerged to enable hard IP integration from external vendors.  The nascent chiplet market leaders have recognized the importance of having a clear definition of the design enablement model set required for a 2.5D package integration.

The Chiplet Design Exchange (CDX) is a group representing chiplet providers, EDA vendors, and end customers developing system-in-package (SiP) designs.  They are working to establish standards and guidelines for the release of chiplet models.  A recent whitepaper titles “Proposed standardization of chiplet models for heterogeneous integration”, authored by Anthony Mastroianni and Joseph Reynick from Siemens EDA with other CDX members, provides a blueprint for chiplet model development.

(The CDX working group is part of the larger “Open Domain-Specific Architecture” (ODSA) initiative.  Other working groups in the ODSA are focused on standards for the physical design and electrical protocols for die-to-die interfaces on an SiP – e.g., the large number of parallel interface signals between a high-bandwidth memory (HBM) stack chiplet and the rest of the SiP die.)

CDX Model Standards

The figures below capture the chiplet data model format for each design methodology area.  In many cases, there will be similarities to the models developed for hard IP, as alluded to above.  Note that there are additional categories unique to chiplet IP.  Specifically, mechanical models for chiplets (with materials properties) are needed for assembly evaluation and structural reliability analysis.

• • Behavioral models

The end-customer will need to collaborate with the chiplet provider to decide whether a full behavioral model or an abstracted bus functional model (BFM) will be part of system simulation.  The chiplet provider may include a testbench to assist with verification. If the chiplet has mixed-signal circuits, an AMS model may be provided.

• • Power models for dissipation analysis and functional verification

Similarly to hard IP, functional power states and power domain information about the chiplet would be provided with a separate UPF file.  The SiP physical power distribution network would be verified against the chiplet UPF description.

• • Signal integrity and power integrity analysis

IBIS models for chiplet I/Os would be used for signal integrity analysis.  IBIS-AMI models and/or S-parameter channel models would be provided for chiplets incorporating off-package SerDes lanes.

• • Physical, mechanical, and electrical properties

Of particular note is the CDX recommendation to adopt the JEDEC JEP30-P101 model format (link).   This schema is a “container” for property and value information for the chiplet and its pins.  Electrical properties would include chiplet operating range limits and individual pin characteristics (e.g., receiver voltage levels, driver I-V values, loading, ESD rating).  Mechanical properties would be needed for both assembly (e.g., chiplet x, y, and z data, pin info, microbump composition/profile) and reliability analysis (e.g., materials data, such as coefficient of thermal expansion, fracture strength).

• • Thermal

Package-level thermal analysis is critical in 2.5D SiP implementations.  The SiP end customer and chiplet provider will need to review the model granularity needed for thermal analysis – i.e., a uniform dissipation map across the chiplet or a more detailed block/grid-level thermal model.

• • Test

As is evident from the list of model deliverables in the figure above, SiP test with chiplets requires some challenging methodology decisions.

Chiplets would be delivered to package assembly as “known good die” (KGD).  Typically, it would suffice post-assembly to test the I/O connectivity on the interposer between die, using a (reduced) boundary scan-based pattern set.  As many of the die-to-die connections will be internal to the package, the SiP test architecture needs to provide an external access method to the individual chiplet boundary scan I/Os.

However, if there is a risk that a chiplet itself may be damaged during the assembly process, a more extensive test of the internal functionality of each chiplet would be required, necessitating delivery of more extensive chiplet test models and/or pattern data (adding considerably to the post-assembly tester time).  This could become quite an involved procedure, if the chiplet contains unique analog circuitry that needs to be re-tested at the package level.

Test models for chiplets become even more intricate if there is the SiP developer needs to pursue post-assembly failure analysis, on defects of a class beyond interposer interconnect validation.

The whitepaper goes into further detail about the chiplet model requirements if an interface design includes redundant lanes to replace/repair interposer interconnect defects found during post-assembly test.

• • Documentation

And, last but certainly not least, the whitepaper stresses the importance for the chiplet provider to release extensive “datasheet” information, ranging from recommendations for design and analysis methodology flows to detailed functional and physical information.  Again, the JEDEC JEP30 Part Model file format is recommended.

And, to be sure, any chiplet firmware code to be integrated by the end-customer needs to be thoroughly documented.

Futures

The whitepaper briefly discusses some of the future areas of modeling focus to be pursued by the CDX working group:

• • a definition for hardware and software security features, providing cryptographic-based validation of chiplet hardware to the system and chiplet-level verification of firmware releases
  • chiplet SerDes receiver eye diagram opening definition
  • chiplet modeling standards for vertically-stacked die in 3D package technologies

If you are involved in a 2.5D SiP project incorporating chiplets, this whitepaper from the CDX working group is a must read (link).

Also Read:

Using EM/IR Analysis for Efinix FPGAs

Methods for Current Density and Point-to-point Resistance Calculations

3D IC Update from User2User