Forum: FPGA, VHDL & Co. Programm zu groß für CPLD


von Christian H. (cavorca)


Lesenswert?

Hallo,

Ich hatte einen Code der gut funktioniert hat. Dann bin ich auf die Idee 
gekommen, dass ich noch zwei Funktionen hinzufügen könnte. Bei der 
Ersten hat das noch geklappt, nach der Zweiten lief der FIT nicht mehr. 
Jetzt kommt die Meldung:
ERROR:Cpld:837 - Insufficient number of macrocells. The design needs at 
least 73 but only 72 left after allocating other resources.
Device 9572XL64 was disqualified.
ERROR:Cpld:868 - Cannot fit the design into any of the specified devices 
with the selected implementation options.


Bei den Fitting-Optionen habe ich schon alles was es gab auf Optimize 
Density gestellt was ging. Gibt es noch andere Möglichkeiten?

Das Programm soll in einen XC9572XL und ist eine Zustandsmaschine mit 10 
Zuständen. Die Funktion die ich hinzufügen wollte ist, dass ein Pin High 
ist, wenn die Maschine sich in einem von zwei bestimmten Zuständen 
befindet.
Versucht habe ich bisher (in der Hoffnung, dass doch eine Möglichkeit 
funktionert):

- Kombinatorisch:assign ausgabe=zustand==6 || zustand==7
- in jedem zustand in einem Register den richtigen Wert speichern
- ein Bit des Zustandregisters an den Ausgang geben

Natürlich könnte ich mich nach einer größeren CPLD umsehen. Wenn ich 
mich aber erinnere, was es für ein Aufwand war die CPLD zu bekommen die 
ich jetzt habe denke ich mir ehr, dass ich lieber auf die Funktion 
verzichte.

Kann ich vielleicht beim Fit noch was optimieren? Notfalls kann ich auf 
die Funktion auch verzichten. Wäre nur halt mit schöner...

Viele Grüße
Christian

von na (Gast)


Lesenswert?

Vielleicht kann man im Code nochwas optimieren, zeig den am besten mal 
her.

von Mark (Gast)


Lesenswert?

Hi Christian,

Du musst zunächst mal sicherstellen, dass die Anzahl der benötigten 
Flip-Flops nicht größer ist als die Zahl der Macrozellen.
Wenn das gegeben ist, hast Du noch eine reelle Chance die Sachen 
reinzuquetschen.
Beim CPLD-Fit gibt es viele Optionen.
Hast Du schon mal -exhaust ausprobiert?
Welchen Wert hast Du für -pterms gesetzt ?
Schau mal in die Anleitungen / XAPPs usw., da findet sich bestimmt noch 
mehr.

von Joerg W. (joergwolfram)


Lesenswert?

Wenn die Anzahl der benutzten pterms (Fitter-Report der funktionierenden 
Version) kleiner als 70% ist, kann man auch versuchen, nach Speed zu 
optimieren. Dabei steigt dann meist die pterm-Auslastung stark an und 
die Anzahl der benutzten Makrozellen geht oft zurück.

Gruß Jörg

von Christoph db1uq K. (christoph_kessler)


Lesenswert?

Die 4 Bit der Zustandsmaschine so wählen, dass sie gleich als Ausgänge 
dienen können. Das kann bis zu vier Makrozellen sparen. Der Fitter hat 
hoffentlich kein "one-hot-encoding" synthetisiert? Das wären dann 10 
statt 4 Makrozellen für die statemachine verschwendet.

von Christian H. (cavorca)


Lesenswert?

Hallo,


Zur Zeit sieht es von der Nutzung her bei mir so aus:

Macrocells Used Pterms Used Registers Used Pins Used Function Block 
Inputs Used
68/72  (95%) 317/360  (89%) 66/72  (92%) 49/52  (95%) 144/216  (67%)
 Also noch genügend Register frei.

-exhaust teste ich grade. Bisher kann ich nur sagen, dass der Fit dann 
extrem lange braucht. Sehe auch grade da kommen einige Meldungen in der 
Console. Wird der irgendwann auch fertig? Oder probiert der immer 
weiter? Mittlerweile läuft es sicher eine halbe Stunde.

Der Wert für pterms steht auf der Standardeinstellung (Kann ich grade 
nicht nachgucken, weil der Fit läuft). Momentan steht die Optimierung 
auf Speed, stand sie auch vorher, hatte nur probeweise mal auf density.

Mit "- ein Bit des Zustandregisters an den Ausgang geben" meinte ich, 
dass ich das eine relevante Bit der Zustandsmaschine direkt an einen 
Output Pin gebe, aber selbst das passt angeblich nicht mehr rein.
der Befehl dazu ist:

assign trigger_warte=state[0:0];

Das weitere Problem dabei wäre, dass beim Synthetisieren die Zahlen 
durch Grey-Code ausgedrückt werden und ich nicht weiß ob es ein Bit 
gibt, dass ich dann einfach so ausgeben kann.

