Sender: <marv@lancaironline.net>
To: lml@lancaironline.net
Date: Sat, 25 Aug 2007 10:07:23 -0400
Message-ID: <redirect-2283994@logan.com>
Received-SPF: none
 receiver=logan.com; client-ip=206.130.116.53; envelope-from=hwasti@lm50.com
From: Hamid Wasti <hwasti@lm50.com>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
Subject: Re: [LML] Re: fallability in the digital age
References: <list-2283539@logan.com>
In-Reply-To: <list-2283539@logan.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Rob Logan wrote:
> I'm confused... GPUs and Altera PLDs do contain "code" that
> can act much like an ALD found in any CPU.. but the errata sheets
> on cpus aren't tiny, so why aren't CPUs held to the same
> standards as a GPU? gate count?
I am not sure what exactly you mean by "ALD" The only acronym I can 
think of for ALD in the context of CPUs is "Atomic Layer Deposition" and 
I do not think that is what you are referring to. In the context of your 
post, I would suspect that you are referring to microcode.

Actually, the GPUs (Graphics Processing Units) and PLDs (Programmable 
Logic Devices) are now being held to the same standard as the CPU 
(Central Processing Unit), whereas they were receiving a free pass in 
the past.

A CPU has a document that describes what instructions it supports and 
what they do. The programmer writes code that runs on the CPU and makes 
it do certain things. In order to achieve certification, this program is 
subject to the DO-178B standard which analyzes branches and paths 
through the code to make sure that the code does what it is supposed to do.

The latest trend in graphics processing is to have a GPU which is 
basically a specialized CPU, optimized to perform graphics operations.  
Its capabilities are tightly held company secrets because that is what 
gives a company edge over their competition. That GPU runs programs that 
actually perform these operations and that code is also a closely held 
secret. The user application, running on the traditional CPU 
communicates with the program running on the GPU through a well defined 
yet proprietary interface. Even this interface is closely held but 
released to select outside developers on a need to know basis so they 
can develop drivers.

In the past the FAA has allowed manufacturers to treat everything past 
the CPU to GPU interface as a black box that did not need to be 
validated, just like it has treated the CPU at the level of its 
specifications. However, in recent years as more and more functionality 
is implemented on the code running on the GPU, the FAA is saying that 
the GPU needs to be treated the same way as any other CPU -- its 
specifications need to be published and the code running on it needs to 
be subject to DO-178B just like the code running on the main CPU. A 
simple question that the FAA is asking: If you tell the GPU to draw a 
shaded polygon between a set of vertices, how do you PROVE that the GPU 
will do exactly that and nothing else under all possible sets of inputs. 
DO178 has mechanisms to ensure that to a satisfactory level and hence 
the FAA's insistence that the code running on the GPU be subject to DO178B.

As for PLDs, there was a lot of abuse going on there as well. Today's 
high density PLDs can implement functionality that would traditionally 
have been implemented in code on a microcontroller.  By migrating this 
functionality to a CPLD the manufacturer was able to sidestepped all 
scrutiny. This led to DO-254, which is basically DO-178 for programmable 
hardware. The  CPLD design, which is now typically done in a high level 
language, is subject to the similar processes as DO-178, but tailored to 
the unique issues pertaining to the programmable hardware.

Yes, you can make an argument that the microcode running on a CPU should 
be treated the same way as the code running on a GPU. There are two 
problems with that argument: The size and complexity of the GPU code is 
orders of magnitude higher than the size and complexity of the 
microcode. Despite that, if you are able to win the argument that the 
two need to be treated identically, it leads to your second and bigger 
problem: If the CPU microcode and GPU code are treated identically, it 
will tighten restrictions on CPUs, not relax them on GPUs.

Regards,

Hamid