mikrocontroller.net

Forum: FPGA, VHDL & Co. Schaltung passt nicht in CPLD


Autor: Daniel Governatori (duese7)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Christoph Kessler (db1uq) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Daniel Governatori (duese7)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Daniel Governatori (duese7)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Diesbezüglich gleich eine weitere Frage:

Kann man ein STD_LOGIC_VECTOR Array von einer entity in die nächste 
übergeben?

Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Daniel Governatori (duese7)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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


Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Schlumpf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schau mal, ob du zwingend addon_data als Register brauchst.
Eventuell kansnt du den Ausgang auch kombinatorisch bilden.

Autor: Daniel Governatori (duese7)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Schlumpf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Schlumpf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Daniel Governatori (duese7)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Daniel Governatori (duese7)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lies mal die Synthese Reports sowie Fitter Reports, dort steht drin was 
rausoptimiert wurde.

MfG
Falk

Autor: Daniel Governatori (duese7)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Klaus Falser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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


Autor: Uwe Bonnes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
XC95144 oder XC95144XL?
Die XL hat breitere Makrozellen, in die passt mehr Logik rein. XL ist 5 
Volt tolerant, braucht aber 3.3V Versorgung.

Autor: Daniel Governatori (duese7)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Daniel Governatori (duese7)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
                               ;-)

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.