Ecc-aware in-system memory testing

Abstract

The present disclosure relates to ECC-aware system memory testing. An apparatus (200) is disclosed herein. The apparatus includes a memory unit (205) configurable to store a first set of data, an assist circuit (216) coupled to the memory unit, and a controller (214) coupled to the assist circuit. The assist circuit is configurable to receive the first set of data from the memory unit, generate a second set of data based on the first set of data, and mask an error in the second set of data using an error correction code level to create a masked second set of data in response to determining that the first set of data has the error. The controller is configurable to perform a memory test of the memory unit based on the masked second set of data received from the assist circuit.

Description

[0001] Cross-reference to related applications

[0002] This application claims priority to U.S. Provisional Patent Application No. 63 / 790,313, filed April 17, 2025, entitled “ECC-AWARE IN-SYSTEM MEMORY TEST,” which is incorporated herein by reference in its entirety. Technical Field

[0003] This disclosure generally relates to integrated circuit devices, and more specifically to integrated circuit devices having built-in self-test capabilities. Background Technology

[0004] For example, a system-on-a-chip (SoC) integrated circuit device may include on-chip memory, such as volatile memory (e.g., RAM) and / or non-volatile memory (e.g., flash memory and / or ROM). Functional safety standards used to ensure that an integrated circuit device is suitable for high-risk applications may require various types of testing on these memories. Therefore, many integrated circuit devices support one or more software suites that allow manufacturers and developers to perform built-in and / or external testing on the on-chip memory.

[0005] Such integrated circuit devices may also include data protection hardware that detects errors in data stored in on-chip memory due to transient or permanent faults. This data protection hardware can implement an error checking and correction (ECC) scheme to generate ECC data and store it along with functional data. Errors in the functional data may cause a mismatch between the ECC data and the functional data, which allows the ECC data to be used to detect and, in some cases, correct errors in the functional data. Summary of the Invention

[0006] This document discloses an apparatus comprising a memory cell configurable to store a first dataset, auxiliary circuitry coupled to the memory cell, and a controller coupled to the auxiliary circuitry. The auxiliary circuitry is configured to receive the first dataset from the memory cell, generate a second dataset based on the first dataset, and, in response to determining that the first dataset contains errors, mask the errors in the second dataset using an error correction code level to create a masked second dataset. The controller is configured to perform a memory test on the memory cell based on the masked second dataset received from the auxiliary circuitry.

[0007] This document also discloses an apparatus comprising a memory cell, auxiliary circuitry coupled to the memory cell, and a controller coupled to the auxiliary circuitry and the memory cell. The memory cell is configured to store first data at a first memory address and store second data at a second memory address. The auxiliary circuitry is configured to receive the first and second data from the memory cell and generate third data based on the second data and a reverse signature. The controller is configured to perform a memory test on the memory cell. The memory test includes: receiving the first and third data from the auxiliary circuitry, calculating a multi-input shift register (MISR) value based on the first and third data, and determining whether the memory cell passes the memory test based on the MISR value.

[0008] This document also discloses a method comprising performing a memory test on a memory cell having multiple memory addresses, and receiving first data based on data read from a first memory address among the multiple memory addresses of the memory cell. The method further comprises determining a multiple-input shift register (MISR) value based on the first data and the first memory address of the memory cell, and comparing the calculated MISR value with a value used to determine whether the execution of the memory test includes the first memory address of the test memory cell.

[0009] Unless otherwise expressly indicated herein, the foregoing features and elements can be combined in any combination without exclusivity. The operation of these features and elements, and the disclosed examples, will become more apparent from the following description and accompanying drawings. Attached Figure Description

[0010] Reference will now be made to the accompanying drawings, which are not necessarily drawn to scale. While the drawings illustrate various examples employing the principles described herein, they do not limit the scope of the claims.

[0011] Figure 1 Perspective views of motor vehicles containing one or more controllers are shown, according to various examples.

[0012] Figure 2 Block diagrams of systems for testing controllers are shown, based on various examples.

[0013] Figure 3A and 3B A block diagram of a controller with built-in self-testing that includes error checking and correction awareness is shown for various examples.

[0014] Figure 4 A flowchart is shown illustrating a method for performing built-in self-tests for error checking and correction awareness, based on various examples.

[0015] Figure 5A and 5BA block diagram of a controller with a built-in signature-based self-test is shown for various instances.

[0016] Figure 6 A flowchart is shown illustrating methods for performing signature-based built-in self-tests based on various examples.

[0017] Figure 7A and 7B Block diagrams of controllers with built-in read-only memory self-tests are shown for various examples.

[0018] Figure 8 A flowchart is shown illustrating methods for performing read-only memory built-in self-tests based on various examples. Detailed Implementation

[0019] The following detailed description is presented for illustrative and not restrictive purposes. Benefits, advantages, and / or solutions to problems may be described with reference to various examples. Detailed descriptions utilize various examples and refer to the accompanying drawings illustrating the various examples described herein. The diagrams, descriptions, and examples are described in sufficient detail to practice this disclosure. It should be understood that the connecting lines shown in the various diagrams are intended to represent the functional relationships and / or physical couplings between various elements, but other relationships and / or couplings are possible while remaining within the scope of this disclosure. It should be further understood that the various diagrams may not be drawn to scale in order to simplify and clarify the detailed description herein. Furthermore, it should be understood that the descriptions and examples contained herein may permit the practice of other examples using logical, chemical, and / or mechanical variations without departing from the spirit and scope of this disclosure. For example, the steps described in the method and process description may be performed in a different order, additional process steps may be added, and / or process steps may be removed, while remaining within the scope of this disclosure.

[0020] Any reference to a singular item and / or instance may include multiple items and / or instances, and any reference to more than one item and / or instance may include a singular item and / or instance. Similarly, unless otherwise stated, a reference to “a / an” or “described” may include one or more of the referenced items. Any reference to the words and / or phrases of connection, coupling, fixing, attachment, or similar terms may include partial, complete, temporary, removable, permanent, or other connection options. Any reference to the phrase of contact may include minimal contact or reduced contact. All scopes used herein may include the upper and lower limits of the scopes disclosed herein, including ratio limits. The stated values ​​may include at least the variations expected within the scope of practicing this disclosure and will be understood and accepted as values ​​included within 10% of the stated values. Similarly, the use of “approximately,” “about,” “substantially,” or other similar terms indicates a quantity that is close to the stated value and still achieves the stated or desired result and / or performs the stated or desired function, and may refer to a quantity within 10% of the stated value.

[0021] The detailed description of the accompanying drawings and symbols includes reference numerals that may be repeated across multiple instances. The repetition of reference numerals is intended to simplify and clarify the description and is not intended to establish or define a relationship between the different instances described herein. The examples and descriptions provided herein are intended to be illustrative and do not limit the scope beyond the claims. For example, the use of terms such as “above” and “over” may indicate that a first feature is formed in direct contact with a second feature, or may indicate a relationship where there is no direct contact between the first and second features, such as when an additional feature is formed between the first and second features. For example, “above” may be used to indicate direct contact between the first and second features, and “over” may be used to indicate direct contact or separation by one or more intermediate layers.

[0022] Spatial relative terms such as “lower,” “upper,” “horizontal,” “vertical,” “above,” “above,” “below,” “under,” “upward,” “downward,” “top,” “bottom,” and their derivatives (e.g., “horizontally,” “downward,” “upward,” etc.) are used herein for ease of discussion and are not intended to limit the orientation of various components, systems, devices, apparatuses, or other features. Therefore, it should be understood and appreciated that the use of spatial relative terms for different orientation practices remains within the scope of this disclosure.

