Intel bringt Xeon CPU mit integriertem FPGA

FPGA-Phreak schrieb im Beitrag #3813839:
> Intel hat im Sommer heimlich still und leise eine neue Xeon-CPU
> vorgestellt, in die ein FPGA integriert ist.
Der umgekehrte Weg ist ja schon ein URALTER Zopf aus dem letzten 
Jahrtausend: FPGAs mit CPU(s).

> Wo seht ihr da Anwendungen?
Das hängt davon ab, wie Intel den Zugang zu diesem FPGA gestaltet. Wenn 
da jeder eine Entwicklungsumgebung herunterladen kann, dann wird es 
schnell still um das FPGA.

Dieser Satz hier ohne ein Wort zur konkreten Anwendung ist bloßes 
Altweibergeschwätz:

1

to turbo-charge their critical algorithms.” Intel estimates that the 

2

Xeon+FPGA will see massive performance boosts in the 20x range

3

(for code executed on the FPGA instead of a conventional x86 CPU

"conventional x86" ist damit ein 8086 gemeint?

Auf jeden Fall ist ein dedizierter ASIC immer schneller als ein für die 
gleiche Anwendung konfiguriertes FPGA.

> Wo seht ihr da Anwendungen?
Ich könnte mir gut vorstellen, dass die Filmindustrie an so einer 
(schnell umkonfigurierbaren) Lösung Interesse haben könnte.

Dieser Artikel gab ein bisschen Einblick in die Anwendung um 
Suchmaschinen zu beschleunigen (erwähnt werden Bing und Baidu):
http://www.eetimes.com/document.asp?doc_id=1323500

Direkt neu ist die Idee nicht. Gabs schon öfter, aber mit im Vergleich 
dazu eher schwacher CPU. Also FPGA mit Hilfsmotor.

Neu hier ist, dass es eine Highend-CPU ist. Die aber statt einer GPU ein 
FPGA drauf hat. Es gibt derzeit einen Trend, eine Onchip-GPU aka APU 
nicht bloss für Grafik, sondern auch für andere Jobs zu nutzen. Speziell 
AMD ist da rührig und integriert diese APU stärker und dichter in die 
Anwendungsprogrammierung. Und nun kommt eben von Intel ein FPGA in 
ähnlicher Rolle wie AMDs APU.

Der Unterschied zu reinen FPGAs (oder gar ASICs) ist auch, dass man kein 
spezielles Board für eine FPGA/ASIC-Lösung eines anspruchsvollen 
Problems braucht. Sondern die gute Infrastruktur normaler PC- und 
Serverboards nutzen kann, Betriebssystem inklusive. Das FPGA ist dabei 
nur für einen speziellen Teil der Gesamtlösung zuständig, jenen, den man 
mit CPU Programmierung schlecht hinbekmmt.

Da wir jetzt schon viele Cores haben aber die Software im Schnitt sich 
immer noch recht schwer tut diese effektiv zu nutzen, scheint mir die 
Zurückhaltung von Intel beim Marketing des "FPGA-Coprozessors" weise.

Bis in jedem Allerweltsrechner so ein FPGA sinnvoll genutzt und es 
deswegen auch gerne bezahlt wird, ist es noch ein langer Weg, vielleicht 
ist es aber auch ein absterbender Ast der Rechnerevolution, so wie 
vieles andere.

Denn das Silizium eines FPGA effektiv zu nutzen kostet einen 
qualifizierten Ingenieur, der zudem teuter als ein 
Allerweltssoftwareingenieur ist, ein vielfaches an Zeit.

Man kann nur auf die automatische, superschnelle und hocheffektive 
Parallelisierung von single Threaded Software und Algorithmen ins FPGA 
hoffen.

Und dann schaue man sich nur einmal an was eine Arbeit und Rechenzeit es 
bedeutet die Logik ins FPGA zu übersetzen, zu platzieren und zu routen 
und dabei das Timing sicherzustellen.

Um hier nicht unheimlich viel Power des FPGA-Siliziums zu verschwenden 
was es unwirtschaftlicher aber auch "einfacher" in der Handhabung machen 
würde, damit dieser Kompromiss unter dem Strich ein positiver ist muss 
noch so etwas wie ein Wunder geschehen, denn es konkurrieren GPU's und 
Multimediaacceleratoren, SIMD, u.v.a. mit, schon lange erfolgreich.

Raymund H. schrieb:
> Denn das Silizium eines FPGA effektiv zu nutzen kostet einen
> qualifizierten Ingenieur, der zudem teuter als ein
> Allerweltssoftwareingenieur ist, ein vielfaches an Zeit.

Soweit musst du gar nicht gehen, schreibst du ja selber:

Raymund H. schrieb:
> Da wir jetzt schon viele Cores haben aber die Software im Schnitt sich
> immer noch recht schwer tut diese effektiv zu nutzen

Ein qualifizierter Ingenieur, der es schafft das Silizium eines modernen 
Intelprozessors effektiv zu nutzen, ist auch teuer und benötigt viel 
Zeit.

Raymund H. schrieb:
> Man kann nur auf die automatische, superschnelle und hocheffektive
> Parallelisierung von single Threaded Software und Algorithmen ins FPGA
> hoffen.

Genau das machen "Allerweltssoftwareingenieure" seit den 80er Jahren. 
Und sie werden weiter vergeblich hoffen.

Ein kleiner Lichtblick: Ich kenne aktuell in meinem Umfeld einen 
Informatik Studenten an der ETH Zürich, der wird schon im 1. Semester 
mit Konzepten zu paralleler Programmierung geprügelt :-)

