Glossary of Terms

This glossary provides definitions for OpenCPI-specific and industry-wide terms and acronyms used in OpenCPI documentation.

OpenCPI Terminology

This section provides definitions for terms that are specific to OpenCPI.

adapter worker

An adapter worker is the worker used when two connected HDL workers are not connectable in some way due to different interface choices in the OWD. Adapter workers are normally inserted automatically as needed, e.g. between a worker that has a 16-bit bus and one with a 32-bit bus, or HDL workers in different clock domains. These workers are considered part of the OpenCPI framework and not created by users. See also worker.

application

[noun] In the context of component-based development, an application is a composition or assembly of connected components that, as a whole, perform some useful function. See also component.

[adjective] The term application can also be used to distinguish functions or code from infrastructure to support the execution of a component-based application; e.g., an HDL device worker vs. an application worker.

Application Control Interface

ACI

The Application Control Interface (ACI) is an application launch and control API for executing XML-based OpenCPI applications within a C++ or Python program. See the ACI topic for more information.

application worker

An application worker is the implementation of a component used in an application, generally portable and hardware independent.

artifact

An artifact is a file that contains executable code for one or more workers, built for a specific platform. An artifact is a binary file that results from building some assets. See the overview in the OpenCPI Application Development Guide for more information.

asset

An asset is an object that is developed for OpenCPI, including applications, components, workers, protocols, platforms, HDL primitives and other asset types. An asset is developed in a project and is defined by an XML file.

authoring model

An authoring model is a method for creating component implementations in a specific language using a specific API between the worker and its execution environment. An authoring model represents a particular way to write the source code and XML for a worker and is usually associated with a class of processors and a set of related languages. Existing models include RCC, HDL and OCL. See the Authoring Models topic for more information.

back pressure

Back pressure is the resistance or force opposing the desired flow of data through an application. Back pressure within an OpenCPI system is a common occurrence that happens when worker output is temporarily not possible due to processing or communication congestion from whatever the output is connected to. Back pressure can be the result of resource-loading issues or passing data between containers.

build configuration

A build configuration is a set of parameter property (compile-time) values to use when building a worker. See the Worker Build Configuration XML Files topic for more information.

component

A component is the interface “contract” specified by an OpenCPI Component Specification (OCS) and implemented by a worker. A component performs a well-defined function regardless of implementation. A component has ports and properties. See the Component Specifications (typically in OCS XML Files) topic for more information.

Component Development Kit

CDK

The OpenCPI Component Development Kit (CDK) is the set of OpenCPI tools, scripts, documents, and libraries used for developing components, workers and other assets in projects.

component library

A component library is a collection of component specifications, workers and test suites that can be built, exported, and installed to support applications. See the Component Libraries topic for more information.

component unit test suite

test suite

unit test

A component unit test suite is a collection of test cases in a component library for testing all the workers in the library that implement the same spec (OCS) across all available platforms. The workers that are tested can be written to different authoring models or languages or simply be alternative source code implementations of the same spec. The OpenCPI unit test framework manages multiple dimensions of worker testing, with automation to minimize test design and preparation efforts. See the Unit Testing of Workers topic for more information.

configuration property

property

A configuration property is a writeable and/or readable value specified in the OCS or OWD that enables control software to control and monitor a worker. Configuration properties (usually abbreviated to properties) are logically the knobs and meters of the worker’s “control panel”. Each worker may have its own, possibly unique, set of configuration properties which can include hardware resources such registers, memory, and state. Properties can be specified as compile time or runtime. See the Property Value Syntax and Ranges topic for more information. See also configuration property accessibility.

configuration property accessibility

Configuration property accessibility is the set of declarations within an OCS or OWD that indicate when it is valid to read from or write to a configuration property. The various accessibility attributes (defined in the Accessibility Attributes; How and When Properties Get Their Values topic) establish the rules in relation to the worker’s lifecycle and may declare the property as fixed at build time (see parameter).

container

