Hi,
ich will den Takt der FPGA Clock von 50Mhz auf einen Sekundentakt
runterbrechen (--> Frequenz runter auf 0,5Hz?)
Leider passiert beim Ausführen immer folgendes:
Die Led leuchtet etwa 1 Sekunde auf und dann nicht mehr.
Oder sind die LOW Phasen etwa soooo lang?
Ich hoffe auf eure Unterstützung,
Max
Warum nimmst du nicht einfach einen Integer zum Zählen? Dann kannst du
natürlichsprachliche, lesbare Zahlen da hinschreiben...
Schau dich mal um, wer ausser dir "wait until rising_edge()" und "if
rising_edge()" hintereinander im selben Prozess verwendet. Niemand?
Richtig! Wie machen es Andere? Was steht denn im Handbuch des
Synthesizers, wie so ein getakteter Prozess auszusehen hat?
BTW: wenn ich mir deinen getakteten Prozess so anschaue, wirst du bald
Erfahrung mit dem Thema "Latency" machen. Du kannst dich schon mal dazu
ein wenig einlesen... ;-)
2hoch27 ist 134217728, und 101111101011110000100000000 sind 100
Millionen soweit ok.
Die LED soll vermutlich 50% der Zeit leuchten. Das "enable" ist aber nur
eine Taktperiode (1/50 MHz) lang high.
Soll "newClock <= enable; led(0) <= newClock;" die LED togglen? Ich
hätte das irgendwie mit led <= /led wenn enable=high gemacht.
Und wieso hat led 4 bit und nur das LSB wird genutzt?
Die Led hat 4 bit, da es ein Board mit 4 Leds ist (ich verwende aber nur
die eine).
"newClock <= enable; led(0) <= newClock;" - das soll das Signal (0 oder
1) von der neu "erstellten" Clock an die Led weitergeben.
"led <= /led" Was bedeutet hier "/" , das sehe ich zum ersten mal?
Lothar M. schrieb:> Schau dich mal um, wer ausser dir "wait until rising_edge()" und "if> rising_edge()" hintereinander im selben Prozess verwendet.
Neugierig: was passiert dabei, wird da effektiv auf zwei Flanken
gewartet?
@Max: irgendwie hast du dich mit counter vs. counter_vector wohl arg
verheddert. Mal wird das eine, mal das andere betrachtet, das kann nicht
Sinn der Sache sein. Habe nicht viel Ahnung von VHDL :), aber für einen
Zweck solltest du wohl auch nur ein Signal haben. Ggf. kannst du ja über
Typumwandlungen immer noch das eine aus dem anderen ableiten (wenn du
aber Lothars Rat mit den Integern befolgst, ist da gar nicht nötig).
Danke für die vielen Antworten.
Ich habe nun Integer verwendet, weiß aber da noch nicht wie ich eine
If Abfrage mit machen kann.
So jedenfalls geht es nicht: if (counter = "100000000") then ...
ps: Habe vorhin gerade meinen ersten eigenen Taktteiler gezimmert, um
vom PLL-Takt innerhalb des FPGAs andere ableiten zu können.
Wenn du dir davon eine Instanz mit einem divisor von 50_000_000 zimmerst
und an clk_o dein LED-Signal hängst, solltest du eine mit 1 Hz blinkende
LED haben.
Maximilian L. schrieb:> So jedenfalls geht es nicht: if (counter = "100000000") then ...
Ganz ohne eine Sprachreferenz oder mal nachlesen wird das wohl nichts
werden. :}
Ich bin da auch totaler Anfänger, aber ein bisschen quer lesen muss man
halt schon mal.
"reset negative", also low-aktiv.
Händisch würde man über das Signal einen Strich drüber schreiben. Geht
in einer Programmiersprache aber schlecht, und auch sowas wie ¬ ist in
VHDL halt nicht in einem Bezeichner zugelassen.
In meinem Falle läuft "reset" extern auf einen Schalter, der low-aktiv
ist.
Jörg W. schrieb:> In meinem Falle läuft "reset" extern auf einen Schalter, der low-aktiv> ist.
Und der vermutlich prellt. Ist der Reset wenigstens einsynchronisiert?
Wenn nein, sind das die Begriffe um hier im FPGA-Forum die Beiträge mit
dem richtigen Lesefutter zu finden :-)
Duke Scarring schrieb:> Ist der Reset wenigstens einsynchronisiert?
Nö.
Allerdings hätte man den ganzen Reset-Zirkus wohl für den Taktteiler
auch komplett weglassen können. War mehr wegen "stand da schon immer so
drin :)".
Maximilian L. schrieb:> "led <= /led" Was bedeutet hier "/" , das sehe ich zum ersten mal?
In VHDL eher "led <= not led;"
Maximilian L. schrieb:> So jedenfalls geht es nicht: if (counter = "100000000") then ...
"if (counter = 16#100000000#) then" sollte gehen aber wie Lothar schon
geschrieben hat, der Vorteil von integer ist vor allem, dass man hier
einfach Dezimalzahlen hinschreiben kann:
"if (counter = 256) then"
Hab grade nachgeschaut, das habe ich 2008 in Verilog formuliert, ein
Taktteiler um mehrere DC/DC-Wandler zu synchronisieren. Die
Ausgangsschwingung ist ein symmetrisches Rechteck:
Also da wird die Negation mit Tilde formuliert. In WinCUPL und ABEL ist
es das Ausrufezeichen. Hier im Forum endet eine Formatierung tatsächlich
mit slash.
Was mir an meinem Zähler noch auffällt, ich lasse den rückwärts zählen.
Das kommt eher aus der Mikrocontrollertechnik, eine Abfrage auf Null
kostet einen Vergleichsbefehl weniger. Das Zero-Flag wird sowieso
gesetzt, wenn man auf Null dekrementiert. Für programmierbare Logik ist
es ziemlich egal.
Und ich habe die Zahlen auch binär geschrieben. Die Angewohnheit stammt
vielleicht noch aus der TTL-Logikzeit.
Jörg W. schrieb:> Habe vorhin gerade meinen ersten eigenen Taktteiler gezimmert
Aber Obacht: so werden keine Takte erzeugt, die innerhalb des Designs
als Takt weiterverwendet werden. Denn der Skew, der durch die Verwendung
von "normalen" Flipflops in Logikblöcken entsteht, kann von der
Toolchain nicht ermittelt werden. Sie kann einen derart abgeleiteten
internen Takt also nicht auf die Einhaltung von Setup- und Hold-Zeiten
prüfen.
Takte für die Interne Verwendung werden über die Clock-Manager erzeugt.
Und sonst wird intern mit Clock-Enables gearbeitet.
Das ideale und einfach zu wartende Design hat intern genau 1 Takt und
der Rest wird mit Clock-Enables abgehandelt.
Wenn auf solche Art ein Signal namens "Takt" für ein externes Gerät
(SPI, I2C, usw) erzeugt wird, dann passt das. Denn so ein "Takt" nach
draußen muss sowieso wie ein Datensignal behandelt und qualifiziert
werden.
Christoph db1uq K. schrieb:> Was mir an meinem Zähler noch auffällt, ich lasse den rückwärts zählen.> Das kommt eher aus der Mikrocontrollertechnik, eine Abfrage auf Null> kostet einen Vergleichsbefehl weniger. Das Zero-Flag wird sowieso> gesetzt, wenn man auf Null dekrementiert. Für programmierbare Logik ist> es ziemlich egal.
Da ist es eher ungeschickt, den Zähler rückwärts laufen zu lassen. Denn
1. bei einem Rückwärtszähler müssen alle Stellen auf 0 abgefragt werden,
wogegen bei einem anderen Zählerstand ggfs optimiert werden kann (bei
einem Rückwärtszähler mit 16 Schritten müssen 4 Bit auf 0 verglichen
werden, bei einem Vorwärtszähler mit 16 Schritten nur 1, nämlich der
Überlauf ins 5. Bit). Und
2. kann zum Zurücksetzen des Zählers dann der Reset-Eingang des
Flipflops verwendet werden, wogegen zum Setzen eines Wertes ggfs.
zusätzliche Logik aufgebaut wird.
Ausprobieren, wie sich der verwendete Synthesizer bei der verwendeten
FPGA Architektur verhält, macht hier schlau... ;-)
Maximilian L. schrieb:> So jedenfalls geht es nicht: if (counter = "100000000") then ...
Ja klar. Weil in VHDL mit " eine Zeichenkette beginnt. Eine Zahl ist
aber keine Zeichenkette. Es ist aber auf diesem urschleimigen Level echt
einfach: Google findet tausende Beispiele für solche simplen Sachen. Und
jetzt schaust du dir einfach mal ein paar an und versuchst sie zu
verstehen. Und wenn du sie verstanden hast(**), dann verwendest du eines
davon.
Maximilian L. schrieb:> Es funktioniert auch nach paar Änderungen super :-)
Ja, und so richtig schön wäre es, wenn du das Ergebnis dann auch noch
zeigst. Denn so könntest du dann mal Anderen helfen.
(**) das kann schon mal einen oder zwei Tage dauern. Aber Tage voll
ausgiebiger Beschäftigung mit dem Thema, nicht solche "auf die Seite
legen und YT gucken und hoffen dass es nebenher klick macht"-Tage.
Lothar M. schrieb:> Takte für die Interne Verwendung werden über die Clock-Manager erzeugt.> Und sonst wird intern mit Clock-Enables gearbeitet.
Hast du mal ein Beispiel, wie man mit clock enable bspw. einen Takt von
¼ des Mastertakts erzeugt?
> das kann schon mal einen oder zwei Tage dauern
Hihi, ja, so langsam wird es hier.
Danke auch an alle für die diversen Hilfen!
Jörg W. schrieb:> Lothar M. schrieb:>> Takte für die Interne Verwendung werden über die Clock-Manager erzeugt.>> Und sonst wird intern mit Clock-Enables gearbeitet.> Hast du mal ein Beispiel, wie man mit clock enable bspw. einen Takt von> ¼ des Mastertakts erzeugt?
Ist hier das Ziel, diesen erzeugten "Takt" intern verwenden? Oder soll
da nur ein Rechtecksignal nach aussen an einen anderen Baustein gegeben
werden?
> Hast du mal ein Beispiel, wie man mit clock enable bspw. einen Takt von> ¼ des Mastertakts erzeugt?
Erst mal vorneweg: an einen Takt, der im FPGA auf die Takteingänge von
Flipflops darf, werden ziemliche ansprüche gestellt. Er muss mit
dedizierten Taktmanagern hergestellt und Taktbuffern im FPGA auf
Clocknetze verteilt werden. Das ist ziemlicher Aufwand, deshalb wird im
einfachsten zu handhabenden Fall mit 1 Mastertakt im ganzen Design
gearbeitet.
Der Rest wird mit Clock-Enalbes abgehandelt, die jeweils 1
Mastertakt-Zyklus lang gesetzt sind. Und deshalb wird damit auch kein
"Takt" im altbekannten Sinne erzeugt, sondern z.B. jeden 4. Mastertakt
eine Aktion ausgeführt.
Mal basierend auf dem Code des Lauflichts dort
http://www.lothar-miller.de/s9y/archives/61-Lauflicht.html käme sowas
heraus:
else-- nächstes Bit ausgeben -- "versteckter" Clock-Enable
8
if(txbitcnt<10)then
9
:
Denn ich hätte diesen Prescaler natürlich auch ausserhalb machen können
und dann beim Compare-Match ein Enable-Flag setzen können.
Clock-Enables sind also einfach Zähler, die bei einem Ablauf jedesmal
einmalig ein Flag setzen und dieses dann auch "selber" beim nächsten
Takt wieder zurücksetzen.
Weil bei einem FPGA dann ja jeder, der dieses Flag "brauchen" könnte,
parallel angeschlossen ist, und deshalb unmittelbar darauf reagieren
wird, muss man nicht wie bei Software warten, bis auch der Letzte noch
mitbekommen hat, dass er ein Flag zu bearbeiten hat.
Lothar M. schrieb:> Der Rest wird mit Clock-Enalbes abgehandelt, die jeweils 1> Mastertakt-Zyklus lang gesetzt sind. Und deshalb wird damit auch kein> "Takt" im altbekannten Sinne erzeugt, sondern z.B. jeden 4. Mastertakt> eine Aktion ausgeführt.
Ja, genau sowas interessiert mich.
Muss ich mir heute Abend mal näher ansehen.
Die PLL in meinem iCE40 fängt in der Ausgabefrequenz erst bei 16 MHz an;
ich habe sie auf 40 MHz konfiguriert (genauer 39,75), brauche aber für
meine Videosignal-Generierung dann 10 MHz. Das wird also genau auf sowas
rauslaufen, das Dingens mit 40 MHz zu speisen und nur bei jedem 4.
Taktimpuls tatsächlich etwas zu tun.
Christoph db1uq K. schrieb:> Was mir an meinem Zähler noch auffällt, ich lasse den rückwärts zählen.
Das mache ich i.d.R. auch so. Irgendwo hab ich mal aufgeschnappt: die
Abfrage auf '0' könne über die Carry-Chain erfolgen.
Ich habs gard eben mal mit Lattice Diamond (und LSE) ausprobiert.
In die eine Richtung (up):
1
################### Begin Area Report (up)######################
Duke Scarring schrieb:> Das mache ich i.d.R. auch so. Irgendwo hab ich mal aufgeschnappt: die> Abfrage auf '0' könne über die Carry-Chain erfolgen.>> Ich habs gard eben mal mit Lattice Diamond (und LSE) ausprobiert.
Vielen dank dafür. Der Unterschied ist jetzt viel höher als ich
angenommen hätte. Ist natürlich FPGA Typ abhängig aber genau so Detail
wissen ist nicht einfach zu bekommen.
Duke Scarring schrieb:> Ich habs gard eben mal mit Lattice Diamond (und LSE) ausprobiert.
Interessant, das muss ich offenbar auch mal wieder näher anschauen...
;-)
Ich finde es ziemlich gruselig, dass dieser Vergleicher angeblich 10
Logiklevel braucht. Und das bei annähernd gleichem Logikverbrauch.
Könntest du das in Bezug auf den
Beitrag "Re: Vergleichsoperator "<" benötigt weniger Logikelemente als "!=" ?" nochmal mit einem
"ungleich" ausprobieren?
Hier für den "up" Counter:
Duke Scarring schrieb:> Ich finde die 'ungleich'-Varianten sind nicht so schön lesbar.
Eigenartig ist hier, dass die "kleiner"-Varianten teilweise deutlich
schlechter implementiert werden...
> Ich finde die 'ungleich'-Varianten sind nicht so schön lesbar.
Ich hätte da noch was für einen Test... ;-)
Hoch:
1
ifcount=count_maxthen
2
count<=0;
3
toggle<=nottoggle;
4
else
5
count<=count+1;
6
endif;
Runter:
1
ifcount=0then
2
count<=count_max;
3
toggle<=nottoggle;
4
else
5
count<=count-1;
6
endif;
Nur zum Test, weil das jetzt wirklich grauenhaft zu lesen ist. Zumindest
dürfte die gedankliche Invertierung ja keinerlei Unterschiede im
Ergebnis machen...
Das scheint der Synthesizer hinzubekommen. Jetzt kann sich das ja mal
jemand mit Synplify, Quartus, Vivado und evtl. ISE anschauen.
Anzumerken wäre noch: das sind die Ergebnisse nach der Synthese. Durch
Map und Place&Route können da nochmal ganz andere Timing-Werte
rauskommen (in beide Richtungen).
Jörg W. schrieb:> Lothar M. schrieb:>> Schau dich mal um, wer ausser dir "wait until rising_edge()" und "if>> rising_edge()" hintereinander im selben Prozess verwendet.> Neugierig: was passiert dabei, wird da effektiv auf zwei Flanken> gewartet?
Das war noch offen... ;-)
Hier die Antwort: weil sich während der Berechnung des Prozesses clk und
clk'last nicht ändern, ist die if-Abfrage einfach völlig unnötig und
kann schlicht ignoriert werden:
1
process
2
begin
3
waituntilrising_edge(clk);-- warten, bis clk='1' und clk'last='0'
4
:
5
:-- clk und clk'last ändern sich nicht...
6
:
7
if(rising_edge(clk))then-- damit ist auch diese Abfrage immer wahr
Duke Scarring schrieb:> Jetzt kann sich das ja mal jemand mit Synplify, Quartus, Vivado> und evtl. ISE anschauen.
Bedingungen: neues Projekt, default settings.
Buildzeit = Synthese + Routing + Bitstream + Timing Analyse
Quartus 18.1 für 5CEBA2F17C8 (kleinster und langsamster Cyclone 5)
Vivado verhält sich komplett anders. Für Up werden hier wohl
"Optimierungen" eingesetzt, so dass man viel weniger LUTs braucht. Dafür
ist der erreichbare Takt manchmal aber auch viel niedriger.
Im Schematic zeigt sich der Einsatz von etwas mehr CARRY4 Elementen bei
Up_ungleich, während down_ungleich sehr viele LUT1 verwendet.
Hui, das ist ja mal wieder spannend hier. Da will ich doch auch
mithelfen :-)
Hier die Resultate für Synplify für ProASIC3L. Neues Projekt, default
Settings, keine Constraints, kein Pinning.
1
Microsemi Libero SoC 11.8 (Synplify Pro L2016.09M-2) für A3P1000L-1FG144 (kleinster und langsamster ProASIC3L)
Und weil es so schön ist gleich noch mal eine andere Architektur. Diese
besitzt sog. Carrychains in der FPGA Fabric um Zähler, Addierer etc. zu
beschleunigen.
1
NanoXplore NXmap 2.9.7 für NG-MEDIUM
2
3
Design | 4-LUT | DFF | Carry | FMax(MHz)
4
---------------|-------|-----|-------|----------
5
up | 2 | 25 | 49 | 157.629
6
down | 6 | 35 | 49 | 152.975
7
up_gleich | 9 | 25 | 24 | 188.395
8
down_gleich | 23 | 34 | 24 | 157.903
9
up_ungleich | 12 | 25 | 24 | 71.551
10
down_ungleich | 27 | 33 | 24 | 125.439
Interessanterweise ist der langsamste Fall völlig unerwartet der
up_ungleich. Interessant ist, dass die Registerzahl springt zwischen den
verschiedenen Beschreibungen. Der schnellste Fall ist gleichzeitig auch
der kompakteste.
Jetzt wo wir es hier vergleichen bin ich sehr neugierig geworden auf
Zahlen mit Yosys und GHDL-synth...
Dann beteilige ich mich auch mal am Wettbewerb. :-)
Lattice Radiant, iCE40UP5K, LSE, defaults
1
LUT4 PFU Registers IO Buffers Carry Cells
2
up 9(9) 25(25) 2(2) 13(13)
3
down 9(9) 25(25) 2(2) 13(13)
4
up_ne 9(9) 25(25) 2(2) 13(13)
5
down_ne 9(9) 25(25) 2(2) 13(13)
Das ist das Resultat, was ich als compilerverwöhnter Mensch intuitiv
erwartet hätte. ;-) Egal, wie man es formuliert, die Software stellt
fest, dass das Ergebnis sich dadurch nicht ändert, und generiert das
gleiche draus.
Wie ich aus der LSE da die von euch geposteten Timing-Werte rausbekomme,
finde ich aber auf die Schnelle nicht.
Vielleicht schiebe ich das heute Abend auch nochmal durch die
Synplify-Pro-Synthese.
Jörg W. schrieb:> Das ist das Resultat, was ich als compilerverwöhnter Mensch intuitiv> erwartet hätte. ;-) Egal, wie man es formuliert, die Software stellt> fest, dass das Ergebnis sich dadurch nicht ändert, und generiert das> gleiche draus.
Jede Synthesesoftware hat gefühlt >100 Schalter deren Änderung einen
anderen (zumindest für mich manchmal ganz unerwarteten und/oder gar
erstaunlichen) Effekt hat. Eigentlich müssten da m.E. nicht eine Hand
voll, sondern ein paar Hundert Zeilen stehen...
Markus F. schrieb:> Jede Synthesesoftware hat gefühlt >100 Schalter deren Änderung einen> anderen (zumindest für mich manchmal ganz unerwarteten und/oder gar> erstaunlichen) Effekt hat.
Ja, dass die Optimierung das eine gegen das andere abwägen muss, ist
völlig klar. Bei den Compilern sind wir da mittlerweile halt so weit,
dass es schon (fast) genügt, -O0, -O1, -Os, -O2 und -O3 zu haben :), bei
der Synthese gibt's da vielleicht mehr Feinheiten.
Aber dass das gleiche Problem, egal, wie man es formuliert, zu gleichem
Resultat führt, ist bei Compilern mittlerweile nahezu die Norm. Insofern
haben mich die teils großen Unterschiede, die nicht von den
Optimierungsstrategien, sondern nur von der Gestaltung des Codes
abhängen, bei den Synthetisanten weiter oben schon etwas verwundert.
Jörg W. schrieb:> Insofern haben mich die teils großen Unterschiede, die nicht von den> Optimierungsstrategien, sondern nur von der Gestaltung des Codes> abhängen, bei den Synthetisanten weiter oben schon etwas verwundert.
Wenn du sowas wie dort unten bei "Gimmick" gesehen hast, wundert dich da
nichts mehr:
http://www.lothar-miller.de/s9y/archives/52-Kompakte-Flankenerkennung.html
Jörg W. schrieb:> Vielleicht schiebe ich das heute Abend auch nochmal durch die> Synplify-Pro-Synthese.
Hier das Resultat:
1
LUT4 PFU Registers IO Buffers Carry Cells
2
up 17(17) 25(25) 2(2) 12(12)
3
down 18(18) 25(25) 2(2) 13(13)
4
up_ne 17(17) 25(25) 2(2) 12(12)
5
down_ne 18(18) 25(25) 2(2) 13(13)
Also kleinere Unterschiede als bei manch anderer Synthese hier, aber
interessanterweise deutlich mehr LUTs als LSE. Gut, Lattice kann
natürlich die Synthese für ihre Devices gut zurecht schneidern.
Dafür bekomme ich bei Synopsis zumindest etwas, was den oben angegebenen
Timingwerten ähnelt:
1
Clock Name (clock_name) Req Freq (req_freq) Est Freq (est_freq) Slack (slack)
Der Unterschied ist ja enorm im Takt.
Ich gehe davon aus die untere Tabelle ist Synthese + Routing durch LSE?
Dann wäre natürlich interessant ob der estimated clock tatsächlich
erreicht wird, also Synthese von Synplify und Routing von LSE.
Die Ressourcen können sich nach dem Placement/Routing ja auch nochmal
ändern.
Robert P. schrieb:> Der Unterschied ist ja enorm im Takt.
Wundert mich auch, und ich gehe bisschen davon aus, dass das irgendwo
Äpfel und Birnen sind, die da verglichen werden.
Das iCE40 ist ein low-power device, und ich habe auch schon woanders
gelesen, dass das wohl so um die 40 MHz an Taktfrequenz erreicht,
insofern sind die LSE-Zahlen sicherlich nicht unrealistisch.
Meiner Erinnerung nach war das erstmal der Wert nur nach der Synthese,
ohne Routing. Muss mich da aber auch noch bisschen tiefer einlesen. Ich
könnte ja auch mal versuchen, das tatsächlich noch zu pinnen und auf dem
realen FPGA zu testen.
Robert P. schrieb:> Die Ressourcen können sich nach dem Placement/Routing ja auch nochmal> ändern.
Du meinst sicherlich Timing bzw. max. Taktfrequenz. Die Ressourcen
ändern sich nach dem mappen nicht mehr.
Jörg W. schrieb:> Wundert mich auch, und ich gehe bisschen davon aus, dass das irgendwo> Äpfel und Birnen sind, die da verglichen werden.
Nein, wir vergleichen hier wie ein Synthesetool auf verschiedene
schreibweisen des selben Zählers reagiert und ob up/down schneller ist.
Theoretisch könnte da jedesmal so ein Ergebnis rauskommen wie bei
Radiant/LSE: Alle up varianten sind X schnell, alle down Varianten sind
Y schnell.
Das ein Artix-7 schneller ist als ein ice40 müssen wir hier nicht
untersuchen, das ist schon bekannt :-)
Markus F. schrieb:> Jede Synthesesoftware hat gefühlt >100 Schalter deren Änderung einen> anderen (zumindest für mich manchmal ganz unerwarteten und/oder gar> erstaunlichen) Effekt hat. Eigentlich müssten da m.E. nicht eine Hand> voll, sondern ein paar Hundert Zeilen stehen...
Jaein, wichtig für diesen Vergleich hier ist, dass alle sechs Codes mit
den selben Einstellungen verglichen werden.
Die vielen Schalter zur Optimierung sind sicher ein wichtiger Punkt aber
meine Vermutung ist, dass diese ihren Job auch erst effizient machen
können, wenn das Front-End (VHDL in nicht optimierte Logik übersetzen)
seine Aufgabe gut macht und hier in allen Fällen den selben up bzw. down
counter erkennt.
Die Ergebnisse zeigen, dass dies alles andere als eine triviale Aufgabe
ist.
Christoph Z. schrieb:>> Wundert mich auch, und ich gehe bisschen davon aus, dass das irgendwo>> Äpfel und Birnen sind, die da verglichen werden.>> Nein, wir vergleichen hier wie ein Synthesetool auf verschiedene> schreibweisen des selben Zählers reagiert und ob up/down schneller ist.
Ich meinte meine Timing-Werte von einerseits LSE und andererseits
SynplifyPro. Ich vermute, dass das verschiedene Aussagen sind.
Jörg W. schrieb:> Ich meinte meine Timing-Werte von einerseits LSE und andererseits> SynplifyPro. Ich vermute, dass das verschiedene Aussagen sind.
Schicke beides mal durch Place&Route und analysiere das Timing dann.
Eigentlich sollten diese beiden Werte die selbe Aussage sein. Deckt sich
auch mit meiner (7 Jahre alten) Erfahrung mit LSE für den MachXO2. Da
war Synplify auch mehr als doppelt so schnell.
Christoph Z. schrieb:> Da war Synplify auch mehr als doppelt so schnell.
OK.
Wobei sie ja hier auch mit doppeltem Ressourcenverbrauch glänzen. ;-)
(17/18 LUTs statt nur 9)
Christoph Z. schrieb:> Robert P. schrieb:>> Die Ressourcen können sich nach dem Placement/Routing ja auch nochmal>> ändern.>> Du meinst sicherlich Timing bzw. max. Taktfrequenz. Die Ressourcen> ändern sich nach dem mappen nicht mehr.
Ich meinte die Ressourcen. Die unterscheiden sich zwischen "nach der
Synthese" und "nach dem Mapping" durchaus.
Wenn die eine Übersicht von Synplify hier nach der Sythese ist, die von
LSE aber nach dem komplettem Build, kann sich da durchaus noch etwas
tun.
Bei nochmaligem lesen scheint es mir aber, das nur das Timing vom
Synplify Report stammt, die Ressourcen aber vom "kompletten" Build.
Robert P. schrieb:> Ich meinte die Ressourcen. Die unterscheiden sich zwischen "nach der> Synthese" und "nach dem Mapping" durchaus.>> Wenn die eine Übersicht von Synplify hier nach der Sythese ist, die von> LSE aber nach dem komplettem Build, kann sich da durchaus noch etwas> tun.
Nach der Synthese hast du aber noch gar keine Ressourceninformation.
Also nicht die, die wir hier vergleichen. LUTs, Core-cells, Carry-* gibt
es erst nach dem Mapping.
Synplify übernimmt die Schritte Synthese und Mapping. Place & Route sind
dann Vendor Tools. Nach meiner Erfahrung sind die Frequenzschätzungen
von Synplify knapp konservativ und nach dem P&R habe ich üblicherweise
etwas bessere Werte.
Christoph Z. schrieb:> Nach der Synthese hast du aber noch gar keine Ressourceninformation.> Also nicht die, die wir hier vergleichen. LUTs, Core-cells, Carry-* gibt> es erst nach dem Mapping.
Also mir zeigt sowohl Vivado als auch Quartus diese Information schon
nach der Synthese an. Siehe Screenshots.
Zumindest mal für LUTs, FFs, DSP und Blockram, also alles Wichtige.
Robert P. schrieb:> Also mir zeigt sowohl Vivado als auch Quartus diese Information schon> nach der Synthese an.
Ich denke auch, dass die Zahlen, die ich da gepostet habe, jeweils die
Reports der Synthese waren, aber ich schau mir das heute Abend nochmal
an.
Jetzt habe ich mal noch ein Pinning ergänzt und den Flow komplett laufen
lassen. Nicht ganz unerwartet rödelt das P&R dann eine Weile, merkt an
dass das Timing "hard to meet" sei und bricht dann ab.
1
SynplifyPro
2
3
up | Actual (all paths) | 14.291 ns | 69.974 MHz
4
down | Actual (all paths) | 14.738 ns | 67.852 MHz
Thread beobachten
Seitenaufteilung abschalten