Intel Launches Atom CPU With Integrated FPGA

An anonymous reader writes "Intel is quite clearly serious about offering competition to ARM in the embedded market, and has just announced a new Atom processor series that offers a unique selling point: an integral FPGA processor. Billed as 'the first configurable Intel Atom-based processor,' the Atom E600C series combines an Intel Atom 'Tunnel Creek' chip with an Altera Field Programmable Gate Array — offering, the company claims, significantly more flexibility for ODMs and OEMs."

Comments

Awesome

[phantomcircuit]

Assuming it's priced relatively reasonably, that is fucking awesome.

Re:Awesome

[badran]

From the article:

Previously rumoured under the codename 'Stellarton,' the Intel Atom E600C series will initially comprise the E665CT, E645CT, E665C, and E645C chips, and become available for ordering priced between $61 and $106 (around £38.21 to £66.40) in batches of 1,000 in the next two months. A further two processors, E625CT and E625C, will hit the channel in the first quarter of next year.

Re:Awesome

[arivanov]

It is not the pricing which is interesting here, it is will there be anticompetitive marketing restrictions.

Atom was intentionally crippled through pairing with crippled 5+ year old video and a specific resolution restriction for systems with it. After NVidia broke this restriction it was redesigned to exclude it.

i815e was intentionally crippled to 512 RAM through a marketing restriction so that RDRAM and 840 and 820 sell.

Turning off SMP anywhere they could turn it off for 10 years since PPro so that the "server varieties" of the same chip (often from the same tray) sell.

And so on.

Intel has a long history of shooting itself in the foot on non-cannibalisation grounds. I suspect it shot itself here as well. This can make a phenomennal HPC platform due to its motherboard "real estate" and cooling requirements, however that will eat into Intel Xeon + QPI enabled FPGA sales. So I guess it will be crippled through marketing to disallow that.

FFS, it does not take a genius to understand the basic idea that "If there is money in it, someone else will cannibalise it for you, so you might as well cannibalise yourself and expand the market".

Re:Awesome

[Elbereth]

Dude, everyone does that. AMD/ATI does it, Nvidia does it, IBM does it, Motorola used to do it, and if Apple ever designed/manufactured anything themselves, they would do it, as well. It's called marketing. Those $1000 "Extreme" CPUs that Intel sells only cost about $100 to manufacture, if that. Probably only $25 or $50. How do you think Intel recoups its R&D costs? It prices the high end chips as high as the market will allow, then sells the mid-range chips for a more reasonable price.

Did you forget that AMD was selling Athlon XP and Athlon MP chips at wildly different prices, even though you could enable MP on the Athlon XP by drawing on them with a pencil? What about disabling MP every one of the later Athlon chips? Even some Opteron chips have MP disabled! That's seriously wrong, in my opinion. As far as I know, no Xeon has ever had MP disabled. Say what you will about Intel, but if you buy a Xeon, you know what you're getting.

What do you want Intel to do, anyways? Sell all their CPUs at manufacturing cost, with no feature differentiation at all? So that everyone can buy Xeon MP chips for $50 each? Yeah. OK. Let's see how long that lasts. I'd say Intel would be bankrupt in less than a year.

Seriously, dude, if you want cheap SMP motherboards and CPUs, go shop on ebay for used stuff from failed dotcoms. That's what I used to do. I even scored some high-end server-grade hardware, like DEC Alpha CPUs, SCSI RAID enclosures, SCSI drives, and smart UPSes. There's no need to rant about Intel's "anti-competitive" tactics, of which exactly zero legitimate examples exist in your post. Intel has done some pretty shitty things in the past, but this isn't one of them. Save your rant for something that matters.

Re:Awesome

[Man On Pink Corner]

Dude, everyone does that. AMD/ATI does it, Nvidia does it, IBM does it, Motorola used to do it, and if Apple ever designed/manufactured anything themselves, they would do it, as well.

Dude, WTF? If Apple were any more vertically-integrated they'd own their own African tantalum mine.

Re:Awesome

[TheThiefMaster]

Did you forget that AMD was selling Athlon XP and Athlon MP chips at wildly different prices, even though you could enable MP on the Athlon XP by drawing on them with a pencil?

Done that. It ups the heat output of the chip from "lots" to "ow my fingerprints"...

I suspect that the chips actually sold as MP were from the higher-end binnings so that they produced less heat (the same bins that the highest performance and the laptop versions of the chips also come from). The "midrange" chips often can't be clocked to the same speed as the top-end chips, because they are physically inferior.

Incidentally the Athlon XP-M chips used less power and put out less heat than the normal ones, and oddly were left with MP enabled. Unfortunately unless you have an MP board capable of manually altering the CPU multiplier (mine didn't) or you cut a bunch of traces on the chip, they'll only run at 4x the fsb (600MHz in my case). Seeing how things freak out when you have one 2GHz cpu and one 600MHz cpu in SMP was interesting though.

Re:Awesome

[teachknowlegy]

Throwing a bunch of hardware together and putting a software layer that seamlessly integrates them (to the user) may be a great marketing strategy, but that doesn't mean they created the stuff.

Re:Awesome

[PopeRatzo]

Even some Opteron chips have MP disabled!

You know, the first thing I thought about when reading that Intel was going to include FPGA on the Atom was that some manufacturer(s) would figure out how to use it to give consumers less for their money, or preventing them from doing something with their hardware.

Re:Awesome

[DrSkwid]

s/YOUR MESSAGE/every company in the world tries to charge what the market allows them to, it's called the elasticity of demand such that price is determined by competition not the price of production.

Re:Awesome

[izomiac]

I've never quite understood why CPU manufacturers intentionally cripple their products. It's not like their industry is completely different economically. Nor is it like cooks go out of their way to make food taste worst if it happens to come out better than expected. They're literally spending money to make their product worse!

As for R&D, that would suggest that people who buy "extreme" versions are subsidizing CPUs that are underpriced for everyone else. I seriously doubt Intel is actually losing money with their most popular processor lines, so I think that's essentially marketing (i.e. creating product differences when none intrinsically exist). "Here, buy this widget for three times the cost, we didn't pound on it with a hammer."

Re:Awesome

[samkass]

And the chip design companies they bought and the chip design people they still employ are just there to improve their marketing too, right? The anti-Apple conspiracy arguments are getting weirder by the week. Yes, they base their chips on established designs and don't create every chip from whole cloth. But you don't get products into form factors like the MacBook Air, iPad, and iPod Touch by just throwing together off-the-shelf parts.

Re:Awesome

[CAIMLAS]

Yeah, maybe. I'm sure some people will attempt it. But you're forgetting something crucial: warranties.

If you drive your car off a cliff, you've voided the warranty. The same basic principle applies here.

Re:Awesome

[maxume]

It's basically tautological that selling the products at the highest prices they can will increase their capacity to do research (but only in a financial sense, they aren't necessarily going to utilize the full capacity).

Re:Awesome

[BitZtream]

Steve owns the mine and the workers in it, he just sells its product to Apple.

Re:Awesome

[teachknowlegy]

Just like the Windows phone I used to read your comment was made by Microsoft, even though HTC Snap is written on it. Motorola made most of Apple's chips. Just cause they "improved" it by putting a little multicolored apple with a chunk taken out of it over the label doesn't mean they created it. Apple is just a better integrated version of what everyone else is doing, and therefore it's quite often priced higher. Same thing as cars. Better integrated = higher value. The "prototypes" usually end up with more bugs and worth less down the road.

Re:Awesome

[wazzap123]

You bet it is. Now... where is my FPGA App Store!

Re:Awesome

[Whiteox]

Wrong! Currently I'm running an Intel board which is almost an exact duplicate of the first Apple 86x boards. They were sourced from Intel with minor chip differences and can be loaded with 10.5 easily.

Don't know if this is a first

[smoot123]

I seem to recall Xilinx offering a FPGA with an embedded PowerPC core 8-ish years ago. Or maybe it was four cores, I heard it from a co-worker.

Seemed like a fun part to hack around with. Too bad we never got to use any.

Re:Don't know if this is a first

[Anonymous Coward]

All of the Xilinx Virtex parts have an integrated PPC hardware core. This announcement is somewhat different, though, in that it seems they have integrated an FPGA fabric on a traditional CPU die.

Being able to implement application-specific memory controllers would be handy, to say the least.

Re:Don't know if this is a first

[commlinx]

I seem to recall Xilinx offering a FPGA with an embedded PowerPC core 8-ish years ago. Or maybe it was four cores, I heard it from a co-worker.

Summary does say 'the first configurable Intel Atom-based processor'.

But yeah Xilinx have had PowerPC on FPGAs for a while and they are still current products. Altera has offerings with an embedded CPU as well

Re:Don't know if this is a first

[the_other_chewey]

This announcement is somewhat different, though, in that it seems they have integrated an FPGA fabric on a traditional CPU die.

No they haven't - it's two chips in one package.

Re:Don't know if this is a first

[Pikoro]

Yo dawg! I heard you like CPUs... so we put a cpu in your cpu...

Re:Don't know if this is a first

[Doc Ruby]

Two problems holding back CPU+FPGA products were power consumption (and related heat dissipation) and price. Those limits also are finally holding back CPU products (or rather the products they're embedded in) overall, which is why there's a market for Atom or ARM chips at all. Meanwhile, overall market demand for embedded PCs that contain complex, high performance logic is growing very quickly, especially in automotive and energy industries. So the stars seem to be crossing each other right this time, after years of FPGA vendors learning what to avoid in the products and their marketing.

..... Really?

[del_diablo]

I would say x86 fails before it uses too much power per unit of processoring power.

double rainbows

[__aatirs3925]

I'm kinda excited for whatever this means. Could somebody please explain? Does this mean Atom processors might be useful now?

Re:double rainbows

[Neil Boekend]

It means that intel has thrown an FPGA into a normal CPU. FPGA's are highly programmable chips that are very fast in the thing they are programmed for. Changing the programming takes, by comparison, a lot of time and they usually can't do anything else than what they are programmed for.

If you would program one to be a decryption device you could have very fast decryption, but you can't let it do something else when there is nothing to decrypt (multitask).

All in all the result will be a major increase for applications that are reprogrammed to be in the FPGA (and are small enough for the FPGA) but nothing will change for the other applications.

There are many other chances and limitations, as it is a completely different device, but these are the most important (as far as I know) in this case.

Re:double rainbows

[Kjella]

If there was a mass market, you'd make an ASIC. This lets embedded developers create special circuitry for whatever embedded need they have, which is useful but I don't see it as a mass market product for regular consumers.

Re:double rainbows

[Anonymous Coward]

Essentially this means that there is a chunk of the processor which will be *COMPLETELY* configurable. FPGA stands for "field programmable gate array" which just implies that you can re-program the way those gates are connected *after* the chip has been manufactured.

Without understanding basic electrical engineering logic it's hard to describe all the neato things you can do with this, but essentially FPGAs can do all sorts of neat things and they can do them in parallel. If you've ever heard of something being "cheap in hardware but expensive in software" that's exactly what an FPGA can solve.

Something like this (assuming the FPGA had enough gates) might allow you to implement the HDCP decoder in "software", and decode the bitstream in realtime. This would be neat!

Re:double rainbows

[ThermalRunaway]

FPGAs are useful as the actual digital circuits are re programmable. So you could theoretically patch your CPU and change the physical functionality of at least part of it. This would lead to all sorts of nice customizations.

One interesting aspect of the Altera soft CPU (NIOS), is that you can add custom HW directly into the execution unit, basically making your own HW instructions. Then you can generate an assembly instruction for it and use it right from your code. This lets you do nifty things like build a custom piece of HW to implement some arcane computation that is specific to your particular use of the HW and have it built right into the CPU. Wonder if there is this sort of setup here.. that would be pretty nice.

www.altera.com/literature/ug/ug_nios2_custom_instruction.pdf

Re:double rainbows

[Arlet]

This is not a soft core CPU. You get a package with 2 dies inside: a regular Intel Atom CPU core, and a separate FPGA.

Re:double rainbows

[ThermalRunaway]

I know.. I've simply giving an example of an interesting way Altera lets you customize some of their IP. The Atom has an Intel core and an Altera FPGA... im doing some wishful thinking that maybe you would get some level of access to the CPU like you do with the NIOS.

Re:double rainbows

[Darinbob]

This sort of stuff isn't done for a general purpose computer usually. Instead you put whatever hardware acceleration you need into the FPGA because you've got an embedded system or have application specific hardware. It's often used when you have a low volume of devices that you're making because FPGAs are relatively expensive but easy to modify if you find bugs. I've worked on a system that had multiple FPGAs + multiple DSPs + CPU (and a big fan).

Though you can use them for things other than hardware acceleration as well, such as putting "support" hardware in the FPGA, simple peripherals, memory controllers, or whatever you can dream up. So it could be used for something like a netbook or mini tablet potentially.

Re:double rainbows

[sznupi]

Atom would almost certainly win handily

Re:double rainbows

[wvmarle]

Interesting. I was thinking the same as GP: what the heck is that!

Can this reprogramming be done by the OS, upon need? And how slow is slow?

Could be nice for e.g. video decoding.

Re:double rainbows

[SuricouRaven]

The Atom is not made to be fast. It's made to be fast *enough* while also very efficient. It'll give you around half the per-clock performance of a P4 (Citation needed), but do so at well under a tenth the power consumption. Perfect for portables, embedded, thin clients, etc. Throwing in an FPGA is aimed at the embedded sector: Have the heavy number-crunching tasks done in highly efficient FPGA, while the x86 core does general management and everything else.

Re:double rainbows

[Macman408]

Probably not for anything you'd be interested in. Unless of course, you're interested in a slow CPU with slow (but custom) logic. If you want fast custom logic, or ridiculously low-power, you go with an ASIC (assuming you have either high volume, or can tolerate a high per-unit price). If you don't have a rather complex, repetitive calculation to do, you go with a regular CPU. If you do have a big calculation, you might consider a faster CPU or GPU, or at least something with a faster connection between the FPGA and CPU. If your calculation isn't particularly complex (eg something simple like adding two numbers), a CPU will already be faster and lower-power, assuming it has an instruction (or several) that implements the function you need.

In the end, Intel has just managed to invent yet another piece of hardware for which there is no good programming model. It's been how many years, and there is STILL no killer model for programming multiple core machines? Yes, there are many ways, but each has pretty significant disadvantages, and the vast majority of applications that people use see very minimal benefit from multiple cores (often because there's no great way to program for them without investing significant effort, see previous sentence).

