mikrocontroller.net

Forum: FPGA, VHDL & Co. Speicherkonzept FPGA/PowerPC - Unklarheiten!


Autor: Andreas B. (loopy83)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

ich stehe vor einem neuen Projekt und habe zum Konzept ein paar Fragen.

Ich habe eine Datenquelle, die pro Sekunde ca. 50MB via LVDS Daten 
bereitstellt. Diese Daten müssen vor allem erst einmal zügig 
abgespeichert werden.

Dazu habe ich einen Spartan3A DSP vorgesehen, der die Daten in einem 
DDR2 Speicherbaustein ablegt.

Diese Daten müssen einem AMCC PowerPC 440EPx (667MHz) zugänglich gemacht 
werden.

Nun stehe ich vor dem Problem, ein entsprechendes Konzept für diese 
Aufgabe zu erarbeiten.
Soll ich ein oder zwei RAM Bausteine verwenden?
Der PPC braucht ja auch RAM für sein Betriebssystem und 
Programmspeicher.  Ich habe im Anhang ein Bild gezeichnet, in dem meine 
ersten Gedanken festgehalten sind.
Der PPC hat seinen eigenen Programmspeicher. Nur wie kann er auf die vom 
FPGA abgelegten Bilddaten zugreifen?

Eine Alternative wäre ein Dual POrt RAM, der aber nach meinen Recherchen 
nur in kleinen Größen erhältlich ist und nicht sonderlich schnell ist.

Könnte man den FPGA denn ganz weglassen? Ich bin bisher davon 
ausgegangen, dass der PPC diese Datenflut nicht bewältigen kann. Aber 
sind an sich die I/Os schnell genug, um 50MB/s ablegen bzw. verarbeiten 
zu können? Als OS kommt ein Linux zum Einsatz. Die Daten sollen dann für 
Gigabit Ethernet aufbereitet und so auch ausgegeben werden. Das ist an 
sich die Hauptfunktion des PPC. Aber könnte er parallel dazu auch noch 
die ankommenden Daten speichern, bearbeiten und am GigE-Port ausgeben ?

Ich bin noch etwas erschlagen von den ganzen Möglichkeiten, die es 
aktuell gibt. Vielleicht kann mir jemand helfen, etwas Licht in das 
Dunkel zu bringen?

VIELEN DANK!

MfG Andreas

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Andreas B. (loopy83)

>Ich habe eine Datenquelle, die pro Sekunde ca. 50MB via LVDS Daten
>bereitstellt.

Kontinuierlich oder nur in kleinen Brocken?

>Dazu habe ich einen Spartan3A DSP vorgesehen, der die Daten in einem
>DDR2 Speicherbaustein ablegt.

Kann man machen.

>Diese Daten müssen einem AMCC PowerPC 440EPx (667MHz) zugänglich gemacht
>werden.

>Soll ich ein oder zwei RAM Bausteine verwenden?

Kommt drauf an. 50MB/s sind eigentlich Peanuts für einen DDR2 RAM.

>Der PPC braucht ja auch RAM für sein Betriebssystem und
>Programmspeicher.

Jo.

>Der PPC hat seinen eigenen Programmspeicher. Nur wie kann er auf die vom
>FPGA abgelegten Bilddaten zugreifen?

Kommt drauf an.

1. Möglichkeit

Der FPGA wird als DMA Kontoller an den PPC Speicherbus angeschlossen 
und schiebt die Daten burstartig in den Speicher des PPC. im FPGA muss 
neben der Steuerung ein kleines FIFO rein, um den Datenstrom zu puffern. 
Wenn alles fertig ist kan der PPC direkt die Daten aus dem RAM lesen.

2. Möglichkeit

Der FPGA scheibt die Daten in einen extra RAM wie in deinem Bild, am 
Ende liset der PPC durch den FPGA die Daten aus.

>Eine Alternative wäre ein Dual POrt RAM, der aber nach meinen Recherchen
>nur in kleinen Größen erhältlich ist

Ja.

> und nicht sonderlich schnell ist.

Nein.

>Könnte man den FPGA denn ganz weglassen?

Wahrscheinlich nicht. Wenn der PPC kein spezielles Hardwareinterface für 
deine LVDS Daten hat, kann er die nicht so schnell aufnehmen und 
verarbeiten.

> Ich bin bisher davon
>ausgegangen, dass der PPC diese Datenflut nicht bewältigen kann.

Siehe oben.

> Aber
>sind an sich die I/Os schnell genug, um 50MB/s ablegen bzw. verarbeiten
>zu können?

;-)
Das allein reicht nicht.

> Als OS kommt ein Linux zum Einsatz.

Dann schon gar nicht.

