Flipflop und Latch

[Christian H. (cavorca)]

Hallo,

Als ich noch Einsteiger in die FPGA Welt war (mittlerweile sehe ich mich 
immerhin als Anfänger) habe ich hier in dem Forum gelernt, dass man 
Latches möglichst vermeiden sollte. Außer man weiß ganz genau was man 
tut.

In welchen Fällen sollte man denn besser ein Latch verwenden? Bzw. Wann 
bietet ein Latch Vorteile? Was gibt es in solchen Fällen beim Latch zu 
beachten?
Gibt es überhaupt Vorteile? Ich meine, werden FF und Latch nicht sowieso 
als D-FF realisiert? Ich meine der FPGA hat ja nichts anderes.

Viele Grüße,
Christian

[Jan M. (mueschel)]

>Ich meine, werden FF und Latch nicht sowieso
>als D-FF realisiert? Ich meine der FPGA hat ja nichts anderes.
Nein, die Hardware, die ein FF realisiert, kann auch als Latch 
konfiguriert werden.

In einem normalen, synchronen Design gibt es wohl keinen einzigen Fall, 
in dem man ein Latch benutzen sollte.

Erstellt man hingegen eine groessere, ungetaktete Logik (was ich aber 
noch nie gesehen habe), inklusive aller Konsequenzen die sich dann durch 
die Verbindung mit getakteten Teilen ergeben, kann man Latches durchaus 
nutzen.

[Christian H. (cavorca)]

Kannst du mir ein Beispiel geben?

[Jan M. (mueschel)]

Ein Beispiel fuer was? Die Verwendung eines Latches im FPGA? Im Prinzip 
in all denen Faellen, in denen man auch ein Latch in einer 
herkoemmlichen diskreten Schaltung verwenden wuerde und es durch die 
vielen Resourcen eines FPGA nicht ueberfluessig gemacht wird.
Aber wie gesagt, das ist äußerst unüblich.

[Fritz (Gast)]

ein Bsp. wäre z.B. das Latchen wenn der FPGA am Adress-Datenbus eines 
uCs hängt und der Takt des FPGAs für das Einsynchronisieren nicht 
reicht.

[Gast (Gast)]

Ein Latch ist ein halbes Flipflop. Latches verwendet man üblicherweise, 
wenn es auf Platz ankommt, dann aber auch nur wenn man wirklich genau 
weiss was man tut.
Ein Beispiel sind grosse Register-Files von Prozessoren, die intern als 
Latches aufgebaut sind, nach aussen aber durch entsprechende 
Zusatzbeschaltung aussehen wie Flipflops.

Ansonsten: Lass es bleiben! Du ärgerst dich nur tot, Simulation geht, 
Hardware nicht, oder vielleicht manchmal doch oder wieder doch nicht...

[Neueinsteiger (Gast)]

Ergibt sich ein Latch oder FF durch die Beschreibung und wenn ja - 
welche Konstrukte führen auf Latches?

Ich frage, weil ich bisher noch nicht explizit gesehen habe, daß ein 
Latch oder FF per Kommando erstellt wird.
(Hört sich vielleicht wirr an, wird aber hoffentlich klar was ich meine 
und, ja, ich bezeichne mich noch als Einsteiger. Nomen est Omen)

[Christian H. (cavorca)]

@Fritz: Ah interessantes Beispiel.

Gast wrote:
> Ein Latch ist ein halbes Flipflop. Latches verwendet man üblicherweise,
> wenn es auf Platz ankommt,
Ich dachte in FPGAs kann ein D-FF entwerder als FF oder als Latch 
konfiguriert werden? Also gleicher Platzverbrauch? Oder meinst du Asics 
und Schaltungen mit Logik ICs?

> dann aber auch nur wenn man wirklich genau
> weiss was man tut.

Darum geht es mir ja. Ich möchte lernen was es da zu wissen gibt. Also 
nicht unbedingt so genau, dass ich die Dinger einsetze, sondern 
vielleicht eine Stufe weiter als dieses "Lieber die Finger davon lassen"

> Ein Beispiel sind grosse Register-Files von Prozessoren, die intern als
> Latches aufgebaut sind, nach aussen aber durch entsprechende
> Zusatzbeschaltung aussehen wie Flipflops.
>
> Ansonsten: Lass es bleiben! Du ärgerst dich nur tot, Simulation geht,
> Hardware nicht, oder vielleicht manchmal doch oder wieder doch nicht...
Wie gesagt, ich plane nicht die Dinger einzusetzen, ich war nur 
neugierig.

[Falk B. (falk)]

@Lothar Miller (lkmiller)

>Es gibt getaktete Latches (D-Latch, in TTL: 74374, 74574).

Bitte nicht solche Begriffsverwirrungen!

Latch ist NICHT getaktet.
FlipFlop ist getaktet.

