FPGA Licensing Principle
The core licensing technology is based on a license key that unlocks at runtime the proper operation of an FPGA design. The license key is loaded into the FPGA after its configuration, usually through PCIe.
The license key is an encrypted container that delivers a secret Activation Code to each protected function inside the FPGA. Protected function can only operate properly when the secret activation code has been received electrically within the function’s digital logic. This protection is implemented into HDL, by using individual bits of the activation code to insert blocking points into control logic and masking points into datapath logic.
The encryption key for the license key is unique per FPGA, derived from a unique hardware identifier such as the Xilinx DNA or the Intel CHIP_ID. Thus, a license key can exclusively unlock the FPGA device is has been generated for; any attempt to load a license key into another FPGA device will fail.
Here’s a short video presenting an overview of the Accelize Platform and its integration.
The Accelize licensing technology is offered in two distinct modes:
A file-based scheme implemented by statically packaging the license key into an encrypted license file, stored locally on the server that hosts the FPGA card.
A server-based scheme implemented by delivering license keys from a license server. Specifically, the license server delivers a regular stream of time-limited single-use license keys.
With these two licensing modes - static and dynamic -, Accelize offers 3 distinct licensing models:
Nodelocked licensing is a static licensing mode. A Nodelocked license is a license grant which allows an application to be executed on a specific FPGA card, and only on that card. Nodelocked licenses are granted to specific FPGA cards and are perpetual, transferable, and non-revocable.
Floating licensing is a dynamic licensing mode. A Floating license is a license grant which allows a specified number of concurrent instances of the application to be executed on any FPGA card. Floating licenses are granted to authenticated users, and the DRM service dynamically enforces the maximum number of concurrent instances allowed.
Metered licensing is also a dynamic licensing mode. A Metered license is a license grant which allows unlimited execution of an application on any FPGA card, and incurs post-use monthly billing based on measured usage. Metered licenses grants are bound to authenticated users, and the DRM service dynamically and securely collects the metering information generated within the FPGA. Metering metrics include time, as well as any measurable quantity within the FPGA, such as data volume, data type, processing requests, application-specific events, etc.
The Accelize licensing technology dynamically supports all licensing modes without any change to the FPGA application. Thus, one can build and deploy a unique FPGA bitstream and dynamically select the desired licensing model for each user, or even each execution.
Get more details on Accelize blog.
The Accelize DRM solution comprises 3 layers:
FPGA HDL IPs that must be embedded into the FPGA design. Specifically, exactly one DRM Controller IP, and one or more DRM Activator IPs. The Activators must be embedded within each protected function. These IPs are delivered in the DRM HDK.
Host The DRM client, a lightweight service that executes on the host CPU, whose main function is to connect the FPGA DRM IPs with either the DRM Web Service (dynamic licensing) or a local license key file (static licensing). The DRM client is delivered as a DRM Library in C/C++ and Python.
Web Service A fully managed DRM Web Service operated by Accelize. The Web service is only used in dynamic licensing and handles user authentication, licensing and metering. Upon special request, the DRM Web Service can deployed on-premise.
1 FPGA image = 1 DRM Controller = 1 DRM Client process
We comply with the semantic versioning defined by semver.org.
Given a version number MAJOR.MINOR.PATCH, increment the:
MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards compatible manner, and
PATCH version when you make backwards compatible bug fixes.
Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.
Digital Rights Management
A unique chip identifier; could be deliver by a PUF
Physically Unclonable Function
Vendor Library Name Version
Functional block to be protected
IP Core + DRM instrumentation
DRM Enabled IP
a Protected IP
Clock Domain Crossing
For Activation Duration controlled by the IP Activator, one per Protected IP
- Getting started
- Node-locked Licenses Generation
- DRM Activator IP
- DRM Controller IP
- DRM Hardware integration
- Supported hardware
- Request DRM HDK
- Modify your design
- Simulate your design
- Synthesize and implement your design
- Constrain your design
- Guidlines to package DRM IPs for Xilinx(R) IP Integrator
- DRM Library installation
- Supported OS
- Software requirements
- Installation from packages
- Installation from source
- Installation with Ansible
- DRM Library integration
- Install DRM API
- Include DRM API
- Use DRM API in your code
- Compile your application
- Advanced usage
- Petalinux integration
- Full API documentation
- DRM Library APIs
- DRM library build & test
- Build CMake configuration
- Compile CMake configuration
- Generated output
- Run tests
- DRM SW Advanced Description
- DRM Migration description