The most needed EDA innovation

Regular readers of my blog may be wondering what I have been doing during the past decade. I have been talking about EDA innovations, both those that succeeded and those that didn't. But I realize that all technologies that I discussed may sound like old news, coming from the nineties of the previous century.

However, we are 2010 by now. Therefore, some of you may think that I am overlooking or underestimating the more recent innovations that are happening before my eyes. What about Constrained Random Verification? Assertion-based Design? SystemC? C-Based High-Level Synthesis?

I could try to defend myself by claiming, as I did in my previous blog posts, that I simply haven't seen a truly disruptive innovation yet. You could then subtly point out that perhaps I'm losing the sense for innovations, as I am growing older and no longer involved in day-to-day design work. These would all be reasonable arguments. However, I believe the honest answer is the following: in the past decade, I have been losing interest in the technological innovations in EDA. That is because I'm unhappy with the overall direction in which it has been going.

Let me explain with an example. Suppose you want to set up a state-of-the-art development flow for digital design. There is a good chance that you'll take a look at SystemVerilog, supposedly a standard that has all the newest technologies. The reality will be rather disappointing. Before you find out what parts of SystemVerilog are exactly supported by which vendor, and how you should use them, you will already have spent lots of money. Think I'm exaggerating? Then read this recent blog post from JL Gray, who certainly knows these matters better than I do.

More and more, innovation in EDA seems to be a matter of the happy few. It's worse than that actually: when access is restricted like that, we can't even be sure that those innovations are real. It becomes a matter of trust in authority instead of self-judgement. This is not the EDA that I like.

Look at how different things are in the software development world. From the smallest hobbyist to the largest engineering department in a high-profile company: we all have access to the same powerful and innovative tools: languages, compilers, IDEs, revision control systems, and methodologies. And this is not just about open source, but about a whole continuum of solutions and business models. For example, a platform like Eclipse maximizes reuse by easily accomodating both open and closed source third party plugins. As an other example, look at how successful companies like Apple and Google manage to mobilize thousands of third-party developers for their proprietary platforms.

In my opinion, EDA needs business models like those found in the software development industry. Rather than technology, those are the kind of innovations that I'm looking out for.

Comments

I think you are right, but

I think you are right, but also that you have missed a little grain in the dirt. A grain of open source and collaboration. I am talking about OpenCores. There you have the beginnings of a common library, a foundation of proven components. OpenCores is to hardware what SourceForge was to software. What we know need is the Eclipse of hardware (it could even be Eclipse, with the right EDA plugins.)

We also need a common knowledge base where people can help each other out.

I wholeheartedly agree. I

I wholeheartedly agree. I have been doing system architecture, design, and verification of FPGAs and ASICs for almost 7 years, and I have never seen anything in the world of hardware design tools like what software design has.

How can we do "agile" FPGA design with VHDL and Verilog? I have been asking myself this question for the past few years. You can't, at least not with any existing EDA tools or VHDL/Verilog. And don't even get me started about frameworks--we have none! Unless your company has spent an descent amount of money on building a custom framework in house. And several have--Motorola, Intel, AMD for instance. But they are not widely shared--both outside their company, and even within!

You guys are definitely firing the first shot by releasing Sigasi. I have been yearning for an IDE that understood VHDL and Verilog since my first Verilog project in college. I was so used to all of the features of Visual Studio for my C/C++ programming classes, and there I sat in the computer labs using Vi. I learned Vi because there was no IDE for VHDL/Verilog. I mean, I'm grateful for it because Vi is a powerful tool (and I still use it to this day for writing VHDL), but once projects hit a certain level of complexity you are left with just far too much stress and pain trying to develop in Vi.

Bring on the innovation!

Absolutely. When I program

Absolutely. When I program in a language like Ruby I can go find all kinds of code examples and gems as well as online documentation and blogs. Plenty of info out there that's openly available. It's similar with any open source project. There's collaboration going on.

