Xilinx has begun packaging select reference and example designs as snaps on the Canonical Snap Store. This page provides technical details related to the snaps that Xilinx is creating. 

Table of Contents

Xilinx Snaps

The following snaps are currently available in the Canonical Snap Store. Canonical maintains general documentation and tutorials for creating snaps compatible with the Canonical Snap Store. For more information about the Xilinx snaps, please refer to the Xilinx Developer Page for each snap.

Utility Snaps

Utility snaps are used to manage the system or update other platform/application snaps.  In some cases they can be used to package boot collateral so that it is compatible with the Certified Ubuntu on Xilinx Devices boot process. An example of this type of snap is xlnx-config. Other utility snaps could be created to perform other system housekeeping tasks.

Platform Snaps

A platform snap includes all or a subset of the boot artifacts needed to create a valid boot image (i.e., BOOT.BIN).  Optionally, a platform snap can also include applications or scripts that are designed to work with the included hardware platform.  Platform snaps include the relevant meta-data that allows them to be managed by the xlnx-config utility snap.  Platform snaps also includes a bootgen.bif file used by the BootGen utility to create the BOOT.BIN file. The syntax of a .bif file is detailed in the BootGen User Guide (UG1283).

Valid platform snaps must contain a contain a properly formatted hwconfig directory in its root.  This directory contains design-specific “configuration” subfolders, each of them with a manifest.yaml file. Any custom user code or files are called “assets” and are the payload provided by the snap. Assets and manifests must reside in the hwconfig directory.

Snaps can contain multiple configurations. A configuration is a particular set of customizations for the target demonstration application. Additionally, each configuration can contain the needed assets required to use the configuration on a target hardware platform (ex: ZCU102, ZCU104, or ZCU106 evaluation boards).

Platforms that include the DPU must also provide a dpu.xclbin with the boot assets. This ensures that when the platform is activated, the associated dpu.xclbin is managed properly and made available to both other snaps and also applications built natively on the target.

For more information about creating and packaging a platform snap, please visit the xlnx-config developer page.

Application Snaps

Application snaps are the most traditional snap type defined by Xilinx. These snaps provide applications that run on top of the hardware configuration present in the currently active platform. Application snaps do not provide any boot or hardware assets on their own. Application snaps may or may not have dependencies on a particular platform snap.  Some application snaps may be generally applicable to all hardware configurations (ex: a simple hello_world application). Others may have direct dependencies on the activated hardware configuration, such as the xlnx-vai-lib-samples snap.