Forum: FPGA, VHDL & Co. wie "voll" darf ein FPGA werden - Bedeutung von area constraint?


von Martin K. (mkohler)


Angehängte Dateien:

Lesenswert?

Hallo,

Wie "voll" sollte ein FPGA werden, damit es in Zukunft voraussichtlich 
nicht Probleme geben sollte?
Hintergrund:
Ich hatte mal ein Design für den Xilinx XC2S100, welches mit ISE6.3.03i 
implementiert werden konnte. Bei der Synthese meldet das System jeweils 
irgendwann "Found area constraint ratio of 100 (+5) ... actual ration is 
102"
Nach irgendwelchen Optimierungen wurde dann "actual ratio is 97" 
ausgegeben und die Implementation klappte wunderbar - mit ISE6.3...

Nach einem Wechsel auf ISE 9.2 musste ich aber feststellen, dass das in 
ISE6.3 erstellte Modell nicht mehr in den XC2s100 passte. ISE9.2 
schaffte es trotz aller Versuche nicht, das Design zu implementieren.

Für die Wartung des alten Designs bin ich nun gezwungen, ISE6.3 und 
ISE9.2 parallel auf der Kiste zu haben. Das klappt ja zum Glück 
einwandfrei, hat aber trotzdem einen etwas unschönen Beigeschmack.


Nun möchte ich denselben Fehler nicht nochmals machen und frage mich 
deshalb, welche Kenndaten einen Hinweis darauf geben, wie voll ein FPGA 
wirklich ist. Die schönsten Zahlen freier FFs nützen mir ja nichts, wenn 
nicht mehr geroutet werden kann.

Auf was achtet ihr bei euren Designs?

Im Anhang sind die Ausgaben der Design Summary des aktuellen Projekts 
dargestellt. Kann man da relevante Infos daraus entnehmen?

Gruss, Martin

-------------------------------------

Und hier noch ein paar "Auslastungszahlen" der Synthese/Implementation:
Synthesis Report
...
Found area constraint ratio of 100 (+ 5) on block KUSB_IO_FLEX, actual 
ratio is 91.
...
Device utilization summary:
Selected Device : 3s250evq100-5
 Number of Slices:                    2328  out of   2448    95%
 Number of Slice Flip Flops:          2121  out of   4896    43%
 Number of 4 input LUTs:              3631  out of   4896    74%
 Number of IOs:                         63
 Number of bonded IOBs:                 63  out of     66    95%
 Number of BRAMs:                        8  out of     12    66%
 Number of GCLKs:                        1  out of     24     4%

Map Report
Design Summary
--------------
Logic Utilization:
  Number of Slice Flip Flops:       2,064 out of   4,896   42%
  Number of 4 input LUTs:           3,523 out of   4,896   71%
Logic Distribution:
  Number of occupied Slices:                        2,446 out of   2,448 
99%
    Number of Slices containing only related logic:   2,103 out of 
2,446   85%
    Number of Slices containing unrelated logic:        343 out of 
2,446   14%
Total Number of 4 input LUTs:          3,635 out of   4,896   74%
  Number used as logic:              3,523
  Number used as a route-thru:         112
  Number of bonded IOBs:               63 out of      66   95%
    IOB Flip Flops:                    57
  Number of Block RAMs:                8 out of      12   66%
  Number of GCLKs:                     1 out of      24    4%

Place and Route Report
Design Summary Report:
 Number of External IOBs                          63 out of 66     95%
   Number of External Input IOBs                 35
      Number of External Input IBUFs             35
        Number of LOCed External Input IBUFs     35 out of 35    100%
   Number of External Output IOBs                20
      Number of External Output IOBs             20
        Number of LOCed External Output IOBs     20 out of 20    100%
   Number of External Bidir IOBs                  8
      Number of External Bidir IOBs               8
        Number of LOCed External Bidir IOBs       8 out of 8     100%
   Number of BUFGMUXs                        1 out of 24      4%
   Number of RAMB16s                         8 out of 12     66%
   Number of Slices                       2446 out of 2448   99%
      Number of SLICEMs                      0 out of 1224    0%

Starting Router
Phase 1: 18715 unrouted;       REAL time: 2 mins 33 secs
Phase 2: 17345 unrouted;       REAL time: 2 mins 38 secs
Phase 3: 7254 unrouted;       REAL time: 2 mins 45 secs
Phase 4: 7254 unrouted; (1363)      REAL time: 2 mins 47 secs
Phase 5: 7275 unrouted; (1274)      REAL time: 2 mins 51 secs
Phase 6: 7277 unrouted; (0)      REAL time: 2 mins 53 secs
Phase 7: 0 unrouted; (0)      REAL time: 3 mins 29 secs
Phase 8: 0 unrouted; (0)      REAL time: 3 mins 34 secs

