Patent Description:
Many electronic systems include a microprocessor that executes code from memory. Such systems often include a read-only memory (ROM) and a random-access memory (RAM). A "boot" ROM may be included in the system to store code that is executed during a boot process for the system. Many systems test the RAM and ROM during the boot process and/or during idle times after the boot process has completed to confirm whether such memories are structurally intact and whether the data stored is reliable. Document <CIT> discloses a computer system including a dual basic input-output read-only memory system to initialize a computer. Moreover, Document <CIT> discloses a system for programmable memory testing. Further, the article<NPL>),.

ISSN: <NUM>-<NUM> discloses a method for testing a ROM in a processor chip with an already verified RAM in the same chip. Furthermore, the article <NPL> discloses a design and architectures of a microcode-based memory built-in self test unit. In addition, Document <CIT>discloses a self-test controller including a memory configured to store test patterns, configuration registers, and a memory data component.

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, upon occurrence of a reset event, executes a first instruction from the ROM to cause the CPU to copy a plurality of instructions from a range 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 executes the plurality of instructions from the volatile storage device using the program counter. The CPU, when executing the plurality of instructions from the volatile storage device, causes the ROM to enter a test mode and the memory BIST controller to be configured to test the ROM.

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 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 an instruction 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 an instruction within the ROM to determine whether the ROM passed a test.

As described above, the contents of a ROM are validated during the boot process. A cyclic redundancy check (CRC) technique often is used to validate the contents of a ROM. CRC techniques are time-consuming, and some applications may have stringent timing requirements. In the case of automotive applications, for example, in which a circuit containing a ROM may be included, the ROM's contents need to be validated within a relatively minimal time window, particularly when the ROM is part of a safety critical circuit. For example, every time a driver turns on an automobile, one or more ROMs within the automobile may need to have their contents validated. However, the driver expects to be able to drive the automobile very soon after starting the automobile and have the automobile operate safely.

The examples described herein provide a circuit architecture for rapidly validating the contents of a ROM. The architecture includes a memory built-in self-test (MBIST) controller that tests both the RAM and ROM of the system. Early on during the boot process, the central processing unit (CPU) executes an instruction from the ROM that causes the CPU to copy certain instructions from the ROM to the RAM (or other type of volatile storage device). The CPU then continues execution of those particular instructions from the RAM. The copied instructions executed from RAM cause the CPU to transition the ROM to a test mode and cause the CPU to instruct the MBIST controller to test the ROM. By offloading the responsibility of ROM-testing to the MBIST controller, the CPU is available to perform other useful boot and initialization functions thereby expediting the boot process. Further, in some systems back-to-back read access by the CPU of the ROM is not possible, which makes testing the ROM slower than if back-to-back reads were possible. Further still, if a CRC process was used to test the ROM, computation cycles using the arithmetic logic unit (ALU) and registers of the CPU may include <NUM>-<NUM> cycles per each ROM location being tested. The architecture described herein tests the ROM in a more efficient and faster manner. The examples described herein pertain to the use of RAM to assist in testing the ROM, but other types of volatile storage devices can be used instead of RAM (e.g., registers).

<FIG> shows an example of a system <NUM> containing a CPU <NUM>, ROM <NUM>, RAM <NUM>, and an MBIST controller <NUM>. In one implementation, the system <NUM> comprises a system-on-chip (SoC) in which the components shown in <FIG> are fabricated on a common semiconductor die. The ROM <NUM> is a non-transitory storage device. While one CPU <NUM> is shown in this example, multiple CPUs may be included in other examples. The CPU <NUM> in this example can access the ROM <NUM> via an address and data bus (BUS1), and the CPU <NUM> can access the RAM <NUM> via a different address and data bus (BUS2). The CPU <NUM> executes code located at a memory location corresponding to a program counter (PC) <NUM>. The value of the PC <NUM> either is the address in the RAM <NUM> or ROM <NUM> from which to fetch an instruction, or the value is used to derive the memory address (e.g., a value that is added to an offset to generate a memory address). Similarly, the MBIST controller <NUM> is communicatively coupled to the ROM <NUM> and RAM <NUM> via address and data buses BUS3 and BUS4, respectively.

