25 ms·
Intel Gears Up for FPGA Push
- m_mueller 9y ago... and presumably they are also preparing to drop that program in about 3-4 years.
- nullc 9y agoIf they ever release it in the first place (or if they ever let it get past a point where you need to specifically contract with intel to get access to it).
- 0xbear 9y agoThis is so obviously not going to fly unless they either start bundling with Xeons, or offer something Xilinx can’t do. Cloud providers aren’t stupid, and there are enough eggs in the Intel basket already.
- microcolonel 9y agoMaybe they could offer a good (maybe open?) toolchain, online partial reprogramming?
- 0xbear 9y agoThe words Intel and “open” do not really belong in the same sentence.
- microcolonel 9y agoIdunno, Xeon Phi, their GPUs since about 2007 (though a lot better recently), good cooperation and documentation with their NICs, direct participation in both major open compiler toolchains, all the stuff that 01.org lists... I think they're doing pretty well with open (aside from the products themselves, but that's kinda the point of having a company). Frankly Intel has done an adequate to good job of providing open source software to interact with all of their hardware for as long as I've been computering. They're the one vendor that has never told me to install a proprietary driver.
- 0xbear 9y agoYou can’t even use their main product without loading in opaque binary blobs and agreeing to a backdoor.
- microcolonel 9y agoThat's true, that's my greatest gripe with them. It's a major part of why I'm looking to other platforms for my workstation. That said, you can't escape that with their nearest competitor, so it's a bit of a moot point for now.
- pratumlabs 9y agoOne of the key benefits of Intel's solution is that the CPU and FPGA share the same RAM, avoiding the O(N) cost of moving data to/from the devices. This type of a zero-copy transaction can enable very high performance applications compared with dedicated discrete cards.
- dragontamer 9y agoAMD already does "Zero Copy transfers" (the on-chip cache!!) with its "Fusion" APUs (ex: A10-7850K) for CPU <<---->> GPU. I'm not really seeing loads of people taking advantage of the feature however. The platform is cheap, the technology is available but its just way too weird an architecture to become mainstream. There are numerous benefits: the CPU can create a linked list or graph, and the memory will still be valid on the GPU. CPU / GPU atomics are unified, and GPUs can even call CPU functions under AMD's HSA platform. * https://images.anandtech.com/doci/7677/20%20-%20HSA%20Use%20Cases.jpg https://images.anandtech.com/doci/7677/20%20-%20HSA%20Use%20... * http://developer.amd.com/wordpress/media/2012/10/hsa10.pdf http://developer.amd.com/wordpress/media/2012/10/hsa10.pdf * https://www.anandtech.com/show/7677/amd-kaveri-review-a8-7600-a10-7850k/6 https://www.anandtech.com/show/7677/amd-kaveri-review-a8-760... --------- I think Intel had a similar technology implemented on their "Crystalwell" chips, which were basically an L4 cache which provided a high-bandwidth link between the CPU and GPU (although not quite as flexible). No, its not an FPGA, but OpenCL / GPGPU compute seems to be a bit more mainstream than FPGA compute at the moment. I haven't seen too much excitement in general for this feature however.
- imtringued 9y ago>I'm not really seeing loads of people taking advantage of the feature however. The platform is cheap, the technology is available but its just way too weird an architecture to become mainstream. AMD sells a consumer product. For most consumers even a smartphone offers enough CPU and GPU performance. The content producers who care about performance usually buy the best CPU and GPU. HSA isn't available on AMD's Ryzen or Threadripper processors. Intel is trying to sell to datacenters where performance or energy efficiency is a major selling point.
- Andys 9y agoIntel really don't do anything unless they already have a market for it. They have bundled with Xeons in the past. If there turns out to be a market (which comes down to tools and cloud platform to make this existing tech much more accessible) then it'll be huge and they'll need to be part of it.
- jackyinger 9y agoIf they do release something in this space they oughta make a SKU that can plop into a standard desktop socket on a standard motherboard. Electrical and computer engineering individuals want cheap big FPGAs too! (Speaking for myself of course.) Or just release a cheap pcie card! Cmon guys! Oh wait you've forgotten how important it is to get a developer community started around your hardware cause it's been so long since the x86 was new!
- spaceseaman 9y ago> Oh wait you've forgotten how important it is to get a developer community started around your hardware cause it's been so long since the x86 was new! Intel: Huh? Developers? But they don't buy servers full of chips. Why do I have to sell to developers?
- StillBored 9y agoThat is pretty much the ARM and POWER problem too, they think they can grow in new markets with these hugely expensive machines in quantities of ten racks. Both would have significantly more traction if they offered a reasonable desktop class machine, but they don't seem to be able to do it. For some reason there are dozens of RPi type devices but making a $200-$300 device with a reasonable set of expansion ports (sata+USB3+pcie gen3+m.2+10g ethernet+etc) seems all but impossible. POWER has a similar problem, with the only inexpensive devices being old NXP parts (yah NXP is still selling a core that turns 20 years old this year https://www.nxp.com/products/microcontrollers-and-processors/power-architecture-processors/powerquicc-processors/powerquicc-ii:PCPPCMPC82XX https://www.nxp.com/products/microcontrollers-and-processors... thats great if your still selling car parts from 20 years ago, not so great if your designing a part today.).
- wmf 9y agoSadly, I suspect all the small developers combined are smaller than one hyperscale customer.
- 9y ago
- katastic 9y agoI've honestly been waiting for this since for YEARS. I've had a vision for "the future of computing". FPGAs that reconfigure themselves (<-these exist) to become whatever macro-level hardware assets your computer needs. Running tons of SHA-256 encryptions per second? The CPU/OS/OpenSSL (or whatever) detects this condition and switches from hand-coded ones, to an IP core that comes with the CPU. The CPU flashes the FPGA's to become SHA-256 "CoreS" and now you're running 4096x the output with less heat. (As CPUs are designed for one thing "few, large, complex cases" while FPGAs are perfect for many, parallel simple cases" even more than a GPU.) Now, you shutdown your encoding and switch to video encoding, or Doom 2019 and your CPU reflashes (Alteria specialized in PARTIALLY flashable FPGAs so you don't have to nuke the entire FPGA, only sections) and adds cores for video, or physics, or "shader units". 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 it internally. (Intel's on-CPU FPGA would be insanely fast access.) and the other one is 2) How do you get people to use it! The simplist is of course, only supporting people who actually request it. But, you can take libraries that perform common, encapsulated macro functionality, like OpenGL, a physics library, or OpenSSL, where people don't care about the inner code ("how it gets done") but instead the result. Asking for floats to be multiplied would be bad. But asking for a cross-product would be much faster. Asking for an SHA-512 key would be super. And the benefit here is, you don't have to hardcode that functionality into a CPU. The FPGA can have NEW or improved IP cores downloaded with Windows Update every week. Back when I was in college, I actually bought a Lattice dev kit with a PCI Express card, dual-gigabit ethernet, DDR3, and an near top-of-the-line FPGA on the board and it cost a mere $100. Unfortunately, I was a more software guy so I really got in over my head (plus health issues set me back and have never let up since), so I never got a working prototype built. But it's still there! A huge opportunity waiting to be seized that could really become another tier of "the standard PC." In the same way we think of SSDs as "almost RAM" scratchpads, or GPUs as "CPUs for massive amounts of simple decisions." Well an FPGA is the "GPU of GPUs". Even simpler decisions and insanely fast and parallel even at "low" (by CPU standard) clockrates of 400 MHz. Here's an older (2009) project/research article that inspired me called the 512 FPGA cube. http://cc.doc.ic.ac.uk/projects/prj_cube/Welcome.html http://cc.doc.ic.ac.uk/projects/prj_cube/Welcome.html http://cc.doc.ic.ac.uk/projects/prj_cube/spl09cube.pdf http://cc.doc.ic.ac.uk/projects/prj_cube/spl09cube.pdf And here's a direct link to the data table results between FPGA, FPGA cube, and Xeon (and cluster of Xeons) trying to do the same work: https://i.imgur.com/byjmEDG.png https://i.imgur.com/byjmEDG.png Those are massive differences in numbers in both power efficiency and compute rate. 72,000 Watts of Xeons to get the speed of a single 832 watt cube. That's two orders-of-a-magnitude! I mean, imagine a world if they bothered to make FPGA's you could plug into Ethernet, and make them configure themselves according to a simple programming tool that was "easy" for normal programmers to exploit instead of requiring intense understanding of logic gates, propagation delay, and so on. A tool that wasn't "as fast as" a dedicated engineer, but 90% (or even 70%) as fast at zero cost and effort. All a sudden you could run tons of programs and macro-sized functions like you had personally stamped them into a printed circuit yourself, but without spending millions on development. I'm honestly not sure why this hasn't already happened. I can't be the only "smart" person who came up with this idea. And the research (and practice with bitcoin miners) all points to a huge opportunity to be exploited if they could lower the knowledge barrier-to-entry so you can basically "push a button" and unleash an FPGA at a problem. Imagine LAPACK and BLAS with FPGA support.
- burntrelish1273 9y agoThe biggest problem with reconfigurable computing is it's either an afterthought, tools are too narrow/proprietary or an extra add-in card. Add a million LUTs and several thousand special-purpose blocks (ALUs, CAM, SRAM, DSPs, etc.) on CPU die that can be reconfigured within a few 10k cycles (ie process context), and then future AI-enabled optimizing compilers could incrementally profile and accelerate applications with reconfigurable resources in new, creative and interesting ways. IRAM and similar zillion core approaches are another approach to solve traditional performance locality bottlenecks: distribute processing, interconnect and RAM amongst each other. It makes the most sense to co-evolve such a radical undertaking gradually with compiler vendors and large customers so that support and usability is working from launch, rather than just throwing silicon over the wall and using the "hail mary" method of product (non)design. PS: Intel could push almost any new on-die CPU technology service/product into the mainstream right now on the server side because of their de-facto monopoly oligopoly dominance. I don't think they will as there is immense organizational pressure to not innovate too much.
- throwaway4590 9y agoThere needs to be a marrying of software and hardware -- and processor instructions to support that. This is hierarchical reconfigurable cache-based architecture I designed a while ago at Intel; I doubt they have touched it but they do own it. https://www.google.com/patents/US20170153892 https://www.google.com/patents/US20170153892
- mankash666 9y agoJust a thought - I suppose you wanted to post with a throwaway account, but claiming to be the inventor of the patent gives your identity away
- chaosite 9y agoSure, but this way his main account is not linked to his name.
- sitkack 9y agoThe whole things smells like monopoly dragging its heels. It bought the competition to slow adoption, claiming that CPU-FPGA hybrids were just around the corner. What we need is a new FPGA based fabric that has the major building blocks to create any number of RISCV cores. Tiles that can be RISCV, or if "sacrificed" turn into clusters of LABs for general purpose use. And the chip company with the software vision for this is AMD with HSAIL.
- zw123456 9y agoFPGA's are the shit but the software is the key. To make them really fly we need some really brilliant software to configure them. Someone is going to disrupt this space soon and whoever does I think will make a unicorn. Just my guess.
- chisleu 9y agoThey bought one of the best hardware makers with one of the worst software platforms. I hope to all that is holy that they replaced the software entirely. What a nightmare those classes were...
- ngsayjoe 9y agoYes Quartus is complete crap! I wrote some of it.
- davrosthedalek 9y agoTo be fair, Quartus was way ahead of Xilinx' offering until they leap-frogged it with Vivado.
- cptskippy 9y agoI wonder if this will receive the Edison treatment.
- tim-- 9y agoWhat's new here anyway? Intel bought Altera, and Altera have had development kits similar to this for a long time. What is the price of the new FPGA add-on cards? That is what will make the difference here for a 'new push'.
- makomk 9y agoThe new thing is that the embedded hard CPU core is some flavour of Xeon rather than ARM or MIPS.
- ww520 9y agoCan JIT run on FPGA? Use the JIT info to reconfigure the chip on the fly. Would there be enough speedup to justify the effort?
- adrianratnapala 9y agoIt sounds like it would be little different from a CPU implemented on an FPGA. True, you want to use run-time info to optimize on the fly, but my guess is that modern branch predictors, caches etc, already do as much of this stuff as we know how to do. In the unforseeable future, then who knows, maybe the predictors will become so flexible that even conventional CPUs evolve into something like basically FPGAs.
- AriaMinaei 9y agoIn the case of Lisp and Smalltalk and other highly dynamic languages, would these on-die FPGAs open new compiler optimisation opportunities?
- yvdriess 9y agoThe common sentiment after the 90's is that it's hard to beat optimized x86 implementation of both. Maybe non-offloading FPGA-CPU hardware has the potential of accelerating certain language features (e.g. burn in the CLOS method lookup cache?)
- simias 9y agoThe problem is that tailor-made FPGA designs won't run nearly as fast as a modern ASIC CPU. That's why for instance FPGA emulators are not more common, for older hardware software implementations are accurate enough and manage to run in realtime so the additional cost and complexity of FPGAs is not warranted. For more modern hardware software implementations can't reach absolute accuracy in real time but FPGAs big and fast enough to handle these designs are prohibitively expensive (if they even exist in the first place). That's why FPGA GameBoy emulators are not popular and you probably won't see a FPGA PS3 emulator any time soon (unless the pricing changes dramatically in the near future). FPGAs shine when you need to process very high throughput data with low (or at least constant) latency or for special-purpose algorithm with no hardware acceleration available on CPU or GPU (video codecs, crypto, computer vision etc...). But in general when an algorithm becomes popular enough (AES, SHA-256, H264...) hardware support is backed into the ASIC eventually with much better performance and power consumption than a FPGA. I see a potential for FPGAs in CPUs for professional applications if you want to process big datastream without having to rely on external hardware. For instance I work in broadcast video transmission where we routinely handle uncompressed HD or even 4K streams, being able to prototype directly on my workstation's CPU would be pretty cool. As for general purpose programing language optimization I have a hard time imagining what it would look like. The problem is that you don't code for a FPGA the way you code for a CPU. To put it very simply on the CPU serial is cheap while forking and synchronizing threads is expensive. On an FPGA it's basically the other way around. Automatically transforming one form into the other automatically in a compiler or JIT sounds very much non-trivial. Maybe I just don't have enough imagination.
- nimish 9y agoTooling 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. Until that changes, FPGAs will always be niche.
- simias 9y agoI dream of a GCC/LLVM for FPGAs. I'm not holding my breath for Intel to help with that though.
- aeruder 9y agoC (or really any traditional programming language) doesn't really map to an FPGA. There are some compilers out there that attempt to convert traditional C code to state machines for FPGAs, but FPGAs are really a completely different paradigm. You're actually describing digital logic, not a sequence of steps. That being said, there are soft-processors that have been written in VHDL/Verilog and can be incorporated into a FPGA design, and those CPUs do often have GCC support (Microblaze Xilinx, NIOS 2 Altera, plenty of MIPS CPUs out there, etc.).
- simias 9y agoOh that's not what I was implying, sorry for the confusion. I meant an open source, portable HDL compiler/synthesizer like what GCC/LLVM are for software. As the parent and many others point out in this thread the tooling is a really sore point for FPGA development. It's always big, clunky, often buggy closed source applications (often running on an unhealthy dose of Tcl scripts cobbled together). And of course if you change supplier you have to relearn everything or pay for an other third-party closed source solution to abstract some of the differences between the environments of Xilinx, Altera/IntelFPGA and friends.
- 9y ago
- agumonkey 9y agoI can't help to think that FPGA would marry well with highly dynamic meta-loving languages like CL (or similar).
- amelius 9y agoI 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?
- gcp 9y agoThe 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.
- murph-almighty 9y agoDoes this mean we can develop using some not-Xilinx proprietary crapware?
- ngsayjoe 9y agoYou can always use third-party EDA tools if you have the money rather than the vendor bundled free software. Eg Cadence, Mentor Graphics, etc.
- gcp 9y agoDon't you need the vendor-specific backend for the physical P&R?
- LoweD 9y agoYes, you do need the vendor's place-and-route. PAR performance is as good as you could expect though. Most complaints about vendor software are closer to the front of the flow. Examples... * Poor language support (applies for both SystemVerilog and VHDL) * Not enough transparency and access to primitives and IP blocks, resulting in poor ability to automate * Generally buggy elaboration and synthesis results, sometimes even causing the tool to crash My opinion is that the FPGA companies spend too much money improving the HLS (c-to-gates) and IP wizard experience, in an attempt to make their devices more accessible to the mythical software engineer who wants to use an FPGA. They should have spent that time and money supporting language standards, and improving the RTL experience, which is how most engineers use their products.
- DesiLurker 9y agoWhat I am interested in is a programmable vector fabric that I can reconfigure fast (in say L2/L3 access times). right now there are 100s of AVX2 instructions & as the number of HPC applications grow it is only going to explode. My problem is that when you are using one vector instruction the silicon for the rest is just sitting around when it could be perhaps used to make a much wider SIMD unit for just the instructions I'll be using. If they can get just that right IMO it'll be a huge success. IMO the problem with FPGA or even silicon dev is mostly tooling. I often say this, the biggest contribution to Open SOurce movement is not of linus/linux ..its gcc. just imagine if 'they' could tangle up every bit of open source code in IP litigation emerging from proprietary compilers.