Patent Grant
8370537
This invention relates to electronic systems and more particularly to trigger router and a test system with trigger router.
Unlike single function instruments where the firmware is largely static after development, since hardware functionality is predefined and fixed, a multi-purpose test system such as a source measure switching system with plug-in cards that can be removed and inserted in the field does not have this luxury. As new plug-in cards such as switching, signal source, and instrumentation plug-in cards for the platform are developed, inevitably the main firmware of the test system, which can also be referred to as a source measure switching system, will suffer from a lack of awareness and support features for the new plug-in cards that precludes its use without modification.
From a solution standpoint, several options address the issue mentioned above. The simplest option is to mandate firmware upgrades each time a new plug-in card development occurs. While this is the simplest option, it is also the most costly for both the manufacturer and the customer and limits the appeal of the instrument, given the fairly constant need for upgrades to the firmware.
The second option takes classes of general plug-in card descriptors to describe different cards in a reasonably generic manner. Each plug-in card carries a descriptor that the source measure switching system can then read to determine specific properties of the plug-in card. Although this solution offers significantly better adaptability than the first, when a new plug-in card can not fit into one of the existing descriptor classes, a mainframe firmware update would be required in order to describe the functionality of the new class of card. This solution also suffers from the problem that it requires a certain degree of rigidity and conformity, even within a descriptor class, to make the solution viable. This fact effectively limits the ability to create inexpensive hybrid cards that can meet the specific needs of semi-custom, customer-driven applications as an illustrative example.
Test system environments typically require the ability to switch signals from one instrument or instrument to another, be able to measure signals, or detect stimulus actions in a high speed and deterministic manner. Given the space premium found in today's testing environments, test applications require test systems that can provide the ability to detect and generate trigger signals for the test system while occupying the least amount of space and provide for maximum flexibility.
The features of the present invention, which are believed to be novel, are set forth with particularity in the appended claims. The invention may best be understood by reference to the following description, taken in conjunction with the accompanying drawings, in the several figures of which like reference numerals identify like elements, and in which:
While the specification concludes with claims defining the features of the invention that are regarded as novel, it is believed that the invention will be better understood from a consideration of the following description in conjunction with the drawing figures.
The present invention provides for a test system with trigger router that has the ability to route and configure trigger signals between a controller, intermodules and from external sources, coupled with the use of a deterministic sequencer that provides deterministic timing when operating in conjunction with a central processing unit (CPU) as shown in
Non-Real-Time Operating Systems (“Non-RTOS”) such as Linux or Windows allow the use of standardized development tools and environments with the disadvantage of their non-deterministic timing that can be a drawback in test system environments where tight system timing and measurement throughput are important. Alternatively, real-time versions of Linux or Windows are available, but they incur increased development complexity and other tradeoffs.
Referring now to
The source measure switching system 100 also includes in one embodiment a 10/100 Base T Ethernet port 110 which can be used for system communications as well as downloading new operating system versions and LXI web pages. A USB 1.1 device port 112 allows for an alternative command port to the Ethernet port 110. An IEEE-488 standard interface or GPIB bus 114 provides a further alternative command port. A RS-232 interface 116 is used for transferring debug messages (Linux console output). A USB 2.0 Host port 118 allows for connection to an external USB storage device to store/recall scan lists and sequences.
An external Trigger In (TRIG IN) input 120 is routed to a sequence engine 130 so that a trigger signal can be routed through a system trigger matrix to other slots, the sequence engine, etc. in the source measure switching system 100. An external Trigger Out (TRIG OUT) output 122 is routed through the trigger router located within the sequence engine 130 in order to provide a variety of trigger options as will be discussed further below. A Reference In/Out (REF IN/OUT) clock router interface 124 allows a reference clock input to be routed among the slots, or allows a clock generated from a plug-in module to be routed to the output. The REF IN/OUT 124 can be programmed as an input or an output. A bus referred herein as the X Bus 128 allows for one or more Xi slot card slots 126 which can accept switching cards or instrument plug-in modules. The X bus in one embodiment comprises a 66 MHz instrument bus to communicate with the Xi cards; the X bus includes data verification and auto-retry. The X bus will be discussed further below. The Xi card slots 126 are also coupled to an analog bus 136. A PXI bus 132 is used as an interface between one or more PXI instrument card slots 134 that can interface/control PXI bus compatible plug-in cards.
In addition to the above, the test system 100 employs a high-speed sequence engine also referred to as a real-time sequencer/scanner 130 capable of making deterministic instrument control operations in microsecond intervals. Contrast this with a microprocessor running the best RTOS available and the performance is at best deterministic to sub-milliseconds, or a Non-RTOS operating system such as Windows or Linux with a non-deterministic multi-millisecond response. In one embodiment the sequencer or sequence engine 130 is implemented via a field programmable gate array (FPGA).
Unlike a microprocessor which typically lacks time determinism (because of interrupts and processing delays), the sequencer 130 used in the source measure switching system 130 is entirely sequential and deterministic to approximately ten-microsecond resolution. It also is fully capable of executing opcode instructions having potentially indefinite completion times and monitoring multiple asynchronous inputs simultaneously without using interrupts—a behavior typically not permissible in ordinary microprocessors. As shown in
In an alternative embodiment, the 130 sequencer can comprise two or more sequencers. For example if two sequencers are present, one is used for immediate command execution and another can be used for deferred use in sequence/scan mode. The two sequencers can be connected to an internal bus arbitrator to prevent contention and also tied to logic necessary for communication over an “X Bus” 128 (described below) interface to one or more installed cards. Additional sequencers beyond two can be utilized for improved system performance, with increased parallel operation and sequence branching. In order to optimize the platform to/for analog, digital, and switching plug in cards, it was necessary to create a new system interface bus which would be optimized for digital control, configurable triggering and interrupts, high speed, fault tolerant, and also include low noise, high-voltage, high-current, and high-bandwidth analog buses. This was accomplished with a new bus design referred to herein as “X-Bus” which includes high-speed low-noise digital communications and both differential and single ended analog buses. The bus structure also includes customizable trigger routing between modules. In addition to the custom bus for specialized instrumentation, the system also includes a standard PXI bus to allow for the inclusion of standard PXI cards.
The control of the plug in card instrumentation requires the application of synchronized and deterministic time-specific commands. This is accomplished in the instrument through sequencer commands and dedicated state machines to control bus communications. The sequencer commands are first defined as high level functional operations which can then be broken down into lower-level sequential operations which can then be stored and executed in a sequencer to control the modules. Rather than creating a new scripting language for the high-level functional operations, our language will be based upon existing industry standard SCPI commands.
In order to reduce CPU and FPGA sequencer external event detection latencies, an autonomous trigger router system is introduced. The trigger router is a fully configurable trigger input and trigger output routing matrix. In one embodiment, the trigger router allows for 16 trigger inputs, although a different number of inputs can be designed for depending on the particular design at hand. Twelve inputs are from twelve slots. Two inputs are from two Scan Sequencers, and two are from two external trigger inputs located on the rear panel of test system 100. The trigger router can also allow for direct connection between modules in order to achieve minimum latency.
In one embodiment, every trigger input can be configured via 4 detection modes: active high, active low, level high, and level low. Every trigger input can be routed to every trigger output. Every trigger output can be configured for input to output delay, output edge active high or active low, output level high or level low, trigger pulse width, trigger repeat cycles (auto or input triggered), and trigger scan interval timer. The trigger scan interval can be configured for up to 1276 hours. Any trigger output can also be configured to be triggered on single trigger, multiple triggers, or auto trigger if set.
Analog Bus
Test system 100 provides an analog bus 136 including 4 pairs of two-wire analog bus and 8 single-ended analog bus lines. The analog bus 136 allows for multiple DMMs to run on separate analog buses. The analog bus lines are designated ABUS1 through ABUS4 for the two-wire buses, and SABUS1 through SABUS8 for the single-ended buses. Each analog bus line is relay-configurable. Normally (at power-up), the slots on the left half of the mainframe (5 Xi slots for one version) are separated from the slots on the right half of the mainframe (4 Xi slots for another version). Each bus can span the halves of the mainframe by closing a relay. There are twelve relay channels that are accessible to the user to connect the analog bus lines.
These channels are controlled by selecting module “0”, which refers to the mainframe instead of a plug-in module. The channel numbers associated with these are:
So, for example, the command CLOSE (@0(1:4)) connects all of the two-wire analog bus lines ABUS1 to ABUS4 on slots 1 through 5 to the analog bus lines ABUS1 to ABUS4 on slots 6 through 9. Similarly OPEN (@0(18)) disconnects analog bus line SABUS8 on slots 1 through 5 from the analog bus line SABUS8 on slots 6 through 9. The analog bus does not provide access to the PXI plug-in modules. Connection to the PXI plug-in modules is accomplished with external cabling. For the plug-in modules which do support connecting to the analog bus, channels 9001 through 9004 shall be used in conjunction with the “[ROUTe:]CLOSe” command to connect to the selected two-wire analog bus lines. Similarly, channels 9011 through 9018 are reserved for connecting the switch card to the single-ended analog bus lines. In order for these channel designations to remain consistent throughout the system, no relay module channel can assign a channel number greater than 8999.
DMM Support
Test system 100 can support up to 4 plug-in PXI DMM in one embodiment. Support levels can be adjusted depending on design requirements. In one embodiment, the DMM model that has been selected for the platform is the Signametrics SMX2064 DMM. This DMM provides up to 7½ digit accuracy.
The following measurement types can be supported in one embodiment of test system 100:
DC Voltage;
AC Voltage;
2-Wire Resistance;
4-Wire Resistance;
6-Wire Resistance;
DC Current;
AC Current;
Capacitance;
Inductance;
Diode Characterization;
Period;
Frequency;
Duty Cycle
Count (Totalize);
Time Interval (pulse width); and
Temperature.
The following stimulus types shall be supported in one embodiment of test system 100 (or designs can includes other stimulus types):
DC Voltage;
AC Voltage; and
Pulse Generator.
Other embodiments of the invention would allow for use of other PXI compatible instruments.
In
System Startup and Initialization
Given that the source measure switching system 100 uses a Linux OS in one embodiment, knowing exactly how the system reaches the state described in
Prior to describing how startup activities in the source measure switching system 100 use this feature, knowing how it works from a hardware standpoint is critical to deploying it. As shown in
The up to 16 separate windows into card memory space allow the core process at its discretion, to assign a unique window to an individual thread. Provided that no other thread inadvertently uses a window not assigned to it, atomicity between operations to the trio of registers within the window is not necessary. Consequently this allows the software architecture to avoid overheads associated with mutex locking necessary to avoid race conditions in a shared arrangement.
The X Bus communication protocol has the ability to pipeline/burst data in block memory-mapped transfer mode for faster transfer times. Once a programmer specifies an address location in the memory select register, the FPGA 130 allows sequential accesses to either the card write or read registers without another update. In fact, it is actually counter-productive to write to the address select register unless necessary since it forces a pipeline/burst reset of the X Bus communication state machine.
As
Normally, libraries pose some unique challenges to software architecture planning. For starters, libraries under Linux fall into one of two major classes: static or dynamic. Static libraries are those with the “.a” suffix. This type of library must be re-linked to the main application anytime a change occurs within the library since the entry points for functions within the library are likely to move. The other challenge this library style creates occurs when multiple libraries with identical function names are loaded. This creates ambiguous references for the linker.
Clearly a static library arrangement is therefore not conducive to the source measure switching system architecture. Not only does the embedded environment lack native tool chains capable of re-linking the application to accommodate card libraries at startup, it is entirely possible that identical plug-in cards with identical libraries (and function names) will exist in the system. The second major library class under the Linux environment is dynamic in nature. This most common form today of this type of library is the shared dynamic library. A dynamic shared library typically carries a “.so” file suffix and can be found in the root system library directory.
Unlike static libraries, dynamic shared libraries linked into an application do not get included with the application. Instead the linker makes references to the function names used in an application for which the Linux kernel dynamically determines the execution entry points when the application first starts. While this technique provides a significant improvement over static libraries, it still does not address what happens if an application needs multiple libraries that use a common API interface with identical function names.
Fortunately Linux provides a solution to this problem. Using the Linux dlsym( ) function call, an application that requires support from a particular library can determine a physical function pointer to the library's implementation of a desired function. Hence this erases ambiguity since the running application controls this behavior rather than a context-unaware dynamic linker, as highlighted in
The core process is also responsible for launching subsidiary child processes that handle remote communications to the outside world. Effectively a dedicated remote communication handling process exists for any major communication pathway into the instrument. Consequently all GPIB communications use the GPIB remote communication process, dynamic web-based accesses use the applet server remote communication process, and so forth.
The final stage of initialization for the source measure switching system 100 from a software architecture standpoint is shown in
External SCPI Message Transport
As
While the SCPI communication standard lost some favor during the VXI days when hardware interfaces supported direct, high-speed register-based access, it has regained value in ethernet-driven products. Ethernet solutions (for which LXI embraces) are not conducive to direct register-based access. Therefore a SCPI or other message-based communication format must be adopted to facilitate communication. Since SCPI offers hardware interface agnostic behavior that works equally well with ethernet, USB, and GPIB, this time-tested standard has an important place in the source measure switching system's software architecture.
The SCPI standard mandates certain behaviors that drive the implementation of a single master SCPI message processor. Since the standard requires sequential behavior in command execution and proscribes parallel command execution paths, this works to the advantage of a product like the source measure switching system with multiple remote interfaces capable of operating concurrently. From a coding standpoint, implementing state machines based on sequential logic proves much simpler than those that have to account for parallel behavior. Each remote interface therefore only need be served in a first-in, first-out round-robin arrangement.
With a presumption that a single master parser in the core source measure switching system's firmware process shall handle command and query activity, other architecture-specific software details now come into focus. Described earlier and illustrated in
Full compliance with the SCPI standard implies implementation of the IEEE-488.2 status reporting model. With the requirements established thus far, this software architecture implements a concept where one or more independent “virtual” instrument clients operate an obscured, single “real” instrument. Each virtual instrument in effect is self-contained and implements complete message and error queues, a response buffer, and IEEE-488.2 status registers. For interfaces that support multiple sessions like Ethernet, this approach easily allows each session to act as a virtual instrument also.
One issue results from this approach however. The IEEE-488.2 status reporting standard heralds from the days of GPIB—well before the idea of a single instrument talking to multiple computers and users was even possible. Unfortunately this standard creates some problems when applied to today's technology. The question about the significance of say the “PON” or power-on bit in the extended status register where multiple “virtual” instruments exist becomes grey—since this is technically related to the state of the real instrument and not the virtual instrument. Clearly in the present approach every time a new virtual instrument is opened the PON bit would be set which likely doesn't adhere with the intentions of the standard.
The source measure switching system is fully compliant with IEEE-488.2 status reporting model when the user sticks to using a single virtual client. If the user decides to use more than one virtual client, it is unreasonable to assume the source measure switching system should religiously comply with a standard that is impossible to satisfy because of future technical problems not foreseen when the standard first evolved.
Unlike previous source measure switching systems, where the main firmware required a certain amount of card awareness in one form or another, the present invention takes a different tack of distributed intelligence. It is possible using careful abstraction and compartmentalization to create two separate pieces of firmware that communicate with each other in a highly-generic sense without revealing or requiring any knowledge of how the other works internally.
If the abstraction and compartmentalization is divided cleanly between firmware servicing the main source measure switching system instrument and that provided by a particular card to service itself, the possibility of introducing new cards with support for previously undefined features becomes a reality. This can all be done without requiring main firmware updates, provided the role of the main firmware is limited to overall message routing, system supervision, and coordination activities between the outside world and individual cards present in the source measure switching system.
In practice, building the required level of abstraction and compartmentalization is tricky. For starters, dynamically bringing two or more completely different pieces of firmware together without recompilation and relinking necessitates the use of a sophisticated operating system to carefully manage the interactions through pipes, sockets, file systems, and/or dynamic libraries.
Trigger Router
The test system's trigger router is a fully configurable trigger input and trigger output routing matrix. The trigger router allows 16 trigger inputs. Twelve inputs are from twelve slots. Two inputs are from two Scan Sequencers, and two are from two external trigger inputs located on the rear panel. Every trigger input can be configured via 4 detection modes: active high, active low, level high, and level low. Every trigger input can be routed to every trigger output. Every trigger output can be configured for input to output delay, output edge active high or active low, output level high or level low, trigger pulse width, trigger repeat cycles (auto or input triggered), and trigger scan interval timer. Trigger scan interval can be configured up to 1276 hours. Any trigger output can also be configured to be triggered on single trigger, multiple triggers, or auto trigger if set.
Trigger Control Registers
Trigger router control requires a group of registers for each trigger input or output which are part of the trigger router. These are:
TROUTE(16-bit), TIN_ENB(1-bit), TOUT_ENB(1-bit), TIN_EDGE(1-bit), TIN_LEVEL(1-bit), TOUT_EDGE(1-bit), TOUT_LEVEL(1-bit), TRIGGER_ARM(1-bit), TRIGGER_AUTO(1-bit), TOUT_DELAY(16-bit), TOUT_WIDTH(16-bit), TOUT_DURA0(32-bit), TOUT_DURA1(4-bit), and TOUT_REPEAT(16-bit) registers. These registers are fully explained on Tables 1.1 through 1.14. Trigger input and trigger output set up process is fully explained on Tables 1.15 through 1.18.
Trigger Input and Output Configuration Process
Then the trigger output can be configured individually as illustrated by the flow diagram in
Trigger Input and Output by Examples
Trigger configurations can be best illustrated by examples As shown in
Trigger output to card #7 is set to auto-triggered and be repeated 5 times. The trigger output is configured to as rising edge. The trigger output delay is at 15.663 sec. The trigger pulse width is 2357 μsec. The trigger scan interval timer is set at 0.45056 sec.
Trigger output to card #8 is set to be triggered on trigger input #1 three times. The trigger output is configured to as rising edge. The trigger input to output delay is set to 15.663 sec. The trigger pulse width is 2099 μsec. The trigger scan interval timer is set at 0.53248 sec. Auto mode is off.
Trigger output to scan #1 is set to be triggered on trigger input #8 on single shot. The trigger output is configured to as rising edge. The trigger input to output delay is set to 0 sec. The trigger pulse width is 1792 μsec. The trigger scan interval timer is set at 0. Auto mode is off.
Then the trigger output can be configured individually.
The trigger router shown in
As shown in
While the preferred embodiments of the invention have been illustrated and described, it will be clear that the invention is not so limited. Numerous modifications, changes, variations, substitutions and equivalents will occur to those skilled in the art without departing from the spirit and scope of the present invention as defined by the appended claims.
This application claims the benefit of U.S. Provisional Patent Application No. 61/094,969, filed Sep. 7, 2008, which is incorporated herein by reference in its entirety.
| Number | Name | Date | Kind |
|---|---|---|---|
| 7152186 | Airaud et al. | Dec 2006 | B2 |
| 20050182583 | Miyazaki et al. | Aug 2005 | A1 |
| Number | Date | Country | |
|---|---|---|---|
| 20100076715 A1 | Mar 2010 | US |
| Number | Date | Country | |
|---|---|---|---|
| 61094969 | Sep 2008 | US |
