mikrocontroller.net

Forum: FPGA, VHDL & Co. Implementierungsfrage VHDL


Autor: Mampf F. (mampf) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guten Mittag,

ich bin dabei einige Algorithmen auf einen FPGA zu portieren, der einige 
Rechenoberationen auf 384Bit Zahlen durchführt (div, add, sub, compare).

Jetzt stellt sich mir folgende Frage:

Das Rechnen mit so großen Zahlen ist vergleichsweise langsam ... ein 
64Bit div ohne Pipeline schafft es auf 10MHz. Sub, Add, Compare (384Bit) 
auf 35MHz rum.

Ich kann pipelinen, was aber Logik und Register kostet - oder ich mache 
die Pipeline des Dividierers kürzer und takte eine Statemaschine einfach 
auf 25MHz und bin damit zufrieden und synchronisiere die Prozesse mit 
unterschiedlichen Clocks per Handshaking.

Was denkt ihr dazu?

Viele Grüße,
Mampf

: Bearbeitet durch User
Autor: Duke Scarring (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Mampf F. schrieb:
> Was denkt ihr dazu?
Das an dem Algorithmus was komisch ist. Wofür braucht man denn 
praktischerweise diese Größenordnung und gleichzeitig diese Auflösung?

Klingt nach einem zahlentheoretischen Problem...

Autor: schiebepeter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Brauchst du eine Pipeline, oder kannst du nicht einfach die ALU so 
gestalten, dass sie N Takte braucht, um eine Operation durchzuführen? 
Für alle deine Operationen gibt es spezialisierte Algorithmen, die in N 
Takten M Bit berechnen können, und das auch sehr sparsam bzgl. Logik.

Habe ich vor kurzem erfolgreich implementiert: "n-cycle restoring 
division algorithm"

Autor: Jürgen S. (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Duke Scarring schrieb:
> Das an dem Algorithmus was komisch ist. Wofür braucht man denn
> praktischerweise diese Größenordnung und gleichzeitig diese Auflösung?

Grafikkarten-Design-Prototype

Autor: TriHexagon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jürgen S. schrieb:
> Duke Scarring schrieb:
>> Das an dem Algorithmus was komisch ist. Wofür braucht man denn
>> praktischerweise diese Größenordnung und gleichzeitig diese Auflösung?
>
> Grafikkarten-Design-Prototype

Was soll das für eine Grafikkarte sein, die mit 384Bit Zahlen rechnen 
muss also SISD? Was willst du denn darstellen, dass du einen solch 
großen Zahlenraum brauchst. Wahrscheinlich ist Gleitkommaarithmetik hier 
die bessere Wahl. Oder gehts hier doch um SIMD-Operationen?

Autor: Mampf F. (mampf) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
TriHexagon schrieb:
> Was soll das für eine Grafikkarte sein, die mit 384Bit Zahlen rechnen
> muss also SISD? Was willst du denn darstellen, dass du einen solch
> großen Zahlenraum brauchst. Wahrscheinlich ist Gleitkommaarithmetik hier
> die bessere Wahl. Oder gehts hier doch um SIMD-Operationen?

Nichts dergleichen - ist für eine Crypto-Währung ein Teil der Signierung 
von Transaktionen. Die haben aufgrund eines Bugs einen etwas 
rechenintensiven work-around, womit zB Cortex M3 so seine Probleme hat.

Ich versuche quasi den Brute-Force Algorithmus auf das FPGA auszulagern.

Autor: Mampf F. (mampf) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
schiebepeter schrieb:
> Habe ich vor kurzem erfolgreich implementiert: "n-cycle restoring
> division algorithm"

Das hab ich schon gemacht, weil die IPs wie lpm_div nur bis 64Bit gehen 
:)

Für Add, Sub und Compare hab ich das nicht ausprobiert.

25MHz Clock sind dafür gut genug - allerdings frage ich mich, ob der 
Resourcenverbrauch geringer sein könnte, wenn ich IPs verwende.

Autor: Blechbieger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für ungenutzte Logik und Register gibt es kein Geld zurück. Falls du sie 
nicht für anderes brauchst oder Energie sparen musst solltest du sie 
nutzen.

Autor: Tobias F. (analrapist)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Mampf F. schrieb:
> Was denkt ihr dazu?

Dass du hier absoluten Käse baust.

Zunächst lässt der Wunsch 384bit Divs für Crypto zu machen bei mir 
Alarmglocken schrillen. Das heißt üblicherweise dass der OP 
Restklassenringe nicht verstanden hat.

Dann ist es so, dass professionelle FPGA Designs praktisch nie mit 25MHz 
laufen. Es mag Ausnahmen geben aber üblicherweise baut man seine 
Pipelinestrukturen so, dass man deutlich höher takten kann und dann 
höheren Durchsatz erreicht.

Wenn du, wie du sagst, den Durchsatz nicht brauchst, wäre vielleicht 
eine CPU Implementierung die bessere Wahl. Überleg mal welche CPU du für 
den Preis des FPGAs kaufen kannst. Vermutlich ist da ein ganzer 
Single-Board PC drinn. Da kannst dann deinen Algorithmus mit Phython 
runterschreiben und es ist trotzdem noch schneller..

Autor: Mampf F. (mampf) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tobias F. schrieb:
> Mampf F. schrieb:
>> Was denkt ihr dazu?
>
> Dass du hier absoluten Käse baust.


> Zunächst lässt der Wunsch 384bit Divs für Crypto zu machen bei mir
> Alarmglocken schrillen. Das heißt üblicherweise dass der OP
> Restklassenringe nicht verstanden hat.

Bitte erleuchte mich, wie man die Konvertierung einer 384Bit Binärzahl 
in eine Zahl zur Basis 27 mit Restklassenringe umrechnet.

> Dann ist es so, dass professionelle FPGA Designs praktisch nie mit 25MHz
> laufen. Es mag Ausnahmen geben aber üblicherweise baut man seine
> Pipelinestrukturen so, dass man deutlich höher takten kann und dann
> höheren Durchsatz erreicht.

Das war ja die Frage ... Und deine Antwort dazu lautet: Bau Pipeline und 
verwende nicht Statemaschines mit niedrigerem Takt.

Im Falle der 384Bit division (durch 27) muss ich das 64Bit-weise machen, 
weil die IP nicht mehr unterstützt und d.h. die Pipeline bringt mir 
keine Vorteile, da ich sie nicht füllen kann. Ich muss für jeden 
weiteren Rechenschritt x Taktzyklen auf das Ergebnis warten.

Daher die Frage, ob ich auf Ästhetik verzichte und pragmatisch die 
Statemaschines gleich langsamer takten lasse.

> Wenn du, wie du sagst, den Durchsatz nicht brauchst, wäre vielleicht
> eine CPU Implementierung die bessere Wahl. Überleg mal welche CPU du für
> den Preis des FPGAs kaufen kannst. Vermutlich ist da ein ganzer
> Single-Board PC drinn. Da kannst dann deinen Algorithmus mit Phython
> runterschreiben und es ist trotzdem noch schneller..

Erzähl doch nicht so einen Quark ... Erstens gibt es nichts, was mit 
Python schneller ist und zweitens handelt es sich bei der 
Zahlen-Konvertierung nur um einen kleiner Teil des Ganzen.

Ein anderer Teil ist ein SHA3 u.a. ... Da macht das schon Sinn.


Aber das ist meine eigene Schuld, ich hätte mehr auf die eigentliche 
Anwendung eingehen sollen als nur generisch zu fragen ... sorry dafür

: Bearbeitet durch User
Autor: Tobias F. (analrapist)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Mampf F. schrieb:
> Bitte erleuchte mich, wie man die Konvertierung einer 384Bit Binärzahl
> in eine Zahl zur Basis 27 mit Restklassenringe umrechnet.

Wie gesagt, solche Fragen sind eben ein Zeichen für Verständnisprobleme. 
Es muss bei dir nicht so sein und ohne genauer zu wissen was du vor hast 
kann man nur davon ausgehen dass du Recht hast. Sollte nur ein 
Denkanstoß für dich sein, vielleicht kannst du es ja auch anders 
rechnen.

Mampf F. schrieb:
> Im Falle der 384Bit division (durch 27) muss ich das 64Bit-weise machen,
> weil die IP nicht mehr unterstützt und d.h. die Pipeline bringt mir
> keine Vorteile, da ich sie nicht füllen kann. Ich muss für jeden
> weiteren Rechenschritt x Taktzyklen auf das Ergebnis warten.

Was? Du kannst einen 384 Bit Teiler bauen, dem du in jedem Takt eine 384 
Bit Zahl geben kannst. Wo die 64 Bit jetzt herkommen ist mir unklar. 
Wenn du nur eine Division berechnen willst und deren Rechenzeit egal ist 
könntest du das auch mit einer Art Softcore rechnen, wäre vermutlich 
kleiner.

Mampf F. schrieb:
> Ich muss für jeden weiteren Rechenschritt x Taktzyklen auf das Ergebnis
> warten.

Das heißt du hast eine Rückkopplung über den Teiler, weswegen du keine 
Pipeline voll bekommst, die Rechenzeit ist aber wichtig? Da hast du dir 
Arschkarte gezogen und wirst ordentlich Logik investieren müssen. 
Trotzdem kann eine gut balancierte Pipeline hier Zeit sparen weil du 
dadurch das Eintakten an zwei Stellen sparst. Müsste man genauer 
analysieren.

Mampf F. schrieb:
> Erzähl doch nicht so einen Quark ... Erstens gibt es nichts, was mit
> Python schneller ist

Glaub mir, eine moderne CPU ist verdammt schnell, wenn man sie richtig 
programmiert. Aber wie das im speziellen Fall hier ist, keine Ahnung.

Mampf F. schrieb:
> Ein anderer Teil ist ein SHA3 u.a. ... Da macht das schon Sinn.

Mag sein. Rechne die Konvertierung doch in einem Softcore? Oder auf 
einem Zynq.

Mampf F. schrieb:
> Aber das ist meine eigene Schuld, ich hätte mehr auf die eigentliche
> Anwendung eingehen sollen als nur generisch zu fragen ... sorry dafür

Ja. Du kannst nicht erwarten hier konkrete Architekturtipps zu bekommen 
wenn du nicht sagst was die Rahmenbedingungen sind. Man kann da nur mit 
"hast du schon in Richtung XY gedacht" helfen.

Autor: TriHexagon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mampf F. schrieb:
> TriHexagon schrieb:
>> Was soll das für eine Grafikkarte sein, die mit 384Bit Zahlen rechnen
>> muss also SISD? Was willst du denn darstellen, dass du einen solch
>> großen Zahlenraum brauchst. Wahrscheinlich ist Gleitkommaarithmetik hier
>> die bessere Wahl. Oder gehts hier doch um SIMD-Operationen?
>
> Nichts dergleichen - ist für eine Crypto-Währung ein Teil der Signierung
> von Transaktionen. Die haben aufgrund eines Bugs einen etwas
> rechenintensiven work-around, womit zB Cortex M3 so seine Probleme hat.

Achso, sehe auch gerade, dass die Antwort nicht von dir stammte.

Tobias F. schrieb:
> Mampf F. schrieb:
>> Erzähl doch nicht so einen Quark ... Erstens gibt es nichts, was mit
>> Python schneller ist
>
> Glaub mir, eine moderne CPU ist verdammt schnell, wenn man sie richtig
> programmiert. Aber wie das im speziellen Fall hier ist, keine Ahnung.

Genau. Arithmetik ist nicht gerade eine Stärke von FPGAs. Es sei denn es 
handelt sich um irgendeine Spezial-Arithmetik, die sich schlecht mit den 
Befehlsatz der CPU abbilden lässt, oder man kann es massiv 
parallelisieren. Ansonsten gewinnt immer die CPU (von hand optimierte 
ALU vs. Look-Up-Table-Grab). So wie sich das hier anhört, ist das nix 
für einen FPGA.

Autor: Tim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
für mich klingt das wie eine typische, in sich abgeschlossene Aufgabe 
für Vivado HLS

Algorithmus in C niederschreiben und dann am Fläche-Speed-Regler drehen.

25 MHz klingt mir super langsam. Was ist das überhaupt für ein FPGA? 
Spartan3?

Autor: Jürgen S. (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tobias F. schrieb:
> Dann ist es so, dass professionelle FPGA Designs praktisch nie mit 25MHz
> laufen.
Kommt drauf an. Wenn man mit günstigen FPGAs fette MULs braucht, ist es 
effektiver, die langsamer laufen zu lassen und 2 parallel zu nehmen, 
statt mit FFs zu versuchen, die Arithmetik aufzubrechen und zu piplinen, 
was ohnehin nicht beliebig geht, wenn es um einen MUL geht:

Mampf F. schrieb:
> Rechenoberationen auf 384Bit
In ASICs sind hohe Bitbreiten für Zwischenrechnungen schon mal nötig und 
auch gut implementierbar. Will man das im FPGA-Prototypen, sollte man 
Zeit mitbringen und keine zu hohen Anforderungen an die 
Verarbeitungsgeschwindigkeit haben:

Eine 64Bit Multiplikation zu 128Bit am Ausgang packt ein ASICs in der 
Spar-Technologie laut Spec des Herstellers bei voller Taktfrequenz und 
Registrierung, also im Loop, mit einer Frequenz von mindestens 2GHz. 
Eine zweistufige MUL als Zwischenergebnis mit Addition immerhin noch mit 
1GHz.
Das sind garantierte Werte für extreme Bedingungen. Als industrial in 
schneller Technologie ist ein Faktor 2 drin. Die MULs dürften also im 
Bereich 300ps arbeiten.

Dasselbe in einem langsamen/schnellen Kintex kommt auf (ausprobiert) 
100MHz/145MHz im zweistufigen System. Verbraucht werden 16 DSP-Elemente. 
Ich stelle hiermit den Antrag, dass die DSP-Elemente von 18x25 auf 25x33 
oder besser gleich 33x33 hochgesetzt werden. Wobei: Laut inoffiziellen 
Aussagen bekommen wir ja bald Altera FPGAs von Intel mit abgespeckten 
I3/5/7 als hardcore mit 64Bit float.


Tim schrieb:
> für mich klingt das wie eine typische, in sich abgeschlossene Aufgabe
> für Vivado HLS
> Algorithmus in C niederschreiben und dann am Fläche-Speed-Regler drehen.
Auch mit noch so vielen FFs kriegt man die Mathematik nicht überwunden, 
wenn sehr breite Multiplikationen auf kleine DSPs verteilt und dann 
Teilterme addiert werden müssen. Da gibt es limits.

Autor: Mampf F. (mampf) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank für euren Input!

Die ersten Ergebnisse sind ...

384Bit Binär Umwandlung in eine 81 stellige Zahl zur Basis 27 dauert 
240µs - (6000 Taktzyklen @ 25MHz).

Der SHA3 ist dafür auf einem FPGA deutlich schneller als auf einem 
Cortex M3 mit 72MHz, d.h. fällt kaum noch ins Gewicht.

Im Gesamten wird die FPGA-Rechnerei um Faktor 70-75 schneller sein.

Ich denke, damit lässt sich der Aufwand schon rechtfertigen :)

Implementiert hab ich es jetzt tatsächlich so, dass die Basis-Umwandlung 
mit 25MHz (laut Timing-Analyse wären mit der aktuellen Implementierung 
noch +20% Luft nach oben) Takt läuft und der Rest auf (noch) gemütlichen 
100MHz.

Autor: C. A. Rotwang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tobias F. schrieb:
> Dann ist es so, dass professionelle FPGA Designs praktisch nie mit 25MHz
> laufen.

Selbst wenn nur 25 MHz takt reingehen, heisst das nicht das intern alles 
mit 25 MHz läuft, Srichwort PLL. FPGA's haben keine Probleme 
Speicherinterface wie DDR2 aufwärts zu implementieren. also schon mal 
das 6-fache von 25 MHz.

Kameras in der Automatisierungstechnik laufen auch mit Pixeltakten  100 
MHz+ wenns sein muss und machen dabei moch Vorarbeitung über die Pixel.

In der Medizintechnik wird Phased Array Ultraschall eingesetzt, da biste 
beim Beamforming schon mal schnell bei 250 MHz.

Softwaredefined radio im VHF bereich, Scopes (Schau mal in den 
Wittig-Thread hier, da holt ein cyclone 200 MHz aus dem Signal) ... etc. 
pp.

http://www.dynamicc4.com/download/Pentek/Handbook/SWR_FPGAF_6th.pdf

Autor: Mampf F. (mampf) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
C. A. Rotwang schrieb:
> Selbst wenn nur 25 MHz takt reingehen, heisst das nicht das intern alles
> mit 25 MHz läuft, Srichwort PLL.

Ja richtig ... Ich hab 3 PLLs ... 100MHz für SHA3, 200MHz für CURL (auch 
ein Hashing-Algorithmus) und die 25MHz für die Zahlenkonvertierung.

Ich denke die Lösung ist ganz okay ...

Angenommen, ich würde die 384Bit Addition, Subtraktion und Vergleiche 
auf kleiner Bitbreiten aufbrechen, damit ich fertige IPs verwenden kann, 
bräuchte ich deutlich höheren Takt als 100MHz, um auf die gleiche 
Geschwindigkeit zu kommen, weil ich dafür dann wieder mehr Takte 
bräuchte.

So gesehen - passt schon.

Ich denke, ich lass es so :)

