ROM Testing Using MBIST Controller and RAM Instruction Copying
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing ROM validation methods, such as cyclic redundancy check (CRC), are time-consuming and inefficient, especially in safety-critical applications like automotive systems, where rapid validation of ROM contents is necessary during the boot process.
Innovation Solution
A memory built-in self-test (MBIST) controller is used to offload ROM testing responsibilities from the central processing unit (CPU) by copying instructions from ROM to volatile storage, transitioning the ROM to a test mode, and executing these instructions from the volatile storage to expedite the testing process.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If CRC validation method is used to validate ROM contents, then reliability of ROM validation is improved, but validation time increases significantly
Solution Approach 1:
The patent copies test patterns and instructions from the ROM into a volatile storage device (RAM) before execution. This allows the ROM to be tested without physically altering it, while enabling faster validation through repeated access to the copied test data in RAM, thus reducing validation time while maintaining reliability
Solution Approach 2:
The patent introduces a volatile storage device as an intermediary between the ROM and the testing process. This intermediary stores test patterns and instructions temporarily, allowing the ROM to be validated through the volatile storage without direct modification of the ROM itself, thereby achieving both reliability and speed
2Reliability
If CPU executes ROM validation instructions directly, then validation can be performed, but CPU productivity decreases due to time-consuming validation process
Solution Approach 1:
The patent copies validation instructions and test patterns from the ROM into volatile storage before the CPU executes them. This allows the CPU to perform validation more efficiently by accessing the copied instructions in RAM rather than repeatedly reading from the ROM, thereby maintaining validation reliability while improving CPU productivity
Solution Approach 2:
The patent performs preliminary copying of test patterns and instructions into volatile storage before the actual validation execution. This preliminary action prepares the validation data in advance, allowing the CPU to execute validation instructions faster without repeatedly accessing the ROM, thus improving productivity while maintaining validation reliability
3Reliability
If ROM is tested using traditional methods, then validation is achieved, but system initialization time increases
Solution Approach 1:
The patent copies test patterns into volatile storage before initiating ROM validation during system initialization. This allows the validation to proceed faster by avoiding repeated ROM reads, thereby reducing the overall initialization time while maintaining ROM validation reliability
Solution Approach 2:
The patent uses volatile storage as an intermediary to accelerate the validation process during initialization. By storing test patterns in this intermediary device, the system can validate the ROM faster without blocking the initialization process for extended periods, thus reducing initialization time while ensuring validation reliability
Data Source
Figure 1~4
Figure 2
Figure 3
AI summary
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), upon occurrence of a reset event, executes a first instruction from the ROM (104) to cause the CPU (102) to copy instructions from a range 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 executes the instructions from the volatile storage device (106) using the program counter. The CPU (102), when executing the instructions from the volatile storage device (106), causes the ROM (104) to enter a test mode and the memory BIST controller (110) to be configured to test the ROM (104).