2D-Kamera VHDL Simulationsmodel

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.

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.

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.

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.

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

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!

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?

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.

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.

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 :-)