www.mikrocontroller.net

Forum: FPGA, VHDL & Co. Syntheseergebnis überprüfen.


Autor: Olaf Hilgenfeld (Firma: skinnerbox) (billy_the_mountain)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: D. I. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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... ;-)

Autor: D. I. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Georg A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Georg A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.