www.mikrocontroller.net

Forum: FPGA, VHDL & Co. Tristate nur in Top-Ebene?


Autor: Steffen Hausinger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

angenommen, ich habe eine Top-Ebene, die die Signale der 
(physikalischen) Schnittstelle erhält und sie ohne Weiterverarbeitung an 
eine untergeordnete Component weiterleitet. Dort werden sie dann 
ausgewertet und verarbeitet. Die Signale müssen Tristate-fähig sein.

Wo soll ich den Multiplexer einbauen? Muss ich ihn in die Top-Ebene 
setzen oder kann ich ihn auch in die untergeordnete Component legen?

Grüße
Steffen

Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich instanziere/inferiere meine Treiber generell im top-Modul. Vom 
Submodul kommt dann nur ein sig_o und ein sig_oe.

Duke

Autor: Klaus Falser (kfalser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zumindest mit den letzten Versionen von XST (ich arbeite mit > 10.x) hat 
man keine Probleme, wenn man die Signale an die Untermodule durchreicht.
Die Signale müssen halt auch im Untermodul als inout definiert sein.

Autor: Bürovorsteher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tristate geht nur in der Top-Ebene und nur nach außen.
Die aufgesplitteten In- bzw. Outsignale kannst du hinhäkeln, wo du sie 
gerne hättest.

Autor: Bürovorsteher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Klaus Falser

Das muss ich mal probieren.

Autor: hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bürovorsteher schrieb:
> Tristate geht nur in der Top-Ebene und nur nach außen.
> Die aufgesplitteten In- bzw. Outsignale kannst du hinhäkeln, wo du sie
> gerne hättest.

Das stimmt so nun nicht. Ich hab das auch schon mit der Xilinx 9.2 
gemacht. Die macht keine Probleme, wenn die Tristate-Buffer irgendwo ein 
paar Ebenen tiefer im Design vergraben sind. Es darf halt nur nichts 
mehr mit den bidirektionalen Signalen gemacht werden. Also einfach 
durchrouten zum Toplevel-Port als inout.
Xilinx Coregen macht das sogar selbst so, wenn man z.B. einen 
DDR-RAM-Controller generiert.
Im ASIC-Bereich wird auch häufig ein Pad-Modul instantiert, in dem dann 
alle Ports zusammenlaufen und die entsprechenden Buffer liegen. Würde 
man alle IO-Buffer direkt in dem Toplevel haben wäre das ja auch ein 
total unübersichtliches Gewirr.

Autor: Harald Flügel (hfl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was alles geht und wie man es richtig macht, das sind 2 Paar Stiefel.

Zitat Duke:
Ich instanziere/inferiere meine Treiber generell im top-Modul. Vom
Submodul kommt dann nur ein sig_o und ein sig_oe.
Ende Zitat (Mit dem Zitieren ohne Quellenangabe soll man bekanntlich 
vorsichtig sein.)

So macht man das, da stimme ich 100% zu. Wohl teilweise auch in der 
ASIC-Welt, zumindest habe ich das im Gegensatz zu Hans dort so gelernt. 
Und dass die FPGA-Hersteller sich manchmal nicht an diese Regel halten 
(Altera auch nicht) tut der Richtigkeit der Regel BOOT (= buffers only 
on top level) keinen Abbruch.

Grüße,
Harald

Autor: hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Harald Flügel schrieb:
> Und dass die FPGA-Hersteller sich manchmal nicht an diese Regel halten
> (Altera auch nicht) tut der Richtigkeit der Regel BOOT (= buffers only
> on top level) keinen Abbruch.

Man lernt nie aus...jedenfalls ist das eine Regel, die ich in zwei 
Firmen aus dem ASIC-Bereich (amerikanische und auch deutsche) nicht 
kennengelernt habe.

Aber ist ja auch egal. Solange alle Tools das verstehen kann die Regel 
ja nicht so kriegsentscheidend sein. Hauptsache das Design läuft 
anständig.
Dann kann das ja jeder so machen wie er will. Je nachdem was er für 
übersichtlicher hält.

Autor: Silvia A. (silvia)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klaus Falser schrieb:
> Zumindest mit den letzten Versionen von XST (ich arbeite mit > 10.x) hat
> man keine Probleme, wenn man die Signale an die Untermodule durchreicht.
> Die Signale müssen halt auch im Untermodul als inout definiert sein.

Das kann ich nur bestätigen. Auch in der ISE 9.X ging das schon.

>...tut der Richtigkeit der Regel BOOT (= buffers only
>on top level) keinen Abbruch.

Kann gut sein , das die Synthesewerkzeuge das früher nicht richtig 
übersetzt haben.  Vorrausgesetzt die Synthesewerkzeuge können das alle 
korrekt umsetzen (Was ich gerade nicht weiss) dann gibt es keinen Grund 
diese Regel anzuwenden.

Autor: Harald Flügel (hfl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Diese BOOT-Regel kommt nicht etwa daher, dass die Tools zu blöde wären 
oder waren. Sie hat etwas mit strukturiertem Entwurf zu tun. Ob man die 
IO-Zellen in den Top-Level setzt oder in ein separates Moduls auslagert, 
das ist dabei zweitrangig. Entscheidend ist, dass man die IO-Zellen von 
der Logik trennt, wie Duke das macht.

Warum macht man das? Die Core-Logik arbeitet rein mit binären Werten, 
Nullen und Einsen, etwas anderes kann und will man ja gar nicht 
modellieren. IO-Zellen sind strukturell etwas anderes wie Gatter, und 
daher beschreibt sie auch anders. Bei IO-Zellen gibt es weitere Aspekte 
wie z.B. IO-Standard, Treiberstärke, etc., die man in HDL nicht 
beschreiben kann. Hierfür braucht man andere Beschreibungsmöglichkeiten 
wie z.B. Settings in der Projektdatei des FPGA oder anderes. Ich weiß 
schon, diese Sichtweise mit den separierten IO-Zellen ist für reine 
FPGA-User, die nie etwas anderes machen, nicht so einfach zu verstehen, 
weil man sich darum nicht unbedingt kümmern muss. Sie ist trotzdem 
richtig, in my humble opinion.

Grüße,
Harald

Autor: hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok. Dann denken wir doch das Gleiche :-)
IO-Zellen (und anderes nicht-digitales Zeug) sollten irgendwo in einem 
Modul (das am besten noch auf dem Toplevel eingebunden wird) gekapselt 
liegen. Wie Harald sagt erhält man dadurch eine strikte Trennung der 
digitalen Logikbeschreibung von dem ganzen anderen, pseude-analogen 
Geraffel. Der Logik-Core ist so auch völlig unabhängig von den 
technologieabhängigen Komponenten.
Grüße!

Autor: Frank V. (scyx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich denke ganz so pauschal sollte man das nicht sehen. Es gibt Fälle in 
denen bestimmte Busstrukturen auch Tristate innerhalb des Cores 
ermöglichen. Das mag kein Standard sein, aber ist möglich, sofern es die 
entsprechenden Gatter dafür gibt.

Ansonsten hab ich auch die Erfahrung gemacht: seperates Top-Modul für 
die Pads erleichtert einiges und hilft der Übersicht.

mfg
 Frank

Autor: berndl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich hab' letztes Jahr mal mit einem existierenden (und funktionierenden) 
Design mit ISE11.x und ISIM rumgespielt: Da kam an den 'versenkten' 
BiDis nix raus. Sowohl ModelSim als auch GHDL simulieren den Design 
anstandslos.

Ob das jetzt an den BiDis lag weiss ich allerdings nicht, ich hab's 
nicht untersucht. Aber da ja wohl jetzt mehr und mehr Xilinx User auf 
ISIM umsteigen (da kein freies ModelSim mehr), sollte man das auch 
rechtzeitig mal testen...

Autor: MXM (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
es ist doch egal, ob man die tri-state zuweisungen in einem "modul" oder 
im top level beschreibt, da im endeffekt der synthetisierer die 
steuerleitung die dafür verantwortlich ist in den IOB führt...

Autor: Dieter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>es ist doch egal, ob man die tri-state zuweisungen in einem "modul" oder
>im top level beschreibt, da im endeffekt der synthetisierer die
>steuerleitung die dafür verantwortlich ist in den IOB führt...

Ich hasse Leute, die der Meinung sind, ausschließlich Kleinschreibung 
verwenden zu müssen.

Dieter

Autor: Steffen Hausinger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für Eure Antworten!!

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.