Software validation for FPGA

[pseudoazurin]

Morning,

I heard there is some unclear about software validation for system that use FPGA. I don't know the general opinion on that, and what would be the implication if manufacturers use multiple MCUs and CPLDs instead of FPGA?

Thx,

 

[Tidge]

My experience has been that is is typically the case that an FPGA is programmed to behave as a specific device (that is, the FPGA isn't "executing code" like a processor), and so aside from exercising revision control (i.e. configuration management) over what is 'installed' in an FPGA as well as the physical part, the programmed FPGA can be evaluated like any other component... that is: does the device behave as required/expected?

If the FPGA is going to act more like a processor, then perhaps a more detailed assessment of how well that code meets its intended use is required.

There are subtleties within different industries, of course.

 

[v9991]

Computer Software Assurance for Production and Quality System Software
looking back, here's summary with a pinch of GPT
in one of the client interviews; the interaction / interview included if i had worked/experienced with the CSA ( already )

#	Theme	Expectation / Pre-Publication Narrative	Final Guidance Reality	Remarks	Status
1	Risk-based critical thinking approach	Industry expected a revolutionary shift away from rigid, script-based validation, toward risk-based thinking and flexibility.	Risk-based thinking is central to the guidance — it encourages "assurance activities commensurate with risk."	This was the most anticipated aspect, and it was largely delivered as promised.
2	Replacement of legacy CSV mindset	Strong belief that CSA would replace traditional Computer System Validation (CSV) with a more modern framework — including agile, continuous, and real-time validation.	CSV isn't fully discarded. The FDA still emphasizes maintaining documentation and controls. CSA adds nuance to CSV but doesn't replace it wholesale.	This was partially met — CSA refines CSV rather than retiring it. Old habits may persist without stronger language.
3	Reduced documentation burden	Widespread expectation that documentation would be significantly reduced, and real-world data/logs would suffice in many cases.	Documentation is still required, though more flexibility is allowed in choosing the format (e.g., logs, screenshots, audit trails). However, no clear threshold is provided.	The final guidance supports smarter documentation, but leaves ambiguity — conservative organizations may revert to excessive paperwork.
4	Explicit allowance of vendor documentation	Hopes were high that vendors’ own test results and certifications would be accepted without revalidation by the manufacturer.	Vendor evidence is mentioned in context but not strongly emphasized or formalized. Manufacturers are still responsible for assurance.	Disappointing to many: no clear directive to accept vendor testing without duplication. Trust-but-verify model remains.
5	Encouragement of unscripted testing	Thought leaders promoted use of unscripted and exploratory testing, with real-world scenarios instead of rigid test cases.	The guidance mentions various testing methods (including unscripted) but stops short of strongly endorsing them.	This is allowed but not championed. Many QA teams may lack confidence without explicit regulatory support.
6	Functional-level risk assessment	Hoped for a feature/function-based risk assessment — i.e., validate only the features that impact product quality or patient safety.	The document refers to "intended use" and "where risk warrants additional rigor", but does not mandate or outline a feature-level risk stratification model.	The concept is acknowledged, but no strong framework is provided — risk stratification remains abstract.
7	Formal withdrawal or replacement of legacy guidance	Assumed CSA would replace or nullify outdated CSV guidance, such as the 2002 “General Principles of Software Validation” (GPSV).	The guidance only supersedes Section 6 of the GPSV — not the whole document. The rest still applies.	A major missed opportunity: legacy guidance remains in force, creating confusion and mixed compliance expectations.
8	More explicit handling of SaaS / Cloud systems	Industry expected clarity on how to validate modern SaaS/cloud tools, especially in an agile release model.	The guidance mentions modern software practices, but does not specifically address SaaS, DevOps, or CI/CD pipelines.	Important modern software models are left ambiguous — creating gaps in implementation.
9	Agile and iterative lifecycle models	Advocates hoped CSA would explicitly support agile, iterative validation and DevOps alignment.	Final guidance supports flexibility and continuous assurance in spirit, but doesn’t explicitly mention agile or modern SDLCs.	Partial alignment — it’s implied, but not strong enough to drive cultural change without organizational will.
10	Case studies and detailed examples	Industry hoped for rich examples, case studies, or templates to aid implementation across system types.	Guidance includes limited examples, but mostly generic; lacks detailed case studies or role-specific illustrations.	Missed opportunity — more prescriptive examples could help conservative teams take action.

 

[Tidge]

Please tell me more about how FPGAs are used in your quality system software.