Glossary of Terms#
Here we provide glossary of terms used terms in this specification. A complete understanding of the term may require knowledge of interaction with other elements and/or its context within the specification.
- Acquisition Context#
Note
Can be abbreviated as “Context”.
A top-level API element that holds acquisition state, a Device Table, and Driver Translator state in order to communicate with a single Controller. A context is manipulated and interacted with using API function calls, and ultimately affects hardware state over the Host Interconnect via a Driver Translator. Multiple contexts can coexist on a single host system and these may each use a different Driver Translator and/or physical interface.
- API#
ONI application programming interface that can be used to develop software to acquire from and control ONI-compliant hardware.
See also
- Controller#
Hardware with a physical interface to the Host Computer over a single Host Interconnect using a Driver Translator and ONI-compliant API. Multiple controllers can coexist in a single Host Computer and need not use the same Driver Translator. Controllers communicate via API calls that manipulate an Acquisition Context and a Device Table, which affect controller state using the driver translator. Hubs are connected to the controller where data to/from their devices is packed and transmitted to/from the host computer. The controller contains a main clock which provides a common timestamp to all incoming data, and that can be synchronized with other controllers.
See also
- Device#
A configurable piece of hardware with its own register address space (e.g., an integrated circuit) or a digital “core” that emulates this. Devices may or may not produce and/or accept streaming data , but that must at least implement a minimal register programming channel. They must be documented, using a Device Datasheet. Devices are the endpoints for most communication operations and often are the hardware interfacing with the physical environment.
See also
- Device Address#
A unique, 32-bit address for each device entry in a Device Table.
See also
- Device Datasheet#
Documentation for a device which describes how it generates and accepts data, if any, along with a guide for programming and reading registers. This might take the form of a manufacturer datasheet if all chip functionality is exposed via raw register access.
See also
- Device Table#
A collection of device addresses and corresponding metadata for all devices governed by a controller. The device table contains all meta-information required to for proper interaction with each device (e.g., packet read-size, packet write-size, burst read cycles, etc.).
See also
- Driver Translator#
A small device driver translation library that converts abstract API calls to hardware-specific system calls that affect the Controller over the Host Interconnect.
See also
- Host Computer#
The computer supporting acquisition and processing from one or more controllers and running software implemented using the API.
- Host Interconnect#
A hardware abstraction layer consisting of a physical bus (e.g., PCIe, USB, or Ethernet) along with a Driver Translator that the Controller uses to communicate with the Host Computer.
- Hub#
A collection of Devices that communicate with a Controller over a Port and share a common clock. All data acquired by devices in the same Hub are timestamped by this clock. Different Hubs may be governed by asynchronous clocks. A Hub either forms a portion of the Device Table or the entire Device Table if it contains all the devices within the Acquisition Context. Hubs can be exist in separate hardware from the Controller (remote hubs) or within the Controller (local hubs).
See also
- Port#
A physical bus between a Hub and a Controller. This could be an external link to a Hub that is separated from the Controller (e.g., a wire or wireless communication channel) or it could be a bus inside of the Controller in the case of a local hub.