VISA Working Group
February 2011
Dan Mondrik
Jim Piotrowski
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
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
• 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
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
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
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
Unclear VXI Extensions
• “To support the I2C 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 I2C 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?
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
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
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
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)
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
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
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
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?
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)
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
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?