Replacing Logic with an FPGA/CPLD in a 510K device.

[hamilton]

Does anyone have some good links on FDA requirements for replacing TTL
logic with an FPGA/CPLD ?

This is for a Class 3 device.

Does the FPGA/CPLD design files constitute "firmware" and needs to be
tested the same way as firmware ?

Thank you

hamilton

 

[Gabor]

On 9/27/2012 5:26 PM, hamilton wrote:

Does anyone have some good links on FDA requirements for replacing TTL
logic with an FPGA/CPLD ?

This is for a Class 3 device.

Does the FPGA/CPLD design files constitute "firmware" and needs to be
tested the same way as firmware ?

Thank you

hamilton

I'm not sure if you've seen this, but Mentor has a white paper
here:

http://www.mentor.com/products/fpga/resources/overview/best-practice-development-processes-for-medical-device-fpgas-ec7f7922-2326-48e2-a8ea-626ab0804b0f

http://www.mentor.com/resources/techpubs/upload/mentorpaper_68961.pdf

It talks about a lack of specific standards in the hardware development
process, and how to go about ensuring quality using techniques borrowed
from other hi-rel fields like aerospace. It no doubt recommends an
approach that requires plenty of their verification tools...

-- Gabor

 

[Brian Drummond]

On Thu, 27 Sep 2012 21:59:34 -0400, Gabor wrote:

On 9/27/2012 5:26 PM, hamilton wrote:
Does anyone have some good links on FDA requirements for replacing TTL
logic with an FPGA/CPLD ?

This is for a Class 3 device.

Does the FPGA/CPLD design files constitute "firmware" and needs to be
tested the same way as firmware ?

http://www.mentor.com/resources/techpubs/upload/mentorpaper_68961.pdf

It talks about a lack of specific standards in the hardware development
process, and how to go about ensuring quality using techniques borrowed
from other hi-rel fields like aerospace. It no doubt recommends an
approach that requires plenty of their verification tools...

-- Gabor

My first thought was DO-254, and I'm glad to see the paper discusses it.
Only 2 pages focus on how many of Mentor's expensive tools you need ;-)

But I think her case that it is radically different from software best
practice is weak; in particular, formal methods and parallelism are also
a concern in software best practice, hence tools like SPARK and the
Ravenscar profile.

In contrast, I believe DO-254 is actually a development of the DO-178
process for software (which the paper doesn't even mention), and the two
have a lot in common.
http://www.atego.com/services/training-course/avionics-certification/
covers both in a single course.

http://www.open-do.org/ has quite a lot of information and open tools on
the software side of best practice.
http://www.open-do.org/projects/hi-lite/
http://www.open-do.org/projects/geneautoada/
the latter covering model-based design, e.g. in Simulink.

It is also interesting how much in common there is between the
synthesisable subset of VHDL, and the SPARK subset of Ada. Apparently the
transformations between RTL and gates(or LUTs,FFs) and between software
and proof conditions have a lot of the same limitations (e.g. no dynamic
allocation...)

It may not be the case that FDA accept DO178 or DO254 wholesale, but it
is likely that following these approaches would make for a good safety
case and simplify the approval process.

In short, if you meant "can FPGA firmware be tested the same way as
typical embedded C code", ... errr, no.

But if you meant "... following software best practice, like SPARK or
DO-178b," you would be a long way towards the goal.

- Brian