mikrocontroller.net

Forum: FPGA, VHDL & Co. RAM-Bits im FPGA effektiv nutzen


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.
Autor: Michl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meine Frage dreht sich um die maximale Datenrate, die ich mit einem FPGA 
speichern kann, um einen Sacnner für schnelle Daten zu haben. 
Gespeichert werden Prozessorzugriffe mit ADR+DAT+STROBES = 44 Bits. Der 
Prozessor arbeitet mit 156.25 MHz.

Wieviele Zugriffe kann ich speichern (angenommen der FPGA ist schnell 
genug, wovon ich ausgehe)?

Aus dem Artix Family Sheet ersehe ich für den 200er Chip 720 RAMs, 
welche "16Kb" haben. In der 32Kb-Spalte stehen die Hälfte. Ich weiß, 
dass das alternativ ist, weil die Bitszahl konstant ist. Wozu die Angabe 
dient, ist mir nicht klar. Sicher kann ich auch 64Kb verdrahten und habe 
1/4?

Wenn ich das "distributed RAM" zur Seite lasse, erhalte ich 16384 x 720 
= 11Mbit. Oder sind es 16000? Oder sind es 18Bit-RAMs?

Egal, da ich ganzzahlig denke, teile ich durch 3 RAMs = 48Bit und 
bekomme: 240ksamples. Kommt das hin oder ist da ein Fehler?

Bei der Taktrate sehe ich also nur 1,5ms, auch wenn ich die Bits gut 
zusammenpacke.

Gibt es eine Möglichkeit, das ohne externes RAM zu steigern? Ich denke 
über eine Kompression nach. Geplant ist momentan nur, im Fall geänderter 
Bits überhaupt etwas zu speichern. Dann verlöhre ich nur noch etwas für 
einen Zeitstempel. Z.B. brauche ich dann 64Bit.

Welche weiteren Ideen sind denkbar?

Ich kann z.B. nicht so recht nachvollziehen, woher die hohe 
Rechenleistung bei FPGAs kommt, wenn man nicht soviel speichern kann. 
Wird das alles in den LUT-Zellen gespeichert? Wieviel habe ich da?

Gibt es da noch einen Trick, den ich übersehen habe?

