Apparatus and method for non-intrusive random memory failure emulation within an integrated circuit

Information

  • Patent Grant
  • 9275757
  • Patent Number
    9,275,757
  • Date Filed
    Friday, February 1, 2013
    12 years ago
  • Date Issued
    Tuesday, March 1, 2016
    9 years ago
Abstract
The system and methods allow for emulation of random hardware failure of an internal embedded memory array of an integrated circuit (IC) device. Emulation of potential defects is performed in order to evaluate the behavior of the rest of the design. This non-intrusive emulation is performed in a pseudo-functional mode in order to evaluate the behavior of one or more memory cores in their standard functional mode. The solution enables the creation of failures and tracking both the detection of the failures and the time required time for detection. Specifically, the emulation of an internal memory array with respect of random failures and the associated diagnostic mechanism ensures that detection and correction mechanisms work as expected. A typical non-limiting use case is to ensure that safety control logic of an IC behaves as expected in cases of data corruption within an embedded memory core.
Description
BACKGROUND OF THE INVENTION

1. Field of the Invention


The invention generally relates to failure detection and correction mechanisms for an integrated circuit (IC), and more particularly to emulation of random failures within a memory core of an IC.


2. Prior Art


Failure detection and correction mechanisms that are integrated within an integrated circuit (IC) aim to deal with malfunctions that randomly appear during a device's life time. Since such failure occurs randomly there is no direct way to test that the embedded detection and correction mechanisms work as expected on silicon. It would therefore be advantageous to provide a solution for emulation of such failure mechanism that would enable to ensure proper operation of a device or at least timely detection of a failure. This is of particular importance within embedded memory units commonly used in today's small and large devices.





BRIEF DESCRIPTION OF THE DRAWINGS

The subject matter that is regarded as the invention is particularly pointed out and distinctly claimed in the claims at the conclusion of the specification. The foregoing and other objects, features and advantages of the invention will be apparent from the following detailed description taken in conjunction with the accompanying drawings.



FIG. 1 is a schematic block diagram of a system architecture for testing a memory core according to an embodiment.



FIG. 2 is a schematic block diagram of a fault injection module (FIM) according to an embodiment.



FIG. 3 is a schematic block diagram of a Random Data Corruption Module (RDCM) according to an embodiment.



FIG. 4 is an illustration of the different type of corruption that can be performed and example of error detection mechanisms that can be then checked through this kind of fault emulation.





DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

It is important to note that the embodiments disclosed by the invention are only examples of the many advantageous uses of the innovative teachings herein. In general, statements made in the specification of the present application do not necessarily limit any of the various claims. Moreover, some statements may apply to some inventive features but not to others. In general, unless otherwise indicated, singular elements may be in plural and vice versa with no loss of generality. In the drawings, like numerals refer to like parts through several views.


The system and methods allow for emulation of random hardware failure of an internal embedded memory array of an integrated circuit (IC). Emulation of potential defects is performed in order to evaluate the behavior of the rest of the design. This non-intrusive emulation is performed in a pseudo-functional mode in order to evaluate the behavior of one or more memory cores in their standard functional mode. The solution enables the creation of failures and tracking both the detection of the failures and the time required time for detection. Specifically, the emulation of an internal memory array with respect of random failures and the associated diagnostic mechanism ensures that detection and correction mechanisms work as expected. A typical non-limiting use case is to ensure that safety control logic of an IC behaves as expected in cases of data corruption within an embedded memory core.


The system and methods allow covering a large range of detection mechanisms. As an illustration, a data corruption may be used to check the behavior of memory integrity checker such as Error Correcting Code (ECC), when a corruption of address may corrupt the set of data used for a CPU calculation and then check a CPU lock-step mechanism is working properly.



