mikrocontroller.net

Forum: FPGA, VHDL & Co. 2D-Kamera VHDL Simulationsmodel


Autor: P. K. (pek)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen

Da ich für mein Kameramodul (AR0134) kein VHDL-Model gefunden habe und
es nicht selbst schreiben möchte (sonst verifiziere ich mich selbst),
suche ein generisches VHDL-Kamera-Simulationsmodel mit N-bit-parallelem
I/F (DCK, SF, SL, D[N-1:0]) für die FPGA-Interface-Entwicklung.
Idealerweise mit ein paar Konstanten parametrisierbar auf den jeweils
benutzten 2D-Kamera-Sensor und interpretierbarem Dateninhalt (Testbild).

Weiss jemand eine Quelle?

Autor: Kest (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
du möchtest dich selber nicht verifizieren, aber jemanden anders? ;-)

Im ernst, sowas schreibt man selber -- geht viel schneller und aus dem 
Datenblatt des Moduls kannst Du die richtigen Parameter nehmen.

Autor: P. K. (pek)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kest schrieb:
> Im ernst, sowas schreibt man selber

Naja, das wäre dann die Fallback-Lösung.

Natürlich mit dem Pferdefuss, dass ein genereller Denkfehler, in Modell 
und I/F eingefügt, durchaus passable Simulationsresultate liefern 
kann, weshalb ich erst mal checke ob schon irgendwo was unabhängiges 
existiert.

