Verilog is an HDL (hardware description language). The other common HDL is VHDL. These languages are used to design and verify digital circuits. The topic of today’s talk is to explore whether these HDL are software in the sense of IEC 61508-3, ISO 26262-6 or D0-178C. If you decide that Verilog and VHDL is software then you should base your digital designs on the software requirements from these parts of the standards rather than on IEC 61508-2, ISO 26262-5 and D0254.
Firstly, some background, Verilog is standardized as IEEE 1364 and VHDL as IEEE 1076. The Verilog standard has been around since 2005. It seems like Verilog has been here forever, but I do remember people designing digital for analog to digital converters using schematics back in the 1980s. The VHDL syntax is based on ADA, is standardized as IEEE 1076-2008 and was adopted by the IEC as IEC 61691-1-1:2011. Hereafter when I talk of Verilog, I generally just mean either Verilog or VHDL.
Whichever of the HDL you use the language is synthesized to implement the circuit using lower level gates from a digital cell library containing basic elements such as AND gates, OR gates, NAND gates, flip-flops and latches. Not all Verilog is synthesizable and such non-synthesizable Verilog can be useful to build high level models of other elements of your design and to implement test benches. The figure below shows the path from requirements to a final hardware implementation on silicon.
Figure 1 - a path from requirements to a final design on hardware
A sample of Verilog code taken from Wikipedia is shown below. You must admit it looks very much like software. If we didn’t care about it being synthesizable, we could add while loops etc and make it look even more like C.
Figure 2 - A sample of Verilog code from Wikipedia
IEC 61508 gives V models for a software and hardware design and they look very similar.
Figure 3 - V models for software and an ASIC from IEC 61508:2010
At this point I think everyone must at least admit that the question “Is Verilog software?” is debatable and I for one would be happy to take either side in such a debate. Some would say that if something walks like a duck and quacks like a duck then it is a duck so that Verilog is software for that reason alone.
Figure 4 - the topic captured by Leo Cullum of the New Yorker
Let’s pretend this is like a jury trial. Let’s look at the evidence and you the jury can have your say.
First to present for the defense is D0-254 the avionics hardware standard. In section 5 it states “HDL design representations use coded text-based techniques that are similar in appearance to those used for software representations. This similarity in appearance can mislead one to attempt to use software verification methods directly on the design representation of HDL or other equivalent languages. The HDL guidance of this document is applicable for design assurance for designs using an HDL representation”. I’m not sure where I read it but another quote, I like is that “software is something that runs on hardware” and that Verilog is only a model of hardware. One good difference between Verilog and hardware is that in Verilog you can model things that happen in parallel but with software things happen serially, and things happening in parallel is just an illusion. But I guess you could argue that software can run in parallel if you get a multi-core processor.
The very smart people from NASA are next to present for the defense. In their complex electronic hardware handbook 4.1.1 they state “complex electronics, such as FPGAs and ASICs, are not firmware because what resides in them is not a software program. Instead, software is used to define the logic structure for a hardware device, which is what these devices become once they are configured” and they double down on this in sub-clause 4.1.2.
Our automotive colleagues who wrote ISO 26262:2018 are more measured in their approach but still say...
Figure 5 - Extract from the software part of ISO 26262
The Australian defense is even more measured, in section 2.3.4 of Australian defense standard 5679:2009 stating “The development of other computer-based components such as programmable hardware and ASICs also involves design processes of a similar complexity to that of software, and this similar levels of rigor need to be applied during development”.
It’s always worth knowing what your external assessors think. Exida in their book “Functional safety – An IEC 61508 SIL 3 Compliant development process” state in C.2 that “A key concept must be kept in mind while writing HDL; it looks like software but is it not. It is really a description/specification of the behaviour of hardware circuits from which the synthesis tool will deduce the required hardware design (layout and interconnections of the required logic gates)." The reference to layout is an interesting difference between hardware produced by Verilog and software. Software has no obvious equivalent of layout.
I don’t know where the quote came from, but I recorded it “You don’t program with Verilog you design with it”.
Wow, the defense arguments seem pretty persuasive but let’s wait for the prosecution arguments before jumping to a decision.
Evidence for the prosecution includes IEC 61496-1:2012 (human presence sensing for industrial standard) 18.104.22.168 which lumps ASIC and FPGA based designs into the same bin and looks for IEC 61508-3 with “shall be developed in accordance with IEC 61508-3”.
Figure 6 - An extract from IEC 61496-1:2012
While NASA might not believe Verilog is software the US military appears to do so.
Whatever your views if you follow IEC 61508 the detailed design techniques for an ASIC are given in IEC 61508-2:2010 Annex F. Currently this Annex is informative, but it is planned that it will be normative in future. Table F.1 lists all the things that an ASIC designer must do rated by SIL. Table F.2 gives the requirements for someone who buys an FPGA and implements their logic in the FPGA i.e. Table F.1 applies to ADI, Xilinx etc but F.2 applies to Xilinx’s customers. A sample from table F.1 is given below.
Figure 8 An extract from IEC 61508-2:2010 Table F.1
You will note it has requirements related to coding standards, code checkers, modularization which are all things which will be very familiar to software professionals.
Previously IEC 61508 Annex F guidance on software tools was to use tools which were proven in use whereas tools used to produce software had to be rated at T1, T2 and T3 as per IEC 61508-3:2010 7.4.4. The latest drafts of IEC 61508:202X will clarify that the software offline tool runs applying to those tools used to produce hardware and software.
Stuff such as configuration management, requirements management, competence management and change management are not included in the above. The fact that these all apply if developing to IEC 61508-2 is covered in a recent blog entitled “Can designers really ignore part 1 of IEC 61508”. But if you are too busy to read that then it is clear that Annex F is referred to from IEC 61508-2:2010 22.214.171.124 and therefore there is nothing to say that the rest of IEC 61508-1 and IEC 61508-2 doesn’t apply. Indeed, you also have IEC 61508-2 7.1.3 and figure 3 showing requirements, verification and validation. In summary Annex F tailors some of the requirements from parts 1, 2 and even part 3 for a digital design. Going forward it is planned to modify Annex F to include requirements for Analog, Mixed signal and sensors and to make Annex F normative. ISO 26262 has already expanded to cover non-digital designs with their version of the Annex F tables.
Of course, anywhere there is room for manoeuvre, people will try to take advantage of it. For instance, I must not be alone in thinking that compliance to the avionics hardware standard D0-254 is easier than compliance to its software equivalent. Guess what? You are never really alone.
Figure 9 - Extract from the paper "D0-178C Benefits vs costs"
The defense and prosecution rest. What say you, jury?
Based on the above I don’t know what you the reader thinks but my advice is that Verilog is not software and should be developed to IEC 61508-2 but if in any doubt the guidance available in IEC 61508-3 won’t steer you too far wrong. You could still use the tables in Annex A, B and C of part 3 in particular to guide you. In fact, you could view the part 2 Annex F guidance as being IEC 61508-3 tailored for a digital design and then the conflict more or less disappears because you need to do the same things either way; or a version of the same things at least.
Not considered here but perhaps it will be the topic of a future blog is whether IEC 61508-2:2010 Annex F compliance on its own has value.
Hopefully you found this blog useful and thought provoking. I have intended to write this one since Christmas at least, but never got the time to do it properly until now. I could have waited longer and been a bit more thorough but this is a blog as opposed to an academic paper and since perfection is the enemy of good enough, here is the blog.
Note 1 - Our software colleagues have recently (2016) tightened up on the reuses of software. IEC TS 61508-3-1 is route 2S for software (ignore the title which indicates route 3S). It limits the use of route 2S to SIL 1 and SIL 2 and imposes additional requirements. However, some of these are related to the fact that software runs on hardware and Verilog is a description of the hardware.
Note 2 – system Verilog is an expansion of the traditional Verilog.
Some additional material related to designing safety circuits with HDL
When the Verilog or VHDL is being implemented on an FPGA as opposed to on an ASIC you definitely move a lot closer again to it being software. For instance the code in an FGPA can be modified almost as easily as software in a uC/DSP. Whereas if the HDL is being used to implement an ASIC it could take 3 months to make a change. The time lag with an ASIC forces a different set of behaviors. Also with an FGPA it is not entirely wrong to say that the HDL is "running" on the FPGA or that it is data driven device. Similarly you have to consider soft/transient errors in an FPGA that you might not have to consider with an ASIC. With an FPGA you probably have unused hardware but with an ASIC since you really are defining the hardware you get just the hardware you need. Within IEC 61508-2:2010 Annex F table F.1 gives detailed design measures for the FGPA companies and F.2 for the FPGA user. Many are the same but some are not. A previous blog on FPGA is available at https://ez.analog.com/b/engineerzone-spotlight/posts/nothing-is-perfect-but-an-fpga-can-be-very-useful
As an avionics designer who does DO254 all the time and how it intersects with DO178C all the time, I'm witness to the FAA having a very strong feeling about this :). There are two aspects to the question, what is the output of the design process, and how that process is performed in itself.
First, the fundamental difference in HDL vs SW is essential: the output of an HDL flow is a configuration file for connecting and initializing components within a defined matrix of components, whereas the output of a SW flow is a series of sequential instructions for a particular architecture. The effort needed to compile an ARM software "app" for multiple devices from multiple vendors is much smaller than building a new config file for two Xilinx parts, sometimes even within the same family, because of the essential difference of those operations. And there's a qualitative aspect: you can write SW and execute it on an HDL model being simulated on SW, but I don't see if the reverse is either possible or interesting. Like you said, the HDL describes the machine, the SW describes what you do with the machine.
The second aspect, process, is what creates this confusion, since the two processes are fairly compatible--and if you look at DO254 vs DO178C, the processes are parallel to the point of being almost interchangeable (if you look at requirements at the right level). But that is because HDL and SW are both coded text files that are "compiled" into something. I guess the more appropriate analogy would be: HDL and SW are more movie-vs-novel, not movie-vs-play. Even if the sources are managed in the same way, the outputs behave so differently that trying to treat them the same overall will not yield a safe system.