When designing and integrating a system of test instruments for performing tests and measurements on a device under test (DUT), it is important to insure that operations of the test instruments are properly timed and coordinated to insure that the test operations perform as expected.
For example, consider the simple case of testing a communication transmitter on several different transmit frequencies with a frequency counter and an RF power meter, all under the control of a test workstation. In such an arrangement, when it is desired to change the transmission channel for the transmitter and make measurements of frequency and power for the new channel, it would be important to insure that the transmission signal is stabilized in frequency and power on the new channel before making the measurements. It would also be necessary to insure that the frequency counter and an RF power meter output signals have stabilized before recording the test data. One can easily see that there are a wide variety of possibly unspecified time delays which must be accounted for in designing the test routine. Such delays include signal propagation delays, set-up times for the test instruments and the transmitter under test, delays for the transmitter to change channels and for its output power to settle/stabilize, etc.
In the past, the test system designer has had limited knowledge and/or control of the timing of these various operations. Furthermore, the test system designer has also had a limited set of tools available to control the sequencing, timing, and synchronization of the operations among the test instruments and DUT. As a result, the designer controls the timing of the operations through a combination of time delays within the instruments, and programmatic delays and interrupts within the test programs controlling the test system.
In general, a test system designer would like more detailed and precise knowledge (and control) of the timing of events in the test system. In many cases, the lack of such information and control may force the test system designer to result to trial-and-error to adjust delays in the system to insure reliable operation and optimize performance. This is particularly problematic when designing a complicated test system, with perhaps dozens of interconnected test instruments, especially when it is desired to minimize test times. As a result, the costs of designing and integrating the test system are increased.
Another particularly troublesome problem may occur when a test system is to be maintained or upgraded and it is either necessary or desirable to replace one or more existing test instruments with newer instruments that have better performance, lower cost, or both. In such a case, it is often the case that the newer instruments operate with different speeds and delays than the “legacy” instruments. When the new instrument(s) are substituted, the timing and coordination of events within the test system may be substantially altered such tat the test system no longer operates properly. So the test system designer has to revise the test program(s) to compensate for the changes in speed and/or delay to restore the system's timing to its prior condition.
However, there is typically very little information available to the designer to understand how the “old” test system configuration timing worked, or what to do to restore the timing to a working arrangement. As noted above, often the designer of the “old” test system may have resorted to trial-and-error to set delays and interrupts for various instruments and in the test program software in the first place. As a result, the designer has few if any attractive options available for replicating the timing conditions of the original test system—and the challenge can be even more difficult in situations where the test software has little documentation of its timing, and/or the original test system designer is no longer available for consultation. Accordingly, the designer typically must resort to experimentally adding and removing delays from the test algorithm by trial-and-error, and/or attempting to analyze the test programs to extract the timing relationships.
The approaches to test system design and maintenance as described above are costly and time-consuming, which in turn can lengthen development times for a test system, and lead to “down time” for the test system when maintenance or upgrades of the test system must be performed. Also, these trial-and-error modifications often degrade the test system performance by increasing test times. These problems are considered to be “facts of life” in test system design and maintenance.
What would be useful, therefore, would be a method for providing better tracking and reporting of the timing and/or sequencing of events in a test system. What would further be useful would be a system for analyzing timing and events in a test system.
In an example embodiment, a method is provided for analyzing the timing of events in a test system comprising a device under test and a plurality of test instruments connected together by one or more communication connections. The method comprises: time-stamping events in a test routine executed by the test instruments under control of a test program to generate time-stamped event data; communicating the time-stamped event data to a central processor; and processing the time-stamped data to output information about the timing of the events.
In another example embodiment, an event timing analyzer is provided for a test system comprising a plurality of test instruments connected together by one or more communication connections, and adapted to perform a test routine for a device under test under control of a test program. The event timing analyzer comprises: means for time-stamping events in a test routine to produce time-stamped event data; and means for communicating the time-stamped event data to a central processor.
In yet another example embodiment, an event timing analysis system is provided for a test system comprising a plurality of test instruments connected together by one or more communication connections, and adapted to perform a test routine for a device under test under control of a test program. The event timing analysis system comprises: a communications port adapted to receive event data; and a processor and memory for storing processor instructions to cause the processor to process the event data and to output information about the timing of the events.
The example embodiments are best understood from the following detailed description when read with the accompanying drawing figures. It is emphasized that the various features are not necessarily drawn to scale. In fact, the dimensions may be arbitrarily increased or decreased for clarity of discussion. Wherever applicable and practical, like reference numerals refer to like elements.
In the following detailed description, for purposes of explanation and not limitation, example embodiments disclosing specific details are set forth in order to provide a thorough understanding of an embodiment according to the present teachings. However, it will be apparent to one having ordinary skill in the art having had the benefit of the present disclosure that other embodiments according to the present teachings that depart from the specific details disclosed herein remain within the scope of the appended claims. Moreover, descriptions of well-known apparati and methods may be omitted so as to not obscure the description of the example embodiments. Such methods and apparati are clearly within the scope of the present teachings.
Of benefit, test system 100A further includes an event timing analysis system comprising event and timing analyzer 115A and a plurality of monitoring devices connected to various communication connections utilized by test system 100. Monitoring devices include serial bus monitor 125A, GPIB monitor 145A, and PXI monitor 155A. A LAN connects these monitoring devices via LAN switch 165 to event and timing analyzer 115A. Monitoring devices 125A, 145A and 155A monitor the occurrence of events of interest on the buses and interfaces to which they are connected.
In the arrangement of
Although the functional block diagram of
Events of interest that may be detected by the monitoring devices include: traffic on a GPIB bus or a USB bus; traffic on a LAN (e.g., a packet containing an LXI LAN trigger); traffic on a VXI or PXI backplane; traffic on a standard serial or parallel port; signal events occurring on an analog, RF, optical or digital communication path; transitions on an LXI wired trigger bus; transitions on instrument-specific input/output trigger lines. Of course this list is meant to be exemplary, not exhaustive, and so other types of events may also be detected.
In test system 100A, some or all of serial bus monitor 125A, GPIB monitor 145A, PXI monitor 155A, and/or analog/digital/RF signal monitor 185A may operate using a system clock provided by test workstation 110 or event and timing analyzer 115A. In that case, the monitoring device detects an event occurring on its connected bus with the resolution of a clock period of the system clock, and sends the indication of the event's occurrence to event and timing analyzer 115A for time-stamping and further processing as will be discussed in further detail below. As shown in
However, in the embodiment described above, the events are detected and time-stamped with limited resolution, because they are all controlled by the system clock. Furthermore, delays and timing jitter in this communication path can adversely impact the resulting timestamp.
Accordingly, to address these limitations,
In one embodiment, one or all of the monitoring devices of test system 100B include hardware, software and/or firmware to allow operation according to the IEEE-1588 precision time protocol as specified in “IEEE 1588-2002 Standard,” the contents of which are incorporated herein by reference, With IEEE-1588-enabled monitoring devices, the event timing analysis system including an event and timing analyzer 115B can observe and report on events detected in the communication connections of test system 100B with greater detail and accuracy.
In this embodiment, the event timing analysis system including event and timing analyzer 115B and the IEEE-1588 enabled monitoring devices may operate as follows. Each monitoring device monitors events, time-stamps the events using a commonly-distributed IEEE-1588 timebase, and stores the time-stamped event data in a buffer. The monitoring devices are connected to event and timing analyzer 115B via switch boundary clock 130. Switch boundary clock 130 participates in the IEEE-1588 synchronization protocol so that timing delays and jitter in the normal LAN switching process do not adversely impact synchronization across the monitoring devices. In another embodiment, switch boundary clock 130 may be replaced by a transparent clock as defined in IEEE-1588, version 2.
It would also be beneficial in system 100B to provide software modifications or “hooks” in a test program executed by test workstation 110. As an executing thread passes a monitoring point, it would log an event and attach a time-stamp. In a beneficial arrangement, acquired events are time-stamped and buffered for later transmission to analysis software running on event and timing analyzer 115B.
In another arrangement, test workstation 110 may have a time-based mechanism such as a built-in IEEE-1588 capability. For example, an adapter card (e.g., a PCI-based card) in test workstation 110 may implement a commonly distributed time-base mechanism such as IEEE-1588, and this is used to generate the time-stamps. In that case, as shown in
In test system 100A of
Monitoring device 200 may monitor one communication connection (e.g., the GPIB bus) of test system 100, and accordingly test systems 100A, 100B and 100C may include a plurality of monitoring devices 200. Alternatively, monitoring device 200 may be an event monitor for a plurality of communication connections, including some or all of a serial bus (including USB), a parallel bus, a GPIB bus, a VXI or PXI backplane, a LAN, an analog connection, an RF or microwave connection, an optical connection, an LXI wired trigger bus, an instrument-specific input/output trigger line, etc.
The embodiment of a monitoring device 200 shown in
A signal on a communication connection (e.g., on a bus, on a LAN, at input or output connector; etc.) of test system 100A, 100B or 100C is monitored via monitor input port 205. The signal is mirrored onto mirror output port 210 so it can be processed by test system 100 as intended. That can be referred to as passive or pass-through monitoring.
The physical layer 220 outputs digital “symbols” that are time-stamped in time-stamp block 225. In one embodiment, processor 280 is IEEE-1588 precision time protocol hardware for outputting a timestamp corresponding to an edge on a latch input received from physical layer interface 220. Time-stamp buffer 230 buffers the symbols and corresponding time-stamps. Event detector 240 analyzes sequences of symbols for events; for example event detector 240 might detect a sequence of symbols/characters such as “reset” in a bus monitoring application. Event detector 240 could be a pattern matcher or a programmable machine (e.g. finite state machine). Event detector 240 can be used to filter out irrelevant symbols and events. Matched sequences are formed into events with an associated time-stamp and placed into event data and time-stamp buffer 250. When monitoring is complete data processor 260 implements transactions for forwarding the time-stamped event data to an event timing analyzer—for example, event timing analyzer 115A, 115B, or 115C of
An explanation of operations of event timing analyzers 115A-115C will now be provided.
In one embodiment, event timing analyzers 115A-115C each include software running on a general purpose processor. The software collects all of the events acquired by all of the monitoring devices and sorts all of the events for further processing. In one embodiment, the analysis software includes a graphical user interface (GUI) component that may provide a rich graphical interface to a user. Event timing analyzers 115A-115C may provide one or all of the following capabilities to a user.
The ability to display events in a natural manner depending on their type.
The ability to zoom in and out of segments of time.
The ability to display events on a time line.
The ability to filter events.
The ability to search for events or combinations of events.
The ability to group and label combinations of events.
The ability to treat a combination or sequence of events as a single named unit.
The ability to open and inspect the events comprising the unit in detail.
The ability to annotate events or groups of events with additional information (comments, graphs, pictures, tables of data, etcetera).
The ability to apply formulas, expressions, or software programs to groups of event data to form synthesized data or events. For example a current measurement and voltage measurement could be used to compute a power measurement, which could be associated with time. Graphical data (e.g. charts) could also be computed and displayed using this capability.
The ability to display intervals during which information is valid in addition to discrete points in time.
The ability to perform a statistical analysis of repeating cycles of events.
The ability to automatically find of the beginning and ending of a cycle.
The ability to merge cycles from different monitoring trials.
The ability to find and display outliers (e.g. trigger jitter relative to a fixed event in a cycle).
The ability to perform automated mean, standard deviation, minimum and/or maximum, analyses for the relative time between two events.
The ability to output a schedule(s) or computer program(s) that can be used to emulate the timing of a legacy system. The schedules or programs would be used with instruments having a common time-base (e.g. IEEE-1588) that could be used to schedule events (e.g. LXI triggers, events, etc.).
The statistical analysis of cycles is useful both in analyzing legacy test systems that are being converted to time-based systems, and also in determining the performance of new time-based systems. Even new time-based systems will have time variability in them due to the presence of non-deterministic elements such as computers and LAN, and determining the timing envelope will allow explicitly timed actions to be adjusted to make for a more robust system.
In the arrangement of
In test system 300 the instruments 320, 332, 334, 342, 344, and 350 themselves all maintain a common precision time. For example, instruments 320, 332, 334, 342, 344, and 350 may all be IEEE-1588 enabled devices which all maintain a common precision time according to the IEEE-1588 protocol.
Of benefit, in the embodiment of
Event and timing analyzer 315 may process event data as explained above with respect to timing analyzers 115A-115C of
In similarity to test systems 100A-100C in
In some embodiments, monitoring devices described above (including test instruments, standalone monitoring devices, and/or event analyzer workstations) are able to store additional state and measurement variables present in the monitoring device along with the detected event. This is particularly useful in the case where the monitoring device is a test instrument, for example, in the case of a digital multimeter (DMM), one might want the voltage measurements and/or state of the instrument when capturing and time-stamping the event to read the voltage.
While example embodiments are disclosed herein, one of ordinary skill in the art appreciates that many variations that are in accordance with the present teachings are possible and remain within the scope of the appended claims. The embodiments therefore are not to be restricted except within the scope of the appended claims.