Intel moves beyond x86, puts 64-bit ARM processor in new FPGA chip

[Coaxialgamer]

Quote

Intel's decision to embrace ARM chips for the FPGA may show a thawing of the chilly relationship between the two companies

Quote

It seems like the chip war between Intel and ARM is slowly winding down, at least for the time being.

Intel for decades has doggedly sworn by chips based on its homegrown x86 architecture, but the company is putting a 64-bit ARM processor in its new Stratix 10 FPGA (field-programmable gate array), which was announced on Tuesday.

The FPGA -- based on Altera technology -- can be reprogrammed to do a wide variety of server or network tasks. It can also run algorithms for machine learning.

In a larger context, the chip points to a long-term strategy of Intel thinking beyond x86 and warming up to other architectures as it looks to shed its reliance on PCs.

 

Quote

In the future, it's possible that x86 and ARM could be integrated in some Intel's chips. Intel plans to integrate Altera FPGAs in Xeon server chips and may put x86 and ARM CPUs on one chip. Intel is already pairing Xeon and Altera FPGAs on multi-chip circuit boards.

ARM CPUs have been used in Altera FPGAs, but the Cortex-A53 in Stratix 10 shows Intel isn't shying away from the latest ARM technology. There's also the possibility of Intel eliminating the ARM CPU for x86 in its integrated Xeon FPGA chip.

Intel and ARM have feuded in the past on architectural superiority, sometimes indulging in petty arguments over power and performance. Intel wants to put its x86 chips in as many devices as possible, but it is willing to tap into ARM CPU designs when necessary.

A sequence of events has led to a friendlier relationship between Intel and ARM. Facing a slowdown in the PC market, Intel in April restructured to focus on robots, drones, cars, and the internet of things. Most PCs use x86 chips, but ARM dominates many of the fast-growing markets Intel is now focusing on.

ARM is also helping drive Intel's lucrative server business. ARM-based mobile and IoT devices feed information to servers that perform data analysis, image recognition, and natural language processing tasks. Intel's x86 chips dominate servers, and the growth in ARM-based devices will indirectly drive sales of high-margin Intel Xeon chips. 

It's nice to see intel and arm collaborating , it could bring progress to both sides. especially since x86 has some serious bottlenecks that armv8 does not

source : http://computerworld.com/article/3127791/computer-hardware/intel-moves-beyond-x86-puts-64-bit-arm-processor-in-new-fpga-chip.html

[patrickjp93]

Damnit, ninja'ed...

 

And Intel is doing this primarily because it means people don't have to recompile their code to run it on the new Altera FPGAs. It's a means to retain customers and get trust before beginning the transition.

[FPSwithaWacomTablet]

I would really like this, only if Quartus II wasn't $12k per copy... 

 

Actually just for any Alterra FPGA in general..

[captain_to_fire]

No wonder Microsoft is pushing developers to use Universal Windows Platform (UWP) for their apps. Although I'm curious if an ARM/x86 combo will run something like Gears of War smoothly vs an i7-6700k with only Intel HD Graphics.

 

What's a Universal Windows Platform (UWP) app?

 

[FPSwithaWacomTablet]

2 hours ago, patrickjp93 said:

Damnit, ninja'ed...

 

And Intel is doing this primarily because it means people don't have to recompile their code to run it on the new Altera FPGAs. It's a means to retain customers and get trust before beginning the transition.

Also how does one find cheap VHDL/Verilog compilers that work with any Xilinx or Alterra FPGA?

[Guest]

6 hours ago, Coaxialgamer said:

 

It's nice to see intel and arm collaborating , it could bring progress to both sides. especially since x86 has some serious bottlenecks that armv8 does not

source : http://computerworld.com/article/3127791/computer-hardware/intel-moves-beyond-x86-puts-64-bit-arm-processor-in-new-fpga-chip.html

Anyone else here wondering about Texas Instruments?  Anyone.... ???

[Bensemus]

17 minutes ago, FPSwithaWacomTablet said:

Also how does one find cheap VHDL/Verilog compilers that work with any Xilinx or Alterra FPGA?

Go back to school? All our labs have quartus installed

 

Assuming it's not for work otherwise they would pay for it Quartus does have a free version. It takes longer to compile and it may be missing a think or two but it might work for you. I know a few of my classmates installed it on their laptops. As far as I know it wasn't a student version.

[patrickjp93]

1 hour ago, FPSwithaWacomTablet said:

Also how does one find cheap VHDL/Verilog compilers that work with any Xilinx or Alterra FPGA?

You don't, because no one uses Verilog anymore in production. It's all moved to OpenCL.

 

2 hours ago, FPSwithaWacomTablet said:

I would really like this, only if Quartus II wasn't $12k per copy... 

 

Actually just for any Alterra FPGA in general..

Download GCC and use OpenCL. No one uses Verilog/Quartus for production code anymore unless you're stuck in the Stone Age.

[Mark77]

1 hour ago, patrickjp93 said:

You don't, because no one uses Verilog anymore in production. It's all moved to OpenCL.

 

Download GCC and use OpenCL. No one uses Verilog/Quartus for production code anymore unless you're stuck in the Stone Age.

LOL.  Do you even know what a HDL is? 

[patrickjp93]

31 minutes ago, Mark77 said:

LOL.  Do you even know what a HDL is? 

In what context?

Hardware Design Language

High Density Library

High Density Lipoprotein

Hastings Data Logger

...?

 

