Hallo Ihrs, ich bin seit einiger Zeit am Programmieren einer DAC/ADC Anwendung. Um die ei- und ausgehenden Daten zu verarbeiten benutze ich einen Xilinx XC95144 - wegen der Bauform der größte zu verwendende Baustein. Das Problem: Zwei Anwendungen müssen in einen Chip. 1. Daten vom Bus runter und in den DAC 2. Daten vom ADC rauf auf den Bus Beide Anwendungen jeweils einzeln passen in den Chip, die ADC Anwendung verbraucht "nur" 30% der Makrozellen. Zur Zeit der Dimensionierung war das meine einzige Information, also wählte ich den o.g. Chip aus. Nun kommt die DAC Anwendung daher und füllt zur Hälfte (16 Bit Daten anstatt 32 bit) den Chip schon zu 96% aus. Schönen Dank! Gibt es etwas, was ich tun kann? Layout der Leiterplatte und Pinbelegung sind festgelegt, da die Leiterplatte bereits gefertigt ist. Ich vermute, es liegt an dem Datenbus. Bei dem Versuch mit 32 bit zu arbeiten, wollte der Fitting Prozess 164 Makrozellen belegen (16 bit -> 137 mc). Ich möchte ungern ein neues Layout mit einem anderen Chip (FPGA) erstellen müssen, da die Folgeänderungen sehr umfangreich wären. Gruß Daniel
@Daniel Governatori > 1. Daten vom Bus runter und in den DAC > 2. Daten vom ADC rauf auf den Bus Das klingt je erstmal nicht allzu viel, eigentlich nur ein Tristate-Treiber. > Beide Anwendungen jeweils einzeln passen in den Chip, die ADC Anwendung > verbraucht "nur" 30% der Makrozellen. > füllt zur Hälfte (16 Bit Daten anstatt 32 bit) den Chip schon zu 96% > aus. Naja, Adam Riese würde sagen, dass 30% + 96% = 126% sind. Und da das grösser als 100% ist, wirds eng. ;-) >Gibt es etwas, was ich tun kann? Layout der Leiterplatte und Pinbelegung Beten. Es besteht die vaage Hoffnung, durch Synergieeffekte das VIELLICHT doch noch reinzukriegen, indem sich bestimmte Schaltungsteile Funktionalität teilen. Das macht die Schaltung zwar langsamer, dafür aber ressourcenschonender. 1.) Sourcecode anschauen 2.) Mit den Fitter Einstellungen experimentieren. Speed/Area Optimierung etc. > arbeiten, wollte der Fitting Prozess 164 Makrozellen belegen (16 bit -> > 137 mc). Naja, ist ja nicht sooovielo mehr Zeig mal deinen Sourcecode. MFG Falk
Murphy's Gesetz für Angler: Um die Würmer wieder zurück in die Dose zu bekommen, hilft nur eine größere Dose. Erst mal die Pin-Zuordnung abschalten, dann hat der Fitter mehr Freiheiten. Wenn es dann immer noch nicht klappt gehts vermutlich wirklich nicht rein.
Anbei der Sourcecode. Ist ein wenig gestückelt. Ich habe mich mit den Möglichkeiten der Programmierumgebung noch nicht so vertraut gemacht und muss ehrlich gestehen, nicht zu wissen, wie und wo ich was einstellen kann. Ich mach mich mal auf die Suche. Was das "Naja, ist ja nicht sooovielo mehr" angeht, das soll nur die Basis für die weitere Entwicklungen sein.
Diesbezüglich gleich eine weitere Frage: Kann man ein STD_LOGIC_VECTOR Array von einer entity in die nächste übergeben?
@Daniel Governatori > Was das "Naja, ist ja nicht sooovielo mehr" angeht, das soll nur die > Basis für die weitere Entwicklungen sein. Naja, DAS kannst du glaub ich vergessen. Mit Müh und Not bekommt man das Design in den CPLD, aber Luft für weitere Entwicklungen ist da nicht. Wo ich im Moment auf die Schnelle Optimierungspotential sehe ist dein DAC_CTRL. Im Toplevel speicherst du 16 bit data0_dac und übergibst die später an dac_ctrl, welche daraus ein 24 bit Rgister baut und seriell an den DAC ausgibt. Da data1_dac .. data3_dac ungenutzt sind, kann man den MUX rauswerfen, ausserdem sollte man die daten die erst in data0_dac gespeichert werden direkt in dac_input unterbringen. Das spart min. 16 Macrozellen, und da der Fitter sagt er braucht 160 (von 144 verfügbaren) sollte es damit geradeso passen. > Kann man ein STD_LOGIC_VECTOR Array von einer entity in die nächste > übergeben? Wenn diese in einem Package definert sind und das Package mi USE eingebunden ist. MfG Fak
data1 - data4 sind deshalb nicht mit drin, weils nicht passt. Werden die Signale, wenn sie unverändert weitergegeben werden, nicht vom Synthese tool auf ein Signal optimiert? So zumindest verstehe ich manche Meldung. Wenn nicht: Wieder was gelernt. Die Übergabe an das 24 bit Register macht aber die serielle Ausgabe sehr schlank und übersichtlich. Wenn ich das Register direkt ausgeben will, muss ich die Übertragung wieder anders ansteuern, was durch Zähler usw. mit Sicherheit auch wieder einiges an MC kostet. Daniel
@Daniel Governatori > Werden die Signale, wenn sie unverändert weitergegeben werden, nicht vom > Synthese tool auf ein Signal optimiert? So zumindest verstehe ich manche Ja. > Die Übergabe an das 24 bit Register macht aber die serielle Ausgabe sehr > schlank und übersichtlich. Wenn ich das Register direkt ausgeben will, Ja, aber es passt nicht rein. > muss ich die Übertragung wieder anders ansteuern, was durch Zähler usw. > mit Sicherheit auch wieder einiges an MC kostet. Auch ja. ;-) Nun wie es scheint wirst du das Ding nur abgespeckt zum Laufen bringen, damit kannst du erste Tests machen. Dann muss irgendwann ne Revision B her, grösserer CPLD + neues Layout. MFG Falk
Schau mal, ob du zwingend addon_data als Register brauchst. Eventuell kansnt du den Ausgang auch kombinatorisch bilden.
Schlumpf wrote: > Schau mal, ob du zwingend addon_data als Register brauchst. > Eventuell kansnt du den Ausgang auch kombinatorisch bilden. Den brauche ich nicht zwingend als Register. Es erschien mir lediglich einfacher. Was meinst Du mit kombinatorisch?
Na ja, dass du eben die internen Daten auf die Ports über einen Multiplexer gibst, ohne sie vorher noch einmal über ein Register zu führen. Ich hab gerade dein Design mal synthetisiert (edif) und hab nur 77% Auslastung.
Ausserdem stell ich gerade fest, dass deine sensitivity-listen nicht vollständig sind. Das kann auch zu komischen syntheseergebnissen führen (je nach tool, das du verwendest)
Ich verwende das ISE WebPack von Xilinx(ISE). Ich habe die Sensitivity Listen aufgefüllt und das ändert an der Zahl der benötigten Zellen nichts. Ich habe ebenfalls in den entities versucht die Register weitestgehend zu eliminieren, bis auf nur eines - ohne MUX, ohne alles - brachte lediglich zwei / drei MCs Ersparnis. Kaum binde ich die addon_data komplett ein - als einzige Änderungen, benötigt das WebPack ~40 MC mehr. An der reinen Anzahl der Register, die ich verwende, kann es eigentlich nicht liegen. Durch das Aufteilen des Eingangs in zwei mal 16 bit, passt das Design in den Chip, füllt ihn aber zu 97%. Ehrlich gesagt, aus dem Bauch heraus (was sicher nichts ist, worauf man zählen sollte, aber) muss doch ein 32 bit Eingang mit "ein wenig" serieller Ein- und Ausgabe ohne Probleme in einen Chip mit 144 MCs passen, oder trügt das Gefühl so sehr??? Daniel
@Daniel Governatori > Ich verwende das ISE WebPack von Xilinx(ISE). Ich habe die Sensitivity > Listen aufgefüllt und das ändert an der Zahl der benötigten Zellen ISE ist das egal, es gibt ne Warnung aus und macht aber dennoch das Richtig. ABER VORSICHT! Die Simulation mit Modelsim stimmt dann nicht! > Ehrlich gesagt, aus dem Bauch heraus (was sicher nichts ist, worauf man > zählen sollte, aber) muss doch ein 32 bit Eingang mit "ein wenig" > serieller Ein- und Ausgabe ohne Probleme in einen Chip mit 144 MCs > passen, oder trügt das Gefühl so sehr??? Wie es scheint, trügt das Gefühl. Jedes FlipFlop braucht eine Macrozelle. Wenn eine Macrozelle al Eingang verwendet wird, ist das FlipFlop sowie der Decoder "unbrauchbar", schau dir die Detail der Macrozellen an. Du hast in deinem CTRL Modul ein paar Zähler, die summieren sich. MFG Falk
Ich weiß, wahrscheinlich nervt es jetzt. Ich habe das gleiche top file mit dem jetzt auskommentierten AD Wandler verwendet. Der funktionierte noch nicht so richtig, in den Grundzügen aber schon. Da meldete mir er Fitter Report (Festhalten!!!): 49 MC Aus diesem Grund bin ich davon ausgegangen, dass eine weitere Anwendung, die vom Prinzip das gleiche macht, ebenfalls passen muss, vor allem weil sie auf dasselbe top file aufsetzt, sprich an dem großen Register ändert sich prinzipiell nichts. Ich kann mich nicht mit allzu Wissen über CPLDs, Digitaltechnik oder Elektronik brüsken, doch bisher dachte ich, dass es dafür reicht. Ein reichlich frustrierter Daniel
Lies mal die Synthese Reports sowie Fitter Reports, dort steht drin was rausoptimiert wurde. MfG Falk
Von den addon_data in beiden Fällen keine addon_ctl in beiden Fällen fast alle, Mit ADC alle DAC Signale weil die entity ohne Funktion ist. Ich finde das Verhältnis etwas seltsam. Der mehr oder weniger identische Quelltext verlangt in dem einen Fall 50 MCs in dem anderen Fall < 160 MCs. Eine Differenz von 10, vielleicht auch 20, kann ich nachvollziehen, aber 110!?! Was kann denn die Ursache für so etwas sein? Kann man sich das "Layout" innerhalb des Chips irgendwie ansehen? Hat man bei einem CPLD evtl. Einfluss darauf? Wenn ja, wie? Gibt es empfehlenswerte (verständliche!) Literatur über dieses Thema? Daniel
Mir kommt vor, Du hast viel zu viele verschiedene Takte in deinem CPLD und die Ausdrücke im Reset Pfad sind viel zu kompliziert. Versuch das Ganze so umzubauen, daß daß alle getakteten Prozesse so ähnlich ausschauen : process(clk, reset) begin if (reset = '1') then <einfache Zuweisungen, kein case und möglichst keine weiteren if's> elsif rising_edge(clk) then <hier die funktion, if's und case > end if; end process: Auch die Lesen und Schreiben des Busses sollte man trennen -- Einlesen process(clk) begin if rising_edge(clk) then if rdfifo = '0' then data0_dac <= addon_data(15 downto 0); end if; end if; end process; -- Schreiben process(clk) begin if rising_edge(clk) then if wrfifo = '0' then addon_data_int(15 downto 0) <= data0_dac; end if; end if; end process; addon_data <= addon_data_int when wrfifo = '0' else (others => 'Z'); So wie Du es geschrieben hast, klingt es zwar logisch, entspricht aber nicht der Hardware. Grüße Klaus
XC95144 oder XC95144XL? Die XL hat breitere Makrozellen, in die passt mehr Logik rein. XL ist 5 Volt tolerant, braucht aber 3.3V Versorgung.
Vielen Dank für Eure Hilfe. Das Design ist so weit "geschrumpft", dass es in den Chip passt. Für die ersten Tests an dem System sollte es reichen, danach muss dann halt die nächste Entwicklungsstufe ran. Ärgerlich, aber nicht mehr zu ändern. Hoffentlich wird dann alles besser. Nochmals vielen Dank. Daniel
Nochmal ein kleiner Nachtrag für alle, die es interessiert.
Ich habe bei der DAC Ansteuerung die verschiedenen Kanäle in einem Array
vereint. Dadurch habe ich 35! MCs eingespart, so dass jetzt beide
Anwendungen in den Chip passen. (Es ist sogar noch ein wenig Platz für
mehr.)
Ich bin mit vollem Umfang der Anwendung bei 79% Auslastung des Chips.
Nochmals vielen Dank für die Hilfe und die Anregungen, die
schlussendlich zur Lösung geführt haben.
Gruß (des nicht mehr ganz so frustierten)
Daniel
;-)
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.