clk_i speise ich dabei mit der Destination-Clock, reset_i ist voll
synchron (lokaler Reset), reset_o ist demnach auch pseudo-synchron.
Quartus 19.2 meckert jedoch rum, dass der Reset nicht synchronisiert
wird.
1
The reset signal "ctrl_i|r.reset" that is generated in one clock domain "ctrl_clk_i" and used in another clock domain should be synchronized: Reset signal destination node(s) from clock "proc_clk_i": "ctrl_reset_cdc_i|chain_out", "ctrl_reset_cdc_i|chain[0]", "ctrl_reset_cdc_i|chain[1]"
Habt ihr eine Idee, ob ich Timing Constraints benötige?
resetto_risotto schrieb:> The reset signal "ctrl_i|r.reset" that is generated in one clock domain> "ctrl_clk_i" and used in another clock domain should be synchronized:> Reset signal destination node(s) from clock "proc_clk_i":> "ctrl_reset_cdc_i|chain_out", "ctrl_reset_cdc_i|chain[0]",> "ctrl_reset_cdc_i|chain[1]"
was sagt Quartus ("Analysys & Synthesis/Optimization Results/Register
Statistics") über (möglicherweise trotz gesetzter Attribute)
stattgefundene Optimierungen?
Markus F. schrieb:> was sagt Quartus ("Analysys & Synthesis/Optimization Results/Register> Statistics") über (möglicherweise trotz gesetzter Attribute)> stattgefundene Optimierungen?
Hallo Markus,
dort wird das Signal in keiner der Untertabs erwähnt, außer bei
"Inverted Registers", da der Reset bei Altera ja an den CLRn geht und
somit invertiert wird. Im Technology Map Viewer wird der Reset-Sync auch
genau so dargestellt, wie ich es gerne hätte (falls die Info hilft).
Wenn der Synchronizer im Technology Map Viewer erscheint, dann ist er
auch da.
Ich denke, Du brauchst noch ein set_false_path constraint zwischen
reset_i und dem Schieberegisterausgang, um den Timing Analyzer zu
zügeln.
resetto_risotto schrieb:> Habt ihr eine Idee, ob ich Timing Constraints benötige?
Viel warscheinlicher ist doch, das du den Reset genau wie in deinem
Codeschnipsel asynchron benutzt und nicht synchron.
Versuchs mal mit:
1
ifrising_edge(clk_i)then
2
ifreset_ithen
3
chain<=(others=>'1');
4
chain_out<='1';
5
else
6
chain<=reset_i&chain(chain'highdownto1);
7
chain_out<=chain(0);
8
endif;
9
endif;
sowohl hier als auch dort wo du den Reset dann nutzt.
FPGA zum Spass schrieb im Beitrag #5938482:
> Codeschnipsel asynchron benutzt und nicht synchron.
Ließe sich das Thema Reset nicht einmal gänzlich und final behandeln?
Besonders bei Alteranutzern fällt mir auf, dass sie nicht verstehen,
wozu die FFs einen asynchronen Eingang haben und synchrone auf aynchrone
Resets umbauen, während die Xilinx-Riege nicht versteht, wie man
synchrone Resets verwendet und asynchrone auf synchrone umbaut, statt
sie einfach wegzulassen.
Was mir besonders auffällt: Noch immer werden Synchronisations-FFs
eingesetzt, um instabile Zustände zu vermeiden, die Signale dann aber
asynchron weiter verwendet, oder sie werden synchron weiter verwendet
und unnötig eingetaktet.
Servus Markus,
Da mich das Thema Reset auch interessiert (Altera), hast du da ein paar
Beispiele zur Hand wie ich ein VHDL Modul vernünftig Beschreibe, um
asynchron rein und synchron raus aus dem Reset gehe?
Grüße
Man kann eine Wissenschaft draus machen oder lässt es sein. Alles
synchron geht immer, egal welcher Hersteller. Entsprechend ist das auch
meine erste Wahl etwas zu beschreiben -> es ist universell.
Da man das sowieso nur an wenigen Stellen und lokal braucht, kann man es
auch so machen ohne das es jetzt großartig Logik/Timing verbraucht.
Den Startupreset kann man über Init-Werte machen.
FPGA zum Spass schrieb im Beitrag #5938887:
> Man kann eine Wissenschaft draus machen oder lässt es sein.
Was hast du gegen Wissen?
FPGA zum Spass schrieb im Beitrag #5938887:
> Den Startupreset kann man über Init-Werte machen.
Auch beim Altera?
Edi M. schrieb:> FPGA zum Spass schrieb im Beitrag #5938887:>> Den Startupreset kann man über Init-Werte machen.> Auch beim Altera?
Jein (soll heißen: logisch jedenfalls, physisch nicht unbedingt).
Je nach Device bzw. Architektur kommen bei Intel/Altera die Register
beim Start ausschliesslich mit '0' hoch (weil die Architektur keine
Presets erlaubt).
Über einen 'Trick' ("NOT gate push-back", standardmässig bei solchen
Devices aktiviert) fügt die Synthese vor und hinter mit '1' zu
initialisierende Register ein NOT ein. Dann sieht's nach aussen richtig
aus und verhält sich auch "richtig".
Das "NOT gate push-back" kann man ausschalten. Dann hat sich's was mit
/= '0' initialisieren und man muss den Reset benutzen.
Edi M. schrieb:> Was hast du gegen Wissen?
So war es nicht gemeint.
Wir bewegen uns hier(asynchrone Resets) in einem Bereich den kaum jemand
überhaupt beherrscht und verwenden soll es dann jeder der hier
reinkuckt, was vielfach Anfänger sind.
Das kann doch nur schief gehen und zu Frust führen.
Markus F. schrieb:> Das "NOT gate push-back" kann man ausschalten. Dann hat sich's was mit> /= '0' initialisieren und man muss den Reset benutzen.
Und warum sollte man es ausschalten, wenn man es benutzen will?
Ich benutze seit 10 Jahren nur Init-Werte, sowohl bei Xilinx als auch
Altera.
Resets(synchrone) gibt es nur an wenigen Stellen, für wenig Signale.
Probleme hatte ich damit bisher nie, was dafür spricht das diese Methode
wohl recht gut funktioniert.
Eine Ausnahme: ein alter Xilinx CPLD schien das nicht zu beherrschen.
FPGA zum Spass schrieb im Beitrag #5941695:
> Wir bewegen uns hier(asynchrone Resets) in einem Bereich den kaum jemand> überhaupt beherrscht und verwenden soll es dann jeder der hier> reinkuckt, was vielfach Anfänger sind.> Das kann doch nur schief gehen und zu Frust führen.
Na ja, asynchrone resets sind doch keine Raketentechnik.
Manches Mal braucht man eben einen Reset und kommt nicht nur mit Inits
aus (z.B. wenn man nur einen Teil des Designs zurücksetzen will).
Wenn man dann ein FPGA hat, dessen Flipflops asynchrone CLR-Eingänge
haben, wäre es Resourcen- und Performanceverschwendung, die nicht zu
benutzen (dasselbe 4-Bit Register braucht bei einem Cyclone mit
synchronem Reset 7 Logic Cells, während es mit asynchronem Reset mit 4
auskommt).
Manchmal braucht man's, meist (tatsächlich) nicht, aber wenn man's
braucht, ist's geschickt.
Der Nachteil ist halt die mangelnde Portierbarkeit, aber irgendwas ist
ja immer.
Donni D. schrieb:> Servus Markus,> Da mich das Thema Reset auch interessiert (Altera), hast du da ein paar> Beispiele zur Hand wie ich ein VHDL Modul vernünftig Beschreibe, um> asynchron rein und synchron raus aus dem Reset gehe?>> Grüße
Ach, da ist ja noch was offen - sorry, habe ich übersehen.
Ich mach' das so:
(meine Interpretation von Intel/Altera AN545, S.11 ff)
Mit dem Output kann man an alle asynchronen CLR-Eingänge in derselben
Taktdomäne (jede braucht ihren eigenen Sync). Wenn man (übrig) hat,
sollte der Reset ein "global signal" werden.
Markus F. schrieb:> meine Interpretation von Intel/Altera AN545, S.11
Das Design ist m.E. nicht völlig robust gegen kurze Spikes/Störungen auf
dem Reset-Eingang. Denn ggfs. setzt so ein Spike nicht alle Flipflops
der Kette zurück. Aber letztlich ist das ein Spiel mit
Wahrscheinlichkeiten.
Ich würde für "absolute Sicherheit" den Reset auch bei den Intel/Altera
FPGAs Einsynchronisieren gleich noch passend Entprellen und erst dann
aufs Reset-Netzwerk geben... ?
Lothar M. schrieb:> Denn ggfs. setzt so ein Spike nicht alle Flipflops> der Kette zurück
Braucht es doch auch garnicht. Ich sehe zumindest nicht wo geprüft wird
das alle Stages '0' sind bevor der Reset rausgeht.
Ein Spike der das oberste Bit von Reset_sync zurücksetzt und schon hat
man den Reset im ganzen System.
Denn nach dem Modul geht es bei Markus ja auch asynchron im ganzen FPGA
mit diesem Reset weiter.
Lothar M. schrieb:> Das Design ist m.E. nicht völlig robust gegen kurze Spikes/Störungen auf> dem Reset-Eingang. Denn ggfs. setzt so ein Spike nicht alle Flipflops> der Kette zurück. Aber letztlich ist das ein Spiel mit> Wahrscheinlichkeiten.
Haha, hab' ich's doch geahnt, dass dem Lothar das asynchrone Zeugs nicht
gefällt ;)
Keine Sorge, bei mir ist üblicherweise immer ein µC im Spiel, der - wenn
der Reset denn von aussen kommt - den entweder selbst erzeugt (dann habe
ich Kontrolle darüber) oder selbst am selben Reset hängt. Wenn dessen
Anforderungen an den Reset erfüllt sind, kommt das Design m.E. immer
damit zurecht.
Dafür freue ich mich daran, daß der Reset - wenn ich ihn denn brauche -
nicht den Datenpfad "verstopft" und Resourcen verbraucht. Wenn man noch
ein globales Signal übrig hat, kostet der praktisch nichts (alles
"sowieso da"-Logik).
FPGA zum Spass schrieb im Beitrag #5944596:
> Ein Spike der das oberste Bit von Reset_sync zurücksetzt und schon hat> man den Reset im ganzen System.
Wenn das Ding so klapprig ist, daß in einem absolut synchronen Design
plötzlich Registerbits kippen, dann ist das Beste, was ihm passieren
kann, ein systemweiter Reset...
Ich ging davon aus das dein "reset_n" der reinkommt von einem Pin kommt.
Wenn nicht, dann sieht es schon viel besser aus, nur weiß das halt
keiner und gerade für Anfänger kommt der Reset oft vom Button. Das wird
dann schon "gefährlich" wenn man das so direkt benutzt.
FPGA zum Spass schrieb im Beitrag #5944596:
> Ein Spike der das oberste Bit von Reset_sync zurücksetzt und schon hat> man den Reset im ganzen System.
Richtig, und das untere Bit wird nicht zurückgesetzt und sofort danach
kommt eine Taktflanke und der Reset ist blitzartig wieder weg und bei
der Hälfte der Flipflops wurde die tsu verletzt. Das meint ich mit
Wahrscheinlichkeiten...
Markus F. schrieb:> Wenn das Ding so klapprig ist, daß in einem absolut synchronen Design> plötzlich Registerbits kippen
Kenne ich aus einer meiner Jugendsünden: den Reset lehrbuchmäßig direkt
vom Pin zum "if (reset='0') then" geführt und beim Einschalten des
Lötkolbens machte das Design kurioseste Dinge, weil ein paar Register
zurückgesetzt wurden. Da ist man dann schon mal eine Woche am Suchen.
> dann ist das Beste, was ihm passieren kann, ein systemweiter Reset...
Schon, aber der muss dann schon mindestens für 1 Takt lang anliegen,
damit der ganze Laden bereit ist für den Neubeginn.
Wenn es unbedingt und warum auch immer ein asynchron aktivierbarer Reset
sein muss, dann würde ich auf sowas aufbauen:
http://www.lothar-miller.de/s9y/archives/19-Kurzer-Spike-in-Puls-umgewandelt.html
Denn durch dieses erste Flipflop wird eine Resetflanke so lange
gespeichert, bis der Reset am Ende der synchronen Schieberegisterkette
ankommt. Und weil der Reset eben nur und genau auf dieses eine erste
Flipflop geht, kann es da keine Doppeldeutigkeiten geben. Entweder
schafft es ein Spike, das FF zu triggern, oder er schafft es nicht. Im
ersten Fall hat man tatsächlich einen definierten Reset, im zweiten Fall
gewissermaßen "Glück" gehabt... ;-)
Sorry Jungs, seid mir nicht böse, aber die originale Frage war:
Donni D. schrieb:> wie ich ein VHDL Modul vernünftig Beschreibe, um> asynchron rein und synchron raus aus dem Reset gehe?
und die habe ich 1:1 (anhand einer AN des Herstellers) versucht zu
beantworten (ich jedenfalls bin bisher immer gut damit gefahren,
Herstellerempfehlungen zu befolgen, die wissen üblicherweise selbst am
besten, wie ihr Geraffel funktioniert).
Der Hinweis, dass das mit einem "zittrigen" reset_n schief gehen kann,
ist gut und richtig, hat aber letztendlich mit der Frage nur am Rande zu
tun.
Jedenfalls weiß Donni jetzt, wie's asynchron geht und es bleibt ihm
selbst überlassen, ob er das 1:1 so übernimmt (weil er vielleicht
ähnliche "äussere Umstände" hat wie ich), nochmal "Entzitter"-Logik
davorhängt, über äussere Beschaltung dafür sorgt, dass reset_n bestimmte
Mindestanforderungen erfüllt oder doch lieber mit synchronen Resets
arbeitet.
Wenn man einen Reset braucht, hat der asynchrone ein paar Vorteile, die
ich jedenfalls nicht aufgeben möchte (in den Links in der AN545 wird
das ausführlich diskutiert).
Danke für Eure rege Beteiligung.
Markus F. schrieb:> und die habe ich 1:1 (anhand einer AN des Herstellers) versucht zu> beantworten
Passt soweit. Der Synthesizer wird aus deiner Beschreibung das bauen,
was Altera empfiehlt.
> ich jedenfalls bin bisher immer gut damit gefahren, Herstellerempfehlungen> zu befolgen, die wissen üblicherweise selbst am besten, wie ihr Geraffel> funktioniert.
Man darf sie aber auch mal ruhig hinterfragen. Nicht jede AppNote ist
unbedingt vom besten Ingenieur geschreiben worden. Manche ganz
offensichtlich sogar vom Praktikanten... :-/
> Wenn man einen Reset braucht, hat der asynchrone ein paar Vorteile, die> ich jedenfalls nicht aufgeben möchte
Du kannst die Altera Flipflops (genauso wie die von Lattice) ja nur
mit asynchronem Reset bekommen und musst ggfs. auch für ein
effizientes synchrones Design den asynchronen Reset-Eingang verwenden.
Ob es generell einen Reset samt Resettaster braucht, steht auf einem
anderen Blatt. Meine Designs haben sowas nicht.
das ganze Intel/Altera-spezifisxche Zeug macht nur unglücklich.
Falls reset_i von extern kommt (Taster), dann muss man tiefpassfiltern.
Oder habe ich das Problem bzw. die Frage nicht verstanden?
Markus, du hast Recht. Als Antwort auf die Frage ist das schon alles gut
und richtig.
Ob man es nutzt ist dann die zweite Frage, muss jeder für sich
beantworten.
Für mich als aktuell Altera-only Nutzer wäre das sogar interessant, weil
ich einige Stellen im Design habe die einen per gesteuerten Reset
brauchen und sowohl timingkritisch als auch ressourcenkritisch sind.
Leider gibt es wohl keine vernünftige Art und Weise das wahlweise
hinzuschreiben und ich will die Sachen schon gerne herstellerunabhängig
halten.
Habe schonmal überlegt beide Reset hinzuschreiben und dann zentral an
einer Stelle nur einen zu verdrahten und den anderen auf konstant
inaktiv zu setzen. Soll sich die Synthese halt drum kümmern.
Was haltet ihr davon?
Beispiel:
FPGA zum Spass schrieb im Beitrag #5945858:
> Habe schonmal überlegt beide Reset hinzuschreiben und dann zentral an> einer Stelle nur einen zu verdrahten und den anderen auf konstant> inaktiv zu setzen. Soll sich die Synthese halt drum kümmern.> Was haltet ihr davon?
wenn ich beides 'umschaltbar' haben wollte, würde ich entweder
versuchen, das mit generate hinzutricksen (müsste sogar 'schaltbar' über
ein Toplevel-Generic - heißt in Quartus dann 'Default Parameter' -
gehen) oder eine Configuration verwenden.
das generic kannst Du in den Project Settings unter "Default Parameters"
setzen. Dann muss nur noch deine "andere" Plattform auch damit
zurechtkommen (wenn die Default-Einstellung "FALSE" ist, brauchst Du
dort kein Toplevel-Generic).
Das "else generate" ist eine VHDL 2008-Erweiterung, die läßt sich aber
durch "end generate; if not ALTERA_ASYNC_RESET generate" funktionsgleich
ersetzen.
Wie man ein Generate schreibt ist mir schon klar. Das Generic würde bei
mir dann am Toplevel hängen, das wäre eh für jedes Board etwas anders.
Das meinte ich aber gar nicht.
Mir ging es nicht darum den Master Reset asynchron oder synchron zu
machen, das bringt von den Ressourcen her ja eh praktisch nix bei den
paar FFs, sondern so wie ich dich verstanden habe benutzt du den ja dann
auch asynchron weiter im Design.
Das heißt, ich muss das ja dann mit jedem Modul machen das den Master
Reset verwendet. Und ich will nun wirklich nicht unterschiedliche
Architectures für alle Module machen.
FPGA zum Spass schrieb im Beitrag #5946997:
> Das heißt, ich muss das ja dann mit jedem Modul machen das den Master> Reset verwendet. Und ich will nun wirklich nicht unterschiedliche> Architectures für alle Module machen.
Pro Taktdomäne musst Du das nur einmal machen - wenn Du also nicht 'zig
Takte hast, ist der Aufwand einigermassen überschaubar.
Dann habe ich irgendetwas falsch verstanden.
Bei mir sind alle Resets die ich nutze als synchrone definiert (erst
rising_edge, dann reset/else).
Profitiere ich jetzt von den ALTERA Asynch-Resets schon dann, wenn ich
den Master Reset asynchron erzeugt habe?
Wann ja, wieso?
Merkt die Synthese das oder wie?
Ähmm, nö. Mein Fehler.
Natürlich mußt Du den "umschaltbaren" synchronen/asynchronen Reset
überall dort "mitziehen", wo Du ihn brauchst. Da hab' ich nicht richtig
mitgedacht.
Ob dein "Trick" funktioniert, habe ich nicht ausprobiert. Probier's doch
einfach mal.