Code Coverage in VHDL and Verilog for Medical Devices

J

jmalm

Does anyone know if code coverage for VHDL/Verilog is widely used in medical device hardware/software design? Would regulating bodies be looking for it like they would for, say, code written in C or other processor-based programming languages?
 

Stijloor

Leader
Super Moderator
Does anyone know if code coverage for VHDL/Verilog is widely used in medical device hardware/software design? Would regulating bodies be looking for it like they would for, say, code written in C or other processor-based programming languages?

Can someone help?

Thank you!

Stijloor.
 
Last edited:

sagai

Quite Involved in Discussions
Hi,
as far as I know VHDL/Verilog used for embedded SWs, there is no restriction what language you use in the course of the design and development of the medical device.
br
Sz.
 
Last edited:
J

jmalm

Thanks, Sagai. My question is more surrounding "code coverage tools" of VHDL/Verilog, and whether, say, the FDA would insist on running a code coverage tool on VHDL/Verilog code.
 

yodon

Leader
Super Moderator
Insist? No, probably not. I'm not aware of anything in the regs that REQUIRE code coverage analysis.

As part of V&V, though, you make a much stronger case if you do show test coverage.
 
Last edited:

glork98

Involved In Discussions
Insist? No, probably not. I'm not aware of anything in the regs that REQUIRE code coverage analysis.

I concur that there is no mandate to show code coverage in either unit testing or verification testing.

That FPGA development has converted much hardware into software is a good thing technically and is a development that the regulatory bodies haven't clearly responded to. You'd think the VHDL would be identified as a software component explicitly.

Aside:

There are metrics suggested on code test coverage in the 80% range. That is, 80% of all source lines are traversed in the tests. My opinion is that this in unrealistic and leads to writing software that will give good numbers and not good software in the first place. The primary source of this is in error handling. Some engineers ("crappy") insist that there is no reason to have error codes or test those that are returned as the called software should be perfect. Having error codes on each function and testing them bulks up the code substantially on a SLOC basis and makes it hard to get a high test coverage number as each call needs to "fail" at a specific line. Very hard to do.

On one project we were given that mandate. I responded by having an engineer analyze how the SLOC count (Source Lines of Code) was determined and how best to write code to still allow thorough error reporting and handling without damaging the metrics. He came up with a system inside C++ of using macros and throw/catch that produced a smaller count of error handling lines and, as "catch" can group these for multiple function calls, we could expect to traverse those lines. This drove up our metric without needing to perform more detailed and difficult testing. I dislike throw/catch as it can be used ignorantly but we needed to get good numbers. And so it goes...
 
Last edited:

sagai

Quite Involved in Discussions
Thanks, Sagai. My question is more surrounding "code coverage tools" of VHDL/Verilog, and whether, say, the FDA would insist on running a code coverage tool on VHDL/Verilog code.
Well, 1oo% agree with yodon and glork. There is no such requirement, actually we also have a similar tool developed inhouse, I have just excluded from validation :tg:
br
Sz.
 

Peter Selvey

Leader
Super Moderator
This question came up in a seminar last week and we also concluded (as with other posters) that VHDL does not fall under IEC 62304, as the software is not in the medical device itself.

In case the auditors don't agree, try the consistency argument: if VHDL must be compliant with IEC 62304 then any software used in the design of a medical device would have to be treated the same. Stupid example: I use excel sheet to calculate non-linear compensation equations for putting in the device software. Does the excel sheet fall under IEC 62304?
 

sagai

Quite Involved in Discussions
However I am not 1oo percent sure what the non linear compensation really considers to, in case the result of the excel sheet is the one you put without any verification/validation into the medical device, I am tend to consider it does a soup and subject to IEC62304.
 

Peter Selvey

Leader
Super Moderator
Maybe poor example.

The excel sheet and related software is not in the medical device.

I just use the algorithms stored in the excel sheet to calculate parameters which are then later put into the medical device software for non-linear compensation.

If we consider VHDL as needing IEC 62304, we should also consider the excel sheet and other cases of software used in the design process.

But, in both cases the software is not in the medical device, so IEC 62304 does not apply. Of course, I still need to validate the results!
 
Top Bottom