Cache based physical layer self test

A software self test engine is executed from a cache of a processor. The software self test engine is executed using an execution engine of the processor to perform a physical layer self test. The physical layer self test is performed by transmitting a test vector from the execution engine under control of the self test engine to an input/output (“I/O”) unit of the processor along a datapath coupling the execution engine to the I/O unit. The test vector is transmitted along a loop back path including the I/O unit and the datapath to test a hardware device along the loop back path.

TECHNICAL FIELD

This disclosure relates generally to built in self testing, and in particular but not exclusively, relates to input/output built in self testing.

BACKGROUND INFORMATION

In many integrated circuit technologies, a short between a signal line and one of ground or a power supply can cause the signal line to be “stuck at” a fixed voltage level. Other manufacturing flaws can cause a switch to be “stuck open”, “stuck closed”, or generate an erroneous output for a given set of inputs. For analog circuitry, faults may present themselves as an erroneous impedance, driver output strength, and receiver offset. Other errors are possible. Built in self test (“BIST”) is a circuit design technique in which physical elements of a circuit are devoted to testing the circuit itself to identify, for example, stuck at faults. Input/output BIST (“IBIST”) is a design technique for testing input/output (“I/O”) circuitry.

FIG. 1is a block diagram illustrating a central processing unit (“CPU”)100having a processor core for executing software instructions coupled via a datapath to an I/O unit for communicating with devices external to the CPU. CPU100includes IBIST logic105that may be internal to the I/O unit or integrated along side the I/O unit. IBIST logic105is physical test circuitry cast into the silicon of CPU100along side operation circuitry for the express purpose of testing the operation circuitry of the I/O unit. IBIST logic105may include logic to directly stimulate the I/O unit with test vectors strategically designed to test certain portions of the I/O unit to determine whether these portions contain a manufacturing flaw.

DETAILED DESCRIPTION

Embodiments of a system and method for implementing a software self test engine are described herein. In the following description numerous specific details are set forth to provide a thorough understanding of the embodiments. One skilled in the relevant art will recognize, however, that the techniques described herein can be practiced without one or more of the specific details, or with other methods, components, materials, etc. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring certain aspects.

FIG. 2is a block diagram illustrating a processor200capable of receiving and executing a software self test engine, in accordance with an embodiment of the present invention. The illustrated embodiment of processor200includes an execution engine205(a.k.a. processor core), a cache210, a datapath215, an input/output (“I/O”) unit220, and test access ports (“TAPs”)225and230.

The components of processor200are interconnected as follows. Execution engine205is coupled to cache210to receive and execute instructions therefrom. Cache210may represent any cache coupled to execution engine205, such as level1and level2cache, system random access memory (“RAM”), and the like. In one embodiment, a software self test engine235and test vectors (or test generation algorithms)240may be loaded into cache210via TAP230. Once loaded into cache210, execution engine205can execute software self test engine235from cache210.

In one embodiment, software self test engine235is a virtual input/output built in self test (“IBIST”) module that replicates the functionality of hardware IBIST circuitry. Software self test engine235leverages the presence of execution engine205to perform self test functionality that would otherwise require dedicated IBIST logic cast in silicon. Software self test engine235performs physical layer self tests to execute design verification and/or test for manufacturing defects in I/O circuitry. I/O circuitry may include any hardware/logic that is accessible to execution engine205.

Execution engine205is further coupled to I/O unit220via datapath215. In one embodiment, datapath215is a 20-bit wide bus coupling I/O unit220to execution engine205. Datapath215may include simple signal lines to a complex network of drivers, receivers, buffers, latches, repeaters, alignment circuitry, and the like, to convey data back and forth between I/O unit220and execution engine205. Executing software self test engine235from cache210enables test exercises to be run on datapath215itself. These tests may target datapath215to search for defects or characterize the performance of datapath215. It should be noted that traditional hardware IBIST circuits (e.g., IBIST105) would not have access to datapath215and therefore could not test datapath215.

I/O unit220provides a link to external devices not integrated into the die of processor200. For example, I/O unit220may couple to a system bus245(e.g., front side bus), which in turn couples to any number of external hardware devices. These external hardware devices may include typical devices disposed on a motherboard. For example, system bus245may couple to a memory interface (e.g., memory controller hub), an I/O interface (e.g., I/O controller hub), a graphics interface (e.g., advance graphics port), and the like.

I/O unit220includes a transceiver250for transmitting/receiving data to/from system bus245. Transceiver250includes drivers255to transmit data onto system bus245and transmit buffers260to buffer the data received along datapath215prior to transmitting onto system bus245. Transceiver250further includes receivers265coupled to receive data from system bus245and receive buffers270coupled to temporarily buffer the received data prior to forwarding the received data to execution engine205via datapath215.

