Avionics certification, and why an FPGA is an advantage?

[peter-h]

Does anyone here work in this field?

When I look at some internals, I see some bizzarre stuff e.g. an FPGA being used to implement a really trivial function which would normally be done by a tiny CPU.

I've also heard that the certification authority has been known to require a file for each function, otherwise recertifying changes is much harder.

This is from a 2004 aircraft intercom where an FPGA is completely ridiculous and always was



Admittedly in those days FPGAs were high fashion I did a lot of FPGA work back then so know how it works.

One thing I've heard is that just different standards are applicable. It may be easier to prove deterministicity and isochronicity on an FPGA.

For sure getting something big built around an RTOS is going to be much much harder.

[SiliconWizard]

The general issue in safety-critical devices is that software is almost invariably considered the hardest to validate, and for (usually) good reasons.
So, that's mainly it. Validation.
Programmable logic such as FPGAs is still not considered software so you avoid a whole lot of troubles and standards to comply with. And yes, it's also much easier in practice to prove correctness.

[Tation]

HDL code inside FPGAs is subject to validation under DO254. Not really knowing if this is more or less cumbersome than software validation, but still not a picnic.

[peter-h]

I did some digging, and apparently certifying FPGA hardware via DO-254 can be more straightforward than certifying software via DO-178C which is what software needs.

But it must surely depend on what the item does.

I just don't buy why there is a difference, given that you can have the same bugs in HDL code. Unless it is totally trivial but then you can have a tiny AVR etc with the same 100 lines of code.

[jbb]

Wild ass guess:
- if the implementation was designed to be easy to certify, then it could be an all logic design
- no stack to run out
- no pointers to go bad
- no chance of a (software) task not getting enough priority to run
- moderately easy to predict / constrain latency
- easy to implement timeouts with confidence

That being said, someone could indeed make a  very complex FPGA design which would be hard to certify

[Psi]

The general issue in safety-critical devices is that software is almost invariably considered the hardest to validate, and for (usually) good reasons.
So, that's mainly it. Validation.
Programmable logic such as FPGAs is still not considered software so you avoid a whole lot of troubles and standards to comply with. And yes, it's also much easier in practice to prove correctness.

heh, that partly explains the cost of aviation electronics.

[peter-h]

- if the implementation was designed to be easy to certify, then it could be an all logic design
- no stack to run out
- no pointers to go bad
- no chance of a (software) task not getting enough priority to run
- moderately easy to predict / constrain latency
- easy to implement timeouts with confidence

However, you could do all of those in a CPU also.

In c. 1980 I was doing code for a Z80 design where the RAM interface was bodged and only M1 accesses (opcode fetches) enabled the RAM. So the whole thing had to be written so only single byte instructions could access the RAM e.g.
ld a, (hl)
ld (hl), a
So there was no stack, either. No need for a stack for simple stuff.

[jbb]

True… but I suspect that approach would cause its own troubles. The certification people might charge more for reviewing the assembler, for instance

[BrianHG]

It is most likely that the intercom was originally an existing design with all TTL logic and the goal was just to perfectly replicate and shrink the existing approved design to a single IC with an additional degree of room for correction logic if needed.

The Altera Flex is a small FPGA and that early Quartus compiler had a GUI IDE with all the 74LSxxx components built into its layout library.  All the engineer had to do was copy the schematic exactly and the compiler would spit out a FPGA matching the schematic function perfectly.

[Psi]

It is most likely that the intercom was originally an existing design with all TTL logic and the goal was just to perfectly replicate and shrink the existing approved design to a single IC with an additional degree of room for correction logic if needed.

The Altera Flex is a small FPGA and that early Quartus compiler had a GUI IDE with all the 74LSxxx components built into its layout library.  All the engineer had to do was copy the schematic exactly and the compiler would spit out a FPGA matching the schematic function perfectly.

That does sound like a more reasonable explanation

[peter-h]

Yes that makes sense.

It is a bit of a sleight of hand job because obviously the design has been changed, but certification is a box ticking exercise and if you tick the right boxes you comply! You don’t get a bonus for exceeding the requirements You can say the circuit diagram is the same. Also nobody will question what Garmin does anyway.

Yes the old Xilinx / Viewlogic 4/LCA stuff also had TTL libraries.

You will eventually get trouble with availability which you would not have with "TTL". For example the EPF8452AQC160-4 or the EPC1064 config chip are no longer available.

Someone else also suggested easier formal verification.

