Why FPGAs in medical devices are increasingly becoming the focus of software audits and how you can avoid regulatory risks early on.
When programmable logic suddenly ends up in a software audit, things can quickly become uncomfortable when the auditor asks you: "Where is your IEC 62304 documentation for the FPGA?"„
MedTech teams are hearing this sentence more and more frequently, often surprisingly late in the project or even during the audit. The first reaction is usually:
„"That's hardware."“
„"No code is running."“
„"The FPGA is not updatable."“
And from a technical point of view, that's absolutely correct. Nevertheless, this is precisely where protracted discussions regularly arise in medical technology projects: Is an FPGA software or not?
An FPGA (Field Programmable Gate Array) is a programmable logic device that can flexibly implement digital circuits in hardware. Unlike traditional microcontrollers or processors, an FPGA does not work with sequentially executed software code, but rather with parallel logic. This makes FPGAs particularly suitable for applications requiring high speed, low latency, and deterministic real-time behavior.
In medical technology, FPGAs are frequently used for safety-critical functions, signal processing, monitoring logic, or high-speed data processing. Typical applications include imaging systems, patient monitoring, diagnostic devices, and control systems with high real-time requirements.
Since FPGAs can take over complex decisions and safety-relevant functions, they are increasingly coming into focus from a regulatory perspective – especially through IEC 62304 and the software assessment of medical devices.
Goran Madzar
Systems Engineer & CEO @MEdtech Engineer
Why FPGAs are becoming regulatoryly relevant in medical technology
FPGAs, CPLDs and other programmable logic devices are specifically used in modern medical products where high performance, deterministic real-time behavior and complex logical decisions are required.
Typical reasons for the use of FPGAs/PLDs in medical technology include:
- High performance and low latency
- true parallel processing
- deterministic real-time behavior
- complex logical decisions
- State Machines
- Monitoring and plausibility logic
- Time-critical signal processing
- Filter, trigger, encoding/decoding
- architectural separation
- independent safety layer
- Firmware monitoring
- determinism
- no scheduling
- no interrupt cascades
- no operating system
These very characteristics make FPGAs attractive for safety-critical functions – and this is the real reason why they are attracting regulatory attention. IEC 62304, FDA guidance, and notified bodies focus less on the technology used and more on the systematic function that an element performs within the overall system. The focus is not on how something is implemented, but on what it does. And as soon as this function is "software-like," IEC 62304 inevitably comes into play.
FPGA and IEC 62304: Engineer's View vs. Auditor's View
From a development perspective, the situation is usually clear:
- The FPGA is programmed only once.
- It is not reconfigurable in the field
- It behaves deterministically, like hard-wired logic.
- VHDL/Verilog describes structure, not process control
- There is no processor, no instructions, no operating system.
All these points are technically correct and important. However, the regulatory perspective focuses on something else. It doesn't ask about the programming language, but rather about responsibility within the system.
- Does the FPGA make decisions?
- Is he evaluating states or limits?
- Does it trigger any security-related actions?
If the answer „"Yes"“ The FPGA inevitably ends up in the software discussion, regardless of whether it is described with C code or HDL.
When an FPGA is considered software
In practice, critical discussion usually arises when the FPGA:
- Safety-relevant limit values are monitored.
- Conditions assessed or classified
- triggers shutdowns or emergency stop signals
- independent of the firmware, decisions are made
The fact that the FPGA is programmed in VHDL and not in C is irrelevant. The more safety-relevant logic is moved to the FPGA, the more auditors and authorities expect a structured, traceable development and documentation strategy.
Practical application: IEC 62304 documentation for FPGA projects
Several clear lessons can be drawn for practical application:
- The FPGA should be integrated into the project early on.
- Architectural decisions must be clearly documented.
- The risk argumentation must not be a retrospective „audit fix“.
- Standards should be used as tools, not as straitjackets.
Taking these points into account significantly reduces the documentation effort and avoids unpleasant surprises during the audit or shortly before approval.
FPGA gap analysis for regulatory safety
When an FPGA takes on safety-relevant functions, the question quickly arises as to how it can be meaningfully and audit-proof integrated into the IEC 62304 documentation – without unnecessary overhead, but with regulatory certainty.
A proven first step is an IEC 62304 gap analysis to:
- to clearly define the role of the FPGA in the system
- To evaluate relevant standard requirements in a structured manner
- Identifying documentation gaps early
- to realistically estimate the actual effort required
You can find more information on this topic on our IEC-62304 Gap Analysis page: