Slashdot Mirror


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."

188 comments

  1. Awesome by phantomcircuit · · Score: 4, Informative

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

    1. Re:Awesome by badran · · Score: 1

      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.

    2. Re:Awesome by arivanov · · Score: 5, Interesting

      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".

      --
      Baker's Law: Misery no longer loves company. Nowadays it insists on it
      http://www.sigsegv.cx/
    3. Re:Awesome by Elbereth · · Score: 5, Interesting

      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.

    4. Re:Awesome by Man+On+Pink+Corner · · Score: 4, Funny

      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.

    5. Re:Awesome by TheThiefMaster · · Score: 2, Interesting

      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.

    6. Re:Awesome by teachknowlegy · · Score: 1

      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.

    7. Re:Awesome by PopeRatzo · · Score: 1

      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.

      --
      You are welcome on my lawn.
    8. Re:Awesome by DrSkwid · · Score: 1

      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.

      --
      There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
    9. Re:Awesome by izomiac · · Score: 1

      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."

    10. Re:Awesome by Anonymous Coward · · Score: 0

      Do some research, troll. Apple designs their own motherboards, they're not standard models and you can't buy them from anyone but Apple. Just because they now use x86 doesn't mean they use the same parts as Dell!

    11. Re:Awesome by samkass · · Score: 1

      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.

      --
      E pluribus unum
    12. Re:Awesome by Anonymous Coward · · Score: 0

      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.

      You do know there are single socket Opterons and Xeons with no MP support as well?

    13. Re:Awesome by Anonymous Coward · · Score: 0

      I'd like to see the mackintosh wearing, renegadingly Jobsian, former army member guards patrolling along outer perimeter of the reality distortion field surrounding the tantalum mine at the Congolese heat, threatening the workers to do their jobs or the guards will slip themselves into black turtlenecks as well.

    14. Re:Awesome by CAIMLAS · · Score: 1

      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.

      --
      ~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
    15. Re:Awesome by maxume · · Score: 1

      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).

      --
      Nerd rage is the funniest rage.
    16. Re:Awesome by BitZtream · · Score: 1

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

      --
      Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
    17. Re:Awesome by teachknowlegy · · Score: 1

      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.

    18. Re:Awesome by Anonymous Coward · · Score: 0

      You bet it is! I want my FPGA app store!

    19. Re:Awesome by wazzap123 · · Score: 1

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

    20. Re:Awesome by Whiteox · · Score: 1

      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 be apathetic. Procrastinate!
    21. Re:Awesome by shnull · · Score: 0

      i see, somewhat like blu-ray is a new invention and dvd's couldnt hold an actual 16+gb from the start?

      --
      beware he who denies you access to information for in his mind, he already deems himself to be your master (SMAC-ish)
  2. 2nd post by Anonymous Coward · · Score: 0

    If only I'd had a FPGA! (

  3. Don't know if this is a first by smoot123 · · Score: 1

    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.

    1. Re:Don't know if this is a first by Anonymous Coward · · Score: 1, Interesting

      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.

    2. Re:Don't know if this is a first by commlinx · · Score: 1

      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

    3. Re:Don't know if this is a first by the_other_chewey · · Score: 2, Insightful

      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.

    4. Re:Don't know if this is a first by Pikoro · · Score: 1

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

      --
      "Freedom in the USA is not the ability to do what you want. It is the ability to stop others from doing what THEY want"
    5. Re:Don't know if this is a first by Anonymous Coward · · Score: 0

      Both Xilinx and Altera have marketed FPGA:s with hard CPU cores. It was to my knowledge a complete and utter market failure. Maybe they were too expensive or not available enough compared to a standard FPGA + a separate CPU. Availability is one of the most important, if not the most important, factors when you select parts for a design. Maybe the hard cores didn't offer enough performance for the money compared to soft cores and discrete CPU:s. A lot of simple applications run fine on soft cores and there are loads of people who know how to connect an FPGA to an external CPU, so it's not like the market is screaming for these parts.

      If Intel markets high performance and low power Atom cores integrated on high performance and low power FPGA:s at reasonable prices and with good availability, then we could see a different outcome.

    6. Re:Don't know if this is a first by Doc+Ruby · · Score: 1

      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.

      --

      --
      make install -not war

  4. ..... Really? by del_diablo · · Score: 1

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

  5. double rainbows by __aatirs3925 · · Score: 3, Funny

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

    1. Re:double rainbows by Anonymous Coward · · Score: 0

      its a Field-programmable gate array (http://en.wikipedia.org/wiki/Field-programmable_gate_array), they added a 'programmable logic', let's say some kind of programmable chip, wich the manufacturer can program (hopefully users as well anytime soon :D) so it can encode/decode vidéo on the fly or encrypt/decrypt stuff in (almost) real-time (for example) and being much more efficient than the atom itself, so you end up having more battery.....

    2. Re:double rainbows by Neil+Boekend · · Score: 5, Informative

      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.

      --
      Well, I might have a way, but it only works on a semi spherical planet in a vacuum.
    3. Re:double rainbows by Kjella · · Score: 2, Insightful

      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.

      --
      Live today, because you never know what tomorrow brings
    4. Re:double rainbows by Anonymous Coward · · Score: 2, Interesting

      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!

    5. Re:double rainbows by Anonymous Coward · · Score: 0

      Wasn't that the selling point for the old Transmeta CPUs?

    6. Re:double rainbows by ThermalRunaway · · Score: 3, Informative

      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

    7. Re:double rainbows by ILuvRamen · · Score: 0

      The Win 7 hardware benchmark rating of 2.1 on the dual core version says no. If I had a pentium 3 machine at the moment, I'd totally benchmark it just to see who'd win. They can put an atom in my cell phone or something but keep them out of my real computers!

      --
      Google's Super Secret Search Algorithm: SELECT @search_results FROM internet WHERE @search_results = 'good'
    8. Re:double rainbows by Arlet · · Score: 1

      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.

    9. Re:double rainbows by ThermalRunaway · · Score: 2, Insightful

      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.

    10. Re:double rainbows by Darinbob · · Score: 1

      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.

    11. Re:double rainbows by sznupi · · Score: 1
      --
      One that hath name thou can not otter
    12. Re:double rainbows by wvmarle · · Score: 1

      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.

    13. Re:double rainbows by SuricouRaven · · Score: 1

      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.

    14. Re:double rainbows by Macman408 · · Score: 2, Insightful

      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.

    15. Re:double rainbows by Anonymous Coward · · Score: 0

      via/Cyrix used/uses? fpga in thier low-power high-efficiency cpu's
      I think it was setup so that it kept track of what kinds of operations the cpu was performing most often, and then it would sub out as many multi-clock operations to a bit of temporary logic in the fpga as it could manage, attempting to turn them into single-clock or at least 'fewer-clock' operations in hopes of speeding the whole thing up.

    16. Re:double rainbows by Bozzio · · Score: 1

      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 :)

      --
      I just pooped your party.
    17. Re:double rainbows by Vectormatic · · Score: 1

      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...

      --
      People, what a bunch of bastards
    18. Re:double rainbows by Morty · · Score: 2, Informative

      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.

    19. Re:double rainbows by wisty · · Score: 1

      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.

    20. Re:double rainbows by marcello_dl · · Score: 1

      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.

      --
      ---- MISSING MISCELLANEOUS DATA SEGMENT --- [sigdash] trolololol
    21. Re:double rainbows by jittles · · Score: 1

      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.

    22. Re:double rainbows by icebraining · · Score: 1

      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.

    23. Re:double rainbows by icebraining · · Score: 1

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

    24. Re:double rainbows by allaunjsilverfox2 · · Score: 2, Funny

      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?

      --
      Restore the madness of youth's lechery
    25. Re:double rainbows by wvmarle · · Score: 1

      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.

    26. Re:double rainbows by mr_mischief · · Score: 1

      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.

    27. Re:double rainbows by RevWaldo · · Score: 1

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

      .

    28. Re:double rainbows by DrSkwid · · Score: 2, Informative

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

      And it turned out to not be a selling point.

      --
      There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
    29. Re:double rainbows by Anonymous Coward · · Score: 0

      I take it you haven't used an Intel GPU.

    30. Re:double rainbows by OeLeWaPpErKe · · Score: 1

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

    31. Re:double rainbows by OeLeWaPpErKe · · Score: 1

      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.

    32. Re:double rainbows by Anonymous Coward · · Score: 0

      double rainbows

      Shit happens...

    33. Re:double rainbows by Andy+Dodd · · Score: 1

      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).

      --
      retrorocket.o not found, launch anyway?
    34. Re:double rainbows by the+eric+conspiracy · · Score: 1

      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.

    35. Re:double rainbows by mrand · · Score: 1

      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

      --
      -- PGP keyID: 0x4C95994D
    36. Re:double rainbows by damien_kane · · Score: 1

      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.

    37. Re:double rainbows by LUH+3418 · · Score: 1

      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.

    38. Re:double rainbows by tlhIngan · · Score: 1

      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.

    39. Re:double rainbows by stoanhart · · Score: 1

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

    40. Re:double rainbows by LUH+3418 · · Score: 1

      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).

    41. Re:double rainbows by Peeteriz · · Score: 1

      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.

    42. Re:double rainbows by Bassman59 · · Score: 1

      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).

    43. Re:double rainbows by Macman408 · · Score: 1

      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.

    44. Re:double rainbows by OeLeWaPpErKe · · Score: 1

      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.

    45. Re:double rainbows by damien_kane · · Score: 1

      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.

    46. Re:double rainbows by cnettel · · Score: 1

      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.

    47. Re:double rainbows by Dogtanian · · Score: 1

      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.

      --
      "Slashdot - News and Chat Sites Deviant". (Click "homepage" link above for details).
    48. Re:double rainbows by Tacvek · · Score: 1

      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.

      --
      Stylish sheet to fix many problems in Slashdot's D3: https://gist.github.com/801524
    49. Re:double rainbows by Tacvek · · Score: 1

      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.

      --
      Stylish sheet to fix many problems in Slashdot's D3: https://gist.github.com/801524
    50. Re:double rainbows by Neil+Boekend · · Score: 1

      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.

      --
      Well, I might have a way, but it only works on a semi spherical planet in a vacuum.
    51. Re:double rainbows by Dogtanian · · Score: 1

      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.

      --
      "Slashdot - News and Chat Sites Deviant". (Click "homepage" link above for details).
    52. Re:double rainbows by Tacvek · · Score: 1

      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.

      --
      Stylish sheet to fix many problems in Slashdot's D3: https://gist.github.com/801524
    53. Re:double rainbows by badkarmadayaccount · · Score: 1

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

      --
      I know tobacco is bad for you, so I smoke weed with crack.
  6. Achronix FPGA's fabbed by Intel by allanw · · Score: 4, Informative
  7. more jobs for me by fpgaprogrammer · · Score: 4, Funny

    yay!

    1. Re:more jobs for me by rrohbeck · · Score: 1

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

    2. Re:more jobs for me by SuricouRaven · · Score: 2, Insightful

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

    3. Re:more jobs for me by fpgaprogrammer · · Score: 1

      i am an ee monster!

    4. Re:more jobs for me by Anonymous Coward · · Score: 0

      No. Designing the PCBs are hard, programming FPGAs are easier than software programming. One just have to come to terms with the idea that everything is parallel and that communication between blocks are synchronous.

    5. Re:more jobs for me by Anonymous Coward · · Score: 0

      No, it is not hard to program an FPGA. You just need to think in parallelism instead of sequential.

    6. Re:more jobs for me by Anonymous Coward · · Score: 0

      FPGA programming (or rather desiging for an FPGA, implementing algorithms) is not so much about EE as it is about CS. The bulk of the work apart from knowing how to implement certain things and interfacing with other systems either on the FPGA itself or in the vicinity of the FPGA is knowing the tools of the trade inside out, especially knowing how to deal with the obscure errors that they tend to throw in your face at the most inconvenient times. It does not help to know about Ohm's law or how to solve differential equations or design an analog circuit. It takes a special kind of knowledge not necessarily taught to your averaga EE or CS student.

    7. Re:more jobs for me by mrand · · Score: 1

      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

      --
      -- PGP keyID: 0x4C95994D
    8. Re:more jobs for me by c++0xFF · · Score: 1

      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.

  8. FPGA users already don't care by r00t · · Score: 1

    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.

    1. Re:FPGA users already don't care by AuMatar · · Score: 4, Informative

      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.

      --
      I still have more fans than freaks. WTF is wrong with you people?
    2. Re:FPGA users already don't care by sznupi · · Score: 1

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

      --
      One that hath name thou can not otter
    3. Re:FPGA users already don't care by 91degrees · · Score: 1

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

    4. Re:FPGA users already don't care by leuk_he · · Score: 2, Insightful

      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.

    5. Re:FPGA users already don't care by Anonymous Coward · · Score: 0

      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.

      They used to be about rapid development/prototyping. Nowadays, all (most) FPGAs support partial runtime reconfiguration, which means that you can use the same die area for different functions at different times. There is quite a lot of research in this area, though at this time there are few commercial solutions available. But the technology could be used for both HPC (accelerating large parallel computations) as well as embedded computing (reducing area footprint/memory consumption).

      Granted, the reconfigurable computing field in academia is already 15 years old. The ideas haven't changed, but only recently have FPGAs become suitable for applications beyond academic theory.

    6. Re:FPGA users already don't care by Anonymous Coward · · Score: 0

      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.

      There is a kernel of truth to that, however more and more portable applications need to be quick to market, which means you either need low power FPGA:s, or a super-fast ASIC development cycle, or low power standard parts and good embedded software developers.

    7. Re:FPGA users already don't care by fpgaprogrammer · · Score: 2, Informative

      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!

    8. Re:FPGA users already don't care by deKernel · · Score: 1

      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.

    9. Re:FPGA users already don't care by Anonymous Coward · · Score: 0

      Emphatic yes.
      As an example, ~1-2 day DES crackers have been built with stacks of FPGA boards that use a fraction of the power and cost magnitudes less than the equivalent solution using general purpose processors.
      Even if the clock rates are slow compared to what ASICs are capable of, FPGAs make a damn lot of good sense in some cases.

    10. Re:FPGA users already don't care by mounthood · · Score: 1

      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.

      --
      tomorrow who's gonna fuss
  9. Will it be used to for hardware enforced DRM? by Ivan+Stepaniuk · · Score: 1

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

    --
    My other signature is a car
  10. 0,1, or 2 PowerPC cores by Jan · · Score: 1

    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.

  11. Actual information by Mysteray · · Score: 4, Informative

    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?

    1. Re:Actual information by allanw · · Score: 2, Interesting

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

    2. Re:Actual information by MichaelKristopeit193 · · Score: 0

      really? what sort of application are you thinking could benefit from a FPGA but also simultaneously saturate a PCI-E lane?

    3. Re:Actual information by allanw · · Score: 1

      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.

    4. Re:Actual information by MichaelKristopeit193 · · Score: 0

      exactly what i was thinking... either the cpu would be utilized in post processing, or almost not at all writing the ram buffer to disk.

    5. Re:Actual information by squizzar · · Score: 1

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

    6. Re:Actual information by MichaelKristopeit193 · · Score: 0

      why would the signal need to be routed through the CPU? there are already cheap ASICs that do resizing/deinterlacing... but even without using one of those... the FPGA could handle the task on it's own and output directly to video memory.

    7. Re:Actual information by dgatwood · · Score: 1

      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....

      --

      Check out my sci-fi/humor trilogy at PatriotsBooks.

    8. Re:Actual information by Doc+Ruby · · Score: 1

      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.

      --

      --
      make install -not war

    9. Re:Actual information by Anonymous Coward · · Score: 0

      Hopefully Intel will make an eval board?

      More seriously, it remains to be seen how many are willing to risk the shop on a product that may or may not be around in a few years time.

      When Intel dropped the Xscale line of CPUs, there were a lot of disillusioned customers who went back to manufacturers with a proven track record of delivering products for the embedded market year after year. Being able to buy the same chip ten years down the road is important.

    10. Re:Actual information by dgatwood · · Score: 1

      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....

      --

      Check out my sci-fi/humor trilogy at PatriotsBooks.

    11. Re:Actual information by Mysteray · · Score: 1

      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?

    12. Re:Actual information by badkarmadayaccount · · Score: 1

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

      --
      I know tobacco is bad for you, so I smoke weed with crack.
  12. Only certain Virtex-2Pro/4/5s have PowerPC cores by Jan · · Score: 4, Informative

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

  13. In particular... by Jan · · Score: 5, Informative

    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.

    1. Re:In particular... by Anonymous Coward · · Score: 0

      Additionally, on both Altera and Xilinx, you can implement a Cortex-M0 core right in the FPGA logic. This means you can put as many cores in there as you can fit, interconnect them however you want, and have direct access to the ARM Host Bus. Need ten serial ports? Easy. PCIe x4? Get a chip with the requisite transceiver blocks, and done. The limit here is that it's hard to push these cores over a couple hundred MHz, but the goal is to enable applications that don't need a huge CPU, doing most of the real processing in the FPGA, which usually has hundreds of independent RAM buffers and multiplier/accumulator (MAC) stages, in addition to standard logic and routing.

      For example, the software radio market has been moving from DSPs to FPGAs big time over the last few years. I once wrote a report where I compared implementations of a simple band shift stage (i.e. digital channel selection) on a DSP (ADI's dual-core 600 MHz SHARC) and an inexpensive FPGA (Altera's Cyclone III). For the SHARC to keep up with the mass of data, it had to sacrifice its level 1 and 2 caches for lookup tables to keep I/O throughput up and use both cores at 67% load. Not really leaving much for any other task. Meanwhile, the Cyclone III (lower cost and power than the SHARC) only needed about 40% capacity of the smallest chip in the product line, and could run fine at 100 MHz.

      Years ago, Altera tried the "hard core" approach with its Mercury line. It combined a PowerPC 4xx or ARM7TDMI hard core (I forget which) with Altera's FPGA array. It didn't sell; designers preferred the far greater flexibility of mixing and matching FPGAs and CPUs. The Mercury line was left to rot, and Altera went all-in with soft cores (their Nios II as well as ARM Cortex-M0) and it seems to be working out fine.

      Finally, the reason that I, as a senior embedded engineer, don't really consider this a huge game-changer, is that Intel's Atom really isn't very power efficient compared to ARM. We have an application that is using an Atom board because the software guys just had to develop it on and for Windows. That board burns 7 Watts of power all by its lonesome, requiring heat sinking and some small amount of forced air cooling. (The Atom, idling, without heat sink or moving air, will heat itself to over 65 C.) Meanwhile, we've got two teams using an Atmel ARM9-based system which runs ucLinux and burns 2 Watts of power. It doesn't need a heat sink or anything special; convection keeps it cool enough.

      This is the real "need" for an Atom on an FPGA: You want to run Windows.

    2. Re:In particular... by Bassman59 · · Score: 1

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

      Actel supports Cortex-M1, too.

    3. Re:In particular... by jrobot · · Score: 1

      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]

    4. Re:In particular... by ewertz · · Score: 0

      And M3.

  14. Very cool and very kludgy by rrohbeck · · Score: 1

    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.

  15. Put an ARM in the FPGA by flyingfsck · · Score: 0, Offtopic

    The obvious solution is to put an ARM processor in the FPGA.

    --
    Excuse me, but please get off my Pennisetum Clandestinum, eh!
    1. Re:Put an ARM in the FPGA by Arlet · · Score: 4, Informative

      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.

    2. Re:Put an ARM in the FPGA by MichaelKristopeit193 · · Score: 0
      what about low-volume products? what about low-performance products? why not discuss them?

      mask fees alone for ASICs are going to run 6 figures real quick.

      granted, i don't see a use for CPU+FPGA in 1 package... but i also don't see a use for telling only half the story.

    3. Re:Put an ARM in the FPGA by Arlet · · Score: 1

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

    4. Re:Put an ARM in the FPGA by MichaelKristopeit193 · · Score: 0
      those markets are building products that are extremely cheap and yet functional for 95%+ of most users' task demands... if intel doesn't compete in those markets, eventually the markets they do compete in won't be required. a 2010 "netbook" blows away an average 1997 desktop. what am i doing on my 2015 desktop that requires so much more computational power or specialization than before?

      sufficiency is cancer to intel's unchanged business model.

    5. Re:Put an ARM in the FPGA by mr_mischief · · Score: 1

      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.

    6. Re:Put an ARM in the FPGA by thegarbz · · Score: 1

      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.

    7. Re:Put an ARM in the FPGA by Anonymous Coward · · Score: 0

      For high-volume products they can't compete on price, and for high-performance products they can't compete on speed.

      True, but the power of an FPGA is its reconfigurable properties. With an ASIC, you're stuck unless you want to do some soldering.

  16. Reading the Intel E6x5C Platform Brief... by Jan · · Score: 5, Informative

    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. ..."

    1. Re:Reading the Intel E6x5C Platform Brief... by Anonymous Coward · · Score: 0

      This PCIe link provides good bandwidth for the most likely purpose this FPGA is thought for: Being a programmable I/O chip. This is especially interesting in the context where you don't need most of the standard PC I/O components, but very specific ones. "Programmable" SoC, kind of.

      Actually, this whole thing doesn't come as a surprise; Intel has been messing with the Atom + FPGA combo before already, which runs under the label "In-Vehicle Infotainment" (Russellville board, Atom + US15W + Xilinx FPGA). You will find references to IVI in Moblin/MeeGo as well.

    2. Re:Reading the Intel E6x5C Platform Brief... by Anonymous Coward · · Score: 0

      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. ..."

      Well, it's not cheap but it's already there: For example the HC-1 delivers the envisioned performance for specific applications using FPGAs as a second CPU in a dual-socket system, so the bandwidth is not an issue. Of course, developing for a FPGA is an effort of its own, but for this they offer pre-defined personalities for the FPGAs by which the FPGA can be used using an extended instruction set as a co-processor for a specific task.

    3. Re:Reading the Intel E6x5C Platform Brief... by Vectormatic · · Score: 1

      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

      --
      People, what a bunch of bastards
    4. Re:Reading the Intel E6x5C Platform Brief... by wisty · · Score: 1

      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 ;)

    5. Re:Reading the Intel E6x5C Platform Brief... by Lennie · · Score: 1

      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.

      --
      New things are always on the horizon
    6. Re:Reading the Intel E6x5C Platform Brief... by Doc+Ruby · · Score: 1

      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?

      --

      --
      make install -not war

    7. Re:Reading the Intel E6x5C Platform Brief... by mako1138 · · Score: 1

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

  17. Programming software? by galvitron · · Score: 1

    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.

  18. It's been done, it's being done. by Jan · · Score: 2, Interesting

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

  19. Re:My Story by somersault · · Score: 1, Offtopic

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

    --
    which is totally what she said
  20. Re:Only certain Virtex-2Pro/4/5s have PowerPC core by Anonymous Coward · · Score: 0

    What?

  21. FPGA-based robot controllers by G3ckoG33k · · Score: 3, Interesting

    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!

  22. Cloud FPGAs by davidjgraph · · Score: 1

    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?

  23. ARM and FPGA by Anonymous Coward · · Score: 0

    "Therein lies the rub, of course: there's nothing to stop customers licensing one of ARM's chip designs and combining it with an FPGA themselves, but it means dealing with two companies - and Intel is obviously betting heavily on there being a sizable quantity of ODMs and OEMs that would prefer to work with a single firm."
    What a beautiful lie. Like the leading FPGA manufacturer haven't done it yet - http://www.xilinx.com/technology/roadmap/processing-platform.htm

  24. Re:My Story by cerberusss · · Score: 0, Offtopic

    During that period, Mrs Palin sexually abused me

    Ah yes. Contrary to popular belief, some females are especially prone to bouts of arousal during their period.

    --
    8 of 13 people found this answer helpful. Did you?
  25. Re:Only certain Virtex-2Pro/4/5s have PowerPC core by squizzar · · Score: 2, Funny

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

  26. It's Complicated by MacGyver2210 · · Score: 1

    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!"

    --
    If the only way you can accept an assertion is by faith, then you are conceding that it can't be taken on its own merits
    1. Re:It's Complicated by Anonymous Coward · · Score: 0

      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 guarantee you can't, since it only comes in a BGA package. From the Intel datasheet:

      "Single-package: A compact 37.5 x 37.5 mm, 0.8 mm ball pitch" and "1466 ball FCBGA".

      Those pesky BGA's are impossible to hand-solder, but some very brave souls have had luck using a toaster oven to solder them down. I'm just now making the transition to SMD, and it's a real bear. I wonder if us tinkerers should start a 'death clock' for thru-hole components?

      [Anonymous due to moderation of other comments]

    2. Re:It's Complicated by Doc+Ruby · · Score: 1

      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.

      --

      --
      make install -not war

  27. Hardly a unique product, apart from x86 by hattig · · Score: 2, Informative

    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?

    1. Re:Hardly a unique product, apart from x86 by Doc+Ruby · · Score: 1

      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.

      --

      --
      make install -not war

  28. Not Unique by Anonymous Coward · · Score: 0

    The article says the Atom CPU/FPGA combo is unique. It is not at all unique -- the Actel SmartFusion processor combines a hard ARM and FPGA. This processor has been available for at least a year. I have several prototyping boards with the processor. The combination of a hard processor with the FPGA is a killer combination. There are too many uses to list here.

  29. SSL offloading by DrSkwid · · Score: 1

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

    --
    There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
  30. What kind of FPGA is it anyways? by Anonymous Coward · · Score: 0

    Anyone know what size FPGA will be there? Now obviously it will be a semi-custom design, but if it's something along the lines of a cyclone 2, there ain't THAT much to gain...

    Now if it's more like a big stratix I'm not saying... ×D

  31. Viruses? by CrazyBusError · · Score: 1

    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...

    --
    -Never argue with an idiot. They drag you down to their level, then beat you with experience-
  32. Eclipse Tools? by Doc+Ruby · · Score: 1

    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?

    --

    --
    make install -not war

  33. Xilinx / ARM Cortex A-9 by Doc+Ruby · · Score: 1

    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.

    --

    --
    make install -not war

    1. Re:Xilinx / ARM Cortex A-9 by Tacvek · · Score: 1

      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.

      --
      Stylish sheet to fix many problems in Slashdot's D3: https://gist.github.com/801524
    2. Re:Xilinx / ARM Cortex A-9 by Doc+Ruby · · Score: 1

      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.

      --

      --
      make install -not war

    3. Re:Xilinx / ARM Cortex A-9 by Tacvek · · Score: 1

      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.

      --
      Stylish sheet to fix many problems in Slashdot's D3: https://gist.github.com/801524
  34. Re:My Story by Anonymous Coward · · Score: 0

    So you're saying she opened her gates while you were reconfiguring her but she didn't FPGAd in your mouth? Perhaps you didn't do it in a sufficiently atomic way?

  35. Re:Only certain Virtex-2Pro/4/5s have PowerPC core by Andy+Dodd · · Score: 1

    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.

    --
    retrorocket.o not found, launch anyway?
  36. Re:Only certain Virtex-2Pro/4/5s have PowerPC core by Doc+Ruby · · Score: 2, Informative

    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.

    --

    --
    make install -not war

  37. Good example by SuperKendall · · Score: 2, Insightful

    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.

    --
    "There is more worth loving than we have strength to love." - Brian Jay Stanley
    1. Re:Good example by IICV · · Score: 1

      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.

    2. Re:Good example by SuperKendall · · Score: 1

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

      --
      "There is more worth loving than we have strength to love." - Brian Jay Stanley
    3. Re:Good example by __aatirs3925 · · Score: 1

      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 :)

    4. Re:Good example by Neil+Boekend · · Score: 1

      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.)

      --
      Well, I might have a way, but it only works on a semi spherical planet in a vacuum.
  38. FFT engine by LynnwoodRooster · · Score: 1

    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!

    --
    Browsing at +1 - no ACs, I ignore their posts. So refreshing!
  39. Re:Only certain Virtex-2Pro/4/5s have PowerPC core by Bassman59 · · Score: 2, Insightful

    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.

  40. So what does this mean? in plain geek please by Anonymous Coward · · Score: 0

    While I am a 15 year veteran programmer I am only familiar with the concept an FPGA and have never looked at using one. How does this work in practice?

    Can I interleave new opcodes I created for the FPGA like this:
    intel opcode
    fpga opcode
    intel opcode

    Or do I have to create a buffer, pass it to a special spot in memory, use a special intel instruction to trigger the FPGA, the FPGA works on it for a while, then it switches back to X86 mode?

  41. RTFA - $61-106 - Real issue is using the FPGA by billstewart · · Score: 1

    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?

    --

    Bill Stewart
    New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
  42. Re:Only certain Virtex-2Pro/4/5s have PowerPC core by Tacvek · · Score: 1

    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.

    --
    Stylish sheet to fix many problems in Slashdot's D3: https://gist.github.com/801524
  43. Re:So what does this mean? in plain geek please by Tacvek · · Score: 1

    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.

    --
    Stylish sheet to fix many problems in Slashdot's D3: https://gist.github.com/801524
  44. FPGA? by tunghoy · · Score: 1

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

    1. Re:FPGA? by ewertz · · Score: 0

      It is. And they never get invited back to compete on the same course because of that they do to the sandtraps.