Executable instructions (also referred to as "code") are stored in ROM <NUM> and can be retrieved therefrom for execution by the CPU <NUM>. The code may comprise boot code which is executed upon a reset of the system <NUM> (e.g., hard or soft reset). The boot code may cause the CPU <NUM> to perform various initialization functions such as configuring various registers, testing interfaces that are present in the system, etc. RAM <NUM> can be used as scratchpad storage for temporary storage of data or code used during run-time. Code from ROM <NUM> can be transferred to RAM <NUM> for execution from RAM <NUM>.

The RAM <NUM> may comprise one or more memory devices and is a dual-ported memory device. Via one port 106a, the CPU <NUM> can access RAM <NUM>. Via another port 106b, the MBIST controller <NUM> can access RAM <NUM>. A RAM TEST MODE signal <NUM> can be asserted to a first logic state to cause the RAM <NUM> to be in a first execution mode (referred to as a "run-time execution mode") in which the CPU <NUM> is able to use the RAM <NUM>, or in a second logic state to cause RAM <NUM> to be in a second mode (referred to as a "test mode") in which the MBIST controller <NUM> is able to access the RAM. In the run-time execution mode, port 106a is active (and port 106b is inactive) to allow the CPU <NUM> to access the RAM <NUM> via BUS2. In the test mode, port 106b is active (and port 106a is inactive) to allow the MBIST controller <NUM> to access the RAM via BUS4. While in its test mode, the MBIST controller <NUM> can test the RAM <NUM>. For example, via BUS4 the MBIST controller <NUM> can write a predefined bit pattern to the RAM <NUM>, and then read the RAM to confirm that the read data matches what was written to the RAM. In one example, the CPU <NUM> writes one or more control registers in the MBIST controller <NUM> to trigger the MBIST controller <NUM> to begin testing the RAM <NUM>.

The ROM <NUM> also is a dual-ported memory device and includes ports 104a and 104b. Port 104a is coupled to the CPU <NUM> and port 104b is coupled to the memory BIST controller <NUM>. Similar to the RAM <NUM>, a ROM TEST MODE <NUM> can be asserted to a first logic state by the memory BIST controller <NUM> to cause the ROM <NUM> to be in a "run-time" execution mode in which the CPU <NUM> is able to access the ROM <NUM> (e.g., to fetch code), or in a second logic state to cause ROM <NUM> to be in a "test mode" in which the MBIST controller <NUM> is able to access the ROM. In the run-time execution mode, port 104a is active (and port 104b is inactive) to allow the CPU <NUM> to access the ROM <NUM> via BUS1. In the test mode, port 104b is active (and port 104a is inactive) to allow MBIST controller <NUM> to access the ROM <NUM> via BUS3.

To test the ROM <NUM>, the example procedure described in <FIG> can be performed. Turning to <FIG>, the contents of at least portions of the ROM <NUM> and the RAM <NUM> are shown. The ROM <NUM> includes executable code <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM>. Code <NUM> and <NUM> comprise functional ROM code to assist in booting the system as well as assisting to operate the system during run-time (e.g., providing access to low-level hardware components on behalf of higher level applications). During the boot process, the CPU <NUM> begins executing functional ROM code <NUM> beginning, for example, at ROM_ADDR_0. That is, program counter <NUM> is loaded with a value that corresponds to ROM_ADDR_0 and the CPU <NUM> begins executing instructions at that address within the ROM. The PC <NUM> is incremented for each code instruction (or group of instructions) fetched from ROM <NUM>.

The PC <NUM> will eventually be a value that corresponds to the location of code <NUM> within the ROM <NUM>. Code <NUM> comprises an instruction that causes the CPU <NUM> to copy ROM code <NUM> from addresses ranging between ROM_ADDR_b and ROM_ADDR_c to RAM addresses ranging between RAM_ADDR_x and RAM_ADDR_y as shown by the dashed lines. The portion of the RAM <NUM> that is used to receive ROM code <NUM> is an otherwise unused portion <NUM> of the RAM. The ROM code <NUM> received into the RAM <NUM> is shown as RAM code <NUM> in <FIG>.

