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
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...
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"
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
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?
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.
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.
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.
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..
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
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.
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.
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?
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.
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.
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
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 :)
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
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.
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.
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.
Ü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.
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.
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...
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.
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.
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.
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?"
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.
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
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.
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.
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
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?
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.
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.ä.?
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 :)
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.
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
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.
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
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?
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?
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
Mampf F. schrieb: > Wie genau würde so ein Multicycle Path Constraint aussehen? Mal aus den Schulungsunterlagen f. Quartus abgetippt
1 | set_multicycle_path -from [get_pins reg1|clk] to get [get_pins reg2|d] -setup 10 |
2 | 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
1 | 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
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:
1 | BIT_MASK_11_10 equ x0000_0000_0000_0C00 |
2 | |
3 | |
4 | AND_64 Reg1, BIT_MASK_11_10 #maks out dont care bits and set zeroflag if all zero |
5 | JZ L_RES_0 #check for "00" -> XOR = '0' |
6 | CMP Reg1,BIT_MASK_11_10 #check for "11" -> XOR = '0' |
7 | JZ L_RES_0 |
8 | SET res # "01" or "10" left -> XOR = '1' |
9 | JMP L_END |
10 | L_RES_0: |
11 | CLR res |
12 | L_END: |
13 | 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
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.
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.
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
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.
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."
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...
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.
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:
1 | BIT_MASK_75 equ x0000_0000_0000_0800 |
2 | BIT_MASK_74 equ x0000_0000_0000_0400 |
3 | BIT_MASK_161 equ x0000_0002_0000_0000 |
4 | BIT_MASK_162 equ x0000_0004_0000_0000 |
5 | |
6 | L_start: |
7 | CLR Reg_count #counts start with 0 |
8 | AND_64 Reg_2, BIT_MASK_74 #maks out dont care bits and set zeroflag if all bits zero |
9 | JZ L_01 #bit is '0' -> no count |
10 | INC Reg_count #bit is '1' -> count |
11 | L_01: |
12 | AND_64 Reg_2, BIT_MASK_75 #some procedure as before |
13 | JZ L_02 |
14 | INC Reg_count |
15 | L_02: |
16 | AND_64 Reg_3, BIT_MASK_161 #some procedure as before |
17 | JZ L_03 |
18 | INC Reg_count |
19 | L_03: |
20 | AND_64 Reg_3, BIT_MASK_162 #some procedure as before |
21 | JZ L_SHIFT |
22 | INC Reg_count |
23 | L_SHIFT: |
24 | RROT Reg_count #Rotate via flag: sum is odd -> Flag is '1' |
25 | LROT Reg_1 #Flag aka XOR-result is shifted to pos[0] |
26 | LROT Reg_2 #shift next reg |
27 | LROT Reg_3 #shift complete |
28 | 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.
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).
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. :-)
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.
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.
Wer wissen will, worum es genau geht: https://twitter.com/ThomasPototsch1/status/1050393183060983809?s=20
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?
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
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?
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.
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
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.
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
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 :-)
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.
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.
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!
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.