ATML IVI Signal Capability Model April 2005 IVI

ATML IVI Signal Capability Model April 2005 IVI Signal Capability Model

Objective n Describe a signal-oriented model for requirements and capabilities in support of resource allocation ¨ Currently used with ATLAS n Can be used with other languages / ADEs n Used in IVI Signal Interface specification ¨ While not perfect, it works n Validated through usage n Can be enhanced to overcome limitations April 2005 IVI Signal Capability Model 2

Principle n n Each signal has a signal type Signal types definitions specify signal parameters (attributes) Requirements and capabilities are expressed in terms of range, resolution and accuracy of signal parameters Allocation algorithm searches for a resource whose capabilities match or exceed requirements April 2005 IVI Signal Capability Model 3

Example n Definition of Signal type AC SIGNAL ¨ Signal Name parameters: Data type Unit Default value Range VOLTAGE Double V >0 FREQ Double Hz ≥ 0 DC_OFFSET Double April 2005 V 0. 0 IVI Signal Capability Model 4

Example. . . n not in use Requirement: n ¨ Source of AC SIGNAL ¨ VOLTAGE n Capability (FGen): ¨ Source of AC SIGNAL n VOLTAGE, controllable ¨ Range 0 V to 2 V ¨ ¨ FREQ n n n ¨ n Range 100 Hz to 1 MHz Resolution 1 Hz Accuracy 0. 1 Hz ¨ CONN P 1 -1, P 1 -2 Range 0 V to 5. 0 V Resolution 1 m. V Accuracy 0. 1% FREQ, controllable ¨ ¨ ¨ Range 10 Hz to 10 MHz Resolution 1 Hz Accuracy 0. 05 Hz ¨ Source of AM Signal. . . signal paths can be closed April 2005 IVI Signal Capability Model 5

Specifying requirements n ATLAS ¨ Implicit, in signal statements APPLY, AC SIGNAL, VOLTAGE 1 V, FREQ 100 HZ, DC-OFFSET 0 V, CNX HI P 1 -1 LO P 1 -1 $ ¨ Explicit – REQUIRE statement n Example: AC sweep changes frequency – range must be indicated in advance REQUIRE, ‘AC SUPPLY’, SOURCE, AC SIGNAL, CONTROL, VOLTAGE RANGE 0 V TO 2 V, FREQ RANGE 100 HZ TO 1 MHZ BY 1 HZ ERRLMT 0. 1 HZ, CNX HI LO $ APPLY, AC SIGNAL USING ‘AC SUPPLY’, VOLTAGE 1 V, FREQ 100 HZ, DC-OFFSET 0 V, CNX HI P 1 -1 LO P 1 -1 $ CHANGE, . . . April 2005 IVI Signal Capability Model 6

Specifying requirements. . . n n Note: In many situations TPS developers specify directly the instrument to be used (in ATLAS, USING) The resource allocator can still verify requirements against capabilities ¨ An allocation error is generated if the capabilities of a replacement instrument do not satisfy requirements. April 2005 IVI Signal Capability Model 7

Specifying requirements. . . n IEEE 1641, Implicit, with existing BSC or TSF components Set STD = Create. Object("STD. Resource") Dim ac. Input As AC_SIGNAL Set ac. Input = STD. Require("AC_SIGNAL") ac. Input. ampl = "1 m. V" Another version of Require() ac. Input. freq = "1 k. Hz" accepts requirements represented in XML Dim ac. Sig As Two. Wire Set ac. Sig = STD. Require("Two. Wire") ac. Sig. hi = "PL 1 -1" ac. Sig. lo = "PL 1 -2" Set ac. Sig. In = ac. Input. out ac. Sig. Out. Run April 2005 IVI Signal Capability Model 8

Specifying requirements. . . n Test Requirements Documents April 2005 IVI Signal Capability Model 9

Describing capabilities n n ATLAS ADEs supporting automatic allocation: usually a proprietary file format IVI Signal Drivers: data structure accessible through the driver API ¨ IVI Signal Interface: driver API supporting the signaloriented control of instruments ¨ Note: Describes the capabilities of the instrument – signal driver subsystem n April 2005 The performance delivered by the instrument depends on how it is configured by the signal driver IVI Signal Capability Model 10

IVI Signal Capability Model Simplified n Signal Driver ¨ Signal n n n Signal Role {Source, Sensor, Monitor, . . . } Signal Type (ex. “AC SIGNAL”) Signal Parameter ¨ ¨ ¨ n Signal Port ¨ n ¨ April 2005 Name (ex. “VOLTAGE”) Signal Parameter Role {Controllable, Measurable, Capability} [Value] [Range: [Min], [Max]] [Resolution] [Accuracy: [Abs. Plus], [Abs. Minus], [Rel. Plus], [Rel. Minus]] Connected Instrument Ports Used Subsystems Signal. . . IVI Signal Capability Model 11

