Testing read-only memory using memory built-in self-test controller

Abstract

The system includes a volatile storage device (106), a read-only memory (ROM, 104), a memory embedded self-test (BIST) controller (110), and a central processing unit (CPU, 102). When a reset event occurs, the CPU (102) executes a first instruction from the ROM (104) to cause the CPU (102) to copy instructions from a range of addresses within the ROM (104) to the volatile storage device (106). The CPU (102) also executes a second instruction from the ROM (104) to change the program counter. The CPU (102) executes further instructions from the volatile storage device (106) using the program counter. When the CPU (102) executes instructions from the volatile storage device (106), the ROM (104) is configured to enter a test mode, and the memory BIST controller (110) is configured to test the ROM (104).

Description

Background Technology

[0001] Many electronic systems include microprocessors that execute code from memory. These systems often include read-only memory (ROM) and random access memory (RAM). A "boot" ROM may be included in the system to store code executed during the boot process for the system. Many systems test RAM and ROM during the boot process and / or during idle time after the boot process is complete to verify that such memories are structurally intact and that the stored data is reliable.

[0002] In one example, the system includes a volatile storage device, read-only memory (ROM), a built-in self-test (BIST) controller, and a central processing unit (CPU). When a reset event occurs, the CPU executes a first instruction from the ROM to cause the CPU to copy multiple instructions from a range of addresses within the ROM to the volatile storage device. The CPU also executes a second instruction from the ROM to change the program counter. The CPU uses the program counter to further execute multiple instructions from the volatile storage device. When the CPU executes multiple instructions from the volatile storage device, the ROM enters test mode and the memory BIST controller is configured to test the ROM.

[0003] In another example, the method includes the steps of copying a plurality of instructions from a range of addresses in read-only memory (ROM) to a volatile storage device, and changing the value of a program counter to correspond to an address in the volatile storage device at the beginning of the plurality of instructions. The method further includes the step of executing a plurality of instructions from the volatile storage device. The instructions include an instruction to change the value of a program counter to correspond to an address in the ROM that follows at the end of the plurality of instructions in the ROM. The method also includes the step of executing an instruction in the ROM to determine whether the ROM has passed a test. Brief explanation of the drawing

[0004] Figure 1 shows an exemplary system for testing a ROM. Figure 2 shows the copying of code for execution from ROM to RAM to start a test of ROM by a memory-embedded self-test (MBIST) controller. Figure 3 shows a timeline for testing a ROM using an MBIST controller. Figure 4 shows another example of a system for testing a ROM. Figure 5 is a flowchart of a method for testing a ROM. Specific details for implementing the invention

[0005] As mentioned above, the contents of the ROM are verified during the boot process. Cyclic Redundancy Check (CRC) techniques are often used to verify the contents of the ROM. CRC techniques are time-consuming, and some applications may have strict timing requirements. For example, in the case of automotive applications that may include circuitry containing ROM, the contents of the ROM need to be verified within a relatively short time window, especially when the ROM is part of a safety-critical circuit. For instance, whenever a driver turns on the vehicle, one or more ROMs within the vehicle may need to have their contents verified. However, the driver expects to be able to drive the vehicle immediately after starting it and ensure that the vehicle operates safely.

[0006] The examples described herein provide a circuit architecture for rapidly verifying the contents of ROM. The architecture includes a Memory Embedded Self Test (MBIST) controller that tests both the RAM and ROM of the system. Early in the boot process, the central processing unit (CPU) executes instructions from ROM that cause the CPU to copy specific instructions from ROM to RAM (or other types of volatile storage devices). The CPU then continues the execution of those specific instructions from RAM. The copied instructions executed from RAM cause the CPU to switch the ROM to test mode and instruct the CPU to instruct the MBIST controller to test the ROM. By offloading the responsibility for testing the ROM to the MBIST controller, the CPU can perform other useful booting and initialization functions, thereby accelerating the boot process. Additionally, in some systems, back-to-back read access to the ROM by the CPU is not possible, which causes the ROM to be tested more slowly than when back-to-back reads are possible. Additionally, if a CRC process is used to test the ROM, calculation cycles using the Arithmetic Logic Unit (ALU) and CPU registers may include 10 to 15 cycles per ROM location being tested. The architecture described herein tests the ROM in a more efficient and faster manner. While the examples described herein relate to using RAM to assist in testing the ROM, other types of volatile storage devices (e.g., registers) may be used instead of RAM.

