Live data from Hacker News

The Lack of Open Tooling for FPGAs

curtis.io

31–40 of 125 posts

Re: The Lack of Open Tooling for FPGAs

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

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.

Re: The Lack of Open Tooling for FPGAs

#32
post #18

Earlier quoted context omitted.

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…

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

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.

Re: The Lack of Open Tooling for FPGAs

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

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.

Re: The Lack of Open Tooling for FPGAs

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

Re: The Lack of Open Tooling for FPGAs

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

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 seen some amazing related work at MIT here: http://people.csail.mit.edu/wjun/papers/fpga2014-wjun.pdf

Re: The Lack of Open Tooling for FPGAs

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

Re: The Lack of Open Tooling for FPGAs

#37

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…

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.

Re: The Lack of Open Tooling for FPGAs

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

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.

Re: The Lack of Open Tooling for FPGAs

#39

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.

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.

Re: The Lack of Open Tooling for FPGAs

#40
post #32

Earlier quoted context omitted.

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

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

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.

Post reply on HN