64/128 Bit Softcore

nur mal aus neugiert, wozu braucht man 128bit?

Ich will ja nicht sinnlos rumnörgeln, aber moderne CPUs haben 128 Bit 
breite Register (die SSE Register). Ich glaub kaum das ein Softcore in 
einem FPGA, der annähernd soviel kostet wie ein Quad Core von AMD oder 
Intel, auch nur annähernd die gleiche Rechenleistung erzielen könnte.

Klar, was es zu kaufen gibt, ist ohnehin billiger, als der Nachbau. aber 
es gibt eben die Möglichkeit, die Architektur zu manipulieren. Z.B. kann 
man bei Auslieferung der Hardware einen Softcore branden und Daten 
Verschlüsseln, sodass eine bestimmte Software nur auf einem einzigen 
System laufen kann. Damit wird dem SW-Klau vorgebeugt.

Wofür 128 Bit? Je mehr Bitbreite der Bus, desto mehr Daten bekommt man 
gleichzeitig über den Bus ins RAM. Es gibt IO-lastige Applikationen, die 
man nur im FPGA machen kann. Der Schritt hin zur Software ist mit 
weniger Latenz belastet.

Auch einfache Rechenoprationen sind effektiver: Um einn unskalierten 
Ausgang einer FFT zu normalisieren, musste ich z.B. 34 Bit qudrarieren. 
Das geht in 64er Architekturen nicht mehr rein. Wenn ich immer noch 
einen Schritt zum Skalieren brauche, dauert der Transport über den 
Prozessor eben nicht 1x4096 Takte sonden 2x4096 Takte. Macht 40us mehr 
Bedarf.

>Quad Core
Dass Softcores mit steigender Größe im Vergleich immer 
unwirtschaftlicher werden, ist klar. Cores im FPGA müssen aber sehr 
leistungsfähig sein, damit es von der Systemplanung her Sinn mach. 
Irgendwelche Sonderbedingungen müssen exisitieren. Wenn der Bedarf für 
dieses maximale Timing nicht da wäre, könnte man solche Operationen 
wieder in die billigeren hardDSPs auslagern.

Andreas Fischer schrieb:
> Wofür 128 Bit? Je mehr Bitbreite der Bus, desto mehr Daten bekommt man
> gleichzeitig über den Bus ins RAM. Es gibt IO-lastige Applikationen, die
> man nur im FPGA machen kann. Der Schritt hin zur Software ist mit
> weniger Latenz belastet.

nicht wirklich, eine normale 32bit CPU kann auch mit 256bit auf dem Ram 
zugreifen. Grafigkarten haben auch eine 512bit Speicheranbindung und 
dort ist meines Wissens keine 512Bit CPU drin.

> mit 256bit auf dem Ram zugreifen
Welche RAMs haben denn 256bit???

CPU-Neuling schrieb:
>> mit 256bit auf dem Ram zugreifen
> Welche RAMs haben denn 256bit???


Typ GDDR3
Taktfrequenz 1632 MHz
Speicheranbindung 512 Bit

http://www.alternate.de/html/product/PNY/Quadro_FX5800/574426/?

Hi,

Du kannst im Prinzip auch einen 8051 core mit speziellen 
n-bit-Instruktionen aufbohren. Stichwort: SIMD oder Vektor-Operationen. 
Am kniffligsten wird vermutlich, die Pipeline so zu designen, dass diese 
Instruktionen in (bevorzugt) Hardwareschleifen in einem Takt 
abgearbeitet werden.
Da würde ich mir doch eher die Berechnungen in einen separaten 
Coprozessor verfrachten, da das Aufbohren so einige Probleme schaffen 
könnte.

Stefan Wimmer schrieb:
> und was macht die 32-Bit ALU dann mit den 256 Bits im nächsten
> Taktzyklus???

sich den Cache füllen. Damit gibt es beim nächsten zugriff keine 
Wartezeit mehr.

Oder mehr als eine ALU(komponente) beschäftigen.

