Patent Description:
System on Chip (SoC) devices may have two or more cores for applications in which redundancy of hardware and data flows are utilized. In such redundant systems, transactions are duplicated wherein one read involves two read operations and one write involves two write operations and two cache lines are used. To ensure redundancy, a check may be performed to confirm that the data on both cache lines are identical. Doubling the amount of data to be processed for the redundancy check, however, means the amount of storage must be doubled. Data on the cache lines may be returned out of order and with no fixed time interval between the copies from two separate memory locations on a redundant mesh. Furthermore, data on the cache lines themselves may be split into two or more chunks which may be returned in any order.

In such redundant systems, the data is not stored until all of the chunks are accumulated in order to check and ensure that all copies of the data are identical.

Such an approach, however, involves a large memory to store all the accumulated data, and also may take too long to accumulate and process the data in order to timely signal any errors before a specified Fault Detection Time Interval (FDTI). Furthermore, in order to ensure that cycle accurate lockstep is maintained between two cores, the outputs of the cores must be checked as being identical every cycle. Any mismatch between the core outputs also must be signaled before the FDTI. Checking the entire outputs of two cores, however, may involve too many wires to route for comparing all data on all the output wires.

<CIT> relates to a semiconductor device with a first processor and a second processor, with two compression circuits that are used to convert an n-bit output of the respective processors to an m-bit output, and with a checker for checking whether the respective m-bit outputs coincide with each other.

<CIT> relates to a self-test of safety logic in safety critical devices. The safety logic includes comparator logic coupled to a circuit under test (CUT) in a safety critical device and the self-test logic is configured to test the comparator logic. The self-test logic may be implemented as a single cycle parallel bit inversion approach, a multicycle serial bit inversion approach, or a single cycle test pattern injection approach.

<CIT> relates to apparatuses and methods for reducing the uncorrectable error rate in a lockstepped dual-modular redundancy system. In one example, an apparatus includes two processor cores, a micro-checker, a global checker, and fault logic. The micro-checker is to detect whether a value from a structure in one core matches a value from the corresponding structure in the other core. The global checker is to detect lockstep failures between the two cores. The fault logic is to cause the two cores to be resynchronized if there is a lockstep error but the micro-checker has detected a mismatch.

The invention is defined in the appended independent claims <NUM>,<NUM> and <NUM>.

Further preferred embodiments of the invention are defined in the sub-claims <NUM>-<NUM>.

The detailed description is provided with reference to the accompanying figures.

In the following description, numerous specific details are set forth in order to provide a thorough understanding of various embodiments. However, various embodiments may be practiced without the specific details. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to obscure the particular embodiments. Further, various aspects of embodiments may be performed using various means, such as integrated semiconductor circuits ("hardware"), computer-readable instructions organized into one or more programs ("software"), or some combination of hardware and software. For the purposes of this disclosure reference to "logic" shall mean either hardware, software, firmware, or some combination thereof.

Referring now to <FIG>, a diagram of a System on Chip (SoC) having two cores with data checkers and a lockstep checker in accordance with one or more embodiments will be discussed. As shown in <FIG>, SoC <NUM> may include a master core <NUM> and a slave core <NUM> that are to operate in lockstep wherein the operations of master core <NUM> are duplicated by slave core for redundancy. Although <FIG> shows an example of a two core SoC <NUM>, other arrangements of SoC <NUM> may be utilized with more or fewer cores, and the scope of the claimed subject matter is not limited in this respect. In one or more embodiments, one or more of the cores may include a corresponding data checker such as data checker <NUM> for master core <NUM> and data checker <NUM> for slave core <NUM>. The data checkers are used to check for data mismatches on cache lines in some embodiments, and in other embodiments the data checkers may be extended to any fabric that returns redundant copies of transactions that are to be efficiently compared in order to ensure that both copies are correct.

