1. Bradford G. Van Treuren March 16, 2016 How Virtual Instrument Virtual Architecture (VISA) relates to SJTAG What can we learn from VISA? (Part I)

2. System JTAG What is VISA? The Virtual Instrument Software Architecture (VISA) is a standard for configuring, programming, and troubleshooting instrumentation systems comprising GPIB, VXI, PXI, Serial, Ethernet, and/or USB interfaces. VISA provides the programming interface between the hardware and development environments. VISA was originally standardized through the VXIplug&play Alliance, a now- defunct T&M standards body. The current standard, "VISA Specification 5.0", is maintained by the IVI Foundation.IVI Foundation

3. System JTAG IVI Architecture http://www.ivifoundation.org/about/Architecture.aspx

4. System JTAG Instrument Classes http://www.ivifoundation.org/about/Instrument_classes.aspx  To enable interchangeability, the foundation creates IVI class specifications that define the base class capabilities and class extension capabilities for some of the most popular instrument classes. There are currently thirteen instrument classes defined: Digital multimeter (DMM) Oscilloscope Arbitrary waveform/function generator DC power supply AC power supply Switch Power meter Spectrum analyzer RF signal generator Upconverter Downconverter Digitizer Counter/timer

5. System JTAG VIRTUAL INSTRUMENT SYSTEM ARCHITECTURE (VISA) IVI FOUNDATION SPECIFICATIONS  http://www.ivifoundati on.org/specifications/ http://www.ivifoundati on.org/specifications/  IVIDriver  IVI Specific Driver  IVI Class ‑ compliant Specific Driver  IVI Custom Specific Driver  IVI Class Driver  API Classes  IVI-C  IVI-COM  IVI.Net Types of IVI Drivers

6. System JTAG Types of IVI Drivers Excerpts from: IVI ‑ 3.1: Driver Architecture Specification  IVIDriver: An IVI driver is an instrument driver that implements the inherent capabilities detailed in IVI ‑ 3.2: Inherent Capabilities Specification, regardless of whether the driver complies with a class specification. IVI drivers can communicate directly to the instrument hardware or act as a pass through layer to another IVI driver. An IVI driver is either an IVI specific driver or an IVI class driver.  IVI Specific Driver: An IVI specific driver is an IVI driver that contains information for controlling a particular instrument or family of instruments and communicates directly with the instrument hardware. For example, IVI specific drivers control message ‑ based instrument hardware by sending command strings and parsing responses.  IVI Class ‑ compliant Specific Driver: An IVI class ‑ compliant specific driver is an IVI specific driver that complies with one of the defined IVI class specifications. For example, an IVI class ‑ compliant specific driver for an oscilloscope exports the API defined by the IviScope class specification. A user should use an IVI class ‑ compliant specific driver when hardware independence is desired.

7. System JTAG Types of IVI Drivers Excerpts from: IVI ‑ 3.1: Driver Architecture Specification  IVI Custom Specific Driver: An IVI custom specific driver is an IVI specific driver that is not compliant with one of the defined IVI class specifications. IVI custom specific drivers cannot be used for hardware interchangeability because they export a custom API. IVI custom specific drivers are typically created for use with specialized instruments, such as an optical attenuator.  IVI Class Driver: An IVI class driver is an IVI driver that allows users to interchange instruments when using IVI class ‑ compliant specific drivers. IVI class drivers export an API that complies with one of the defined IVI class specifications. IVI class drivers communicate to instruments through an IVI class ‑ compliant specific driver. For example, an IviScope class driver exposes the functions, attributes, and attribute values defined in the IviScope class specification. An application program makes calls to an IviScope class driver. The IviScope class driver, in turn, makes calls to an IviScope ‑ compliant specific driver that communicates with an oscilloscope. IVI class drivers are necessary for interchangeability when using IVI ‑ C class ‑ compliant specific drivers. IVI class drivers may also communicate to instruments through IVI ‑ COM class ‑ compliant specific drivers.

8. System JTAG IVI Class-Compliant Specific Driver API Types Excerpts from: IVI ‑ 3.1: Driver Architecture Specification  IVI-C: IVI drivers that that have a C API. For example, an IVI ‑ C class ‑ compliant specific driver is an IVI specific driver that exports a C API and complies with one of the defined IVI class specifications. IVI ‑ C drivers are distributed on Windows to users in the form of a Win32 ‑ DLL. Many commonly used application development environments, such as Agilent VEE, LabVIEW, LabWindows/CVI, and Visual C++ support calling into a C DLL. To achieve interchangeability with an IVI ‑ C specific driver, the user’s application program must make calls to an IVI class driver.  IVI-COM: IVI drivers that have a COM API. For example, an IVI ‑ COM class ‑ compliant specific driver is an IVI specific driver that exports a COM API that complies with one of the defined IVI class specifications. IVI ‑ COM drivers are distributed on Windows to users in the form of a Win32 ‑ DLL. Many commonly used application development environments, such as Agilent VEE, LabVIEW, LabWindows/CVI, and Visual C++ support calling a COM object. To achieve interchangeability with an IVI ‑ COM class ‑ compliant specific driver, the user’s application program must make a call to the IVI ‑ COM Session Factory, a software component defined by the IVI Foundation.

