High Impedance State 'z'

[Daniel (Gast)]

Hallo schon wieder,
so langsam komm ich voran mit meinem Design. Jetzt mal wieder ne Frage.

1.Ich habe es mit bidirectionalen Signalen zu tun und meine Ports
dementsprechend deklariert. Wie kann ich jetzt zur "Laufzeit" den
Typen umdeklarieren?
2. Ich will einen Port auf High Impedance setzen. Meine Datentypen sind
std_logic. Ich habe zudem ein Signal definiert. Dieses Signal (auch
std_logic) kann aber nur 1 oder null, nicht jedoch z annehmen. Der Port
kann dies jedoch direkt durch die Zuweisung 'z'. Kann ich also nicht
direkt das Signal dem Port zuweisen wenn ich high impedance Zustände
zuweise? Muß ich dann eine Routine schreiben, die, je nach
Signalzustand den Port auf den gewünschten Zustand setzt?

Tappe da noch ein wenig im Dunkel. Würd mich über Tips freuen.
Danke Daniel

[Xenu (Gast)]

Normalerweise macht man das so:

 port <= Ausgangssignal when (BEDINGUNGUNG_FÜR_AUSGANG_WAHR) else
'Z';


BEDINGUNGUNG_FÜR_AUSGANG_WAHR ist halt irgendeine Bedingung,
z.b. (bla = '1' and dings = "10011"), je nachdem wann Du halt das
Signal
rausgeben willst.

Sonst ist der Port hochohmig ('Z') und kann als Eingang benutzt
werden.

[Daniel (Gast)]

ok, das heißt also wenn ich einen Port als inout deklariere und einfach
auf '1','0', oder 'z' setze, kann ich den Ausgangszustand ändern.
Und wenn ich ihn auf z setze wirkt der Port automatisch gleich als
Eingang? Ist das wirklich so? - ich muß da nicht mehr den Buffer
umschalten oder so? Ich weise einfach 'z' zu und kann den Port danach
direkt wie einen Eingang behandeln?
Sorry das ich so hartnäckig frage.
Würd mich freuen noch einige Tips zu bekommen oder ein vhd- file in dem
 ein Bus bedient wird auf dem sowohl gelesen und geschrieben wird.
Wäre euch wirklich sehr dankbar. Habe zig App.Notes etc. gesucht, aber
einfach nicht das gefunden was ich suche.

[Xenu (Gast)]

>Und wenn ich ihn auf z setze wirkt der Port automatisch gleich als
>Eingang?

Ein bidirektionaler Port ist immer Eingang und Ausgang gleichzeitig.
Bei einem bidirektionalen Treiber ist der Eingang eines Eingangspuffers
mit dem Ausgang eines Tristate-Ausgangspuffers verbunden (und mit dem
Pin nach aussen). Wenn du schreibst, wird der Ausgangspuffer
geschrieben, wenn Du liest, der Eingangspuffer gelesen.

>ich muß da nicht mehr den Buffer
>umschalten oder so?

Du schaltest ihn dadurch ja um, obwohl "umschalten" eigentlich der
falsche Ausdruck ist.
Wenn Du eine '0' oder '1' schreibst (INOUT-Port schreiben =
Ausgangspuffer schreiben), dann liegt dieser Wert auch am
Eingangspuffer an. D.h. wenn du eine '1' schreibst, wirst Du auch
eine
'1' lesen (wenn Du gleichzeitig aussen den Pin auf Masse legst,
solltest Du eine '0' lesen; fragt sich nur ob die Puffer einen
Kurzschluß längere Zeit verkraften).
Wenn Du 'Z' auf den Port schreibst, ist der Ausgangspuffer hochohmig
und damit quasi nicht mehr vorhanden, und wenn Du jetzt den Port liest,
liest du den Wert (bzw. Spannung) am Pin, wie bei einem gewöhnlichen
IN-Port.

Du kannst natürlich auch die bidirektionalen Treiber (Eingangspuffer +
Tristate-Ausgangspuffer) als Komponente(n) einbinden und damit
arbeiten. Ist aber umständlicher und immer vom jeweiligen Hersteller
bzw. Baustein abhängig.

[Daniel (Gast)]

OK, Xenu danke erstmal.

Ich hab jetzt den ganzen Tag damit verbracht, die BIDI's zum laufen zu
bekommen. Hab da jetzt noch ein paar Fragen:
Habe beide Varianten ausprobiert (einmal im process mit der direkten
Zuweisung von 'z' und andererseits mit dem Einbinden der Instanzen
der Treiber aus den templates)
Dabei eine erste Frage: Ich binde die Komponenten einfach wie folgt
ein:

IOBUF_inst : IOBUF
   generic map (
      DRIVE => 12,
      IOSTANDARD => "DEFAULT",
      SLEW => "SLOW")
   port map (
      O => Output,         -- Buffer output
      IO => INOUTPUT,   -- Buffer inout port (connect directly to
top-level port)
      I => Input,        -- Buffer input
      T => tri_enable    -- 3-state enable input
   );

(habe ich aus den examples der language templates)

Dabei binde ich einfach die Bibliothek UNISIM ein. Aber eine
Deklaration component .... end component binde ich nicht ein. Sind die
in den Bibliotheken deklariert? Und dann kann ich die Instanzen einfach
so aufrufen?
Ok, wenn ich das so mache dann übergebe ich doch mit den generics
einige Infos über die Konfiguration,oder? Wenn ich jedoch einfach nur
einen inout port deklariere und innerhalb eines Prozess 'z' zuweise,
woher bekommt der Synthesyser die Informationen über die Generics?
Eigentlich lege ich doch die Eigenschaften der Ports in den Constraints
fest? Wird das dann automatisch für die Buffer übernommen? Und warum
sehe ich davon nichts im VHDL Code?

Ich habe außerdem in dem Technologieschema (Xilinx webpack) gesehen,
daß der synthesiser aus den toplevel ports je nach deklaration
(in,out,inout) automatisch einen passenden Buffer einbindet, auch wenn
ich die Variante ohne Einbinden der Treiberbausteine buf nehme. Woher
weiß er das?

Ok, die Fragen sind etwas wirr. Aber vielleicht verstehst Du meine
Probleme? Würde mich sehr freuen wenn Du mir nochmal ein paar Sätze für
ein besseres Verständniss schreibst!
Danke Daniel

[Xenu (Gast)]

>Wenn ich jedoch einfach nur einen inout port deklariere und innerhalb
>eines Prozess 'z' zuweise, woher bekommt der Synthesyser die
>Informationen über die Generics?


Die Puffer-Eigenschaften kann man an mehreren Stellen einstellen,
ich mach das immer in der .ucf-Datei ("user constraint file").

Am Besten Du schaust Dir mal den "XST User Guide" an, da sollte
alles
Wichtige drinstehen. Ist als PDF im WebPack mit dabei.


>Ich habe außerdem in dem Technologieschema (Xilinx webpack) gesehen,
>daß der synthesiser aus den toplevel ports je nach deklaration
>(in,out,inout) automatisch einen passenden Buffer einbindet, auch
>wenn ich die Variante ohne Einbinden der Treiberbausteine buf nehme.
Woher weiß er das?


Die Toplevel-Ports gehen zwangsläufig auf die Pins, also sind Puffer
nötig.