|
Anzeige
|
Tristate nur in Top-Ebene?
Gast
#2067342
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
Gast
#2067352
Ich instanziere/inferiere meine Treiber generell im top-Modul. Vom Submodul kommt dann nur ein sig_o und ein sig_oe. Duke 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.
Gast
#2067361
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.
Gast
#2067364
@ Klaus Falser Das muss ich mal probieren.
Gast
#2067390
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. 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
Gast
#2067451
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. 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. 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
Gast
#2067624
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! 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
Gast
#2067974
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...
Gast
#2068322
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...
Gast
#2068641
>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
Gast
#2068845
Danke für Eure Antworten!! Antwort schreiben |
Anzeige
|
