AN 866: Mitigating and Debugging Single Event Upsets in Intel Quartus Prime Standard Edition
1. Mitigating Single Event Upset
The Intel® Quartus® Prime Standard Edition software offers several features to detect and correct the effects of SEU, or soft errors, as well as to characterize the effects of SEU on your designs. Additionally, some Intel FPGAs contain dedicated circuitry to help detect and correct errors.
Intel FPGAs have memory in user logic (block memory and registers) and in Configuration Random Access Memory (CRAM). The Intel® Quartus® Prime Programmer loads the CRAM with a .sof file. Then, the CRAM configures all FPGA logic and routing. If an SEU strikes a CRAM bit, the effect can be harmless if the device does not use the CRAM bit. However, the effect can be severe if the SEU affects critical logic or internal signal routing.
Often, a design does not require SEU mitigation because of the low chance of occurrence. However, for highly complex systems, such as systems with multiple high-density components, the error rate may be a significant system design factor. If your system includes multiple FPGAs and requires very high reliability and availability, you should consider the implications of soft errors. Use the techniques in this document to detect and recover from these types of errors.
1.1. Failure Rates
The Soft Error Rate (SER) or SEU reliability is expressed in Failure in Time (FIT) units. One FIT unit is one soft error occurrence per billion hours of operation.
- For example, a design with 5,000 FIT experiences a mean of 5,000 SEU events in one billion hours (or 114,155.25 years). Because SEU events are statistically independent, FIT is additive. If a single FPGA has 5,000 FIT, then ten FPGAs have 50,000 FIT (or 50K failures in 114,155.25 years).
Another reliability measurement is the mean time to failure (MTTF), which is the reciprocal of the FIT or 1/FIT.
- For a FIT of 5,000 in standard units of
failures
per billion hours, MTTF is:
1 ÷ (5,000 ÷ 1 Bh)=1 billion ÷ 5,000 = 200,000 hours = 22.83 years
SEU events follow a Poisson distribution and the cumulative distribution function (CDF) for mean time between failures (MTBF) is an exponential distribution. For more information about failure rate calculation, refer to the Intel FPGA Reliability Report.
Neutron SEU incidence varies by altitude, latitude, and other environmental factors. The Intel® Quartus® Prime software provides SEU FIT reports based on compiles for sea level in Manhattan, New York. The JESD89A specification defines the test parameters.
1.2. Mitigating SEU Effects in Embedded User RAM
Stratix® V, Stratix® IV, and Arria® V GZ FPGAs offer dedicated error correcting code (ECC) circuitry for embedded memory blocks. FPGA families that do not have dedicated ECC circuitry support ECC by implementing a soft IP core.
You can reduce the FIT rate for these memories to near zero by enabling the ECC encode/decode blocks. On ingress, the ECC encoder adds 8 bits of redundancy to a 32 bit word. On egress, the decoder converts the 40 bit word back to 32 bits. You use the redundant bits to detect and correct errors in the data resulting from SEU.
The existence of hard ECC and the strength of the ECC code (number of corrected and detected bits) varies by device family. Refer to the device handbook for details. If a device does not have a hard ECC block you can add ECC parity or use an ECC IP core.
The SRAM memories associated with processor subsystems, such as for SoC devices, contain dedicated hard ECC. You do not need to take action to protect these memories.
For more information about embedded memories and ECC, refer to the device documentation.
1.2.1. Configuring RAM to Enable ECC
Although the ECC checking function results in some additional output delay, the hard ECC has a much higher fMAX compared with an equivalent soft ECC block implemented in general logic. Additionally, you can pipeline the hard IP in the M20K block by configuring the ECC-enabled RAM to use an output register at the corrected data output port. This implementation increases performance and adds latency.
For devices without dedicated circuitry, you can implement ECC by instantiating the ALTECC IP core, which performs ECC generation and checking functions.1.3. Mitigating SEU Effects in Configuration RAM
Intel FPGAs contain frames of CRAM. The size and number of frames is device specific. The device continually checks the CRAM frames for errors by loading each frame into a data register. The EDCRC block checks the frame for errors.
When the FPGA finds a soft error, the FPGA asserts its CRC_ERROR pin. You can monitor this pin in your system. When your system detects that the FPGA asserted this pin during operation, indicating the FPGA detected a soft error in the configuration RAM, the system can take action to recover from the error. For example, the system can perform a soft reset (after waiting for background scrubbing), reprogram the FPGA, or classify the error as benign and ignore it.
To enable error detection, point to Assignments > Device > Device and Pin Options > Error Detection CRC, and turn on error detection settings.
1.4. Internal Scrubbing
The internal scrubbing feature corrects single-bit and double-adjacent errors automatically.
If the FPGA finds a CRC error in a CRAM frame, the FPGA reconstructs the frame from the error correcting code calculated for that frame. Then the FPGA writes the correct frame into the CRAM.
If you enable internal scrubbing, you must still plan a recovery sequence. Although scrubbing can restore the CRAM array to intended configuration, latency occurs between the soft error detection and correction. During this latency period, the FPGA may operate with errors. If the FPGA must scan a large number of configuration bits, this latency can be up to 100 milliseconds. For more information about latency refer to the device datasheet.
To enable internal scrubbing, click Assignments > Device > Device and Pin Options > Error Detection CRC and turn on the Enable internal scrubbing option.
1.5. SEU Recovery
Errors due to faulty operation can propagate elsewhere within the FPGA or to the system outside the FPGA. During your design process, determine the possible SEU outcomes and design a recovery response that considers resetting the FPGA to a known state.
1.5.1. Planning for SEU Recovery
Often, an SEU impacts CRAM bits that the implemented design does not use (for example, CRAM bits that control unused logic and routing wires). Depending on the implementation, FPGAs with high utilization only use about 40% of available CRAM bits. Therefore, only 40% of potential SEU events in the entire FPGA require intervention, and you can ignore the remaining 60%. Designs that do not completely fill the FPGA use even fewer available CRAM bits.
You can determine which portions of the implemented design are not critical to the FPGA's function. Examples include test circuitry that is not important to the FPGA operation, or other non-critical functions that the system can log but does not need to reprogram or reset.
1.5.2. Designating the Sensitivity of the Design Hierarchy
When an error occurs during system operation, the system determines the impact of the error by looking up the classification in the .smh file. The system can then take corrective action based on the classification.
To access the .smh file, you must add an instance of the IP core to your design.
1.5.2.1. Hierarchy Tagging
The Intel® Quartus® Prime hierarchy tagging feature allows you to improve design-effective FIT rate by tagging only the critical logic for device operation.
You can also define the system recovery procedure based on knowledge of logic impaired by SEU. This technique reduces downtime for the FPGA and the system in which the FPGA resides. Other advantages of hierarchy tagging are:
- Increases system stability by avoiding disruptive recovery procedures for inconsequential errors.
- Allows diverse corrective action for different design logic.
The .smh file contains a mask for design sensitive bits in a compressed format. The Intel® Quartus® Prime software generates the sensitivity mask for the entire design. The Intel® Arria® 10, Cyclone® V, and Stratix® V device families support hierarchy tagging.
1.5.2.2. Using Partitions to Specify Logic Sensitivity ID
- In the Intel® Quartus® Prime software, designate a design block as a design partition.
- Specify the sensitivity ID assigned to the partition in the ASD
Region column in the Design Partitions
window. Figure 4. ASD Region Column in the Design Partitions WindowAssign the partition a numeric sensitivity value from 0 to 16. The value represents the sensitivity tag associated with the partition.
- A sensitivity tag of 1 is the same as no assignment, and indicates a basic sensitivity level, which is "region used in design". If a soft error occurs in this partition, the IP core reports the error as a critical error in the sensitivity region 1.
- A sensitivity tag of 0 is reserved, and indicates unused CRAM bits. You can explicitly set a partition to 0 to indicate that the partition is not critical. This setting excludes the partition from sensitivity mapping.
Alternatively, use the following assignment:
set_global_assignment -name PARTITION_ASD_REGION_ID <asd_id> -section_id <partition_name>
1.5.3. Advanced SEU Detection IP Core
- During system operation, the Advanced SEU Detection IP core reads the FPGA's error message register (EMR) to determine the location of the error.
- The IP core finds the upset location in the .smh file.
- The IP core returns whether or not the bit is critical for the design.
You can implement either an on-chip or external sensitivity processor:
- On-chip sensitivity processor: the IP core looks up the bit sensitivity in the .smh with a user-supplied memory interface.
- External sensitivity processor: the IP core notifies external logic (typically via a system CPU interrupt request), and provides cached event message register values to the off-chip sensitivity processor. The external sensitivity processor's memory system stores the .smh information.
The Advanced SEU Detection IP Core User Guide provides instructions for incorporating the IP core into your design, and describes how to access the .smh file.
1.5.3.1. On-Chip Sensitivity Processor
On-chip sensitivity processing is autonomous: the FPGA determines whether an SEU affected it without using external logic. On-chip sensitivity processing requires some FPGA logic resources for the external memory interface.
1.5.3.2. External Sensitivity Processor
With external sensitivity processing, the FPGA does not need to implement an external memory interface or store the .smh. If the system already has a CPU, external sensitivity processing may be more hardware efficient than on-chip processing.
1.6. Intel Quartus Prime Software SEU FIT Reports
1.6.1. SEU FIT Parameters Report
- Altitude represents the default altitude (above sea-level).
-
Neutron Flux Multiplier is the
relative flux for the default location, which is New York City per JESD specification. The
default is 1. Change the setting by adding the following assignment to your .qsf
file:
set_global_assignment RELATIVE_NEUTRON_FLUX <relative_flux>
Note: You can compute scaled values using the JESD published equations for altitude, latitude, and longitude. Websites, such as www.seutest.com, can make this computation for you. -
Alpha Flux is the default for
standard Intel packages; you cannot override
the default. Note: When you change the relative Neutron Flux Multiplier, the Intel® Quartus® Prime software only scales the neutron component of FIT. Location does not affect the Alpha flux.
1.6.2. Projected SEU FIT by Component Usage Report
An Intel FPGA's sensitivity to soft errors varies by process technology, component type, and your design choices when implementing the component (such as tradeoffs between area/delay and SEU rates). The report shows all bits (the raw FIT), utilized bits (only resources the design actually uses), and the ECC-mitigated bits.

