Frage zum "Einsynchronisieren" und "RESET"

[Jochen (Gast)]

Hallo Leute,

ich habe heute viel über bestimmte "Do´s" and "dont´s" im VHDL Design 
gelesen. Dabei war der Tenor immer wieder:

- Signale müssen einsynchronisiert werden (am besten über zwei 
FlipFlops)
- reset "IMMER" synchron

zum synchronen Reset habe ich mir viel von Lothar Miller durchgelesen 
und verstehe die Argumentation und halte das ganze für richtig und 
sauber erklärt. Mein Professor (stammt eher aus der ASIC-Entwicklung) 
hat uns allerdings auch immer erklärt, dass ein Reset generell Asynchron 
zu sein hat... (PS.: Das Whitepaper von Xilinx zum Thema habe ich 
bereits gelesen)

ABER: Ich habe mal nen kleines Testdesign zum einsynchronisieren 
gebastelt. Die Synthese hab ich mir dann im RTL Viewer angeschaut. Ich 
habe 3 Varianten getestet:

1. gar kein RESET  (Bild VARIANTE 1)
2. asynchroner RESET (Bild Variante 2)
3. synchroner Reset (Bild Variante 3)

1. Frage
========
Komischerweise habe ich erwartet, dass in Variante 2/3 der Reset auf den 
ClearEingang des FF geht. Dies tut er aber nur, wenn ich ihn asynchron 
beschreibe. Warum?

2. Frage
========
Gibt es eine elegante Methode, die Einsynchronisierung über zwei FF 
laufen zu lassen? Mir würde höchstens einfallen, die Signale zwei mal 
über den von mir beschriebenen Code einzusynchronisieren. Oder reicht 
die Einsych. über ein FF völlig aus?

Hier noch mein Code der drei Varianten.

LIBRARY ieee;
USE ieee.std_logic_1164.all;
USE ieee.numeric_std.all;


ENTITY ydf IS
  PORT
  (
    sig1        : IN std_logic;  
    sig2        : IN std_logic;
    reset        : IN std_logic;
    clk        : IN std_logic;
    
    sig1_out        : OUT std_logic;
    sig2_out        : OUT std_logic
    );
END ENTITY;

ARCHITECTURE rtl OF ydf IS
                        
  BEGIN  
-- Variante 1
--    PROCESS(clk)
--    BEGIN
--    if rising_edge(clk) then
--      
--        sig1_out <= sig1;
--        sig2_out <= sig2;
--      
--    end if;
--    END PROCESS;
    
--  --Variante 2                      
--  
--    PROCESS(clk)
--    BEGIN
--    if reset = '1' then
--        sig1_out <= '0';
--        sig2_out <= '0';
--    
--    elsif rising_edge(clk) then
--      
--        sig1_out <= sig1;
--        sig2_out <= sig2;
--      
--    end if;
--    END PROCESS;
    
--  --Variante 3                      

    PROCESS(clk)
    BEGIN
    if rising_edge(clk) then
      if reset = '1' then
        sig1_out <= '0';
        sig2_out <= '0';
      else
        sig1_out <= sig1;
        sig2_out <= sig2;
      end if;
    end if;
    END PROCESS;
END;

[daniel__m (Gast)]

Jochen schrieb:
> Komischerweise habe ich erwartet, dass in Variante 2/3 der Reset auf den
> ClearEingang des FF geht. Dies tut er aber nur, wenn ich ihn asynchron
> beschreibe. Warum?

Da kann es mehrere Gründe geben. Der übliche ist, dass die Toolchain den 
Set/Reset über die LUT nachbildet, um damit ein sogenanntes 
"control-set" zu sparen. Vom Verhalten, welches du beschrieben hast, ist 
es absolut identisch.

Jochen schrieb:
> Oder reicht
> die Einsych. über ein FF völlig aus?

Geht genauso, hängt lediglich davon ab, wie hoch die 
Restwahrscheinlichkeit sein soll, dass es mal nicht geht. Das 
Einsynchronisieren hat 2 Aufgaben

1) für die Metastabilität sorgen (bei aktuellen FPGAs grob gesagt erst 
ab 200MHz relevant). Je höher die Frequenz desto mehr FFs in Reihe 
benötigst du. Evtl. auch mal mehr wie 2 FFs.

2) dafür zu sorgen, dass, wenn das Signal an mehrere FF geht, alle das 
gleiche Signal sehen, Stichpunkt Laufzeitunterschiede zu den 
State-Machine-FFs. Für diesen Fall genügt 1 FF völlig.

gruß

[Jochen (Gast)]

