Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Lack of Open Tooling for FPGAs

curtis.io

Post reply on HN
Print view View original

41–50 of 125 posts

Re: The Lack of Open Tooling for FPGAs

#41

Post by scottchin »

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

Re: The Lack of Open Tooling for FPGAs

#42

Post by bravo22 »

diamondman wrote: post #40
bravo22 wrote: post #32

Earlier quoted context omitted.

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

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

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

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

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

Re: The Lack of Open Tooling for FPGAs

#43

Post by [deleted] »

diamondman wrote: post #40
bravo22 wrote: post #32

Earlier quoted context omitted.

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

[deleted]

Re: The Lack of Open Tooling for FPGAs

#44

Post by diamondman »

vonmoltke wrote: post #17
skwuent wrote: post #15

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

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

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

Re: The Lack of Open Tooling for FPGAs

#45

Post by jjoonathan »

scottchin wrote: post #41

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 40 years... :(

Re: The Lack of Open Tooling for FPGAs

#46

Post by snops »

diamondman wrote: post #26
zwieback wrote: post #21

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…

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

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

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

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

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

Re: The Lack of Open Tooling for FPGAs

#47

Post by deutronium »

progman wrote: 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 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.

Re: The Lack of Open Tooling for FPGAs

#48

Post by UncleOxidant »

jjoonathan wrote: post #45
scottchin wrote: post #41

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…

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.

Re: The Lack of Open Tooling for FPGAs

#49

Post by scottchin »

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.

Re: The Lack of Open Tooling for FPGAs

#50

Post by diamondman »

bravo22 wrote: post #42
diamondman wrote: post #40

Earlier quoted context omitted.

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

I fully support the spirit of what you're doing btw. I hope you don't take my comments as somehow dumping on your work ;). What is "crappy" about Xilinx tools aside from the UI? I'm genuinely curious. I don't think the comparison between synthesis tools and compilers hold. They are different beasts. I think compiler equivalent is sim tools which should be open and free. Everyone that I've talked to who uses Keil uses…

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

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

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

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

Post reply on HN