The Lack of Open Tooling for FPGAs

This does a good job of capturing the first part of the problem. Note that Xilinx did make an "open" FPGA part, the 3000 series, it did not do well for them.

The critical thing to understand, is that FPGA users (the big ones, not the casual ones) don't want them to be open. They want the information they program into them to be secret so that their hardware is not easily duplicated by the folks in China and mass produced to under cut them. You can't patent schematics. So these folks want to have a way that a board can be assembled in China but not reproduced there in a way that isn't an exact clone (which you can get blocked as a counterfeit product).

Ok, so where does that leave us? Well it might be easier to create your own FPGA design, have TSMC make it on their cheapest process. And then try to sell those chips.

And if you're saying "Jeebus Chuck! That isn't 'easy' at all." you would be right. And that is why a 200Mhz general purpose CPU is easier to turn into a "custom chip" than an actual custom chip.

So where does that leave us? Well, all the bits between HDL and chip can be done, in a low scale way, either in simulation or on bulk small scale hardware. You can program CPLDs to be simple Logic Units (LU) for your FPGA and wire them together on a PC board. You can find the things that need to be parameterized (intra-LU timing, global clocks, I/O configuration) and build tools which can synthesize, place & route, and download to your "pseudo" FPGA. And if you have all that tooling, and you can show it works, you might be able to get a partner to make some small scale parts for you (200 - 1000 LUs)

It won't happen over night, that is a 5 year plan minimum I think. And you have to get over the hump of developing tooling for an FPGA that may never exist. On the plus side it should be good for several Masters level projects and probably a PhD or two, and if your simulation work was robust you might become the 'standard model' for testing assumptions about reducibility of different constructs into hardware[1]

[1] Sort of the Lena[2] for FPGAs.

[2] A playmate digitized by USC which became the standard image processing image for research.

I am OP

astrodust: That is exactly the problem :). Turns out ISE (Xilinx's tool) has several command line tools that are run by the GUI in order, but the arguments are not documented. I was able to make a Makefile that did the ISE compilation so I could edit in emacs, but that was way too much crap to be real. The new generation of Xilinx's tools, vivado, is written in Java and does not output any temporary files so during compile it can fill over 32 gigs of RAM and crash. Xilinx suggests that until max ram gets higher to use ISE for larger chips.

kornholi: I do not want to insult hardware engineers since they are very intelligent, they just often do not respect the same things software engineers do. I went to an Atmel event where they were demonstrating how to use their new ultra low power chips. It turns out that most of the people who went were software people driving down from SF. They started off by reminding us that they have a new IDE based on the powerful and versatile Visual Studios. Everyone in the audience groaned. Almost everyone in the audience asked for assistance to find where the Makefile was. The following exchange happened over and over. host: Oh, but you see, with AVR Studios, you do not have to _worry_ about the Makefile, it does it for you. guest: yeah but I do not want to use it. host: but... why would you not want to use the tool we provide, it works. It seems to me that most of the hardware industry will take whatever tools they can get, even if they have to have the company pay several thousand dollars. The ones I have met forget that they can write tools. When the tools need to be created they just pick whoever is the most comfortable in Java, or outsource it to anyone. This all sounds very critical of professional hardware engineers, but it is not exclusively their fault. It is also a culture thing of the companies and the industry. Everything feels to me like how software engineering was (as I am told) in the 70-80 where everyone is super paranoid about secrets, and rushing to be the first. There is reasonable concern for being the first. If you build the first flash ram chip, 40 years in the future when we have moved from flash to crystallized light or something, everyone who wants to compete will be using the same pinouts you picked for your first product so that boards never have to be redesigned. As for ISE and vivado, I hear it suffers from design by committee. Where every feature has to be checked off as working before it will ship so there is a new bullet point. Hell, they have a C to fpga compiler which you would suspect could do some crazy things and took thousands of engineering hours to make work. But instead it just implements a CPU in the FPGA with slightly accelerated operations for your setup, completely missing the point of FPGAs.

I am sorry you suffer from the dongle collection woes too. The only reason I can see to buy expensive dongles are the ones that have a big blob of RAM on them for quickly reading debug output from the chip without slowing it down, and ones that can adapt to highly exotic voltages and pin outs automatically. But usually the software for these only work in windows, have secret drivers, and are NOT worth 2 thousand dollars.

Xilinx and Altera would not have to give up their custom algorithm. It is like building GCC instead of using Intel's compiler. We just want to know what the chip's instructions are, we will find a way to make it optimal ourselves.

You are not wrong, and I think the first company to support open tools would gain a competitive advantage . . . I know I would give them my business.

They could release some details, but they won't. They perceive it to not be in their interest. They are probably wrong about that, but that is the way they perceive it.

Of course on the other hand FPGAs are not a great fit for mobile devices, which are one of the main consumers of wireless communication (radio) technology.