Bidirektionaler Bus undefined

[Andreas G. (andy1988)]

Hallo,
ich baue grade an einer Statemachine, die ein HD44780 Display ansteuert. 
Da das jetzt funktioniert, bin ich dabei das ganze etwas zu optimieren. 
Bisher warte ich nach jedem Befehl 40us, auch wenn der Befehl gar nicht 
so lange braucht.
Deswegen wollte ich das Busyflag checken und so etwas Zeit sparen.

Es gibt allerdings keine einzelne Busy-Leitung, sondern man muss die 
Read-Leitung auf High ziehen und dann das oberste Bit des Datenbusses 
betrachten.

Ich hab also etwas gegooglet, wie man einen solchen Bidirektionalen Bus 
behandelt.
Leider funktioniert es in der Simulation nicht wirklich. Anstatt das der 
Augang komplett Low ist, ist der undefined.

Ich habe mal einen kleinen Test implementiert.
Als erstes geht oe auf High, schaltet damit den Bus auf Ausgang und lege 
Daten an den Bus. Der Bus ist undefined. Wie? Watt?
Dann gehe ich in den Wartezustand, der nichts macht und plötzlich, 
mittendrin, wird der Bus XXXXXXXX. Hä?
Das lesen geht dann anschließend wieder, wenn ich dann Daten extern 
anlege und oe auf low ziehe.
Kann mir das jemand erklären?

Und dann noch was:
Kann man sich so auch Kürzschlüsse bauen und den FPGA kaputt machen?
Angenommen ich lege ne 0 an eine Leitung und zur selben Zeit legt die 
andere Seite eine 1 auf die Leitung. Geht da was kaputt?

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

entity bidir_bus is
    Port ( data : inout  STD_LOGIC_VECTOR (7 downto 0);
           clk : in  STD_LOGIC;
           reset : in  STD_LOGIC;
           data_read : out STD_LOGIC_VECTOR (7 downto 0));
end bidir_bus;

architecture Behavioral of bidir_bus is
  signal data_in : STD_LOGIC_VECTOR (7 downto 0) := (others => '0');
  signal data_out : STD_LOGIC_VECTOR (7 downto 0) := (others => '0');
  signal oe : std_logic := '1';
  
  signal i : integer range 0 to 80000 := 0;
  
  type state_sequence is (
    start, write_data, wait1, read_data, done
  );
  signal state : state_sequence := start;
begin
  data_in <= data;
  data <= data_out when oe = '1' else (others => 'Z');
  
  doStuff: process(clk, reset)
  begin
    if reset = '1' then
      oe <= '1';
      data_out <= (others => '0');
      state <= start;
    elsif rising_edge(clk) then
      case state is
        when start =>
          state <= write_data;
          
        when write_data =>
          oe <= '1';
          data_out <= x"55";
          state <= wait1;
          
        when wait1 =>
          if i = 80000 then
            i <= 0;
            oe <= '0';        --prepare for input
            state <= read_data;
          else
            i <= i + 1;
            state <= wait1;
          end if;
            
        when read_data =>
          data_read <= data;
          state <= done;
          
        when done =>
          state <= done;
      end case;
    end if;
  end process;

end Behavioral;

edit:
OK. Bin ein Stück weiter.
Die Xe in ISim meinen wohl tatsächlich Kurzschluss. Denn immer genau die 
Bits sind mit X markiert, bei denen auf der einen Seite eine 1 und auf 
der anderen eine 0 steht. Ich hab das jetzt mal nicht unbedingt auf dem 
FPGA selber testen wollen ;)

Alledings wirft das dann noch ne Frage auf.
Ich muss also unbedingt vorher, bevor die Gegenstelle meint senden zu 
wollen unbedingt auf Z schalten, weil das sonst mächtig warm werden 
könnte?
Ich bastel mal etwas weiter...

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

> Kann man sich so auch Kürzschlüsse bauen und den FPGA kaputt machen?
Ja und wahrscheinlich ja. Wobei idR. ein kurzzeitiger Buskonflikt nur an 
ein paar Pins noch nicht den Tod des FPGAs mit sich bringt.

> Leider funktioniert es in der Simulation nicht wirklich.
Wie sieht denn die Testbench aus? Wird da zum falschen Zeitpunkt was auf 
den Bus getrieben? Wie bekommt dein LCD-Modell mit, dass etwas gelesen 
werden soll? Da fehlt doch noch die Steuerleitung RW...

[Andreas G. (andy1988)]

Lothar Miller schrieb:
>> Kann man sich so auch Kürzschlüsse bauen und den FPGA kaputt machen?
> Ja und wahrscheinlich ja. Wobei idR. ein kurzzeitiger Buskonflikt nur an
> ein paar Pins noch nicht den Tod des FPGAs mit sich bringt.
Grundsätzlich sollte man solche Bus-Wars also vermeiden. Aber damit 
sowas auffällt gibts ja die Simulation, die dann hoffentlich auch 
korrekt ist.

>> Leider funktioniert es in der Simulation nicht wirklich.
> Wie sieht denn die Testbench aus? Wird da zum falschen Zeitpunkt was auf
> den Bus getrieben? Wie bekommt dein LCD-Modell mit, dass etwas gelesen
> werden soll? Da fehlt doch noch die Steuerleitung RW...
Ja. Es lag am Testbench. Ich hab da echt einfach irgendwann nen Wert auf 
den Bius geschoben und keine Steuerleitung angefasst -> Konnte ja nicht 
gut gehen.
Danke für den Schubs in die richtige Richtung.

Nach einigem Frickeln in den letzten Tagen hab ich es grade in der 
Simulation und dann, nach ein wenig Tuning an den Warteschleifen, auch 
endlich auf der Hardware ans laufen gekriegt. Sehr, sehr nervig war das.
Nuja, dafür kann ich jetzt mit Bidirektionalen Signalen umgehen. Auch 
was Wert.