Servus, so langsam geht meine Diplomarbeit gen Ende und leider funzt die Synthese meines Systems noch nicht. Die Simulation geht einwandfrei. Was kann ich abgesehen von einer Timing-Simulation tun, um rauszukriegen warum das so ist? Und gibt es typische Designfehler, die in der Simulation keine Rolle spielen, in der Synthese aber nicht funktionieren, ohne dass man dafür eine Warnung oder Fehler bekommt?
Sowas kann schmerzhaft werden... hab schon von Diplomarbeiten gehört die "am Ende mal alles synthetisieren" wollten... jo.... Pustekuchen wars.... da war nix zu retten.... Dein Tool gibt normalerweise Fehlermeldungen.... es gibt einen Haufen Sachen die man zwar in VHDL schreiben kann, die aber nicht synthetisierbar sind... "after" zb... Was sagt dein Tool denn?
Ein typischer Designfehler können Domänenübergänge sein. Wenn Du mehrere Taktdomänen hast, musst Du Daten die von einer Domäne in eine andere gehen mit mindestens 2 Registerstufen rüber synchronisieren. Sonst kann ein metastbiler Zustand entstehen und nix geht.
Abgesehen von Meldungen für offene Signale oder welche, die konstant 0 sind bekomme ich eigentlich nichts. Ich habe einen Domänenübergang, ein Audiosignal wird per SPDIF übertragen und der Wishbone-Bus des Empfängers hat einen anderen Takt als mein System. Dazwischen habe ich ein asynchrones FIFO mit zwei Takteingängen. In der Simulation funktioniert der Übergang einwandfrei.
@ Philip Kirchhoff (plip) >Abgesehen von Meldungen für offene Signale oder welche, die konstant 0 >sind bekomme ich eigentlich nichts. Was meinst du mit "Synthese geht nicht"? kann das Design nciht synthetisiert werden (Abbruch mit Fehlermeldung) oder läuft dein System auf dem realen FPGA fehlerhaft? >In der Simulation funktioniert der Übergang einwandfrei. Das ist meistens so ;-) MFG Falk
Geht nicht heißt in diesem Fall, dass das System bei identischem Eingangssignal nicht dieselben Ausgangsdaten liefert, wie in der Simulation.
@ Philip Kirchhoff (plip) >Geht nicht heißt in diesem Fall, dass das System bei identischem >Eingangssignal nicht dieselben Ausgangsdaten liefert, wie in der >Simulation. Dann sollte das ein Diplomand auch so fomulieren können. Naja, da wirst du wohl debuggen müssen. Schrittweise vom Eingang die Daten anschauen, entweder per Oszi oder in einem BRAM aufzeichen lassen. Wenn du hast per Logic Analyzer. MfG Falk
>Ein typischer Designfehler können Domänenübergänge sein. Wenn Du >mehrere Taktdomänen hast, musst Du Daten die von einer Domäne in >eine andere gehen mit mindestens 2 Registerstufen rüber synchronisieren. >Sonst kann ein metastbiler Zustand entstehen und nix geht. Solche Aussagen sind z.B. solche tyischen Fehler! Die Synchronisation behebt lediglich das Problem des wechselnden Taktes zur Zeit der Auswertung. Metastabilität hat damit (noch) nichts zu tun. Auch ohne metastabile FFs bekommt man zum Flankenwechsel undefinierte Daten, die bei Bussen Probleme machen. Einsynchronsieren alleine liefet zwar logisch stabile Signale, reicht aber allein auch noch nicht. Es muss auf logische Konsistenz getestet werden. Dies erfordert den internen Datenvergleich oder einen externen Trigger.
Zum Debuggen kann ich diesen Logic-Analyzer wärmstens empfehlen: http://www.sump.org/projects/analyzer/ Vorausgesetzt, man hat eine serielle Schnittstelle und etwas Ressourcen über. Rick
Leider hab ich noch nie mit nem Logikanalyzer gearbeitet und wüsste jetzt auf die Schnelle auch nicht, woher ich einen organisieren könnte. Wie gesagt, die Zeit rennt...Ende Februar ist Abgabe und die Synthesergebnisse müssen auch noch in die Ausarbeitung einfliessen. Ich verwende ohnehin ein UART, um die Ausgangsdaten wieder an den PC zu schicken und mit Matlab zu verarbeiten. Ich hab da jetzt mal noch ein großes FIFO zwischengeschaltet, dessen Eingang ich halt da hin biege, wo ich die Daten sehen will. Ist halt ein bisschen Gebastel und die Datenmenge ist etwas begrenzt, aber was besseres fällt mir grad nicht ein. Ich denke nicht, dass die Arbeit als nicht bestanden gewertet wird, wenns am Ende nicht läuft, aber es dürfte schon arg auf die Note gehen :-(
@ Philip Kirchhoff (plip) >Datenmenge ist etwas begrenzt, aber was besseres fällt mir grad nicht >ein. Besser als nichts. >Ich denke nicht, dass die Arbeit als nicht bestanden gewertet wird, >wenns am Ende nicht läuft, aber es dürfte schon arg auf die Note gehen >:-( Muss man nur mit blumig-akademischen Worten verhüllen, dann spielt das keine nennenswerte Rolle. AKA Marketing. MFG Falk
@Falk Irgendwie benutzt Du aufallend häufig das Wort akademisch in herablassendem "Ton". Sollte da etwa eine Aversion vorhanden sein? :-) Marketing ist eher nicht mein Ding, ich bin ein erklärter Freund von Ehrlichkeit und offenen Worten! Kommt bei Vorstellungsgesprächen leider nicht so gut...:-)
@ Philip Kirchhoff (plip) >Irgendwie benutzt Du aufallend häufig das Wort akademisch in >herablassendem "Ton". Sollte da etwa eine Aversion vorhanden sein? :-) Ihhhh woo!! ;-) >Marketing ist eher nicht mein Ding, ich bin ein erklärter Freund von >Ehrlichkeit und offenen Worten! Kommt bei Vorstellungsgesprächen leider >nicht so gut...:-) Ehrlichkeit ist ein Zier, doch weiter kommt man ohne ihr. MfG Falk P.S. Zum Thema akademische Aversion. Wir hatten mal ein Praktikum, zum Thema Abtastung und FFT und so. Da wurde doch tatsächlich RAUSCHEN abgetastet, auch "zu langsam". Und dort sollte man dann "klar sehen", dass das Abtasttheorem verletzt wurde. Ich habs bis heute nicht gesehen. :-0
Gibt es irgendwelche "Sauereien" im Design (Latches, rückgekoppelte Mealy-Automaten, sonstige asynchrone Schaltungen)? Sind für Ein- und Ausgänge passende Timing-Constraints gesetzt und werden die eingehalten? Warum versuchst du nicht mal eine Post-Place & Route-Simulation?
Falk Brunner wrote: > > P.S. Zum Thema akademische Aversion. Wir hatten mal ein Praktikum, zum > Thema Abtastung und FFT und so. Da wurde doch tatsächlich RAUSCHEN > abgetastet, auch "zu langsam". Und dort sollte man dann "klar sehen", > dass das Abtasttheorem verletzt wurde. Ich habs bis heute nicht gesehen. > :-0 Das ist allerdings ein Knaller... @Andreas Latches gibt es nicht. Ich verwende ein paar asynchrone ROM-Speicher. Automatentheorie ist bei mir schon ne Weile her, was ist mit rückgekoppelten Mealy-Automaten gemeint und warum sind die ein Problem? Ich habe keine Timing-Constraints selbst gesetzt und weiß auch gar nicht wie das geht. Ich bekomme aber irgendwann die Meldung "all constraints were met", oder so...
Wieso ist das ein Knaller? Wenn das Rauschen nicht deterministisch eingespeist wurde, dürfte es schwer fallen, einen Soll-Ist-Vergleich zu machen. Das Abtasttheorem ist schon gültig, keine Sorge.
Schau Dir die Coverage von Deinen Constraints an. Die gibt an wieviel Prozent Deines Designs von den Constraints abgedeckt werden. Wenn der Wert sehr klein ist, musst Du constraints für die nicht abgedeckten Teile hinzufügen.
Es funktioniert!!! Gab zwei Fehler, die aber beide nicht im eigentlichen System, sondern in der Peripherie lagen: 1. 12 kHz-File abspielen bedeutet nicht, dass das S/P-Dif Signal eines mit 12 khz ist, es wird auf 48 kHz hochgesampled. Das war mir nicht bewusst. Erst als ich einen Sinus reingeschickt habe, hab ich festgestellt, dass der mit viel mehr Punkten pro Periode ankommt. Da mein System nur mit 12 kHz was anfangen kann, hat das nicht gefunzt. Gelöst hab ichs jetzt durch eine Unterabtastung. 2. Auch wenn man die Daten per UART entsprechend der Baudrate versendet, heißt das noch nicht, daß Matlab auch in dieser Geschwindgkeit einliest. Und wenn der Buffer überläuft gibts Datenmüll (zumindest so wie ichs gemacht habe). Mann, bin ich froh dass es geht. Ich möchte mich ganz herzlich bei allen bedanken, die mir bei diesem ganzen Zeug geholfen haben!
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.