Built in test controller with a downloadable testing program

The present invention relates to memory testing generally and, more particularly, to a method and/or apparatus for implementing a built in test controller having a downloadable testing program.

In the synthesis of VLSI designs, built-in test controllers are often implemented. Some modules (such as memories) have a much higher defect density than other types of logic. Memories normally implement additional and comprehensive testing. One conventional approach is to test such memory modules by using a test controller placed on a chip. Comprehensive testing often means performing a number of tests. Such tests often become cumbersome to combine into one test controller.

It would be desirable to implement a test controller that may receive downloadable tests. The downloadable tests may be implemented in the form of a program that may be downloaded into the test controller and executed during the test runtime.

The present invention concerns an apparatus comprising a processor and an internal memory. The processor may be configured to test an external memory using (i) a netlist and (ii) a testing program. The internal memory may be configured to store the testing program. The testing program may be downloadable to the internal memory independently from the storing of the netlist.

The objects, features and advantages of the present invention include providing a test controller that may (i) receive downloadable programming, (ii) download a precompiled test program up to the capacity of an internal memory, (iii) provide a programmable test program that may be written/rewritten, (iv) provide a flexible test program that may be changed on the fly during testing, (v) provide a low complexity implementation that uses a minimal amount of logic around an internal memory, and/or (vi) provide a universal implementation of a microprocessor and internal memory that remains consistent for different types of test controllers.

These and other objects, features and advantages of the present invention will be apparent from the following detailed description and the appended claims and drawings in which:

FIG. 1 is a diagram illustrating a context of the present invention;

FIG. 2 is a diagram of a test controller;

FIG. 3 is a diagram of a memory;

FIG. 4 is a diagram of a microprocessor;

FIG. 5 is a more detailed diagram of the microprocessor of FIG. 4 ;

FIG. 6 is a diagram of one of the circuits of the microprocessor;

FIG. 7 is a more detailed diagram of one the circuits of the microprocessor; and

FIG. 8 is a diagram of the circuit test controller of FIG. 2 with a command interpreter.

Referring to FIG. 1 , a block diagram of a system 50 is shown in accordance with a preferred embodiment of the present invention. The system 50 generally comprises a block (or circuit) 52 , a block (or circuit) 54 , a number of memory circuits 60 a- 60 n, a number of blocks 56 a - 56 n and a block (or circuit) 58 . In one example, the circuit 52 may be implemented as a user logic circuit. The circuit 54 may be implemented as a controller circuit. In one example, the controller circuit 54 may be implemented as a BIST circuit. The controller circuit 54 may be a common controller used with each of the memory circuits 60 a - 60 n . The controller circuit 54 may include a circuit 100 . The circuit 100 may be implemented as a core testing module. The circuits 60 a - 60 n may be implemented as memory circuits. The circuits 56 a - 56 n may be implemented as collar circuits. The circuit 58 may be implemented as a terminator unit.

The system 50 may be implemented as part of the transport subsystem of a MBIST chain architecture. For example, the memory circuits 60 a - 60 n may form a chain. A number of busses 62 a - 62 n and 64 a - 64 n may be implemented. The busses 62 a - 62 n and 64 - 64 n may be implemented having moderate width (e.g., 8-10 bits). However, other bit-widths may also be implemented. The busses 62 a - 62 n and 64 a - 64 n may be connected to form a chain. The controller 54 may be on one side of the chain. The terminator unit 58 may be on another side of the chain. collar circuits 56 a - 56 n may be implemented to allow the various memory circuits 60 a - 60 n to operate with the common controller 54 . For example, the collar 56 a may operate with the memory 60 a , the collar 56 b may operate with the memory circuit 60 b , etc. The structures and/or size of the memory circuits 60 a - 60 n may be varied to meet the design criteria of a particular implementation. For example, the memory circuits may be implemented as a SRAM memory, a 1-port memory, a 2-port memory, or other types and/or combinations of memory. The length of particular busses 62 a - 62 n and 64 a - 64 n connecting the neighboring collars 56 a - 56 n (or to the controller 54 and the nearest one of the collars 56 a - 56 n ) is not normally a critical parameter and may be varied. An MBIST chain architecture normally permits splitting long connections into smaller pieces by adding flipflop boundaries between such connections.

Referring to FIG. 2 , a block diagram of a system 100 is shown in accordance with a preferred embodiment of the present invention. The system 100 may be implemented as a Built-In Test Controller. The system 100 may provide a Built-In Test Controller that includes a downloadable testing program.

