The Lack of Open Tooling for FPGAs | Hacker News Reader

The Lack of Open Tooling for FPGAs

curtis.io

230 pointscgag121 comments

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.

> Note that Xilinx did make an "open" FPGA part, the 3000 series, it did not do well for them.

Could you provide further details?

http://www.xilinx.com/support/documentation/data_sheets/3000... is the data sheet. I used to have the programming and layout specs doc they gave out.

But in how far didn't it do well for Xilinx?

Well the guy I know who used to be in charge of strategic marketing for Xilinx shared that it had not met sales projections and support costs were higher (which cut into margin) when people were trying to program the things with their own tools. So sharing all that stuff about the chip alienated some big customers, reduced profit margins, and didn't help volumes. That pretty much defines 'fail' in the chip business.

This is an interesting story. An unfortunate end. Most of these things sound like short term issues that get resolved as the tools are made. Alternately Xilinx could have just put the docs out there and said they only support ISE. That way if an open source developer makes a tool they have no responsibility, but can reconsider in a few years in case it gets wide acceptance. I am not a market strategist, but supporting everyone's custom tool sounds like a quick way to waste money and the wrong way to try and open source something. Similar to respecting every coupon people bring in, even hand written ones.

Can you find the "programming and layout specs docs," online or physical copies? I can't find any mention of them anywhere. I'm very curious to see them.

Are you sure it was the xc3000 that was documented and not the xc6200 series (e.g. xc6264)? I remember the xc3000 being documented the usual amount for their parts (pinout, architectural description, call for info about licensing the software you need to have to use the thing), but the xc6200 datasheet definitely included details about the bits and is still floating around: https://duckduckgo.com/?q=xc6200.pdf

If there's so much value there, how are these companies stopping internal espionage? If a company wanted to see what their competitors were doing to gain a large advantage, they could certainly field a candidate to work as an agent for their competitor. It sounds like how Nikon doesn't document the NEF format and pretends their binaries are the only way to decode such files. Except obviously the secrets these hardware companies have is far more than a simple RAW format.

From what I've read of internal leaks, the leakers get caught and charged and dealt with, which discourages other leakers perhaps. But there isn't anything stopping an employee from selling or stealing company secrets. That hasn't changed.

But during the 70's and 80's a lot of manufacturers stopped printing schematics in response to clones appearing which used a circuit that was close (but not exactly like) theirs and sold at a deep discount[1].