The illustrated embodiment of I/O unit220further includes control and status registers (“CSRs”)275. CSRs275enable I/O unit220to be programmed with command data and save status information. In one embodiment, CSRs275may be externally written to via TAP225. In one embodiment, CSRs275are exposed and accessible to execution engine205over datapath215. In the latter embodiment, execution engine205and/or I/O unit220may include decode logic280to enable execution engine205to address and map CSRs275. During normal operation of processor die200, CSRs275are hidden or otherwise locked out from execution engine205and applications executing on execution engine205. However, during a self-test mode of operation, execution engine205is granted access to CSRs275. In one embodiment, software self test engine235includes a key to access CSRs275during the self-test mode of operation. Thus, CSRs275may be accessible both externally to a technician or test equipment via TAP225and/or internally to execution engine205via datapath215.

FIG. 3is a block diagram illustrating a motherboard300including processor200capable to execute a software self test engine to test hardware devices along a loop back path, in accordance with an embodiment of the present invention. The illustrated embodiment of motherboard300includes processor200, a slave device305, and a slave device310. In the illustrated embodiment, each slave device305and310includes one or more transceivers312, similar to transceiver250, to receive and transmit data thereon.

Slave devices305and310represent devices external to processor200(i.e., not integrated onto the die of processor200) coupled to processor200via I/O unit220. For example, slave device305may be a memory interface, a graphics interface, or a repeater, while slave device310may be the actual memory unit or graphics engine. Slave devices305and310may be “daisy chained” to system bus245, as illustrated, or multiple slave devices may be directly coupled to system bus245(not illustrated).

Each of I/O unit220, slave device305, and slave device310can be placed in a loop back test mode to test hardware circuitry along a loop back path315. I/O unit220can be placed into the loop back test mode by software self test engine235accessing CSR275via datapath215and writing command data to CSR275. Similarly, software self test engine235can place each of slave devices305and310into the loop back test mode by accessing and writing command data to CSR320and325, respectively.

The processes explained below are described in terms of computer software and hardware. The techniques described may constitute machine-executable instructions embodied within a machine (e.g., computer) readable medium, that when executed by a machine will cause the machine to perform the operations described. The order in which some or all of the process blocks appear in each process should not be deemed limiting. Rather, one of ordinary skill in the art having the benefit of the present disclosure will understand that some of the process blocks may be executed in a variety of orders not illustrated.

FIG. 4is a flow chart illustrating a process400to implement physical layer self tests using a cache based software self test engine, in accordance with an embodiment of the present invention.

In a process block405, software self test engine235is transferred into cache210. In one embodiment, software self test engine235is transferred into cache210via TAP230. In this embodiment, software self test engine235may be used to perform physical layer self test before any operating system (“OS”) is loaded by processor200. In one embodiment, software self test engine235is transferred into cache210via an ordinary software install during OS runtime. In this latter embodiment, software self test engine235may be executed to perform various design verification tests (e.g., stress tests that determine operational limits of hardware coupled to execution engine205along loopback path315). It should be appreciated that design verification tests may be performed after testing for manufacturing flaws and I/O unit220and datapath215are known to be free of disabling manufacturing flaws.

In a process block410, execution engine205under the control of software self test engine235writes command data to one or more of CSRs275,320, and325to place one or more of I/O unit220, slave device305, and slave device310into the loop back test mode. Placing one or more of I/O unit220, slave device305, and slave device310into the loop back test mode enables software self test engine235to transmit test vectors330onto datapath215that are routed back to software self test engine235as response vectors335along loop back path315.

In one embodiment, software self test engine235can configure I/O unit220to perform near-end self tests that only test the functionality of datapath215and I/O unit220. During these near-end tests, loop back path315is shortened to loop back along path340. In one embodiment, software self test engine235can configure I/O unit220and slave device305to perform far-end self tests that test the functionality of datapath215, I/O unit220, and slave device305. During these far end tests, loop back path315is selectively adjusted to loop back along one of paths345or350. In one embodiment, software self test engine235can configure I/O unit220, slave device305, and slave device310to perform deep far-end tests that test the functionality of datapath215, I/O unit220, slave device305, and slave device310. During these deep far-end tests, loop back path315is lengthened to loop back along a path355.

In a process block415, software self test engine235transmits control data onto datapath215to adjust operating parameters of the device under test. For example, transceiver250may include 64 individual drivers255and transmit buffers260, each corresponding to a bit line of system bus245. In this case, software self test engine235may transmit control data to I/O unit220to enable one of the driver circuits for testing. In one embodiment, the control data is written to one or more of CSRs275,320, and325to setup and target various components (e.g., transceivers250and312) in each of I/O unit220and slave devices305and310for physical layer self testing.

In a process block420, software self test engine235transmits test vectors330over datapath215to I/O unit220. Test vectors330are selected to rigourously test hardware along loop back path315. For example, test vector330may include 256 alternating “0” and “1” bits to test whether a particular driver circuit of transceivers250or312is functioning properly. Test vectors330transmitted over datapath215may be obtained by software self test engine235from cache210where they are stored as test vectors240. As discussed above, test vectors240can be uploaded into cache210via TAP230as a pre-configured set of test vectors, pseudo-randomly generated by software self test engine235itself using the processing resources of execution engine205, generated according to preconfigured guidelines, or a combinations thereof.

