hallo leute, ich prgrammiere nun schon seit gut 2..3 jahren fast täglich fpga's oder cpld's in verilog. leider mache ich immer wieder die sehr nervende erfahrung, das der simulierte programmcode einige schwierigkeiten bei der synthetisierung bereitet. was ich meine ist, dass ich mit modelsim oder dem simulator aus quartus recht schnell die gewünschte funktion realisieren kann. es kommt jedoch immer wieder vor das die programmierung anfangs einwandfrei läuft aber dann bei auch nur sehr kleineren änderungen oder anpassungen völlige fehlfunktionen aufweist. macht ihr auch solche erfahrungen?? woran liegt das eurer meinung nach?? sollte ich meinen codestyle überarbeiten?? gibts es unterschiede diesbezgl. zwischen verilog und vhdl?? thanks for your reply........ gruß
Wenn es nur eine Takt Domaene gibt und die Synthese beim anvisierten Takt keine Timingprobleme berichtet, dann sollte das ganz auch laufen, wenn der Hardwareaufbau stimmt. Hat man mehrere Taktdomaenen, wird alles schwieriger. Versuch doch erstma zu verstehen, wass Du aenderst, und wass in den Faellen oben dann schieflaeuft. Dann kannst Du evt selbst Deine Schluesse ziehen.
was mich an der synthese etwas nervt, ist die lange Wartezeit bis ein Ergebnis da ist. Ja kommt schon öfters vor, das der synthetisierte Code nicht so tut wie in der simulation... bei mir ist's meist eine mangelnde testbench, die nicht exakt das Umfeld wiederspiegelt. Sonst ist meist das gewünschte Ergenis nach der Synthese anzutreffen Ich arbeite in vhdl, von verilog hab ich leider keinen blassen Dunst. Aber währent man so auf die syntheseergebnisse wartet (so wie ich jetzt) kann man gemütlich µC Forum lesen ;)
"es kommt jedoch immer wieder vor das die programmierung anfangs einwandfrei läuft aber dann bei auch nur sehr kleineren änderungen oder anpassungen völlige fehlfunktionen aufweist." Änderungen im Code oder Änderungen in der HW drumherum? Ich arbeite zwar erst seit einem halben Jahr täglich mit FPGAs aber ich habe mir schon angewöhnt, jede Codeänderung einmal durch die Simulation zu jagen. Manchmal, wenn ich recht optimistisch bin weil die Änderung sehr klein oder trivial war, werfe ich schon parallel zur Simulation die Synthese an. Auf den FPGA spiel ich das ganze aber erst, wenn ich in der Simulation gesehen habe, dass das ganze funktioniert, wie ich es mir erwarte.
danke erstmal für eure schnellen antworten. zu flint: - das was ich meine sind reine hdl änderungen; hardware ist identisch - in kleineren design ist das sicherlich richtig und kein problem einige wichtige zwischenschritte zu überspringen. bei größeren designs ist meine vorgehensweise auch so wie du sie beschrieben hast. trotz alledem muss eine erfolgreiche simulation nicht gleich eine erfolgreiche und einwandfreie funktion in der realität nachsichziehen. zu Gagosoft: - ja der zeitfaktor nervt noch zusätzlich. es ist aber mit den geeigneten tools etwas in grenzen zu halten. - bei dem umfeld stimmt ich dir auch zu. diese erfahrungen habe ich auch schon mehrfach gemacht. in meinem aktuellen projekt ist jedoch ledigleich ein start-signal zu generieren (hi-lo-transition). der darauf folgende ablauf reagiert auf keine äußeren einflüsse. zumindest bisher. zu Uwe: - das problem an der ganzen sache ist, das es ja nur sehr geringfügige änderungen sind. um das deutlicher machen zu können muss ich wahrscheinlich meine aktuelle programmierung etwas genauer darstellen: ALSOOOO: ich möchte den ltc1427 mit nem smbus-interface ansteuern. smbus ist im grunde nur ein anderer name für i2c. die zur programmierung und der daraus folgenden änderung der ausgangsgröße sind 3 einzelne sequenzen erforderlich. um den takt zu generieren teile ich zunächst den systemtakt soweit runter das er der spezifikation entspricht (50 MHz -> max. 400 kHz). die 3 taktsequenzen erzeuge ich, indem ich einen zähler starte und immer zu festgelegten zählerständen dem scl einen taktwert, 1 oder 0 zuteile (siehe datenblatt diagramm). das klappt alles wunderbar. wenn ich aber zum beispiel die zählerstände leicht anpasse oder ändere kommt es mitunter vor das zum beispiel die komplette mittelsequenz (mittleren 9 takte) nicht kommen. ich habe aber lediglich die scl-belegung von 0 auf taktwert einen zählerstand früher gelegt. die zählerstruktur ist gleich geblieben und der rest auch. nur die erwähnte stelle wurde verändert. und genau das ist mein problem. wieso?? warum?? weshalb?? um jetzt die änderung zu suchen oder zu finden bleibt mir nur übrig die netzliste genauer zu studieren. aber eigentlich müsste mir das auch egal sein, denn in der simulation ist diese fehlfunktion nicht vorhanden. real ist sie jedoch da. versteht das einer?? sollte ich änderungen in den compiler optionen vornehmen?? wenn ihr noch genauere erläuterungen braucht schreibt mir einfach. gruß
Verwendest du scl als Takt (rising_edge(scl))? Dann ist das Problem schon klar: verwende Clock Enable statt einem runtergeteilten Takt (Taktung FPGA/CPLD). Ansonsten siehe VHDL Grundregeln.
also scl ist ein runtergeteilter clk den ich für bestimmte zeiten tod schalte um die einzelnen sequenzen zu unterteilen. der systemtakt für die gesamte programmierung ist 4 mal höher. ich werde deinen hinweis mal einbinden. danke!! hast du vielleicht noch ne andere idee wie man die einzelnen sequenzen für scl erzeugen kann?? oder würdest du einen ähnlichen aufbau wie bereits oben erläutert wählen??
>was ich meine ist, dass ich mit modelsim >oder dem simulator aus quartus recht schnell die gewünschte funktion >realisieren kann. es kommt jedoch immer wieder vor das die >programmierung anfangs einwandfrei läuft aber dann bei auch nur sehr >kleineren änderungen oder anpassungen völlige fehlfunktionen aufweist. Das ist das Naturell! Schnell programmiertes ist anfällig. Du must solide programmieren. Mein Zeugs leuft bestens und synthetisert meist im ersten Anlauf. Es braucht natürlich Vorbereitung und eine solide, vorausschauende Designtechnik.
wie sieht denn in deinen augen eine solide programmierung aus?? vielleicht kannst du mir dafür mal ein beispiel nennen. rein zum lernzweck. DANKE!!
vielleicht noch eine andere frage. überlasst ihr mehr dem compiler die letztendliche umsetzung in die digitale schaltung?? oder arbeitet ihr eher mit primitives?? also mit vordefinierten konstrukten (Bsp.: DFF) ein gutes beispiel dafür könnte eine zählerprogrammierung sein??!!!?? gruß
> oder arbeitet ihr eher mit primitives?? Nein, sonst bräuchte ich ja kein VHDL und portabel ist es dann auch nicht mehr. Gib dem Compiler was des Compilers ist -> die Arbeit. Klaus
> überlasst ihr mehr dem compiler die > letztendliche umsetzung in die digitale schaltung?? Bis zu einem gewissen Grad ja. Zähler z.B. schreibe ich als ein n-bit Register und der Anweisung "x <= x + 1;" im synchronen Teil. "Bis zu einem gewissen Grad" bedeutet konkret: Soweit ich den Synthesetools traue, das hingeschriebene auch korrekt (also ohne Änderung der Semantik) umzusetzen. Dazu gibts Doku im Netz und bei dem jeweiligen Synthesetool. Leider sind HDL-Synthesetools keine Compiler in dem Sinne dass sie ein äquivalentes Programm in einer anderen (tieferen) Sprache erzeugen. Unter dem Stichwort "synthesizable subset" findet man die Menge der VHDL-Programme, die korrekt in Netzlisten compiled werden. Gegenbeispiel wäre die Erzeugung eines 1-Pulses der Dauer 100 ms. Wenn ich "x <= '1'; x <= '0' after 100 ms;" hinschreibe wird der Synthesizer das nicht korrekt synthetisieren (z.B. unter Verwendung eines Zählers), sondern die Semantik der Befehle ändern. Also ist das genau der Punkt, wo ich näher an der eigentlichen Hardware arbeite und den Zähler selbst hinschreibe. Ansonsten lohnen sich tiefere Eingriffe nur wenn entweder die low-level Beschreibung einfacher zu verstehen ist (selten), oder zum Optimieren, und das macht man (aus Erfahrung) nur wenn es unbedingt nötig ist.
Häufige Fehler bei der FPGA Programmierung sind nicht eindeutige Codeteile. Sowohl die Simulatoren, als auch die Synthesetools müssen den Code (in Verilog oder VHDL) interpretieren, da beide Sprachen Hardwarebeschreibungssprachen sind. Sind Teile des Codes nicht eindeutig, so kann jedes Tool die Stelle entsprechend anders interpretieren. ModelSim in diesem Fall ist sehr sehr gutmütig, cver oder icarus dagegen nicht. Meiner Erfahrung nach ist icarus sehr streng, will heissen, auch wenn in der ModelSim Simulation alles gut aussieht, so zeigt die Synthese (aber auch icarus) ein anderes Verhalten. Klassiker für diese Stellen sind Zuweisungen von Vektoren. Vektorbreiten sollten immer explizit angegeben werden. Also: c[3:0] <= a[3:0] + b[3:0]; und nicht c <= a + b; Spielt dann eine Rolle, wenn die Vektorbreiten in der Definition unterschiedlich sind (was dann mit den Bits passiert ist sonst nicht exakt definiert. Unbenutzte Bits werden von dem einen Tool auf 1 von dem anderen auf 0 gelegt). Erstrecht gilt dies für case und if Sequenzen. Es sollte immer nur gegen definierte Bitbreiten getestet werden. Eine weiterer wichtiger Part ist die korrekte Definition der Taktfrequenzen für den mapper, placer und router. Ohne diese Definition kann ein Design mal funktionieren und mal wieder nicht, hängt ganz von der Laune dieser Tools ab (zu meinen Anfängen hatte ich ein Design, wo die Seriennummer erzeugt werden sollte, immer dann, wenn ich ungerade Nummer benutzte, funktionierte das Design nicht mehr. Hier fehlten damals diese Taktangaben).
Bei solchen Beispielen kann ich als VHDL Programmierer nur ein wenig schmunzeln, da ich in meiner ganzen Karriere bis jetzt eigentlich keine nicht eindeutigen Codeteile hatte. Das was ich simuliert habe, ist letztendlich auch rausgekommen (außer einmal wegen einem Bug in ISE).
So schlimm wie es immer dargestellt ist, ist es IMO nicht. Man muss sich nur angewöhnen, die Finger von Simulationstricks zu lassen und weder mit der sensitivity noch den afters herum experimentieren. Dann hat man auch gut simulierbaren code, der sauber synthetisert.
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.