Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Intel To Offer Custom Xeons With Embedded FPGAs For the Data Center

timothy posted about 3 months ago | from the bitcoin-obviously dept.

Intel 80

MojoKid (1002251) writes For years, we've heard rumors that Intel was building custom chips for Google or Facebook, but these deals have always been assumed to work with standard hardware. Intel might offer a different product SKU with non-standard core counts, or a specific TDP target, or a particular amount of cache — but at the end of the day, these were standard Xeon processors. Today, it looks like that's changing for the first time — Intel is going to start embedding custom FPGAs into its own CPU silicon. The new FPGA-equipped Xeons will occupy precisely the same socket and platform as the standard, non-FPGA Xeons. Nothing will change on the customer front (BIOS updates may be required), but the chips should be drop-in compatible. The company has not stated who provided its integrated FPGA design, but Altera is a safe bet. The two companies have worked together on multiple designs and Altera (which builds FPGAs) is using Intel for its manufacturing. This move should allow Intel to market highly specialized performance hardware to customers willing to pay for it. By using FPGAs to accelerate certain specific types of workloads, Intel Xeon customers can reap higher performance for critical functions without translating the majority of their code to OpenCL or bothering to update it for GPGPU.

cancel ×

80 comments

Sorry! There are no comments related to the filter you selected.

To help prevent people from buying AMD and nVidia (3, Insightful)