Raymund H. schrieb:
> damit dieser Kompromiss unter dem Strich ein positiver ist muss
> noch so etwas wie ein Wunder geschehen, denn es konkurrieren GPU's und
> Multimediaacceleratoren, SIMD, u.v.a. mit, schon lange erfolgreich.

Auch nur wenn sie von qualifizierten Ingenieuren benutzt werden. Das 
Wunder von dem du sprichst könnte OpenCL sein, wir werden sehen wie sich 
das entwickelt und ob OpenCL sich in der Praxis überhaupt für FPGAs 
eignet (Altera versucht es ja schon, keine eigene Erfahrung).
Die anderen von dir genannten techniken werden auch weiterhin auf dem 
Markt bestehen bleiben.
(Math Star mit dem field programmable object array [FPOA] ist ja tod)

Christoph Z. schrieb:
> Raymund H. schrieb:
>> Da wir jetzt schon viele Cores haben aber die Software im Schnitt sich
>> immer noch recht schwer tut diese effektiv zu nutzen
>
> Ein qualifizierter Ingenieur, der es schafft das Silizium eines modernen
> Intelprozessors effektiv zu nutzen, ist auch teuer und benötigt viel
> Zeit.

Ingenieure sind verschieden Teuer, ergo unterscheiden sie sich in ihrem 
Nutzen, zumindest dem Vermeintlichem für die die das Geld geben. Darf 
man das sagen?

Nun, ich will/wollte darauf hinaus dass ein Ingenieur (eher ein Team) 
der/das einen Intel Prozessor mit FPGA effektiv nutzt, teurer (und evtl. 
auch gestresster) als einer der "nur" SSE4, und X64 nutzt ist, denn da 
ist ja vieles durch Compiler automatisiert.

Der Markt ist gnadenlos und "rechnet" das gegen den Nutzen den es ihm 
tatsächlich bringt (und natürlich auch den "Bling"- oder "Buzz"-Faktor) 
und tut sich wohl schwer mit dem FPGA + Intelx64-Chip.

> Raymund H. schrieb:
>> Man kann nur auf die automatische, superschnelle und hocheffektive
>> Parallelisierung von single Threaded Software und Algorithmen ins FPGA
>> hoffen.
>
> Genau das machen "Allerweltssoftwareingenieure" seit den 80er Jahren.
> Und sie werden weiter vergeblich hoffen.

