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ß
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.
