Sally ich / wir verzweifeln hier total. Wir wollen einen INOUT Datenbus
erzeugen und wollten ihn zu beginn auf den zustand 'z' setzen.
Jedoch "weigert" sich irgendwie das Modelsim....
Das ist die erste datei...
Meiner Meinung nach wird von Modelsim die Entity ASIC nicht instanziert,
weil die comonent Beschreibung in der Testbench nicht übereinstimmt :
Verwendung von std_logic und std_ulogic in den ports.
Jan M. wrote:
>>Jedoch "weigert" sich irgendwie das Modelsim....>> Ja, was tut es denn? Bei dem geposteten Code der testbench sollte es nur> so Fehlermeldungen hageln.
Jo das stimmt warscheinlich schon bei dem Auszug. Wir haben den
Testbench gekürzt. Es hagelt beim orginal keine fehler.
Gruss Achim
Hallo,
zuerst einmal danke für eure Antworten und Vorschläge.
Modelsim instantiiert den rsel(4 downto 0) std_logic_vector
ordnungsgemäß, nur den dbus(7 downto 0) nicht.
Beide sind von Typ std_logic_vector und das auch in beiden
Architekturen. Deswegen kann ich mir nicht vorstellen, dass der Fehler
an dem liegen kann.
In einem weiterem Schritt haben wir nur das INOUT Signal in dem Entity
gelassen, dass Ergebnis war aber das gleiche. Der Zustand blieb bei 'U'.
Grüße
Markus
> INOUT ist nicht gut. Macht lieber zwei getrennte Busse für Ein- und> Ausgang.
Aussen auf der Platine gehts idR. gar nicht anders, da gibt es nur 1
Datenbus, der wird zum Lesen und Schreiben verwendet.
Das Ding ist... das mit dem INOUT kam von unserem Prof. Diese
Test_des.vhd Datei sollte unser Code auf die richtige Funktionsweise
prüfen und ob die Verschlüsselung bzw. Entschlüsselung funktioniert.
Gibt es keine Möglichkeit ein INOUT Bus zu verwenden oder ist das
Allgemein eine schlechte Lösung ?
Hallo!
Ich habe die 2. Datei mal ein wenig abgespeckt und schon läut es.
Gerade die Beschreibung der clock kommen mir bei deinem code etwas
seltsam vor. Ich habe sie mal in den Process gebracht und etwas
vereinfacht.
Konnte dein Modelsim Compiler überhaupt das übersetzen? Und wen ja,
läuft die Simulation an?
Der Besucher
ENTITY test_des IS
END test_des;
LIBRARY ieee;
USE ieee.std_logic_1164.all;
ARCHITECTURE struktur OF test_des IS
CONSTANT tcyc: time := 100 ns;
COMPONENT asic
PORT(reset: IN std_ulogic; -- reset
clk: IN std_ulogic; -- clock
cs: IN std_ulogic; -- chip select
rd: IN std_ulogic; -- read
wr: IN std_ulogic; -- write
int: OUT std_ulogic; -- interrupt
dbus: INOUT std_logic_vector(7 DOWNTO 0);
rsel: IN std_logic_vector(4 DOWNTO 0));
END COMPONENT;
SIGNAL reset: std_ulogic := '0';
SIGNAL clk: std_ulogic := '0';
SIGNAL cs: std_logic := '1';
SIGNAL rd: std_logic := '1';
SIGNAL wr: std_logic := '1';
SIGNAL int: std_logic := '1';
SIGNAL hlt: std_ulogic := '0';
SIGNAL dbus: std_logic_vector(7 DOWNTO 0) := (OTHERS => 'Z');
SIGNAL rsel: std_logic_vector(4 DOWNTO 0) := (OTHERS => 'Z');
BEGIN
u1: asic PORT MAP(reset, clk, cs, rd, wr, int, dbus, rsel);
stim: process
BEGIN
cs <= '0';
rd <= '0';
wr <= '0';
rsel <= (others => '0');
loop
clk <= '1' AFTER tcyc/2 , '0' AFTER tcyc;
wait for tcyc;
end loop;
END PROCESS;
reset <= '0', '1' AFTER 3*tcyc;
END struktur;
Ich sitze gerade an einer linux-kiste, werde aber heute Abend es gleich
Testen.
Die Simulation zu starten war kein Problem. Es gab keine Fehler beim
Compilieren.
Danke schonmal.
Die Simulation lief auch einige Zeit?
Denn direkt nach dem laden ist der dbus auch bei mir erst noch auf "U".
Erst wenn einige delta-zyklen gelaufen sind wechselt dbus auf "Z".
Der Besucher
Ja, die Simu. lieft solange ich sie hab laufen lassen... d.h. der
Process hat schon längst die Daten auf den dbus gelegt, nur da dieser
'U' war, konnte der andere Process nichts lesen.
Aber sei's drum ;-)
> ... std_ulogic ...
Kein Kommentar.
Oder doch:
Früher, ja damals, als Männer noch Männer und die Rechner noch so
richtig schwach auf der Brust waren, da hat es noch signifikante
Geschwindigkeitsvorteile gebracht, die Logik nicht aufzulösen. Aber in
den VHDL-Codes, die in der Praxis zu sehen sind ist dieser Datentyp
ausgestorben.
jetzt läuft es mit dem INOUT bus. Die Lösung vom Besucher funktioniert
sehr gut soweit ich das beurteilen kann. Wieso es aber funktioniert weiß
ich aber immer noch nicht.
Nachdem der Bus instantiiert wurde hab ich angefangen die processe
wieder einzusetzen und es ging immer noch :) .
zum Schluss wollte ich aber wissen was der unterschied zwischen eurer
Lösung und der von meine Prof. war. Beim einem Dokumenten Vergleich ist
herausgekommen, dass nur ein paar Zeilen verdreht waren.
Einmal waren die Entity und die Lib verdreht und als zweites die tcty
mit dem subtype.
1
ENTITYtest_desIS
2
ENDtest_des;
3
4
LIBRARYieee;
5
USEieee.std_logic_1164.all;
6
USEwork.types.all;
7
8
ENTITYtest_desIS
9
ENDtest_des;
und...
1
CONSTANTtcyc:time:=100ns;
2
SUBTYPEbyteISbit_vector(7DOWNTO0);
3
SUBTYPEt_rselISbit_vector(4DOWNTO0);
4
CONSTANTtcyc:time:=100ns;
Nach meinem Verständnis müssten beide Lösungen funktionieren.
Also hab ich die Datei vom Prof. im .txt Editor geöffnet -> (strg+c) und
dann mit der anderen Lösung ersetzt... compiliert, simuliert... dbus =
'U'.
Aus irgendeinen Grund will der anscheinend gleich aussehende code von
meinem Prof nicht laufen. Die zusammengesetzte lösung von euch aber
schon.
Zwar ist das auch eine Erkenntnis aber viel anfangen kann ich damit
nicht.
@ Lothar
Deine Lösung mit dem CLK finde ich auch übersichtlicher aber wie schon
gesagt, war es die Lösung von meinem Prof.
Danke für eure Hilfe.
Gruß
Markus
Hallo,
konnte mich beim Lesen mal nicht zurückhalten und geb mal meinen Senf
dazu:
Modeliert ist ein Baustein mit IO-Bus welcher seinen Bus in den
hochohmigen Zustand schaltet und Ihr wundert euch warum in der
Simulation der Bus 'U'ndefined ist?
Ist wie im richtigen Leben, ein Bus ohne Abschluss floatet, sprich
dessen Zustand ist undefined...
Sowas sollte man auf realer Hardware tunlichst vermeiden ( Es sei denn
man weiss was man tut).
Analog zu diesem Problem hierzu gibt es im Typ std_logic die weichen
Pegel H und L mit denen externe Pull-Ups und Pull-Downs nachempfunden
werden, diese sorgen wiederum in der Simulation für definierte Pegel
wenn alle Treiber im 'Z' Zustand sind.
Gruss
@bergmann_a
Nein, es ist schon richtig. Wenn man einem inout port von "innen"
hochohmig 'Z' zuweist und von "außen" hochohmig 'Z' treibt, dann zeigt
die Simulation ebenfalls hochohmig.
Außerdem steht 'U' nicht für undefined, sondern für uninitialized.
> Ist wie im richtigen Leben, ein Bus ohne Abschluss floatet, sprich> dessen Zustand ist undefined...
'Z' ist ein sehr wohl definierter Zustand.
'X' wäre undefiniert. Das passiert, wenn z.B. ein Teilnehmer '0', der
andere '1' treibt. So eine Konstellation kann nicht aufgelöst werden.
Sicherlich ist es nicht fein, wenn ein Bus floatet. Aber eigentlich ging
es doch nur darum einen Weg zu finden, dass die Testbench funktioniert,
ohne völlig neue Signalpegel eingeführt werden (es scheint sich ja um
eine Übungsaufgabe zu handeln). Und was wissen wir dadrüber, welche
anderen Instanzen noch den Bus treiben. Vielleicht gibt es auch gar
keinen externen Pull. Es gibt ja auch noch andere Möglichkeiten, um den
Bus nicht floaten zu lassen. Und das Signal ist nach Änderung der TB
eben nicht mehr "U", sondern zeigt schon den hochohmigen Zustand. Wie
der hochohmige Zustand jetzt zu bewerten ist, liegt aber jetzt in der
Verantwortung des Designers.
Entscheidender könnte eher sein, ob man resoveld oder unresolved
benutzt, wenn man mit mehreren Treibern arbeitet.
Der Besucher
