Testing Read-Only Memory Using the Built-In Self-Test Controller

Abstract

A system includes a volatile storage device (106), a read-only memory (ROM) (104), a memory built-in self-test (BIST) controller (110), and a central processing unit (CPU) (102). The CPU (102) executes a first instruction from the ROM (104) upon occurrence of a reset event, causing the CPU (102) to copy instructions from a series of addresses in the ROM (104) to the volatile storage device (106). The CPU (102) also executes a second instruction from the ROM (104) to change a program counter. The CPU (102) further uses the program counter to execute the instruction from the volatile storage device (106). When executing the instruction from the volatile storage device (106), the CPU (102) causes the ROM (104) to enter a test mode and causes the memory BIST controller (110) to be configured to test the ROM (104).

Description

Background Art

[0001] Many electronic systems include a microprocessor that executes code from memory. Such systems typically include read-only memory (ROM) and random access memory (RAM). A "boot" ROM may be included in a system to store code that is executed during the boot process of the system. Many systems test the RAM and ROM during the boot process and / or during idle time after the boot process has been completed to confirm that such memory is structurally intact and that the stored data is reliable. Summary of the invention

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

[0003] In another example, a method includes: copying a plurality of instructions from a series of addresses within a read-only memory (ROM) to a volatile storage device; and changing a value of a program counter to correspond to an address within the volatile storage device at the beginning of the plurality of instructions. The method further includes executing the plurality of instructions from the volatile storage device. The instructions include instructions to change the value of the program counter to correspond to an address within the ROM following the end of the plurality of instructions within the ROM. The method also includes executing instructions within the ROM to determine whether the ROM passes a test. BRIEF DESCRIPTION OF THE DRAWINGS

[0004] Figure 1 An exemplary system for testing a ROM is illustrated.

[0005] Figure 2 The diagram illustrates copying code from ROM to RAM to execute the code from RAM to initiate testing of the ROM by a memory built-in self-test (MBIST) controller.

[0006] Figure 3 Diagram illustrating the timeline for testing a ROM using the MBIST controller.

[0007] Figure 4 Another example of a system for testing a ROM is shown.

[0008] Figure 5 is a flow chart of a method for testing a ROM. DETAILED DESCRIPTION

[0009] As described 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. In the case of, for example, automotive applications where circuits containing ROMs may be included, the contents of the ROMs need to be verified within a relatively minimum time window, especially when the ROMs are part of safety-critical circuits. For example, each time a driver turns on a car, one or more ROMs within the car may need to have their contents verified. However, the driver expects to be able to drive the car quickly after starting it and have the car operate safely.

[0010] The example described herein provides a circuit architecture for rapidly verifying the content of ROM. The architecture includes a memory built-in self-test (MBIST) controller for both the RAM and ROM of the test system. Earlier during the boot process, the central processing unit (CPU) executes an instruction from ROM, which causes the CPU to copy certain instructions from ROM to RAM (or other types of volatile storage devices). The CPU then continues to execute those specific instructions from RAM. The copied instruction executed from RAM causes the CPU to transition ROM to test mode and causes the CPU to instruct the MBIST controller to test ROM. By transferring the ROM test responsibility to the MBIST controller, the CPU can be used to perform other useful startup and initialization functions, thereby accelerating the boot process. In addition, in some systems, it is impossible to read access immediately by the CPU of ROM, which makes the test ROM slower than the possible situation of reading immediately. Further, if the CRC process is used to test ROM, the calculation cycle using the arithmetic logic unit (ALU) and register of CPU can include 10 to 15 cycles of each tested ROM position. The architecture described herein tests ROM in a more efficient and faster way. The examples described herein involve using RAM to assist in testing the ROM, but other types of volatile storage devices may be used in place of RAM (eg, registers).