Early computer board manufacturers used programmable logic to create special "nodes" within the system which obscured the functioning of things such that to clone them you would have to hire an engineer to understand the design and re-design it. Generally that was more effort than most of the cloner companies were willing to go through. (apparently if they had their own engineers that could understand the circuit they didn't need to clone, they could design their own)

FPGAs get you at least two layers of obfuscation, both the bit stream is encrypted and "decompiling" from the place and route configuration bits is not straight forward at all. Folks who have gone down the path of trying to figure this stuff out (as the OP is possibly doing) discover that changing a routing bit way in the front changes a bunch of other bits later but in very subtle ways. And routing in an FPGA is a great way of screwing up function, when you do timing analysis if you have to run at 200Mhz you have to make sure your setup and hold times are accurate to within a few nanoseconds across temperature and voltage differences. FPGA vendors tout this as a 'design security' feature some times.

Decoding this data is a lot more challenging than reverse engineering an image format.

[1] And yes you can argue this is just business, and it is, and this is just "business defense."

Thanks for all these great answers you've given - they're a nice compliment to the article, really explain a lot of why these sorts of decisions were made by the FPGA companies.

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

So how does having a closed tool chain achieve that? Aren't the FPGAs programmed either on the line, or from ROM at power up? Either way, board producers should be able to replicate the product. How does being closed help?

> So how does having a closed tool chain achieve that?

It doesn't. It slows reverse engineering, but doesn't itself prevent cloning. I'm not sure what ChuckMcM was trying to argue. I don't know of any big companies that care whether or not the toolchain/devices are open source. They just want a way to get their design into the world. What we (users of FPGAs) care about is price; the toolchains are sufficient (though yes, cruddy in various ways).

And to be honest, this conversation about the FPGA (and ASIC) toolchains being closed sources crops up again and again. They're closed source not because Altera/Xilinx/Microsemi need to keep secrets. They already know eachother's "secrets", and the FPGAs themselves are rather trivial devices. They're closed source not because users want them to be; again they couldn't care less. They're closed source because the userbase is absolutely tiny. A small userbase means we will only ever see tools that are sufficient. There is no benefit to Altera/Xilinx/Microsemi to put in extra time and effort open sourcing their work. And honestly, I wouldn't want them to. I'd rather their time and resources go into continuing to drive the price down and features up (as does every other company).

Not that I don't think opensource toolchains/devices wouldn't be great. I follow the MiGen/Milkymist mailing list where some open source FPGA tools are being developed. But in the commercial space, open sourcing FPGAs and their tools isn't the highest priority.

Going back to protecting designs, that's what bitstream encryption is for, which all modern FPGAs possess. Though Altera was quite late to the ballgame on that front with their Cyclone series...

Sure the fpga companies don't want anybody to know how to build their software. Building good fpga's is not that hard(if you're intel, or quallcom or any other of the big guys). But building good, efficient software is very hard, takes decades and tens of thousands of customers designs to run it on.

When you say 'good, efficient software' i wonder if you are talking about Xilinx ISE/Vivado, or any of the tools from their competitors. I can not imagine you are.

Have you noticed anybody else with better software and chips ? no ? maybe because it's extremely hard to to get to the level of ISE and the competitors ?

Well Quartus isn't bad. It will be interesting to see what Intel does with it. They have a history of open sourcing things other folks don't want to open source (like Graphics Drivers).

'get to the level' of ISE... I disagree. I do not want to build an IDE. I want an open toolchain, the thing that the ISE interface calls. There is some math in there that takes certain skills to implement, but I know several people who could do it if they had the layout of the chips. MAYBE the reason there are no open toolchains 'on the level' of ISE and competitors is not because Xilinx has some amazing secret sauce and is instead because the whole industry is caustically secretive and horribly anti competition.

This feels like circular logic to me. We do not want the hardware companies spending time 'open sourcing' their docs because they need to spend that time and money 'making more features' which they wouldn't have to do alone if it was open, but we can't have it open because spending the time and money 'open sourcing' their docs......

I think there is a big difference between 'users wanting tools to be closed source' and 'users not caring if their tools are closed source'. And I would argue that even if the primary user base does not care, we can do better than that. It is no excuse to use these fragile lumbering behemoths of bad design and super seeeeecret tricks that you can learn in a university or the internet. And history keeps showing the problems of big black boxes with the words 'trust us' written on the outside. All we need is the layout and a map of the bitstream and open developers will do most of the work for these companies.

As for spending their resources 'driving prices down', that is quite relative. And if you look at the pricing model of their software it is clearly not their goal to make that reasonable (at least Xilinx). And every version of the software stretches to provide arbitrary bullet points on the back of a box that either mean nothing, were tested in suspicious conditions, or conflate multiple optimized tests together and say 'we are better than everyone at everything. How many times will that be said by all competitors at the same time, and how many times will it be believed? Anyways, with all those features, somehow ISE is still unstable on windows.

>>> which they wouldn't have to do alone if it was open

Well, that's an assumption. User base is very small, and potential contributors base is even smaller. So that would be a big bet hoping that someone would contribute to make it worthwhile.

However, your statement is true when it comes to more mainstream technologies like ruby or javascript.

But each company has it's own tools. That means redundant development. If they just worked on one set of open source tools, it should reduce development costs. It also opens the door to researchers to try things directly in the mainstream tools. That means not having to re-implement things published in papers, but instead deciding weather or not to merge a feature from a branch.

   > I'm not sure what ChuckMcM was trying to argue.

If you create a circuit board which has all of the same chips as someone else, if you've changed the layout, you are completely within your rights to sell it as your own and keep all the money.

However, if you copy firmware, then creating a circuit board with the copied firmware is a copyright violation and you can be found guilty of copyright infringement at most of our trading partners.

For folks who built cloned CPU boards with a copyrighted BIOS they re-implemented the BIOS in a clean room to have their own "work alike" version, which then gave them the right to sell their boards.

If however you copy an FPGA bitstream, which is the compiled output of a copyrighted HDL description, you're in violation. But building a 'clean room' implementation of an FPGA bitstream is generally infeasible as it requires you to both know how the manufacturer encodes and encrypts it, and all of the functions of the internal chip.

A really great example of this in action was that the recent flap over "clone" FTDI USB to serial chips, wasn't a clone of the chip at all. Instead the cloners used an ARM M0 CPU with a USB peripheral and a UART peripheral and a bit of code that responded in all of the same ways in which the FTDI chip (which was presumably an ASIC) responded. That 'workalike' implementation was only possible because the set of inputs and outputs for that system are constrained, and the only IP violation was the re-use of FTDI's VID/PID pair. If they had been forced to use a bitstream file for an FPGA they would be liable for up to $30,000 per copy, and jail.

Some people have been preventing cloning by locking their bitstream to the FPGA's unique serial number, which exists partly to allow people to do this. This is trivial to work around if you know the bitstream and device internals.

I disagree that it is trivial. If we know what bits of the unencrypted bitstream do what, and have a cryptographically secure way of signing the stream, then GLHF with that. If it turns out that documenting the parts of the chip required for configuration makes the black box security not work, then it was crap security and provided no real security to anyone. As it stands there is no way to tell and we have to take the smiling sales guy's word that it is "SUPER secure, promise".

A big reason why the fpga companies keep everything secret is to protect themselves against patent lawsuits (exactly as gpu companies). So once again we can see how the patent system is good for innovation....

I am OP

Hmm, that is actually a good point. Might as well not draw any attention to yourself incase some ass hole has a patent on the concept of moving electrons down copper or something insane.

Having done my graduate studies in FPGA architecture and software, I can definitely see where the author is coming from. In fact, it seems like the entire hardware development industry has to face the issue of most tools being closed-source. Although I don’t have a solution for the technology specific phases (Place and Route, Bit Stream Generation, etc.), I am actually part of a company that is trying to help solve this problem higher up in the tool chain.

One of the biggest barriers to developing EDA (electronic design automation) software tools is knowing all the nuances of the various hardware-description languages like VHDL, Verilog and System Verilog. We learned this the hard way through our previous startup (later acquired) which built a hardware verification tool.

I don’t want to be self-promoting here, but in case anyone in this thread is interested, we are building a platform called Invio that lets you build your own EDA tools. We try to solve more than just the language support side of things and all of our platform’s inputs and outputs are open standards: Python, TCL, Verilog, SystemVerilog, VHDL, etc. You can look at my profile to find more info, or google “Invio”.

Do you have an offering that would allow me to code up a SystemVerilog->Verilog translation script on a hobbyist budget? I'm stuck coding for my SP605 in Verilog (or VHDL) but I would really like to be able to use structs and interfaces from SystemVerilog.

Coming from software dev it's insane: The $500 devkit doesn't support structs and I would have to pay $1300 to get one that does. Meanwhile C has had structs for 40 years... :(

How about using VHDL and records? I think these are synthesizeable outside of ports. VHDL is a much better language from a software engineering standpoint than Verilog.

I know nothing about VHDL -- I vaguely remember hearing someone say it suffered from the same issue so I didn't pursue it. Thanks for the tip!

VHDL is more strongly typed than Verilog (I consider this a good thing). Sure, it's a bit more verbose, but the language is more expressive than Verilog - allows overloading operators, for example. A nice example of the advantage of VHDL over verilog is that there's a FixedPoint type in VHDL (as of VHDL 2008, I think) whereas in Verilog you're on your own to line up the binary points - very annoying.

I've had similar needs but couldn't find an existing tool, nor a parser on which to build. There are some open source parsers [0], but they don't seem to do preprocessing and hence lose a lot of context.

So I made a parser that might work for your use-case given some work:

https://github.com/svstuff/systemverilog

It works for some fairly big codebases, so I know it's not completely broken. I'm not very proud of the scala code, it's quite ugly in places. But at least there are some tests :p

[0]: this also seems active worth checking out: https://github.com/gburdell/parser

EDIT: added link to other parser.

Thanks, looks promising! My needs are pretty minimal at the moment but it will be both refreshing and educational to give this a go.

Duplicating all the DRAM wires at each and every level of abstraction was just hideous.

aninhumer was (and may still be) doing something similar-sounding with bluespec; you may like to talk to him.

I've been wondering recently how viable it would be to implement an FPGA-within-an-FPGA:

  * Create a model of a simple, open FPGA.
  * Create tools to support the open FPGA.
  * Synthesize the FPGA for an existing proprietary FPGA.
  * Install bitstream in SPI NOR.
  * Ignore the proprietary FPGA from now on - work with the open FPGA that's inside it.

Yes, it would be absurdly inefficient. However, you can buy pretty huge FPGAs for very little these days. If the ratio of host:target LUTs isn't too bad, and you can find constructs which synthesize efficiently, it might yield something usable.

Perhaps it could be a way of bootstrapping an "open" FPGA effort.

Amusingly the Xilinx license states that you are not allowed to use the bitstreams generated by their software in any device that they did not manufacture. This means if you implemented a xilinx fpga in an altera fpga, it would be against the agreement to program the inner xilinx fpga with the bitstream. The more you know!

You might be interested in the now defunct Meta-FPGA (MPGA) project, which attempted this exact thing:

ftp://ftp2.de.freebsd.org/pub/misc/opencores/ml-archive/archives/cores/0109/msg00019.html

The idea was to use the proprietary tools to produce a once off "meta-FPGA" bitstream for each device. From then on, the open-source MPGA tools would be used to synthesise, place and route designs.

The JTAG mess resonates with me. I probably have 10 different debugger dongles now and the higher end ones from GreenHills or WindRiver are pricey.

As to open FPGA tools, I think the main problems are:

- there's a ton of competitive advantage in the algorithms to generate the bit stream so Altera and Xilinx have no good reason to give that up until a viable competitor emerges

- FPGAs are usually in small to mid size designs so it's hard to scale up to the point where just selling the chips makes enough money

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.

In the microcontroller world, expensive debug dongles are essentially hardware keys for the software included. Lauterbach's[1] Trace32 for instance don't even have software keys, the license for their very extensive debugging software is stored in the dongle itself.

Another piece of software that isn't often mentioned in these discussions is the driver for the embedded flash memory inside parts. USB has quite poor latency (1ms) and flash peripherals require quite a few read-modify-write operations, which soon adds up. More expensive JTAG dongles can run these operations locally on the dongle, with USB just for bulk data transfers, or even download and run code on the target itself for even lower latency, greatly increasing download speed. Since this software needs to be tested for each target, requiring a physical chip to be bought, this gets very expensive to develop. Even a "cheap" dongle like the Segger J-Link has an incredibly long list of targets[2], and I suspect a substantial amount of the purchase price is in engineering and testing flash drivers for those.

ARM seem to be trying to solve some of these problems in the ARM world with CMSIS-DAP[3], an open standard for JTAG/SWD dongles USB protocol. It uses USB HID, so no drivers should be needed on any platform, and they have even created an Apache licensed implementation[4], which Freescale are now using in their FRDM boards.

[1]http://www.lauterbach.com/ [2]https://www.segger.com/jlink_supported_devices.html [3]http://www.keil.com/support/man/docs/dapdebug/dapdebug_intro... [4]https://github.com/ARMmbed/CMSIS-DAP

Very well written.

I had no idea some companies went so far as directly making their debugger the software key. That is intense but makes a lot of sense.

In the case of the Xilinx Platform Cable I wrote firmware to, they have a CPLD that does the JTAG writing of data, and a Cypress FX2LP handling the USB information. They use a quad buffered USB endpoint to let the PC load as much crap as possible into USB and in my experience the buffer fills up fast and the jtag work takes the time. Of course this is only because multiple 'pages' were preloaded, otherwise the delay to request more pages would be insane.

Are you talking about the flash driver for loading external SPI flash? If so you likely know this but you have to load the FPGA with a program to load the flash with the program you want the FPGA to load on reboot. Each of these programs have to be compiled and tested per chip. While looking through OpenOCD I found they had drivers for the actual flash, and I am not sure if this is required for the fpga flash boot strapper I just described.

I will look over these links. I recently started messing with ARM chips and they are programmed very differently than FPGAs so I have some stuff to learn on that.

>Are you talking about the flash driver for loading external SPI flash?

I was slipping into talking about ARM microcontrollers there, which have internal flash. Reads from it are memory mapped, but writes generally require feeding peripheral registers with commands, hence the latency sensitive read-modify-write. Some ARM microcontrollers do have more direct methods though, some of Freescale's Kinetis range have a feature called EzPort, where you hold a pin low on boot and it pretends to be SPI flash instead, and tiny 8 bit micros like the AVR all have something similar as full JTAG would be too big for them.

>If so you likely know this but you have to load the FPGA with a program to load the flash with the program you want the FPGA to load on reboot. Each of these programs have to be compiled and tested per chip.

Yeah, this is what I meant by having code run on the "target", this being the microcontroller you are programming. You are right in thinking this means the JTAG dongle no longer needs to know how to program flash itself, but it still needs to code to load in and instructions on how to do it (setting up clocks etc), which are also very platform specific. You could do the same for external flash, but its often easier just to connect to it directly and bypass the microcontroller.

Feel free to PM me if you have any more questions.

Xilinx's tools are horribly buggy. And they don't want to get bug reports from you anymore unless you're a top-tier account. So their tools are a shit-show and they don't want to hear about how they can be made better unless you're already buying a lot of their parts every quarter. I don't have any experience with Altera's tools to be able to comment, but I don't hear good things from their users either.

The only way around this is to create a completely open source FPGA architecture. Most of the basic patents have expired so this should be doable now (it wasn't doable 10 years ago because too many of the basic patents were still in effect). An open FPGA architecture is the only way we're going to get open FPGA tools. You'd think that if such an architecture were created that several semiconductor companies could then produce parts.

One of the major challenges in creating a competitive FPGA architecture is tuning the architecture. Commercial vendors do this tuning through direct insight into their customer's designs. And since the vendors have a large portfolio of customer designs, they have a lot of data points to perform this tuning. That's one of the many reasons why we haven't seen a successful FPGA startup in a long time (decades probably). Kind of like a chicken and the egg problem.

I'll offer a guess as to why the FPGA manufacturers are hostile to open tools. Open tools reveal the internal details of their FPGA hardware which is their bread and butter. I think it is probably the wrong approach, but that sort of thinking is common around intellectual "property."

I am OP

You are correct some of the information required to build a computer for these chips are 'internal' details. However they already have strict patents on most of it, and knowing the configuration bits of a chip and the the delay of various paths is not going to give away their fabrication technique. They could potentially release just enough details to satisfy compiler writers instead of making us do it ourselves so we try to rip every details out of it.

Often times there are clever optimizations and work around that have to be implemented to work around internal limitations that they don't publish so as not to give their competitor marketing advantages.

What we should be pushing for are cross platform tool. Being open-source isn't something that I necessarily would care about as an EE in this particular case. It doesn't get me anything I don't with vendor tools. The BIGGEST thing in FPGA/ASIC design is certainty. Error in the tool costs me time and money.

You'll find it difficult to convince anyone to a tool that isn't supported by the vendor because errors and bugs, in the tool or the tool data, won't get resolved quickly.

Most of the money in ASIC/FPGA is spent on "verification" either as pre-build/pre-tested cores or as tools that do verification, such as formal logic tools.

Hmm, that is a way I did not think about. Documenting hardware limitations for compilers gives competitors leverage for saying theirs is better because it does not suffer from X.

I understand that open source is not particularly important to you, but I am a bit more skeptical about the verifiability of a product that is all secret sauce and promises than I am about something with open check-able code and test suites. Open source software very rarely tries to hide its flaws to prevent a PR issue and then lazily fixed in the future because it is 'low priority', instead they are fixed by whoever can, verified, etc. There are always counter examples, but I thing the verifiability of the tool is in the same world and of similar importance to the verifiability of the output.

You do make a point in the catastrophic cost of a screw up when casting an ASIC though.

FPGA/ASIC interchangeable for the purpose of verification. There are two types of verification: A) does the post synthesis gate match my RTL B) Does my RTL do what I want it to do, i.e. matches the spec.

For B you have a whole host of third party IP, verification library, assertions, etc. that you can use

For A there are formal verification tools. They mathematically match A to B. There is no need for that tool or anything in the chain to be open.

Synthesis is complex and an optimized synthesis is very important. Timing closure is where a lot of this stuff comes to the forefront and that's the part that vendors won't release. That's their secret of what sucks in their chip, or what workarounds they have to use. You'll pry it from their dead cold hands.

As an engineer I don't care about their secret. I care about making sure that I don't have to chase down a synthesis bug and that their compiler gives me the most optimized, fast design. Synplify used to be a third party product that did FPGA synthesis (Synopsys bought them). They discontinued it, even though though they had full specs/details from Xilinx/Altera. The main reason is Xilinx/Altera tools are excellent. They know their chips better than anyone and for marketing purposes it is in their interests to give you the tool that does the fastest design, or smallest design. Otherwise you would switch to their competitor.

I love the idea of what OP is trying to do but it is a solution in search of a problem.

There is a bigger problem that an open source tool could solve and that is Verilog simulation. Currently we have Icarus Verilog but someone should improve it and add SystemVerilog support. Simulation is much easier to solve, since there is a spec to design against, and has many more users. There aren't good, inexpensive simulation tools. Simulation is as important as compilers. Imagine a world where gcc didn't exist and you had to pay to get a good compiler.

People will always stick to the big vendor for synthesis. I can't imagine a day that they wouldn't.

OP here

You are right that my particular project is not the biggest piece, but it is the part that pisses me off. I can deal with Xilinx's crappy compiler if I can program my chips with ease..... or maybe I should say UNTIL I can program my chips with ease. Then my focus will change hehe.

Icarus works but it has been maintained by one 'eccentric' guy for quite a while and the code base is semi unapproachable. I believe this is why the Yosys guys started from scratch.

You are also right that the place and route, as well as verification of the LAYOUT in the chip are super big problems. It is in fact what my friends toying with the compiler side are dreading dealing with because we have no idea the delays of individual traces in the chip.

I disagree that people will stick with the vendors tools. Open compilers dominate most of the Intel CPU market besides on windows since Visual Studio is the only thing that deals with all the quirks reasonably well. But the windows case is more of a lack of interest.

ARM compilers are more interesting to me because most people use Keil. Keil... works. But it feels crazy retro paying for a compiler. I believe the only reason that Keil is being used for most embedded ARM projects is there simply are not enough people with compiler knowledge using ARM regularly yet to pour enough work to make a better alternative.

But it will come.

And one day we will have synthesis tools for FPGAs that are comparable to the big guys or better.

I fully support the spirit of what you're doing btw. I hope you don't take my comments as somehow dumping on your work ;).

What is "crappy" about Xilinx tools aside from the UI? I'm genuinely curious.

I don't think the comparison between synthesis tools and compilers hold. They are different beasts. I think compiler equivalent is sim tools which should be open and free.

Everyone that I've talked to who uses Keil uses it because of SUPPORT. If they need something or there is a bug they know it'll get fixed. That's the ONLY reason anyone has EVER cited to me. It is not true that lack of alternatives is due to lack of knowledge. There just isn't a big enough market for it. ARM itself also makes all the patches for GCC tools. I use gcc toolchain as do many people.

Haha, not at all. I do not take it as an attack or anything :).