FIG. 1 is an exemplary and non-limiting block diagram of architecture of a system 100 according to an embodiment. The diagram shows a memory core 101 that is accessible through a functional memory interface 102, as well as an optional test memory interface 103. The functional memory interface 102 is configured for sending functional data 106. The test memory interface 103 is configured in test mode to send data from a memory built-in self-test (BIST) module 104 to test memory core 101. Fault injection module (FIM) 200 configured to send to the test memory interface 103 either corrupted or non-corrupted data from any one of the memory BIST module 104 or the data provided on interface 106. The interface 106 provides the address within the memory core, the data to be written therein, and a write enable signal. FIM 200 may force the memory core 101 to run using its test memory interface 103 when running in functional mode. This is handled by a control of the test mode signal 105 that allows switching the interface used by the memory core 101. When activated, the FIM 200 sends either the functional data supplied on interface 106 to the memory core 101 or an internally generated corrupted data. One of ordinary skill in the art would readily appreciate that the system 100 allows to create a failure and to track both the detection of this failure and the required time for this detection through feedback provided from the detection interface 107.



FIG. 2 is an exemplary and non-limiting schematic of the FIM 200 according to an embodiment. The module 200 is connected to a system, such as system 100, through a FIM interface 201. Fault injection module 200 includes a detection interface 107 for allowing information exchange between an IC mechanisms in charge of the error detection and the FIM 200, BIST Interface 208 for collecting the signal provided by a memory BIST module, such as memory BIST module 104 shown in FIG. 1, interface 106 for receiving the functional signals driving the memory core 101 in functional mode, and a control interface 207 for managing the FIM 200. A Control Interface 207 allows controlling the FIM behavior.


The FIM 200 aims to emulate an internal memory error in order to check the error detection mechanisms of the IC are working as expected. This emulation is performed through either a data or an address corruption. Data corruption is performed on memory on a write access so that the data that is stored within the memory core 101 emulates a fault. Address corruption can be made either on a read or on write access.


The FIM 200 allows choosing whether the memory core 101 receives its address and data from the BIST interface 208 or from the functional interface 106 or from the Random Data Corruption Module (RDCM) 300. Output data 209 is sent to the memory core 101 and might be corrupted by the RDCM 300. Output memory address 212 is sent to the memory core 101 and might be corrupted by the RDCM 300. When the IC is in emulation mode, data and address from the functional interface 106 are transmitted to the memory core 101. When the fault emulation mode is enabled, data or address corruption takes place on at least a memory access after a random period of time.


The corruption of the data is performed by the RDCM 300 and the memory address where the corruption has been performed is stored within a corrupted address register (CAR) 202. The corruption can be made either on the memory data 209 or the memory address 212. A dedicated signal 204 from the RDCM 300 informed the CAR 202 to save any corrupted memory address. After completing this procedure the FIM 200 reverts to a neutral mode, sending data from the functional interface 106 to the memory core 101 without corruption. When the corruption has been done on the memory address during a memory read, the detection delay counter (DDC) 203 is immediately starting.


The role of DDC 203 is to measure the time it takes the rest of the IC to detect that a corrupted value has been read. In case the corruption is done during a write access (on data or address), the DDC 203 starts counting on the next read access to memory. The DDC detects the failure when the read to memory is using an address where a corruption has been made, which could be considered either the corrupted address where the data was written, or the address where the data should have been written, or the first of these two addresses to be read.


When the detection is made, a detection 107 signal is sent back to the FIM 200. The value of the counter may be read through the control interface 207 in order to determine the time required to detect that corrupted data was provided. A signal 210 from the Random Data Corruption Module (RDCM) 300 module allows choosing whether the memory data 209 has to be corrupted or not. Another dedicated signal 211 is provided by the RDCM 300 to choose whether the memory address 212 has to be corrupted or not.



FIG. 3 is an exemplary and non-limiting schematic of the RDCM 300 according to an embodiment. RDCM is controlled by the IC through the RDCM control interface 311. A non-limiting implementation of a corruption module CM 301-1 include the capability of corrupting a single bit of data through the Single Bit Corruption Module (SBCM) 302, to corrupt more bits through a Multi Bit Corruption Module (MBCM) 303, or to randomly replace the data by another through a pseudo random pattern generator 304. The corruption type choice is setup through the RDCM control interface 311 and sent to the CM 301-2 through configuration signal 305. Since the corruption can be applied either on memory data 309, on memory address 308 or both, the RDCM 300 includes a second CM module 301-2 dedicated to the corruption of the memory address. Corrupted memory address 306 and corrupted memory data 307 are then used by the FIM 200 and sent to the memory core 101. An internal finale state machine (FSM) 312 manages the different signals that are required by the FIM 200 to propagate the corrupted data 307 or the corrupted address 306 at the right time. The monitoring of the Memory Write Enable signal 310 allows the FSM 312 to determine the type of memory access being performed and then react accordingly.



