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

Intel Gears Up for FPGA Push

nextplatform.com

Post reply on HN
Print view View original

101–110 of 112 posts

Re: Intel Gears Up for FPGA Push

#101

Post by slrz »

Boothroid wrote: post #60
nimish wrote: post #44

Tooling tooling tooling. FPGA hardware is cool but the tooling fucking sucks. Like stepping back into the time where you needed to pay thousands of dollars to get decent compilers and debuggers. The ability for anyone to develop software for CPUs at zero-cost is an amazing freedom. You literally cannot do that on certain fpgas--not only do they cost thousands, so do the tools to actually create a working design. Unti…

I have an iCEstick sitting in a drawer, for which some pretty amazing open source tools are available: http://www.clifford.at/icestorm/ I wish I had the time to play with it!

I recently tried to buy an iCEStick and failed horribly. Where did you get yours?

Re: Intel Gears Up for FPGA Push

#102

Post by nxmehta »

nakedrobot2 wrote: post #47
nimish wrote: post #44

Tooling tooling tooling. FPGA hardware is cool but the tooling fucking sucks. Like stepping back into the time where you needed to pay thousands of dollars to get decent compilers and debuggers. The ability for anyone to develop software for CPUs at zero-cost is an amazing freedom. You literally cannot do that on certain fpgas--not only do they cost thousands, so do the tools to actually create a working design. Unti…

FPGA's are extremely powerful, but the toolchain is absolute dog shit. Xilinx, shame on you. Intel, will you change anything here? The compound problem of this in reality is that finding the right people who have the right strain of semi-insanity to do this really well, is very slim. And most of them are tied up with a massive salary from some aerospace company such as Raytheon, GE, Honeywell, or someone like Philips…

FYI, the toolchain is shit because:

1. The optimization problems that EDA tools have to solve are about as hard as it gets - NP-hard and sigma 2p problems at a massive scale. I'd argue that these are among the hardest optimization problems in modern computer science today.

2. The number of people with the CS + EE training to develop this software is decreasing. Not a lot of people are getting PhDs in EDA anymore, because:

3. Regular software houses (Google, Amazon, etc.) have about 2-3x the comp as EDA companies. Trust me I've seen a lot of incredibly smart EDA people jump to Google and more than double their salary overnight.

I doubt Intel is going to shift the balance here. It's not easy to develop a fast and efficient SP&R flow.

Re: Intel Gears Up for FPGA Push

#103

Post by Boothroid »

slrz wrote: post #101
Boothroid wrote: post #60

Earlier quoted context omitted.

I have an iCEstick sitting in a drawer, for which some pretty amazing open source tools are available: http://www.clifford.at/icestorm/ I wish I had the time to play with it!

I recently tried to buy an iCEStick and failed horribly. Where did you get yours?

Element 14 / Farnell

Re: Intel Gears Up for FPGA Push

#104

Post by gcp »

nxmehta wrote: post #102
nakedrobot2 wrote: post #47

Earlier quoted context omitted.

FPGA's are extremely powerful, but the toolchain is absolute dog shit. Xilinx, shame on you. Intel, will you change anything here? The compound problem of this in reality is that finding the right people who have the right strain of semi-insanity to do this really well, is very slim. And most of them are tied up with a massive salary from some aerospace company such as Raytheon, GE, Honeywell, or someone like Philips…

FYI, the toolchain is shit because: 1. The optimization problems that EDA tools have to solve are about as hard as it gets - NP-hard and sigma 2p problems at a massive scale. I'd argue that these are among the hardest optimization problems in modern computer science today. 2. The number of people with the CS + EE training to develop this software is decreasing. Not a lot of people are getting PhDs in EDA anymore, bec…

You know, we would all like faster synthesize and P&R cycles, but when people complain about the tooling being shit, that's not what they're complaining about. (Mostly)

Re: Intel Gears Up for FPGA Push

#105

Post by gcp »

ethbro wrote: post #90
gcp wrote: post #78

Earlier quoted context omitted.

I got a Xilinx Spartan DEV board sitting in a drawer too. The board is great but Xilinx's tooling has negative value for me, so it'll stay there. Tooling is 100% the thing keeping FPGAs back.

As far as I can tell, it's an economics problem. The big consumers of FPGAs don't care if the tooling is terrible, because they're coming from 80s development environments and practices and can afford to dedicate 50-person teams to the job function. Smaller companies won't touch it because it's terrible, and the vendors won't improve it because there's no demonstrated market for improvements.

Sounds about right. I guess the market economics don't work out for a simple design (i.e. with not much IP revealed by open sourcing the spec) that can be programmed with OS tools. I mean, there's these ICE chips, which is a huge step, but realistically I'd want something just a tiny bit bigger and with a hardcore (ARM or MIPS) in it.

Or maybe the market economics work out, but are small relatively compared to the big players, so it moves glacially.

Re: Intel Gears Up for FPGA Push