Once transmitted, test vector330is looped back along loop back path315as response vector335(process block425). In a decision block430, if software self test engine235is testing for a manufacturing flaws, then process400continues to a process block435. In process block435, software self test engine235analyzes response vector335to determine whether a manufacturing flaw exits along loop back path315. Manufacturing flaws may include stuck at faults, shorts, parasitic capacitances, and the like. Since test vectors330are transmitted over datapath330, a manufacturing flaw within datapath215can be tested for and discovered using the techniques described herein. Furthermore, by beginning with near-end tests and gradually extending loop back path315out to include far-end and deep far-end testing, hardware flaws can be isolated to a particular component of motherboard300or processor200.

In one embodiment, analyzing response vector335includes comparing response vector335against test vector330to determine whether the two vectors are identical. If response vector335is supposed to return to software self test engine235as an identical replica to the transmitted test vector330, but instead returns with a bit flipped, then software self test engine235may determine a flaw exists. In one embodiment, response vector335is compared bit-by-bit against the transmitted test vector335. In one embodiment, checksums are computed for each of test vector330and response vector335and the checksums are compared. In other embodiments, response vectors335are intended to change in a known manner after traversing loop back path315. In a process block440, software self test engine235logs a pass and/or fail for each test vector330and response vector335pair. The number of errors occurring in response vector335can be counted and a bit error rate (“BER”) of the loop back path315calculated.

Returning to decision block430, if software self test engine235is testing for design verification, then process400continues to a process block445. In process block445, software self test engine235analyzes response vector335to determine design parameters. Testing for design verification may include stress testing various components (e.g., datapath215) to determine maximum clock speeds, signal margins, BERs, testing for clock harmonic responses, and the like. For example, software self test engine235may adjust sampling timing of I/O unit220on datapath215and/or system bus245to determine signal margins. In a process block440, software self test engine235logs a pass and/or fail for each test vector330and response vector335pair.

In a decision block455, software self test engine235determines whether all test vectors240have been transmitted. If not, process400returns to process block415and continues therefrom as described above. It should be noted that multiple test vectors may be transmitted without adjusting operating parameters of I/O unit220, slave device305, or slave device310and therefore, process block415may be periodically skipped. If all the test vectors have been transmitted and the self testing complete, then process400continues to a process block460to generate a pass/fail report. In one embodiment, the pass/fail report is stored in cache210and downloaded from cache210via TAP230.

Implementing IBIST functionality using software self test engine235loaded into cache210provides added flexibility. Often optimal test vectors for verifying problematic portions of a processor are not known until the processor is taped out and entered high volume manufacturing for sale. Since current IBIST engines are finite state machines cast in silicon, adding a new optimized set of test vectors can be very costly requiring a new tape out of the processor die. However, embodiments of the present invention enable circuit designers, original equipment manufactures, and the like to augment existing test vectors with new ones as they become available, simply by uploading the new test vectors via TAP230into cache210. Additionally, software self test engine235helps ameliorate the tremendous burden of extensive pre-silicon validation and post silicon debug of extensive design for test features imbedded in silicon, as well as, the expense and lengthy turn around time to fix bugs or add enhancements to the design for test circuitry.

FIG. 5is a diagram illustrating a demonstrative processing system500for implementing embodiments of the present invention. The illustrated embodiment of system500includes a chassis510, a monitor515, a mouse520(or other pointing device), and a keyboard525. The illustrated embodiment of chassis510further includes a floppy disk drive530, a hard disk535, a compact disc (“CD”) and/or digital video disc (“DVD”) drive537, a power supply (not shown), and motherboard300populated with appropriate integrated circuits including system memory545, nonvolatile (“NV”) memory550, and one or more processor(s)200.

Processor(s)200is communicatively coupled to system memory545, NV memory550, hard disk535, floppy disk drive530, and CD/DVD drive537via a chipset on motherboard300to send and to receive instructions or data thereto/therefrom. In one embodiment, NV memory550is a flash memory device. In other embodiments, NV memory550includes any one of read only memory (“ROM”), programmable ROM, erasable programmable ROM, electrically erasable programmable ROM, or the like. In one embodiment, system memory545includes random access memory (“RAM”), such as dynamic RAM (“DRAM”), synchronous DRAM, (“SDRAM”), double data rate SDRAM (“DDR SDRAM”), static RAM (“SRAM”), and the like. In various embodiments, either of NV memory550or system memory545may represent slave device310, while a memory controller/interface (not illustrated) may represent slave device305.

Hard disk535represents any storage device for software data, applications, and/or operating systems, but will most typically be a nonvolatile storage device. Hard disk535may optionally include one or more of an integrated drive electronic (“IDE”) hard disk, an enhanced IDE (“EIDE”) hard disk, a redundant array of independent disks (“RAID”), a small computer system interface (“SCSI”) hard disk, and the like.

In one embodiment, a network interface card (“NIC”) (not shown) is coupled to an expansion slot (not shown) of motherboard300. The NIC is for connecting system500to a network560, such as a local area network, wide area network, or the Internet. In one embodiment network560is further coupled to a remote computer565, such that system500and remote computer565can communicate.