Live data from Hacker News

The Lack of Open Tooling for FPGAs

curtis.io

51–60 of 125 posts

Re: The Lack of Open Tooling for FPGAs

#51

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.

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

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

Re: The Lack of Open Tooling for FPGAs

#52
post #10

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

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.

Re: The Lack of Open Tooling for FPGAs

#53

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 t…

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 4…

[deleted]

Re: The Lack of Open Tooling for FPGAs

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

Re: The Lack of Open Tooling for FPGAs

#55

Earlier quoted context omitted.

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…

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 see…

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.

Re: The Lack of Open Tooling for FPGAs

#56
post #34

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.

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.

Re: The Lack of Open Tooling for FPGAs

#57

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.

Re: The Lack of Open Tooling for FPGAs

#58

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 prod…

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

Could you provide further details?

Re: The Lack of Open Tooling for FPGAs

#59
post #25

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.

Re: The Lack of Open Tooling for FPGAs

#60

Earlier quoted context omitted.

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

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.

Post reply on HN