1. VISA Working Group February 2011 Dan Mondrik Jim Piotrowski

2. Agenda Recap of agenda sent out last week 1:30 Meeting logistics and goals 1:45 VXI 4.0 extensions requested by Tom Sarfi, Torsten Rissel 2:30 PXI extensions: BACKPLANE, INSTR (64-bit BAR info) 3:45 PXI multi-vendor interoperability initiative – Discuss user-kernel API or some other approach 4:45 Opportunity to request other VISA spec extensions 5:00 Create draft to send to Technical Committee meeting – Officially open and/or create the necessary specs 5:15 Decide on timing and frequency of conference calls – Goals for addressing by next IVI meeting

3. VXI Extensions Intro VXI hardware is governed largely by VXI-1 spec Version 4.0 of that spec came out in July 2010 – http://www.vxibus.org/?q=node/269 http://www.vxibus.org/?q=node/269 VISA is the standard software API for VXI VXI vendors are requesting that extensions for VXI-1 4.0 be added to VISA specification These software requirements would apply to vendors providing VXI-1 4.0 controllers Other VXI controller vendors should remain compliant even with new VISA

4. VXI 2eVME/2eSST Background: each VXI register access specifies the following: – Address space (A16, A24, A32, A64) is a parameter to each function – Offset (register address) is a parameter to each function – Data width (8 bit, 16 bit, 32 bit, 64 bit) is inherent in the function (e.g., viMoveIn32) – Address modifier (privileged/non-privileged, data/program/block, etc.) is an attribute The attributes VI_ATTR_SRC_ACCESS_PRIV and VI_ATTR_DEST_ACCESS_PRIV are the ones applicable to the new VXI 4.0 extensions – Apparently there are new 64-bit and 128-bit address modifiers – Need to verify that this really is consistent with the intent of the address modifier attributes – Most likely does not make sense for peek/poke mapped window, VI_ATTR_WIN_ACCESS_PRIV These new attribute values are being requested – VI_D64_2eVME (2eVME D64 transfer) – VI_D64_SST160 (2eSST D64 transfer, 160 MB/s) – VI_D64_SST267 (2eSST D64 transfer, 267 MB/s) – VI_D64_SST320 (2eSST D64 transfer, 320 MB/s) – VI_D64_SST160_BCST (2eSST D64 broadcast transfer, 160 MB/s) – VI_D64_SST267_BCST (2eSST D64 broadcast transfer, 267 MB/s) – VI_D64_SST320_BCST (2eSST D64 broadcast transfer, 320 MB/s) Unclear if address offset applies to broadcast or if that parameter is ignored

5. VXI Star Triggers Currently VISA defines constants for TTL and ECL backplane triggers – VXI-1 4.0 adds 2 star triggers direct to each slot – Maximum 13 slots per chassis (controller + 12 devices) Parameter to viMapTrigger() and viUnmapTrigger() – 2 star triggers per slot = 24 additional values VI_TRIG_VXI_STAR0_SLOT1 … VI_TRIG_VXI_STAR0_SLOT12 VI_TRIG_VXI_STAR1_SLOT1 … VI_TRIG_VXI_STAR1_SLOT12 Attribute of received VI_EVENT_TRIG – In this case it is slot neutral; need 2 new values VI_TRIG_VXI_STAR0 and VI_TRIG_VXI_STAR1

6. VXI Utility Bus Signals VXI-1 4.0 provides a new SYNC100 signal – User can explicitly synchronize clock circuitry on modules VISA has an existing backplane utility function viAssertUtilSignal() this seems to fit with – Takes a mode enumeration for which line to pulse or change Need new parameter value VI_UTIL_PULSE_SYNC100

7. Unclear VXI Extensions “To support the I 2 C bus signals SDA0, SCL0, SDA1 and SCL1, two new address spaces need to be added to the list of defined address spaces for the memory I/O services for the backplane resource” – VI_SER0_SPACE and VI_SER1_SPACE But … address spaces are irrelevant on backplanes “In addition a new attribute VI_ATTR_SER_SLAVE_ID is necessary to address a certain I 2 C node” But … on what resource, with what values? Lacking context – Also, not sure if we want “slave” in VISA spec, regardless of its technical accuracy Worst case if we can’t figure this out: just vendor extensions? – Need example app, how these features would be used – How much effort to make everything fit?

8. VXI Extensions: Spec Impact VPP 4.3 (VISA Library) – New constant values VPP 4.3.2 (Implementation Specification for C) – New constant values – Contents of “visa.h” VPP 4.3.4 (Implementation Specification for COM) – New constant values – Possibly new interface if new attributes needed

