mikrocontroller.net

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


Autor: Markus K. (hyperion)
Datum:

Bewertung
0 lesenswert
nicht 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...
library ieee;
use ieee.std_logic_1164.all;
--use ieee.std_logic_unsigned.all;   
--use ieee.std_logic_arith.conv_std_logic_vector; 

entity ASIC is
  port (RESET, CLK : in std_logic;
      CS, RD, WR : in std_logic;
      INT : out std_logic;
      DBUS : inout std_logic_vector (7 downto 0);      
      RSEL : in std_logic_vector (4 downto 0));
end ASIC;

architecture BEHAVIOR of ASIC is
    begin
    DBUS <= (others => 'Z'); 
      
end BEHAVIOR; 



und die zweite datei..
ENTITY test_des IS
END test_des;

LIBRARY ieee;
USE ieee.std_logic_1164.all;
USE work.types.all;

ARCHITECTURE struktur OF test_des IS
  CONSTANT tcyc: time := 100 ns;
  SUBTYPE byte IS bit_vector(7 DOWNTO 0);
  SUBTYPE t_rsel IS bit_vector(4 DOWNTO 0);

  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);
  
  ....
    PROCEDURE ReadSCR(val: OUT byte) IS
    BEGIN
      ReadByte("11000", val);
    END ReadSCR;
    
    PROCEDURE WaitOn(pos: integer) IS
      VARIABLE val: byte;
    BEGIN
      ReadSCR(val);
      WHILE val(pos)='0' LOOP
        ReadSCR(val);
      END LOOP;
    END WaitOn;

    CONSTANT Ready: integer := 4;
    VARIABLE iv: std_logic_vector(1 TO 64);
    VARIABLE cipher: word64;
  BEGIN
    WAIT UNTIL clk'EVENT AND clk='1' AND reset='1';
    FOR i IN frames'RANGE LOOP
      WriteBlk(test1(i).plain);
      WriteKey(test1(i).key);
      WriteSCR("00000001");
      WaitOn(Ready);
      ReadBlk(cipher);
      ASSERT cipher=test1(i).cipher REPORT "wrong encryption" SEVERITY error;
    END LOOP;
        
    hlt <= '1';
  END PROCESS;

  reset <= '0', '1' AFTER 3*tcyc;

  clk <= '1' AFTER tcyc/2 WHEN (clk='0' AND hlt='0') ELSE '0' AFTER tcyc/2;

END struktur;

Die andere Threads konnten uns nicht weiter helfen.

Grüße
Markus

Autor: Jan M. (mueschel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Jedoch "weigert" sich irgendwie das Modelsim....

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

Autor: Klaus Falser (kfalser)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Achim Vogt (sciutr2d2)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Markus K. (hyperion)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Ron (Gast)
Datum:

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

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Markus K. (hyperion)
Datum:

Bewertung
0 lesenswert
nicht 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 ?

Autor: Der Besucher (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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;

Autor: Markus K. (hyperion)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Der Besucher (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Markus K. (hyperion)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das
  clk <= '1' AFTER tcyc/2 WHEN (clk='0' AND hlt='0') ELSE '0' AFTER tcyc/2;
wäre so etwas kompakter und übersichtlicher:
  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.

Autor: Markus K. (hyperion)
Datum:

Bewertung
0 lesenswert
nicht 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.
ENTITY test_des IS
END test_des;

LIBRARY ieee;
USE ieee.std_logic_1164.all;
USE work.types.all;

ENTITY test_des IS
END test_des;

und...
CONSTANT tcyc: time := 100 ns;                   
SUBTYPE byte IS bit_vector(7 DOWNTO 0);
SUBTYPE t_rsel IS bit_vector(4 DOWNTO 0);
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

Autor: Der Besucher (Gast)
Datum:

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

Der Besucher

Autor: bergmann_a (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Klaus Falser (kfalser)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Der Besucher (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.