Intel completes epic $16.7bn Altera swallow, fills self with vitamin IoT Intel has closed its mega $16.7bn (£11.2bn) deal to acquire programmable chip maker Altera, likely in a bid to move away from the declining PC market. The unit will sit in Intel's newly formed Programmable Solutions Group, headed by former Altera vice president Dan McNamara. Intel hopes to shove Altera’s field-programmable …
Only for proof of concept Prototypes. Any IoT chip will be an SoC / ASIC. An FPGA is simply too power hungry.
FPGA are only for volume too low for ASIC or prototypes. The FPGA "design tools" can target a specific FPGA for a prototype or specialist lower volume application or an ASIC.
Any IoT chip will be an SoC / ASIC. An FPGA is simply too power hungry.
For IoT, you're certainly right. But IoT is the current buzzword to get people to read the press releases; it's going to become purloined to mean "smallish computer" once corporations realise how little sensor stuff they're going to selll...
FPGA are only for volume too low for ASIC or prototypes
Maybe. Back in the '90s, I was using SRAM-based FPGAs for video processing - a kind of reconfigurable coprocessor. It made the image crunching much more effective (at the cost of development effort, naturally). I'm rather looking forward to using these new Intel chips to do more of the same.
Now this is not necessarily tied to low-volume applications; the reprogrammability of the FPGA can be of use when you need many different operations to be availble from time to time. The NRE of ASIC goes up steeply with complexity, and the field-programmability of FPGA also allows for in-the-field upgrades. Whether a product makes sense in that situation depends heavily on what Intel produce, and at what price point. But it could be interesting :-)
Vic.
I don't know whether this will fly or not, but I think Intel wouldn't spend $16.7 billion without feeling pretty confident about this.
Yes, FPGAs are more power hungry than ASICs, but there are some tasks they can complete faster than a general purpose CPU. Basically it is similar to a dedicated accelerator but since it is programmable it can accelerate a lot of things. Yes, ASICs are faster but if you have specific code you need to run and either you modify it regularly or it is very company/industry specific, the cost of developing an ASIC to accelerate it could never be justified.
Wow what a load crap that is.
The FPGA business will never grow much. FPGAs use too much silicon and too much power compared with silicon designed for a specific jobs (ASICs). That means FPGAs never get used in volumes which can support the design of an ASIC.
FPGAs have and will continue to get better but so have and will ASICs which pretty much maintains the FPGA's disadvantage.
It isn't a bad business to be in but not one for growth, The idea that FPGAs are going to be used by the million in autonomous vehicles is farcical and I don't see any internet of things application other than small parts in low volume applications.
"The idea that FPGAs are going to be used by the million in autonomous vehicles is farcical "
Agreed. But ASICs are only a good fit when the volume (and price) of parts to be sold makes sense, given the huge one time setup costs of ASIC design and production.
You wouldn't usually use an ASIC for a few hundred parts.
You wouldn't usually use an FPGA for a few million parts.
Somewhere in between is a changeover zone, where the balance changes from FPGA to ASIC.
On the whole, the size of the "use ASICS here" sector is shrinking, and the size of the "use FPGA here" is increasing.
Still plenty of room for both. One size does not fit all.
"The idea that FPGAs are going to be used by the million in autonomous vehicles is farcical"
Really, you think that they will be either standard CPUs or an ASIC they got right first time and has no need for updates due to bugs and litigation-induced changes?
"Really, you think that they will be either standard CPUs or an ASIC they got right first time and has no need for updates due to bugs and litigation-induced changes?"
Maybe they'll also invent some kind of semi-permanent but updateable software - they could call it "firmware" and update that on the fly?
You don't need to re-wire a chip to make it do different things. The connected sensors and hardware will still be the same.
FPGAs are massively faster than a CPU at highly parrallel tasks, even given the difference in clock speed. The latest generation of Altera devices combine ARM CPU cores with FPGA fabric on a 14nm process. The result is a device able to clock (on the FPGA side) at up to 1GHz, share memory with the main CPU, provide custom blocks for functions like floating point math (10Tflops peak) and DSP operations. They are both reasonably power efficient and far faster than a conventional CPU.
Where ASICs win out is cost for high volume applications. Where they lose is in flexibility and ease of reconfiguration. You can start with an FPGA design and convert it to an ASIC once things are stable and if volumes justify the costs.
" That means FPGAs never get used in volumes which can support the design of an ASIC."
Using FPGA as an Asic prototype, or for small volumes, has always been the most unimaginative use.
The reprogrammable FPGAs have always had an advantage over ASICs where a product needs to be updated in service.
The significant use is for reprogrammable units that change their configuration dynamically during operation. These changes can be data dependent on the intermediate results as the calculations proceed. Note the article's reference to data centres.
The potential was identified back in the 1980s when the reprogrammable Xilinx devices first appeared. The advantages of reconfigurable hardware in problem processing are obvious when compared to serial processing. Perhaps now there will be the investment to make it happen to overcome the limits of serial processing in many areas.
"The advantages of reconfigurable hardware in problem processing are obvious when compared to serial processing."
On paper, yes.
In practice: modern FPGAs are amazingly great hardware and have some amazing software tools to go with them. But to "solve a problem" they need to be programmed accordingly. In "datacentre" applications, that programming won't generally be using the widely available and widely understood (by hadrware people) FPGA toolsets.
It'll likely need something from the people that understand both FPGAs and the fundamentals of parallel algorithms and parallel programming (if it's not parallel, you probably don't want an FPGA). A decade or two ago when I was closer to this market, names in the frame were people like Oxford University spinoff Celoxica, whose Handel-C allowed FPGAs to be programmed in a C-like language by people who knew about parallel programming but didn't know FPGAspeak.
Intel have a compiler group. Some of them understand data flow, parallelisation, and so on. What can they bring to the table?
The "reprogrammable FPGA" technology's been there for quite a while. It's even been relatively reasonably priced, sometimes ridiculously so in hardware terms. It's had a chance to go mainstream, but the x86-dependence of the IT world in general meant it didn't happen.
Will that really change now, just because Intel own more of the picture?
Well Intel's support didn't exactly do much for WiMax (or even IA64) did it.
We'll see.
ps
Altera have been an ARM licencee for a while... *some* specific problems might be quite amenable to a little bit of ARM to manage the overall system, and a lot of FPGA to do the heavy lifting. No x86 needed.
Have actually opened one up to change a fan, and noticed it had a Xilinx Spartan FPGA in it.
That's a good example of FPGA sweet-spot where you need significant bandwidth (16Gbps), some smarts (MAC filtering, VLANs, web GUI), updatability, and perhaps the ability for others to OEM the product with their own firmware branding and "secret sauce".
Exactly. FPGAs fit very nicely in certain currently niche(ish) applications that processor-based and ASIC-based designs can't sensibly address.
Another one, now several years old: one of the digital oscilloscope manufacturers (probably Tektronix) introduced a new series of digital smart scopes. All were based around the same FPGA-based board (probably a Xilinx Virtex, iirc). Higher speeds, more functionality, etc were in-field upgrades involving reprogramming the FPGA.
"e digital oscilloscope manufacturers (probably Tektronix) introduced a new series of digital smart scopes. All were based around the same FPGA-based board "
While HP/Agilent/Keysight continued development of their Megazoom ASICs producing a range of scopes which in price/performance terms pissed all over Tektronix offerings.
"While HP/Agilent/Keysight continued development of their Megazoom ASICs producing a range of scopes which in price/performance terms pissed all over Tektronix offerings."
Whereas the Rigol DS1054Z, the budget buyer's choice of champions that pisses all over the products of HP/Agilent/Keysight in price/performance is powered by a Xilinx Spartan 6LX25 FPGA. It's not that simple.
This post has been deleted by its author
Whatever happened to identify a need, create a product to fulfill it and then mass produce it?
There's a whole new future evolving in things that require micro processors that don't sit on a desk.
There's a lot of people walking around with half a brain that need help fulfilling their vast personal void.
Unless they are implementing a CPU.
The FPGA "source" is really a description (not a program) and "compiled" into a logic array configuration loaded at power on. No run time code at all, unless part of the FPGA is implementing a CPU. It's pretty wasteful of FPGA resources to implement multipliers, so most FPGA have pre-designed multipliers. Similarly there are a variety of FPGA with an ACTUAL cpu core (not one wired out of FPGA gates), to allow efficient execution of run time code or prototype the HW around a CPU core on an SoC as implementing a CPU uses too much of FPGA.
A raw FPGA is useless to programmer unless that programmer can design the HW of a hypothetical CPU from scratch. They are not programmed in CPU sense, but designed by people that design hardware. Verilog and VHDL only look like programming languages, they are hardware definition languages for physical definition and interconnection of gates (due to ultra fast static RAM, some logic functions are truth table type Look up tables in RAM rather than interconnected NAND and NOR as in earliest designs). The Hardware design is LOADED from a ROM, EPROM, Flash Memory or even USB or JTAG at power on time. After that, it's functionally an ASIC or logic board, only actually executing ANY code if there is a CPU (FPGA based or a pre-designed core element) as part of the design.
Above about 10K parts there is no point to an FPGA.
Then someone is designing a custom CPU implemented using an FPGA.
No, that's not the case.
Modern compilers allow block functionality to be specified in C. The netlist generated is purely the logic described by the C code; there is no discrete processor.
The tools these days are very impressive, even if the implementation of some of them leaves quite a lot to be desired[1]...
Vic.
[1] I was given the task of finding out why a certain compiler is twice as fast on Windows 7 as it is on Linux on the same hardware. A bit of profiling showed that the Linux version was spending 90% of its time in gettimeofday(). The "port" was simply gluing a compatability layer under the Windows version, and that layer really wasn't well-written...
"After that, it's functionally an ASIC or logic board, only actually executing ANY code if there is a CPU (FPGA based or a pre-designed core element) as part of the design."
That is a very narrow view of what constitutes a computer. Anything which can remember a dynamic binary state is capable of being programmed to perform a deterministic range of digital logic activities.
When microprocessors first arrived many people tended to think of them as small computers. Then microprocessor controllers started to supplant designs using discrete logic devices - although some functions had to be implemented as ASICs for speed or compactness.
Eventually the embedded controller industry required more powerful microprocessors with a minimum of hardware logic devices - they especially did not want inflexible ASIC designs that were expensive to develop and expensive to update.
The first FPGAs were seen as agile ASICs - with once-off fuses to program them. Then the reprogrammable FPGAs made it possible to reconfigure them for updates - or even dynamically in real-time.
The interesting disruption was when FPGAs allowed a product design to use a cheap microprocessor - rather than the more obvious expensive ones. The FPGAs provided compact fast parallel logic processing - but their function could also be upgraded at the same time as the microprocessor code. The FPGA's function could also be dynamically changed as part of the product's normal running.
One company made a nice profit on such an innovative cheap design. The high market price for the commodity product was established by their competitors - who all used an expensive powerful microprocessor to achieve similar functionality. The company happily settled for a market share that gave them a very high margin - knowing that they could undercut any competitor if it was ever necessary. Later models from their competitors also adopted the same technique.
"Then microprocessor controllers started to supplant designs using discrete logic devices"
As small computers, running programs simulating slow discrete logic. Internally a quite different design. I've implemented decoders, counters, generators etc using PIC micros. They ARE small cheap computers, (from 30c).
FPGA are fast, power hungry and expensive. They ONLY execute code AFTER loading the configuration if the design implements a CPU or it has a ready made CPU core.
Field Programmable Logic Array. They replace discrete ready made VLSI with a custom design in a production chip.
You won't get much FPGA for $10.
"FPGA don't run programs Unless they are implementing a CPU."
See, this is the problem you end up with when you have hardware people and software people and limited crossover between the two.
"A raw FPGA is useless to programmer unless that programmer can design the HW of a hypothetical CPU from scratch"
Not exactly. Go read about Handel C (there are probably others I know even less about).
Someone can describe a program (and its interfaces) in something like Handel C and the transformed Handel C source can be loaded into an FPGA which with a following wind for the right kind of applications can look to the system designer just as though "it is running a program" except it does it more quickly than a conventional CPU could. Or for less cost.
The person writing the Handel C does not need to know how to design an instruction set or anything like that; they just need to be able to describe the interfaces and the data processing required by the application.
Doesn't suit all applications in all environments. Traditionally a bit niche. But last time I looked, FPGAs of a given capability were getting cheaper more quickly than ASICs were getting cheaper, so the volume at which custom ASICs are a better investment increased as time goes by.
If you're building disk drives (huge volume, limited variety, very cost sensitive), ASICs probably still win because of the volume and complexity tradeoffs.
If you're building vehicle control systems (not so huge volume, maybe more variety, maybe less cost sensitive)? Not such an obvious choice (unless custom ASIC economics have changed in the last few years)
OMG! Somebody still hung up on CPUs!
To implement an algorithm you only need a sequencer that can sequence through all the required states as needed. This can be done in hardware using logic power, or in software using instruction power (although ultimately this uses the logic power of the CPU's ALU and built-in sequencer.)
"[...] and "compiled" into a logic array configuration loaded at power on"
Early FPGAs found novel applications that required them to be reconfigured during real-time processing. Later models allowed for parts of the FPGA to be reconfigured at any time.
Way back in the 1990s I was using Xilinx FPGAs inside a PC as a hardware test tool. The downloaded FPGA configuration was generated by a DOS program on the fly - it did not have a pre-compiled image for each of the very large number of test cases that were theoretically possible,
Intel might have the overall multi-discipline resources and influence to advance the Holy Grail of FPGA parallel processing in association with a conventional CPU. That dynamically reconfigures the FPGA as a calculation advances. The configuration changes are generated in response to the data and intermediate results This is primarily a parallel processing descriptive language problem - Handel-C has already been mentioned.
A number of the largest data center customers are already using custom x86 server hardware that includes large FPGA devices to offload custom data processing algorithms. Companies like Facebook and Google have engineers to implement parts of their algorithms in an FPGA, while Intel's acquisition of Altera may make the technology available to smaller customers.
Intel CPU with FPGA onboard
http://www.extremetech.com/extreme/184828-intel-unveils-new-xeon-chip-with-integrated-fpga-touts-20x-performance-boost
FPGA with Intel CPU onboard
https://code.google.com/p/fpga-x86-processor/
Arm CPU with FPGA onboard
https://www.altera.com/products/soc/overview.html
Other combinations are available
FPGA with Arm CPU onboard
https://en.wikipedia.org/wiki/Amber_%28processor_core%29
Maybe they shouldn't have chopped their own legs out from under them and everyone else when they released a $183 E6300 that was faster than the $500 PressHott... Now we are all five years in he hole because ALL OF A SUDDEN our old PCs were NOT WORTH ANYTHING, so many had to put off the new system...
At the same time, ARM was drinking their milkshake and giving people something other than WinTel to surf the web...
Hopefully, Zen will fix it by more clearly differentiating products... Who can really tell the difference between Core i3, i5, and i7...?
i7 is for those who need lots and lots of computing power, like photo and movie editing, database crunching, etc. The power user. Or gamers! A quad-core or better Xeon does the trick here, too.
i5 is for people who are less demanding than the power user, but who still need to be productive with a computer.
i3 is your basic business processor.
Intel confused us all at the outset with insufficient differentiation between i5 and i7, but they seem to have fixed that.
Ailing? Well, the PC market is hardly dormant, but ailing is a stretch. For Intel, all those Xeon, i3, i5, i7, Pentium and Celeron CPUs generate billions of revenue which cannot be ignored. It's just that the revenue is not growing, but declining slowly. Foreseeable, actually. Tablets and smartphones have something to do with it. Microsoft's total screwup with Windows 8 sure did hurt the entire personal computer biz. And altho Windows 10 has some nice features (easier install and update, occupies less disk space than any Windows since Vista), it is still easy to look at Windows 10 with a jaundiced eye as spyware that wants to surveil everyone and feed them ads and sell all the Microsoft cloud crap.
Until there is some sort of monumental paradigm shift in how we all do our computing, corporations, enterprises, government agencies and consumers alike will replace their desktop and laptop computers with new ones now and again. Ka-ching! More revenue for Intel, selling processor chips AND motherboard chipsets. Not ailing, but not booming like it once did.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
