Hallo zusammen, ich bitte euch um Hilfe, weil ich trotz Suche und Help Files durchlesen einfach nicht mehr weiterkomme. Mein VHDL Entwurf ist fehlerfrei durch Place and Rout durchgelaufen. ( siehe Datei im Anhang ) Lt. Helpfile hab ich beim Process Generate Post P+R Simulation Modell in den <Properties> unter <erweiterten Optionen> das Häckchen für <Create Testbench> zur Sicherheit angekreuzt. In der Anlage könnt ich sehen wie bei mir das Process Fenster für die <Post-Route Simulation> aussieht. Bei mir erscheint unter den Sources kein File unter meinem Baustein. Wenn ich mit create Source ein Testbench File hinzufüge, dann erscheint das VHD Testfile immer under dem Process <Behaviour> aber nicht unter dem <Post-Route Simulation> Fenster. Wie kann ich denn nun für die Post Route Simulation einen Testbench einbinden ? Oder muss ich dafür einen Simulator extern einbinden ? Davon stand allerdings nirgends in den Helpfiles was. Ich bitte euch dringend um Tipps, denn ich mach da jetzt schon ganz schön lange rum und bin echt Down. Gruß vom FPGA-Fragenden
Ich tippe mal auf Bug in der ISE :D "Project Clean" mal gemacht? ModelSim XE ausprobiert? Hast du mal versucht, das Post-PAR Modell als VHDL-Quelldatei zu laden ("Add Copy of Source", netgen/par/<DESIGN>_timesim.vhd)? Die SDF-Datei liegt im gleichen Verzeichnis. Hat es bei einem anderen Projekt schon mal funktioniert? HTH -- stefan
Hallo Stefan, Du bist ne Wucht !!! Und hast wohl schon selbst genügend Lehrgeld bezahlt !! " Ich tippe mal auf Bug in der ISE :D " That´s right. Ich hab den Rechner komplett neu gestartet. Alle VHDL Files in ein neues Projekt kopiert. Alles nochmal durchlaufen lassen und siehe da es hat geschnaggelt. Das einzige Problem was ich nun habe ist folgendes: Wenn man in der Post Route Simulation die Signale aussuchen möchte, die man sich anschauen will, dann wir das aber voll %&$§??#+ Soll heißen in der Auswahlliste im "Model under Test" erscheinen in der Liste nun ewig viele "sozusagen Teilsignale" und man sucht sich einen Bär, bis man das gewünschte Signal findet. Gibt es da nicht irgend einen Trick. Ich glaub ich hab bestimmt 15 min gesucht bis ich ein best. Signal das ich suchte gefunden hab. Ein Tipp wäre nicht schlecht. Wie löst Du das Problem ? Gruß vom FPGA-Fragenden
@ FPGA-Fragender >Ich glaub ich hab bestimmt 15 min gesucht bis ich ein best. Signal das >ich suchte gefunden hab. >Ein Tipp wäre nicht schlecht. Wie löst Du das Problem ? Ich löse das Problem, indem ich keine Post P%R Simulation mache. Wenn das Design sauber synchron ist reicht eine automatische, statische Timinganalyse. MFG Falk
In dieser Hinsicht bin ich selbst noch Anfänger. Ich habe schon versucht, Post-PAR Simulationen durchzuführen, die aber schiefgegangen sind ... ergo habe ich in meinem Design noch Fehler drinne. Falk, als du Anfänger warst, hast du doch sicher auch Timingsimulationen durchgeführt. Wann war der Punkt, als du das aufgegeben hast? Es wird wohl darauf hinauslaufen, das "gesamte" Design mit Constraints zu belegen und dann das Tool machen zu lassen. Dafür muss man dann aber das Verhalten der externen Bausteine kennen. -- stefan
@ Stefan Hanke >In dieser Hinsicht bin ich selbst noch Anfänger. >Ich habe schon versucht, Post-PAR Simulationen durchzuführen, die aber >schiefgegangen sind ... ergo habe ich in meinem Design noch Fehler >drinne. Sicher, aber das sind zu 99% Logikfehler, die du auch in einer normalen Verhaltenssimulation auf VHDL Ebene findest. Und dort sind alle Signalnamen wie im VHDL. Deine Testbench muss einige worst case Fälle simulieren. >Falk, als du Anfänger warst, hast du doch sicher auch Timingsimulationen >durchgeführt. Wann war der Punkt, als du das aufgegeben hast? Ich war nie Anfänger. ;-) Kleiner Scherz. Nein, ich hab auch nicht aufgegeben. Ich habe einfach nur das gemacht, was zum Erreichen des Ziels (sicher funktionierendes Design) notwendig war. Und da habe ich schnell gemerkt und gelernt, dass eine Timingsimulation zu 99% sinnlos ist. >Es wird wohl darauf hinauslaufen, das "gesamte" Design mit Constraints >zu belegen und dann das Tool machen zu lassen. Dafür muss man dann aber >das Verhalten der externen Bausteine kennen. Sicher. Aber löse dich mal von dem Gedanken "mit nem Haufen Constraints wird das Tool es schon richtig machen". DU must es richtig machen, und den Tools gewisse Hinweise geben. Für ein sauberes synchrones Design brauchst du nur 3 Angaben. Taktfrequenz Datenverfügbarkeit am Eingang (offset for ...) Datenverfügbarkeit am Ausgang (offset after . . .) Das sind drei einfach Zeilen im UCF (bei Xilinx). Ausserdem können auch die besten in Massen vergebenen Constraints keine Logikfehler ausbügeln. MfG Falk
Noch was. Dein IO Timing kannst du fürs erste am besten im realen Design mit nem Oszi prüfen. Wenn da was arg daneben liegt siehts du das. Aber bitte ein Oszi und Tastkopf auswählen, das der Geschindigkeit der Schnittstellen angemessen ist! MFG Falk
Ein paar Tectronix müssten hier rumstehen. :) Nochmal zur Denkweise: Die Constraints sagen, was ich gerne hätte. Das Tool kann dann die Synthese/etc "anleiten". Danach dienen die Constraints dazu, per statischer Timinganalyse die Einhaltung zu überprüfen. Die statische Timinganalyse ist quasi das gleiche wie eine Timingsimulation, nur wird sie automatisch durchgeführt. Sie liefert mir dann aber die entscheidenden Hinweise, welche Pfade Constraints verletzen. -- stefan
Thread beobachten
Seitenaufteilung abschaltenBitte 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.