Eine Frage an die Optimierer des Stromverbrauchs von FPGAs: Ich musste anhand mehrerer Schaltungen feststellen, dass die Stromaufnahme der FPGAs leicht steigt, wenn sie mit der Version 2019.1 erzeugt werden, als mit der 2018.3. Dafür laufen die Synthesen schneller durch. Die Synthesen laufen mit denselben Scripten und Einstellungen. Kann es sein, dass man Genauigkeit und Optimierung dem Synthesetempo geopfert hat?
Weltbester FPGA-Pongo schrieb im Beitrag #5994575: > Kann es sein, dass man Genauigkeit und Optimierung dem Synthesetempo > geopfert hat? Nein, es sei denn, du kannst einen kausalen Zusammenhang quantitativ nachweisen. Der Stromverbrauch hängt im wesentlichen von Optionen ab die keinen Einfluss auf die Syntheselaufzeit haben. Bspw. ob beim bitgen die bits gesetzt werden, die Sicherstellen, das ungenutzte Teile des clock-trees abgeschaltet werden. Ob jetzt das P&R schneller oder langsamer für eine constraint driven Optimierung durchläuft, hat m.E. keinen wesentlichen Einfluss auf die Aktivierung der Stromsparmassnahmen.
Das kann schon sein. Ich hab die Beobachtung gemacht dass die Synthese und Implementierungs Settings zwar dann von der alten Version irgendwie übernommen werden, aber manchmal nicht korrekt funktionieren. Wenn du bei den Presets schaust hast du immer die Verionsangabe dahinter stehen. Bei mir hat es geholfen statt Performance...2018.3 dann Performance...2019.1 auszuwählen und dann lief es wie gewohnt. Ich hatte das ab und zu beim Timing dann.
Hat sich tatsächlich die gemessene Leistungsaufnahme erhöht oder nur die von Xilinx geschätzte in einem Report? Bei Intel gab es vor ein, zwei Jahren den Fall das eigentlich bereits als Final deklarierte Powermodelle für den Arria 10 nochmals geändert wurden. Danach hat die Powerestimation höhere Werte geliefert aber die gemessenen Werte blieben gleich.
Kommt denn ähnliche Ressourcennutzung raus? Habe da durchaus schon Unterschiede von 5-10% bei den Luts/FFs festgestellt bei gleichem Design. Besonders dämlich übrigens wenn das Design vorher rein gepasst hat und in der neuen Version nicht mehr passt.
die 2019.1 scheint nicht so dolle. Habe einen Kollegen, der ist wegen der Fehler wieder auf die 2018.3 zurück gestiegen. Ist das bei Xilinx eigentlich immer noch so, dass die geraden Versionszahlen die Guten sind?
Ein Design für einen kleinen Artix XC7A15T komplett ohne IP.
1 | 2018.3 2019.1 (2018 Strategy) 2019.1 (2019 Strategy) |
2 | ________________________________________________________________ |
3 | WNS | 0.313 ns 0.198 ns 0.305 ns |
4 | Power | 0.191 W 0.192 W 0.155 W |
5 | LUT | 68.23 % 68.14 % 62.91 % |
6 | FF | 35.76 % 35.76 % 27.17 % |
7 | BRAM | 96 % 96 % 96 % |
8 | DSP | 35.56 % 35.56 % 35.56 % |
Wenn ich das Projekt also nur kopiere oder ohne Änderung mit dem neuen Vivado öffne, also mit alter 2018 Strategy, dann wird das WNS schlechter. Stelle ich dann die gleichen Strategys ein, aber statt 2018 jetzt 2019 wird das WNS besser, aber auch am Rest verbessert sich einiges. el Bi schrieb: > Ist das bei Xilinx eigentlich immer noch so, dass die geraden > Versionszahlen die Guten sind? Das ist brandgefährlich. Gut bei Xilinx Tools jetzt vielleicht weniger, aber bei sicherheitskritischer Software weil dann Leute manche Patchversionen auslassen weil "das ist eine ungerade Version" oder "das ist eine .0 Version". Am Ende führt das zu weniger gepatchten Systemen und sogar dazu, dass manche Projekte keine .0 mehr ausliefern sondern gleich eine .1 bauen.
:
Bearbeitet durch User
Gustl B. schrieb: > Stelle ich dann die gleichen Strategys ein, aber statt 2018 jetzt 2019 > wird das WNS besser, aber auch am Rest verbessert sich einiges. Das deckt sich mit meinen Erfahrungen. Siehe oben. Man muss nur jedes Mal dran denken. Insgesamt macht die 2019.1 bei mir nicht mehr und und nicht weniger Probleme als die 2018.3
Christian R. schrieb: > Insgesamt macht die 2019.1 bei mir nicht mehr und und nicht weniger > Probleme als die 2018.3 Welche?
x.1 vermeide ich auch gerne. In .2 und höher gab es meist mehr "Reife". Ein Ändern der Versionen lohnt sich am meisten bei neuen Projekten. "Brandgefährlich" finde ich es nicht. Denn am Ende müssen die eigenen Tests herhalten. Den Flow geradeziehen ist aber meist irgendwo notwendig und meist mehr als nervig. Blockdesigns sind öfters mal pflegebedürftig. Falls die Synthese irgendwie schlechter ausfällt, würde ich zuerst schauen, ob die Syntheses überhaupt auf diesen Parameter ausgelegt war.
Tim schrieb: > "Brandgefährlich" finde ich es nicht. Denn am Ende müssen die eigenen > Tests herhalten. Stimmt für den Fall hier vermutlich. Aber in der Softwarewelt gehen Hersteller oft davon aus, dass der Benutzer immer alle Patches installiert. Da wird auch leise unsichtbar gepatcht. Da kommt dann eine neue .0 mit neuen Features, aber eben auch mit Patches die aber nicht dabei stehen weil das der Hersteller gerne geheim halten will. Die verpasst man dann also.
Gustl B. schrieb: > Die verpasst man dann > also. das macht nichts, wenn man an eine getestete und zugelassene SW hat mit der man arbeiten kann. die patches beziehen sich eh meist nur auf neue funktionen und chips, die man nicht im einsatz hat, oder deren macken man kennt klar, solange man irgendwelche probleme hat, wird man neue patches herbei sehnen ich sehne bei Xilinx aber schon lange nichts anderes mehr herbei als einen großen dicken Asteroiden, der dort einschlägt.
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.