In some embodiments, SoC <NUM> may have an input <NUM> to provide inputs to master core <NUM>. The inputs of master core <NUM> also may be driven to slave core <NUM>. SoC <NUM> also may have an output <NUM> wherein outputs from master core <NUM> may be utilized to drive the mesh of a central processing unit (CPU), for example as shown in and described with respect to <FIG> below, although the scope of the claimed subject matter is not limited in this respect. In order to ensure that the master core <NUM> and slave core <NUM> are in lockstep, a lock step checker <NUM> may receive the outputs from both of the cores to compare the output of master core <NUM> with the output of slave core <NUM>.

In or more embodiments, data checker such as data checker <NUM> and data checker <NUM> may check between the Master cache line and Slave Cache line. Each cache line is <NUM> bytes (B), or <NUM> bits (b), and arrives in two chunks of <NUM> b for the upper cache line and the lower cache line. The arrival order on the cache lines is not guaranteed to be in any particular order. There may be storage available for <NUM>-<NUM> bits. A mismatch between the Master cache line and the Slave cache line results in a fatal error.

A redundant mesh data check may check that data on the Master cache line == data on the Slave cache line by performing a cyclic redundancy check on all four of the cache lines (Master upper and lower cache lines and Slave upper and lower cache lines): <MAT>.

Effectively, if all the four CRC (<NUM>* <NUM> half cachelines) are exclusive ORed (XORed) together, the final vector should be <NUM> for a redundancy check pass: <MAT> for a passing case. In such an operation, the redundancy check structure is initialized to <NUM>. When a 1st half cache line arrives from any of the redundant halves:.

When 2nd half cache line arrives from any of the redundant halves:.

When the last expected data half line is being XORed, check if final result is <NUM>. If the final result is <NUM>, then the data check passes. Otherwise, the data check fails. An example of a CRC pipeline for data checker <NUM> or data checker <NUM> is shown in and described with respect to <FIG>, below.

Referring now to <FIG>, a diagram of a data checker in accordance with one or more embodiments will be discussed. As shown in <FIG>, data checker <NUM> may represent the CRC pipeline of data checker <NUM> or data checker <NUM> of <FIG>. Valid input data (VALID-IN) may be provided to flip-flop (FLOP) <NUM> and then to flip-flop (FLOP) <NUM> to provide valid CRC output data (CRC _64_OUT_VAL) which may be <NUM> bits in one or more embodiments. The data to be checked (DATA_IN) comprising <NUM> bits may be provided to flip-flop (FLOP) <NUM>, which may be multiplexed with built in self-test test data (BIST_DATA_IN) with multiplexer (MUX) <NUM> for testing purposes. The output of flop-flop <NUM> may be provided to a 64b CRC checker <NUM> to provide its output to flop-flop (FLOP) <NUM> to provide a 64b CRC output (CRC_64_OUT). The CRC checker <NUM> may include a <NUM>:<NUM> error inject mask (ERROR_MASK[<NUM>:<NUM>]). Built in self-test (BIST) patterns and cyclic redundancy codes (CRs) may be stored in a memory <NUM>.

In one or more embodiments, the data checker CRC pipeline <NUM> may operate to interleave the data bits such that b[<NUM>]^b[<NUM>]^b[<NUM>]. , b[<NUM>]^[b5]^b[<NUM>],. A data checker finite state machine (FSM) may operate by adding a five state FSM per Queue entry to track stored the CRC value state.

In one or more embodiments, the data checker CRC polynomials may be as shown in Table <NUM>, below.

In one or more embodiments, data checker debug hooks may be implemented as follows.

In one or more embodiments, the data checker BIST mat be implemented as follows.

