/
Versal Gen2 Application Security Unit Firmware

Versal Gen2 Application Security Unit Firmware

ASUFW Overview

In Versal devices, PLM provides cryptographic services. However, in scenarios where these services are critically needed, there can be a backlog and extended waiting periods to access the necessary services from PLM. This can pose a significant challenge when it comes to prioritizing cryptographic services.

The ongoing digital transformation in the automotive industry is ushering in a host of exciting opportunities. However, it also presents new hurdles, particularly in the realm of cybersecurity. As the number of connected vehicles and smart technologies continues to rise, so does the potential for cyber-attacks. Implementing robust security measures to protect against any harmful activities is of paramount importance.

As such, guaranteeing the security of smart and connected vehicles will be a primary focus and an escalating concern in the future landscape of the automotive industry.

The Versal Gen2 platform is addressing these issues by incorporating a separate Application Security Unit (ASU). This dedicated ASU processor is responsible for all application specific security-related functionalities, delivering them with high performance.

In automotive systems built on the Automotive Open System ARchitecture (AUTOSAR) classic or adaptive platforms using Versal Gen2, the ASU functions as a hardware security module (HSM). This ensures that the security of these systems is maintained at the highest level.

ASUFW is designed to use an event-based framework. Each task which needs to be executed can be added as an event with priority to the task list.

ASUFW functionality is broken down into the following sub-components:

  1. ASUFW application (XASUAPP)

  2. ASU library (XILASU)

image-20250923-055120.png
IPI communication flow

ASUFW functionality

ASU application shall provide the following functionality:

  1. Key management.

  2. The ASU application provides an interface for communication using shared memory from other subsystems. This interface supports non-blocking operations to the greatest extent possible. However, certain components like ECDSA and RSA operate in blocking mode as they depend on third-party code. Attempting to make these components non-blocking could add unnecessary complexity.

  3. Implementation for modules functionality

  4. Error handling

  5. Interface for schedule timer events.

  6. Debug print levels and common utilities.

  7. Implementation of tasks execution with 16 priorities.

  8. Implementation of tasks with periodic and non-periodic execution.

  9. Implementation of different crypto services.

Modules in ASUFW

ASUFW is architected with a modular design, ensuring that each functionally distinct feature is developed as an independent module. The creation and initialization of these modules occurs during the ASUFW initialization process. This modular approach allows for the flexible enabling or disabling of specific functionalities as needed. As a result, ASUFW can be easily customized and extended to meet varying requirements. This design also simplifies maintenance and upgrades by isolating changes to specific modules without affecting the entire system.

The ASUFW functionality is designed and developed in 3 different layers which are:

·       Application layer: This layer handles scheduling commands from all clients, verifying required resources and permissions, and transferring control to the appropriate module.

·       Module layer: This layer executes module-specific commands by extracting inputs from the request buffer, managing the hardware state machine, and calling the HW layer to process the commands. It prepares the response based on command execution and writes it to the appropriate response buffer. This layer is independent of the application layer above it and depends solely on the HW layer below it.

·       HW driver layer: This layer implements the crypto driver's functionality, directly interfacing with the hardware. It is designed to be portable across different platforms and has no dependencies on the upper layers. The HW layer's functionality will be organized in a separate folder within the ASUFW application.

Below are the list of modules supported by ASUFW:

  1. AES

  2. SHA

  3. RSA

  4. ECC

  5. TRNG

  6. LMS

  7. HMAC

  8. KDF

  9. X.509

  10. OCP

  11. ECIES

  12. ECDH

  13. KeyWrap

  14. PLM

ASUFW Build Steps

ASUFW build steps using Vitis

  • Open Vitis GUI

    • Login to any developer machine and go to bash.

    • source /proj/xbuilds/2025.2_daily_latest/installs/lin64/2025.2/Vitis/settings64.sh

    • vitis &

    • If you see any error like mentioned in the below image, then you need to set your DISPLAY environment variable using this command. Eg: export DISPLAY=xhdvnc208:9

      image-20250723-101507-20250924-141837.png

    • Vitis GUI looks like

      image-20250723-102416-20250924-142004.png

  • If you want to build using your local repo, update the repo path in the Vitis using below mentioned images.

    • Click on Embedded SW Repositories…

      image-20250724-131922-20250924-142134.png

    • Browse and provide the local repo path as shown in below image and click OK.

      image-20250724-132254-20250924-142247.png

  • Create a new folder and provide the folder path using set workspace option.

  • In Embedded Development, click on New Platform Component and create a platform for ASU processor.

    • Provide a name to the platform and click on Next.

      image-20250723-103403-20250924-143503.png

    • Provide a name to the platform and click on Next.Provide the design path here or you can use the existing platform if it is already created and click on Next.

      image-20250723-103130-20250924-143617.png

    • Select the processor for which you want to generate the platform and click on Next.

      image-20250723-103622-20250924-143646.png

    • Then click on Finish which creates the platform and after creation of platform build the platform.

      image-20250723-103828-20250924-143717.png

  • Create ASUFW application.

    • Click on examples on the left side and select ASU Firmware.

      image-20250723-111924-20250924-143742.png

    • Click on Create Application Component from Template.

      image-20250723-112029-20250924-143812.png

    • Provide component name and click on Next.

      image-20250723-112130 (1)-20250924-144025.png

    • Select the platform created and click on Next.

      image-20250723-112241-20250924-144057.png

    • Select standalone_asu and click on Next.

      image-20250723-112343-20250924-144134.png

    • Click on Finish.

Module Configurations in ASUFW

image-20250723-112428-20250924-144200.png

  • After creating asufw component, navigate to the bsp settings of asufw component to enable or disable the required modules.The value true/false i.e enable/disable respectively across each option name decides whether the algorithm is included or not in the build

    image-20250912-105518-20250924-144224.png

  • Build the created asufw component. This will generate the asufw.elf if the build is successful.

    image-20250723-113406-20250924-144248.png

  • You can see the output elf file here as shown in below image.

    image-20250723-131449-20250924-144318.png

XilAsu client examples build steps using Vitis

  • Platform creation for APU/RPU.

    • Create platform for APU/RPU using the same steps mentioned above to create platform for asu. But you have to select the processor as cortexa78_0 for APU and cortexr52_0 for RPU.

      image-20250723-113801-20250924-144623.png

    • Once the platform is created, build the platform.

  • Create application using examples in XilAsu library.

    • After creation of platform, go to the Board Support Package of platform created for APU/RPU.

      image-20250723-115202-20250924-144646.png

    • In BSP, enable XilAsu library and import any example from the import Examples option of xilasu and click OK. Make sure platform is built before importing the example.

      image-20250723-130950-20250924-144711.png

    • This will create the selected example component and then build the example which generates the example.elf.

    • You can see the output elf file here as shown in below image.

      image-20250723-131402-20250924-144735.png

 

 

© 2025 Advanced Micro Devices, Inc. Privacy Policy