[0011] Figure 1 An example of a system 100 is shown containing a CPU 102, a ROM 104, a RAM 106, and an MBIST controller 110. In one embodiment, the system 100 comprises a system-on-chip (SoC) wherein Figure 1104 is a non-temporary storage device. Although a CPU 102 is shown in this example, multiple CPUs can be included in other examples. In this example, CPU 102 can access ROM 104 via address and data bus (BUS1), and CPU 102 can access RAM 106 via different address and data bus (BUS2). CPU 102 executes the code at the memory location corresponding to program counter (PC) 103. The value of PC 103 is the address in RAM 106 or ROM 104 from which instruction is extracted, or the value is used to derive memory address (e.g., added to offset to produce the value of memory address). Similarly, MBIST controller 110 is coupled to ROM 104 and RAM 106 in a communication manner via address and data bus BUS3 and BUS4, respectively.

[0012] Executable instructions (also referred to as "code") are stored in ROM 104 and can be retrieved therefrom for execution by CPU 102. The code may include startup code that is executed upon resetting system 100 (e.g., a hard or soft reset). The startup code may cause CPU 102 to perform various initialization functions, such as configuring various registers, testing interfaces present in the system, etc. RAM 106 may be used as a scratch pad storage device for temporarily storing data or code used during runtime. Code from ROM 104 may be transferred to RAM 106 for execution from RAM 106.

[0013] RAM 106 can comprise one or more memory devices and is a dual-port memory device. Via a port 106a, CPU 102 can access RAM 106. Via another port 106b, MBIST controller 110 can access RAM 106. RAM TESTMODE signal 115 can be asserted to the first logic state so that RAM 106 is in the first execution mode (called " runtime execution mode") where CPU 102 can use RAM 106, or asserted in the second logic state so that RAM 106 is in the second mode (called " test mode") where MBIST controller 110 can access RAM. In the runtime execution mode, port 106a is active (and port 106b is inactive) to allow CPU 102 to access RAM 106 via BUS2. In test mode, port 106b is active (and port 106a is inactive) to allow MBIST controller 110 to access RAM via BUS4. When being in its test pattern, MBIST controller 110 can test RAM 106.For example, via BUS4, MBIST controller 110 can be written to RAM 106 with predefined bit pattern, and then reads RAM to confirm that read data matches and is written to the content of RAM.In an example, CPU 102 pairs of one or more control registers in MBIST controller 110 are written to trigger MBIST controller 110 and begin to test RAM 106.

[0014] ROM 104 is also a dual-port memory device and includes ports 104a and 104b. Port 104a is coupled to CPU 102 and port 104b is coupled to memory BIST controller 110. Similar to RAM 106, ROM TEST MODE 111 can be asserted to a first logic state by memory BIST controller 110 to cause ROM 104 to be in a "runtime" execution mode in which CPU 102 can access ROM 104 (e.g., to extract code), or asserted in a second logic state to cause ROM 104 to be in a "test mode" in which MBIST controller 110 can access ROM. In the runtime execution mode, port 104a is active (and port 104b is inactive) to allow CPU 102 to access ROM 104 via BUS1. In the test mode, port 104b is active (and port 104a is inactive) to allow MBIST controller 110 to access ROM 104 via BUS3.

[0015] To test ROM 104, execute Figure 2 The example procedure described in . Figure 2, showing the contents of at least portions of ROM 104 and RAM 106. ROM 104 includes executable code 202, 204, 206, 208, 210, and 212. Code 202 and 212 include functional ROM code to assist in booting the system and to assist in operating the system during runtime (e.g., providing access to low-level hardware components on behalf of higher-level applications). During the boot process, CPU 102 begins executing functional ROM code 202 starting, for example, with ROM_ADDR_0. That is, program counter 103 is loaded with a value corresponding to ROM_ADDR_0 and CPU 102 begins executing instructions at that address within ROM. PC 103 is incremented for each code instruction (or group of instructions) fetched from ROM 104.