Andreas Fischer schrieb:
> Ich sehe aber im Markt Anwendungsbedarf für 128Bit Applikationen,

Welche wären das?

Gibt es in ASICs schon geraume Zeit. Die Prozessorhersteller haben das 
wohl nur deshalb nicht drin, weil es keiner nachfragt. (?)

Siebzehn mal Fuenfzehn schrieb:
> Bei Bedarf kann man sich ja auch selbst eine CPU aus ALU und dergleichen
> zusammenkloppen. So schwierig ist das nun auch wieder nicht.

Schon mal gemacht?

Halbleitermann schrieb:
> Gibt es in ASICs schon geraume Zeit. Die Prozessorhersteller haben das
> wohl nur deshalb nicht drin, weil es keiner nachfragt. (?)
Hättest Du ein Beispiel für einen solchen ASIC?

Andreas Fischer schrieb:

> Wofür 128 Bit? Je mehr Bitbreite der Bus, desto mehr Daten bekommt man
> gleichzeitig über den Bus ins RAM. Es gibt IO-lastige Applikationen, die
> man nur im FPGA machen kann. Der Schritt hin zur Software ist mit
> weniger Latenz belastet.

Dafür braucht es aber keinen128 bit cpu core sondern einen entsprechend 
breiten Memoryxontroller. Dafür gibt es schon einiges am Markt.

Wobei solche IO-lastigen Applikationen selten sind. Mir ist noch keine 
Applikation untergekommen die ADU mit mehr als 16bit Quantisierung 
nutzen.
Für mehrkanalanwendungen z.B Phased Array oder CT gruppiert man eben 
einige Kanale passend zum Ram-interface und instanziert die Blöcke 
parallel.


> Auch einfache Rechenoprationen sind effektiver: Um einn unskalierten
> Ausgang einer FFT zu normalisieren, musste ich z.B. 34 Bit qudrarieren.
> Das geht in 64er Architekturen nicht mehr rein. Wenn ich immer noch
> einen Schritt zum Skalieren brauche, dauert der Transport über den
> Prozessor eben nicht 1x4096 Takte sonden 2x4096 Takte. Macht 40us mehr
> Bedarf.

Hast du mal ein Beispiel wo eine 34bit FFT nötig ist? Wo liegen die 
Vorteile - bessere frequenzauflösung - im sub-ppm Bereich? Feinere 
Betragsquantisierung - aber der Großteil davon ist eh rauschen?

MfG,

Bist du sicher, dass Deine APP nur mit einem 128 bitter zu machen ist? 
Softcores machen bekanntlich nur wirklich Sinn, wenn sie wenig und 
Langsames zu rechnen haben, weil sie de facto schon sequenziell an die 
Aufgabe herangehen. Ich meine, dass das geringfügige Aufblähen des Codes 
gegenüber dem Rechnen mit einer 32Bit-CPU nicht sonderlich ins Gewicht 
fallen sollte, es sei denn, es ginge jetzt zufällig um 2-3 Takte mehr 
oder weniger. Es hat schon seinen Grund, warum die keiner baut: Weil's 
keiner braucht :-)

Eher schon machen 64Bit und mehr breite HW-DSPs Sinn, wenn es um das 
Verarbeiten von hochschnellen Signalen geht. Einmal als VHDL erarbeitet, 
kann man die ja flux in einen ASIC backen. CERN hat da immer mal wieder 
was im Gepäck, um die beschleunigten Teilchen erfassen und prozessieren 
zu können.

Experte schrieb:
> Eher schon machen 64Bit und mehr breite HW-DSPs Sinn, wenn es um das
> Verarbeiten von hochschnellen Signalen geht. Einmal als VHDL erarbeitet,
> kann man die ja flux in einen ASIC backen.

So ist es. Wir haben den Tipp dankend aufgenommen:
Beitrag "Re: Projekt-Idee 64-Bit RISC CPU in VHDL"

Waren noch 2 Studenten mit dran und ja, er wandert nach erfolgreichem 
Prototyping in einen ASIC rein und zwar an einer Stelle, wo nur für 
einen Chip Platz ist.