9. System JTAG IVI Class-Compliant Specific Driver API Types Excerpts from: IVI ‑ 3.1: Driver Architecture Specification  IVI.Net: IVI drivers that have a.NET API. For example, an IVI.NET class ‑ compliant specific driver is an IVI specific driver that exports a.NET API and complies with one of the defined IVI class specifications. IVI.NET drivers are distributed on Windows to users in the form of a.NET assembly. Many commonly used application development environments, such as C#, VB.NET, LabVIEW, Agilent VEE, and managed Visual C++ support calling into a.NET assembly. To achieve interchangeability with an IVI.NET specific driver, the user’s application program must make a call to one of the IVI.NET session factory methods. These factories are defined and implemented by the IVI Foundation.

10. System JTAG Capabilities that all IVI instrument drivers are required to implement IVI-3.2: Inherent Capabilities Specification Each driver must provide the compliant set of Attributes/Properties for a particular class of driver Each driver must provide the compliant set of Functions/Methods for a particular class of driver In the case of.Net and COM drivers, the driver implementer also must provide the corresponding session factory

11. System JTAG Capabilities that all IVI instrument drivers are required to implement IVI-3.2: Inherent Capabilities Specification (Hierarchy of Inherent C Attributes) Category or Generic Attribute NameC Defined Constant COM Interface Inherent IVI Attributes User Options Range Check PREFIX_ATTR_RANGE_CHEC K DriverOperation Query Instrument Status PREFIX_ATTR_QUERY_INST RUMENT_STATUS DriverOperation Cache PREFIX_ATTR_CACHE DriverOperation Simulate PREFIX_ATTR_SIMULATE DriverOperation Record Value Coercions PREFIX_ATTR_RECORD_COE RCIONS DriverOperation Interchange Check PREFIX_ATTR_INTERCHANG E_CHECK DriverOperation

12. System JTAG Capabilities that all IVI instrument drivers are required to implement IVI-3.2: Inherent Capabilities Specification (Hierarchy of Inherent C Attributes) Category or Generic Attribute Name C Defined Constant COM Interface Inherent IVI Attributes User Options Range Check PREFIX_ATTR_RANGE_CHECK DriverOperation Query Instrument Status PREFIX_ATTR_QUERY_INSTRUMEN T_STATUS DriverOperation Cache PREFIX_ATTR_CACHE DriverOperation Simulate PREFIX_ATTR_SIMULATE DriverOperation Record Value Coercions PREFIX_ATTR_RECORD_COERCION S DriverOperation Interchange Check PREFIX_ATTR_INTERCHANGE_CHE CK DriverOperation

13. System JTAG Capabilities that all IVI instrument drivers are required to implement IVI-3.2: Inherent Capabilities Specification (Hierarchy of Inherent C Attributes) Category or Generic Attribute NameC Defined Constant COM Interface Inherent IVI Attributes Class Driver Identification Class Driver Description PREFIX_ATTR_CLASS_DRIVER_DESCR IPTION N/A Class Driver Prefix PREFIX_ATTR_CLASS_DRIVER_PREFI X N/A Class Driver Vendor PREFIX_ATTR_CLASS_DRIVER_VENDO R N/A Class Driver Revision PREFIX_ATTR_CLASS_DRIVER_REVIS ION N/A Class Driver Class Spec Major Version PREFIX_ATTR_CLASS_DRIVER_CLASS _SPEC_MAJOR_VERSION N/A Class Driver Class Spec Minor Version PREFIX_ATTR_CLASS_DRIVER_CLASS _SPEC_MINOR_VERSION N/A

14. System JTAG Capabilities that all IVI instrument drivers are required to implement IVI-3.2: Inherent Capabilities Specification (Hierarchy of Inherent C Attributes) Category or Generic Attribute Name C Defined Constant COM Interface Inherent IVI Attributes Driver Identification Specific Driver Description PREFIX_ATTR_SPECIFIC_DRIVER_DESCRIPT ION N/A Specific Driver Prefix PREFIX_ATTR_SPECIFIC_DRIVER_PREFIX N/A Specific Driver Locator PREFIX_ATTR_SPECIFIC_DRIVER_LOCATOR N/A Specific Driver Vendor PREFIX_ATTR_SPECIFIC_DRIVER_VENDOR N/A Specific Driver Revision PREFIX_ATTR_SPECIFIC_DRIVER_REVISION N/A Specific Driver Class Spec Major Version PREFIX_ATTR_SPECIFIC_DRIVER_CLASS_SP EC_MAJOR_VERSION N/A Specific Driver Class Spec Minor Version PREFIX_ATTR_SPECIFIC_DRIVER_CLASS_SP EC_MINOR_VERSION N/A

