Forum: FPGA, VHDL & Co. 64/128 Bit Softcore


von A. F. (chefdesigner)


Lesenswert?

Generell bin ich nicht der Freund der Softcores, da klassische 
Softwareverarbeitung das FPGA-Silizium nicht sonderlich gut auslastet.

Ich sehe aber im Markt Anwendungsbedarf für 128Bit Applikationen, die 
sich mit aktuellen CPUs nicht machen lassen und auch nicht so schnell 
machen lassen werden.

Daher würde ich die Frage stellen, ob jemand weiss, ob und wo bereits 
64b/128b Softcores in der Entwicklung sind.

Oder: Welche Softcore liesse sich mit vertretbarem Aufwand 
hochskalieren?

von Peter II (Gast)


Lesenswert?

nur mal aus neugiert, wozu braucht man 128bit?

von ... (Gast)


Lesenswert?

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.

von A. F. (chefdesigner)


Lesenswert?

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.

von Peter II (Gast)


Lesenswert?

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.

von CPU-Neuling (Gast)


Lesenswert?

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

von Peter II (Gast)


Lesenswert?

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/?

von Purzel H. (hacky)


Lesenswert?

Bei Bedarf kann man sich ja auch selbst eine CPU aus ALU und dergleichen 
zusammenkloppen. So schwierig ist das nun auch wieder nicht.

von Andreas B. (andreas_b77)


Lesenswert?

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

Man kann RAMs auch parallel schalten...

von Strubi (Gast)


Lesenswert?

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.

von Stefan W. (wswbln)


Lesenswert?

Peter II schrieb:
> eine normale 32bit CPU kann auch mit 256bit auf dem Ram
> zugreifen.

...und was macht die 32-Bit ALU dann mit den 256 Bits im nächsten 
Taktzyklus???

EBEN!

von Peter II (Gast)


Lesenswert?

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.

von gfdgrt (Gast)


Lesenswert?

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

von Weltbester FPGA-Pongo (Gast)


Lesenswert?

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

Welche wären das?

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Strubi schrieb:
> Du kannst im Prinzip auch einen 8051 core mit speziellen
> n-bit-Instruktionen aufbohren.
Hört sich innovativ an: ein (in Zahlen 1) Akku mit 128 Bit Breite...

von Halbleitermann (Gast)


Lesenswert?

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

von K. L. (Gast)


Lesenswert?

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?

von A. F. (chefdesigner)


Lesenswert?

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?

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Andreas Fischer schrieb:
> Hättest Du ein Beispiel für einen solchen ASIC?
Sieh mal eine Grafikkarte aus dem höheren Preissegment genauer an. 
Andere verwenden übrigens genau solche Grafikkarten zum Rechnen mit 
großer Wortbreite...

Andreas Fischer schrieb:
> Ich sehe aber im Markt Anwendungsbedarf für 128Bit Applikationen, die
> sich mit aktuellen CPUs nicht machen lassen und auch nicht so schnell
> machen lassen werden.
Und auf was kommt es da an? Wortbreite oder Geschwindigkeit?
> Daher würde ich die Frage stellen, ob jemand weiss, ob und wo bereits
> 64b/128b Softcores in der Entwicklung sind
Softcores sind LANGSAM. Und was nützt mir eine langsame CPU mit breiten 
Registern?

von Fpgakuechle K. (Gast)


Lesenswert?

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,

von Experte (Gast)


Lesenswert?

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.

von K. L. (Gast)


Lesenswert?

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.

von Weltbester FPGA-Pongo (Gast)


Lesenswert?

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?

von Strubi (Gast)


Lesenswert?

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

von Jobst M. (jobstens-de)


Lesenswert?

Wer eine Rock-Stable 128-Bit Plattform sucht: AS/400. Seit 30 Jahren 128 
Bit.
(Damals noch über switching, mittlerweile echte Busbreite.)

;-)


Gruß

Jobst

von J. S. (engineer) Benutzerseite


Lesenswert?

> Experte schrieb:
>> Eher schon machen 64Bit und mehr breite HW-DSPs Sinn, wenn es um das
>> Verarbeiten von hochschnellen Signalen geht.

> Im Schnitt packt das VHDL rund 60% bis 90% dessen, was der Zynq kann,
> ich kann aber 20 Stück in den FPGA setzen.
hm, auch bei großen FPGAs bleibt nicht viel, wenn man die Resourcen 
durch 20 teilt. Da ist vielleicht eine CPU bei einer kleinen Architektur 
möglich, aber die dürfte kaum der Rechenleistung eines Zynq-ARM 
vergleichbar sein.

