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
Sind das unsere Pädagogen heute? Na dann gute Nacht... ARMES DEUTSCHLAND
@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 :)
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.