Autor: Gomolke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mampf F. schrieb:
> Angenommen, ich würde die 384Bit Addition, Subtraktion und Vergleiche
> auf kleiner Bitbreiten aufbrechen, damit ich fertige IPs verwenden kann,
> bräuchte ich deutlich höheren Takt als 100MHz, um auf die gleiche
> Geschwindigkeit zu kommen, weil ich dafür dann wieder mehr Takte

dann könntest du aber mehrer gleichzeitigig berechnen

Autor: Tobias F. (analrapist)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Jürgen S. schrieb:
> Kommt drauf an. Wenn man mit günstigen FPGAs fette MULs braucht, ist es
> effektiver, die langsamer laufen zu lassen und 2 parallel zu nehmen,
> statt mit FFs zu versuchen, die Arithmetik aufzubrechen und zu piplinen,
> was ohnehin nicht beliebig geht, wenn es um einen MUL geht:

Ich zitiere mal nur dieses Stück. Das Problem ist, dass hier 
Geschwindigkeit nicht definiert ist. Geht es Latenz, um Bandbreite oder 
um beides? Außerdem ist nicht klar, was überhaupt das Ziel ist und wie 
es um den Resourcenbedarf steht. Daher gibt es aif jeden Fall mehrere 
Lösungen die alle Vorteile haben. Genauso deine Aussage, was heißt hier 
effektiver? Die FFs sind ja schon da, die kosten nichts extra. Daher 
kann es durchaus auch effektiver zu sein ordentlich zu pipelinen. Ab wie 
"fetten" MULs und ab wie vielen lohnt sich das denn? Die Realität ist 
einfach dass man ohne genaue Anforderungen keine sinnvolle Aussage 
machen kann, der Trend aber eher zu langen, schnelldn Pipelines geht.

C. A. Rotwang schrieb:
> Softwaredefined radio im VHF bereich, Scopes (Schau mal in den
> Wittig-Thread hier, da holt ein cyclone 200 MHz aus dem Signal) ... etc.
> pp.

Und? Das hat weder etwas mit dem FPGA Takt zu tun, noch mit meiner 
Aussage, dass man selten 25MHz Takt an einem FPGA sieht. Kleines Rätsel 
für dich: Es gibt Oszilloskope mit 256GSamples/s. Läuft der ASIC da mit 
256GHz? Außerdem hat hier niemand etwas vom Input-Takt gesagt. Hast du 
die Diskussion verstanden?

Gomolke schrieb:
> dann könntest du aber mehrer gleichzeitigig berechnen

GENAU das ist der Knackpunkt. Der OP möchte uns aber nicht mitteilen ob 
das nötig/erwünscht ist, oder was überhauot das Ziel ist. Daher kann man 
nur noch gratulieren, dass er eine für ihn wohl passende Lösung gefunden 
hat.

Autor: C. A. Rotwang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tobias F. schrieb:
> C. A. Rotwang schrieb:
>> Softwaredefined radio im VHF bereich, Scopes (Schau mal in den
>> Wittig-Thread hier, da holt ein cyclone 200 MHz aus dem Signal) ... etc.
>> pp.
>
> Und? Das hat weder etwas mit dem FPGA Takt zu tun, noch mit meiner
> Aussage, dass man selten 25MHz Takt an einem FPGA sieht. Kleines Rätsel
> für dich: Es gibt Oszilloskope mit 256GSamples/s. Läuft der ASIC da mit
> 256GHz? Außerdem hat hier niemand etwas vom Input-Takt gesagt. Hast du
> die Diskussion verstanden?

Wenn du meinst ich hätte es nicht verstanden, dann erklärs bitte mal 
verständlich. Und zur Erinnerung, deine Aussage lautete, Zitat:

> "Dann ist es so, dass professionelle FPGA Designs praktisch nie mit 25MHz
laufen."

Das ist hier so angekommen, das FPGA's mit höchstens 25 MHz internen 
Takt laufen. Vielleicht wolltest du was anderes aussagen, dann stell das 
bitte hier klar. FPGA's laufen sehr wohl mit Takten oberhalb 100 MHz, 
intern wie extern. Davon kannst Du dich gerne selbst überzeugen wenn du 
Dich mal mit den beispielhaft genannten design beschäftigst.

Autor: Tobias F. (analrapist)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
C. A. Rotwang schrieb:
> Das ist hier so angekommen, das FPGA's mit höchstens 25 MHz internen
> Takt laufen.

