Test for processor memory cache

Systems, methods, software products test a memory cache of a processor that includes a test engine (e.g., a BISTE). High level test source code is formulated to use routines in API source code that, when compiled into machine test code, interfaces with the test engine. The machine test code is executed with the processor to test the memory cache to detect one or more faulty memory blocks in the memory cache. If any of the faulty memory blocks are detected, the test engine is instructed, through the machine test code, to set one or more bits in registers to functionally replace the faulty memory blocks with redundant blocks of the memory cache.

BACKGROUND

Complex processors are often tested after manufacture and prior to customer shipment. Typically this testing includes (a) evaluating the processor's internal memory cache, and (b) repairing the memory cache if faults are found. To facilitate testing, the processor's designer uses a workstation to create a macro script. The macro script is a set of instructions written in low level assembly language with predefined macros that aid in constructing complex test sequences. The macro script is expanded into an assembly language source sequence that is then assembled into machine code.

The machine code is loaded into non-volatile memory of a testing device. Typically this testing device varies power supply voltages to the processor during testing to verify correct processor functionality over its full operational voltage range. Each memory block of the memory cache is individually tested. The memory cache includes redundant memory blocks to be used in place of any faulty memory blocks—so long as the faulty memory blocks are detected during testing of the processor. The processor has a one-time programmable (“OTP”) memory (also known as a fuse) that encodes the faulty memory blocks such that the redundant memory blocks are later used in place of the faulty memory blocks, thereby repairing the memory cache. The processor also contains a built-in-self-test engine (“BISTE”) that reads the OTP memory to map the redundant memory blocks to the faulty memory blocks in repairing the memory cache. The BISTE is controlled by the machine code when executed by the processor.

While the use of macros aid the designer in creating complex test sequences, the macro script and expanded assembly language source are difficult to comprehend and maintain due to their low-level interaction with the processor and the BISTE. The time and cost associated with developing and modifying macro scripts to accommodate new or different tests is therefore significant.

SUMMARY OF THE INVENTION

In various embodiments, one method tests memory cache of a processor that includes a test engine, including: formulating high level test source code to use routines in API source code that, when compiled into machine test code, interfaces with the test engine; executing the machine test code with the processor to test the memory cache to detect one or more faulty memory blocks in the memory cache; and, if any of the faulty memory blocks are detected, instructing the test engine, through the machine test code, to set one or more bits in registers to functionally replace the faulty memory blocks with redundant blocks of the memory cache.

One software product includes instructions, stored on computer-readable media, wherein the instructions, when executed by a computer, perform steps for testing a memory cache of a processor, including: formulating machine test code; executing the machine test code on the processor to test the memory cache to detect one or more faulty memory blocks in the memory cache; and, if any faulty memory blocks are detected, utilizing routines to set one or more bits in registers to map the faulty memory blocks to redundant memory cache blocks.

In various embodiments, one system tests a memory cache of a processor of the type that includes a test engine and programmable memory, including: machine test code means, compiled from high level test source code, and API source code, for defining tests to be performed by the test engine; and API code means for interfacing with the test engine in performing the tests to identify faulty memory blocks of the memory cache.

In various embodiments, a processor includes a memory cache for caching data within the processor. A test engine is responsive to machine test code, compiled from high level test source code using routines in API source code, to (a) test the memory cache to detect faulty memory blocks of the memory cache and (b) to set one or more bits that functionally replace the faulty memory blocks with redundant blocks of the memory cache.

DETAILED DESCRIPTION OF THE FIGURES

FIG. 1shows one system50with a processor68operably connected with a test unit58. Processor68is constructed with a built-in-test engine (“BISTE”)74, control registers70and a one-time programmable (“OTP”) memory76. Test unit58is for example used to test processor68after manufacture and prior to customer shipment. A workstation52couples to test unit58and utilizes built-in-self-test engine application programming interface (“BISTE API”) source code55and high level test source code54to create machine test code60within test unit58. As described in more detail below, machine test code60then operates to test a memory cache78of processor68.

Workstation52is for example used to create high level test source code54that defines tests to be performed on processor68. BISTE API source code55may be developed on workstation52to facilitate creation, development and maintenance of high level source code54. BISTE API source code55provides pre-developed routines that, when compiled into BISTE API code62, interface with BISTE74. High level test source code54and BISTE API source code55are, for example, compiled by a compiler56within workstation52and then transferred to test unit58as machine test code60. Machine test code60thereby contains high level test code61, generated from high level test source code54, and BISTE API code62, generated from BISTE API source code55. Machine test code60is for example stored within non-volatile memory64of test unit58.

