11 ms·

The Lack of Open Tooling for FPGAs

230 points by cgag 12y ago

elevensies 12y ago
Delete the "A" from the first link to see the referenced comment thread: https://news.ycombinator.com/item?id=9388751 https://news.ycombinator.com/item?id=9388751
- deleted 12y ago
  [deleted]
- cgag 12y ago
  fixed thanks
astrodust 12y ago
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.
- vonmoltke 12y ago
  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?
  - diamondman 12y ago
    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.
- dominicgs 12y ago
  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/targets/common.mk https://github.com/mossmann/daisho/blob/master/sw/fpga/targe...
- kornholi 12y ago
  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... :(
  - zwieback 12y ago
    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.
  - bliti 12y ago
    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.
  - diamondman 12y ago
    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.
- fnordfnordfnord 12y ago
  Some of the Xilinx and Altera tools come with and install Cygwin (and tcl). Watching WINE install Cygwin is good for a chuckle.
  - UncleOxidant 12y ago
    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.
  - diamondman 12y ago
    Oh god i never noticed that! Maybe it does not install when running the native linux ISE.
    - fnordfnordfnord 12y ago
      >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.
goodcanadian 12y ago
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."
- diamondman 12y ago
  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.
  - bravo22 12y ago
    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.
    - diamondman 12y ago
      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.
catern 12y ago
>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?
- dominicgs 12y ago
  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.
  - sliverstorm 12y ago
    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.
  - bravo22 12y ago
    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.
    - dominicgs 12y ago
kristoffer 12y ago
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....
- diamondman 12y ago
  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.
zackmorris 12y ago
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.
skwuent 12y ago
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.
- vonmoltke 12y ago
  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.
  - diamondman 12y ago
    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.
zwieback 12y ago
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
- diamondman 12y ago
  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.
  - snops 12y ago
    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/ http://www.lauterbach.com/ [2]https://www.segger.com/jlink_supported_devices.html https://www.segger.com/jlink_supported_devices.html [3]http://www.keil.com/support/man/docs/dapdebug/dapdebug_introduction.htm http://www.keil.com/support/man/docs/dapdebug/dapdebug_intro... [4]https://github.com/ARMmbed/CMSIS-DAP https://github.com/ARMmbed/CMSIS-DAP
ChuckMcM 12y ago
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.
- wolfgke 12y ago
  > Note that Xilinx did make an "open" FPGA part, the 3000 series, it did not do well for them. Could you provide further details?
  - ChuckMcM 12y ago
    http://www.xilinx.com/support/documentation/data_sheets/3000.pdf 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.
boxerab 12y ago
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?
- diamondman 12y ago
  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.
  - DrHoppenheimer 12y ago
    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-partners.html https://www.altera.com/solutions/partners/opencl-board-partn...
- TD-Linux 12y ago
  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.
  - hornd 12y ago
    Hmm? FPGAs, in most cases, consume significantly less power than GPUs, unless GPU technology has caught up in the past year or so.
    - TD-Linux 12y ago
      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.
progman 12y ago
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.
- UncleOxidant 12y ago
  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.
- deutronium 12y ago
  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.
  - diamondman 12y ago
    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.
- diamondman 12y ago
  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.
UncleOxidant 12y ago
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.
- scottchin 12y ago
  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.
scottchin 12y ago
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”.
- jjoonathan 12y ago
  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... :(
  - UncleOxidant 12y ago
    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.
    - jjoonathan 12y ago
      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!
scottchin 12y ago
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.
- diamondman 12y ago
  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.
scottchin 12y ago
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.
- diamondman 12y ago
  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.
pslam 12y ago
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.
- diamondman 12y ago
  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!
- femto 12y ago
  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.
aswanson 12y ago
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.
- diamondman 12y ago
  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!
  - aswanson 12y ago
    Wow. The beatings just continue. I was headed straight into the worse engineering subfield for starting a company, economically as well as legally.
mekarpeles 12y ago
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.
- voltagex_ 12y ago
  So why aren't these targets for OpenOCD instead of a new system?
  - mekarpeles 12y ago
    @diamondman responded to this in another thread: http://www.reddit.com/r/programming/comments/338t25/the_lack_of_open_toling_for_fpgas/cqiz0gh 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.
wcunning 12y ago
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?
- mng2 12y ago
  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.
  - wcunning 12y ago
    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.
alexweber 12y ago
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) https://en.wikipedia.org/wiki/Novena_(computing_platform)
anon_agin 12y ago
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 http://www.ohwr.org/attachments/821/sebastien.pdf

230 points by cgag 12y ago

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

deleted 12y ago
[deleted]
cgag 12y ago
fixed thanks

astrodust 12y ago

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.

vonmoltke 12y ago
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?
- diamondman 12y ago
  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.
dominicgs 12y ago
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/targets/common.mk https://github.com/mossmann/daisho/blob/master/sw/fpga/targe...
kornholi 12y ago
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... :(
- zwieback 12y ago
  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.
- bliti 12y ago
  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.
- diamondman 12y ago
  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.
fnordfnordfnord 12y ago
Some of the Xilinx and Altera tools come with and install Cygwin (and tcl). Watching WINE install Cygwin is good for a chuckle.
- UncleOxidant 12y ago
  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.
- diamondman 12y ago
  Oh god i never noticed that! Maybe it does not install when running the native linux ISE.
  - fnordfnordfnord 12y ago
    >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.

goodcanadian 12y ago

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

diamondman 12y ago
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.
- bravo22 12y ago
  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.
  - diamondman 12y ago
    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.

catern 12y ago

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

dominicgs 12y ago
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.
- sliverstorm 12y ago
  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.
- bravo22 12y ago
  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.
  - dominicgs 12y ago

kristoffer 12y ago

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

diamondman 12y ago
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.

zackmorris 12y ago

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.

skwuent 12y ago

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.

vonmoltke 12y ago
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.
- diamondman 12y ago
  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.

zwieback 12y ago

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

diamondman 12y ago
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.
- snops 12y ago
  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/ http://www.lauterbach.com/ [2]https://www.segger.com/jlink_supported_devices.html https://www.segger.com/jlink_supported_devices.html [3]http://www.keil.com/support/man/docs/dapdebug/dapdebug_introduction.htm http://www.keil.com/support/man/docs/dapdebug/dapdebug_intro... [4]https://github.com/ARMmbed/CMSIS-DAP https://github.com/ARMmbed/CMSIS-DAP

ChuckMcM 12y ago

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.

wolfgke 12y ago
> Note that Xilinx did make an "open" FPGA part, the 3000 series, it did not do well for them. Could you provide further details?
- ChuckMcM 12y ago
  http://www.xilinx.com/support/documentation/data_sheets/3000.pdf 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.

boxerab 12y ago

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?

diamondman 12y ago
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.
- DrHoppenheimer 12y ago
  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-partners.html https://www.altera.com/solutions/partners/opencl-board-partn...
TD-Linux 12y ago
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.
- hornd 12y ago
  Hmm? FPGAs, in most cases, consume significantly less power than GPUs, unless GPU technology has caught up in the past year or so.
  - TD-Linux 12y ago
    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.

progman 12y ago

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.

UncleOxidant 12y ago
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.
deutronium 12y ago
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.
- diamondman 12y ago
  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.
diamondman 12y ago
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.

UncleOxidant 12y ago

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.

scottchin 12y ago
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.

scottchin 12y ago

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

jjoonathan 12y ago
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... :(
- UncleOxidant 12y ago
  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.
  - jjoonathan 12y ago
    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!

scottchin 12y ago

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.

diamondman 12y ago
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.

scottchin 12y ago

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.

diamondman 12y ago
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.

pslam 12y ago

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.

diamondman 12y ago
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!
femto 12y ago
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.

aswanson 12y ago

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.

diamondman 12y ago
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!
- aswanson 12y ago
  Wow. The beatings just continue. I was headed straight into the worse engineering subfield for starting a company, economically as well as legally.

mekarpeles 12y ago

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.

voltagex_ 12y ago
So why aren't these targets for OpenOCD instead of a new system?
- mekarpeles 12y ago
  @diamondman responded to this in another thread: http://www.reddit.com/r/programming/comments/338t25/the_lack_of_open_toling_for_fpgas/cqiz0gh 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.

wcunning 12y ago

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?

mng2 12y ago
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.
- wcunning 12y ago
  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.

alexweber 12y ago

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) https://en.wikipedia.org/wiki/Novena_(computing_platform)

anon_agin 12y ago

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 http://www.ohwr.org/attachments/821/sebastien.pdf