1.6.2.1. Component FIT Rates
The Projected SEU FIT by Component report shows FIT for the following components:
- SRAM embedded memory in embedded processors hard IP and M20K or M10K blocks
- CRAM used for LUT masks and routing configuration bits
- LABs in MLAB mode
- I/O configuration registers, which the FPGA implements differently than CRAM and design flipflops
- Standard flipflops the design uses in the address and data registers of M20K blocks, in DSP blocks, and in hard IP
- User flipflops the design implements in logic cells (ALMs or LEs)
1.6.2.2. Raw FIT
The Intel® Quartus® Prime software computes the FIT for each component using (component Mb × intrinsic FIT/Mb × Neutron Flux Multiplier) for the device family and process node. (For flip flops, “Mb” represents a million flip flops.)
To give the worst-case raw FIT, the report assumes the maximum amount of CRAM that implements MLABs in the device. Thus, the CRAM raw FIT is the sum of CRAM and MLAB entries.
1.6.2.3. Utilized FIT
The Projected SEU FIT by Component report's Utilized CRAM FIT represents provable deflation of the FIT rate to account for CRAM upsets that do not matter to the design. Thus, the SEU incidence is always higher than the utilized FIT rate.
1.6.2.3.1. Comparing .smh Critical Bits Report to Utilized Bit Count
The number of design critical bits that the Compiler reports during .smh generation correlates to the utilized bits in the report, but it is not the same value. The difference occurs because the .smh file includes all bits in a resource, even when the resource usage is partial.
1.6.2.3.2. Considerations for Small Designs
The raw FIT for the entire device is always correct. In contrast, the utilized FIT is very conservative, and only becomes accurate for designs that reasonably fill up the chosen device. FPGAs contain overhead, such as the configuration state machine, the clock network control logic, and the I/O calibration block. These infrastructure blocks contain flip flops, memories, and sometimes I/O configuration blocks.
The Projected SEU FIT by Component report includes the constant overhead for GPIO and HSSI calibration circuitry for first I/O block or transceiver the design uses. Because of this overhead, the FIT of a 1-transceiver design is much higher than 1/10 the FIT of a 10-transceiver design. However, a trivial design such as “a single AND gate plus flipflop” could use so few bits that its CRAM FIT rate is 0.01, which the report rounds to zero.
1.6.2.4. Mitigated FIT
The Projected SEU FIT by Component Usage report's w/ECC column represents the FPGA's lowest guaranteed, provable FIT rate that the Intel® Quartus® Prime software can calculate. ECC does not affect CRAM and flipflop rates; therefore, the data in the w/ECC column for these components is the same as the in Utilized column.
The ECC code strength varies with the device family. In devices, the M20K block can correct up to two errors, and the FIT rate beyond two (not corrected) is small enough to be negligible in the total.
An MLAB is simply a LAB configured with writable CRAM. However, when the Intel® Quartus® Prime software configures the RAM as write enabled (MLAB), the MLAB has a slightly different FIT/Mb. The Projected SEU FIT by Component Usage report displays a FIT rate in the MLAB row when the design uses MLABs, otherwise the report accounts for the block's FIT in the CRAM row. During compilation, if the Intel® Quartus® Prime software changes a LAB to an MLAB, the FIT accounting moves from the LAB row to the MLAB row.
The w/ECC column does not account for other forms of FIT protection in the design, such as designer-inserted parity, soft ECC blocks, bounds checking, system monitors, triple-module redundancy, or the impact of higher-level protocols on general fault tolerance. Additionally, it does not account for single event effects that occur in the logic but the design never reads or notices. For example, if you implement a non-ECC FIFO function 512 bits deep and an SEU event occurs outside of the front and back pointers, the application does not observe the SEU event. However, the report accounts for the full 512 bit deep memory and includes it in the w/ECC FIT rate. Designers often combine these factors into general deflation factors (called architectural vulnerability factors or AVF) based on knowledge of their design. Designers use AVF factors as low (aggressive) as 5% and as high (conservative) as 50% based on experience, fault-injection or neutron beam testing, or high-level system monitors.
1.6.2.5. Architectural Vulnerability Factor
SEFI represents a combination of factors. A utilization + ECC factor of 40% and AVF of 25% thus represents a global SEFI factor of 10%, because 0.4 × 0.25 = 0.1. An end-to-end SEFI factor of 10% is typical for a full design.
1.6.3. Enabling the Projected SEU FIT by Component Usage Report
To enable the report:
- Obtain and install the SEU license.
-
Add the following assignments to your project's .qsf file:
set_global_assignment –name ENABLE_ADV_SEU_DETECTION ON set_global_assignment –name SEU_FIT_REPORT ON
1.7. Triple-Module Redundancy
With TMR, your design does not suffer downtime in the case of a single SEU; if the system detects a faulty module, the system can scrub the error by reprogramming the module. The error detection and correction time is many orders of magnitude less than the MTBF of SEU events. Therefore, the system can repair a soft interrupt before another SEU affects another instance in the TMR application.
The disadvantage of TMR is its hardware resource cost: it requires three times as much hardware in addition to voting logic. You can minimize this hardware cost by implementing TMR for only the most critical parts of your design.
There are several automated ways to generate TMR designs by automatically replicating designated functions and synthesizing the required voting logic. Synopsys offers automated TMR synthesis.
1.8. Evaluating a System's Response to Functional Upsets
The Fault Injection Debugger works together with the Fault Injection IP core. To use the debugging feature you must instantiate the Fault Injection IP core in the FPGA design. During debugging, the IP core flips a CRAM bit by dynamically reconfiguring the frame containing the CRAM bit.
1.9. CRAM Error Detection Settings Reference

