Hallo FPGA Fans,
ich habe eine CMOS Kamera. Diese erzeugt ein Bild mit 640x480 Punkten.
Jeder Pixel 12 Bit. Für meine Berechnung bin ich davon ausgegangen das
jeder Pixel mit 2 Bytes abgespeichert wird.
Die Kamera soll so ca 100 Bilder pro Sekunde schaffen. Demnach sind das
640x480x2x100 = 61,44MByte
Der Speicher muss so groß sein das maximal 2 Bilder reinpassen. Demnach
muss der Speicher 640x480x2 = 614,4kByte groß sein. Da ich sehr scnell
zum Ergebnis kommen muss, schließe ich erst mal die DDR aus, da diese
für die Umsetzung zu vielZeit benötigen.
Ich hatte so an einen FIFO von Cypress gedacht, doch als ich dann den
Preis sah (mehere 100€) viel ich fast vom Hocker.
Der Block RAM im FPGA ist leider etwas gering um 1 Bild zwischen zu
speichern. Jedoch ist der Block RAM sehr einfach anzusteuern. Gibt es so
einen Speicher nicht auch für extern nur halt etwas größer?
Für SDRAM benötigt man doch ein SDRAM Controler oder sehe ich das
falsch?.
Ich möchte einfach die Adresse und Daten anlegen und dann werden die
Daten dort gespeichert oder von dort gelesen. Beim SDRAM muss man doch
die Speicher refreshen.
Ich habe gerade Ferroelektrischen RAM gefunden nur ist dieser mit
maximal 20MHz zu langsam.
Ich hatte noch etwas vergessen :-)
Ich bekomme die Daten vom Bildsensor (12Bit) mit einem 72,5MHz Takt.
Daher fallen die langsamen Baustein weg :-)
Daher müssen die Bausteine schon mindestens 72MHz könnne. Da ich die
Daten auch noch auslesen muss :-) müssen die Speicherbausteine noch
schneller sein.
Ich gelaube ich komme um so einen DDR Speichercontroller nicht vorbei.
:-((
Martin schrieb:> Die Kamera soll so ca 100 Bilder pro Sekunde schaffen. Demnach sind das> 640x480x2x100 = 61,44MByte
Speichert die Kamera wirklich RAW-Bilder weg? Oder wird vielleicht schon
komprimiert?
Gib mal den Link zu der Kamera bekannt.
Wo ist denn Dein Interface-Punkt?
>Die Leerzeilen verschlechtern aber die Zugriffszeit ;-)
schon klar, aber das entfernen hätte länger gedauert als die
Suche + kopieren und hier einfügen
Ich hab mal einen 40MHz 8Bit Stream auf ein damals noch langsameres
SDRAM Speichermodul geschrieben.
Das mit dem Refresh ist kein Problem. Den kann man auch mit den 27MHz
machen.
Ich weiß noch, dass man das Timing etwas geschickt sortieren musste.
Aber dann ging es. Ok man braucht ein CPLD (oder FPGA) dafür.
Achja ... ich hatte die 8 Bit auf alle 64Bit verteilt. Dann war es also,
als ob man mit nur 5MHz auf das SDRAM schreibt.
>Für SDRAM benötigt man doch ein SDRAM Controler oder sehe ich das>falsch?.>Ich möchte einfach die Adresse und Daten anlegen und dann werden die>Daten dort gespeichert oder von dort gelesen. Beim SDRAM muss man doch>die Speicher refreshen.
Aber dafür hast du doch den FPGA. Das macht die State-Machine für die
Ram-Bausteine und die Refresh-Zyklen. Es braucht da keinen Controller
dafür.
Den Core für Rams kannst du kaufen, es gibt auch offene
Implementierungen. Und meinen eigenen hatte ich in weniger als zwei
Wochen geschrieben. (und eine Menge dabei gelernt)
Martin schrieb:> Das ist eine Kamera von Aptina. Es werden die Rohdaten 12Bit parallel>> rausgegeben.
Und warum reduzierst Du die nicht wie bei DVI zu 3 Bytes je Doppelbild?
Das geht mit einem simplen FiFo 2 Worte a 12 auf 24 und ausgangsseitig
ein 8 Bit Anschluss. Wenn man das verdoppelt kommt man auf eine Rate von
4 Worten bei 16 Bit = 2 SRAMs parallel. 4 Worte sind 25 Hz. Bei 640x480
ein Klacks.
Noch einfacher 3 RAMs für je 2x4 Bit sequentiell , also
Nibble 1 von Wert 1 + Nibble 2 von Wert 2
Nibble 1 von Wert 1 + Nibble 2 von Wert 2
Nibble 1 von Wert 1 + Nibble 2 von Wert 2
An einen DDR RAM Controller wollte ich mich nocht nicht wagen. Da dies
alles schnell fertig werden muss, wollte ich lieber einen statischen RAM
verwenden. Ich hoffe mal das diese auch noch 4 Jahre zur Verfügung
stehen.
Von welcher FIRMA sollte man denn den statischen RAM kaufen? Nicht das
dieser in 2 Wochen abgekündigt wird.
Soll dies ein Produkt werden, oder ist es ein Hobby- oder
Forschungsprojekt?
Willst Du einmal ein paar Bilder raus holen oder
kontinuierlich Bilder aufsammeln?
Martin schrieb:> Von welcher FIRMA sollte man denn den statischen RAM kaufen? Nicht das> dieser in 2 Wochen abgekündigt wird.
Cypress und IDT bauen ihr zeug sehr lange. Wir habern IDT FIFOs im
Einsatz, das sind seit 2004 die gleichen. Ich würde darauf achten, dass
es eine Bauform und Anschlussbelegung ist, die es auch bei anderen
Herstellern gibt, so kannst du notfalls ausweichen.
Es soll ein Produkt werden. Die Bilddatenstream soll kontinuierlich
kommen nach Möglichkeit zwischen 50 bis 100 Bilder pro Sekunde.
Ich habe mir folgendes überlegt. Ich werde 2 statische RAMs verbauen.
Die Kamera ist momentan direkt mit dem FPGA verbunden. Die Bilder werde
ich immer abwechselnd in die RAMs schreiben. Also das 1. Bild in den
SRAM und das 2. Bild in den anderen SRAM.
Wenn ich das 2. Bild im 2 SRAM abspeicher werde ich das 1. Bild aus dem
1. SRAM auslesen und übertragen.
Demnach benötige ich 32 Datenleitungen und insgesamt 38 Adressleitugnen.
Das sind natürlich schon recht viele Leitungen.
Mit einem DDR3 Speicher wäre dies sicherlich viel kompakter und
preiswerter, aber ich muss momentan schnell zum Ziel kommen.
Martin schrieb:> Wenn ich das 2. Bild im 2 SRAM abspeicher werde ich das 1. Bild aus dem> 1. SRAM auslesen und übertragen.
Der Vollständigkeit halber, um ein ganzes Bild zu bekommen,
wie das System aussehen soll:
Wie und wohin werden die Daten übertragen?
Wohl doch nicht mit USB 2.0 HS zu einem PC?
Und vielleicht auch: Was wird dann damit auf dem PC gemacht?
Martin schrieb:> Ich bekomme die Daten vom Bildsensor (12Bit) mit einem 72,5MHz Takt.> Daher fallen die langsamen Baustein weg :-)
Schalte 4 Stück im Zeit-Interleave. Dann brauchst du nur noch 20 MHz
Speichertakt.
Für kontinuierlich würd ich aber einen FIFO nehmen, da geht das viel
besser zu streamen. Oder einen FIFO-Wrapper für einen SDRAM Controller.
Ist aber schon was für Experten dann. Und wo soll das dann hin? In den
PC? Da brauchst du mindestens Gigabit Ethernet, oder USB 3.0. USB 3
würde sich da wegen UVC anbieten. Das geht mit dem neuen FX3 von Cypress
sehr gut. Der hat auch ziemlich viel interne DMA Puffer, da könnte der
FIFO kleiner ausfallen...
Martin schrieb:> Michael> Das habe ich nicht ganz verstanden. Du machst aus 2 Bilder 1 Bild?
Punkt, nicht Bild.
Du bekommst 3 Nibbles (4 Bits) je Punkt. Du kannst 2 Punkte A,B so
ordnen:
AAAAAAAA AAAABBBB BBBBBBBB
oder so ordnen:
AAAA BBBB
AAAA BBBB
AAAA BBBB
CCCC DDDD
CCCC DDDD
CCCC DDDD
Du sammels als 2x2 Punkte und speichers jeweils 3 nibble in 3
verschiedene RAMs
AAAACCCC + BBBBDDDD + AAAACCCC + BBBBDDDD + AAAACCCC + BBBBDDDD
Die 12 A sind jeweils 12 Bit, die 12 B auch.
Ich habe sie jetzt nicht nummeriert.
Der Vorteil dieser Method ist, dass man bei Auslesen die Möglichkeite
hat, nur ein einziges RAM zu durchsuchen, um mit einer Leseoperation im
Nachhinein die höchsten Nibbles von gleich 2 Punkten einzulesen, um ein
vereinfachtes Vorabbild zu bilden oder ein Histogramm zu entwickeln.
So was musste ich mal machen.
Ansonsten schreibst Du einfach wie in der Empfehlung 1 jeweils 2 Punkte
auf 3 Bytes. Geht mit einem 24:8 Fifo am einfachsten.
Ich habe gesehen das die meisten SRAMs die für mich in Frage komme
asynchrone SRAMs sind. Demnach gibt es dort keine Clock Leitung.
Ich habe bis jetzt immer nur mit synchronen Speichern gearbeitet. Wie
kann man sich das bei asynchronen SRAMs vorstellen?
Ich die Adressleitungen, Datenleitungen und WR Leitungen. Wenn ich die
Daten und die Adresse angelegt habe, dann setze ich die WR Leitung und
die Daten werden übernommen.
Wenn ich jedoch gleichen einen ganzen Stream aus mehreren 100 Bytes in
SRAM schreiben möchte dann lasse ich die Schreibleitung aktiviert und
änder die Daten und die Adressleitung. Dadurch werden die Daten in die
nächste Adresse geschrieben.
Bei FPGA benutzt man dann so einen 100MHz oder 200MHz Takt um die neuen
Daten und Adressen zu erzeugen. Muss man bei den asynchronen SRAMs
besser wenn man zuerst die Adresse erhöte und dann die Daten ändert, so
das die Daten an der alten Adresse nicht ausversehen überschrieben
werden?
Mal als kleine Anregung: Bei mir in der Arbeit wird ein 5 Megapixel
Farbchip verbaut. Der besitzt einen Farbfilter und hat somit "nur" 8 Bit
Helligkeitsinformation pro Pixel. Hinterher wird mittels einer
Bayer-Konvertierung das Bild auf 24 Bit Farbtiefe hochgerechnet. Das ist
ein Vorgehen, dass nicht umsonst von vielen praktiziert wird.
Martin schrieb:> Wenn ich jedoch gleichen einen ganzen Stream aus mehreren 100 Bytes in> SRAM schreiben möchte dann lasse ich die Schreibleitung aktiviert und> änder die Daten und die Adressleitung. Dadurch werden die Daten in die> nächste Adresse geschrieben.
Bei aktivem WR dürfen sich üblicherweise die Adressen nicht ändern.
Also: Bei permanent aktivem CS die Adressen anlegen, dann in beliebiger
Reihefolge WR und Daten anlegen, dann WR wegnehmen. Timing beachten.
Also muss man immer einen WR PULSE erzeugen. Ich werde mir das
Datenblatt noch mal durchlesen. Der Baustein besitzt schon mal ein
TSOPII Gehäuse und es sind 1000 Stück bei Digikey verfügbar.
Ein IDT 72T18125 kann dein gesamtes Bild auf einmal aufnehmen (512k x
18Bit). Ist ein schneller synchroner FIFO. Klar, kostet dann natürlich
bissl was, bei Digikey reichlich 100€. Kann aber dann auch synchron mit
deinem 62MHz bedeient werden. Aber musst du denn ein gesamtes Bild
speichern, wenn das PC-Interface schnell genug ist? Dann reciht ja
vielleicht auch ein halbes oder ein viertel....
Soll das überhaupt direkt zum PC? Oder brauchst du zwischendrin
wahlfreien Zugriff auf die Bilddaten?
Christian R. schrieb:> Ein IDT 72T18125 kann dein gesamtes Bild auf einmal aufnehmen (512k x> 18Bit). Ist ein schneller synchroner FIFO. Klar, kostet dann natürlich> bissl was, bei Digikey reichlich 100€.
Das finde ich für eine Serie viel zu teuer. Second Source ist wohl auch
nicht. Dann doch lieber TSOPII-44 SRAMs.
Martin schrieb:> Bei FPGA benutzt man dann so einen 100MHz oder 200MHz Takt um die neuen>> Daten und Adressen zu erzeugen. Muss man bei den asynchronen SRAMs>> besser wenn man zuerst die Adresse erhöte und dann die Daten ändert, so>> das die Daten an der alten Adresse nicht ausversehen überschrieben>> werden?
Das gibt grossen Matsch, weil Du niemals Adress- und Datenleitungen
gleichzeitig ändern kannst. Nur bei bestimmten DV_systemen macht man das
so. Diese Takten alles ein und anylisieren Adressleitungsänderungen, um
sich selber eine WE zu erzeugen. Du musst das WE immer zu stabilen
Zeiten anlegen. Das WE ist dann sozusagen der Takt. Das geht im FPGA
ganz einfach, wenn Du die Frequenz des FPGAs genau an das Maximum des
RAMs anpasst und das WE und die ADressen und Daten alle mit diesem Takt
registrierst. Dabei musst du dann nur per Delay das WE entsprechend
verchieben. Synchron geht das dann wiederum sehr gut, wenn du genau den
doppelten Takt benutzt und das WE einmal negiert mit einem clock toogle
verundest und eintaktest:
Im FPGA:
CLK _____``````_____``````_____``````_____``````_____``````
ADR 000000XXX1111111111111111111XXX2222222222222222222XXX3333
DAT zeitlich so gültig, wie die ADR
DE ___________```````````___________```````````___________``````
Am Port
ADR 000000000000000011111111111111111111112222222222222222222
DAT wie oben die Adressen
DE _________________``````________________``````________________
RAM sieht : 111111 222222
@ Christian R.
Diesen FIFO habe bereits auch schon gesehen, jedoch ist die
Verfügbarkeit sehr schlecht zum gibt es wie bereits erwähnt keine second
source das ist mir zu heiß.
Ich benötige ein ganzes Bild, da die Kamera synchron mit unseren
Messsystem laufen soll. Die Daten übertrage ich per Camera Link.
Ich will die Daten hinten an den anderen Messstream dranhängen. Somit
habe ich 2 Bilder.
Da ich nicht sicherstellen kann das beide 1. Zeilen zugleich aufgenommen
werden können muss ich das CMOS Bild zwischenspeichern. Da ich auch noch
nicht weiß wie lange die Belichtungszeit sein muss gehe ich erst mal
davon aus das ich 1 Bild zwischenspeichern muss.
Die SRAMS habe wirklich einen großen Vorteil Sie sind sehr einfach
anzusteuern genau das habe ich mir auch so gedacht. Jetzt muss ich noch
mal am FPGA checken welche I/O Port Spannungen ich verwende.
Schon mal vielen Dank für Eure sehr hilfreichen Bemühungen :-)
Martin schrieb:> Hallo FPGA Fans,>> ich habe eine CMOS Kamera. Diese erzeugt ein Bild mit 640x480 Punkten.> Jeder Pixel 12 Bit. Für meine Berechnung bin ich davon ausgegangen das> jeder Pixel mit 2 Bytes abgespeichert wird.>> Die Kamera soll so ca 100 Bilder pro Sekunde schaffen. Demnach sind das> 640x480x2x100 = 61,44MByte>
Also deine Kameravorgaben lassen einiges ausser betracht:
-CMOS rauscht stark, die unteren beiden bits kann man daher wegwerfen
ohnen Qualitätsverlust.
-die bist pro Pixel sind Helligkeitsinfo, keine Farbe (R-Kanal,
Grün-Kanal, Blau-Kanal). für ein farbbild musst du entsprechend dem
Bayer-Mosaic die fehlenden Kanäle aus den nachbarpixeln interpolieren.
-Für 100 fps müsst die Kamera mit 1/100 belichten und während der
Belichtung das vorhegehende Bild in den RAM pappen. Kann dein Sensor
dies gleichzeitig? Ist deine Szene so lichtreich das mit 1/100 nicht
unterbelichtet wird?
-Das menschliche Auge nimmt mit 25 fps ruckelfreie Bewegung dar, wozu
100 fps?
Also bei der Festlegung der Bild-rate solltest du genau abprüfen was
geht und was gebraucht wird. 100 fps sind da recht anspruchsvoll,
realistisch wären da 25 fps. belichrungszeiten 1/10 - 1/25 und länger
sind für Innenaufnahmen eher die Regel als 1/100 und kürzer.
Hinsichtlich des mangels an embedded FPGA-Mem, lohnt es sich bei allen
FPGA-Herstellern in den datenblättern zu schauen. Altera aht da zuweilen
deutliche größere Blöcke als Xilinx, der fusion von Actel hat sogar
Flash on Chip.
Moderne SDRAM's machen ihren Refresh selber, das ist nicht das problem.
Und mit etwas planung greift man auf ein Speicherbereich hinzu, der
nicht gerade aufgefrischt wird.
Die Softcore-memorycontroller sind in der Regel recht gut. problematisch
ist das baorddesign und die schnellen SDRAMS sauber an den FPGA zu
bekommen.
-> SRAM ist eine gute Zwischenlösung um erst mal einen prototypen für
die Bildverarbeitung zu bauen, tendendiell solltest du in Richtung SDRAM
(DDR2) entwickeln.
MfG,
Es soll ja auch erst eine schnelle Zwischenlösung werden. Es ist schon
geplant auf DDR3 und einen Spartan 6 umzusteigen.
Das mit der Belichtung ist kein Problem. Wir verwenden schon eine
gekaufte USB Kamera die so ca zwischen 25 und 40 Bilder pro Sekunde
kann. Jedoch werden die Bilder per USB 2.0 übertragen und es befindet
sich kein Speicher auf dem Board, so das auch mal Bilder verloren gehen.
So das man keinen kontinuierlichen Bilddatenstrom hat.
Es gibt auch genügend Anwendungen wo man mehr als 25 Bilder pro Sekunde
benötigt.
Mir ist bewust das dies nur die Rohdaten sind und das man am PC ein
Farbbild erzeugen muss. Ich hatte zuvor Kontakt mit dem Kamera Support
aufgenommen und mir die Framerate bestätigen lassen. Die Kamera soll so
um die 87 Frames bei 640x480 schaffen. Zudem ist die Empfindlichkeit
deutlich besser als bei der anderen Kamera.
Und der Preis war auch nicht gerade besonders günstig
Es sind zwar schon viele Posts und ich hab auch nicht alle überflogen,
aber dadurch das es nur ums zwischenspeichern geht wäre ein SDRAM vllt
wirklich das Mittel der Wahl. Einen "Controller" brauchen so gesehen
alle RAMs. Zumindest eine Ablaufsteuerung um die Signale entsprechend
Wackeln zu lassen damit man auf der einen Seite die Daten rein, und auf
der anderen Seite die Daten rausschaufeln kann. SRAM wäre sicher
möglich, und auch das einfachste, aber da sind die Preise eben
vergleichsweise "hoch" für die Kapazitäten.
SDRAM hat mit dem Page-Burst-Mode auch noch die schöne Eigenschaft das
man eine ganze Seite bequem ein/auslesen kann und mit jedem Takt ein
neues Datenwort schreiben/lesen kann.
Fritz Jaeger schrieb:> -CMOS rauscht stark, die unteren beiden bits kann man daher wegwerfen
Kann er so einfach nicht. Erstens kann das Rauschen geeignet prozessiert
werden und zweitens wird durch das Runden ein höherer digitaler noise
injiziert. Weiter kann man davon ausgehen, dass das Bild gfs schon
vorverarbeitet ist, da irgend ein Chip den CameraLink realisieren muss
und die meistens auch schon Vorverarbeitung machen.
Selbst wenn, die Rohdaten rauskommen ist es so, dass die Pixel ein fixed
pattern noise haben, das korrigiert werden muss und damit verschiebt
sich nochmal das Rauschniveuu. Eine sinnvolle Datenreduktion kann bei
einem Bild immer erst erfolgen, wenn die gain-offeset-correction druch
ist, defektive Pixel erstezt wurden und ein Rauschfilter drübergelaufen
ist, der auf die optische Auflösung angepasst wurde. Dann könnte man das
Bild gfs noch logarithmieren, um Bits einzusparen oder eine autoadaptive
Helligkeitskorrektur vornehmen.
> -Für 100 fps müsst die Kamera mit 1/100 belichten
nicht unbedingt, z.B. wenn Zwischenbildgewinnung betrieben wird, um
Überläufe zu vermeiden oder mit Überlappung gefahren wird, um die
Auflösung zu verbessern.
> Das menschliche Auge nimmt mit 25 fps ruckelfreie Bewegung dar
Das ist erstens kein Kriterium für die Bildverarbeitung, denn schnell
bewegende Objekte müssen im Industrie- und Militärbereich durchaus sehr
viel schneller aufgelöst werden, um z.B. Bewegungen zu messen oder eine
Autostabilisation zu ermöglichen.
Zudem ist das auch nicht ganz richtig interpretiert: "Kein Ruckeln
wahrnehmen" heisst nur, dass man dem Bild nicht ansehen kann, dass es
kein echtes flüssiges Bild ist, z.B. bei einem Kameraschwenk. Wenn sich
schnell bewegende Objekte im Bild befinden, kann man das sehr wohl
sehen, dass es ein zeitlich limiertes Bild ist, weil die Bewegung
zeitlich abschnittweise verschmiert
ist, während das Auge in Realität dem Objekt gut folgen würde und eine
sehr geringe Relativbewegung und damit eine schärfere Abildung hätte.
Das lässt sich leicht beim Tennis verifizieren, wo man als Zuschauer
sehr schnell den Ball nicht fokussieren kann, während das real sehr wohl
möglich ist.
Um ein bewegtes Objekt relativ mit maximaler Schärfe auf dem Schirm
abzubilden, muss die frame rate so hoch sein, dass sich das Objekt nur
um ca. einen halben Bildpunkt je frame verschiebt, wenn es statisch so
scharf abgebildet wird.
Wenn die Grösse und Optik es zulassen, dass ein Gegenstand im Bereich
von einem Bildpixel scharf berandet ist, darf es sich bei 60Hz nur um 30
pixel in der Sekunde verschieben, bevor das Auge bei projizierten
Bildern den Unterschied auf wahrnehmen kann. Bei Computer-TFT ist es
etwas unkritischer, weil die zeitlich sehr verschmieren und der
Abbildung nicht hinterher kommen. Da liege dann ohnehin Einschränkungen
vor, die früher limitieren, was die Darstellung angeht. Bei der Aufnahme
ist es aber so, dass man durch die Bildrasterung eine Bewegung zeitlich
"sampelt" und da gilt indirekt auch so eine Art Nyquist. Bewegungen im
Bereich von fs/4 sind nicht mehr gut- und die über fs/2 überhaupt nicht
mehr korrekt zu messen. Umgekehrt gibt es das in der Betrachtung der
horizontalen Auflösung auch, wenn man als fs die H-Freq nimmt:
Bewegungen deutlich kleiner, als 1 Pixel sind nicht in einem Bild zu
messen sondern brauchen mehrere Bilder.
>Mit einem DDR3 Speicher wäre dies sicherlich viel kompakter und>preiswerter, aber ich muss momentan schnell zum Ziel kommen.
Wer sagt denn, dass die Inbetriebnahme eines DDR3-Speichers mit
eintsprechendem IP-Core soviel länger dauert?
Außerdem bist du dann für die Zukunft gewappnet.
Schau dir doch mal, was dein FPGA-Hersteller für IP-Cores anbietet ...
Stachele schrieb:> Wer sagt denn, dass die Inbetriebnahme eines DDR3-Speichers mit>> eintsprechendem IP-Core soviel länger dauert?
99% der FPGA-Designer werden das behaupten.
Moin,
habe hier nen VGA-Sensor (Aptina) an nem Spartan6 mit DDR, die
skizzierten Bildraten ins DDR sind problemlos zu schaffen. Den DDR-Core
muss man nur noch mit LogiCore generieren, alles deutlich einfacher als
bei älteren Spartan-Familien.
Um die Daten schlussendlich wegzukriegen: Stichwort MJPEG encoder.
Zumindest die DCT kann man ins FPGA auslagern, den Rest (Verschicken)
macht man besser über einen DMA und embedded-Linux-fähigen Chip.
Gruss,
- Strubi
