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
Replacing Logic with an FPGA/CPLD in a 510K device.
Started by ●September 27, 2012
Reply by ●September 27, 20122012-09-27
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 > > hamiltonI'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
Reply by ●September 28, 20122012-09-28
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... > > -- GaborMy 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
