ABSTRACT
This chapter is a prelude to the rest of the book. Its focus is systems applications and implications: why you may want to make things in 3D, what you might and will not get out of doing so, and the numerous considerations and requirements for making 3D systems in varying degrees of complexity. On the face of it, making a 3D system sounds like a panacea. It solves the evolutionary problem of continuing to scale the number of transistors in a chip, known as Moore’s law. It seems to be a no brainer. The goal of this chapter is to bring some perspectives to this initial reaction. Building a system in 3D does enable a few specific opportunities. It also requires solving some completely new sets of problems. As will become
clearer in this chapter, you should first decide what problems need to be solved by building a system in 3D before figuring out how to go about building it. Without first identifying what it is you think you are improving by using a 3D solution, it is not possible to tailor a 3D solution to your needs. Without first matching the various processes to the application, you will likely work much harder than needed or derive very little benefit from 3D. 3D is a wide range of technology alternatives that span a spectrum of processes and complexities.1-3 And that span is not a panacea. In essence, this chapter is cautionary: Know why you are using 3D before deciding to do so. Identify what you will gain by using 3D. And then tailor the processes to the needs. If you can’t identify what, specifically, you are gaining with 3D, don’t use it.Finally, this chapter gives a view as to where we’ve been and where we are, and a glimpse as to where we might go in systems design. At the time of 3D Integration for VLSI Systems Edited by Chuan Seng Tan, Kuan-Neng Chen and Steven J. Koester Copyright © 2012 by Pan Stanford Publishing Pte. Ltd. www.panstanford.com
this writing, 3D has only been used in limited ways, and our view toward the future is undoubtedly hampered by some of our implicitly held assumptions as to what “must be” when it comes to systems heretofore built in 2D. Since we are well aware of our innate myopia, we will make a conscious effort to look past those blinders when looking into the future. 2.1 SYSTEMS 101: THE BASICS OF COMPUTING SYSTEMSThe term system originates from the Greek systema, which refers to “a whole, compounded of several parts.” A system is an aggregation of subsystems of (perhaps) different functionalities and capabilities, wherein each subsystem can also be a system. On the surface, this seems to be a useless tautology. Why define it thus? Very simply, because this aligns with the way in which we think in abstractions.This recursive and tautological deconstruction makes even the most complex systems tractable. A system can be abstracted into subsystems. Each subsystem can be abstracted into subsystems, and so on. Eventually out of this aggregation we boil subsystems that are simple enough to specify, understand, design, verify, test, and so on. And then we put them back together to achieve a complex working system.At the level of thought and designability, this deconstruction requires that we have tools to adequately describe each subsystem in various forms: functional, structural, electrical, thermal, and physical. It also requires that as we compose the aggregate system from its subsystems, we have tools to verify that each aggregation is “correct” in the sense that its pieces cooperate in the manners intended and anticipated.While such deconstruction and reconstruction ostensibly seem like mere intellectual constructs, a natural artifact of that deconstruction (in fact, an inherent trait of systems that leads to the most natural and logical deconstructions) is that the “connectedness” of the constituent subsystems tends to be simple and narrow relative to any random cut-set that would partition a system arbitrarily.