von Duke Scarring (Gast)


Lesenswert?

Schau Dir mal mit xdlanalyze (http://www.da.isy.liu.se/~ehliar/stuff/) 
an, wo denn ISE 9.2. anders ist, als ISE 6.3 (evtl. musst Du ein 
größeres Device einstellen um überhaupt Ergebnisse zu sehen).

Duke

von vbc (Gast)


Lesenswert?

> Selected Device : 3s250evq100-5

Der report ist aber nichtens für einen Spartan2 ?!

von Martin K. (mkohler)


Lesenswert?

vbc wrote:
> Der report ist aber nichtens für einen Spartan2 ?!
Scharf erkannt ;-)

Ich schrieb ja auch vom aktuellen Projekt, bei dem ich den 
Auslastungsfehler nicht nochmals machen will. Daher sind auch die 
angehängten Kenndaten vom aktuellen Projekt, in welchem ein XC3S250e 
eingesetzt wird.

von Morin (Gast)


Lesenswert?

> Nach einem Wechsel auf ISE 9.2 musste ich aber feststellen, dass das in
> ISE6.3 erstellte Modell nicht mehr in den XC2s100 passte. ISE9.2
> schaffte es trotz aller Versuche nicht, das Design zu implementieren.

Ich hatte mal ähnliche Probleme mit dem Timing (9er erzeugte ein zu 
langsames Design). Das und diverse andere Gründe (z.B. Bugs) haben mich 
dazu gebracht bei der 6er zu bleiben, und gleiches empfehle ich auch 
dir. Fazit: Versionswechsel nur, wenn es absolut nötig ist (z.B. 
Synthese auf einem Device, welches von der alten Version nicht 
unterstützt wird).

> Für die Wartung des alten Designs bin ich nun gezwungen, ISE6.3 und
> ISE9.2 parallel auf der Kiste zu haben.

Ja, genau so würd ich es machen.

> Das klappt ja zum Glück
> einwandfrei, hat aber trotzdem einen etwas unschönen Beigeschmack.

Gewöhn dich schon mal dran :) Der Beigeschmack wird nämlich, solang du 
mit Xilinx-Software arbeitest, nicht mehr weggehen.

von Martin K. (mkohler)


Lesenswert?

Morin wrote:
> Das und diverse andere Gründe (z.B. Bugs) haben mich
> dazu gebracht bei der 6er zu bleiben, und gleiches empfehle ich auch
> dir. Fazit: Versionswechsel nur, wenn es absolut nötig ist (z.B.
> Synthese auf einem Device, welches von der alten Version nicht
> unterstützt wird).
Genau da sind wir mit den XC3S250e, die werden in der 6.3er Version 
nicht unterstützt.

von xvz (Gast)


Lesenswert?

Tja, was soll man da sagen, FPGA's werden immer zu 99% voll, ansonsten 
wird man vom Controlling erschlagen, da man zu teuer entwickelt.

So als Erfahrungswerte aus den Jahren 2002-2005:
-Xilinx gibt als Schallmauer an der der router erheblich länger läuft 
95% Auslastung an (Slices)
-BMW ließ Projekte auf 80-90% Auslastung spezifizieren
-Persönlich schlafe ich bis 90% ruhig.

Nur lässt sich dies eben nie umsetzen, der nächstgrößere Chip ist ja 
gleich 30% größer. Und sag mal den Chef, das Du dies und jenes nicht 
einbauen willst, weil dann die Auslastung über 90% ist aber die ISE 
V13.092 die im Spätsommer 2012 kommt, das nicht mehr schaffen könnte.

Und man kann den Code immer so schreiben, das neuere versionen immer das 
selbe daraus machen müssen. Um das archivieren alter ISE-Installationen 
und sei es nur aus Dokumentationsgründen, wirst Du nicht herum kommen.

von Martin K. (mkohler)


Lesenswert?

xvz wrote:
> -Persönlich schlafe ich bis 90% ruhig.
Dann würden bei meinen 99% occupied slices also die Alarmglocken 
schrillen?

Aber "occupied slices" ist ja eigentlich immer nahe 100%, wenn der 
Synthesizer speed-optimiert arbeiten soll (ausser es ist wirklich 
wenig im Design drin). Somit kann doch die Anzahl Slices eigentlich 
nicht das Mass für die Auslastung des FPGA sein.

Kann ich denn eher auf die "Logic Utilization" mit den 42% FFs und den 
71% LUTs schauen?

