Hallo zusammen. Ich benutze ISE 11.1, und wie ich in älteren Beiträgen lesen konnte ist der RTL/Schematics Viewer in seiner Darstellungsmoral nicht immer ganz verlässlich. Wie überprüfe ich jetzt parallel zur Simulation mein Syntheseergebnis, bevor ich das auf den FPGA brate? Danke, Olaf.
Olaf Hilgenfeld schrieb: > Wie überprüfe ich jetzt parallel zur Simulation mein > Syntheseergebnis, bevor ich das auf den FPGA brate? Du kannst auch das Syntheseergebnis simulieren (wenn Du genügend Zeit mitbringst). Du mußt Dir ein post-synthesis simulation model erzeugen lassen. In gefühlt 99,5% der Fälle läuft die Synthese richtig. Duke
Duke Scarring schrieb: > In gefühlt 99,5% der Fälle läuft die Synthese richtig. Und bei den gefühlten 0,5% macht es bei gefühlten 90% nichts aus, wenn da was Seltsames oder unnötig Aufwendiges herauskommt... Olaf Hilgenfeld schrieb: > Wie überprüfe ich jetzt parallel zur Simulation mein > Syntheseergebnis, bevor ich das auf den FPGA brate? Du brätst nicht das Syntheseergebnis auf das FPGA, sondern die Synthese ist der allererste Schritt, danach kommen noch Translate, Map, P&R und die Bitstromerzeugung. Erst dann kannst du das Ding aufs FPGA laden... IdR. brauchst du das Design nach der funktionalen Simulation nicht überprüfen, wenn du ein synchrones Design hast, das mit passenden Timing-Constraints versehen ist. Denn die Toolchain muss anhand der Timing-Constraints sicherstellen, dass die beschreibene Funktion implementiert werden kann.
Lothar Miller schrieb: > IdR. brauchst du das Design nach der funktionalen Simulation nicht > überprüfen, wenn du ein synchrones Design hast, das mit passenden > Timing-Constraints versehen ist. Im ASIC-Flow fängt da der Spaß ja erst an :D
D. I. schrieb: > Im ASIC-Flow fängt da der Spaß ja erst an :D Was mache Leute unter Spass verstehen... Ich bleib bei FPGAs... ;-)
Lothar Miller schrieb: > D. I. schrieb: >> Im ASIC-Flow fängt da der Spaß ja erst an :D > Was mache Leute unter Spass verstehen... > Ich bleib bei FPGAs... ;-) dito. erstmal zumindest :D
Ich würds erstmal aufs FPGA braten, und erst bei Problemen mit Post-Synthesis-Simu anfangen. Jedenfalls solange es ein SRAM-basiertes FPGA ist und kein OTP und/oder ausser Nicht-Funktionieren keine Folgeschäden zu erwarten sind (Kernschmelze etc.)... Wenn seltsame Dinge auftauchen, kannst du immer noch simulieren, aber das kostet viel Zeit und Nerven. Auf Anhieb wird wahrscheinlich dann gar nichts gehen, selbst wenn die Synthese stimmt. Und wenn ein sporadischer Fehler "nur" durch externe Bedingungen/Bauelemente getriggert wird, die nicht sinnvoll simuliert werden (können), hilft das ohnehin nicht weiter... Ja, ich stehe der Post-Synthesis-Simu bei FPGAs skeptisch gegenüber. Bei ASICs ist es natürlich was anderes...
Georg A. schrieb: > Ich würds erstmal aufs FPGA braten, und erst bei Problemen mit > Post-Synthesis-Simu anfangen. Du meinst hier aber schon, dass schon vor der Synthese eine (wenigstens grundlegende) funktionale Simulation durchgeführt wurde? Dann stimme ich zu: die Timing-Simulation bringt nichts, was mit den passenden Constraints (und vernünftigen Design-Regeln) nicht einfacher mit der statischen Timinganalyse herauszubekommen wäre. Denn wenn die Timing-Simulation zeigt, dass da ein Fehler sein könnte, dann weiß ich immer noch nicht wieso und wo. In der statischen Timinganalyse sehe ich aber sofort den begrenzenden Pfad und kann dann eingreifen: entweder beim VHDL-Design oder bei den Implementations-Strategien.
> Du meinst hier aber schon, dass schon vor der Synthese eine > (wenigstens grundlegende) funktionale Simulation durchgeführt wurde? Natürlich. Die geht ja auch schnell und die Fehler sind direkt zu lokalisieren.
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.