Drive-On-Chip with Functional Safety Design Example for Agilex™ 5 Devices¶

Hardware Description and Functionality¶

This document provides insights about the functionality of the design example using the hardware blocks as a reference. The user must account for the interaction of the hardware described in this section and the software that executes in the Hard Processor System to gain full understanding of the implementation of the Safety Concept for Speed Monitoring.

The Platform Designer high-level system includes many subsystems. These subsystems allow the system to work appropriately.

The clock_subsystem and board_subsystem contain blocks related to the board resources such buttons, switches, LEDs, reference clocks, resets. They provide the clocks and resets for the other subsystems.
The hps_subsystem is an instance of the Agilex™ 5 HPS that runs the HPS safe channel application in Linux. EMIF to on-board DDR4 chip includes presets and connections of the HPS2FPGA bridges to other subsystems. The subsystem includes an instance of DDR4 EMIF to interface with on-board memory chip with all presets and connections to the HPS2FPGA bridges to other subsystems.
The shared_mem_subsystem enables cross comparison data to pass between the FPGA and HPS as part of the safety concept. A memory location where the FPGA channel and the HPS channel read and write the necessary safety payloads.
The esl_subsystem is an internal (FPGA fabric) implementation of the external safety logic. In a production functional safety application, you remove this block and you implement it in a separate device from the Agilex™ device.
The hardware_subsystem collects information off the device that you can use to implement safety features such as voltage and temperature monitoring and validation.
The safety_subsystem implements one channel of the the safety concept in the FPGA. This safety channel is currently attached to the speed monitoring of Axis0
The subsystems dniosv_subsystem*, motor_model_subsystem*, drive_subsystem* and control_subsystem* are blocks related to motor control and motor modeling. For more information on these blocks, refer to AN1000: Drive-On-Chip Design Example for Agilex™ 5 Devices.

The following block diagram shows the main components and subsystems of the "Drive-On-Chip with Functional Example Design".

Hardware Top Block Diagram.

The diagram is color-coded to match the Platform Designer view and the XML contained in the "designs" folder in this repository. The following figure correlates the block diagram, the XML file and the Platform Designer view:

Modular Design Tool Kit PD project vs XML file.

Safety-specific Hardware Subsystems and Components¶

a. Safety Subsystem¶

The safety subsystem consists of various submodules that collect appropriate information to indicate the status and actions of the whole system, which passes into the external safety logic.

The safety subsystem comprises the following blocks:

Safety block (FPGA implementation of the safety channel)
Quadrature encoder pulse
Interval timer
Push button debounce (for reset)
Bridges for control and device access.

Safety Subsystem Platform Designer View.

a.1. Safety Block¶

This block implements the FPGA safety channel. It has two main functional blocks: FPGA safety function block and the FPGA cross-comparison function for HPS-FPGA payloads.

a.1.1 Safety Function Block¶

Contains the FUSA and timer heartbeat generator, speed estimator, and payload generator.

FUSA and Timer Heartbeat Generator: The heartbeat generator monitors the condition of all the other IPs in the FPGA and HPS channels. The generate bit is a control signal that toggles the heartbeat. For the FPGA, the generate input is derived from the FPGA Comparison Function state machine's start output, which in turn triggers from the timeout. Therefore, the FPGA heartbeat signal indicates correct restarting controlled by the software and operating comparison function state machine.
Speed Estimator: The speed estimator estimates the speeds of the motor model based off quadrature encoder pulse count. Using this calculated value, the module determines respective safety bits, which pass into the external safety logic. The main algorithm of the estimator is similar to the one in drive on chip, with additional safety diagnostics. The speed estimator module controls local parameters and modifies sampling frequencies.
Payload Generator: The payload generator takes in many different signals from around the overall safety block and generates a payload with all the relevant information. The FPGA-side payload is passed into the cross-comparison block for relevant and respective checks.

The following table shows the format for the payload data.

32-bit Safety Payload format.

