Forum: FPGA, VHDL & Co. "Tricks" für platzsparendes Design


von Christian P. (kron)


Lesenswert?

Hallo,

ich muss ein Design in einen Spartan XL S05 quetschen
(mit Foundation 4.1), und bekomme bei der Implementation die Design 
Summary:
-----------------
Design Summary:
   Number of errors:        1
   Number of warnings:      1
   Number of CLBs:            123 out of   100  123%
      CLB Flip Flops:     194
      CLB Latches:          0
      4 input LUTs:        89
      3 input LUTs:        49 (43 used as route-throughs)
   Number of bonded IOBs:      72 out of    77   93%
      IOB Flops:           27
      IOB Latches:          0
   Number of clock IOB pads:    2 out of     8   25%
   Number of TBUFs:            64 out of   240   26%
   Number of BUFGLSs:           6 out of     8   75%
   40 unrelated functions packed into 31 CLBs.
   (25% of the CLBs used are affected.)
Total equivalent gate count for design: 2163
Additional JTAG gate count for IOBs:    3456
-------------------

Das Design scheint also einfach zu groß für den Chip zu sein.
Es handelt sich bei dem Design ursprünglich um Schematics, die
in VHDL umgeschrieben wurden. Über Schematics passt das Design
gerade so auf den Spartan XL.

Meine Frage ist nun, ob ich an diesem Wert (123 CLBs) mit
irgendwelchen "Tricks" noch drehen kann.
Ich bin den Code schon mehrmals sorgfältig durchgegangen,
er sollte mittlerweile wirklich halbwegs optimal sein.
Bei dem Foundation-Programm habe ich alle (eher wenigen)
Optimierungsoptionen durchprobiert, die 123 sind da schon das Beste.

Hat jemand irgendwelche Tipps, was ich evtl. noch probieren könnte?

von Rick Dangerus (Gast)


Lesenswert?

Selbst wenn Du 99% Auslastung schaffst kann es sein, daß er es nicht 
mehr routen kann.

Hast Du die schematics-Version noch vorliegen? Wenn ja, könntest Du 
vergleichen, welches Element wieviel Platz braucht (vorher/nachher).

Meldet sich der HDL-Advisor mit Informationen?

Hat der Spartan XL Blockram? Lassen sich evtl. Funktionen dorthin 
mappen?

Rick

von Spartanne (Gast)


Lesenswert?

Ohne Code kann man nur vermuten. Benutzt du einen asynchronen Reset?? 
Wenn ja, versuche den mal synchron zu machen. Damit kann u.U. viel an 
Reset-Logik eingespart werden.
Kenne mich aber mit der XL-Serie nicht so gut aus...

von fpgakuechle (Gast)


Lesenswert?

