Darf man std_logic_vectoren ungetaktet vergleichen?

[Dosmo (Gast)]

Hallo,

mal eine grundsätzliche Verständnisfrage:

Darf ich einen std_logic_vector, der getaktet beschrieben wird, 
ungetaktet vergleichen, ohne Gefahr zu laufen, ein metastabiles 
Vergleichsergebnis zu bekommen?

Beispiel:

signal  counter :   std_logic_vector(15 downto 0) := x"0000";

proc_add : process (CLK)
begin
  if (rising_edge(CLK)) then
    counter <= counter + 1;
  end if;
end process;

proc_compare : process (counter)
begin
  if (counter = x"1234") then
           match <= '1';
  else
           match <= '0';
  end if;
end process;

Können da Laufzeitunterschiede der einzelnen Bits vom getakteten 
"proc_add" zum ungetakteten "proc_compare" auftreten?

PS: Es geht darum, einen bestehenden Code zu bewerten. Die Frage "warum 
ist das überhaupt so" steht leider nicht zur Debatte :/

[Christian R. (supachris)]

Klar geht das. Das macht nur bei hohen Frequenzen eventuell Probleme, 
aber nicht weil die Bits verschieden schnell sind (Ist ja ein Binär 
Zähler), sondern weil eventuell der Vergleich so viele Logik-Ebenen hat, 
dass die Durchlaufzeit länger ist als die Periodendauer deines Taktes.
Wie hoch ist denn die Frequenz und welcher FPGA?

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

Christian R. schrieb:
> Das macht nur bei hohen Frequenzen eventuell Probleme
Das Signal match wird unabhängig von der Frequenz Glitches 
aufweisen.

Wenn dieses Signal daher (evtl. sogar extern) asynchron weiterverwendet 
wird, kann es Probleme geben. Wenn es synchron weiterverwendet wird, 
dann hat die Toolchain das soweit im Griff (bei angegebenem 
Takt-constraint).


Eine kleine Anmerkung:
> signal  counter :   std_logic_vector(15 downto 0) := x"0000";
> counter <= counter + 1;
Mit uneingeschränkten Vektoren rechnet man nicht. Dafür nimmt man besser 
signed und unsigned Vektoren oder gleich passende Integer:
Beitrag "IEEE.STD_LOGIC_ARITH.ALL obsolete"

[Christian R. (supachris)]

Dass das Signal dann synchron weiter verwendet wird, hab ich erst mal 
angenommen. Alles andere wäre Bastelmurks.

[Dosmo (Gast)]

Okay, danke.

[JBB (Gast)]

Die gesamte Fragestellung ist eigentlich irrelevant, da die Synthese eh 
umsetzt, was sie will. Welche LUTs dann mit welchen verglichen werden 
ist nicht zu kontrollieren und Zufallsergebnis, weil Schaltungsteile mit 
anderen zusammengefasst werden.

Man muss einfach davon ausgehen, dass zum Zeitpunkt der synchronen 
Verwendung eines Ergebnisses, der Wert stabil ist und darauf achtet die 
Synthese ja auch.

Das bedeutet allerdings, dass sich bei der "Verrechung" von 
kombinatorischen Ausgängen statt von FFs, der Pfad verlängert und die 
mögliche Taktfrequenz sinkt, wenn dieser Pfad damit zum Längsten wird.

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

Dosmo schrieb:
> ein metastabiles Vergleichsergebnis zu bekommen?
Der Mythos Metastabilität ist innerhalb eines FPGAs sowieso nicht 
vorhanden. Denn Metastabilität bedeutet ja, dass bereits die tsu/th 
irgendeines Flipflops verletzt wurde. Wenn das in einem FPGA passiert, 
dann wurde mit falschen Zeiten gerechnet, oder das Design hinterher 
übertaktet...


Dosmo schrieb:
>>>> Darf ich einen std_logic_vector, der getaktet beschrieben wird,
>>>> ungetaktet vergleichen
JBB schrieb:
> Die gesamte Fragestellung ist eigentlich irrelevant, da die Synthese eh
> umsetzt, was sie will.
Und insbesondere deshalb, weil Vergleicher eben Kombinatorik sind, und 
daher zwingend jeder Vergleich kombinatorisch sein wird. Auch einer, 
der in einer getakteten VHDL-Beschreibung steht.
Der Vergleicher vom OP wird genau der selbe sein wie dieser hier:

signal  counter :   std_logic_vector(15 downto 0) := x"0000";

proc_add : process (CLK)
begin
  if (rising_edge(CLK)) then
    counter <= counter + 1;
    if (counter = x"1234") then
           match <= '1';
    else
           match <= '0';
    end if;
  end if;
end process;

Nur wird hier match hinterher erst mal auf ein Flipflop gehen, und so 
mit einem Takt Latency behaftet sein.

[Matthias (Gast)]