[0023] Integrated circuit (IC) devices may include a built-in self-test (BIST) circuitry system that verifies the raw data integrity of a memory device (e.g., RAM or ROM). In an example where RAM is being tested, the BIST circuitry system may write one or more specified data patterns into the RAM, then read data from the RAM and determine whether the read data is the same as the data pattern written into the RAM. In an example where ROM is being tested, the BIST circuitry system may read data from the ROM, generate a signature based on the read data, and then compare the signature with a known-good signature. Both examples can be used to determine whether the memory is error-free. In various examples, an external test device may determine whether the read data and / or the generated signature is correct. As IC devices are improved, some IC devices implement a type of error checking and correction (ECC) scheme and / or repair circuitry system that can be used during the operation of the IC device. As used herein, ECC may refer to error checking and correction or error correction codes.

[0024] This document discloses an IC device implementing an ECC scheme and including a BIST circuitry system, which can be configured to verify a memory device with and without an ECC scheme. For example, the BIST circuitry system can be configured to perform a BIST to verify the raw data integrity of the memory device without using an ECC scheme. The same BIST circuitry system can be configured to verify the functional integrity of the memory device when using an ECC scheme (e.g., an ECC-aware self-test). In other words, raw data integrity verification returns the expected data from the memory device, and functional integrity verification can correct the returned data using an ECC scheme. Therefore, the BIST circuitry system can be configured to verify the functionality of the memory device with or without an ECC scheme.

[0025] This document also discloses an IC device incorporating a BIST circuitry system configured to generate a unique signature for each test performed by the BIST circuitry system. In various instances, the unique signature can be generated by the BIST circuitry system based on both the data read from a memory device and the memory address from which the data is read. Therefore, in some instances, the signature can be used to verify that the run test is the intended test. In other words, the signature provides a verification value that uniquely identifies a combination of data patterns and the tested memory address of the memory device. In various instances, this can be used as a secondary verification for testing all memory addresses. In some instances, the IC device may include a BIST circuitry system configured to perform both ECC-aware memory testing and test signature generation.

[0026] This document also discloses an IC device incorporating a BIST circuitry system configured to perform a power-on self-test of a programmable memory BIST (PBIST) of read-only memory (e.g., ROM). In various instances, the BIST circuitry system can generate a signature based on data read from the ROM. The BIST circuitry system may additionally include a reverse signature, which, when combined with data read from the last memory address of the ROM, causes the generated signature to match a known good signature. Including a reverse signature allows the ROM to be modified without altering the known good signature. Conversely, a reverse signature can be generated and stored to ensure that a known good signature is generated during testing.

[0027] In some instances, the BIST circuitry system may include both a programmable memory BIST (PBIST) controller and auxiliary PBIST circuitry. In other instances, the BIST circuitry system may include a PBIST controller that provides functionality for the auxiliary PBIST circuitry. While no advantage is required for any particular instance, some instances of this disclosure provide a mechanism for manufacturers or developers to determine whether the memory contains any errors, and if so, whether the errors are severe enough to be uncorrectable.

[0028] Now for reference Figure 1 According to various aspects of this disclosure, a motor vehicle 100 is shown. The motor vehicle 100 includes a plurality of devices 104 and a communication bus 106 connecting the plurality of devices 104. In various embodiments, the motor vehicle 100 may be, for example, a car, truck, van, shuttle bus, motorcycle, bus, etc. In various embodiments, the plurality of devices 104 may be configured to control various functions of the motor vehicle 100. These functions may include lighting, climate control, windows, engine management, braking, steering wheel, infotainment system, traction control, and instrument panel controls, etc. Each device 104 may communicate with one or more of the other devices 104 via the communication bus 106. In various embodiments, the plurality of devices 104 may be or include integrated circuit (IC) devices. In various embodiments, the plurality of devices 104 may be CAN (Control Local Area Network) devices, and the communication bus 106 may be a CAN bus. As described below, one or more of the devices 104 may be or include any of the components described herein that perform the disclosed built-in self-test.

[0029] Now for reference Figure 2 A block diagram of system 200 is shown according to various aspects of this disclosure. System 200 includes apparatus 202 and automated test equipment (ATE) 218. In various embodiments, apparatus 202 may be... Figure 1An example of device 104 is shown. Device 202 includes processor 204, memory 205, input / output (I / O) 212, PBIST controller 214, and auxiliary PBIST circuitry 216. As shown, in some instances, auxiliary PBIST circuitry 216 may be external to PBIST controller 214. From the perspective of die area and performance (e.g., timing, operating frequency, etc.), it is effective to place auxiliary PBIST circuitry 216 outside PBIST controller 214. In other instances, auxiliary PBIST circuitry 216 may be internal to (or a portion thereof) PBIST controller 214. For ease of discussion, auxiliary PBIST circuitry 216 will be described below as being external to PBIST controller 214.

[0030] Processor 204 controls the general operation of device 202. For example, processor 204 can provide processing power to execute operating systems, programs, user and application interfaces, and / or any other functions of device 202. Processor 204 may include one or more microprocessors, such as one or more general-purpose microprocessors, application-specific microprocessors (ASICs), or combinations of such processing components. Processor 204 may include one or more processors based on x86 or reduced instruction set computer (RISC) architectures, as well as dedicated graphics processors (GPUs), image signal processors, digital signal processors (DSPs), video processors, audio processors, and / or related chipsets. Processor 204 may include multiple processing cores of the same or different types and may be implemented as a system-on-a-chip (SoC) device.

[0031] Memory 205 includes a computer-readable medium for storing instructions to be executed by processor 204 and / or data for operation of device 202. Memory 205 may include one or more memory devices (e.g., DRAM, SDRAM, or internal memory). Each memory device may include one or more memory cells, wherein a memory cell may refer to a storage element capable of storing a single bit or multiple bits of information. Thus, a memory cell may refer to a single storage element, a subset of storage elements, or each storage element of a memory device. Figure 2As shown, memory 205 includes random access memory (RAM) 206, read-only memory (ROM) 208, and programmable built-in self-test (PBIST) ROM 210. Memory 205 may further include one or more external memory devices (e.g., hard disk drive (HDD), solid-state drive (SSD), flash memory, etc.). In various instances, RAM 206 may be used as operational memory by processor 204. That is, processor 204 may read data from RAM 206 and write data to RAM 206 during normal operation of device 202. In some instances, ROM 208 may store operational instructions to be executed by processor 204. That is, processor 204 may read instructions from ROM 208 and execute these instructions. In some instances, PBIST ROM 210 may store test instructions to be executed by PBIST controller 214. That is, PBIST controller 214 may read instructions from PBIST ROM 210 and execute these instructions to perform the built-in self-test (BIST) of device 202.

[0032] I / O 212 may include circuitry and / or pins configurable to receive and / or transmit data from device 202. In various instances, processor 204 may be directly connected to I / O 212. In various instances, device 202 may include one or more intermediate circuits (e.g., a Controller Area Network (CAN) controller) for receiving and / or transmitting data to / from processor 204 via I / O 212.

[0033] PBIST controller 214 can control the built-in self-test operation of device 202. For example, PBIST controller 214 can provide processing capabilities to perform one or more built-in self-tests when device 202 is started (e.g., powered on or initialized) or at other times upon request. PBIST controller 214 may include one or more microprocessors, ASICs, or combinations thereof. PBIST controller 214 can communicate with processor 204, auxiliary PBIST circuitry 216, and / or memory 205 (including RAM 206, ROM 208, and / or PBIST ROM 210). PBIST controller 214 can read instructions from PBIST ROM 210 for performing the built-in self-tests of RAM 206, ROM 208, and / or PBIST ROM 210.

