Embedded Security Blog | KiviCore

Secure Boot on AMD Artix-7 FPGA: Getting started with KiviBoot-Tiny and MicroBlaze CPU

Written by Editoral Team | Oct 22, 2026, 5:47:00 AM

Explore verified application startup with KiviBoot-Tiny on the AMD Artix-7 FPGA. The prepared Arty A7 reference connects your application build to signing, encryption and verified boot. 

 
 Content 
1. Start with a prepared Arty A7 reference
2. How KiviBoot fits into the FPGA softcore system
3. Connect your application build to verified startup
4. Follow the boot sequence on the board
5. Use the reference to assess your integration
6. From evaluation to your product
7. Review the guide and request your evaluation
 

 

Your application runs on a processor implemented in the FPGA fabric and loads its firmware from external flash. The system needs to establish that it comes from an authorised source and has not been altered, before it boots. Integrating those checks requires a defined path between the FPGA configuration, bootloaders and application build.

The KiviBoot-Tiny evaluation for the Digilent Arty A7-100T FPGA Development Board using the AMD Artix-7 FPGA provides a prepared reference for exploring that path. It combines bootloader images, a matching hardware description, an example application and tools for signing and encrypting application images. You can follow the workflow from application build to verified startup without first rebuilding the bootloaders.

KiviBoot-Tiny performs its cryptographic boot operations in software. In this reference, the bootloaders and application execute on a MicroBlaze RISC-V processor implemented within the AMD Artix-7 FPGA.

 

1. Start with a prepared Arty A7 reference

A first evaluation needs a consistent set of components: the processor system implemented in the FPGA, its software platform, the bootloaders and the application image format must fit together.

The Arty A7 package provides that starting configuration. It includes an FPGA configuration image containing KiviNanoBL, a separate KiviSecureBL image, and a matching hardware description for creating the application platform in AMD Vitis IDE Classic. The delivery also contains a standalone LED-blink application, board-specific software support, development credentials and image preparation tools.

Both FPGA configuration with KiviNanoBL and KiviSecureBL are supplied as programming files for the board’s external flash. You can use them directly to run the example and concentrate on the application workflow.

The accompanying Getting Started Guide covers the practical setup using Vitis IDE Classic, Vivado, Python and a serial terminal. It takes you from programming the supplied images to building and running the reference application.

 

2. How KiviBoot fits into the FPGA softcore system

The Arty A7 reference implements a MicroBlaze RISC-V processor in the Artix-7 FPGA fabric. The FPGA configuration therefore defines the processor system on which the bootloaders and application run.

The protected FPGA configuration provides the starting point for the boot chain. It includes KiviNanoBL, which executes from on-chip block RAM. KiviNanoBL loads and checks KiviSecureBL before transferring control to it. KiviSecureBL runs in external DDR memory and handles the signed and encrypted application image.

The application image and the separately stored KiviSecureBL image reside in external QSPI flash. Before starting the application, KiviSecureBL loads the image into DDR memory, decrypts it and verifies its signature.

This extends the chain of trust from the protected FPGA configuration through the bootloader stages to the application. Each handover connects the next software component to the preceding trusted stage.

Figure 1. KiviBoot-Tiny boot stages on the MicroBlaze RISC-V softcore. KiviNanoBL executes from on-chip block RAM. KiviSecureBL and the application run in external DDR memory.

For application developers, this architecture provides a defined integration point. Your build must produce an image with the format, memory layout and cryptographic protection expected by KiviSecureBL.

 

3. Connect your application build to verified startup

The workflow begins with the hardware description supplied in the package. You use this XSA file to create a Vitis platform for the reference processor system, then build the standalone application against it.

The hardware description matters because it connects the software environment to the processor and peripherals implemented in the FPGA. The supplied platform sources provide the board-specific interfaces used by the example application.

The application’s memory layout must also match the bootloader’s expectations. In this reference, KiviSecureBL loads the application image into DDR memory at 0x80100000. The image begins with a 0x400-byte header, so executable code is linked at 0x80100400. Keeping the image load address and executable entry location consistent is part of the integration.

After compilation, the supplied image preparation tools sign and encrypt the application. Signing enables verification of its authenticity and integrity. Encryption addresses the confidentiality of the stored application.

The resulting image is then packaged into an MCS file for programming with Vivado. This file places the application in its designated QSPI flash region while preserving the other boot components.


Figure 2. The application workflow connects the Vitis build to image signing and encryption, flash programming and verified startup.

Application development and image preparation remain separate steps. You can examine where signing and packaging belong in your own development process while using the supplied bootloader configuration as a consistent reference.

 

4. Follow the boot sequence on the board

The LED-blink application keeps the first evaluation easy to observe. After programming the boot components and application, a restart begins the boot sequence from QSPI flash.

With logging enabled, the serial output shows KiviNanoBL starting, handing control to KiviSecureBL, and KiviSecureBL loading the application. The application then prints its own startup message, and the board’s status LED toggles once per second.

These observations help you distinguish between stages during bring-up. If KiviNanoBL starts but cannot proceed, the next bootloader image or its matching configuration needs attention. If KiviSecureBL starts but cannot load a bootable application, the application image, credentials and memory configuration are relevant checks. Those cases are covered alongside practical issues such as serial settings and toolchain configuration in our Getting Starting Guide.

A successful LED-blink run confirms that the reference application has reached execution through the supplied boot workflow. Evaluating the security behaviour also requires checking how the system responds to invalid or modified images. Treat those checks as a separate part of your assessment.

5. Use the reference to assess your integration

Once the example runs, you have a concrete basis for evaluating how KiviBoot-Tiny fits your application and FPGA design.

For firmware developers, the main questions concern the application image and build process:

  • Application layout: Does your linker configuration match the memory locations and image format expected by the bootloader?
  • Image preparation: Where will signing and encryption sit in your build and release workflow?
  • Boot behaviour: How will you observe successful startup and verify that invalid images do not execute?
  • Platform fit: Which interfaces and memory assumptions need to change for your application?

FPGA developers contribute where the software depends on the implemented processor system. Changes to the processor configuration, memory map or peripherals need to remain consistent with the hardware description and software platform used to build the application.

KiviBoot-Tiny provides a starting point when software cryptography is suitable for the intended boot requirements. Assess boot performance using your application size and target configuration. If cryptographic processing becomes a limiting factor, hardware acceleration can be considered within the wider KiviBoot family.

 

6. From evaluation to your product

The reference package establishes the components and interfaces needed for a first evaluation. Moving to a product requires adapting that configuration to your hardware, application and security requirements.

Replace the supplied development credentials with production credentials, protect signing private keys, and adapt device-side key provisioning to your architecture. Protection of the initial FPGA configuration remains part of the complete design.

Changing credentials embedded in boot components may require rebuilding them and generating a new FPGA configuration. The Getting Started Guide leaves this outside the initial walkthrough so you can explore the application workflow with matching components.

Product integration also requires defined behaviour for verification failures, updates, recovery and rollback prevention. A successful reference startup does not validate these requirements for your system.

The Arty A7 example helps identify which parts of the supplied configuration fit your design and where adaptation is needed.

 

7. Review the guide and request your evaluation

Access the KiviCore evaluation portal to download the Getting Started Guide e and review the setup, application workflow and programming steps.

When you are ready to try it on your board, request the KiviBoot-Tiny evaluation package through the portal. The prepared bootloader images, reference application and signing tools provide a starting point for assessing verified application startup on an FPGA softcore system.