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

91–100 of 125 posts

Re: The Lack of Open Tooling for FPGAs

#91

Post by minthd »

diamondman wrote: post #55
sixdimensional wrote: post #35

Earlier quoted context omitted.

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…

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

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

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

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

Re: The Lack of Open Tooling for FPGAs

#92

Post by minthd »

fpgaminer wrote: post #86
phkahler wrote: post #82

Earlier quoted context omitted.

>> They want the information they program into them to be secret so that their hardware is not easily duplicated by the folks in China and mass produced to under cut them. So how does having a closed tool chain achieve that? Aren't the FPGAs programmed either on the line, or from ROM at power up? Either way, board producers should be able to replicate the product. How does being closed help?

> So how does having a closed tool chain achieve that? It doesn't. It slows reverse engineering, but doesn't itself prevent cloning. I'm not sure what ChuckMcM was trying to argue. I don't know of any big companies that care whether or not the toolchain/devices are open source. They just want a way to get their design into the world. What we (users of FPGAs) care about is price; the toolchains are sufficient (though…

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

Re: The Lack of Open Tooling for FPGAs

#93

Post by diamondman »

minthd wrote: post #92
fpgaminer wrote: post #86

Earlier quoted context omitted.

> So how does having a closed tool chain achieve that? It doesn't. It slows reverse engineering, but doesn't itself prevent cloning. I'm not sure what ChuckMcM was trying to argue. I don't know of any big companies that care whether or not the toolchain/devices are open source. They just want a way to get their design into the world. What we (users of FPGAs) care about is price; the toolchains are sufficient (though…

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

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

Re: The Lack of Open Tooling for FPGAs

#94

Post by diamondman »

fpgaminer wrote: post #86
phkahler wrote: post #82

Earlier quoted context omitted.

>> They want the information they program into them to be secret so that their hardware is not easily duplicated by the folks in China and mass produced to under cut them. So how does having a closed tool chain achieve that? Aren't the FPGAs programmed either on the line, or from ROM at power up? Either way, board producers should be able to replicate the product. How does being closed help?

> So how does having a closed tool chain achieve that? It doesn't. It slows reverse engineering, but doesn't itself prevent cloning. I'm not sure what ChuckMcM was trying to argue. I don't know of any big companies that care whether or not the toolchain/devices are open source. They just want a way to get their design into the world. What we (users of FPGAs) care about is price; the toolchains are sufficient (though…

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

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

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

Re: The Lack of Open Tooling for FPGAs

#95

Post by wolfgke »

ChuckMcM wrote: post #72
wolfgke wrote: post #58

Earlier quoted context omitted.

> Note that Xilinx did make an "open" FPGA part, the 3000 series, it did not do well for them. Could you provide further details?

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

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

Re: The Lack of Open Tooling for FPGAs

#96

Post by TD-Linux »

scottchin wrote: post #49

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…

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

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

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

Re: The Lack of Open Tooling for FPGAs

#97

Post by TD-Linux »

boxerab wrote: 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?

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.

Re: The Lack of Open Tooling for FPGAs

#98

Post by bravo22 »

dominicgs wrote: post #66
bravo22 wrote: post #33

Earlier quoted context omitted.

SDR uses orders of magnitude more power than an ASIC implementation which is why no one uses them except for base stations -- such as cell towers. FPGA based design for crypto would have the same timing attack as CPU. It can be worked around the same way it would for a CPU.

Sure, ASICs are always going to beat FPGAs and CPUs in power consumption for the same task, but there are also applications where the ability to update the system far outweigh the power requirements. Interestingly, SDR is being used for the UK's small scale digital radio station trials this year. Off the shelf SDR hardware appears to be performing well enough at a lower cost than bespoke DAB hardware. Again, this fit…

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

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

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

Re: The Lack of Open Tooling for FPGAs

#99

Post by wcunning »

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?

Re: The Lack of Open Tooling for FPGAs

#100

Post by hornd »

TD-Linux wrote: post #97
boxerab wrote: 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?

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

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