Once the ROM code <NUM> is copied to the RAM <NUM>, the PC is again incremented to ROM_ADDR_a. The code at that location causes the CPU <NUM> to change the PC <NUM> to a value that corresponds to the RAM address RAM_ADDR_x (the beginning address of RAM code <NUM>, which contains code <NUM> from ROM <NUM>). The CPU <NUM> then executes the instructions of ROM code <NUM>, but executes a copy of those instructions from the RAM (code <NUM>). The instructions comprise instructions 208a-208d. Instruction 208a causes the CPU <NUM> to configure the ROM <NUM> for the test mode. In one example, configuring the ROM <NUM> for the test mode comprises the memory BIST controller <NUM> asserting ROM TEST MODE signal <NUM> (<FIG>) to the logic state which causes the ROM <NUM> 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 <NUM> to configure the MBIST controller <NUM> to test the ROM <NUM>. In one example, the CPU <NUM> writes one or more control registers in the MBIST controller <NUM> to trigger the MBIST controller <NUM> to begin testing the ROM <NUM>. Any suitable nonvolatile memory test process can be used to test the ROM <NUM>.

The CPU <NUM> then executes instruction 208c to cause the CPU <NUM> to enter a pause state as to wait for the MBIST controller <NUM> to complete its testing of the ROM <NUM>. Once the MBIST controller <NUM> completes its ROM testing process, the MBIST controller <NUM> may assert an interrupt to the CPU <NUM> to signal the CPU that the ROM test has completed. The CPU <NUM> exits the pause state and then executes instruction 208d which causes the CPU <NUM> to take the ROM <NUM> out of its test mode and place into the run-time execution mode to thereby permit the CPU <NUM> to again retrieve instructions from the ROM via port 104a. This action may be implemented by the MBIST controller changing the logic state of the ROM TEST MODE signal <NUM> to a logic state corresponding to the run-time execution mode in which port 104a is enabled and port 104b is disabled. Instruction 208e from RAM <NUM> is then executed which causes the CPU to change the PC <NUM> to a value corresponding to ROM_ADDR_d, which is the ROM address following code <NUM> that was previously copied to RAM <NUM>.

The MBIST controller <NUM> includes a ROM status register <NUM> which contains a value indicative of the result of the ROM test. In one example, the ROM status register includes a pass/fail indication. With the newly changed PC <NUM> back to a value corresponding to ROM_ADDR_d, the CPU <NUM> then fetches instructions from ROM <NUM> instead of RAM <NUM>. Instruction <NUM> is thus fetched and causes the CPU <NUM> to check the MBIST status register <NUM> for the results of the ROM test. Instruction <NUM> further may cause code execution to continue in the functional ROM code <NUM> if the ROM <NUM> passed its test. If the ROM <NUM> did not pass its test, instruction <NUM> may initiate an error response. Examples of error response include the generation of an interrupt to the CPU <NUM>, the assertion of an output signal by an error state machine, etc..

<FIG> provides an example of a timeline illustrating how the ROM <NUM> is tested. Either before or after the RAM <NUM> is tested by the MBIST controller <NUM> (and thus RAM TEST MODE signal <NUM> is in a logic state such as logic "<NUM>" in the example of <FIG>), the ROM TEST MODE signal <NUM> is in a logic state ("<NUM>" in <FIG> as shown at <NUM>) corresponding to the ROM's run-time execution mode to permit the CPU <NUM> to fetch code from ROM <NUM> for execution. At <NUM>, the code <NUM> is copied by the CPU <NUM> from the ROM <NUM> to the RAM <NUM>. The logic state of the ROM TEST MODE signal <NUM> is then changed to a state to place the ROM <NUM> in the test mode (logic "<NUM>" in this example) to permit the MBIST controller <NUM> to access port 104b for test purposes. The copied ROM code <NUM> (now in RAM <NUM>) is executed from the RAM. The copied ROM code <NUM> causes the CPU <NUM> to perform the operations explained above, such as configure the MBIST controller <NUM> to test the ROM <NUM>. At <NUM>, the ROM TEST MODE signal <NUM> is then asserted back to its former state in which the ROM <NUM> is placed back in its run-time execution mode so that code fetching can continue from ROM <NUM> and execution by the CPU <NUM> at <NUM>.