Ganz vergeblich nicht. denke ich, denn schaut man zurück dann hielt die 
x86-Architektur ja schon sehr lange durch, hat sich in kleinen Schritten 
zu dem was wir heute haben evolviert, wo wir doch mal so ein RISC-Hype 
hatten und der böse CISC x 86 immer gedisst wurde, an allem schlechten 
in der IT Schuld war, auch daran dass W95 so oft abgestürzt ist.

Genau da vermute ich auch das größte Potential: Die Architektur nur so 
weit ändern dass die meisten Ingenieure immer noch effektiv damit 
umgehen können aber es dabei schaffen trotzdem mehr Leistung aus dem 
Silizium was man fertigen kann zu holen.

Was soll auch anderes passieren?

> Ein kleiner Lichtblick: Ich kenne aktuell in meinem Umfeld einen
> Informatik Studenten an der ETH Zürich, der wird schon im 1. Semester
> mit Konzepten zu paralleler Programmierung geprügelt :-)

Nun, man könnte meinen das Problem ist zumindest erkannt.
Doch der Mensch hat grob zwei Extreme mit Problemen umzugehen:

Vermeidung (Flucht)
Lösung (Kampf)

Praktisch ist es meist irgend was dazwischen, also eine Vereinfachung 
des Problems um nicht so viel Kämpfen zu müssen.

> Auch nur wenn sie von qualifizierten Ingenieuren benutzt werden. Das
> Wunder von dem du sprichst könnte OpenCL sein, wir werden sehen wie sich
> das entwickelt und ob OpenCL sich in der Praxis überhaupt für FPGAs
> eignet (Altera versucht es ja schon, keine eigene Erfahrung).
> Die anderen von dir genannten techniken werden auch weiterhin auf dem
> Markt bestehen bleiben.

Ich weiß nicht so recht. Parallelität ist so schlecht skalierbar, so 
störrisch, das Puzzle ist so schwer zusammenzusetzen.
Der Wunsch ist klar, siehe oben, doch warten wir es ab, bleibt auf jeden 
Fall spannend.

> (Math Star mit dem field programmable object array [FPOA] ist ja tod)

Ich denke so Sachen und auch "Systolic Arrays" o.ä. leben in der Nische 
und im Geschlossenen weiter, es gibt bestimmt ein paar praktische 
Anwendungen in Silizium auf der Welt, muss ja keiner wissen.

Was ich mir bei Altera und dem C-V mit Arm schon gedacht hab ist dass da 
Arm auch einen gewissen Einfluss bei der Entwicklung hatte.

Ich denke das HPS mit dem ARM ist keine alleinige 
Altera-Eigenentnwicklung, logisch, zumindest der ARM Core schon mal 
nicht, vieles der Peripherie ist auch aus dem ARM-IP Programm, was die 
FPGA-spezifischeren Dinge angeht mag, wie gesagt, Arm da ja einen Teil 
geleistet oder sogar vorgearbeitet haben, vielleicht hat man sich was 
davon versprochen.
Vielleicht hatte Arm sogar mal Pläne selbst ein FPGA (mit arm natürlich) 
zu machen, in der Embedded Welt vielleicht viel eher mit Erfolgsaussicht 
als im PC-x86 Markt, durch die andere Anwendungsstruktur und die anderen 
Ingenieurstypen.

Doch dann haben die vielleicht gemerkt was die FPGA-Player in die 
EDA-Software stecken müssen.

Doch Intel hat das gesehen und wollte auch was tun, wenn es auch nur 
erstmal zum  "Probieren" ist.

Egal, genug spekuliert.

Virenprogger schrieb:
> Cool, kann man dann neuerdings Rechner auch per Malware-FPGA-Configfile
> ins Hardware-Jenseits schicken?

Jede Zelle ein Ringoszillator und das Licht geht aus, oder an, ich 
schätze ich weiss nicht so genau.

Das ist aber in der Tat eine interessante Idee auf die du mich da 
bringst:

Die CPU hat eine MMU und ein Betriebssystem.

Wie wird das FPGA vor Schadcode geschützt? Und wie wird es zwischen den 
Prozessen aufgeteilt? Wie werden die gegeneinander abgeschirmt?

