1. Field of the Invention
This invention pertains to test software used to test and debug electrical circuits and, more particularly, such devices that use a Joint Test Action Group (JTAG) port.
2. Description of the Related Art
With the complexity and increase of pin-count of new computer chips and the dense assembly of these chips on circuit boards, it becomes increasingly difficult to test and debug the circuit boards after being assembled. A group of leading electronic companies has joint joined forces and developed a standard test port to be built on every chip. The purpose of this test port is to allow connection to a test tool to validate the connection of each pin on the chip. Some chips add more functionality to this test port to provide access to virtually any resource inside the chip such as RAM, registers or I/O ports. One example of an in situ test port is the “JTAG” (Joint Test Action Group) test port adopted by the Institute of Electrical and Electronics Engineers, Inc, and defined as the IEEE standard 1149.1.
A common use of a test port is to test the components of a circuit board such as memory, Flash memory, Input/output chips and the on-board CPU. The test port can also be used to test the solder joints and the functionality of some of the onboard chips, and to program FLASH memory chips.
The common method of testing such circuit is to use a JTAG bus-master controller to control the JTAG bus and all the devices under test connected to this controller. The JTAG-bus controller is normally enclosed in a test equipment which has its own CPU and memory as shown in
One disadvantage of this method is the repeated use of the interpreter code if the test procedure has to be rerun more than one time. For each test cycle, the interpreter has to read the test code, analyze it and generate the appropriate commands for the JTAG-test bus controller. This consumes additional time which slows the test cycle.
It is an object of the present invention to provide a JTAG code compiler that can compile the test code at once and then store the data and code to be executed by the JTAG-bus controller in memory so that it can be accessed repeatedly without the need to interpret it every time the test is run.
The JTAG code compiler can be either executed using the test tool CPU or using another computer and then transferred to the test tool for execution.
The compiler will read the provided test information which could be in text, SVF, BSDL or any other format not directly executable by the JTAG-bus controller. This information would normally need interpretation before execution by the JTAG-bus controller. The compiler will generate JTAG-bus transactions that are directly executable by the JTAG-bus controller and store it in memory for execution. The data used for the test, such as test victors, would be translated into formats, such as binary format, that can be stored in the memory ready for execution and directly supplied to the JTAG-bus controller. The compiler should have the ability to manage and allocate memory spaces for code and data storage so that it can be accessible during test execution. Using such memory management, multiple scan data can be stored and ready for test execution.
Any of these features if integrated in the current solution will help increase the test speed. Combining all of these features in a single solution adds a lot of speed to the existing solution.
Referring to the accompanying
Referring to
The compiler does not have to generate any code for execution by any other device in addition to the instructions used by the JTAG-bus controller. The test tool CPU can be used to start the test procedure and setup the initial test parameters but is not needed during the execution of the test. This can be done as a part of the operating system functionality of the test tool CPU that allows it to receive the compiler output and store it in memory to be ready for delivery and execution by the JTAG-bus controller. The JTAG-bus controller can use one or multiple DMA request and acknowledge signals to request data and instructions from the memory structure. These data and instructions are to be used by the JTAG-bus controller and are different from data scans and instructions scans that will be sent to the TAP controllers to execute JTAG test functions.
An example for such a function is to initiate a SCAN-DR function in a SVF format. The SVF code to be executed is:
SDR 32 TDI (89ABCDEF);
This statement is used to send the value 0X89ABCDEF to the object under test. The incoming date from the object under test will be stored in a separate location.
For this code, the compiler will generate the command for the JTAG-bus controller to initiate the SCAN-DR function for 32-bit of data and will allocate the needed memory space (8 bytes) to store the data-in and data-out values for the operation and additionally will attach pointers to said instruction to specify said memory spaces to be used with the generated instruction to be executed by the JTAG-bus controller. It can optionally set the end state of the JTAG bus.
At execution, the instruction will be sent to the JTAG-bus controller and the data read from memory and written to the controller. The incoming date from the JTAG-bus will be written to the memory space allocated by the compiler. As stated before, the data and instructions can be moved from the memory to the controller using a DMA controller or a similar device.
The JTAG-bus controller can be also modified to allow the direct access to the instructions and data from the memory structure. This will increase the speed of the test procedure.
The compiler will be able to compile multiple JTAG functions and allocate and manage multiple memory spaces to store scan data. It does that by dividing a large memory space to smaller spaces each capable of storing data for a specific JTAG function. Some of the data that are input from the JTAG-bus for one function can be used as output data in a following function. In such a case, the compiler will allocate a single memory structure and allocate its address pointers to two functions one as input and the other as output, which allows a more efficient use of the memory space.
In compliance with the statute, the invention described herein has been described in language more or less specific as to structural features. It should be understood; however, that the invention is not limited to the specific features shown, since the means and construction shown, is comprised only of the preferred embodiments for putting the invention into effect. The invention is therefore claimed in any of its forms or modifications within the legitimate and valid scope of the amended claims, appropriately interpreted in accordance with the doctrine of equivalents.