Als nächstes probiere ich den Code zu optimieren. Falls es nicht klappt 
poste ich den Code mal.

Dazu direkt eine Frage:
Ich habe einige Variablen, bei denen es in einigen Zuständen eigentlich 
egal ist ob ich im kombinatorischen Teil

next_wert=0;

oder

next_wert=wert;

sage. Ich könnte mir vorstellen, dass es Resourcen spart, wenn ich die 
erste Version komplett aus allen Zuständen streiche. Ist das richtig?

Vielleicht sollte man mal einen Thread eröffnen mit Richtlinien für 
Codeoptimierung. Vorher suche ich zur Sicherheit mal lieber ob es so 
einen Thread nicht schon gibt ;-)

Viele Grüße,
Christian

von Christian H. (cavorca)


Lesenswert?

Meine Idee war scheinbar richtig. Jetzt passt es. Ich hoffe nur jetzt 
macht das Ding auch noch alles was es machen soll ;-)

Also jetzt habe ich daraus gelernt:

eine Reset-Zuweisung nur im Reset Teil der sequentiellen Logik 
verwenden. Im Kombinatorischen Teil möglichst darauf verzichten.
Als Beispiel: Möglichst nur im sequentiellen Teil
if (reset) wert<=0;
und im Kombinatorischen besser nicht
next_wert=0;
sofern möglich.

Ist das so richtig?

Vielen Dank für alle Tipps und alle Beiträge!

Viele Grüße,
Christian

von Mark (Gast)


Lesenswert?

Hi Christian,

aus der Beschreibung entnehme ich, dass Du eine FSM in Register und
Kombinatorik geteilt hast. Wenn Du natürlich ohne Not immer 0 zuweist
wird das vermutlich Logik kosten.
Ich bevorzuge die FSM mit Registern und Kombinatorik in einem Stück und
versuche jede unnötige Signalzuweisung zu vermeiden.
Vielleicht kannst Du ja nochmal einen Auszug mit kritischen Teilen 
posten,
damit man den Unterschied versteht.
Ansonsten glaube ich nicht, dass hier viel Interesse besteht die letzten
Macrozellen auszuquetschen, da die meisten offenbar mit FPGAs arbeiten
und den CPLDs im Allgemeinen nicht viel zugetraut wird.
Leider sind CPLDs mit > 72 MCs in handhabbaren Gehäusen eh schwer zu 
kriegen
bzw. teuer.
Und die meisten Frager hier sind schon kaum in der Lage, vernünftiges 
VHDL zu schreiben, von Ressourcen-sparendem Code ganz abgesehen - sorry.

von Christian H. (cavorca)


Lesenswert?

Mark wrote:
> Hi Christian,
>
> aus der Beschreibung entnehme ich, dass Du eine FSM in Register und
> Kombinatorik geteilt hast. Wenn Du natürlich ohne Not immer 0 zuweist
> wird das vermutlich Logik kosten.
> Ich bevorzuge die FSM mit Registern und Kombinatorik in einem Stück und
> versuche jede unnötige Signalzuweisung zu vermeiden.
> Vielleicht kannst Du ja nochmal einen Auszug mit kritischen Teilen
> posten,
> damit man den Unterschied versteht.
Das hast Du schon richtig verstanden. Damals habe ich mir darüber keine 
Gedanken gemacht. Es war mit eins meiner ersten größeren Projekte mit 
CPLD.

> Ansonsten glaube ich nicht, dass hier viel Interesse besteht die letzten
> Macrozellen auszuquetschen, da die meisten offenbar mit FPGAs arbeiten
> und den CPLDs im Allgemeinen nicht viel zugetraut wird.
> Leider sind CPLDs mit > 72 MCs in handhabbaren Gehäusen eh schwer zu
> kriegen
> bzw. teuer.

OK, ich denke aber auch dass es noch andere Gründe gibt aus denen man 
versucht sein sollte optimalen Code zu schreiben z.B.:
Geschwindigkeit
Stromverbrauch (?)
Stabilität (?)

Ich denke auch, wenn man weiß wie man effizienten Code schreibt lernt 
man besser CPLDs und FPGAs zu verstehen und kann Probleme lösen, die man 
ohne dieses wissen nicht lösen könnte. Zumindest nicht so gut.

Sowieso halte ich es generell für besser zu Wissen was man tut.

> Und die meisten Frager hier sind schon kaum in der Lage, vernünftiges
> VHDL zu schreiben, von Ressourcen-sparendem Code ganz abgesehen - sorry.
Was meinst du damit? Falls du mich meinst: Ich weiß dass ich noch das 
ein oder andere zu lernen habe, aber deshalb frage ich ja.
Falls du das Forum insgesamt meinst: Ich denke schon, dass es hier 
einige Leute mit viel know-how gibt.

Viele Grüße,
Christian

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.