# US 2015/0106569 A1 · Chip stack cache extension with coherency

> Agents: this data is available as JSON from the patentgrep API and MCP server — see https://patentgrep.com/llms.txt

- Number: US 2015/0106569 A1
- Document ID: US20150106569A1
- Status: Published application
- Kind: A1
- Application number: 14/051,067
- Filed: 2013-10-10
- Published: 2015-04-16
- Earliest claimed: 2013-10-10
- Assignees: International Business Machines Corporation
- Applicants: International Business Machines Corporation
- Inventors: Edgar R. Cordero; Anand Haridass; Subrat K. Panda; Saravanan Sethuraman; Diyanesh Babu Chinnakkonda Vidyapoornachary
- Web page: https://patentgrep.com/patent/US20150106569A1

## CPC

- H10W 90/00: Package configurations
- G06F 11/00: Error detection; Error correction; Monitoring (error detection, correction or monitoring in information storage based on relative movement between record carrier and transducer G11B20/18; monitoring, i.e. supervising the progress of recording or reproducing G11B27/36; in static stores G11C29/00)
- G06F 12/0802: Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
- H10W 90/297: {characterised by the through-semiconductor vias [TSVs] in the stacked chips}
- H10W 90/722: {between stacked chips}
- H10W: GENERIC PACKAGES, INTERCONNECTIONS, CONNECTORS OR OTHER CONSTRUCTIONAL DETAILS OF DEVICES COVERED BY CLASS H10
- G06F: ELECTRIC DIGITAL DATA PROCESSING (computer systems based on specific computational models G06N)

## Abstract

By arranging dies in a stack such that failed cores are aligned with adjacent good cores, fast connections between good cores and cache of failed cores can be implemented. Cache can be allocated according to a priority assigned to each good core, by latency between a requesting core and available cache, and/or by load on a core.

## Claims

### Claim 1

A cache management method for a semiconductor device stack of at least two dies, each die including at least two computing devices, each computing device including at least one core, each core including a local cache, and each die including at least one shared cache connected to at least one core of the respective die, the method comprising:
testing each core;
responsive to a core failing the testing, identifying the core as a failed core;
responsive to a core passing the testing, identifying the core as a good core;
stacking the at least two dies such that a good core of a first die is aligned with a failed core of at least one adjacent die; and
connecting a failed core local cache of each failed core to at least a first aligned good core for primary use by the at least a first aligned good core.

### Claim 2 (depends on 1)

The method of claim 1, further comprising storing a respective quality indicator and a respective address of each core, the respective quality indicator including one of good, good core with failed cache, failed core with good cache, or failed core with failed cache.

### Claim 3 (depends on 2)

The method of claim 2, wherein the stacking of the at least one die includes using the respective quality indicator and respective address of each core so that any failed core with good cache of one die is aligned with at least one respective good core of at least one adjacent computing device.

### Claim 4 (depends on 1)

The method of claim 1, further comprising providing a respective scan communication (SCOM) register for each computing device with at least an extension mode bit, a first value of the extension mode bit indicating that extension mode is enabled and a second value of the extension mode bit indicating that extension mode is disabled, the respective SCOM register further including at least two respective failed core cache bits for every failed core of the respective computing device, values of the failed core cache bits storing an address of a failed core.

### Claim 5 (depends on 4)

The method of claim 4, further comprising managing use of any failed core cache by each respective aligned good core using a hypervisor in communication with every configuration register.

### Claim 6 (depends on 1)

The method of claim 1, wherein each core includes a respective local cache, each die includes a respective shared cache, and the method further comprises determining a first latency between a good core and the respective shared cache, determining a second latency between the good core and the local cache of a failed core, and connecting the local cache of the good core to the respective one of the local cache or the shared cache associated with the lesser of the first latency and the second latency.

### Claim 7 (depends on 1)

The method of claim 1, further comprising connecting the failed core cache to at least a second aligned good core for secondary use when the first aligned good core is not using the failed core cache.

### Claim 8 (depends on 1)

The method of claim 1, further comprising monitoring each good core for a failure, identifying any good core experiencing a failure as a failed core, and assigning a failed core cache of any failed core to at least one good core.

### Claim 9 (depends on 1)

The method of claim 1, further comprising, responsive to a first good core needing additional cache, assigning at least a portion of a respective good core cache of a second good core to the first good core.

### Claim 10 (depends on 9)

The method of claim 9, further comprising reassigning the at least a portion of the respective good core cache to the second good core responsive to the first good core no longer needing additional cache.

### Claim 11 (depends on 1)

The method of claim 1, further comprising sending a memory intensive workload to the at least one aligned good core.

### Claim 12 (depends on 9)

The method of claim 9, further comprising storing register data indicative of the assignment of the failed core cache and allowing access to the register data by at least one of a running process, a running program, or a device.

### Claim 13

A semiconductor device stack comprising:
at least two dies, each die including:
at least two computing devices, each computing device including:
at least one core having associated therewith a respective identifier of good core or failed core; and
a respective local cache connected to each core;
at least one shared cache connected to every core of the computing device; and
a configuration register connected to every core of the computing device and storing each respective identifier in a respective quality indicator,
wherein the at least two dies are oriented with any failed core of any die aligned with a respective good core of at least one other adjacent die,
the stack being configured to enter a cache extension mode in which at least one good core is configured to use at least one of a local cache of another core or a shared cache of another computing device.

### Claim 14 (depends on 13)

The stack of claim 13, wherein each configuration register includes a respective scan communication (SCOM) register for each computing device configured to store an extension mode indicator of whether cache extension mode is enabled and at least one cache indicator of a respective enabled cache.

### Claim 15 (depends on 14)

The stack of claim 14, wherein a respective local cache of a good core is connected to one of a respective local cache of a failed core or a respective shared cache of a computing device including the failed core responsive to each respective SCOM and each respective quality indicator.

### Claim 16 (depends on 13)

The stack of claim 13, wherein the stack is responsive to a hypervisor configured to communicate with every configuration register, to monitor at least the good cores of the stack, and to control at least one configuration register responsive to the quality indicators and to a load on each core.

### Claim 17 (depends on 16)

The stack of claim 16, wherein the hypervisor is further configured to monitor the cores of the stack for failure and to change a respective identifier of any good core that fails to failed.

### Claim 18

A method comprising:
testing each of at least two dies each including at least one computing device with at least one respective core, each core having a respective local core, and each die having at least one shared cache connected to at least one respective core;
storing a quality indicator for each core in at least one configuration register, the quality indicator identifying the respective core as a failed core or as a good core responsive to the respective core failing or passing the testing, respectively;
stacking the dies with any failed core in alignment with a respective good core of at least one adjacent die;
determining a first latency between a good core and the respective shared cache;
determining a second latency between the good core and the local cache of a failed core; and
connecting the local cache of the good core to the respective one of the local cache or the shared cache associated with the lesser of the first latency and the second latency.

### Claim 19 (depends on 18)

The method of claim 18, further comprising connecting a failed core local cache to at least a first aligned good core for primary use by the first aligned good core and to at least a second aligned good core for secondary use by the second aligned good core.

### Claim 20 (depends on 18)

The method of claim 18, further comprising storing register data indicative of a connection between the local cache of a good core with another cache.