[0016] PC 103 will ultimately be a value corresponding to the location of code 204 within ROM 104. Code 204 includes instructions that cause CPU 102 to copy 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, as shown by the dashed lines. The portion of RAM 106 used to receive ROM code 208 is the otherwise unused portion 220 of RAM. ROM code 208 received in RAM 106 is copied to the RAM 106 at the address range between ROM_ADDR_b and ROM_ADDR_c. Figure 2 It is shown as RAM code 222.

[0017] Once the ROM code 208 is copied to the 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 the ROM 104). The CPU 102 then executes the instructions of the ROM code 208, but executes a copy of those instructions from the RAM (code 222). The instructions include instructions 208a to 208d. Instruction 208a causes the CPU 102 to configure the ROM 104 for the test mode. In one example, configuring the ROM 104 for the test mode includes the memory BIST controller 110 asserting the ROM TEST MODE signal 111 ( Figure 1) asserts to cause ROM 104 to enter the logic state of its test mode that wherein enables its port 104b (and disables port 104a).Then execution instruction 208b causes CPU 102 to configure MBIST controller 110 to test ROM 104.In an example, CPU 102 writes one or more control registers in MBIST controller 110 to trigger MBIST controller 110 to start testing ROM 104.Any suitable non-volatile memory test process can be used for testing ROM 104.

[0018] CPU 102 then executes instruction 208c so that CPU 102 enters pause state to wait for MBIST controller 110 to complete its test to ROM 104. Once MBIST controller 110 completes its ROM test process, MBIST controller 110 just can assert the interruption to CPU 102 to complete ROM test signaling to CPU.CPU 102 exits pause state and then executes instruction 208d, instruction 208d causes CPU 102 to take ROM 104 out of its test mode and put into the runtime execution mode to allow CPU 102 to retrieve the instruction from ROM via port 104a once more thereby.MBIST controller can implement this action, and described MBIST controller changes the logic state of ROM TEST MODE signal 111 to the corresponding logic state with wherein enabling port 104a and the runtime execution mode of disabling port 104b. Instruction 208e from RAM 106 is then executed, causing the CPU to change PC 103 to a value corresponding to ROM_ADDR_d, which is the ROM address following the code 208 previously copied to RAM 106 .

[0019] MBIST controller 110 comprises ROM status register 117, and ROM status register 117 contains the value of the result of indication ROM test.In an example, ROM status register comprises pass / fail indication.When the PC 103 of new change returns to the value corresponding to ROM_ADDR_d, CPU 102 then extracts instruction from ROM 104 rather than RAM 106.Therefore instruction 210 is through extracting and causes CPU 102 to check the result of the ROM test of MBIST status register 117.If ROM 104 has passed its test, instruction 210 further can cause code execution to continue in functional ROM code 212 so.If ROM 104 does not pass its test really, instruction 210 can initiate error response so.The example of error response comprises generation interruption to CPU 102, assertion output signal etc. by error state machine.