[0034] The auxiliary PBIST circuit 216 provides additional functionality to the PBIST controller 214. As discussed above, the auxiliary PBIST circuit 216 may be internal to or external to the PBIST controller 214. The auxiliary PBIST circuit 216 may communicate with the processor 204, the PBIST controller 214, and / or the memory 205 (including RAM 206, ROM 208, and / or PBIST ROM 210). The auxiliary PBIST circuit 216 may include one or more integrated circuit (IC) components or devices configured to provide additional functionality to the PBIST controller 214. Further details and examples of the auxiliary PBIST circuit 216 will be described in more detail below.

[0035] ATE 218 is an external computer, machine, or device that can provide control signals, streaming data, and / or test modes to and / or receive outputs from device 202. In some instances, the control signals, streaming data, and / or test operations of device 202 can be controlled by ATE 218. In other instances, the control signals, streaming data, and / or test modes can be processed by processor 204 and / or PBIST controller 214 before or in place of ATE 218. In various instances, ATE 218 can be introduced into device 202 by probing IC die pads at the wafer level or by contacting package pins of device 202 (both represented by I / O 212).

[0036] As will be described in more detail below, the PBIST controller 214 and auxiliary PBIST circuitry 216 can be configured to perform various built-in self-tests of the actuator 202. For example, the PBIST controller 214 and auxiliary PBIST circuitry 216 can be configured to perform ECC-aware built-in self-tests of the actuator 202, as will be described below. Figure 3A and 3B As described in [the original text]. In other instances, the PBIST controller 214 and auxiliary PBIST circuitry 216 can be configured to perform a signature-based built-in self-test of the device 202, as described below. Figure 5A and 5B As described in [the original text]. In other instances, the PBIST controller 214 and auxiliary PBIST circuitry can be configured to perform a read-only memory built-in self-test upon device 202 startup, as described below. Figure 7A and 7B As described in the text.

[0037] Now for reference Figure 3A and 3B A block diagram of system 300 is shown according to various aspects of this disclosure. System 300 includes components described above. Figure 2The system 200 described herein contains similar components, including device 302, processor 304, RAM 306, PBISTROM 310, PBIST controller 314, auxiliary PBIST circuitry 316, and ATE 318, the description of which will not be repeated below. In various instances, as described herein, device 302, processor 304, RAM 306, and PBIST ROM 310 may be instances of device 202, processor 204, RAM 206, and PBIST ROM 210, respectively. PBIST controller 314 and auxiliary PBIST circuitry 316 may be instance implementations of PBIST controller 214 and auxiliary PBIST circuitry 216, respectively, for performing ECC-aware built-in self-tests of device 302.

[0038] The PBIST controller 314 and auxiliary PBIST circuitry 316 (collectively referred to as PBIST controller 314) are configured to perform a built-in self-test on the device 302. Specifically, the PBIST controller 314 is configured to verify the hardware integrity of the device 302's RAM (e.g., RAM 306) and / or ROM (e.g., ROM 208). For example, the built-in self-test can verify that data read from the ROM is correct. Additionally, the PBIST controller 314 can verify that data read from RAM 306 is the same as data written to RAM 306. For simplicity and ease of discussion, the following description of system 300 will refer to RAM 306, but similar functionality for testing the ROM of the device 302 may exist.

[0039] System 300 can further be configured to perform a built-in self-test utilizing error checking and correction (ECC), such as an ECC-aware built-in self-test. The ECC-aware built-in self-test ensures that data read from RAM 306 can be corrected, if necessary, to match the data initially written to RAM 306. Therefore, device 302 can be configured to verify the original data integrity of RAM 306 (e.g., without ECC correction) or the functional integrity of RAM 306 (e.g., with ECC correction applied to the read data). In some instances, the built-in self-test can be performed at device 302 startup (e.g., power-on or initialization). In other instances, the built-in self-test can be performed after device 302 startup.

[0040] As described above, processor 304 can communicate with PBIST controller 314 and auxiliary PBIST circuitry 316. Processor 304 can communicate with PBIST controller 314 via CPU bus 320 and with auxiliary PBIST circuitry 316 via one or more signal lines. For example, as... Figure 3AAs shown, processor 304 can provide ECC level signal 338 and ECC mode enable signal 340 to auxiliary PBIST circuit 316. Both ECC level signal 338 and ECC mode enable signal 340 can be configured to operate with built-in self-test.

[0041] The PBIST controller 314 can communicate with RAM 306, PBIST ROM 310, and auxiliary PBIST circuitry 316. Furthermore, the PBIST controller 314 may include a data generator 322 and a comparator circuit 324, each of which can communicate with RAM 306 and / or auxiliary PBIST circuitry 316. For example, the data generator 322 may provide one or more memory interface signals 330 to RAM 306 and a desired data signal 332 to auxiliary PBIST circuitry 316. In various instances, the memory interface signals 330 may include control signals, data signals, and / or address signals. Examples of control signals may include read signals, timing signals, write enable signals, read enable signals, and / or chip enable signals, etc. Examples of data signals may include write data bus signals, read data bus signals, and / or data bus signals. In some instances, address signals may include address bus signals. The information provided by the memory interface signals 330 can be used by RAM 306 to write and / or read data. Comparison circuit 324 may receive expected data signal 332 from data generator 322 and return data signal 336 from auxiliary PBIST circuit 316. Comparison circuit 324 may provide comparison results in response to requests from processor 304 or ATE 318. In some instances, data generator 322 and / or comparison circuit 324 may be implemented in hardware within PBIST controller 314. In other instances, data generator 322 and / or comparison circuit 324 may be implemented in software that may be stored in PBIST ROM 310 and executed by PBIST controller 314.

[0042] The auxiliary PBIST circuit 316 includes a comparison block 342 (e.g., XOR), a masking circuit 346, and a multiplexer 348. The comparison block 342 receives an expected data signal 332 and a read data signal 334 (containing data read from RAM 306), and generates an output signal 344. Figure 3BDuring operation, comparison block 342 compares expected data signal 332 and read data signal 334, and outputs the comparison as output signal 344. Each of expected data signal 332 and read data signal 334 may contain one or more bits associated with the memory access operation. For example, both expected data signal 332 and read data signal 334 may contain multiple bits, such as 4 bits, 8 bits, 16 bits, 27 bits, or any other number of bits that can be designed. Output signal 344 may contain the same number of bits as expected data signal 332 and read data signal 334.

[0043] In various instances, comparison block 342 can generate output signal 344 as a bitwise comparison (e.g., XOR) between expected data signal 332 and read data signal 334, such that each bit of output signal 344 indicates whether the corresponding bit of read data signal 334 is different from expected data signal 332. For example, comparison block 342 can output "0" when expected data signal 332 is the same as read data signal 334, and output "1" when expected data signal 332 is different from read data signal 334. In instances where each of expected data signal 332 and read data signal 334 contains 4 bits, both signals can have a value of '0010', in which case output signal 344 can have a value of '0000', indicating that there is no error in read data signal 334. In another example, the expected data signal 332 may have a value of '0010', and the read data signal 334 may have a value of '0110'. In this case, the output signal 344 may have a value of '0100', indicating an error in the read data signal 334. For illustrative and explanatory purposes, [the following is provided]. Figure 3B As an example, comparison block 342 may therefore be implemented in a manner different from that shown without departing from the scope of this disclosure.