When I program in SystemC and hit a snag and then google around... there's not much out there. When I hit problems in EDA there's just not much out there. Not many forums where the issues are discussed openly.

I would disagree slightly and say that it is about open source. The big EDA companies have become "Old boy networks" - they only care about their large customers with lots of $$$. They don't seem to care about actually improving the state-of-the-art. I suspect they need competition in the form of Open Source EDA apps. I imagine that software development would be in the same boat were it not for gcc. Imagine if gcc had never been created (or never open source).

What will the gcc of the EDA world be?

If there ever will be a GCC

If there ever will be a GCC of the EDA world, it is has to be able to generate bit files for the major FPGA vendors.

In the Software World

Back then GCC was free and had the ability to generate executables for the commercial Unix operating systems.

This enabled the creation of operating system tools, (GPL and BSD), which when the Linux kernel arrived, made distributions like Ubuntu possible.

But in the beginning there was not even GCC! There was the editor. And then there was a compiler, and it was called GCC.

So to summarize,

  1. Editor
  2. GCC
  3. Operating system
  4. Open Software Ecosystem

In the Hardware World

In the hardware world, we are just at the beginning. If Sigasi or some other entity creates a good open source HDL development environment, we are at the Editor stage.

When the Editor stage is passed, what is needed next, is to produce a “GCC” which can compile Verilog and VHDL to bit files suitable for established FPGA parts. (At this time, Xilinx and Altera.) Just like how GCC compiled for proprietary Unix.

When this stage is reached, half is won. The last stage is twofold:

  • Standardize on an open bit file format.
  • Create an open reference implementation of an FPGA which takes the standard bit file format.

Summary:

  1. Editor - a solid open source HDL IDE
  2. An open source synthesizer which can generate bitfiles for Altera and Xilinx.
  3. A standardized, open FPGA bitfile format.
  4. An open hardware Ecosystem

This will bring the ultimate commoditization of HDL technology and put even more pressure on established vendors to innovate and distinguish themselves.

Open Hardware Ecosystem

Open Hardware Ecosystem ...

Jakob Eriksson makes this hole in the market very clear! Right now, the synthesis tools that everyone uses are proprietary. Why? Because they're the only thing out there and so many companies have already spent the time and money to learn the proprietary tools.

If open source development tools for hardware became readily available, well developed, and a good community could grow around them... then we'd see the open hardware Ecosystem that we all crave. The hard part is getting started. To get to the same point that software is in right now may take some time. This Eclipse plugin seems like the first step of many.

I'm a recent grad of electrical engineering and computer science, but am currently working on software at a hardware company. I had the opportunity to show my boss how well Eclipse works for what I do, and I mentioned that there may be plugins out there for VHDL and Verilog. He was impressed, and wanted me to do a presentation on Eclipse and some other tools I use. I found this plugin, and one other one (SimplifIDE). As our company is transitioning to a verilog only environment, I was forced to check out SimplifIDE, which currently seems a bit underdeveloped, and just getting started.

Currently, we use a collection other proprietary tools for development: Xilinx ISE, Modelsim/Questasim, Actel Designer, Mentor Graphics DxDesigner, vi, etc... Today's hardware engineer is split between managing all these different programs, and probably wasting a lot of unnecessary time going back and forth as mentioned in this article

It would be nice to see how well all of this process can be integrated in the future to create a better set of tools and hopefully an open hardware ecosystem.

Thanks. It seems we are not

Thanks. It seems we are not alone in thinking these thoughts. Look at "aneccodeal"s answer to this question: http://stackoverflow.com/questions/2056560/opensource-fpga-development

This is what I am talking

This is what I am talking about.
Apparently, someone even wrote a paper about how FPGAs could be virtualized and then how a toolchain could be written to support this:

http://bit.ly/f6CYsH

"Placing, Routing and Editing Virtual FPGAs."

I have no experience at all

