Abstract:
Apparatus, systems, and methods for configuring a plurality of stacked semiconductor dice with unique identifiers and identifying a die in the stack using the unique identifier are provided. Additional apparatus and methods are disclosed.

Description:
BACKGROUND 
     As the focus in microelectronics is gradually changing to include more emphasis on packaging, added value may be attained in packages by using System-in-Packages (SiP) methods. SiP methods may be considered as a leading viable solution for the ongoing trend in function integration. SiP methods include placing several dice into one package, either side-by-side or on top of each other. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       Some embodiments of the disclosed technology are illustrated by way of example and not limitation in the figures of the accompanying drawings in which: 
         FIG. 1  is a block diagram illustrating an example of modules of a circuit for sharing resources in a multi-dice stack, according to various embodiments of the invention; 
         FIG. 2  is a diagram illustrating an example of circuits for sharing resources in a four-dice stack, according to various embodiments of the invention; 
         FIG. 3  is a diagram illustrating an example of a multi-dice stack and associated resource sharing circuits, according to various embodiments of the invention; 
         FIG. 4  is a block flow diagram illustrating a method for configuring the dice of a multi-dice stack, according to various embodiments of the invention; 
         FIG. 5  is a block flow diagram illustrating a method for configuring the dice of a multi-dice stack, according to various embodiments of the invention; 
         FIG. 6  is a diagram illustrating an example of a multi-partition memory die, according to various embodiments of the invention; 
         FIG. 7  is a flow diagram illustrating a method for sharing resources in a multi-dice stack, according to various embodiments of the invention; and 
         FIG. 8  is a diagram depicting an example representation of a machine, according to various embodiments for performing any one or more of the methodologies described herein. 
     
    
    
     DETAILED DESCRIPTION 
     Example methods and circuits for sharing resources in multi-dice stacks will be described. In the following description for purposes of explanation, numerous examples having example-specific details are set forth to provide an understanding of example embodiments. It will be evident, however, to one skilled in the art that the present examples may be practiced without these example-specific details. 
     Some example embodiments described herein may include configuring a die of a number of stacked semiconductor dice (e.g., dice of a multi-dice stack, such as a 3-dimensional (3-D) die stack) and using a unique identifier to identify the die. Unique identifiers may include, but are not limited to, unique identification numbers such as 0, 1, 2, etc. The configuration may include enumeration of the dice of the multi-dice stack using the unique identification numbers. The unique identifier may be used to identify a specific die among the dice of the multi-dice stack, for example, when a command is directed to the specific die. 
     Example methods may include making ownership of (e.g., a right to control such as to receive or to generate) a signal by an identified die observable to other dice of the plurality of the multi-dice stack. For example, when a signal is generated by a device on a particular die, allowing other dies to know that the signal is generated by that particular die. The signal may include one or more commands, addresses, or data. According to described example methods, resources including one or more buses (e.g., a control bus, an address bus, or data bus) may be shared between dice of the multi-dice stack. 
     The use of enumeration of the dice of the multi-dice stack may be useful when, for example, more than one device in the multi-dice stack may use a clocking function. Due to timing constraints, each device may require its own dedicated clock signal. Traditionally, interconnected devices such as dynamic random access memories (DRAM) having a common command, address or data bus, in a planar configuration, may use a chip select signal to identify a chip. However, in a multi-dice stack, providing unique interconnects such as vias (e.g., through-silicon vias (TSV)) for individual DRAMs may become prohibitively expensive. For example, when the multi-dice stack comprises of 8 DRAMS, each including multiple logically-independent partitions (see,  FIG. 6 ), employing individual TSVs for each partition may result in use of 128 (8×16) TSVs. 
     The number of TSVs used to interconnect the devices in the dice of a stack may be reduced by assigning a unique identifier to each DRAM. Different partitions in a DRAM may share the same unique identifier. For example, in an 8-DRAM stack, since 3 bits would be sufficient to identify 8 DRAMS, 3 TSVs may be used for each partition. Therefore, for a 16 partition die, a total number of 16×3=48 TSVs may be used, which is a major reduction compared to the 128 TSVs used if enumeration of DRAMs was not employed (see end of paragraph 13). The unique identifier for each DRAM may be stored in a register on the DRAM. The DRAM may respond to a command received by the DRAM, only when an identification transmitted along with the command matches the stored unique identifier. 
       FIG. 1  is a block diagram illustrating an example of a circuit  100  for sharing resources in a multi-dice stack, according to various embodiments. The circuit  100  may include a configuration module  110 , an identification module  120 , a snoop module  130 , a register  140 , a receiver  150 , and a transmitter  160 . All or parts of the components shown in  FIG. 1  may be provided on each die of the dice of the multiple-dice stack. According to example embodiments, the configuration module  110  may configure a die of a number of stacked semiconductor dice using a unique identifier. The configuration may include, but not be limited to, enumeration of the dice of the multi-dice stack using identification numbers as unique identifiers. For example, in a four dice stack, the numbers may include zero, one, two, and three to identify the dice in the stack from the lowest die in the stack to the top die of the stack, respectively. 
     According to example embodiments, the configuration module  110  may be arranged to configure the dice (e.g., DRAMs) of the multi-dice stack upon a power-up or reset of the multi-dice stack. The configuration module  110  may use an adjacent die to enable configuration of a specific die. The adjacent die, for example, may be a die sitting under the specific die in the multi-dice stack, as described in detail below in the discussion of  FIG. 3 . 
     During normal operation, the identification module  120  may identify the die using the unique identifier. The identification module  120  may be arranged to compare a received identification number with a stored unique identifier to identify the die. For example, whenever the die detects a signal on a bus, the identification module  120  may compare an identification number transmitted in conjunction with the signal, with an identification number assigned to the die (e.g., the stored unique identifier stored in the register  140 ). One or more of the devices on the die may take the ownership of the signal, for example, by responding to the signal when the identification module  120  confirms that the identification number matches an identification number assigned to the die. The bus may be used to share signals by the dice of the multi-dice stack. The signal may include data, a command, or an address that may be communicated over a data bus, a control bus (e.g., control bus  360  of  FIG. 3 ), or an address bus (e.g., buses  370  of  FIG. 3 ), respectively. 
     In an example embodiment, the identification module  120  may include an input/output (I/O) interface. The identification module  120  may identify the die by applying an identification number to inputs at the I/O interface. Once the identification number is applied to the inputs of the I/O interface, the I/O interface may identify the die by comparing the identification number with a unique identifier stored on the register  140  provided on the die. In an alternative example embodiment, the identification module  120  may include a decoder to decode a received identification number to generate a set of select signals. The set of select signals may cause selection of the die as described in more detail below. 
     The snoop module  130  may be local to each die of the multi-dice stack and observe signals transmitted to other dice of the multi-dice stack. The signal may include control or timing (clock) signals. By observing control and clock signal transmitted to other dice of the multi-dice stack, the snoop module  130  may control access to shared resources, such as one or more data buses, so as to avoid data contention with other dice of the multi-dice stack. Each die of the multi-dice stack may include the receiver  150  to receive signals from one or more buses. Each die may also include the transmitter  160  to transmit signals to the bus when enabled to drive the bus, as discussed below. 
       FIG. 2  is a diagram illustrating an example of circuit  200  for sharing resources in a four dice stack, according to various embodiments. The circuits are only shown for two dice of a four-dice stack identified by unique identifiers 0 and 1 as die 0  and die 1 . The four-dice stack may include four control signals  220 ,  230 ,  240  and  250 , which are used to indicate access to the shared resources such as a data bus  210  (DQ 0 ). The control data may include clock signals or strobe signals. For each die on the multi-dice stack, there may be one set of control signals. The dice on the four-dice stack may be identified by unique identifiers, such as 0 to 3. Every time the four dice stack is powered up or reset, the enumeration logic  312  shown in  FIG. 3  may assign one set of the control signals  220 ,  230 ,  240 , and  250  to one of the dice of the four-dice stack. The number of control signals may be the same as the number of dice in a multi-dice stack and is not limited to four. 
     The assignment of the one set of control signals to each of the dice of the multi-dice stack may be valid for a particular period of time, during which the die may generate one or more control signals. For example, when the die is a DRAM that has received a read request, the DRAM may send a clock pulse to signal that the DRAM is about to drive a data bus  210 . 
     As shown in  FIG. 2 , the decoder  260  may decode an identification (ID) number  262  generated by the enumeration logic  312  of  FIG. 3  to generate a set of select signals  264 . The set of select signals  264  may cause the selection of one of the dice of the four-dice stack. For example, to assign the control signal  220  to the die 0 , the set of select signals  264  generated by the decoder  260  may cause a switch  228  to close and therefore enable die  0  to have ownership of the control signal  220 . The set of select signals  264  are applicable to select lines of other dice (such as, select line  239 ) as well. For example, when the set of select signals  264  generated by the decoder  260  cause the switch  238  to close, the die 1  is enabled to claim the ownership of control signal  230 . 
     In the example embodiment shown in  FIG. 2 , each die of the four dice stack may comprise a DRAM (e.g., a DRAM 0  and a DRAM 1 ) and the control signals  220 ,  230 ,  240 , and  250  may be transmitted through TSVs. When the DRAM 0  is assigned the control signal  220  (also shown as CLK 0 ), the DRAM 0  may transmit a control signal  220  to let a logic die  310  shown in  FIG. 3  know that the DRAM 0  is reading out data. A high (e.g., logic level 1) select signal on a select line  229  may enable the driver  224  of the DRAM 0  to generate the control signal  220  using the clock signal (e.g., CLKOUT)  222 . The same high select signal may disable a receiver  226  of DRAM 0 . While the DRAM 0  is reading out, the receivers of the other DRAMs connected to the control signal  220 , are not connected to select lines (such as select line  239 ) thus are not disabled and may monitor the control signal  220 . 
     When the receiver  226  is disabled by a high signal on the select line  229 , a transistor  227  having a high signal on its gate (connected to select line  229  when the switch  228  is closed) is turned ON. The ON transistor  227  may pull an output of the receiver  226 , which is disabled, to the ground. As a result, an input of an OR-gate  270 , connected to the output of receiver  226 , will also be connected to the ground. The OR-gate  270  may then pass signal transitions from the other control signals routed from the other dice of the multi-dice stack to other inputs of the OR-gate  270  to the snoop logic  280 . The snoop logic  280  may respond to the signal transitions from other control signals by enabling a diver  212  to drive the data bus  210 . The enabling of the diver  212  may occur, at an appropriate time based on access status of the other dice of the multi-dice stack, as observed through the other control signals routed to other inputs of the OR-gate  270 . 
     Assume that DRAM 0  is driving the data bus  210 , the DRAM 1  may observe a read request issued to other DRAMS (e.g., DRAM 0 ) and decode a non-matching identification number associated with the read request to allow DRAM 1  to disable access to the data bus  210  and only enable access to the data bus  210  when the snoop logic  282  of the DRAM  1  receives a proper signal. The snoop logic  282 , which is monitoring the control signal  220  through a receiver  236  and an OR-gate  272 , may snoop the control signal  220  to find out when the DRAM 0  stops driving the data bus  210 . The snoop logic  282  may detect the stopping time of the DRAM 0  being driven by the data bus  210  by sensing a transition in the control signal  220 . The snoop logic  282  may enable a driver  216  to drive the data bus  210  at an appropriate time, based on the transition in the control signal  220 . While DRAM 0  is driving the data bus  210 , DRAM 1  may receive a read request. The DRAM 1  may decode a matching identification number associated with the read request; however, the read request may be delayed by the snoop logic  282  until the read request to DRAM 0  is complete. 
       FIG. 3  is a diagram illustrating an example of a multi-dice stack  300  and associated resource sharing circuits, according to various embodiments. The multi-dice stack  300  may include a logic die  310  and four DRAMs  320 ,  330 ,  340  and  350 . The logic die  310  may include an enumeration logic  312 . In example embodiments, the enumeration logic  312  may include the configuration module  110  and the identification module  120 , both of  FIG. 1 .  FIG. 3  also shows a group of buses (e.g., TSVs)  370  (also called shared buses  370 ), which may include shared command, address, and data buses for DRAMs  320 ,  330 ,  340 , and  350 . 
     Also shown on  FIG. 3  are control buses (e.g., TSVs)  360 ,  362 ,  364 , and  366 . The enumeration logic  312 , including the configuration module  110  of  FIG. 1 , may configure each of DRAMs  320 ,  330 ,  340 , and  350  by assigning a unique identifier to each DRAM. Enumeration logic  312  may use the configuration bus (e.g., TSV)  382  and identification bus (e.g., TSV)  384  to configure and identify the DRAMs  320 ,  330 ,  340 , and  350  of the multi-dice stack  300 . The DRAMs  320 ,  330 ,  340 , and  350  may also include enumeration logics  322 ,  332 ,  342 , and  352 . 
     The process of configuration of DRAMs  320 ,  330 ,  340 ,  350  by the enumeration logic  312  starts from the configuration of the DRAM  320 . The configuration process for each DRAM may include using a DRAM next to that DRAM (e.g., a DRAM under that DRAM) to enable the configuration. For example, the enumeration logic  322  may be enabled via an enable signal received from the enumeration logic  312 . The enable signal may reach an enable input of the enumeration logic  322  through a via  324  connecting the output of the enumeration logic  312  to an enable input of the enumeration logic  322 . Once enabled, the enumeration logic  322  may be able to read a unique identifier (e.g., an identification number such as 0) provided by the enumeration logic  312  from the configuration bus  382 . The read unique identifier may then be loaded into the register  140  of  FIG. 1 , which exists on DRAM  320 . 
     After the DRAM  320  is configured, the enumeration logic  322  may be stopped from reading the configuration bus  382 . The enumeration logic  322  may then send a second enable signal through a via  334  to the enumeration logic  332  of DRAM  330  to enable reading of the configuration bus  382  by the enumeration logic  332 . Similarly, the enumeration logics  342  and  352  may be successively enabled by the enumeration logics  332  and  342  through vias  344  and  354 , respectively. Each of the DRAMS  330 ,  340  and  350  may also include the register  140  shown in  FIG. 1 , and use the register  140  to store the unique identifiers assigned to them by the enumeration logic  312 . Each DRAM  320 ,  330 ,  340 , and  350  may then be identified by the identification module  120  shown in  FIG. 1  using an identification number placed on the identification bus  384  by the enumeration logic  312 . In some embodiments the enumeration logic  312  may use an alternative method for enumerating the dies of the multi-dice stack  300 . 
     Each DRAM, as discussed in more detail below, may include multiple logically-independent partitions (see partitions in DRAM of  FIG. 6 ). An identification number assigned to each DRAM of the multi-dice stack  300 , by the enumeration logic  312 , may be distributed to the multiple logically-independent partitions of that DRAM. During the normal operation of the DRAM, when a command is issued within a particular partition, the identification number for the intended DRAM is transmitted along with the command. The partition that receives the command, if belongs to the DRAM that has the stored identification number matching the transmitted identification number may then respond to that command. 
     The DRAMs shown in the multi-dice stack  300  may also include the driver  224 , the receiver  226 , the OR-gate  270  and the snoop logic  280  as shown in both  FIGS. 2 and 3 . The driver  224  and the receiver  226  may be used to drive the control bus  360  or receive clock signals from the control bus  360  in a similar fashion as described above with respect to  FIG. 2 . To avoid data bus contention and for proper sequencing of commands, the snoop logic  280  may determine when ownership of any of the shared buses  370  is available for an individual DRAM of the multi-dice stack  300 . 
       FIG. 4  is a block flow diagram illustrating an example of a method  400  for configuring dice of a multi-dice stack, according to various embodiments. The multi-dice stack  300  of  FIG. 3  is powered up or reset at operation  410 . At operation  420 , the logic die  310  of  FIG. 3  may use the enumeration logic  312  shown in  FIG. 3  to initiate the enumeration of the DRAMs of the multi-dice stack  300 . At operation  430 , unique identifier values are decoded by each DRAM using the decoder  260  of  FIG. 2 . At operation  440 , drivers and receivers (for example, driver  224  and receiver  226 , both of  FIG. 3 ) connected to the control bus  360  of  FIG. 3  may be enabled according to assigned unique identifiers to each DRAM (for example DRAM  320 ). At operation  450 , configurations of the DRAMs in the multi-dice stack  300  continue. The configuration process restarts upon following power-ups or resets of the multi-dice stack  300 . 
       FIG. 5  is a block flow diagram illustrating an example of a method  500  for configuring dice of a multi-dice stack, according to various embodiments. The method  500  starts at operation  510  when the logic die  310  of  FIG. 3  starts configuration of the DRAM  320  by enabling the enumeration logic  322  of the DRAM  320 . At operation  520 , the enumeration logic  312  of the logic die  310  may issue a command to assign the DRAM  320  a unique identifier (e.g. a digital identifier or a digital identification number) using the configuration bus  382  of  FIG. 3 . At operation  530 , the DRAM  320  may use the register  140  shown in  FIG. 1  and included in the enumeration logic  322  to store the digital identifier assigned by the enumeration logic  312 . 
     The DRAM  320  of  FIG. 3 , at operation  540 , may disable the loading functionality of an identification number by the enumeration logic  322  shown in  FIG. 3  and enable the enumeration logic  332  of the DRAM  330  of  FIG. 3  for configuration of the DRAM  330 . The enumeration logic  312  may perform similar operation with the other DRAMs in the multi-dice stack  300  (e.g., DRAMs  340  and  350 ). At the control operation  550 , the enumeration logic  312  may check that all the DRAMs in the multi-dice stack  300 , including the last DRAM  350 , are configured with unique identifiers. If the last DRAM (e.g., DRAM  350 ) has been configured, the method  500  will end. Otherwise, the control is passed to the operation  520  where the remaining DRAMs will be configured with unique identifiers assigned to those DRAMs by the enumeration logic  312 . 
       FIG. 6  is a diagram illustrating an example of a multi-partition memory die  600 , according to various embodiments. The multi-partition memory die  600  may, for example, comprise one of the DRAMs of the multi-dice stack  300  of  FIG. 3 . As shown in the  FIG. 6 , the multi-partition memory die  600  may include a number of partitions  610  (for example, 16 partitions). Each partition may include several arrays  612  of memory cells. Each partition may also include a group of TSVs  614  dedicated to the partition. The group of TSVs  614  may include data, command and address buses dedicated to the partition  610 . The multi-partition memory die  600  may also include an array of TSVs  620  which are common to all partitions of the multi-partition memory die  600 . The configuration and identification of the multi-partition memory die  600  is performed in a similar fashion as described above with respect to the DRAMs of the multi-dice stack  300  of  FIG. 3 . 
       FIG. 7  is a flow diagram illustrating an example of a method  700  for sharing resources in the multi-dice stack  300  of  FIG. 3 , according to various embodiments. The method  700  starts at operation  710 , where the configuration module  110  of  FIG. 1  may configure a die of a multi-dice stack  300  of  FIG. 3  with a unique identifier. At operation  720 , using the unique identifier, the enumeration logic  312  of  FIG. 3  may use identification bus  384  to identify each DRAM of the multi-dice stack  300  of  FIG. 3 . At operation  730 , the snoop module  130  of  FIG. 1  may make ownership of a signal by an identified die (for example, die  320  of  FIG. 3 ) observable to other dice of the multi-dice stack  300  (e.g., dice  330 ,  340  and  350 ). The signal may include one or more of an address, a command, or data communicated through one or more of the shared buses  370  of  FIG. 3 . 
       FIG. 8  is a diagram illustrating an example representation of a machine  800 , according to various embodiments. In an example embodiment, machine  800  includes a set of instructions that may be executed to cause machine  800  to perform any one or more of the methodologies discussed herein. In alternative embodiments, the machine  800  may operate as a standalone device or may be connected (e.g., networked) to other machines. In a networked deployment, the machine  800  may operate in the capacity of a server or a client machine in a server-client network environment or as a peer machine in a peer-to-peer (or distributed) network environment. Machine  800  may be realized in the form of a computer. 
     The machine  800  may be a server computer, a client computer, a personal computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a Web appliance, a network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein. 
     The example machine  800  may include a processor  860  (e.g., a central processing unit (CPU), a graphics processing unit (GPU) or both), a main memory  870  and a static memory  880 , all of which communicate with each other via a bus  808 . The machine  800  may further include a video display unit  810  (e.g., a liquid crystal display (LCD) or cathode ray tube (CRT)). The machine  800  also may include an alphanumeric input device  820  (e.g., a keyboard), a cursor control device  830  (e.g., a mouse), a disk drive unit  840 , a signal generation device  850  (e.g., a speaker), and a network interface device  890 . 
     The disk drive unit  840  may include a machine-readable medium  822  on which is stored one or more sets of instructions (e.g., software)  824  embodying any one or more of the methodologies or functions described herein. The instructions  824  may also reside, completely or at least partially, within the main memory  870  and/or within the processor  860  during execution thereof by the machine  800 , with the main memory  870  and the processor  860  also constituting machine-readable media. The instructions  824  may further be transmitted or received over a network  882  via the network interface device  890 . 
     While the machine-readable medium  822  is shown in an example embodiment to be a single medium, the term “machine-readable medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The term “machine-readable medium” shall also be taken to include any medium capable of storing, encoding, or carrying a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present technology. The term “machine-readable medium” shall accordingly be taken to include, but not be limited to, solid-state memories and optical and magnetic media. 
     Embodiments of a method and a circuit for sharing resources in a stacked dice have been described. Although the present embodiments have been described, it will be evident that various modifications and changes may be made to these embodiments. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense. 
     The Abstract of the Disclosure is provided to comply with 37 C.F.R. §1.72(b), requiring an abstract that allows the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the claims. In addition, in the foregoing Detailed Description, it may be seen that various features are grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as limiting the claims. Thus, the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separate embodiment.