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.
1
entityXis
2
port(
3
CLK:instd_logic;
4
FERTIG:outstd_logic
5
NEUES_PAKET:outstd_logic_vector(7downto0);
6
);
7
endX;
8
architecureAofXis
9
signalS_FERTIG:std_logic:='0';
10
signalS_NEUES_PAKET:std_logic_vector(7downto0);
11
begin
12
13
MAIN:process
14
begin
15
waituntirising_clk(CLK);
16
...
17
S_FERTIG<=notS_FERTIG;--weis das macht kein Sinn ist nur ein Bsp. :)
18
...
19
endX;
20
21
--hier die Frage so richtig oder eher nicht=
22
FERTIG<=S_FERTIG;
23
NEUES_PAKET<=S_NEUES_PAKETwhenS_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
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.
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 imFPGA 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.
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?
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.
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.
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.
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.
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.
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!
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
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.