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: jou1716294613293

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)
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

4.3.1.2. Cross-Comparison Block

The cross-comparison block consists mainly of a state machine which, when triggered by the timer, writes to and reads from the shared memory to compare the FPGA payload with the HPS payload.
Figure 18. Cross Comparison States

When triggered in the initial init state by the timer, the state machine waits a clock cycle for the payload to be generated before writing it to the shared memory. The FPGA status location is then updated in the shared memory to indicate that the FPGA payload is valid. The state machine then waits, checking the shared memory location for the HPS status to determine when the HPS writes its payload data to the shared memory. The design performs cross comparison that verifies that the payload sequence number in the two payloads matches and also that the two speeds match to within the allowed tolerance. Various factors determine the acceptable tolerance between the two speed estimations:

  • The maximum acceleration of the motor
  • The interrupt response time in the HPS software
  • The alignment of the 4 kHz speed estimation sampling between the HPS and FPGA
  • Clock cycle tolerance in the sampling of the encoder quadrature. One decoder can sample a change in the quadrature signals one clock cycle after the other.

Although the overspeed flag is in the payload data, the design does not cross compare flags because tolerances in the speed estimation means that one speed estimation can be just over the threshold and one just under. Hence the overspeed flags not matching is a valid condition.

The state machine then updates the FPGA status in the shared memory to indicate when the FGPA completes its cross comparison. The state machine then waits, monitoring the HPS status for its cross comparison to be complete.

The FPGA state machine then clears the HPS status in the shared memory and the HPS reciprocally clears the FPGA status in the shared memory. This handshaking ensures that state machines in the FPGA and HPS remain synchronized with each other. The FPGA state machine then returns to the initial state and the process repeats.

Between the generate state and returning to the init state, the design enables a watchdog timer. This watchdog prevents the FPGA state machine from waiting indefinitely for the HPS. If the watchdog expires, the state machine transitions to the error state and the compare_good_p/n output pair is asserted. The design only exits the error state when the reset_safety_n input is asserted (active-low).

Level Two Title