von xvz (Gast)


Lesenswert?

Naja Du hast unrelated logic angeschaltet. Das ist gut, da platzsparend,
daher gehe ich davon aus dass die 99% Slices realistisch sind. Dagegen 
eine Auslastung ähnlich des Maximums aus Anzahl_ff und _LUT anzunehmen 
ist falsch. (bei Virtex5 mit 4 LUT/FF pro Slice sieht das anders aus). 
Wobei ich allerdings immer auf Fläche bzw -balanced optimiere, da das 
die besseren Ergebnisse bringt
(vorausgesetzt der der Takt ist nicht pervers hoch).

Ermittele doch die Flächenauslastung experiementell, Bau testhalber ein 
paar Counter oder ähnliches in einer Generate schleife ein und taste 
dich so an die NoGo-Grenze ran. das ist eine praktische Näherung, alles 
andere sind nur theoretische Kennzahlen. Und bei Deinen 99% sollte man 
sich wirklich diese Zeit nehmen, um den bedenken nachzugehen.

von xvz (Gast)


Lesenswert?

BTW, persönlich würde ich hinsichtlich der LUT-Auslastung von 74% 
(inklusive der route thru's) ausgehen, nicht von 71% (Logic Utilization 
only).

Jedenfalls ist es mir und den FAE 2005 (ISE 6.*) nicht gelungen die 
route thrus wegzuoptimieren. Und die Ursache für diese konnten wir auch 
nicht finden, es sah so aus als ob beim Spartan3 und unseren design 
Signale unverknüpft durch eine LUT geführt werden müßen. Aber vielleicht 
löst sich das Problem, wenn Du auf Area optimierst.

von Martin K. (mkohler)



Lesenswert?

ich habe nun mal den Synthesizer auf "area optimized" mit "effort high" 
eingestellt, dabei ist das Bild im Anhang raus gekommen.

Habe ich nun ein Platzproblem?

Ich glaube nicht, denn ich habe testhalber schon ein paar Instanzen 
eines grösseren Funktionsblocks zusätzlich eingefügt gehabt, das hatte 
geklappt.

Wie aber kann der Füllgrad des FPGA z.B. von BMW auf 80-90% spezifiziert 
werden, welche Zahlen sind dafür zu beachten?

von ehk (Gast)


Lesenswert?

Tja nix ist für ewig gültig, auch nicht die Algorhitmen der FPGA-Mapper:
Also irgendwo zw. ISE 6 und 9 hat Xilinx die Software so geändert, dass 
möglichst viele Slice benutzen werden, wenn auch nur halb, oder viertel 
(beim Spartan3 hat ein slice 2 FF und 2 LUT). Der FAE hats mir im 
Vergleich mit einem Gas erklärt, das sich im gesamten Raum ausbreitet 
und damit verdünnt. Ergo ist die Auslastung der Slices zu vergessen und 
dafür das Maximum von LUT oder FF-Auslastung zu nehmen... Die BMW-Spec 
stammt noch aus Zeiten, in denen die Slice-Auslastung das maßgebliche 
war. Man lernt halt nie aus....  Also Du kannst wohl doch von 74% 
ausgehen.

von Martin K. (mkohler)


Angehängte Dateien:

Lesenswert?

ehk wrote:
> Ergo ist die Auslastung der Slices zu vergessen und
> dafür das Maximum von LUT oder FF-Auslastung zu nehmen... Die BMW-Spec
> stammt noch aus Zeiten, in denen die Slice-Auslastung das maßgebliche
> war. Man lernt halt nie aus....  Also Du kannst wohl doch von 74%
> ausgehen.

Das ist mal eine Ansage, danke!
Die Auslastung wäre dann beim mit "area optimized" mit "effort high" 
implementierten Design bei 66% nach deiner Interpretation.

Ich muss aber wohl davon ausgehen, dass ich das FPGA nur bis ca. 75% 
füllen kann, denn bei diesem Versuch (siehe Anhang) mit Zusatzlogik 
schaffte es der Mapper nicht (wohl wegen "number of occupied slices" = 
103%). Allerdings wurde diese Variante mit "speed optimized" 
synthetisiert.

Dann gehe ich bis auf weiteres davon aus, dass ich noch "Reserven" habe, 
wenn die "Total Number of 4 input LUTs" noch unter 75% liegt. Ist das 
wohl ein einigermassen sinnvoller Kennwert?

Oder eher so? Wenn beide Werte "number of slice FFs" und "number of 4 
input LUTs" kleiner als 75% sind, dann habe ich noch "Luft".

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.