Wie macht man Kontextumschaltung?

Der Kontext eines FPGA's hat viele Größenordungen mehr Bits als die paar 
Prozessorregister. Das braucht Zeit und Energie.

Braucht das FPGA dann einen User- und Supervisor-Mode?
Was darf man im User Mode das FPGA noch tun lassen?

Kann man überhaupt sinnvoll per FPGA-Betriebssytem überwachen ob 
Schadcode eine extreme Verlustleistung / Schaltaktivität (asynchron) 
evtl. mit der Folge der Zerstörung oder Fehlfunktion von Digitallogik 
durch Übersprechen bewirkt?

Braucht das FPGA auch eine art Bitstreampolizei und -Feuerwehr?

Doch so weit muss es überhaupt erst mal kommen, bei den größeren 
Problemen die ich schon aufgezählt habe.

Raymund H. schrieb:
> Bis in jedem Allerweltsrechner so ein FPGA sinnvoll genutzt und es
> deswegen auch gerne bezahlt wird, ist es noch ein langer Weg, vielleicht
> ist es aber auch ein absterbender Ast der Rechnerevolution, so wie
> vieles andere.

Ein breiter Massenmarkt wird das wahrscheinlich nicht. Allein schon 
deshalb, weil bei ausreichend Masse spezifische Prozessorerweiterungen 
für die typischerweise damit gelösten Aufgaben auftauchen werden. Die 
dann natürlich wesentlich effizienter sind als ein FPGA. Die FPGA-Phase 
wäre für solche Fälle nur eine Art Prototypenstadium auf dem Weg zur 
eigentlichen Lösung.

> Und dann schaue man sich nur einmal an was eine Arbeit und Rechenzeit es
> bedeutet die Logik ins FPGA zu übersetzen, zu platzieren und zu routen
> und dabei das Timing sicherzustellen.

Das gilt aber nicht nur für FPGAs in CPUs, sondern für FPGAs allgemein. 
Und es lässt sich kaum übersehen, dass FPGAs tatsächlich eingesetzt 
werden, obwohl der Aufwand nicht unbeträchtlich ist. ;-)

Allerdings kann man die Probleme, die man mit FPGAs löst, vereinfachend 
in zwei Klassen einteilen, die ich mal hardware-bezogene Probleme und 
algorithmische Probleme nennen will.

Die hardware-bezogenen Probleme setzen anwendungsspezifische Interfaces 
voraus, vulgo Pins mit entsprechender Programmierung. Es versteht sich 
von selbst, dass Intels Ansatz hier nicht weiterhilft.

Bei den algorithmischen Problemen geht es um spezielle Aufgaben, die man 
ebensogut mit normalen PC-Programmen lösen könnte, wenn die dafür nur 
schnell genug wären. Sowas wie Bitcoin-Mining beispielsweise. Genau da 
setzt Intels Ansatz an.

Bisher konnte man, um FPGAs für solchen algorithmischen Aufgaben 
einzusetzen, ein FPGA über PCIe anbinden. Dabei ist allerdings die 
Kooperation mit der CPU eher lose, mit entsprechen hohen Latenzen.
Am meisten Sinn ergibt eine Integration in die CPU deshalb, wenn das 
FPGA deutlich enger mit der CPU kooperiert, als das mit PCIe möglich 
ist.

Beispielsweise indem Caches konstruktiv berücksichtigt statt leergeräumt 
werden und indem man verwendete Speicheradressen nicht erst umständlich 
durch den Wolf der Speicherverwaltung drehen muss, bevor man sie dem 
FPGA vorwerfen kann.

Ich wäre freilich auch nicht erstaunt, wenn diese Entwicklung nicht 
allein eine Idee von Intel war. Sondern bestimmte mit viel Geld 
ausgestattete Nischenmärkte ein Interesse an durchsatzstarken Lösungen 
haben, mit denen man sich in relativ kurzer Zeit neuen Problemen 
widmen kann.

