Flipflop und Latch

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

Kannst du mir ein Beispiel geben?

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

@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

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

1

-- D-Latch

2

signal q : std_logic;  -- ausgang

3

signal i : std_logic;  -- eingang

4

signal lc : std_logic; -- latch clock

5

:

6

process (lc) 

7

begin

8

   if (lc'event and lc='1') then

9

       q <= i;

10

   end if;

11

end process;

12

:

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:

1

-- T-Latch

2

signal q : std_logic;  -- ausgang

3

signal i : std_logic;  -- eingang

4

signal le : std_logic; -- latch enable

5

:

6

process (le,i) 

7

begin

8

   if (le='1') then   

9

       q <= i;

10

   end if;

11

end process;

12

:

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

1

-- fehlerhaft beschriebenes T-Latch

2

-- wird wie D-FF simuliert (unvollständige Sens-List)

3

:

4

process (le) 

5

begin

6

   if (le='1') then

7

       q <= i;

8

   end if;

9

end process;

10

:

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:

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?

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

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

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?

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

@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

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?

@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

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

1

library IEEE;

2

use IEEE.STD_LOGIC_1164.ALL;

3

use IEEE.STD_LOGIC_ARITH.ALL;

4

use IEEE.STD_LOGIC_UNSIGNED.ALL;

5

6

entity AsyncInput is

7

    Port ( clk  : in  STD_LOGIC;

8

           inp  : in  STD_LOGIC;

9

           outp : out STD_LOGIC);

10

end AsyncInput;

11

12

architecture Behavioral of AsyncInput is

13

signal inpFF   : std_logic := '0';

14

signal inpSR   : std_logic_vector( 1 downto 0) := "00";

15

signal outpL   : std_logic := '0';   -- lokales Singal für dss Ausgangssignal

16

begin

17

   process (inp,outpL)  

18

   begin

19

      -- mit outp FF zurücksetzen      

20

      if    (outpL='1')      then inpFF <= '0';

21

      -- mit inp FF setzen      

22

      elsif rising_edge(inp) then inpFF <= '1'; 

23

      end if;

24

   end process;

25

26

   process (clk)   -- DER globale FPGA-Clock

27

   begin

28

      -- Einsynchronisieren, inpFF ist asynchron zu clk

29

      if rising_edge(clk) then   

30

         inpSR <= inpSR(0) & inpFF;

31

      end if;

32

   end process;

33

34

   outpL <= '1' when inpSR = "11" else '0'; 

35

   outp <= outpL;

36

37

end Behavioral;

An dieser Stelle:

1

:

2

:

3

      if    (outpL='1') then inpFF <= '0';

4

      -- inp latchen      

5

      elsif (inp='1')   then inpFF <= '1';          --< das rein

6

--      -- mit inp FF setzen

7

--      elsif rising_edge(inp) then inpFF <= '1';   --< das raus

8

      end if;

9

:

10

:

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

Und hier noch zum selber probieren: die Testbench.

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

1

:

2

process (switch,a,b)

3

begin 

4

   case switch is 

5

   when '1' => out1 <= a;

6

   when '0' => out2 <= b;

7

   end case;

8

end process

9

:

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.