High level test code61calls routines within BISTE API code62to access and control BISTE74through control registers70. In one example, high level test code61contains calls to routines of BISTE API code62to perform specific tests on memory cache78and to return test results to test unit58. Workstation52may interact with test unit58to display these test results. BISTE API code62may further contain higher level routines to repeat one or more of the tests before returning test results. BISTE API code62may therefore contain a hierarchy of routines to access and control BISTE74.

Memory cache78is divided into memory blocks79that facilitate testing and repair. Certain memory blocks79may contain faults and are illustratively shown as faulty memory blocks80. Memory cache78therefore has redundant memory blocks82used to repair memory cache78through operation of BISTE74. BISTE74tests memory cache78and determines bits to be set in OTP memory76to identify faulty memory blocks80.

BISTE74is used in post-manufacture testing, e.g., within test unit58, and during normal operation, when processor68operates within a customer's computer system. During normal operation, this computing system effectively replaces test unit58by storing machine test code60within separate non-volatile memory. In either case, therefore, BISTE74performs tests on memory cache78during power-up to detect and functionally replace faulty memory blocks80and ensure operability of processor68. Specifically, BISTE74reads the OTP memory bits to map redundant memory blocks82to faulty memory blocks80, making memory cache78fully operational.

FIG. 2illustrates one example of functional hierarchy within BISTE API code62. BISTE API code62contains high level routines90, low level routines92and low level BISTE control94. High level test code61calls high level routines90and specifies the test(s) to be performed on memory cache78and the number of times to repeat the test(s). These repeated tests may thus define the total area of memory cache78under test. High level routines90include functions that perform sequences within the test(s), utilizing functions of low level routines92; in a similar manner, low level routines92utilize functions of BISTE control routines94to control BISTE74in performing tests and returning results.

Six pass cache test function91is one example of one function of high level routines90called by high level test code61. Six pass cache test function91calls cache test function93of low level routines92, which in turn calls write BISTE control register function95of BISTE control routines94. High level test code61may call other functions of low level routines92and BISTE control routines94as a matter of design choice. In one embodiment, there are two register access levels to BISTE74; specifically, control registers70to BISTE registers75of BISTE74. Accordingly, BISTE control routines94may therefore include read BISTE register function96, to read BISTE registers75, and write BISTE register function95, to write BISTE registers75, to facilitate access to BISTE registers75and control registers70.

The following pseudo code illustrates one example of high level test source code54utilizing BISTE API source code55that, when compiled into machine test code60by compiler56and executed by processor68, controls BISTE74to test memory cache78. Specifically, the pseudo code tests memory blocks79of memory cache78, generates reports of test results, and effects repairs to memory cache78by calling a function “IdentifyBadMemoryBlock”. IdentifyBadMemoryBlock generates an output identifying the faulty memory to program mapping information into OTP memory76; this information is later used by BISTE74to set register bits and map redundant memory blocks82to faulty memory blocks80on power-up of processor68.

In the above pseudo code, FirstCacheBlock is an identifier defining a first block of memory blocks79, and LastCacheBlock is an identifier defining a last block of memory blocks79. A function TestMemoryCache contains a for-loop indexing from FirstCacheBlock to LastCacheBlock, to step through each block of memory blocks79.

Each block of memory blocks79is then tested by six pass cache test function91of high level routines90,FIG. 2. Six pass cache test function91returns a Boolean value indicating whether the test passed (true) or the test failed (false). If the test fails, an IdentifyBadMemoryBlock function generates an output referencing the failed memory block, identified by CacheMemoryBlock.

The following code segments illustrate one example of a ‘#define’ statement specifying bit fields within BISTE registers75. The segments specifically illustrate the use of a macro statement that generates source code for a processor instruction that writes bit values passed as parameters to BISTE registers75. A source code statement is shown utilizing the macro and the ‘#define’ statement to produce a processor assembly code instruction to load a bit pattern specified in the ‘#define’ statement into BISTE registers75.

Through the ‘#define’ statement, a first string of characters identifies a second string of characters. During macro expansion, at each location where the first string is used in the source code, the first string is replaced by the second string. For example, such ‘#define’ statements may be used to specify bit field properties (e.g., location, size, default values) for use in other macros. The bit field properties are stored as comma-separated items in the second string; the position and number of the items are kept constant. If for example the third item in the second string is defined as a bit length for a register field, the third item in the second string of other associated '#define statements will also specify a register field bit length. If an item is not required for a particular definition, an ‘x’ fills the space in the second string to maintain the number and order of the items in the second string.