Raymund H. schrieb:
>> Raymund H. schrieb:
>>> Man kann nur auf die automatische, superschnelle und hocheffektive
>>> Parallelisierung von single Threaded Software und Algorithmen ins FPGA
>>> hoffen.
>>
>> Genau das machen "Allerweltssoftwareingenieure" seit den 80er Jahren.
>> Und sie werden weiter vergeblich hoffen.
>
> Ganz vergeblich nicht. denke ich, denn schaut man zurück dann hielt die
> x86-Architektur ja schon sehr lange durch, hat sich in kleinen Schritten
> zu dem was wir heute haben evolviert, wo wir doch mal so ein RISC-Hype
> hatten und der böse CISC x 86 immer gedisst wurde, an allem schlechten
> in der IT Schuld war, auch daran dass W95 so oft abgestürzt ist.
>
> Genau da vermute ich auch das größte Potential: Die Architektur nur so
> weit ändern dass die meisten Ingenieure immer noch effektiv damit
> umgehen können aber es dabei schaffen trotzdem mehr Leistung aus dem
> Silizium was man fertigen kann zu holen.

Seit ich diesen Artikel gelesen habe (und mir der Kopf gehörig geraucht 
hat danach) habe ich die Hoffnung definitv aufgegeben:
http://www.heise.de/artikel-archiv/ct/2014/12/176_Matrix-reloaded

Ja, es sind alles Compiler Tricks, aber man muss sie richtig einsetzen 
und den richtigen Compiler zur Hand haben. Und sein Problem überhaupt 
überblicken, was im Artikel eine "simple" Matrix Multiplikation ist.

Raymund H. schrieb:
>> Ein qualifizierter Ingenieur, der es schafft das Silizium eines modernen
>> Intelprozessors effektiv zu nutzen, ist auch teuer und benötigt viel
>> Zeit.
[...]
> Nun, ich will/wollte darauf hinaus dass ein Ingenieur (eher ein Team)
> der/das einen Intel Prozessor mit FPGA effektiv nutzt, teurer (und evtl.
> auch gestresster) als einer der "nur" SSE4, und X64 nutzt ist, denn da
> ist ja vieles durch Compiler automatisiert.

Ja, kann ich dich voll unterstützen. Ein Team aus x86 Experten wird viel 
effizienter sein als ein Team aus x86 und FPGA Experten (Bei gleichen 
kosten oder Anzahl Personen)

@ Logische Wahrheit

Sicher doch.

Bedenke aber auch dass Prozessoren heute auf automatische Optimierung 
des Codes hin entwickelt werden (Out of order execution, automatische 
paralellisierung), das macht die "Handoptimierung" im Vergleich zur 
automatischen evtl. deutlich unwirtschaftlicher und die 
Wahrscheinlichkeit dass die Handoptimierung nix ist außer 
Zeitverschwendung steigt.

Und das ist es am Ende: Ein Kompromiss der sich wirtschaftlich trägt.

Fpga Kuechle schrieb:

Sagte ich handoptimierung ist generell sinnlos?

Das beispiel mit der dft ist nicht so glücklich, denn der handoptimierer 
weiss nicht wie groß der cache gerade ist auf dem es läuft.

Außerdem gibt es wohl schon compiler die die zugriffsmuster auf die 
sin/cos tabelle erkennen und u.u. Numerisch äquivalente optimierungen 
machen die so eine tabelle vierteln.

Der schritt für den compiler dann die phasen sukzessiv per 
matrixmultiplikation zu berechnen und damit aus dem cache zu nehmen ist 
nicht mehr groß, wenn sie auch nicht numerisch äquivalent wären und 
explizit enabled würden müssten.

Doch das problem der "skalierbarkeit" auf die maschine die den code 
ausführt bleibt, weswegen ich denke diese optimierungen werden evtl. zum 
teil ins betriebssystem und den prozessor wandern.

Betriebssysteme könnten ja eine neue innovationswelle nach html5 
gebrauchen.

Christoph Z. schrieb:
> Ja, kann ich dich voll unterstützen. Ein Team aus x86 Experten wird viel
> effizienter sein als ein Team aus x86 und FPGA Experten (Bei gleichen
> kosten oder Anzahl Personen)

