Patent Publication Number: US-2019179721-A1

Title: Utilizing non-volatile phase change memory in offline status and error debugging methodologies

Description:
BACKGROUND 
     Faulty Printed Circuit Boards (PCBs) populated with various types of electrical components arrive at development labs from various locations for error analysis. When an error occurs on a PCB, the voltage regulator on the PCB outputs a fault associated with the error. The fault may be stored in memory to allow engineers to analyze the faulty circuits or systems on the PCBs, The PCBs arrive from various locations that were operated with various firmware versions and/or system configurations that cannot be identified without powering the PCB. However, powering a PCB with incorrect firmware and/or system configurations can lead to additional damage that prevents diagnosis of the error that originally occurred. Additionally, catastrophic errors may shut down a PCB before the PCB can store the fault associated with the catastrophic error into memory. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIGS. 1A, 1B, 10, and 1D  are block diagrams of example memristor system to collect fault data and/or status data corresponding to an example integrated circuit in accordance with the present disclosure. 
         FIG. 2  is a block diagram of an example memristor controller of  FIGS. 1A-1D  to control the example memristor system of  FIGS. 1A-1D . 
         FIGS. 3 and 4  are flowcharts representative of machine readable instructions that may be executed by the example memristor controller of  FIGS. 1A-1D and 2  to operate the example memristor system of  FIGS. 1A-1D . 
         FIG. 5  is a processor platform to execute the instructions of  FIGS. 3 and 4  to implement the example memristor controller of  FIGS. 1A-1D and 2 . 
     
    
    
     The figures are not to scale. Wherever possible, the same reference numbers will be used throughout the drawing(s) and accompanying written description to refer to the same or like parts. 
     DETAILED DESCRIPTION 
     Non-volatile phase change memory elements (e.g. memristors) have numerous advantages in electrical designs. Memristors are semiconductive devices that have variable resistance. The resistance of a memristor can be changed and/or read by applying various voltages for various amounts of time. Accordingly, a memristor can be implemented as a memory bit. In such an example, applying a first voltage for a first duration of time changes the resistance of the memristor to a low resistance to act like a closed switch. Additionally, applying a second voltage for a second duration of time changes the resistance of the memristor to a high resistance to act like an open switch. The amount of resistance can be equated to a binary value (e.g., like a bit cell) in memory. Small blocks of memristors are able to store data faster than conventional memory. Additionally, stored values in memristors can be determined by measuring the resistance of the memristors. Accordingly, a user can probe memristors externally with a probe to determine data stored in the memristors (e.g., via an oscilloscope) without actually powering up the memristors and/or a processor associated with the memristors. 
     Examples disclosed herein utilize the properties of memristors to perform status and/or error logging associated with an integrated circuit (IC). Status logging includes determining the status of a system (e.g., status data) associated with the integrated circuit. The status data may include a firmware being utilized by the system, system configurations, operating temperature, ambient temperature, software status, identifiers associated with the integrated circuit and/or a device in communication with the integrated circuit, etc. Error logging includes determining fault data related to an error associated with the integrated circuit. When an error occurs, a voltage regulator down may output fault data to a programmable logic device, an integrated lights out device, and/or a memristor system. As further described herein, the fault data may be minimal or may be more detailed depending on how the memristor system is attached to the integrated circuit. 
     Conventional techniques for storing fault data and/or status data include storing the data into an active health negative-and (NAND) memory, Electrically Erasable Programmable Read-Only Memory (EEPROM), and/or Read-Only Memory (ROM). However, such conventional techniques require a large amount of space. Additionally, active health NAND memory, EEPROM, and/or ROM cannot be read externally (e.g., via a probe). Therefore, an engineer needs to power a circuits and/or systems on a PCB associated with the memory to determine the stored data. However, powering the circuits and/or systems PCB with incorrect system configurations and/or firmware may lead to additional damage that prevents diagnosis of the error that originally occurred. Additionally, such conventional techniques are slower than examples disclosed herein. Catastrophic errors cause all and/or some of the components of the PCB and memory to shut down immediately. Thus, such conventional techniques are not fast enough to log (e.g., store) a fault associated with the catastrophic error. 
     Examples described herein communicatively coupe memristors to an integrated circuit to store fault data and/or status data associated with the integrated circuit. Memristors store data much faster than traditional memory. Thus, a fault associated with a catastrophic error can be detected and shared before a catastrophic error shuts-down the components of the PCB. Additionally, data stored in memristors can be read by determining the resistance of the memristors. Therefore, an engineer can determine system configurations, firmware versions, fault data, etc. corresponding to the PCB by probing the memristors externally with a probe without powering up the components of the PCB. In this manner, an engineer can power the PCB with the correct system configurations, options, riser cards, mated system boards, firmware, etc. to prevent further damage. Additionally, components on a PCB can re-boot with correct system configurations, firmware version, etc. when the components are activated/re-activated. 
       FIGS. 1A, 1B, 10, and 1D  are four example block diagrams  110 ,  120 ,  130 ,  140  of different circuit configurations using a memristor system to collect fault data and/or status data. The example block diagrams include an example IC  100 , an example converter  101 , an example programmable logic device  102 , an example Integrated Lights-Out device (iLO)  104 , an example memristor system  106 , an example memristor controller  107 , and an example memristor array  108 . 
     The example IC  100  is semiconductor device including a set of electrical components (e.g., resistors, capacitors, inductors, transistors, etc.). The example IC  100  may be part of a bigger IC and/or in communication with other ICs. For example, the example IC  100  may be part of and/or connected to an Ethernet motherboard, a central processing unit, memory, a server, a processor, a controller, etc. The example integrated circuit  100  includes the example converter  101  to receive a first signal (e.g., first voltage) and output a second signal (e.g. a second voltage). In some examples, the integrated circuit  100  includes and/or is coupled to a processor to output the first signal to the example converter  101  (e.g., when an error occurs and/or to transmit status data). In  FIGS. 1A, 1B, 1C, and 1D , the example converter  101  is a voltage regulator. Alternatively, the example converter  101  may be a linear regulator, a multiple-phase regulator, a magnetic converter, an alternating current to direct current (AC-DC) converter (e.g., a rectifier, a mains power supply unit, a switched-mode power supply, etc.), an AC-AC converter (e.g., a transformer, an autotransformer, a voltage converter, a voltage regulator, a cycloconverter, a variable-frequency transformer, etc.), a DC to AC converter (e.g. an inverter), and/or any other device that can convert a first voltage to a second voltage. When the example IC  100  experiences an error, the example converter  101  outputs fault data to an external device (e.g., the programmable logic device  102  and/or the example memristor system  106 ) via a bus. The bus includes multiple rails to communicate various data to any one of the example programmable logic device  102 , the example iLO  104 , and/or the example memristor system  106 . The fault data output by the example converter  101  is  1  bit or a small number of bits. The fault data output by the example converter  101  is minimal to quickly inform the example programmable logic device  102 , the example iLO  104 , and/or the example memristor system  106  that the example converter  101  and/or integrated circuit  100  is faulting. 
     The example programmable logic device  102  receives the minimal fault data from the example converter  101  and outputs the minimal fault data and more detailed fault data. Additionally, once the minimal fault data is received by the example programmable logic device  102 , the programmable logic device  102  communicates with the example IC  100  to get additional information about the failure. For example, the additional information may include data related to a type of error that occurred, which part of the IC  100  caused the error, which rail is turning off due to the error, a status of other rails in the bus, and/or whether or not turning off the rail caused the IC  100  to continue operating without a reboot. In some examples, the example programmable logic device  102  includes ambient temperature sensors. In such examples, the example programmable logic device  102  includes the ambient temperature sensed by the sensors in the more detailed fault data, In some examples, the example programmable logic device  102  is a complex programmable logic device (CPLD) including logic implementing disjunctive normal form expressions and/or more specialized logic operations, Alternatively, the example programmable logic device  102  may be a programmable logic array, a programmable array logic device, a generic array logic device, a field-programmable gate array, and/or any other type of programmable logic device. The example programmable logic device  102  outputs the more detailed fault data to the example iLO  104  and/or the example memristor system  106 . 
     The example iLO  104  is a remote server management processor to control and/or monitor status of the example integrated circuit  100  from a remote location. The example iLO  104  timestamps the error when the more detailed fault data is received, In some examples, the example iLO  104  communicates with a basic input/output system (BIOS) and/or unified extensible firmware interface (UEFI) associated with the example IC  100 , Communicating with the BIOS and the UEFI allows the example iLO  104  to determine various status data such as system status (e.g., booting, running, idle), a current checkpoint state of the BIOS, stress load of the system, etc. In some examples, the iLO  104  includes a network connection and/or Internet Protocol (IP) address to connect to other management networks. In some examples, the iLO  104  includes a remote web-based console to communicate with the example integrated circuit  100  remotely. Using the remote web-based console, a user can operate features including setup, configuration, remote power on and/or off, secure socket layer security, detailed status (e.g., server status), virtual indicators, and/or diagnostics. In some examples, the iLO  104  outputs a most detailed fault data by outputting the more detailed fault data from the example programmable logic device  102  along with a timestamp, state of the system (e.g., BIOS checkpoints), data related wo whether and/or how long the system was booted up for, the stress load of the system, etc. In some examples, the example programmable logic device  102  and the example iLO  104  may be combined into one device performing the functionalities of both devices. 
     The example memristor system  106  includes the example memristor controller  107  and the example memristor array  108 . In some examples, the memristor system  106  is a separate device (e.g., PCB) attached at least one of the example IC  100 , the example programmable logic device  102 , and/or the example iLO  104 . Alternatively, the example memristor system  106  may be embedded in at least one of the example IC  100 , the example programmable logic device  102 , and/or the example iLO  104 . In  FIG. 1A , the example memristor system  106  is attached (e.g., coupled) to the example iLO  104 . In  FIG. 1B , the memristor system  106  is attached to the example programmable logic device  102 . In  FIG. 1C , the example memristor system  106  is attached to the example IC  100 . In  FIG. 1D , the example memristor system  106  is attached to the example IC  100 , the example programmable logic device  102 , and the example iLO  104 . Alternatively, the example  FIG. 1D , may include two or more memristor systems  106  (e.g., one attached to the example IC  100 , one attached to the example programmable logic device  102 , and one attached to the example iLO  104 ). Alternatively, the example Memristor system  106  may be embedded in any of the example Integrated circuit  100 , the example programmable logic device  102 , and/or the example iLO  104 . 
     The example memristor controller  107  receives fault data and/or status data from the example converter  101 . In some examples, the example memristor controller  107  communicates (e.g., periodically or aperiodically) with the example IC  100 , the example programmable logic device  102 , and/or the example iLO  104  to determine status data of the example IC  100 . The status data may include system configurations, options, riser card identifiers, mated system board identifiers, firmware identifiers, software identifiers, an IC identifier, an operating temperature, an ambient temperature, a timestamp, and/or any other data related to the example IC  100 . In some examples, the example memristor controller  107  polls an input associated with the example converter  101  to identify (e.g., detect) a fault output by the example converter  100  associated with the example IC  100 . The example memristor controller  107  stores the fault data and/or status data in the example memristor array  108 . Additionally, the example memristor controller  107  may read the stored status data from the example memory array  108 . For example, if the example IC  100  needs to be rebooted (e.g. restarted), the example memristor controller  107  may read the status data in the example memory array  108  to determine IC system configurations, options, a riser car identifier, a mated system board identifier, and/or firmware version installed on the example IC  100 . In such an example, the memristor controller  107  may transmit the system configurations and/or firmware version to the example IC  100  prior to and/or after the reboot. Transmitting the correct firmware various allows the example IC  100  to reboot without causing further damage associated with rebooting with incorrect configurations. 
     The example memristor array  108  is an array of non-volatile phase change memory elements (e.g. memristors). The example memristor array  108  may include any number of memristors. The memristors in the memristor array  108  are resistive elements created from a thin doped semiconductor film with variable resistance. As voltage is applied to a memristor, the doping of the semiconductor film changes. As the doping changes, the resistance associated with the memristor changes. For example, a memristor may be doped. The doped memristor has a low resistance (e.g., 100 Ohms) and operates like a closed switch. In such an example, the low resistance of the memristor may be associated with a binary value of “1” to indicate “ON.” If a high voltage is applied to the doped memristor for a sufficient duration of time, the dopants drift to cause the memristor to act like undoped semiconductor material. The “undoped” memristor has a high resistance (e.g., 1 megaOhm) and operates like an open switch. In such an example, the high resistance of the memristor may be associated with a binary value of “0” to indicate “ON,” In some examples, the amount of resistance can be associated with an analog value. In such example the example memristor controller  107  outputs a particular voltage for a particular amount of time to change the resistance of a memristor to a particular resistance. The particular resistance can later be read and associated with the stored data (e.g., based on the resistance). As previously described, the resistance is non-volatile. Thus, stored values in memristors can be determined after power is lost and without providing power to any other device. For example, a user can read the stored data by probing the example memristor array  108  without powering the example IC  100  (e.g., via an oscilloscope). 
     In  FIG. 1A , the example memristor system  106  is attached to the example iLO  104 . In operation, when an error associated with the example IC  100  and/or the example converter  101  occurs, fault data is transmitted to the example programmable logic device  102  via the example converter  101 . The fault data may identify that the error occurred. The example programmable logic device  102  receives the minimal fault data and transmits the minimal fault data to the example iLO  104 . Additionally, the example programmable logic device  102  communicates with the example IC  100  to determine additional fault data. As described above, the additional fault data may identify the type of error, the location of the error, a faulty component in the example IC  100 , an ambient temperature, and/or any data associated with the error. The example programmable logic device  102  outputs the minimal fault data and the additional data (e.g., the more detailed fault data) to the example iLO  104 . The example iLO  104  processes the more detailed fault data. In some examples, the iLO  104  updates the more detailed fault data with a timestamp, system data, a stress load, a state of the system, BIOS checkpoints, etc. to create the most detailed fault data. Additionally, the example iLO  104  transmits status data to the example memristor system  106 . The example iLO  104  transmits the most detailed fault data the status data to the example memristor system  106 . In some examples, the iLO  104  transmits status updates periodically and/or when the status of the example IC  100  has changed (e.g. updated). In some examples, the example memristor controller  107  communicates the example iLO  104  to request status data associated with the IC  100 . The example memristor controller  107  of the example memristor system  106  stores the fault data, the timestamp, and/or the status data in the example memristor array  108 . In some examples, the example memristor controller  107  transmits the status data in the memristor array  108  to the example iLO  104 , as further described in  FIG. 4 . 
     In  FIG. 113 , the example memristor system  106  is attached directly to the example programmable logic device  102 . In operation, when an error associated with the example IC  100  occurs, the minimal fault data is transmitted to the example programmable logic device  102  via the example converter  101 . As previously described, the example programmable logic device  102  receives the minimal fault data and communicates with the example integrated circuit  100  to determine additional data. The example programmable logic device  102  combines the minimal fault data with the additional data (e.g., to create more detailed fault data) and transmits the more detailed fault data to the example memristor system  106 . Additionally, the example programmable logic device  102  may transmit status data related to the IC  100  to the memristor system  106 . The example memristor controller  107  of the example memristor system  106  stores the fault data and/or the status data in the example memristor array  108 . In some examples, the example memristor controller  107  transmits the status data in the memristor array  108  to the example programmable logic device  102 , as further described in  FIG. 4 . 
     In  FIG. 1C , the example memristor system  106  is attached directly to the example integrated circuit  100 . In operation, when an error associated with the example IC  100  occurs, the minimal fault data is transmitted to the example memristor system  106  via the example converter  101 . Additionally, the example IC  100  may transmit status data related to the IC  100  to the memristor system  106 . The example memristor controller  107  of the example memristor system  106  stores the fault data and/or the status data in the example memristor array  108 . In some examples, the example memristor controller  107  transmits the status data in the memristor array  108  to the example IC  100 , as further described in  FIG. 4 . 
     In  FIG. 1D , the example memristor system  106  is directly attached to the example IC  100 , the example programmable logic device  102 , and the example iLO  104 . Alternatively, any combination of the example IC  100 , the example programmable logic device  102 , and the example iLO  104  may be connected to the example memristor system  106 . In some examples, the example of  FIG. 1C  may include two or three memristor systems  106 , a first memristor system  106  directly attached to the IC  100 , a second memristor system  106  directly attached to the example programmable logic device  102 , and a third memristor system  106  directly attached to the example iLO  104 . The example memristor system  106  of  FIG. 10  is attached to the example IC  100 . Thus, the example programmable logic device  102 , and the example iLO  104 , the example memristor controller  107  will receive and store minimal fault data (e.g., from the IC  100 ), the more detailed fault data (e.g., from the example programmable logic device  102 ), and the most detailed fault data (e.g. from the iLO  104 ) into the example memristor array  100 . Additionally, status data may be transmitted to the example memristor system  106  periodically, when the status has updated, and/or based on a request from the example memristor controller  107 . In some examples, the example memristor controller  107  transmits the status data in the memristor array  108  to the example IC  100 , the example programmable logic device  102 , and/or the example iLO  104 , as further described in  FIG. 4 . 
     The example block diagram  110  of  FIG. 1A  stores status data and the most detailed fault data transmitted by the example iLO  104  in the example memristor array  108 . The example block diagram  120  of  FIG. 1B  stores status data and the more detailed fault data transmitted by the example programmable logic device  102 . The example block diagram  130  of  FIG. 10  stores status data and the minimal detailed fault data transmitted by the example IC  100  via the example converter  101 . As described above, the most detailed fault data from the example iLO  104  contains more detailed fault information than the minimal fault data (e.g., from the example IC  100  in the example block diagram  130  of FIG. C) or the more detailed fault data (e.g., from the example programmable logic device  102  in the example block diagram  120  of  FIG. 1B ). However, the example block diagram  110  of  FIG. 1A  takes the most amount of time to receive and store the most detailed fault data, the example block diagram  120  of  FIG. 1B  takes the second most amount of time to receive and store the more detailed fault data, and the example block diagram  130  of  FIG. 10  takes the least amount of time to receive and store the minimal fault data. Accordingly, the example block diagrams  110 ,  120  may be unable to store fault data associated with a catastrophic error (CATERR). CATERRs are sudden total failures of the example IC  100  where recovery is impossible and the IC  100  immediately shuts down. When a CATERR occurs, all devices (e.g., the example IC  100 , the example programmable logic device  102 , the example iLO  104 , and the example memristor system  106 ) are shut down. In some examples, a fault associated with the CATERR output by the example converter  101  may not be stored in the example memristor array  108  prior to the shutdown. In such an example, the block diagram  130  of  FIG. 1C  is able to store the fault associated with the CATERR into the memristor array  108  prior to being shut down. However, the stored fault data (e.g., the minimal fault data) may not include additional data (e.g., operating temperature, a timestamp, etc.) associated with the more detailed fault data and/or the most detailed fault data that would be stored in the example block diagrams  110 ,  120 . 
     The example block diagram  140  of  FIG. 1D  is able to receive and store the minimal fault data (e.g., via the example IC  100 ), the more detailed fault data (e.g., via the example programmable logic device  102 ), and the most detailed fault data (e.g., via the example iLO  104 ) at the expense of additional cost, space, and complexity. For example, the example block diagram  140  needs a larger example memristor array  108 , additional cabling (e.g., buses), and/or additional memristor systems  106  to store the fault data associated with the example block diagram  140  of  FIG. 1D . Additionally, due to space requirements, it may be difficult and/or impossible to implement the example memristor system  106 , and thus any one of the other example block diagrams  110 ,  120 ,  130  may be used. 
       FIG. 2  is a block diagram of the example memristor controller  107  of  FIGS. 1A-1D . The example memristor controller  107  includes an example receiver  200 , an example transmitter  202 , an example fault detector  204 , and an example status determiner  206 . 
     The example receiver  200  receives fault data and/or status data from the example IC  100 , the example programmable logic device  102 , and/or the example iLO  104 . In some examples, the example receiver  200  may receive stored data from the example memristor array  108 . The example receiver  200  transmits the received data to the example transmitter  202 , the example fault detector  204 , and/or the example status determiner  206  for further processing. 
     The example transmitter  202  transmits a write signal or a plurality of write signals to store received fault data and/or status data into the example memory array  108  of  FIGS. 1A-1D . The write signal is a voltage signal that is transmitted to particular memristors in the example memristor array  208 . As previously described, a memristor can be programmed as ON by applying a first voltage to the memristor or programmed as OFF by applying a second voltage to the memristor. When either the first voltage or the second voltage is applied, the resistance changes to a low resistance or a high resistance which can later be read by applying a third voltage (e.g., a read signal) to the memristor. In some examples, the transmitter  202  transmits signals (e.g., status update signals) with the example IC  100 , the example programmable logic device  102 , and/or the example iLO  104  of  FIGS. 1A and 1D  to determine the status of the example IC  100 . Additionally, the example transmitter  202  may transmit stored status data from the example IC  100  prior to and/or after a reboot. 
     The example fault detector  204  processes data received via the example receiver  200  to determine if fault data has been received by the example receiver  200 . The example receiver  200  may receive fault data and/or status data. Thus, the example fault detector  204  may sort through received data to determine if the received data is fault data and/or status data. If the example fault detector  204  determines that the received data is associated with an error (e.g., the received data is fault data), the fault detector  204  generates a write signal to store the fault data into the example memristor array  108 . If the received data is associated with the IC status, the status determiner  206  processes the received data. 
     The example status determiner  206  processes received signals to determine how to store the received signals into the example memristor array  206 . In some examples, the example status determiner  206  generates a write signal to store the received fault data and/or status data into the example memristor array  208  via the example transmitter  202 . In some examples, the example status determiner  206  may analyze the stored status data to generate signal identifying a last known firmware and/or other data based on the stored status data. In such an example, the example transmitter  202  may transmit the generated signal to the example IC  100  (e.g., for a re-boot). 
     While example manners of implementing the example memristor controller  107  of  FIGS. 1A-1D  are illustrated in  FIG. 2 , elements, processes and/or devices illustrated in  FIG. 2  may be combined, divided, re-arranged, omitted, eliminated and/or implemented in any other way. Further, the example receiver  200 , the example transmitter  202 , the example fault detector  204 , the example status determiner  206 , and/or, more generally, the example memristor controller  107  of  FIG. 2 , may be implemented by hardware, machine readable instructions, software, firmware and/or any combination of hardware, machine readable instructions, software and/or firmware. Thus, for example, any of the example receiver  200 , the example transmitter  202 , the example fault detector  204 , the example status determiner  206 , and/or, more generally, the example distance memristor controller  107  of  FIG. 2  could be implemented by analog and/or digital circuit(s), logic circuit(s), programmable processor(s), application specific integrated circuit(s) (ASIC(s)), programmable logic device(s) (PLD(s)) and/or field programmable logic device(s) (FPLD(s)). When reading any of the apparatus or system claims of this patent to cover a purely software and/or firmware implementation, at least one of the example receiver  200 , the example transmitter  202 , the example fault detector  204 , the example status determiner  206 , and/or, more generally, the example memristor controller  107  of  FIG. 2  is/are hereby expressly defined to include a tangible computer readable storage device or storage disk such as a memory, a digital versatile disk (DVD), a compact disk (CD), a Blu-ray disk, etc. storing the software and/or firmware, Further still, the example memristor controller  107  of  FIG. 2  includes elements, processes and/or devices in addition to, or instead of, those illustrated in  FIG. 2 , and/or may include more than one of any or all of the illustrated elements, processes and devices. 
     Flowcharts representative of example machine readable instructions for implementing the example memristor controller  107  of  FIG. 2  is shown in  FIGS. 3 and 4 . In the example, the machine readable instructions comprise a program for execution by a processor such as the processor  512  shown in the example processor platform  500  discussed below in connection with  FIG. 5 . The program may be embodied in machine readable instructions stored on a tangible computer readable storage medium such as a CD-ROM, a floppy disk, a hard drive, a digital versatile disk (DVD), a Blu-ray disk, or a memory associated with the processor  512 , but the entire program and/or parts thereof could alternatively be executed by a device other than the processor  512  and/or embodied in firmware or dedicated hardware. Further, although the example programs are described with reference to the flowcharts illustrated in  FIGS. 4 , many other methods of implementing the example memristor controller  107  of  FIG. 2  may alternatively be used. For example, the order of execution of the blocks may be changed, and/or some of the blocks described may be changed, eliminated, or combined. 
     As mentioned above, the example processes of  FIGS. 3 and 4  may be implemented using coded instructions (e.g., computer and/or machine readable instructions) stored on a tangible computer readable storage medium such as a hard disk drive, a flash memory, a read-only memory (ROM), a compact disk (CD), a digital versatile disk (DVD), a cache, a random-access memory (RAM) and/or any other storage device or storage disk in which information is stored for any duration (e.g., for extended time periods, permanently, for brief instances, for temporarily buffering, and/or for caching of the information). As used herein, the term tangible computer readable storage medium is expressly defined to include any type of computer readable storage device and/or storage disk and to exclude propagating signals and to exclude transmission media. As used herein, “tangible computer readable storage medium” and “tangible machine readable storage medium” are used interchangeably. Additionally or alternatively, the example processes of FIGS,  3  and  4  may be implemented using coded instructions (e.g., computer and/or machine readable instructions) stored on a non-transitory computer and/or machine readable medium such as a hard disk drive, a flash memory, a read-only memory, a compact disk, a digital versatile disk, a cache, a random-access memory and/or any other storage device or storage disk in which information is stored for any duration (e.g., for extended time periods, permanently, for brief instances, for temporarily buffering, and/or for caching of the information). As used herein, the term non-transitory computer readable medium is expressly defined to include any type of computer readable storage device and/or storage disk and to exclude propagating signals and to exclude transmission media. As used herein, when the phrase “at least” is used as the transition term in a preamble of a claim, it is open-ended in the same manner as the term “comprising” is open ended. 
       FIG. 3  is an example flowchart  300  representative of example machine readable instructions that may be executed by the example memristor controller  107  of  FIG. 2  to store fault data and/or status data in the example memristor array  108  of  FIGS. 1A-1D . 
     At block  302 , the example receiver  200  receives status data associated with the example IC  100  of  FIGS. 1A-1D . As previously described, the status data includes system configurations, options, a riser card identifier, a mated system board identifier, a firmware identifier, a software identifier, an IC identifier, an operating temperature, an ambient temperature, a timestamp, and/or any other data related to the example IC  100 . At block  304 , the example status determiner  206  determines that the received data is status data and generates a write signal to store the received status data into the memristor array  108 . The write signal is a voltage and/or series of voltages that, when applied to the example memristor array  108 , store the status data into the memristor array  108 . At block  306  the example transmitter  202  transmits the write signal to the memristor array  108  to store the status data into the memristor array  108 . 
     At block  308 , the status determiner  206  determines if the status data associated with the IC  100  has been updated. In some examples, the status determiner  206  sends requests via the example transmitter  202  to the example IC  100 , the example programmable logic device  102 , and/or the example iLO  104  to send updated status data. Once the example transmitter  202  receives the updated status data, the example status determiner  206  compares the updated status data with the stored status data to determine if the status data has been updated. In some examples, the IC  100 , the example programmable logic device  102 , and/or the example iLO  104  may send IC status data only when the example IC  100  has been updated (e.g., based on system configurations, a firmware version, a software version, etc.). In such an example, the status determiner  206  determines that the integrated circuit status data has been updated whenever the example receiver  200  receives additional status data. 
     If the example status determiner  206  determines that the IC status data has been updated, the example status determiner  206  transmits a write signal via the example transmitter  202  to update the example memristor array  108  based on the updated IC status data. If the example status determiner  206  determines that the IC status data has not been updated, the example fault detector  204  determines if a fault has been detected (block  310 ). As previously described, the fault detector  204  may determine a fault has been detected when fault data is received by the example receiver  200 . If fault data has not been detected, the status determiner  206  continues to determine if the IC status data has been updated. If a fault has been detected, the example fault detector  204  generates a write signal to transmit to the example memristor array  108  via the example transmitter  202  to write the fault data into the example memristor array  108  (block  312 ). In some examples, if the error associated with the fault does not cause the system to shut down, the process may return to continue to check the IC status data has been updated and/or if additional faults are received by the example receiver  200 . 
       FIG. 4  is an example flowchart  400  representative of example machine readable instructions that may be executed by the example memristor controller  107  of  FIG. 2  to read and transmit stored fault data and/or status data in the example memristor array  108  of  FIGS. 1A-1D . In some examples, the instructions of the example flowchart  400  are initiated based on power-up/re-boot. In some examples, the instructions of the example flowchart  400  are initiated when the example receiver  200  receives a status request from the example IC  100 , the example programmable logic device  102 , and/or the example iLO  104 . 
     At block  402 , the example transmitter  202  transmits a read signal to the example memristor array  108  to determine values stored in the example memristor array  108 . The status determiner  206  receives the values from the example memristor array  108  and determines the stored IC status data based on the received values (block  404 ). For example, the example status determiner  206  may determine system configuration of the example IC  100 , last ran firmware version on the example IC  100 , etc. The example status determiner  206  generates a signal to send the example IC  100 , the example programmable logic device  102 , and/or the example iLO  104  based on the determined status data. 
     At block  406 , the example transmitter 202  transmits the status data to the example IC  100 , the example programmable logic device  102 , and/or the example iLO  104 . As previously described, the example IC  100  may initialize (e.g., re-boot) based on the received status data. For example, the IC  100  may initialize with firmware associated with and/or compatible with the firmware identified in the received status data. Additionally or alternatively, the example IC  100  may initialize with system configuration corresponding to the system configurations associated with the status data. 
       FIG. 5  is a block diagram of an example processor platform  500  capable of executing the instructions of  FIGS. 3 and 4  to implement the memristor controller  107  of  FIGS. 1A-1D and 2 . The processor platform  500  can be, for example, a server, a personal computer, a mobile device (e.g., a cell phone, a smart phone, a tablet such as an iPad™), a personal digital assistant (FDA), an Internet appliance, or any other type of computing device. 
     The processor platform  500  of the illustrated example includes a processor  512 . The processor  512  of the illustrated example is hardware. For example, the processor  512  can be implemented by one or more integrated circuits, logic circuits, microprocessors or controllers from any desired family or manufacturer. 
     The processor  512  of the illustrated example includes a local memory  513  (e.g., a cache). The processor  512  executes the instructions of  FIGS. 3 and 4  to implement the example receiver  200 , the example transmitter  202 , the example fault detector  204 , and the example status determiner  206  to implement the example memristor controller  107 . The processor  512  of the illustrated example is in communication with a main memory including a random access memory  514  and a read only memory  516  via a bus  518 . The random access memory  514  may be implemented by Synchronous Dynamic Random Access Memory (SDRAM), Dynamic Random Access Memory (DRAM), RAMBUS Dynamic Random Access Memory (RDRAM) and/or any other type of random access memory device. The read only memory  516  may be implemented by flash memory and/or any other desired type of memory device. Access to the main memory  514 ,  516  is controlled by a memory and/or clock controller. 
     The processor platform  500  of the illustrated example also includes an interface circuit  520 . The interface circuit  520  may be implemented by any type of interface standard, such as an Ethernet interface, a universal serial bus (USB), and/or a PCI express interface. 
     In the illustrated example, one or more input devices  522  are connected to the interface circuit  520 . The input device(s)  522  permit(s) a user to enter data and commands into the processor  512 . The input device(s) can be implemented by, for example, an audio sensor, a microphone, a keyboard, a button, a light emitting diode (LED), a mouse, a touchscreen, a track-pad, a trackball, isopoint and/or a voice recognition system. 
     One or more output devices  524  are also connected to the interface circuit  520  of the illustrated example. The output devices  524  can be implemented, for example, by display devices (e.g., a light emitting diode (LED), an organic light emitting diode (OLED), a liquid crystal display, a cathode ray tube display (CRT), a touchscreen, a tactile output device, a light emitting diode (LED) and/or speakers). The interface circuit  520  of the illustrated example, thus, typically includes a graphics driver card, a graphics driver chip or a graphics driver processor. 
     The interface circuit  520  of the illustrated example also includes a communication device such as a transmitter, a receiver, a transceiver, a modem and/or network interface card to facilitate exchange of data with external machines (e.g., computing devices of any kind) via a network  526  (e.g., an Ethernet connection, a digital subscriber line (DSL), a telephone line, coaxial cable, a cellular telephone system, etc.). 
     The processor platform  500  of the illustrated example also includes one or more mass storage devices  528  for storing software and/or data. Examples of such mass storage devices  528  include floppy disk drives, hard drive disks, compact disk drives, Blu-ray disk drives, RAID systems, and digital versatile disk (DVD) drives. 
     The coded instructions  532  of  FIGS. 3 and 4  may be stored in the mass storage device  528 , in the random access memory  514 , in the read only memory  516 , and/or on a removable tangible computer readable storage medium such as a CD or DVD. 
     From the foregoing, it will be appreciated that the above disclosed method, apparatus, and articles of manufacture utilize a memristor system to store fault data and/or status data associated with an IC. Using example disclosed herein stored fault data and/or status data in the memristor system can be determined (e.g., via a probe) without supplying power to (e.g., powering up) the IC. Additionally, examples disclosed herein can store fault data associated with CATERRs. In some examples, the memristor system is attached directly to the IC to receive faults associated with the CATERRs. In some examples, the memristor system is attached to a programmable device and/or an iLO to receive more detailed fault data. In some examples, the memristor system and/or multiple memristor systems are attached to any combination of the IC, the programmable logic device, and the iLO to receive fault data associated errors that occur within a system. Additionally, the memristor system receives and stores status data associated with the IC. In some examples, the IC  100  uses status data stored in the example memristor system to initialized and/or re-boot the IC  100 . 
     Conventional methods for storing status and/or fault data associated with an IC include storing the status and/or the fault data into active health NAND, EEPROM, and/or ROM attached to the IC. Such conventional methods require more space, cannot be read without powering the IC, and are slower. Conventional methods cannot be read without powering the IC and additional damage can be caused by powering the IC with incorrect (e.g., outdated) configurations and/or firmware. Additionally, the amount of time to store data into such conventional techniques is so long. Thus, conventional techniques are unable to store faults associated with a CATERR (e.g., since CATERRs cause the IC to shut-down). Examples disclosed herein alleviate such problems by utilizing the memristor system to store fault data and/or status data into a faster memristors that can be read without providing power to the IC attached to the memristor system. 
     Example methods and apparatus are disclosed to store status and/or fault data associated with an integrated circuit. Such an example apparatus includes a plurality of resistive elements, a fault detector to determine when a fault corresponding to an integrated circuit has occurred, and a data determine to, when first data related to the integrated circuit is updated, store the first data in a first subset of the plurality of resistive elements, the data determine to, in response to, in response to the detection of the fault, store second data in a second subset of the plurality of resistive elements, the second data corresponding to an error associated with the fault. 
     In some examples, the plurality of resistive elements are memristors. In some examples, the first data include an identifier identifying at least one of the integrated circuit, firmware utilized by the integrated circuit, software utilized by to the integrated circuit, hardware corresponding to the integrated circuit, a temperature corresponding to the integrated circuit, or a component associated with the integrated circuit. In some examples, the status determiner is to determine that the integrated circuit has been updated by polling the integrated circuit. 
     In some examples, the second data includes a timestamp corresponding to when the fault occurred, In some examples the first data and the second data can be read without powering the integrated circuit. In some example the data determine is to, when an error associated with the fault causes the integrated circuit to re-boot, transmit the first data to the integrated circuit prior to the re-booting. 
     Although certain example methods, apparatus and articles of manufacture have been disclosed herein, the scope of coverage of this patent is not limited thereto. On the contrary, this patent covers all methods, apparatus and articles of manufacture fairly falling within the scope of the claims of this patent.