>Die werden dann einfach als FF synthetisiert.

Dieses ICs SIND FLipFLops. Nämlich 8 Stück in einem IC. Kann man auch 
als 8 Bit Register bezeichnen, aber NICHT als Latch.

MFg
Falk

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

@ Falk
Ok, du hast Recht. Ich habe den fehlerhaften Beitrag gelöscht und hier 
nochmal korrigiert eingestellt:


>FF und Latch
Es gibt D-Flipflops (D-FF, in TTL: 74374, 74574).
Hier werden mit einer Taktflanke die Daten vom Eingang an den Ausgang 
durchgegeben.
So z.B.:

-- D-Latch
signal q : std_logic;  -- ausgang
signal i : std_logic;  -- eingang
signal lc : std_logic; -- latch clock
:
process (lc) 
begin
   if (lc'event and lc='1') then
       q <= i;
   end if;
end process;
:

Daneben gibt es transparente Latches (T-Latch, in TTL: 74373, 74573).
Diese Latches geben, während latch-enable high ist, den Eingang direkt
an den Ausgang durch. Das ist Kombinatorik, da ist kein Takt mit
involviert.
Das geht (oft) schief:

-- T-Latch
signal q : std_logic;  -- ausgang
signal i : std_logic;  -- eingang
signal le : std_logic; -- latch enable
:
process (le,i) 
begin
   if (le='1') then   
       q <= i;
   end if;
end process;
:

Hat jeder den kleinen Unterschied bemerkt?
Beim T-Latch fehlt le'event, und i ist in die Sens-List mit aufgenommen
worden.

Ein übler Fehler ist dann z.B.:

-- fehlerhaft beschriebenes T-Latch
-- wird wie D-FF simuliert (unvollständige Sens-List)
:
process (le) 
begin
   if (le='1') then
       q <= i;
   end if;
end process;
:

Dieses T-Latch (ohne Takt!!) wird wie ein D-FF simuliert, weil die
Simulation des Prozesses nur startet, wenn sich le ändert (also quasi
ein 'event). Es wird aber als T-Latch synthetisiert, zusammen mit 
einer dezenten Warnung: da fehle ein Signal in der Sensitivity-List und 
es werde ein Latch eingebaut. Das ist ein gern gemachter Fehler.

[Gast (Gast)]

@Christian H.:

Sorry, ich meine natürlich ASICs.

Zu Lothars Ausführungen: Man kann auch ausversehen Latches z.b. in case 
statements einbauen. Mein Hirn hat jetzt grad kein VHDL parat, aber 
schreibs mal in Verilog:

always @(switch or a or b)
 begin
  case(switch)
   1'b1: out1 = a;
   1'b0: out2 = b;
  endcase
 end

Dadurch, dass nicht beide Outputs immer zugewiesen werden, ist im Falle 
switch=1 out1 transparent, switch=0 out2 transparent. Das Beispiel wird 
in der Synthese 2 Latches produzieren. Das ganze lässt sich natürlich 
auch prima mit if-else statements erzeugen.

Ich hoffe das ist für VHDLer nachvollziehbar, ansonsten möge es bitte 
jemand in VHDL übersetzen.

[Christian H. (cavorca)]

@Gast:

Sowas habe ich auch schon mal fabriziert. Aber ehr aus versehen als mit 
Absicht. Ist so etwas denn auch ein sauberes Design oder nicht mehr als 
ein typischer Anfängerfehler?

[Gast (Gast)]

Das ist ein typischer Anfängerfehler!

[Christian H. (cavorca)]

Ok. Gut. Es ist ja manchmal so, dass typische Anfängerfehler unter 
bestimmten Umständen auch wieder richtig sein können, wenn man dem 
Anfänger noch unbekannte Dinge beachtet. Aber wenn das hier nicht so ist 
um so besser. Das macht es einfacher ;-)

[Morin (Gast)]

> Es ist ja manchmal so, dass typische Anfängerfehler unter
> bestimmten Umständen auch wieder richtig sein können, wenn man dem
> Anfänger noch unbekannte Dinge beachtet. Aber wenn das hier nicht so ist
> um so besser. Das macht es einfacher ;-)

Um ganz genau zu sein: Ich habe tatsächlich mal eine Schaltung gesehen, 
in der FFs, Latches und kombinatorische Logik munter durcheinander 
gemischt wurden. Da wurden dann auch ohne Hemmung die (Daten-)Ausgänge 
an die asynchronen Set/Reset oder an den Clock-Eingang gelegt (Glitches? 
Die waren vermutlich eingeplant!)

Vorteil: Es wurden erheblich weniger Bauteile benötigt.

Ganz großer Nachteil: Ich konnte die einwanfreie Funktion der Schaltung 
nicht mal nachvollziehen, geschweige denn dass ich oder auch sonst 
jemand den ich kenne so etwas hätte bauen können.