[brucehoult]

It is most likely that the intercom was originally an existing design with all TTL logic and the goal was just to perfectly replicate and shrink the existing approved design to a single IC with an additional degree of room for correction logic if needed.

The Altera Flex is a small FPGA and that early Quartus compiler had a GUI IDE with all the 74LSxxx components built into its layout library.  All the engineer had to do was copy the schematic exactly and the compiler would spit out a FPGA matching the schematic function perfectly.

If you're allowed to use software that takes a GUI schematic of 74xx chips and turns that into Verilog then why are you not allowed to use software that takes the same GUI schematic and turns it into C code with one big loop (after setup) and inside that loop straight line no if/then/else, no loops, no malloc() code that implements the boolean logic?

[brucehoult]

For that matter, if outputting Verilog is ok then you could hit that with Verilator to turn it into C.

[nctnico]

It is most likely that the intercom was originally an existing design with all TTL logic and the goal was just to perfectly replicate and shrink the existing approved design to a single IC with an additional degree of room for correction logic if needed.

The Altera Flex is a small FPGA and that early Quartus compiler had a GUI IDE with all the 74LSxxx components built into its layout library.  All the engineer had to do was copy the schematic exactly and the compiler would spit out a FPGA matching the schematic function perfectly.

If you're allowed to use software that takes a GUI schematic of 74xx chips and turns that into Verilog then why are you not allowed to use software that takes the same GUI schematic and turns it into C code with one big loop (after setup) and inside that loop straight line no if/then/else, no loops, no malloc() code that implements the boolean logic?

But you'd still need to prove you adhere to coding standards which might be more involved compared to qualifiying hardware. In addition, implementing something in software in a high reliability environment typically means you want to monitor whether the software is still running and if not, bring the system to a safe state. The latter means having extra hardware. So in the end using an FPGA can make sense just to minimise the number of chips needed.

[Fire Doger]

An other wild guess is that avionics are also exposed to higher radiation.
FPGAs might be more robust.
Also its easier to make parallel implementation of same functionality and compare that both units agree, so any drift for whatever reason is detectable.
And if you have a bunch of engineers with high expertise in fpga, stock and contracts with manufacturer, why to bother using anything else? Using an avr or stm32 looks like more unnecessary risk than benefit for these companies...

[Tation]

Using TTL libraries may be not as acceptable as expected in the most demanding DAL levels. You need to prove inexistence of unused logic, so things like, say, the /LT input of a 7447 permanently tied to Vcc, which is clearly a sign of unused logic, can be problematic.

Only if the design is simple enough to fit in the DO254 category of "simple hardware", then its certification will be easy (or better, not that complex). Being the circuit that simple, it may be reasonable to draw its gates+FFs schematic, but if it is not that simple, well, you will need HDL anyway.

[Tation]

It is most likely that the intercom was originally an existing design with all TTL logic and the goal was just to perfectly replicate and shrink the existing approved design to a single IC with an additional degree of room for correction logic if needed.

The Altera Flex is a small FPGA and that early Quartus compiler had a GUI IDE with all the 74LSxxx components built into its layout library.  All the engineer had to do was copy the schematic exactly and the compiler would spit out a FPGA matching the schematic function perfectly.

If you're allowed to use software that takes a GUI schematic of 74xx chips and turns that into Verilog then why are you not allowed to use software that takes the same GUI schematic and turns it into C code with one big loop (after setup) and inside that loop straight line no if/then/else, no loops, no malloc() code that implements the boolean logic?

You can get the path you want, provided that you can prove that the final circuit in the PCB behaves as stated in the design spec. If you get Verilog from a schematic (and the design requirements are traceable to and fro such schematic), you need to prove that the conversion worked properly. To achieve this you can certificate also the library and the tool or, more simple, certificate instead the resulting HDL by tracing the requirements directly to and fro such HDL.

[iMo]

And what certification I need when I would run a 32bit cpu inside the FPGA (with tons of special peripherals, MMU, FPU, DMA, etc.)??

[BrianHG]

Its more like if you need to guarantee the new FPGA based device can be a drop-in replacement of the old discrete logic design, as avionics intercom may have multiple in and out routing priority for who gets to talk over who, the schematic capture method leaves little room for deviation of function and timing.

By no means does this mean you cannot render proper HDL or MCU code an equivalent.  But, when a lot of the discrete TTL logic series is being retired and unobtainable and the order from above is to replicate the old circuit, no deviation.  I would imagine doing it this FPGA way as price per device is not a concern with avionics instrumentation, but you better believe engineering time, testing and approvals is a concern.

