Address SoC routing congestion with 2.5D SiP

Transcription

1 Address SoC routing congestion with 2.5D SiP The System in Package in a 2D package is the best of both worlds approach that the electronics industry has come up with to resolve a design dilemma. By Ayan Kumar Halder System Software Engineer Open-Silicon Research Pvt Ltd Not very long ago, embedded systems were made up of logic spread across multiple chips for example, the CPU sub-system. Memory, the analogue components, and so on, were each on their own IC. The advantage was that each chip could be independently designed at its appropriate process technology node (90nm, 130nm, etc.). However, the inter-connection between the chips consumed a significant amount of power, and there was high inter-chip communication latency as well as even higher risk of failure. Then came the era of the System on Chip (SoC) where the various components (digital logic, analogue logic, and memory sub-system) were placed on the same silicon chip. Thus the increased power consumption and latency issues observed with inter-chip communication in the previous design mechanism was ruled out. However, the disadvantage was that as the components were integrated in the same silicon, they had to be built at the same technology node (65nm, 40nm, 28nm, and so on). While some logic, particularly the main processor, adds a greater value if it is designed at the latest technology node, the other components, such as memory, might not add that much value. However, the dilemma is that using traditional System-on-Chip methods, the chip designer has to choose the same process technology for all the logic. In addition to forcing the designer to create a less than silicon-efficient design, this also hindered reusability of some blocks, such as the CPU sub-system, as independent verified logic in the next system design. The best of both worlds approach that the electronics industry has come up with to solve this dilemma is the System in Package (SiP) in a 2D package. Here multiple chips (DIE) are placed on a common substrate. Thus there can be a CPU-sub-system on one die, a memory sub-system on another, and analogue logic on a third die (figure 1). Each DIE can be designed at its appropriate process technology node and later reused in later designs as Known Good DIEs (KDGs) which have been tested at wafer level. This reduces the time to market for the complete system, as KGDs can be reused with newer dies. The substrate carries a low power, low latency, high speed communication link between the DIEs. Figure 1: 2D package. The DIEs are mounted on the SiP substrate by flip-chip bumps. The copper tracks on the substrate are many times wider than that on the DIEs. However, this creates a problem of placement, as it limits the number of dies that can be accommodated on the substrate because of routing congestion, which ultimately impacts performance and power consumption. Relieving routing congestion with 2.5D SIP The solution to this problem is 2.5D packaging, where a silicon interposer is added between the DIEs and the substrate. The interposer is a low power, low latency, high speed communication link between the chips. The DIEs are mounted on the interposer using micro bumps that are many times smaller than the flip-chip bumps connecting the interposer to the substrate. The copper tracks on the upper layer of interposer are almost of the same dimensions as those on the DIEs. The interposer has TSV (Through Silicon Vias copper connections) connecting the tracks on the upper layer to those EE Times-Asia eetasia.com Copyright 2014 emedia Asia Ltd. Page 1 of 5

2 on the lower layer. It allows thousands of connections between the dies. Thus, by using the interposer the routing/congestion problems faced in 2D design are overcome. Figure 2: 2.5D package. A natural successor is 3D, where multiple DIEs are mounted one on top of the other with TSVs running through the lower dies to allow inter-die communication and provide power to all the dies. Further elaboration of 3D technology is out of scope from our technical paper s perspective. System design with 2.5D Show in figure 3 is a typical 2.5D System in Package (SiP) architecture, in which DIE1/DIE2 consist of two CPU cores with l2 cache interfaced by two AXI master interfaces. It has some slow peripherals (UART, GPIO, I2S, I2C, SPI, BootROM) interfaced by an APB interface. The DIE to DIE (D2D) interface runs through the interposer. It consists of two AXI-AXI bridges (each AXI bridge consists of a master and slave port), 64 GPIO lines (32GPIOs in which DIE1 is configured as input and DIE2 as output and the remaining 32GPIO lines are configured for DIE1 as output and DIE2 as input), Interrupt lines, and DMA channels. The interposer also branches the system reset to each DIE to allow both the DIEs to reset together. The D2D interface determines the visibility of IPs of the neighbouring DIE to the host DIE. In this case, as each DIE has two master/slave interfaces, it can communicate to some of the IPs of the neighbouring DIE, which will be discussed later. DIE1 and DIE2 are virtually identical, except that DIE1 has a DDR controller and PHY interface connected to a DRAM chip, while DIE2 does not. Further, DIE1 has I2S and an I2C interfaced codec, which is missing in DIE2. The DIE2 sub-system has an LCD panel mounted on GPIO pins. Each DIE has its own memory map in which D2D slave interfaces occupy a section. DIE1 Figure 3: 2.5D System in Package architecture. DIE2 EE Times-Asia eetasia.com Copyright 2014 emedia Asia Ltd. Page 2 of 5