Referring now to <FIG>, a diagram of an alternative data checker in accordance with one or more embodiments will be discussed. The data checker <NUM> of <FIG> is substantially similar to the data checker <NUM> of <FIG> except that data checker <NUM> utilizes four 16b CRC checkers <NUM>, <NUM>, <NUM>, and <NUM> instead of a 64b CRC checker <NUM> to produce four 16b CRC outputs (CRC_16_OUT_0, CRC_16_OUT_1, CRC_16_OUT_2, and CRC_16_OUT_3) from flip-flops <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM>. Flip-flops <NUM> and <NUM> provide a 16b valid output (CRC_16_OUT_VAL), and four multiplexers (MUX) <NUM>, <NUM>, <NUM>, and <NUM> receive 64b data inputs. The BIST data is stored in a 64b linear feedback shift register (LFSR) <NUM> and the CRC bit patterns are stored in control registers <NUM>.

Referring now to <FIG>, <FIG>, and <FIG>, diagrams of a lockstep checker, an example circuit for the lockstep checker for two cores of a system on chip (SoC), and an example multiple input shift register (MISR) circuit, respectively, in accordance with one or more embodiments will be discussed. Similar to the arrangement of <FIG>, the lockstep checker <NUM> may be coupled with master core <NUM> and slave core <NUM> to provide a lockstep error output <NUM> to check that the two cores are operating in lockstep. Such a checking scheme may be extended to any two blocks operating in lockstep to be checked on a cycle boundary in an efficient manner. In order to ensure that both cores in the lockstep core SoC <NUM> are executing in parallel, the following constraints may be applied. First, checking should be done on a cycle basis. Second, since wires are a premium between cores, the lockstep checker <NUM> should consume as little wire tracks as possible. Third, the lockstep checker <NUM> should have the ability to be checked for faults. Fourth, a filter may be used to remove incomparable data from IDI or to drive known data when there is no data issued from the cores. Fifth, the lockstep checking scheme should have low probability of aliasing to ensure that errors are not masked. It should be noted that the above constraints are merely example properties of a lockstep checker and/or a lockstep checking scheme, and the scope of the claimed subjected matter is not limited in these respects.

In one or more embodiments, master core <NUM> may include one or more filters for command and control unit (C2U) buses. A filter is utilized to ensure that every cycle the output of the cores that are to be compared have consistent data. In some embodiments depending on the transaction, certain fields are don't care so the values may not be consistent between master core <NUM> and slave core <NUM>. In order to ensure consistency, for such don't care bits the filter drives a <NUM>, and when there is no valid bit the filter drives a <NUM>. Thus, consistency may be achieved with the filter by driving don't care bits to a zero value. In some embodiments the core outputs are not relevant depending upon the transaction being issued wherein it may be the case that the non-relevant outputs are inconsistent across the lock step pairs. Furthermore, checking may be performed every cycle and when there is no traffic from the cores known data may be used rather than stopping and restarting the checker only when there are valid transactions from the core.

For C2UReq, C2URsp, C2UData:
AND the valid bit with the payload towards HWL checker logic (making the bus going towards checker logic <NUM> if not valid).

A first embodiment of the lockstep checker <NUM> may operate as follows.

