Grammatikfrage für VHDL sync von Signalen

[T. K. (tntbc)]

Hallo ich habe ja nun gelernt, dass man Signale die von einer anderen 
Ebene ob nun Architektur oder Außenwelt kommen einsyncen sollte.
Nun zu meiner Frage, was ist mit den Signalen die ich ausgebe? Als 
Beispiel soll ein Steuersignal dienen was angibt ob ein Paket fertig 
gelesen wurde.

entity X is
port(
     CLK: in std_logic;
     FERTIG: out std_logic
     NEUES_PAKET: out std_logic_vector(7 downto 0);
);
end X;
architecure A of X is
signal S_FERTIG: std_logic := '0';
signal S_NEUES_PAKET: std_logic_vector(7 downto 0);
begin

MAIN: process
begin
wait unti rising_clk(CLK);
...
  S_FERTIG <= not S_FERTIG; --weis das macht kein Sinn ist nur ein Bsp. :)
...
end X;

--hier die Frage so richtig oder eher nicht=
FERTIG <= S_FERTIG;
NEUES_PAKET <= S_NEUES_PAKET when S_FERTIG='1';

ist das machbar FERTIG so zu setzen oder erzeuge ich da ein Problem was 
ich nicht sehe? Oder besser wie in einigen Büchern über eine Process?

Vielen Dank

[VHDL hotline (Gast)]

T. K. schrieb:
> die von einer anderen
> Ebene ob nun Architektur oder Außenwelt kommen einsyncen sollte

Falsch. Signale, die aus einer anderen clock domain kommen (dazu zählt 
die Außenwelt und entities mit anderem Takt) musst du einsyncen. Wenn du 
innerhalb eines VHDL-Designs nur einen Takt benutzt musst du nichts 
"zwischen Architekturen oder Ebenen" syncen, nur Signal, die von der 
Außenwelt kommen.

Zum Syncen Richtung Außenwelt kommt es darauf an, was der Baustein, den 
du dort draußen dran hast, für Anforderungen hat. Ggf. muss man mittels 
constraints Daten und Takt zueinander in bestimmte Phase setzen, aber 
ein syncen mittels Registern wie beim einsyncen ist nicht sinnvoll.

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

T. K. schrieb:
> erzeuge ich da ein Problem was ich nicht sehe?
Ja, das tutst du. Du erzeugst damit ein Latch. Und mit annähernd 100%er 
Wahrscheinlichkeit willst du das nicht.

> Oder besser wie in einigen Büchern über eine Process?
Eine Concurrent-Beschreibung ist nichts anderes wie ein etwas anders 
formulierter Prozess. Oder andersrum: man kann jede 
Concurrent-Beschreibung ganz problemlos und ohne jegliche 
Funktionsänderung in einen Prozess umwandeln. Es wird dadurch exakt die 
selbe Hardware erzeugt.

Langer Rede kurzer Sinn:
Deine Denkrichtung ist falsch.
Du denkst: "Ich schreibe etwas hin und der Synthesizer macht mir 
Hardware daraus."
Richtig wäre aber, zu denken: "Ich möchte diese Hardware. Wie muss ich 
sie beschreiben, damit der Synthesizer das kapiert?

Soweit das Allgemeine, jetzt zu deinem Problem:
Du willst parallel Daten ausgeben. Und wenn diese Daten stabil und 
gültig sind, zeigst du das mit einem FERTIG-Flag an. Der Ansatz ist 
richtig.

Es kommt jetzt aber darauf an, ob du die Daten im FPGA mit dem (selben 
und im Idealfall einzigen) Takt weiterverarbeitest, oder ob diese Daten 
hinaus zu anderen asynchronen Bauteilen gehen.
Im ersten Fall musst du gar nichts weiter machen, sondern einfach die 
Daten am Port bereitstellen.
Im zweiten Fall musst du sicherstellen, dass keine der Datenleitungen 
mehr zappelt, wenn du mit dem FERTIG Signal anzeigst, dass die Daten 
gültig sind. Du darfst dieses Signal also nicht gleichzeitig mit den 
Daten ändern, sondern solltest da noch abwarten. Und du solltest das 
FERTIG Signal schon vor dem Ändern der Daten wieder deaktivieren.