I have no experience at all in the hardware realm, or at least very limited experience, so please help to enlighten me if I seem to have misunderstood the issue. As far as I can tell, it seems that all that is required is for an FPGA vendor to reveal two things:

1. Firstly, we need to know the format of the bit file that is used to program the FPGA. We know how VHDL and Verilog works, now we need to know how the FPGA works in order to produce code for it from VHDL and Verilog, and - potentially - any other language that we may choose to create, that we then can translate into a working bit file for an FPGA. This seems to me to be similar, in the CPU world, to the x86 instruction set specification. This is really a two-part speicification. Ie. 1: which instructions are there that we can use, and 2: what is the format/"wrapping" that we use to feed these instructions to the CPU. Like this: http://www.intel.com/design/intarch/manuals/243191.htm

2. Secondly, we need to know - now that we know *what* to program to the FPGA - *how* to program the FPGA. Ie. how do we get the generated bit file into the FPGA. This seems similar to this document from AMD: http://support.amd.com/us/Processor_TechDocs/43170.pdf

All that needs for this to be possible is for an FPGA manufacturer to release the documentation above. As far as I can tell, at least to begin with, it isn't necessary for FPGA manufacturers to agree on any single open standard for a bit file format. And it may be a bit too much to ask to begin with. Ie. that all FPGA vendors conform to some specific format. As far as I can see, it would be better if they each were free to use their own format, but the information on these formats were openly accessible - like it is for x86/ARM/PowerPC etc.. As far as I can tell, even this information for FPGAs is not available is it?
If we have the necessary information, we could just adjust the bit file format depending on which FPGA we're "compiling"/synthesizing to. Like the gcc compiler compiling to either x86 or ARM, by simply adjusting a switch.

So if any single FPGA vendor were to release this documentation, we could actually start an open development with FPGAs. Neither Xilinx nor Altera would need to participate, as I suspect open source community development would quickly start to center around this open FPGA vendor (though Xilinx and Altera would probably keep their current corporate customers), and perhaps this could help push the larger FPGA vendors into releasing similar documentation for their FPGAs, in order not to lose the ones programming FPGAs for fun (which, in my opinion, is a very important part of the developer crowd).

Now bear in mind that I'm totally new at this hardware stuff, this is just how I see it and I would appreciate corrections, so I can learn more about this issue. I definitely agree that this seems to be what is holding the FPGA field back, compared to software development.

In my opinion, you are

In my opinion, you are totally correct.

1) - The bitfile format and the abstractions it describes, these are closely guarded secrets of the vendors.

2) - is no problem. I think we know this already.

Another problem is that often are these things not only secrets, but also patented. Alas, since we are actually talking about hardware here, these patents have a litter more clout than "just" software patents, which are un-enforcable in many parts of the world and even in the US weaker than hardware patents.

Adding insult to injury, vendors often require users (in their license terms) to not reverse engineer or in other ways find out or spread information about how the bitfile works.

All these things can be worked around, but care must be taken to not step on any important toes in the process.

Cool thing that we know how

Cool thing that we know how to program it at least, that's one less barrier to overcome.

Sadly, it seems we can do everything besides overcome patents. They always seem to be the very last obstacle, but this we can't overcome easily. At least not when it's hardware patents, where we need some company to produce the hardware and take the risk of getting sued. We could make sure our opinion on patents is heard, and financially support institutions that oppose patents though.
All in all it seems like a waste to me :\ - I'm sure FPGA development would flourish if things opened up in this area, there seems to be so much potential.

I actually think patents are

I actually think patents are far from the biggest obstacle. FPGA like technology can be produced in many ways.

The biggest problem is that we don't know how to make our toolchains targeting our own hardware we bought from for example Xilinx. But this maybe can be somewhat mitigated through this technology: Editing Virtual FPGAs.

Well that sounds like good