Lothar Miller schrieb:
> Der Mythos Metastabilität ist innerhalb eines FPGAs sowieso nicht
> vorhanden. Denn Metastabilität bedeutet ja, dass bereits die tsu/th
> irgendeines Flipflops verletzt wurde. Wenn das in einem FPGA passiert,
> dann wurde mit falschen Zeiten gerechnet, oder das Design hinterher
> übertaktet...

Ich hab mehrere Clock Domains im FPGA und nicht an allen Stellen wird 
eine klassische Block RAM basierte Dual-Clock FIFO verwendet, sondern 
teilweise auch handcodiertes Übergeben von Werten mittels Handshake. Da 
muss ich dann dem Tool mitteilen, dass es sich um einen falschen Pfad 
handelt und wenn da die Constraints falsch gesetzt sind oder im Code 
irgendwas übersehen wurde, kann das Tool das ja nicht mehr abfangen.

Ein anderer Fall wo ich definitiv Metastabilität gesehen habe war der 
Übergang zwischen zwei Clock Domains wo die eine von der anderen mittels 
PLL abgeleitet war. Ich konnte das Problem bis zu einem FF verfolgen, 
das als Eingang in die FSM diente. Witzigerweise war das Problem 
behoben, als ich eine DLL statt einer PLL verwendete.

Habs eh damals hier ein wenig beschrieben.

[Dosmo (Gast)]

Lothar Miller schrieb:
>> Die gesamte Fragestellung ist eigentlich irrelevant, da die Synthese eh
>> umsetzt, was sie will.
>Und insbesondere deshalb, weil Vergleicher eben Kombinatorik sind, und
>daher zwingend jeder Vergleich kombinatorisch sein wird. Auch einer,
>der in einer getakteten VHDL-Beschreibung steht.
>Der Vergleicher vom OP wird genau der selbe sein wie dieser hier:signal

counter :   std_logic_vector(15 downto 0) := x"0000";
proc_add : process (CLK)
begin
  if (rising_edge(CLK)) then
    counter <= counter + 1;
    if (counter = x"1234") then
           match <= '1';
    else
           match <= '0';
    end if;
  end if;
end process;

>Nur wird hier match hinterher erst mal auf ein Flipflop gehen, und so
>mit einem Takt Latency behaftet sein.

Aber wenn ich Dich richtig verstehe, würde dieser Code keine Glichtes 
auf "match" aufweisen, richtig?

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

Dosmo schrieb:
> würde dieser Code keine Glichtes auf "match" aufweisen, richtig?
Nein. Er würde es nicht nur, sondern er kann es gar nicht, denn 
match ist ein Flipflop-Ausgang.

[Dosmo (Gast)]

JBB:
>Man muss einfach davon ausgehen, dass zum Zeitpunkt der synchronen
>Verwendung eines Ergebnisses, der Wert stabil ist und darauf achtet die
>Synthese ja auch.

Ich glaub, jetzt versteh ich es:
Kombinatorische Logik hat gar keinen Takt, sondern der Ausgang folgt 
einfach den Eingängen (mit einer gewissen Laufzeit).
Das ist aber unkritisch, solange die Eingänge getaktet sind und der 
Ausgang auch wieder getaktet gelesen wird, weil die Synthese dann 
sicherstellen kann, daß der Ausgang der Kombinatorik korrekt und stabil 
ist, wenn der nächste Takt kommt.

[Klaus (Gast)]

Dosmo schrieb:
> Ich glaub, jetzt versteh ich es:
> Kombinatorische Logik hat gar keinen Takt, sondern der Ausgang folgt
> einfach den Eingängen (mit einer gewissen Laufzeit).
> Das ist aber unkritisch, solange die Eingänge getaktet sind und der
> Ausgang auch wieder getaktet gelesen wird, weil die Synthese dann
> sicherstellen kann, daß der Ausgang der Kombinatorik korrekt und stabil
> ist, wenn der nächste Takt kommt.

Absolut korrekt :)

[Sven P. (Gast)]

Dosmo schrieb:
> JBB:
>>Man muss einfach davon ausgehen, dass zum Zeitpunkt der synchronen
>>Verwendung eines Ergebnisses, der Wert stabil ist und darauf achtet die
>>Synthese ja auch.
>
> Ich glaub, jetzt versteh ich es:
> Kombinatorische Logik hat gar keinen Takt, sondern der Ausgang folgt
> einfach den Eingängen (mit einer gewissen Laufzeit).
> Das ist aber unkritisch, solange die Eingänge getaktet sind und der
> Ausgang auch wieder getaktet gelesen wird, weil die Synthese dann
> sicherstellen kann, daß der Ausgang der Kombinatorik korrekt und stabil
> ist, wenn der nächste Takt kommt.
So läufts. Du synthetisierst echte Hardware, also denk doch einfach 
daran, wie du ein paar UND-Gatter an die Flipflops klemmst. Da hast du 
dann deinen kombinatorischen Term.

Und da hast du auch gleich deine Glitches: Die treten da nämlich exakt 
genauso auf, wie sie anno dunnemal auftraten, wenn man im KV-Diagramm zu 
viel optimierte und versehentlich Struktur- und/oder Funktionshazards 
einbaute.