Ich nehme an, Du meinst, "so ein Team wird in der gleichen Zeit mehr 
nutzbare Funktion auswerfen" denn (Arbeits)effizienz/Teameffizienz ist 
ja noch mal was ganz anderes.

Ich stimme Dir zu - aber der Vergleich ist auf jedes Projekt anwendbar, 
wo Neuentwickung (Hardwareerzeugung) mit der Nutzung bereits vorhandener 
Hardware (Softwareerzeugung) verglichen wird. Diese Frage, ob ein FPGA 
sinnvoller ist oder DSP/CPU sind meines Erachtens genrell Unfug, weil 
das Ergebnis der Betrachtung schon vorher feststeht, da nur Themen 
verglichen werden können, die beide leisten und da ist kaufen immer 
besser, als bauen :-)

Die Fragestellung ist doch eigentlich eine ganz andere:

a) Wann brauche ich die spätere Anpassbarkeit einer Hardware, um auf 
high speed / low level-Niveau z.B. bugs beseitigen oder Adaptionen an 
Unbekanntes erzeugen zu können, weil es eben in SW nicht gehen wird

b) In welchen Fällen brauche ich die parallele Architektur von FPGAs, 
weil ich eine Rechenpipeline bauen will, die viele sequenzielle 
Berechnungen für viele time slots oder Kanäle durcführen soll

Wenn diese Bedingungen erfüllt sind, scheiden DSPs und MCUs aus und es 
wird ein FPGA, auch wenn ein DSP es von der Funktion her grundsätzlich 
leisten könnte.

Was ich mich hier nun frage;

- Wie umfangreich wird dieser FPGA?
- Wie ist er an die CPU angebunden?
- Wie komme ich an den dran?

Eine Option für ein solches System wäre z.B. das system monitoring in 
der Entwicklung.

Auch die Verschlüsselung eines Busses aus Sicherheitsgründen wäre 
denkbar.

Ein effektives pipeline prozessing ist nur machbar, wenn das Ding 
eigenes DP-RAM hat und auch eine parallele Anbindung an den RAM-Speicher 
des Systems.
Wenn der FPGA nur zwischen Peripherie und CPU sitzt und mitguckt, ist da 
wenig zu tun.
Der FPGA braucht eigenes DDR-RAM und viel BRAM, zudem breiten parallelen 
64 Bit Zugriff auf die CPU-Register.

Wenn es nur um ein COPRO System geht, wo FPGA und Intel kommunitzieren, 
müsste da nichts Neues her, das wird heute schon gebaut.

Kest schrieb:
> FPGA braucht keinen eigenen Speicher -- wozu auch, wenn man den
> Arbeitsspeicher
In dem Punkt muss ich wiedersprechen. Wenn Du eine vollständige 
virtuelle pipeline bauen willst, und nur damit bekommst Du einen 
maximalen Datendurchsatz in der kompletten Schaltungslogig, weil anders 
als in sequenziellen Systemen nicht jeweils ein Elemetent eine Funktion 
ausführt, sondern zu jedem Zeitpunkt jedes Element seine Funktion 
vollführt, brauchst Du eine kontinuierliches mapping aller Parameter und 
"Variablen" = Zustandspeicher und dies geht nur über dual port RAMs die 
beide von beiden Seiten mit jedem Takt beschrieben werden. Wollte man 
das in sequenzieller Speichertechnolgie lösen braucht es die 2fache 
Bandbreite für jede geschriebene Variable und auch bei einem 64Bit Bus 
ist da schnell Schluss.

Andi F. schrieb:
> Kann es sein, Intel hier über das Hintertürchen in den FPGA-Markt
> eindringen möchte?

Das tut Intel doch schon in dem sie angeblich für Altera Silizium 
liefern.

Vielliecht war Intel neidisch dass Altera so schöne Dual-Core Arms mit 
FPGA von ihnen bekommt und will auch "mitspielen"?