ottawanker (597020) | about 3 months ago | (#47273713)

Intel Xeon customers can reap higher performance for critical functions without translating the majority of their code to OpenCL or bothering to update it for GPGPU

In other words, to help prevent people from buying AMD and nVidia products.

Re:To help prevent people from buying AMD and nVid (4, Interesting)

Austerity Empowers (669817) | about 3 months ago | (#47273781)

No ignore that entire last sentence, it's dumb. FPGAs don't do floating point very well for one and even their integer performance will never rival a GPGU either in performance, or power. For another, I can and do, use both FPGAs and OpenCL/GLSL in my daily life and would infinitely prefer to port my functions to OpenCL over an FPGA. It's quite a bit more work to synthesize and validate an FPGA design than it is to write OpenCL code and debug the usual way.

I think it's far more likely customers are implementing custom hardware solutions using the FPGA related to power management, server management and datastructure infrastructure that can only be done with an FPGA in certain power domains. I say this having designed servers and dealt with the feature requests.

Re:To help prevent people from buying AMD and nVid (1)

Austerity Empowers (669817) | about 3 months ago | (#47273839)

s/datastructure/datacenter/

caffeine, it's what should have been for breakfast.

Re:To help prevent people from buying AMD and nVid (0)

Anonymous Coward | about 3 months ago | (#47277057)

Preview, it's what should have come before Submit.

Re:To help prevent people from buying AMD and nVid (4, Informative)

ShanghaiBill (739463) | about 3 months ago | (#47274057)

FPGAs don't do floating point very well for one and even their integer performance will never rival a GPGU either in performance, or power.

Sure, and a hammer makes a terrible screwdriver. GPUs are specifically designed for register-to-register SIMD operations, so of course they are going to excel at that. But an FPGA is going to be better at bitstream operations, including many hashing and encryption algorithms.

Re:To help prevent people from buying AMD and nVid (0)

Anonymous Coward | about 3 months ago | (#47274121)

But an FPGA is going to be better at bitstream operations, including many hashing and encryption algorithms.

Which, of course, is why every hashing algorithm used in cryptocurrencies is being attacked with GPUs foremost and CPUs secondmost, rather than a relatively cheap FPGA board.

( With double-SHA256 and limited variants of Scrypt (and announcements for others) being attacked by ASICs - with parallels drawn for some cryptographic functions (e.g. AES) that are available on chips as it is. )

Re:To help prevent people from buying AMD and nVid (2)

Bengie (1121981) | about 3 months ago | (#47274159)

GPUs are primarily being used because everyone has one. FPGAs are about 10x faster and consume about the same amount of power as a GPU for stuff like bitcoin. the problem is the up-front cost and trust issues from the companies that make these pre-built FPGA boards.

Re:To help prevent people from buying AMD and nVid (1)

itzly (3699663) | about 3 months ago | (#47274383)

Of course, bitcoin mining using the SHA256 hash which is not a typical application for a GPU. It involves a lot of shuffling at the bit level, which a GPU was not designed for. For some other workloads, involving standard math operations, or large amounts of memory bandwith, the GPU will likely be faste.r

Re:To help prevent people from buying AMD and nVid (0)

Anonymous Coward | about 3 months ago | (#47275469)

Actually FPGA's consume FAR FAR LESS power than a GPU, and do much much more, that is why they are preferred (After ASIC's) for BitCoin mining.

Re:To help prevent people from buying AMD and nVid (0)

Anonymous Coward | about 3 months ago | (#47274135)

FPGAs don't do floating point very well for one and even their integer performance will never rival a GPGU either in performance, or power.

Sure, and a hammer makes a terrible screwdriver. GPUs are specifically designed for register-to-register SIMD operations, so of course they are going to excel at that. But an FPGA is going to be better at bitstream operations, including many hashing and encryption algorithms.

This.
FPGAs excel at crypto. They excel at other things too but Xeons in servers have a crypto load beyond that which your lowly desktop PC sees.
Maybe its good for big data indexing or stuff like that, but I don't know anything about that.

Re:To help prevent people from buying AMD and nVid (0)

Anonymous Coward | about 3 months ago | (#47274131)

even their integer performance will never rival a GPGU either in performance, or power

You're making a sweeping statement while failing to take any notice of the parameters (how many ALUs on the GPU vs how many LUTs on the FPGA) or the constraints (FPGAs can do deep and narrow logic at one result per cycle throughput; ALUs on narrow integer logic are very inefficient). The BTC guys certainly seem to think an FPGA is superior to a GPU at SHA-128 computation, so your "will never rival" is looking a bit "actually it already does, for some applications".

power management, server management and datastructure infrastructure

Anything related to those things can be done with a regular outboard CPU, you don't have the timing constraints to justify an FPGA design.

The likely application for this is fast custom crypto, of course.

Re: To help prevent people from buying AMD and nVi (1)

Anonymous Coward | about 3 months ago | (#47274337)

Dude, Altera FPGAs already do OpenCL (says me, a guy who helped implement it).

Re: To help prevent people from buying AMD and nVi (1)

Austerity Empowers (669817) | about 3 months ago | (#47275353)

That's great, so they're going to port their code to Open CL, then run it on your FPGA? Why not just buy a GPU and plug it in?

If they're really set on your FPGA, why not buy a PCIe attached version of your FPGA? Xilinx has them and they go up to pcie v3 x8? What about power? Datacenters care, FPGAs are going to use more power. Why is this a good idea?

Re:To help prevent people from buying AMD and nVid (1)

Forever Wondering (2506940) | about 3 months ago | (#47277297)

Some workloads perform much better on an FPGA, notably, realtime encoding/compression of HD H.264 video. I know because I've worked on such a broadcast quality encoder [currently being used by some major distribution outlets]. While you're right that it's harder to program an FPGA [in particular, validate the design], the performance gains can be huge. In particular, calculating motion vectors gets a win.

Note that H.264 DCT's are integer ones. And, with Intel's hybrid/onchip implementation, the FPGA logic could have access to the CPU's SIMD FP hardware. With Intel's hafnium and trigate technologies, adding the FPGA won't consume that much additional power.

Also note the benefits for search in an article just published today: http://arstechnica.com/informa... [arstechnica.com]

Re:To help prevent people from buying AMD and nVid (0)

Anonymous Coward | about 3 months ago | (#47279263)

This is likely what Google is buying them for. Youtube.

Re: To help prevent people from buying AMD and nVi (0)

Anonymous Coward | about 3 months ago | (#47278863)

Alteras latest FPGAs have hard floating point. The 14nm ones from Intels fabs have over 10 Tflops per chip.

Re:To help prevent people from buying AMD and nVid (1)

Eunuchswear (210685) | about 3 months ago | (#47276353)

So, does the FGPA "code" get swapped on a context switch?

Code (1)

Anonymous Coward | about 3 months ago | (#47273737)

"By using FPGAs to accelerate certain specific types of workloads, Intel Xeon customers can reap higher performance for critical functions without translating the majority of their code to OpenCL or bothering to update it for GPGPU"

LOL. But they will have to translate it to Verilog or VHDL, which is far harder.

Re:Code (3, Interesting)

fuzzyfuzzyfungus (1223518) | about 3 months ago | (#47273923)

My guess would be that the real perk is bandwidth and latency. Unless Intel really phones it in on integration, the FPGA should have about the fastest, lowest-latency, link to the CPU, possibly even some of the cache, especially if they throw in a big chunk of eDRAM, as they have for 'Iris Pro' parts, that money can buy.

Less of a "Hey, let's do this instead of GPU compute!" and more of a "It sucks that our weirdo application-specific operation is probably never going to be one of Intel or AMD's extensions to x86; but this is the closest we can get to having it added" thing.

Re:Code (3, Informative)

drinkypoo (153816) | about 3 months ago | (#47274093)

My guess would be that the real perk is bandwidth and latency. Unless Intel really phones it in on integration, the FPGA should have about the fastest, lowest-latency, link to the CPU, possibly even some of the cache, especially if they throw in a big chunk of eDRAM, as they have for 'Iris Pro' parts, that money can buy.

As usual, the slashdot post has the absolute worst story link. compare http://www.enterprisetech.com/... [enterprisetech.com] which gives you links to where it gets its info, namely https://communities.intel.com/... [intel.com] and http://gigaom.com/2014/06/18/i... [gigaom.com] ... the latter is the interesting link because it tells us that the FPGA will have access to main memory. I personally would presume that means it's tied into the memory controller somehow.

Less of a "Hey, let's do this instead of GPU compute!" and more of a "It sucks that our weirdo application-specific operation is probably never going to be one of Intel or AMD's extensions to x86; but this is the closest we can get to having it added" thing.

What I began fantasizing about immediately upon reading the article was some sort of optimizer that would semi-automatically build functional units to perform whatever function the CPU was grinding on at the moment, with some sort of recognition engine and periodic updates garnered from participating customers to help special-yet-common cases. As well, seeing how customers actually use FPGA with their products will help Intel decide what functionality to add to their next (or next+1, etc) processor.

There are already options to add an FPGA to your Xeon system, with its own blob of RAM. Since they talk about this being fundamentally different, I'm not sure what makes sense except the idea of it being connected at the memory controller. Hopefully there will be a talk with some nice block diagrams released soon.

Re:Code (2)

complete loony (663508) | about 3 months ago | (#47277581)

Bingo. Imagine an LLVM based optimisation pass that uses profiling data to take a hot code block and translate it to run on the FPGA. Anywhere in your implementation where the CPU core is the bottleneck, rather than memory access. And since it's in the CPU, you could shift from running x86 instructions to raw hardware without the complexity and latency increase of piping data to a GPU or other external device.

Re:Code (0)

Anonymous Coward | about 3 months ago | (#47279273)

How does that work with the context-switch that occurs every 15 msec on that CPU? What happens when two processes competing for the same CPU both want some hot-path FPGA mitigation? You're certainly not going to reconfigure the FPGA every time.

Re:Code (1)

complete loony (663508) | about 3 months ago | (#47279365)

Any way you set it up, your going to need OS support to reconfigure the FPGA. Perhaps a well defined section in the ELF format, with some kind of locking semantics to prevent more than one process from using it. That would depend on how many FPGA resources / CPU cores you have....

Anyone who is going to spend the money to buy and use these CPU's, will have to solve this problem. For the short term, this is likely to only be used in high end clustered server farms, for workloads where you wouldn't want to swap jobs very often anyway.

Re:Code (1)

Lennie (16154) | about 3 months ago | (#47279449)

My guess would be this is for I/O.

These customers have lots of I/O that, if you can do high performance optimized operations on a general CPU how useful would that be ?

Think of something like liberouter or NetFFPGA embedded on the CPU die.

Or maybe the FPGA is used to implement calculations like crypto and hashes like CRC32C. Instead of building them into the silicon, why not make it possible to do research by loading new versions of it.

Maybe you just need to look around on the Internet what other companies are doing with these, it might also give you hints:
http://www.embedded.com/electr... [embedded.com]

Re:Code (1)

complete loony (663508) | about 3 months ago | (#47279583)

Since this is in the CPU die, it can't add to the I/O throughput of the CPU, unless the code you're running isn't fast enough to saturate the memory bus. Even if your code is saturating I/O you might want to use an FPGA to reduce power consumption.

Re:Code (1)

Lennie (16154) | about 3 months ago | (#47279667)

It depends on what is connected to the FPGA, it could also be connected to the PCI-bus, but I guess you are right.

Re:Code (3, Interesting)

ShanghaiBill (739463) | about 3 months ago | (#47273931)

LOL. But they will have to translate it to Verilog or VHDL, which is far harder.

I suppose it depends on your skill set, but I find Verilog to be much easier than coding GPU pipelines. You just need to realize that you are not coding a program that will be sequentially executed, but a hardware description where everything happens at once. Anyway, these chips sound really slick, and I would definitely pay for a PC containing a CPU with some FPGA fabric instead of a standard X86.

Re:Code (1)

Anonymous Coward | about 3 months ago | (#47278479)

LOL. But they will have to translate it to Verilog or VHDL, which is far harder.

I suppose it depends on your skill set, but I find Verilog to be much easier than coding GPU pipelines. You just need to realize that you are not coding a program that will be sequentially executed, but a hardware description where everything happens at once. Anyway, these chips sound really slick, and I would definitely pay for a PC containing a CPU with some FPGA fabric instead of a standard X86.

You don't have to close timing on an actual circuit when programming GPU. You write your program and off you go.

That is why programming an FPGA is way harder.

Re:Code (0)

Anonymous Coward | about 3 months ago | (#47274061)

OpenCL already supports FPGA implementations. If Intel doesn't provide OpenCL support for this feature I'm betting their competitors will offer a more complete solution in short order. An AMD APU with embedded FPGA capability would rock the cryptocurrency world, IMHO. Those coin-hasher guys already know OpenCL backwards and forwards and aren't afraid to bet with their wallets.

Re:Code (0)

TechyImmigrant (175943) | about 3 months ago | (#47274147)

>LOL. But they will have to translate it to Verilog or VHDL, which is far harder.

For you maybe. Some of us write synthesizable HDL all day and it's not hard at all.

Re:Code (1)

KingOfBLASH (620432) | about 3 months ago | (#47274179)

Yes but some applications, like High Frequency Trading focus solely on speed.

If this proves faster than GPU programming, I can see a lot of people heading in that direction...

Re:Code (0)

Anonymous Coward | about 3 months ago | (#47274355)

There are already network cards equipped with FPGAs to cut the latency down for such liquidity harvesting.

Re:Code (1)

drinkypoo (153816) | about 3 months ago | (#47276987)

There are already network cards equipped with FPGAs to cut the latency down for such liquidity harvesting.

Making a general-purpose processor that people use where they used to use a bunch of custom kit is kind of intel's thing. Every so often they try making a specific-purpose processor and then they always return to generalization. This is pretty much the epitome of that trend, now they're not even telling you what the hardware will do.

This could be cool (1)

nurb432 (527695) | about 3 months ago | (#47273773)

*IF* its not some lame, slow, tiny array.. and if you get full access to it ( HDL or something )

what? (2)

dmbasso (1052166) | about 3 months ago | (#47273797)

By using FPGAs to accelerate certain specific types of workloads, Intel Xeon customers can reap higher performance for critical functions without translating the majority of their code to OpenCL or bothering to update it for GPGPU.

What? This doesn't make sense. Unless Intel invented a way to automatically generate parallel code (in which case it could also be used in GPUs), somebody would have to rewrite the relevant parts of the program in VHDL, Verilog, OpenCL, or whatever.

Re:what? (1)

Hadlock (143607) | about 3 months ago | (#47274265)

If you're paying $$ for custom Intel processors, you probably already have a way to leverage a particular function in parallel on the CPU

Re:what? (1)

st3v (805783) | about 3 months ago | (#47275037)

I see this as a really good thing. More options for parallel computing are great. Writing the parallel parts in VHDL/Verilog isn't too bad if you studied computer/electrical engineering. This is a good technology to compete with GPUs. To me, writing parts in Verilog for parallel data computations would be easier than using OpenCL and similar. I'm sure the development tools would be updated for this kind of support.

Re:what? (1)

dmbasso (1052166) | about 3 months ago | (#47275291)

I agree it is a good thing. IIRC, Altera even made a tool for synthesis from OpenCL (great for me, as I don't know VHDL and Verilog).

I'm in particular interested in that Parallella board (http://www.parallella.org/), but they're out of stock, and I've been the queue for months without a response.

Re:what? (1)

m00sh (2538182) | about 3 months ago | (#47276005)

By using FPGAs to accelerate certain specific types of workloads, Intel Xeon customers can reap higher performance for critical functions without translating the majority of their code to OpenCL or bothering to update it for GPGPU.

What? This doesn't make sense. Unless Intel invented a way to automatically generate parallel code (in which case it could also be used in GPUs), somebody would have to rewrite the relevant parts of the program in VHDL, Verilog, OpenCL, or whatever.

I would assume the FPGA part of the CPU would be programmed in VHDL. Once programmed, it would act like a set of custom instruction sets in the CPU.

Simple example. An operation like a bit circling (10010 -> 00101 move the bits one step to the left and move the first bit to the end getting 00101) is very inefficient. You can left shift but the first bit falls of and then you have to and it and then put in the end. A lot of operations. A custom FPGA operation to do just that could be just one instruction and would speed up a lot of programs.

Of course, that is a super super simple example. You could take an algorithm, analyze where it spends most of its time and turn in into "silicon" because FPGAs can be huge in capacity.

I'm assuming here running as single core CPU. Maybe one of the cores will be responsible for the FPGAs and can do parallel execution.

Re:what? (1)

dmbasso (1052166) | about 3 months ago | (#47276163)

I would assume the FPGA part of the CPU would be programmed in VHDL.

Yes, that's the obvious reasoning. And that's certainly interesting enough on its own. But the summary said

[...]for critical functions without translating the majority of their code[...]

Somebody has to do the translation, agree?

Re: what? (0)

Anonymous Coward | about 3 months ago | (#47279191)

The important part of that quote is "the majority" I think.
Implying that some translation is needed but not as much as other methods like GPGU.

Re:what? (1)

jimmydevice (699057) | about 3 months ago | (#47278507)

It's called rotate, and MOST CPU's can do it.

Re:what? (1)

complete loony (663508) | about 3 months ago | (#47277717)

IMHO hardware design tools have had far less investment than compiler tools, and we're overdue to invest more effort in improving them.

Since the FPGA is in the CPU, I assume there are either CPU instructions to pipe data in and out of the FPGA. Or the FPGA may have direct access to the memory controller / cache. Either way you need a good way to synchronise between them.

So consider a solution that takes LLVM bitcode and runtime profiling data. Pick out some number of hot code blocks in an optimisation pass, translate the data flow into VHDL (or write something better....) build that, calculate the final circuit timing, replace the code block with new LLVM intrinsics to hand over control, then in the back end emit the new CPU instructions.

Obviously you'll also need to modify the operating system to manage the configuration of the FPGA, and ensure that you don't blow up the chip by running the wrong code at the wrong time.

But I think there is plenty of scope to implement something like this. There just hasn't been a need to build the tools before now.

Re:what? (0)

Anonymous Coward | about 3 months ago | (#47278697)

> (in which case it could also be used in GPUs)

FFS, who mods this bullshit up? GPUs are not remotely similar to FPGAs.

Not only that, C to logic compilers for FPGAs have existed for several years already although the results are not nearly as good as hand crafted HDL.

OMG I WANT! (1)

BitZtream (692029) | about 3 months ago | (#47273821)

As a hardware hacker, god I want one of these. On chip reprogramable DSP!? While it's a niche market, I'd love to get my hands on some, and not have to give up my favorite OS or build custom boards to do signal processing.

Re:OMG I WANT! (1)

nurb432 (527695) | about 3 months ago | (#47273869)

I tend to agree and will want one or 2 myself, but it still wont be quite as cool for hardware people, as you dont have any "programmable" pins hanging off this thing..

Re: OMG I WANT! (0)

Anonymous Coward | about 3 months ago | (#47273893)

I guess all those programs listening to microphones to identify music (and transcribe conversations on the sly) heralded a need for more processing power and more DSPs in the cloud.

Re:OMG I WANT! (1)

Bill_the_Engineer (772575) | about 3 months ago | (#47275609)

Or you could just run out and buy yourself a Virtex FPGA.

Re:OMG I WANT! (1)

Anonymous Coward | about 3 months ago | (#47276023)

Looks like you misspelled Stratix.

Actually the Virtex parts are faster (IO, at least) and larger, but Altera has OpenCL and. IMO, a much better toolchain than Xilinx. Xilinx has some awesome technology for 2.5D interposer hybrids which is bringing the scale up and the cost of scale down, but Altera has Intel 14nm trigate for their upcoming Stratix 10 parts, which may mean they are faster than Virtex 7.

Re:OMG I WANT! (0)

Anonymous Coward | about 3 months ago | (#47293703)

Xilinx has OpenCL for the Virtex-7. The Virtex line is not only more than capable at DSP processing but some models actually come with one or more PowerPC cores. Even the Virtex-4 models which are years old have the capability that Intel is beginning to offer in the article above.

Re:OMG I WANT! (1)

dargaud (518470) | about 3 months ago | (#47275647)

Yes, I do data acquisition, and we only use board with FPGAs, such as Xilinx' offerings. This way we don't have to deal with the horrors of real-time OSes. Just do the acquisition in VHDL and send the buffer to the OS via a simple to write driver. Those would blow Xilinx out of the water (not that it's necessary for most low-power low-speed applications)

Perfect for High Frequency Trading platforms (1)

JoeyRox (2711699) | about 3 months ago | (#47273829)

Dedicated FPGA HFT cards are ridiculously expensive. I wonder how integrated the FPGA will be in terms of interconnects with PCIE and the Xeon caches.

Strange duck (0)

Anonymous Coward | about 3 months ago | (#47273857)

So this is drop-in replacement pin compatible with existing Xeons? That means no dedicated I/O and a shared TDP. Seems like this is potential solution for certain CPU bound algorithms (crypto comes to mind) but nothing world shattering. If the cost barrier of entry is low enough this could be a boon for privacy. I wonder what sort of export regulations will be slapped on these devices?

Re:Strange duck (0)

Anonymous Coward | about 3 months ago | (#47274015)

Bitcoin mining

Re:Strange duck (1)

fuzzyfuzzyfungus (1223518) | about 3 months ago | (#47274113)

Given that Intel added AES-NI without a ripple several years ago, and somewhat similar crypto acceleration functions were available on Geode LXes and some fairly antique VIA x86 cores(and very likely a lot of embedded stuff that was too feeble for much software crypto, albeit probably not exposed to anybody who hadn't sold their soul to qualcomm for BREW elite developer status or something), probably not many beyond whatever ones apply by default to all kinds of things.

As a matter of policy, the feds of the world appear to have largely recognized that the cat is out of the bag on strong crypto, algorithms and software move too easily, and doing it in software is too fast (for common purposes, obviously terminating a massive number of TLS connections or something isn't for the faint of heart).

They've not been shy about mandating 'lawful intercept' features, cultivating access to trusted links in the system, and ensuring that the overall level of security remains low; but the "Put your head in the sand and pretend that keys longer than 56 bits don't exist!" theory of regulation is largely a relic.

Re:Strange duck (2)

TechyImmigrant (175943) | about 3 months ago | (#47274239)

> pretend that keys longer than 56 bits don't exist!" theory of regulation is largely a relic.

But the law [gpo.gov] still sets a limit at 64 bits and requires you to get an export license for anything beyond.
 

Re:Strange duck (1)

fuzzyfuzzyfungus (1223518) | about 3 months ago | (#47274391)

True, though you'll note that many of the changes in the linked document refer to loosening after encryption systems were removed from 'munitions' classification and assorted expansions of 'self-report', new categories with reduced reporting requirements, and so on.

I have no doubt that the amount of paperwork require to fully comply with the law in exporting something every war3z kiddie in Iran already has is still silly, and I don't doubt that there's a cube somewhere in Intel Inc. whose salary is justified by filling it out; but this isn't the big flap over PGP era. I'm not sure that the regulations will ever die off entirely, especially the stuff governing large outfits, since the marginal cost of one extra form is so low; but as a matter of strategy direct attacks on cryptographic systems have substantially faded (since you can't keep software away from criminals, and you can't bank safely with stuff law enforcement can easily brute force) in favor of RIPA/CALEA style legislative compromises.

Speeding up specific workloads... (0)

Anonymous Coward | about 3 months ago | (#47273867)

... like hijacking decrypted data in realtime to send to the NSA.

A beer says you can sit this FPGA directly on the memory bus and snoop anything you want, including decrypted data.

Three Words (2)

jtara (133429) | about 3 months ago | (#47273897)

High-Frequency Trading

Not the first of its kind (0)

Anonymous Coward | about 3 months ago | (#47274085)

See Stretch's ISEF [stretchinc.com]

saw it coming (0)

Anonymous Coward | about 3 months ago | (#47274089)

This is also to keep apple happy so they don't start adding coprocessors to their laptops and start moving away from intel. They've already been adding accelerators to their A7 line.

SoC, FPGA Development (5, Interesting)

volvox_voxel (2752469) | about 3 months ago | (#47274361)

I have a friend in that in graduate school used a motherboard that could take an Altera FPGA in one of the Xeon sockets. This seems like the next logical step; hopefully it's not too expensive so that the hardware is accessible to hobbiest/engineers. I am happy that both Xilinx and Altera offer cheap development boards so that we can play with the new offerings. It's easier to convince a boss to use it if we're familiar with it. (hint hint, wry grin)

I use the zynq processor at my job, and am very happy with the amount of flexibility you can get out of an embedded system having access to the FPGA and processor fabric; you can directly access gigasample ADC's, etc. When I first got into embedded systems on an FPGA, the processor was a soft-IP and not terribly fast. Both Xilinx and Altera now offer ARM processors that run up to 1GHZ. The amount of system flexibility is great. You can make major architectural choices without changing the hardware. You might have a data-path, or computation that is simply too intensive for a processor to handle.. You have the flexibility to port this portion to the logic side. If you're in a rapid prototyping mode and are constrained by board size and mechanical packaging constraints, FPGAs are great.

Debugging SoC still has it's challenges though. It's easy to program FPGAs, and easy to program the microprocessor. The tools are still a little clunky from Xilinx or Altera to handle their hybrid SoC parts. There is still work to be done to make them work more seamlessly.

Custom hardware malware, factory direct to you (2)

Nkwe (604125) | about 3 months ago | (#47274367)

Think of the fun that could be had with this. Fits in the same socket and does who knows what.

Re:Custom hardware malware, factory direct to you (1)

Gothmolly (148874) | about 3 months ago | (#47274751)

Custom NSA snooper/decrypter, running at the hardware level.

YUO FAIL IT! (-1)

Anonymous Coward | about 3 months ago | (#47274399)

If *BSD is to reaper Nor do the as those non 6ay, ransom fo3r their over to yet another

It may also be Achronix (0)

Anonymous Coward | about 3 months ago | (#47274485)

It may also be Achronix. They are also providing FPGA:s with Intel process.
http://www.achronix.com/

Re:It may also be Achronix (0)

Anonymous Coward | about 3 months ago | (#47274827)

It must be.
There they already have an FPGA with Intel QPI interface
http://www.achronix.com/applications/hpc.html

what about the ram / pci-e lanes that are socket (1)

Joe_Dragon (2206452) | about 3 months ago | (#47274541)

what about the ram / pci-e lanes that are part of the socket?

Maybe in 4 way boards or some 2 socket boards.

2 socket broads can work with only 1 cpu. But what will they do when they see a filled socket but no ram and no PCI-E io?

Re:what about the ram / pci-e lanes that are socke (1)

viperidaenz (2515578) | about 3 months ago | (#47275085)

I don't know what you're talking about here
They're not selling FPGA's in an Intel socket. They're selling Xeon CPU's with integrated FPGA's.

Great for special topologies and interconnects (0)

Anonymous Coward | about 3 months ago | (#47274781)

We're talking google and facebook here, they are perfectly willing to hire EEs capable of doing very low-level and very high-level VHDL designs, and they use custom motherboard designs already. So, they wouldn't really be restricted to software-only uses for the on-die FPGA like packet processing or custom crypto offloading.

These FPGAs could be used for better node interconnects. Getting it done using QPI is insane, the whole box can go unstable, and it becomes a large and unwieldy NUMA box, something neither google or facebook would need or want.

OTOH, give me a large enough FPGA directly wired to the CPU, and I could deploy an extremely low latency RDMA-based interconnect for hardware-assisted MPI that would be MUCH cheaper than deploying Myrinet-like interconnects over the entire DC (development cost is not that high, a two-man team can do it in one year, so it will be around US$ 1M tops, and you pay it only once). This looks like something more interesting for content providers with large DCs like google and facebook.

Of course, maybe they just want to run python/java bytecode directly on hardware or something. That'd be lame and terribly easy to implement (and likely not much of a gain over running it JITted in the main CPU).

Re:Great for special topologies and interconnects (1)

viperidaenz (2515578) | about 3 months ago | (#47275063)

How can they be used for interconnects?
The CPU fits in the same socket an existing Xeons.

Looks more like a way to compete with AMD+GPU with just an Intel CPU.

This explains it (1)

viperidaenz (2515578) | about 3 months ago | (#47275039)

This explains why Intel was selling fab time to an FPGA vendor.

Re:This explains it (0)

Anonymous Coward | about 3 months ago | (#47276131)

No, this is something different.

It has already been press released a year ago that Altera are making Stratix 10 and and Aria 10 on Intel 14nm trigate, and they have been making Achronix 22i on Intel 22nm FinFET for two or three years now.

The question is this: Is it an Altera FPGA, Achronix or Tabulus. They are fabricating for all three programmable logic companies, but by far Altera has the largest market share (smaller than Xilinx, of course). On the other hand, that might mean Intel could squeeze better pricing from Achronix. A typical Xeon sells for $500 ~ $2000 a piece, a typical Stratix sells for $5k ~ $20k a piece.

Are these things going to be Stratix priced or Xeon priced?

Re:This explains it (0)

Anonymous Coward | about 3 months ago | (#47276419)

No, this is something different.

It has already been press released a year ago that Altera are making Stratix 10 and and Aria 10 on Intel 14nm trigate, and they have been making Achronix 22i on Intel 22nm FinFET for two or three years now.

The question is this: Is it an Altera FPGA, Achronix or Tabulus. They are fabricating for all three programmable logic companies, but by far Altera has the largest market share (smaller than Xilinx, of course). On the other hand, that might mean Intel could squeeze better pricing from Achronix. A typical Xeon sells for $500 ~ $2000 a piece, a typical Stratix sells for $5k ~ $20k a piece.

Are these things going to be Stratix priced or Xeon priced?

Altera, I hear.

And of course it's going to be Stratix priced. This is aimed at the cost insensitive enterprise market after all.

old timer here... (1)

Larry_Dillon (20347) | about 3 months ago | (#47275247)

Image a Beowulf cluster of these!

Intel have done this before... and here's the snag (3, Informative)

Dogtanian (588974) | about 3 months ago | (#47275757)

Intel has already come up with an Atom CPU with integrated FPGA [slashdot.org] , but only for the embedded market.

I'd already been thinking about the possibility of end-user-accessible, on-the-fly-reprogrammable FPGA functionality as part of a "regular" computer before I heard Intel had produced an integrated CPU/FPGA (though it's not clear how easily configurable the FPGA was there). I raised the issue in that previous thread and got a *very* interesting and informative response [slashdot.org] (thank you Tacvek) that pointed out some major problems with the concept of general access to such functionality.

The issues raised there explain why Intel are unlikely to be making an easily-reconfigurable hybrid product like this available to the general public any time soon, however smart and exciting the idea sounds.

Two words: (1)

kheldan (1460303) | about 3 months ago | (#47276175)

'Cryptocoin mining'.

HF Trading (1)

smcdow (114828) | about 3 months ago | (#47278849)

I bet HF trading ends up being a prime market for this technology.

Customer Instructions (1)

ThermalRunaway (1766412) | about 3 months ago | (#47279025)

I hope they allow customer instructions like the NIOS soft CPU in Altera FPGAs. This lets you create customer HW to implement some function at the ISA level... Altera lets you do single or multi cycle return. And auto generates either an instruction for ASM use or some stubs for C. It really is super useful.

Privacy? Yeah, we've heard of it. (1)

VinylPusher (856712) | about 3 months ago | (#47279429)

"Bob, we're glad you Intel boys have finally come around".
"Hi Jeff. Yeah, well we just about got the marketing boys convinced enough to run with it. They managed to find an angle that flies pretty well. Gets us off the hook and gets your boys into a heck of a lot of servers!"
"Hey, it's a win-win so far as I'm concerned. Wish it could have been sooner though, but what with all this pressure from the purse-holders, we couldn't bankroll it for you".
"Times are getting tough, huh? It wasn't that long ago you NSA boys had infinitely deep pockets".
"The times we live in, Bob. What can you do?".
"You need any help with the rootkit code? Some of our wizards are pretty good"
"Thanks, Bob, but we already have it covered".

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>