[0044] Masking circuit 346 receives output signal 344 and ECC level signal 338 as inputs and generates masked data 345. Masking circuit 346 can use ECC level signal 338 to mask one or more errors (if present) in read data signal 334 (as identified by output signal 344). ECC level signal 338 determines the number of correctable errors within the data set. For example, when ECC level signal 338 has a value of '1', masking circuit 346 can mask a single error in read data signal 334 by modifying output signal 344 to generate masked data 345. Returning to the above example where output signal 344 has a value of '0100', masking circuit 346 can output a value of '0000' in response to assertion of ECC level signal 338. That is, masking circuit 346 can correct a single error in read data signal 334, similar to the ECC scheme of device 302. In another example, when ECC level 338 has a value of '2', masking circuit 346 can modify output signal 344 to generate masked data 345, thereby masking up to two errors in read data signal 334. In other words, masking circuit 346 can correct errors in read data signal 334 that are equal to or less than the number of errors indicated by ECC level signal 338. For example, when output signal 344 has a value of '0110', masking circuit 346 can mask a single error (e.g., masked data 345 has a value of '0010') in response to ECC level signal 338 having a value of '1', but can mask two errors (e.g., masked data 345 has a value of '0000') in response to ECC level signal 338 having a value of '2'. Therefore, masking circuit 346 can provide verification of RAM 306 using an ECC scheme without implementing an ECC scheme.

[0045] Multiplexer 348 receives output signal 344, masked data 345, and ECC mode enable signal 340 as inputs. In various instances, the multiplexer described herein may be referred to as a selector circuit because it receives two or more data inputs and a selection input and produces a single output based on the selection input. Multiplexer 348 receives ECC mode enable signal 340 and, in response to the value of ECC mode enable signal 340, outputs output signal 344 or masked data 345 as return data signal 336. For example, multiplexer 348 passes output signal 344 in response to ECC mode enable signal 340 being a first value (e.g., '0' or logic low) and passes masked data 345 in response to ECC mode enable signal 340 being a second value (e.g., '1' or logic high). These values ​​are provided as examples for illustrative and descriptive purposes; other values ​​may be used to control multiplexer 348.

[0046] Comparator circuit 324 receives a returned data signal 336 and an expected data signal 332 as inputs and provides an output indicating whether the built-in self-test has passed or failed. In various instances, comparator circuit 324 may provide a pass or fail response to receiving the returned data signal 336. In some instances, the comparison result may be returned to processor 304. In other instances, the comparison result may be returned to ATE 318.

[0047] Therefore, system 300 can be configured to perform an ECC-aware built-in self-test. The ECC-aware built-in self-test verifies the functional integrity of RAM 306 by identifying and masking one or more errors (if present) that may occur during data reads from RAM 306. Furthermore, system 300 can be configured to perform a non-ECC-aware built-in self-test to verify the raw data integrity of RAM 306. Thus, system 300 improves the testing capabilities of device 302 and provides additional information about the status and functionality of RAM 306.

[0048] Now for reference Figure 4 Based on various examples, methods for performing the above are shown. Figure 3A and 3B The flowchart of the built-in self-test method 400 described herein is provided. In various instances, method 400 can be used to perform a built-in self-test on a device (e.g., device 302) without using ECC or an ECC-aware built-in self-test. In various instances, method 400 can be executed on a memory device (e.g., RAM 306) by a PBIST controller (e.g., PBIST controller 214, PBIST controller 314). In other instances, method 400 can be executed on a memory device by an ATE 318. Additional processes may be provided before, during, and after method 400.

[0049] At step 402, the controller (e.g., PBIST controller 314 and auxiliary PBIST circuitry 316 or ATE 318) initiates a memory test. In various instances, the memory test may begin when the device is powered on (e.g., powered on). In various other instances, the memory test may occur after startup.

[0050] At step 404, the controller (e.g., data generator 322) may write the first dataset to a memory cell (e.g., RAM 306). In various instances, writing the first dataset may involve providing the RAM 306 with a memory address location, a test mode, and / or other signals (e.g., memory interface signal 330). For example, the test mode may be data written to and read from RAM 306. In some instances, the test mode may be all '0' or all '1'. In other instances, the test mode may be an alternating bit pattern (e.g., '0101') or another known pattern for verifying the integrity of RAM 306.

[0051] At step 406, the controller (e.g., data generator 322 and auxiliary PBIST circuitry 316) reads the first dataset from a memory unit (e.g., from RAM 306). In various instances, the first dataset may be received and processed by the PBIST controller 314. In other instances, the first dataset may be received and processed by the auxiliary PBIST circuitry 316.

[0052] In step 408, the controller (e.g., auxiliary PBIST circuit 316) generates a second dataset based on the first dataset. Generating the second dataset may involve performing a bitwise comparison of the first dataset with the expected test pattern. The second dataset may indicate the presence of errors (if any) in the first dataset.

[0053] At step 410, the controller (e.g., multiplexer 348 of the auxiliary PBIST circuit 316) determines whether ECC testing is enabled. Typically, when ECC testing is not enabled, the controller tests the raw data integrity of the memory cells, and when ECC testing is enabled, the controller tests the functional integrity of the memory cells. If the controller determines that ECC testing is not enabled, method 400 proceeds to step 412.

[0054] At step 412, the controller (e.g., comparator circuit 324) determines whether the memory test passes or fails based on the second dataset. For example, the controller may check the second dataset for values ​​(e.g., '1') that indicate the presence of an error in the first dataset. If the controller finds an error, the test fails. Otherwise, the test passes.

[0055] Conversely, if at step 410 the controller (e.g., multiplexer 348) determines that ECC testing is enabled, method 400 proceeds to step 414. At step 414, the controller (e.g., masking circuit 346 of auxiliary PBIST circuit 316) receives an ECC level. The ECC level may be provided by an external processor (e.g., processor 304). The ECC level may indicate the available correction level. For example, a level of '1' may indicate that one error can be corrected and two errors can be detected. As another example, a level of '2' may indicate that two errors can be corrected and three errors can be detected.

[0056] At step 416, the controller (e.g., masking circuit 346) determines whether an error exists in the first dataset. Similar to step 412 described above, the controller can determine the presence of an error. If the controller determines that there is no error in the first dataset, method 400 proceeds to step 412 to determine whether the memory test has passed or failed based on the second dataset. Conversely, if it is determined that there is no error in the first dataset, method 400 proceeds to step 418.

[0057] At step 418, the controller (e.g., masking circuit 346) masks errors in the second dataset based on ECC levels. In other words, the controller can use error correction code (ECC) levels to mask errors in the second dataset to create a masked second dataset. Masking errors may involve toggling bits in the second dataset. For example, in response to an ECC level of '1', the controller can change a single value '1' to '0'. In other instances, in response to an ECC level of '2', the controller can change two values ​​'1' to '0'. Method 400 then proceeds to step 412 to determine whether the memory test has passed or failed based on the second dataset.

[0058] The steps of method 400 can be repeated for as many datasets as possible present in the memory test. For example, method 400 can be executed as described above, writing a first dataset, generating a second dataset based on the first dataset, masking any errors, and determining whether the memory test passes. Subsequently, method 400 can be executed again using a third dataset. For example, the controller can write the third dataset to a memory cell, read the third dataset from the memory cell, generate a fourth dataset based on the third dataset, and mask errors in the fourth dataset in response to determining that the third dataset has errors.

