Hallo, ich kann mir das reject-inertial-Modell irgendwie sehr schwer vorstellen. Reject xy ns heisst ja, dass alle Impulse die mindestens xy Nanosekunden lang anlagen nicht unterdrückt werden, auch wenn sie kürzer als die Verzögerungszeit des Gatters sind. Nun folgendes Beispiel: Ich habe ein Gatter mit einer Verzögerungszeit von 12 ns, will aber Impulse mit einer Impulsdauer von 3 ns nicht mehr unterdrücken (also nur alle die kleiner 3 ns anliegen). Das könnte ja bspw. ein Takt sein, dessen Phasen jeweils 3 ns lang anliegen (also Wert 1 liegt 3 ns lang an, Wert 0 liegt 3 ns lang an, usw.). Angenommen zum Zeitpunkt 0 ns liegt am Eingang des Gatters der Wert 1 an. Nach 3 ns liegt der Wert 0 an. Nach 6 ns der Wert 1. NAch 9 ns der Wert 0 und nach 12 ns der Wert 1. Wenn also nach 12 ns das dritte mal der Wert 1 anliegt, ändert sich der Ausgangswert des Gatters aufgrund des 1-Wertes zum Zeitpunkt 0 ns. Das heisst wiederum, dass die Werte 0, 1, 0 zu die zu den Zeitpunkten 3 ns, 6 ns, 9 ns am Eingang anlagen ja irgendwie im Gatter gespeichert werden müssen... Und das obwohl doch so ein Gatter keine internen Zustände hat. Ich versuch mir grad den Zusammenhang zwischen VHDL und der Hardware (die ja in VHDL beschrieben werden soll) klar zu machen. Hoffe irh versteht was mein Problem ist und könnt mir helfen. Vllt hab ich auch nur einen groben Denkfehler drin. Mfg Guest
Du verknotest hier zwei Mechanismen: 1. eine Art "Massenträgheit": nur Impulse ab einer bestimmten Dauer werden überhaupt etwas bewirken 2. eine Verzögerungszeit: jedes Gatter hat eine (angenommen konstante) Durchlaufzeit In der Praxis sieht das so aus:
1 | 1 Zeichen = 1ns |
2 | _ = 1ns low |
3 | - = 1ns high |
4 | reject 3ns: Änderungen kleiner 3ns werden ignoriert |
5 | Durchlaufzeit 5ns: xxxxx |
6 | |
7 | Input ___----______----______--______-------__-----____--___ |
8 | | | |
9 | v v |
10 | Reject ___----______----______________--------------_________ |
11 | | |
12 | '-----v |
13 | Output xxxxxx___----______----______________--------------_________ |
Hallo, danke für deine Antwort. Also wenn ich das richtig verstehe, gibt reject x ns an, wie lange ein Signal mindestens am Eingang anliegen muss. Und after y ns gibt an, wie lange das Gatter braucht, bis eine Wertänderung am Ausgang zu beobachten ist. Beim inertial-Modell gibt after dann sozusagen beides gleichzeitig an. Zum einen, dass ein Signal, das kürzer als die angegebene Zeit anliegt, unterdrückt wird. Zum anderen, wie groß die Durchlaufzeit des Gatters ist. Dann sind also folgende Anweisungen äquivalent:
1 | s <= inertial a after 10 ns; |
und [vhdls <= reject 10 ns inertial a after 10 ns;[/vhdl] Was mir dennoch nicht klar ist, ist wie das ganze in Hardware funktionieren kann. Denn bspw. bei
1 | input <= '0', '1' after 2 ns, '0' after 3 ns; |
2 | output <= reject 2 ns inertial input after 8 ns; |
Die '0'-Phase am Anfang wird um 8 ns verzögert output zugewiesen, weil das Gatter eine (baulich bedingte) Verzögerungszeit/Durchlaufzeit von 8 ns hat. Zum Zeitpunkt 2 ns liegt aber schon der Wert '1' am Eingang an. Das Gatter ist doch aber noch mit dem Wert '0' beschäftigt. Müsste sich das Gatter dann nicht in einer Art Puffer alle am Eingang anliegenden Signale merken? MfG
Guest schrieb: > Müsste sich das Gatter dann nicht in einer Art Puffer alle am Eingang > anliegenden Signale merken? Wieviele Bits haben auf 100m Kupferkabel beim 10BaseT Ethernet Platz? Dann haben wir eine Signallaufzeit 0,59×c (100m -> 0,565µs) und eine Bitdauer von 0,1us. Somit passen auf 100m Leitung 565 Bits... Die Leitung kann sich die Bits "merken" und verzögert ausgeben. Guest schrieb: > Was mir dennoch nicht klar ist, ist wie das ganze in Hardware > funktionieren kann Das wirst du nicht in Hardware gegossen bekommen! Diese ganzen Sprachkonstrukte funktionieren nur andersrum: Wenn du an einem real existierenden Baustein (oder der angesprochenen Ethernetleitung) so ein Verhalten beobachtet hast, dann kannst du es mit VHDL beschreiben. Denn das ist VHDL in erster Linie: eine Hardwarebeschreibungssprache. Bestenfalls 1% vom Sprachumfang von VHDL taugt auch für die Synthese und kann für den umgekehrten Weg (VHDL nach Hardware) verwendet werden... :-(
Lothar Miller schrieb: > Wieviele Bits haben auf 100m Kupferkabel beim 10BaseT Ethernet Platz? > Dann haben wir eine Signallaufzeit 0,59×c (100m -> 0,565µs) und eine > Bitdauer von 0,1us. Somit passen auf 100m Leitung 565 Bits... > Die Leitung kann sich die Bits "merken" und verzögert ausgeben. Achso, ok. Also kann sich so ein Baustein durchaus einige Bits merken. Allerdings ist die Anzahl der Bits, die sich die Leitung/der Baustein merken kann, nun auch durch die Leitungslänge und die Signallaufzeit bestimmt. Das heisst, das Ganze ist ein Maß für den maximalen Takt? Lothar Miller schrieb: > Diese ganzen Sprachkonstrukte funktionieren nur andersrum: > Wenn du an einem real existierenden Baustein (oder der angesprochenen > Ethernetleitung) so ein Verhalten beobachtet hast, dann kannst du es mit > VHDL beschreiben. Ja, das ist mir klar. In VHDL gibt es ja Sprachkonstrukte, die synthetisierbar sind und solche, die es nicht sind (bspw. File, assert,...). Ich dachte halt nur, dass reject zu den synthetisierbaren gehört. Bzw.: reject soll ja ein, in einem real existierendem Baustein, beobachtetes Verhalten beschreiben. Und ich hatte mich halt gefragt, wie dieses beobachtete Verhalten aussehen mag. MfG
Guest schrieb: > Achso, ok. Also kann sich so ein Baustein durchaus einige Bits merken. Jein, eine Leitung kann das, ein Gatter wahrscheinlich nicht... > dass reject zu den synthetisierbaren gehört. Nein. Sicher nicht. Nicht mal sowas wirklich einfaches wie ein output <= input after 3ns; kann synthetisiert werden. > Bzw.: reject soll ja ein, in einem real existierendem Baustein, > beobachtetes Verhalten beschreiben. Richtig. So herum stimmt es: das Verhalten wurde zuerst beobachtet, dann in einem (Simulations-)Modell beschrieben. > dass reject zu den synthetisierbaren gehört. Was synthetisiert werden kann, wird in entsprechenden Synthesis-Guidelines beschreiben.
Lothar Miller schrieb: > Jein, eine Leitung kann das, ein Gatter wahrscheinlich nicht... Ok, das heisst man müsste bei der Synthese darauf achten/sicherstellen, dass der Takt nicht schneller am Eingang anliegt, als das Gatter Zeit benötigt, bis sich am Ausgang eine Änderung einstellt? Oder anders gesagt: Das Gatter muss genug Zeit haben (after y ns), um eine Wertänderung am Eingang zu verarbeiten. Also ist
1 | out <= reject 3 ns in after 10 ns; |
zwar simulierbar (es ergibt sich ein um 10 ns verschobenes Signal, das nur die Impulse enthält die nicht kleiner 3 ns sind), aber es ist nur realisierbar, wenn der Takt entsprechend langsam gewählt wird?
Guest schrieb: > Ok, das heisst man müsste bei der Synthese darauf achten/sicherstellen, > dass der Takt nicht schneller am Eingang anliegt, als das Gatter Zeit > benötigt, bis sich am Ausgang eine Änderung einstellt? Ja, aber das mußt (zumindest bei FPGAs) nicht du machen, sondern du sagst der Toolchain, wie das Timing aussieht (Timing Constraints), und die Toolchain sorgt dann dafür, das es mit den verfügbaren Mitteln geht. Oder sie gibt eine Fehlermeldung aus, wenn sie es nicht schafft, das von dir gewünschte Timing einzuhalten. > aber es ist nur realisierbar, Es ist nicht realisierbar. Diese Richtung von VHDL nach Hardware gibt es nicht! Es ist eine Beobachtung, die an der Hardware gemacht und mit VHDL beschreiben wurde. > wenn der Takt entsprechend langsam gewählt wird? Welchen Takt meinst du? Ein Takt ist da doch gar nicht involviert...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.