Beispiel: Im Vergleich zum derzeit schnellsten Zynq läuft mein RS1-96 
Core für jeweils optimierte Taktfrequenzen auf rund einem Drittel der 
Geschwindigkeit, mit der er z.B. FSMs abarbeiten kann.

Er schafft aber bei komplexer Rechnung mit mehr als 36 Bit Auflösung 
schon 40% ... 160% an Datendurchsatzes gegenüber dem Zynq - kommt so auf 
45% der Leistung.

Bei komplexen Rechnungen mit Iterationen wie z.B. Mandelbrot mit 
floating point, die mit den vollen 96 Bit fixed point gerechnet werden, 
sind bis zum Fünffachen des Datendurchsatzes gegenüber dem Zynq möglich, 
er ist mit an anderen Operationen zusammen also schon fast gleichwertig.

Im Schnitt packt das VHDL rund 60% bis 90% dessen, was der Zynq kann, 
ich kann aber 20 Stück in den FPGA setzen.

Für die ASIC-lösung erwarten wir eine Taktfrequenz von 1500 MHz 
gegenüber 300 MHz. Da ist dann einer alleine schon 3x schneller.

So jetzt sortieren wir mal:


> in einen ASIC rein und zwar an einer Stelle, wo nur für
> einen Chip Platz ist.
Es geht also um den Platz. Wenn dort ein ASIC hingeht, der Software 
verarbeiten kann, dann muss dort wenigstens noch ein RAM und ein FLASH 
hin. Oder sitzt das auch alles im ASIC?

> Beispiel: Im Vergleich zum derzeit schnellsten Zynq läuft mein RS1-96
> Core für jeweils optimierte Taktfrequenzen auf rund einem Drittel der
> Geschwindigkeit, mit der er z.B. FSMs abarbeiten kann.
Der Vergleich bezieht sich also auf eine CPU im FPGA. Was ist mit einer 
normalen CPU?

> Bei komplexen Rechnungen mit Iterationen ...
> ... also schon fast gleichwertig.
Also so schnell wie eine SOPC-Plattform. Ein echte CPU wäre also immer 
noch einen Faktor 2 schenller.

> Im Schnitt packt das VHDL rund 60% bis 90% dessen, was der Zynq kann,
> ich kann aber 20 Stück in den FPGA setzen.
Kannst Du auch 20 Stück dieser Prozessoren in den ASIC setzen? Woher 
bekommen die ihre Daten? Alle brauchen Flash und RAM.

> Für die ASIC-lösung erwarten wir eine Taktfrequenz von 1500 MHz
> gegenüber 300 MHz. Da ist dann einer alleine schon 3x schneller.
1500 / 300 = Faktor 3 ?

Mich beschäftigt Folgendes:

Ein CPU, egal wie sie aussieht, setzt jemand ein, wenn er komplizierte 
Sachen machen will, die als Programm laufen. Wie aber wird das Programm 
erzeugt? Gibt es ein C-Programm das durch einen Compiler geht, oder ist 
es Assembler-Code?

Naja. Ich melde mal auch etwas Skepsis an. Butter bei die Fische:

1) Welches FPGA?
2) CPU sauber verifiziert?
3) Was ist neu?
4) Debug-Interface (In Circuit Emulation)?


> Waren noch 2 Studenten mit dran und ja, er wandert nach erfolgreichem
> Prototyping in einen ASIC rein und zwar an einer Stelle, wo nur für
> einen Chip Platz ist.
>

Das mit den Studenten spricht erfahrungsgemäss leider nicht grade für 
einen Chip...

>
> Für die ASIC-lösung erwarten wir eine Taktfrequenz von 1500 MHz
> gegenüber 300 MHz. Da ist dann einer alleine schon 3x schneller.

Das Ziel kommt mir ein bisschen hochgesteckt vor.
Aber wenn Ihr das hinkriegt und eine Bude auftut, werdet ihr bestimmt 
von NXP gekauft:-)

