Overview
This document describes how to develop component implementations, known as HDL workers, for FPGAs, using the Hardware Description Language (HDL) Authoring Model. Workers are typically created in a component library, so that they are available for OpenCPI application developers and users.
Some knowledge of FPGA terminology is assumed here, but this document is also useful for non-FPGA developers in understanding the OpenCPI FPGA development process.
This document builds on the information provided in the OpenCPI Component Development Guide (CDG)**, which introduces concepts and processes used for OpenCPI component development in general.
In addition to describing how to develop HDL workers, this document also describes:
how to create HDL primitive libraries, which are libraries of smaller/simpler reusable code modules sometimes used in the design of HDL workers
how to create HDL primitive cores, which are prebuilt and possibly pre-synthesized modules sometimes incorporated into HDL workers
how to assemble a group of connected HDL workers to form an HDL assembly, which is realized in a complete FPGA bitstream.
HDL assemblies enable an FPGA to execute a subset of, or all of, the components specified in an OpenCPI application. Usually when an OpenCPI application uses an FPGA, it is using it to execute some of the components specified in the application, with the others executing on other processors typically using other authoring models. However, in some cases an HDL assembly provides workers for all the components required by an application.
For HDL development, OpenCPI utilizes technology-specific FPGA synthesis and simulation tools (e.g. Xilinx Vivado or ISE and Isim, Altera/Intel Quartus, Modelsim etc.).
The following sections describe the development of HDL workers, primitives (libraries and cores), assemblies and bitstreams to support the execution of parts of component-based applications on FPGAs. All these terms are prefixed with HDL here to avoid confusion when they are used elsewhere.
HDL Authoring Model: the OpenCPI authoring model targeting Hardware Description Languages that are appropriate for FPGA development, currently using VHDL, with some legacy support for Verilog. Full support for Verilog and System-Verilog is not currently included. VHDL workers calling primitives written in Verilog is supported. New HDL workers should be written in VHDL.
HDL Target: a particular type of FPGA device, usually what is considered a part family, that is the target of compilation or synthesis, where the result can be used for any architecturally similar device. Examples are “artix7”, or “kintex7”, or “zynq”. Simulators are also HDL targets, including Mentor’s Modelsim and Xilinx Isim and Xsim.
HDL Worker: an HDL (e.g. VHDL) implementation of a component specification, with the source code written according to HDL authoring model. While most HDL workers are application workers (usable in portable applications), a special type is device workers which are for controlling hardware physically attached to the FPGA. For application workers, it is common and recommended to have an RCC worker that also implements the same spec. Such workers are sometimes called “work-alikes”.
HDL Primitive: an HDL asset that is lower level than workers, that is used as a building block for workers. HDL primitives can either be libraries or cores.
HDL Primitive Library: a collection of low level modules compiled from source code that can be referenced in HDL worker code. An HDL worker declares which HDL primitive libraries it draws modules from.
HDL Primitive Core: a low level module that may be built and/or synthesized from source code, or imported as presynthesized and possibly encrypted from 3rd parties, or generated by tools like Xilinx CoreGen or Altera MegaWizard. An HDL worker declares which primitive cores it requires (and instantiates).
The following diagram shows the hierarchy of modules when an FPGA design is realized using OpenCPI:
Figure 10: HDL Hierarchy
HDL Assembly: a composition of connected HDL workers that are built into a complete FPGA configuration bitstream, acting as an OpenCPI artifact. The resulting bitstream is executed on an FPGA to implement some part or all of (the components of) the overall OpenCPI application. The HDL code is automatically generated from a brief description in XML.
HDL Platform: an OpenCPI platform based on an FPGA that is enabled to host OpenCPI HDL workers. Simulators are also considered HDL platforms.
HDL Platform Worker: a specific type of HDL worker providing infrastructure for implementing control/data interfaces to devices and interconnects external to the FPGA or simulator (e.g. PCI Express, Clocks). See the HDL Platform and Device Development topic.
HDL Device Worker: a specific type of HDL worker that supports external devices attached to FPGAs. See the HDL Platform and Device Development topic.
HDL Platform Configuration: a prebuilt (presynthesized) assembly of device-level HDL workers that represent a particular configuration of device support modules for a given HDL platform. The HDL code is automatically generated from a brief description in XML. See the HDL Platform and Device Development topic.
HDL Container: a complete design for an entire FPGA, which includes an HDL assembly and an HDL platform configuration combined in a specified fashion. The HDL code is automatically generated from a brief description in XML.
HDL development in OpenCPI includes both application workers in a component library, which perform functions independent of any specific hardware attached to the FPGA, as well as device workers that are designed to support specific external hardware such as ADCs, flash memories, I/O devices, etc.
HDL device workers are developed as part of enabling an HDL platform (an FPGA on a particular board) for OpenCPI. See the HDL Platform and Device Development topic.
The sections below for HDL/FPGA development are:
Developing application workers in a component library
The HDL Build Process: building HDL assets for different target devices and platforms
The HDL Build Hierarchy: how whole device “bitstreams” are created from other assets
Developing assemblies of workers on FPGAs.