The UI is obvious. The inability to use most of the intermediate file formats for anything since they are secret formats is annoying. If I remember correctly it had dependencies on Java and Mono. The command line tools are archaic and very difficult to use even before realizing they are not documented out of the fear of giving something away about how anything works. The iMPACT for programming chips incorrectly loads the libusb.so file and has to be LD_PRELOADed on linux, but even then there is some weird race condition that makes it work 1 out of 4 times. In order to do anything you have to download and install 15 gigs of data and agree to aggressive licenses.

The compiler tool chain usually is a compiler and a linker. I could understand if you said that the place and route was more of a linker step, but people often call the full process 'compilation'. The fact that stitching the modules together and actualizing the equivalent of addresses and instructions (in CPU terms) is a physical fitting and box packing problem in an FPGA does not make it a fundamentally disparate step to me.

Wow, I did not know that about the ARM compilers. I must have got the wrong impression from forum posts on the use of GCC for ARM chips. That makes me pretty happy, particularly that ARM is helping with the open tools. I will say though that this feels like it is supporting my point because people are using the non vendor tools. If support is a concern, support is not something that only a big company can provide. Postgres provides support and adds features on auction. I will admit that the responsiveness of Oracle for their customers having a need is much bigger and more organized, but it better be for what people pay for that. With the Oracle example, I think I am leaning towards 'there will always be room for a proprietary solution to handle edge cases of a market' instead of open solutions will not work as well as proprietary ones and are unable to be the defacto standard.

