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.
Hubert schrieb:> dass man InOut Ports nicht innerhalb eines Designs nutzen soll ist klar.
Man kann sie eigenlich auch nicht nutzen, weil es sowas imFPGA 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"...
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.
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).
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?
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...
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
endif;
Macht das einen Unterschied? Eigentlich nicht, oder?
INOUT_Principle.png
(11 KB)