Bit range	Length	Intended Data	Description
[0]	1 bit	Over-speed indication	1 for Over-speed
[25:1]	25 bits	Estimated speed	Measured in rpm
[31:26]	6 bits	Sequence	Implemented an internal counter to register the sequence of measurements. (0-128) always looping around.

a.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. The following diagram specifies the in-built states of the state machine.

State Machine Diagram to execute the Speed
Monitoring Safety Function.

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 over-speed 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 over_speed flags not matching is a valid condition.

The state machine then updates the FPGA status in the shared memory to indicate when the FPGA 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).

a.2. Quadrature Encoder Pulse¶

The quadrature encoder pulse IP decodes the quadrature inputs from the position encoder, signals A, B and I. The Drive-on-Chip with Functional Safety Design Example design reuses the IP from the Drive-on-Chip Design Example. However, it now exposes the count value to pass it for further analysis. The IP also monitors any errors due to over-speed.where both A and B phases of the quadrature change in the same sampling period. The IP may monitor the encoder’s error output.

a.3. Interval Timer¶

The interval timer from the Quartus® or Platform Designer IP catalog is the source of synchronization of the FPGA channel and the HPS channel. Calculating the speed in both the channels, the cross comparison, and evaluating the safety function must occur in the interval between the timer timeout and interrupt signals.

The interval timer provides the safety response time. In this design, the safety response time is 1 ms. During that time, the FPGA channel generates a payload, writes the payload to shared memory, retrieves the payload from the HPS, and runs the comparison. Similar for the HPS safety channel. The HPS uses the interrupt line from Linux to start the safety function.

In this design, the timer is set to 1 ms interval by writing a count value according by the clock frequency of the timer (in this case 100 MHz). This IP writes to the registers periodl and periodh. Then, the timer runs in free running mode by writing a 0x7 in the control register. When the count reach 0x0, the timer issues an Interrupt for the Linux system (the timer is registered as a UIO device in the Linux DTS with its corresponding interrupt number) and the design assert the timeout output. These signals trigger the safety function in the FPGA and HPS channel respectively. When the interrupt occurs, the systems clears the interrupt and the timeout signal and sets the timer to free running mode again.

b. Shared Memory Subsystem¶

The shared memory is a 4x32 bit dual-port block RAM. One side connects via AXI to the HPS. The other side connects via APB interface to the FPGA cross comparison block. The design implements error correction codes (ECC) on both ports, allowing single-bit errors to be automatically corrected and multi-bit errors to be detected. The correction of single-bit errors allows the safety function to continue despite a single fault. If uncorrectable multi-bit errors are detected, the memory_fault_p/n complementary-pair output is asserted. You can only de-assert this output by the active-low reset_safety_n input.

Intended Shared Memory Address Map.

Address	Data
0x0	FPGA payload
0x4	FPGA status
0x8	HPS payload
0xC	HPS status

Intended definition of Status Bit.

FPGA status / HPS status bit	Meaning
0	Valid data from the channel is ready to be compared. Comparison pending.
1	Comparison done in the corresponding channel

c. External Safety Logic Subsystem¶

The external safety logic identifies common causes of failures and disparities in the overall system. You can model the external safety logic via internal logic when no external device is present. The following descriptions state each of the diagnostics external safety logic Implements.

