![\"Figure](\"https:\/\/www.techdesignforums.com\/practicefiles\/2022\/10\/fig_1-2.5D-IC-drawing.png\")
<\/a>Figure 1. Heterogenous integration using 2.5D-IC (Siemens EDA)<\/p><\/div>\n
<\/a>Figure 2: True 3D-IC achieved by stacking wafers (Siemens EDA)<\/p><\/div>\n
In terms of EDA physical verification, designers need to confirm that the 3D-IC assembly is connected as expected, compared to the \u2018golden\u2019 design intent (captured as a system-level netlist). For the system-level netlist to be considered golden, the designer must be confident enough that it is the absolute reference of system connectivity.<\/p>\n
Transitioning to advanced system-level connectivity flows<\/h3>\n
In the case of 2.5D-IC systems, designers usually build silicon interposers using the same approaches used to build digital SoCs (using traditional, automatic place-and-route EDA tools), which means that the interposer connectivity is usually captured in a Verilog netlist format. As far as the designer can tell, this is the best system-level golden connectivity reference that he or she can generate using the traditional IC flows.<\/p>\n
But now, when graduating to 3D-IC system-level design tools and approaches, how can designers know they built the connectivity correctly?<\/p>\n
They will need to employ equivalence checking, with which they can compare the output of the traditional connectivity capture approach (usually a single domain: CDL, Verilog, or CSV) versus the output of a new, system-level connectivity capture approach (multi-domain). In other words, you need a quick, automated, and flexible netlist- versus-netlist comparison. Once the comparison results are clean, the designer will have more confidence in using the newly introduced connectivity capture flow.<\/p>\n
To help designers make this transition, Siemens has developed an automated approach\u2014using Siemens\u2019s Xpedition Substrate Integrator (xS)\u2014in which the designer can compare with his or her traditional flow netlist (SPICE, Verilog, or CSV) versus the system-level assembly netlist generated from xSI (CSV). This automated netlist-versus-netlist comparison is performed using Calibre tools accessed through an add-on feature integrated with xSI. Figure 3 shows the interactive GUI (wizard) that is used for the netlist-versus-netlist comparison.<\/p>\n
<\/a>Figure 3. The xSI wizard for its netlist-versus-netlist feature (Siemens EDA)<\/p><\/div>\n
Users can see whether the xSI system-level connectivity matches their traditional flow connectivity by generating the netlist-versus-netlist runset out of xSI, executing the comparison, and viewing the generated comparison report. If the report is clean, xSI correctly built the system connectivity as intended.<\/p>\n
System connectivity exceptions in 3D-IC multi-substrate assemblies<\/h3>\n
In some cases, a system source netlist is not enough for LVS verification of 3D-IC multiple substrate systems. In these cases, designers need to \u2018short\u2019 some signals together in the substrate layout. These shorts create a mismatch between the layout and the source netlist. Although these differences are reported in the LVS comparison results, they are intended by the user (usually temporarily).<\/p>\n
For the user to differentiate between the intended LVS issues and the real LVS issues, the intended LVS issues need to be somehow waived from the LVS results. One obvious solution is to modify the system source netlist to match the physical layout implementation. However, this is not desirable since the system source netlist needs to be golden and frozen across different physical implementations and iterations.<\/p>\n
Thus, designers need a quick, automated, and flexible way to handle connectivity exceptions in a 3D-IC design that enables them to waive intended shorts in the LVS comparison results. Siemens\u2019s Calibre 3DSTACK supports a \u2018net mapping\u2019 feature that can be utilized to account for the intended shorts. The shorts list can be considered a net map file, and it can be automatically included in the Calibre runset using a wizard that is integrated with xSI.<\/p>\n
Another challenge can arise when an assembly includes both an interposer and a package substrate for the same connection; the IC design team (building the silicon interposer) may use a different net naming methodology than the packaging team (building the organic substrate). The system-level designer then ends up in a situation where the same port name can be assigned to two different net names. For example, the same die-to-BGA connection can be assigned to two different net names: C4_PKG (packaging team naming) and C4_INT (interposer team naming).<\/p>\n
xSI can recognize a connection across substrates, even when two different net names are assigned to the connection. This is achieved by applying the xSI interface part feature.<\/p>\n
The interface part function is used to connect two different substrates in xSI (called floorplans or designs). An example of an interface part is highlighted (on the left) in Figure 4.<\/p>\n