[0007] FIG. 1 illustrates an example of a system (100) comprising a CPU (102), ROM (104), RAM (106), and an MBIST controller (110). In one embodiment, the system (100) comprises a system-on-chip (SoC) in which the components shown in FIG. 1 are manufactured on a common semiconductor die. The ROM (104) is a non-transient storage device. In this example, one CPU (102) is shown, but in other examples, multiple CPUs may be included. In this example, the CPU (102) can access the ROM (104) via an address and data bus (BUS1), and the CPU (102) can access the RAM (106) via a different address and data bus (BUS2). The CPU (102) executes code located at a memory location corresponding to a program counter (PC) (103). The value of PC (103) is an address in RAM (106) or ROM (104) to fetch an instruction, or the value is used to derive a memory address (e.g., a value added to an offset to generate a memory address). Similarly, the MBIST controller (110) is coupled to the ROM (104) and RAM (106) so as to communicate with each other via address and data buses (BUS3 and BUS4).

[0008] Executable instructions (also referred to as “code”) are stored in ROM (104) and can be retrieved from therefor for execution by CPU (102). The code may include boot code that is executed upon a reset of the system (100) (e.g., a hard or soft reset). The boot code may enable the CPU (102) to perform various initialization functions, such as configuring various registers and testing interfaces present in the system. RAM (106) may be used as a scratchpad storage for the temporary storage of data or code used during runtime. Code from ROM (104) may be transferred to RAM (106) for execution from RAM (106).

[0009] RAM (106) may include one or more memory devices and is a dual-port type memory device. Through one port (106a), the CPU (102) can access RAM (106). Through the other port (106b), the MBIST controller (110) can access RAM (106). The RAM test mode signal (115) may be asserted to a first logic state to allow RAM (106) to be in a first execution mode (referred to as "runtime execution mode") in which the CPU (102) can use RAM (106), or asserted to a second logic state to allow RAM (106) to be in a second mode (referred to as "test mode") in which the MBIST controller (110) can access RAM. In runtime execution mode, port (106a) is active (and port (106b) is inactive), allowing the CPU (102) to access RAM (106) via BUS2. In test mode, port (106b) is active (and port (106a) is inactive), allowing the MBIST controller (110) to access RAM via BUS4. While in test mode, the MBIST controller (110) can test RAM (106). For example, via BUS4, the MBIST controller (110) can write a predefined bit pattern to RAM (106) and then read RAM to verify that the read data matches what was written to RAM. In one example, the CPU (102) triggers the MBIST controller (110) to start testing RAM (106) by writing one or more control registers to the MBIST controller (110).

[0010] The ROM (104) is also a dual-port type memory device and includes ports (104a and 104b). Port (104a) is coupled to the CPU (102) and port (104b) is coupled to the memory BIST controller (110). Similar to RAM (106), the ROM test mode (111) may be declared as a first logic state by the memory BIST controller (110) to allow the ROM (104) to be in a "runtime" execution mode where the CPU (102) can access the ROM (104) (e.g., to fetch code), or it may be declared as a second logic state to allow the ROM (104) to be in a "test mode" where the MBIST controller (110) can access the ROM. In runtime execution mode, port (104a) is active (and port (104b) is inactive) to allow the CPU (102) to access the ROM (104) via BUS1. In test mode, port (104b) is active (and port (104a) is inactive) to allow the MBIST controller (110) to access the ROM (104) via BUS3.