[Tation]

And what certification I need when I would run a 32bit cpu inside the FPGA (with tons of special peripherals, MMU, FPU, DMA, etc.)??

If the core and periphs can be treated as COTS  IPs, rely on history usage. If not, bad news, you need full specs of the desired MCU, list of requirements and all DO254 machinery applied over them. In both cases, firmware will need DO178.

[peter-h]

It won't be radiation. This is a GMA340 GA (general aviation) product, probably max certification altitude 20,000ft.

The function is an audio panel (an intercom in unfashionable terminology) which has a load of inputs e.g. mikes, line level inputs, loads of outputs e.g. headset speakers, a few-watts ceiling speaker, an RF section for ILS marker beacon receiving, and a front panel with a load of buttons and switches. Then it has some relays for signal switching.

I would expect the logic to be static (not clocked) and implement a combinatorial circuit, switching outputs based on front panel selections, with some priorities implemented. Probably 100 lines in an AVR.

This one is by Garmin. PS Engineering make a lot of very similar ones. These products are all a tour de force in how many discrete components can be thrown on a PCB An interesting angle is that Garmin bought a competitor called UPS Aviation Tech which had managed to get FAA to let them do certification internally (subject to some auditing) and Garmin bought UPSAT to get this concession (and basically shut UPSAT down almost right away ). So Garmin don't need to demonstrate compliance to an outside body - within certain limits.

4000 series CMOS will go on forever.

Big FPGAs are a different thing I am sure. This is a very simple case. I just don't "get" an FPGA here, especially given their relatively limited production life and with the little EPC1064 configuration memory chip having to be - like the Xilinx ones from that era - programmed in a programmer (not on-PCB in those days) and then issued to the assembly line. Conceivably it could be in-circuit programmed via JTAG...

Re DO178, I can see a simple FPGA is a lot less work than an AVR

[nctnico]

But, when a lot of the discrete TTL logic series is being retired and unobtainable and the order from above is to replicate the old circuit, no deviation.

That doesn't seem a plausible reason. TTL style chips are still available. With an FPGA a change to CMOS and/or 3.3V will still need to be made.

[mikeselectricstuff]

FPGAs would have several potential advantages:
Good partitioning between separate functionality, so independent functions can be tested independently.
More predictable timing - e.g. compared to a multitasking processor, timing will not depend on other activity.
Much less internal state^* to worry about - on a processor, all the RAM, registers etc. contain state that the outputs may depend on, with near-inifinite complexity.

* assuming the bitstream is protected somehow - I believe some FPGAs have mechanisms to detect bitstream corruption while running.
On a processor, the entire processor architecture and toolchain is in teh loop of verification - with an FPGA, it can be verified correct at the RTL or even bitstream level. 

Of course there are also some pitfalls like metastability that aren't generally an issue with a processor.

[mikeselectricstuff]

But, when a lot of the discrete TTL logic series is being retired and unobtainable and the order from above is to replicate the old circuit, no deviation.

That doesn't seem a plausible reason. TTL style chips are still available. With an FPGA a change to CMOS and/or 3.3V will still need to be made.

But existing discrete logic can be replicated in an FPGA easily - the logic levels and timing may vary, but once that is dealt with, the logic itself can be shown to be equivalent. In the case of old designs, the original functional spec may no longer even be available, so simply copying the logic may be a more pragmatic approach than trying to replicate it in software.
Many years ago I was asked to look at re-creating a board full of about 100 TTL chips in a rail application, which had dozens of independent random logic functions ,and quickly concluded that an FPGA would be the quickest and simplest  way to do it.

[Tation]

FPGAs would have several potential advantages:
Good partitioning between separate functionality, so independent functions can be tested independently.
More predictable timing - e.g. compared to a multitasking processor, timing will not depend on other activity.
Much less internal state^* to worry about - on a processor, all the RAM, registers etc. contain state that the outputs may depend on, with near-inifinite complexity.

* assuming the bitstream is protected somehow - I believe some FPGAs have mechanisms to detect bitstream corruption while running.
On a processor, the entire processor architecture and toolchain is in teh loop of verification - with an FPGA, it can be verified correct at the RTL or even bitstream level. 

Of course there are also some pitfalls like metastability that aren't generally an issue with a processor.

With FPGA you also need certificated tools (compiler, simulator, ...) to validate RTL/netlist.