Abstract:
An apparatus coupled to a low speed tester and a device is disclosed. The device may have a first speed faster than a second speed of the low speed tester. The apparatus may be configured to allow the low speed tester to perform high speed tests of the device at the first speed.

Description:
CROSS REFERENCE TO RELATED APPLICATIONS 
   The present application relates to co-pending application Ser. No. 09/658,894 filed Sep. 11, 2000. 
   FIELD OF THE INVENTION 
   The present invention relates to a method and/or architecture for verifying operation of a Universal Serial Bus (USB) device generally and, more particularly, to a method and/or architecture for verifying operation of a USB device with a production test mode device. 
   BACKGROUND OF THE INVENTION 
   The Universal Serial Bus (USB) Specification, Version 2.0, (published April 2000 and hereby incorporated by reference in its entirety) defines a high speed mode that operates at 480 MHz. Testing of such high speed devices can be difficult. Conventional solutions for implementing high speed testing include: (i) running tests on an expensive tester capable of 480 MHz operation; (ii) not performing at speed production testing (i.e., assuming the part is correct by design and operates at the high speed) and/or (iii) using a golden parts tester implementation for comparison purposes. A golden parts tester is a test-mode capable slave device, identical to the device which is being tested, that is capable of performing tests. There are disadvantages to each of the conventional approaches. 
   The first approach of simply implementing a high speed tester capable of 480 MHz testing is not a cost effective solution. Conventional high speed testers capable of 480 MHz operation and able to process a USB 2.0 design (which is largely digital) are at the state of the art in testers and, therefore, expensive. Furthermore, even a fast tester (i.e., a 480 MHz tester) can be problematic. Conventional at speed testers implement an internal phase lock loop (PLL) at 480 MHz. Synchronization of the 480 MHz tester to an incoming data rate is difficult. Verification of the incoming data rate is also difficult. Conventional high speed testers require a complex scheme to synchronize to a device under test (DUT). Additionally, the PLL will vary in phase from device to device and from test to test. 
   The second approach of not performing at speed production testing implies that the device is correct by design and well within the specification limits with a sufficient margin, as proven by full characterization. Specifically, not performing 480 MHz testing does not require expensive testing devices. Not performing at speed testing assumes that there are no plausible defects that can inhibit at speed operation (i.e., 480 MHz operation). 
   The approach of implementing a golden parts tester implementation (i.e., a replica of a target-only device implemented as a tester) for comparison purposes is not a possible tester solution for non peer-to-peer devices. The golden parts tester implementation cannot allow a replica of a target-only device to test another target-only device. A non peer-to-peer device (i.e., a USB device) cannot communicate to another non peer-to-peer device since they are non peer-to-peer devices. 
   USB implementations require a master and a slave device. However, slave devices cannot initiate communication. The golden part device expects to be a target (i.e., a slave) device and not a control (i.e., master) device. The golden parts tester cannot be implemented for a non peer-to-peer device, since peer-to-peer devices are not target-only devices. For example, a USB bus is not a peer-to-peer bus and the golden parts tester implementation is unable to communicate with another target-only device. 
   Therefore, it is desirable to provide a method and/or architecture to (i) enable slave devices to test other slave devices and/or (ii) add test mode enhanced slave device capabilities to a tester in order to test other non test mode slave devices. 
   SUMMARY OF THE INVENTION 
   One embodiment of the present invention concerns an apparatus comprising a plurality of target devices. At least one of the plurality of target devices may be configured as a control test device and may be capable of performing testing of the plurality of test devices. 
   Another embodiment of the present invention concerns an apparatus coupled to a low speed tester and a device. The apparatus may be configured to allow the low speed tester to perform high speed tests of the device. 
   The objects, features and advantages of the present invention include providing a method and/or architecture for verifying operation of a USB device that may (i) allow a low cost tester to verify high speed functionality, (ii) verify functionality of a part, (iii) enhance capabilities of a tester, (iv) create a test mode control (e.g., master) function in a target (e.g., slave) device and/or (v) allow testing of a target device by reconfiguring a replica of a target device as a control device. 

   
     BRIEF DESCRIPTION OF THE DRAWINGS 
     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 block diagram of a preferred embodiment of the present invention; 
       FIG. 2  is a flow diagram illustrating an operation of the present invention of  FIG. 1 ; 
       FIG. 3  is a block diagram of a preferred embodiment of the present invention; and 
       FIG. 4  is a flow diagram illustrating an operation of the present invention of  FIG. 3 . 
   

   DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
   The present invention may provide a method and/or architecture to verify a peripheral device (e.g., a USB 2.0 device) at a high speed operating frequency (e.g., 480 MHz). The present invention may provide such a verification in a production test facility without having to resort to an expensive tester capable of direct 480 MHz testing. The present invention may enhance an otherwise incapable tester device to perform testing of high speed devices. The present invention may provide a control test (e.g., master) function in a target (e.g., slave) device. Additionally, the present invention may test a target device by reconfiguring a replica of the target device as a control test device (e.g., a golden part). 
   Referring to  FIG. 1 , a block diagram of a circuit  100  is shown in accordance with a preferred embodiment of the present invention. The circuit  100  may illustrate a testing implementation of a target device by reconfiguring a replica of the target device as a test control device (golden part). The structure of the circuit  100  generally comprises a block (or circuit)  102  and a block (or circuit)  104 . In one example, the circuit  102  may be implemented as a golden part and the circuit  104  may be implemented as a device under test (DUT). However, the circuit  102  and the circuit  104  may each be implemented as another appropriate type device in order to meet the criteria of a particular implementation. 
   Initially, the golden part  102  may need to be tested and/or configured during fabrication. The golden part  102  may be required to be pre-tested to ensure full functionality. The golden part  102  may be similar and/or identical to the DUT  104 . The circuit  102  may be implemented as a golden part to transmit and receive data to/from the DUT  104 . The golden part  102  may implement a number of test modes in order to thoroughly test the DUT  104  (via transmit and receive operations). For example, the test modes may be implemented to test high speed operation, low speed operation, power down operation, suspend operation, etc. However, the golden part  102  and the DUT  104  may be required to be in a test mode operation in order to provide testing. The test modes of the golden part  102  and the DUT  104  may be asserted/deasserted by an external device (not shown). In a preferred implementation, the test modes may be controlled by a tester. 
   The circuit  102  may be implemented as a control device and the circuit  104  may be implemented as a target device. The circuit  102  may be configured via a number of input pins. For example, a particular test mode may be selected via a predetermined criteria. The golden part  102  and the DUT  104  may be configured to transfer and receive data in a target (e.g., slave) and control test (e.g., master) type configuration. The DUT  104  may be implemented as a target (e.g., slave) device of the golden part  102 . The transmission and reception of the master/slave type configurations of the DUT  104  may allow the circuit  100  to verify both a transmit and receive operation of the DUT  104 . The DUT  104  may transmit a packet of data in response to the golden part  102 . The circuit  102  and/or the circuit  104  may be controlled by a tester, state machine, etc. Additionally, the circuit  102  and the circuit  104  may be implemented on a single tester loadboard. 
   The golden part  102  may be similar to the DUT  104 . In particular, the golden part  102  may be a replica of the DUT  104 . However, the golden part  102  may be reconfigured to provide a testing interface with the DUT  104 . The golden part  102  may be reconfigured through conventional input/output pins when in the test mode. A test command may be received at an input (e.g., MO, M 1  and/or M 2 ) of the golden part  102  and/or the DUT  104 . The test commands may be initiated by a tester, a state machine, or the golden part where applicable. The golden part  102  may transmit the test packet based on the simple test command. The DUT  104  may receive and re-transmit the test packet from the golden part  102 . However, the DUT  104  may transmit a single packet, only after receiving a single packet from the golden part  102 . 
   The test packet may allow the golden part  102  to verify the DUT  104 . For example, the DUT  104  may (i) receive the test packet from the golden part  102  and test the packet for corruption;
         (ii) compare the packet to ensure an accurate reception; and (iii) transmit a test packet back to the golden part  102 . The golden part  102  may then test the packet for corruption. The golden part  102  may compare the packet to ensure an accurate transmission operation of the DUT  104 . The reception and transmission of the test packet may be implemented to verify the DUT  104 . Results of the comparison are generally available on an external pin (e.g., DONE) of the golden part  102  and/or the DUT  104  such that a pass/fail determination can be made. The pass/fail determination may be indicated by an asserted/deasserted signal.       

   The test packet sent and/or received by the DUT  104  may be of any applicable pattern loaded into an internal memory of the circuit  100  (not shown). Additionally, test packet comparison logic (not shown) may be shared with the test packet generation logic (not shown) of the golden part  102 , since the data packet is generally similar in both transmission and reception. The circuit  100  may allow the DUT  104  to transmit a packet to the golden part  102 . Additionally, the golden part  102  may validate the packet received from the DUT  104 . In a production test environment, control of transmission of the packet and the pass/fail signal (e.g., DONE) may be based on a low-speed asynchronous test interface (to be discussed in connection with  FIGS. 3 and 4 ). 
   By reversing the roles of the golden part  102  and DUT  104 , the circuit  100  may allow both the transmission and the reception operations of the DUT  104  to be verified. The circuit  100  may allow both the golden part  102  and the DUT  104  to run with crystals in an asynchronous fashion. The crystals may be different frequencies (e.g., slightly different frequencies, in order of ½%, 1% difference, sometimes less than ½% difference) in order to verify the ability of the DUT  104  to adapt to phase, as well as frequency differences that may be encountered in actual use. The circuit  100  may allow for deviations of frequency on the transmitted or received signals via a number of signals (e.g., DPLUS and DMINUS). 
   The circuit  100  may provide a special test mode that may allow a standard peripheral part that is normally a target device (e.g., a slave device) to become a host device (e.g., a master device) of a bus. For example, the circuit  100  may allow a slave device to become a host to control testing of a similar slave device. The circuit  100  may verify transmit and receive operations of a test device under test. Additionally, the circuit  100  may allow a non peer-to-peer device to be tested in a peer-to-peer like mode. 
   Referring to  FIG. 2 , a block diagram of a method (or process)  200  is shown in accordance with the present invention. The method  200  may be implemented to provide testing of a device. The method  200  may illustrate an exemplary operation of the circuit  100 . The method  200  generally comprises a portion  202  illustrating steps of the operation of a device under test and a portion  204  illustrating steps of the operation of a tester operation. The device under test portion  202  may illustrate an operation of a target-only device (e.g., the DUT  104 ). The tester operation portion  204  may illustrate an operation of a control test replica (e.g, the golden part  102 ) of the target-only device. The method  200  generally comprises an initialization section  206 , a transmit test section  208  and a receive test section  210 . The initialization section  206  may initialize the golden part  102  and the DUT  104 . The transmit test section  208  may test a transmission operation of the DUT  104 . The receive test section  210  may test a reception operation of the DUT  104 . 
   The initialization section  206  generally comprises an issue reset block  212  (for the device under test section  202 ) and an issue reset block  214  (for the tester section  204 ). The method  200  may be implemented to reset a device under test and a tester device. For example, the method  200  may reset the golden part  102  and the DUT  104 . In one example, the reset block  212  and the reset block  214  may be controlled by an external device (e.g., a tester). However, the reset block  212  and the reset block  214  may be controlled by another appropriate device in order to meet the criteria of a particular implementation. 
   The transmit test block  208  generally comprises a place in transmit mode state  216  (for the device under test portion  202 ) and a place in receive test mode state  218 , a decision block  220  and a decision block  222  (for the tester portion  204 ). The place in transmit test mode state  216  may place a DUT in a transmit test mode. The place in receive test mode state  218  may place a tester device in a receive test mode. The place in transit mode state  216  and the place in receive mode state  218  may allow a tester device to correctly test a transmit operation of the DUT. The tester portion (e.g., the golden part  102 )  204  may control the DUT portion (e.g., the DUT  104 )  202  during the transmit test block  208 . Additionally, the DUT portion  202  and/or the tester portion  204  may be controlled by another appropriate device. 
   The place in transmit test mode state  216  may proceed to the receive test section  210 , in response to a predetermined criteria. The place in transmit test mode  216  may proceed to the receive test section  210  in response to a specified time constraint (e.g., a USB time constraint) that may allow sufficient time for the transmit test to occur. However, the system  200  may be configured to respond to an internal signal, external signal, completion signal, etc. in order to meet the criteria of a particular implementation. 
   The decision state  220  may determine if a “DONE indication” has been received. The DONE indication may be implemented internal to the tester  204 . However, the DONE indication may be generated by another appropriate device in order to meet the criteria of a particular implementation. The DONE indication may indicate if a test packet has been correctly received by the tester device. If the DONE indication has been received, the decision block  220  may proceed to the receive test section  210 . If the DONE indication is not received, the decision block  220  may move to the decision block  222 . The decision block  222  may determine if a “DONE timeout” is to occur. In one example, the DONE timeout may be implemented as a specified time constraint. However, the DONE timeout may be controlled by another appropriate type device. If a DONE timeout is to occur, the decision block  222  generally proceeds to a test failed block  224 . If a DONE timeout is not to occur, the decision block  222  may proceed to the decision block  220 , repeating the DONE indication process (e.g., the decision blocks  220  and  222 ). 
   The receive test section  210  generally comprises a place in receive test mode state  226 , a decision state  228  and a decision state  230  (for the device under test section  202 ) and a place in transmit test mode state  232  (for the tester section  204 ). The tester  204  may be implemented to control the DUT  202  during the receive test block  210 . However, the DUT  202  and/or the tester  204  may be controlled by another appropriate type device. The state  226  may place the DUT in a receive test mode. The decision block  228  may check if a “DONE indication” has been received. The DONE indication may indicate if a test packet has been correctly received by the DUT. The DONE indication may be implemented internal to the DUT  202 . However, the DONE indication may be generated by another appropriate type device in order to meet the criteria of a particular implementation. If a DONE indication has been received, the decision block  228  may enter a test passed state  234 . If a DONE indication is not received, the decision block  228  may enter the decision block  230 . If the decision block  230  determines that a “DONE timeout” is to occur, the decision block  230  may enter the test failed block  224 . If the decision block  230  determines that a DONE timeout is not to occur, the decision block  230  may move to the decision block  228 . 
   The method  200  may illustrate testing of a target-only device with a replica of the target-only device. For example, the method  200  may illustrate testing of the DUT  104  with the golden part  102 . Each state of the method  200  may be independently controlled and/or implemented in order to meet the criteria of a particular implementation. However, in a preferred embodiment, an external tester may control the golden part  102  and/or the DUT  104 . The golden part  102  may be configured to perform tests on the DUT  104 . 
   Referring to  FIG. 3 , a system  300  is shown illustrating a high speed testing device derived from a low speed tester. The circuit  300  may allow testing of a device to be controlled by a low-speed asynchronous test interface. The system  300  generally comprises a conventional low speed tester  302  and a high speed wrapper  304 . The high speed wrapper  304  may allow the conventional low speed tester  302  to implement high speed testing of devices. The high speed wrapper  304  generally comprises a high speed host emulator  306  and a tester vectors section  308 . The high speed host emulator  306  and the test vectors section  208  may be implemented to perform high speed tests. The high speed wrapper  304  may allow the conventional low speed tester to test a high speed device. 
   The conventional low speed tester  302  may have an output  312  that may present a signal (e.g., PASS/FAIL), an output  314  that may present a transmission signal (e.g., TA), an input  316  that may receive a reception signal (e.g., RE) and an input  318  that may receive a signal (e.g., TV). The signal PASS/FAIL may indicate a pass/fail condition of a DUT  310 . The signal PASS/FAIL may be asserted and/or deasserted to indicate a particular condition of the DUT  310 . The test vectors section  308  may generate the signal TV. In one example, the signal TV may be implemented as testing vectors. However, the signal TV may be implemented as another appropriate type signal in order to meet the criteria of a particular implementation. The tester vectors  308  may provide testing vectors TV to the conventional low speed tester  302  in order to test the DUT  310 . 
   An input  320  of the high speed host emulator  306  may receive the signal TA. An output  322  of the high speed host emulator  306  may present the signal RE. Additionally, the high speed host emulator  306  may have an input/output  324  that may present/receive a signal (e.g., USB). An input/output  326  of the DUT  310  may present/receive the signal USB. In one example, the signal USB may be implemented as a bi-directional high speed interface signal (e.g., a USB bus). However, the signal USB may be implemented as another appropriate type signal (e.g., firewire, etc.) in order to meet the criteria of a particular implementation. The signal USB may allow the conventional low speed tester  302  (via the high speed wrapper  304 ) to perform verification of the DUT  310 . 
   Referring to  FIG. 4 , a flow diagram  400  is shown illustrating an operation of the system  300 . The flow diagram  400  generally comprises a state  402 , a state  404 , a decision block  406 , a decision block  408 , a decision block  410 , a decision block  412 , a result state  414  and a result state  416 . The state  402  may implement the low-speed tester  302  to issue a number of tester vectors to the host emulator  306 . The state  404  may implement the host emulator  306  to issue a number of features to the device under test  310 . The host emulator may be implemented as a test capable slave device. For example, the host emulator may be implemented as a USB host adapter. The test capable slave device may emulate a host device to transmit test packets. The state  402  and the state  404  may be controlled. 
   The decision block  406  may check to see if an acknowledge signal is received from the device under test  310 . If an acknowledge signal is received, the decision block  406  may move to the decision block  410 . If an acknowledge signal is not received, the decision block  406  may move to the decision block  410 . The acknowledge signal may be generated in response to an acknowledgment packet. The acknowledgment packet may be implemented as a handshake packet. The acknowledgment signal may confirm at a transmit and receive operation of the DUT  310 . 
   The decision block  408  may check for a bus turnaround timeout. The bus turnaround timeout may be implemented as a USB specified time constraint that may determine how long after a master device (e.g., the host emulator  306 ) sends a packet to wait for a target device (e.g., the DUT  310 ) to respond. The time duration may be short. However, the bulk of the time constraint may be devoted to tester setup and/or setting time. The USB turnaround time is generally 192 bit times (e.g., 384 ns). If a bus turnaround timeout occurs, the decision block  408  may move to the result block  414  and the device under test  310  fails. If a bus turnaround timeout does not occur, the decision block  408  may move back to the decision block  406 . The decision block  410  may check to see if a packet has been received from the device under test  310 . If the packet has been received, the decision block  410  may move to the result block  416  and the device under test  310  passes. If a packet has not been received from the device under test, the decision block  410  may move to the decision block  412 . The decision block  412  may check for a “DONE timeout”. If a DONE timeout has been received, the decision block  412  may move to the result block  414  and the device under test  310  generally fails. If the DONE timeout has not been detected, the decision block  412  may move back to the decision block  410 . 
   The system  100  (or  300 ) may allow a low-cost, low-speed tester to test a high-speed target-only part. Compared to existing methods, the present invention allows a low-cost tester to verify the high-speed functionality of a complex part. The system  100  (or  300 ) may allow a target-only (non peer-to-peer) USB device to act as an initiator of test packets. The system  100  may adapt USB 2.0 defined (e.g., required) test modes for implementation in a production test environment. The system  100  may extend capability of a USB target-only device to verify the reception of a test packet. Additionally, the system  300  may allow high-speed transmit, reception, and response checking to be under control of a low-speed tester-friendly interface. 
   The system  100  (or  300 ) may reduce test costs for a cost-sensitive but high-performance part. The system  100  may be applicable to devices for busses that are not peer-to-peer, such that using a golden part to verify a device under test requires the device to support a newly defined peer-to-peer test mode. Using the test method described, the functionality of the part can be verified not only in the ideal environment of a tester (e.g., using a fully synchronous high-speed tester) but is also verified in the more real-world situation of a slightly varying phase and frequency. The circuit  100  (or  300 ) may provide a level of verification that may be more complete than would be possible with a conventional high-speed tester. 
   The function performed by the flow diagrams  200  and/or  400  of  FIGS. 2 and 4  may be implemented using a conventional general purpose digital computer programmed according to the teachings of the present specification, as will be apparent to those skilled in the relevant art (s). Appropriate software coding can readily be prepared by skilled programmers based on the teachings of the present disclosure, as will also be apparent to those skilled in the relevant art(s). 
   The present invention may also be implemented by the preparation of ASICs, FPGAs, or by interconnecting an appropriate network of conventional component circuits, as is described herein, modifications of which will be readily apparent to those skilled in the art(s). 
   The present invention thus may also include a computer product which may be a storage medium including instructions which can be used to program a computer to perform a process in accordance with the present invention. The storage medium can include, but is not limited to, any type of disk including floppy disk, optical disk, CD-ROM, and magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMS, Flash memory, magnetic or optical cards, or any type of media suitable for storing electronic instructions. 
   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 spirit and scope of the invention.