Ich habe eine etwas grössere Schaltung, die ich in einen kleinen FPGA quetschen muss und gerade eben einen seltsamen Effekt aufgetan: Ich habe zuletzt eine einfache Drucktastenfunktion implementiert, die einen Zähler nach oben und unten zählen kann. Limitiert wird bei Taste L auf 0 und Taste R auf 19. Ich kann, wie erwartet mit den Tasten L und R den Zähler gegen die beiden Anschläge bringen. Nun kommt's: Ich habe das Optimierungsziel auf Area getrimmt, dabei festgestellt dass das in MAP noch auf speed stand und es per Hand auch umgestellt. Ergebnis: Die Schaltung wird etwas kleiner, taktet langsamer und produziert einen Fehler: Der linke Anschlag existiert nicht mehr: Beim Runterzählen wird die Abfrage auf Null überlesen und der Zähler springt auf 255, einen ungültigen Wert. Nochmaliges Drücken L bringt ihn auch nicht zurück. Erst bei R setzt das Limit auf 19 und der Zähler stimmt wieder. Die Abfrage geht also. Am VHDL wurde nichts geändert. Ich habe nun wieder alles auf balanced gestellt und es geht wieder. Gibt es das?
Early Bird schrieb: > einfache Drucktastenfunktion implementiert erst einmal eine klassische Frage: werden die Taster-Signale direkt vom Pad verwendet, also asynchron oder werden sie einsynchronisiert? Im ersteren Fall wird der Fehler mit hoher Wahrscheinlichkeit daher rühren. Gruß
Nein, das Schaltverhalten ist ok. Es geht pro Tastendruck jeweils um eines weiter.
Mir geht es nicht um Prellen, sondern darum, ob die Tastensignale synchron zum intern verwendetem Takt sind. Schicke die Tastensignale erst einmal durch ein FF und nutze das FF-Signal für die interne Verarbeitung.
Das Gegenteil von "Area" ist ja "Speed". Das heißt die Toolchain gibt sich nun weniger Mühe, das Design möglichst schnell zu bekommen. Da drängt sich mir die Frage auf: Stimmen deine Timinconstraints und läuft die Timinganalyse ohne Fehler durch?
Early Bird schrieb: > Gibt es das? Eher unwahrscheinlich... Ich denke, dass es daran liegt, dass du eine "unsaubere" Beschreibung hast, die in dem einen Fall halt noch funktioniert und bei der anderen Strategie natürlich zu einem anderen Syntheseergebnis führt, bei welcher dann die "unsaubere" Beschreibung zum Tragen kommt. Mal ein Beispiel: Wenn du z.B. wie Daniel M. ja schon angedeutet hast, deine Tastensignale nicht einsnchronisierst, also die Datenwechsel in Phasenbezug zum internen Takt bringst, dann kann das zu genau solchen Effekten führen. Das ist dann aber kein Fehler der Synthese, sondern die Fehlerquelle sitzt dann 50cm vor dem Bildschirm. :-) Warum das zu Problemen führen kann? Die Information über den Tastenzustand wird in deinem Design vermutlich an mehrere Register führen (Counter, FSM etc). Die Laufzeit vom Pin zum jeweiligen Register ist aber nicht für jeden Pfad gleich. Wechselt jetzt die das Signal am Pin seinen Zustand (Taste gedrückt) unmittelbar vor einer internen Flanke, dann kann sein, dass ein Teil deiner internen Register mit der Flanke den neuen Zustand bereits "erfassen" und ein anderer Teil noch nicht. Das kann dann z.B. bei einem Zustandsspeicher für eine FSM dazu führen, dass deine FSM in einen falschen oder einen gar nicht codierten Zustand abbiegt... Gerade bei einer Area-Optimierung kann sein, dass die FSM nicht mehr one-hot-codiert wird und dann kann dein Zustandsspeicher sogar Zustände einnehmen, die du gar nicht codiert hast. Ich denke, wie Daniel auch, dass du irgendwo so einen Fehler "vergraben" hast, der eben jetzt zum Vorschein kommt.
Daniel M. schrieb: > Mir geht es nicht um Prellen, sondern darum, ob die Tastensignale > synchron zum intern verwendetem Takt sind. > > Schicke die Tastensignale erst einmal durch ein FF und nutze das > FF-Signal für die interne Verarbeitung. Sonst passiert dir das da: http://www.lothar-miller.de/s9y/archives/64-State-Machine-mit-asynchronem-Eingang.html Denn ein Zähler ist die einfachste Form einer FSM. > Am VHDL wurde nichts geändert. Ich habe nun wieder alles auf balanced > gestellt und es geht wieder. Klassischer Effekt von nicht einsynchronisierten Eingängen und/oder asynchronen kombinatorischen Resets. Wie sieht der VHDL-Code aus? Einfach hier als *.vhd oder *.vhdl Datei anhängen.
Early Bird schrieb: > > Am VHDL wurde nichts geändert. Ich habe nun wieder alles auf balanced > gestellt und es geht wieder. > > Gibt es das? Abgesehen mal von Tiningchecks, die auch wichtig sind: Synthese, Mapping, Bitfile-Gen. läuft ohne die geringste Infomsg/Warningmsg durch? Zumeist sieht man auch dort schon was (wie "latches implemented", "comparison may fail", "missing signal in sensitivity list", "may cause bad timing" oder so) um auf ein mögliches Problem zu schließen - welches wie Schlumpf angedeutet hat dann durch verändertes Constraining (wie area/speed) aufgedeckt wird...
Early Bird schrieb: > Ich habe das Optimierungsziel auf Area getrimmt, dabei festgestellt dass > das in MAP noch auf speed stand Eine von mehren Merkwürdigkeiten der Xilinx-Toolchain :-) Wenn es kein Synchronisationsproblem ist, dann kann u.U. die Projektverwaltung Probleme bereiten. Ich hatte im letzten Projekt regelmässig Probleme, das Timing zu treffen, wenn ich zu lange herumsynthetisert habe. Einige Optimierungen bei Xilinx XST haben Mängel und funktionieren offenbar nicht richtig. Ich habe ebenfalls schon designs auf "speed" synthesitiert und sie wurden nicht schneller, sondern langsamer. Schuld daran sind offensichtlich alte Ergebnisse vorheriger Läufe, die vom Smartguide genutzt werden. Er muss ja immer entscheiden, ob er einen Teil neu macht, oder nicht - und dort scheint sich die Strategie zu verennen. Wenn ich dann das Projektverzeichnis gesäubert habe, Smartguide ausgeschaltet hatte, ging es plötzlich wieder und die Timings wurden getroffen. Einmal hatte ich den Fall, das garnichts mehr ging. Die Synthese liefr nicht mehr durch. Ich hatte dann einen älteren Projektstand aus Subversion hervorgekramt, in diesen die neuen VHDLs eingepflegt und erst dann lief die Synthes wieder durch. Offenbar gibt es einige versteckte Parameter im Projekt irgendwo, die Einfluss nehmen können.
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.