I too am wondering about how the FPGA will be accessed from software. I can only assume that there's a built-in DMA interface, and that only one process can grab the FPGA at a time.
Why would it need to be accessed from software? There's probably a strong likelihood that hardware manufacturers will configure the FPGA in the factory, and the end-user will end up oblivious to the fact it's even there.
Thats the more likely scenario, but also the much less interesting one, since, at least for me, the possibility of runtime reconfigurable hardware is what makes me like this.
I agree .. it's less interesting - but I suppose the benefit of having an FPGA on-board is reduced development time (and cost) for the hardware manufacturers. Once they've created their product - and licensed the necessary cores .. they're going to try their damnedest to keep the unit sealed.
End-users, sure, but developers is another story completely. I'm sure there will be Linux libraries to access the FPGA directly, within a few weeks/days :P
The FPGA fabric will also have to be configured whenever power is lost. This probably includes the low power states of the Atom since the FPGA wasn't designed to support it. It would make sense for this to be part of the BIOS-level code since the FPGA is useless until configured.
There is a savings in board space, but, otherwise, this solution provides no additional value. You can already connect an Atom processor and FPGA through PCI Express.
The configuration would be saved in Flash memory and loaded at boot time. Also, you'd need to reboot the FPGA each time a new configuration would be written in.
I am not yet aware of FPGA-like chip architecture that can be reconfigured dynamically.
Looking at the product brief, it seems that the Intel CPU and the FPGA are being packaged on the same module and connected over PCI-E. So the interface from the processor to the FPGA will be over this connection. I imagine the development flow will be the same as if you connected these devices externally on your PCB. The processor won't need to know its connected to an FPGA, just a PCI-E device, and the same goes for the FPGA. The standard FPGA development flow can be followed.
I'm completely in love with FPGAs and the possibilities that they bring. But, they bring a number of problems with them.
Because the core designs used are generally protected as intellectual property, all of the problems commerce currently has in relation to IP protection, are duplicated in this area of hardware design.
It seems that in the new coming digital age, ideas really are the main currency - and at the moment I can't really understand how things are going to pan out economically. Our traditional economic models (with scarcity driving price upwards) don't seem to sit well with IP (where abundance is unlimited).
I can only imagine that these IP problems will become more complex as time goes by - even more new IP markets are going to be formed in the near future, as rapid-prototyping and 3D printing become more commonplace.
Seriously, though, if you're an American or citizen of a Western country, you should be careful what you wish for. The fact that the Western world still owns pretty much all IP is a huge economic advantage, as long as everyone honors it. And the so-called "knowledge economy" only works if knowledge can actually be said.
Does any one know the specs of the FPGA? How many LUTS/block rams?
I think its exciting that Intel has started to pay attention to FPGAs, and hopefully with mass production, this FPGA+CPU chip will be priced cheaply---that may yet be the biggest contribution here.
I'm also curious as to how this will interact with system memory and IO. Not many details, but I can't help but be insanely excited -- this opens up so many possibilities in terms of crypto... not to mention the demoscene!
Edit: Just got the product brief. Some more info on the FPGA:
> Features transceiver speeds up to 3.125 Gbps, high-speed LVDS with SERDES at up to 840 Mbps, support for DDR3, DDR2, DDR SDRAM, QDR II, and QDR II+ SRAM memory interfacing, up to four general-purpose PLLs, 312 18 x 18 multipliers and more than 60,000 logic elements and 350 user I/O pins. Each of the high-speed transceiver channels have a clock data recovery (CDR) feature, and support for multiple I/O standards such as 3.3-V LVTTL/3.3-V LVCMOS, single-ended SSTL/HSTL and differential SSTL/HSTL.
So this is how Intel is going to go after the embedded space without having to offer embeddable CPUs. ARM has done very well because people like cell phone manufacturers can take an ARM attach some specialized cellphone DSP logic, and put it in a cellphone as one space-saving package. Since Intel was never going to allow something like this it was a big factor holding them back, but with an FPGA that third parties can put their specialized cellphone or whatever stuff in Intel will be able to get into this game at only a minor disadvantage.
For high-volume, low-margin embedded applications (like cellphones) FPGAs are not cost-effective. They also don't offer the circuit density or the power-savings of custom chips.
I was going to say the same thing. The price is already too high. At $60-$100 I think it is already too pricey if they are aiming for the same embedded market.
This is quite interesting. I wonder how capable the platform will be. The article doesn't have many details, unfortunately.
Several years ago I was looking for a chip we could use in a set-top box design. We wanted low-power high-performance H.264 decoding. We talked to a very interesting company — Stretch Inc. (http://stretchinc.com/), they've been developing something similar for many years now. They basically have a CPU with a tightly-integrated FPGA within.
Problem is, the devil is in the details. While FPGAs can theoretically provide impressive acceleration, what ends up mattering is whether you can get them data to process fast enough, what the latencies are, what the interfaces are, and how much easily-accessible memory you have on the FPGA die. That's for the easier algorithms which are mostly CPU-bound.
For memory-bound algorithms what really matters is the DMA engine. That is something Intel never got right, which is why you see Texas Instruments DSPs in most embedded applications. If you want to have predictable high-throughput data processing, you need to be in control of your caches. That means a multichannel DMA engine that lets you schedule reads ahead of time and precisely control what is in your L1/L2 at any given time. The ubiquitous n-way set associative caches are great for general-purpose code, but end up being wildly unpredictable for DSP-type stuff.
Another factor with FPGAs is how quickly they can be reconfigured — how quickly can you switch the code inside? Can you use the FPGA for several parts of your data pipeline, or does the reconfiguration take so long that it becomes impractical to switch?
So, I will be very interested in what the details are — but for the moment color me skeptical. It took Stretch many years to get to a well-designed architecture and even that wasn't right for all purposes. And Intel isn't known for experience with DSPs, which really matters here.
Note I didn't even mention compiler support, OS support and how the FPGA is actually to be programmed. I consider those to be secondary to actual hardware performance.
28 comments
[ 4.0 ms ] story [ 73.6 ms ] threadThat said, why not link to http://www.thinq.co.uk/2010/11/22/intel-launches-fpga-equipp... instead of slashdot?
http://www.fpga4fun.com/ is a nice site with stuff that novices can have a go at creating.
There's also a sister site (http://www.knjn.com/) where you get hold of inexpensive FPGAs for tinkering with.
There is a savings in board space, but, otherwise, this solution provides no additional value. You can already connect an Atom processor and FPGA through PCI Express.
I am not yet aware of FPGA-like chip architecture that can be reconfigured dynamically.
Because the core designs used are generally protected as intellectual property, all of the problems commerce currently has in relation to IP protection, are duplicated in this area of hardware design.
It seems that in the new coming digital age, ideas really are the main currency - and at the moment I can't really understand how things are going to pan out economically. Our traditional economic models (with scarcity driving price upwards) don't seem to sit well with IP (where abundance is unlimited).
I can only imagine that these IP problems will become more complex as time goes by - even more new IP markets are going to be formed in the near future, as rapid-prototyping and 3D printing become more commonplace.
Well, we'll have either that, or rampant piracy...
Seriously, though, if you're an American or citizen of a Western country, you should be careful what you wish for. The fact that the Western world still owns pretty much all IP is a huge economic advantage, as long as everyone honors it. And the so-called "knowledge economy" only works if knowledge can actually be said.
I'm interested to see where these chips go.
I think its exciting that Intel has started to pay attention to FPGAs, and hopefully with mass production, this FPGA+CPU chip will be priced cheaply---that may yet be the biggest contribution here.
Edit: Just got the product brief. Some more info on the FPGA:
> Features transceiver speeds up to 3.125 Gbps, high-speed LVDS with SERDES at up to 840 Mbps, support for DDR3, DDR2, DDR SDRAM, QDR II, and QDR II+ SRAM memory interfacing, up to four general-purpose PLLs, 312 18 x 18 multipliers and more than 60,000 logic elements and 350 user I/O pins. Each of the high-speed transceiver channels have a clock data recovery (CDR) feature, and support for multiple I/O standards such as 3.3-V LVTTL/3.3-V LVCMOS, single-ended SSTL/HSTL and differential SSTL/HSTL.
Interestingly, Altera has basically end-of-lifed that approach in favor of their NIOS II soft CPU. Atom is definitely a bit higher end than NIOS.
Several years ago I was looking for a chip we could use in a set-top box design. We wanted low-power high-performance H.264 decoding. We talked to a very interesting company — Stretch Inc. (http://stretchinc.com/), they've been developing something similar for many years now. They basically have a CPU with a tightly-integrated FPGA within.
Problem is, the devil is in the details. While FPGAs can theoretically provide impressive acceleration, what ends up mattering is whether you can get them data to process fast enough, what the latencies are, what the interfaces are, and how much easily-accessible memory you have on the FPGA die. That's for the easier algorithms which are mostly CPU-bound.
For memory-bound algorithms what really matters is the DMA engine. That is something Intel never got right, which is why you see Texas Instruments DSPs in most embedded applications. If you want to have predictable high-throughput data processing, you need to be in control of your caches. That means a multichannel DMA engine that lets you schedule reads ahead of time and precisely control what is in your L1/L2 at any given time. The ubiquitous n-way set associative caches are great for general-purpose code, but end up being wildly unpredictable for DSP-type stuff.
Another factor with FPGAs is how quickly they can be reconfigured — how quickly can you switch the code inside? Can you use the FPGA for several parts of your data pipeline, or does the reconfiguration take so long that it becomes impractical to switch?
So, I will be very interested in what the details are — but for the moment color me skeptical. It took Stretch many years to get to a well-designed architecture and even that wasn't right for all purposes. And Intel isn't known for experience with DSPs, which really matters here.
Note I didn't even mention compiler support, OS support and how the FPGA is actually to be programmed. I consider those to be secondary to actual hardware performance.