Reset in FPGAs (wieder mal)

[He. (Gast)]

Aufgrund der Diskussionen um den Reset in FPGAs hier und in anderen 
Bereichen des Netzes habe ich mich hingesetzt und ein bischen was 
ausprobiert. Ein etwas seltsamer Effekt ist, dass die Bentzung eines 
synchronen Resets in einem Fall einer großen Testschaltung mit 60% 
Füllung zu dramatisch mehr FFs und deutlich schlechterem timing geführt 
hat, während das in einer anderen Schaltung gar kein Punkt war. In 
beiden Fällen wurde von asynchronem Reset manuell auf synchron 
umgestellt, also der Reset vor dem Takt in den Takt geschoben. Rest 
blieb gleich. Die Sesi-Listen wurde bereinigt. Es wurde vorher und 
nachher per Simulation und Test geprüft, dass der Reset auch 
angeschlossen und verwendet wurde.

Woran kann das liegen?

In einem Fall wurde das timing durch Weglassen des synchronen resets 
(Setzen des Signals auf Null oben im Toplevel) sogar etwas schlechter.

Ich wage gar nicht zu fragen, woher das kommen kann.

[Gustl B. (-gb-)]

Erstmal solltest du die Designs hochladen, also die ganzen Projekte mit 
Code und so. Einfach damit wir das hier nachvollziehen können. Denn

Heiko E. schrieb:
> dramatisch mehr FFs und deutlich schlechterem timing

ist komplett undefiniert. "dramatisch mehr" und "deutlich schlechter" 
kann so ziemlich Alles sein. Also Zahlen bitte und am Allerbesten das 
ganze Design.

[Rick D. (rickdangerus)]

Du hast ja nichtmal verraten, welches FPGA und welches Synthesetool du 
verwendet hast...

[Vancouver (vancouver)]

Heiko E. schrieb:
> also der Reset vor dem Takt in den Takt geschoben.

Was bedeutet das? Hast du einfach das Resetsignal einsynchronisiert, 
aber bei allen FFs weiterhin den asynchronen Reseteingang verwendet? In 
diesem Fall hast du dafür gesorgt, dass der Reset weiterhin wie ein 
asynchroner Reset verwendet wird, aber immer in der Nähe einer 
Taktflanke liegt. Ein asynchrones Signal, das sich nahe der Taktflanke 
ändert... da sollte beim Thema Timing eine rote Lampe ein deinem Kopf 
aufleuchten.

Heiko E. schrieb:
> Die Sesi-Listen wurde bereinigt.

Und... was um alles in der Welt ist das? Nichtmal Google kennt den 
Begriff.

[DSGV-Violator (Gast)]

Siehe Appnote-Auszug im Anhang.

[Markus F. (mfro)]

Ohne zu wissen, welches FPGA und welche Synthese-Software benutzt wird, 
ist das nichts als Stochern im Trüben und führt höchstens zu falschen 
Fährten.

Die Empfehlungen der Xilinx-Appnote führen z.B. zu praktisch völlig 
gegenteiligen Ergebnissen, wenn man einen MAX10 und Quartus verwendet.

Das einzige, wozu man (ohne genauere Angaben) verlässlich raten kann 
ist: know your FPGA.

[He. (Gast)]

Ich müsste eine Schaltung extrahieren, die ich posten kann, weil die 
Sourcen teilweise geschäftlichen Ursprungs sind. Mal sehen ...

Sensi-Liste = Sensitivityliste

FPGA & Tool: Xilinx Spartan 7 mit Vivado

[DSGV-Violator (Gast)]

Statt sich der Gefahr auszusetzen gegen NDA oder ähnliche 
Geheimhaltungsklauseln zu verstoßen, mach lieber Dummy-Testdesigns, 
synthetisiere und implementiere diese und schau was bei den 
verschiedenen Schaltungs-/Copileschalter-varianten rauskommt.

Der ATA-controller von OpenCores, OCIDEC hat sync wie async reset 
eingang, da kann man durch Offenlassen des unerwünschten Eingangs 
verschiedene Varianten antesten. https://opencores.org/projects/ata

Neben Spielereien um async oder sync reset hat bei FPGA's u.U. die 
aktive Wertigkeit (High- oder low-activ) einen Einfluss, da sollte man 
neuerdings eher High-active verwenden.
Initialisierung statt Reset-Netzwerk kann auch kräftig Resourcen sparen. 
Wo die Hardware keine wahlfreie Inititialisierung unterstützt, nimmt man 
sen PowerUp Initwert (soweit vorhanden). Das ist dann meistens '0'. 
Verwendet man den anderen als der der sich nach PowerUp/Konfiguration 
einstellt, muss das Synthesetool extra ressourcen hinzufügen. (siehe 
Anhang)


> großen Testschaltung mit 60%
> Füllung zu dramatisch mehr FFs und deutlich schlechterem timing geführt
> hat
Ja und?
Die Synthese bei FPGA's ist "constraints-driven". Das heisst, die Tools 
hören mit der Optimierung auf, sobald die constraints (taktfrequenz, 
Resourcenauslastung <= 100%) erreicht sind. Ob da noch "Luft" ist, das 
Design mit mehr automatischer Optimierung (kostet mehr Laufzeit 
(Stunden!) der Tools) schneller und kleiner wäre interessiert die Tools 
nicht - wenn es (gerade so) passt, dann passt es. Dann muss der 
FPGA-Entwickler seine HDL-Source-Comfortzone eben verlassen und sich 
durch chipview/Netzlisten-logs wühlen, um Reserven zu entdecken.
Oder Tagelang mit compile-schalter/Optionen "rumspielen". Nennt sich 
Exploration design space"

[He. (Gast)]

DSGV-Violator schrieb:
> neuerdings eher High-active verwenden.

Das ist aber schon eine ganze Weile so, meine ich. Die internen Elemente 
kennen keinen low aktiven Reset. Sagt Xilinx FAE, wenigstens.

Danke für die links.