15. System JTAG Capabilities that all IVI instrument drivers are required to implement IVI-3.2: Inherent Capabilities Specification (Hierarchy of Inherent C Attributes) Category or Generic Attribute Name C Defined Constant COM Interface Inherent IVI Attributes Driver Capabilities Supported Instrument Models PREFIX_ATTR_SUPPORTED_INST RUMENT_MODELS Identity Class Group Capabilities PREFIX_ATTR_GROUP_CAPABILI TIES Identity Instrument Identification Instrument Manufacturer PREFIX_ATTR_INSTRUMENT_MAN UFACTURER Identity Instrument Model PREFIX_ATTR_INSTRUMENT_MOD EL Identity Instrument Firmware Revision PREFIX_ATTR_INSTRUMENT_FIR MWARE_REVISION Identity Advanced Session Information Logical Name PREFIX_ATTR_LOGICAL_NAME DriverOperation I/O Resource Descriptor PREFIX_ATTR_IO_RESOURCE_DE SCRIPTOR DriverOperation Driver Setup PREFIX_ATTR_DRIVER_SETUP DriverOperation

16. System JTAG Capabilities that all IVI instrument drivers are required to implement IVI-3.2: Inherent Capabilities Specification (Hierarchy of Inherent C Functions) Category or Generic Function Name C Function Name COM Interface Initialize Prefix_init N/A Initialize With Options Prefix_InitWithOptions Attribute Access Functions Set Attribute Functions Prefix_SetAttribute N/A Get Attribute Functions Prefix_GetAttribute N/A Invalidate All Attributes Prefix_InvalidateAllAttributes DriverOperation Utility Functions Self Test Prefix_self_test Utility Reset Prefix_reset Utility ResetWithDefaults Prefix_ResetWithDefaults Utility Disable Prefix_Disable Utility Revision Query Prefix_revision_query N/A Error Query Prefix_error_query Utility Error Message Prefix_error_message N/A Get Specific Driver C Handle Prefix_GetSpecificDriverCHandle N/A Get Specific Driver IUnknown Pointer Prefix_GetSpecificDriverIUnknownPtr N/A Get Error Prefix_GetError N/A Clear Error Prefix_ClearError N/A Lock Session Prefix_LockSession Utility Unlock Session Prefix_UnlockSession Utility Get Next Coercion Record Prefix_GetNextCoercionRecord DriverOperation Get Next Interchange Warning Prefix_GetNextInterchangeWarning DriverOperation Reset Interchange Check Prefix_ResetInterchangeCheck DriverOperation Clear Interchange Warnings Prefix_ClearInterchangeWarnings DriverOperation Close Prefix_close

17. System JTAG Example VISA Application from Agilent/Keysight http://cp.literature.agilent.com/litweb/pdf/E2090-90040.pdf /*idn.c This program queries a GPIB device for an ID string and prints the results. Note that you must change the address. */ #include void main () { ViSession defaultRM, vi; char buf [256] = {0}; /* Open session to GPIB device at address 22 */ viOpenDefaultRM(&defaultRM); viOpen(defaultRM, "GPIB0::24::INSTR", VI_NULL,VI_NULL, &vi); /* Initialize device */ viPrintf(vi, "*RST\n"); /* Send an *IDN? string to the device */ viPrintf(vi, "*IDN?\n"); /* Read results */ viScanf(vi, "%t", buf); /* Print results */ printf ("Instrument identification string: %s\n", buf); /* Close sessions */ viClose(vi); viClose(defaultRM); }

18. System JTAG Example VISA Application from National Instruments http://www.ni.com/pdf/manuals/370423a.pdf #include "visa.h" #define MAX_CNT 200 int main(void) { ViStatus status; /* For checking errors */ ViSession defaultRM, instr; /* Communication channels */ ViUInt32 retCount; /* Return count from string I/O */ ViChar buffer[MAX_CNT]; /* Buffer for string I/O */ /* Begin by initializing the system*/ status = viOpenDefaultRM(&defaultRM); if (status < VI_SUCCESS) { /* Error Initializing VISA...exiting*/ return -1; } /* Open communication with GPIB Device at Primary Addr 1*/ /* NOTE: For simplicity, we will not show error checking*/ status = viOpen(defaultRM, "GPIB0::1::INSTR", VI_NULL, VI_NULL, &instr); /* Set the timeout for message-based communication*/ status = viSetAttribute(instr, VI_ATTR_TMO_VALUE, 5000); /* Ask the device for identification */ status = viWrite(instr, "*IDN?\n", 6, &retCount); status = viRead(instr, buffer, MAX_CNT, &retCount); /* Your code should process the data */ /* Close down the system */ status = viClose(instr); status = viClose(defaultRM); return 0; }