Setting | Description |
---|---|
Enable Error Detection CRC_ERROR pin | Enables CRAM frame scanning |
Enable open drain on CRC_ERROR pin | Enables the CRC_ERROR pin as an open-drain output |
Divide error check frequency by | To guarantee the availability of a clock, the EDCRC function operates on an independent clock generated internally on the FPGA itself. To enable EDCRC operation on a divided version of the clock, select a value from the list. |
1.10. Document Revision History
Date | Version | Changes |
---|---|---|
2021.01.05 | 17.1.0 |
|
2019.09.10 | 17.1.0 | Updated the topic about failure rates to correct the number of years of one billion hours. |
2017.12.15 | 17.1.0 |
|
2017.11.06 | 17.1.0 |
|
2016.10.31 | 16.1.0 |
|
2016.05.24 | 16.0.1 |
|
2016.05.03 | 16.0.0 |
|
2015.11.02 | 15.1.0 |
|
June 2014 |
2014.06.30 |
|
November 2012 |
2012.11.01 |
|
2. Debugging Single Event Upset Using the Fault Injection Debugger
You can detect and debug single event upset (SEU) using the Fault Injection Debugger in the Intel® Quartus® Prime software. Use the debugger with the Intel FPGA Fault Injection IP core to inject errors into the configuration RAM (CRAM) of an Intel FPGA device.
The injected error simulates the soft errors that can occur during normal operation due to SEUs. Since SEUs are rare events, and therefore difficult to test, you can use the Fault Injection Debugger to induce intentional errors in the FPGA to test the system's response to these errors.
The Fault Injection Debugger is available for Intel® Arria® 10 and Stratix® V family devices. For assistance with support for Arria® V or Cyclone® V family devices, file a service request using your My Intel account.
The Fault Injection Debugger provides the following benefits:
- Allows you to evaluate system response for mitigating single event functional interrupts (SEFI).
- Allows you to perform SEFI characterization, eliminating the need for entire system beam testing. Instead, you can limit the beam testing to failures in time (FIT)/Mb measurement at the device level.
- Scale FIT rates according to the SEFI characterization that is relevant to your design architecture. You can randomly distribute fault injections throughout the entire device, or constrain them to specific functional areas to speed up testing.
- Optimize your design to reduce SEU-caused disruption.
2.1. Single Event Upset Mitigation
Integrated circuits and programmable logic devices such as FPGAs are susceptible to SEUs. SEUs are random, nondestructive events, caused by two major sources: alpha particles and neutrons from cosmic rays. Radiation can cause either the logic register, embedded memory bit, or a configuration RAM (CRAM) bit to flip its state, thus leading to unexpected device operation.
Intel® Arria® 10 , Arria® V, Cyclone® V, Stratix® V and newer devices have the following CRAM capabilities:
- Error Detection Cyclical Redundance Checking (EDCRC)
- Automatic correction of an upset CRAM (scrubbing)
- Ability to create an upset CRAM condition (fault injection)
For more information about SEU mitigation in Intel FPGA devices, refer to the SEU Mitigation chapter in the respective device handbook.
2.2. Hardware and Software Requirements
The following hardware and software is required to use the Fault Injection Debugger:
- FEATURE line in your Intel FPGA license that enables the IP core. For more information, contact your local Intel FPGA sales representative.
- Download cable ( Intel® FPGA Download Cable, Intel® FPGA Download Cable II, Intel® FPGA Ethernet Cable, or Intel® FPGA Ethernet Cable II).
- Intel FPGA development kit or user designed board with a JTAG connection to the device under test.
- (Optional) FEATURE line in your Intel FPGA license that enables the Advanced SEU Detection IP core.
2.3. Using the Fault Injection Debugger and IP Core
The Fault Injection Debugger works together with the IP core. First, you instantiate the IP core in your design, compile, and download the resulting configuration file into your device. Then, you run the Fault Injection Debugger from within the Intel® Quartus® Prime software or from the command line to simulate soft errors.
- The Fault Injection Debugger allows you to operate fault injection experiments interactively or by batch commands, and allows you to specify the logical areas in your design for fault injections.
- The command-line interface is useful for running the debugger via a script.
The Fault Injection Debugger communicates with the IP core via the JTAG interface. The IP accepts commands from the JTAG interface and reports status back through the JTAG interface.
You use the IP core with the following IP cores:
- The Error Message Register Unloader IP core, which reads and stores data from the hardened error detection circuitry in Intel FPGA devices.
- (Optional) The Advanced SEU Detection Intel® FPGA IP core, which compares single-bit error locations to a sensitivity map during device operation to determine whether a soft error affects it.
2.3.1. Instantiating the IP Core
The and the EMR Unloader IP cores are available in Platform Designer and the IP Catalog. Optionally, you can instantiate them directly into your RTL design, using Verilog HDL, SystemVerilog, or VHDL.
2.3.1.1. About the EMR Unloader IP Core

