INOUTs von Component auf 'signal' von Top-Level Entity

[Maik R. (kiamur)]

Hallo!

Ich versuche folgendes mit einem Altera Stratix FPGA in der Quartus II 
Software 7.0 und VHDL zu realisieren:

Ich habe ein Entity, welches ein Interface zum SRAM auf meinem Board 
ist. Es hat eine 'data' INOUT und jeweils ein 'data1' und 'data2' INOUT 
zu den beiden SRAM Bausteinen. Ich nenne 'data' mal den logischen und 
'data1' und 'data2' mal die physikalischen Ports.

Ich denke, dass ich die beiden physikalischen Ports ganz gut im Griff 
habe. Je nach Datenrichtung werden die in der Simulation schön auf 'Z' 
oder eben nicht geschaltet.

Mein Problem ist nun der logische Datenbus. Dieser wird an das Top-Level 
Entity meines Designs angeschlossen, und ist ja auch ein INOUT.
Vielleicht habe ich nun einen Denkfehler, aber alle logischen Ein- bzw. 
Ausgänge von Components, die in einem Top-Level Entity eigebettet sind, 
werden doch mit dem Top-Level Entity über 'signals' des Top-Level 
Entities verbunden, so dass die beiden miteinander kommunizieren können, 
oder?

Ich habe also ein als 'signal' deklarierten std_logic_vector (-> den 
INOUT Datenbus) in meinem Top-Level Entity deklariert, und versuche nun 
diesen mit dem logischen Datenbus vom 'SRAM Interface' Entity zu 
verbinden.
Leider kann ich in einer 'signal' Deklaration ja nicht angeben, dass 
dies ein INOUT Signal sein soll, und bekomme nun immer 
Kompilierungsfehler ("The <pinname> has multiple drivers").

Lange Rede kurzer Sinn:
Wie kann ich auf einen logischen INOUT Datenbus eines als Component 
eingebetteten Entities, vom Top-Level Entity aus auf diesen Bus 
schreiben, bzw. von diesem Bus lesen?

Bei totaler Konfusion könnte ich ja auch mein Projekt hier reinstellen, 
aber ich habe Angst, dass ihr euch dann auf andere Dinge in meinem 
(wahrscheinlich nicht so dollem) Design einschießt, als diese Frage zu 
beantworten. . . ;-)

Gruß
Maik

[Christian P. (kron)]

Man soll wohl INOUTS eigentlich nur im Top-Level nutzen,
aber es geht auch so.
Du machst zwei Signale (data_in und data_out),
die du dann mit der bekannten "Z-Methode" mit
dem INOUT verbindest, also

data_in <= data;
und
data <= data_out when switch = '1' else others => 'Z';

[Kim N. (kim)]

Hi
also ich kenn mich nur mit ISE aus hab mal im Anhang ein Projekt von mir 
Angehängt (ISE)  kannst ja mach checken ob das bei denen auch so geht.

das heísst wenn ich deine Frage richtig verstanden habe ;)
ansonsten ignorieren
gruss
KIm

[Maik R. (kiamur)]

Hallo Christian!

Danke für den Tip, und deine Mühe dir meine Frage durchzulesen (und 
offenbar auch zu verstehen)!
Als ich meine Frage losgeschickt hatte, bin ich auch auf die Idee 
gekommen, und habe dann gemerkt, dass ich es bei den physikalischen 
INOUTS ja auch schon so gemacht habe. . . (AnDieStirnKlatsch)

>Man soll wohl INOUTS eigentlich nur im Top-Level nutzen,
Gibt es dafür auch eine Begründung? Denn wie sollte ich denn interne 
Datenbusse zwischen den Components eines Top-Levels sonst realisieren? 
Jeweils immer n-Bit als In und wieder n-Bit als Out deklarieren? Hmmm . 
. .

Gruß
Maik

[Maik R. (kiamur)]

Hallo Kim!

Du hast es dann wohl so gemacht, wie ich in meiner Antwort auf 
Christians Frage gemutmaßt habe.

Würde mich mal interessieren, wie hier die Meinungen (und Begründungen) 
anderer Forumsteilnehmer sind.

Gruß
Maik

[Johnsn (Gast)]

@Maik Ritter:
Inout Signale macht man deshalb nur in der Toplevelentity, weil 
FPGA-intern ein Tristate Bus keinen Sinn macht. Intern kannst du es dir 
leisten einfach 2 Ports zu machen. Bidirektionale Busse dienen ja nur 
dazu, um Leitungen auf einer Platine zu sparen.

Gruß,
J

[Matthias (Gast)]

Nicht nur deswegen, sondern weil INOUTs intern auch garnicht möglich 
sind. Leitungen im FPGA sind immer unidirektional (zumindest soweit ich 
das weiß). Die Tristate Fähigkeit wird schließlich nur durch die IO 
Buffer ermöglicht.
Es ist natürlcih möglich, dass das synthese tool dir automatisch aus der 
bidirektionalen Leitung zwei Unidirektionale erzeugt. Aber wer vertraut 
schon aufs Synthesetool :-)

[Maik R. (kiamur)]

Hallo Johnsn und Matthias!

Danke für eure Meinungen!
Ich konnte das jetzt in meinem Projekt auch bestätigen. Dort habe ich 
intern jetzt auch jeweils einen IN und einen OUT Bus verwendet. Ich habe 
es mit INOUT zwar hinbekommen, dass er fehlerlos synthetisiert, aber die 
Logik im RTL Viewer war ganz und gar nicht das, was ich mir erwartet 
habe. Ich konnte machen, was ich wollte, es ging nicht. Und das, obwohl 
ich diesen internen INOUT genauso programmiert habe, wie die 
physikalischen INOUTs zu meinen SRAM Bausteinen, die tadellos 
funktionieren.
Wahrscheinlich liegt es wirklich daran, weil intern einfach keine 
Tristate fähigen Elemente vorhanden sind . . .

Gruß
Maik