Hallo,
ich möchte gern verschiedene Addierer bei unterschiedlichen Bitbreiten
auf einem FPGA vergleichen. Ich bin gerade am überlegen, wie man einen
Benchmark in einem FPGA realisieren könnte.
Ich möchte die Latenzzeiten messen und den Resourcenverbrauch. Letzteres
erhalte ich durch das Synthesetool. Und ersteres, würde ich wie folgt
ran gehen:
Ich mache n gleiche addierer mit der bittiefe m, zähle z.b. mit 3 auf.
Bei jedem Taktzyklus werden die n summen mittel exclusiv oder
verglichen. Kommt ne 0 raus, dann gab es keinen fehler.
Wenn das nun einige sekunden gut geht, wird der Takt erhöht.
Wie würdet ihr so einen Benchmark bauen?
mfg
fpga bench schrieb:> Wie würdet ihr so einen Benchmark bauen?
Ganz ohne FPGA rein auf Basis der Daten, die mir die Toolchain liefert.
> Wenn das nun einige sekunden gut geht, wird der Takt erhöht.
Und die Temperatur? Und die Versorgungsspannung? Und die Platzierung des
Designs im FPGA? Alles beliebig? Dann ist das Ergebnis deiner
Untersuchungen auch beliebig... :-o
BTW1: wenn du der Toolchain keine vernünftigen Constraints vorgibst,
dann ist die mit dem "langsamsten" Ergebnis schon zufrieden. Du wolltest
ja nicht mehr als "mach mir den Addierer".
BTW2: warum ist dein Addierer getaktet? Prinzipiell ist sowas doch rein
kombinatorisch.
BTW3: wenn du einfach nur a+b hinschreibst, bekommst du automatisch den
schnellsten Addierer, den du im FPGA bekommen kannst. Nicht umsonst
haben die FPGA-Entwickler in solche Alltagsaufgaben viel Gehirnschmalz
gesteckt und Patente dafür bekommen.
>BTW1: wenn du der Toolchain keine vernünftigen Constraints vorgibst,>dann ist die mit dem "langsamsten" Ergebnis schon zufrieden. Du wolltest>ja nicht mehr als "mach mir den Addierer".
Das Synthesetool kann mir im voraus schon sagen, ob ein 128 Bit Addierer
bei 100 MHz noch funktioniert wird? Ich muss dann eben nur die
Constraints dafür festlegen?
>BTW2: warum ist dein Addierer getaktet? Prinzipiell ist sowas doch rein>kombinatorisch.
Da hast du recht. Wenn du kurz in das Program schaust von mir, da siehst
du dass es bei mir auh Kombinatorisch ist. Die Auswertungselektronik
ist aber getaktet. Anhand der Taktraten wollte ich dann auf Latenzzeiten
kommen.
>BTW3: wenn du einfach nur a+b hinschreibst, bekommst du automatisch den>schnellsten Addierer, den du im FPGA bekommen kannst. Nicht umsonst>haben die FPGA-Entwickler in solche Alltagsaufgaben viel Gehirnschmalz>gesteckt und Patente dafür bekommen.
Oh das wusste ich nicht. Ich dachte man bekommt dann immer den ripple
carry Adder.
Wie sieht es denn aus wenn ich sehr sehr große addiere beschreiben
möchte? z.b. mit 2048 bit? Wird sich dann das tool für einen "kogge
stone addierer" entscheiden?
Normalerweise überlass ich sowas dem Tool, aber wenn ich 3 Adder
benchmarken müsste, dann würde ich das so machen:
1. wie du bereits sagtest, Sythese-Resourcen auswerten für Fläche
2. nun für alle 3 Adder das gleiche Constraint setzen. Hierbei zu hoch
setzen, womit es keines der Adder schafft. 500 MHz? Wichtig auch, dass
Eingänge und Ausgänge registered sind, sonst werden die langsamen IOs
berücksichtigt. Bei Xilinx gibt es eine IP/Submodul-Funktion, was dieses
Thema vereinfacht.
3. Implementierung laufen lassen und dann für die 3 Adder die
schlechtesten Zeitpfade vergleichen. Nun kann man die maximale Frequenz
für jeden Adden ausrechnen.
(4.) Nochmal die Implementierungsresourcen vergleichen, falls die
Toolchain die Adder doch stark umgebaut hat (Replication beispielsweise)
Das ist eine praktische, wenn auch nicht so sehr wissenschaftliche
Variante.
Der theoretische Weg wäre so:
1. Adder mit Regs/Gatter aufmalen -> Resourcen
2. Zeitkritischen Pfad finden -> Geschwindigkeit
Nachteil ist hierbei, dass man erst reale Ergebnisse bekommt, wenn man
die Technologiedaten der Gatter hat.
fpga bench schrieb:>>BTW3: wenn du einfach nur a+b hinschreibst, bekommst du automatisch den>>schnellsten Addierer, den du im FPGA bekommen kannst. Nicht umsonst>>haben die FPGA-Entwickler in solche Alltagsaufgaben viel Gehirnschmalz>>gesteckt und Patente dafür bekommen.> Oh das wusste ich nicht. Ich dachte man bekommt dann immer den ripple> carry Adder.> Wie sieht es denn aus wenn ich sehr sehr große addiere beschreiben> möchte? z.b. mit 2048 bit? Wird sich dann das tool für einen "kogge> stone addierer" entscheiden?
Vielleicht :) Hier muss man den Synthesizer verstehen, den man
verwendet. Sicher werden die meisten zwischen Ripple und
Carry-look-ahead umschalten. Ich kenn auch manche, die eine
Pipelining-Beschreibung ausnutzen. (y <= a + b; +3 Regs verzögerung;
Ergebnis ist ein Adder über 3 Stufen verteilt).
fpga bench schrieb:> Wenn du kurz in das Program schaust von mir
VH-Programming-L?
> Anhand der Taktraten wollte ich dann auf Latenzzeiten kommen.
Kann man machen. Und dann gibt einfach mal unterschiedliche Takte als
Constraints vor. Du siehst dan ja, ob die Toolchain es schafft.
fpga bench schrieb:> Oh das wusste ich nicht. Ich dachte man bekommt dann immer den ripple> carry Adder.> Wie sieht es denn aus wenn ich sehr sehr große addiere beschreiben> möchte? z.b. mit 2048 bit? Wird sich dann das tool für einen "kogge> stone addierer" entscheiden?
Vermutlich nicht. Ich vermute aber genauso, dass ein solcher Addierer
einfach hingeschrieben nicht schneller ist, als das, was die Toolchain
macht. Wenn, dann muss das Ding sicher im FPGA Floorplaner optimiert
werden.
http://ijsetr.com/uploads/32654114-IJSETR123.pdf
Was heißt VHDL? Kommt da "Programmieren" drin vor?
Wenn du mit VHDL "programmierst" wie du C programmierst, dann ist das
Scheitern sicher. Denn VHDL ist eine Beschreibungssprache. Du brauchst
also eine Vorstellung von dem, was du willst und beschreibst es dann mit
VHDL. Du präsentierst hier also keine Programme, sondern Beschreibungen.
Oder andersrum: die Denkweise ist komplett anders.
fpga bench schrieb:> Das Synthesetool kann mir im voraus schon sagen, ob ein 128 Bit Addierer> bei 100 MHz noch funktioniert wird?
Du sagst der Toolchain mit einem Clock-Constraint, dass du 100MHz
möchtest. Und die Toolchain sagt dir, ob sie es schafft. Aber sie wird
eben von sich aus nicht versuchen, 150MHz zu erreichen.
> Was heißt VHDL? Kommt da "Programmieren" drin vor?
Ja ok Verzeihung für die falsche Formulierung. Mir ist klar das es bei
verilog oder VHDL nicht um Programmiersprachen handeln kann.
>Vermutlich nicht. Ich vermute aber genauso, dass ein solcher Addierer>einfach hingeschrieben nicht schneller ist, als das, was die Toolchain>macht. Wenn, dann muss das Ding sicher im FPGA Floorplaner optimiert>werden.
Mein Kenntnisstand vom Studium (2009) war damals so, dass wenn man
ausdrücke wie sum = a + b; oder m = d % n; nicht direkt synthetisierbar
sind. Hat sich das nun geändert? Macht es noch Sinn bei addieren,
multiplizierern und ähnliches "Eigenkreationen" zu entwickeln?
Wie schaut es da mit der modularen Division aus?
Gibt das Synthesetool eigentlich Fehlermeldungen aus, wenn man z.b. das
"%" verwendet und dieses nicht synthetisierbar ist?
fpga bench schrieb:> Mein Kenntnisstand vom Studium (2009) war damals so, dass wenn man> ausdrücke wie sum = a + b; oder m = d % n; nicht direkt synthetisierbar> sind. Hat sich das nun geändert?
Blick ins Datenblatt deines Bausteins (bzw. der Familie) hilft. Alle
haben seit ~20 Jahren spezielle HW im FPGA, damit du einen schnellen
Addierer bauen kannst (Stichwort: Carry). Sie haben auch sog.
DSP-Bloecke in HW realisiert (also echt im Silizium), damit kannst du
prima Multiplizierer bauen. Mit der Kombi aus beidem kannst du
sauschnelle MAC (MultiplyACcumulate) realisieren, damit werben die
Hersteller auch gerne bzgl. maximaler Taktfrequenz. Ist wohl vor allem
fuer die Profi-Codeknacker ein KO-Kriterium...
Aber ein Modulo oder eine Division oder Wurzel oder ARCTAN oder oder
must du aus den vorgegebenen Elementen (LUTs) zusammenbasteln.
berndl schrieb:> Mit der Kombi aus beidem kannst du> sauschnelle MAC (MultiplyACcumulate) realisieren, damit werben die> Hersteller auch gerne bzgl. maximaler Taktfrequenz. Ist wohl vor allem> fuer die Profi-Codeknacker ein KO-Kriterium...
Eher für alle die digitale Filter, FFT und so brauchen, also
Software-Defined-Radio wie Mobilfunk und Radar, Ultraschall, MRI,
schnelle Regler etc.
Hallo,
Nun ich habe gestern (die oben stehende) meine Verilogbeschreibung mal
ins Quartus2 eingegeben. Die Bitbreiten der vier Addieren habe ich mal
auf 1024 gesetzt und war sehr überrascht, dass schon 8% vom FPGA
gebraucht werden.
Bei dem FPGA handelt es sich um einen Cyclone 4 (DE2-115 Board).
Nach dem Erstellungsprozess gab es einige rotmarkierte Meldungen
bezüglich des Timings. Das Tool ist der Meinung, das man noch mit etwa
7MHz arbeiten könnte.
Was ist eigentlihc mit den Angaben "slack" gemeint? Ich nehme an dieser
sollte gegen 0 gehen.
Da ich nur drei IO Signale definiert habe, error, clk und reset. Gab es
beim Clock Probleme. Ich habe dann den Clock auf 5Mhz gesetzt und dann
gab es für das Synthesetool auch keine Probleme mehr.
Die Constraints die ich angebene kann, bewirken aber nicht wirklich,
dass der Takt dann mit 5Mhz läuft oder? Wenn ich das so haben möchte,
dann muss ich auch nen Prescaler bauen, welcher den Takt verkleinert.
berndl schrieb:
> Mit der Kombi aus beidem kannst du> sauschnelle MAC (MultiplyACcumulate) realisieren, damit werben die> Hersteller auch gerne bzgl. maximaler Taktfrequenz. Ist wohl vor allem> fuer die Profi-Codeknacker ein KO-Kriterium..
Mal angenommen der FPGA hat einen n x m Multiplizierer. Woher weis ich,
dass das Synthesetool anhand meiner Verilogbeschreibung diesen auch
korrekt verwendet, wenn ich z.b. schreibe mul <= a * c ? (engenommen a
hat n, b m und mul n+m bits)
fpga bench schrieb:> Was ist eigentlihc mit den Angaben "slack" gemeint? Ich nehme an dieser> sollte gegen 0 gehen.
Das ist die Zeit, um die Dein Signal (bei gegebenen Constraints) zu spät
kommt. Um Reserven zu haben, sollte die Zeit negativ sein. Das Ergebnis
sollte vor der nächsten Taktflanke gültig sein.
> Die Constraints die ich angebene kann, bewirken aber nicht wirklich,> dass der Takt dann mit 5Mhz läuft oder?
Nein, das ist hier kein CubeMX. Üblicherweise gibt man die Taktfrequenz
des externen Oszillators an, z.B. 50 MHz.
> Wenn ich das so haben möchte,> dann muss ich auch nen Prescaler bauen, welcher den Takt verkleinert.
Jein. Um den Wunschtakt zu erhalten verwendet man die Ressourcen, die
der Hersteller im FPGA mitliefert: PLL, DCM und/oder CLKDIV. Die sind
auf die Aufgabe spezialisiert.
Idealerweise generieren die Synthesetools auch die passenden sekundären
bzw. abgeleiteten Timingconstraints. Bei Xilinx funktioniert das nach
meiner Erfahrung ganz gut, bei Lattice/Synopsis schaut man da lieber
zweimal im Timingreport, ob das geklappt hat.
Duke
>> Was ist eigentlihc mit den Angaben "slack" gemeint? Ich nehme an dieser>> sollte gegen 0 gehen.>Das ist die Zeit, um die Dein Signal (bei gegebenen Constraints) zu spät>kommt. Um Reserven zu haben, sollte die Zeit negativ sein. Das Ergebnis>sollte vor der nächsten Taktflanke gültig sein.
In Quartus2 wird das "Slack" Dimensionslos angegeben. Ich nehme aber an
das soll sich dann bestimmt um ns handeln.
fpga bench schrieb:> Die Constraints die ich angebene kann, bewirken aber nicht wirklich,> dass der Takt dann mit 5Mhz läuft oder? Wenn ich das so haben möchte,> dann muss ich auch nen Prescaler bauen, welcher den Takt verkleinert.
Nein. Die sagen dir nur, wie schnell dein Design maximal funzt. Wenn
das, was dir TimeQuest als maximalen Takt ausgibt. kleiner ist als deine
tatsächliche Taktfrequenz, läuft dein Design nicht oder fehlerhaft.
fpga bench schrieb:> Mal angenommen der FPGA hat einen n x m Multiplizierer. Woher weis ich,> dass das Synthesetool anhand meiner Verilogbeschreibung diesen auch> korrekt verwendet, wenn ich z.b. schreibe mul <= a * c ? (engenommen a> hat n, b m und mul n+m bits)
Was die Tools da verwenden sollte in den verschiedenen Reports stehen,
beim "Mapping" werden ja die Ergebnisse des Synthesetools auf die real
existierenden Chip-Resourcen abgebildet. Und z.B. Xilinx ISE schmeisst
dir im Klartext raus, was fuer jede Komponente so verbaut wurde. Also
BRAM oder Distributed-RAM, Multiplier, schnelle Carry Verbindungen bei
Add/Subtract.
Auch der Static-Timing-Report von ISE ist sehr leicht verstaendlich,
Stichwort "Slack".
Aber so in der Ausfuehrlichkeit und Verstaendlichkeit habe ich das
bisher bei Altera oder Lattice noch nicht gesehen (oder halt nicht
gefunden)...
Hallo,
Bei meinem Vergleich würde mich auch sehr der Energieverrbauch
interessieren. Im Report des Quartus2 habe ich nur eine Angabe namens
"fan-out" gefunden. Kann diesen Wert konkret in Watt umrechnen oder so?
:)
Wie schaut es denn da bei der konkurrenz aus (xilinx)?
Markus F. schrieb:> ... das sagt dir der Project Navigator (in Tabellenform) reichlich> ausführlich. Was fehlt dir da?
siehe hier: Beitrag "Synthesereport --verbose"
So habe ich das bisher auch nur in ISE gesehen
berndl schrieb:> Markus F. schrieb:>> ... das sagt dir der Project Navigator (in Tabellenform) reichlich>> ausführlich. Was fehlt dir da?>> siehe hier: Beitrag "Synthesereport --verbose"> So habe ich das bisher auch nur in ISE gesehen
was fehlt dir da? Da steht doch alles?
Markus F. schrieb:> was fehlt dir da? Da steht doch alles?
da steht in etwa das, was bei ISE in der Summary steht. Mir gefallen
aber die zusaetzlichen Infos der ISE schon ganz gut
berndl schrieb:> da steht in etwa das, was bei ISE in der Summary steht. Mir gefallen> aber die zusaetzlichen Infos der ISE schon ganz gut
Welche denn? Was fehlt?
Altera hat meines Wissens dieselben Ausgaben.
Was da oben steht, sind allerdings nur die resourcen. Die timings stehen
woanders.
Found 32-bit adder for signal <erCntValue[31]_GND_125_o_add_1_OUT> created at line 1241.
30
Found 32-bit adder for signal <mmCntValue[31]_GND_125_o_add_10_OUT> created at line 1241.
31
Found 32-bit comparator equal for signal <vdRecWord[31]_vdExpWord[31]_equal_10_o> created at line 111
32
Summary:
33
inferred 2 Adder/Subtractor(s).
34
inferred 135 D-type flip-flop(s).
35
inferred 1 Comparator(s).
36
inferred 9 Multiplexer(s).
37
inferred 1 Finite State Machine(s).
38
Unit <Validator> synthesized.
2. Bekomme ich den Tabellenoutput auch irgendwie außerhalb der GUI?
Hintergrund: Ich schreibe alle Textausgaben der Tools in ein Logfile.
Dort kann man prima mittels diff Änderungen sichtbar machen.
Duke
Nun ja, die Geschmäcker sind verschieden. In meinen FPGAs gibt's keine
Addierer und Multiplexer, nur LUTs und eben die Elemente, die im Report
aufgeführt werden.
Insofern ist die Information, daß die Synthese mein Plus-Zeichen als
solches erkannt hat, für mich eher irrelevant ;) (zumal am Ende - nach
der Optimierung - meist sowieso nicht mehr viel davon übrig bleibt).
Die Tabelle ist lediglich die grafische Aufbereitung des entsprechenden
.rpt-Files, das die von Quartus aufgerufenen Kommandozeilenprogramme
produzieren. In diesem Fall der <Projektname>.map.rpt-Datei, zu finden
im output-files Verzeichnis.
Markus F. schrieb:> Nun ja, die Geschmäcker sind verschieden. In meinen FPGAs gibt's keine> Addierer und Multiplexer, nur LUTs und eben die Elemente, die im Report> aufgeführt werden.
Das was wir da sehen, ist der Synthesereport,
denn Duke Scarring schrieb:>>> Unit <Validator> synthesized.
Der Synthesizer macht aus der Beschreibung noch keine LUTs, sondern
erkennt erst mal, welche Funktionen/Module in der Beschreibung gefunden
wurden. Für die Umsetzung dieser Funktionen/Module in die Zielhardware
mit LUTs und Register ist prinzipiell der Rest der Toolchain zuständig.
Markus F. schrieb:> In diesem Fall der <Projektname>.map.rpt-Datei
Und der Mapper spuckt dann letztlich auch (s)einen entsprechenden Report
aus.
Hallo,
Da das Compilieren sehr sehr viel Zeit in anspruch nimmt, bevorzuge ich
meine Module mit iverilog zu entwickeln. Kann iverilog bzw der Simulator
vvp Auskunft über die Anzahl von Resourcen wie gates, lut´s usw geben?
fpga bench schrieb:> Kann iverilog bzw der Simulator> vvp Auskunft über die Anzahl von Resourcen wie gates, lut´s usw geben?
Nein, überhaupt nicht. Der Simulator kennt die verwendete
FPGA-Architektur nicht.
Duke
Duke Scarring schrieb:> fpga bench schrieb:>> Kann iverilog bzw der Simulator>> vvp Auskunft über die Anzahl von Resourcen wie gates, lut´s usw geben?> Nein, überhaupt nicht. Der Simulator kennt die verwendete> FPGA-Architektur nicht.
Wie auch??
Das kann ganz grundsätzlich nicht sein, weil VHDL oder Verilog nichts
anderes ist, als ein Logikdesign, also boolsche Mathematik und verbale
Beschreibung. Da dort keine reale Physik dahinter steckt, wird kein
Simulator der Welt irgendwelche timings oder resourcen schätzen können.
Aus der Formel C=A+B kann auch nicht ersehen werden, wie eine konkrete
Maschine aussehen kann, die das rechnet. Konrad Zuse z.B. hat das mit
Röhren und Relais gebaut.
Die Formel alleine ist unvollständig.
VHDL oder Verilog, oder MATLAB/Simulink sowie C sind nichts anderes als
Funktionslogik und damit eine funktionelle Beschreibung was ein System
tun soll. Das ist bestenfalls die Hälfte dessen, was es zu einem realen
System braucht.
Ich finde es immer wieder erstaunlich, dass doch recht vielen bei der
Betrachtung von FPGA-Entwicklung einfachste Denkbausteine fehlen.
Wo ist denn jetzt eigentlich das Problem, ein konkretes design durch den
Synthesizer zu jagen und dazu den FPGA-Bautein und all die anderen
Randbedingungen anzugeben, die vorgeben, wie ein von mir aus c = a + b
durchgeführt werden soll?
> Wo ist denn jetzt eigentlich das Problem, ein konkretes design durch den> Synthesizer zu jagen und dazu den FPGA-Bautein und all die anderen> Randbedingungen anzugeben, die vorgeben, wie ein von mir aus c = a + b> durchgeführt werden soll?
Da gibt es kein Problem :)
Ich nutze verilog um meine Module zu simulieren und wenn wenn diese
fehlerfrei sind, dann kann man es druch den Synthesizer geben.
Ich hatte mir nur erhofft, des es noch neben iverilg, vvp und gtkview
ein paar weitere tool um resourcen zu schätzen.
fpga bench schrieb:> Ich hatte mir nur erhofft, des es noch neben iverilg, vvp und gtkview> ein paar weitere tool um resourcen zu schätzen.
Die Synthese versucht, die benötigte Logik möglichst optimal auf
vorhandene Logik zu mappen. Ein Simulator weiß nicht, was für Logik
vorhanden ist und kann das dementsprechend nicht.
Du könntest deine Zielarchitektur (oder eine Approximation davon)
beschreiben und dann Yosys drauf loslassen. Das ist aber auch nur ein
Synthesizer...