A container is the OpenCPI infrastructure element that “contains,” manages, and executes a set of workers. Logically, the container “surrounds” the workers, mediating all interactions between the workers and the rest of the system. A container typically provides the OpenCPI runtime environment for a particular processor in the system. See the The RCC Worker Interface topic for more information on RCC containers. See the HDL Container XML files topic for more information on HDL containers.

control application

A control-application is the conventional application (e.g. “main program”) that constructs and runs component-based applications. See the ACI topic for more information.

control interface

The control interface is the interface as seen by HDL worker code that an HDL container uses to provide (at a minimum) a control clock and associated reset into the worker, convey life cycle control operations like initialize, start and stop, and access the worker’s configuration properties as specified in the OCS and OWD. See the The Control Interface to the HDL Worker. topic for more information.

control operations

Control operations are a fixed set of operations that every worker may have. These operations implement a common control model that allows all workers to be managed without having to customize the management infrastructure software for each worker, while configuration properties are used to specialize components. The most commonly used control operations are “start” and “stop”. See the topic on LifeCycle Control Operations for more information.

control plane

In OpwnCPI, the control plane is the control and configuration infrastructure for runtime lifecycle control and configuration of worker instances throughout the system at runtime. See the Control Plane Introduction topic for more information.

control software

Control software is the software that launches and controls OpenCPI applications, either the standard OpenCPI utility ocpirun or custom C++ or Python programs that perform the same function embedded inside them using the Application Control Interface application launch and control API. See the Control Plane Introduction topic for more information. See also control application. Control software generally launches, configures and controls an application and the runtime workers that make up the application. A proxy, meanwhile, is a worker within an application that can control and configure other workers. See the OpenCPI RCC Development Guide for more information. See also device proxy worker.

core project

The OpenCPI core project is a built-in OpenCPI project (package ID ocpi.core) that contains the minimum set of workers and infrastructure VHDL for OpenCPI framework operation on software and FPGA simulators.

data interface

A data interface is the set of ports defined in a worker’s OCS that convey data, message boundaries, opcodes and EOF into and out of the worker and which implement flow control.

data plane

In OpenCPI, the data plane is a data-passing infrastructure that allow workers of all types to consume/produce data from/to other workers in an application regardless of the container on which the workers are executing in (or the processor on which they are executing). See the Data Plane Introduction topic for more information.

Datagram Remote Direct Memory Access

DG-RDMA

Datagram Remote Direct Memory Access (DG-RDMA) is a protocol for achieving remote direct memory access (RDMA) that uses a datagram service (DG). In OpenCPI, DG-RDMA is a data plane protocol that achieves RDMA using the Layer 2 (L2) Ethernet type of datagram service. While OpenCPI protocols (OPS) define howcomponents and workers communicate regardless of authoring model, platform, or container, data plane protocols like DG-RDMA define how containers communicate and provide the underlying inter-container protocol that supports inter-worker communication Inter-container protocols can be carrying multiple worker-to-worker conversations between containers, and each of these conversations can be using different inter-component protocols.

device proxy worker

A device proxy worker is a software worker (RCC/C++) that is specifically paired with one or more HDL device workers in order to translate a higher-level control interface for a class of devices into the lower-level actions required on a specific device. See the Controlling Slave Workers from Proxies — C++ Language Only topic and the Device Support for FPGA Platforms topic for more information.

Digital Radio Controller

DRC

The Digital Radio Controller (DRC) is a utility component in the OpenCPI built-in core project that is used when an application needs to use radio hardware in the system to control it and to stream sample data to and from it. The “digital radio” functionality in a system usually has antennas for transmitting and receiving RF signals and channels which convert the RF signals to and from baseband digital samples that are produced and consumed by the application. See the Utility Components for Applications topic for more information.

HDL assembly

An HDL assembly is a fixed composition of connected HDL workers that are built into a complete FPGA bitstream that can be executed on an FPGA to implement some or all of the components of an OpenCPI application. The HDL code is automatically generated from the HDL assembly’s OHAD. See the Preparing HDL Assemblies for Use by Applications topic and the OpenCPI HDL Development Guide for more information.