Die Frage im Thread war "25MHz oder Pipelinen und höher takten". 
Natürlich meinte ich dann, als ich sagte dass 25MHz unüblich sind, dass 
die ganze Welt nur 5MHz kann. Sehr logisch.

Autor: Tobias F. (analrapist)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Übrigens war meine Aussage

Tobias F. schrieb:
> Dann ist es so, dass professionelle FPGA Designs praktisch nie mit 25MHz
> laufen. Es mag Ausnahmen geben aber üblicherweise baut man seine
> Pipelinestrukturen so, dass man deutlich höher takten kann und dann
> höheren Durchsatz erreicht.

Aber für den zweiten Satz hat wohl die Aufmerksamkeit nicht mehr 
gerreicht. Kann ja mal passieren.

Autor: C. A. Rotwang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tobias F. schrieb:

> Tobias F. schrieb:
>> Dann ist es so, dass professionelle FPGA Designs praktisch nie mit 25MHz
>> laufen. Es mag Ausnahmen geben aber üblicherweise baut man seine
>> Pipelinestrukturen so, dass man deutlich höher takten kann und dann
>> höheren Durchsatz erreicht.
>
> Aber für den zweiten Satz hat wohl die Aufmerksamkeit nicht mehr
> gerreicht. Kann ja mal passieren.

Der zweite Satz steht nicht zur Debatte, der ist digitaltechnisch eine 
seit Jahrzehnten sattsam bekannte Banalität.

Vielleicht wolltest du ja sagen das ohne Pipelining keine Takte oberhalb 
25 MHz möglich wäre. Aber auch das ist auch unwahrscheinlich, wenn man 
mal einen Blick auf die Angaben zu LUT/DSP-Block-Durchlaufzeiten oder 
pin to pin propagation delay geworfen hat. Schon mit einem Spartan3 kann 
man ungepipelinde CPU-Cores mit 66 MHz++ laufen lassen, bei einem 
Artix-7 schafft die Multiplikation selbst unter LowPower und bei 
Pipeline-verzicht noch deutlich über 100 MHz.

https://www.xilinx.com/support/documentation/data_sheets/ds181_Artix_7_Data_Sheet.pdf

Wenn die Synthesetools wirklich so optimal sind, wie behauptet, sollte 
es genügen, das Ergebnis bitweise durch 4 (D-)FF ohne Reset zu schicken 
und "register balancing" zu aktivieren. Wäre interessant zu sehen, was 
dabei herauskommt.

Autor: Tobias F. (analrapist)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
C. A. Rotwang schrieb:
> Der zweite Satz steht nicht zur Debatte, der ist digitaltechnisch eine
> seit Jahrzehnten sattsam bekannte Banalität.

Mal darüber nachgedacht, dass die beiden Sätze vielleicht 
zusammengehören?

Die Aussage war in etwa "Im Regelfall entwirft man seine Pipelinestufen 
so, dass man deutlich höher als 25MHz takten kann, um einen höheren 
Durchsatz bei ähnlicher Latenz zu erreichen".

Wenn man dazu nur eine Zielregisterstufe und sonst keine Pipeline 
braucht ist das ja auch schön, im Falle des OPs ist es aber wohl nicht 
der Fall.

C. A. Rotwang schrieb:
> Wenn die Synthesetools wirklich so optimal sind, wie behauptet, sollte
> es genügen, das Ergebnis bitweise durch 4 (D-)FF ohne Reset zu schicken
> und "register balancing" zu aktivieren. Wäre interessant zu sehen, was
> dabei herauskommt.

Moment. Nur weil das Synthesetool die Register Platziert heißt das ja 
noch lange nicht dass da keine Pipeline ist. Das nur so am Rande...

Autor: C. A. Rotwang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tobias F. schrieb:
> Die Aussage war in etwa "Im Regelfall entwirft man seine Pipelinestufen
> so, dass man deutlich höher als 25MHz takten kann, um einen höheren
> Durchsatz bei ähnlicher Latenz zu erreichen".

Man muss aber keine Pipeline einbauen um schneller als 25 MHz zu takten, 
sondern da hat man irgendeinen "groben schnitzer" drin bspw. ein falsch 
oder nicht gesetztes timing constraint, oder falsch gesetzte 
Syntheseoption. Bei den obigen Formulierungen ensteht der falsche 
Eindruck, es gäbe eine "magische" latenzmauer von 40 ns die nur durch 
Pipelining zu brechen wäre.

Autor: Tobias F. (analrapist)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
C. A. Rotwang schrieb:
> Man muss aber keine Pipeline einbauen um schneller als 25 MHz zu takten,
> sondern da hat man irgendeinen "groben schnitzer" drin bspw. ein falsch
> oder nicht gesetztes timing constraint, oder falsch gesetzte
> Syntheseoption. Bei den obigen Formulierungen ensteht der falsche
> Eindruck, es gäbe eine "magische" latenzmauer von 40 ns die nur durch
> Pipelining zu brechen wäre.

Und bei dir entsteht der Eindruck jede logische Funktion kann mit >25MHz 
ohne Pipelining in einem üblichen FPGA umgesetzt werden. Das ist 
offensichtlich genauso falsch.

Autor: Jürgen S. (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tobias F. schrieb:
> Geschwindigkeit nicht definiert ist. Geht es Latenz, um Bandbreite oder
> um beides? Außerdem ist nicht klar, was überhaupt das Ziel ist und wie
> es um den Resourcenbedarf steht.

Dann definiere ich mal:

a) Geschwindigkeit ist die die umgekehrte absolute Zeit, mit der eine 
Aufgabe abgearbeitet werden kann. Da der user Mampf das FPGa hier als so 
eine Art Rechenknecht gebraucht, soll diese wohl minimal sein.

b) Bandbreite ist im Bezug auf Rechnungen das, was in Summe, also beim 
Prozessieren mehrerer Rechnungen, maximal erreicht werden kann. Ob das 
hier bei der Mampfaufgabe eine Rolle spielt, müsste man untersuchen. 
Allgemein ist das in jedem Fall ein Punkt.

> Daher gibt es aif jeden Fall mehrere
> Lösungen die alle Vorteile haben.
Eigentlich gibt es je nach Fall nur eine von mehreren Lösungen, die 
jeweils die Beste ist.

> Genauso deine Aussage, was heißt hier effektiver?
Effektiver kann bedeuten,

- schneller zu implementieren, weniger Formulierungsaufwand
- geringerer Resourcenverbrauch in a) Zeit oder b) Fläche
- Kostengünstiger

Hier konkret ist es so, dass das pipelinen deshalb zu kaum Verbesserung 
führt, weil Teilrechungen künstlich aufgespalten werden. Es sit deshlab 
mitunter besser, die gesamte MUL als ein Block zu belassen und mehrere 
davon zu parallelisieren und sequenziell anzusteuern.

Z.B. könnte man mit einer Latzenz von 4 Schritten 4 solche Blocks 
verwenden und mit dem ansteuernden Prozess die Daten passend absetzen 
und abholen. Damit hat man keinen Zeitverlust, kein Warten und das aus 
meiner Sicht wahrscheinlich kleinste Design.

> Die FFs sind ja schon da, die kosten nichts extra.
Die Rechung ist IMO eine Milchmädchenrechnung. Jede Resource im FPGA 
muss berechnet und kostentechnisch veranschlagt werden. So rechnen kann 
man nur, wenn man Lösungen zwischen LUTs und FFs hin und her balanciert 
wie wir das bei der Betrachtung von vor einigen Wochen hatten.


C. A. Rotwang schrieb:
> Man muss aber keine Pipeline einbauen um schneller als 25 MHz zu takten,
> sondern da hat man irgendeinen "groben schnitzer" drin bspw. ein falsch
> oder nicht gesetztes timing constraint, oder falsch gesetzte
> Syntheseoption.
Es reicht, wenn die Rechenoperationen eine ausreichende Breite haben. 
Die MUL-Geschichte ist das beste Beispiel. Wenn da FFs dazwischen 
kommen, helfen die nicht, das zu beschleunigen.

Ob und wann eine pipeline was bringt und ob man sie von innen oder von 
außen aufbaut, muss man im Detail betrachten.

Wie im parallelen thread schon dargestellt, führt das Zwischenspeichern 
von DSP-Ausgängen / Komninatorik, um es zu pipelinen dazu, dass weniger 
zusammengefasst werden kann. Das Design wird also um einiges größer. Das 
gilt insbesondere dann, wenn man Kanäle und Zeitebenen zwischenspeichern 
muss, um Architekturen mehrfach zu verwenden.

Ich schaue gerade mal in meine Liste und finde:

IIR-EQ als MonoBlock : 4 DSPs,  8 LUTRAMs,  53 LUTs, 117 FFs,  8cc
IIR-EQ als Pipeline  : 6 DSPs, 11 LUTRAMs, 126 LUTs, 343 FFs, 12cc

Der Unterschied ist z.B., dass Daten die intern scheinbar in FFs 
gespeichert sind, dann aber beim Optimieren verschwinden, wenn das Tempo 
passt, nun erhalten bleiben und parallel durch die pipe fliessen müssen, 
um zeitrichtig verrechnet werden zu können. Zudem braucht es Register 
für des Multiplexen.

Wenn man den IIR aber nur für einen Kanal einsetzen will, packt der im 
loop die 8cc mit etwa 40 MHz = 500kHz. Man könnte ihn folglich mit 
simplem Multiplexen für 8 Kanäle für 48kHz verwenden. Braucht man 16 
Kanäle wären des deren 2. Damit erst übertrifft der Bedarf die 
1D-pipeline-Lösung.

Für eine 2D-pipe, also Kanäle und Samples über die Zeit, lohnt es sich 
wegen der DSPs ab 16 Kanälen, mit Blick auf die LUTs und FFs aber erst 
bei 24 Kanälen, denn:

IIR-EQ als Pipeline2 : 6 DSPs, 11 LUTRAMs, 211 LUTs, 477 FFs, 16cc

D.h. es muss soviel zwischengespeichert werden, um zeitrichtig und 
kanalrichtig zu rotieren, dass der FF-Aufwand stark steigt.

"Effektiver" würde ich die 2D-pipe aber dennoch nennen, weil sie eben 
2048 Kanäle mit 48kHz packt, bzw konkret 32x32x96kHz in meinem 
Audio-DSP.