2.3.1.2. About the Advanced SEU Detection IP Core
You must use the EMR Unloader IP core with the ASD IP core. Therefore, if you use the ASD IP and the IP in the same design, they must share the EMR Unloader output via an Avalon® -ST splitter component. The following figure shows a Platform Designer system in which an Avalon® -ST splitter distributes the EMR contents to the ASD and IP cores.

2.3.2. Defining Fault Injection Areas
The SMH file stores the coordinates of the device CRAM bits, their assigned region (ASD Region), and criticality. During the design process you use hierarchy tagging to create the region. Then, during compilation, the Intel® Quartus® Prime Assembler generates the SMH file. The Fault Injection Debugger limits error injections to specific device regions you define in the SMH file.
2.3.2.1. Performing Hierarchy Tagging
- Choose Assignments > Design Partitions Window.
- Right-click anywhere in the header row and turn on ASD Region to display the ASD Region column (if it is not already displayed).
-
Enter a value from 0 to 16 for any partition to assign it to a specific ASD
Region.
- ASD region 0 is reserved to unused portions of the device. You can assign a partition to this region to specify it as non-critical..
- ASD region 1 is the default region. All used portions of the device are assigned to this region unless you explicitly change the ASD Region assignment.
2.3.2.2. About SMH Files
The SMH file contains the following information:
- If you are not using hierarchy tagging (i.e., the design has no explicit ASD Region assignments in the design hierarchy), the SMH file lists every CRAM bit and indicates whether it is sensitive for the design.
- If you have performed hierarchy tagging and changed default ASD Region assignments, the SMH file lists every CRAM bit and it's assigned ASD region.
The Fault Injection Debugger can limit injections to one or more specified regions.
- Choose Assignments > Device > Device and Pin Options > Error Detection CRC.
- Turn on the Generate SEU sensitivity map file (.smh) option.
2.3.3. Using the Fault Injection Debugger
To use the Fault Injection Debugger, you connect to your device via the JTAG interface. Then, configure the device and perform fault injection.