[0059] Now for reference Figure 5A and 5BA block diagram of system 500 is shown according to various aspects of this disclosure. System 500 includes components similar to system 300 described above in FIG3, including device 502, processor 504, RAM 506, PBISTROM 510, PBIST controller 514, auxiliary PBIST circuitry 516, ATE 518, CPU bus 520, data generator 522, comparator circuitry 524, memory interface signal 530, read data signal 534, return data signal 536, expected data signal 532, first comparator block 542, and first multiplexer 548. In various instances, device 502, processor 504, RAM 506, and PBISTROM 510 may be instances of device 202, processor 204, RAM 206, and PBISTROM 210, respectively. PBIST controller 514 and auxiliary PBIST circuit 516 may be example implementations of PBIST controller 214 and auxiliary PBIST circuit 216, respectively, for performing built-in self-tests on RAM 506 and / or ROM (not shown). Therefore, data generator 522, comparator circuit 524, memory interface signal 530, read data signal 534, return data signal 536, expected data signal 532, first comparator block 542, and first multiplexer 548 may be similar to and perform similar functions to data generator 322, comparator circuit 324, memory interface signal 330, read data signal 334, return data signal 336, expected data signal 332, comparator block 342, and multiplexer 348 described above in FIG3. For simplicity, system 500 will be described below with respect to testing RAM 506.

[0060] The built-in self-test ensures the hardware integrity of RAM 506, specifically ensuring that data read from RAM 506 is identical to data written to RAM 506. System 500 can be configured to perform a built-in self-test utilizing a signature, such as a signature-based built-in self-test. A signature-based built-in self-test ensures that the performed test is the test expected using test data and memory address information provided by the test. For example, each test can be used to test different memory addresses within RAM 506 using the same test data (or to test the same memory address using different data). A signature-based built-in self-test provides a unique signature for each combination of test data and memory address. For example, the signature generated by system 500 for a first dataset read from a first memory block may be different from the signature generated for the first dataset and a second memory block. In some instances, the built-in self-test can be performed when device 502 is started (e.g., power-on or initialization). In other instances, the built-in self-test can be performed after device 502 is started. In various instances, system 500 may be used in combination with system 300 to provide enhanced built-in self-test functionality for devices (e.g., devices 202, 302, 502).

[0061] System 500 can be configured to perform built-in self-tests of RAM 506, and, when enabled, generate a unique signature for each built-in self-test performed. Processor 504 can provide an On-Demand Multiple-Input Shift Register (OMISR) mode signal 554 and a distributed comparison signal 556 to auxiliary PBIST circuitry 516. OMISR mode signal 554 and distributed comparison signal 556 can be selectable modes for configuring built-in self-test operation. OMISR mode signal 554 can enable the unique signature functionality of system 500. Distributed comparison signal 556 can indicate whether the comparison of read data signal 534 is performed by a first comparison block 542 (generating return data signal 536) or by PBIST controller 514. OMISR mode signal 554 can enable signature-based built-in self-tests when asserted. For example, when OMISR mode signal 554 has a first value (e.g., '1' or high), system 500 can perform signature-based built-in self-tests. In another instance, when the OMISR mode signal 554 has a second value (e.g., '0' or low), system 500 can perform a built-in self-test without generating a signature for each test. In some instances, when the distributed comparison signal 556 has a first value (e.g., '1' or high), system 500 can use both the return data signal 536 and the expected data signal 532 in a signature-based built-in self-test. In other instances, when the distributed comparison signal 556 has a second value (e.g., '0' or low), system 500 can use the return data signal 536 in a signature-based built-in self-test without using the expected data signal 532.

[0062] The PBIST controller 514 can communicate with RAM 506, PBIST ROM 510, and auxiliary PBIST circuitry 516. Additionally, the PBIST controller 514 may include a data generator 522, a comparison circuit 524, and a signature generator 526, each of which can communicate with RAM 506 and / or the auxiliary PBIST circuitry 516. In various embodiments, the PBIST controller 514, the comparison circuit 524, and the signature generator 526 can each communicate with the ROM of device 502 (e.g., ROM 208).

[0063] The auxiliary PBIST circuit 516 includes a first comparator block 542, a second comparator block 543, a second multiplexer 544, a third comparator block 546, and a first multiplexer 548. The first comparator block 542, the second comparator block 543, and the third comparator block 546 are similar to those described above. Figure 3A and 3B The comparison block 342 described above functions as follows. Specifically, the first comparison block 542 receives a read data signal 534 from RAM 506 and an expected data signal 532 from data generator 522. Subsequently, the first comparison block 542 performs a bitwise comparison of the two signals, as described above, to generate a return data signal 536. The comparison circuit 524 receives the return data signal 536 and determines whether the built-in self-test has passed or failed.

[0064] In addition to performing the built-in self-test, system 500 may further generate a unique signature in response to OMISR mode signal 554. The unique signature can be used to verify that the built-in self-test was performed correctly (or as expected). For example, the unique signature can be read by processor 504 and / or ATE 518 to verify that the test was performed correctly.

[0065] The second comparison block 543 can generate a first dataset as a bitwise comparison (e.g., XOR) between the returned data signal 536 and the expected data signal 532, such that each bit of the first dataset indicates whether the corresponding bit of the returned data signal 536 is different from the expected data signal 532. Therefore, the second comparison block 543 is similar to the one described above in... Figure 3A and 3B The comparison block 342 described herein functions. The result of this operation is that the first dataset is the same as the read data signal 534. In various instances, a second comparison block 543 may be used instead of the read data signal 534, for example when the auxiliary PBIST circuit 316 is inside the PBIST controller 314.

[0066] The second multiplexer 544 receives the first dataset and the return data signal 536, and can output either one based on the value of the distributed comparison signal 556. For example, when the distributed comparison signal 556 has a first value (e.g., '1' or high), the second multiplexer 544 can output the first dataset. In another instance, when the distributed comparison signal 556 has a second value (e.g., '0' or low), the second multiplexer 544 can output the return data signal 536.

[0067] The third comparison block 546 performs a bitwise comparison of the output of the second multiplexer 544 and the memory interface signal 530. In various instances, the third comparison block 546 may use a subset of the signals from the memory interface signal 530. For example, the subset of the memory interface signal 530 may include portions of the memory interface signal 530 that do not contain data to be written to RAM 506 during the built-in self-test. In some instances, the subset of signals to be used may be identified by the bit positions within the signals. That is, unused portions of the memory interface signal 530 may be received by the third comparison block 546 and ignored (e.g., blocked, unused). In other instances, the subset of signals to be used may be passed to the third comparison block 546, while unused signals may not be passed to the third comparison block 546. This comparison allows each built-in self-test signature to be unique based on the address, control, and data read during the test. For example, the data read may be the same for all addresses of RAM 506, while the subset of RAM 506 being tested may change with each test. Therefore, system 500 can distinguish between a first test testing one portion of RAM 506 and a second test testing another portion of RAM 506. For example, the first test might be designed to write data to a first block of RAM 506, and the second test might be designed to write the same data to a second block of RAM 506. System 500's signature-based built-in self-test generates a unique signature for both the first and second tests based on the written data and the data block address. Therefore, after running either test, it can be confirmed whether the first or second test was performed.