Allenfalls ist die Aufgabe so gestellt, daß ein ARM qualitativ 
unterfordert wäre, weil Teile der Funktionen brach lägen.

Oder es liegt an vielen Speicherzugriffen, die beim FPGA / ASIC im Ggs 
zum ARM wegfallen, weil Block-RAM verwendet wird.

von Fitzebutze (Gast)


Lesenswert?

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.

von S. R. (svenska)


Lesenswert?

Die Entwickler von RISC-V hatten anfangs als Spielerei in die Spec 
geschrieben, dass man neben 32 und 64 Bit auch eine 128 
Bit-Implementation machen könnte, wenn man denn wollte. Daraufhin wurden 
sie mit Anfragen so lange zugeschissen, bis sie das auch gemacht haben.

Solche Cores scheinen für gewisse Anwendungsfälle (d.h. Bignum, z.B. 
Krypto) hinreichend nützlich zu sein. Zumindest die 32- und 64-bittigen 
RISC V-Kerne werden von GCC schon unterstützt, ob das auch für 128 Bit 
zutrifft, weiß ich nicht.

Hat natürlich dann wieder nichts mit Multicore zu tun.

: Bearbeitet durch User
von J. S. (engineer) Benutzerseite


Lesenswert?

S. R. schrieb:
> Solche Cores scheinen für gewisse Anwendungsfälle (d.h. Bignum, z.B.
> Krypto) hinreichend nützlich zu sein.
Ja, das ist schon richtig. Hatte auch schon APPs, wo 64 gerade nicht 
ausreichend war. Ließ sich natürlich emulieren. Das Problem bei einem 
Softcore mit 128 Bit ist der Flächenverbrauch, wenn es dann nur partiell 
ausgenutzt wird. Daher sind die Einwände im thread absolut berechtigt.

von S. R. (svenska)


Lesenswert?

Jürgen S. schrieb:
> Das Problem bei einem Softcore mit 128 Bit ist der Flächenverbrauch,
> wenn es dann nur partiell ausgenutzt wird. Daher sind die Einwände im
> thread absolut berechtigt.

Ich kann nicht einschätzen, ob ein einfacher 128 Bit-Core so viel größer 
ist als ein komplexerer 32 Bit-Core ist, der (im Extremfall) in der 
gleichen Zeit das Fünffache an Befehlen ausführen können muss.

von Jobst M. (jobstens-de)


Lesenswert?

Vielleicht schafft man es ja, einen Prozessor zu bauen, der aus 4 32Bit 
Cores besteht, welche jeweils eigene Tasks bearbeiten und mit einem 
Befehl zu einem 1x 128Bit Core umgeschaltet werden können ... ;-)


Gruß

Jobst

von J. S. (engineer) Benutzerseite


Lesenswert?

Ich würde jetzt nicht einen einfachen mit einem komplizierten Core 
vergleichen, weil Komplexität im FPGA zu einerseits Flächenbedarf- aber 
auch Zeitbedarf führt, der sich in der maximalen Geschwindigkeit 
niederschlägt. Aus demselben Grund ist es auch schwierig, den Anstieg 
des Flächenbedarfs zu schätzen:

Da es Teile in einer Schaltung gibt, die von der Wortbreite unabhängig 
sind, dürfte eine 128er Architektur zunächst deutlich unter dem 
Doppelten liegen, was einer 64er-Architektur verbraucht. Da aber mit den 
Worten gerechnet wird, entstehen naturgemäß viel längere Pfade. Will man 
das klein halten, geht die fmax runter, ansonsten kostet es mehr FFs! 
Und trotzdem wird es dann noch so sein, dass das Tempo oft nicht 
ausreichend ist und man mit Architekturverdopplung arbeiten muss, um 
eine pipe schnell zu kriegen.  Es kann daher durchaus sein, dass die 
128er Architektur mehr, als doppelt so groß wird.

Die 4 32-bit-Systeme bringen da keine Lösung des Problems, weil sie a) 
schon mal pauschal 4x größer sind und b) noch lange keine 128 bit DSP-OP 
realisieren. Nehmen wir doch einfach mal die binomische Formel für 32Bit 
durch 16Bit mit H und L für zwei Faktoren realisiert:

ERG_32 = A_32 x B_32  -> wird zu:

ERG_32 = (AH_16 x 65536 + AL_16)  x  (BH_16 x 65536 + BL_16) ->

= 65536 x 65536 x (AH_16 x BH_16) + 65536 x (AH_16 x BL_16 + AL_16 x 
BH_16) + AL_16 * BL_16

Sind also 4 Multiplikationen + 1 Addition und 3 weitere implizite 
Additionen durch Zusammensetzen der Terme, was durch richtiges Speichern 
mit explizitem Carry erfolgen kann.

Sind also 4 parallele Schritte für jede CPU und einen weiteren wobei 3 
im Leerlauf sind.

In FPGAs braucht die MUL gfs 2 Taktzyklen, sind also 4x3 time slots bei 
denen 5 belegt sind. Na Danke.

Sowas baut man dann eher als schmale pipeline mit einer mitgeführten 
Potenz, die die Binärstelle steuert, hängt einen Takt für die 
Carry-Addition dran und schiebt es sequenziell durch, macht 3+1+(4-1) = 
7 Takte im FPGA mit einer Architektur.

Beim FPGA hängt man immer irgendwo an den DSP-Breiten fest. Der Spartan 
z.B. hat 18x25, da kann man sich abzählen, dass er für 36x36 bit noch 
einigermaßen hinkommt, die absolute Grenze sind 36x50, darüber wird es 
übel mit dem MUL-Verbrauch und dem Tempo. Ich kann mir schon vorstellen, 
dass das in einem ASIC super schnell arbeiten könnte.

von J. S. (engineer) Benutzerseite


Angehängte Dateien:

Lesenswert?

Ein Beispiel für den Flächenverbrauch an slices und MULs, zusätzlichen 
Registerstufen nach dem Multiplier, um 60 MHz zu erreichen.

von Strubi (Gast)


Lesenswert?

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

von J. S. (engineer) Benutzerseite


Lesenswert?

Strubi schrieb:

> Warte also noch auf das bahnbrechende Argument pro "generische 64 bit
> ALU".
Also 64 bit sind schon gebrauchsfähig, habe ich auch schon benutzt, aber 
128 sind halt ein bischen fett und schlecht zu handhaben, aber 
vielleicht kommt das ja noch in Zukunft mit neuen FPGAs. Jetzt, wo die 
Anforderungen steigen, wäre es eigentlich Zeit, mal breitere Multiplier 
einzubauen. Oder noch besser: Gleich eine mikroskopische FIR-Struktur 
mit durchtaktbarem 24Bit-Register und parallel ladbaren Multiplieren bei 
direkter Summierung, wo man einfach nur noch ein Datum reintaktet und im 
nächsten Takt direkt das Teilergebnis hat. Wäre für Videofilterung 
wichtig. So muss man doch einiges an resourcen verwenden und tricksen 
und oft Register spendieren, weil das Tempo nicht reicht.

Mit Bezug zur Grafik oben nochmal einige alternative Werte vom Artix7:

Bei 24x24 benötigt er nur 2 statt 4 Multiplier, dafür aber mehr FFs! 
Offenbar baut die Synthese (welche - anders als oben beim Spartan - auf 
"balanced" eingestellt sein kann, um das timing zu treffen) einige der 
Terme direkt in fabric auf! Konkret werden 176 FFs verbraten, dafür 
packt er standardmässig aber schon mal 80 MHz!

Die Geschichte setzt sich nach oben fort! Kontinuierlich eher weniger 
DSP-Elemente und irgendwann auch weniger FF-Bedarf. Für 128x128 werden 
1282 FFs benötigt, aber dann auch 64 MULs bei erreichbaren 80MHz und das 
jeweils aber mit nur einer FF-Stufe hinter den MULs. Die Architektur 
beim Artix ist also regelmäßig signifikant kleiner und hat trotzdem eine 
höhere Grenzfrequenz.

Mit "Performance Retiming" und 3 Stufen hinter den MULs, zum balancieren 
der FFs werden bei jetzt 1634 FFs immerhin 100 MHz erreicht, dann ist 
aber auch so ziemlich Schluss!

Der Artix hat aber im Vergleich zum Spartan schon ein enormes 
Preis-Leistungsverhältnis, muss man sagen. Meinen ersten Synthesizer den 
ich vor 10 Jahren für den Spartan3 gebaut habe, packt er für die 
Zielfrequenz von 50 MHz auf Wunsch OHNE einen einzigen DSP anzutasten! 
Bei der aktuellen Version mit 200MHz fallen alle DSPs für die langsamen 
Modulatoren (multi cycle constraint) unter den Teppich und er verbrät 
weniger als 300 DSP Elemente ( die beim Spartan der Anschlag waren) hat 
aber über 700 an Board! Wenn ich mir in Erinnerung rufe, was ich mich 
noch vor Jahren mit dem schnuddeligen Virtex abgequält habe :-)

