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?