[T. K. (tntbc)]

Lothar M. schrieb:
> Ja, das tutst du. Du erzeugst damit ein Latch. Und mit annähernd 100%er
> Wahrscheinlichkeit willst du das nicht.

Ha ok? Im Bereich der Änderung von FERTIG kann es instabil werden und 
daher kein Latch?

Lothar M. schrieb:
> Es kommt jetzt aber darauf an, ob du die Daten im FPGA mit dem (selben
> und im Idealfall einzigen) Takt weiterverarbeitest, oder ob diese Daten
> hinaus zu anderen asynchronen Bauteilen gehen.

Es ist gibt nur einen Takt im FPGA für mehr reicht meine derzeitige 
Erfahrung nicht. ;) Da diese Daten von dem gleichen Takt erzeugt werden 
reicht also das direkte schreiben der Signale auf die Ausgänge!

Lothar M. schrieb:
> Du darfst dieses Signal also nicht gleichzeitig mit den
> Daten ändern, sondern solltest da noch abwarten.

Ok das macht sind. Ist wie auf der PCB erste Daten auf dem Bus dann CS. 
Aber wie mache ich das im FPGA. Ich gehe mal davon aus, das der Befehl 
"after 5ns" von Synthesizer nicht verstanden wird?

VHDL hotline schrieb im Beitrag #4629430:
> Falsch. Signale, die aus einer anderen clock domain kommen

was ist mit Signalen die zwangsweise durch den ganzen FPGA geroutet 
werden mit unterschiedlichen Längen?

[Achim S. (Gast)]

Zur Eklärung an T.K.:

Lothar M. schrieb:
> Ja, das tutst du. Du erzeugst damit ein Latch.

bezieht sich wohl nur auf das folgende Konstrukt

T. K. schrieb:
> NEUES_PAKET <= S_NEUES_PAKET when S_FERTIG='1';

Wenn S_FERTIG nicht gleich 1 ist, muss NEUES_PAKET seinen Wert speichern 
(als Latch). Würdest du noch mit beschreiben, was aus NEUES_PAKET werden 
soll wenn S_FERTIG ungleich 1 ist, dann wäre es kein Latch sondern 
einfach eine kombinatorische Logik zwischen deinen internen 
FlipFlop-Ausgängen und dem FPGA-Ausgang.

Die Zuweisung an FERTIG hingegen ist sauber und üblich, wenn man 
output-Signale auch intern rücklesbar braucht. Es entsteht dabei kein 
Latch, weil die Zuweisung immer (ohne irgendwelche Bedingungen) erfolgt.

T. K. schrieb:
> FERTIG <= S_FERTIG;

Eigentlich "entsteht" dadurch im FPGA gar nichts: du hast nur in VHDL 
zwei unterschiedliche Signalnamen (FERTIG und S_FERTIG) für das 
identische Signal (wobei nur von einem der beiden Signalnamen 
zurückgelesen werden kann).

Mein Tip: lies dir die Warnungen deines Synthesetools durch (speziell zu 
Latches) und schau dir im RTL-Viewer an, welche Hardware aus deiner 
Beschreibung erzeugt wird.

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

Die Aussage, dass jegliche Eingangssignale einsychronisiert werden 
müssen, gilt dann, wenn intern eine getaktete Verarbeitung stattfinden 
soll. Ebenso müssen interne Signale (erneut) einsychronisiert werden, 
wenn sie die Taktdomain wechseln. Es ist aber nicht erforderlich, beim 
Wechsel von Entities oder anderen Abstraktionsebenen die Synchronisation 
durchzuführen, wenn sich alles auf denselben Takt bezieht.

