mikrocontroller.net

Forum: FPGA, VHDL & Co. Xilinx FPGA Power - MMCM


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Gustl B. (-gb-)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe mir jetzt mal den Power Report angeguckt weil mein Spartan7 
etwas warm wird bin doch recht überrascht davon, dass die beiden (2 von 
5) MMCM mit 67% den Großteil ausmachen.
Ja, das FPGA ist recht leer aber es werden z. B. auch sehr viele IOs 
verwendet, da hätte ich erwartet, dass die IOs deutlich mehr brauchen 
als die MMCMs.

Jetzt verwende ich aktuell 2 MMCMs, und jedes davon erzeugt mir 2 oder 3 
Takte, ist also noch lange nicht am Limit, die können 7 Takte ausgeben.

Ist es sinnvoll seine Takte mit möglichst wenig MMCMs zu erzeugen oder 
hat das Nachteile?

von Hannes (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Weniger MMCMs => Weniger Strom.
Der Nachteil, wenn eine MMCM mehrere Takte machen muss, ist natuerlich, 
dass du nur eine VCO-Frequenz hast, die du fuer die Ausgaenge 
runterteilen musst. Das heisst, wenn deine Frequenzen `schoen' sind 
(z.B. 20, 50, 100, 150 MHz), dann kann der VCO zum Beispiel auf 600, 900 
oder 1200MHz laufen, und alle Zielfrequenzen glatt treffen.

Wenn jetzt eine krumme dabei sein soll (z.B. 25.175MHz), musst du dich 
ziemlich anstrengen, um die ueberhaupt zu treffen. Damit wird der VCO 
normalerweise krumm und schief, sodass anderen Ausgaenge ebenfalls 
schief werden. Dann kannst du primaer nachdenken, bei welchen Frequenzen 
du gut treffen willst (200MHz Refclk fuer IDelay), und bei welchen es 
dir eigentlich eher egal ist (Prozessor bei 96.3 MHz statt 100? Merkt 
mann nicht).

Theoretisch gibt's noch Einfluesse bezueglich Clock Jitter und Noise, 
aber ich glaube, hier geht's eher um Grundlagen. Da sind die 
wahrscheinlich noch nicht ganz so wichtig.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Gustl B. schrieb:
> ich habe mir jetzt mal den Power Report angeguckt weil mein Spartan7
> etwas warm wird bin doch recht überrascht davon, dass die beiden (2 von
> 5) MMCM mit 67% den Großteil ausmachen.

Wenn dein Design mal etwas macht, dann sind die 0.2 W vernachlaessigbar 
wenig.

von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
Ja, das stimmt. Bisher verbindet es eigentlich nur die ICs, nimmt Daten 
entgegen und gibt sie wieder aus, bedient ADC und DAC aber gerechnet 
wird fast nicht.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Wie hast du ueberhaupt den Power Analyzer gefuettert? Nomalerweise 
erstellt man aus einer Simulation heraus ein "Switching Activity File" 
damit der PA die durchschnittliche Togglerate der einzelnen Elemente 
kennt.

Wenn da natuerlich ueberall nix eingetragen ist, dann passiert auch 
entsprechend wenig. Am besten mal UG907 durcharbeiten.

von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
Gar nicht. Habe da nur mal aus Interesse draufgeklickt. Aber ich gucke 
mir das jetzt mal genauer an ...

von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
So, ich lasse das gerade simulieren für das saif File. Aber das macht ja 
vermutlich keinen Sinn da nur die ersten paar ns zu simulieren weil da 
alle ICs und FPGA Komponenten noch im Init rumhängen. Das RAM z. B. 
braucht 150 us bis es bereit ist. Sprich ich will schon solange 
simulieren bis das ganz normal "rumwerkelt" aber das dauert irre lang. 
Ist das denn vom Prinzip her richtig was ich mache oder genügen die 
ersten paar ns?

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Du brauchst halt die Informationen mit welcher Rate und mit welcher 
Wahrscheinlichkeit die einzelnen Teile togglen. Je laenger du simulierst 
desto verlaesslicher ist der Mittelwert.

Wenn dir das zulange gehet, kannst auch einfach in die Felder manuell 
eintragen was fuer eine Rate du erwartest.

Wie gesagt, einfach mal den User Guide durcharbeiten, dann sollte das 
ganze klar werden.

von Gustl B. (-gb-)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So, hat lange gedauert. Für 350 us über 1 Stunde und das .saif ist jetzt 
ca. 12 GByte fett. Aber: Das war der schnelle Teil. Wenn ich länger 
simuliere bis der HyperRAM aktiv ist und dort geschrieben wird, dann 
wird es unfassbar viel langsamer. So im Bereich mehrere Minuten je ns 
Simulation.

Ohne diese .saif Erzeugung läuft die Simulation übrigens sehr schnell. 
In unter einer Minute sind da die ersten paar ms simuliert. Aber bei der 
großen saif Datei war auch der RAM voll.

Egal, jetzt sieht es jedenfalls etwas anders aus. Wie vermutet brauchen 
die IOs auch ordentlich - und da ist jetzt der HyperRAM noch nicht mit 
dabei.

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.

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