Results of payload comparison: Both the FPGA and HPS process their own comparisons to ensure both values of payload agree. The design passes these outputs into the external safety logic to ensure that both comparison checks agree.
Clock Checker: The external safety logic actively takes in respective FPGA and HPS clocks as inputs of different frequencies. The design processes these signals through the clock checker to ensure frequencies are in a tolerable range. The clock checker takes a fixed reference clock and its respective reset, and compares it to a clock under comparison. Using fixed parameterizable thresholds, the clock checker determines whether the clock under test falls into appropriate and safe frequencies. The external safety logic uses the clock checker to ensure that HPS and PGA clocks operate at appropriate frequencies, and the design has no instances of skewing or jitter when passing through various blocks.
Channel Operation: Refers to the two heartbeat signals present in FPGA and HPS operations. These signals help to identify that everything is functional within a process safety time. The external safety logic receives these signals as inputs, which the design then delays using two flip-flops to prevent any metastable values that might fluctuate through. The design applies a window check to allow for the heartbeat to arrive within a determinable time span.
CRAM Configuration Check: Ensures that no soft errors or transient faults occur.
Power Supply Check: Ensures no failures because of loss of power or unsafe operating voltage conditions. The design checks the power supply by using the Mailbox Client with Avalon Streaming Interface IP. The design compares the voltages to optimal operating voltage conditions. Refer to Agilex™ User Guide.
Temperature Check: Ensures no failures because of unsafe temperatures. The design checks the temperature by using the Mailbox Client with Avalon Streaming Interface IP. The design compares the temperature values against parameterizable temperature limits to ensure they are in a safe range. For more details on power supply and temperature check, refer to Agilex™ Power Management User Guide.
Complementary Bit Package: The complementary bit package contains a typedef for a definition of type called compli which allows effective storage of complementary bit pairs. The complementary bit check also contains fault checking functions to ensure that received complementary pairs are organized into the correct format. The design processes external safety logic's I/O in a complementary manner to detect any stuck bits during transmissions. To accommodate any timing delays, complementary pairs can arrive within a preset and adjustable window.

d. Hardware Subsystem¶

The hardware subsystem collects information about the system, which the external safety logic can use. Agilex™ devices contain on-chip voltage and temperature sensors.

The secure device manager stores sampled data, which you can access by using the Mailbox Client with Avalon Streaming Interface Altera® FPGA IP. Using the relevant information, external safety logic can determine unsafe temperatures and inoperable voltage conditions.

The subsystem comprises command, response, a set of command addresses, and a mailbox client. During the command stage, the mailbox receives preprogrammed addresses. The response stage receives results from the mailbox and sorts into corresponding arrays.

The following table contains command address information.

Hardware Subsystem Command and Address Information.

e. Voltage Thresholds¶

The design tests the voltage measurements received from the secure device manager (SDM) against the thresholds (hex digital value).

Derivation of Voltage Rail Thresholds.

The design divides some of the voltages rails by a factor of two before the on-board ADC samples them. The SDM multiplies up those samples by two again. The ADC measures to ±3.5% accuracy. The final digital output from the SDM mailbox is represented as an unsigned fixed point number with 16 bits below the binary point (e.g. 0x0000C000 = 0.75 V, 0x00010000 = 1.0 V).

This project variant is based on the "Drive-On-Chip Example Design for Agilex™ Devices" see AN 999: Drive-on-Chip with Functional Safety Design Example: Agilex™ 7 Devices and AN 1000: Drive-on-Chip Design Example: Agilex™ 5 Devices. Enhancing it with an instance of the HPS Subsystem (Hard Processor System) to provide a higher level of abstraction for motion control. The subsystems instantiated in the XML file are described below.

a. HPS Subsystem¶

The HPS Subsystem is mainly an instance of the “Hard Processor System Agilex™ (or other) FPGA IP” and is configured consistently with the GSRD. The HPS in this design should run all the necessary SW components to implement the HPS safety channel( e.g., OS, RTOS, containers, drivers, user application, etc). Internally, the subsystem comprises the HPS, EMIF for external DDR4 on the development kit, and lightweight and full HPS-to-FPGA bridges. The lightweight bridge accesses blocks related to the Drive-On-Chip application (drives, motor models, encoders, control memory, GUI memories). The full HPS-to-FPGA bridge connects safety-related blocks (shared safety memory, FPGA safety blocks). The HPS controls the timer that controls the safety function, reads and writes safety payloads, and cleans the FPGA channel control registers if necessary.

The connection from the HPS2FPGA LW bridge to all drive-on-chip subsystem blocks. This connection allows the HPS to change parameters of the motor control. The connection allows the HPS to run speed estimation using the drive0 encoder.

