AN 999: Drive-on-Chip with Functional Safety Design Example: Agilex™ 7 Devices

Download PDF
ID 823627
Date 7/04/2024
Public

Visible to Intel only — GUID: fww1716370585562

Ixiasoft

View Details

Document Table of Contents
Document Table of Contents x
1. About the Drive-on-Chip with Functional Safety Design Example for Agilex™ 7 Devices 2. Getting Started 3. Rebuilding the Drive-on-Chip Design 4. Functional Description of the Drive-On-Chip with Functional Safety Design Example for Agilex 7 Devices 5. HPS Channel Safety Software 6. Drive-on-Chip Design Recommendations and Disclaimers 7. Document Revision History for AN 999: Drive-on-Chip with Functional Safety Design Example for Agilex 7 Devices
1. About the Drive-on-Chip with Functional Safety Design Example for Agilex™ 7 Devices x
1.1. Features of the Drive-on-Chip with Functional Safety Design Example for Agilex 7 Devices 1.2. About the Safety Concept 1.3. Other Drive-on-Chip Design Documents
1.2. About the Safety Concept x
1.2.1. High-Level Block Diagram of the Drive-On-Chip with Functional Safety Design Example
2. Getting Started x
2.1. Software Requirements for the Drive-On-Chip with Functional Safety Design Example for Agilex 7 Devices 2.2. Hardware Requirements for the Safe Drive-On-Chip with Functional Safety Design Example for Agilex 7 Devices 2.3. Downloading and Installing the Design 2.4. Installing Python 2.5. Creating an SD Card Image 2.6. Setting Up your Development Board for the Drive-On-Chip with Functional Safety Design Example for Agilex 7 Devices 2.7. Debugging and Monitoring the Drive-On-Chip with Functional Safety Design Example for Agilex 7 Devices with Python GUI 2.8. Looking into the Drive-On-Chip Output
2.3. Downloading and Installing the Design x
2.3.1. Design Directory Structure
2.7. Debugging and Monitoring the Drive-On-Chip with Functional Safety Design Example for Agilex 7 Devices with Python GUI x
2.7.1. GUI Safety Function Tab for the Drive-On-Chip with Functional Safety Design Example for Agilex 7 Devices
3. Rebuilding the Drive-on-Chip Design x
3.1. Generating the Platform Designer System 3.2. Generating and Building the NiosV/g BSP for the Drive-On-Chip Design Example 3.3. Compiling the Hardware in the Intel Quartus Prime Software 3.4. Modifying the Motor Control Software Application 3.5. Generating .jic and .rbf files After Hardware Modifications 3.6. Recreate an SD Card Image 3.7. Modifying the HPS Safety Function Application
4. Functional Description of the Drive-On-Chip with Functional Safety Design Example for Agilex 7 Devices x
4.1. Drive-on-Chip Related Subsystems 4.2. HPS Safety Subsystem 4.3. Safety Subsystem 4.4. Shared Memory Subsystem 4.5. External Safety Logic 4.6. Hardware Subsystem 4.7. Voltage Thresholds 4.8. IP Input and Output Signals 4.9. Registers
4.3. Safety Subsystem x
4.3.1. Safety Block 4.3.2. Quadrature Encoder Pulse 4.3.3. Interval Timer
4.3.1. Safety Block x
4.3.1.1. Safety Function Block 4.3.1.2. Cross-Comparison Block
5. HPS Channel Safety Software x
5.1. Meta Layer and Yocto Build 5.2. HPS Channel Speed Monitoring Safety Application
5.1. Meta Layer and Yocto Build x
5.1.1. Layer Configuration Files 5.1.2. Board Support Package Recipes (recipes-bsp) Device-Tree hw-ref-design u-boot recipes-example recipes-images
5.2. HPS Channel Speed Monitoring Safety Application x
5.2.1. Main (hps_safe_channel.c) 5.2.2. Speed Estimation Thread (speed_estmation.c/.h) 5.2.3. Printing Thread (print_safety.c/.h) 5.2.4. Safety Function Application (srt.c/.h) 5.2.5. Access to Devices 5.2.6. Core Isolation and Core Affinity
1. About the Drive-on-Chip with Functional Safety Design Example for Agilex™ 7 Devices
2. Getting Started
3. Rebuilding the Drive-on-Chip Design
4. Functional Description of the Drive-On-Chip with Functional Safety Design Example for Agilex 7 Devices
5. HPS Channel Safety Software
6. Drive-on-Chip Design Recommendations and Disclaimers
7. Document Revision History for AN 999: Drive-on-Chip with Functional Safety Design Example for Agilex 7 Devices