FIG. 4 represents the different types of error emulation that can be handled through the invention and the corresponding error detector IC features that can be checked thanks to this emulation. As described in this figure, the corruption of the memory core 101 content allows checking both the behavior of data integrity mechanisms such as ECC, but also any other feature that allows detecting a calculation error due to bad input data such as lockstep or data drop anomaly detector.


The principles of the invention are implemented as hardware or a combination of hardware, firmware, and software of any combination. With respect of firmware and software these are preferably implemented as an application program tangibly embodied on a program storage unit or computer readable medium. The application program may be uploaded to, and executed by, a machine comprising any suitable architecture. Preferably, the machine is implemented on a computer platform having hardware such as one or more central processing units (“CPUs”), a memory, and input/output interfaces. The computer platform may also include an operating system and microinstruction code. The various processes and functions described herein may be either part of the microinstruction code or part of the application program, or any combination thereof, which may be executed by a CPU, whether or not such computer or processor is explicitly shown. In addition, various other peripheral units may be connected to the computer platform such as an additional data storage unit and a printing unit and/or display unit. Furthermore, while a single memory core was described hereinabove, one of ordinary skill in the art would readily appreciate that a plurality of memory cores would be possible using the same principles disclosed herein without undue burden and therefore are specifically to be considered an integral part of the invention. An IC includes, also and without limitation a system on chip (SoC). The IC may be implemented as a monolithic semiconductor device.


All examples and conditional language recited herein are intended for pedagogical purposes to aid the reader in understanding the principles of the invention and the concepts contributed by the inventor to furthering the art, and are to be construed as being without limitation to such specifically recited examples and conditions. Moreover, all statements herein reciting principles, aspects, and embodiments of the invention, as well as specific examples thereof, are intended to encompass both structural and functional equivalents thereof. Additionally, it is intended that such equivalents include both currently known equivalents as well as equivalents developed in the future, i.e., any elements developed that perform the same function, regardless of structure.

Claims
  • 1. An integrated circuit (IC) comprising: a fault injection module coupled between a built-in self-test module and a memory, via a test memory interface, the fault injection module having a data corruption module configured to either send functional data to the memory, or randomly corrupt a data and write the corrupted data into a memory address or write uncorrupted data into a corrupt memory address responsive to a write enable signal; andthe fault injection module further comprises a detection interface allowing information exchange with error detection IC mechanisms.
  • 2. The IC of claim 1, further comprising: the memory having a built-in self-test module.
  • 3. The IC of claim 1 wherein the fault injection module is configured to corrupt data to be written into a memory address or to corrupt a memory address to which data is to be written to or from which data is to be read by a single bit corruption module.
  • 4. The IC of claim 1 wherein the fault injection module is configured to corrupt data to be written into a memory address or to corrupt a memory address to which data is to be written to or from which data is to be read by a multi bit corruption module.
  • 5. The IC of claim 1 wherein the fault injection module is configured to corrupt data to be written into a memory address or to corrupt a memory address to which data is to be written or from which data is to be read by a pseudo random pattern generator.
  • 6. The IC of claim 1, wherein the fault injection module further comprises: a random data corruption module configured to randomly corrupt the data to be written into an address of the memory or to corrupt the data that is to be written into or read from the memory address.
  • 7. The IC of claim 1, wherein the fault injection module further comprises: a corrupted address register to which the address of the memory is written upon corruption of data in the respective memory address, or to which the corrupted address is written.
  • 8. The IC of claim 7, wherein the fault injection module further comprises: a detection delay counter.
  • 9. The IC of claim 8, wherein the fault injection module is further configured to activate the detection delay counter to begin counting upon detection that a read from the memory from an address stored in the corrupted address register is attempted.
  • 10. The IC of claim 9 wherein addresses stored in the corrupted address register are the addresses into which corrupted data has been written.
  • 11. The IC of claim 9 wherein addresses stored in the corrupted address register are the corrupted addresses.
  • 12. The IC of claim 9 wherein addresses stored in the corrupted address register are the corrupted address and the address before corruption.
  • 13. The IC of claim 8 wherein the fault injection module is configured to receive an error signal and provide count information from the detection delay counter responsive thereto.
  • 14. The IC of claim 1, wherein the IC comprises a system on a chip.
  • 15. The IC of claim 1, wherein the IC is implemented as a monolithic semiconductor device.