To configure your JTAG chain:
- Click Hardware Setup. The tool displays the programming hardware connected to your computer.
- Select the programming hardware you wish to use.
- Click Close.
- Click Auto Detect, which populates the device chain with the programmable devices found in the JTAG chain.
2.3.3.1. Configuring Your Device and the Fault Injection Debugger
The Software Object File (.sof) configures the FPGA. The .smh file defines the sensitivity of the CRAM bits in the device. If you do not provide an .smh file, the Fault Injection Debugger injects faults randomly throughout the CRAM bits.
To specify a .sof:
- Select the FPGA you wish to configure in the Device chain box.
- Click Select File.
- Navigate to the .sof and click OK. The Fault Injection Debugger reads the .sof.
-
(Optional) Select the SMH file.
If you do not specify an SMH file, the Fault Injection Debugger injects faults randomly across the entire device. If you specify an SMH file, you can restrict injections to the used areas of your device.
- Right-click the device in the Device chain box and then click Select SMH File.
- Select your SMH file.
- Click OK.
- Turn on Program/Configure.
- Click Start.

2.3.3.2. Constraining Regions for Fault Injection
- Right-click the FPGA in the Device chain box, and click Show Device Sensitivity Map.
- Select the ASD region(s) for fault injection.

2.3.3.3. Specifying Error Types
- Single errors (SE)
- Double-adjacent errors (DAE)
- Uncorrectable multi-bit errors (EMBE)
Intel FPGA devices can self-correct single and double-adjacent errors if the scrubbing feature is enabled. Intel FPGA devices cannot correct multi-bit errors. Refer to the chapter on mitigating SEUs for more information about debugging these errors.
- In the Fault Injection Debugger, choose Tools > Options.
- Drag the red controller to the mix of errors. Alternatively, you can specify the mix numerically.
- Specify the Injection interval time.
- Click OK.