Xilinx iMPACT (the FPGA programmer) bugs:

On one version, it can load the project it saved, but then crashes when you go to program. So you have to scan and reload all the data files every time you start it.

Later version, failed to program the chip at the last stage of the process. Diagnosed that over phone tag where the user was non-technical and on a machine not connected to the Internet. Exact same chip as above.

Another later version has different iMPACT bugs than that first version above, but right now I haven't been able to get it to work on any Win 8.1 machine so I don't remember which bugs it has.

You have to change out a certain DLL for POST windows 8 in order to get ISE to behave and not crash randomly. YAY! Xilinx said they didn't care but somewhere on their support forum there is some kind soul who said what dll to rename (they have two versions of the DLL in the install anyways but they did not use the win 8 one by default and refuse to patch).

This is entertaining. I've used Xilinx's tools for a while, almost exclusively on Linux (CentOS usually). I thought that renaming/symlinking libraries to get things to work was something only Linux users needed to do, and I figured this was just because Xilinx tests more on Windows (makes sense). If these kinds of problems also affect the Windows versions, then, I don't even know what to say. At some point you just can't make excuses for this stuff anymore.

One nasty little caveat is that Xilinx's tools will not synthesize certain elements, such as state machines, in the way you've written them for performance reasons. Caught me out - I was trying to use an open source design someone else had created with Synplify, and it used a Grey-code state machine to cross between two clock domains. Xilinx's synthesis tool replaced it with a one-hot state machine which was not safe for this purpose and worked for a while then randomly wedged itself. To be fair, the synthesis log did mention this in amongst the huge pile of other messages.

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.