Autor: Dito (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
P. K. schrieb:
> Hallo zusammen
>
> Da ich für mein Kameramodul (AR0134) kein VHDL-Model gefunden habe und
> es nicht selbst schreiben möchte (sonst verifiziere ich mich selbst),
> suche ein generisches VHDL-Kamera-Simulationsmodel mit N-bit-parallelem
> I/F (DCK, SF, SL, D[N-1:0]) für die FPGA-Interface-Entwicklung.
> Idealerweise mit ein paar Konstanten parametrisierbar auf den jeweils
> benutzten 2D-Kamera-Sensor und interpretierbarem Dateninhalt (Testbild).
>
> Weiss jemand eine Quelle?

Ich könnte fast wetten das Du nichts finden wirst:
Zu speziell, wenn schon der Hersteller des Modules nichts liefern 
(kann/will) wer sonst?

Ggfs. gibt es aber irgendwo ein Evalboard an dem man sich mittels 
Logic-Analyzer (vorzugsweise PC Basiert) dranhängen kann und die Daten 
in ein File sampelt und anschließend von dort in einer Testbench 
"abspielt"?

Das hätte dann auch den Vorteil das Du ggfs. die physikalischen 
Gegebenheiten eines realen Sensors (HotPixel, weak Pixel) in Datenform 
vorliegen haben könntest...

Gruß

Dito

Autor: Lars R. (lrs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

P. K. schrieb:
> Da ich für mein Kameramodul (AR0134)

Welches? Selbst gebaut?

> kein VHDL-Model gefunden habe und
> es nicht selbst schreiben möchte (sonst verifiziere ich mich selbst),
> suche ein generisches VHDL-Kamera-Simulationsmodel mit N-bit-parallelem
> I/F (DCK, SF, SL, D[N-1:0]) für die FPGA-Interface-Entwicklung.

Das ist typischerweise das geringste Problem. Man sieht es auch schnell 
und kann es relativ schnell beheben, falls bei diesem parallelen 
Interface etwas nicht wie erwartet funktioniert.

Autor: P. K. (pek)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lars R. schrieb:
> Welches? Selbst gebaut?
Ja, selbst gebaut (zumindest bis zum Schema). Liegt leider noch nicht 
auf dem Tisch, sonst würde ich mich nicht mit Modellen rumschlagen, 
sondern direkt den Chip ansteuern.

Autor: Jürgen S. (engineer) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Wie aufwändig soll es denn werden? Nur generisches Sensortiming oder 
auch auch physikalisch, elektrisch korrekt? Eigentlich reicht dafür ein 
reines trigger-Modell im Simulator, das entsprechend extrem eingestellt 
wird.

Nur, bei konkreten Vorausentwicklungen im ASIC-Bereich, wo beide 
Baustellen, nämlich der Sensor und der FPGA offen sind, geht man da in 
details - gfs auch in hardware.

Ich habe da mal was angedacht, um die Renderanimationen, die ich in 
Cinema mache, teilweise in Echtzeit aus dem FPGA kommen zu lassen, 
inklusive Zoomfahrten, Linseneffekte aber auch die typischen Defekte von 
Sensoren inklusive Rauschen, um Bildverarbeitung testen zu können.

Bin gerade dabei, das für HDMI flott zu machen (in der ersten Version 
kann es nur schnöde 800x600 mit Zoom für die Sensorpixel). Auch binning 
und Unschärfe ist bei entsprechend großem und schnellem FPGA möglich.

Autor: Martin S. (strubi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

ich hätte nen Core für sowas. Ist quasi ein virtueller Sensor, wo du die 
Sensorentimings (Front/Back porch, Line Valid/Frame Valid resp. Sync 
signale frei einstellst, mit verschiedenen Testbildmodi). Die 
Cosimulations-Variante kannst du per Python und Netzwerk-FIFO mit Daten 
füttern und die verarbeiteten Daten entsprechend auslesen. In der 
Hardware benötigst du eine CPU und etwas an RAM, falls du wahlfrei Daten 
generieren willst. Gibt dazu einen fertigen Videogenerator SoC für 
Synthese in VHDL.
Steckt aber einiges Hirnschmalz in der Sache und benötigt eine 
entsprechend virtuelle Maschine für die Simulation (Linux Container), so 
komplett supportfrei ist die Geschichte nicht, und kostet 
dementsprechend etwas an Schotter, um es an das Problem anzupassen.
Wenn Du die Verifikation selber machen willst, würde ich auch Kests Rat 
folgen. Was du selber kennst, kannst du auch optimal debuggen.
Falls Du komplett die Verifikation "outsourcen" willst, würde das ein 
grösseres Projekt werden.

Gruss,

- Strubi

Autor: P. K. (pek)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Im Hinblick, dass ich das I/F für ein FPGA entwickle und das Kameraboard 
im Oktober auf dem Tisch liegt, ist es wahrscheinlich das sinnvollste, 
wenn ich da ein primitives "works-for-me"-VHDL-Modell selbermache um 
vorbereitend simulieren zu können. Ich plane dann halt etwas mehr Zeit 
für die Inbetriebnahme ein, um die Feinheiten mit dem Kameramodul 1:1 zu 
debuggen.

So oder so: Vielen Dank für die Anregungen!

Autor: Lars R. (lrs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Soweit ich es verstanden habe, geht es um die Ansteuerung eines Sensors 
mit parallelem Interface und 50-70MHz. Die von Jürgen S. und Martin S. 
geschrieben Dinge sind beeindruckend, haben aber mit der 
Modell-/Simulations-gestützten Ansteuerung eines solchen Sensors 
überhaupt nichts zu tun.

Für ein solche "einfaches" Interface benötigt man dies ohnehin nicht. 
Typischweise entstehen eventuelle Schwierigkeiten bei Dingen, die man 
falsch verstanden hat, übersehen hat, oder gar nicht wissen konnte.

@P.K.: Ich habe Dir eine PN geschickt. Nur falls Du Sie nicht bekommen 
hast: Würdest Du mir bitte eine schicken?

: Bearbeitet durch User
Autor: strubi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lars R. schrieb:
> Soweit ich es verstanden habe, geht es um die Ansteuerung eines Sensors
> mit parallelem Interface und 50-70MHz. Die von Jürgen S. und Martin S.
> geschrieben Dinge sind beeindruckend, haben aber mit der
> Modell-/Simulations-gestützten Ansteuerung eines solchen Sensors
> überhaupt nichts zu tun.

Haben sie doch. Für div. Aptina-sensoren gibt es entspr. Profile mit 
exaktem timing. Kann sogar i2c Register emulieren. Das ist der Gag am 
virtuellen Sensor.

Autor: Lars R. (lrs)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
strubi schrieb:
> Lars R. schrieb:
>> Soweit ich es verstanden habe, geht es um die Ansteuerung eines Sensors
>> mit parallelem Interface und 50-70MHz. Die von Jürgen S. und Martin S.
>> geschrieben Dinge sind beeindruckend, haben aber mit der
>> Modell-/Simulations-gestützten Ansteuerung eines solchen Sensors
>> überhaupt nichts zu tun.
>
> Haben sie doch. Für div. Aptina-sensoren gibt es entspr. Profile mit
> exaktem timing. Kann sogar i2c Register emulieren. Das ist der Gag am
> virtuellen Sensor.

Das ist wirklich hübsch aber nicht relevant. Das Problem bei diesem 
Ansatz ist, dass eine Ansteuerung, die am echten Sensor nicht das 
vorhergesagte Ergebnis liefert, ebenso am Modell nicht das erhoffte 
Verhalten zeigt; und zwar für möglichst fast "alle" Fälle. Dabei hängt 
dies ggf. auch noch von der Beschaltung des Bildsensors ab. Wie "schlau" 
ist das Modell? simuliert es die analogen Vorgänge und die 
Funktionalität von nicht dokumentierten oder schwammig und knapp 
beschriebenen Registereinträgen?...
Andererseits sollte das Modell aber keinen Fehler liefern, wenn es mit 
dem Bildsensor (dann doch) problemlos und stabil läuft.

Das Timing von einem 14-bit parallen Interface ist doch überhaupt nicht 
die Schwierigkeit. Beim Bildsensor kommt es auf ganz andere Dinge an.

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

Bewertung
0 lesenswert
nicht lesenswert
Ich stimme teilweise zu. Um die Auslese eines Bildes zu validieren, 
braucht es zunächst weder ein physikalisches timing noch ein Bild. Es 
reicht eine reine Logiksimulation. Allerding ist diese auch mehr oder 
weniger trivial, weil sich ein händisch erzeugtes Modell einfach durch 
Zählen validieren liesse, um es sicher zu machen. Es würde auch im 
Fehlerfall kein Problem entstehen, wenn sich später bei Anlieferung des 
realen Chips eine diesbezügliche Diskrepanz ergäbe: Es würde einfach ein 
Wert angepasst und fertig.

Bildverarbeitung im FPGA bedeutet aber nicht immer nur einfach, die 
Daten durchzulassen und weiterzureichen, sondern sie vorzuverarbeiten 
und eine Anpassung der Signalverarbeitung erfordert konkrete Testbilder. 
Und da lassen sich selbst bei schon vorhandenem Sensor nicht so einfach 
alle Szenarien darstellen, die man haben möchte, ganz zu schweigen von 
einer Entwicklung von Software, die die Entwicklung des Sensors 
begleitet, wie das heute oft der Fall ist. Auch lässt sich aus 
Zeitgründen Vieles nicht in der Simulation machen, wie z.B. 3D-Rauschen 
etc.

Hinzu kommt, daß oft auch ein elektrisches Timing getestet werden soll, 
um z.B. Laufzeiten auf Leiterbahnen und die Exemplarstreuung von Chips 
zu untersuchen. Bei meinem Core lässt sich nicht nur das Sensortiming 
variabel einstellen, sondern auch das elektrische.

Autor: strubi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn existierende Sensoren emuliert werden sollen, macht das keinen 
Sinn, in die Details der Registerbugs zu gehn. Und dem TO geht es 
offenbar nicht um das Neudesign des Sensors...
Gerade Rauschen oder Artefakte lassen sich gut per Cosimulation 
erschlagen. Elektr. Kram interessiert nicht, das ist auch eher für 
ibis/spice. Auch wenn sich das im Prinzip ins hdl-modell einschleifen 
lässt.
Solange sich HW und Sim gleich verhalten, tut's das. Und wenn der 
Videogen mehr Stress als der Sensor erzeugen kann, hat man ne gute 
Robustness für die Schaltung gezeigt.

Klassiker: Auflösung im lfd. Betrieb ändern..

Autor: Weltbester FPGA-Pongo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Soll hier ein Kameramodell oder nur ein Sensormodell her? Eine Kamera 
mit ihren vielfältigen Optionen und Einstellmöglichkieten simuliert kein 
Mensch mit VHDL. Vor allem keine Register. Was soll das bringen?

Und Sensormodelle bekommt man gewöhnlich vom Hersteller. Die müssen ja 
auch etwas zum Simulieren haben, wenn sie selbigen entwerfen. Das sind 
heute alles integrierte Sensortechnologien mit ASICs drauf. Die werden 
vorher 100mal hin und her- simuliert, bevor es in den Prozess geht.

Autor: Strubi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Weltbester FPGA-Pongo schrieb im Beitrag #4681096:
> Und Sensormodelle bekommt man gewöhnlich vom Hersteller. Die müssen ja
> auch etwas zum Simulieren haben, wenn sie selbigen entwerfen. Das sind
> heute alles integrierte Sensortechnologien mit ASICs drauf. Die werden
> vorher 100mal hin und her- simuliert, bevor es in den Prozess geht.

Ich habe noch keinen Hersteller gefunden, der irgendwas von seinen 
Pixel-Modellen hergäbe, abgesehen schon mal von den $$$-Tools, die man 
dafür bräuchte...
Die Komplettsimulation gibt's m.W. eh nicht. Was die 100mal anbetrifft, 
bin ich bei einigen Digitalsections auch skeptisch, da gibts doch ein 
paar Sensoren (die mit den 68xx-Cores), die recht buggy sind. Siehe 
obiger Klassiker mit der Auflösung.
Gerade deswegen lohnt es sich, seine eigene Verifikationskette 
aufzubauen. Sprich: Man kommt kaum drum herum.

Autor: Weltbester FPGA-Pongo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn ein Hersteller unbedingt Sensoren verkaufen will und der Endkunde 
groß genug ist, dann kann man da auch was bekommen, denn vorhanden sein 
muss das in jedem Fall. Ist mehr ein rechtliches Thema.

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

Bewertung
0 lesenswert
nicht lesenswert
Ein Modoll, das die Analogoptionen abbildet wird man nicht bekommen. 
Wird aber auch nicht unbedingt nötig sein, meine ich. Das Digitale 
Verhalten ist schon ein Gewinn. Immerhin gäbe es mit einem solchem 
Modell die Chance, der Hersteller nachzuweisen, dass sein Sensor nicht 
in der Spec ist, wenn der daraufhin entwickelte Code nicht funzt :-)

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.