[0068] The first multiplexer 548 receives the output of the third comparator block 546 and the ROM MISR signal 550, and can output either signal as the MISR input signal 552 based on the value of the OMISR mode signal 554. For example, when the OMISR mode signal 554 has a first value (e.g., '1' or high), the first multiplexer 548 can pass the output of the third comparator block 546 as the MISR input signal 552. In another instance, when the OMISR mode signal 554 has a second value (e.g., '0' or low), the second multiplexer 544 can pass the ROM MISR signal 550 as the MISR input signal 552. The ROM MISR signal 550 may contain a ROM test MISR signature generated by the PBIST controller 514 in a conventional test mode, thereby allowing the system 500 to be compatible with unsigned self-test.

[0069] The signature generator 526 generates a deterministic signature based on the MISR input signal 552 (e.g., the output of the auxiliary PBIST circuit 516). In various instances, the signature generator 526 may be or contain data accumulated from the input stream (e.g., the MISR input signal 552) and generate a signature with N bits. In various instances, N may be 8 bits, 27 bits, 32 bits, 64 bits, 128 bits, or any other number of bits. In some instances, the signature generator 526 may perform XOR and shift operations to generate the signature. In other instances, the signature generator 526 may use a hash function to generate the signature. In various instances, the hash function may be or contain one or more of MD5, SHA-1, SHA-2, CRC32, etc. These are example implementations of the signature generator 526, and other implementations are within the scope of this disclosure. In some instances, the signature generator 526 may be implemented in hardware within the PBIST controller 514. In other instances, the signature generator 526 may be implemented in software that can be stored in PBIST ROM 510 and executed by PBIST controller 514.

[0070] Therefore, system 500 can be configured to perform signature-based built-in self-tests. Signature-based built-in self-tests provide a signature to verify that a specific built-in self-test has been performed. The signature can be compared with a known signature associated with the built-in self-test to be performed. Furthermore, system 500 can be configured to perform non-signature-based built-in self-tests, such as those currently performed in the baseline process. Additionally, signature-based built-in self-tests can be combined with ECC-aware built-in self-tests to provide enhanced testing capabilities for the device (e.g., device 502). Thus, system 500 improves the testing capabilities of the device and provides additional information about tests performed on the device and more specifically on RAM (e.g., RAM 506).

[0071] Now for reference Figure 6 Flowcharts of a method 600 for performing a signature-based built-in self-test are shown, based on various examples. In various examples, method 600 can be used to generate a signature that uniquely identifies the test, based at least on the test data and the memory address of the positive test. In various examples, method 600 can be executed by a PBIST controller (e.g., PBIST controller 514 and auxiliary PBIST circuitry 516). In various examples, method 600 can be executed by an ATE (e.g., ATE 518). Additional processes may be provided before, during, and after method 600.

[0072] At step 602, the controller (e.g., PBIST controller 514 and auxiliary PBIST circuitry 516) performs memory tests on the memory cells (e.g., RAM 506). The memory tests may be selected from multiple memory tests. Each of the multiple memory tests may differ from the others. Therefore, the steps of method 600 can verify that the correct (or expected) memory tests have been performed. The memory tests may include writing data to a first address block of the memory cell, reading data from the first address block, and comparing the read data with expected data to determine whether the test has passed or failed. Additional tests may be performed on a second address block of the memory cell to test the second address block.

[0073] At step 604, a controller (e.g., PBIST controller 514 and auxiliary PBIST circuitry 516) reads first data from a first memory address. The first memory address may be a first memory address of a first address block. The controller may read the first memory address in response to a signal sent to a memory cell (e.g., memory interface signal 530). The signal may be sent by a processor (e.g., processor 504, PBIST controller 514, ATE 518).

[0074] At step 606, the controller (e.g., the second multiplexer 544) determines whether distributed comparison is enabled. A distributed comparison signal is received from the processor, and this signal indicates the controller's operating mode. When distributed comparison is enabled, the controller operates in a first mode (e.g., performing the comparison outside the PBIST controller 514). When distributed comparison is disabled, the controller is in a second mode (e.g., performing the comparison inside the PBIST controller 514). If the controller determines that distributed comparison is enabled, method 600 proceeds to step 608. If the controller determines that distributed comparison is disabled, method 600 proceeds to step 610.

[0075] At step 608, the controller (e.g., second comparison block 543) compares the first data with the expected data. The controller may perform a bitwise comparison between the first data and the expected data. In various instances, this can be performed using an XOR operation. In other instances, other techniques may be used to perform the bitwise comparison, such as using NOT, AND, OR, or combinations thereof.

[0076] At step 610, the controller (e.g., the third comparison block 546) combines the first data with the address data of the first memory address. When distributed comparison is enabled, the comparison of the first data and the expected value is combined with the address data. When distributed comparison is disabled, the first data is combined with the address data. In some instances, the combination of data and address information can be performed using an XOR operation. In other instances, a hash algorithm can be used to combine data and address information.

[0077] At step 612, the controller (e.g., the first multiplexer 548) determines whether OMISR mode is enabled. When OMISR mode is enabled, the controller generates a signature based on the combined data and address information. That is, the controller generates a test-specific (e.g., unique) signature. When OMISR mode is disabled, the controller generates a signature using ROM signature data for addresses that are not unique to the address being read.

[0078] If the controller (e.g., the first multiplexer 548) determines that OMISR mode is disabled, method 600 proceeds to step 614. At step 614, the controller passes ROM signature data, the ROM signature value to be used in subsequent calculations. The ROM signature value may be a test signature generated when testing the ROM of the device. In some instances, the signature may be a Multiple-Input Shift Register (MISR) value.

[0079] Conversely, if the controller (e.g., the first multiplexer 548) determines that OMISR mode is enabled, method 600 proceeds to step 616. At step 616, the controller outputs combined first data and address data. The controller can use the combined value in subsequent calculations. The combined first data and address data can be used to uniquely identify the test being performed.

[0080] At step 618, the controller (e.g., signature generator 526) calculates a signature value based on the received data (e.g., data received from step 614 or step 616). In some instances, the data received from step 614 may contain a MISR value for the memory cell. In other instances, the data received from step 616 may contain a combination of first data and address data to uniquely identify the current memory test. The controller calculates the signature by combining the received data with previously received data. In some instances, a multi-input shift register may be used to calculate the signature. In other instances, a hash function may be used to calculate the signature.

[0081] At step 620, the controller (e.g., PBIST controller 514 and auxiliary PBIST circuitry 516) determines whether there is any more data to be read. The data to be read may be part of the same self-test for the memory cell. That is, the controller may continue reading data from the memory cell as part of a built-in self-test. The controller may continue reading data and calculating signatures until data from all memory addresses of the current test has been read. If the controller determines that there is more data to be read, method 600 proceeds to step 604. Conversely, if the controller determines that there is no more data to read, method 600 proceeds to step 622.

[0082] At step 622, the controller (e.g., comparison circuit 524) compares the final signature value with a value used to determine whether the first memory address has passed a memory test. For example, the final signature can be used to verify that a particular memory block has been tested by the controller. The final signature is a signature calculated after all data has been read from the memory cell. The value to be compared for the final signature may be a value pre-calculated by the controller. In other instances, the value may be a pre-calculated value stored in the ATE. In various instances, the controller may indicate a fault in response to the controller determining that the final signature identifies a memory test different from the expected memory test (e.g., a second memory test is performed when the first memory test is expected).

