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
Vielleicht kann man im Code nochwas optimieren, zeig den am besten mal her.
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.
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
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.
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
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
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.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.