Hallo, ist es legitim, dass die erreichte Geschwindigkeit und Hardwareauslastung eines Designs allein unter Berücksichtigung der Syntheseergebnisse beurteile. Konkret geht es darum, dass ich die Daten in einer Diplomarbeit verwerten will. Aber nicht jede Umsetzung auf FPGA testen kann. Aus diversen veröffentlichten Papern, die ich für Literaturrecherche und Vergleiche verwendet habe erkennt man, dass die das auch nicht anders machen. Bin mir nicht ganz sicher ob das als "Proof of Concept" aber ganz korrekt ist. Viele Grüße Ps. natürlich habe ich auch getestet, dass die Funktion des Designs richtig ist.
Fabian O. schrieb: > Hallo, > > ist es legitim, dass die erreichte Geschwindigkeit und > Hardwareauslastung eines Designs allein unter Berücksichtigung der > Syntheseergebnisse beurteile. Konkret geht es darum, dass ich die Daten > in einer Diplomarbeit verwerten will. Aber nicht jede Umsetzung auf FPGA > testen kann. > Aus diversen veröffentlichten Papern, die ich für Literaturrecherche und > Vergleiche verwendet habe erkennt man, dass die das auch nicht anders > machen. > Bin mir nicht ganz sicher ob das als "Proof of Concept" aber ganz Die max. taktung (geschwindigkeit wird durch die Länge und das Fanout des kritischen Pfades bestimmt. Anhand dieser sollten sich versch. Strukturen bewerten lassen (kürzer (weniger Gatter zwischen Pipelinestufen) und wenige Fanout = schneller und besser). MfG,
Vielen Dank. ja genau diese Zeit wollte ich verwenden. Für eine Bewertung recht das sicherlich aus. Ich tue mich dabei aber etwas schwer die Behauptung aufzustellen, dass ich eine gewisse Taktfrequenz sicher erreichen kann. Obwohl ich es nur in der Hardwaresynthese geprüft habe. Die Erfahrung hat mir gezeigt, dass die erreichbaren Taktfrequenzen teilweise doch nicht so hoch sind wie vom Synthesetool berechnet. naja, irgendwie ist es auch egal. Wenn die restlichen Leute in ihren Veröffentlichungen nicht anders argumentieren wird es wohl ok sein wenn ich es genauso mache.
Fabian O. schrieb: > ja genau diese Zeit wollte ich verwenden. Für eine Bewertung recht das > sicherlich aus. Und für einen Vergleich bei gleichen Bedingungen (meist) auch. > Ich tue mich dabei aber etwas schwer die Behauptung > aufzustellen, dass ich eine gewisse Taktfrequenz sicher erreichen kann. Warum solltest du das tun? Bicht dir ein Zacken aus der Krone wenn du einfach schreibst das es sich hierbei um die berechneten Werte aus der HW-Synthese handeln auf dem Chip XYZ? > Obwohl ich es nur in der Hardwaresynthese geprüft habe. Die Erfahrung > hat mir gezeigt, dass die erreichbaren Taktfrequenzen teilweise doch > nicht so hoch sind wie vom Synthesetool berechnet. Es kommt einfach auch darauf an was man fordert. Wenn deine Designrules eine Taktfrequenz von 50Mhz vorsehen, warum sollte der Placer/Fitter/... das ganze für 200MHz optimieren? Wenn er irgenwas >= 50 MHz erreicht hat bricht er halt (sinnvollerweise) ab. > naja, irgendwie ist es auch egal. Wenn die restlichen Leute in ihren > Veröffentlichungen nicht anders argumentieren wird es wohl ok sein wenn > ich es genauso mache. Naja... Ob das so die richtige Einstellung ist..
Läubi .. schrieb: >> Ich tue mich dabei aber etwas schwer die Behauptung >> aufzustellen, dass ich eine gewisse Taktfrequenz sicher erreichen kann. > Warum solltest du das tun? Bicht dir ein Zacken aus der Krone wenn du > einfach schreibst das es sich hierbei um die berechneten Werte aus der > HW-Synthese handeln auf dem Chip XYZ? > >> Obwohl ich es nur in der Hardwaresynthese geprüft habe. Die Erfahrung >> hat mir gezeigt, dass die erreichbaren Taktfrequenzen teilweise doch >> nicht so hoch sind wie vom Synthesetool berechnet. > Es kommt einfach auch darauf an was man fordert. Wenn deine Designrules > eine Taktfrequenz von 50Mhz vorsehen, warum sollte der Placer/Fitter/... > das ganze für 200MHz optimieren? Wenn er irgenwas >= 50 MHz erreicht hat > bricht er halt (sinnvollerweise) ab. Das Problem ist eher das P&R unterhalb der Synthesemessungen bleibt. Beispielsweise, weil der Chip zu Voll und verknotete Routingresourcen genutzt werden müssen. Oder weil irgendwelche LOCATION constraints andere Componenten Wege verbauen. Oder der Placer einfach zu bloed ist und aus den 8 DCM's immer die falschen auswählt. Shit happens,
Jetzt kenn ich mich nicht aus, hast du das tatsächlich schon auf FPGAs getestet? Wenn ja, wie kann es dir dann passieren, dass die tatsächliche maximale Taktrate nicht der berechneten entspricht? Es mag ja immer wieder Probleme geben, aber so schlecht sollte die STA da nicht abschneiden. Anderer Ansatz wäre evtl, das Design einmal mit unrealistischen Einstellungen und brute-force synthetisieren zu lassen, sodass das tool das beste rausholt, was es schafft. Dann identifiziert man den längsten Pfad, macht sich ein wenig Gedanken, wie das auf unterschiedlichen FPGA-Architekturen bzw vlt. auch ASICs implementiert werden könnte und gibt auf Basis dieser Argumentation eine gewisse Grundspezifikation für den Chip an und die Parameter, die man mit dem Design für so was erreicht. Dann kann man in 10 Jahren mit dem Paper auch noch was anfangen. lg Matthias
Die statische Timing Analyse kommt weit hinter der Synthese. In der STA bei späteren Prozessschritten sind bereits Routingpfade mit einbezogen. Das ist in der Zahlenangabe bei der Synthese nicht (in ausreichendem Maß) der Fall. > Anderer Ansatz wäre evtl, das Design einmal mit unrealistischen > Einstellungen und brute-force synthetisieren zu lassen, sodass das > tool das beste rausholt, was es schafft. Das bringt nichts, probiers aus ;-) Besser ist der Weg von "unten" her, da sind die Tools arg menschlich: Erst mal wenig verlangen, dann ein wenig mehr, usf...
Da gibts auch eine Appnote dazu, leider weiß ich weder den Namen noch die Nummer. In jedem Fall war die Aussagen(nicht wörtlich !) : Wenn man 50 mhz fordert erreicht man auch etwa 50mhz Wenn man 60mhz fordert erreicht man mitunter auch nur 50mhz. Wenn man 55 mhz fordert, dann erreicht man ggf sogar 55 mhz. Der Grund : das Synthese Tool probiert nicht unendlich viele Möglichkeiten aus und verfolgt Ansätze die nicht vielversprechend sind (55mhz sind nicht vielversprechend wenn man 60mhz will) nicht weiter da dies in einer Sackgasse endet. >> Die Erfahrung >> hat mir gezeigt, dass die erreichbaren Taktfrequenzen teilweise doch >> nicht so hoch sind wie vom Synthesetool berechnet. Wo hast du denn diese Erfahrungen gemacht ? Meine Erfahrung ist eher das man tendenziell deutlich schnellere Taktraten real erreicht als theoretisch angegeben werden. Da dies aber von Temperatur, Spannung und insbesondere dem speziellen Chip abhängt bringt es garnichts die ermittelten Werte anzugeben in einer wissenschaftlichen Arbeit. Bsp : wenn du einen Test einer x86 CPU liest, dann willst du auch wissen wie diese läuft wenn du sie kaufst und nicht (ausschließlich) wenn sie maximal übertaktet ist.
@Fpga Kuechle:
> Das Problem ist eher das P&R unterhalb der Synthesemessungen bleibt.
Da habe ich eine andere Erfahrungen: Teilweise schafft P&R das doppelte,
wo die Synthese nur 70 MHz schafft.
Duke
>> Die Erfahrung >> hat mir gezeigt, dass die erreichbaren Taktfrequenzen teilweise doch >> nicht so hoch sind wie vom Synthesetool berechnet. Tschuldigung wenn das falsch verstanden wurde. Bei dem einen Design lies sich die Taktrate die berechnet wurde nicht erreichen. komischerweise. >> naja, irgendwie ist es auch egal. Wenn die restlichen Leute in ihren >> Veröffentlichungen nicht anders argumentieren wird es wohl ok sein wenn >> ich es genauso mache. >Naja... Ob das so die richtige Einstellung ist.. Das soll nicht heißen, dass ich mir die Arbeit leicht machen will, denn wenn ich Mist publiziere schneide ich mir eh ins eigene Fleisch. War eher so gemeint, dass es wohl in Ordnung geht, wenn man sich auf die Ergebnisse aus der Synthese verlässt und sie verwendet Ansonsten nochmals vielen Dank für die Menge der Anworten
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.