#106

Post by gcp »

amelius wrote: post #50

I think Intel or somebody else should put more effort in whetting our appetite for possible applications. What long list of applications can CPU+FPGA bring us that a CPU or GPU can't?

The applications are the same, but an FPGA allows extremely narrow optimization. Got something that doesn't parallelize all that well, but can be pipelined, or benefits from a wide datapath? Design that. Got something that parallelizes well and only needs a tiny datapath? Make it a 1000 wide vector machine. It needs difficult control flow? No problem, we're flexible as we're not a GPU, etc.

The optimization needs to beat out the inefficiency of the FPGA compared to an ASIC though (not to speak of development time). But sometimes, you can do just that.

Re: Intel Gears Up for FPGA Push

#107

Post by gcp »

ngsayjoe wrote: post #91
murph-almighty wrote: post #83

Does this mean we can develop using some not-Xilinx proprietary crapware?

You can always use third-party EDA tools if you have the money rather than the vendor bundled free software. Eg Cadence, Mentor Graphics, etc.

Don't you need the vendor-specific backend for the physical P&R?

Re: Intel Gears Up for FPGA Push

#108

Post by rjsw »

burntrelish1273 wrote: post #95
rjsw wrote: post #53

Earlier quoted context omitted.

Intel do have ARM+FPGA products already from Altera, as do Xilinx. It will be interesting to see if Intel replaces the ARM CPU with a variant of x86.

Yes, I've evaluated some of them too (great for some projects that need like a RPi but with custom digital / DSP logic), they're just not exactly mainstream as Xeon processors.

I have only used the original Xilinx one but ARM is pretty mainstream, the newest ones even have Mali GPUs.

I would expect a Xeon+FPGA to be at a very different price point from the ARM+FPGA devices, it will be interesting to see whether Intel carry on selling ARM ones or also produce an Atom+FPGA equivalent.

Re: Intel Gears Up for FPGA Push

#109

Post by jecel »

AriaMinaei wrote: post #97
jecel wrote: post #93

Earlier quoted context omitted.

I have worked on this in the case of Smalltalk and the opportunities are there but there are significant problems. The opportunity is in the form of adaptive compilation where you initially use a simple compiler (or even an interpreter for the very first execution) and then collect profiling information and call a much better compiler to generate code for the "hot spots". A key optimization is inlining which greatly…

This was very interesting, thank you! I'm sure I missed something in your first paragraph though, because the process that you described sounds very much like a normal modern JIT compiler. In V8 and SpiderMonkey for example, the engine starts with the first tier, which is a baseline interpreter that collects type information on each function call, and then if a function is invoked enough times, it compiles the functi…

JIT is a generic term that applies both to dynamic compilation (one pass) and adaptive compilation (multiple passes with profiling). While it is pretty normal these days, many people involved in FPGA research only know about static languages and manual partitioning (like OpenCL) and that is why I always explain what it is.

FPGAs don't help JITs at all. I was saying the opposite: if certain problems (slow compilation and slow reconfiguration) could be solved then JITs could offer the opportunity to generate hardware acceleration on demand that would be tuned for a specific execution of an application.

Re: Intel Gears Up for FPGA Push

#110

Post by katastic »

Boothroid wrote: post #64
katastic wrote: post #10

I've honestly been waiting for this since for YEARS. I've had a vision for "the future of computing". FPGAs that reconfigure themselves ( This would be hard for a single person, but any large company could handle making this. You can even do it with off-the-shelf FPGAs. The biggest problems are 1) bandwidth. The "macro" function size needs to be bigger than the latency hit you take for asking the FPGA over computing…

I've been thinking of something similar recently - to extend your idea slightly, why couldn't the flashing of the FPGA happen per tick? Thus at every tick your FPGA could become entirely different hardware, tailored to whatever task is required at that tick.

Well, flashing is pretty slow compared to modern computers. You have to load it from flash (no pun) memory and Altera are the only ones (AFAIK) that support only changing subsections. (Which could be great because you can change only a half or quarter of your FPGA with new logic units while the others keep running.)

Also, you'd have to know what you'd need... before you need it. Which is kind of impossible. By time you know you need tons of integer units, you probably could have started working on them. That is, if you need to rapidly switch, then your workload is pretty rapidly completed to begin with.

However, I don't thing they need to reconfigure that fast. Once every second would be enough to keep up with most workloads. Most "heavy duty" workloads aren't changing that rapidly. You load a video game, it's a videogame for hours you play it. You load a web server, you're going to be doing SSL.

If you need much more fine control, it'd probably be better to treat the problem at a much higher level ("I need more SSL keys / sec", instead of "I need more integer adds to make SSL keys") or add another FPGA (one for each use case or set of use cases, ala one for web server keys, one for deciding some other major web server feature).

Of course, I'm no expert in the field. I'm just a guy with an idea and some experience / research into FPGA's as reconfigurable logic units.

Post reply on HN