VHDL InOut Ports

Lothar Miller schrieb:
> Ob allerdings "driven" ein sinnvoller Name für das Output-Enable-Signal
> ist, möchte ich doch in Frage stellen. Oder kommt das "driven" gar von
> "DRIVe ENable"...

da gebe ich Dir absolut Recht, Drive_en wäre sinnvoller gewesen.
Genauso ist es auch Geschmackssache ob es (wie der Autor es in der 
Grafik beschreibt) alles über Records löst.
Sicherlich sind Records eine sinnvolle Erweiterung, aber ich denke 
wichtige Signale wie clk, rst, wr_en, rd_en, din, dout sollten nicht 
über Records beschrieben werden damit man die Übersicht nicht verliert.

Lothar Miller schrieb:
> Hubert schrieb:
>> dass man InOut Ports nicht innerhalb eines Designs nutzen soll ist klar.
> Man kann sie eigenlich auch nicht nutzen, weil es sowas im FPGA gar
> nicht gibt. Jeder inout Port innerhalb eines FPGAs muss daher in einen
> Multiplexer aufgelöst werden.

Und weil es sich nicht gibt, macht es auch keinen Sinn, sie theoretisch 
einzuführen. Funktionstechnisch bidirektionale Busse und Signallayer in 
FPGAs sind immer als Hin-Rück-Weg zu beschreiben, weil sie für die 
meisten Anwendungen nicht benötigt werden, die halbe Funktionsschicht 
damit wegfällt und die Implementierung nur mehr Aufwand bedeutet, die 
Platz und Geld kostet, um ein paar Leitungen zu sparen. Innerhalb der 
FPGAs macht es keinen Sinn.

Mit steigenden Taktfrequenzen macht es auch ausserhalb der FPGAs keinen 
Sinn mehr, weil die Bandbreiten in den FPGAs inzwischen deutlich grösser 
sind, als was drausen transportierbar ist und damit die Leitungen eh 
schon Flaschhals sind. Leitungen durch Buffer umzuschalten is out.

Der Aufrechterhalt bidirektionaler Verbindungen ist daher ohnehin 
Quatsch und an der Realität vorbei. Der Herr Professor kommt 25 Jahre zu 
spät.

Hans schrieb:
> Leitungen durch Buffer umzuschalten is out.
>
> Der Aufrechterhalt bidirektionaler Verbindungen ist daher ohnehin
> Quatsch und an der Realität vorbei.

Verallgemeinerungen sind immer falsch! ;-)

Jetzt muß ich mal was doofes Fragen:

Macht es denn einen Unterschied, ob ich ein Signal als "inout" definiere 
und den Rest der Toolchain überlasse, ober ob ich das selber händisch 
die beschriebene Lösung auscodiere?

Sorry, ich meinte:

1. Fall:
Ich ziehe ein einziges "inout"-Signal durch 10 Hierarchie-Ebenen 
hindurch in das Zielmodul, wo ich dann das Signal lese und entweder '0', 
'1' oder 'Z' draufschreibe.

2. Fall:
Ich ziehe drei Signale (ich nenne sie mal "DataIn, DataOut, DataDir") 
durch 10 Hierarchie-Ebenen und habe im TopLevel-Modul so etwas wie

1

DataIn <= MEININOUTPIN;

2

if (DataDir = '1') then

3

    MEININOUTPIN <= DataOut;

4

else

5

    MEININOUTPIN <= 'Z';

6

end if;

Macht das einen Unterschied? Eigentlich nicht, oder?