Ebenso ist es im Allgemeinen nicht erforderliche, Eingangssignale 
einzusynchronisieren, wenn diese nicht getaktet, sondern rein 
kombinatorisch verarbeitet und dann irgendwann wieder ausgegeben werden.

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

T. K. schrieb:
> Lothar M. schrieb:
>> Du darfst dieses Signal also nicht gleichzeitig mit den
>> Daten ändern, sondern solltest da noch abwarten.
> Ok das macht sind. Ist wie auf der PCB erste Daten auf dem Bus dann CS.
> Aber wie mache ich das im FPGA.
Du machst gar nichts. In einem synchronen Design setzt du deine Daten im 
und mit dem selben Takt wie das FERTIG Signal. Und die Komponente, die 
"am anderen Ende" sitzt, hat dann bis zum nächsten Takt Zeit, sich zur 
Übernahme der Daten vorzubereiten.

> Ich gehe mal davon aus, das der Befehl
> "after 5ns" von Synthesizer nicht verstanden wird?
Er ignoriert es einfach.

> Im Bereich der Änderung von FERTIG kann es instabil werden und daher
> kein Latch?
Ein Latch entsteht, wenn etwas ohne Takt gespeichert werden soll. Und 
deshalb ist (wie erwähnt) NEUES_PAKET ein Latch:
>>> NEUES_PAKET <= S_NEUES_PAKET when S_FERTIG='1';
Schlimmer: es sind gleich 8 Latches, die von 1 Signal angesteuert 
werden. Und wenn auf diesem Signal mal ein kurzer Glitch ist, kann es 
sein, dass ein paar dieser 8 Latches die zufällig anliegenden Daten 
übernehmen --> Super-GAU durch inkonsistente Daten.

[VHDL hotline (Gast)]

T. K. schrieb:
> was ist mit Signalen die zwangsweise durch den ganzen FPGA geroutet
> werden mit unterschiedlichen Längen?

Die Toolchain sorgt dafür, dass innerhalb einer Taktdomän alles synchron 
an Registern anliegt, egal wie lang die Route ist. Bei einer langen 
Route wird die Toolchain möglicherweise mitteilen, dass sie deinen 
gewünschten Takt nicht schafft.

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

VHDL hotline schrieb im Beitrag #4629565:
> Die Toolchain sorgt dafür, dass innerhalb einer Taktdomän alles synchron
> an Registern anliegt, egal wie lang die Route ist. Bei einer langen
> Route wird die Toolchain möglicherweise mitteilen, dass sie deinen
> gewünschten Takt nicht schafft.
Wenn man ihr per Timing Constraint mitteilt, welchen Systemtakt man 
haben möchte.

[T. K. (tntbc)]

Lothar M. schrieb:
> Wenn man ihr per Timing Constraint mitteilt, welchen Systemtakt man
> haben möchte.

Ich habe die erstellt welche im TUT bei altera standen. Also clk und pll 
definiert und allgemeine Ein- und Ausgänge!

[Gelehrter (Gast)]

T. K. schrieb:


Es gibt nicht viele Methoden einen synchronizer zu realisieren außer man 
benutzt zwei D-FF. Und diese beschreibt man in VHDL über einen process

entity X is
port( CLK:    in std_logic;
     no_sync_i: in std_logic;
     sync_o: out std_logic);
end X;

architecure A of X is
signal sync_q: std_logic_vector(1 downto 0);

begin

P_sync: process(clk)
begin
 if rising_edge(clk) then
  sync_q <= sync_q(0) &  no_sync_i;
 end if;
end process P_sync;

sync_o <= sync_q(1);

end architecture A;

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

Gelehrter schrieb:
> zwei D-FF. Und diese beschreibt man in VHDL über einen process
Das kommt auf den Synthesizer an. Die, die ich verwende, können das auch 
nebenläufig:
signal sr: std_logic_vector(1 downto 0);
...
sr <= sr(0) & input when rising_edge(clk);

Und wie gesagt theoretische reicht bei heutigen FPGA auch 1 
Sync-Flipflop.