Forum: FPGA, VHDL & Co. Freitag: Umgang mit Warnungen


von Martin O. (ossi-2)


Lesenswert?

Ich bin noch ziemlicher Neuling bei FPGAs. Ich habe den Eindruck, dass 
relativ schnell Warnungen bei Designs entstehen. Mitunter gibt es 
Designs die in VIVADO warnungsfrei sind, in QUARTUS aber Warnungen 
ergeben.

Daher mal die Frage: Wie geht Ihr mit Warnungen beim FPGA Design um? 
Korrigiert Ihr solange, bis die letzte Warnung verschwunden ist? 
Ignoriert Ihr Warnungen?

von Teo D. (teoderix)


Lesenswert?

Ich bin zwar kein FPGAler aber das macht keinen Unterschied.
Warnung heißt doch nur "Achtung, weist du auch genau was du tust?"!
Wenn nicht, Abhilfe schaffen oder Problem anders lösen, ohne Warnung....

: Bearbeitet durch User
von Artha (Gast)


Lesenswert?

Teo D. schrieb:

> Ich bin zwar kein FPGAler ...

Hauptsache irgendeine Binsenweisheit loswerden.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Martin O. schrieb:
> Wie geht Ihr mit Warnungen beim FPGA Design um?
Du beachtest sie und wenn dir keine plausible Erklärung dafür einfällt, 
dann kontrollierst du, wie es dazu kommt.

Das gilt übrigens für alle Meldungen, auch wenn z.B. "nur" die Info 
kommt, dass die Sensitivliste nicht vollständig und deshalb die 
Simulation falsch ist...

: Bearbeitet durch Moderator
von Teo D. (teoderix)


Lesenswert?

Artha schrieb:
> Hauptsache irgendeine Binsenweisheit loswerden.

Wenn sie zutrifft, was spricht dagegen?
Oder möchtest du damit andeuten, das du was anderes behaupten möchtest?
Nur raus damit!

von Burkhard K. (buks)


Lesenswert?

Lothar M. schrieb:
> Du beachtest sie und wenn dir keine plausible Erklärung dafür einfällt,

Wobei die Komplexität hinter Warnungen schon sehr unterschiedliches 
Niveau haben kann.

XST z.B. warnt: "Node xyz is unconnected in block <abc>", selbst wenn im 
dazugehörigen Port Mapping bereits "xyz => open" steht. (Erklärung: "Zu 
simpel gestricktes Synthesetool"?)

Interessant bis absolut nervig kann es beim Einbinden fremder IP werden. 
Der MIG (Memory Interface Generator von Xilinx) ist so ein Kandidat; bei 
dessen Verwendung können schon mal mehrere Tausend Warnungen zusammen 
kommen.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Burkhard K. schrieb:
> (Erklärung: "Zu simpel gestricktes Synthesetool"?)
Eher: "Der der da warnt, weiß nichts mehr von dieser Portzuweisung", 
denn diese Warnung kommt ja nicht vom Synthesizer und die zum Ignorieren 
nötige Information ist zwischendurch auf der Strecke geblieben...

> Interessant bis absolut nervig kann es beim Einbinden fremder IP werden.
Da hilft dann tatsächlich nur noch ein brauchbarer grep zum Filtern oder 
was Selbstgestricktes.  :-/

: Bearbeitet durch Moderator
von Rudolph (Gast)


Lesenswert?

Bei Unterhaltungen mit Leuten, die eher Software machen, wurde mit immer 
wieder erzählt, dass diese eine "No Warning" Policy durchziehen. Da 
musste ich dann immer bitter auflachen...

Martin O. schrieb:
> Daher mal die Frage: Wie geht Ihr mit Warnungen beim FPGA Design um?
> Korrigiert Ihr solange, bis die letzte Warnung verschwunden ist?
> Ignoriert Ihr Warnungen?

Leider ist es tatsächlich so, dass es viele Warnings gibt, die einfach 
pauschal geworfen werden, wenn bestimmte Konstrukte benutzt werden (BRAM 
zum Beispiel...). Die kann man dann gar nicht wegbekommen. Schlimm ist 
es dann tatsächlich, wenn man IP benutzt und dieser alleine schon alles 
mit Warnings zuklumpt.

Es gibt da gerade bei Vivado diverse Gegenmaßnahmen. Man kann die IPs 
Out-Of-Context synthetisieren, dann bekommt man deren Warnings gar nicht 
mehr mit, und es gibt das Message Filtering, mit dem einzelne bestimmte 
Warnings oder alle Warnings eines Typs ausgeblendet werden können (gab's 
bei ISE auch schon, aber eher mäßig gut funktionierend).

Alleine dass es das Message Filtering gibt, spricht schon Bände, ohne 
dieses wird man umfangreicheren Code niemals warningfrei bekommen.

Also, man korrigiert, was zu korrigieren ist (wenn man das in dem ganzen 
Wust den überhaupt findet), und den Rest ignoriert man (oder lässt 
ignorieren, wenn man den filtert).

von Sebastian S. (amateur)


Lesenswert?

@Artha
>Teo D. schrieb:

>> Ich bin zwar kein FPGAler ...

>Hauptsache irgendeine Binsenweisheit loswerden.

Hierzu fällt mir nur: "Senf dazugeben" ein.


Egal ob Fehler oder Warnung, man wird sich mit beidem Beschäftigen 
müssen und sich zu jeder Ausgabe Gedanken machen.
Ob und was dagegen unternommen werden muss, kann sowieso nur der Typ an 
der Tastatur entscheiden. Dazu gehört aber, dass man die Ausgabe gelesen 
und eventuell auch verstanden hat.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Sebastian S. schrieb:
> Dazu gehört aber, dass man die Ausgabe gelesen und eventuell auch
> verstanden hat.
Streiche "eventuell".
Merke: nur eine Warnung, deren Tragweite man verstanden hat, darf man 
auch ignorieren.

von Rudolph (Gast)


Lesenswert?

Lothar M. schrieb:
> Merke: nur eine Warnung, deren Tragweite man verstanden hat, darf man
> auch ignorieren.

Wenn das denn überhaupt möglich ist. Leider sind die Warnings selbst oft 
eher kryptisch formuliert, und weitere Beschreibungen meist nicht 
vorhanden oder man muss sie sich mühsam aus den Foren suchen. Leider 
wird man da von den Herstellern nicht besonders gut unterstützt.

Und irgendwann wird man dann fatalistisch...

von Finger Hakler (Gast)


Lesenswert?

Rudolph schrieb
> Wenn das denn überhaupt möglich ist. Leider sind die Warnings selbst oft
> eher kryptisch formuliert, und weitere Beschreibungen meist nicht
> vorhanden oder man muss sie sich mühsam aus den Foren suchen. Leider
> wird man da von den Herstellern nicht besonders gut unterstützt.
>
 Du kannst Dir die Mühen sparen, lass deine Finger davon und überlass 
das denen die sich gern in Probleme vertiefen und lernbereit sind.

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.