Was die Tools angeht: Es gibt auch durchaus Ansätze, die ohne C-Compiler 
gut benutzbar sind, wie z.B. Motorola 56k-Klone als DSP-Coprozessoren, 
oder die gut lesbare Blackfin-Assembler-Syntax mit 
Vektor/Parallel-Operationen. Wenn einer gut bison kann, kriegt er nen 
Gnu Assembler-Port in 3-4 Monaten hin.

Der letzte Knackpunkt aber ist die Frage: Ist es ein akademisches 
Spielwiesenprojekt, oder soll es ein richtiger Systemprozessor werden, 
von dem man auch in Zukunft noch was hören wird?
Statistisch: Es gibt nämlich doch eine Menge me2-Projekte, die nach 
anfänglicher Euphorie schnell wieder der Verwaisung unterliegen, weil 
die Komplexität einer Industrielösung unterschätzt wurde.

Gruss,

- Strubi

Die AS/400 war ne geile Kiste, neben der PDP-11. Wenn die Dinger nur 
nicht so viel Strom gefressen hätten... (sonst stünden sie noch in 
meinem alten Kinderzimmer :-) )

Zum Thema "Vollpacken" von FPGAs mit CPU-Kernen kann man sich etwas an 
den klassischen alternativen Ansätzen orientieren:
- Parallax-Architektur
- Chucks Forth Prozessoren

Obwohl theoretisch diese Kerne immer n-fach in ein großes FPGA 
reinpassen, manifestiert sich spätestens im P&R das Problem mit einer 
Gatter-Verstopfung, typischerweise beim shared memory oder den Register 
Files. Mit alternativen Ansätzen a la J1 und andere Forth-Prozessoren 
und einer unabhängigen Programm-Pipe geht das bis zu einem gewissen 
Punkt gut, bei registerbasierten CPUs wie wir sie gewohnt sind 
(GCC-Support) ist bald mal Schluß.
Leider sind in der Industrie die Forth-Sachen nie so recht angekommen, 
ein robuster C-Compiler gehört heute einfach zum Standard.
Einen annehmbaren Kompromiß für "home made" multi core kriegt man mit 
der ZPU hin, das ist so ein Zwischending zwischen reiner Stack-Maschine 
und wanderndem Register-Window. Mit distributed RAM als Stack/Register 
file sieht das dann so aus, daß jede CPU für sich recht kompakte Logik 
alloziert und die Memory-Interfaces entlastet werden können.
Dementsprechend laufen aber auch keine großen Programme auf den 
Nebenkernen. Bisher habe ich noch keine sinnvolle Anwendung für mehr als 
drei Kerne gefunden (ein Master, zwei Slave threads).
Gegenüber einem ARM mit Linux macht das sowieso keinen Sinn. Nur, wenn 
man ein beweisbares/stromsparendes Design haben möchte/muß.
Für richtig dedizierte Rechenpower sollte man sich lieber an den 
parallelen Shader-Units von nvidia orientieren. Alles andere klingt mir 
- verzeiht mir meine ehrliche Meinung - nach akademischer Verträumtheit.

Moin,

