In which we mull the rising number of FPGA design starts, the falling number of ASIC design starts, and the impact that this is having on the EDA industry...
The inspiration for this blog came from an article I read recently that talked about the rising number of FPGA design starts, the falling number of ASIC design starts, and the impact that this is having on the EDA industry.
It also pointed out that FPGAs still account for only a tiny fraction of the semiconductor revenues, so I thought I would add my own 2 cents to this discussion, not by regurgitating the data that has already been put out there, but to look at why FPGAs have not become as prevalent as the ever so humble microprocessor.
Let’s look at the microprocessor. It is a very inefficient device for almost every task. It is slow, it consumes a lot of power per unit of computation, and it is also one of the largest possible implementations in terms of chip size to perform the desired functions (bears a lot of similarity to the negative aspects of the FPGA, except that the FPGA is better on almost all counts). So why on earth did this device ever become so popular? I think it comes down to a few simple reasons – simplicity, independence, and abstraction. Let me explain what I mean by each of those and point out why the FPGAs at the moment do not meet the necessary expectations.
Simplicity – to program a processor you need little or no knowledge about how the processor actually works, only the paradigm set forth by Von Neumann. Instructions are fetched from memory and operated on in order. Registers inside of the device hold temporary variables, variables can be moved in and out of memory to registers, and certain instructions can change the place from where the next instruction will come from – and let’s face it, that is about it.
With the instruction set, it then just becomes a matter of logically thinking through the process. Just think what would have happened if reverse polish logic had become the way in which everything was done? My first calculator used reverse polish, and while it was more efficient, it was also a lot more complex to get it right. You had to constantly be thinking about what was on the stack, ordering of operations several steps in the future, or to look at that another way, you had to constantly think about the processing pipeline.
How do FPGAs compare? A study was performed by BDTi in early 2010.The focus of the study was ESL high-level synthesis tools targeting FPGAs. Their conclusion was that the high-level synthesis tools were great, but that they were let down by the back-end FPGA tools that required far too much hardware knowledge in order to achieve success. There we have problem #1. If we cannot insulate the user from knowing details about how the FPGA works, then it will never attain the same level of dominance as the processor.
Independence – with a processor, it is never necessary to actually verify the processor when you want to verify the software. Software can be developed in isolation and in many cases it is even possible to develop the software without knowing what processor it will execute on. This allows total team size to grow without having the problems that face most engineering teams in that by adding additional people, you add to the communications and management problems.
Now I agree that there are hardware/software boundary issues, but this is not with the processor, it is usually with everything else in the hardware. The software team can operate completely independently except for that interface between them. This independence comes from the encapsulation methods used for a processor.
This is very similar to the way in which hardware used to be designed using discrete logic. Anyone who has been around as long as I have will remember the 7400 series of devices. We did not have to worry about interoperability issues or integration problems so long as we followed a few simple rules.
Can we do the same for an FPGA? Can we have one team developing the code for the FPGA while an independent team develops the environment in which the FPGA will operate? I don’t think so. We can’t even integrate pieces of IP within an FPGA without problems. And we most certainly cannot develop and verify the code for the FPGA and not have to re-verify it after it has been mapped to the device. I talked about this problem a few blogs ago.
Abstraction – software development has not stood still since those early days. Programmers wanted to be able to move above the instruction level of coding for all but the most highly optimized parts of the system. They wanted even more independence such that code would be even more portable, but more than that - they wanted the efficiencies that come from abstraction.
Abstraction raises productivity in every aspect of the flow – design, development, debug, verification… Now I have seen the charts that show that hardware productivity increases at a higher rate than software productivity. There are two reasons for this. The first is that hardware started at such a low level of abstraction that it has been catching up. We are now beginning to see people being able to develop hardware using C, C++ and SystemC - languages that have been the staple of the software industry for decades (well, not SystemC). That same BDTi report gave the high-level synthesis tools a fairly high endorsement for the usability of those tools even though they do not cover the whole language. This will improve over time.
The second reason is that the tools created for the hardware portion are so much better than the tools available for software engineers. That of course is partially a reflection of costs. Software developers do not want to pay a lot of money for tools, whereas ASIC developers have traditionally paid very high dollar amounts per seat. This directly impacts the investment in the tools. The early tools for the programmers came from the processor manufacturers, just as the FPGA vendors put out free tools, but the processor tools were adequate for the task. The FPGA tools are not, and even most of the tools that you can buy from the other vendors still fail in many aspects.
So, I think that FPGAs have a long way to go if they are ever going to attain the same kind of dominance as the humble processor. We need to stop thinking about them as hardware devices and start thinking about them more as programmable, encapsulated pieces of functionality and simplify their usage model. I do see some of this happening, but not enough and not fast enough.
Apple turned the MP3 player from a techno geek device into one for the masses by removing complexity and even some capability. The same has to happen for the FPGA. Who will be the Steve Jobs for the FPGA?
Brian Bailey – keeping you covered