WP_Term Object
    [term_id] => 45
    [name] => Aldec
    [slug] => aldec
    [term_group] => 0
    [term_taxonomy_id] => 45
    [taxonomy] => category
    [description] => 
    [parent] => 157
    [count] => 96
    [filter] => raw
    [cat_ID] => 45
    [category_count] => 96
    [category_description] => 
    [cat_name] => Aldec
    [category_nicename] => aldec
    [category_parent] => 157
    [is_post] => 1

Aldec the leader in DO254

Aldec the leader in DO254
by Luke Miller on 03-19-2014 at 12:00 pm

I am convinced after studying out the matter, that Aldec is one of the leaders in DO254 certification. As you listen and read the news as I do about flight MA-370, you keep theorizing and wondering. This is a good time to introduce the reader to the seriousness of flight worthy electronics and the arduous process to achieve certification. First and foremost I recommend if your company is serious about designing airborne electronics that you attend the Aldec D0254 Training conference. Three chucked full days, of the seriousness of DO254. Under $2k, this is a bargain. The three day high level objectives are shown below.

I want to briefly go over some Aldec tools, process and hardware that will assist even the fledgling company entertaining the idea of setting out to design products that require DO254/FAA type certification. Buckle your seat belt, you can do this with Aldec without having to acquire a company! First let’s identify the challenge. Below is a very simple drawing with an FPGA, the FPGA could be any FPGA, I chose Xilinx since I am more familiar with them.

The processing and algorithms in the FPGA are not the challenge. Let’s pretend that each status input is over 8 IO lines, and each output control is over 8 IO lines. From a safety critical point of view, what happens if any inputs bits are opened? Shorted? Missing state cases? Could that cause the rudder to be stuck down? Yikes… You get the idea. So at some point you must verify in hardware every single IO does what it is supposed to do and not supposed to do. It also requires that ‘errors’ on inputs result to a ‘safe’ output condition. You still need to verify the guts in the FPGA do exactly what they are supposed to do. Now picture all the systems in a Boeing 777! (Though the standard did not exist then) That is not trivial, and I would estimate 25% of the budget is given to electronics design and 75% to test and verification.

Aldec has an awesome video on DO-254 and there solution for FPGA target in level testing. Watch it right now if you can, as it would take me another few pages to explain all of it. Aldec also has white papers on the topic as well, all worth reading and studying.

To plagiarize from Aldec, “DO-254/CTS™ is a certifiable at-speed FPGA level in-target testing system for Levels A and B DO-254 designs.” When designing firmware for an FPGA you have a testbench or testbed. The testbench will have input stimuli and you capture the results and compare. Usually when hardware comes you redesign most of the testbed work so it can work on hardware. This is no place to live when working DO254, and Aldec’s DO254/CTS allows you an evaluation platform ASAP so you can reuse your test vectors and pay attention to the important things which are the safety critical tests. Since the Aldec solution uses real hardware, it runs in real time as RTL simulation is slow an painful, and eats up precious time and $$. Below is a nice diagram that captures the system. I encourage to get over to the Aldec website and attend the training in May. Until then…

lang: en_US