[0083] Now for reference Figure 7A and 7BA block diagram of system 700 is shown according to various aspects of this disclosure. System 700 includes components similar to system 300 described above in FIG3, including device 702, PBIST ROM 710, PBIST controller 714, auxiliary PBIST circuit 716, ATE 718, CPU bus 720, comparator circuit 724, memory interface signal 730, read data signal 734, return data signal 736, and multiplexer 748, the description of which will not be repeated below. In various embodiments, device 702, PBIST ROM 710, and ATE 718 may be examples of device 202, PBIST ROM 210, and ATE 218, respectively. PBIST controller 714 and auxiliary PBIST circuit 716 may be example embodiments of PBIST controller 214 and auxiliary PBIST circuit 216, respectively, for performing the built-in self-test of PBIST ROM 710. Therefore, the comparator circuit 724, memory interface signal 730, read data signal 734, return data signal 736, and multiplexer 748 are similar to and perform similar functions as the comparator circuit 324, memory interface signal 330, read data signal 334, return data signal 336, and multiplexer 348 described above in Figure 3.

[0084] PBIST controller 714 and auxiliary PBIST circuitry 716 are configured to perform a built-in self-test on PBIST ROM 710 to ensure the hardware integrity of PBIST ROM 710, specifically ensuring that the data read from PBIST ROM 710 is correct. In some instances, the built-in self-test can be performed during device 702 startup (e.g., power-on or initialization). In other instances, the built-in self-test can be performed after device 702 startup. In various instances, system 700 can be used in combination with system 300 and / or system 500 to provide enhanced built-in self-test functionality for devices (e.g., devices 202, 302, 502, 702).

[0085] Typically, the instructions for performing the built-in self-test stored in PBIST ROM 710 are finalized before the operating instructions stored in the rest of the ROM. That is, in some instances, PBIST ROM 710 may not be separate from the operating ROM (e.g., ROM 208). Therefore, performing the self-test at startup may be impossible because PBIST ROM 710 is finalized before the rest of the ROM. Therefore, system 700 uses a reverse ROM signature that is determined after all instructions for device 702 are finalized. For example, a final signature value may be determined and programmed into PBIST ROM 710. After the rest of the ROM for device 702 is finalized, a reverse ROM signature may be defined such that when combined with the last data read from PBIST ROM, the calculated signature is the same as the defined signature. This allows device 702 to perform the built-in self-test of PBIST ROM.

[0086] System 700 can be configured to perform a built-in self-test of PBIST ROM 710. PBIST controller 714 can request data to be read sequentially from all addresses of PBIST ROM 710 (including other ROM addresses). In various instances, the data read request may begin at the lowest memory address of the ROM and continue sequentially until the highest memory address of the ROM is requested (e.g., the highest memory address of PBIST ROM 710). In other instances, the data read request may begin at the highest memory address and continue sequentially until the lowest memory address is requested (e.g., the lowest memory address of the ROM). Still others, the data read request may begin at any memory address and continue until data read requests have been made for all memory addresses of the ROM. For simplicity and clarity, the following discussion will use the example of reading data from the lowest memory address to the highest memory address. Therefore, PBIST controller 714 sends the read request to PBIST ROM 710 and auxiliary PBIST circuitry 716 via memory interface signal 730. The auxiliary PBIST circuit 716 reads a memory address from a read request, determines whether the memory address is the last address (e.g., the maximum or highest address) of the PBIST ROM 710, and returns the read data from the PBIST ROM 710 to the PBIST controller 714. If the read request is for the last memory address, the auxiliary PBIST circuit 716 combines the read data with the reverse ROM signature received from the reverse ROM signature signal 752 and returns the combined data to the PBIST controller 714.

[0087] The auxiliary PBIST circuit 716 includes a detection circuit 742, a first storage element 744 (e.g., a flip-flop), a comparison block 746, a multiplexer 748, and a second storage element 750. For each read request from the PBIST controller 714, the detection circuit 742 determines whether the memory address is the last memory address (or the highest memory address). The detection circuit 742 outputs a first value (e.g., '1' or high) in response to the memory address being the last memory address, and outputs a second value (e.g., '0' or low) in response to the memory address not being the last memory address. The first storage element 744 stores the output of the detection circuit 742 while simultaneously reading data from the PBIST ROM 710. By holding the data from the detection circuit 742 in the first storage element 744, the system 700 ensures that the result of the detection circuit 742 and the read data arrive at the multiplexer 748 on the same clock cycle. In some instances, the first storage element 744 and the second storage element 750 may be or include flip-flop devices. In such instances, the flip-flops may be rising-edge triggered or falling-edge triggered.

[0088] Comparison block 746 performs a bitwise comparison (e.g., XOR operation) between read data signal 734 and inverse ROM signature signal 752, and sends the comparison to multiplexer 748. Multiplexer 748 reads the value of first storage element 744 and outputs read data signal 734 in response to the value being a second value, or outputs a modified read data signal (e.g., the comparison by comparison block 746) in response to the value being a first value. In various instances, second storage element 750 stores the value output by multiplexer 748 within one clock cycle, and signature generator 726 reads the stored value from second storage element 750.

[0089] Signature generator 726 operates similarly to signature generator 526 described above. The reverse ROM signature signal 752 provides a value that, when combined with the read data signal 734 of the last memory address, causes the signature generated by signature generator 726 to match an expected (or predefined) signature. In other words, during the design of device 702, the code in PBIST ROM 710 is finalized, and the expected signature 754 is defined. After the ROM of device 702 is finalized, a reverse ROM signature is generated such that the signature generated by signature generator 726 matches the predefined expected signature. In various instances, this may involve storing the reverse ROM signature in a read-only memory, such as a one-time programmable (OTP) fuse, electrically erasable programmable read-only memory (EEPROM), or a similar storage element.

[0090] Therefore, system 700 can be configured to perform a built-in self-test on the ROM (containing PBIST ROM 710). By defining an inverse ROM signature to be combined with the last data read of PBIST ROM 710, system 700 provides a mechanism to ultimately determine the code in PBIST ROM 710 before the remainder of the code in the ROM of device 702. Furthermore, system 700 can be combined with system 300 and / or system 500 to provide enhanced self-test capabilities.

[0091] Now for reference Figure 8 Flowcharts of a method 800 for self-testing a ROM (containing a PBIST ROM) of an execution device are shown, according to various examples. In various examples, method 800 can be used to generate a signature for verifying data stored in the ROM. In various examples, method 800 can be executed by a PBIST controller (e.g., PBIST controller 714). In other examples, method 800 can be executed by an ATE (e.g., ATE 718). Additional processes may be provided before, during, and after method 800.

[0092] At step 802, the controller (e.g., PBIST controller 714 and auxiliary PBIST circuitry 716) begins a memory test on the memory cell. The memory cell may contain a read-only memory device. In some instances, the memory cell may contain ROM instructions for the processor and ROM instructions for the controller.

[0093] At step 804, the controller initializes the signature value. The controller initializes the signature value by setting the current signature value to a starting value (e.g., '0'). In various instances, this provides a known starting point for calculating the signature. In other instances, the initialization of the signature value may be skipped, and the first calculated signature (e.g., at step 810) may overwrite the initial signature value.

[0094] At step 806, the controller reads data from the next memory address of the memory cell. If this read is the first read, the controller reads data from the first memory address of the memory cell. If this is not the first read, the controller reads data from the next address of the memory cell. In some instances, the next address may be an incrementing value (e.g., a memory address with a higher value). In other instances, the next address may be a decrementing value (e.g., a memory address with a lower value).

[0095] At step 808, the controller determines whether the memory address is the last memory address of the memory cell. The controller may compare the memory address with a known value to determine whether the memory address is the last memory address. In some instances, the last memory address may be the final memory address within the memory cell.

