FPGA Synchronisation

[Philipp S. (Gast)]

Ich möchte in einem getakteten Prozess ein externen signal einlesen, 
welches als trigger für einen ADC im fpga dient. Dieser trigger kommt 
von extern und ist asynchron. Der Prozess läuft mit 60MHz. Muss ich 
solche Signale synchronisieren? Im schlimmsten Fall kann doch passieren, 
dass der etwas zu spät erkannt wird, was mir egal ist, denn der trigger 
ist deutlich langsamer als der ADC.

[rossi (Gast)]

Du musst vor allem sicherstellen, dass das externe Signal nur mit genau 
einem Register in die 60 Mhz Taktdomäne übernommen wird. Zwei Register 
direkt hintereinander schaden auch nicht. Metastabilität ist aber nicht 
wirklich ein relevantes Problem. Erst nach dem Samplen kannst du das 
synchronisierte Signal an beliebig viel weitere Logik verteilen.

Welchen FPGA verwendest Du?

[Vancouver (Gast)]

rossi schrieb:
> Metastabilität ist aber nicht
> wirklich ein relevantes Problem.

Metastabilität hat mich schon zu viele Stunden bei der Fehlersuche 
gekostet, als dass ich diese Aussage noch unterstützen könnte. Es ist 
'Best Practice', asynchrone Signale immer über zwei Registerstufen 
einzusamplen. Das kostet praktisch keine Ressourcen und das Thema MS ist 
damit statistisch für die nächsten 100000 Jahre vom Tisch.

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

Vancouver schrieb:
> Metastabilität hat mich schon zu viele Stunden bei der Fehlersuche
> gekostet, als dass ich diese Aussage noch unterstützen könnte.
Allerdings wird richtige Metastabilität eben oft mit fehlendem 
Einsynchronisieren verwechselt. Heute sind Flipflops im FPGA nach ein 
paar ns sicher irgendwo hingekippt und nicht mehr zwischen 0 und 1 
floatend:

http://www.lothar-miller.de/s9y/archives/62-Testaufbau-Metastabilitaet.html

> Es ist 'Best Practice', asynchrone Signale immer über zwei
> Registerstufen einzusamplen.
Das Hauptproblem (das hier auch immer wieder aufschlägt) sind fast 
ausschließlich solche Effekte mit unterschiedlichen Laufzeiten von nicht 
synchronisierten Eingangssignalen im FPGA:

http://www.lothar-miller.de/s9y/archives/64-State-Machine-mit-asynchronem-Eingang.html

Und die Ausrede: "Ich habe da gar keine FSM!" fällt dann meist ganz 
schnell, wenn man sich vergegenwärtigt, dass auch schon ein simpler 
Zähler ein Zustandsautomat ist...

rossi schrieb:
> dass das externe Signal nur mit genau einem Register in die 60 Mhz
> Taktdomäne übernommen wird.
Und weil sich da ggfs. der Synthesizer mit per Register-Duplication doch 
Freiheiten herausnimmt, sind 2 Register hintereinander der Weg zum Ziel. 
Denn dann wird das erste FF sicher nicht dupliziert und es gibt nur 1 
Laufzeit bis zum 1. Register. Ab da kann dann beliebig dupliziert 
werden.

Philipp S. schrieb:
> Ich möchte in einem getakteten Prozess ein externen signal einlesen
Du denkst in Software. Ein Prozess "liest" kein Signal ein. Sondern ein 
Prozess beschreibt bestenfalls ein Flipflop, das den Zustand eines 
externen Signals abhängig von einem internen Takt speichern soll.

[Messtechnikprofi (Gast)]

Lothar M. schrieb:
> Allerdings wird richtige Metastabilität eben oft mit fehlendem
> Einsynchronisieren verwechselt.
Den Eindruck habe ich auch. Jeder bachelor der mal etwas von FPGAs 
gehört hat, bekommt von seinem schlecht informierten 
Was-bin-ich-so-stolz-dass-ich-mich-Professor-nennen-darf Lehrmeister an 
der dualen Hochschule etwa von Meta erzählt und findet es toll, dass er 
es bekämpfen kann.

Dabei wird verkannt, dass es oft falsch einsynchronisierte Busse und 
Signalgruppen sind, deren Zustand durch ein scheinbar technisch 
richtiges- aber aus Logiksicht unzureichendes Eintakten zerpflückt wird.

Schlecht, wenn man nicht in der Lage ist, Problemstellungen zu erfassen 
und einzuordnen.

> Heute sind Flipflops im FPGA nach ein
> paar ns sicher irgendwo hingekippt und nicht mehr zwischen 0 und 1
> floatend

"Picosenkunden" wolltest du sicher schreiben. Nano wäre etwas langsam 
:-)

[Vancouver (Gast)]