This will be interesting for small embedded systems designers, who can come up with nifty ways to use the hardware, don't have large volumes, and can charge high prices since their customers have low-volume very specific needs. The rest of us will ignore it, forget it, and not shed a tear when Intel quietly discontinues the product.

Re:double rainbows

[Bozzio]

This could have interesting implications for game AI.

Depending on how slow the FPGAs are to reprogramit'd be interesting to use these to simulate a neural network, or something similar. Live, adaptive AI which is independant of the CPU :)

Re:double rainbows

[Vectormatic]

man, i remember working on a nios II project back in 2005 for my internship, that was an awesome experience, configuring my own cpu, bus-clock, multipliers, memory interfaces and all that stuff

Compile times sucked though, especially since the best hardware us interns got was a 2.4 GHz pentium 4.. i would click compile and go for a walk around the building, get tea/coffee, returning to find my 45 minute compile couldnt achieve the clock speeds i wanted it to run at...

Re:double rainbows

[Morty]

Some vendors, such as Juniper, have transitioned at least some of their product lines from ASICs to FPGAs. A problem with ASICs is that you can't patch them for security issues. This is bad if, say, you sell firewall products.

Re:double rainbows

[wisty]

Video decoding may be better on a dedicated chip. A good GPU should be fine (oh wait, it's Intel ...)

I guess FPGA could be used for nifty device drivers. You don't want to change the touchscreen interface very often (as an example), but if you (shudder) encounter a bug then the FPGA can be modified.

Re:double rainbows

[marcello_dl]

Could the FPGA also implement codecs? that would be a more flexible alternative to hardware based decoding/encoding. Or is it a job for a programmable dsp instead, I don't really know.

Re:double rainbows

[jittles]

Atoms aren't totally useless. I actually have a dual core atom that I am using as a server, with a VM running. I also remote desktop into the machine and use it on a daily basis at work. Since I'm pretty much the only user of the machine, it works perfectly and consumes under 30W. I used to leave my desktop on 24 hours a day and it was sucking up 300W all day long. That's a huge power savings for me at $0.12a kWh.

If you're wondering why I keep this thing running all the time its because I run an SVN, VPN, and Zimbra mail server on there. I like being able to VPN into my home network from anywhere. I use an x86 architecture instead of PPC because that's what the software I need to use supports. Otherwise I'm sure I could get my power consumption down below 10W.

I will also admit that I cheat and run this all on an SSD, which definitely helps with some performance.

Re:double rainbows

[icebraining]

This isn't for users, it's for ODMs and OEMs. You'll probably need physical access and a programming board to program the FPGA, no realtime in software programming.

Re:double rainbows

[icebraining]

Wouldn't a GPU with GPGPU be better at that anyway?

Re:double rainbows

[allaunjsilverfox2]

And REALLY piss off intel at the same time. Using Intel chips to decode hdcp would be pretty ironic. I mean, Can you imagine using the FPGA to do the grunt work of decoding and then using the cpu to re encode the stream?

Re:double rainbows

[wvmarle]

That's why my question: how slow is slow to reprogram? Could this be a replacement for various dedicated chips - taking up a task when needed? Like when you want to play a video, it becomes video decoder, or maybe it can be used for other tasks that are fairly intensive, and last long.

Re:double rainbows

[mr_mischief]

The only sure answer is unfortunately "it depends". Just because they are programmable in the "field" doesn't mean you can necessarily do it from software. Some FPGAs require a service tech to hook some other system up to the motherboard to change anything. Some require pulling the chip and putting it in a portable device. Some can have different programs swapped in from ROM at different times. Some can have custom programs loaded from RAM by an application. I'm not sure which this is, but since it's the Atom line I'm guessing it's going to be one of the more restrictive types to reprogram.

Re:double rainbows

[RevWaldo]

Could this be used as an anti-jailbreaking tool? "Unauthorized OS detected, reprogram FPGA to 'guacamole mode' "

.

Re:double rainbows

[DrSkwid]

No, Transmeta Chips did on-the-fly binary translation.

And it turned out to not be a selling point.

Re:double rainbows

[OeLeWaPpErKe]

If they're large enough. An FPGA h264 codec uses 100k + gates, not something found in tiny cheap low-power fpga's.

Re:double rainbows

[OeLeWaPpErKe]

Then what is their value proposition ? "1 chip is slightly cheaper" ? That wouldn't convince many people.

If people use this, it will be for the live reprogramming feature.

Re:double rainbows

[Andy Dodd]

Given that some of Xilinx's parts can reconfigure from flash memory in only 1-2 seconds, this much smaller part should be able to configure in under half a second if the reconfiguration architecture is done right.

So you could reconfigure it as part of an application startup sequence. Not sure how you'd handle device contention though (an attempt to run two apps that both want to use the FPGA - context switching would be a real bitch).

Re:double rainbows

[the eric conspiracy]

Yeah, but SSDs have more CPU overhead than HDs. If you are running something that doesn't do a lot of disk I/O it may be that you would be better off with an HD.

Re:double rainbows

[mrand]

s/some vendors/most vendors/

Telecom and datacomm equipment have long used FPGAs at key points in their systems for one or more of the following reasons:

* off-the-shelf silicon sometimes costs to much

* off-the-shelf silicon is missing something that is important to you (maybe an interface type, or a key feature)

* off-the-shelf silicon doesn't have the density

* ASIC's cost a lot to develop, and prices have been going up (while each year, FPGA prices go down). If you don't have pretty high volume, each year it has gotten harder and harder to justify.

A number of HDTV's had Xilinx Spartan FPGA's in them... I'm guessing that some still do.

      Marc

Re:double rainbows

[damien_kane]

Yeah, but SSDs have more CPU overhead than HDs. If you are running something that doesn't do a lot of disk I/O it may be that you would be better off with an HD.

[Citation needed]

Current-gen SSDs don't have the high-overhead found in those released even as recent as a year ago.

Re:double rainbows

[LUH 3418]

Current GPUs are only really useful for some tasks. Namely, code that doesn't do alot of branching (e.g.: matrix multiplication). The rest can't really gain that much performance. Not to mention, you have to manually upload and download data to the GPU, it's a total mess to program.

With an FPGA, you can generate on-the-fly a customized hardware accelerator for your problem domain. This could be a processor with specialized instruction for your problem domain, a vector processor, or even a hardware raytracing accelerator.. Whatever you need, so long as the FPGA has enough resources to encode it... And, it can potentially have access to the same memory bus as the CPU.

This won't beat a GPU at raw floating-point power, but it's just much much much more flexible in what it can do.

Re:double rainbows

[tlhIngan]

Yeah, but SSDs have more CPU overhead than HDs. If you are running something that doesn't do a lot of disk I/O it may be that you would be better off with an HD.

[Citation needed]

Current-gen SSDs don't have the high-overhead found in those released even as recent as a year ago.

Actually, SSDs have the same overhead as a hard disk. Even those of a year ago - it's all SATA anyhow. It's just that you're completing I/O operations so much faster on an SSD that the CPU is busier because it can get more stuff done - it's not wasting time waiting for the disk.

If you need to seek 10,000 random blocks and you have a 1GHz processor, a hard disk will take under 100 seconds to do it (most hard drives have sub-10ms seek times, which lets you do just over 100 random I/O operations a second). So any processing you do per block is distributed over those 100 seconds, and the CPU is idle the rest of the time (or doing something else).

A decent SSD would complete those operations in about a second, maybe 2-5 for the lousier ones. Thus the CPU is busier since it's doing in a few seconds what it used to do in over a minute.

CPU utilization during an random block seek test isn't a valid metric because it's easily doing nearly 100 times more work because rhe results come in that much faster. If you really want to measure it properly, you need to do, say, a million block reads and time not only how long that takes and how much CPU time was spent doing those. It's just that the hard drive has amortized it over a longer period of time that the utilization appears lower. The SSD can work much faster so the utilization is higher but the CPU time actually used is the same.

Re:double rainbows

[stoanhart]

The FPGA's I've worked with lose their programming when the power goes out, and are reflashed by software on every boot.

Re:double rainbows

[LUH 3418]

There is a programming model for FPGAs. They have their own programming languages which are widely used in the industry (Verilog/VHDL). This model isn't so different from the way OpenCL is used with GPUs. This kind of design will work well for some applications, where custom hardware accelerators can be precompiled and loaded on demand. There will already be demand for this. Some companies that can't afford to make ASICS will certainly like the idea of integrating their own decryption/routing/video accelerator into a chip for cheap, and be able to patch the hardware.

I would personally love to have a CPU that's coupled with an FPGA because it would allow things like implementing your own raytracing accelerator. You can even implement a whole custom CPU into an FPGA... To give you an idea of the flexibility, you can design your own custom memory controller, your own cache. Custom-design your own CPU with a hardware-accelerated garbage collector... The possibilities are boner inducing....

I don't know how much of a difference it will make for customers in the very near future, but for researchers, this will be an invaluable tool, and it might lead to insight on how to make good-ole regular processors (without FPGAs) better (hardware design research).

Re:double rainbows

[Peeteriz]

I could see usage of this in portable consumer devices (phones, tablets, whatever is the next thing), offering the possibility for app-dependent 'ASIC' on otherwise low-computing-power devices - say, when the user is watching a video, put the stream decoding stuff on the FPGA, if there is music in the background, put the mp3/ogg/whatever decoding there so that the main processor is free for other apps, heck, if flash or html5 is too slow then probably some compute-intensive part of it can also be pushed to the FPGA in one way or another.

Re:double rainbows

[Bassman59]

Then what is their value proposition ? "1 chip is slightly cheaper" ? That wouldn't convince many people.

If people use this, it will be for the live reprogramming feature.

The main reason to glue an FPGA to a hard-core processor is that your application-specific logic can be right next to the processor, rather than in a separate device. The FPGA/Atom device, when installed in an OEM's product, will very likely NOT be user-programmable, as it's married to the underlying hardware (PCB and other external devices).

Re:double rainbows

[Macman408]

There *is* a programming model, there's just no *good* programming model. I'm very familiar with Verilog and VHDL, and use them in my job. That said, they're not languages that an average programmer can pick up and expect to get a good result - you have to learn how various constructs get converted to hardware, and how you are constrained by the hardware you are working with.

Similarly, I feel like OpenCL and the many parallel programming models suffer similar limitations (I've used Pthreads, OpenMP, MPI, Hadoop, TBB, Cilk, and others). There's a long way to go on research that will produce tools that can take the best advantage of modern hardware with the least required detailed knowledge about the target system.

For what it's worth, I did master's research involving including an FPGA (well, really coarsely-reconfigurable logic - so you get adders, multipliers, logic units, etc. that perform the same operations as in the CPU, but can rearrange the connections between them, eg string them together one way for one application, and a different way for another one) within a CPU as an integrated unit (alongside the integer, FP, and other units, as opposed to Intel's two-die approach). The idea would be to either have the OS detect some of the innermost loops of the program, or the application could specify them explicitly. Once it knows the innermost loop, it could convert the involved operations into a hardware configuration, and then the reconfigurable hardware could perform the operation more quickly than the CPU could alone. I think that's a better idea in that it doesn't have to require the programmer to know anything about how it works, though it also makes it more challenging to design the OS - but there are far fewer OS programmers than user-level programmers, so it'd be a net win.

As for your examples, I think that a raytracing accelerator would be better served by a much larger piece of hardware (an FPGA, GPU, or CPU) due to the compute requirements, plus higher bandwidth than PCIe x1. A custom CPU is doable, but it'd have to be extraordinarily simplified to fit in the fairly small FPGA (probably lacking 64-bitness, hyperthreading, out-of-order, superscalar, and all the other fun goodies that CPUs have now); a bigger CPU would need a bigger FPGA, likely quite a few FPGAs tied together. Making your own memory controller is doable, but since the CPU already has an integrated memory controller, I doubt you'd be able to get the CPU to use it - plus the limited bandwidth thing I mentioned. And ditto for your own cache; not to mention, FPGAs aren't typically known for their low latencies.

Most likely, they're going after the low-volume embedded market where it's not uncommon to have an FPGA or PLD to implement some glue logic and custom I/Os. One of my previous employers did just that; for example, implementing a Serial RapidIO link in an FPGA, and hooking it up to a CPU. Whether a x1 PCIe link is enough for the embedded market is questionable, though. But having the FPGA integrated on the die is a huge win for board area, which is often in high demand.

Re:double rainbows

[OeLeWaPpErKe]

The main reason to glue an FPGA to a hard-core processor is that your application-specific logic can be right next to the processor, rather than in a separate device.

That's not entirely accurate, in general closer together means better interlinks. In the xilinx and altera versions it means that they're so close that you can actually implement new processor opcodes in the fpga, implementing new operations, or controlling external peripherals in a single clock cycle.

If it's a simple device on a pci express 1x lane, what's left of this advantage ?

And then the big disadvantage of this solution enters the picture : inflexibility. A separate chip, is flexible. It can be replaced (hopefully *cough*) without affecting the rest. Your design outgrowing the chip ? Place a bigger one. With this solution, that won't work.

Re:double rainbows

[damien_kane]

Older ones (lower-cost/entry-level, not the X-25s) actually did have an issue during writes; in that it couldn't keep up the throughput (and as such the system would "stall", like it used to with floppy-disk access). This caused CPU usage to go through the roof while the system kept trying to get confirmation of the write.
Cache on the SSD and better controllers have pretty much alleviated that, though.

Re:double rainbows

[cnettel]

SSDs tend to show higher CPU overhead due to the insane amounts of throughput. If you would artificially introduce latencies equivalent to those of a HD, they will tend to be on par.

Re:double rainbows

[Dogtanian]

It means that intel has thrown an FPGA [wikipedia.org] into a normal CPU. FPGA's are highly programmable chips that are very fast in the thing they are programmed for. Changing the programming takes, by comparison, a lot of time and they usually can't do anything else than what they are programmed for.

I'm getting the impression that there may be some limitations on this FPGA, but the general concept of having a computer whose hardware itself can be reconfigured via a simple user-level program seems fascinating to me.

I came up with this idea myself a few years ago, and I think I mentioned it here. Not that I'm claiming credit for what is a fairly logical (well, bleeding obvious) extension of the FPGA concept when you think about it, and I'm sure that many others have come up with the same vague idea independently- but I'm surprised that going by the low level of discussion that even *more* people haven't thought about it.

Obviously, in raw terms the FPGA is going to be massively slower than a modern Intel/AMD x86 CPU (that is, if one was to pointlessly attempt to configure the FPGA into an x86 compatible CPU), but of course we're comparing the x86's fast execution of a program with the FPGA's equivalent functionality implemented in hardware.

And the interesting question is how hard and how fast would it be reconfigure, and could they get it to the stage where bog standard apps could speed themselves up by implementing algorithms as temporarily-dedicated hardware?

I'll admit I know bugger all about this, but it surprises me that there's not *more* discussion about it.

Re:double rainbows

[Tacvek]

Most FPGAs in the field are coupled with EEPROMs that are triggered by the FPGA's own startup sequence, and emit a bitstream that is basically exactly the same as the data that would be sent if programing via JTAG. The FPGA start-up logic just transfers this data directly onto the interior scan chain that holds the configuration.

The chips invariably support other options too, such as the already mentioned JTAG based programming, and sometimes more complicated schemes.

There also exist a few that have integrated the EEPROM into the same package as the FPGA (probably not on the same die, but it could potentially be.

Re:double rainbows

[Tacvek]

Many of us had thought about it, but it is very tricky to pull off. First standardizing the FPGA frabric is essential, or apps would need a different partial config bitstream for each CPU manufacturer. Further, standard FPGA frabric is not optimized for minimizing reconfiguration time.

In many setups, we are talking ten or hundreds of milliseconds. Not bad for starting an application, but unless apps claim exclusive us of the FPGA, then to quote Andy Dodd's post above: "context switching would be a real bitch".

Further, to get maximum possible performance likely requires exposing parts of the CPU to the fabric. A malicious application could potentially permanently damage the processor unless special step are taken. For example, the outputs of the CPU would need to be connected to FPGA pads that cannot be configured to be output pads, or a program could effectively short VDD and GND, literally causing the chip to fry itself.

Further, if great care is not taken, the FPGA configuration could deliberately time its outputs to change as the CPU clock ticks, attempting to introduce metastability to the processor. The processors are designed to be resistant to inputs randomly causing metastability of an input latch, but continuous deliberate attempts to introduce metastability are not usually factored into CPU design.

Re:double rainbows

[Neil Boekend]

I'd imagine they would start optimising the reprogrammability, if this sells well.
Nonetheless: Multitasking the FPGA in the traditional sense woule be a real bitch. They will never get it to speeds like 0.1s. More like 5s.
However: an FPGA can be programmed with multiple programs in parallel, as long as all the code can fit into it, so 2 or 3 small programs in an FPGA would not be a problem. This is not multitasking in the way the OS does it now on a single core; the programs truly run in parallel. The total amount of program complexibility would be limited, while the current CPU's can handle a nearly infinite amount of tasks (while this is unpractical).
The OS would have to determine whether a new program requesting FPGA space actually fits in the available space, but with some programming this can be done. If a program cannot use FPGA space there are some options, but my choice for the default would be to let the program run on the code created for CPU's without an FPGA, since you would need that code anyways. An OS setting could cause a conflict to invoke an error message instead, or even a list with FPGA using programs, allowing the user to kill a program that uses FPGA space in order to start another program.

Re:double rainbows

[Dogtanian]

In many setups, we are talking ten or hundreds of milliseconds. Not bad for starting an application, but unless apps claim exclusive us of the FPGA, then to quote Andy Dodd's post above: "context switching would be a real bitch".

Ha ha, yeah, oddly enough the multitasking and context-switching issues *had* occurred to me; I'm actually surprised that it would be that fast, to be honest!

Probably you'd require multiple FPGAs (possibly having a few simple ones instead of one complex one; not sure how much complexity would be required to get the best performance anyway, or whether the FPGA would be better suited to optimising particular taskt that could be done in a small amount of silicon).

Further, to get maximum possible performance likely requires exposing parts of the CPU to the fabric. A malicious application could potentially permanently damage the processor unless special step are taken.

OTOH *that* one hadn't occurred to me; if we were effectively wanting to do hardware versions of software I'm guessing it might be possible to include some restrictions. But at the same time that would probably cut out a massive swathe of potential. And as you suggest, it would be hard to design it so that a malicious app couldn't do damage somehow.

Interesting idea though- I'm sure that we will see it come to full mainstream fruition one day.

Re:double rainbows

[Tacvek]

In many setups, we are talking ten or hundreds of milliseconds. Not bad for starting an application, but unless apps claim exclusive us of the FPGA, then to quote Andy Dodd's post above: "context switching would be a real bitch".

Ha ha, yeah, oddly enough the multitasking and context-switching issues *had* occurred to me; I'm actually surprised that it would be that fast, to be honest!

Partial/Full reconfiguration speeds are very dependent on the FPGA architecture, but one designed for say column-wise partial configuration shouldn't have too much trouble reconfiguring a column in 200 to 300 ms. Once you have gone that far, it is not too much harder to allow reconfiguring multiple columns in parallel, and you would then end up with times like those I mentioned. One should be able to improve that speed significantly with various tricks. Many of those tricks are at the expense of a bit of die area, but that may well be a necessary trade-off for reconfigurable processors.

Re:double rainbows

[badkarmadayaccount]

Transmeta were ahead of their time. Were they here, they would have eaten the Atom's lunch.

Achronix FPGA's fabbed by Intel

[allanw]

In related news, and also very interesting: http://www.eetimes.com/electronics-news/4210263/Intel-to-fab-FPGAs-for-startup-Achronix

more jobs for me

[fpgaprogrammer]

yay!

Re:more jobs for me

[rrohbeck]

I thought you don't need a programmer for FPGAs ;)

Re:more jobs for me

[SuricouRaven]

You need an EE master. FPGA programming is *hard*.

Re:more jobs for me

[fpgaprogrammer]

i am an ee monster!

Re:more jobs for me

[mrand]

FPGA programming (or rather desiging for an FPGA, implementing algorithms) is not so much about EE as it is about CS.

Wrong. It has little to do with CS - and in fact, if you approach it that way, you'll make code that the synthesis tools can't handle efficiently. You'll end up with many levels of logic and won't meet your timing requirements. FPGA "programming" is about describing digital circuits in an HDL.

      Marc

Re:more jobs for me

[c 0xFF]

The AC doesn't know what he's talking about, but digital circuit design has gradually incorporated more and more CS concepts and methodology. HDLs are becoming more high-level, for example, so that an engineer can describe what needs to happen and when, leaving the details on how up to the synthesizer.

There's a reason that universities are offering Computer Engineering degrees, bringing together Computer Science and Electrical Engineering. The AC is right: Ohm's Law doesn't really apply (that's not to say a digital circuit designer shouldn't know it inside and out) when working with FPGAs, but nor do most sorting algorithms taught in CS classes.

FPGA users already don't care

[r00t]

If you care about power, you make an ASIC. An FPGA is all about being cheap and getting to market. FPGAs burn power and don't even clock fast.

Re:FPGA users already don't care

[AuMatar]

FPGAs aren't all that cheap either. They're about rapid development, and are cheaper than an ASIC for small to medium lots. Large scale ASICs win out on cost per unit being really low.

Re:FPGA users already don't care

[sznupi]

It might very well burn a lot less than the same thing done in software.

Re:FPGA users already don't care

[91degrees]

Surely if you're doing something simple and very parallelisable though, it's useful.

Re:FPGA users already don't care

[leuk_he]

THis might be the weak point. Suppliers cannot change to a ASIC in a later phase, unless intel licenses the atom cpu. (right....). The biggest advantage of atom is de x86 development tools and applications (windows). The Quick to Market is a big win there. However to optimize power/price in a later phase is not possible.

Re:FPGA users already don't care

[fpgaprogrammer]

There are very cheap FPGAs too! Actel igloo nano are even under $1. These are often used as glue logic or nano-controllers like to connect a USB port to an ADC and DAC. In many cases, low cost ($1-20) FPGAs are use instead of microcontrollers and often FPGAs are even being programmed with microprocessor cores like the Nios(altera) or Microblaze (xilinx) or even soft ARM cores. You can run Linux on them!

Re:FPGA users already don't care

[deKernel]

Not all that correct. Typically FPGAs are used when either production quantities are to low to justify the expense of creating ASICs, OR if you want to reprogram your self on the fly.

Re:FPGA users already don't care

[mounthood]

And the design process is worse: If you design for Atom+FPGA and then want to move to an ASIC you have a bunch of work to do. If you start with a separate FPGA, just drop an ASIC in place.

Will it be used to for hardware enforced DRM?

[Ivan Stepaniuk]

I just hope not, OEMs could easily avoid you to reprogram the FPGA.

0,1, or 2 PowerPC cores

[Jan]

Virtex-II Pro, Virtex-4, and Virtex-5 offered devices with 0, 1, or 2 PowerPC cores. Xilinx once showed die floorplans of Virtex-II Pros with 4 PowerPC cores but if I recall correctly they never shipped such devices.

Actual information

[Mysteray]

http://edc.intel.com/Link.aspx?id=3961

350 user I/O pins. I think that could control a few Christmas lights. Or make a nifty message-passing bus for a parallel computer.

Wonder if anyone will make inexpensive boards with breakout IO?

Re:Actual information

[allanw]

Only PCI-E 1x interconnect between the CPU and FPGA? Kinda disappointing.

Re:Actual information

[allanw]

Since FPGA's are good at processing massively parallel data, high bandwidth is necessary to do any work. I suppose CPU to FPGA bandwidth isn't important if they can both access RAM.

Re:Actual information

[squizzar]

Video resizing/deinterlacing. 1 PCIE lane is 2.5GBps, uncompressed 1080P60 at 10 bit RGB is 3.7GBps.

Re:Actual information

[dgatwood]

350 user I/O pins. I think that could control a few Christmas lights. Or make a nifty message-passing bus for a parallel computer.

Yes! Finally enough I/O pins to make my velocity-sensitive pipe organ idea viable....

Re:Actual information

[Doc Ruby]

Actually I'm excited about the possibility of inserting a chip like this into my Hammond M-100A organ, then running Linux apps on it that control all its keys and switches. If I could embed just the tone generator electromechanics and chip in a cabinet, with effects loops and MIDI, I could have all the various hardhack Hammond mods available, and new ones, in a small cabinet. I could even have room for several Hammonds at once, making chorus/phaser/vibrato and really complex combos. Keyed either from software or from a better manual than the ones on the $200 Hammonds I buy. Who knows - maybe controlling a Leslie with multi speeds, dynamic crossover, etc is in the cards. I'm a software developer, so rather than learning lots of AC electronics hacks I could just experiment on one of these little brains.

Re:Actual information

[dgatwood]

Well, my insane idea involves ripping out the actual keyboard from a pipe organ, replacing it with a MIDI keyboard of the same size, and using it to drive a computer that translates the MIDI signals into commands for a series of controllers (one per rank). Because each keypress would send key velocity information, the harder you play, the louder the sound would be (like a piano). This could, of course, be enabled or disabled at will, since it's all done in software.

Each controller would consist of a controller like this with the output pins driving a bunch of crude DACs, one per key. Those per-key outputs would then drive some sort of variable flow gate valves to controlling the volume of each pipe individually. In addition, each stop knob would have a variable resistor instead of a switch, so you can control the relative volumes of the different stops independently. Those volume commands would drive an additional digital output on a particular rank's controller board, which would drive another DAC that in turn would drive a VCA on the output of all of the per-key outputs. Alternatively, this could be simplified by scaling in the digital domain, but with only five bits of precision per key, I'd hesitate to do that; MIDI provides seven bits of precision per key, and I'm assuming there's a reason for this.

The bottom line is that to do what I want, I'd need one breakout board with a chip like this per rank, but that's still better than having to put piles of external glue logic (a truckload of demuxes and data latches) just to cover a single rank like I would with most of the FPGA developer boards I've seen. Of course, depending on the cost, I still might have to use a pile of glue logic to get multiple ranks per board, but....

Oh, and if I can't find variable flow valves that respond quickly and accurately enough and are small enough, I could always do the DAC in the air pressure domain---five pipes of progressively smaller size, controlled individually with traditional on-off valves. Of course, that many electropneumatic valves would cost a small fortune, but....

Re:Actual information

[Mysteray]

Then I suppose if you want to handle raw, uncompressed 1080p60 I guess you'll need something with more bandwidth than this particular Atom.

Here's a thought: I wonder if you could route that other external PCIe back into the FPGA for more bandwidth?

Re:Actual information

[badkarmadayaccount]

Why don't you do it in SW on the GPU and wire an amp?

Only certain Virtex-2Pro/4/5s have PowerPC cores

[Jan]

Many Virtex-II Pro, Virtex-4, and Virtex-5 don't have PowerPC cores. No Virtex-6 or later device does.

In particular...

[Jan]

Altera used to have FPGAs with an embedded ARM core + support "stripe" (Excalibur, early 2000s) -- e.g. Altera Excalibur EPXA10.

Of course Xilinx has announced a family of 7 series FPGAs with ARM Cortex-A9MPCore cores. http://www.xilinx.com/technology/roadmap/processing-platform.htm

Both Xilinx and Altera also have in-house soft-processor cores and infrastructure, and ecosystems of third-party soft processor cores.

Re:In particular...

[Bassman59]

Additionally, on both Altera and Xilinx, you can implement a Cortex-M0 core right in the FPGA logic.

Actel supports Cortex-M1, too.

Re:In particular...

[jrobot]

The Virtex 7's with dual A9MPs are going to be awesome parts.
They supposedly will function independently of the bitstream configuration,
which suggests increasing possibilities for partial reconfiguration.

Xilinx's software team needs to get their act together.
SystemVerilog for synthesis, extended IDE w/ tcl support are long overdue.[/rant]

Very cool and very kludgy

[rrohbeck]

The right way to do this license the Altera IP and integrate it closely with the CPU. Then the CPU could use it in normal operation, for floating point for example. You have various programs and every time you try to access one that's not in the FPGA an interrupt is generated.
Almost like in the good old days of WCS.

Reading the Intel E6x5C Platform Brief...

[Jan]

Before you all speculate widely, try reviewing the actual product brief. http://download.intel.com/embedded/processors/prodbrief/324535.pdf . In which you will see this is an MCM with an Atom E6xx SoC die and an Altera FPGA die, interconnected by 1-2 PCIe x1 links. It has an amazing 1466 ball grid array package.

It's not clear to me what this level of packaging and integration achieves compared to mounting a (not integrated) E6xx BGA and a separate Altera or Xilinx FPGA BGA onto the main PCB, interconnected by PCIe x1 or perhaps even x4. Then you would get a broader choice of FPGAs -- and perhaps a simpler PCB escape for the two packages compared to one 1466 ball beast.

The advantages of this MCM as stated in the brief include:
* reduced board footprint
* lower component count
* simplified inventory control / manufacturing
* single-vendor support

True, but forgive me if I'm not over the moon. The dream of integrated FPGA fabric into a heterogeneous SoC (same die) includes a very low latency and possibly cache coherent interconect between the processor(s) and the FPGA. But here the FPGA is on the other side of a narrow PCIe link. It can't share the Atom SoC's memory hierarchy / DRAM channels very effectively. It is probably a very long latency round trip from x86 software control / registers and L1$ data, to some registers or function units in the FPGA, and back to the x86. So I think of this as more of a super-flexible Atom SoC platform than a dream reconfigurable computing platform.

It's a nice step but I look forward to so much more.

http://www.fpgacpu.org/usenet/fpgas_as_pc_coprocessors.html (1996): "... So as long as FPGAs are attached on relatively glacially slow I/O buses
-- including 32-bit 33 MHz PCI -- it seems unlikely they will be of much use in general purpose PC processor acceleration. ..."

Re:Reading the Intel E6x5C Platform Brief...

[Vectormatic]

i dont know, FPGAs are wonderfull for DSP/codec functions. This could give intel a way to really speed up HD playback on their platform without having to finally build a decent graphics chip (like nvidia has done with ion, or amd with their IGPs), but those applications benefit from high data throughput.

Unless this FPGA is somewhat undersized or has a decent chunk of ram directly attached to its own pins, it will be severely choked by the pci-e 1x interface

Re:Reading the Intel E6x5C Platform Brief...

[wisty]

Using the FPGA as a replacement for a decent GPU would be crazier than Larrabee. Which isn't to say they won't try it ;)

Re:Reading the Intel E6x5C Platform Brief...

[Lennie]

I was immediately thinking if that would mean someone could make a cheaper NetFPGA/LibreRouter (line rate forwarding open source router platform using FPGA instead of ASICs which the normal routers from Cisco, Juniper, etc. use for hardware-routing/switching).

It is mostly used for academic purposes, but if the FPGA does not have direct access to RAM and can not do direct I/O it's probably not useful.

Re:Reading the Intel E6x5C Platform Brief...

[Doc Ruby]

Xilinx EPP puts an ARM Cortex A-9 in the die with a large Xilinx FPGA. Is that the dream of integrated FPGA fabric come true?

Re:Reading the Intel E6x5C Platform Brief...

[mako1138]

And it's only 60K logic elements, making it clear that this device is not intended for number crunching.

Programming software?

[galvitron]

I am hoping that the software needed to program the FPGA portion of the chip is available and that the FPGA itself is programmable by the end user. This would be a big leap in the kinds of projects that can be attempted by homebrew dudes and the like.

It's been done, it's being done.

[Jan]

Done: Altera Excalibur EPXA10
In progress: http://www.xilinx.com/technology/roadmap/processing-platform.htm

Re:Put an ARM in the FPGA

[Arlet]

The advantage of the ARM business model is that you don't have to. Anybody can get a license from ARM to put a core in an ASIC. This means that is very easy to build an integrated system on a chip around a CPU and any kind of peripherals you want.

This is Intel's attempt to capture some of that market. But because they don't want to license their core, their trying to tie it to an FPGA. I have doubts whether this will be attractive. FPGAs are slow, use more power, and are more expensive compared to ASICs. For high-volume products they can't compete on price, and for high-performance products they can't compete on speed.

Re:My Story

[somersault]

Well, at least she didn't try to make you listen to her.

FPGA-based robot controllers

[G3ckoG33k]

Articles (found freely on Google) like "Evolving FPGA-based robot controllers using an evolutionary algorithm." by Renato A. Krohling, Yuchao Zhou, and Andy M. Tyrrell is a dream!!!

Genetic algorithms and FPGA is way cool!

Re:Put an ARM in the FPGA

[Arlet]

I highly doubt Intel is interested in competing in the low-volume, low-performance markets.

Cloud FPGAs

[davidjgraph]

As has been pointed out, the FPGA isn't tightly coupled architecturally-wise enough to provide a performance gain in tightly coupled software. This solution, like any board with an FPGA, works best when the task allocated to it is relatively stand-alone (some intensive DSP, etc). Now what would be interesting in this field is cloud providers making FPGAs available as part of their packages, or even using them themselves. So many web applications grind the server for image processing, that would be well suited to an FPGA. Maybe Google should consider it for GAE, for example?

Re:Only certain Virtex-2Pro/4/5s have PowerPC core

[squizzar]

Shush AC, there there, don't let the scary electronics frighten you...

Re:Put an ARM in the FPGA

[mr_mischief]

They aren't. That's why they have this CPU+FPGA product that they'll sell in large volume to a large number of companies that do low volume work. That's what the FPGA is for: letting lots of low-volume products be built from one high-volume product.

It's Complicated

[MacGyver2210]

I love programming and wiring up some microcontrollers as much as the next geek, but at what point does a chip become too complex for realistic home use?

I don't need hundreds of GPIO pins, and I don't even think I can solder detailed enough or design home-made PCB with enough detail to accommodate a processor with this many pins and features.

I am pretty happy to see FPGAs making it into commercial projects - they're just so useful.

"You want your processor to use this specific logic pipeline? There's a chip for that!"

Re:It's Complicated

[Doc Ruby]

This part will be sold in PCs with large parallel connectors for interfacing multiple or complex devices to the FPGA pins, along with the rest of the HW that supports a smart embedded device. You won't be soldering directly to the part.

But it's not really designed for "home use", except for embedded home automation developed by serious engineers. Which could be a DIY, but mostly won't be.

Re:Put an ARM in the FPGA

[thegarbz]

But for a medium sized company with no expertise on ASIC design it provides an option which previously didn't exist. Any recent EE grad would likely have done some FPGA programming in university. On the flip side ASIC design is quite specialised.

Hardly a unique product, apart from x86

[hattig]

There are loads of FPGAs on the market with integrated PowerPC cores. There are probably FPGAs on the market with integrated ARM cores (ah yes, a post already links to one such creation). This is a dual-die package with a 60k gate FPGA. It's a nice option on the market, but it's hardly unique. The cost will be a major issue as well, although so far the prices look reasonable. But you can't put much into 60,000 gates (although maybe they're counted different from Xilinx or Spartan gates), certainly not a Minimig AGA core.

So enjoy your 600MHz Atom + FPGA. Or 1GHz. Or 1.3GHz. WIth enough FPGA to implement a C64. Yeah, I know that in industry it will be used for different purposes, but will that industry care about x86 compatibility ... or continue using the existing PowerPC and ARM options?

Re:Hardly a unique product, apart from x86

[Doc Ruby]

I've got an industrial control project that's been designed so far around an embedded Atom PC and a custom PCB for sensor/actuators. We might be able to port the custom PCB to this FPGA, leaving only voltage transformers/transistors/relays outboard. Which could save us a lot of money in production, and even more in maintenance/upgrades. There are existing PPC and ARM devices, but our existing SW is for x86. Which is why an Atom/FPGA part could be a great savings for us. And of course ours is a very typical situation.

Though the ARM/FPGA parts are competitive, since our code is userspace, and can be easily recompiled for ARM Linux instead of x86 - if the parts are otherwise competitive. This competition will make our choices even better alternatives than they are now.

SSL offloading

[DrSkwid]

If it's fast enough you could use it as an SSL front end to non-SSL web servers.

Viruses?

[CrazyBusError]

Great. Now when you get a virus, it'll be able to reprogram your *hardware*. I'm sure that couldn't go horribly wrong at all...

Eclipse Tools?

[Doc Ruby]

Can I run Linux and Eclipse on one of these new CPUs locally, and use a good Eclipse module to port Linux kernel functions (like IO logic) from iterated procedures to the FPGA, then test them? Which Eclipse modules would support that development?

Xilinx / ARM Cortex A-9

[Doc Ruby]

Xilinx this year introduced a whole new architecture embedding an ARM Cortex A-9 in a large FPGA, designed to run primarily as the CPU, including FPGA functions as the developer specifies through software.

Re:Xilinx / ARM Cortex A-9

[Tacvek]

Interesting. Does it also supporting using the logic for system on a chip features, like implementing the memory controller? (Obviously in addition to the main draw of reconfigurable accelerators and co-processors.)

I ask because most of Xilinx's past offerings with hard CPU cores were aimed mostly at creating an System on a chip, while still potentially supporting reconfigurable accelerators if you could pull it off (partial reconfiguration is rather tricky[1]).

[1] Of course using partial reconfiguration as a way of live patching a system with negligible downtime can be even trickier than using it for replaceable accelerators that are inactive while reconfiguring, but people have still pulled off the former feat.

Re:Xilinx / ARM Cortex A-9

[Doc Ruby]

It looks like the FPGA is connected to the ARM by an AXI bus, which I don't think allows FPGA directly connected to memory. The FPGA is more of a peripheral to the (dual core) ARM, though perhaps the FPGA pins off the chip can connect to RAM to which the FPGA can act as a controller. Take a look at the architecture points at the link I provided to Xilinx.

Re:Xilinx / ARM Cortex A-9

[Tacvek]

Interesting.

Reading between the lines a bit, the main goal of the fabric is to instanctiate a set of accelerators useful to your application. Stock acellerators are provided. Alternatively custom acellerators could be written. Certain other peripherals, such as say a PS/2 controller, or USB controller, or Gigabit Ethernet MAC could also be instantiated, but some of the most likely desired ones will exist as hard logic.

Not a bad way to support basic SOC system, especially since the emphasis on the programmable logic is on the accelerators. The system would not be as configurable as the old Vertex offerings, but one can get better specs (speed, power dissipation, etc) on peripherals that nearly every design will use by having them be hard logic.

With a bit of work, one could probably split the fabric up into several distinct "slots", using floor-planning to constrict place and route, and instantiate each stock accelerator in each slot, generating partial reconfiguration bit streams, for each slot/accelerator combination. Then the application code could literally just pick a set of desired accelerators, and instantiate them. A latter portion of the application could come along later, and swap some out for others that would be useful, etc.

That really cannot be easily done with the peripherals though, since they would be using the external pins, and there is no easy way to make the PCB traces configurable at run time.

Re:Only certain Virtex-2Pro/4/5s have PowerPC core

[Andy Dodd]

The largest I have seen has two PowerPC 440 cores. That would be the Virtex-5 FX130T and FX200T (Only different in the number of logic gates available).

None of the current V6s do, but I keep hearing about Xilinx going to ARM. It is in one of their roadmap documents but no real info on exactly where in the roadmap it is.

Unlike Intel's solution, the Xilinx units have everything on a single silicon die.

Re:Only certain Virtex-2Pro/4/5s have PowerPC core

[Doc Ruby]

Xilinx Extensible Processing Platform parts are supposedly manufactured, and planned for sale in early 2011. I've been hearing about their progress for over a year from a friend who's a top Xilinx engineer.

Good example

[SuperKendall]

It would let viruses create some custom FPGA code that would be able to crack any encrypted files you had in mere seconds, instead of hours.

Re:Good example

[IICV]

You don't need custom FPGA code for that.

Here's how it goes:

1. Virus waits for the user to enter in a password, any password.
2. Virus tries password on encrypted files.

Repeat until decryption is achieved.

No amount of encryption will save you from an untrustworthy program running on your machine.

Re:Good example

[SuperKendall]

But with an FPGA, why even wait? Just get busy cracking! It's the next wave I tell you!

Re:Good example

[__aatirs3925]

Thanks everyone for replying to my question, and to whoever found my question funny, I find that offensive you insensitive clod! I learned a lot today though :)

Re:Good example

[Neil Boekend]

It would let viruses create some custom FPGA code that would be able to crack any encrypted files you had in mere seconds, instead of hours.

Err, this is a small FPGA. If these could crack encrypted files within seconds the NSA would have the high power (more than 10 times as many gates) versions in great arrays and brute force crack 256 bit AES within hours. Nowadays the time required is longer than the expected lifetime of the sun (the life expectancy of the sun is 5.000.000.000 years.)

FFT engine

[LynnwoodRooster]

Please please PLEASE leave this open for hobbyists to download their own FPGA code. I could REALLY use a dedicated FFT or DSP for math crunching!

Re:Only certain Virtex-2Pro/4/5s have PowerPC core

[Bassman59]

The largest I have seen has two PowerPC 440 cores. That would be the Virtex-5 FX130T and FX200T (Only different in the number of logic gates available).

None of the current V6s do, but I keep hearing about Xilinx going to ARM. It is in one of their roadmap documents but no real info on exactly where in the roadmap it is.

Unlike Intel's solution, the Xilinx units have everything on a single silicon die.

And my God, the tools SUCK.

RTFA - $61-106 - Real issue is using the FPGA

[billstewart]

Whether that's relatively reasonable depends a lot on what you're trying to do. For a netbook, probably not realistic. For a specialized machine where the FPGA enables something hard to do in a vanilla CPU, maybe. Maybe you can use the FPGA to do graphics processing more cost-effectively than a separate nVidia chip, or do good enough graphics while keeping the power consumption down, or do fancy geometry crunching for a game machine. Who knows?

Re:Only certain Virtex-2Pro/4/5s have PowerPC core

[Tacvek]

They do suck, but you get used to the ways they suck after a while. For example, I found it hard to move to a different synthesis tool from XST, because the other ones lacked some nice little convenience features of XST, despite the better RTL-level synthesis of the alternative tools.

I'm sure I'd be driven batty if I ever tried to use an Altera FPGA, simply because some of the features I'm used to will not be there, even though the features are emphatically non-essential.
My mental model of an FPGA is also based heavily on the Virtex and Spartan designs, and it would take some work to adjust them.

Re:So what does this mean? in plain geek please

[Tacvek]

Neither. FPGAs don't work by opcodes, or anything remotely similar.

While it is possible to have a CPU design where additional CPU Opcodes can be added by the FPGA, and they would work just like any other opcode[1], but this is not such a design. The design here is a standard Atom CPU, connected to the FPGA by a a 1x PCIE bus. The FPGA could be configured to act like any possible PCIE component, with internal digital logic, and using the GPIO pins to interface with something else you (the PCB designer) put on the motherboard.

Footnote:
[1] Practical implementations of such a system may have the new opcodes take more cycles than a native opcode, as the CPU's clock speed may be to great for the FPGA, but you may well be able to have the new opcode take 10 clock cycles, or so, to perform some function that would normally take 100 operations or more.

What would be possible in such a system would very much be dependent on the design of the platform. A platform that exposes only the ALU stage of the pipeline would only work particularly well for new esoteric arithmetic operations, but one could still put registers in there allowing for more complex sets of additional instructions. However if hooks into more of the CPU are exposed, then the new opcodes could potentially be more efficent, or add interesting features like virtualization extensions, and so on.

FPGA?

[tunghoy]

I thought the FPGA was an organization of cats who play golf.