9. PXI Extensions Intro When PXI was added to VISA specification, only INSTR and MEMACC were defined for PXI NI also implements per-chassis BACKPLANE resource for PXI, similar to VXI – Important for multi-vendor interoperability Related to effort in PXISA – We can use what NI implements as a basis Even the INSTR resource needs additions – 32-bit apps may need access to 64-bit values

10. PXI Backplane Resource One resource per chassis, just like VXI Attributes: chassis number, manufacturer name, model name Operations: viMapTrigger(), viUnmapTrigger() – Trigger line ID is a parameter – Have to set source, destination bus attributes first Badly overloaded viAssertTrigger() – In this case the modes are VI_TRIG_PROT_RESERVE and VI_TRIG_PROT_UNRESERVE – Have to set trigger bus, trigger line ID attributes first – Identical behavior as INSTR resource

11. PXI Instrument Resource Each device has 6 Base Address Registers – Always has at least 1, not necessarily in order – VISA represents them as address spaces (e.g., BAR0) Each BAR has base address, size, and type – On 64-bit machines, base address can be > 4 GB – Even 32-bit apps can access, it’s just a virtual map – VISA exposes base address and size attributes Need to add base address 64-bit versions Size > 4 GB is technically possible but not needed (now)

12. PXI Instrument Interoperability PCI/PXI does not make use of classes like USB does – Each device must be bound to driver with its own INF Binding a device to a given kernel driver is not optimal: – Static, when a vendor creates a distribution, or – Manual, on the end user’s machine, after installation In PCI/PXI there are some things you can only do from the kernel driver – Devices from different vendors have different optimization techniques (e.g., DMA, write combining) All of this points to a need to allow multiple vendors’ kernel components to coexist

13. PXI Interoperability Options How do we get multiple vendors’ PXI kernel components’ resources returned from viFindRsrc()? – For other bus types, each vendor’s VISA could talk to its own kernel, such as in VXI (VXI0 = vendor A, VXI1 = vendor B) – But all PXI devices are interface 0 and start with “PXI0::” So that is not an option Most likely scenario is to define a spec where any VISA could talk to every PXI kernel driver – Similar to IVI user-kernel specification for USBTMC – Would be a completely new IVI specification – Would not affect VISA API, just implementation No other options at this time but open to discussion

14. PXI Extensions: Spec Impact VPP 4.3 (VISA Library) – Extend BACKPLANE definition to apply to PXI Add source / destination trigger bus attributes – Add 64-bit BAR attributes VPP 4.3.2 (Implementation Specification for C) – New attributes for BACKPLANE and INSTR – Contents of “visa.h” VPP 4.3.4 (Implementation Specification for COM) – New interface for BACKPLANE – New derived interface for 64-bit INSTR attributes John Harvey: issues with existing COM INSTR interface? Create new IVI 6.3 for PXI user-kernel interface

15. Additional Spec Change Requests? Work on VISA.NET standard has uncovered NI extensions for Serial – NI is willing to add non-proprietary extensions to the main specification But not interested in driving the effort Since we are opening the VISA specifications for VXI and PXI, this is your chance to propose additional extensions – If you are willing to provide use cases, examples, the text for the spec, and tests Anything else needed for VISA specification?

16. Work on draft for TC Extensions for VXI and PXI Major edits for these specifications: – VPP 4.3 (Jim Piotrowski) – VPP 4.3.2 (Jim Piotrowski) – VPP 4.3.4 (John Harvey) Creation of a new specification: – IVI 6.3 (NI)

17. Text of Motion to TC The VISA working group moves that the IVI Foundation VISA Working group update VPP 4.3, VPP 4.3.2, and VPP 4.3.4, and create a new IVI 6.3 specification, to extend the VISA definition to include: – Extensions to control VXI-1 4.0 compliant controllers. Specifically the ability to: Support new address modifiers for 2eVME/2eSST Control the additional star trigger lines Assert new SYNC100 utility bus signal – Extensions to control PXI devices including: A PXI BACKPLANE resource class for mapping/unmapping triggers and reserving triggers Support 64-bit base address registers – A common user-kernel driver interface for PXI

18. Conference Calls Who wants to participate? Who can lend VXI expertise? – Limited to IVI members? Which topics need to be covered in calls? Would Thursdays 9:00-10:00 CST work? – Existing time slot used for HiSLIP That work should be complete now Start the week of March 3, 2011?