Also wenn du nicht zufällig die "Basic Blocks" eines IC selbst 
entwirfst, bleib bei synchronen Schaltungen und (flankengesteuerten) 
FFs.

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

>Ist so etwas denn auch ein sauberes Design
Ein gewolltes Latch an der richtigen Stelle kann einem u.U. die Arbeit 
erleichtern (z.B. beim Übergang zwischen Taktdomänen, speziell ext. 
Prozessor gibt Daten an das FPGA). Nur sollte man eben genau wissen, was 
man da macht.

Aber das sollte man sowieso... ;-)

>oder nicht mehr als ein typischer Anfängerfehler?
Das ist eher die Regel: Kombinatorik im Prozess,
keine Defaultzuweisung (else...  bzw.  when others...)
--> Latch

Eine unvollständige Sensitivity-Liste dazu, und das Ganze verhält sich 
in der Simulation grundlegend anders als in der Realität.

[Gast (Gast)]

Es ist tatsächlich so, dass asynchrone Logik und Latches eine Funktion 
weit kleiner implementieren können als das mit synchroner Logik möglich 
ist. Die Erfahrung der letzten Jahrzehnte hat aber gezeigt, dass man 
sich da früher oder später ins Knie schiesst. Eher früher als später...

Es gibt Ansätze, die Probleme asynchroner Logik durch den Einsatz von 
Software zu lösen. Wie gut das funktioniert kann ich aber nicht 
beurteilen. Soweit ich weiss ist das aber hauptsächlich akademisch.

[Christian H. (cavorca)]

Ich hatte mal die Aufgabe ein asynchrones Signal zu verlängern. Wie 
stark es verlängert wurde war egal, Hauptsache es war so lang, dass es 
auf jeden Fall sicher von einem CPLD verarbeitet werden konnte (nachdem 
das Signal durch eine Delay-Line noch verschmiert wurde).

Ich habe es so gelöst, dass das eingehende Signal auf den Takteingang 
eines FF ging. Der Dateneingang war permanent auf 1, sodass der Ausgang 
bei einer steigenden Flanke des Signals aktiviert wurde.
An der Stelle ging es dann mit synchroner Logik weiter. Wenn dieser 
Ausgang jetzt HIGH ist beginnt ein Zähler zu Zählen. Wenn er bei 1 
angekommen ist Sendet er an das erste FF ein Reset-Signal und der 
Ausgang wird wieder LOW.
Der Ausgang vom ersten FF ist das geformte Signal.
So sind die beiden Forderungen erfüllt: -Die steigende Flanke des 
Ausgangssignals weist keine zufällige Verschiebung gegenüber der 
steigenden Flanke des Eingangssignals auf (konstante Zeitunterschiede 
sind OK). -Der Puls ist mindestens eine und höchstens 2 Taktzyklen der 
verwendeten Frequenz lang.

Also asynchrone Signale ganz ohne Latch. Oder gibt es eine elegantere 
Möglichkeit das zu lösen? Oder wäre ein Latch hier vielleicht sogar 
sinnvoll?

[Falk B. (falk)]

@Christian H. (cavorca)

>Also asynchrone Signale ganz ohne Latch.

Hätte ich aus so gemacht bzw. hab ich auch schon gemacht.

> Oder gibt es eine elegantere
>Möglichkeit das zu lösen?

Keine Ahnung.

> Oder wäre ein Latch hier vielleicht sogar
>sinnvoll?

Sehe ich erstmal nicht.

MFG
Falk

[Joko (Gast)]

@Christian H. (cavorca)

> Wenn dieser Ausgang jetzt HIGH ist beginnt ein Zähler zu Zählen

Genau genommen ist 'dieser Ausgang' asynchron zu dem Takt Deines 
Zählers!
Also müßte 'dieser Ausgang' noch durch 2 FFs aufynchonisiert werden, 
bevor
es als Enable-Signal Deines Zählers verwendet werden darf.
(wodurch sich bei gleicher Taktperiode die ausgegebene Pulsdauer
verlängert).
Andernfalls ist nicht garantiert, daß Dein Zähler sich nicht 
'verschluckt'

Gruß
Joko

[Christian H. (cavorca)]

Joko wrote:
> @Christian H. (cavorca)
>
>> Wenn dieser Ausgang jetzt HIGH ist beginnt ein Zähler zu Zählen
>
> Genau genommen ist 'dieser Ausgang' asynchron zu dem Takt Deines
> Zählers!
Ja, klar.
> Also müßte 'dieser Ausgang' noch durch 2 FFs aufynchonisiert werden,
> bevor
> es als Enable-Signal Deines Zählers verwendet werden darf.
> (wodurch sich bei gleicher Taktperiode die ausgegebene Pulsdauer
> verlängert).
Verschiebt das das Problem nicht nur an eine andere Stelle? Sonst 
verstehe ich nicht was du meinst.
> Andernfalls ist nicht garantiert, daß Dein Zähler sich nicht
> 'verschluckt'
Meinst du mit verschluckt, dass er einen Takt zu spät anfängt zu zählen 
wegen verletzter Setup Zeit? Wenn ja: das ist egal. Der Puls soll ein 
wenig verlängert werden. Ob es jetzt 20 ns oder 80 ns sind ist egal.