Im massen PC-Markt scheint mir das kaum lohnend, der Embedded Markt ist 
da viel dankbarer.

Lattice User schrieb:
> Schwachsinn. Intel hat eine ARM Architecture Lizense und könnte
> jederzeit mitspielen. Nur lohnt es sich für Intel einfach nicht.

Schwachsinn zurück, sie bräuchten eine "Altera Architecture License" und 
die ganze Software oder sie müssten es neu machen.

Selbst ein Schwergewicht im Halbleitermarkt wie Intel sieht es wohl als 
nicht lohnenswert an so ein riesiges Investment mit bescheidenen 
Aussichten zu tun.

Eher kauft Intel Altera.


Da der Intel FPGA nicht breit vermarktet wird ist er wohl ein 
Nischenprodukt für Facebook, Goolge, Serverfarmen, Cisco, Netzwerk, 
Telecom etc. oder so etwas in der Art, für einen kleinen Markt weit 
abseits des Mainstreampcs, denn wie schon gesagt täte der Massenmarkt 
sich sehr schwer dieses Silizium effektiv zu nutzen.

Lattice User schrieb:
> Das ist jetzt aber eine andere Aussage wie deine vorige:

Nun, da Intel nicht von FPGA+x86 lebt, ist es für sie (noch) ein Spiel. 
Natürlich kann sich daraus etwas entwickeln wie Erfahrungen/Erkenntnisse 
für zukünftige Entscheidungen.

Lattice User schrieb:
> Nur hat das nichts mit der Zielgruppe von existierenden FPGA SoCs zu
> tun.

Sag ich doch.

Noch mal ein paar Informationen zu den Forschungsarbeiten von Microsoft:
http://www.eetimes.com/document.asp?doc_id=1324372&_mc=NL_EET_EDT_EET_programmablelogicdesignline_20141023&cid=NL_EET_EDT_EET_programmablelogicdesignline_20141023&elq=386258bf50fa48028ce09c89e2630c98&elqCampaignId=19852

Entgegen meiner Annahme arbeiten sie gar nicht mit Kombie-Prozessoren:

1

Microsoft has not evaluated CPUs with FPGA co-processors linked on a

2

coherent interconnect with shared memory, an approach companies such as 

3

Intel and IBM are promoting. “But that’s a whole different programming 

4

model, and it’s not clear how you share data and control structures -- 

5

I don’t think anyone has figured that out yet.”

Christoph Z. schrieb:
> Microsoft has not evaluated CPUs with FPGA co-processors linked on a
> coherent interconnect with shared memory

Sieht aus als mache es mehr Sinn das FPGA in den Netzwerkchip zu packen. 
Ein hardened Crypto Acellerator + FPGA Netzwerk/Switch/Router chip oder 
so was in der Art.

Gibts das nicht schon?

Ich weiss einfach nicht recht mit dem FPGA + x86 im Allerweltsrechner 
was das soll.

Da hat man ja offensichtliche netzwerkbezogene Durchsatzprobleme aber 
der Markt ist zu klein für den Netzwerbeschleunigerchip?

"Bisher konnte man, um FPGAs für solchen algorithmischen Aufgaben
einzusetzen, ein FPGA über PCIe anbinden. Dabei ist allerdings die
Kooperation mit der CPU eher lose, mit entsprechen hohen Latenzen.
Am meisten Sinn ergibt eine Integration in die CPU deshalb, wenn das
FPGA deutlich enger mit der CPU kooperiert, als das mit PCIe möglich
ist."

Bei einem Serverboard:

-freut man sich über jede auf dem Board integrierte Hardware da 
PCIe-Slots gerade in 1HE-Chassis wertvolle Mangelware sind

-flucht man über jede integrierte Hardware weil sie im Defektfall nicht 
trivial austauschbar ist* und, auch wenn nicht genutzt und abgeschaltet 
wird,immer ein gewisses Stör-und Sicherheitsrisiko darstellt.


*bei höheren Xeon-Modellen kostet es mitunter mehr eine CPU als ein 
Board zu tauschen daher gilt da dasselbe...