1 / 20

ATML

ATML. IVI Signal Capability Model. Objective. Describe a signal-oriented model for requirements and capabilities in support of resource allocation Currently used with ATLAS Can be used with other languages / ADEs Used in IVI Signal Interface specification While not perfect, it works

emilie
Download Presentation

ATML

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. ATML IVI Signal Capability Model

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

  3. Principle • 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 IVI Signal Capability Model

  4. Example • Definition of Signal type AC SIGNAL • Signal parameters: IVI Signal Capability Model

  5. Example... not in use • Requirement: • Source of AC SIGNAL • VOLTAGE • Range 0V to 2V • FREQ • Range 100Hz to 1MHz • Resolution 1Hz • Accuracy 0.1Hz • CONN P1-1, P1-2 • Capability (FGen): • Source of AC SIGNAL • VOLTAGE, controllable • Range 0V to 5.0V • Resolution 1mV • Accuracy 0.1% • FREQ, controllable • Range 10Hz to 10MHz • Resolution 1Hz • Accuracy 0.05Hz • Source of AM Signal ... signal paths can be closed IVI Signal Capability Model

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

  7. Specifying requirements... • 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. IVI Signal Capability Model

  8. Specifying requirements... • IEEE 1641, Implicit, with existing BSC or TSF components Set STD = CreateObject("STD.Resource") Dim acInput As AC_SIGNAL Set acInput = STD.Require("AC_SIGNAL") acInput.ampl = "1 mV" acInput.freq = "1 kHz" Dim acSig As TwoWire Set acSig = STD.Require("TwoWire") acSig.hi = "PL1-1" acSig.lo = "PL1-2" Set acSig.In = acInput.out acSig.Out.Run Another version of Require() accepts requirements represented in XML IVI Signal Capability Model

  9. Specifying requirements... • Test Requirements Documents IVI Signal Capability Model

  10. Describing capabilities • 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 signal-oriented control of instruments • Note: Describes the capabilities of the instrument – signal driver subsystem • The performance delivered by the instrument depends on how it is configured by the signal driver IVI Signal Capability Model

  11. IVI Signal Capability Model Simplified • Signal Driver • Signal • Signal Role {Source, Sensor, Monitor, ...} • Signal Type (ex. “AC SIGNAL”) • Signal Parameter • Name (ex. “VOLTAGE”) • Signal Parameter Role {Controllable, Measurable, Capability} • [Value] • [Range: [Min], [Max]] • [Resolution] • [Accuracy: [AbsPlus], [AbsMinus], [RelPlus], [RelMinus]] • Signal Port • Connected Instrument Ports • Used Subsystems • Signal ... IVI Signal Capability Model

  12. IVI Signal Capability Model... Complete • Exclusive capabilities • Ex. DMM can measure DC SIGNAL or AC SIGNAL • Alternative capabilities • Ex. DMM can provide voltage_accuracy_1 for voltage_range_1 or voltage_accuracy_2 for voltage_range_2 • Interdependent capabilities • 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 • Ex: static digital channel and static digital IVI Signal Capability Model

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

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

  15. IVI Signal Capability Model... For more information: • IVI Signal Interface WG page: http://ivifoundation.org/Member%20Login/Signal-Interfaces/default.htm • Previous drafts - obsolete • PowerPoint files & minutes for past meetings • Draft 4 of specification (coming soon) • Requirements applicable to ATML: in Groove, Files / Working Groups / Instrument Description / Requirements & Use Cases/ ATML Instrument Use Cases and Requirements – TYX • 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 • XML equivalent of data structure exposed by IVI Signal Driver API IVI Signal Capability Model

  16. Limitations • 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: • 1. Use the same model to express capabilities at the UUT interface; use these capabilities for allocation • Problem: capabilities may also depend on signal paths through the switching subsystem • 2. Describe in ATML schemas the capabilities of switching subsystem, cables, receiver, ITA; the allocator calculates the capabilities at the UUT interface • Problem: calculation may be complex (ex. frequency-dependent transmission characteristics) or imprecise IVI Signal Capability Model

  17. Limitations... • 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 • 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

  18. Limitations... • 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 IVI Signal Capability Model

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

  20. Conclusions • 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 IVI Signal Capability Model

More Related