Hallo,
die Frage ist eigentlich schon im Betreff gestellt.
Nun ist es aber so, das die Signale vom verschiedenen Typ
sein können. Konkret um einmal bit, einmal std_logic
entity tb is
end;
architecure testbench of tb is
signal s: bit;
begin
s <= '0';
s <= '1';
end;
root@mond---[22:30:49]---/pool/PROG/vhdl/10 # ghdl -a tb.vhd
root@mond---[22:30:52]---/pool/PROG/vhdl/10 # ghdl -e config
root@mond---[22:30:55]---/pool/PROG/vhdl/10 # ./config
.tb(testbench).s
./config:error: several sources for unresolved signal
ich verstehe warum es hier zum Konflikt kommt
und zum Runtime kommt die exception
jetzt das ganze mit std_logic
architecure testbench of tb is
signal s: std_logic;
begin
s <= '1'; -- string 1
s <= 'L'; -- weak 0
end;
std_logic ist resolved, logischerweise gewinnt starke 1
dies ist der Fall worauf meine Frage abziehlt
man hört doch man soll sowas nicht machen
(aus mehreren Processen ein Signal treiben)
allerdings scheint mir, dass es hier kein
undefined behaviour ist (keine Ahnung wie es in vhdl heisst)
was mich aber gewundert hat, ist das
architecure testbench of tb is
signal s: std_logic;
begin
s <= '1'; -- string 1
s <= '0'; -- string 0
end;
zur Laufzeit keine exception schmeisst.
Oder ist es eher so, dass s dann zu 'X' wird?
ein assert s = 'X'; ging leider nicht
operator = war undefiniert
Schreibt VHDL da vor wie sich ein Simulator
verhalten soll?
Gruss, Daniel
Diese Frage bringt Dich auch nicht weiter. In der Hardware geht sowas einfach nicht, egal ob der Simulator es kann oder nicht.
Hallo Daniel, wie Du schon richtig schreibts, std_logic ist resolved. Daher ist es lt. VHDL zulässig, dieses Signal aus zwei Prozessen (oder Components, Concurrent Assingments, ...) zu treiben. Was dann passiert ist in der Resolution Funktion definiert. So ergibt 1 und L = 1, 1 und 0 aber X. Bei der Synthese ist sowas aber mit vorsicht zu behandeln. Ich würde dieses vermeiden wann immer möglich. Es gibt ein paar Anwendungen, wo sowas Sinn macht - dies sind i.d.R. Busse, wo mehr als ein Mudol drauf treiben. Die Busse sind normalerweise tristate (oder haben einen pull up oder pull down oder bushold - hardwaretechnisch gesehen). Dabei überschreibt dann 0 oder 1 diese Werte (Z, H, L, ... H und L sind als "weak" 1 oder 0 definiert, d.h. wenn z.B. H an den Eingang eines Gatters gelegt wird, wird das wie ne 1 interpretiert ...) (Bin kein FPGA Mensch, weiss nicht was welche FPGAs und FPGA Synthesetools bzgl. Tristate machen/können.) In der Simulation ist das Verhalten durch VHDL bzw. die zugehörigen Libraries genau beschrieben (genaugenommen: std_logic und deren resolved function ist auch nix anderes, als wenn Du Dir nen eigenen Datentypen definierst, als resolved und dann die zugehörigen Resolution Function selber definierts. Std_logic ist im Package stdlogic definiert. Die Source dazu steht in aller Regel irgendwo bei Deinem Simulatio-Install-Verzeichniss, sinnigerweise unter <source>/IEEE/... Schau dort einfach mal rein: Std_logic is resolved Std_ulogic, d.h. Std-ulogic definiert den Datentyp als UX01ZWLH- Für Std_logic gibt es ne zugehörige Resolution Function, die im Package-Body beschrieben ist. Ach ja, das ganze geht auch als Vector, std_locic_vector - ist das resolved Pendant zu sld_ulogic_vector. Bzgl: > architecure testbench of tb is > signal s: std_logic; > begin > s <= '1'; -- string 1 > s <= '0'; -- string 0 > end; > > zur Laufzeit keine exception schmeisst. > Oder ist es eher so, dass s dann zu 'X' wird? Genau! Deshalb verwendet man Resolved Signale ;-) Simulier das einfach mal, dann siehst Du das X ... ----- Simulation vs. Synthese: Das Verhalten Deiner Beschreibung wird durch den VHDL-Standard und die Packages definiert. Der Simulator bildet dies i.d.R. zu 100% nach (wenn nicht, würd ich mir nen anderen Simulator suchen ;-). Die Synthese kann zur Teile von VHDL synthetisieren und macht dabei bestimmte Angaben. Anwendungen für Resolved sind z.B. Tri-State-Busse, kann m.E. sowohl für Simulation als auch für Synthese sein. Nur um den Code in einer Testbench vermeintlich "besser" zu schreiben (z.B. ein Prozess setzt ein Signal, ein anderer löscht es wieder), würde ich keine Resolved SIgnale verwenden, da gibt es andere Lösungen dafür. Gruss, Alex
Danke für die Antworten da ich im Moment eh keine Hardware zur Synthese habe mit der ich spielen könnte, konzentiere ich mich auf VHDL aus der Sicht des Simulators soweit ich mich recht entsinne ist VHDL LRM auch nur eine Beschreibung von VHDL wie ein Simulator den Code handhaben soll und nicht was die Synthese daraus macht. Ich habe 2 weitere Fragen, die mir gestern in den Sinn kamen 1) Hat sich jemand hier schon Gedanken gemacht wie so eine Event-driven-simulation in C++ ausschaut? ich dachte da konkret an kleine C++ Engine, die VHDL nachbildet. Damit wollte ich sichergehen, dass ich die Reihenfolge der Abarbeitung eines Events verstehe. Zb wann Signal activ wird, wann event generiert wird. wie timing ge-handelt wird, wann process execution an der Reihe ist und so weiter 2) resolved ist also da um Busse zu beschreiben könnte jemand kleines Beispielkode einfügen, wie eine tri-state fähige Hardware in VHDL beschrieben wird? (nicht nur für Simulation sondern auch Synthese) Gruss, Daniel
Ich glaube das ghdl, das Du verwendest, ist in C++ programmiert. Dort könntest Du dir den ganzen Mechanismus einmal ansehen. Der Mechanismus in allen Feinheiten ist aber komplizierter als es den Anschein hat, dazu gibt es ganze Bücher. Kurze Zusammenfassung : Zuerst einmal gibt es für jedes Signal und für jeden Prozess, der das Signal ändert, eine Event Queue (Ereignis-Liste), in der die zukünftigen Signal-Änderungen festgehalten werden (Neuer Pegel, Zeitpunkt der Änderung). Dann gibt es eine Reihe von Prozessen, welche die Signale ändern. Prozesse entstehen nicht nur wenn man ein prozess-Statement schreibt, sondern sogar die Zeile s <= '1'; aus Deinem Beispiel erzeugt einen Prozess. Alle Prozesse werden beim Starten der Simulation aktiviert und laufen bis zum Ende oder bis zu einem wait-statement. Dabei erzeugen sie Signal-Änderungen für zukünftige Zeitpunkte. In Deinem Beispiel erzeugt s <= '1'; die Signaländerung von 'U' auf '1'. Der VHDL-Simulator verwendet dabei eine Methode, die man Delta Zyklus nennt. Wenn in der Zuweisung keine Verzögerung angegeben ist, gilt die Zuweisung für den gleichen Zeitpunkt, aber einen "Augenblick" (1 Delta-Zyklus) später. In Deinem Beispiel ist die Zeit bei der Zuweisung 0 ns, der neue Wert gilt für 0 ns + 1 Delta Cycle. Erst wenn ALLE Prozesse abgearbeitet sind, dann werden die Werte für die Signale neu berechnet und zugewiesen. In Deinem Fall hat es 2 Prozesse gegeben, welche das Signal s zu Zeitpunt t = 0 ns + 1 Delta ändern wollten. Das Ergebnis ist 'X'. Der Simulator rückt dann die Zeit weiter (eventuell nur um einen Delta Zyklus) und startet alle Prozesse neu (oder setzt sie am wait-statement fort), welche auf eine Änderung der geänderten Signale warten. In Deinem Fall gibt es keine solchen Prozesse, und außerdem keine weiteren Signal-Änderungen -> d.h. der Simulator stoppt. Zur Synthese von resolved signalen : Wie gesagt wurde braucht man resolved Signale zur modellierung von Bussen, und bei Bussen soll immer nur ein Modul den Bus treiben, alle anderen sollen tri-staten. Es gibt aber wenige FPGA's, welche interne, tri-state fähige Busse haben. Resolved Signale werden deshalb meist nur in Testbenches sinnvoll eingesetzt. Man verwendet andererseits auch bei Modulen, die man synthetisiert, meistens den type "std_logic", aber unnötigerweise. Grüße Klaus
Hallo Klaus, Danke für die ausführliche Erklärung Ich lese zZ ein Buch "VHDL for logic Synthesis" von Andrew Rushton und er beschreibt kurz die Arbeitsweise vom Simulator. Das auch simple s <= '1'; ein Process ist, das war mir klar. Auch wenig gebrauchte Syntax name: s <= '1'; ist analog zu name: process begin end process;
bin auf Returntaste aus Versehen und zu schnell abgeschickt :)
name: process
begin
s <= '1';
end process;
ist äqivalent zu
name: s <= '1';
wobei der letzte Process implizit Abhängig von allen
Events die auf der rechten Seite von <= stehen.
und beim ersten muss explizit eine sensitive list stehen.
(oder "wait on" im Processblock)
ghdl ist in Ada geschrieben, ich denke weil Frontend
von Ada und vhdl ähnlich sind(?)
Gruss, Daniel
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.