Didier_Juges 2/8/2012 8:41:06 PM User Rank Blogger
Testing FPGA
Aseem, I believe what you are doing to help testing of FPGAs is similar to what I have done for uC code. In many systems, it is not always convenient to exercise all the conditions that the product is supposed to respond to, so I have developped a method that works for my architecture. It turned out that there was a beneficial side effect that I had not envisionned. Let me elaborate a little.
Most of my uC projects are controllers that themselves provide a user interface via a serial (or ethernet) port. The communication protocol is strictly command/response, and the commands are composed of status or telemetry queries, and state change commands. The main status query returns a bit-mapped byte array, where each bit corresponds to a particular status or fault condition. This is pretty common and straightforward. The customer is expected to write his own software to issue commands and decode responses from our devices. I wrote such control software for our own internal use of course to allow us to test our products. This software runs on a PC.
Some time ago I realized that to help testing my own PC control software, I needed to simulate some faults on the remote device that are difficult to create in real life, in order to verify that all the fault bits were handled properly by the PC software. I created a version of the uC code that allowed that through special commands. At first, I intended that to be just for test purposes, but as I found a relatively low impact way of doing it, I decided to leave the test commands in the finished product and document them for our customers. It has been a very good decision, and I intend to do that now for all upcoming projects.
Jaz, a couple of the reasons I have been given for the military's FPGA preference include security, reliability, and longevity.
A non-volatile FPGA can be made to prevent outside recovery of the configuration, so if a device falls into enemy hands it cannot be readily replicated. That can be harder to do with firmware.
As to reliability, the FPGA is a hard-wired, deterministic device. A random alpha-ray strike cannot readily change a memory bit and crash the device's operation the way it can with software. Also, software can be difficult to make behave deterministically.
For longevity, well, processors and operating systems and development tools seem to change every year or two while FPGAs tend to hang around much longer. The military wants systems with a 20-year operating life.
None of these are compelling reasons to use an FPGA. An MCU can address all of these concerns. It may just be a little easier today with a hardware solution.
You guys seem to know more about FPGAs than i do... I actually guessed that the military prefer to use FPGA only where intensive processing is needed such as coding/decoding, encryption, data acquisition, data transmission, video and image processing and so on... I also understand the importance of having a flexible hardware that can be configured on demand. well, what are the other reasons for the military to prefer FPGAs over uCs? It is well obvious that the military sector is one of the most sectors interested in this technology...
ASEEMOV 2/7/2012 11:58:01 AM User Rank Program Manager
Re: MCUs or FPGAs
I fully agree with Didier on this. I have seen a lot of defense (military) establishments opting for FPGAs for the reasons Didier explained in his post. Its precisely just that. In fact, in some of the recent designs which were more of upgrades from the older designs which used the microcontrollers/DSPs, the guys have simply knocked out the controllers and replaced them with FPGAs.
Also, with lot of megafunction and macro support provided by the FPGA vendor tools, customers' design cycle times have much reduced as they don't have to write RTL code from scratch but rather instantiate a proven macro provided by the FPGA tools.
Defense/military folks don't seem to care much about the chip cost - it is not a cost sensitive market.
Also FPGAs are much prefered by low volumes product manufacturers.
ASEEMOV 2/7/2012 11:43:39 AM User Rank Program Manager
Re: Logic optimization in FPGA vs Code optimization in Microcontroller
Hello Didier,
I think I have seen optimization for speed and size parameters in both Quartus and Xilinx XST.Well, I was sort of trying to caution about the other kind of logic 'optimization' that is automatically performed by the compiler. What I have seen is that if the results are not being used anywhere or in other words, not being brought out of the top level module, compiler simply removes the entire logic. Though you may see the logical design in RTL view, there will be nothing shown in the technology view (all logic optimized out) for that piece of design. If the signals are brought out of the top level module, that is fine too - it is not required to connect these signals to the FPGA IOs. Also, one could use 'synkeep' attribute for these nets nets to retain them and hence the logic corresponding to these nets is also retained. Also, if one hooks up SignalTap or Chipscope probes onto these nets, the logic is retained.
ASEEMOV 2/7/2012 11:29:10 AM User Rank Program Manager
Re: Main issues with designs using FPGA
Hello Didier,
It's not going to cause any harm if you leave it as it is lying in the FPGA. It is just a ROM instance. The main reason for me to use this feature was that I didn't have the entire system around the FPGA to drive stimulus and configure various IP configuration parameters. Assuming I had the required system around the FPGA, I would use the memory bus of the processor sitting on the board (outside the FPGA) to write to the local register set inside the FPGA (registers, whose bits I would connect to the control parameters/signals for the IP implemented on FPGA). Since I didn't have the infrastructure around the FPGA, I created a ROM instance (using in-system programming feature - Altera megafunction wizard). Without this feature I would have had to create separate FPGA builds (one each for every hardwired parameter). Now the parameters are no more hardwired in the FPGA but are controlled through the in-system ROM. So this way I could use just one single FPGA build and still test various features/modes of the IP by writing the control information straight into the ROM via in-system window.
Microp 2/7/2012 2:04:56 AM User Rank Program Manager
Re: MCUs or FPGAs
Jaz, you are right and what you pointed is true. But we cannot neglect FPGA as such from embedded sector. In my opinion when compare over others, FPGA have many advantages like compatibility, incorporating more components and functionalities in a single chip etc. by functionality wise, FPGA can be customized based on target bopard/chip.
Didier_Juges 2/6/2012 7:43:34 PM User Rank Blogger
Re: Logic optimization in FPGA vs Code optimization in Microcontroller
@aseemov: One can think of microcontroller code (with all optimizations turned off) as a strict implementation of the source code and libraries. Under that concept, one could imagine that various compilers should generate very similar binaries from the same source code when all optimizations are turned off.
It is difficult to imagine a similar scenario for an FPGA. I cannot imagine a concept of "strict implementation" of an FPGA design, and there has to be always a significant amount of optimization (maybe "simplification" would be a better term), even if the designer does not specifically ask for it. For instance, I am not aware that Quartus offers various levels of "optimization". You can force the tool to lay your design out a certain way, or to use certain features such as clocks but that's about it. I am not aware that you can tell the tool (or that you would want to) to not optimize something.
Didier_Juges 2/6/2012 7:35:24 PM User Rank Blogger
Re: Main issues with designs using FPGA
@aseemov: I like the tool you describe as "in-sytem ROM programing option". I am using Quartus for my little FPGA project and there are many things about this software that I am unfamiliar with, but this seems interesting, particularly if it allows testing various scenarii without rebuilding. Is that something that you ultimately leave in your code (assuming that you can somehow disable it), or do you do one final rebuild without it?
Didier_Juges 2/6/2012 7:22:15 PM User Rank Blogger
Re: MCUs or FPGAs
@jaz: It is tempting to agree with you. However, the users of critical systems like the military and the FAA in general do not agree with you. The requirements for software safety and verification are significantly more difficult and expensive to meet for processor based systems than for FPGA. In many cases, processors are simply disallowed while FPGAs are allowed.
It seems that these agencies have data to support the fact that FPGAs are simpler to design and test, and that they have fewer bugs.
I agree with you that due to their higher integration and lower cost, microcontrollers will always win in consumer applications, but in my job, I have faced criticism many times for using a uC instead of an FPGA.
I do not see that trend changing with the new DO-178B and DO-254 standard for airborne electronic software and hardware. For this purpose, FPGAs are considered to be hardware and are exempt of the requirements of DO-178B. Software systems always have a hardware component, so they are subject to both standards.
To save this item to your list of favorite Microcontroller Central content so you can find it later in your Profile page, click the "Save It" button next to the item.
If you found this interesting or useful, please use the links to the services below to share it with other readers. You will need a free account with each service to share an item via that service.
Tweet This
