Hallo und guten Tag, ich befinde mich immer noch in der Entwicklungs-/ Konzeptphase eines größeren Projektes. Dabei möchte ich Bilddaten (4MPixel, 14bit) übertragen und speichern. Die Bilddaten sind in LVDS aufbereitet und sind in linke/rechte Bildhälfte und 7bit zu 7bit unterteilt. Insgesamt werden also 4 LVDS Kanäle + LVDS Takt aus dem ADC ausgegeben. Diese LVDS Daten werden in einen Spartan3A DSP gegeben, dort aufbereitet (in ein FIFO geschoben) und sollen von dort abgefragt werden. Die Abfrage übernimmt ein PPC 440EPx. Der FPGA wird an den Local (oder externen?) Bus angeschlossen und kommuniziert mittels DMA mit dem DDR2 RAM, der am 16bit SDRAM Bus des PPC angeschlossen ist (dieser ist eigentlich 64bit groß, aber da nur ein RAM Baustein verwendet wird, wird er auf 16bit verkleinert). Der PPC ist der DMA Master und fragt die Daten vom FPGA ab. Nun ist der Bus, an dem der FPGA angebunden ist, ja 64bit groß (wenn ich das dem Datenblatt [DMA to PLB3 Controller] richtig entnommen habe). Ist es denn generall möglich, den FPGA auch nur mit 16bit an diesen Bus anzubinden, damit es keine Konflikte beim Schreiben in den RAM gibt? Am Local Bus hängt ja ebenfalls noch ein NOR Flash, von dem der PPC bootet. Der hat ebenfalls nur 16bit Daten. Die Beschneidung des Busses sollte also keinerlei Auswirkungen auf andere Busteilnehmer haben. Wird der Transfer der Bilddaten (sind ja doch 7MByte pro Bild) via DMA in den DDR2 RAM schnell genug von statten gehen, oder sind die Latenzen zu groß? Ein Komilitone meinte, dass DMA vergleichbar wäre mit "komm ich heut nicht komm ich morgen"... es also da Probleme geben könnte. Sind die Übertragungs-/Verarbeitungswege denn theoretisch schnell genug, um 4 Bilder (also 28MB) innerhalb kürzester Zeit (500ms-1s) zu übertragen? Vielen Dank! MfG Andreas
DDR2 mit S3 ist eben schon schwierig, mit max rate geht es nicht. die IP cores machen bus width matching, wenns gluck geht alles :) wie schnell es wird hangt SEHR von burst-size ab der MPMC hat latenz von etwa 30 bus zyklen, dh beliebiger ram zugriff schlagt immer zu erst 30 clocks tot! mit grossen burst ist es nicht so schlimm, aber mit so 32 bit oder 64 bit zugriffen ist overhead enorm :( Antti
Es soll genau dieser Spartan 3A DSP eingesetzt werden => XC3SD1800A-4CS484C Nach meinen Recherchen sollte das ohne Probleme machbar sein, auch über DMA auf den DDR2 zuzugreifen... Oder gibt das mit der S3 Generation allgemein Probleme?
na 200mhz DDR2 clock schaffst du ja nicht? oder hoffst du noch? S3A ist ganz am grenzen mit DDR2 deswegen ist ja im S6 DDR2 kontroller als hard macro drinne antti
Heinze78 schrieb:
> Hast du eine Skizze von deinem System ?
Ja => Siehe Anhang.
Ich hoffe es könnte so klappen, wie ich mir das vorstelle bzw. wie es
mir hier im Forum geraten wurde. Ich dachte eigentlich nur, dass ich mir
über die Details noch Gedanken machen muss, wie z.B. die Busbreite. Die
Machbarkeit stand für mich außer Frage, aber nach dem Kommentare von
Antti zweifle ich da auch wieder.
DANKE!
ah der DDR2 sitzt ja an externen PPC gott sei dank! ich dachte ist an S3A, das ware nicht so optimal irgendwas klappt immer noch nicht DDR2 -> PPC (DDR2 bus!) PPC (SDRAM bus, 16 bit ?) <> S3A ? ich glaube kaume das dein PPC separate bussen fur DDR2 und noch einen SDRAM hat, der S3 ist doch an was local bus? auf keinen fall darf der S3A an dem SDRAM bus sitzen wo auch der DDR2 drauf ist, dann gehts es kaput alles must du nur die PPC dokus lesen, S3A wurde schon alles schaffen, gegeben den PPC bus und DMA kann man konfigurieren wie du vorhast a
Hi, eine Frage zu dem Aufbau: Was ist denn eigentlich die Bildquelle bzw. was hängt am Eingang des ADCs ? Wie pufferst du die Daten im FPGA, die du vom ADCs bekommst ? VG, Heinze
Hallo, der DDR2 Baustein und der S3A sitzen selbstverständlich nicht am gleichen Bus. Der RAM wird am SDRAM Bus angebunden und der S3A am Local Bus, der vom DMA Controller verwaltet wird. Die Bildquelle ist ein CCD Chip. Aber das sollte an sich ja unerheblich sein, wichtig in meinen Augen für den Transport und die Verarbeitung der Daten ist, dass die Daten in 4 LVDS Kanälen mit externem Takt in den S3A gelangen und dort weiter verarbeitet werden müssen. Wie genau ich die Bilddaten buffern werde, weiß ich leider noch nicht. Entweder schiebe ich sie vom Eingang direkt in ein FIFO oder parke sie vorrübergehend im SRAM des FPGA. Wird sicherlich auch von der Burstgröße abhängen, wie groß der Buffer sein muss. Aber ich vermute, dass ich kein ganzes Bild (7MB) im FPGA zwischenspeichern kann. Der PPC wird der Master sein. Er fragt also die Daten im FPGA ab und sendet den DMAReq. Der FPGA wird dem PPC über einen Interrupt mitteilen können, dass der Zwischenspeicher/Buffer dabei ist überzulaufen und er die Daten abholen soll. Vielen Dank für die bzw. weitere Hinweise! MfG Andreas
Schon mal daran gedacht, einen externen Speicher an das FPGA anzuschließen ? Dort könnten die ADC-Daten ohne Probleme gepuffert werden und wären vom PPC-FPGA-Datenpfad entkoppelt. VG, Heinze
Ja habe ich, leider fehlt mir auf dem PCB ein wenig der Platz und dann muss ja der PPC auch irgendwie auf den RAM des FPGA zugreifen, um sich die Bilder zu holen. Das geht dann meiner Meinung nach nicht ohne weiteres mit DMA und es erfordert wieder Prozessorlast. Der PPC schaufelt ja dann die Bilder erstmal nur vom FPGA RAM in den eigenen... da kann der FPGA die Bilder auch direkt in den RAM des PPC ablegen. So war der Gedankengang und dank DMA sollte das auch recht Ressourcen schohnend gehen. Vielen Dank! Andreas
Zum Thema Prozessorlast: Kannst du sicherstellen, dass der PPC die Daten rechtzeitig aus dem FPGA holt, bevor neue ADC-Daten kommen ? Du solltest mal unbedingt eines Bandbreiten-Berechnung anstellen und schauen, ob der FPGA-interne Speicher ausreicht: 1. Bilddatenrate am ADC-FPGA-Interface (welche Auflösungen, welcher Takt) 2. Daterate am PPC (inkl. Paket-Overhead etc.) Selbst wenn der interne FPGA-Speicher ausreicht, solltest du dir anschauen, ob du alle Embedded-RAM-Blöcke zu einem Gesamtspeicher zusammenpömpeln kannst, ist ja nicht gesagt, dass dieses Unterfangen timingmäßig (fMAX) hinhaut. VG, Heinze
Bitte 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.