The system 100 may provide a precompilation of a test program into a binary file. One or more test programs may be implemented. The test program may be downloaded to a read-only memory 102 . The program may be executed during test runtime. The system 100 may allow a test controller netlist to remain unchanged while changing (or modifying) test programs. Such changes may provide flexibility. Such testing may be done on the fly (e.g., during a testing phase in a factory). The system 100 may be implemented independently of a particular test under development. The system 100 may provide a consistent controller core that may be used along with various built-in test controllers. In one example, the system 100 may be used for testing memory modules. However, the system 100 may be designed to test other types of circuit designs.

The test controller of the system 100 may allow (i) improved timing, (ii) reduced die size, (iii) at speed testing on a chip, (iv) testing multiple instances, (v) easy implementation and easy extension to desired built-in test, (vi) downloadable and/or downloaded precompiled test program(s) up to the capacity of an internal memory, (vii) a programmable test program that may be written/rewritten, (viii) a flexible test program that may be changed on the fly, (ix) a low complexity implementation that uses a minimal amount of logic around an internal memory, and/or (x) a highly universal design with a microprocessor and internal memory that remain consistent for different types of test controllers.

The system 100 generally comprises a block (or circuit) 102 and a block (or circuit) 104 . The circuit 102 may be implemented as an electrically programmable read only memory module (EPROM) (or circuit). Other nonvolatile memories (e.g., EEPROM, flash memory, etc.) may also be implemented. The circuit 104 may be implemented as a processor module (or circuit). The system 100 may be used to test an external memory or other design (e.g., the memory devices 60 a - 60 n ). The system 100 may have an input 110 that may receive a signal (e.g., CLK), an input 112 that may receive a signal (e.g., IF), an input 114 that may receive a signal (e.g., EN), an output 116 that may present a signal (e.g., VALID), an output 118 that may present a signal (e.g., DATA), an output 120 that may present a signal (e.g., COM_TYPE), and an output 122 that may present a signal (e.g., PAR_TYPE).

The circuit 102 may have an input 130 that may receive the signal EN, an input 132 that may receive the signal CLK, an input 134 that may receive a signal (e.g., RA), and an output 136 that may present a signal (e.g., DO). The processor module 104 may have an input 140 that may receive a signal EN, an input 142 that may receive a signal IF, an input 144 that may receive the signal CLK, an output 146 that may present the signal RA, and an input 148 that may receive the signal DO. The system 100 may include a program stored in the EPROM module 102 . The processor module 104 may read the program stored in the EPROM module 102 and interpret commands received from the program.

The signal EN may be implemented as an enable signal. The signal IF may be implemented as an interface signal. The signal CLK may be implemented as a clock signal that oscillates at a particular frequency. The signal RA may be implemented as a read address signal. The signal DO may be implemented as a data output signal.

Referring to FIG. 3 , a more detailed diagram of the circuit 102 is shown. In one example, the circuit 102 may be implemented as a programmable read-only memory (or ROM). However, other types of non-volatile memory circuits may be used to meet the design criteria of a particular implementation. For example, the memory 102 may be implemented as a binary table that may be hardwired as part of the controller 100 . The memory circuit 102 may be implemented as a type of memory appropriate for use in cell-based chip designs for data storing along with the data read-only operation.

In general, during each cycle of the signal CLK, the memory circuit 102 may be in an active (e.g., enabled, or “1”) or an inactive (e.g., disabled, or “0”) state depending on the signal EN. For example, when the signal EN=1, data stored at a location in the memory 102 specified by the read address signal RA may be presented through the output 136 as the memory data-output signal DO.

The memory circuit 102 may be used to store system-level programs. The memory circuit 102 may be configured to download and change programs on the fly. In one example, the memory circuit 102 may be implemented as a two port (or dual port) memory. One port (e.g., a port A) may be used for reading. Another port (e.g., a port B) may be used for writing (e.g., downloading) data. A two port implementation may be useful for built-in testing chip purposes.

Referring to FIG. 4 , a diagram of the processor circuit 104 is shown. The processor circuit 104 may be implemented as a built-in microprocessor. For example, the circuit 104 may be built into a memory test system. The microprocessor 104 may be configured to read a sequence of data stored in the memory 102 . The data may be read, in one example, one item at a time.

Referring to FIG. 5 , a more detailed diagram of the microprocessor circuit 104 is shown. The circuit 104 generally comprises a circuit 150 , a circuit 152 , a circuit 154 , a circuit 156 , a circuit 158 , and a circuit 160 . The circuits 150 , 152 and 154 may be implemented as flip-flops. The circuit 156 may be implemented as an adder circuit. The circuit 158 may be implemented as a NEXT IND circuit. The circuit 160 may be implemented as a flag circuit.

