Visible to Intel only — GUID: fcg1716385508439
Ixiasoft
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
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
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
Visible to Intel only — GUID: fcg1716385508439
Ixiasoft
1.2. About the Safety Concept
Applying safety concept principles to the Drive-on-Chip with Functional Safety Design Examples
According to ISO 13849-1, clause 6.2.6 the Category 3 requirements are:
- Apply designated architecture for Cat. 3.
- Apply measures against common cause failures (CCF) (see Annex F).
- For category 3, apply the same basic safety principles as those according to 6.2.3 for category By.
- Follow “Well-tried safety principles” (see ISO 13849-2) according to 6.2.4.
- Design SRP/CS of category 3 so that a single fault in any of these parts does not lead to the loss of the safety function.
- Whenever reasonably practicable, detect the single fault at or before the next demand upon the safety function.
- Ensure the diagnostic coverage (DCavg) of the total safety related parts of the control system (SRP/CS) including fault detection must be at least low.
- Ensure the mean time to dangerous failure (MTTFD) of each of the redundant channels must be low-to-high, depending on the performance level.
According to ISO 13849-1:2015, clause 6.2.6, the designated architecture for Cat. 3 requires two channels with independent inputs and outputs and a cross comparison (CC). Altera can satisfy this architecture by implementing two logical blocks in a single SoC FPGA, with an external safety logic to mitigate common cause failures. The design meets Cat 3 designated architecture and the measures against CCF. However the reliability parameters (MTTFD , DCavg) are application-specific and you can only evaluate them at application level with a specific safety concept, although the design includes examples of such diagnostics.
Figure 2. First-Level Safety Concept Diagram Applied to Drive-on-Chip Design Example.The figure shows the basic architecture of the safety concept divided in two independent safety channels.
The design implements the first channel using the hard processor system (HPS) in the Agilex™ 7 SoC devices to run speed monitoring and cross-comparison functions. The HPS safety function interacts with the nonsafe function or drive-on-chip block to monitor and estimate the speed for a safe threshold.
The design implements the second channel in the FPGA fabric using custom and Platform Designer IP to monitor and calculate motor rotational speed. The design cross compares and verifies data from the HPS safety channel and the FPGA safety channel by its counterpart within the safety response time. Multiple mechanisms verify the correct behavior of the safety logic.
Many faults in motor control can lead to the motor overspeeding and so if either of the speed monitor safety functions detects such a fault, the design removes power from the motor to prevent the motor running unsafely.
The HPS and FPGA channels provide diverse implementations of the safety function that improves the diagnostic coverage. The design can detect some systematic faults and random faults and also counts towards CCF measures. AXI and APB interfaces pass the cross-comparison data between the FPGA and HPS. This maximizes RTL re-use and also allow use of third party verification IP, which can help reduce systematic faults and add independence to the verification process.
The external safety logic detects when FPGA and SoC fail simultaneously and performs functions such as monitoring temperature and providing a watchdog function. In a real design, the external safety logic is a physically separate device. However, this design models it within the FPGA.
FPGA features add diagnostics. ECC and complementary pins. ECC in the shared memory detects multibit errors and corrects single-bit errors.
Complementary-pair signaling adds redundancy to detect stuck or short type faults. The complementary-pair consists of two signals denoted _p and _n corresponding to active-high and active-low respectively. Under normal circumstances the _p and _n elements are always opposite polarity to each other. If they are the same, a fault has occurred – e.g. stuck-high or low fault, short to adjacent pin.