Hallo.
Ohne jetzt meinen ganzen Code posten zu wollen(und zu können) mal eine
kurze Frage an alle die gerne in die Kugel schauen.
Ich habe ein (fast)voll synchrones Design. Verbrauch laut ISE bei 13xx
LUTs.
Heißt, meine ganze Logik befindet sich innerhalb eines Prozezesses
1
a:process(clk,rst)is
2
....
3
if(rst='1')then
4
...
5
elsif(rising_edge(clk))then
6
...
7
endif;
Synchronisier ich den rst jetzt(also innerhalb der clk anweisung)
verbraucht das Design auf einmal über 1700 LUTs.
Ist das vorhersehbar(z.B. aufgrund von Xilinx) und sollte mich das jetzt
in Erstaunen bringen(was es aktuell macht, hätte eigentlich gedacht das
wird weniger...)
gruß
Könnte daran liegen, dass der asynchrone Reset-Eingang in der HW schon
vorgesehen ist, der synchrone aber durch Erweiterung der Übergangslogik
abgebildet wird (-> mehr LUTs wenns nicht mehr reinpasst).
Schau Dir doch mal das bei der Sythese generierte Schematic an, und
schau wo der Reset so durchgeht.
Lothar M. schrieb:> Siehe z.B. den Beitrag "Xilinx und die Resets" und die> darin enthaltenen Links.
Danke erstmal für den Link hab mal kurz das White Paper überflogen.
Lothar M. schrieb:> Welche Zielarchitektur?>> Ansonsten: WP272 u.a.
Virtex 4, ich war ja nur etwas verwundert^^
Marco schrieb:> Ist ein synchroner RST uneffizienter als Asynchroner? Oder ist das nur> ein Beobachtungseffekt ?
Es kommt aufs FPGA an...
Für den Spartan S3 gilt: alles synchron!
Für Lattice und Altera gilt: asynchroner Reset ist ok.
Allerdings darf auch bei denen der Reset nicht einfach vom Pin weg
verwendet werden. Sondern er muss(!!) wie jedes asynchrone Signal erst
mal eingetaktet werden, so dass er synchron deaktiviert wird.
Siehe auch:
http://www.lothar-miller.de/s9y/categories/35-Einsynchronisieren
Lothar M. schrieb:> Marco schrieb:>> Ist ein synchroner RST uneffizienter als Asynchroner? Oder ist das nur>> ein Beobachtungseffekt ?> Es kommt aufs FPGA an...> Für den Spartan S3 gilt: alles synchron!> Für Lattice und Altera gilt: asynchroner Reset ist ok.>> Allerdings darf auch bei denen der Reset nicht einfach vom Pin weg> verwendet werden. Sondern er muss(!!) wie jedes asynchrone Signal erst> mal eingetaktet werden, so dass er synchron deaktiviert wird.>> Siehe auch:> http://www.lothar-miller.de/s9y/categories/35-Eins...
hmmm...
ok. ich glaub dir einfach mal ;)
nichts desto trotz: was meinst du mit einsynchronisiert? einmal durch
ein getaktetes FF, oder versteh ich dich irgendwie falsch?
Lothar M. schrieb:> Ansonsten: WP272 u.a.
WP272 ist zwar auch ein essentiales Dokument aus dem Themenkreis Reset,
warum aber mehr LUT's abhängig vom FF-Typ benötigt werden steht nicht
dort sondern in WP275 ("Get your Priorities Right – Make
your Design Up to 50% Smaller" -
http://www.xilinx.com/support/documentation/white_papers/wp275.pdf).
P. K. schrieb:> Schau Dir doch mal das bei der Sythese generierte Schematic an, und> schau wo der Reset so durchgeht.
Man muss nicht das schematic "per hand absuchen". Ich lass mir dafür die
EDIF-Netzliste ausgeben und zähle dann per script (bspw awk) oder unter
Linux mit grep {FF-makro-id} | wc -l wie oft FF mit synchronen resp.
asynchronen Eingängen vorkommen. Die einzelnen FF- Makros sind im
Library guide erklärt, bspw. f. den Spartan 6 in
http://www.xilinx.com/support/documentation/sw_manuals/xilinx11/spartan6_scm.pdf
ab S. 213
Ziel ist nur dort FF mit asynchronen Inputs zu verwenden wo man sie
wirklich braucht. In der Regel sind das weniger als 10 im Gesamt-design.
MfG,
Fpga K. schrieb:> Man muss nicht das schematic "per hand absuchen". Ich lass mir dafür die> EDIF-Netzliste ausgeben und zähle dann per script (bspw awk) oder unter> Linux mit grep {FF-makro-id} | wc -l wie oft FF mit synchronen resp.> asynchronen Eingängen vorkommen. Die einzelnen FF- Makros sind im> Library guide erklärt, bspw. f. den Spartan 6 in> http://www.xilinx.com/support/documentation/sw_man...> ab S. 213>> Ziel ist nur dort FF mit asynchronen Inputs zu verwenden wo man sie> wirklich braucht. In der Regel sind das weniger als 10 im Gesamt-design.>> MfG,
Danke erstmal für das WP. Ziemlich interessant(besonders weil es
ziemlich gut stimmt was sie da sagen bzgl. meines Codes^^, naja ist halt
doch nicht trivial). Im Moment läuft mein Zeugs ja, ist mir nur bisserl
zu groß. Naja vielleicht find ich nochmal Zeit das zu optimieren.
verwundet schrieb:> Danke erstmal für das WP. Ziemlich interessant
Ich hatte oben übrigens nicht ganz grundlos auf die Links im verlinkten
Beitrag hingewiesen, dort wäre das WP275 auch schon aufgetaucht und
Untersuchungen mit Dreizeilern zu genau diesem Thema:
Beitrag "Re: Hardware mit VHDL "richtig" beschreiben."
Wie gesagt: unbedingt das Datenblatt zum konkreten FPGA lesen. Lattice
und Altera kennen diese Betriebsartenumschaltung nicht, dort ist ein
asynchonchroner Reset immer perfomanter.
Aber er sollte eben nie direkt vom Pin ins Design, sondern darf zwar
asynchron kommen, muss aber immer asynchon deaktiviert werden...
Lothar M. schrieb:> verwundet schrieb:>> Danke erstmal für das WP. Ziemlich interessant> Ich hatte oben übrigens nicht ganz grundlos auf die Links im verlinkten> Beitrag hingewiesen, dort wäre das WP275 auch schon aufgetaucht
Nein, da wird auf WP272 verlinkt, nicht auf WP275.
> Untersuchungen mit Dreizeilern zu genau diesem Thema:> Beitrag "Re: Hardware mit VHDL "richtig" beschreiben."
Super thread, der erklärt das auf deutsch - sollte der referenz-link zu
diesem Thema werden.
MfG,
Da steht auch weitgehend im Artikel zu den Resets, meine ich. Vielleicht
könnte man da einige gute Beiträge linken. Es gibt ja schließlich
wenigstens 2stk im Jahr zu dem Thema :-)
https://www.mikrocontroller.net/articles/Reset_f%C3%BCr_FPGA/CPLD
Mein Weg war in der Anfangszeit, Schaltungen mal so und mal so zu
definieren und den Syntheseknopf zu drücken. Das schafft Aufklärung :D#
Lothar M. schrieb:> verwundet schrieb:>> Danke erstmal für das WP. Ziemlich interessant> Ich hatte oben übrigens nicht ganz grundlos auf die Links im verlinkten> Beitrag hingewiesen, dort wäre das WP275 auch schon aufgetaucht und> Untersuchungen mit Dreizeilern zu genau diesem Thema:> Beitrag "Re: Hardware mit VHDL "richtig" beschreiben.">> Wie gesagt: unbedingt das Datenblatt zum konkreten FPGA lesen. Lattice> und Altera kennen diese Betriebsartenumschaltung nicht,
Für Lattice stimmt diese Aussage bezüglich der Betriebsartenumschaltung
nicht, das FF kann sehr wohl für synchronen oder asynchronen Clear/Set
konfiguriert werden. Allerdings entweder Clear oder Set.
Das Lattice FF hat 6 Eingänge: (siehe z.B. FL1P3JY in der Diamond Hilfe)
D0,D1,SD,SP,CLK, PD/CD.
D0,D1,SD ist ein 2:1 Eingangsmultiplexer
SP Clock Enable (warum das SP heisst abe ich nicht erforscht)
CK
PD/CD; Kann auf Clear oder Preset und Sync oder Async konfiguriert
werden.
GSR kann zusäzlich aktiviert werden.
> dort ist ein> asynchonchroner Reset immer perfomanter.
Das liegt aber daran, dass das GSR Netzwerk für den asynchronen Reset
verwendet werden kann, gilt also nur wenn man EINEN globalen Reset hat.
> Aber er sollte eben nie direkt vom Pin ins Design, sondern darf zwar> asynchron kommen, muss aber immer asynchon deaktiviert werden...
Dein oben verlinkter Artikel zum Einsynchroniseren auf deiner Webseite
deckt diesen Fall allerdings nicht ab. Wäre eventuell sinnvoll das zu
ergänzen.
Lattice User schrieb:> Wäre eventuell sinnvoll das zu> ergänzen.
und dann gleich das Thema bei tun, wo es um die Verteilung der
Einsynchronisier-FFs in die Schaltung hinein geht, die die
Gleichzeitigkeit wieder kaputt macht.
Markus W. schrieb:> Lattice User schrieb:>> Wäre eventuell sinnvoll das zu>> ergänzen.>> und dann gleich das Thema bei tun, wo es um die Verteilung der> Einsynchronisier-FFs in die Schaltung hinein geht, die die> Gleichzeitigkeit wieder kaputt macht.
Das ist in Lothars Artikel angesprochen.
Markus W. schrieb:> wo es um die Verteilung der Einsynchronisier-FFs in die Schaltung hinein> geht, die die Gleichzeitigkeit wieder kaputt macht.
Überraschend kommt es auch, wenn solche Sync-FFs per "Register-Doubling"
vervielfacht werden. Denn das sieht man der VHDL Beschreibung nicht
an...