The circuit 156 may generate a signal (e.g., IND_PLUS). The circuit 152 may generate a signal (e.g., IND_JUMP). The circuit 154 may generate a signal (e.g., VALID). The flip-flops 150 , 152 and 154 may store and retrieve current values of IND, IND_JUMP and EN. The flip-flops 150 , 152 and 154 may also provide a one (or more) clock cycle delay to the value of the read address signal RA, the value of the signal IND JUMP, and the value of the enable input signal EN.

The circuit 158 may have an input 180 that may receive the signal VALID, an input 182 that may receive the signal IF, an input 184 that may receive the signal IND_JUMP, an input 186 that may receive the signal IND_PLUS, an input 188 that may receive a signal (e.g., IND_MEM), an input 190 that may receive a signal (e.g., IF_COM_FLAG), and an input 192 that may receive a signal (e.g., SET_JUMP_FLAG). The signal IF_COM_FLAG and the signal SET_JUMP_FLAG may be implemented as auxiliary flags.

The signal DO may be stored in the memory 102 . The signal DO may have a specific format that may be used for testing. The width of the memory 102 may be varied. For example, if a value IND WIDTH denotes the width of the memory address signal RA, then the capacity of the memory 102 may be defined by the following equation:

Capacity =2 IND—WIDTH ,

where the signal DO is 2-bits wider than the memory address signal RA. If the first two most significant bits are denoted as a prefix bit (e.g., PREF 0 ) and a prefix bit (e.g., PREF 1 ), then the signal DO may be defined as follows:

DO =(PREF 0 , PREF 1 , DATA),

where DATA is a binary word having a width defined as IND WIDTH bits. In one example, the data signal DO may be implemented as a microprocessor command and two prefix bits. The prefix bits PREF 0 and PREF 1 , may be implemented to code the microprocessor command as one of the following types:

1. unconditional command—if PREF 0 =0 and PREF 1 , =0;

2. conditional command—if PREF 0 =0 and PREF 1 , =1; in this case the auxiliary flag IF_COM_FLAG is set to 1;

3. SET_JUMP command—if PREF 0 =1 and PREF 1 =0; in this case the auxiliary flag SET_JUMP_FLAG is set to 1.

Depending on the maximum test program size that may be downloaded into the memory 102 , the size of the memory 102 may be varied in typical cases as follows:

Capacity=16÷128.

Referring to FIG. 6 , a detailed diagram of the circuit 158 is shown. The circuit 158 may compute the next value of the signal IND (e.g., the memory address RA to be read next), IND NEXT, and the next value for the signal IND_JUMP, IND JUMP NEXT.

If the inputs to the circuit 158 are IND_MEM=DATA, IND_PLUS=IND+1, and IND_JUMP, then the circuit 158 computes new values for the signal IND_NEXT and the signal IND_JUMP_NEXT as follows:

1. (jump command case) if SET_JUMP_FLAG=1, then IND_JUMP_NEXT=IND_MEM; otherwise hold the current value of the signal IND_JUMP_NEXT=IND_JUMP;

2. (conditional command case) if IF=0 and IF_COM_FLAG=1 and EN=1, then IND_NEXT=IND_JUMP;

3. (unconditional command case) if (IF=0 or IF_COM_FLAG=0) and EN=1, then IND_NEXT=IND_PLUS; and

4. (reset case) if IF=0 then IND_NEXT=0.

Referring to FIG. 7 , a more detailed diagram of the circuit 158 is shown. The circuit 158 generally comprises a circuit 202 , a circuit 204 , and a circuit 206 . The circuit 202 may be implemented as a multiplexer. The circuit 204 may be implemented as a de-multiplexer. The circuit 206 may be implemented as a multiplexer. The circuits 202 , 204 and 206 illustrate an example implementation of the logic described. Other logic may be implemented to meet the design criteria of a particular design.

Referring to FIG. 8 , a diagram of a system 200 is shown illustrating the circuit 100 in the context of a circuit 220 . The circuit 220 may be implemented as a command interpreter. The command interpreter 220 may be configured to receive the signals COM_TYPE, PAR_TYPE, DATA, and VALID. The signal DATA, generated from the test controller module 100 , includes the microprocessor data and commands that may be further interpreted and decoded by the command interpreter circuit 220 . Using appropriate prefix coding, the test controller 100 may present the signal DATA to be decoded by the command interpreter 220 . The command interpreter 220 generates test command-data flow as the signal TEST_DATA.

The various signals of the present invention are generally “on” (e.g., a digital HIGH, or 1) or “off” (e.g., a digital LOW, or 0). However, the particular polarities of the on (e.g., asserted) and off (e.g., de-asserted) states of the signals may be adjusted (e.g., reversed) to meet the design criteria of a particular implementation. Additionally, inverters may be added to change a particular polarity of the signals.

While the invention has been particularly shown and described with reference to the preferred embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made without departing from the scope of the invention.