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

101–110 of 125 posts

Re: The Lack of Open Tooling for FPGAs

#101

Post by copascetic »

diamondman wrote: post #77
coryrc wrote: post #65

Earlier quoted context omitted.

Xilinx iMPACT (the FPGA programmer) bugs: On one version, it can load the project it saved, but then crashes when you go to program. So you have to scan and reload all the data files every time you start it. Later version, failed to program the chip at the last stage of the process. Diagnosed that over phone tag where the user was non-technical and on a machine not connected to the Internet. Exact same chip as above.…

You have to change out a certain DLL for POST windows 8 in order to get ISE to behave and not crash randomly. YAY! Xilinx said they didn't care but somewhere on their support forum there is some kind soul who said what dll to rename (they have two versions of the DLL in the install anyways but they did not use the win 8 one by default and refuse to patch).

This is entertaining. I've used Xilinx's tools for a while, almost exclusively on Linux (CentOS usually). I thought that renaming/symlinking libraries to get things to work was something only Linux users needed to do, and I figured this was just because Xilinx tests more on Windows (makes sense). If these kinds of problems also affect the Windows versions, then, I don't even know what to say. At some point you just can't make excuses for this stuff anymore.

Re: The Lack of Open Tooling for FPGAs

#102

Post by minthd »

diamondman wrote: post #93
minthd wrote: post #92

Earlier quoted context omitted.

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.

Have you noticed anybody else with better software and chips ? no ? maybe because it's extremely hard to to get to the level of ISE and the competitors ?

Re: The Lack of Open Tooling for FPGAs

#103

Post by ChuckMcM »

wolfgke wrote: post #95
ChuckMcM wrote: post #72

Earlier quoted context omitted.

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?

Well the guy I know who used to be in charge of strategic marketing for Xilinx shared that it had not met sales projections and support costs were higher (which cut into margin) when people were trying to program the things with their own tools. So sharing all that stuff about the chip alienated some big customers, reduced profit margins, and didn't help volumes. That pretty much defines 'fail' in the chip business.

Re: The Lack of Open Tooling for FPGAs

#104

Post by ChuckMcM »

minthd wrote: post #102
diamondman wrote: post #93

Earlier quoted context omitted.

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.

Have you noticed anybody else with better software and chips ? no ? maybe because it's extremely hard to to get to the level of ISE and the competitors ?

Well Quartus isn't bad. It will be interesting to see what Intel does with it. They have a history of open sourcing things other folks don't want to open source (like Graphics Drivers).

Re: The Lack of Open Tooling for FPGAs

#105

Post by TD-Linux »

hornd wrote: post #100
TD-Linux wrote: post #97

Earlier quoted context omitted.

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.

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.

Re: The Lack of Open Tooling for FPGAs

#106

Post by femto »

pslam wrote: post #64

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

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.

Re: The Lack of Open Tooling for FPGAs

#107

Post by mng2 »

wcunning wrote: post #99

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?

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.

Re: The Lack of Open Tooling for FPGAs

#108

Post by ChuckMcM »

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…

   > I'm not sure what ChuckMcM was trying to argue.
If you create a circuit board which has all of the same chips as someone else, if you've changed the layout, you are completely within your rights to sell it as your own and keep all the money.

However, if you copy firmware, then creating a circuit board with the copied firmware is a copyright violation and you can be found guilty of copyright infringement at most of our trading partners.

For folks who built cloned CPU boards with a copyrighted BIOS they re-implemented the BIOS in a clean room to have their own "work alike" version, which then gave them the right to sell their boards.

If however you copy an FPGA bitstream, which is the compiled output of a copyrighted HDL description, you're in violation. But building a 'clean room' implementation of an FPGA bitstream is generally infeasible as it requires you to both know how the manufacturer encodes and encrypts it, and all of the functions of the internal chip.

A really great example of this in action was that the recent flap over "clone" FTDI USB to serial chips, wasn't a clone of the chip at all. Instead the cloners used an ARM M0 CPU with a USB peripheral and a UART peripheral and a bit of code that responded in all of the same ways in which the FTDI chip (which was presumably an ASIC) responded. That 'workalike' implementation was only possible because the set of inputs and outputs for that system are constrained, and the only IP violation was the re-use of FTDI's VID/PID pair. If they had been forced to use a bitstream file for an FPGA they would be liable for up to $30,000 per copy, and jail.

Re: The Lack of Open Tooling for FPGAs

#109

Post by wcunning »

mng2 wrote: post #107
wcunning wrote: post #99

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?

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

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.

Re: The Lack of Open Tooling for FPGAs

#110

Post by ReversedGif »

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.

Can you find the "programming and layout specs docs," online or physical copies? I can't find any mention of them anywhere. I'm very curious to see them.
Post reply on HN