Altera Reset Synchronizer richtig machen

[resetto_risotto (Gast)]

Hallo zusammen,
ich verzweifle gerade an einem Reset-Synchronizer für 
Altera/Intel-FPGAs. Folgenden Code nutze ich:

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

library altera;
use altera.altera_syn_attributes.all;

entity altera_cdc_reset is
    generic(
        DEPTH : positive := 2                     -- Number of stages for synchronization
    );
    port(
        clk_i   : in  std_ulogic;
        reset_i : in  std_ulogic;
        reset_o : out std_ulogic
    );
end entity altera_cdc_reset;

architecture rtl of altera_cdc_reset is
    signal chain     : std_ulogic_vector(DEPTH - 1 downto 0) := (others => '1');
    signal chain_out : std_ulogic                            := '1';

    -- preserve chain registers (no optimization, shift register extraction, ...)
    attribute PRESERVE of chain : signal is true;

    -- see altera_reset_synchronizer.v
    attribute ALTERA_ATTRIBUTE of reset_i : signal is "SUPPRESS_DA_RULE_INTERNAL=R101";

begin
    process(clk_i, reset_i)
    begin
        if reset_i then
            chain     <= (others => '1');
            chain_out <= '1';
        elsif rising_edge(clk_i) then
            chain     <= reset_i & chain(chain'high downto 1);
            chain_out <= chain(0);
        end if;
    end process;

    reset_o <= chain_out;
end architecture rtl;

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.

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?

[Markus F. (mfro)]

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?

[resetto_risotto (Gast)]

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).

[Markus F. (mfro)]

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.

[FPGA zum Spass (Gast)]

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:

if rising_edge(clk_i) then
   if reset_i then
      chain     <= (others => '1');
      chain_out <= '1';
   else
      chain     <= reset_i & chain(chain'high downto 1);
      chain_out <= chain(0);
   end if;
end if;

sowohl hier als auch dort wo du den Reset dann nutzt.

[Hamburger (Gast)]

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.

[Markus F. (mfro)]

Bei Altera heißt es: asynchron in den Reset, synchron wieder raus.

Wobei letzteres m.E. wesentlich schwieriger richtig hinzubekommen ist.

[Donni D. (Gast)]

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

[FPGA zum Spass (Gast)]

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.

[Edi M. (Gast)]

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?

[Markus F. (mfro)]

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.

[FPGA zum Spass (Gast)]

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.

[Markus F. (mfro)]

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.

[Markus F. (mfro)]

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:

library ieee;
use ieee.std_logic_1164.all;

entity master_reset is
    generic
    (
        NUM_RESET_SYNC_STAGES       : natural := 2
    );
    port
    (
        clk             : in std_ulogic;
        reset_n         : in std_ulogic;
        master_reset_n  : out std_ulogic
    );
end entity master_reset;

architecture reset_sync_arch of master_reset is
    attribute altera_attribute                      : string;
    signal reset_sync                               : std_ulogic_vector(NUM_RESET_SYNC_STAGES - 1 downto 0) := (others => '1');
    attribute altera_attribute of reset_sync        : signal is "-name SYNCHRONIZER_IDENTIFICATION ""FORCED IF ASYNCHRONOUS""";
    attribute altera_attribute of reset_sync_arch   : architecture is "-name SDC_STATEMENT ""set_false_path -to [get_registers {*|reset_sync[0]}] """;
begin
    p_sync : process(all)
    begin
        if not reset_n then
            reset_sync <= (others => '0');
        elsif rising_edge(clk) then
            reset_sync <= reset_sync(NUM_RESET_SYNC_STAGES - 2 downto 0) & '1';
        end if;
    end process p_sync;
    master_reset_n <= reset_sync(NUM_RESET_SYNC_STAGES - 1);
end architecture reset_sync_arch;

(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.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

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... ?

[FPGA zum Spass (Gast)]

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.

[Markus F. (mfro)]

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).

[Markus F. (mfro)]

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

[FPGA zum Spass (Gast)]

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.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

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...  ;-)

[Markus F. (mfro)]

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.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

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.

[Kest (Gast)]

Ich würde da gar nicht lange fackeln:

process(clk)
begin
  if rising_edge(clk) then
    if reset_i = '1' then
      reset_sync <= (others => '1');
    else
      reset_sync <= reset_sync(2 downto 0) & '0';
      master_reset <= reset_sync(2);
    end if;
  end if;
end process;

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?

[FPGA zum Spass (Gast)]

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:

process(clk,rst_a)
begin
  if (rst_a = '1') then
    cnt <= 0;
  elsif rising_edge(clk) then
    if rst_s = '1' then
      cnt <= 0;
    else
      cnt <= cnt + 1;
    end if;
  end if;
end process;

[Markus F. (mfro)]

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.

[Markus F. (mfro)]

ich hab's mal ausprobiert, so geht's (hier mit zwei 
architecture-Abschnitten, das Aufschreiben der synchronen architecture 
überlasse ich dir ;)):

    gen_reset: if ALTERA_ASYNC_RESET generate
        i_reset_sync : entity work.master_reset(altera_asynchronous)
            port map
            (
                clk => clk,
                reset_n => reset_n,
                master_reset_n => master_reset_n
            );
    else generate
        i_reset_sync : entity work.master_reset(others_synchronous)
            port map
            (
                clk => clk,
                reset_n => reset_n,
                master_reset_n => master_reset_n
            );
    end generate;

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.

[FPGA zum Spass (Gast)]

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.

[Markus F. (mfro)]

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.

[FPGA zum Spass (Gast)]

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?

[Markus F. (mfro)]

Ä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.