Ja, vermutlich ist die fehlende Synchronisation meistens die 
Fehlerursache. Aber wir hatten vor einigen Jahren im Labor mal echte 
Metastabilität fabriziert, auf einem Virtex-5, der CPU-Steuersignale in 
eine 100MHz-Domain einsamplen sollte. Hin und wieder erschien satt des 
Signalzustandes auf dem Logi völlig wirres Zeug und der FPGA verhielt 
sich teilweise, sagen wir... indeterministisch und die Stromaufnahme 
stieg drastisch an. Eine FSM blieb z.B. in einem ungültigen Zustand 
hängen usw. Blieb nur der Reset. Das Problem verschwand, nachdem ich 
meine Hausaufgaben gemacht und alle Signale 2-stufig einsynchronisiert 
hatte.

Das Problem mit der Metastabilität ist, dass sie sich, auch wenn sie nur 
kurz dauert, mit einer gewissen Wahrscheinlichkeit in die nächste Stufe 
überträgt und dann zur Logik-Demenz führt.

[rossi (Gast)]

Vancouver schrieb:
> Das Problem mit der Metastabilität ist, dass sie sich, auch wenn sie nur
> kurz dauert, mit einer gewissen Wahrscheinlichkeit in die nächste Stufe
> überträgt und dann zur Logik-Demenz führt.

"Kurz" sind aber wirklich nur Nanosekunden oder noch viel weniger. Schon 
1997 hat Xilinx bei damals aktuellen FPGAs in 0.5 Mikron Technik keine 
Probleme bei < 100 MHz Takt gesehen. [XAPP 094 November 24, 1997 
(Version 2.1)] Da war der metastabile Zustand lange aufgelöst, bevor die 
nächste Taktflanke kommt.

Das echte Problem ist die automatische Register-Duplizierung, die Lothar 
M. angesprochen hat und das selbst bei trivialen Sachen das asynchrone 
Signal einen Fanout größer 1 hat.

process(clk)
begin
  if rising_edge(clk) then
    if (trigger_async = '1') then
      next_adc_sample <= adc_data(15 downto 0);
    end if;
  end if;
end process;

Sowas kann schon schief gehen, wenn trigger_async zu unterschiedlichen 
Zeiten an den einzelnen Registern für die Bits ankommt.

[Ole W. (ole_w)]

Also wenn du Vivado nutzt, dann gibt es da ganz händische Blöcke die das 
Einsynchronisieren für dich gleich übernehmen.

  xpm_cdc_async_rst_inst : xpm_cdc_async_rst
  GENERIC MAP(
    DEST_SYNC_FF => 4, -- integer;
    INIT_SYNC_FF => 0, -- integer; 
    RST_ACTIVE_HIGH => 1 -- integer; 
  )
  PORT MAP(
    src_arst => FPGA_RESET_ASYNC
    dest_clk => FPGA_MAIN_CLK,
    dest_arst => FPGA_RESET_SYNC
  );

Hat für mich den Job bis jetzt wunderbar erledigt.

Gruß,
Ole

[rossi (Gast)]

Wenn man Vivado verwendet, kann man das Attribut ASYNC_REG für die 
Register in einer Synchronisierungskette setzen. Das sorgt dafür, das 
die Register nicht wegoptimiert werden und nahe beieinander platziert 
werden.

https://www.xilinx.com/content/dam/xilinx/support/documents/sw_manuals/xilinx2021_2/ug912-vivado-properties.pdf

[Martin S. (strubi)]

Fuer externe (!) Triggereingaenge nehme ich gerne sowas (allerdings 
architekturabhaengig):

entity pulsestrobe is
    port (
        trigger : in std_ulogic;
        strobe : out std_ulogic;
        en : in std_ulogic;
        clk : in std_ulogic
    );
end entity pulsestrobe;

architecture myhdl_emulation of pulsestrobe is
    -- Local type declarations
    -- Signal declarations
    signal pset : std_ulogic := '0';
    signal pout : std_ulogic := '0';
    signal clk_fb97 : std_ulogic;
    signal reset : std_ulogic;
begin
    
trigger_strobe:
    process(clk_fb97, reset)
    begin
        if reset = '1' then
            pset <= '0';
        elsif rising_edge(clk_fb97) then
            if (en = '1') then
                pset <= '1';
            end if;
        end if;
    end process;
    
trigger_ff:
    process(clk)
    begin
        if rising_edge(clk) then
            pout <= pset;
        end if;
    end process;
    clk_fb97 <= trigger;
    reset <= pout;
    strobe <= pout;
end architecture myhdl_emulation;

Nimmt allerdings auch jeden Glitch mit und 'verschwendet' allenfalls 
etwas Clock-Routing-Resourcen, somit ist es nicht optimal portabel. MS 
kann natuerlich von pset -> pout noch auftreten.
Ansonsten moechte man vielleicht sowieso entprellen, damit hat sich 
obige Thematik erledigt.

[Hannes B. (Gast)]

Mach dir doch nicht ins Hemd wegen Trigger glitches. Da passiert nichts 
und da muss auch nichts einsynchronisiert werden. EInen Trigger in einem 
getakteten Prozess zu nutzen ist vollkommen in Ordnung.