habe in der Vergangenheit mal mit manuell generierten Vektor-ALUs 
herumgespielt, die in die Richtung der Blackfin-Vektoreinheiten gehen, 
allerdings mit etwas mehr Genauigkeit, Anwendung: 
Matrizenmultiplikation.
Da sieht man eigentlich ziemlich dasselbe, was die Xilinx-Corengen-Tools 
für MAC-Units auch ausspucken: Beim Kaskadieren der DSP-Primitiven kommt 
gezwungenermassen eine Pipeline-Stage dazu, wenn die Fmax noch gelten 
soll.
Bei meiner Anwendung waren das schon 5 Takte Pipeline delay pro 
Vektor-MAC. Das beisst sich dann prinzipiell mit einer generischen CPU, 
bei der die Daten irgendwo aus dem RAM kommen, da hat man einfach die 
ALU-Pipeline nie voll. Das kann man allerdings a la Blackfin 
parallelisieren, wird aber auf dem FPGA eine wüste Geschichte mit einer 
Menge Hazard-Szenarien, die man einem Anwender nicht zumuten kann. 
Geschweige denn demjenigen, der die RTL für den GCC entwerfen muss...
Auf einem ASIC mag das schliesslich mit viel Arbeit lösbar sein, aber 
Hazard-Logik auf dem FPGA neigt fast immer zu lokaler 
Resourcen-Verstopfung, sprich: bremst.
Deswegen kann ich der Idee mit der fetten ALU-Bitbreite unter dem Aspekt 
des generischen Cores nicht so viel abgewinnen.
Der pragmatische Highspeed-Ansatz sieht also nach wie vor so aus, dass 
der generische Kern nur die DMA-Datenschleuder anschmeisst, die die 
Rohdaten in die Vector-MAC des unabhängigen Coprozessors schleust (und 
hinten wieder raus).
Beim generischen "inline"-Ansatz, d.h. Berechnung im Programmcode, macht 
es IMHO mehr Sinn, sich Carry/Adder-Chains sequentiell aufzubauen, wie 
Jürgen es oben skizziert hat.
Warte also noch auf das bahnbrechende Argument pro "generische 64 bit 
ALU". Denn flexibel gestalten kann man den highspeed-Ansatz mit 
SIMD-Mikrocode auch.

Grüsse,

- Strubi

Moin,

mit generisch meinte ich eben eigentlich den Einsatz als ALU in einer 
CPU.
Aber mal von der anderen Seite aufzäunen: Die Frage, warum sich fast 
alle Hersteller immer bei den 18 Bit breiten DSP-Slices (MAC-Units) 
finden, kommt ja immer wieder auf.
Im Zusammenhang mit den BRAM-Schnittstellen ist das wohl nach wie vor 
der beste generische Kompromiss. Warum das überhaupt was mit dem Memory 
zu tun haben sollte, kann man natürlich in den Raum werfen, aber das 
klassische Schema sollte für sich sprechen:

1

[Peripheriegerät] --Rohdatenstrom--> [Interface] -> [FIFO Memory(DMA)] ->

2

[DSP unit]

Wenn man da die Datenworte auf 32 bzw die MAC auf 64 oder 96 bit 
aufbohrt (mehr macht IMHO keinen Sinn für 'double'-Emulation), kommen 
halt die weiteren Register (Pipeline-Stages) hinzu, an denen man von der 
Kaskadierung der Multiplier her schon nicht vorbeikommt. Aber noch kein 
Problem, die Daten strömen clocksynchron durch, und der Delay tut hier 
nicht weh.
In der CPU allerdings schon, da sich selbige ja die Daten erst besorgen 
oder evaluieren muss.

D.h. um maximale Effizient wie oben zu kriegen, brauchts eine 
1-Zyklen-Parallel-Op für den typischen FIR wie:

1

loop(z0) {  ; Hardware loop register 0

2

    a1 += r0 * r1 ¦ r0 = [i0]++ ¦ r1 = [i1]++;

3

}

4

; TODO: a1 evaluieren