A second embodiment of the lockstep checker <NUM> as shown in detail in <FIG> may utilize less than ten wires between mater core <NUM> and slave core <NUM>. The C2Data, C2URequest and C2UResponse buses first go through a filter, filter <NUM>, filter <NUM>, and filter <NUM>, respectively, to ensure that every bit has a known value. In some embodiments depending on the transaction, certain fields are don't care so the values need not be consistent between master core <NUM> and slave core <NUM>. In the don't care bits the filter drives a <NUM>. When there is no valid bit the filter drives a <NUM>. The outputs of the filter drives into a series of multiple input shift registers (MISR's) (128b/64b) such as MISR <NUM>, MISR <NUM>, MISR <NUM>, MISR <NUM>, and MISR <NUM>. The most significant bit (MSB) of each of the MISRs of the master core <NUM> is fed to a comparator lockstep checker <NUM> to detect a mismatch with the MISR outputs of the slave core <NUM>. The slave core <NUM> mirrors the filters and MISRs of the master core <NUM> and provides the MSBs of each of the MISRs of the slave core <NUM> to the comparator lockstep checker <NUM>. When the cores are running at a higher frequency shifting out the 128b in the indicated Fault Detection Time Interval (FDTI), which typically is in the millisecond range, should be easily accomplished. The comparator lockstep checker <NUM> performs a single bit compare every cycle. The MISRs on both the master core <NUM> and the slave core <NUM> may be started simultaneously.

<FIG> shows an example circuit for the comparator lockstep checker <NUM>. As shown in <FIG>, the outputs from the MISRs of the master core <NUM> and the slave core <NUM> are XORd together through a series of XOR gates and provided as the lockstep checker <NUM> error output <NUM>. If the MISR outputs from both the master core <NUM> and the slave core <NUM> match, then the lockstep error output <NUM> will have a value of <NUM>. Otherwise, the value will be <NUM> which indicates an error or mismatch.

In one or more embodiments, for a test mode, a write may be broadcast from the Test Control Unit or Block (e.g., control registers <NUM>) to enable the lockstep checker <NUM>. As a test mode at key off, a known pattern could be driven into the filters, and the resulting signature could be checked. In such an arrangement, the wires to be shifted for comparison effectively may be reduced to two wires. Valid bits for C2U req, C2Udata and C2Ursp may be passed and compared in raw form.

In one or more embodiments, for debug cases a function to disable and to enable the lockstep checker <NUM> may be added, and a function to clear and restart the MISRs and the lockstep checker <NUM> also may be added, including the ability to reset and initialize the lockstep check from the Test Control Unit or Block. Upon a mismatch between the cores as determined by the lockstep checker, a micro break point may be triggered.

The control registers per lockstep checker may include the following:.

In order to test the lockstep checker <NUM>, a first test may be as follows.

Alternatively, a second test of the lockstep checker <NUM> may be as follows.

<FIG> shows the details of MISR <NUM> circuit used by master core <NUM> or slave core <NUM>, for example MISR <NUM>. The circuit of MISR <NUM> may comprise a series of XOR gates and D flip-flops connected as shown. For the MISR <NUM> circuits, the arrangement of <FIG> may be extended to have <NUM> inputs. The CRC <NUM> Polynomial as shown in Table <NUM>, above, may be used by the MISR circuit in a manner similar as a CRC checker.

Referring now to <FIG>, <FIG>, and <FIG>, diagrams of an alternative lockstep checker, an example circuit for the alternative lockstep checker, and a diagram of the lockstep checker with skid on the output in accordance with one or more embodiments will be discussed. The circuitry for lockstep checking of master core <NUM> and slave core <NUM> as shown in <FIG> is substantially similar to the circuitry as shown in <FIG> with the following changes. The master and slave cores each have a respective lockstep checker <NUM> having outputs provided to an OR gate <NUM> to provide lockstep error output <NUM>. The C2U inputs are provided to filters <NUM> and CRC checkers <NUM> instead of the MISRs of <FIG>. For testing, 64b LFSR test data may be provided to the filters <NUM> via multiplexers <NUM>, and the outputs of the filters <NUM> may be provided through AND gates to control each path via MASK signals. The outputs of each of the lockstep checkers <NUM> may provide test outputs of lockstep control registers <NUM> in each of the cores. <FIG> shows the circuitry for the lockstep checkers <NUM> wherein the outputs of the 64b CRC checkers <NUM> are passed through 64b XOR trees to provide each lockstep checker comparator output. Test multiplexers (MUXs) are provided for testing purposes.

<FIG> shows a lockstep checker with skid on the output. The lockstep checker <NUM> of <FIG> may be duplicated for data, request, and response inputs. The lockstep checker <NUM> may include a <NUM> deep delay first in first out (FIFO) buffer. The FIFO <NUM> may be 64b per entry via <NUM> entry buffer <NUM> if CRC checkers are used or <NUM> bit per entry if MISRs are used. The depth of FIFO <NUM> may be adjustable to accommodate skid. <FIG> shows a <NUM> cycle skid between the master core <NUM> and the slave core <NUM>. In addition, each of the master comparators and the slave comparators <NUM> include a valid request counter <NUM> (master) and a valid request counter <NUM> (slave) which may be a 5b counter incremented for every master request, or for every slave request, and reset when there is a match. The counters may signal a lockstep error when the counter overflows.

Referring now to <FIG>, a diagram of a lockstep checker deployed in a central processing unit in accordance with one or more embodiments will be discussed. As shown in <FIG>, a central processing unit (CPU) <NUM> or processor or system may include a mesh interconnect architecture comprising a mesh <NUM> to connect multiple cores in the CPU <NUM>. It should be noted that <FIG> does not include all of the elements of CPU <NUM> and is to illustrate the coupling of two or more cores <NUM> via a lockstep checker <NUM> in accordance with one or more embodiments as discussed herein, for example in an arrangement that is capable of being replicated multiple times across the mesh interconnect grid to provide a multi-core structure for CPU <NUM>. In the embodiment shown, each core tile in the grid may include a core <NUM>, a last-level cache/snoop filter (LLC/SF) <NUM>, a caching and home agent (CHA) <NUM>, and/or mid-level cache (MLC) <NUM>, although the scope of the claimed subject matter is not limited in these respects. Such a multicore mesh architecture of CPU <NUM> may comprise an Intel XEON processor or the like, although the scope of the claimed subject matter is not limited in this respect.

<FIG> illustrates a block diagram of a system on chip (SOC) package in accordance with an embodiment. As illustrated in <FIG>, SOC <NUM> includes one or more Central Processing Unit (CPU) cores <NUM>, one or more Graphics Processor Unit (GPU) cores <NUM>, an Input/Output (I/O) interface <NUM>, and a memory controller <NUM>. Various components of the SOC package <NUM> may be coupled to an interconnect or bus such as discussed herein with reference to the other figures. Also, the SOC package <NUM> may include more or less components, such as those discussed herein with reference to the other figures. Further, each component of the SOC package <NUM> may include one or more other components, e.g., as discussed with reference to the other figures herein. In one embodiment, SOC package <NUM> (and its components) is provided on one or more Integrated Circuit (IC) die, e.g., which are packaged into a single semiconductor device.

As illustrated in <FIG>, SOC package <NUM> is coupled to a memory <NUM> via the memory controller <NUM>. In an embodiment, the memory <NUM> (or a portion of it) can be integrated on the SOC package <NUM>.

The I/O interface <NUM> may be coupled to one or more I/O devices <NUM>, e.g., via an interconnect and/or bus such as discussed herein with reference to other figures. I/O device(s) <NUM> may include one or more of a keyboard, a mouse, a touchpad, a display, an image/video capture device (such as a camera or camcorder/video recorder), a touch screen, a speaker, or the like.

<FIG> is a block diagram of a processing system <NUM>, according to an embodiment. In various embodiments the system <NUM> includes one or more processors <NUM> and one or more graphics processors <NUM>, and may be a single processor desktop system, a multiprocessor workstation system, or a server system having a large number of processors <NUM> or processor cores <NUM>. In on embodiment, the system <NUM> is a processing platform incorporated within a system-on-a-chip (SoC or SOC) integrated circuit for use in mobile, handheld, or embedded devices.

An embodiment of system <NUM> can include, or be incorporated within a server-based gaming platform, a game console, including a game and media console, a mobile gaming console, a handheld game console, or an online game console. In some embodiments system <NUM> is a mobile phone, smart phone, tablet computing device or mobile Internet device. Data processing system <NUM> can also include, couple with, or be integrated within a wearable device, such as a smart watch wearable device, smart eyewear device, augmented reality device, or virtual reality device. In some embodiments, data processing system <NUM> is a television or set top box device having one or more processors <NUM> and a graphical interface generated by one or more graphics processors <NUM>.

In some embodiments, processor <NUM> is coupled to a processor bus <NUM> to transmit communication signals such as address, data, or control signals between processor <NUM> and other components in system <NUM>. In one embodiment the system <NUM> uses an exemplary "hub" system architecture, including a memory controller hub <NUM> and an Input Output (I/O) controller hub <NUM>. A memory controller hub <NUM> facilitates communication between a memory device and other components of system <NUM>, while an I/O Controller Hub (ICH) <NUM> provides connections to I/O devices via a local I/O bus. In one embodiment, the logic of the memory controller hub <NUM> is integrated within the processor.

Memory device <NUM> can be a dynamic random-access memory (DRAM) device, a static random-access memory (SRAM) device, flash memory device, phase-change memory device, or some other memory device having suitable performance to serve as process memory. In one embodiment the memory device <NUM> can operate as system memory for the system <NUM>, to store data <NUM> and instructions <NUM> for use when the one or more processors <NUM> executes an application or process. Memory controller hub <NUM> also couples with an optional external graphics processor <NUM>, which may communicate with the one or more graphics processors <NUM> in processors <NUM> to perform graphics and media operations.

In some embodiments, ICH <NUM> enables peripherals to connect to memory device <NUM> and processor <NUM> via a high-speed I/O bus. The I/O peripherals include, but are not limited to, an audio controller <NUM>, a firmware interface <NUM>, a wireless transceiver <NUM> (e.g., Wi-Fi, Bluetooth), a data storage device <NUM> (e.g., hard disk drive, flash memory, etc.), and a legacy I/O controller <NUM> for coupling legacy (e.g., Personal System <NUM> (PS/<NUM>)) devices to the system. One or more Universal Serial Bus (USB) controllers <NUM> connect input devices, such as keyboard and mouse <NUM> combinations. A network controller <NUM> may also couple to ICH <NUM>. In some embodiments, a high-performance network controller (not shown) couples to processor bus <NUM>. It will be appreciated that the system <NUM> shown is exemplary and not limiting, as other types of data processing systems that are differently configured may also be used. For example, the I/O controller hub <NUM> may be integrated within the one or more processor <NUM>, or the memory controller hub <NUM> and I/O controller hub <NUM> may be integrated into a discreet external graphics processor, such as the external graphics processor <NUM>.

<FIG> is a block diagram of an embodiment of a processor <NUM> having one or more processor cores 902A to 902N, an integrated memory controller <NUM>, and an integrated graphics processor <NUM>. Those elements of <FIG> having the same reference numbers (or names) as the elements of any other figure herein can operate or function in any manner similar to that described elsewhere herein but are not limited to such. Processor <NUM> can include additional cores up to and including additional core 902N represented by the dashed lined boxes. Each of processor cores 902A to 902N includes one or more internal cache units 904A to 904N. In some embodiments each processor core also has access to one or more shared cached units <NUM>.

The internal cache units 904A to 904N and shared cache units <NUM> represent a cache memory hierarchy within the processor <NUM>. The cache memory hierarchy may include at least one level of instruction and data cache within each processor core and one or more levels of shared mid-level cache, such as a Level <NUM> (L2), Level <NUM> (L3), Level <NUM> (L4), or other levels of cache, where the highest level of cache before external memory is classified as the LLC. In some embodiments, cache coherency logic maintains coherency between the various cache units <NUM> and 904A to 904N.

In some embodiments, processor <NUM> may also include a set of one or more bus controller units <NUM> and a system agent core <NUM>. The one or more bus controller units <NUM> manage a set of peripheral buses, such as one or more Peripheral Component Interconnect buses (e.g., PCI, PCI Express). System agent core <NUM> provides management functionality for the various processor components. In some embodiments, system agent core <NUM> includes one or more integrated memory controllers <NUM> to manage access to various external memory devices (not shown).

In some embodiments, one or more of the processor cores 902A to 902N include support for simultaneous multi-threading. In such embodiment, the system agent core <NUM> includes components for coordinating and operating cores 902A to 902N during multi-threaded processing. System agent core <NUM> may additionally include a power control unit (PCU), which includes logic and components to regulate the power state of processor cores 902A to 902N and graphics processor <NUM>.

In some embodiments, processor <NUM> additionally includes graphics processor <NUM> to execute graphics processing operations. In some embodiments, the graphics processor <NUM> couples with the set of shared cache units <NUM>, and the system agent core <NUM>, including the one or more integrated memory controllers <NUM>. In some embodiments, a display controller <NUM> is coupled with the graphics processor <NUM> to drive graphics processor output to one or more coupled displays. In some embodiments, display controller <NUM> may be a separate module coupled with the graphics processor via at least one interconnect, or may be integrated within the graphics processor <NUM> or system agent core <NUM>.

In some embodiments, a ring based interconnect unit <NUM> is used to couple the internal components of the processor <NUM>. However, an alternative interconnect unit may be used, such as a point-to-point interconnect, a switched interconnect, or other techniques, including techniques well known in the art. In some embodiments, graphics processor <NUM> couples with the ring interconnect <NUM> via an I/O link <NUM>.

The exemplary I/O link <NUM> represents at least one of multiple varieties of I/O interconnects, including an on package I/O interconnect which facilitates communication between various processor components and a high-performance embedded memory module <NUM>, such as an eDRAM (or embedded DRAM) module. In some embodiments, each of the processor cores <NUM> to 902N and graphics processor <NUM> use embedded memory modules <NUM> as a shared Last Level Cache.

In some embodiments, processor cores 902A to 902N are homogenous cores executing the same instruction set architecture. In another embodiment, processor cores 902A to 902N are heterogeneous in terms of instruction set architecture (ISA), where one or more of processor cores 902A to 902N execute a first instruction set, while at least one of the other cores executes a subset of the first instruction set or a different instruction set. In one embodiment processor cores 902A to 902N are heterogeneous in terms of microarchitecture, where one or more cores having a relatively higher power consumption couple with one or more power cores having a lower power consumption. Additionally, processor <NUM> can be implemented on one or more chips or as an SoC integrated circuit having the illustrated components, in addition to other components.

In various embodiments, the operations discussed herein, e.g., with reference to the figures described herein, may be implemented as hardware (e.g., logic circuitry), software, firmware, or combinations thereof, which may be provided as a computer program product, e.g., including a tangible (e.g., non-transitory) machine-readable or computer-readable medium having stored thereon instructions (or software procedures) used to program a computer to perform a process discussed herein. The machine-readable medium may include a storage device such as those discussed with respect to the present figures.

Additionally, such computer-readable media may be downloaded as a computer program product, wherein the program may be transferred from a remote computer (e.g., a server) to a requesting computer (e.g., a client) by way of data signals provided in a carrier wave or other propagation medium via a communication link (e.g., a bus, a modem, or a network connection).

Reference in the specification to "one embodiment" or "an embodiment" means that a particular feature, structure, and/or characteristic described in connection with the embodiment may be included in at least an implementation. The appearances of the phrase "in one embodiment" in various places in the specification may or may not be all referring to the same embodiment.

Also, in the description and claims, the terms "coupled" and "connected," along with their derivatives, may be used. In some embodiments, "connected" may be used to indicate that two or more elements are in direct physical or electrical contact with each other. "Coupled" may mean that two or more elements are in direct physical or electrical contact. However, "coupled" may also mean that two or more elements may not be in direct contact with each other, but may still cooperate or interact with each other.

Claim 1:
A method to check for redundancy in two or more data lines of two cores of a multicore System on Chip (SoC), the two cores operating in lockstep and including a master core and a slave core, the method comprising:
receiving data on a first data line of the two cores;
computing a first cyclic redundancy check (CRC) value on the data of the first data line;
performing an exclusive OR (XOR) function on the first CRC value with a stored memory value; and
updating the stored memory value with a result of the XOR function;
wherein said receiving, computing, performing, and updating is performed on additional data lines of the two cores until a last line is processed such that an error is indicated if a final stored memory value is not zero, wherein the two or more data lines comprise cache lines including a master cache line of the master core and a slave cache line of the slave core.