|
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
|
|