[0011] To test the ROM (104), the exemplary procedure described in FIG. 2 may be performed. In FIG. 2, at least some of the contents of the ROM (104) and RAM (106) are illustrated. The ROM (104) contains executable code (202, 204, 206, 208, 210, and 212). The code (202 and 212) contains functional ROM code that assists in booting the system as well as assists in operating the system during runtime (e.g., providing access to lower-level hardware components on behalf of higher-level applications). During the boot process, the CPU (102) begins executing the functional ROM code (202), for example, starting at ROM_ADDR_0. That is, the value corresponding to ROM_ADDR_0 is loaded into the program counter (103), and the CPU (102) begins executing instructions at that address within the ROM. PC (103) is incremented for each code instruction (or group of instructions) fetched from ROM (104).

[0012] PC (103) is ultimately a value corresponding to the location of the code (204) within the ROM (104). The code (204) includes instructions that cause the CPU (102), as illustrated by the dotted lines, to copy the ROM code (208) from addresses in the range between ROM_ADDR_b and ROM_ADDR_c to RAM addresses in the range between RAM_ADDR_x and RAM_ADDR_y. The portion of RAM (106) used to receive the ROM code (208) is another unused portion (220) of the RAM. The ROM code (208) received in the RAM (106) is illustrated as the RAM code (222) in FIG. 2.