HDL authoring model

The HDL authoring model is the authoring model used by VHDL-language and less-supported Verilog-language workers that execute on FPGAs. See the OpenCPI HDL Development Guide for information about using this authoring model. See also Hardware Description Language (HDL).

HDL build hierarchy

The HDL build hierarchy is the structure in which FPGA bitstreams are created from other assets. See The HDL Build Hierarchy topic for more information.

HDL build process

The HDL build process is the process of building HDL assets for different target devices and platforms. See the Building HDL Assets topic for more information.

HDL card

An HDL card is hardware that contains devices and plugs into a slot on an HDL platform. Devices are either directly attached to the pins on an HDL platform or attached to cards that plug into compatible slots on the platform. Devices on a card are considered to be part of the card, which can be plugged into a certain type of slot on any platform, rather than part of the platform itself. See the Device Support for FPGA Platforms and the Defining Cards Containing Devices that Plug into Slots of Platforms topics for more information.

HDL data interface

An HDL data interface is the set of ports defined in an HDL worker’s OCS that convey data, message boundaries, opcodes and EOF into and out of the HDL worker and which implement flow control. Worker data ports can be implemented as stream or message interfaces. Stream interfaces are FIFO-like with extra qualifying bits along with the data indicating message boundaries, byte enables and EOF. Message interfaces are based on addressable message buffers. See the HDL Worker Data Interfaces for OCS Data Ports topic for more information.

HDL device emulator worker

An HDL device emulator worker is a special type of HDL device worker that acts like a device for test purposes. A device emulator worker provides a mirror image of an HDL device worker’s external signals so that it can can emulate the device in simulation. See the Testing Device Workers with Emulators topic for more information.

HDL device worker

device worker

An HDL device worker is a specific type of HDL worker designed to support a specific external device attached to an FPGA such as an ADC, flash memory, or I/O device. HDL device workers are typically developed as part of enabling an HDL platform. See the Device Support for FPGA Platforms topic for more information.

HDL interface

For HDL workers, an HDL interface is the set of input and output port signals that correspond to a high-level OpenCPI port as defined in the OCS and OWD for the HDL worker. An HDL worker has a control interface (for the implicit control port), data interfaces (for the explicit data ports defined in the OCS), and service interfaces (for service ports as defined in the HDL worker’s OWD).
For all worker types, an HDL interface is the implicit control port.

HDL platform

An HDL platform is an OpenCPI platform based on an FPGA that is enabled to host OpenCPI HDL workers. An HDL simulator is also considered to be an HDL platform. See the Enabling FPGA Platforms topic for more information.

HDL platform configuration

An HDL platform configuration is a pre-built (usually pre-synthesized) assembly of HDL device workers that represents a particular reusable configuration of device support modules for a given HDL platform. The HDL code is automatically generated from a brief description in XML. See the Enabling Execution for FPGA Platforms topic for more information.

HDL platform worker

platform worker

An HDL platform worker is a specific type of HDL worker that enables an HDL platform for use with OpenCPI and provides the infrastructure for implementing control/data interfaces to devices and interconnects external to an FPGA or simulator, such as PCIe or clocks. See the Enabling Execution for FPGA Platforms topic for more information.

HDL primitive

An HDL primitive is an HDL asset that is lower level than a worker and can be used (and reused) as a building block for HDL workers. An HDL primitive is either a library or a core. See the HDL Primitives topic for more information.

HDL primitive core

An HDL primitive core is a low-level module that can be built and/or synthesized from source code, or imported as pre-synthesized and possibly encrypted from third parties, or generated by tools like Xilinx CoreGen or Intel/Altera MegaWizard. An HDL worker declares which primitive cores it requires (and instantiates). See the HDL Primitives topic for more information.

HDL primitive library

An HDL primitive library is a collection of low-level modules compiled from source code that can be referenced in HDL worker code. An HDL worker declares the HDL primitive libraries from which it draws modules. See the HDL Primitives topic for more information.

