Chip Scale Review - January February 2020

38 Chip Scale Review January • February • 2020 [ChipScaleReview.com] Process ownership Because HDAP is still an emerging technology, the responsibility for HDAP verification can vary from team to team and company to company. For example, some design companies see 2.5D design and verification as a “more SoC, less packaging” activity, and assign design and verification tasks to SoC and/or computer- aided design (CAD) teams experienced in SoC verification requirements and formats, but with limited packaging experience. FOWLP design and verification, on the other hand, is viewed as a “less SoC, more packaging” activity, so responsibility often goes to a packaging team that is less familiar with SoC verification requirements and formats. The bottom line is that foundries, OSATS, and EDA companies cannot impose a single, uniform set of processes and conditions when supporting HDAP design companies using diverse methodologies and requirements. Flexibility is essential to success. Data To run full-package LVS verification, all the data for all the HDAP components must be available. For example, in a FOWLP design, designers require: 1) Die1 through Die n layout design databases; 2) FOWLP design database; and 3) FOWLP system source netlist (in some form). So what happens if the FOWLP design dat aba se (owned by t he packag i ng team) is ready, while the individual d ie d a t aba s e s (owne d by t he SoC teams) are still being developed? If the FOWLP designer has to wait until all the dies are built and verified to run the FOWLP LVS and find out that the FOWLP design database is full of shorts, i g h - d e n s i t y a d v a n c e d p a c k a g i n g ( H D A P ) c o m b i n e s m u l t i p l e integrated circuit (IC) dies in a single package. This heterogeneous integration provides an improved form factor and enhanced functionality when compared to other packaging technologies, but presents some tricky verif ication challenges, because each of those die may be built using a different technology node. Like any electronic product, HDAP designs require extensive verification to ensure they will perform as intended, and can be reliably manufactured in sufficient quantities to meet market demand. Unlike traditional ICs, system-on-chips (SoCs), or printed circuit boards (PCBs), however, automating HDAP verification requires combining elements of both IC and package verification. This has proved to be somewhat challenging for the electronic design automation (EDA) industry, though it has invested a significant amount of time and research into categorizing the issues and developing solutions, and progress is being made. To begin with, the general concept of qualified assembly design kits (ADKs) that are similar to foundry-qualified process design kits (PDKs) for ICs [1- 3] has become at least a limited reality [4]. Assembly-level layout vs. schematic (LVS) verification for HDAPs [5-6] now has at least one EDA solution [7]. The value of post-layout simulation for analog and post-layout static timing analysis (STA) for digital flows for HDAPs is now well-understood [8], as is the need for an automated approach that generates HDAP system-level connectivity while accounting for die, package, and die/ package interface parasitics [9]. While the maturity and scope of the processes needed to make HDAPs a viable market option may still be in development, this seems a good time to assess where we are. To get an idea of how far we’ve come, and where we need to go, let’s take a closer look at one particular process—package LVS ver if icat ion—usi ng the two HDAP designs that are cu r rently the most popular: 2.5D (interposer) and fan-out wafer-level packaging (FOWLP), shown in Figure 1 . HDAP LVS verification We all know that an SoC can’t be submitted to manufacturing unless the geometries that are present in the physical layout implement t he connect iv it y and circuit performance created in the schematic/design intent. LVS verification is a mature, well-established, highly- automated flow in the SoC design world. To support the automated LVS process, LVS tools require a consistent set of data: 1) Layout database (GDSII, OASIS, or LEF/DEF); 2) Source netlist (SPICE or Verilog); and 3) LVS rule deck (format depends on EDA tool used). The layout database and source netlist are created by the design company for each SoC design, while the LVS rules deck is typically created and provided by the foundry, and is independent of any single SoC. Design companies, foundries, and EDA suppliers all understand and agree that SoC LVS verification can’t happen without some combination of these three inputs. When we start to look at HDAP LVS verification, we immediately see major dif ferences. The most obvious and most critical is that design companies, foundries, outsourced assembly and test suppliers (OSATS), and EDA suppliers are neither in alignment, nor agreement, on the set of inputs required for an HDAP LVS flow. This disconnect exists for three reasons: ownership, data availability, and design dependence. H Where are we with HDAP LVS verification? By Tarek Ramadan [Mentor, a Siemens Business] Figure 1: 2.5D interposer-based and FOWLP designs are the HDAP technologies currently used most frequently.

RkJQdWJsaXNoZXIy ODIzODM4