Autor: Jürgen S. (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
C. A. Rotwang schrieb:
> Wenn die Synthesetools wirklich so optimal sind, wie behauptet, sollte
> es genügen, das Ergebnis bitweise durch 4 (D-)FF ohne Reset zu schicken
> und "register balancing" zu aktivieren. Wäre interessant zu sehen, was
> dabei herauskommt.

Diese Sache hatte ich im schon oben angesprochenen Parallelthema schon 
mal erörtert:

Beitrag "Re: Ein DSP - aber 2 Multiplikationen. David Copperfield?"

Autor: C. A. Rotwang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tobias F. schrieb:
> Und bei dir entsteht der Eindruck jede logische Funktion kann mit >25MHz
> ohne Pipelining in einem üblichen FPGA umgesetzt werden. Das ist
> offensichtlich genauso falsch.

Schau das ist nicht mein Eindruck sondern meine Erfahrung und damit 
jeder überprüfen kann wie realistisch das ist, wurde oben des Datenblatt 
mit den Schaltzeiten eines FPGA's verlinkt.

Es wäre jetzt wirklich an der Zeit mal die "professionellen FPGA 
Designs" zu zeigen, die Du angeblich kennst und die dich zur der Aussage 
von 25 MHZ ist schluss geführt. Oder eine AppNote, White Paper, etc..
Derzeit drängt sich der Eindruck auf, das ist nur aus den Finger gesogen 
und was an Belgen und Glaubwürdigkeit fehlt wird durch markigen 
Formulierung kompensiert.

Autor: Mampf F. (mampf) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Diskussion um die 25MHz finde ich sehr interessant!

Auf meinem Cyclone 10 LP lässt sich ein 64Bit Dividierer nur mit max 
10MHz synthetisieren.

Man kann im IP Konfigurator die Latenz angeben, die man "haben möchte".

Dadurch steigt der Takt beträchtlich ... Bei 25 Takten Latenz (sprich 25 
stufige Pipeline) kriegt man über 100MHz raus.

Trotzdem besteht das Problem - konkret in meinem Anwendungsfall - dass 
ich für jeden Rechenschritt die 25 Takte warten muss, da ich auf das 
Ergebnis der vorherigen Division warten muss.

Bei 25MHz reicht immerhin eine 3-stufige Pipeline.

Das war so der Hauptgedanke an meiner ursprünglichen Frage ...

Würde man aus Gründen der Ästhetik (nur eine Clock-Domain im FPGA) 
größere Pipelines bauen lassen, obwohl dadurch dann noch mehr Resourcen 
benötigt werden oder aus pragmatischen Gründen einfach nur mit 25MHz 
takten lassen.

So oder so - schneller würde ich das Ergebnis nicht bekommen ... 25 
Takte @ 100MHz ist immer noch langsamer als 3 Takte @ 25MHz.

Hatte mich dann für letzteres entschieden.

384Bit Addition, Subtraktion, Vergleich kann ungefähr 30MHz - ohne dass 
man mehrere Zyklen braucht, weil man die Operationen auf kleinere Bits 
aufspalten müsste, damit man IPs verwenden kann.

Alles in allem denke ich, dass man sich eine Menge an Logik spart, wenn 
man einfach langsamer fährt.

: Bearbeitet durch User
Autor: Jürgen S. (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mampf F. schrieb:
> Würde man aus Gründen der Ästhetik (nur eine Clock-Domain im FPGA)
> größere Pipelines bauen lassen
Mit mehr oder weniger Domänen hat das aber nichts zu tun.
Wir reden hinsichtlich pipelining von ein und derselben Domain.

> obwohl dadurch dann noch mehr Resourcen
> benötigt werden oder aus pragmatischen Gründen einfach nur mit 25MHz
> takten lassen.
Wie ich weiter oben beschrieben habe: Je nach Konzept hat man entweder 
minimale Fläche oder mehr Invest und dafür pipe für mehr, als einen 
Kanal.

> So oder so - schneller würde ich das Ergebnis nicht bekommen ... 25
> Takte @ 100MHz ist immer noch langsamer als 3 Takte @ 25MHz.
So ist es, wobei man i.d.R. nicht 3:25 an FFs investieren muss, um 
Faktor 4 an Frequenz zu bekommen. Mehr, als in Register je Schritt macht 
keinen Effekt mehr.

Noch ein Beispiel:

Eine Stufe, also ein Element des hier dargestellten FM-Modulators:
http://www.96khz.org/htm/fmsynthesis2.htm

braucht im Artix 7 für einfachen Betrieb mit 100MHz

LUT      374
LUTRAM     3
FF       504
DSP        9

Für einen Synth mit weniger Taktfrequenz z.B. 128x96kHz kriegt man 
zunächst einige Extra-FF weg, danach fallen DSPs weg, die in 1152 LUTs 
wandern und für das minimale System mit der Taktfrequenz von S/PDIF = 
64x48kHz werden LUTs zusammengefasst und man kommt auf:

LUT      491
FF       276
DSP        4


Für einen 8 Operator-Synth müssen 8 solche Module parallel instanziiert 
werden, um einen FMS8 mit allen Kanälen zu haben. Heraus kommt nur 
geringfügig mehr, als das 8-fache der Einzellösung. Je nach 
Konfiguration des FM-Moduls fällt auch etwas lokal weg:

LUT     3221
FF      1876
DSP       28

Alternativ kann es nochmals gepipelined werden und es entstehen dann 
"nur" 128 Stimmen zu 192kHz, die mit auf den 200MHz rennen und fürs 
Verschalten und Verwalten zusätzliche Zwischenspeicher sowie Extra-FFs 
wegen Timing brauchen. Zudem stellt es die Vereinigungsmenge der 
Konfigurationen dar:

LUT      761
LUTRAM     3
FF       981
DSP       11


Wenn ich davon dann 8 parallel nehme, um die volle Stimmanzahl zu haben, 
wäre das mehr DSP-Bedarf aber weniger LUT/FF-Bedarf, als das 8fach 
kopierte schnelle System aus Beispiel 1.

Fazit: Man muss immer auf die Randbedingungen schauen, wie man konkret 
baut.

Solche Beispiele präsentiere ich gerne meinen Kunden, wenn jemand der 
Ansicht ist, man könne das alles automatisch aus einer C-Beschreibung 
mit MATLAB erzeugen lassen.

Geht nicht! Es geht deshalb nicht, weil man MATLAB nicht mit den 
Randbedingungen füttern kann, die es dazu bräuchte.

Autor: Da D. (dieter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tobias F. schrieb:
> Mampf F. schrieb:
>> Was denkt ihr dazu?
>
> Dass du hier absoluten Käse baust.

Auf einen Beitrag, der so anfängt brauchst du eigentlich gar nicht 
antworten.

Autor: C. A. Rotwang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mampf F. schrieb:

>Ich kann pipelinen, was aber Logik und Register kostet - oder ich mache
>die Pipeline des Dividierers kürzer und takte eine Statemaschine einfach
>auf 25MHz und bin damit zufrieden und synchronisiere die Prozesse mit
>unterschiedlichen Clocks per Handshaking.

Ich bin mir nicht sicher ob handshake hier der richtige Begriff für 
dieses Design ist, mir kommt da eher die Bezeichnung "multicycle path" 
in den Sinn.

Bei diesem hat man halt Designteile die länger als einen takt brauchen 
um durchzurechnen. Damit man die Tools das auch richtig platzieren 
können, sollte man ein passendes constraint angeben beispielsweise im 
SDC-file.

http://www.ee.bgu.ac.il/~digivlsi/slides/Multicycles_6_2.pdf
https://www.intel.com/content/www/us/en/programmable/support/support-resources/design-examples/design-software/timinganalyzer/tq-multicycle-path.html

Damit kann das design weiter mit dem (höheren)FSM-Takt laufen.

--

> Die Diskussion um die 25MHz finde ich sehr interessant!
>
> Auf meinem Cyclone 10 LP lässt sich ein 64Bit Dividierer nur mit max
> 10MHz synthetisieren.

Bei langsamen Pfaden sollte man analysieren, welchen Anteil Routing und 
welchen Logik benötigt. Ein "Berechnungswerk" von bspw 10 LUT's kann 
"geschickt" verdrahtet sein, so das das Signal 80% der Laufzeit durch 
die LUT's rast oder ungeschickt, routing, also die "Drähte" zwischen den 
LUT's derart "verknotet" sind, das der Knoten mehr Laufzeit benötigt als 
die LUT's. Routing-Laufzeiten sind verkleinerbar, Logik-Laufzeiten eher 
nicht.

Eine Möglichkeit den "Knoten" zu vermeiden ist es, die bits des 
Eingangsvectors gut im Inneren des FPGA's zu verteilen. Bei den 
erwähnten 384bit Zahlen wäre da die Frage zu stellen wo sie vor der 
Berechnung gespeichert werden. Wenn in einem Speicherblock aus Embedded 
RAM Blöcken. gäbe es die Möglichkeit, da eben viele mit schmalen 
Outbut-Ausgangsdatenport zu verwenden. Oder aufzuteilen zwischen 
Ramblöcken und FF. Und nach den Ramblöcken eine FF-Stage hereinzusetzen, 
auch wenn sie pipelinetechnisch nicht nötig ist.

Auf die Schnelle habe ich zum Thema Optimierung des route delay Anteils 
nur dieses Xilinx- doc gefunden: 
https://www.xilinx.com/publications/prod_mktg/club_vivado/presentation-2015/paris/Xilinx-TimingClosure.pdf

Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tobias F. schrieb:
> Und bei dir entsteht der Eindruck jede logische Funktion kann mit >25MHz
> ohne Pipelining in einem üblichen FPGA umgesetzt werden. Das ist
> offensichtlich genauso falsch.
Nein, so falsch ist die Aussage nicht. Ich mache FPGA seit dem Spartan 
3. Da liefen meine Designs mit ca. 50 MHz. Ein MicroBlaze im S3E läuft 
mit ca. 90 MHz.
Inzwischen sind wir bei 10G-Ethernet, PCIe-4, JESD204-ADCs und 
Gigasample-DACs. Da läuft der Großteil des Designs mit 125 MHz, 156 MHz 
oder gar 250 MHz. Ich weiß grad nicht, wie es bei Video aussieht, aber 
da dürfte ebenfalls Bandbreite gefragt sein.

Hier zum Zitieren mein Statement:
Ein Design wird so schnell getaktet, wie es für die Aufgabe nötig ist. 
Auf aktuellen FPGAs (2018) sind dabei Taktraten zwischen 100 MHz und 200 
MHz i.d.R. erreichbar.
Dabei laufen dedizierte I/O-Interfaces (Serdes, DDRx-Speicher) oft mit 
wesentlich höherer Taktrate.

Mampf F. schrieb:
> Auf meinem Cyclone 10 LP lässt sich ein 64Bit Dividierer nur mit max
> 10MHz synthetisieren.
Richtig. Bei so langer Kombinatorik geht der Takt runter.
Meine Bitbreiten bewegen sich zwischen 12, 16, 24 und 32 Bit. Höhere 
Bitbreiten gibt es nur an FIFOs oder Speicherinterfaces, wo gerne mal 
mehrere Datenwörter parallel verarbeitet werden.

Von daher ist für mich ein 64 Bit-Dividierer, genauso wie Deine 384 
Bit-Arithmetik kein praktischer Anwendungsfall. Die realen Meßwerte die 
ich verarbeiten muß haben einfach (noch) nicht diese Dynamik, wohl aber 
entsprechende Datenraten und gelegentlich auch eine hohe Zahl an 
Meßkanälen.

Duke

P.S.: Wieviele Pins hat der Cyclone 10 LP? Kann der 64 Bit gleichzeitig 
einlesen? Und steht das LP für low power oder high performance?

Autor: Mampf F. (mampf) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Duke Scarring schrieb:
> Von daher ist für mich ein 64 Bit-Dividierer, genauso wie Deine 384
> Bit-Arithmetik kein praktischer Anwendungsfall.
> ...
> P.S.: Wieviele Pins hat der Cyclone 10 LP? Kann der 64 Bit gleichzeitig
> einlesen? Und steht das LP für low power oder high performance?

Dafür hätte er schon genügend Pins ... Es werden aber nur 7 verwendet, 
da das FPGA per SPI angebunden ist.

LP steht für Low-Power - das ist glaub ich ein aktualisierter Cyclone 3 
im Prinzip.

Bzgl Anwendungsfall ... Ja, ich gebe dir recht - es lohnt sich nicht, 
die Umrechnung im FPGA zu machen, da man kaum etwas parallel machen 
kann.

Sequentieller ist es auf einem Microcontroller schneller ...

Aaaaber, es ist nur eine notwendige Teilaufgabe.

Im Prinzip läuft es so, dass man einen 96 bis 768 Byte großen Block in 
das FPGA lädt.

Dann wird der Block von SHA3 gehasht und die Ergebnis-Bytes in die Basis 
27 gewandelt, um zu überprüfen, ob der Hash "gut" ist (die Zahl 26 darf 
im Ergebnis an keiner Stelle vorkommen).

Falls das Ergebnis nicht gut ist, wird an 1-5 Stellen im Block etwas 
geändert und es nochmal versucht.

Im Gesamten ist es dann im FPGA ca 75 mal schneller als auf einem 
STM32F3 mit 72MHz.

Aber die Zahlenkonvertierung frisst halt am meisten Zeit - muss man aber 
leider machen.

Auf dem STM32 kann man die Konvertierung nicht machen, weil durch den 
Datentransfer viel zu viel Zeit verloren gehen würde.

Das war so der Gedanke dahinter.

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mampf F. schrieb:
> Im Gesamten ist es dann im FPGA ca 75 mal schneller als auf einem
> STM32F3 mit 72MHz.

Wie vergleicht sich das eigentlich mit einer optimierten Implementation 
für x86, möglicherweise mit Unterstützung von HVX, CUDA o.ä.?

Autor: Mampf F. (mampf) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
> Mampf F. schrieb:
>> Im Gesamten ist es dann im FPGA ca 75 mal schneller als auf einem
>> STM32F3 mit 72MHz.
>
> Wie vergleicht sich das eigentlich mit einer optimierten Implementation
> für x86, möglicherweise mit Unterstützung von HVX, CUDA o.ä.?

Keine Ahnung - x86 mit HVX oder CUDA ist nicht meine Zielplattform^^

Die Lösung ist für ein Microcontroller-System gedacht :)

Autor: Jürgen S. (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Duke Scarring schrieb:
> Von daher ist für mich ein 64 Bit-Dividierer, genauso wie Deine 384
> Bit-Arithmetik kein praktischer Anwendungsfall.
Nun ja, einen 64Bit Divider braucht es schon mal, z.B. wenn man 32 Bit 
Zahlen mit Rest berechnen will und dazu vorher 32Bit drauf 
addiert/schiebt.

Die 384 Bit Thematik hat man wiederum z.B: im Bereich DSD, wenn ein 
Filter eine komplette Bitgruppe von 128,256 oder 512 in der pipeline 
prozessieren soll. Sind dann eben einfache Additionen, u. U. aber 
durchaus mit Faltungsoperation / Gewichtung.

> P.S.: Wieviele Pins hat der Cyclone 10 LP? Kann der 64 Bit gleichzeitig
> einlesen? Und steht das LP für low power oder high performance?

Ich bin nicht sicher, ob es eine Frage des gleichzeitigen Einlesens ist. 
Wenn es in einem Takt in eine pipeline muss, dann würde man bei einem 
32Bit IF z.B. High/Low nacheinander eintakten und dennoch ergäbe sich 
die Anforderung des gleichzeitigen Loslaufens der pipe / der 
Verarbeitung.


C. A. Rotwang schrieb:
> Ich bin mir nicht sicher ob handshake hier der richtige Begriff für
> dieses Design ist, mir kommt da eher die Bezeichnung "multicycle path"
> in den Sinn.

Das bringt nur nichts in Sachen Geschwindigkeit, geht aber in die 
Richtung was ich oben andeutete:

Mehrere solcher nicht gepipelineten langsamen Blöckchen nebeneinander um 
einen Takt zeitversetzt verwendet.

Autor: C. A. Rotwang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:

> Wie vergleicht sich das eigentlich mit einer optimierten Implementation
> für x86, möglicherweise mit Unterstützung von HVX, CUDA o.ä.?

Ist wohl eine Frage wie gut diese Architekturen "exotische" 
Bitoperationen unterstützen und da sieht es meiner Kenntnis nach 
ausserhalb ASIC/FPGA eher mau aus. CPU's müssen die Bits einzeln mit 
BIT-Masken oder Bit-test Befehlen extrahieren und genauso umständlich 
wieder dranpappen. In Hash Algos wie auch in ERC's werden viele 
Bit-Operationen eingesetzt. Lookuptables helfen nur bis zu einer 
bestimmten Komplexität.

Als Beispiel mag ein rückgekoppeltes Schieberegister -LFSR- dienen; ein 
FPGA schafft die Berechnung des nächsten Patterns für eine 162 maximum 
lengh sequence nach dem Polynom x(0)_t+1 = x[161] xor x[162] xor x[75] 
xor x[74]
locker in einem Takt, während auch für einen 64 bit Prozessor wohl 
minimum 10-20 Takte anzusetzen sind. Durch das iterative Vorgehen kann 
man auch nur beschränkte mehrere Werte der Sequence gleichzeitig aka 
parallel berechnen.


PS:
x86 als Beteichnung ist schon lange tot und wurde von IA32 abgelöst, was 
wiederum 2003 von x64 abgelöst wurde. 
https://de.wikipedia.org/wiki/X86-Prozessor#Benennung_nach_Befehlssatz

Autor: C. A. Rotwang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jürgen S. schrieb:
> C. A. Rotwang schrieb:
>> Ich bin mir nicht sicher ob handshake hier der richtige Begriff für
>> dieses Design ist, mir kommt da eher die Bezeichnung "multicycle path"
>> in den Sinn.
>
> Das bringt nur nichts in Sachen Geschwindigkeit,

Da (Multicycle path constraint) soll es auch nicht um Geschwindigkeit 
gehen sondern lediglich um Designvereinfachung da man sich die 
Aufspaltung in mehrere Clockdomains spart und trotzdem die FSM und der 
Rest schneller laufen lassen kann als die eigentliche Berechnung.

FSM-Pseudocode:
State_0: hash_input  <= shift_rx_reg; --store argument in input FF-stage 
with spi received value
State_1: nop
..
State_10: shift_tx_reg <= hash_output; --store calculated hash in 
transmit

Für den TO mit dem Zitat:
>Würde man aus Gründen der Ästhetik (nur eine Clock-Domain im FPGA)
>größere Pipelines bauen lassen, obwohl dadurch dann noch mehr Resourcen
>benötigt werden oder aus pragmatischen Gründen einfach nur mit 25MHz
>takten lassen.

bedeutet multicycle eine dritte Lösungsvariante die die Vorteile der im 
Zitat genannten beiden (eine Clockdomain, schneller system-Takt, wenig 
ressourcenverbrauch) vereint. Wegen dem langsamenen SPI-Interface 
tröpfeln die Argumente wohl so langsam ein, das eine Beschleunigung der 
Berechnung durch Pipeling nicht wirklich sinnvoll ist.

Autor: Mampf F. (mampf) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
C. A. Rotwang schrieb:
> Da (Multicycle path constraint) soll es auch nicht um Geschwindigkeit
> gehen sondern lediglich um Designvereinfachung da man sich die
> Aufspaltung in mehrere Clockdomains spart und trotzdem die FSM und der
> Rest schneller laufen lassen kann als die eigentliche Berechnung.

Ahja!

Das ist denke ich was neues für mich ...

Ich hatte das zunächst so versucht, dass ich in der 100MHz Statemaschine 
einfach mehrere States auf die Ergebnisse gewartet hatte, aber das 
Synthesetool war - erstaunlicherweise - nicht klug genug, das zu 
erkennen und am Fmax änderte sich dadurch nichts.

Wie genau würde so ein Multicycle Path Constraint aussehen?

*edit*: Google kennt den Begriff - dann hab ich schon mal was, nachdem 
ich suchen kann :)

Das wäre ja die perfekte Lösung für mein ursprüngliches  Dilemma ... 
Hätte ich das vorher schon gekannt, hätte es diesen Thread niemals 
gegeben.

Danke für die Erleuchtung!

: Bearbeitet durch User
Autor: Christoph Z. (christophz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mampf F. schrieb:
> Dann wird der Block von SHA3 gehasht und die Ergebnis-Bytes in die Basis
> 27 gewandelt, um zu überprüfen, ob der Hash "gut" ist (die Zahl 26 darf
> im Ergebnis an keiner Stelle vorkommen).
>
> Falls das Ergebnis nicht gut ist, wird an 1-5 Stellen im Block etwas
> geändert und es nochmal versucht.

Der SHA3 hash block wär so ein klassischer Fall wo Pipelining eingesetzt 
werden kann. Du kannst ja die 1-5 Stellen ja schon ändern bevor du das 
Ergebnis auswertest.

Der Flaschenhals bleibt da natürlich noch die Prüfung auf "keine 26 
vorhanden".

Nur so mal eine Idee von mir:
Hast du schon mal überlegt, ob sich eine Struktur bauen lässt, die nur 
im Worst-case die ganze Zahl konvertieren muss?
Ich meine damit, lässt sich die Konvertierung in mehrere 
Berechnungsschritte zerlegen wo nach jedem Schritt auf eine 
Abbruchbedingung geprüft werden kann?

Autor: Thomas U. (thomasu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jürgen S. schrieb:
> Duke Scarring schrieb:
>> Von daher ist für mich ein 64 Bit-Dividierer, genauso wie Deine 384
>> Bit-Arithmetik kein praktischer Anwendungsfall.
> Nun ja, einen 64Bit Divider braucht es schon mal, z.B. wenn man 32 Bit
> Zahlen mit Rest berechnen will und dazu vorher 32Bit drauf
> addiert/schiebt.

C. A. Rotwang schrieb:
> Als Beispiel mag ein rückgekoppeltes Schieberegister -LFSR- dienen; ein
> FPGA schafft die Berechnung des nächsten Patterns ...
> locker in einem Takt, während auch für einen 64 bit Prozessor wohl
> minimum 10-20 Takte anzusetzen sind.
Das EXOR dauert eigentlich nur einen Takt je 64Bit und danach ist eine 
jeweilige Rotation.


Mampf F. schrieb:
> Das Rechnen mit so großen Zahlen ist vergleichsweise langsam ... ein
> 64Bit div ohne Pipeline schafft es auf 10MHz. Sub, Add, Compare (384Bit)
> auf 35MHz rum.
Was genau soll denn da nun rein?
Compare und Add können so aufwändig ja nicht sein, oder?

Autor: Mampf F. (mampf) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christoph Z. schrieb:
> Nur so mal eine Idee von mir:
> Hast du schon mal überlegt, ob sich eine Struktur bauen lässt, die nur
> im Worst-case die ganze Zahl konvertieren muss?
> Ich meine damit, lässt sich die Konvertierung in mehrere
> Berechnungsschritte zerlegen wo nach jedem Schritt auf eine
> Abbruchbedingung geprüft werden kann?

Nein, leider nicht!

Dieser Algorithmus ist Gift für effiziente Implementierung ...

Diese 81 Stellige Zahl zur Basis 27 wird noch normalisiert.

D.h. es wird versucht, die Summe aller "Ziffern" auf 0 zu bekommen - und 
erst nach der Normalisierung kann man sagen, ob es eine schlechte Stelle 
gibt.

Aber für die Normalisierung benötigt man die Summe aller Zahlen ... Man 
muss das immer komplett ausrechnen xD

: Bearbeitet durch User
Autor: C. A. Rotwang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mampf F. schrieb:

> Wie genau würde so ein Multicycle Path Constraint aussehen?

Mal aus den Schulungsunterlagen f. Quartus abgetippt
set_multicycle_path -from [get_pins reg1|clk] to get [get_pins reg2|d] -setup 10 
set_multicycle_path -from [get_pins reg1|clk] to get [get_pins reg2|d] -hold 9  


Hier liegt der Pfad zwischen zwei FF reg1 und reg2 am selben Takt und an 
der selben clk_ena Leitung die aber nur aller 10 Takte aktiv wird. der 
Ausgang q von FF reg1 ist mit dem Eingang d von reg2 verbunden. In den 
Schulungsunterlagen wird lang und breit erklärt wie man die beiden 
zeilen benutzen muss um ein "Übernahmefenster" mit EMS (end multicycle 
setup) und EMH (end multicycle hold) definiert.

https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/an/an481.pdf


An andere stelle im Internet (für actel(?)) habe ich eine einfacher 
Definition gefunden, die da SDC standard ist, auch so funktionieren 
könnte.


http://ebook.pldworld.com/_Semiconductors/Actel/Libero_v70_fusion_webhelp/set_multicycle_path_constraint.htm
set_multicycle_path 3 -from [get_pins {reg1}] –to [get_pins {reg2}]

Das ist für 3 Takte multicycle.


SDC Constraints sind TCL-scripte und damit nicht so trivial wie Xilinx 
ISE contraints. Am besten mal a bisserl mit Timequest von quartus (das 
icon mit dem Ziffernblatt) rumspielen. Timequest sollte auch timing 
diagramme zeichnen können, an denen man es vielleicht einfacher erkennen 
kann, wie das Übernahmefenster geschoben wird.

ftp://ftp.altera.com/up/pub/Altera_Material/10.1/Tutorials/Timequest.pdf

Autor: C. A. Rotwang (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Thomas U. schrieb:
> C. A. Rotwang schrieb:
>> Als Beispiel mag ein rückgekoppeltes Schieberegister -LFSR- dienen; ein
>> FPGA schafft die Berechnung des nächsten Patterns ...
>> locker in einem Takt, während auch für einen 64 bit Prozessor wohl
>> minimum 10-20 Takte anzusetzen sind.
> Das EXOR dauert eigentlich nur einen Takt je 64Bit und danach ist eine
> jeweilige Rotation.

Nachdem was ich auf die schnelle gefunden habe, kann man bei diesem XOR 
aber nicht einzelne bits addressieren sondern nur "ganze" Register oder 
Immediates (direkt konstanten), die dann bitweise verknüpft werden. Hier 
braucht man aber die Vernüpfung zweier bits (im obigen beispiel tap [75] 
und [74] also bit 11 und 10) in einem Register, die man erstmal 
ausmaskieren muss. Da's könnte dann in Pseudocode etwas so aussehen:
BIT_MASK_11_10  equ x0000_0000_0000_0C00


 AND_64   Reg1, BIT_MASK_11_10  #maks out dont care bits and set zeroflag if all zero
 JZ       L_RES_0               #check for "00"     -> XOR = '0'  
 CMP      Reg1,BIT_MASK_11_10   #check for "11"     -> XOR = '0'
 JZ       L_RES_0
 SET      res                   # "01" or "10" left -> XOR = '1'
 JMP      L_END
L_RES_0:
 CLR      res 
L_END:
         return res   


Also deutlich mehr als ein cycle und das nur für 2 von den 4 Taps. Ich 
bin nicht sonderlich aktuell im x64 instruction set, möglich das man da 
1,2 Takte dank SSE2 etc. sparen kann.
Beim ARM kann man sicherlich durch die bedingte Ausführung einen jump 
und damit die pipeline stalls vermeiden. Vielleicht bringt zusätzlich 
ARM Bitbanding was.
Aber auch so braucht dieses simple LFSR Takte im zweistelligen Bereich.
Ich schlage aber vor diese Diskussion um CPU-Takte in einem Unterforum 
weiterzuführen in dem die X64 experten sitzen, bspw.: 
https://www.mikrocontroller.net/forum/pc-programmierung

Autor: Tobias F. (analrapist)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
C. A. Rotwang schrieb:
> Bei langsamen Pfaden sollte man analysieren, welchen Anteil Routing und
> welchen Logik benötigt. Ein "Berechnungswerk" von bspw 10 LUT's kann
> "geschickt" verdrahtet sein, so das das Signal 80% der Laufzeit durch
> die LUT's rast oder ungeschickt, routing, also die "Drähte" zwischen den
> LUT's derart "verknotet" sind, das der Knoten mehr Laufzeit benötigt als
> die LUT's.

Achso! Wenn ein Design mit weniger als 25MHz läuft liegt das nur am 
Routing, und wenn ich dann alles schön über den Chip verteile läufts 
wieder schneller! Wieder was gelernt! Puh, gut dass ich das bei jedem 
Design und FPGA Füllstand machen kann!

Ach moment, du verstehst ja offenbar keine Ironie. Also nochmal 
ernsthaft, natürlich ist deine Abschätzung mit LUT Laufzeiten Käse wenn 
viel Routing dazukommt. Leider kann man das nicht immer vermeiden, vor 
allem nicht wenn man nicht nur Mini-Designs macht. Wenn der FPGA voller 
wird wird das Routing teils richtig ätzend, da ist es nicht selten dass 
die Routing Laufzeiten die der Logik um ein Mehrfaches überschreiten. 
Aber das steht halt nicht im Datenblatt, daher läuft ja auch alles mit 
>25MHz.

Mampf F. schrieb:
> Bzgl Anwendungsfall ... Ja, ich gebe dir recht - es lohnt sich nicht,
> die Umrechnung im FPGA zu machen, da man kaum etwas parallel machen
> kann.
>
> Sequentieller ist es auf einem Microcontroller schneller ...

Daher sagte ich schon die ganze Zeit dass du das mal mit einem Softcore 
ausprobieren kannst. Spart bestimmt Unmengen an Logik.

Jürgen S. schrieb:
> Effektiver kann bedeuten,
>
> - schneller zu implementieren, weniger Formulierungsaufwand
> - geringerer Resourcenverbrauch in a) Zeit oder b) Fläche
> - Kostengünstiger

Achne echt jetzt? Blöd nur dass der OP sich nicht dazu herablassen 
konnte zu sagen wie viele dieser Konvertierungen er in welcher Zeit 
rechnen möchte. Es mag durchaus schneller sein wenn das erste Ergebnis 
lange braucht, die nächsten aber schnell kommen.

Da D. schrieb:
> Auf einen Beitrag, der so anfängt brauchst du eigentlich gar nicht
> antworten.

Wieso tust dus dann?

Mampf F. schrieb:
> Dann wird der Block von SHA3 gehasht und die Ergebnis-Bytes in die Basis
> 27 gewandelt, um zu überprüfen, ob der Hash "gut" ist (die Zahl 26 darf
> im Ergebnis an keiner Stelle vorkommen).
>
> Falls das Ergebnis nicht gut ist, wird an 1-5 Stellen im Block etwas
> geändert und es nochmal versucht.

Hier könnte man sich z.B. vorstellen, mehrere SHA3 Blöcke zu 
implementieren und eine gepipelinte Konversion ständig auszulasten. Oder 
auch den SHA3 zu pipelinen und direkt eine Möglichkeit nach der Anderen 
reinzuladen. Aber was rede ich, offenbar bin ich eh zu doof zu wissen 
dass man Routing garnicht  braucht und alles >25MHz geht.

Autor: C. A. Rotwang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tobias F. schrieb:
> Ach moment, du verstehst ja offenbar keine Ironie. Also nochmal
> ernsthaft, natürlich ist deine Abschätzung mit LUT Laufzeiten Käse wenn
> viel Routing dazukommt.

Schau wenn keiner ausser Dir Deine Ironie und dein "Käse, Käse" versteht 
oder hilfreich findet, dann lass um des liebens Forums Frieden lieber.

Stattdessen kannst Du ja mal den nachgefragten Belege/Quelle für "Dann 
ist es so, dass professionelle FPGA Designs praktisch nie mit 25MHz 
laufen. " nachliefern.

Autor: Mampf F. (mampf) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tobias F. schrieb:
> Mampf F. schrieb:
>> Bzgl Anwendungsfall ... Ja, ich gebe dir recht - es lohnt sich nicht,
>> die Umrechnung im FPGA zu machen, da man kaum etwas parallel machen
>> kann.
>>
>> Sequentieller ist es auf einem Microcontroller schneller ...
>
> Daher sagte ich schon die ganze Zeit dass du das mal mit einem Softcore
> ausprobieren kannst. Spart bestimmt Unmengen an Logik.

Jau genau, das ist der zukünftige Plan!

Werde für das Projekt auf Xilinx umsteigen und den Cortex M1 von 
DesignStart von ARM verwenden.

Der Vorteil ist, dass man mit einem Soft-Core eine sehr gute Kopplung 
zwischen µC und FPGA Logik hat - da kann man dann sequentielle Sachen im 
Softcore erledigen und sowas wie SHA3 nach Logik auslagern und die 
Transferzeiten zwischen den beiden fallen dann nicht mehr sonderlich ins 
Gewicht :)

Ein weiterer Grund für den Softcore ist unter anderem, dass das ganze 
eine Art Crypto-Core wird, der auch einige high-level-Funktionen können 
soll (insbesondere gibt es fertigen C/C++ Code schon für die Funktionen 
- es sind nur Teile zu langsam).

Solche Funktionen mit State-Maschines in Logik nachzubauen macht keinen 
Sinn ... Lieber die Low-Level Sachen in die Logik auslagern und den Rest 
auf dem Cortex laufen lassen.

: Bearbeitet durch User
Autor: Jürgen S. (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas U. schrieb:
> Jürgen S. schrieb:
>> Nun ja, einen 64Bit Divider braucht es schon mal, z.B. wenn man 32 Bit
>> Zahlen mit Rest berechnen will und dazu vorher 32Bit drauf
>> addiert/schiebt.
Sollte da noch eine Frage dazu kommen?
Man könnte als weiteres Beispiel eine Wurzelbildung nennen, die man 
vorher entsprechend aufbläht, um die Nachkommastellen zu bekommen:

Beitrag "Re: Wurzel ziehen - VHDL"
Beitrag "Quadratwurzelberechnung in VHDL mit Modelsim"

C. A. Rotwang schrieb:
> Nachdem was ich auf die schnelle gefunden habe, kann man bei diesem XOR
> aber nicht einzelne bits addressieren sondern nur "ganze" Register oder
> Immediates (direkt konstanten), die dann bitweise verknüpft werden.
So ist es und deshalb ist eine LFSR-Operation dieser Art in der Software 
immer mehrstufig. Bei CRCs ist das anders: Da lässt sich die Operation 
auf das Wort umrechnen und direkt anwenden.

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
C. A. Rotwang schrieb:
> Stattdessen kannst Du ja mal den nachgefragten Belege/Quelle für "Dann
> ist es so, dass professionelle FPGA Designs praktisch nie mit 25MHz
> laufen. " nachliefern.

Ich habe den Satz übrigens so verstanden:

"Dann ist es so, dass professionelle FPGA-Designs praktisch nie mit 
NUR 25MHz laufen."

Autor: C. A. Rotwang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:

> Ich habe den Satz übrigens so verstanden:
>
> "Dann ist es so, dass professionelle FPGA-Designs praktisch nie mit
> NUR 25MHz laufen."

Dann hast den dem Zitat folgenden Abschnitt ignoriert:

"Überleg mal welche CPU du für
den Preis des FPGAs kaufen kannst. Vermutlich ist da ein ganzer
Single-Board PC drinn. Da kannst dann deinen Algorithmus mit Phython
runterschreiben und es ist trotzdem noch schneller.."

Der klingt eindeutig danach das für den "Käse" - Lord FPGA's lahme Enten 
sind, die unterhalb des Niveaus eines Script-Interpreters auf einen Low 
End Consumer Rechner rangieren...

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stimmt, den Satz habe ich ignoriert. Andererseits haben wir auf Arbeit 
(überraschenderweise) festgestellt, dass ein kleiner Java-Algorithmus 
auf einem ARM schneller lief als der gleiche Algorithmus in C++. Der 
Java-Compiler hat die Vektorisierung wesentlich besser gepackt.

Insofern kann ich mir auch gut vorstellen, dass ein in Python 
runtergeschrieber Algorithmus auf einem günstigen Quadcore schneller 
abläuft als auf einem FPGA - wenn der Algorithmus sich für CPUs gut, für 
FPGAs aber nur schlecht eignet.

Autor: C. A. Rotwang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jürgen S. schrieb:
> C. A. Rotwang schrieb:
>> Nachdem was ich auf die schnelle gefunden habe, kann man bei diesem XOR
>> aber nicht einzelne bits addressieren sondern nur "ganze" Register oder
>> Immediates (direkt konstanten), die dann bitweise verknüpft werden.
> So ist es und deshalb ist eine LFSR-Operation dieser Art in der Software
> immer mehrstufig.

So ich bin  dann doch nochmal über den Pseudocode drübergegangen. Da man 
ja bekanntlich XOR über n ersetzen kann durch Zählen der '1'-bits der n 
- Taps und der anschließenden Entscheidung, ob diese Summe gerade oder 
ungerade ist, kann man die LFSR Nachbildung für das Polynom x(0)_t+1 = 
x[161] xor x[162] xor x[75]  xor x[74] vereinfachen zu:
BIT_MASK_75    equ x0000_0000_0000_0800
BIT_MASK_74    equ x0000_0000_0000_0400
BIT_MASK_161   equ x0000_0002_0000_0000
BIT_MASK_162   equ x0000_0004_0000_0000

L_start:
 CLR      Reg_count           #counts start with 0
 AND_64   Reg_2, BIT_MASK_74    #maks out dont care bits and set zeroflag if all bits zero
 JZ       L_01                #bit is '0' -> no count 
 INC      Reg_count           #bit is '1' -> count 
L_01:     
 AND_64   Reg_2, BIT_MASK_75   #some procedure as before 
 JZ       L_02               
 INC      Reg_count
L_02:     
 AND_64   Reg_3, BIT_MASK_161  #some procedure as before 
 JZ       L_03               
 INC      Reg_count
L_03:     
 AND_64   Reg_3, BIT_MASK_162  #some procedure as before 
 JZ       L_SHIFT               
 INC      Reg_count
L_SHIFT:
 RROT    Reg_count             #Rotate via flag: sum is odd -> Flag is '1'   
 LROT    Reg_1                  #Flag aka XOR-result is shifted to pos[0] 
 LROT    Reg_2                  #shift next reg
 LROT    Reg_3                  #shift complete
 JMP     L_start               #next round

Das wären trotz Vereinfachung und wohlmeinende Annahmen über den 
Befehlssatz (bspw AND das nur flags setzt aber denInhalt des Src-Regs 
nicht verändert) immer noch 18 Befehle.

In einem FPGA  (das allerkleinste genügt für diesen Pillepalle) sollte 
diese simple Verkettung von 162 FF und einem einzigen Gatter mit 100+ 
MHz laufen. Eine CPU muss dann schon mit 1.8 GHz schwitzen um 
vergleichbare Bitraten abzuliefern.

Autor: C. A. Rotwang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
> Der
> Java-Compiler hat die Vektorisierung wesentlich besser gepackt.

Oder C++ ist seinem Ruf treu geblieben dem unbedarften Programmierer das 
Vergeuden von Ressourcen zu "erleichtern".

Oder Java passt besser in die Caches als das C++-Compilat?!

> Insofern kann ich mir auch gut vorstellen, dass ein in Python
> runtergeschrieber Algorithmus auf einem günstigen Quadcore schneller
> abläuft als auf einem FPGA - wenn der Algorithmus sich für CPUs gut, für
> FPGAs aber nur schlecht eignet.

Welcher Algorithmus sollte das sein?
Quadcores profitieren hauptsächlich von parallisierbare Code, aber 
Parallelisierung ist auch eine "Stärke" des FPGA, der kann auch 
Heka-Core wenn's kann und muss. Allerdings grosse LookUpTables kann ein 
(standalone) FPGA mangels internen Speicher nicht so gut, aber auch ein 
Quadcore verlässt sich bei solchen Algo-abkürzungen auf externen 
Speicher (Stichwort Rainbow table).

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
C. A. Rotwang schrieb:
> Welcher Algorithmus sollte das sein?

Na der hier beschriebene, oder zumindest ein Teil davon. Wenn eine 
FPGA-Implementation auf mäßige 25 MHz kommt (oder optimiert vielleicht 
100 MHz), dann sollte eine CPU das auch können. Die 
Geschwindigkeitssteigerung verglichen mit einem STM32 empfand ich 
jedenfalls alles andere als beeindruckend.

Zum Rest des Systems kann ich keine Aussage treffen. Ich weiß auch 
nicht, ob der FPGA das Ganze in 25-facher Ausfertigung parallel 
macht/machen soll oder welche anderen Randbedingungen gelten.

Darum hatte ich ja gefragt, wie performant eine Implementation für 
gewöhnliche PCs mit Vektorisierung oder GPUs ist. Wurde aber 
abgeschmettert, weil vorher unbekannte Randbedingung verletzt. :-)

Autor: C. A. Rotwang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
> Na der hier beschriebene, oder zumindest ein Teil davon. Wenn eine
> FPGA-Implementation auf mäßige 25 MHz kommt (oder optimiert vielleicht
> 100 MHz), dann sollte eine CPU das auch können.

Können schön, die Frage ist wie schnell resp. in wieviel Takten. Sobald 
einer CPU die speziellen Befehle fehlen um eine bestimmte Operation in 
einem Takt auszuführen und daher gezwungen ist das über mehrere Befehle 
zu berechnen schmilzt der Vorsprung durch den höheren Takt schnell 
dahin. Bit-Operationen wie "Tausche im Register_3  bit 2,6 und 30 mit 
bits 29, 24 und 1, ist so eine Operation. Ein FPGA erledigt das in einem 
Takt, eine CPU braucht dafür vielleicht 6-12. Und in Cryptogeschichten 
kommen solche Bitoperationen eher häufig vor. Das durch das Fehlen von 
Bitoperationen die bitrate mal schnell um eine ganze Größenordnung 
runter geht, zeigt IMHO das beispiel mit dem LFSR recht gut.

> Die
> Geschwindigkeitssteigerung verglichen mit einem STM32 empfand ich
> jedenfalls alles andere als beeindruckend.

Wobei der STM32 als ARM den m.E. "schnelleren" Befehlssatz gegenüber x64 
mitbringt, er taktet aber eben nicht im GHz-bereich.

> Zum Rest des Systems kann ich keine Aussage treffen. Ich weiß auch
> nicht, ob der FPGA das Ganze in 25-facher Ausfertigung parallel
> macht/machen soll oder welche anderen Randbedingungen gelten.

(Massive) Parallelisierung ist nicht die einzige Stärke eines FPGA, 
manchmal sind es Kleinigkeiten wie eine frei wählbare 
Registeraddressbechnung. Man schaue sich dazu mal den Klassischen 
"Mittelweg" zwischen CPU und FPGA an - den DSP. Der punktete damals für 
klassische Filterberechnungen allein dadurch, das er in einem Takt nicht 
nur multiplizieren sondern auch die Adressen des nächsten Koeffizenten 
ermitteln (indizierung) kann. Stichwort VLIW. Und "Spezial-Operationen" 
wie bit reversed (bits von rechts nach links tauschen) gleich mitbringt. 
Das braucht man beispielsweise für FFT.

Autor: Jürgen S. (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
C. A. Rotwang schrieb:
> In einem FPGA  (das allerkleinste genügt für diesen Pillepalle) sollte
> diese simple Verkettung von 162 FF und einem einzigen Gatter mit 100+
> MHz laufen. Eine CPU muss dann schon mit 1.8 GHz schwitzen um
> vergleichbare Bitraten abzuliefern.

Dann wären sie beide aber exakt gleich schnell, denn der Faktor 20 ist 
ja der derzeit typische zwischen FPGAs und CPUs was die Betrachtung der 
Latenz angeht. Und: Die CPU verbrät mitunter dafür weniger Leistung, 
weil des Silizium effektiver ist. Ich sehe beim Übergang von FPGA <-> 
ASIC schon einen Faktor 5 in der Stromeinsparung. Bei optimiertem 
Silizium (low power CPUs) sind auch das ein Faktor 10.

Die grundlegende Aussage bleibt natürlich: Gerade solche low level 
Operationen sind im FPGA bestens aufgehoben.

Autor: Horst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: TriHexagon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Horst schrieb:
> Wer wissen will, worum es genau geht:
> https://twitter.com/ThomasPototsch1/status/1050393183060983809?s=20

Was denn? DAS ist die Plattform für die Multiprozessorarchitektur?

Autor: Mampf F. (mampf) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Horst schrieb:
> Wer wissen will, worum es genau geht:
> https://twitter.com/ThomasPototsch1/status/1050393...

Das ist ein anderes meiner Projekte ... Völlig andere Anwendung und 
Leistungsklasse^^

Bei den Fragen hier ging es eher um einen Forschungs- und Förder-Antrag 
...

Ich hatte da bisserl Vorarbeit geleistet, um zu kucken, wo die Probleme 
sein könnten und wie das Konzept am besten aussehen sollte.

: Bearbeitet durch User
Autor: Tobias F. (analrapist)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
S. R. schrieb:
> Stimmt, den Satz habe ich ignoriert. Andererseits haben wir auf Arbeit
> (überraschenderweise) festgestellt, dass ein kleiner Java-Algorithmus
> auf einem ARM schneller lief als der gleiche Algorithmus in C++. Der
> Java-Compiler hat die Vektorisierung wesentlich besser gepackt.
>
> Insofern kann ich mir auch gut vorstellen, dass ein in Python
> runtergeschrieber Algorithmus auf einem günstigen Quadcore schneller
> abläuft als auf einem FPGA - wenn der Algorithmus sich für CPUs gut, für
> FPGAs aber nur schlecht eignet

Du hast absolut recht, das was der Herr Rotwang schreibt kannst du 
getrost ignorieren. Ich habe mehrfach erklärt dass man praktisch immer 
höher als 25MHz Taktet um höheren Durchsatz zu bekommen, aber das 
scheint er nicht zu verstehen.

Auch dass moderne CPUs verdammt schnell sind scheint er nicht verstanden 
zu haben. Gerade wenn man Algorithmen hat die viele verschiedene 
Operationen durchführen artet das im FPGA schnell aus, was dann aufgrund 
begrenzter Resourcen auch gern zu geringer Geschwindigkeit führt.

Aber auch ein Softcore kann bei gleichem Resourcenverbrauch viel 
schneller sein bzw bei gleicher Geschwindigkeit viel kleiner, das hat 
der OP ja auch schon bestätigt, wenn auch noch nicht umgesetzt.

C. A. Rotwang schrieb:
> Stattdessen kannst Du ja mal den nachgefragten Belege/Quelle für "Dann
> ist es so, dass professionelle FPGA Designs praktisch nie mit 25MHz
> laufen. " nachliefern.

Du hast doch selbst schon einige Beispiele für professionelle Designs 
mit höherem Takt geliefert. Was verstehst du eigentlich nicht?

C. A. Rotwang schrieb:
> Der klingt eindeutig danach das für den "Käse" - Lord FPGA's lahme Enten
> sind, die unterhalb des Niveaus eines Script-Interpreters auf einen Low
> End Consumer Rechner rangieren...

Naja der OP verwendet wohl einen Cyclone 3 wenn ichs richtig im Kopf 
habe. Das ist jetzt nicht unbedingt das Neueste vom Neuen. Ich glaube 
tatsächlich dass dem ein "Low End Consumer Rechner" bei vielen Aufgaben 
nicht viel nachsteht.

C. A. Rotwang schrieb:
> Welcher Algorithmus sollte das sein? Quadcores profitieren hauptsächlich
> von parallisierbare Code, aber Parallelisierung ist auch eine "Stärke"
> des FPGA, der kann auch Heka-Core wenn's kann und muss. Allerdings
> grosse LookUpTables kann ein (standalone) FPGA mangels internen Speicher
> nicht so gut, aber auch ein Quadcore verlässt sich bei solchen
> Algo-abkürzungen auf externen Speicher (Stichwort Rainbow table).

Dann ist ja alles Klar. Ein FPGA kann auch Heka-Core (sic) und wenn ein 
Algorithmus sich auf 4 Kerne aufteilen lässt ist er oerfekt FPGA 
geeignet. Außer er braucht viel Speicher, denn Speicher an einen FPGA 
anschließen geht natürlich nicht. Wieso diskutier ich überhaupt mit dir?

Autor: Markus W. (elektrowagi78) Benutzerseite
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Tobias F. schrieb:
> Auch dass moderne CPUs verdammt schnell sind scheint er nicht verstanden
> zu haben.

Das scheinen viele nicht verstanden zu haben. Meistens deshalb, weil sie 
nicht gelernt haben, CPUs effektiv zu nutzen.

Autor: Mampf F. (mampf) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tobias F. schrieb:
> Aber auch ein Softcore kann bei gleichem Resourcenverbrauch viel
> schneller sein bzw bei gleicher Geschwindigkeit viel kleiner, das hat
> der OP ja auch schon bestätigt, wenn auch noch nicht umgesetzt.

Jau, sogar schneller als ein externer zB STM32F3 mit 72MHz.

Ich hab mir das Vivado mit IP von ARM usw alles mal installiert und ein 
Beispiel für das Arty S7 durchsynthetisieren lassen ... Der Cortex M1 
schafft immerhin 100MHz in einem Spartan 7.

Das ist echt nicht schlecht :)

Von Vivado und dem System-Editor bin ich übrigens beeindruckt ... In 
Verbindung mit dem Eclipse-basierten SDK ist das echt eine gelungene 
Sache!

: Bearbeitet durch User
Autor: VHDL Polizei (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
M. W. schrieb:
> Tobias F. schrieb:
>> Auch dass moderne CPUs verdammt schnell sind scheint er nicht verstanden
>> zu haben.
>
> Das scheinen viele nicht verstanden zu haben. Meistens deshalb, weil sie
> nicht gelernt haben, CPUs effektiv zu nutzen.

Abgesehen von einigen wenigen Sonderfällen ist es aber 10mal einfacher 
eine CPU so zu programmieren, dass sie effektiv läuft, als eine VHDL 
hinzustellen, die das tut. Mit VHDL kannst du alles mögliche an 
Srukturen in FPGAs bauen, die belibieg schlecht funktionieren. Da habe 
ich schon viel gesehen, vor allem von denen die behaupten CPUs seien 
effektiver.
Viele von denen haben noch nie eine hardwarenahe Schaltung gesehen oder 
entworfen.

Autor: Mampf F. (mampf) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
VHDL Polizei schrieb im Beitrag #5614802:
> M. W. schrieb:
>> Tobias F. schrieb:
>>> Auch dass moderne CPUs verdammt schnell sind scheint er nicht verstanden
>>> zu haben.
>>
>> Das scheinen viele nicht verstanden zu haben. Meistens deshalb, weil sie
>> nicht gelernt haben, CPUs effektiv zu nutzen.
>
> Abgesehen von einigen wenigen Sonderfällen ist es aber 10mal einfacher
> eine CPU so zu programmieren, dass sie effektiv läuft, als eine VHDL
> hinzustellen, die das tut. Mit VHDL kannst du alles mögliche an
> Srukturen in FPGAs bauen, die belibieg schlecht funktionieren.

Die Kunst ist, zu erkennen, was sich für FPGAs eignet und was nicht und 
da gehört einiges an Erfahrung dazu - oder Erfahrungen zu machen, indem 
man beim rumprobieren einen Weg als Holzweg enttarnt :)

Ich hatte mal einen Chef, der hat alles mit PICs (16F84^^) gemacht - 
nahezu egal, was es war ... Das kannte er halt^^ Dem hat definitiv die 
Erfahrung in anderen Bereichen gefehlt ...

Irgendwann wollte er mal eine USB-SPS-Schnittstelle und ich hatte ihm 
ARM-Controller vorgeschlagen - kannte er nicht, hat sich geweigert. Im 
Prinzip hatte ich alles fertig und ich hatte mit den Erfahrungen 
gesammelt ... Als ich ihn dann an die Wand argumentiert hatte, hatte er 
wir ein schmollendes Kind total dicht gemacht und das Projekt war 
beender bevor es begonnen hatte.

3 Jahre später - als ich schon nicht mehr dort arbeitete - erzählte er 
mir fasziniert, dass ARM mittlerweile >80% Marktanteil im 
Embedded-Bereich hat LOL

: Bearbeitet durch User
Autor: Ulmer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mampf F. schrieb:
> Als ich ihn dann an die Wand argumentiert hatte, hatte er
> wir ein schmollendes Kind total dicht gemacht und das Projekt war
> beender bevor es begonnen hatte.

Oh Mann, das könnte auch mein Chef gewesen sein. Von der Sorte gibt es 
mehr, als Sandkörner am Stand. In meinem Fall wollte er von VHDL nichts 
wissen, weil ihm die FPGAs zu unsicher waren, er sich damit nicht 
auskannte und er aufgrund der Projekte mit einigen billigen 
Schmalspur-FPGA-Designern schleche Erfahrungen hatte. Also wurde alles 
mit Prozessoren oder Software am PC gemacht. Ich bin damals aus der 
Entwicklung raus ins System Engineering einer parallelen Abteilung mit 
anderen Produkten.

Im Laufe der Zeit hat er sich dann mühsam dazu durchgerungen, sich doch 
mit FPGAs zu befassen und dann zunehmend doch welche integriert, 
besonders mit Microblaze und NIOS, wo man wieder viel programmieren 
konnte. Mittlerweile werden standardmäßig FPGAs eingesetzt, wo es 
aufgrund der gestiegenen Geschwindigkeit längst Micrcontroller gäbe, die 
die Aufgabe besser erledigen könnten. Nur gibt es in deren Abteilung 
keinen embedded Entwickler mehr, der noch einen ARM programmieren könnte 
:-)

Autor: Kest (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Jürgen S. schrieb:
> oder besser gleich 33x33 hochgesetzt werden. Wobei: Laut inoffiziellen
> Aussagen bekommen wir ja bald Altera FPGAs von Intel mit abgespeckten
> I3/5/7 als hardcore mit 64Bit float.

Ich glaub noch nicht daran. Klar, wenn es Xeons mit einem FPGA gibt, 
dann wäre es doch einfach einen FPGA mit einem Xeon zu verheiraten.

Autor: Jürgen S. (engineer) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Ich sehe da schon Optionen. Wenn man z.B. Datenverbindungen zwischen CPU 
und FPGA in Breitband 128Bit mit 1GHz hinbekäme, hätte man damit 
Optionen, die man mit Schaltungen externer Bauteile nicht mehr schafft.

Autor: Thomas U. (thomasu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
C. A. Rotwang schrieb:
> Nachdem was ich auf die schnelle gefunden habe, kann man bei diesem XOR
> aber nicht einzelne bits addressieren sondern nur "ganze" Register oder
> Immediates (direkt konstanten),

Da ist was dran, stimmt!

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.