2.3.3.4. Injecting Errors
- Inject one error on command
- Inject multiple errors on command
- Inject errors until commanded to stop
- Turn on the Inject Fault option.
- Choose whether you want to run error injection for a number of iterations
or until stopped:
- If you choose to run until stopped, the Fault Injection Debugger injects errors at the interval specified in the Tools > Options dialog box.
- If you want to run error injection for a specific number of iterations, enter the number.
- Click Start.Note: The Fault Injection Debugger runs for the specified number of iterations or until stopped.
The Intel® Quartus® Prime Messages window shows messages about the errors that are injected. For additional information on the injected faults, click Read EMR. The Fault Injection Debugger reads the device's EMR and displays the contents in the Messages window.
2.3.3.5. Recording Errors
If, for example, an injected fault results in behavior you would like to replay, you can target that location for injection. You perform targeted injection using the Fault Injection Debugger command line interface.
2.3.3.6. Clearing Injected Errors
2.3.4. Command-Line Interface
You can run the Fault Injection Debugger at the command line with the quartus_fid executable, which is useful if you want to perform fault injection from a script.
Short Argument |
Long Argument |
Description |
---|---|---|
c | cable |
Specify programming hardware or cable. (Required) |
i | index |
Specify the active device to inject fault. (Required) |
n | number |
Specify the number of errors to inject. The default value is 1. (Optional) |
t | time |
Interval time between injections. (Optional) |
The following code provides examples using the Fault Injection Debugger command-line interface.
############################################ # # Find out which USB cables are available for this instance # The result shows that one cable is available, named "USB-Blaster" # $ quartus_fid --list . . . Info: Command: quartus_fid --list 1) USB-Blaster on sj-sng-z4 [USB-0] Info: Intel® Quartus® Prime 64-Bit Fault Injection Debugger was successful. 0 errors, 0 warning ############################################ # # Find which devices are available on USB-Blaster cable # The result shows two devices: a Stratix® V A7, and a MAX V CPLD. # $ quartus_fid --cable USB-Blaster -a Info: Command: quartus_fid --cable=USB-Blaster -a Info (208809): Using programming cable "USB-Blaster on sj-sng-z4 [USB-0]" 1) USB-Blaster on sj-sng-z4 [USB-0] 029030DD 5SGXEA7H(1|2|3)/5SGXEA7K1/.. 020A40DD 5M2210Z/EPM2210 Info: Intel® Quartus® Prime 64-Bit Fault Injection Debugger was successful. 0 errors, 0 warnings ############################################ # # Program the Stratix® V device # The --index option specifies operations performed on a connected device. # "=svgx.sof" associates a .sof file with the device # "#p" means program the device # $ quartus_fid --cable USB-Blaster --index "@1=svgx.sof#p" . . . Info (209016): Configuring device index 1 Info (209017): Device 1 contains JTAG ID code 0x029030DD Info (209007): Configuration succeeded -- 1 device(s) configured Info (209011): Successfully performed operation(s) Info (208551): Program signature into device 1. Info: Intel® Quartus® Prime 64-Bit Fault Injection Debugger was successful. 0 errors, 0 warnings ############################################ # # Inject a fault into the device. # The #i operator indicates to inject faults # -n 3 indicates to inject 3 faults # $ quartus_fid --cable USB-Blaster --index "@1=svgx.sof#i" -n 3 Info: Command: quartus_fid --cable=USB-Blaster --index=@1=svgx.sof#i -n 3 Info (208809): Using programming cable "USB-Blaster on sj-sng-z4 [USB-0]" Info (208521): Injects 3 error(s) into device(s) Info: Intel® Quartus® Prime 64-Bit Fault Injection Debugger was successful. 0 errors, 0 warnings ############################################ # # Interactive Mode. # Using the #i operation with -n 0 puts the debugger into interactive mode. # Note that 3 faults were injected in the previous session; # "E" reads the faults currently in the EMR Unloader IP core. # $ quartus_fid --cable USB-Blaster --index "@1=svgx.sof#i" -n 0 Info: Command: quartus_fid --cable=USB-Blaster --index=@1=svgx.sof#i -n 0 Info (208809): Using programming cable "USB-Blaster on sj-sng-z4 [USB-0]" Enter : 'F' to inject fault 'E' to read EMR 'S' to scrub error(s) 'Q' to quit E Info (208540): Reading EMR array Info (208544): 3 frame error(s) detected in device 1. Info (208545): Error #1 : Single error in frame 0x1028 at bit 0x21EA. Info (10914): Error #2 : Uncorrectable multi-bit error in frame 0x1116. Info (208545): Error #3 : Single error in frame 0x1848 at bit 0x128C. Enter : 'F' to inject fault 'E' to read EMR 'S' to scrub error(s) 'Q' to quit Q Info: Intel® Quartus® Prime 64-Bit Fault Injection Debugger was successful. 0 errors, 0 warnings Info: Peak virtual memory: 1522 megabytes Info: Processing ended: Mon Nov 3 18:50:00 2014 Info: Elapsed time: 00:00:29 Info: Total CPU time (on all processors): 00:00:13
2.3.4.1. Targeted Fault Injection Feature
The Fault Injection Debugger injects faults into the FPGA randomly. However, the Targeted Fault Injection feature allows you to inject faults into targeted locations in the CRAM. This operation may be useful, for example, if you noted an SEU event and want to test the FPGA or system response to the same event after modifying a recovery strategy.
You can specify that errors are injected from the command line or in prompt mode.
2.3.4.1.1. Specifying an Error List From the Command Line
c:\Users\sng> quartus_fid -c 1 - i "@1= svgx.sof#i " -n 2 -user="@1= 0x2274 0x05EF 0x2264 0x0500"
Where:c 1 indicates that the fpga is controlled by the first cable on your computer.
i "@1= svgx.sof#i " indicates that the first device in the chain is loaded with the object file svgx.sof and is injected with faults.
n 2 indicates that two faults are injected.
user=”@1= 0x2274 0x05EF 0x2264 0x0500” is a user-specified list of faults that are injected. In this example, device 1 has two faults: at frame 0x2274, bit 0x05EF and at frame 0x2264, bit 0x0500.
2.3.4.1.2. Specifying an Error List From Prompt Mode
Prompt Mode Command | Description |
---|---|
F | Inject a fault |
E | Read the EMR |
S | Scrub errors |
Q | Quit |
In prompt mode, you can issue the F command alone to inject a single fault in a random location in the device. In the following examples using the F command in prompt mode, three errors are injected.
F #3 0x12 0x34 0x56 0x78 * 0x9A 0xBC +
- Error 1 – Single bit error at frame 0x12, bit 0x34
- Error 2 – Uncorrectable error at frame 0x56, bit 0x78 (an * indicates a multi-bit error)
- Error 3 – Double-adjacent error at frame 0x9A, bit 0xBC (a + indicates a double bit error)
F 0x12 0x34 0x56 0x78 *
One (default) error is injected:
Error 1 – Single bit error at frame 0x12, bit 0x34. Locations after the first frame/bit location are ignored.
F #3 0x12 0x34 0x56 0x78 * 0x9A 0xBC + 0xDE 0x00
Three errors are injected:
- Error 1 – Single bit error at frame 0x12, bit 0x34
- Error 2 – Uncorrectable error at frame 0x56, bit 0x78
- Error 3 – Double-adjacent error at frame 0x9A, bit 0xBC
- Locations after the first 3 frame/bit pairs are ignored
2.3.4.1.3. Determining CRAM Bit Locations
During system testing, save the EMR contents reported by the Fault Injection Debugger when you detect an EDCRC fault.
2.3.4.2. Advanced Command-Line Options: ASD Regions and Error Type Weighting
First, you specify the mix of error types (single bit, double adjacent, and multi-bit uncorrectable) using the --weight <single errors>.<double adjacent errors>.<multi-bit errors> option. For example, for a mix of 50% single errors, 30% double adjacent errors, and 20% multi-bit uncorrectable errors, use the option --weight=50.30.20. Then, to target an ASD region, use the -smh option to include the SMH file and indicate the ASD region to target. For example:
$ quartus_fid --cable=USB-BlasterII --index "@1=svgx.sof#pi" --weight=100.0.0 --smh="@1=svgx.smh#2" --number=30
- Programs the device and injects faults (pi string)
- Injects 100% single-bit faults (100.0.0)
- Injects only into ASD_REGION 2 (indicated by the #2)
- Injects 30 faults
2.4. Document Revision History
Date |
Version |
Changes |
---|---|---|
2018.09.24 | 18.1.0 |
|
2015.11.02 | 15.1.0 | Changed instances of Quartus II to Intel® Quartus® Prime . |
2015.05.04 |
15.0.0 |
|
2014.06.30 |
14.0.0 |
|
December 2012 |
2012.12.01 |
Preliminary release. |