daniel__m schrieb:
> Da kann es mehrere Gründe geben. Der übliche ist, dass die Toolchain den
> Set/Reset über die LUT nachbildet, um damit ein sogenanntes
> "control-set" zu sparen. Vom Verhalten, welches du beschrieben hast, ist
> es absolut identisch.

Ah, ok... Wieder völlig neue Begriffe für mich. Was ist ein 
"Control-set" genau? Bedeutet das, dass die Toolchain das macht, um das 
Clear nicht nutzen zu müssen? Ist der vorgeschaltete Mux nicht 
aufwändiger?

Danke für deine Antwort!

[Jürgen S. (engineer)]

Zum generellen Einsynchronisieren und dem überschätzten Problem der 
Metastabilität gibt es im Bereich FPGA einiges in den Artikeln.

http://www.mikrocontroller.net/articles/FPGA

[Jochen (Gast)]

Danke Jürgen! Werd ich lesen und mich bei offenen Fragen dazu nochmals 
melden!

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

Jochen schrieb:
> Komischerweise habe ich erwartet, dass in Variante 2/3 der Reset auf den
> ClearEingang des FF geht. Dies tut er aber nur, wenn ich ihn asynchron
> beschreibe. Warum?
Welche Zielplattform verwendest du?
Für den Spartan3 gilt das, was im 
Beitrag "Re: Hardware mit VHDL "richtig" beschreiben." untersucht wurde, bei 
nachfolgenden FPGA-Generationen hat sich da durchaus was geändert (und 
es ist auch ein Unterschied, ob ich V6 oder S6 verwende), und auch bei 
anderen Herstellen lohnt es sich, solche Grundlagenfragen vorab an ein 
paar kleinen Dreizeilern zu untersuchen (so, wie du es hier offenbar 
machst).

Als Tipp: bei Xilinx heißen synchrone Signale Reset und Set, asynchrone 
Signale heißen Clear und Preset.

> Mein Professor hat uns allerdings auch immer erklärt, dass ein Reset
> generell Asynchron zu sein hat...
Ja, schade nur, dass man mit solchen Verallgemeinerungen evtl. die 
Ressourcen des Bausteins nicht gut ausnützt...

[Jochen (Gast)]

Hallo Lothar,

Lothar Miller schrieb:
> Welche Zielplattform verwendest du?

Daheim verwende ich einen Cyclone III C6
Auf der Arbeit verwende ich im Rahmen meiner Masterthesis einen ArriaV. 
Zielplattform wird dann aber ein StratixV sein.

Lothar Miller schrieb:
>> Mein Professor hat uns allerdings auch immer erklärt, dass ein Reset
>> generell Asynchron zu sein hat...
> Ja, schade nur, dass man mit solchen Verallgemeinerungen evtl. die
> Ressourcen des Bausteins nicht gut ausnützt..

Ich werde auf jeden Fall "alle" Signale einsynchronisieren, da mir deine 
Argumentation als logisch erscheint. Danke dir.