Ich bin eigentlich ziemlich sicher, dass die künftigen FPGAs 
entsprechende DPSs drin haben werden, vielleicht auch mit dem Fokus 
Grafk und Video. Nett wären CUDA-ähnliche Strukturen, die man so 
programmieren könnte, wie Grafikkarten. Auch die CPUs im FPGA werden 
zulegen. 32 Bit sind eigentlich überholt :-)

von Strubi (Gast)


Lesenswert?

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

von T.U.Darmstadt (Gast)


Lesenswert?

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.

von Lars R. (lrs)


Lesenswert?

Thomas U. schrieb:
> Softcores
> sind ineffektiv und haben nur einen Zweck, nämlich die Entwicklung zu
> vereinfachen.

Gegenüber Hardcores (beliebiger Art) ist ein weiterer Vorteil die 
prinzipielle HW- und Hersteller-unabhängige Verwendbarkeit. Eine 
generische Beschreibung läuft auch in 50 Jahren noch auf den dann 
aktuell verfügbaren ICs.

Nur scheinbar hat daran leider niemand ein Interesse.

von René D. (Firma: www.dossmatik.de) (dose)


Lesenswert?

Lars R. schrieb:
> Thomas U. schrieb:
>> Softcores
>> sind ineffektiv und haben nur einen Zweck, nämlich die Entwicklung zu
>> vereinfachen.

ineffektiv ist nicht ganz richtig. Es lassen sich nicht die 
Geschwindigkeiten erreichen, die eine HW-CPU erreicht.

200MHz für einen Softcore ist kein Problem. Was viele CPUs durchaus auch 
im Regen stehen lässt.

von mads (Gast)


Lesenswert?

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.

von T.U.Darmstadt (Gast)


Lesenswert?


von Strubi (Gast)


Lesenswert?

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

von Jonas B. (jibi)


Lesenswert?

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

>EBEN!

Man merkt, du hast noch nie versucht eine CPU zu designen. Dann wüsstest 
du nämlich das Zugriffe auf den Ram ewwwwig dauern. Da hat die CPU 
dreimal die Pipeline geleert und neu befüllt.

Gruß Jonas

von T.U.Darmstadt (Gast)


Lesenswert?

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.

von Strubi (Gast)


Lesenswert?

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...

von Freak (Gast)


Lesenswert?

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.

von Jobst M. (jobstens-de)


Lesenswert?

Freak schrieb:
> Die sind doch Ergebnis einer Iteration.

Ja. Viele kleine Prozessoren in einem FPGA. Jeder rechnet an einem 
Pixel. Oder an einer Zeile. Ich denke einige hundert Einheiten bekommt 
man parallel.
Zumal man die Berechnung gleich in HW gießen kann.


Gruß

Jobst

: Bearbeitet durch User
von Strubi (Gast)


Lesenswert?

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?

von Strubi (Gast)


Lesenswert?

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

Rot13:
[ Frv Rcfvyba xyrvare Ahyy ]

von J. S. (engineer) Benutzerseite


Lesenswert?

Jonas B. schrieb:
>>...und was macht die 32-Bit ALU dann mit den 256 Bits im nächsten
>>Taktzyklus???
> Man merkt, du hast noch nie versucht eine CPU zu designen. Dann wüsstest
> du nämlich das Zugriffe auf den Ram ewwwwig dauern.

Das gilt aber nur, wenn man einen klassischen RAM-Zugriff der CPU auf 
externe RAMs fokussiert. Im FPGA kann man das so lösen, dass internes 
RAM adressiert wird. Dann wird die CPU der Limiter sein, weil die RAMs 
schnell genug sind. Aus einem BRAM kriege ich völlig unregistriert Daten 
jederzeit mit 50MHz raus, bei schnellen FPGAs mit 100MHz. Das ist die 
soft-CPU langsamer.

Anders herum betrachtet bekommt man mit einer 32Bit-Emulation bei 
echten RAM--Zugriffen mehr davon, um die Terme zu handhaben und wäre 
mit einer breiten soft-CPU schneller.

von A. F. (chefdesigner)


Lesenswert?

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.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.