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
>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.
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.
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...
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)
@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
signalq:std_logic;-- ausgang
3
signali:std_logic;-- eingang
4
signallc:std_logic;-- latch clock
5
:
6
process(lc)
7
begin
8
if(lc'eventandlc='1')then
9
q<=i;
10
endif;
11
endprocess;
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
signalq:std_logic;-- ausgang
3
signali:std_logic;-- eingang
4
signalle:std_logic;-- latch enable
5
:
6
process(le,i)
7
begin
8
if(le='1')then
9
q<=i;
10
endif;
11
endprocess;
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
endif;
9
endprocess;
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.
@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:
1
always @(switch or a or b)
2
begin
3
case(switch)
4
1'b1: out1 = a;
5
1'b0: out2 = b;
6
endcase
7
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.
@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 ;-)
> 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.
>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.
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.
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
@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
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
libraryIEEE;
2
useIEEE.STD_LOGIC_1164.ALL;
3
useIEEE.STD_LOGIC_ARITH.ALL;
4
useIEEE.STD_LOGIC_UNSIGNED.ALL;
5
6
entityAsyncInputis
7
Port(clk:inSTD_LOGIC;
8
inp:inSTD_LOGIC;
9
outp:outSTD_LOGIC);
10
endAsyncInput;
11
12
architectureBehavioralofAsyncInputis
13
signalinpFF:std_logic:='0';
14
signalinpSR:std_logic_vector(1downto0):="00";
15
signaloutpL: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')theninpFF<='0';
21
-- mit inp FF setzen
22
elsifrising_edge(inp)theninpFF<='1';
23
endif;
24
endprocess;
25
26
process(clk)-- DER globale FPGA-Clock
27
begin
28
-- Einsynchronisieren, inpFF ist asynchron zu clk
29
ifrising_edge(clk)then
30
inpSR<=inpSR(0)&inpFF;
31
endif;
32
endprocess;
33
34
outpL<='1'wheninpSR="11"else'0';
35
outp<=outpL;
36
37
endBehavioral;
An dieser Stelle:
1
:
2
:
3
if(outpL='1')theninpFF<='0';
4
-- inp latchen
5
elsif(inp='1')theninpFF<='1';--< das rein
6
-- -- mit inp FF setzen
7
-- elsif rising_edge(inp) then inpFF <= '1'; --< das raus
8
endif;
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 ;-)
>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
caseswitchis
5
when'1'=>out1<=a;
6
when'0'=>out2<=b;
7
endcase;
8
endprocess
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.