Synchroner RST uneffizienter als Asynchroner

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^^

Was ist denn jetzt die Quintessenz aus den Artikeln?

Ist ein synchroner RST uneffizienter als Asynchroner? Oder ist das nur 
ein Beobachtungseffekt ?

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,

Lothar M. schrieb:
> Fpga K. schrieb:
>> sondern in WP275
> Hoppla, da hatte ich die falsche Zahl zugeordnet... :-/

Ich merk auch die Zahlen nie, ich such da immer mit google neu nach.

Ihr ratet aber nie welches Stichworte ich für dieses WP benutze ;-)

https://www.google.de/search?q="Do+not+mix+your+drinks"_Xilinx

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.

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,

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.