> Die Daten sollen dann für
>Gigabit Ethernet aufbereitet und so auch ausgegeben werden. Das ist an
>sich die Hauptfunktion des PPC. Aber könnte er parallel dazu auch noch
>die ankommenden Daten speichern, bearbeiten und am GigE-Port ausgeben ?

Wahrscheinlich nicht ohne FPGA-Hilfe.

MfG
Falk

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hm, sinnvoll wäre es, einen FPGA mit integriertem PowerPC zu benutzen. 
Der Virtex 5 hat einen PPC440 eingebaut. Dann wird die Sache einfacher, 
denn du kannst die LVDS Daten mit Hilfe des DMA Controllers direkt in 
den DDR RAM schreiben lassen, und dann stehen die dem PPC zur Verfügung.

Welche Interfaces hat denn der externe PPC440? Auch sowas wie PLB?

Autor: Andreas B. (loopy83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Virtex 5 sieht sehr interessant aus. Ein FPGA mit integriertem PPC 
ist ne feine Sache. Ich werde mal schauen, ob sowas in FRage kommt.

@Falk Brunner:
Danke für deine Antworten.
Hast du vielleicht einen Link oder ein Bps für einen DualPOrt RAM, den 
ich einsetzen könnte?

Ich habe bisher nur kleine Chips gefunden, die von der Größe her aber 
nicht ausreichen dürften. Ein Bild hat ja 4MB aufwärts. Ich wollte schon 
so planen, dass 4-5 Bilder abgelegt werden können. Also sowas in 
Richtung 64MB.

Ich werde mal weiter schauen.... derweil bin ich weitere Hinweise und 
ANregungen dankbar!

MfG Andreas

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Andreas B. (loopy83)

>Hast du vielleicht einen Link oder ein Bps für einen DualPOrt RAM, den
>ich einsetzen könnte?

Dual Port RAM würde ich nicht verwenden. Bekanntester Hersteller ist 
Cypress.

http://www.cypress.com/

MfG
Falk

Autor: Andreas B. (loopy83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Virtex 5 kostet natürlich auch gleich mal 400€ aufwärts... nach oben 
wie so ift keine Grenze. Ich denke das wird mir zu teuer...

EIne Antwort bin ich euch noch schuldig:
Die Daten kommen vom einem Bildsensor. Kommen also kontinuierlich. Man 
hat aber die Option, auch nur burstartige Bilder zu machen. Also Bild 
machen und fertig... eine Lösung für beide Varianten wäre also nicht 
allzu verkehrt. Wobei ich dann eher zur kontinuierlichen Methode 
übergehen würde, denn wenn ein System kontinuierlich Bilder abspeichern 
und verarbeiten kann, sollte es auch mit einem einzelnen Bild 
klarkommen.

DANKE !!!!

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn du das kontinuierlich ohne Aussetzer zum PC übertragen möchtest, 
brauchst du große FIFOs um die Daten zu puffern. Ist das ein 
Privatprojekt, oder wieso knauserst du so? Der PPC mit all seiner 
nötigen Peripherie wird ja auch nicht gerade billig sein, oder?

Autor: Andreas B. (loopy83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es ist eine Diplomarbeit und der Fachbereich hat nun auch nicht 
unbegrenzte Mittel zur Verfügung, dass ich schon ein wenig drauf achte, 
ob die ganze Sache nun 2000€ oder 5000€ kostet :)
Die Firma, für die ich dieses Projekt bearbeite, hat quasi einen 
"Forschungsauftrag" an die FH gegeben und ist natürlich daran 
interessiert, dass das Ergebnis wirtschaftlich gestaltet ist.

Ich muss mir nun also überlegen, welches KOnzept die Anforderungen 
erfüllt und welches es umzusetzen gilt.

Was ein PPC440 einzeln kostet, schaue ich gleich mal nach!

VIELEN DANK!

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Virtex4 hat auch nen PPC drin meine ich, ggf. ist der etwas 
günstiger zu haben.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der hat aber "nur" den PPC 405. Reicht aber dicke. Nur wenn man den GbE 
MAC mit dem PPC und dem MPMC-DMA Controller nutzel will, ist der 
kleinste Virtex 4 FX12 schon nahezu voll. Da bleibt kaum noch Platz für 
Peripherie. Der FX20 ist da schon besser, kostet auch nur etwa 250 Euro. 
Am sinnvollsten ist ja eh ein Entwicklungskit, das ML405 haben wir hier 
liegen, das hat etwa 800€ gekostet. Ist aber dann alles komplett drauf 
und funktiopniert halt schon. Ich denke, das integrierte Konzept ist 
besser und man kommt schneller ans Ziel, mit dem externen PPC hast du 
auch erst mal eine Menge zu tun, dir ein passenden Bus-Interface zu 
erfinden. Innerhalb des Virtex geht das recht einfach über ein LocalLink 
Interface für die Video-Anbindung. Das kann dann der MPMC direkt 
benutzen...

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Christian R. (supachris)

>Der hat aber "nur" den PPC 405. Reicht aber dicke. Nur wenn man den GbE
>MAC mit dem PPC und dem MPMC-DMA Controller nutzel will, ist der
>kleinste Virtex 4 FX12 schon nahezu voll.

Die Frage ist eher, was denn genau mit den Bilddaten passieren soll? 
Superkomplexe Berechnungen oder ehr einfache Filter. Die kann man auch 
ohne PPC im FPGA machen, dann tut es ein einfacher, preiswerter 
Spartan3. GbE ist ale Einzel-IC billigetr als im FPGA. Dort ist es vor 
allem eine schöne Spielerei, SoC ;-)
Den Rest macht der FPGA nebenbei (Daten umkopieren).

>besser und man kommt schneller ans Ziel, mit dem externen PPC hast du
>auch erst mal eine Menge zu tun, dir ein passenden Bus-Interface zu
>erfinden.

Der interne ist auch alles andere als trivial!

MFG
Falk

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Den einlaufenden (kontinuierlichen) Datenstrom würde ich in jedem Fall 
im FPGA in einen BlockRAM packen. Die sind zwar klein (irgendwas um 2 
kB) aber sehr schnell und entlasten den Datentransfer zum DDR RAM.

Selbst mit einem "rattenschnellen" DDR2-RAM kämst Du man schnell an 
Grenzen, wenn du für jedes byte einen einzelnen Sende- und 
Empfangstransfer aufmachst.
Besser ist eine Blockweise Übertragung.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja klar, die Billddaten abholen und puffern kann man natürlich ohne 
den PPC machen. Aber wenn man ein ordentliches GbE Interface mit 
einigen Protokollschichten machen will, ist der PPC recht sinnvoll dafür 
geeignet. UDP geht zwar auch in Hardware, aber ist eben dann recht 
aufwendig und DHCP und solche Spielchen sind auch schwierig.

Und ja, LocalLink ist auch intern alle andere als trivial. Aber von der 
Fragestellung her hab ich den Eindruck, der Fragesteller ist damit 
sowieso überfordert. Ob intern oder extern....

Autor: Andreas B. (loopy83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank für die vielen Hinweise. Ich stecke noch am Anfang meiner 
Arbeit. Ich wollte nur erstmal ein Konzept erstellen, dass ich weiß in 
welche Richtung ich anfangen kann zu lernen. Ich bin also durchaus noch 
etwas überfordert, wenn es um die Einzelheiten geht.

Falk Brunner schrieb:
> 1. Möglichkeit
>
> Der FPGA wird als DMA Kontoller an den PPC Speicherbus angeschlossen
> und schiebt die Daten burstartig in den Speicher des PPC. im FPGA muss
> neben der Steuerung ein kleines FIFO rein, um den Datenstrom zu puffern.
> Wenn alles fertig ist kan der PPC direkt die Daten aus dem RAM lesen.
>
> 2. Möglichkeit
>
> Der FPGA scheibt die Daten in einen extra RAM wie in deinem Bild, am
> Ende liset der PPC durch den FPGA die Daten aus.

Vorteil der ersten Methode wäre, dass ich einen RAM Baustein spare. Nur 
wird diese Platzersparnis durch einen enrom höheren Programmieraufwand 
erkauft? Ist also die Anwendung der Methode 1 wesentlich aufwendiger als 
die der Methode 2?

DMA ist ja nach meinem Wissen eine Art SPI. Nur die Abarbeitung der 
Daten unterscheidet sich ja. Ist ein serielles Interface denn schnell 
genug, um die Datenmenge bewältigen zu können? Sowohl FPGA, also auch 
PPC müssen dieses Interface ja dann entsprechend hoch takten können.

Vielen DANK!!!!

Autor: matzunami (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

muss es denn ein PPC sein? Wenn du einen Microblaze integrierst, würde 
das doch eventuell reichen und zur not kannst du auch auf diesen Linux 
installieren. (nur mal so als Idee)

Gruß

Autor: Bernhard Mayer (bernhard84)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde das ganze FPGA + DDR-Ram und Kamera-Interface als 
PCI/PCIe-Device gestalten. Das kann dann DMA und du musst dir nicht so 
viel gedanken um das Bus-Interface zum Prozessor machen. Und 
wahrscheinlich gibts für die einzelnen Teile schon fertige Core, die du 
nur noch verknüpfen musst.

Und testen kannst du dann das ganze auf einem standard-x86-pc oder mit 
dem demoboard von dem AMCC. Das hat sicher auch irgendwo nen 
PCI/PCIe-Steckplatz. und von der zu übertragenden Datenmenge dürfte das 
hinkommen. Und eine PCI-Karte ist halt einfacher zu bauen, als ein 
ganzes System.

nur mal so als Vorschlag
Bernhard

Autor: Andreas B. (loopy83)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

also ich muss so wie es aktuell ausschaut eh das komplette neue System 
aufbauen. Mit einer neuen PCI Karte ist mir also nicht wirklich 
geholfen.

Ich habe mir das mit dem DMA nochmal etwas genauer angeschaut, denn es 
ist für mich aktuell die eleganteste Lösung, die am wenigsten kostet und 
Platz auf der Platine spart, das ich nur einen DDR2 RAM Baustein 
benötige.

Dazu habe ich noch ein paar Fragen:
Der PPC ist ja der Master und der FPGA wird an den Peripheriebus 
angeschlossen. Die Übertragung funktioniert mittels DMA. Ich habe ja 
einen 32bit Bus, sodass ich die LVDS Signale vom FPGA auflösen lassen, 
sie in ein FiFo packe und sie dann zu je 32bit vom PPC nach einem 
DMARequest gelesen werden.

Nur kann ich diese Daten dann auch ohne Probleme an den DDR2 
weiterreichen und dort ablegen? An sich sage ich dem PPC in der DMA 
Config ja nur, dass er die Adresse von da nach da packt und das so und 
so oft. Meine Quelladresse ist der Pheripheriebus und meine Zieladresse 
ist der DDR2 Speicher. NUr habe ich noch Bedenken, ob der PPC auf diesem 
Weg ohne CPU grpßartige Last mit dem RAM kommunizieren kann.

VIELEN DANK für Eure Hilfe!!!

PS: Ja, es muss leider ein PPC sein. Diese Vorgabe habe ich erhalten. 
Ich habe auch recherchiert und es gibt spezielle Bildprozessoren, die 
das besser können als der PPC, aber diese Maßgabe muss ich nun mal 
erfüllen.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Andreas B. (loopy83)

>Vorteil der ersten Methode wäre, dass ich einen RAM Baustein spare. Nur
>wird diese Platzersparnis durch einen enrom höheren Programmieraufwand
>erkauft?

Mehr oder weniger.

> Ist also die Anwendung der Methode 1 wesentlich aufwendiger als
> die der Methode 2?

Nicht unbedingt. Soooo komplex ist die Busanschaltung auch nicht.

>DMA ist ja nach meinem Wissen eine Art SPI.

Nöö. DMA ist DMA, und SPI ist SPI.

>Daten unterscheidet sich ja. Ist ein serielles Interface denn schnell
>genug, um die Datenmenge bewältigen zu können?

DMA ist nicht seriell, zumindest nicht bitseriell.

>sie in ein FiFo packe und sie dann zu je 32bit vom PPC nach einem
>DMARequest gelesen werden.

So in etwa.

>Nur kann ich diese Daten dann auch ohne Probleme an den DDR2
>weiterreichen und dort ablegen?

Ja.

> An sich sage ich dem PPC in der DMA
>Config ja nur, dass er die Adresse von da nach da packt und das so und
>so oft. Meine Quelladresse ist der Pheripheriebus und meine Zieladresse
>ist der DDR2 Speicher.

Ja.

> NUr habe ich noch Bedenken, ob der PPC auf diesem
>Weg ohne CPU grpßartige Last mit dem RAM kommunizieren kann.

???
Das macht der DMA-Controller im PPC. Die CPU mehr davon nix. UNd dank 
Cache auf dem PPC sollte das auch keinen nennenswerten Leistungseinbruch 
erzeugen.

MFG
Falk

Autor: Snowyrain (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich kann Dir zum Speicherkonzept nicht so viel sagen. Aber ich habe 
meine Abschlußarbeit auch (zum Teil) mit einem FPGA realisiert. Ich habe 
viele viele Nächte durchgemacht. Gerade die Fehlersuche ist nicht 
trivial.

Ich würde Dir empfehlen soviel fertige Hardware wie möglich zu nehmen. 
Und Deine Arbeit als eine Art "Proof of Concept" auslegen.
Wenn Dir ein 405er PPC reicht. Schau Dir mal das UZAKU SZ410-U00S an. 
Entwicklungsumgebung (PPC-Seite) wird als VMWare Image bereit gestellt. 
Es gibt ein sehr gutes Tutorial (leider auf japanisch, systrans hilft 
hier).
Ich würde sagen, dass nur die Hardware-Entwicklung mit Programmierung 
eine Diplomarbeit ist. Hals Dir nicht zuviel auf. ;-)


Mit freundlichen Gruß

Snowyrain

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.