Hast du evtl. dazu auch einen Tipp?`Wäre super (PS.: Post#2 ist 
relevant)
Beitrag "Simulation - Bei Abtastung anliegendes Signal übernehmen"

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

Jochen schrieb:
> Cyclone III C6  ...  StratixV
Da passt natürlich ein Xilinx Whitepaper wie die Faust aufs legendäre 
Auge...  ;-)

> Ich werde auf jeden Fall "alle" Signale einsynchronisieren
Es hat keinen Sinn, z.B. 32 Bits eines Busses einzutakten. Hier muss ein 
anderer Synchronisationsmechanismus her. IdR. ist das dann ein Write- 
oder Latch-Signal...

[Jochen (Gast)]

Lothar Miller schrieb:
>> Cyclone III C6  ...  StratixV
> Da passt natürlich ein Xilinx Whitepaper wie die Faust aufs legendäre
> Auge...  ;-)

Ja, natürlich nicht... eigentlich. Aber ich denke, dass die Unterschiede 
nicht so groß sein werden?!?! Vom Prinzip her ist die Grundlage, die 
dahinter steht doch die gleiche?!?!

Lothar Miller schrieb:
> Es hat keinen Sinn, z.B. 32 Bits eines Busses einzutakten. Hier muss ein
> anderer Synchronisationsmechanismus her. IdR. ist das dann ein Write-
> oder Latch-Signal...

Interessant. Hast du dazu evtl. auch schon einen kleinen Artikel 
verfasst?

[Marcus H. (mharnisch)]

Jochen schrieb:
>> Es hat keinen Sinn, z.B. 32 Bits eines Busses einzutakten. Hier muss ein
>> anderer Synchronisationsmechanismus her. IdR. ist das dann ein Write-
>> oder Latch-Signal...
>
> Interessant. Hast du dazu evtl. auch schon einen kleinen Artikel
> verfasst?

Dazu brauchts keinen Artikel. Das Einsynchronisieren ist nur bei 
unabhängigen Signalen sinnvoll, da Du nicht vorhersehen kannst ob der 
"richtige" Wert jedes einzelnen Signals bereits im ersten oder erst im 
zweiten Zyklus übernommen wurde.

[Schlumpf (Gast)]

Ich generiere den globalen Reset immer wie im Anhang gezeigt.
Asynchroner Reset und synchrones "Wegnehmen" des Resets.
Dieses zentral erzeugte Reset-Signal wird über GSR an alle asynchronen 
Resets der Register des Designs geführt.

[Jürgen S. (engineer)]

Jochen schrieb:
> Mein Professor (stammt eher aus der ASIC-Entwicklung)
> hat uns allerdings auch immer erklärt, dass ein Reset generell Asynchron
> zu sein hat...

Vielleicht meinte er, dass man ihn als asynchron anzusehen hat, denn so 
macht die Aussage keinen Sinn.

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

Marcus Harnisch schrieb:
>>> Es hat keinen Sinn, z.B. 32 Bits eines Busses einzutakten. Hier muss ein
>>> anderer Synchronisationsmechanismus her. IdR. ist das dann ein Write-
>>> oder Latch-Signal...
>> Interessant. Hast du dazu evtl. auch schon einen kleinen Artikel
>> verfasst?
> Dazu brauchts keinen Artikel. Das Einsynchronisieren ist nur bei
> unabhängigen Signalen sinnvoll
Und ein Signal auf einem Datenbus ist nicht unabhängig. Sondern es 
hängt von irgendwelchen Steuersignalen ab. Deshalb muss man das 
Steuersignal abtasten und abhängig von diesem einzigen 
einsynchronisiserten Signal dann die 32 Bits Daten einlesen.

[Jochen Peters aus München (Gast)]

Lothar Miller schrieb:
> Und ein Signal auf einem Datenbus ist nicht unabhängig. Sondern es
> hängt von irgendwelchen Steuersignalen ab. Deshalb muss man das
> Steuersignal abtasten und abhängig von diesem einzigen
> einsynchronisiserten Signal dann die 32 Bits Daten einlesen.

Hmm... Das heißt also für mein reales Problem:

Ich bekomme pro Takt vom Avalon-ST Bus ein Signal mit 64 Bit. Dazu gibt 
es ein Valid Signal. Wenn das '1' ist, kann ich die Daten übernehmen.

Daraus folgt:

Ich synchronisiere das Validsignal ein und nehme die Daten bei der 
steigenden Flanke des Takts wenn Valid = '1'. Der Takt der Daten und der 
Übernahmetakt meines Designs sind gleich (bzw. bekomme ich den Takt vom 
Avalon ST)

[Jürgen S. (engineer)]

Das ist aber hier kein "Einsynchronisieren" wie es üblicherweise 
verstanden wird, sondern Du nutzt doch ein bereits synchrones Signal. 
Der Avalon Mechanismus ist doch IM FPGA und nicht extern. Das valid ist 
ein ganz normales enable.

[Jochen Peters aus München (Gast)]

Juergen Schuhmacher schrieb:
> er Avalon Mechanismus ist doch IM FPGA und nicht extern. Das valid ist
> ein ganz normales enable.

Stimmt... Man, ich glaub es reicht erstmal.

Ich danke euch, für die vielen Antworten. Hab wirklich viel dabei 
gelernt. Ich wünsch euch nun ein schönes Wochenende!

[Schlumpf (Gast)]

Wenn der Quell- und Zieltakt wirklich identisch sind, also die gleiche 
Takt Quelle haben, dann kannst du dir das Ein takten sparen.
Du musst dann der Synthese nur in Form von Constraints mitteilen, in 
welchem Phasenbezug der Takt und die Daten am FPGA stehen.

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

Jochen Peters aus München schrieb:
> Ich bekomme pro Takt vom Avalon-ST Bus ein Signal mit 64 Bit. Dazu gibt
> es ein Valid Signal. Wenn das '1' ist, kann ich die Daten übernehmen.
Soweit richtig.
> Daraus folgt:
> Ich synchronisiere das Validsignal ein
Das ist unnötig, weil der Avalon-Bus bereits synchron zum "eigenen" Takt 
ist. Und wenn dieser Takt auch der Takt deines Systems ist, dann ist 
schon alles synchron und du musst nur noch mit der steigenden Flanke auf 
valid='1' abfragen:

   process (clk) begin
     if valid='1' then       -- valid ist synchron zum Takt
       mydata <= avalondata; -- und sogar die Daten sind synchron zum Takt,
     end if;                 -- mindestens aber stabil, wenn valid='1' ist
   end process;