Error detection/correction and fault detection/recovery – Data processing system error or fault handling – Reliability and availability
Reexamination Certificate
2001-03-29
2004-12-07
Decady, Albert (Department: 2133)
Error detection/correction and fault detection/recovery
Data processing system error or fault handling
Reliability and availability
C714S723000, C717S124000
Reexamination Certificate
active
06829722
ABSTRACT:
FIELD OF THE INVENTION
The present invention relates to a system and method of processing partially defective memories. More particularly, it relates to a system and method of modifying and obtaining (via compiling and linking) corresponding object codes or machine codes for a source code in advance according to all possible defect distribution types of a memory, and then selecting the corresponding object code or machine code to load and execute according to the physical defect distribution type of the memory to be loaded into.
DESCRIPTION OF THE PRIOR ART
In the past, memory ICs (Integrated Circuits) containing any defective memory cell generally would not be sold on the market. To reduce the number of the memory ICs that are thrown away due to one or more defects, there are at present many techniques that can repair defective memory ICs thereby allowing them to work normally.
For example, U.S. Pat. No. 4,939,694 disclosed a memory system that has self-testing and self-repairing functions. The memory system can perform an on-site self-test process to locate defective memory cells. Once these defective memory cells are located, the memory system will use an error correction code engine to correct these defective memory cells. When the error correction code engine becomes overburdened with defective memory cells, the memory system automatically deletes these defective memory cells.
Furthermore, U.S. Pat. No. 5,644,541 disclosed a technique of using substitution memories to correct semiconductor memories with defective memory cells. All access routes to these bad bit-locations are redirected to good memory cells within the substitution memory by using a mapping logic circuit, whereby the defective memory cells are replaced.
A fault-tolerating memory system, disclosed in U.S. Pat. No. 5,278,847, uses an error detecting and correcting code (EDAC). Reliability of storage data can be determined by using the EDAC for each data cell and for adding spare-bits.
In U.S. Pat. No. 5,579,266, a laser-repairing technique and a programmable fuse repairing technique are used to deal with defective memory cells, wherein redundant memories can be used to replace defective memories.
In fact, the error-detecting and repairing technique disclosed in U.S. Pat. No. 4,939,694, the encoding and spare bit technique disclosed in U.S. Pat. No. 5,278,847, and the access-redirecting technique disclosed in U.S. Pat. No. 5,644,541 do not only complicate the hardware design, but also suffer an execution overhead as programs are executed. Further, for the redundancy memory technique disclosed in U.S. Pat. No. 5,579,266, the hardware design and the practical procedure for repairing defective memory cells are also complicated.
On the other hand, an executable machine code or object code is generated from the source code of a computer program by using compilers and linkers. The machine code program can be directly downloaded to memories for execution.
FIG. 1
(PRIOR ART) shows a system structure of a general single chip computer or a system-on-a-chip. As shown in
FIG. 1
, the system comprises a central processing unit (CPU) or microprocessor
1
, random access memories (RAMs)
3
, read-only memory (ROMs)
5
, an I/O interface circuit
7
, and external storage devices
9
such as hard-disk drives, floppy disk drives, or CD-ROM drives. The general operation is that the CPU
1
loads an executable machine code or object code from the I/O interface circuit
7
or the external storage devices
9
into the RAMs
3
via data/address bus
10
. Generally, an object code is comprised of three segment types, instruction segments, data segments, and stack segments, respectively. The CPU
1
executes the object code from the entry point of one of the instruction segments.
FIG. 2
(PRIOR ART) is a flow chart illustrating the process of executing an object code. First, an entry point is acquired (S
100
). Then, the address of the next instruction is fetched (S
101
). According to the address, the opcode of the next instruction can be fetched (S
102
). Then, the opcode is decoded (S
103
). Next, determination of whether one or more operands are needed for the current instruction can be determined by the decoded information of the current instruction. Then, the operand can be read from the follow-up address, if any (S
104
). Finally, the instruction is executed by the operation defined in the fetched opcode and the data/reference addresses defined in the operand (S
105
). If the current instruction is a termination instruction (S
106
), the process of executing the machine code program finishes (S
107
). Otherwise, the process goes back to step S
101
to acquire the address of the next instruction. Apparently, it is possible that each instruction does not have the same number of bytes. The instruction length depends on the type of the CPU. Generally, there are two types of instruction sets applied in various CPUs, the variable-length instruction set and the constant length instruction set.
The above-described execution procedure only can be applied to the instruction segments of the object code. If the same execution procedure is applied to other segments, such as the data segments or the stack segments, the decoding result will be erroneous. In this case, when a data byte is decoded into a faulty opcode by the CPU
1
, several pieces of sequential data will be mistaken for operands according to the faulty opcode. Generally, the CPU
1
cannot automatically distinguish the instruction segment from the data segment or the stack segment via standard fetching and decoding actions. Furthermore, the instruction segments and the data/stack segments of the program cannot be randomly broken. The instruction pools must be broken based on each complete instruction, including its opcode and the follow-up operands. Generally, the data/stack segments cannot be broken because some of the interrelation within the data/stack segments only can be determined during execution, such as array data structures.
SUMMARY OF THE INVENTION
The object of the present invention is to provide a system and method of processing memory. An appropriate object code, which is loaded into a partially defective memory, can still be executed normally without changing the hardware design or increasing the execution overhead.
Accordingly, the invention provides a method of processing memory, for loading an executable object code compiled from a source code into the memory. At first, set up a plurality of pre-compiled object codes generated from a source code, each pre-compiled object code having at least a skipped-code-address range. Then, test the memory and locate the defective addresses therein by using a tester for example. The tested result (indicated by a defective address or defective distribution type) is directly transferred to a code-loading system, or stored in a label memory of the memory first and then read by the code-loading system.
According to the tested result, the code-loading system selects an executable object code, which has the matching skipped-code-address range, from the pre-compiled object codes; and the selected code is loaded into the memory. Further, via the skipped-code-address table indicating the pre-compiled object code and the corresponding skipped-code-address range, the code-loading system selects and determines an appropriate executable object code by directly checking the skipped-code-address table.
Further, the aforementioned pre-compiled object code can be generated by modifying the source code or object code. For example, in the pattern of modifying a source code, first modify the source code according to the skipped-code-address range, and then compile the modified source code to generate a pre-compiled object code. In the pattern of modifying an object code, compile a source code to generate a standard object code, and then according to the skipped-code-address range modify the standard object code to generate the desired pre-compiled object code.
In the pattern of modifying an object code, if the skipped-code-address range i
De'cady Albert
Dooley Matthew C.
Winbond Electronics Corp.
LandOfFree
System and method of processing memory does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with System and method of processing memory, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and System and method of processing memory will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3278849