Wenn die Bitbreite nicht ausreicht, muss man die MUL/MAC softwaremässig 
kaskadieren und verbrät weitere Zyklen, da ist die breite ALU (in HW) 
wieder besser dran. Innerhalb der Schleife kriegt man dann auch 
"1-Zyklen"-Performance. Aber am Ende muss die Pipeline gespült werden, 
um mit a1 weiter was im Programmcode machen zu können.
Und da beisst der Delay. Wer also jetzt generische Operationen in der 
CPU (noch per bare metal assembler-code) anstrebt, muss einen gehörigen 
gordischen Knoten lösen. Und da sich schlussendlich nach meinem 
Feststellen fast immer der Bandbreitenstau an den Memory-Interfaces 
ergibt, ist IMHO eine generische Lösung als Systemprozessor mit allen 
Programmierschmankerl bei der Bitbreite fast nicht praktikabel, 
geschweige denn vom Aufwand, den ein vernünftiger C-Compiler mit sich 
bringt.
Die Entwicklung der ALU-Sektion alleine ist also nicht das Problem, und 
auch Register lassen sich intern mit Aufbohren des Befehlssatzes 
kaskadieren. Auf der ZPU(next generation) habe ich den 'DSP-Mode' so 
implementiert, dass obige MAC-Ops inline im Code per Mikrocode-Emulation 
abspulen. Ein Escape-Bit im Opcode schaltet sozusagen den Befehlssatz 
um.
Das resultiert in einem (anwendungsspezifischen) Mikrocode-Applet, 
welches intern die 32 bit breiten Register-shadows jeweils zu 64-Bit 
Breite zusammenhängt. Also bisschen a la "Trick Jobst single core", oder 
wie es der Blackfin mit seinen 16-Bit-Registerhälften macht. Ineffizient 
wird das bloss bei "Immediate loads", die Daten müssen also parallel aus 
dem 32 Bit-BRAM kommen.
Nur generisch ist das Ganze kaum, der Mikrocode wird als langes Bitfeld 
von parallelisierten/verzögerten Opcodes ausgespuckt, ein Assembler wäre 
schon zu aufwendig, und GCC-RTL bekäme die 1-Zyklen-Optimierung nicht 
mal hin.
Es läuft also immer öfter auf hybriden Ansatz raus, bei dem Pipeline, 
Operationsablauf und ALU wie auch zugehöriger Default-Mikrocode für den 
jeweiligen Zweck aus der HDL generiert wird, und der C-Code bloss 
Applets lädt/aufruft.
D.h. damit lässt sich kein Systemprozessor konzipieren, den die 
Community brauchen kann (Kennt noch jemand den HiCoVec?).
Lasse mich dennoch immer gern überraschen. Ist nur etwas still geworden 
um den oben angekündigten 64-Bit-RISC...

Grüsse,

- Strubi

Allein schon, wenn ich versuche, dem Sermon zu folgen, gelange ich zu 
der Erkenntnis, dass das für den Benutzer nicht machbar ist. Softcores 
sind ineffektiv und haben nur einen Zweck, nämlich die Entwicklung zu 
vereinfachen. Alles, was der Compiler nicht automatisch erledigen kann, 
bleibt dem User und konterkariert die gesamte Idee!

Dann lieber in C bauen und in VHDL übersetzen lassen.

Thomas U. schrieb:
> Dann lieber in C bauen und in VHDL übersetzen lassen.

Schon mal ausprobiert?
Ich halte davon gar nichts. Bei 3x3 Filterkernel kann die HLS von Xilinx 
schon nicht mehr mithalten.

Auch sind Softcores nicht ineffektiv, wir haben ein DSP design im FPGA 
laufen, wo es sonst keine Lösung gibt mit ARM, etc. Kann dazu aber nicht 
mehr sagen.
Es sind hier halt oft Nischenanwendungen, wo es nur wenige Spezialisten 
gibt.
Dort ist auch sehr viel Interesse vorhanden, z.b. für gewisse 
Sicherheitsanforderungen, wo ein ARM nicht in Frage kommt.

Also dann, wer mag: Eine 64 Bit FPU:

https://www.ra.informatik.tu-darmstadt.de/fileadmin/user_upload/Group_RA/main/documents/Dokumenation_FPU.pdf

Thomas U. schrieb:
> Also dann, wer mag: Eine 64 Bit FPU:

Jo, sieht nach einer ordentlichen Arbeit aus.
Aber gerade auf einem FPGA bevorzuge ich wegen verschiedener Faktoren 
fixed point. Gerade bei Fehlerabschätzung ziemlich essentiell. Macht 
also IMHO mehr Sinn, mehr Bits zu spendieren und stattdessen die 
Konversion double <-> FixedPoint nur an den Schnittstellen (d.h. dem 
Interface zu C) vorzunehmen.
Mich würde mal interessieren, was die Xilinx HLS aus einem in C 
geschriebenem Algo mit double-Werten so an Logik zusammenkaskadiert...
Ansonsten sehe ich softcores mit DSP-Erweiterungen als sehr effektiv für 
den jeweiligen Zweck an.
Als konkretes Anwendungsbeispiel: MJPEG-Streamer für HD video.