[Falk B. (falk)]

@Christian H. (cavorca)

>Verschiebt das das Problem nicht nur an eine andere Stelle?

Nein, so werden asychrone Signale sauber synchronisiert.

>Meinst du mit verschluckt, dass er einen Takt zu spät anfängt zu zählen
>wegen verletzter Setup Zeit?

Nein, viel schlimmer. Einige FlipFlops zählen schon los, einige nicht!
Das kann man nur entschärfen, wenn man ein Schieberegister als Zähler 
nimmt (Johnson Counter). Dann geht das klar. Ein Binärzähler kann das 
nicht ohne synchronisierten Eingang.

MFg
Falk

[Christian H. (cavorca)]

Aso. Liegt das daran, dass durch Toleranzen manche FFs die Daten noch 
akzeptieren, andere nicht?
Wenn ich mich richtig erinnere hatte ich eh nur ein FF, da ich ja nur 
bis 1 Zählen wollte. In dem Fall ist es egal?

[Falk B. (falk)]

@Christian H. (cavorca)

>Aso. Liegt das daran, dass durch Toleranzen manche FFs die Daten noch
>akzeptieren, andere nicht?

Ja, Timingtoleranzen im Sub-ns Bereich.

>Wenn ich mich richtig erinnere hatte ich eh nur ein FF, da ich ja nur
>bis 1 Zählen wollte. In dem Fall ist es egal?

Ja, ein FlipFlop geht immer.

MFG
Falk

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

>Genau genommen ist 'dieser Ausgang' asynchron zu dem Takt Deines Zählers!
Ist er, denn das FF weiß ja nichts von einem anderen FPGA-Takt. Also muß 
auch der FF-Ausgang erst auf den FPGA-Takt einsynchronisiert werden.

Hier ein "Dreizeiler", der die von  Christian H. beschriebene Funktion 
implementiert. Eine (auch sehr kurze) steigende Flanke an inp erzeugt 
genau 1 Puls mit 1 Taktzyklus Länge am outp. Syntheseergebnis und 
Waveform im Anhang.

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

entity AsyncInput is
    Port ( clk  : in  STD_LOGIC;
           inp  : in  STD_LOGIC;
           outp : out STD_LOGIC);
end AsyncInput;

architecture Behavioral of AsyncInput is
signal inpFF   : std_logic := '0';
signal inpSR   : std_logic_vector( 1 downto 0) := "00";
signal outpL   : std_logic := '0';   -- lokales Singal für dss Ausgangssignal
begin
   process (inp,outpL)  
   begin
      -- mit outp FF zurücksetzen      
      if    (outpL='1')      then inpFF <= '0';
      -- mit inp FF setzen      
      elsif rising_edge(inp) then inpFF <= '1'; 
      end if;
   end process;

   process (clk)   -- DER globale FPGA-Clock
   begin
      -- Einsynchronisieren, inpFF ist asynchron zu clk
      if rising_edge(clk) then   
         inpSR <= inpSR(0) & inpFF;
      end if;
   end process;
  
   outpL <= '1' when inpSR = "11" else '0'; 
   outp <= outpL;

end Behavioral;

An dieser Stelle:

:
:
      if    (outpL='1') then inpFF <= '0';
      -- inp latchen      
      elsif (inp='1')   then inpFF <= '1';          --< das rein
--      -- mit inp FF setzen
--      elsif rising_edge(inp) then inpFF <= '1';   --< das raus
      end if;
:
:

Könnte statt dem FF ein Latch generiert werden.
Bei kurzen Eingangspulsen verhalten sich beide Lösungen gleich.
Aber wehe, der Eingangspuls dauert mal ein wenig länger...
Probiert es mal aus  ;-)

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

Und hier noch zum selber probieren: die Testbench.

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

>always @(switch or a or b)
> begin
>  case(switch)
>   1'b1: out1 = a;
>   1'b0: out2 = b;
>  endcase
> end

>möge es bitte jemand in VHDL übersetzen...

:
process (switch,a,b)
begin 
   case switch is 
   when '1' => out1 <= a;
   when '0' => out2 <= b;
   end case;
end process
:

Hier ist sowohl out1 wie auch out2 nicht vollständig definiert,
tauchen also nicht in jedem when-Pfad auf --> 2 Latches.

Wie gesagt:
Das passiert gerne aus Versehen bei solchen kombinatorischen Prozessen.