3 The system is designed in such a way that a part of DDR (first 512MB) is shared between the two DIEs. The interaction between DIE1 and DIE2 via the DIE-to-DIE interface is illustrated in figure 4. Thus, DIE2 is able to access the first 512MB of DDR through its D2D slave interfaces. Please note this is only a partial view of our memory map, which serves to illustrate access of DDR by DIE2 via DIE-to-DIE interface/communication. Shown in figure 4 is the DIE-to-DIE communication, in which DIE2 communicates with the DDR of DIE1 through its D2D slave interface via the D2D Bridge. However, it is equally possible for DIE1 to communicate with any functional component of DIE2 through its D2D slave interface. For the sake of keeping the design simple, this has been avoided. Figure 4: Memory Map showing how DDR is shared between DIE1 and DIE2. Figure 5: DIE1 and DIE2 initialisation. EE Times-Asia eetasia.com Copyright 2014 emedia Asia Ltd. Page 3 of 5

4 Software demonstration of DIE-to-DIE interaction Shown in figure 5 is a simple implementation that illustrates DIE-to-DIE interaction. DIE2 has a GPIO interface to a LCD panel. It displays images on the LCD, which is obtained from DIE1. DIE1 has I2S and I2C interfaced codec. It plays audio data obtained from DIE2. DIE-to-DIE GPIO has been used as a signalling mechanism between DIE1 and DIE2. Execution of a typical system operation typically starts from Boot ROM (0xFFFF0000). Both the DIEs fetch their first instruction from Bootrom. DIE1 and DIE2 initialise the CPU cores and caches. DIE2 is made to wait on a DIE-to-DIE GPIO to allow DIE1 to initialise DDR Controller and PHY and copy the images (to be displayed by DIE2) from its NOR (which has a parallel interface via Static Memory Controller) to a pre-decided location in the shared section of DDR (first 512MB). Figure 6: DIE1 and DIE2 Interaction over D2D interface.the arrows represent the flow of data. Figure 7: DDR Partition for DIE1 and DIE2. EE Times-Asia eetasia.com Copyright 2014 emedia Asia Ltd. Page 4 of 5

5 But this operation restricts DIE2 from accessing DDR (via the D2D interface) until DDR has been initialized by DIE1. On receiving the GPIO signal, DIE2 starts copying the audio data (for DIE1) from its NOR (interfaced by Static Memory Controller) to a pre-decided location in the shared section of DDR (first 512MB) via its DIE-to-DIE (D2D) slave interfaces. In the meantime, DIE1is waiting for a D2D GPIO signal. After copying the audio data, DIE2 sends a D2D GPIO signal to DIE1. Further, DIE2 initializes the LCD Controller and starts rendering data to the LCD via the GPIO from the DDR location (where DIE1 had copied the images) via its DIE-to-DIE (D2D) slave interfaces. As shown in figure 6, on receiving the D2D GPIO signal DIE1 initializes the I2S and codec. It starts rendering audio data from DDR (where DIE2 had copied the audio data) to the codec via the I2C interface. Here PNOR1/2 denotes NOR with static memory controller interface. The DDR is partitioned for use by DIE1 and DIE2 as shown in figure 7. Conclusion On all the categories important to a system designer design simplicity, reusability of hardware IP, power consumption, and time to market, 2.5D technology is a step ahead of single DIE System on Chip. Refer to figure 8 for a comparative description of 2.5D vs single DIE SoC. Figure 8: Comparison between SoC (single DIE) and 2.5D. In real-world scenarios, 2.5D is best used with a more heterogeneous system architecture where we have the CPU sub-system and digital logic (such as USB, PCIE, SATA, etc.) on one DIE, memory sub-system (SRAM, DDR3 controller) on another die, analogue components (DDR-PHY, USB PHY) on a third die, and thermal sensors and power regulators on a fourth DIE. Such complex designs would derive even greater benefits from the 2.5D approach. About the author Ayan Kumar Halder is a System Software Engineer at Open-Silicon Research Pvt Ltd. His work involves designing/porting bare-metal software, kernels, bootloaders and linux drivers on ARM based custom SOCs. He has contributed to porting Open Virtualization, an open-source kernel-based virtual machine SDK on Versatile Express. He received his Masters in Computer Science from University of Pune, India. EE Times-Asia eetasia.com Copyright 2014 emedia Asia Ltd. Page 5 of 5