[0013] Once the ROM code (208) is copied to RAM (106), the PC is incremented again to ROM_ADDR_a. The code at that location causes the CPU (102) to change the PC (103) to a value corresponding to the RAM address RAM_ADDR_x (the starting address of the RAM code (222) containing the code (208) from ROM (104). The CPU (102) then executes the instructions of the ROM code (208), but executes a copy of those instructions (code 222) from RAM. The instructions include instructions (208a-208d). Instruction (208a) causes the CPU (102) to configure the ROM (104) for test mode. In one example, configuring the ROM (104) for test mode involves the memory BIST controller (110) declaring the ROM test mode signal (111) (Fig. 1) as a logic state, which causes the ROM (104) to enter its test mode in which its port (104b) is enabled (and port (104a) is disabled). Instruction (208b) is then executed to cause the CPU (102) to configure the MBIST controller (110) to test the ROM (104). In one example, the CPU (102) writes one or more control registers to the MBIST controller (110) to trigger the MBIST controller (110) to start testing the ROM (104). Any suitable non-volatile memory test process may be used to test the ROM (104).

[0014] Next, the CPU (102) executes an instruction (208c) to cause the CPU (102) to enter a paused state to wait for the MBIST controller (110) to complete the test of the ROM (104). When the MBIST controller (110) completes its ROM test process, the MBIST controller (110) may declare an interrupt to the CPU (102) to signal to the CPU that the ROM test is complete. The CPU (102) exits the paused state and then executes an instruction (208d) to cause the CPU (102) to take the ROM (104) out of its test mode and enter a runtime execution mode, thereby allowing the CPU (102) to retrieve instructions from the ROM again through the port (104a). This operation can be implemented by an MBIST controller that changes the logic state of the ROM test mode signal (111) to a logic state corresponding to a runtime execution mode in which port (104a) is enabled and port (104b) is disabled. Next, an instruction (208e) from RAM (106) is executed, which causes the CPU to change the PC (103) to a value corresponding to ROM_ADDR_d, which is a ROM address that follows the code (208) previously copied to RAM (106).

[0015] The MBIST controller (110) includes a ROM status register (117) containing a value indicating the result of a ROM test. In one example, the ROM status register includes a pass / fail indication. When the newly changed PC (103) is set back to the value corresponding to ROM_ADDR_d, the CPU (102) fetches instructions from the ROM (104) instead of the RAM (106). Thus, the instruction (210) is fetched and causes the CPU (102) to check the MBIST status register (117) for the result of the ROM test. The instruction (210) can also cause code execution to continue in the functional ROM code (212) if the ROM (104) passes the test. If the ROM (104) does not pass the test, the instruction (210) can initiate an error response. Examples of error responses include the generation of an interrupt to the CPU (102) and the declaration of an output signal by an error state machine.

[0016] FIG. 3 provides an example of a timeline showing how the ROM (104) is tested. Before or after the RAM (106) is tested by the MBIST controller (110) (thus, the RAM test mode signal (115) is in a logic state such as logic "0" in one example of FIG. 3), the ROM test mode signal (111) is in a logic state (as shown as 302, "0" in FIG. 3) corresponding to the runtime execution mode of the ROM, so that the CPU (102) can fetch code from the ROM (104) for execution. In 306, the code (208) is copied from the ROM (104) to the RAM (106) by the CPU (102). Next, the logic state of the ROM test mode signal (111) is changed to a state (logic "1" in this example) that places the ROM (104) in test mode to allow the MBIST controller (110) to access port (104b) for testing purposes. The copied ROM code (208) (now in RAM (106)) is executed from RAM. The copied ROM code (208) causes the CPU (102) to perform the actions described above, such as configuring the MBIST controller (110) to test the ROM (104). Then, at 313, the ROM test mode signal (111) is declared back to the previous state in which the ROM (104) is placed back into its runtime execution mode so that code fetching can continue from the ROM (104) and execution by the CPU (102) can continue.

[0017] FIG. 4 is an exemplary architecture of a system (400) implementing the aforementioned ROM test paradigm. The exemplary system (400) includes a CPU (402) (which may include an ARM core), a boot ROM (404), RAM (406), and an MBIST controller (410). The exemplary system (400) of FIG. 4 also includes additional components such as Direct Memory Access (DMA), a controller (412), additional ROMs (428), and a hardware CRC (420). The CPU (402), DMA (412), MBIST controller (410), hardware CRC (420), ROMs (428), and RAM (406) are connected together via a bus (405). In one example, the bus (405) includes an Advanced Extensible Interface (AXI), but in other implementations, it may conform to other standards. The boot ROM (404) (containing the ROM code shown in FIG. 2) is coupled to the CPU (402) via TCM (Tightly Coupled Memory) interfaces (ITCM and DTCM). The MBIST controller (410) is coupled to the boot ROM (404), ROMs (428), and RAM (406) via respective interfaces (413, 425, and 427) as shown. The operations performed by the CPU (102) and MBIST controller (110) for the ROM (104) and RAM (106) of FIG. 1 are performed by the CPU (402) and MBIST controller (410) for the ROM (404) and RAM (406) of FIG. 4.

[0018] FIG. 5 shows a flowchart of a method according to an example. The operations may be performed in the illustrated order or in a different order. Additionally, the operations may be performed sequentially, or two or more of the operations may be performed simultaneously.

[0019] In block (502), a reset event occurs. Power to the system (100, 400) may be enabled, or a soft or hard reset event may occur. In block (504), the CPU begins executing code from the ROM (e.g., ROM (104), ROM (404)). One of the ROM instructions in block (506) causes the CPU to copy a portion of the code from the ROM to RAM. In block (508), the PC is modified to correspond to an address in RAM that corresponds to the start of the copied ROM code. Then, the CPU begins executing the code copied from RAM, and in doing so, configures the ROM to test mode in block (510). An MBIST controller (e.g., MBIST controller (110, 410)) is configured by the CPU to test the ROM in block (512), and the MBIST controller then begins testing the ROM (block (514)).

[0020] The CPU waits in block (516) for the MBIST controller to complete the ROM test. When the ROM test is completed, in block (518), the ROM is reconfigured into its runtime execution mode to allow the CPU to continue fetching instructions from the ROM. The PC is changed to an address within the ROM that follows the previously copied ROM code (block (520)). In block (522), the method includes a step of determining whether the ROM has passed the test. This operation may include the CPU reading a value in a register (e.g., a pass / fail flag). If the ROM has passed the test, the method continues in block (526), ​​where the boot process is completed and the system enters its runtime environment (e.g., one or more runtime applications are executed). However, if it is determined that the ROM has not passed the test, in block (524), the ROM error is handled in an appropriate manner as previously described.

[0021] In this description, the term “couple” (or “couples”) means either an indirect or direct wired or wireless connection. Thus, when a first device couples to a second device, such connection may be made through a direct connection or through an indirect connection via other devices and connections. The description “based on” means “based at least partially on”. Thus, where X is based on Y, X may be a function of Y and any number of other factors.

[0022] Within the scope of the claims, modifications to the described embodiments are possible, and other embodiments are possible.

Claims

Claim 1 A system comprising: a volatile storage device; a read-only memory (ROM) configured to store a first set of instructions and a second set of instructions; a built-in self-test (BIST) controller; and a central processing unit (CPU), wherein the CPU: executes the first set of instructions stored in the ROM to copy the second set of instructions in the ROM to the volatile storage device; executes the second set of instructions from the volatile storage device to instruct the memory BIST controller to perform a test operation on the ROM; and is configured to continue executing the second set of instructions from the volatile storage device simultaneously with the memory BIST controller performing the test operation. Claim 2 A system according to claim 1, wherein the CPU is further configured to instruct the ROM to exit test mode. Claim 3 A system according to paragraph 2, wherein the CPU is further configured to instruct the ROM to terminate the test mode when the memory BIST controller completes the test operation of the ROM. Claim 4 A system according to paragraph 2, wherein the CPU is further configured to instruct the ROM to enable the first port of the ROM and disable the second port of the ROM. Claim 5 A system according to claim 1, wherein the CPU is further configured to change a program counter to a new value corresponding to an address in the ROM. Claim 6 In paragraph 5, the new value of the program counter corresponds to a ROM address that follows the range of addresses of the second set of instructions, in a system. Claim 7 In paragraph 6, the system is further configured such that the CPU determines whether the ROM has passed its test by the memory BIST controller. Claim 8 A system comprising: a volatile storage device; a read-only memory (ROM) configured to store a plurality of instructions; a memory embedded self-test (BIST) controller configured to test the ROM in response to one of the plurality of instructions; and a central processing unit (CPU), wherein the CPU: in response to an initialization event, copies the plurality of instructions in the ROM to the volatile storage device; instructs the ROM to enter a test mode and the memory BIST controller to be configured to test the ROM; and is configured to execute the plurality of instructions from the volatile storage device simultaneously with the memory BIST controller testing the ROM, wherein the ROM has a first port coupled to the CPU and the ROM has a second port coupled to the memory BIST controller, and when the CPU instructs the ROM to enter the test mode, the ROM disables the first port and enables the second port. Claim 9 In claim 8, the system is further configured such that the CPU instructs the ROM to exit the test mode when the memory BIST controller completes testing of the ROM. Claim 10 A system according to claim 8, wherein the CPU is further configured to instruct the ROM to enable the first port of the ROM and disable the second port of the ROM. Claim 11 In claim 8, the system is further configured such that the CPU changes the program counter to a new value corresponding to an address in the ROM. Claim 12 In claim 11, the system, wherein the new value of the program counter corresponds to a ROM address following the range of addresses of the plurality of instructions. Claim 13 In paragraph 12, the system is further configured such that the CPU determines whether the ROM has passed its test by the memory BIST controller. Claim 14 A method comprising: executing a first set of instructions stored in a read-only memory (ROM) to copy a second set of instructions in the ROM to a volatile storage device; executing the second set of instructions from the volatile storage device to instruct a memory embedded self-test (BIST) controller to perform a test operation on the ROM; and continuing to execute the second set of instructions from the volatile storage device simultaneously with the memory BIST controller performing the test operation. Claim 15 A method according to claim 14, further comprising the step of instructing to disable the first port of the ROM coupled to the central processing unit and to enable the second port of the ROM coupled to the memory BIST controller. Claim 16 A method according to claim 15, further comprising the step of instructing the ROM to enable the first port of the ROM and disable the second port of the ROM upon completion of the test operation of the ROM. Claim 17 A method comprising: copying a plurality of instructions in a read-only memory (ROM) to a volatile storage device in response to an initialization event; instructing the ROM to enter a test mode; configuring a memory embedded self-test (BIST) controller to test the ROM; executing the plurality of instructions from the volatile storage device by a central processing unit while simultaneously testing the ROM by the memory BIST controller; and instructing to disable a first port of the ROM coupled to the central processing unit and to enable a second port of the ROM coupled to the memory BIST controller. Claim 18 A method according to claim 17, further comprising the step of instructing the ROM to enable the first port of the ROM and disable the second port of the ROM upon completion of testing the ROM.

Images