das Problem sind die FF an sich, da hilft auch kein synchron/asynchron 
da das nur LUT spart. Du kannst statt den CLB -FF versuchen die IOB FF 
zu nutzen. Der XL hat IMHO distributed RAM (LUT als Speicherelemente), 
da könnte man was machen (FF Register mit distr. RAM aufbauen). Dann 
müsste er auch SRL16 (16bit schieberegister kennen. Das ersetzt 
FF-Ketten durch eine LUT. Den XST kann man dazu bringen das er srl16 
automatsich nutzt. Wechsel der ISE-Version kann was bringen, die 7.1 
galt als Ressourcenverschleuder (im Vgl. zu 6.3 und 8.1).

Der synthesereport kann noch hilfreich sein *.syr. Falls du nicht den 
gesamten veröffentliche willst, dann die ersten Zeilen mit den 
eingestellten Oprionen, das selbe gilt für map und par. Verrät uns die 
gesetzten Optionen und wir können (vielleicht) weiterhelfen

von Falk (Gast)


Lesenswert?

@Rick Dangerus

>Selbst wenn Du 99% Auslastung schaffst kann es sein, daß er es nicht
>mehr routen kann.

So weit isser noch lange nicht. Und dann kann man noch (blockweise) per 
Hand plaziren. Hab ichmal vor Jahren durchexerziert, ein Scheissjob, 
aber am Ende hat das Design reingepasst.

>Hat der Spartan XL Blockram? Lassen sich evtl. Funktionen dorthin

Nein.

@fpgakuechle

>das Problem sind die FF an sich, da hilft auch kein synchron/asynchron
>da das nur LUT spart. Du kannst statt den CLB -FF versuchen die IOB FF

Naja, 100 CLBs sind 200 FFs. Plus die in den IOs. Knapp aber könnte 
passen, wenn XST sich nicht so zickig und highspeedsüchtig benehmen 
würde.

>müsste er auch SRL16 (16bit schieberegister kennen. Das ersetzt

nee, das gibts erst in Spartan-II.

>automatsich nutzt. Wechsel der ISE-Version kann was bringen, die 7.1
>galt als Ressourcenverschleuder (im Vgl. zu 6.3 und 8.1).

Er nutzt 4.1, die war IIRC recht gut.

@Christian Peters

>ich muss ein Design in einen Spartan XL S05 quetschen
>(mit Foundation 4.1), und bekomme bei der Implementation die Design

>   Number of CLBs:            123 out of   100  123%
>      CLB Flip Flops:     194
>      CLB Latches:          0
>      4 input LUTs:        89
>     3 input LUTs:        49 (43 used as route-throughs)

Die 43 route-through sind so eine Macke von XST, der will immer alles 
auf maximalen Takt trimmen.

Als erstes musst du die Synthese-Properties prüfen.

Keep Hierachy - OFF (kein Haken)
Equivalent Register removal - ON (Haken)
Register Duplication - OFF (kein Haken)
Slice Packing - ON (Haken)

Mit den anderen Parametern kann und muss man auch noch ein wenig 
experimentieren.

Wenn das alles nicht reicht, kannst du dir die Demoversion von Synplify 
besorgen und es damit synthetisieren. Damit hab ich mal ein Design in 
einen 50er Spartan-II gequetscht, wofür XST zu dämlich war ;-)

MfG
Falk

von fpgakuechle (Gast)


Lesenswert?

Die statemachienecodierung auf binary setzen.

von fpgakuechle (Gast)


Lesenswert?

BLockRAM hat er nicht ab distributed: 1LUT = 16x1bit, also etwa 16 FF 
Wobei natürlich steuerloguk ninhzukommt und nicht jede FF-Struktur ist 
durch ein RAM feld zu ersetzen.

von FPGA-Küchle (Gast)


Lesenswert?

Du kannst das design kompakter integrieren, in dem Du compressed logik 
nimmst: Normalerweise wird in einem CLB nur dann das FF und die Lut 
benutzt wenn beide über ein Signal verbunden sind. Compressed Logik 
nutzt aber auch dann beispielsweise die LUT, wen dessen Ausgang an den 
Eingeng an ein FF eines anderen CLB führt. Ohne compressed Logic, würde 
die LUT in dem CLB des FF nicht genutzt. Laut report nutzt Du dieses 
Feature schon, aber möglicherweise nur teilweise. Bei compressed Logik 
gibt man an, wieviel Prozent  des Designs auf dieses Weise kompaktiert 
wird. Die Zeile

40 unrelated functions packed into 31 CLBs.
   (25% of the CLBs used are affected.)

aus Deinem report kann bedeuten, das compressed Logik auf 25 % des FPGAs 
beschränkt wurde, aber auch das nur 25 % kompaktierbar waren. Das ist 
eine Option im MAP-prozess in der Commandozeile -c Packfaktor:

in meinem Makefile sieht der Kommentar so aus:
#pack CLBS (unreleated logic) 0|100: no pack -easy place and Route; 1: 
max pack -> low area, difficult placeroute
MAP_OPTS  := $(MAP_OPTS) -c 1

Schau mal wie du in Foundation diese Option änderst, dann könnte dein 
design kleiner werden bei gleichbleibender Anzahl der FF.


Falls ich mal über dein Design schauen soll oder es mit neueren Tools 
versuchen darf, kannst Du mir eine Email schicken:

http://www.mikrocontroller.net/articles/Spezial:Emailuser/FPGAk%C3%BCchle


Manche haben halt Spass dran das letzte aus einem design raus zu 
kitzeln.

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.