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?
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.
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.
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
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.
Angehängte Dateien:
-
realtime_rendering_vhdl.jpg
120 KB
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?
:
Bearbeitet durch User
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.
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
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.
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..
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.
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.
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.
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 :-)
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.