Forum: FPGA, VHDL & Co. FPGA Synthetisierung etwas nervtötend


von Martin Y. (cyron)


Lesenswert?

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ß

von Uwe B. (Firma: TU Darmstadt) (uwebonnes)


Lesenswert?

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.

von GagoSoft (Gast)


Lesenswert?

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 ;)

von Matthias F. (flint)


Lesenswert?

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

von Martin Y. (cyron)


Lesenswert?

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ß

von Andreas S. (andreas) (Admin) Benutzerseite


Lesenswert?

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.

von Martin Y. (cyron)


Lesenswert?

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??

von Krampusch (Gast)


Lesenswert?

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

von Martin Y. (cyron)


Lesenswert?

wie sieht denn in deinen augen eine solide programmierung aus?? 
vielleicht kannst du mir dafür mal ein beispiel nennen. rein zum 
lernzweck.

DANKE!!

von Martin Y. (cyron)


Lesenswert?

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ß

von Klaus F. (kfalser)


Lesenswert?

> 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

von Morin (Gast)


Lesenswert?

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

von Arndt B. (Firma: Helion GmbH) (bussmann)


Lesenswert?

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

von Klaus F. (kfalser)


Lesenswert?

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

von Gast (Gast)


Lesenswert?

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.

von Smithy (Gast)


Lesenswert?

Mit dem After zu hantieren bringt meist nicht viel.

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
Noch kein Account? Hier anmelden.