That's basically the same reasoning used by most GPU manufacturers, but two of the biggest players in that market have chosen not to act that way and don't seem to be suffering at all for it.

Companies seem to be terrified of trying anything. That is why I was happy when Sony put The Interview up on the internet and theaters for simultaneous release. No one would try that first, and since it worked ok for them it is now an option other companies may consider. Even though both GPU companies and FPGA companies are in hardware, they do not see strategic experiments like opening documentation in the other to be sign of viability for themselves.

They also invest a lot of money into the software tools and frankly what you can accomplish with the free ones is light years beyond what the full paid tools of 15 years ago could do. Having to compete against an alternate free toolset diminishes their value derived from that investment.

The tools for FPGAs are horribly clunky and extremely difficult to script since most are Windows GUI based.

Glad to see people working to rectify this.

Indeed. It's unfortunate that they need to do their work in spite of the companies that make the hardware.

Actually I would like to get involved in that. What are the IRC channels referenced in the post?

Sadly it is private. It is a channel for reverse engineering silicon devices. If you are interested and you hang out in IRC channels for microcontrollers, FPGAs, etc, and ask the right questions you may get an invite.

I haven't had problems scripting the Altera tools. We use make on Linux to build things for the Daisho project[1]. Or were you thinking of something more advanced than that?

Having said that, I'm 100% in favour of open tools. I think the current tools are one of the biggest barriers to the use of FPGAs. I also think that they cause a lock-in effect for developers, which hurts FPGA adoption as a whole.

[1] https://github.com/mossmann/daisho/blob/master/sw/fpga/targe...

Not just FPGA tools, pretty much the whole EE industry.

Few days ago I had trouble saving results from a semiconductor analyzer. The problem? Path had spaces in it. If you have the time to display a warning that it doesn't support spaces (on windows!), you should be able to fix the issue. Just imagine how bloated their codebase that you can't fix issues like this easily.

Recently I was trying to use ModelSim (HDL simulation tool) on a Linux machine, which unfortunately was not running a 10 year old distribution. It was failing with obscure Tcl/Tk errors :). Should have known better not to waste my time. Reinstalled it on a windows machine and now it was having problems connecting to our license server so I had to use a crack from a Chinese BBS (ugh).

I really want work to be done in this area, but one of the giants will either sue you into oblivion or make an offer you can't refuse. Either way nothing productive will get done... :(

Tcl script errors on Altera tools - brings back lots of bad memories... It seems like as soon as you try to break out of the standard way of doing things the scripts break.

These codebases are often sub-contracted to the lowest bidder. Which explains all of the issues that everybody has on a daily basis. Sadly, hardware is a race to the bottom, and there is little motivation to provide quality tools.

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.

Hardware engineers are often the worst when it comes to writing software. It's not that they're technically incompetent, but that their priorities are inverted.

Hardware is often hard if not impossible to change. Software is expected to change, or more importantly, to be able to be changed by the developer. Applying a hardware mind-set to software is a constant source of irritation.

Lol. I used to work in HW.

You are kind of insulting but it's true: we take what we can get. I am not sure what you are suggesting HW engineers do.

Who has time to build a better tool? That's a massive task. When you are on a project, you work on delivering it.

Projects fork out several thousand dollars for tools licenses because revenue for the finished product is in the millions of dollars.

The Xilinx tools are crap. But you just work around them. 95% of HW engineering is fixing the actual design. It doesn't matter that much how good the tools are.

It's like asking a truck driver to build their own truck. They're paid for getting stuff from A to B on time.

> 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

Is that seriously how Vivado HLS works? Now I'm glad I decided not to buy it.

How well HLS does highly depends on the source code (this is in general and not specific to Vivado HLS). If your code is a simple loop over an array and you add a vendor-specific #pragma directive (such as #pragma unroll) the tool will unroll your loop and extract the parallelism from there. This actually works quite well in practice for regular DSP code (like FIR and FFT) and floating point. Anything else is another story though.

The thing is that unless you're writing your code as the tool expects it, with the proper pragmas etc. there's no way it can be transformed to fast hardware. A way around that is for vendors to ship "customizable IP" kind of like Altera's Megafunctions... so much for portability and high-level.

I'm not sure which tool OP is referring to though, I remember Altera had a C2H tool that they discontinued in favor of their OpenCL SDK.

ModelSim isn't even the most clunky FPGA-related tool I've used. That honour has to got to Xilinx's FPGA Editor, which has been ported to Linux using some ancient, proprietary Motif-based Windows API compatibility layer with a whole bunch of interesting issues running on anything other than the approved RHEL version.

Some of the Xilinx and Altera tools come with and install Cygwin (and tcl). Watching WINE install Cygwin is good for a chuckle.

The Xilinx tools are all over the map. It looks like some of them were developed in Tcl others in C and C++. Some on *nix others on Windows. It's quite a hodgepodge.

Oh god i never noticed that! Maybe it does not install when running the native linux ISE.

>Maybe it does not install when running the native linux ISE.

Quartus II does, I just checked. IIRC ISE does it too. Can't check that one for you right now though.

Posts like this make me happy I didn't get that "dream" job from Altera back in the day and got pulled into software. Closed tools, expensive proprietary equipment to get started, hostage to large vendors. I dodged a career bullet.

Those jobs also pay you to sell your ideas that you are never allowed to use again unless you continue working for the company you sold it to. And if you have the gall to use your own idea, lawyers!

Wow. The beatings just continue. I was headed straight into the worse engineering subfield for starting a company, economically as well as legally.

First, just wanted to say that I find this topic really interesting. I'm trying to understand who the target user is for open-source FPGA tools.