IVI Signal Capability Model. . . Complete n Exclusive capabilities ¨ n Alternative capabilities ¨ n n Ex. DMM can provide voltage_accuracy_1 for voltage_range_1 or voltage_accuracy_2 for voltage_range_2 Interdependent capabilities ¨ n Ex. DMM can measure DC SIGNAL or AC SIGNAL Ex. DMM can provide voltage_accuracy_1 for frequency_range_1 or voltage_accuracy_2 for frequency_range_2 Support for switch modules and internal switches of instruments Hierarchical signals ¨ April 2005 Ex: static digital channel and static digital IVI Signal Capability Model 12

IVI Signal Capability Model n Signal Type Specification ¨ 1641 TSF signals ¨ 1641 signal attributes n Amplitude, frequency, DC offset, phase ¨ Parameters n describing signal quality Overshoot, linearity, noise, harmonics, etc. ¨ Parameters for the “complementary” parameter n April 2005 Current, for a voltage source IVI Signal Capability Model 13

IVI Signal Capability Model. . . n n The principle is validated through use in ATLAS systems The implementation was validated through prototyping ¨ IVI signal drivers n n n ¨ Signal Object Library n n ¨ n Bandwidth test – Visual Basic Signal transfer tests – Test. Base test executive, IEEE 1641 signals Interchangeability demonstration n n April 2005 COM API supports signal-oriented testing with GPLs Run-time engine provides automatic resource allocation and switch path calculation TPSs n ¨ “Traditional” instruments Sound card as “synthetic” instrument Digital instrument Serial bus Switch Instrument replacement Re-hosting IVI Signal Capability Model 14

IVI Signal Capability Model. . . For more information: ¨ IVI Signal Interface WG page: http: //ivifoundation. org/Member%20 Login/Signal-Interfaces/default. htm n n n ¨ Requirements applicable to ATML: in Groove, Files / Working Groups / Instrument Description / Requirements & Use Cases/ ATML Instrument Use Cases and Requirements – TYX n ¨ Previous drafts - obsolete Power. Point files & minutes for past meetings Draft 4 of specification (coming soon) Originate from TYX experience with ATLAS implementations and IVI Signal Interface design process Prototype schema & sample instance documents: in Groove, Files / Working Groups / Instrument Description / Requirements & Use Cases/ IVI Signal Capability Schema for ATML. zip n April 2005 XML equivalent of data structure exposed by IVI Signal Driver API IVI Signal Capability Model 15

Limitations n Capabilities available at UUT pins are often different from the capabilities of the individual instruments ¨ See Mike Seavey’s posting to Test Configuration discussion tool in Groove ¨ Possible solutions: n 1. Use the same model to express capabilities at the UUT interface; use these capabilities for allocation ¨ n 2. Describe in ATML schemas the capabilities of switching subsystem, cables, receiver, ITA; the allocator calculates the capabilities at the UUT interface ¨ April 2005 Problem: capabilities may also depend on signal paths through the switching subsystem Problem: calculation may be complex (ex. frequency-dependent transmission characteristics) or imprecise IVI Signal Capability Model 16

Limitations. . . n Signal-oriented requirements may be insufficient for measurement operations ¨ Signal-oriented requirements describe the signal waveform “when the UUT is good” ¨ Measurement may be difficult or impossible to perform when the UUT is bad n April 2005 Example: because the signal is distorted, the trigger levels calculated based on the “good” waveform are wrong; the scope does not synchronize IVI Signal Capability Model 17

Limitations. . . n The model relies on external signal type definitions. This may be impractical in the case of complex waveforms, due to their infinite diversity. ¨ Complex waveforms are typically generated with ARBs or synthetic instruments. Thus, the waveform shape is no longer an allocation criterion (any shape can be generated). ¨ Allocation is typically based on signal parameters that are not directly related to the shape, ex. maximum sampling frequency, amplitude resolution, etc. ¨ Sampled signals with arbitrary waveforms are supported in ATLAS by the single signal type WAVEFORM ¨ Conclusion: this is not a limitation April 2005 IVI Signal Capability Model 18

Support in ATML (suggested) n Requirements: ¨ Test Description ¨ Possibly, schema for XML snippets to be embedded in test program code n Capabilities: ¨ Instrument Description (same spec, ¨ Tester Configuration ¨ TBD (maybe Interface Adapter). . . n or separate spec) Note: Models for requirements & capabilities are similar but not identical ¨ Separate schemas will likely be needed ¨ Reusable types may end up in Common April 2005 IVI Signal Capability Model 19

Conclusions n n n A powerful signal-oriented model for requirements and capabilities exists Simple enough to allow interchangeable implementation of resource allocation Ability to handle complex use cases validated through usage Can be enhanced to overcome existing limitations Necessary for supporting existing ATLAS systems April 2005 IVI Signal Capability Model 20