HDL slot

An HDL slot is an integral part of an HDL platform that enables an HDL card to be plugged in so that its attached devices are accessible to the platform. An HDL platform has defined slot types; HDL cards that are designed for the same slot type can be plugged in to the defined slots on the platform. See the Device Support for FPGA Platforms and the Defining Cards Containing Devices that Plug into Slots of Platforms topics for more information.

HDL subdevice worker

An OpenCPI HDL subdevice worker is a special type of HDL application worker that supports an HDL device worker defined in another library. See the Subdevice Workers topic for more information.

HDL worker

An HDL worker is an HDL implementation of a component specification with the source code (for example, VHDL) written according to the HDL authoring model. An HDL worker is usually a hardware-independent, portable application worker but can alternatively be an HDL device worker that controls a specific piece of hardware attached to an FPGA. See the HDL Workers topic for more information.

lifecycle state model

lifecycle model

The OpenCPI lifecycle state model specifies the control states each worker may be in and the control operations which generally change the state a worker is in, effecting a state transition. See the LifeCycle State Model topic for more information.

OpenCL authoring model

OCL

The OpenCL (OCL) authoring model is the authoring model used by Open Computing Language (OpenCL) (C subset/superset)-language workers usually executing on graphics processors. This OpenCPI authoring model is currently experimental.

OpenCPI Application Specification

OAS

An OpenCPI Application Specification (OAS) is an XML document that describes the collection of components along with their interconnections and configuration properties that defines an OpenCPI application. See the chapter OpenCPI Application Specification (OAS) XML Documents topic for more information.

OpenCPI Component Specification

OCS

spec file

component specification

component spec