[0096] If the controller determines that the memory address is not the last memory cell, method 800 proceeds to step 810. At step 810, the controller calculates a signature value based on the data (e.g., data read from the memory cell). In some instances, a multi-index shift register (MISR) may be used to calculate the signature. In other instances, a hash function may be used. Method 800 may then proceed to step 806 to read more data. Method 800 may repeat steps 806, 808, and 810 to read data from the memory cells until all identified addresses have been read.

[0097] If the controller determines at step 808 that the memory address is the last memory cell, method 800 continues to step 812. At step 812, the controller generates updated data based on the read data and the reverse signature. That is, after determining that the memory address is the last memory address, the controller can generate an updated data value based on the read data and the reverse signature value.

[0098] At step 814, the controller uses the updated data to calculate the signature value. The signature value can be calculated in the same way as described above in step 810.

[0099] At step 816, the controller compares the signature value with a value used to determine whether the memory cell passes the memory test. That is, the controller compares the signature value with a value used to verify the integrity of the ROM (containing PBIST ROM 710). If the signatures match, the memory test passes; otherwise, the memory test fails.

[0100] Therefore, the described systems and methods provide enhanced built-in self-tests for IC devices. In various instances, the system can be configured to perform ECC-aware built-in self-tests. ECC-aware built-in self-tests verify the functional integrity of RAM by identifying and masking one or more errors that may occur during data reads from RAM, if present. Additionally, the system can be configured to perform signature-based built-in self-tests. Signature-based built-in self-tests provide a signature to verify that a specific built-in self-test has been performed. The signature can be compared with a known signature associated with the built-in self-test to be performed. Furthermore, the system can be configured to perform built-in self-tests of ROM (including PBIST ROM). Each of these capabilities can be used in combination with each other. For example, the system can incorporate ECC-aware self-tests, signature-based self-tests, and / or ROM self-tests.

[0101] Finally, it should be understood that any of the concepts described above may be used alone or in combination with any or all of the other concepts described above. Although various examples have been disclosed and described, it should be understood, recognized, and / or anticipated that certain modifications will fall within the scope of this disclosure. Therefore, the description is not intended to be exhaustive or to limit the principles described or illustrated herein to any precise form. In light of the foregoing teachings, many modifications and variations are possible.

Claims

1. An apparatus comprising: A memory unit that can be configured to store the first dataset; An auxiliary circuit, coupled to the memory cell, wherein the auxiliary circuit can be configured to: Receive the first dataset from the memory unit; The second dataset is generated based on the first dataset; In response to determining that the first dataset has an error, the error in the second dataset is masked using an error correction code level to produce a masked second dataset; as well as A controller, coupled to the auxiliary circuit, is configured to perform memory tests on the memory cells based on the masked second dataset received from the auxiliary circuit.

2. The apparatus according to claim 1, wherein: The memory unit can be further configured to store a third dataset; The auxiliary circuit can be further configured to: Receive the third dataset from the memory unit; The fourth dataset is generated based on the third dataset; In response to determining that the third dataset has an error, the error correction code level is used to mask the error in the fourth dataset to create a masked fourth dataset; and The controller is further configured to perform the memory test of the memory cell based on the masked fourth dataset received from the auxiliary circuitry, and to determine, based on the masked fourth dataset, that the memory cell has failed the memory test.

3. The apparatus of claim 1, wherein the auxiliary circuit comprises: An XOR circuit, configured to generate a second dataset by comparing the first dataset and the test dataset; and A masking circuit configured to receive the second dataset from the XOR circuit and use the error correction code level to generate the masked second dataset.

4. The apparatus according to claim 3, wherein: The error correction code level indicates the number of errors that can be corrected within the dataset; and The masking circuit can be configured to correct the number of errors in the first dataset that is equal to or less than the number of errors indicated by the error correction code level.

5. The apparatus of claim 4, wherein the auxiliary circuit further comprises: The selector circuit can be configured to output the second dataset or the masked second dataset based on the error correction mode enable input to the controller.

6. The apparatus according to claim 1, wherein: The memory unit can further be configured to store a third dataset; and The auxiliary circuit can be further configured to: Receive the third dataset from the memory unit; The fourth dataset is generated based on the third dataset; In response to determining that the error correction code level is not enabled, the fourth dataset is output to the controller; and The controller is further configured to perform the memory test of the memory cell based on the fourth dataset received from the auxiliary circuit.

7. The apparatus of claim 1, wherein the memory test performed by the controller is a first memory test from a plurality of memory tests, each of the plurality of memory tests being different from one another, the apparatus further comprising: A signature generator, coupled to the auxiliary circuitry and the controller, is configurable to: A signature value is calculated based on the memory address of the masked second dataset and the first dataset from the memory cell, wherein the signature value identifies the memory test from the plurality of memory tests; as well as Send the signature value to the controller; and The controller can further be configured to verify that the signature value recognizes the first memory test.

8. The apparatus of claim 7, wherein the controller is further configured to indicate a fault in response to the controller determining that the signature value identifies a second memory test from the plurality of memory tests performed based on the masked second dataset.

9. An apparatus comprising: A memory unit that can be configured to store first data at a first memory address and store second data at a second memory address; An auxiliary circuit, coupled to the memory cell, is configured to: Receive the first data and the second data from the memory unit; and The third data is generated based on the second data and the reverse signature; A controller, coupled to the auxiliary circuitry and the memory unit, is configurable to: Receive the first data and the third data from the auxiliary circuit; The multi-input shift register (MISR) value is calculated based on the first data and the third data; and The MISR value is used to determine whether the memory cell passes the memory test.

10. The apparatus of claim 9, wherein the auxiliary circuitry is further configured to identify the second memory address as the final memory address of the memory cell.

11. The apparatus of claim 9, wherein the auxiliary circuit comprises: A detection circuit configured to output a first value in response to a controller requesting first data from a first memory address, and to output a second value in response to a controller requesting second data from a second memory address; and A multiplexer coupled to the detection circuit, the multiplexer being configured to output the first data in response to receiving the first value, and to output the third data in response to receiving the second value.

12. The apparatus of claim 11, wherein the auxiliary circuit further comprises: A first flip-flop, coupled between the detection circuit and the multiplexer; and A second trigger is coupled between the multiplexer and the controller.

13. The apparatus of claim 9, wherein the memory unit comprises one or more read-only memories configured to store the reverse signature.

14. The apparatus of claim 9, wherein the controller is configured to run the memory test during device initialization.

15. A method comprising: Perform memory tests on memory cells with multiple memory addresses; The first data is received based on data read from a first memory address among the plurality of memory addresses of the memory cell; The value of the multi-input shift register (MISR) is determined based on the first data and the first memory address of the memory unit; as well as The calculated MISR value is compared with the value used to determine whether the execution of the memory test includes testing the first memory address of the memory cell.

16. The method of claim 15, wherein calculating the MISR value based on the first data and the first memory address of the memory cell occurs during the memory test performed on the memory cell.

17. The method of claim 15, further comprising comparing data from the first memory address with an expected value to generate the first data.

18. The method of claim 17, wherein performing the memory test includes determining whether the memory test is passed based on the first data.

19. The method of claim 17, wherein performing the memory test comprises: In response to identifying an error in the data from the first memory address, the first data is masked based on an error correction code level; and The test for passing the memory test is determined based on the masked first data.

20. The method of claim 15, wherein the memory unit is a random access memory unit or a read-only memory unit.

Images