Autor: C. A. Rotwang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Michl (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
C. A. Rotwang schrieb:
> Lies das:
> 
https://www.xilinx.com/support/documentation/user_guides/ug473_7Series_Memory_Resources.pdf

Nein!

Bitte fasse es mir zusammen bzw antworte auf die Fragen oben!

Autor: PostalDude (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Es sind Bits Dude und keine Bytes.

Autor: Jürgen S. (engineer) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Michl schrieb:
> 16384 x 720
> = 11Mbit. Oder sind es 16000? Oder sind es 18Bit-RAMs?

Die Bezeichnungen sind da manchmal etwas unglücklich. Xilinx spricht 
einmal von einem 16kb-RAM und im anderen guide von KB18 und KB36. Es 
sind 18 Bits. Nutzen kannst du sie aber nur, wenn du geschickt 
sortierst. Effektiv wäre dann z.B. 18x3.



Michl schrieb:
> Wozu die Angabe
> dient, ist mir nicht klar. Sicher kann ich auch 64Kb verdrahten und habe
> 1/4?

Von der Summe der Speicherzellen hast du recht. Je mehr du in einem Wort 
zusammenfasst, desto weniger von denen hast du. Bei 4 RAMs auch gerne 
32er MODE mit 72Bits. Ausdrücklich auszuwählen braucht man das aber 
nicht. Die Synthese wählt das selber aus.

Es gibt nur eine Besonderheit mit der Einteilung bei gleichzeitigem 
Zugriff, die man im Hintzerkopf haben sollte: In der 16er-Konfiguration 
können beide eines 32ers unabhängig von einander verwendet werden. Es 
wären also wirklich >700 unabhängige kleine Speicher. Die Synthese sagt 
dir aber schon, wieivle sie verbrutzelt hat.


Die Gleichzeitigkeit des Zugriffs beantwortet auch die Frage nach der 
Leistungsfähigkeit eines FPGAs: Rechne dir mal aus, was an Bandbreite 
herauskommt, wenn eine Recheneinheit alle RAMs mit voller Taktfrequenz 
und Dual-Port-Funktion benutzt.

Das sind Terrabits pro Sekunde! Ich habe das für meinen Synthie mal 
ausgerechnet, der wirklich alle RAMs mit jedem Takt über 2/3 Seiten 
zugreift.
Für den 100er Artix sind das 2500Gbps. Das entspricht der Bandbreite von 
>10 aktuellen DDR3-Controllern. Will man die gleichen Rechnungen mit 
einem PC machen und speichert alles in Variablen weg, bräuchte man (hin- 
und her) mindestens 20 PCs.

Die gleiche Rechnung kann man für die Speicherung von 
Zwischenergebnissen machen, die in Registern stehen. Wenn man die 
100.000 FFs mit voller Rate fährt, braucht es sogar noch eine 
Größenordnung mehr an Bandbreite nach aussen, damit ein Prozessor Daten 
holen und speichern kann. Selbst wenn er sich 90% der Arbeit wegspart 
und jeweils ohne zu speichern in Registern weiterrechnet, gibt das 
nochmals mindesten einen so großen Speicherbedarf, wie oben 
vorgerechnet. Macht also 40-50PCs um die gleichen Mengen an Daten zu 
bewegen.

Vergleicht man jetzt noch das, was der FPGA mit seiner Kombinatorik 
rechnen kann (die FFs werden ja von etwas gespeist), dann kommt man auf 
die Rechenbandbreite. Für den erwähnten Synthie sind das um die 3500 
Multiplikationen, Additionen und Vergleiche bei 200MHz. Ein PC-Prozessor 
kann manches in einem Schritt, hat bis zu 8 Cores aktiv und schafft 
4MHz. Trotzdem wären es auch wieder 20 Stück, wenn es optimal liefe und 
er nichts anderes täte.

Real zusammen mit den Speicherzugriffen und Verwaltung der Rechnereien 
sind es auch etwa 50 PCs. Bei 50% Speichern und Rechnen, als 100 
Prozzis.

Ein voll ausgelasteter Artix 200 (dreifache Zahl der RAMs) ersetzt bei 
rudimentärer Signalverarbeitung 250 ... 300 gut ausgelastete 
PC-Prozessoren. Da der FPGA andererseits durchschnittlich auf 16 ... 48 
Bit arbeitet, kann man 64Bit-Systemen wieder einen Faktor 2 
gutschreiben. Da PCs auch noch weitere Funktionen haben, wie RS232, 
Grafik, PCI, USB und es letztlich nicht gelingt, den FPGA bei allen 
Resourcen zu erschöpfen, geht das aus Systemsicht nochmals runter.

Autor: FPGA zum Spass (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michl schrieb:
> Ich kann z.B. nicht so recht nachvollziehen, woher die hohe
> Rechenleistung bei FPGAs kommt

Wie, das kannst du nicht nachvollziehen?

Du hast in diesem von dir ausgewähltem FPGA 360 Blockrams mit 2*36 Bit 
Interface..

Mal zum Vergleich mit aktuellen High-End Graphikkarten mit 
HBM(=schneller gehts nicht):

Radeon VII:
Schnittstelle: 4.096 Bit
Taktrate: 1000 MHz (DDR)
Bandbreite: 1,0 Terabyte/s
Latenz

-------
Artix 7 200:
Schnittstelle: 25920 Bit
Taktrate: 509Mhz (höchster Speedgrade)
Bandbreite: 1,6 Terabyte/s

Und da sprechend wir noch nichtmal von Latenz, minimalen Burstgrößen 
usw., wo Blockram immer im Vorteil ist.
Wenn du Spaß hast, dann kannst du ja mal die Bandbreite für die LUTs 
ausrechnen, da wird einem sicher schwindelig.

Du siehst: selbst so ein "Lowcost" FPGA ist schneller als jede 
verfügbare Standardhardware im PC.

Klar ist davon wenig Speicher vorhanden. Kein Wunder, der ist so schnell 
das er halt teuer ist.
Frag mal Intel warum die in ihrem schnellsten Prozessor nur läppische 
512Kbyte Level 1 Cache einbauen.


An die alten Hasen: mir ist klar das eine Taktrate von 509 Mhz am 
Blockram nicht realistisch zu erreichen ist, jedoch handelt es sich in 
beiden Fälllen um Datenblattwerte, von daher ist es sicher fair.

Autor: C. A. Rotwang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es handelt sich wohl um externe Daten, damit sind obige Datenratten 
völlig fürs Klo, weil der Flaschenhals FPGA-IO's nicht in Betracht 
gezogen wird.

Was der TO anfragt ist wohl ein aufgebohrter Bithound 
https://bastli.ethz.ch/index.php?page=bithound

Autor: FPGA zum Spass (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
C. A. Rotwang schrieb:
> Datenratten völlig fürs Klo

Bitte keine Ratten im Klo!

Das Schöne ist: man braucht damit nicht mal 0.1% der zur Verfügung 
stehenden Bandbreite.

Den Rest kann man z.b. benutzen um noch Zig weitere Prozessoren 
einzubauen, die mit 156 Mhz takten.
Die können dann parallel verschiedene Kompressionsalgorithmen auf den 
Daten testen und die effizienteste Variante wird benutzt, damit man mit 
dem bischen Speicher auskommt.*

Alternativ kann man auch einfach ein (S)(D)DRam anschließen, wie es halt 
sonst auch gemacht wird wenn viele Daten anfallen.


* muss man Ironie hier kennzeichnen?

Autor: Sigi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jürgen S. schrieb:
> Real zusammen mit den Speicherzugriffen und Verwaltung der Rechnereien
> sind es auch etwa 50 PCs. Bei 50% Speichern und Rechnen, als 100
> Prozzis.

Der Witz bei deiner Rechnung ist ja, dass man im Gegensatz
dazu für einen "modernen" PC inkl. Graka sicherlich duzende
grössere Artixe für eine Nachbildung braucht, die Taktrate
noch nicht berücksichtigt. D.h. um ein Artix per simulierten
PC auf Artixbasis zu simulieren sind sicherlich 100te FPGAs
nötig.

Autor: Jürgen S. (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sigi schrieb:
> Der Witz bei deiner Rechnung ist ja, dass man im Gegensatz
> dazu für einen "modernen" PC inkl. Graka

Wenn du eine komplette Graka mit ihren dedizierten Funktionen nachbilden 
willst, ganz sicher. Für allgemeine Rechnung ist das nicht so eindeutig:

Graka können nur einen sehr schmalen Ausschnitt der möglichen 
Berechnungen, die wir so industriell benötigen, so hocheffektiv leisten. 
Rendering ist das in erster- und parallele Rechnung mit wenigen, sich 
selten ändernden Parametern in zweiter Linie. Typische Rechnungen 
erfordern ein häufigeres Umladen und Abholen der Ergebnisse und da kommt 
die limitierte Bandbreite ins Spiel. Nicht die zum RAM, sondern die zum 
Zielsystem. Grafikkarten bekommen im Vergleich wenige Parameter und 
rechnen damit sehr viel, daher muss man genauer hinsehen, was da 
passiert:

Ich verfolge das Thema seit über 10 Jahren und habe an unterschiedlichen 
Stellen Vergleiche und Performance-Tests dazu gesehen und mit 
durchgeführt.

Da verliert eine Graka sehr oft eben wegen suboptimaler Optionen des 
Datenaustauschs. Ein aktuelles Beispiel sind neuronale Netze, die sich 
in FPGAs in begrenztem Umfang durchaus in 3D oder sogar 4D vernetzen 
lassen und Graka um gleich mehrere Größenordnungen schlagen, weil die 
Strukturen dafür fehlen.

Was sich anböte, ist die Nutzung von Grafikspeicher im Verbund mit 
FPGAs, bei entsprechend breiter Anbindung, statt das DDRx-Technik mit 
wenigen Leitungen und begrenztem Durchsatz.

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.