<FIG> is an example architecture of a system <NUM> implementing the ROM-testing paradigm explained above. The example system <NUM> includes a CPU <NUM> (which may comprise an ARM core), a boot ROM <NUM>, RAM <NUM>, and an MBIST controller <NUM>. System <NUM> in the example of <FIG> includes additional components as well such as a direct memory access (DMA) controller <NUM>, additional ROMs <NUM>, and a hardware CRC <NUM>. The CPU <NUM>, DMA <NUM>, MBIST controller <NUM>, hardware CRC <NUM>, ROMs <NUM>, and RAM <NUM> are coupled together via bus <NUM>. In one example, bus <NUM> comprises an Advanced Extensible Interface (AXI), but can comport with other standards in other implementations. Boot ROM <NUM> (which contains the ROM code shown in <FIG>) is coupled to the CPU <NUM> via a Tightly Coupled Memory (TCM) interface (an ITCM and a DTCM). The MBIST controller <NUM> is coupled to boot ROM <NUM>, ROMs <NUM> and RAM <NUM> via interfaces <NUM>, <NUM>, and <NUM>, respectively, as shown. The operations performed by the CPU <NUM> and MBIST controller <NUM> relative to ROM <NUM> and RAM <NUM> of <FIG> are performed by CPU <NUM> and MBIST controller <NUM> relative to ROM <NUM> and RAM <NUM> of <FIG>.

<FIG> shows a flow chart of a method in accordance with an example. The operations can be performed in the order shown, or in a different order. Further, the operations can be performed sequentially, or two or more of the operations may be performed concurrently.

At <NUM>, a reset event occurs. Power to the system <NUM>, <NUM> can be enabled or a soft or hard reset event may occur. At <NUM>, the CPU begins executing code from the ROM (e.g., ROM <NUM>, ROM <NUM>). One of the ROM instructions causes the CPU at <NUM> to copy a portion of the ROM's code to RAM. The PC is changed at <NUM> to correspond to an address in RAM corresponding to the beginning of the copied ROM code. The CPU then begins to execute the copied code from the RAM and, in so doing, configures the ROM into the test mode at <NUM>. The MBIST controller (e.g., MBIST controller <NUM>, <NUM>) is configured by the CPU to test the ROM at <NUM>, and the MBIST controller then begins to test the ROM (<NUM>).

The CPU waits at <NUM> for the MBIST controller to complete the ROM test. Once the ROM test is complete, at <NUM> the ROM is configured back into its run-time execution mode to permit the CPU to continue fetching instructions from the ROM. The PC is changed to an address in ROM following the previously copied ROM code (<NUM>). At <NUM>, the method includes determining whether the ROM passed the test. This operation may comprise the CPU reading the value (e.g., pass/fail flag) in a register. If the ROM passed its test, then the method continues at <NUM> in which the boot process is finished and the system enters its run-time environment (e.g., one or more run-time applications are executed). If, however, the ROM is determined not to have passed its test, then at <NUM>, the ROM error is processed in a suitable manner such as that described above.

In this description, the term "couple" or "couples" means either 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 recitation "based on" means "based at least in part on. " Therefore, if X is based on Y, then X may be a function of Y and any number of other factors.

Claim 1:
A system (<NUM>), comprising:
a volatile storage device (<NUM>);
a read-only memory, ROM, (<NUM>) configured to store instructions;
a memory built-in self-test, BIST, controller (<NUM>); and
a central processing unit, CPU, (<NUM>) configured to, upon occurrence of an initialization event:
execute a first instruction from the ROM (<NUM>) to cause the CPU (<NUM>) to copy a plurality of instructions from a range of addresses in the ROM (<NUM>) to the volatile storage device (<NUM>);
execute a second instruction from the ROM (<NUM>) to change a value of a program counter (<NUM>) to correspond to an address within the volatile storage device (<NUM>) at the beginning of the plurality of instructions;
execute the plurality of instructions from the volatile storage device (<NUM>) using the program counter (<NUM>), the CPU (<NUM>), when executing the plurality of instructions, causes the ROM (<NUM>) to enter a test mode and the memory BIST controller (<NUM>) to be configured to test the ROM (<NUM>), the instructions including an instruction to change the value of the program counter (<NUM>) to correspond to an address within the ROM (<NUM>) following the end of the plurality of instructions within the ROM (<NUM>); and
execute an instruction from the ROM (<NUM>) to determine whether the ROM (<NUM>) passed its testing by the memory BIST controller (<NUM>), wherein:
the ROM (<NUM>) has a first port (104a) coupled to the CPU (<NUM>) and the ROM (<NUM>) has a second port (104b) coupled to the memory BIST controller (<NUM>); and
when the CPU (<NUM>) causes
the ROM (<NUM>) to enter the test mode, the ROM (<NUM>) disables the first port (104a) and enables the second port (104b).