By way of example, in the above ‘#define’, a first string identifier “L1_INDEX_CNTL_PERIOD” identifies twenty-five items separated by commas in the second string; though only twenty items are actually used of the twenty-five items. Additional parameters are included at the end of the second string and filled with ‘x’ characters to reserve space for future use, removing the necessity of later modifying other macros utilizing the ‘#define’ statements when additional parameters are required in the second string. Such ‘#define’ statements can be used in a plurality of macros without parameter-order confusion and without creating multiple copies of bit field information that is difficult to maintain.

The ‘macro’ definition utilizes multiple parameters as provided by the ‘#define’ statement. In the above example, the macro is identified by the name ‘BistPutField’ at the start of the macro definition. This is followed by a directive, ‘.MACRO’, which is then followed by a list of twenty-seven parameters. The center twenty-five parameters are based on the same number and order of items specified by the ‘#define’ statement. The macro has one additional parameter, ‘r’, at the front, and a second additional parameter, ‘t’, at the end. The lines shown between the ‘.MACRO’ directive and the ‘.ENDM’ directive, in the above example, specify text to be substituted with macro expansion of the identifier ‘BistPutField’. In this example, ‘depd’ is a processor instruction that takes four parameters—‘r’, ‘pos’, ‘len’, and ‘t’—that are substituted by parameters passed during invocation.

In the example, the ‘BistPutField’ macro is invoked with just three items. The first items, ‘%r3’, is a register identifier. The second item, ‘L1_INDEX_CNTL_PERIOD’, identifies the ‘#define’ statement; and the third item, ‘arg4’, identifies a parameter used by the processor instruction ‘depd’. The second item is replaced by the second string of the ‘#define’ statement such that the macro item list consists of the twenty-seven items. In one example of operation, the macro uses relevant items from the list to produce the following assembly code:depd %r3,5,3,arg4

The ‘#define’ statement facilitates grouping of many common items into a single list. This single list assists in construction and maintenance of common items since the ‘#define’ statement may be used in a plurality of macro definitions and source code statements.

FIG. 3is a flow chart illustrating one process110for testing a memory cache78of a processor68. Process110creates a high level test source code54utilizing pre-developed routines of BISTE API source code55that, when compiled into machine test code60, access and control BISTE74, which in turn tests memory cache78.

Process110starts at step112and continues with step114. Step114creates high level test source code54to use pre-developed routines of BISTE API source code55.

Step116expands any ‘#define’ statements and macros utilized in high level test source code54and BISTE API source code55, in preparation for a compilation process in step118.

In step118, compiler56generates machine test code60from the expanded source code of step116. Machine test code60contains BISTE API code62, generated from BISTE API source code55, and high level test code61, generated from high level test source code54. In step118, compiler56also notifies the user of any errors detected during compilation of the source code.

Step120is a decision. If errors were detected during the compilation process of step118, process110continues with step122; otherwise process110continues with step128.

Step122provides for editing of high level test source code54, to correct errors identified during the compilation process of step118. Upon reading and fully appreciating this disclosure, one skilled in the art appreciates that the creation114of high level test source code54may involve an interactive editing process using editing software on workstation52, for example. When source code54compiles without errors, process110continues with step128.

Step128loads machine test code60, generated in step118, into test unit58. Process110continues with step130.

Step130executes machine test code60on processor68. In one embodiment, machine test code60performs tests on memory cache78using BISTE74. Machine test code60may also instruct BISTE74to set its registers75to map the redundant memory blocks to the faulty memory blocks.

In step132, machine test code60accumulates results from BISTE74and transfers the results to test unit58.

Step134generates a display or report of the results received from machine test code60. Process110terminates at step136.

The creation of high level test source code54and generation of machine test code60for testing memory cache78of processor68is simplified and expedited by use of BISTE API source code55. Further, the use of ‘#define’ statements and macros in the source code (created during the development of BISTE API source code55) increases readability and maintainability of the processor's complex sequences used to control BISTE74.

Changes may be made in the above methods, apparatus and systems without departing from the scope hereof. For example, OTP memory76may be other memory, e.g., erasable-programmable read only memory (“EPROM”), electrically erasable programmable read only memory (“EEPROM”), non-volatile random access memory (“NVRAM”), etc. It should thus be noted that the matter contained in the above description or shown in the accompanying drawings should be interpreted as illustrative and not in a limiting sense. The following claims are intended to cover all generic and specific features described herein, as well as all statements of the scope of the present method and system, which, as a matter of language, might be said to fall there between.