Well that sounds like good news to me. If patents don't really pose a problem to the development of FPGAs, someone at least *can* come into the market (probably a small player) and produce FPGAs with open specifications.

It would be cool to see the underdog do this, like AMD has done in the GPU market for Linux, releasing a lot of documentation for their older and new GPUs so community developers can create drivers for these devices.

It would be really neat to see something similar happen in the FPGA market. In my opinion, if patents really aren't that much of a hindrance, it can't take long before this happens.

On a similar note, do you know approximately how much it would cost to start up a company from scratch than can produce attractive FPGAs. Is the hardware a challenge to make. Because if all else fails, we *could* always do a community funded production of an open FPGA.

Let's say we're able to gather a hundred thousand FPGA enthusiasts that are willing to pay $100 each for a completely open FPGA - at the moment, opencores.org have 112,538 members so I don't see it as far fetched. These $10M could be used to fund a company producing a completely open source FPGA with all the documents needed to create compilers/synthesizers and what else is needed.
If we could find a million interested FPGA hobbyists, we'd only have to donate $10 per person, even I would be willing to sacrifice that amount, even with the risk of it not turning out for the best.

It would of course take some time for the open FPGA community to catch up with the closed source development tools of Xilinx and Altera (like Xilinx' ISE, IDK and SDK and Altera's Quartus), but if indeed 100,000 or even 1,000,000 are willing to donate money to the project, this work force could without a doubt produce something very valuable in less than a couple of years.

I find your numbers for

I find your numbers for people willing to donate money very optimistic. Remember, just the advertising for such a huge campaign is a great undertaking.

Also I remember someone in the industry saying that something more like hundreds of millions of dollars to start a new fab. Plus we would have to develop a new FPGA like thing too, not just create a fab.

If you want a realistic price, there are always new contenders trying to hit their way into the FPGA market. Take for instance TierLogic. Figure out what it would take to acquire them, that should be a pretty realistic sum. No, I think the way forward is to use the FPGA hardware already out there. Or persuade TierLogic that their business would benefit from open sourcing their bitfile formats. This may very well be true, too, but the people who put down many millions of dollars would need some convincing.

Yeah, of course you're right.

Yeah, of course you're right. Hardware is expensive as hell. Both the expertise to produce it, and the costs of the actual production facilities. This approach might be feasible with software, though.

In the end, if opening up ones specs really is as profitable as we believe, I'm sure someone will do it at some point. But whether it be one or five years before it happens, is hard to tell. I'd venture a guess and say within five years.

Thinking about it, may the problem with opening up specs also be that some of the methods used to create the bit file, are licensed from third parties through restrictive NDAs?
I know this is the case with AMDs proprietary driver for their GPUs. They needed to start over developing an open source driver, because they simply didn't own all the code in their closed source driver, much was licensed from third parties.

I have no idea, but would not

I have no idea, but would not be surprised if the FPGA business is a cross-licensed mess overall. :-)

Hi Rune, I love your

Hi Rune,

I love your enthusiasm. You need to do some more research, though. Your numbers are off by one or two orders of magnitude.

We have no idea what "100,000 registered OpenCores users" really means. The number of registered accounts can easily be five or ten times more than the number of actual people that are interested in the subject and that are regularly visiting the site.

There simple are not a million people interested in FPGAs. Talk to marketing people at Xilinx and Altera. Each company has a some tens of thousands of users registered. Not hundreds and certainly not a million. I think you'll have a hard time even finding the names of 10,000 FPGA hobbyists.

If you are familiar with open source software project, you will know that these projects are not started with by a million of enthusiastic people. Usually two guys start off in a garage and then gather a following of ten, fifty, two hundred and eventually five thousand or more people. If you want to change the world, by all means: write a blog, get a garage, and get started. I'll be the first person to click the "donate" button on your website.

Hi Rune, it seems that

Hi Rune, it seems that Opencores.com likes your idea! http://www.sigasi.com/content/opencores-raises-community-funding-open-so...