For many hardware companies, the risk of using an unproven tool is too severe. Unlike software, you can't just push out a patch if there is a bug. I mean, in theory, I guess you can since FPGAs are reconfigurable, but it is probably not very straightforward from a deployment point of view (I actually don't know so feel free to correct me).

So, since you cannot push out fixes easily, it's quite scary for the engineering teams to work with unproven tools. For the consumer electronic space, product life-cycles are quite short (mobile phones get updated every year!). So you definitely don't want to risk cutting into your product's time-to-market due to bugs in the FPGA tools.

Also, the bigger the company, the more likely that they will have high-priority direct-support from the FPGA Vendors. Whereas, it's probably harder to get support for open-source tools. So I can't see consumer electronic companies choosing open-source tools.

So again, I'm not against this work at all! Just trying to understand the target audience.

OP here

I get there is a big difference between hardware and software, but I feel that certain parts of the gaps are closing. They will not CLOSE, but as they get closer we can learn from each other.

With that said, to address your point: Linux is one of the most dominant systems for servers. Google, Facebook, Twitter, etc use it for almost all of their backend systems. They use it not just because it is free but because it is proven and scalable. Open source databases and web servers also enjoy considerable (sometimes dominant) share. There are companies that provide support contracts for Linux (Suse, Redhat) and that model has worked to fund other open software.

So I think that establishes that a company will use open software.

As for being scary, you are correct that is a primary decision making motivation. It is why many professionals in tons of industries still run windows XP. Often they NEED XP because the software they rely on is so dependent on that specific ecosystem that huge rewrites are necessary in order for it to work on anything else, and this work (even if done by the original distributor) will take years for the tools to be stable again. This is not good engineering on the part of the tool designers. The crippling fear of NEVER TOUCHING ANYTHING is something that the open software alternatives seem to be alleviating in corporate environments since the late 90s.

The lifecycles of putting a phone together is much faster than Intel designing a processor, or Xilinx designing a new FPGA. building boards in phones and laptops is a complex game of Lego and placing them around so the timing diagrams work in all expected use cases. And if the timing does not work in some cases, whatever, people get a phone a year. Hell on my Galaxy S3 Verizon said 'oh yeah that is a known issue where sometimes the GPS just does not work because of loose wires, that was fixed in the S4, I think, which is only $$$.'

You are also correct about direct support from the company. In face make Xilinx enough money and they will share their secrets with you. But I am more targeting small to medium development. If open tools become popular and stable enough to get market share in hobbyist up to medium sized companies, it will only be so many years before bigger companies hire new engineers who grew up using open tools and have no patience for tools that have to be emulated in windows XP and have 35 nested sub menus for enabling a feature.

I do not feel attacked at all. You brought up interesting points. I hope i did them justice and did not ramble since there were a lot of points to hit.

>(I actually don't know so feel free to correct me).

Okay, I will :) Many FPGAs load their program from a SPI chip on board, which can't be reprogrammed. However, it's increasingly common for another microcontroller or SoC to be on the same board. In this case, it's cheaper and more convenient to store the FPGA bitstream on that controller's flash and send it over SPI to the FPGA on powerup, which makes upgrades much easier, too.

On the Xilinx Zynq, a FPGA containing two Cortex-A9 cores running Linux, you can simply cat your bitstream to a character device to reconfigure the FPGA.

>I want to pave the way for FPGAs to be usable in everything from laptop/desktop computers to phones (if the static power consumption gets better). I have some very interesting ideas of what an average user could do with in system FPGAs that can be reconfigured at runtime.

What are these ideas?

I can't speak for OP, but my interest is in signal processing. DSP and FPGAs are a great match and with the boom in software defined radio, having reconfigurable DSP capabilities is extremely useful.

For example, if 802.11b devices had been built using FPGAs, an upgrade to 802.11g could have been an OTA update. Or a new Bluetooth variant emerges (e.g. BLE) and support could be added to computers and phones overnight.

For these applications it's useful to think of an FPGA as a chip that you can patch, upgrade or reconfigure for new applications. However, looking at it from another angle, we can think of it as software that isn't limited by the CPU architecture.

This second category opens up the possibility of crypto algorithms that don't suffer from the timing attacks that they do on the CPU. Or a video codec that can be designed without having to worry about which extensions the CPU supports.

I'm sure there are much better examples and some of these are bad ideas that would work better on a CPU, but hopefully that gives you some ideas.

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.

SDR uses orders of magnitude more power than an ASIC implementation which is why no one uses them except for base stations -- such as cell towers.

FPGA based design for crypto would have the same timing attack as CPU. It can be worked around the same way it would for a CPU.

Sure, ASICs are always going to beat FPGAs and CPUs in power consumption for the same task, but there are also applications where the ability to update the system far outweigh the power requirements.

Interestingly, SDR is being used for the UK's small scale digital radio station trials this year. Off the shelf SDR hardware appears to be performing well enough at a lower cost than bespoke DAB hardware. Again, this fits in with your base station category.

You're right about timing attacks, I have no idea what I was thinking there. Would they be better for power analysis attacks? I guess if we're concerned about that then we'll end up back at ASICs again.

FPGAs ARE ASICs :) Just a special case of ASICs. The fabrication and processes are the same. There is no advantage of one over the other.

FPGAs are more vulnerable in some ways than ASICs because someone could steal your design and duplicate it much much more easily than an ASIC.

A lot of crypto chips have built in protection against many side-channel attacks.

I am replying to this comment instead of the multiple people under it.

You guys are right that FPGAs are not quite ready, or maybe will never be ready to be the primary radio for a phone because of the static power consumption. You could still have one available for certain burst operations that need to be highly accelerated. Good point about the timing attacks on crypto, but hardware crypto can be updated within an FPGA. This can be seen as a pro and a con to security.

OP here

dominicgs had some good ideas since software defined radio is very powerful. One extreme example of something you could do with a reconfigurable radio signal processor in your machine is install things that the FCC would not let be produced and sold. For example if someone reversed the military high accuracy GPS stuff, and produced a verilog spec anonymously so he was not sent to prison forever, no one would be able to use that to produce chips in consumer devices. But if we found verilog and wanted military GPS on our phones, all we do is install software.

