{"id":5914,"date":"2013-10-11T08:42:47","date_gmt":"2013-10-11T08:42:47","guid":{"rendered":"https:\/\/www.techdesignforums.com\/practice\/?p=5914"},"modified":"2014-06-27T16:17:46","modified_gmt":"2014-06-27T16:17:46","slug":"power-grid-analysis-interposer-3dic","status":"publish","type":"post","link":"https:\/\/www.techdesignforums.com\/practice\/technique\/power-grid-analysis-interposer-3dic\/","title":{"rendered":"Power grid analysis for 2.5D and 3D IC systems"},"content":{"rendered":"<p>Interposer-based 2.5D and stacked 3D IC integration are high profile \u2018more than Moore\u2019 strategies now enabling the incorporation of additional capabilities within ever-smaller form factors. A major design challenge for both is power grid analysis (PGA). Existing software is well-defined for use on planar designs, but needs to be extended and enhanced for 2.5D and 3D to fulfill new requirements and use models. Let\u2019s look at the key changes that will be necessary.<\/p>\n<h2>System-centric power grid analysis<\/h2>\n<p>Power grid analysis has been an IC-centric process for mainstream 2D configurations. It must become system-centric for 2.5D and 3D systems.<\/p>\n<p>For example, as Figure 1 shows, several die in any 2.5D or 3D IC system will typically share the same network supplies. The incoming generation of PGA solutions must concurrently analyze these die, as the voltage drop for one could be directly linked to another. Also, PGA solutions must support various 2.5D\/3D die configurations &#8211; addressing, for example, placement, orientation, and stacking order &#8211; as well as models for inter-die interconnects.<\/p>\n<div class=\"article_figure\"><a class=\"figure\" title=\"Figure 1 : Shared power supplies between dies A, B, and C\" href=\"https:\/\/www.techdesignforums.com\/practicefiles\/2013\/10\/tdf-ment-3dpowergrid-fig1lg.jpg\"><img decoding=\"async\" src=\"https:\/\/www.techdesignforums.com\/practicefiles\/2013\/10\/tdf-ment-3dpowergrid-fig1med.jpg\" alt=\"Shared power supplies between dies A, B, and C\" \/><\/a><\/div><div class=\"article_figure\"><p class=\"figure_wrapper\"><span class=\"figure_title\">Figure 1 <\/span>Shared power supplies between dies A, B, and C<\/p><\/div>\n<h3>Heterogeneous nodes<\/h3>\n<p>The presence of multiple die also highlights the need for 2.5D\/3D PGA solutions to support heterogeneous technology nodes. Each die in a system may have be designed on a different process, as dictated by node maturity for the applications it contains. So, a system could contain die designed at 40nm and 28nm, and an interposer designed at 65nm.<\/p>\n<p>Enabling incremental technology file definition and calibration is also a plus. End users then need only calibrate the new part of a stack definition related to the 2.5D\/3D integration, rather than re-calibrate the IC portion of a stack definition.<\/p>\n<h3>2.5D and 3D integration \u2018objects\u2019<\/h3>\n<p>Then there is the question of how everything within a system is mounted and connected. Figure 2 shows how 2.5D\/3D flows must take account of the specific \u2018objects\u2019 required for vertical integration. These can include backside bumps and backside metal layers.<\/p>\n<p>The latter is a good illustration of the type of challenge these present for PGA software: The backside metal layers in a 3D structure are routed at 45 degree angles instead of the usual 90 degrees used for front-side metal layers.<\/p>\n<p>For 3D, there is then the further need to support the use of through-silicon vias (TSVs) between front and backside metals. Meanwhile for 2.5D systems, PGA tools must be able to handle passive interposers that contain only metal (no devices underneath).<\/p>\n<div class=\"article_figure\"><a class=\"figure\" title=\"Figure 2 : 2.5D\/3D-specific 'objects'\" href=\"https:\/\/www.techdesignforums.com\/practicefiles\/2013\/10\/tdf-ment-3dpowergrid-fig2lg.jpg\"><img decoding=\"async\" src=\"https:\/\/www.techdesignforums.com\/practicefiles\/2013\/10\/tdf-ment-3dpowergrid-fig2med.jpg\" alt=\"2.5D\/3D-specific 'objects'\" \/><\/a><\/div><div class=\"article_figure\"><p class=\"figure_wrapper\"><span class=\"figure_title\">Figure 2 <\/span>2.5D\/3D-specific 'objects'<\/p><\/div>\n<h2>Use models<\/h2>\n<p>Due to the typical size of 2.5D and 3D systems, and the additional complexity introduced by the possible need to integrate third-party die, PGA solutions must be capable of running in three different modes.<\/p>\n<h3>1. Power model-based power grid analysis<\/h3>\n<p>Power model-based PGA is already implemented in existing solutions. Each of the die is represented by its compact power model, and the PGA software analyzes the full 2.5D\/3D IC system using those models and their connections. This mode can be run fairly quickly to provide a high-level PGA of the system, though the only issues that it detects are related to inter-die connections.<\/p>\n<p>Only one additional degree of complexity must be considered when running a power model-based PGA on a system incorporating multiple technology nodes. Power models are generated for technology node-specific corners, so PGA solutions here must be able to handle multi-die systems represented by compact power models generated for different corners. For instance, one 90nm die model is generated for a 1.2V corner, while a 65nm die model is generated for a 1.0V corner.<\/p>\n<h3>2. Full 2.5D\/3D power grid analysis<\/h3>\n<p>This mode is not covered by existing PGA solutions and is also computationally expensive.<\/p>\n<p>End users want to analyze the voltage drop on specific multi-die nets similar to those shown in Figure 1. However, to provide such visibility, the software\u2019s capacity and turnaround time must be several orders of magnitude greater than seen in PGA solutions already on the market.<\/p>\n<h3>3. Hybrid power grid analysis<\/h3>\n<p>The hybrid solution is induced by 2.5D\/3D third-party die integration. It can handle a mix of compact power models and dies (Figure 3). In a given system, a third-party die is only represented by its compact model for integration into the system PGA.<\/p>\n<div class=\"article_figure\"><a class=\"figure\" title=\"Figure 3 : 2.5D or 3D PGA using a third-party die power model\" href=\"https:\/\/www.techdesignforums.com\/practicefiles\/2013\/10\/tdf-ment-3dpowergrid-fig3lg.jpg\"><img decoding=\"async\" src=\"https:\/\/www.techdesignforums.com\/practicefiles\/2013\/10\/tdf-ment-3dpowergrid-fig3med.jpg\" alt=\"2.5D or 3D PGA using a third-party die power model\" \/><\/a><\/div><div class=\"article_figure\"><p class=\"figure_wrapper\"><span class=\"figure_title\">Figure 3 <\/span>2.5D or 3D PGA using a third-party die power model<\/p><\/div>\n<h2>Power grid analysis within the design flow<\/h2>\n<p>To detect power grid issues early and then efficiently diagnose and correct them, 2.5D\/3D PGA must be run at different stages within the design flow. Beyond signoff PGA, further analysis is required during implementation at the floor planning, post-CTS, and post-route stages. At each, the effect of the system on a given die must be taken into account to find power grid issues as early as possible.<\/p>\n<p>2.5D\/3D PGA systems should allow users to analyze all dies in the system easily. This can be achieved by offering multi-frame capability or die-to-die browsing in a given stack. Such capabilities allow the user to review, diagnose, and debug power grid issues efficiently. Die-to-die browsing should be fairly straightforward to implement, assuming that the solution can handle the typical data size without freezing. An efficient multi-frame capability will be more of a challenge, but such a feature will be particularly useful to users trying to debug a dynamic PGA run.<\/p>\n<h2>Power grid analysis output<\/h2>\n<p>Any 2.5D\/3D PGA solution must be able to generate a complete or a partial power model of the full system that can be used for packaging\/board power integrity analysis. This partial model generation is particularly important because of the likelihood of third-party integration.<\/p>\n<p>For instance, if a supplier is analyzing a die on an interposer that will be connected to another die by customers, the supplier will need to deliver both a power model for the first die and the parasitics netlist for the interposer. Customers need all this information to run analyses encapsulating the power model, the interposer parasitics, and their own die, to have a comprehensive PGA of the final system.<\/p>\n<h2>Conclusion<\/h2>\n<p>Power grid analysis for 2.5D\/3D ICs requires capabilities well beyond those in the simple power model-based analysis tools currently available. Power is one of the biggest challenges in 2.5D\/3D IC implementations and issues that arise here cannot be solved solely at the RTL level.<\/p>\n<p>To enable the semiconductor industry to fully embrace 3D integrations beyond just 2.5D, memory stack, and wide IO applications, Power grid analysis solutions must begin to address the requirements discussed here, especially if the goal is to have a true homogeneous 3D IC integration flow with multi-die, robust power grid floor planning capability.<\/p>\n<h2>About the author<\/h2>\n<p>Christen Decoin is Product Marketing Manager for New &amp; Emerging Markets for Calibre Design Solutions at Mentor Graphics, responsible for driving early-stage new market analysis, product definition, and product launch.<\/p>\n<p>Christen was previously responsible for Mentor\u2019s participation in the DeCADE Nano2013 program focusing on parasitic inductance, 3D IC, and high frequency extraction. Before joining Mentor Graphics, Christen was the director of application engineering at Sagantec and senior product marketing manager for DFM, OPC, and OPC verification at Brion Technologies.<\/p>\n<h2>Contact<\/h2>\n<p><em>Mentor Graphics<\/em><br \/>\n<em>Corporate Office<br \/>\n<\/em><em>8005 SW Boeckman Rd<br \/>\n<\/em><em>Wilsonville<br \/>\n<\/em><em>OR 97070<br \/>\n<\/em><em>USA<\/em><\/p>\n<p><em>T: +1 800 547 3000<br \/>\n<\/em><em>W: <a href=\"http:\/\/www.mentor.com\" target=\"_blank\">www.mentor.com<\/a><\/em><\/p>\n","protected":false},"excerpt":{"rendered":"<p>PGA has been IC-centric for mainstream 2D configurations. It must become system-centric for 2.5D and 3D systems.<\/p>\n","protected":false},"author":138,"featured_media":5915,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[30,38],"tags":[1068,1070,954,1073],"coauthors":[1441],"class_list":["post-5914","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-dfm-dfy","category-ic-implementation","tag-2-5dic","tag-3dic","tag-power-grid","tag-silicon-interposer","workflow-featured","workflow-front-lead","workflow-technique","workflow-up-to-date","organization-mentor-graphics"],"_links":{"self":[{"href":"https:\/\/www.techdesignforums.com\/practice\/wp-json\/wp\/v2\/posts\/5914","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.techdesignforums.com\/practice\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.techdesignforums.com\/practice\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.techdesignforums.com\/practice\/wp-json\/wp\/v2\/users\/138"}],"replies":[{"embeddable":true,"href":"https:\/\/www.techdesignforums.com\/practice\/wp-json\/wp\/v2\/comments?post=5914"}],"version-history":[{"count":0,"href":"https:\/\/www.techdesignforums.com\/practice\/wp-json\/wp\/v2\/posts\/5914\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.techdesignforums.com\/practice\/wp-json\/wp\/v2\/media\/5915"}],"wp:attachment":[{"href":"https:\/\/www.techdesignforums.com\/practice\/wp-json\/wp\/v2\/media?parent=5914"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.techdesignforums.com\/practice\/wp-json\/wp\/v2\/categories?post=5914"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.techdesignforums.com\/practice\/wp-json\/wp\/v2\/tags?post=5914"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.techdesignforums.com\/practice\/wp-json\/wp\/v2\/coauthors?post=5914"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}