An OpenCPI Component Specification (OCS) is an XML file that describes both configuration properties and zero or more data ports (referring to protocol specifications) of a component establishing interface requirements for multiple implementations (workers in any authoring model. Also referred to as a component spec or spec file. See the Component Specifications (typically in OCS XML Files) topic for more information.

OpenCPI HDL Assembly Description

OHAD

An OpenCPI HDL Assembly Description (OHAD) is an XML file that describes an HDL assembly. See the HDL Assemblies for Creating Bitstreams/Executables topic for more information.

OpenCPI HDL Platform Description OHPD

OHPD

An OpenCPI HDL Platform Description (OHPD) is an XML file that describes an HDL platform. An OHPD contains the same information as the OWD for the HDL platform worker and also describes the devices (controlled by HDL device workers) that are attached to the HDL platform and available for use. See the Enabling Execution for FPGA Platforms topic for more information.

OpenCPI Protocol Specification

OPS

protocol specification

protocol

An OpenCPI Protocol Specification (OPS) is an XML file that describes the allowable data messages (operation codes) and payloads (operation arguments) that may flow between the ports of components. See the Protocol Specifications (in OPS XML Files) topic for more information.

OpenCPI System support Project

OSP

An OpenCPI System support Project (OSP) is an OpenCPI project that contains OpenCPI assets whose purpose is to enable and test a particular system (of platforms) to be used by OpenCPI. OSPs fulfill what is generally meant by the more generic industry term: Board Support Package (BPS). An OSP may contain assets to support multiple related systems.

OpenCPI Worker Description

OWD

An OpenCPI Worker Description (OWD) is an XML file that describes the worker and references the component specification it is implementing. See the Worker Descriptions in OWD XML Files topic for more information.

operation (within a protocol)

An operation is a message type encapsulating zero or more operation arguments within an OpenCPI protocol specification.

operation argument

argument

An operation argument is one of the data values in the payload data defined for a particular operation (message type) within a protocol specification whose type information is determined by the protocol XML.

operation code

opcode

An operation code (opcode) is an ordinal that indicates which of the possible operations in a protocol is present.

package ID

A package ID is the globally-unique identifier of an OpenCPI asset. A project’s package ID is used when it is depended on by other projects. A component’s package ID is used to reference it in applications or workers. While all assets have package IDs (either explicitly specified or inferred from the directory structure), only certain assets are currently identified by their package IDs. See the Package IDs for more information.

parameter

A parameter is an immutable configuration property that is set at build time, allowing software compilers and hardware compilers to optimize accordingly. See the Properties That Are Build-time Parameters, Accessibility Attributes; How and When Properties Get Their Values, Parameter Attribute of Property Elements, and Parameter Attribute for OWD SpecProperty Elements topics for more information.

platform

An OpenCPI platform is a particular type of processing hardware and/or software that can host a container for executing OpenCPI workers based on artifacts. Platforms may be based on CPUs, GPUs or FPGAs. See the OpenCPI Systems and Platforms topic for more information.

port

An OpenCPI port is an interface of a component that allows it to communicate with other components using a protocol. Ports are unidirectional: input or output, consumer or producer. In OpenCPI, a port is a high-level data flow interface in and out of all types of workers. In the VHDL and Verilog languages, however, a “port” refers to the individual signals (of any type) that are the inputs and outputs of an entity (VHDL) or module (Verilog). See the Port Element of ComponentSpec Elements topic for more information.

port readiness

Port readiness indicates whether an input port has data to be consumed or an output port has capacity to produce data (e.g. no back pressure). Input ports are ready when there is message data present that has not yet been consumed by the worker. Output ports are ready when buffers are available into which they may place new data.

project

An OpenCPI project is a work area (and directory) in which to develop OpenCPI components, libraries, applications, and other platform- and device-oriented assets. See the :ref: Developing-OpenCPI-Assets-in-Projects topic for more information.

project registry

registry

An OpenCPI project registry is a directory that contains references to projects in a development environment so they can refer to (and depend on) each other. Development activity takes place in the context of a project registry that specifies available projects to use. See the The Project Registry: How Projects Depend on and Find Each Other topic for more information.

protocol summary

A protocol summary is the set of summary attributes, whether inferred from the messages specified for the protocol, or specified directly as attributes of the protocol, and indicates the basic behavior of a port using a protocol. A protocol summary can also be present when messages are specified, and can override the attributes inferred from the message specifications. See also Component Development Kit (CDK).

RCC

RCC authoring model

Resource-Constrained C (RCC) authoring model

The Resource-Constrained C (RCC) authoring model is the authoring model used by C or C++ language workers that execute on General-Purpose Processors (GPPs). The “Resource-Constrained” prefix indicates that the environment may be constrained to use a limited set of library calls; see the OpenCPI RCC Development Guide for more information.

RCC worker

An RCC worker is an RCC implementation of an OpenCPI component specification with the source code (for example, C or C++) written according to the RCC authoring model. An RCC worker can act as a device proxy worker. See the OpenCPI RCC Development Guide topic for more information.

run condition

A run condition is the specification by an RCC worker as to when it should execute, based on a combination of port readiness and/or some amount of time having passed. The commonly-used default run condition is when all ports are ready, with no consideration of time passing.

run method

A run method is a non-blocking software method that is executed when a worker’s run condition is satisfied, as determined by its container.

SpecProperty

A SpecProperty is an XML element that adds a worker-specific attribute to a configuration property already defined in the component spec. See the Worker Descriptions in OWD XML Files topic for more information.

system

In OpenCPI, a system is a collection of platforms usually in a box or on a system bus or fabric.

target

An OpenCPI target is the entity for which an asset should be built (compiled, synthesized, place-and-routed, etc.). In OpenCPI, build targets are usually platforms (particular products or particular operating system releases and architectures). When a set of platforms shares a common processor architecture family, it is sometimes possible to build for the “family” and the results of that build can be used for all the platforms. See the RCC Compiler and Linking Options and HDL Build Targets topics for more information.

worker

An OpenCPI worker is a specific implementation (and possibly a runtime instance) of a component specification with the source code written according to an authoring model. See the Introduction to Worker Development for more information.

worker property

A worker property is a configuration property related to a particular implementation (design) of a worker; that is, one that is not necessarily common across a set of implementations of the same high-level component specification (OCS). A worker property is additional to the properties defined by the component specification being implemented. See the How a Worker Accesses its Properties, Property Access, and Property Data Types topics for more information.

Zero-Length Message (ZLM)

A Zero-Length Message (ZLM) is a data payload with no operation arguments present when a protocol specification specifies such an operation code with no data fields.

Industry Terminology

This section provides definitions for industry-wide terms relating to OpenCPI.

Advanced eXtensible Interface
AXI: Advanced eXtensible Interface (AXI) is an industry-standard bus used by ARM processors.
Advanced RISC Machine
ARM: Advanced RISC Machine (ARM) is a widely-used processor architecture originally based on a 32-bit reduced instruction set (RISC) computer.
Board Support Package
BSP: A Board Support Package (BSP) is the layer of software in an embedded system that contains hardware-specific drivers and other routines that allow a particular operating system (usually a real-time operating system) to function in a particular hardware environment integrated with the operating system itself. An OpenCPI System support Project (OSP) performs the function of a BSP in OpenCPI.
Central Processing Unit
CPU: A Central Processing Unit (CPU) is the electronic circuitry that executes instructions comprising a computer program. A CPU performs basic arithmetic, logic, controlling, and input/output (I/O) operations specified by the instructions in the program, in contrast with external components such as main memory and I/O circuitry and specialized processors such as Graphics Processing Units (GPUs).
Digital Signal Processor
DSP: A Digital Signal Processor (DSP) is a specialized microprocessor chip with an architecture that is optimized for the operational needs of digital signal processing.
digital signal processing: Digital signal processing (also abbreviated to “DSP”) is the use of digital processing by General-Purpose Processors (GPPs) or Digital Signal Processors (DSPs) to perform a wide variety of signal processing operations. The digital signals processed in this way are a sequence of numbers that represent samples of a continuous variable in a domain such as time, space, or frequency.
eXtensible Markup Language
XML: eXtensible Markup Language (XML) is a standardized markup language that defines a set of rules for encoding documents in a format which is both human- and machine-readable.
Field-Programmable Gate Array
FPGA: A Field-Programmable Gate Array (FPGA) is an integrated circuit that is designed to be configured by a customer or a designer after manufacturing. The FPGA configuration is generally specified using a Hardware Description language (HDL), similar to that used for an Application-specific Integrated Circuit (ASIC).
FPGA bitstream: In the context of FPGA development, an FPGA bitstream is a single, standalone artifact, resulting from building an HDL assembly, that is ready for loading onto an actual, physical FPGA.
framework: A framework is a development and runtime tool set for a particular class of software, firmware, or gateware development. OpenCPI is a framework.
gateware: Gateware is source code written in an HDL for an FPGA. Gateware is like software because it is fully programmable, but it compiles to fully parallel logic, which allows it to to compute efficiently like hardware. Gateware solutions achieve performance and flexibility by running on FPGAs.
General-Purpose Processor
GPP: A General-Purpose Processor (GPP) is a processor designed for general-purpose computers such as PCs or workstations and for which computation speed is the primary concern. See also Central Processing Unit (CPU).
Graphics Processing Unit
GPU: A Graphics Processing Unit (GPU) is a chip or electronic circuit capable of rendering graphics for display on an electronic device. In the last decade, GPUs have also been used for more general-purpose computing when algorithms can exploit the same highly parallel architectures.
Hardware Description language
HDL: Hardware Description Language (HDL) is a specialized language used to program the structure design and operation of digital logic circuits. In OpenCPI, it is an authoring model using the VHDL language and is targeted at FPGAs. HDL workers should be developed according to the HDL authoring model described in the OpenCPI HDL Development Guide.
Integrated Synthesis Environment Design Suite
ISE®: The Xilinx Integrated Synthesis Environment (ISE) Design Suite is a discontinued software tool for synthesis and analysis of HDL designs, which primarily targets development of embedded firmware for Xilinx FPGA and Complex Programmable Logic Device (CPLD) integrated circuit (IC) product families. Use of the last released edition continues for in-system programming of legacy hardware designs containing older FPGAs and CPLDs otherwise orphaned by the replacement design tool, Vivado® Design Suite.
ISE® Simulator
Isim
isim: The ISE Simulator (ISim) is the HDL simulator provided with the Xilinx ISE® Design Suite. In OpenCPI, this simulator is called the isim HDL platform.
Open Computing Language
OpenCL
CL: The Open Computing Language (OCL, OpenCL) is a language and runtime for writing programs that, subject to the availability of appropriate tools, may execute on different types of processors, e.g. Central Processing Units (CPUs), Graphics Processing Units (GPUs), Digital Signal Processors (DSPs), Field-Programmable Gate Arrays (FPGAs) and other processors or hardware accelerators. OpenCL is an open standard maintained by the non-profit technology consortium Khronos Group.
Open Source Software
OSS: Open Source Software (OSS) is a type of computer software in which source code is released under a license in which the copyright holder grants users the rights to use, study, change, and distribute the software to anyone and for any purpose. Open Source Software may be developed in a collaborative public manner.
Peripheral Component Interconnect
PCI: Peripheral Component Interconnect (PCI) is a local computer bus for attaching hardware devices in a computer and is part of the PCI Local Bus standard. The PCI bus supports the functions found on a processor bus but in a standardized format that is independent of any given processor’s native bus. Devices connected to the PCI bus appear to a bus master to be connected directly to its own bus and are assigned addresses in the processor’s address space. PCI is a parallel bus, synchronous to a single bus clock. Attached devices can take either the form of an integrated circuit fitted onto the motherboard (called a planar device in the PCI specification) or an expansion card that fits into a slot.
Peripheral Component Interconnect expresse
PCIe: Peripheral Component Interconnect Express (PCIe) is a high-speed serial computer expansion bus standard that is designed to replace the older PCI, PCI-X and AGP bus standards. Improvements over the older standards include higher maximum system bus throughput, lower I/O pin count and smaller physical footprint, better performance scaling for bus devices, a more detailed error detection and reporting mechanism and native hot-swap functionality. More recent revisions of the PCIe standard provide hardware support for I/O virtualization.
RPM Package Manager
RPM: The RPM Package Manager (RPM) is a free and open-source package management system used in some Linux distributions. The name “RPM” refers to .rpm file format and to the Package Manager program command itself.
System on a Chip
SoC: A system on a chip (SoC) is a single integrated circuit (IC, or “chip”) that integrates all or most components of a computer or other electronic system. SoC is a complete electronic substrate system that may contain analog, digital, mixed-signal or radio frequency functions. Its components usually include a Graphics Processing Unit (GPU), a Central Processing Unit (CPU) that may be multi-core, and system memory (RAM). SoCs are in contrast to the common traditional motherboard-based PC architecture, which separates components based on function and connects them through a central interfacing circuit board. SoCs used with OpenCPI typically also contain FPGAs.
Verilog: Verilog is a Hardware Description language (HDL) used to model electronic systems. Verilog is standardized as IEEE 1364.
VHSIC Hardware Description language
VHDL: VHDL is a Hardware Description language used in electronic design automation to describe digital and mixed-signal systems such as FPGAs and integrated circuits (ICs). VHDL can also be used as a general-purpose parallel programming language.
Vivado® Design Suite
Vivado
Xilinx Vivado: The Xilinx Vivado Design Suite is a software suite for synthesis and analysis of HDL designs. Vivado is an integrated design environment (IDE) with system-to-IC level tools built on a shared scalable data model and a common debug environment. Vivado supersedes Xilinx ISE with additional features for System on a Chip development and high-level synthesis. Vivado WebPACK Edition is a free version of Vivado that provides designers with a limited version of the Vivado Design Suite environment.
Vivado® Simulator
xsim: Vivado Simulator is an HDL event-driven simulator that Xilinx provides with Vivado® Design Suite and WebPACK Edition. In OpenCPI, this simulator is called the xsim HDL platform.