19. System JTAG Example VISA Application from PyVISA https://pyvisa.readthedocs.org/en/stable/ >>> import visa >>> rm = visa.ResourceManager() >>> rm.list_resources() ('ASRL1::INSTR', 'ASRL2::INSTR', 'GPIB0::12::INSTR') >>> inst = rm.open_resource('GPIB0::12::INSTR') >>> print(inst.query("*IDN?")) (That’s the whole program; really!) It works on Windows, Linux and Mac; with arbitrary adapters (e.g. National Instruments, Agilent, Tektronix, Stanford Research Systems).

20. System JTAG VISA Resource Syntax and Examples InterfaceSyntax ENET-Serial INSTRASRL[0]::host address::serial port::INSTR GPIB INSTRGPIB[board]::primary address[::secondary address][::INSTR] GPIB INTFCGPIB[board]::INTFC PXI BACKPLANEPXI[interface]::chassis number::BACKPLANE PXI INSTRPXI[bus]::device[::function][::INSTR] PXI INSTRPXI[interface]::bus-device[.function][::INSTR] PXI INSTRPXI[interface]::CHASSISchassis number::SLOTslot number[::FUNCfunction][::INSTR] PXI MEMACCPXI[interface]::MEMACC Remote NI-VISAvisa://host address[:server port]/remote resource Serial INSTRASRLboard[::INSTR] TCPIP INSTRTCPIP[board]::host address[::LAN device name][::INSTR] TCPIP SOCKETTCPIP[board]::host address::port::SOCKET USB INSTRUSB[board]::manufacturer ID::model code::serial number[::USB interface number][::INSTR] USB RAWUSB[board]::manufacturer ID::model code::serial number[::USB interface number]::RAW VXI BACKPLANEVXI[board][::VXI logical address]::BACKPLANE VXI INSTRVXI[board]::VXI logical address[::INSTR] VXI MEMACCVXI[board]::MEMACC VXI SERVANTVXI[board]::SERVANT

21. System JTAG So how does this relate to SJTAG? A question we have to ask ourselves: Is an instrument interface able to be generic or specialized or support both?  On slide 4 VISA lists different types of classes it defines; each having an associated IVI Specialize Class defined (e.g., IVIScope) with specific behavioral requirements  IEEE 1687 defined a set of instruments the working group identified that forms the basis for their types of classes; however, they let ICL define the access and PDL define the behavior as an open interface  IEEE 1149.1-2013 provides an open API, via PDL, to a register (target destination for a vector segment) and lets the PDL define the behavior of how that register is used  VISA tends to follow what C/ATLAS was defining with specialized classes, which define the required behavioral support for an instrument  SJTAG needs to define whether it wants to define specialized class behavior or allow for an open free form behavioral definition by the instrument provider

22. System JTAG So how does this relate to SJTAG? The IVI Specification states: IVI drivers can communicate directly to the instrument hardware or act as a pass through layer to another IVI driver. SJTAG is talking about sending data to a target port or through an instrument that is acting as a pass through layer (access link) to the target instrument. That is different than what IVI talks about as a pass through function. It states:  The IVI class driver does not actually implement any of the capabilities except for a few inherent capabilities specific to class drivers. Instead, the IVI class driver is a pass ‑ through layer to the IVI class ‑ compliant specific driver. The IVI class driver dynamically loads the specific driver and connects the inherent and class ‑ defined functions and attributes in the IVI ‑ C class ‑ compliant specific driver to the corresponding functions and attributes in the IVI class driver.

23. System JTAG So how does this relate to SJTAG? VISA sends ASCII string commands or Binary raw data to an instrument and receives ASCII strings or Binary raw data responses For SJTAG, we are looking at sending a vector pattern to an instrument and receiving a vector pattern response once an access link to the target is established. For SJTAG, we are also looking at commands that control the access link configuration for different types of Access Link classes. For SJTAG, we are also looking at messages/commands to send to a virtualized API (an Interface) that really is handling the request by a software service. (Gunnar’s ATCA example)

24. System JTAG So how does this relate to SJTAG? Next we need to look at similarities of use cases between the VISA and the SJTAG domain now that we have an overview of what VISA is.