Addressing safety
critical FPGA designs
Advanced EDA tools and methodology is helping designers
to avoid synthesis bugs in safety-critical FPGA designs, as
Rob van Blommestein explains
F ield-programmable gate
arrays (FPGAs) are the
dominant hardware platform
in many safety-critical, low-volume
applications, including aerospace and
nuclear power plants (NPPs).
Modern FPGA devices feature
integrated microprocessor cores,
digital signal processing (DSP)
units, memory blocks and other
specialised intellectual properties
(IPs) and these advanced devices
allow for the implementation of large,
high-performance system-on-chip
(SoC) designs with integrated safety
mechanisms, making a strong case
for adoption in additional safetycritical
applications traditionally
dominated by application-specic
integrated circuits (ASICs).
From a high-level perspective, the
FPGA and ASIC development ows are
similar. Register-transfer level (RTL)
coding and integration of third-party
intellectual properties (IPs) are crucial
steps in the front-end part of the ow.
Extensive functional verication of the
RTL design model reduces the risk of
mismatches between requirements
and RTL behaviour. At this stage,
specication, coding, and module
integration mistakes are the main
source of systematic faults that, if
undetected, could lead to dangerous
failures of the FPGA device in the eld.
The RTL model then goes through
several implementation steps (see
Figure.1). Synthesis and place-androute
tools map the design onto the
target FPGA device. The bitstream
generation step produces the le
used to program the FPGA. Functional
behaviour of the corresponding
netlist in the presence of unknown,
or X, values. Consequently, while the
synthesis tool operates correctly, its
generated netlist may still not match
the intended RTL behaviour.
Requirement-based testing does
not explicitly target these type of
corner cases, which can therefore be
missed. RTL linting tools may warn
about these scenarios. However, they
provide neither a denite answer nor
a simulation trace that shows how
the bad scenarios may occur.
Desired functionality
FPGA implementation tools must
t the desired functionality into a
prefabricated structure while meeting
performance and power consumption
goals. Implementation tools perform
signicant changes to the original
logic structure of the design to
improve device utilization and overall
quality of results (QoR). Advanced
optimisations pose a higher risk of
corrupting the RTL functionality.
Certain FPGA synthesis tools
support the automatic insertion of
hardware safety mechanisms. Safety
mechanisms shall not change the
design functionality when no fault is
present. In the event of a random
hardware fault occurring during eld
operation, they need to raise an
alarm and potentially correct the
effects of the fault on the y.
Synthesis tools may transform
the encoding of nite state machines
(FSMs), for example to include
Hamming-based error detection and
correction. Triple modular redundancy
(TMR) is another type of safety
mechanism where a critical logic
function is triplicated and voting logic
added to determine which of the
three outputs should be considered
as correct. Logic duplication and
inference of memories with error
correcting codes (ECC) may also be
supported. Users certainly benet
signicantly from these design
enhancements that can be performed
automatically by the synthesis tool.
verication of implementation steps
reduces the risk of mismatches
between the derived netlists and the
RTL design model. This is crucial
to close the loop and ensure that
the functionality implemented in the
FPGA device matches the hardware
requirements.
Functional bugs can be introduced
during implementation steps, either
because of RTL issues that cannot be
detected during synthesis, or because
of malfunctions in implementation
tools, particularly synthesis and placeand
route, corrupting the original RTL
functionality. While engineers may
expect that implementation tools
have been extensively tested prior to
release, each design and coding style
are unique and may trigger unknown
corner cases.
Regardless of the implementation
tool used, there are coding issues
that may go undetected during
RTL verication and creep into the
synthesis netlist. In some corner
case scenarios, RTL simulation
behaviour may not match the
Figure 1: The FPGA
development flow
Author details:
Rob van
Blommestein,
Vice President
of Marketing,
OneSpin
Solutions.
20 9 March 2021 www.newelectronics.co.uk
/www.newelectronics.co.uk