And I work for a financial institution that does high speed derivative trading using FPGAs. OpenCL is far easier to debug, faster to code in, and has consistently produced faster code/circuits.

[Mark77]

25 minutes ago, patrickjp93 said:

 

And I work for a financial institution that does high speed derivative trading using FPGAs. OpenCL is far easier to debug, faster to code in, and has consistently produced faster code/circuits.

Maybe in that very specific realm, but there are plenty of communications applications, in particular, for which trying to "code" them in OpenCL or whatever would be absurd.  We're talking embedded systems here, not just specialized coprocessing of banking applications. 

[Energycore]

6 hours ago, patrickjp93 said:

Damnit, ninja'ed...

 

And Intel is doing this primarily because it means people don't have to recompile their code to run it on the new Altera FPGAs. It's a means to retain customers and get trust before beginning the transition.

Is it as simple as just put both the x86 and ARM instruction sets, plus any useful extensions, to solve compatibility issues and provide more options for coders?

[Mark77]

5 minutes ago, Energycore said:

Is it as simple as just put both the x86 and ARM instruction sets, plus any useful extensions, to solve compatibility issues and provide more options for coders?

For some applications, it may be possible to put both an x86 and an ARM core on the same die, and selectively disable one or the other. 

 

For self-driving cars, for example, they are likely to require redundant CPU's with different software architectures performing redundant calculations to meet the system reliability requirements.  So one chip could boot up as an ARM chip, and run ARM code.  The other, identical chip, comes up in x86 mode, and runs x86 code.  And a third chip comes up randomly assigned to one or the other.  A comparator would compare the results of the 3 chips and trigger an alarm if there was a discrepancy. 

[patrickjp93]

12 minutes ago, Energycore said:

Is it as simple as just put both the x86 and ARM instruction sets, plus any useful extensions, to solve compatibility issues and provide more options for coders?

To pack both instruction sets on a chip would require a binary analyzer frontend to figure out which ISA was being used. The same bit string can be used on both architectures and mean 2 completely different things, so it's not that simple. Also, I'm pretty sure ARM and x86 use different byte orderings, so it's even harder than that.

 

17 minutes ago, Mark77 said:

Maybe in that very specific realm, but there are plenty of communications applications, in particular, for which trying to "code" them in OpenCL or whatever would be absurd.  We're talking embedded systems here, not just specialized coprocessing of banking applications. 

I'm afraid AT&T disagrees with you, and they handle secure communications for the U.S. military via FPGAs.

[Energycore]

1 minute ago, Mark77 said:

For some applications, it may be possible to put both an x86 and an ARM core on the same die, and selectively disable one or the other. 

 

For self-driving cars, for example, they are likely to require redundant CPU's with different software architectures performing redundant calculations to meet the system reliability requirements.  So one chip could boot up as an ARM chip, and run ARM code.  The other, identical chip, comes up in x86 mode, and runs x86 code.  And a third chip comes up randomly assigned to one or the other.  A comparator would compare the results of the 3 chips and trigger an alarm if there was a discrepancy. 

That's an interesting approach to error correction. Hmm. But a single chip can't both be x86 and ARM, right?

[Mark77]

1 minute ago, Energycore said:

That's an interesting approach to error correction. Hmm. But a single chip can't both be x86 and ARM, right?

It could be built as both (so the vendor doesn't have to develop 3 unique boards).  And one is just selectively disabled either permanently (much like Intel turns off cores), or by the board asserting a pin to flip it from utilizing one architecture to another. 

 

3 minutes ago, patrickjp93 said:

I'm afraid AT&T disagrees with you, and they handle secure communications for the U.S. military via FPGAs.

Yeah FPGA's are embedded in all sorts of communications equipment, for various functions that in the past would have been dealt with using custom ASICs with long development cycles and no in-service customizability.  Their use as business application software coprocessors is a very rare use of them.   Obviously not zero, but we're talking only thousands/tens of thousands of units compared to millions of FPGAs shipped each year.  In such applications, the micro may very well be mostly disabled and its really immaterial whether its ARM or x86.  In a typical FPGA embedded application, an embedded micro cuts down the overall BOM and reduces system cost.

[patrickjp93]

10 minutes ago, Mark77 said:

It could be built as both (so the vendor doesn't have to develop 3 unique boards).  And one is just selectively disabled either permanently (much like Intel turns off cores), or by the board asserting a pin to flip it from utilizing one architecture to another. 

 

Yeah FPGA's are embedded in all sorts of communications equipment, for various functions that in the past would have been dealt with using custom ASICs with long development cycles and no in-service customizability.  Their use as business application software coprocessors is a very rare use of them.   Obviously not zero, but we're talking only thousands/tens of thousands of units compared to millions of FPGAs shipped each year.  In such applications, the micro may very well be mostly disabled and its really immaterial whether its ARM or x86.  In a typical FPGA embedded application, an embedded micro cuts down the overall BOM and reduces system cost.

FPGAs are actually turning into the most popular specialist accelerators for encrypted communication, compression, and number crunching for analytics. It's one of the reasons Intel bought Altera. I honestly can't wait to see their 720mm sq. chip that's rumored to be coming. Xilinx can't compete with a 12TFlop FPGA. It just can't. If Intel supplants Xilinx from the high speed financial markets with their own FPGAs hooked up to 4+ 100Gbe optical NICs, Xilinx will go up in flames. The big accelerator chips sell for 80 grand a piece.