- Strubi

Strubi schrieb:

> Mich würde mal interessieren, was die Xilinx HLS aus einem in C
> geschriebenem Algo mit double-Werten so an Logik zusammenkaskadiert...

Ich habe mich ein wenig mit der HLS befasst und sage mal so: Ich bin 
nicht gerade weggerissen. Manche Sachen kann man sich auf diese Weise 
sehr einfach formulieren und Zeit sparen, aber es sind die einfachen 
FPGA-Algorithmen und -abläufe, die sich gut umsetzen lassen. Bei allen 
FPGA-spezifischen Dingen wie pipelining, Parallelisierung, muss dem tool 
unter die Arme gegriffen werden.

Auch habe ich den Eindruck, dass der Resourcenverbrauch höher ist - 
gerade bei mathematischen Rechnungen. Offenbar hat er Probleme, die 
ranges zu handhaben und kleinzukürzen. Ist aber Vermutung.

Thomas U. schrieb:
> FPGA-Algorithmen und -abläufe, die sich gut umsetzen lassen. Bei allen
> FPGA-spezifischen Dingen wie pipelining, Parallelisierung, muss dem tool
> unter die Arme gegriffen werden.

Da C jetzt nicht wirklich optimal zur Beschreibung von HW ist, bist du 
doch sehr schnell wieder beim SystemC++-Ansatz und schreibst dir deine 
eigenen Fixpoint-Klassen, wenn du volle Kontrolle über deine 
DSP-Arithmetik haben willst. Richtig?
Solange man sich nicht auf experimentellem Wege Wissen über die Funktion 
einer Blackbox-Toolchain aneignen muss, ist das alles ok :-)
Und natürlich um eben mal ein paar float-ops zu beschleunigen auch.
Aber schon bei Matrizenkram stelle ich mir das schwieriger vor. Spart 
man sich da wirklich die Zeit?
Gerate weil generische CPUs immer flotter werden, muss das FPGA immer 
mehr mit dediziert optimierten Verarbeitungspipes kontern (oder mit 
einem echten ALU-Novum).
Und die HDL-Apfelmännchen-Messedemos kommen langsam in die Jahre...

Strubi schrieb:
> Und die HDL-Apfelmännchen-Messedemos kommen langsam in die Jahre...

Welche Vorteil hätten den FPGAs ausgerechnet bei den Appelmännern? Die 
sind doch Ergebnis einer Iteration. Da muss doch der FPGA auch mehrfach 
rechnen, bis er ein Ergebnis hat. Sicher nix wo der seine Stärken 
ausspielen könnte, oder?

Oder ließen sich mit so hochaufgelösten Cores die Rechnungen schneller 
machen? Ich meine, eine gute CPU rennt heute auf immerhin 4GHz.

Moin,

mit den nvidia-Shadern konnte man vor Jahren sowas schon in Realtime 
machen. Lag nahe, das im FPGA nachzubauen, aber da kommt die Anspielung 
ins Spiel: nach Jahren Messepräsenz ist der Coolness-Faktor in Bezug auf 
HLS etwas verflogen. Oder war er jemals grösser Epsilon?

Nachtrag: Bevor jemand auf den Gedanken kommt: Bitte keine 
Mathematikerwitze nachlegen :-)

Rot13:
[ Frv Rcfvyba xyrvare Ahyy ]

Ich komme nochmals zurück auf meine damals gestellte Frage. Interessant, 
was es inzwischen als Antworten gab. Das Thema ist jetzt auch wieder 
aktuell, weil wir im Begriff sind, Grafikchips, die auf 128 Bit 
angefahren werden, anzusprechen.