Another example some friends have been excited about is emulation of older hardware, including video games, but much more. I will describe old games since they are closer to people's hearts. All the old cartridge based games had the actual cartridge contain half of the hardware needed to make a full computer. This immediately complicated emulation. But the real issue comes from quirks in the actual hardware. This is an issue because developers had no API except the exact hardware specifications that every console had. No one worried about checking their clock frequency was correct and dividing it to the right point so they got a certain framerate... everything was constant. Developers would find and exploit undocumented glitches in the hardware to make things faster, or sometimes to make them run at all. Hell, some games used the difference in clock frequency between two internal chips as a source for PCM sound to make little bleeps so they could save code. For this last example this means that unless you are emulating to the clock cycle each of these chips and sometimes their exact internal structures, some game will not work or crash randomly. The CPU power to do this is insane: a 3GHz core was the minimum suggested processor for running a highly accurate NES emulator in real time.

FPGAs let us implement the actual system, bugs and all, in hardware and not worry about CPU usage. Give the fpga a blob of shared memory for writing video and PCM data to and the CPU just passes blobs of memory between devices.

Programs like Postgres could implement highly optimized methods of certain algorithms like hashing for looking up in an index.

The kernel could detect it has FPGA space and offload some of its work to the chip.

I hope these have sounded interesting.

I'm personally interested in your comment about Postgres, I have been thinking about implementing digital circuit versions of certain database operators to see if FPGAs can be used for distributed, parallel processing of data streams. I think there is a fit for digital versions of analog circuits to substitute for software operators (if that makes any sense - this is pushing my knowledge level to the limit). I've seen some amazing related work at MIT here: http://people.csail.mit.edu/wjun/papers/fpga2014-wjun.pdf

In the future if my tool for loading the chips works and is adopted, I hope to define an interface for using FPGAs directly in the computer similar to how OpenCL defines an interface for GPUs. Hopefully I would not follow the shit show that occasionally is the Chronos Group.

Some people will say that there are already pcie cards with fpgas on them and that this is not a new idea. But the issue is that existing cards like Digilent make are there for building pcie card designs. The FPGA (usually one) on the board has to implement the pcie fabric plus whatever it wants to do. Imagine if when you write an OpenGL/CL program you had to deal with all the DMA work and quirks of the underlying setup. Instead the grid of fpgas should have standard ways to access certain mapped regions of memory through a different chip that handles the PCIe transport layer stuff. If this was available then adding FPGA support into POSTGRES would not require bypassing the HAL of your kernel or worrying about timing details of something fundamental to modern computers (and thus software engineers) like PCIe.

Obviously the FPGA is still something that is hardware specific, but who knows what could be done with that. Even if we had to Synthesize from raw HDL every time, at least loading the chips would WORK. We could start using these chips to solve problems instead of thing slike a one off project by an EE major to build a grid of FPGAs that process bitcoin. The bitcoin work was impressive but it bothers me SO MUCH that they used reconfigurable devices to build a solid card with a fixed function.

But you can buy fpga boards with pcie bridges, doesn't it solve the problem ?

http://www.dinigroup.com/new/DNK7_F5PCIe.php

Also the main problem that prevents fpga's being used for all kinds of cool stuff is that it's really hard to program. And many companies are trying to solve it - yet without great success.

And to solve this problem(in a decent but not in the most efficient way), one doesn't have to have the internals of the fpga, no?

Would somebody knowledgeable care to comment on how tools like Bluespec SystemVerilog play into this discussion if at all? Disclaimer: I know little enough about EE that this question might be nonsensical.

SystemVerilog is a Hardware Description Language (HDL), which is what the first step in the process. The HDL synthesis is the level just above the part of the process where the major tooling issues referenced exist, since synthesis generally isn't specific to a particular chip vendor and, as noted, is also a necessary step before laying out an ASIC.

Several friends complain about the arcane nature of verilog and vhdl and like the idea of better languages written by actual language designers. But since the steps of FPGA compiling first converts the HDL language into a netlist which is used for all other operations, once a tool chain exists we can just replace the verilog compiler with a VHDL or bluespec compiler and everything will still work.

Open FPGAs would be disruptive to the status quo, that's why they are closed. Right now many technologies like video cards are wandering in the desert, adding on more and more opaque layers rather than providing general purpose computing. So that's set simulation back at least a decade or two and hindered progress in fields like AI.

I just want to address one of the main complaints about FPGAs - that they require more chip area to route logic. This is not as big of a deal as it sounds because today 3/4 of a chip's area or more is often dedicated to mundane things like cache.

Also since there has been little progress in breaking the 3 GHz barrier since the early 2000s, everything is moving towards higher transistor counts. So the added cost of layout goes down over time and after about 3 years is on par with the previous generation. So we have a chicken and egg problem where true general purpose parallel computing can't get off the ground because it's perceived as too expensive, but it's too expensive because it hasn't gotten off the ground yet.

Breaking that chicken and egg cycle by opening FPGAs could trigger an overnight adoption of them, even greater than when Bitcoin triggered renewed interest in ASICs.

About @diamondman's Adapt Framework (github.com/diamondman/adapt)

Adapt is an open, modular framework which offers a streamlined approach for JTAG controllers to speak to target devices (currently CPLDs and soon fpgas).

Adapt is built to be extensible and currently includes open/reversed drivers for the following Controllers and target devices:

- Digilent & Xilinx PC1 (JTag Controllers) & XC2C-256 (CPLD)*

*Note: Map files are required for CPLDs to avoid legal recourse

FEATURE ROADMAP:

1. Support for Controllers: Currently Adapt only supports JTag but @diamondman intends to support dbw & spi. Patches for other serial protocols are welcome.

2. Support for Target Devices: The next milestone is to support Spartan3 & Spartan6 fpgas

3. Extending Adapt / Contributing Drivers: Adapt can be extended to additional controllers and target devices -- @diamondman will write a tutorial on how this is done + what the limitations are, if there is enough interest.

Please express interest in driver support by replying to this comment thread.

So why aren't these targets for OpenOCD instead of a new system?

@diamondman responded to this in another thread: http://www.reddit.com/r/programming/comments/338t25/the_lack...

"I actually want to hook OpenOCD into my Daemon to bring some sanity to how it manages devices. Several of my IRC friends prefer using closed source tools to open OCD calling open Obsessive Compulsive Disorder, frustrated the license is so strict (mine will be LGPL), and annoyed that everything has to be exhaustively specified in TCL files for it to do ANYTHING."

The TL;DR is OpenOCD's driver model itself is fixed/limited/standardized to a degree which prevented him from, in many cases, optimizing underlying controllers (or getting them to work at all -- e.g. OpenJTag, I believe). Also, see licensing disagreements above + unreasonable configuration requirements outlined in @diamondman's answer above.

Thinking about this topic some more, it seems hard to gain the critical-mass of contributors for such an open-source tool.

