Ich verwende Xilinx ISE 9.2i für eine VHDL Lehrveranstaltung die ich an
der Uni besuche.
(Diese Version ist die letzte, welche den auf den dort verwendeten
Evalboards verbauten Spartan 2 unterstützt.)
Bei der Synthese habe ich manchmal das Problem, dass das Synthesetool
Gatter generiert, welche am Ausgang und meist an mehreren Eingängen
scheinbar nicht angeschlossen sind. (Siehe Anhang)
Manchmal schaffe ich es, durch Verändern des VHDL Codes das Problem zu
beheben, manchmal auch nicht. Ich habe aber nicht herausgefunden,
wodurch das Problem konkret erzeugt wird.
Meine Frage ist jetzt, ob das eine Eigenheit des Tools ist und man das
getrost ignorieren kann, oder ob man das beheben muss.
Ich habe schon mit Kollegen gesprochen, aber bis jetzt nicht
herausgefunden, woran es liegt. Google und die Forensuche haben auch
nichts brauchbares zu Tage gefördert.
Da es sich um eine Hausübung handelt, will ich den Sourcecode hier nicht
posten (höchstens nachdem der Abgabetermin vorbei ist), aber vllt. kennt
ja jemand das Problem.
(Ich habe auch RTL Schematic Screenshots gefunden, bei denen das auch so
war (hier z.B:
http://vhdlguru.blogspot.com/2010/03/simple-1-4-demultiplexer-using-case.html
), aber keine Erklärung.)
Hi!
Wenn Du mit der Maus über das Symbol gehst, müsstes Du irgendwo den
Instanznamen sehen können. Nach diesem würde ich mal im Synthesereport
sehen, ob das halbwegs ok aussieht.
Ansonsten könntest Du testweise eine aktuelle ISE-Version installieren
und gucken, ob der Schematic-Viewer immer noch solchen Mist macht.
Rick
>Meine Frage ist jetzt, ob das eine Eigenheit des Tools ist und man das
<getrost ignorieren kann, oder ob man das beheben muss.
Die Frage kannst Du Dir doch selbst beantworten, indem Du das Projekt
auf das Zielsystem bringst und schaust, ob es das tut, was es tun soll.
kopfschüttel
@VHDL-Anfänger
Da das Design noch nicht fertig ist, geht das im Moment schlecht.
Zweitens habe ich das Board nicht zu Hause und drittens ist ausprobieren
nur zum Teil befriedigend, denn es heißt noch lange nicht, dass man es
immer ignorieren kann, sollte es in dem einen Fall funktionieren.
@Rick Dangerus
Ich kann nichts auffälliges erkennen, der Instanzname kommt darin nicht
vor.
Es gibt ein paar Warnings:
Xst:1710 - FF/Latch <Mtridata_Col<1>> (without init value) has a
constant value of 1 in block <MatrixDecoder>.
Xst:1895 - Due to other FF/Latch trimming, FF/Latch <Mtridata_Col<2>>
(without init value) has a constant value of 1 in block <MatrixDecoder>.
Xst:1895 - Due to other FF/Latch trimming, FF/Latch <Mtridata_Col<3>>
(without init value) has a constant value of 1 in block <MatrixDecoder>.
Xst:638 - in unit MatrixDecoder Conflict on KEEP property on signal
Mtridata_Col<1> and Mtridata_Col<2> Mtridata_Col<2> signal will be lost.
Xst:638 - in unit MatrixDecoder Conflict on KEEP property on signal
Mtridata_Col<1> and Mtridata_Col<3> Mtridata_Col<3> signal will be lost.
welche aber daher kommen, dass ein paar Ausgänge jeweils nur auf 'Z'
oder '1' geschaltet werden, sodass anscheinend FFs wegoptimiert und
Signale zusammengefasst werden.
Das sollte wenn überhaupt aber nur indirekt mit dem Problem
zusammenhängen, weil der Teil, welcher die Warnings generiert, alleine
keine unvollständig beschalteten Gatter erzeugt. (Das ist aber eine
Vermutung.)
Das sind nur Darstellungsfehler im RTL View. Kommt leider öfters vor. Ab
und zu gibt es auch mal Leitungen die schräg über den gesamten Plan
verlaufen...
Wenn du dir den Tooltip anschaust der erscheint wenn du mit der Maus
über dem Gatter bist siehst du, dass alles ordentlich angeschlossen ist.
Mit den Darstellungsfehlern habe ich schon Bekanntschaft gemacht.
Meistens kann man aber durch herumzoomen und scrollen bzw. anklicken
der Leitung recht gut die Verbindung kontrollieren.
Die Screenshots im Anhang deuten aber eher auf das Gegenteil hin.
Ich bin mit der Maus über den beschalteten Eingang, einen unbeschalteten
Eingang und den Ausgang gefahren. Bei I2 steht nichts und bei O auch
nichts.
Ich habe jetzt mal das demux Beispiel von der oben von mir genannten
Webseite synthetisiert. Laut Webseite hat der Ersteller ISE10.1
verwendet, es ist also kein Wunder, dass das Ergebnis bei mit etwas
anders aussieht. (Außerdem hat er sicher einen anderen Zieltyp als
FPGA.)
Wie auch immer, selbst dieses einfache Beispiel zeigt das Problem.
(Anscheinend aber auch mit ISE10.1, falls der Screenshot auf der
Webseite korrekt ist, also keine Darstellungsfehler hat.)
Ich habe mir erlaubt, die Tooltips alle in ein Bild zu kopieren, damit
es nicht wieder so groß wird.
Whitespace schrieb:> die Verbindung kontrollieren
Ähm. Räusper.
Zum Überprüfen der Funktionalität, schaut man sich nicht die
Verbindungen im RTL-View an, sondern checkt das Design im Simulator
(ghdl, modelsim o.ä.) mit einer Testbench und geeigneten Stimuli.
Rick
Mir ist schon klar, dass man die Funktionalität mittels Simulation
kontrolliert und nicht durch Kontrolle der Leitungen im RTL View.
Das Design wurde natürlich vor der Synthese simuliert.
Es geht mir einfach darum, warum das Tool das gezeigte Resultat
generiert und ob das normal ist bzw. man nochmal ein Auge darauf werfen
muss (mit der post Synthese Simulation muss ich mich erst noch
beschäftigen), wenn man sowas sieht.
Interessant sind eigentlich nur die Warnings, die xst bringt. Meistens
sind sie harmlos, manchmal deuten sie aber auf ein echtes Problem hin,
dass man verpennt hat. Also Zuweisungen vergessen, auch mal nur von
einem sonderbeandelten Signal eines Busses, Takt nicht angeschlossen,
kein/falscher Resetfall, etc. Drüberschauen lohnt auf jeden Fall, auch
wenn es in der Simulation und scheinbar auch im FPGA selbst geht.
Die erzeugte Logik habe ich seit dem Übergang von Schematic Entry auf
VHDL (war '96, also kurz nach'm Krieg ;) ) nur noch ab und zu bei der
Ausgabe vom fpga-Compiler (Synopsys) angeschaut. Der hat wirklich noch
manchmal einen ziemlichen Mist produziert, oft leider auch nicht
reproduzierbar. Aber seit xst (~2001 rum) auch nicht mehr. Man steigt da
auch nur noch schwer durch, wenn man die Korrelation zum VHDL versucht.
Echte Synthesefehler habe ich auch bei ISE 9.2 nicht mehr gesehen, und
da war es schon etwas deutlich Grösseres. Man denkt es manchmal, wenns
nicht geht und sucht einen Sündenbock, aber am Ende war dann doch immer
nachvollziehbar die Wetware schuld... Entweder programmier ich so
defensiv oder ich habe einfach nur Glück :)
gate1.png
(7 KB)