US Referenced Citations (59)
Number Name Date Kind
4005405 West Jan 1977 A
4669081 Mathewes et al. May 1987 A
4759019 Bentley et al. Jul 1988 A
4873705 Johnson Oct 1989 A
4875209 Mathewes et al. Oct 1989 A
5274646 Brey et al. Dec 1993 A
5325365 Moore et al. Jun 1994 A
5428624 Blair et al. Jun 1995 A
5471482 Byers et al. Nov 1995 A
5475624 West Dec 1995 A
5664159 Richter et al. Sep 1997 A
5668816 Douskey et al. Sep 1997 A
5784323 Adams et al. Jul 1998 A
5828824 Swoboda Oct 1998 A
5903719 Yamamoto May 1999 A
5937154 Tegethoff Aug 1999 A
5978935 Kim et al. Nov 1999 A
6009256 Tseng et al. Dec 1999 A
6009541 Liu et al. Dec 1999 A
6014504 Saine et al. Jan 2000 A
6035420 Liu et al. Mar 2000 A
6061274 Thibault et al. May 2000 A
6067262 Irrinki et al. May 2000 A
6269455 Deas Jul 2001 B1
6338148 Gillenwater et al. Jan 2002 B1
6457149 Uehara Sep 2002 B1
6496950 Zhao et al. Dec 2002 B1
6536008 Nadeau-Dostie et al. Mar 2003 B1
6557115 Gillenwater et al. Apr 2003 B2
6769084 Kim et al. Jul 2004 B2
6785873 Tseng Aug 2004 B1
6842865 Nee et al. Jan 2005 B2
6862565 Zheng Mar 2005 B1
7038955 Susuki et al. May 2006 B2
7149924 Zorian et al. Dec 2006 B1
7184915 Hansquine et al. Feb 2007 B2
7222282 Park May 2007 B2
7222800 Wruck May 2007 B2
7278078 Hii et al. Oct 2007 B2
7284159 Chakraborty et al. Oct 2007 B2
7392442 Averbuj et al. Jun 2008 B2
7409610 Drimer Aug 2008 B1
7472051 Mariani et al. Dec 2008 B2
7483824 Hill Jan 2009 B1
7487421 Damodaran et al. Feb 2009 B2
7519875 Rearick et al. Apr 2009 B2
7539900 Plofsky May 2009 B1
7814380 Averbuj et al. Oct 2010 B2
7827438 Tarta Nov 2010 B2
7856581 Tabatabaei et al. Dec 2010 B1
7869293 Morein Jan 2011 B2
8051346 Somasundaram et al. Nov 2011 B2
8112730 Aleksanyan et al. Feb 2012 B2
8176372 Anzou et al. May 2012 B2
8296613 La Fever et al. Oct 2012 B2
20060126799 Burk Jun 2006 A1
20090193296 Kellington et al. Jul 2009 A1
20120239993 Chung Sep 2012 A1
20130212445 Doerr et al. Aug 2013 A1
Non-Patent Literature Citations (1)
Entry
Folkesson, Peter , et al., “A Comparison of Simulation Based and Scan Chain Implemented Fault Injection”, Twenty-Eighth Annual International Symposium on Fault-Tolerant Computing, 1988. Digest of Papers., (Jun. 23-25, 1998), pp. 284-293.
Related Publications (1)
Number Date Country
20140217406 A1 Aug 2014 US