This design connects the HPS to the block hps_fpga_gpio for the inputs for the external safety logic if any of the safe state conditions in the HPS safety channel is asserted.

This design subsystem connects the HPS to the hps_fpga_gpio block. The outputs from hps_fpga_gpio are inputs the external safety logic. Asserting the signals from hps_fpga_gpio triggers the safe state condition from the HPS safety channel.

HPS Subsystem PD sub-Blocks.

b. CPU (dnios_) Subsystem¶

The Drive-On-Chip Design Example NiosV/g processor subsystem offers a fully functional processor system with debugging capabilities. The NiosV/g processor subsystem comprises the following Platform Designer components: NiosV/g soft processor, on-chip RAM, JTAG master, IRQ management, JTAG UART, timers and, performance counters.

NIOSV/g Subsystem PD sub-Blocks.

The ISR uses the memory blocks for code and data to ensure fast, predictable execution time for the motor control algorithm. The NiosV/g subsystem uses the JTAG master and debug memories to allow real-time interactions between the GUI and the processor.

c. Drive Subsystem¶

There are two instances of the drive_subsystem in this variant. This subsystem is a collection of IPs to enable interfaces, signals and ports for motor control using FPGA. The main components of this subsystem are Six-channel PWM Interface IP (doc_pwm), a Drive System Monitor IP (doc_sm), Quadrature Encoder Interface IP (doc_qep), Sigma-Delta ADC interfaces for Drive Axes (doc_adc and doc_adc_pow), an instance of Field-Oriented Control Algorithm IP generated with DSP Builder (doc_foc_fixp), resolver SPI interface IP (doc_rslvr_spi*), and Parallel IO IP (hall pio) for hall interface. More details about these blocks can be found in Application Notes AN 999: Drive-on-Chip with Functional Safety Design Example: Agilex™ 7 Devices and AN 1000: Drive-on-Chip Design Example: Agilex™ 5 Devices

Drive Subsystem PD sub-Blocks.

d. Control Subsystem¶

The Drive-On-Chip Design uses the debugging RAM to send commands and receive status information. The debugging dump memory stores trace data that you can display as time graphs in the GUI (doc_svm_dump). The debug memory (doc_sys__debug_ram) is used to interact and provide commands to the Drive-On-Chip control application. The memories contained in the control subsystem are fundamental to interacting with the DoC capabilities and getting feedback signals for debugging and external control.
In this safety-oriented variant an additional doc_safety_dump memory in the control_subsystem to show safety-related values in another interface e.g. a GUI.

Control Subsystem PD sub-Blocks.

e. Motor Model Subsystem¶

The Drive-On-Chip Design Example for Agilex™ Devices implements a motor and power board model instead of a real motor kit. The motor and power board model is a DSP Builder model, which generates the RTL for the motor and power board model. By integrating the Avalon interface, motor parameters are accurately configured to represent a tandem motor kit. You can experiment with the design without investing in an expensive motor kit. You can explore and optimize your designs. The motor model included in this design example is based on the Tandem Motion 48V power board parameter specifications with a Tamagawa TS4747N3200E600 motor. There are two instances of the motor_model_subsystem in this design.
To expand safety capabilities, the connection between the motor_model subsystem and the esl_subsystem allows you to disconnect the motor from power supply if the system goes into "safe state" whenever the design detects an unsafe condition. The external safety logic asserts the signal to disconnect the motor.

Motor Model Subsystem PD sub-Blocks.

General Use Hardware Subsystems and Components¶

a. Clock and Board Subsystems¶

The clock Subsystem alongside the board subsystem contains blocks related to the board resources such as buttons, switches, LEDs, reference clocks, and resets. They provide the clocks and resets for the other subsystems.

Board and Clock Subsystems PD sub-Blocks.

Back to Documentation

Last update: March 6, 2025
Created: March 6, 2025