Forum: FPGA, VHDL & Co. INOUT immer im 'U' Zustand


von Markus K. (hyperion)


Lesenswert?

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...
1
library ieee;
2
use ieee.std_logic_1164.all;
3
--use ieee.std_logic_unsigned.all;   
4
--use ieee.std_logic_arith.conv_std_logic_vector; 
5
6
entity ASIC is
7
  port (RESET, CLK : in std_logic;
8
      CS, RD, WR : in std_logic;
9
      INT : out std_logic;
10
      DBUS : inout std_logic_vector (7 downto 0);      
11
      RSEL : in std_logic_vector (4 downto 0));
12
end ASIC;
13
14
architecture BEHAVIOR of ASIC is
15
    begin
16
    DBUS <= (others => 'Z'); 
17
      
18
end BEHAVIOR;



und die zweite datei..
1
ENTITY test_des IS
2
END test_des;
3
4
LIBRARY ieee;
5
USE ieee.std_logic_1164.all;
6
USE work.types.all;
7
8
ARCHITECTURE struktur OF test_des IS
9
  CONSTANT tcyc: time := 100 ns;
10
  SUBTYPE byte IS bit_vector(7 DOWNTO 0);
11
  SUBTYPE t_rsel IS bit_vector(4 DOWNTO 0);
12
13
  COMPONENT asic
14
    PORT(reset: IN    std_ulogic;  -- reset
15
         clk:   IN    std_ulogic;  -- clock
16
         cs:    IN    std_ulogic;  -- chip select
17
         rd:    IN    std_ulogic;  -- read
18
         wr:    IN    std_ulogic;  -- write
19
         int:   OUT   std_ulogic;  -- interrupt
20
         dbus:  INOUT std_logic_vector(7 DOWNTO 0);
21
         rsel:  IN    std_logic_vector(4 DOWNTO 0));
22
  END COMPONENT;
23
24
  SIGNAL reset: std_ulogic := '0';
25
  SIGNAL clk:   std_ulogic := '0';
26
  SIGNAL cs:    std_logic  := '1';
27
  SIGNAL rd:    std_logic  := '1';
28
  SIGNAL wr:    std_logic  := '1';
29
  SIGNAL int:   std_logic  := '1';
30
  SIGNAL hlt:   std_ulogic := '0';
31
  SIGNAL dbus:  std_logic_vector(7 DOWNTO 0) := (OTHERS => 'Z');
32
  SIGNAL rsel:  std_logic_vector(4 DOWNTO 0) := (OTHERS => 'Z');
33
  
34
BEGIN
35
  u1: asic PORT MAP(reset, clk, cs, rd, wr, int, dbus, rsel);
36
  
37
  ....
38
    PROCEDURE ReadSCR(val: OUT byte) IS
39
    BEGIN
40
      ReadByte("11000", val);
41
    END ReadSCR;
42
    
43
    PROCEDURE WaitOn(pos: integer) IS
44
      VARIABLE val: byte;
45
    BEGIN
46
      ReadSCR(val);
47
      WHILE val(pos)='0' LOOP
48
        ReadSCR(val);
49
      END LOOP;
50
    END WaitOn;
51
52
    CONSTANT Ready: integer := 4;
53
    VARIABLE iv: std_logic_vector(1 TO 64);
54
    VARIABLE cipher: word64;
55
  BEGIN
56
    WAIT UNTIL clk'EVENT AND clk='1' AND reset='1';
57
    FOR i IN frames'RANGE LOOP
58
      WriteBlk(test1(i).plain);
59
      WriteKey(test1(i).key);
60
      WriteSCR("00000001");
61
      WaitOn(Ready);
62
      ReadBlk(cipher);
63
      ASSERT cipher=test1(i).cipher REPORT "wrong encryption" SEVERITY error;
64
    END LOOP;
65
        
66
    hlt <= '1';
67
  END PROCESS;
68
69
  reset <= '0', '1' AFTER 3*tcyc;
70
71
  clk <= '1' AFTER tcyc/2 WHEN (clk='0' AND hlt='0') ELSE '0' AFTER tcyc/2;
72
73
END struktur;

Die andere Threads konnten uns nicht weiter helfen.

Grüße
Markus

von Jan M. (mueschel)


Lesenswert?

>Jedoch "weigert" sich irgendwie das Modelsim....

Ja, was tut es denn? Bei dem geposteten Code der testbench sollte es nur 
so Fehlermeldungen hageln.

von Klaus F. (kfalser)


Lesenswert?

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.

von Achim V. (sciutr2d2)


Lesenswert?

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

von Markus K. (hyperion)


Lesenswert?

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

von Ron (Gast)


Lesenswert?

INOUT ist nicht gut. Macht lieber zwei getrennte Busse für Ein- und 
Ausgang.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

> 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.

von Markus K. (hyperion)


Lesenswert?

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 ?

von Der Besucher (Gast)


Lesenswert?

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;

von Markus K. (hyperion)


Lesenswert?

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.

von Der Besucher (Gast)


Lesenswert?

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

von Markus K. (hyperion)


Lesenswert?

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.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Das
1
  clk <= '1' AFTER tcyc/2 WHEN (clk='0' AND hlt='0') ELSE '0' AFTER tcyc/2;
wäre so etwas kompakter und übersichtlicher:
1
  clk <= not clk AFTER tcyc/2 WHEN (hlt='0') ELSE '0';

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.

von Markus K. (hyperion)


Lesenswert?

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
ENTITY test_des IS
2
END test_des;
3
4
LIBRARY ieee;
5
USE ieee.std_logic_1164.all;
6
USE work.types.all;
7
8
ENTITY test_des IS
9
END test_des;

und...
1
CONSTANT tcyc: time := 100 ns;                   
2
SUBTYPE byte IS bit_vector(7 DOWNTO 0);
3
SUBTYPE t_rsel IS bit_vector(4 DOWNTO 0);
4
CONSTANT tcyc: time := 100 ns;


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

von Der Besucher (Gast)


Lesenswert?

Hat dein Kürzel (hyperion) etwas mit den Romanen von Dan Simmons zu tun?
Nur mal so interessehalber.

Der Besucher

von bergmann_a (Gast)


Lesenswert?

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

von Klaus F. (kfalser)


Lesenswert?

@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.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

> 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.

von Der Besucher (Gast)


Lesenswert?

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

Bitte 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
Noch kein Account? Hier anmelden.