5.1.2. Board Support Package Recipes (recipes-bsp)

The directory contains recipe extension files to support the devices in the FPGA that the HPS must control while running the safety function.

Device-Tree

Adds a custom .dtsi file to the main device tree for Linux kernel boot up stage socfpga_agilex7_socdk.dts. it compiles into a DTB during kernel compilation and is added to the SD card image during the Yocto build. The recipe device-tree.bb.

Figure 20. Custom Device Tree

You expand the device tree by appending the contents of the file agilex7_dk_si_agf014ea_custom.dtsi that exposes seven devices as UIO devices in the RootFS. The figure shows the instances of the devices. These definitions should match with the devices that the HPS can access in the FPGA soft logic and you can verify the address map in the Platform Designer Project (.qsys). For example, the interval timer has the address 0x0000_0020 in Platform Designer, but from the view of HPS you should add the offset reflecting the HPS-FPGA bridge (0x8000_0000 refer to Example (Recommended) System Memory Mapping Scheme in the Agilex 7 HPS Technical Reference Manual) specifying the address 0x8000_0020 in the agilex7_dk_si_agf014ea_custom.dtsi file. Components connected to the full HPS to FPGA bridge have an offset of 0x8000_0000 and components connected to lightweight HPS-to-FPGA bridge have an offset of 0xF900_0000.

All components are listed in the .dtsi as compatible generic_uio, which is a way to map devices using generic user IO interface in the Linux kernel and user space.

If you modify or add memory mapped devices in Platform Designer, reflect the change in the .dtsi file. When the Yocto build refreshes, the Linux system lists the device in the corresponding /dev/uiox and populates the information in sys/class/uio/uiox. The .dtsi and Platform Designer mapping should be consistent to provide the HPS safety function application tp run correctly.

For example, the application looks for the names specified in the .dtsi, for example interval_timer0 and gets the device UIOX identifier, the address, the offset, and all meaningful information to access the device in the FPGA.

A particularity of the .dtsi in the previous figure is the interrupts metadata. The interval timer processes the safety function by issuing an interrupt to the HPS that is polled by software. The interrupt <0 17 4> is the first interrupt line accepted by the HPS from any FPGA (soft logic) device. In Platform Designer the interrupt line to the interval timer shows Interrupt number 0.

Figure 21. Interval Timer Interrupt line connection to the HPS

You can check the number of interrupts triggered by the interval timer at any point by issuing the following command in the Agilex 7 command line:

>> cat /proc/interrupt

And look for interrupt 49, subscribed to the Interval Timer.

Figure 22. Amount of Interrupts Triggered by the Interval Timer

hw-ref-design

Adds the agilex7_dk_si_agf014ea.core.rbf file to the build. The file is generated after Quartus Prime compilation. The core.rbf file is added to the kernel.itb in the boot partition of the SD card. The HPS configures the FPGA at initialization and part of the board-4 (fpga-4) booting configuration of the FIT image.

Figure 23. FPGA configuration during HPS booting process

u-boot

An append to the u-boot layer to enable UIO drivers defined by uio_pdrv_genirq.of_id=generic-uio. This design isolates cores 2 and 3 for use exclusively in the application (speed estimation and main safety function).

The u-boot commands nohz_full=2,3 and isolcpus=2,3 in the file custom-uboot.txt. They ensure the isolation of cores for the application. You can verify the core allocation in the C source code.

recipes-example

Two recipes to build and deploy the HPS safety application. The source code is in files/hpssafechannel_1.0.tar.gz the Makefile is provided. The recipe hpssafechannel_1.0.bb compiles and packages the executable into the SD card image .wic. The recipe installs the executable in /opt/hpssafechannel. You can run it to start the design.

The recipe hpsafechannelservice_1.0.bb deploys the HPS safety application as a service, it installs the file hpssafechannel.service to /lib/system/system and launches it some seconds after kernel initialization using the start.sh script in /usr/bin.

recipes-images

An extension of gsrd-console-image to add the layer meta-safedriveonchip to the build and remove unused packages from GSRD in this design.

Related Information
Level Two Title