[0020] Figure 3An example of a timeline illustrating how to test ROM 104 is provided. After RAM 106 is tested by MBIST controller 110 (and thus Figure 3 In the example of , RAM TEST MODE signal 115 is in a logic state such as logic "0") before or after, ROM TEST MODE signal 111 is in a logic state corresponding to the runtime execution mode of the ROM ( Figure 3 106. In the embodiment of the present invention, the ROM code 208 of the present invention is copied to the ROM 104 by the ROM TEST MODE signal 111. The ROM code 208 of the present invention is copied to the ROM 104 by the MBIST controller 110. The ROM code 208 of the present invention is copied to the ROM 104 by the ROM TEST MODE signal 1 ...MBIST controller 110. The ROM code 208 of the present invention is copied to the ROM 104 by the ROM TEST MODE signal 111. At 313 , ROM TEST MODE signal 111 is then asserted back to its previous state, where ROM 104 is put back into its runtime execution mode so that code extraction can continue from ROM 104 and be executed by CPU 102 at 312 .

[0021] Figure 4 4 is an example architecture of a system 400 that implements the ROM test paradigm explained above. The example system 400 includes a CPU 402 (which may include an ARM core), a boot ROM 404, a RAM 406, and an MBIST controller 410. Figure 4 In the example of the system 400, the system 400 also includes additional components, such as a direct memory access (DMA) controller 412, an additional ROM 428, and a hardware CRC 420. The CPU 402, DMA 412, MBIST controller 410, hardware CRC 420, ROM 428, and RAM 406 are coupled together via a bus 405. In one example, the bus 405 includes an Advanced eXtensible Interface (AXI), but may be consistent with other standards in other embodiments. The boot ROM 404 (which contains Figure 2 4 (ROM code shown in FIG. 1 ) is coupled to CPU 402 via tightly coupled memory (TCM) interfaces (ITCM and DTCM). MBIST controller 410 is coupled to boot ROM 404, ROM 428 and RAM 406 via interfaces 413, 425 and 427, respectively, as shown. Figure 1The operations performed by the ROM 104 and RAM 106 are performed by the CPU 402 and the MBIST controller 410 with respect to Figure 4 ROM 404 and RAM 406 execute.

[0022] Figure 5 A flow chart of a method according to an example is shown. The operations may be performed in the order shown or in a different order. In addition, the operations may be performed sequentially, or two or more of the operations may be performed simultaneously.

[0023] At 502, a reset event occurs. The power supply of system 100, 400 may be enabled or a soft or hard reset event may occur. At 504, the CPU begins to execute code from ROM (e.g., ROM 104, ROM 404). One of the ROM instructions causes the CPU to copy a portion of the code of ROM to RAM at 506. At 508, PC is changed to an address corresponding to the beginning of the copied ROM code in RAM. The CPU then begins to execute the copied code from RAM, and in doing so, ROM is configured to test mode at 510. At 512, an MBIST controller (e.g., MBIST controller 110, 410) is configured by the CPU to test ROM, and the MBIST controller then begins to test ROM (514).

[0024] CPU waits for MBIST controller to complete ROM test at 516 places.Once complete ROM test, at 518 places, ROM is configured back to its runtime execution mode to allow CPU to continue to extract instructions from ROM.PC is changed to the address (520) after previously copied ROM code in ROM.At 522 places, method comprises determining whether ROM has passed test.This operation may include the value (for example, pass / fail flag) in CPU reading register.If ROM has passed its test, method continues at 526 places, wherein completes startup process and system enters its runtime environment (for example, performs one or more runtime applications).But, if determine that ROM does not pass its test, at 524 places, handle ROM error in suitable manner (for example, manner described above).

[0025] In this description, the term "couple" or "couples" means an indirect or direct wired or wireless connection. Thus, if a first device couples to a second device, the connection may be through a direct connection or through an indirect connection via other devices and connections. The statement "based on" means "based at least in part on." Thus, if X is based on Y, X may vary with Y and any number of additional factors.

[0026] Modifications are possible in the described embodiments, and other embodiments are possible within the scope of the claims.

Claims

1. A memory system, wherein include: a volatile storage device; a read-only memory ROM configured to store instructions; Memory built-in self-test controller; and A central processing unit CPU, which is configured to, upon occurrence of an initialization event: executing a first instruction from the ROM to cause the CPU to copy a plurality of instructions from a series of addresses in the ROM to the volatile storage device; executing a second instruction from the ROM to change the value of the program counter to correspond to an address within the volatile storage device at the beginning of the plurality of instructions; executing the plurality of instructions from the volatile storage device using the program counter, the CPU, when executing the plurality of instructions, causing the ROM to enter a test mode and causing the memory built-in self-test controller to be configured to test the ROM, the plurality of instructions including instructions to change the value of the program counter to an address in the ROM corresponding to an address in the ROM after an end of the plurality of instructions in the ROM after the ROM test; and Instructions from the ROM are executed to determine whether the ROM passes a test performed by the memory built-in self-test controller.

2. The memory system according to claim 1, in: The ROM has a first port coupled to the CPU and the ROM has a second port coupled to the memory built-in self-test controller; and When the CPU causes the ROM to enter the test mode, the ROM disables the first port and enables the second port.

3. The memory system of claim 1, wherein the CPU, when executing the plurality of instructions, further causes the ROM to exit the test mode.

4. The memory system according to claim 3, wherein the CPU, when executing the plurality of instructions, causes the ROM to exit the test mode upon completion of the test of the ROM by the memory built-in self-test controller.

5. The memory system of claim 3, wherein upon causing the ROM to exit the test mode, a first port of the ROM is enabled and a second port thereof is disabled.

6. The memory system of claim 1, wherein the CPU, when executing the plurality of instructions, further causes the CPU to again change the program counter to a new value corresponding to an address in the ROM.

7. The memory system of claim 6, wherein the new value of the program counter corresponds to a ROM address following the series of addresses of the plurality of instructions.

8. A read-only memory ROM storing instructions which, when executed by a central processing unit (CPU), cause the CPU to perform the following operations: executing a first instruction to copy a plurality of instructions from a series of addresses in the ROM to a volatile storage device; executing a second instruction from the ROM to change a program counter to an address corresponding to an address in the volatile storage device at the beginning of the plurality of instructions; executing the plurality of instructions from the volatile storage device using the program counter and, when executing the plurality of instructions, causing the ROM to enter a test mode and causing a memory built-in self-test controller to be configured to test the ROM, the plurality of instructions including instructions to change a value of the program counter to correspond to an address in the ROM after the ROM test that is subsequent to an end of the plurality of instructions in the ROM; and Instructions from the ROM are executed to determine whether the ROM passes a test performed by the memory built-in self-test controller.

9. The ROM of claim 8, wherein the plurality of instructions to be copied to the volatile storage device include instructions to cause the ROM to disable a port to be coupled to the CPU, and to cause the ROM to enable a port to be coupled to the memory built-in self-test controller.

10. The ROM of claim 8, wherein the plurality of instructions to be copied to the volatile storage device include instructions to cause the memory built-in self-test controller to be configured to test the ROM.

11. The ROM according to claim 8, wherein the plurality of instructions to be copied to the volatile memory device include instructions to cause the CPU to wait for the memory built-in self-test controller to complete the test of the ROM.

12. The ROM of claim 8, wherein the plurality of instructions to be copied to the volatile storage device include instructions to cause the ROM to enable a port to be coupled to the CPU and disable a port to be coupled to the memory built-in self-test controller.

13. The ROM according to claim 8, wherein the plurality of instructions to be copied to the volatile memory device include instructions to change the program counter to correspond to an address in the ROM following the plurality of instructions.

14. A method for memory operation, wherein include: executing a first instruction to copy a plurality of instructions from a series of addresses in a read-only memory ROM to a volatile storage device; executing a second instruction from the ROM to change the value of the program counter to correspond to an address within the volatile storage device at the beginning of the plurality of instructions; executing the plurality of instructions from the volatile storage device, causing the ROM to enter a test mode and causing a memory built-in self-test controller to be configured to test the ROM, the plurality of instructions including instructions to change the value of the program counter to an address in the ROM corresponding to an address in the ROM after an end of the plurality of instructions in the ROM after the ROM test; and Instructions within the ROM are executed to determine whether the ROM passes the test.

15. The method of claim 14, further comprising performing the test on the ROM by the memory built-in self-test controller.

16. The method of claim 14, wherein executing the plurality of instructions from the volatile memory device comprises disabling a first port of the ROM coupled to a central processing unit and enabling a second port of the ROM coupled to the memory built-in self-test controller.

17. The method of claim 16, further comprising enabling the first port of the ROM and disabling the second port upon completion of the testing of the ROM.

18. The method of claim 14, wherein executing the plurality of instructions from the volatile storage device comprises waiting for the memory built-in self-test controller to test the ROM.

Images