180 likes | 301 Views
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)
E N D
VISA Working GroupFebruary 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, TorstenRissel • 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?