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
Angehängte Dateien:
-
konzept.png
3,5 KB
@ 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
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?
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
@ 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
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 !!!!
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?
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!
Der Virtex4 hat auch nen PPC drin meine ich, ggf. ist der etwas günstiger zu haben.
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...
@ 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
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.
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....
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!!!!
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ß
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
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.
@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
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
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.