Testing read only memory using built-in self-test controller
By copying ROM instructions to RAM during startup and testing ROM with BIST controller, the problem of time-consuming verification of ROM in the prior art is solved, and the rapid verification and acceleration of the startup process is achieved.
Patent Information
- Application Number
- CN202510671854.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Priority Date
- 2019-02-08
- Filing Date
- 2019-10-29
- Publication Date
- 2025-08-29
AI Technical Summary
The prior art takes a long time to verify read-only memory (ROM), especially in systems with strict timing requirements, such as when a car starts, it is difficult to quickly verify the content of the ROM within the minimum time window.
By copying the ROM's instructions to a volatile storage device such as RAM during the startup process, and testing the ROM with a built-in self-test (BIST) controller for the memory, the burden on the CPU is reduced and the testing responsibility is quickly transferred to the BIST controller, thereby speeding up the startup process.
It realizes rapid verification of ROM content during startup, reduces startup time, meets strict timing requirements, and improves testing efficiency.
Smart Images
Figure CN120564804A_ABST
Abstract
Description
[0001] Divisional application information
[0002] This application is a divisional application of the invention patent application with the application date of October 29, 2019, application number "201980070484.8", and invention name "Testing Read-Only Memory Using Built-in Self-Test Controller". Technical Field
[0003] The present disclosure relates generally to semiconductor memories and methods, and more particularly to testing read-only memories using a built-in self-test controller. Background Art
[0004] 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 system's boot process. Many systems test the RAM and ROM during the boot process and / or during idle time after the boot process has completed to confirm that such memory is structurally intact and that the stored data is reliable. Summary of the Invention
[0005] In one example, a system includes a volatile memory device, a read-only memory (ROM), a memory built-in self-test (BIST) controller, and a central processing unit (CPU). Upon a reset event, the CPU executes a first instruction from the ROM to cause the CPU to copy multiple instructions from a range of addresses in the ROM to the volatile memory 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 memory device. When executing the multiple instructions from the volatile memory device, the CPU causes the ROM to enter a test mode and causes the memory BIST controller to be configured to test the ROM.
[0006] In another example, a method includes: copying a plurality of instructions from a range of addresses within a read-only memory (ROM) to a volatile memory device; and changing a value of a program counter to an address within the volatile memory device corresponding to the beginning of the plurality of instructions. The method further includes executing the plurality of instructions from the volatile memory device. The instructions include instructions to change the value of the program counter to an address within the ROM that follows the end of the plurality of instructions within the ROM. The method also includes executing the instructions within the ROM to determine whether the ROM passes a test. BRIEF DESCRIPTION OF THE DRAWINGS
[0007] Figure 1 An exemplary system for testing a ROM is illustrated.
[0008] 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.
[0009] Figure 3 Illustrate the timeline for testing a ROM using the MBIST controller.
[0010] Figure 4 Another example of a system for testing a ROM is shown.
[0011] Figure 5 is a flow chart of a method for testing a ROM. DETAILED DESCRIPTION
[0012] As described above, the contents of the ROM are verified during the boot process. Cyclic redundancy check (CRC) techniques are commonly 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 automotive applications, for example, which may include circuits containing ROMs, it is necessary to verify the contents of the ROMs within a relatively minimum time window, especially when the ROMs are part of safety-critical circuits. For example, each time a driver turns on the 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 and operate it safely after starting it.
[0013] The example described herein provides a circuit architecture for rapidly verifying the content of ROM. The architecture comprises a memory built-in self-test (MBIST) controller for both the RAM and the ROM of the test system. Early in the boot process, a central processing unit (CPU) executes an instruction from ROM, which causes the CPU to copy certain instructions from ROM to the RAM (or other types of volatile storage devices). The CPU then continues to execute those specific instructions from the RAM. The copied instruction executed from the RAM causes the CPU to transition ROM to test mode and causes the CPU to instruct the MBIST controller to test the ROM. By transferring the ROM test responsibility to the MBIST controller, the CPU can be used for performing other useful startups and initialization functions, thereby accelerating the boot process. In addition, in some systems, it is impossible to read access immediately by the CPU of the ROM, which makes the test ROM slower than the possible situation of reading immediately. Further, if the CRC process is used to test the ROM, the calculation cycle using the arithmetic logic unit (ALU) and register of the CPU can comprise 10 to 15 cycles of each tested ROM position so. The architecture described herein tests the ROM in a more efficient and faster manner. 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).
[0014] 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-a-chip (SoC) wherein Figure 1 104. The components shown in FIG. 104 are fabricated on a common semiconductor die. ROM 104 is a non-transitory storage device. Although a CPU 102 is shown in this example, multiple CPUs may 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 a memory address (e.g., adding to an offset to generate the value of a memory address). Similarly, MBIST controller 110 is communicatively coupled to ROM 104 and RAM 106 via address and data bus BUS3 and BUS4, respectively.
[0015] 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 for temporarily storing data or code used during runtime. Code from ROM 104 may be transferred to RAM 106 for execution from RAM 106.
[0016] RAM 106 can comprise one or more memory devices and is a dual-port memory device.Via a port 106a, CPU 102 accessible RAM 106.Via another port 106b, mbist controller 110 accessible RAM 106.RAM TESTMODE signal 115 can be through asserting to the first logic state so that RAM 106 is in the first execution mode (being called " runtime execution mode ") that wherein CPU 102 can use RAM 106, or through asserting in the second logic state so that RAM 106 is in the second pattern (being called " test mode ") that wherein mbist controller 110 can access RAM.In runtime execution mode, port 106a is active (and port 106b is inactive) to allow CPU 102 via BUS2 access RAM 106.In test mode, port 106b is active (and port 106a is inactive) to allow mbist controller 110 via BUS4 access RAM. 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 coupling is written to the content of RAM.In an example, CPU 102 pairs of one or more control registers in the mbist controller 110 are written to trigger mbist controller 110 and begin to test RAM 106.
[0017] 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 test mode, port 104b is active (and port 104a is inactive) to allow MBIST controller 110 to access ROM 104 via BUS3.
[0018] To test ROM 104, you can 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 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, for example, starting at ROM_ADDR_0. That is, program counter 103 is loaded with the 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.
[0019] 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 ROM_ADDR_b and ROM_ADDR_c to RAM addresses in the range RAM_ADDR_x and RAM_ADDR_y, as shown by the dotted 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 Figure 2 It is shown as RAM code 222.
[0020] 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 through 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 the logic state that causes ROM 104 to enter its test pattern that wherein enables its port 104b (and disable port 104a).Then execution instruction 208b is to cause CPU 102 to configure MBIST controller 110 to test ROM 104.In an example, CPU 102 writes one or more control registers in the MBIST controller 110 to trigger MBIST controller 110 and begins to test ROM 104.Any applicable nonvolatile memory test process can be used for test ROM 104.
[0021] CPU 102 then executes instruction 208c so that CPU 102 enters pause state to wait for mbist controller 110 to finish its test to ROM 104.In case mbist controller 110 finishes its ROM test process, mbist controller 110 just can assert the interruption of CPU 102 so that will have finished ROM test and send signal to CPU.CPU 102 exits pause state and then executes instruction 208d, instruction 208d causes CPU 102 ROM 104 to be taken out of its test pattern and put into the runtime execution pattern 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 disabling the runtime execution pattern of port 104b. Instruction 208 e 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 .
[0022] 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. Under the situation that the PC 103 of new change turns back 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 causing 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 initial error response so.The example of error response comprises generation interruption to CPU 102, by error state machine assertion output signal etc.
[0023] Figure 3 An example of a timeline illustrating how to test ROM 104 is provided. 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, ROM TEST MODE signal 111 is a logic " 1 " signal which is used to control the ROM 104 to be used for test purposes. ROM code 208 is copied to RAM 106 from ROM 104. At 306, CPU 102 copies code 208 to RAM 106 from ROM 104. The logic state of ROM TEST MODE signal 111 is then changed to the state (being logic " 1 " in this example) in order to place ROM 104 in the test pattern to allow mbist controller 110 access ports 104b for test purposes. Execute copied ROM code 208 (now in RAM 106) from RAM. Copy ROM code 208 causes CPU 102 to carry out the operation explained above, for example configures mbist controller 110 to test ROM 104. 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 fetching can continue from ROM 104 and be executed by CPU 102 at 312 .
[0024] 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 FIG4 , system 400 also includes additional components, such as direct memory access (DMA) controller 412, additional ROM 428, and hardware CRC 420. CPU 402, DMA 412, MBIST controller 410, hardware CRC 420, ROM 428, and RAM 406 are coupled together via bus 405. In one example, bus 405 includes an Advanced eXtensible Interface (AXI), but in other embodiments may be consistent with other standards. Boot ROM 404 (which contains Figure 2 ROM code shown in FIG) is coupled to the CPU 402 via tightly coupled memory (TCM) interfaces (ITCM and DTCM). The MBIST controller 410 is coupled to the boot ROM 404, ROM 428, and RAM 406 via interfaces 413, 425, and 427, respectively, as shown. Figure 1 The 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.
[0025] Figure 5 Flowcharts showing methods according to examples. The operations may be performed in the order shown or in a different order. Furthermore, the operations may be performed sequentially, or two or more of the operations may be performed simultaneously.
[0026] 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 part 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 the RAM. The CPU then begins to execute the copied code from RAM, and when doing so, ROM is configured to test mode at 510. At 512, an MBIST controller (e.g., MBIST controller 110, 410) is configured to test ROM by the CPU, and the MBIST controller then begins to test ROM (514).
[0027] CPU waits for MBIST controller to finish ROM test at 516 places.Once finish ROM test, at 518 places, ROM is just configured back into its runtime execution mode to allow CPU to continue to extract instruction from ROM.PC is changed to the address (520) after previously copying ROM code in ROM.At 522 places, method comprises determining whether ROM has passed test.This operation may comprise the value (for example, pass / fail flag) in CPU reading register.If ROM has passed its test, method continues at 526 places so, 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, so at 524 places, handle ROM error with suitable mode (for example mode described above).
[0028] 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, that connection may be through a direct connection or through an indirect connection via other devices and connections. The phrase "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.
[0029] Modifications are possible in the described embodiments, and other embodiments are possible within the scope of the claims.
Claims
1. A system comprising: volatile storage device; a read-only memory ROM configured to store a first instruction set and a second instruction set; Memory built-in self-test (BIST) controller; and A central processing unit (CPU) configured to: executing a first set of instructions stored in the ROM; copying a second instruction set in the ROM to the volatile storage device; Instructing the BIST controller to perform a test operation on the ROM; and The second set of instructions is executed from the volatile memory device while the BIST controller performs the test operation.
2. The system of claim 1, wherein the CPU is further configured to instruct the ROM to exit a test mode.
3. The system of claim 2, wherein the CPU is further configured to instruct the ROM to exit the test mode upon completion of the test of the ROM by the memory BIST controller.
4. The system of claim 2, wherein upon causing, the CPU is configured to instruct the ROM to enable a first port of the ROM and disable a second port of the ROM.
5. The system of claim 1, wherein the CPU is further configured to change a program counter to a new value corresponding to an address in the ROM.
6. The system of claim 5, wherein the new value of the program counter corresponds to a ROM address following a series of addresses of the second set of instructions.
7. The system of claim 6, wherein the CPU is further configured to determine, through the memory BIST controller, whether the ROM passes its test.
8. A system comprising: volatile storage device; a read-only memory (ROM) configured to store a plurality of instructions; a memory built-in self-test (BIST) controller configured to test the ROM in response to one of the plurality of instructions; and A central processing unit (CPU) configured to: copying the plurality of instructions in the ROM to the volatile storage device in response to an initialization event; Instructing the ROM to enter a test mode and the memory BIST controller is configured to test the ROM; and executing the plurality of instructions from the volatile memory device while the BIST controller tests the ROM; 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.
9. The system of claim 8, wherein the CPU is further configured to instruct the ROM to exit a test mode upon completion of the test of the ROM by the memory BIST controller.
10. The system of claim 8, wherein upon causing, the CPU is configured to instruct the ROM to enable a first port of the ROM and disable a second port of the ROM.
11. The system of claim 8, wherein the CPU is further configured to change a program counter to a new value corresponding to an address in the ROM.
12. The system of claim 11, wherein the new value of the program counter corresponds to a ROM address following a series of addresses of the plurality of instructions.
13. The system of claim 12, wherein the CPU is further configured to determine, via the memory BIST controller, whether the ROM passes its test.
14. A method comprising: executing a first set of instructions stored in a read-only memory ROM; copying a second instruction set in the ROM to a volatile storage device; Instructing a memory built-in self-test (BIST) controller to perform a test operation on the ROM; and The second one of the instructions is executed from the volatile memory device while the BIST controller performs the test operation.
15. The method of claim 14, further comprising instructing 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.
16. The method of claim 15, further comprising instructing the ROM to enable the first port of the ROM and disable the second port of the ROM upon completion of the testing of the ROM.
17. A method comprising: In response to an initialization event instructing a read-only memory ROM to enter a test mode, a plurality of instructions in the ROM are copied to a volatile memory device; Configuring a memory built-in self-test (BIST) controller to test the ROM; and testing the ROM by the memory BIST controller while executing the plurality of instructions from the volatile memory device by a central processing unit; and The first port of the ROM coupled to the central processing unit is instructed to be disabled, and the second port of the ROM coupled to the memory built-in self-test controller is enabled.
18. The method of claim 17, further comprising instructing the ROM to enable the first port of the ROM and disable the second port of the ROM upon completion of the testing of the ROM.