VHDL InOut Ports

[Hubert (Gast)]

Hallo,

dass man InOut Ports nicht innerhalb eines Designs nutzen soll ist klar.
Aber zur Anbindung von ext. Hardware kann dies immer mal wieder 
auftreten (sehr beliebt I2C).

Leider sehe ich immer wieder recht viele Leute die diese INOUTs mit 
durch die unterschiedlichsten Module schleppen.

Nun habe ich in Vortragsfolien von Ronald Hecht (University of Rostock,
Institute of Applied Microelectronics and Computer Engineering) eine
gute Erklärung gefunden wie man dieses elegant lösen kann.

Ich wollte diese Idee hier einfach mal zur Diskussion stellen.

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

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.

Hubert schrieb:
> Leider sehe ich immer wieder recht viele Leute die diese INOUTs mit
> durch die unterschiedlichsten Module schleppen.
Man kann einen inout-Port durchaus einfach "durchreichen" und von einem 
"tiefer" vergrabenen Modul aus ansteuern. Aber eben sinnvollerweise 
nicht von mehreren Modulen aus. Das geht zwar auch, wird aber schnell 
unübersichtlich...

> Leider sehe ich immer wieder recht viele Leute die diese INOUTs mit
> durch die unterschiedlichsten Module schleppen.
Klar, weil es so oft noch in den verwendeten Büchern steht...

> Ich wollte diese Idee hier einfach mal zur Diskussion stellen.
Dieser Ansatz ist der einzig sinnvolle. Wo genau diese 
Richtungsumschaltung erfolgt, ist eigentlich egal. Es sollte aber eben 
nur an genau 1 Stelle passieren.
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"...

[Freddy (Gast)]

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 M. (Firma: Titel) (lkmiller) (Moderator)]

Freddy schrieb:
> Genauso ist es auch Geschmackssache ob es (wie der Autor es in der
> Grafik beschreibt) alles über Records löst.
Ich sehe die Records auch eher zwiespältig:
Der Profi kann damit Zeit einsparen (wenn Ports angepasst werden müssen) 
und seine Simulation sicherer machen (den (Eingangs-)Record in die 
Sensitivliste und gut is).
Der Anfänger lernt so aber gar nicht, was eine unvollständige 
Sensitivliste bewirken kann. Wehe, wenn er dann mal ein "altes" Design 
in die Finger bekommt und ändern muss. Und er lernt nicht, dass Hardware 
vorher durchdacht und definiert sein will/soll (besonders an den 
Schnittstellen aka. Ports).

[Hans (Gast)]

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.

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

Naja, wir hätten als bidirektionalen Bus immerhin noch den zu Anfang 
aufgeführten I2C Bus... ;-)

[Klaus (Gast)]

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! ;-)

[Bronco (Gast)]

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?

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

Bronco schrieb:
> und den Rest der Toolchain überlasse
Welchen "Rest"? Umschalten musst doch sowieso du selber. Denn nur du 
weißt, wann du was ausgeben willst/sollst/darfst...

[Bronco (Gast)]

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

DataIn <= MEININOUTPIN;
if (DataDir = '1') then
    MEININOUTPIN <= DataOut;
else
    MEININOUTPIN <= 'Z';
end if;

Macht das einen Unterschied? Eigentlich nicht, oder?