Place-and-route for example, requires a very specific set of knowledge in both optimization (comp-sci), and hardware (electrical). Most of the people who have these skill sets are probably already employed by the major FPGA vendors and under NDA to not contribute to such an open-source tool. I've seen this first-hand having been in the academic space of FPGA research. New masters and phd grads typically go straight to Xilinx or Altera. And without really really good place-and-route, you won't have a competitive tool.

I'm not sure how you would solve this problem.

OP here

This is a severe problem that saddens me greatly. For now I am just writing tools to make JTAG/SPI/etc loading of chips Ubiquitous to the developer writing software/netlists for them. I do not know enough about the place and route math and routines, nor have I seen enough details of real life chips to know the types of real challenges faced. But I will cross that bridge when I get there (maybe it will be someone else :)).

I personally have a huge issue letting anything fundamental I figure out be marked down as the property of a company to have and hold for 20+ years. But I understand the financial rewards and interesting problems are more than enough for many people, so I can not hold it against a student with a PHD worth of debt to need cash. Sigh.

Hopefully if a good enough extensible base exists, people will add pieces on (whatever they can get away with) over a long time. That is all I can really hope for.

Delete the "A" from the first link to see the referenced comment thread: https://news.ycombinator.com/item?id=9388751

fixed thanks

I have done a lot of GPU programming, and interested in looking into FPGA for low power solutions. Will this situation improve with the release of OpenCL support?

OpenCL support for FPGAs is super limited and only done through vendor specific tools. The point of these tools is more to LET you write your FPGA program that runs outside of a desktop computer in OpenCL than it is to make an FPGA be able to speed up your OpenCL program running on a desktop. So it is not like 'I will pop in a new FPGA card so I can play better games.' Though that is what i want to happen in the next...... lets say 5-10 years.

You're confusing OpenCL with high level synthesis (HLS). OpenCL is explicitly a platform for software developers. It targets accelerator boards attached to a host (via PCIE), just like GPGPU.

https://www.altera.com/solutions/partners/opencl-board-partn...

FPGAs are certainly not known for their low power consumption. Especially for something like an OpenCL workload, you'd probably do much better with a vector processor architecture, like on GPUs.

Hmm? FPGAs, in most cases, consume significantly less power than GPUs, unless GPU technology has caught up in the past year or so.

This is the opposite of my experience (assuming the same performance level). Though I consider FPGAs and GPUs mostly cut out for vastly different purposes. I unfortunately can't find a good reference to back this up because very few people do FPGA to GPU comparisons with anything more than a trivial FIR filter or FFT.

Is is actually a good idea to reverse engineer the internal structure of FPGAs since the manufacturers likely won't disclose their proprietary knowledge ever?

The question is, do we really need FPGAs? What about emulating FPGAs in GPUs? Or using massive parallel chips like Parallela or GreenArrays GA-144 (Forth) to simulate logic gates? Such architectures are usually much more open than FPGAs.

Things like GPUs and Parallella are great, but it would still be great to have an open FPGA architecture. Some problems don't map all that well into a GPU, but would be fairly simple to map into an FPGA to get huge performance increasese. Also, a GPU comes with a computer and that tends to be large and power hungry. Often times an algorithm can be implemented in an FPGA which can run on 5W and fit into a package the size of a deck of cards.

I can't see how you could possibly create an FPGA from a GPU, whereas you could/can create a GPU from an FPGA, for example Altera have OpenCL running on FPGAs, and also people have implemented GPUs using an FPGA.

Note that Altera's compiler for Open CL does not let you run your OpenCl stuff faster. It is intended so you can write your FPGA programs (that run outside of your computer usually) in OpenCL. Most of the imagined benefits kind of vanish, at least to me, when you realize that this is just a tool so if all you can hire if OpenCL developers, you can still get the job done.

I get the idea you are aiming for, but this will not work.

GPUs are vector processors. They are good at certain types of repetitive unrelated (parallel) math. They can be good at simulating physics since physics is described with matrix math.

You could simulate the gates in a chip, though this is a MASSIVE problem and will tax the GPU for meh results. If you decided to simulate a chip in a GPU, simulating an FPGA would be quite pointless since FPGAs are less than optimal so they can be reconfigured to implement (not simulate) different chips.

This would be like running a Sparc emulator in a Java VM implementation of an Intel VM... mabe throw javascript in there somewhere. Each level of emulation, simulation, or implementation robs resources.

Yes those architectures are more open but they do not do the same thing. More work with those setups so, say, Postgres can offload certain math to the GPU, is great and should be done. But this is somewhat different than FPGAs (though in the same spirit).

CPUs, GPUs, and FPGAs all solve different types of problems very well. But they do not run each other's problems well, and certainly do not implement each other super well. Well, with one exception: you can build a reasonable GPU with shaders in an FPGA, but this is not to out perform the FPGA it is implemented on in a task. If you hardwired the FPGA to run the equivalent operations of a shader in OpenCL running on a GPU implemented in the same FPGA, the FPGA would win hands down.

I'm still reading above the level I currently understand when talking about FPGAs and chips and such… but how does Bunnie's Novena[1] factor in to all this?

[1] https://en.wikipedia.org/wiki/Novena_(computing_platform)

An interesting talk on "How to Build an Open Source FPGA toolchain" was presented at the Open Hardware Workshop a few years back: http://www.ohwr.org/attachments/821/sebastien.pdf

I'm not the best FPGA engineer out there, but I am relatively educated. I agree that most of the tools suck, but I'm quite impressed with Vivado. Xilinx has really upped their game there. Does anyone have any experience with it, and if so, do you agree?

Vivado is good and bad. Vivado's schematic and device views are much better than the earlier FPGA Editor et al. The interface for adding Chipscope debug signals is quite nice.

However there are lingering bugs. The hardware manager crashes a lot if you don't handle your debug nets carefully. My colleague had an issue with constraint priority. I _think_ I've encountered an issue with VHDL synthesis being incorrectly cap-sensitive, but I never bothered to make certain.

Overall it's getting there. The Zynq stuff is neat (once you understand what's going on) but I have some misgivings about the push toward IP cores.

Yeah, I'm not a huge fan of IP cores, but they have their place. The biggest thing that I'm a fan of is the push towards standard TCL methods for everything Vivado does or touches. That's the difference between UCF and XCF. I'm also under the impression, but don't have the experience to say for sure, that there's supposed to intermediate files for every design step and that the command line interface is better documented.

I am very impressed by the Zynq stuff. I'm particularly looking forward to seeing people using it for accelerators and such.

Reply on news.ycombinator.com