Hallo zusammen, ich arbeite mit einem Spartan 3 / 1000 Starterboard von Digilent. Folgenden Effekt kann ich mir nicht erklären. Ich habe eine Erweiterungsplatine mit einem 40 Pin Pfostenstecker gefertigt und auf den A2 Steckverbinder aufgesteckt. Die Spannungsversorgung für meine Erw-Plat. erfolgt durch eine eigene geregelte Versorgung also nicht vom Digi. Board. Ich nehme die 5V Versorung vom PC Nezuteil und gehe auf entsprechend beschaltete LM317 Spannungsregler ( Spannungsteiler, Siebkondensator, Schutzdiode usw.) Der Ausgang der Spannungsregler sind dann die 1,8V bzw. 3,3V Spannungsversorgung der Erweiterungsplatine Die Pins am Digilent Board Stekcer für 3,3V , 5V , und GND ( testweise ) sind alle NICHT mit der Erweiterungsplatine verbunden. Wenn ich nun den Spannungsversorgungs Stecker für das Digilent Board abziehe leuchten die LEDs vom Digi Board immer noch deutlich sichbar schwach ebenso die Power LED. Auf der 3,3V Schiene auf dem Digilent Board kann ich mit dem Voltmeter ca. 2V messen. Bei der Erw. Platine handelt es sich um einen Video AD-Wandler mit 3 * 8 Bit Ausgängen CMOS 3,3 V Die entsprechenden PINs am FPGA habe ich alle als IN , CMOS 3,3V und FAST per UCF File definiert. Die Gesamt Schaltung ( FPGA + Erw-Platine ) funktioniert auch einigermaßen, allerdings kommen immer wieder Lesefehler vor. Manche Bild-Daten werden doppelt gelesen. Beispiel: Je Zeile werden die Farbanteile im Bild linear aufsteigend definiert. Über das Spartan interne Dual Port Ram mit 2 Clock Domains bekomme ich dann häufig folgende Lesefehler: ....123, 124, 125, 126, 126, 128, 129.. ( also 126, 126 statt 126, 127 ) Muss dazu sagen ich benutze zu Testzwecken zur Zeit den Digitalen DVI Eingang des Bausteins und nicht analogen Eingang über den AD-Wandler Teil, so dass die Daten eigentlich exakt eingelesen werden müssten. Ad-Wandler Ungenauigkeiten werden ja ausgeschlossen. Wenn ich - die Spannungsversorgung für meine Erweiterungsplatine weiterhin in Betrieb habe - jedoch den Ausgang der GrKa abschalte, so dass die 3 *8 Bit Ausgänge aufgrund von fehlendem Input DVI Video Signal nicht mehr takten => dann kommt erst erlischt das schwache Leuchten der LEDs auf dem Digilent Board und auch die Power LED und die gemessene Spannung von 2V auf der 3,3V Schiene geht auf 0. Wie kann über die getakteten Eingange des FPGA ohne FPGA Betriebsspannung eine Spannung auf der 3,3 V Spannungsversorgung erzeugt werden, die dann sogar die LEDs zum schwach Leuchten bringt ??? Gruß vom FPGA-Fragenden
@ FPGA-Fragender (Gast) >Ich nehme die 5V Versorung vom PC Nezuteil und gehe auf entsprechend >beschaltete LM317 Spannungsregler ( Spannungsteiler, Siebkondensator, Das würde ich mir verkneifen. PC-Netzeile sind NICHT ungefährlich. Nimm eine kleines Steckernetzteil oder Labornetzteil. >Wenn ich nun den Spannungsversorgungs Stecker für das Digilent Board >abziehe leuchten die LEDs vom Digi Board immer noch deutlich sichbar >schwach ebenso die Power LED. Das macht man ja auch nicht. Denn damit ist eine Schaltung ohne Spannungsversorgung mit einer Schaltung mit Spannungsversorgung verbunden. >Auf der 3,3V Schiene auf dem Digilent Board kann ich mit dem Voltmeter >ca. 2V messen. Logisch. Dein FPGA wird über die Schutzdioden der IO-Pins von der Erweiterungsplatine versorgt. Das ist nicht gut. Siehe Pegelwandler. Deine Vermutung mit der "Ghost" Übertragung ist schon richtig. >Die entsprechenden PINs am FPGA habe ich alle als IN , CMOS 3,3V und >FAST per UCF File definiert. Ist egal, die Schutzdioden sind IMMER da. >Beispiel: Je Zeile werden die Farbanteile im Bild linear aufsteigend >definiert. >Über das Spartan interne Dual Port Ram mit 2 Clock Domains bekomme ich >dann häufig folgende Lesefehler: Ich hoffe mal, dass du im Betrieb das Board sauber mit Spannung versorgst, oder? >Muss dazu sagen ich benutze zu Testzwecken zur Zeit den Digitalen DVI >Eingang des Bausteins und nicht analogen Eingang über den AD-Wandler >Teil, so dass die Daten eigentlich exakt eingelesen werden müssten. >Ad-Wandler Ungenauigkeiten werden ja ausgeschlossen. Na dann mach mal ein Testmodul im FPGA, dass digital korrekt Daten generiert und gib die aus. Die müssen dann auf das Bit genau stimmen. MFg Falk
Hallo Falk, >Ich nehme die 5V Versorung vom PC Nezuteil und gehe auf entsprechend >beschaltete LM317 Spannungsregler ( Spannungsteiler, Siebkondensator, Das würde ich mir verkneifen. PC-Netzeile sind NICHT ungefährlich. Nimm eine kleines Steckernetzteil oder Labornetzteil. Also ich meinte das so, dass das PC-Netzteil ganz normal seinen Dienst im PC verrichtet und über einen Adapter Stecker 5V und Masse abgegriffen werden. Nun verstehe ich nicht ganz was du mit NICHT ungefährlich meinst. Sämtliche Komponenten vom PC hängen doch auch an dem Teil. Also ich hab an dem Netzteil nix modifiziert oder rumgebastet. >Wenn ich nun den Spannungsversorgungs Stecker für das Digilent Board >abziehe leuchten die LEDs vom Digi Board immer noch deutlich sichbar >schwach ebenso die Power LED. Das macht man ja auch nicht. Denn damit ist eine Schaltung ohne Spannungsversorgung mit einer Schaltung mit Spannungsversorgung verbunden. Du hast vollkommen recht, ich bin ja auch nur durch Zufall auf den Effekt aufmerksam geworden, als aus Versehen die Spannungsversorgung für das Digilent Board abgeschaltet hab, bei noch in Betrieb befindlicher Erw. Platine. >Über das Spartan interne Dual Port Ram mit 2 Clock Domains bekomme ich >dann häufig folgende Lesefehler: Ich hoffe mal, dass du im Betrieb das Board sauber mit Spannung versorgst, oder? Also normalerweise läuft das Digilent Board mit seiner eigenen Spannungsversorgung und das Erw. Board über das PC Netzteil und anschließenden Spannungsreglern. Den Masse-Pin von der Steckerleiste des Digilent Board hab ich mit der Masse von meinen Spannungsreglern verbunden. Das ist doch korrekt oder ?? Das Abklemmen der Masseverbindung hab ich nur mal zu Test-Zwecken gemacht. >Muss dazu sagen ich benutze zu Testzwecken zur Zeit den Digitalen DVI >Eingang des Bausteins und nicht analogen Eingang über den AD-Wandler >Teil, so dass die Daten eigentlich exakt eingelesen werden müssten. >Ad-Wandler Ungenauigkeiten werden ja ausgeschlossen. Na dann mach mal ein Testmodul im FPGA, dass digital korrekt Daten generiert und gib die aus. Die müssen dann auf das Bit genau stimmen. Das Problem an dem ich einfach nicht weiterkomme sieht so aus: Ein Testrechner liefert über den DVI-Ausgang von mir erstellte Testbilder. Ein gutes DVI Kabel wurde von mir auf ca. 1,5m verkürzt und möglichst nahe an den PINS des AD-Wandler Bausteins ( natürlich digitaler Eingang des Bausteins ) direkt angelötet. Die Ausgangspins des AD-Wandler Bausteines wurden jeweils mit 100 Ohm Serien Widerständen direkt auf den Stecker des Digilent Board geführt. Alle Längen möglichst gleich lang. Gesamtstrecke von den PINs des Baustein zum Stecker ca. 5cm. Nun hab ich bereits in Testmodul auf dem FPGA geschrieben. Nur kann ich die Fehler nicht zuordnen. 1. Sind die Fehler aufgrund des 1,5m langen Kabels zu suchen ? Die Länge müßte eigentlich unkritisch sein. 2. Am Ende sind die ganz kleinen DVI Anschlussleitungen ca. 4cm ohne Schirmung und auf meine Platine aufgelötet. Kommen die Fehler durch Einstrahlungen auf diesen ungeschirmten Leitungsabschnitt ? 3. Die Daten kommen dann aus dem Wandler Baustein über die Schutzwiderstände zum FPGA Eingang. Kippen dort evtl. Bits aufgrund der hohen Frequenz ??? 4. Das Einlesen der Daten in das Dual Port Ram im FPGA ist eigentlich narrensicher. Lt. Datenblatt kommt die Aufsteigende Flanke des AD-Wandler Taktes genau dann, wenn die Daten Valid sind. Was mich sehr verwundert ist die Tatsache, dass das Ändern der Pixel clock keine Veränderung der Lesefehler bewirkt. Also: z.B. 640 * 480 / 60Hz hat ja deutlich niedrigeren Pixel Clock als von mir getestete 1280 * 720 / 60 Hz. Der Fehler bleibt aber genau gleich. Hab leider kein Oszi, um mir die Daten am Stecker Digilent Steker im Bezug zum Takt anzuschauen. Gruß vom FPGA-Fragenden .. der seit ca. 6 Monaten intensiv an diesem Projekt arbeitet, als Anfänger unglaublich viele Hürden überwunden hat und jetzt eigentlich fast fertig sein wollte...
@ FPGA-Fragender (Gast) >Also ich meinte das so, dass das PC-Netzteil ganz normal seinen Dienst >im PC verrichtet und über einen Adapter Stecker 5V und Masse abgegriffen >werden. Naja, kann man machen, aber . . > Nun verstehe ich nicht ganz was du mit NICHT ungefährlich >meinst. Das Ding hat Dampf ohne Ende. Wenn du einen Kurzschluss baust bringt das locker 30A und mehr. Da verdampfen schon dünne Drähte. Mach wenigstens ne kleine Sicherung rein (1A). >Den Masse-Pin von der Steckerleiste des Digilent Board hab ich mit der >Masse von meinen Spannungsreglern verbunden. >Das ist doch korrekt oder ?? Ja. Masse muss immer verbunden werden. >Das Abklemmen der Masseverbindung hab ich nur mal zu Test-Zwecken >gemacht. AUA! >Das Problem an dem ich einfach nicht weiterkomme sieht so aus: >Ein Testrechner liefert über den DVI-Ausgang von mir erstellte >Testbilder. >Ein gutes DVI Kabel wurde von mir auf ca. 1,5m verkürzt und möglichst Warum das? Wenn es ein gutes Kabel ist, schnitzt man da nicht dran rum sondern nutzt die Stecker. >nahe an den PINS des AD-Wandler Bausteins ( natürlich digitaler Eingang >des Bausteins ) direkt angelötet. Alles nur Panikattacken. Mach ne solide Platine mit Steckverbinder. DVI Digital ist *SCHNELL!* Das spielt der Wellenwiderstand und die Terminierung eine entscheidende Rolle. Ausserdem, ein AD-Wandler mit digitalem Eingang? >Die Ausgangspins des AD-Wandler Bausteines wurden jeweils mit 100 Ohm >Serien Widerständen direkt auf den Stecker des Digilent Board geführt. Wahrscheinlcih zuviel. Nützt ausserdem wenig wenn die Leitungsimpedanzen arg daneben liegen bzw. die Masseführung schlecht ist. >Nun hab ich bereits in Testmodul auf dem FPGA geschrieben. >Nur kann ich die Fehler nicht zuordnen. Das ist schlecht. Da musst du dich schrittweise vortasten. >1. Sind die Fehler aufgrund des 1,5m langen Kabels zu suchen ? Kann sein. >Die Länge müßte eigentlich unkritisch sein. [ ] Dir ist klar, mit welchen Frequenzen bzw. Anstiegszeiten DVI-Digital arbeitet? >2. Am Ende sind die ganz kleinen DVI Anschlussleitungen ca. 4cm ohne >Schirmung und auf meine Platine aufgelötet. Kommen die Fehler durch >Einstrahlungen auf diesen ungeschirmten Leitungsabschnitt ? Ich tippe auf Reflexionen durch schlechtes Layout und Fehlanpassung. >3. Die Daten kommen dann aus dem Wandler Baustein über die >Schutzwiderstände zum FPGA Eingang. Kippen dort evtl. Bits aufgrund der >hohen Frequenz ??? Sicher nicht. >4. Das Einlesen der Daten in das Dual Port Ram im FPGA ist eigentlich >narrensicher. Everything is easy with the right tool. But a fool with a tool is still a fool. ;-) >Lt. Datenblatt kommt die Aufsteigende Flanke des AD-Wandler Taktes genau >dann, wenn die Daten Valid sind. Naja, über welche Frequenzen reden wir denn hier? 30 MHz ++. Hast du eine FlipFlop Stufe zur Abtastung in den IOs drin? >Was mich sehr verwundert ist die Tatsache, dass das Ändern der Pixel >clock keine Veränderung der Lesefehler bewirkt. Was die Vermutung der Reflexionen verstärkt. Die sind frequenzunabhängig. >Also: z.B. 640 * 480 / 60Hz hat ja deutlich niedrigeren Pixel Clock als >von mir getestete 1280 * 720 / 60 Hz. >Der Fehler bleibt aber genau gleich. >Hab leider kein Oszi, um mir die Daten am Stecker Digilent Steker im >Bezug zum Takt anzuschauen. Schlecht. >.. der seit ca. 6 Monaten intensiv an diesem Projekt arbeitet, als >Anfänger unglaublich viele Hürden überwunden hat und jetzt eigentlich >fast fertig sein wollte... Der Enspurt ist immer der schwierigste Teil. 90% der Arbeit werden in den letzten 10% der Zeit erledigt. MFG Falk
Hallo Falk, Du glaubst gar nicht wie mich das freut von jemand guten Response zu bekommen.. >Lt. Datenblatt kommt die Aufsteigende Flanke des AD-Wandler Taktes genau >dann, wenn die Daten Valid sind. Naja, über welche Frequenzen reden wir denn hier? 30 MHz ++. Hast du eine FlipFlop Stufe zur Abtastung in den IOs drin? Wie meinst Du das genau ? Also ich hab den Takt auf einen normalen Eingangspin des FPGA gelegt. Allerdings hab ich an keiner Stelle meinem FPGA irgendwie mitgeteilt, dass dieser PIN ein Clock Eingang darstellt. Der Process für das Auswerten der Sync Impulse und warten auf den sichtbaren Bildausschnitt wird dann mit diesem AD-clock direkt getaktet. Ist das falsch ? Sollte ich der ISE irgendwie mitteilen, dass dieser PIN besonders zu handhaben ist ?? Wie mach ich das. ? Die 3 * 8 Bit Daten hab ich ebenfalls einfach auf Input Pins gelegt ohne nähere Angaben. Diese Takte ich zunächst ohne Vorbedingung mit jeder steigenden Flanke des AD-Clocks in ein 24 Bit breites Register. Quasi als Entkopplung für die Laufzeit der Signale von außerhalb und innerhalb des FPGA. Was ist bei der Nutzung von Eingangsflip-flops anders ?? Bei entsprechender Sync Freigabe werden die Daten mit jeder steigenden Flanke des AD-CLK in das Dual Port Ram eingetaktet. Um sicher zu gehen ( also rein zu Testzwecken ) mach ich zunächst das ganze DP-Ram voll. Danach lesen ich mit dem normalen 50 Mhz FPGA-Takt = zweite Taktdomäne die Daten aus dem DP-Ram aus. Die Signale die das Auslesen usw. steuern laufen als Process mit dem FPGA-Takt. Das mit dem AD-Wandler und digitalen Daten hat folgende Bewandnis. Der AD9880 Baustein hat sowohl analog und dvi digital Einang. Zur Verifikation der Schaltung verwende ich den DVI Digitaleingang, weil hier die "Proglematik" der AD-Wandlung kein Problem darstellt. ( Hier muss der Baustein wesentlich komplizierter konfiguriert werden ) Bei digitalem Eingang wird der CLK der TMDS Signale der Graka verwendet. Ich weiß, der Takt ist irrsinnig hoch. ( ca. pixel clock * 10 wow ) Sobald das Gesamtsystem mit dem Digitaleingang läuft, kann ich mich speziell auf die AD Wandlung konzentrieren und hab nicht so viele Fehlerquellen. Problem Leitungsanpassung: Also lt. dem Schaltplan von Eval Boards von Analog werden die DVI TMDS Signale direkt auf den Baustein geführt ohne irgendwelche Zusatzbeschaltung. Ist das nicht richtig ? Gruß vom FPGA-Fragenden
@ FPGA-Fragender (Gast) >>Hast du eine FlipFlop Stufe zur Abtastung in den IOs drin? >Wie meinst Du das genau ? Es sollte/muss ein FlipFlop direkt in der IO- Zelle platziert werden, um die Daten direkt dort abztutasten. >Also ich hab den Takt auf einen normalen Eingangspin des FPGA gelegt. Glaub ich nicht, dann meckert ISE. Takte können in erste Linie nur auf spezielle Taktpins gelegt werden (GCKx). Das hast du wahrscheinlich unbewusst gemacht. >Allerdings hab ich an keiner Stelle meinem FPGA irgendwie mitgeteilt, >dass dieser PIN ein Clock Eingang darstellt. Muss man nicht, erkennt die Software automatisch. >Der Process für das Auswerten der Sync Impulse und warten auf den >sichtbaren Bildausschnitt wird dann mit diesem AD-clock direkt getaktet. Zeig mal deinen Code. >Die 3 * 8 Bit Daten hab ich ebenfalls einfach auf Input Pins gelegt ohne >nähere Angaben. Diese Takte ich zunächst ohne Vorbedingung mit jeder >steigenden Flanke des AD-Clocks in ein 24 Bit breites Register. Genau das meine ich. Nun muss diese Register nur noch in den IOs platziert werden. Dazu gibt es in den Mapper-Optinen eine Einstelluung. >Was ist bei der Nutzung von Eingangsflip-flops anders ?? Das IST die Nutzung der Eingangsflipflops. >Danach lesen ich mit dem normalen 50 Mhz FPGA-Takt = zweite Taktdomäne >die Daten aus dem DP-Ram aus. Die Signale die das Auslesen usw. steuern >laufen als Process mit dem FPGA-Takt. Naja, vorsichtig. Das Ganze muss solide synchronisiert werden, damit das Auslesen mit dem Einschreiben nicht kollidiert. Das passiert bei dir wahrscheinlich. >Ich weiß, der Takt ist irrsinnig hoch. ( ca. pixel clock * 10 wow ) EBEN! 300 MHz++ >Also lt. dem Schaltplan von Eval Boards von Analog werden die DVI TMDS >Signale direkt auf den Baustein geführt ohne irgendwelche >Zusatzbeschaltung. Ist das nicht richtig ? Kann man ohne Bild/Layout nicht sagen. MFG Falk
Hallo Falk, >Also lt. dem Schaltplan von Eval Boards von Analog werden die DVI TMDS >Signale direkt auf den Baustein geführt ohne irgendwelche >Zusatzbeschaltung. Ist das nicht richtig ? Kann man ohne Bild/Layout nicht sagen. Hier der Link zu einem Eval Board für den AD9887. Man sieht sowohl im Schaltplan als auch im Layout der Platine, dass die TMDS Leitungen direkt auf den Baustein gehen und nur ein 500 Ohm Term Widerstand gegen Masse am Baustein anliegt. Die geforderten 50 Ohm Leitungsanpassungs Widerstsände müssen also intern sein. ( Oder ich hab mal wieder was falsch verstanden ??? ) http://www.analog.com/UploadedFiles/Evaluation_Boards/Tools/182062315AD9887AEB_0.pdf Ich hab mir gestern nochmal die Mühe gemacht und das lange Ende des DVI Kables durch das kurze ende auszutauschen. Sprich, ich hab nun ein DVI Kabel mit Stecker in der Graka des PC mit Länge ca. 45cm und das andere Ende auf der Platine angelötet. Außerdem hab ich diesmal darauf geachtet, dass die Innenschirmung für jeweils 1 Adernpaar erhalten bleibt und nur ganz kurz vor der Lötstelle entfernt wird, also Schirmung der Adernpaare bis fast auf die Platine. Ergenis ist leider enttäuschend. Lesefehler bleibt nach wie vor. Das fatale ist nun folgender Effekt: ( der vorher auch schon vorhanden war) Wenn ein Lesefehler beim H-Synch , als Zeilen wechsel Impuls auftritt, ist das gut zu erkennen. Im DP-Ram werde die Bilddaten von z.B. Zeile 213 bis. 223 eingelesen, statt z.B. Zeile 28 ...38. ( Zeile 28 ist Ende des Blanking Bereiches und Anfang der sichtbaren Bild-Daten. Manchmal klappt das ja auch , dann eben wieder nicht. ICH HAB JETZT ERSTMAL AUFGEGEBEN !!!!!! ( schniiieeeeeefffff, seufz ) Gestern hab ich alle Kabel und Adapterplatinen usw. zusammengepackt in einen Karton verstaut weit weg irgendwo auf den hintersten Schrank im Haus. Ich bin jetzt an einem Punkt angelant, wo ich ohne weitere praktische Hilfe nicht mehr weiterkomme. Die AD9880 Adapterplatine hat mich jetzt soviel Nerven gekostet, dass mir der Spass vergangen ist. Bis ich den 100 Pin QFP mit 0,5 mil Abstand per Hand auf die Adapterplatine gelötet hatte und das ganze mit Stützkondensatoren versehen war und dann alle 100 Pins vom Baustein korrekt verdrahtet...... Ich denke ich bräuchte eine professionelle multilayer Adapterplatine mit Masse Layer und SMD Block- Kondensatoren ganz unmittelbar an den PINs des Bausteins, wie das in den Layout Empfehlungen von Analog ja auch empfohlen wird. Leider ist so eine Platine nirgends einzeln zu bekommen. Wenn irgend jemand hier mitliest und weiß, wo man so eine Adapter-Platine mit DVI bzw. HDMI eingang und wenn möglich RGV, YUV Analog eingang herbekommt bitte gerne den Link posten. Eval Boards mit FPGAs bestückt sind für mich zu teuer. ( ca. 1200 Dollar aufwärts ) Gruß vom FPGA-Fragenden, der wirklich unglaublich weit gekommen ist, was ich anfänglich nie gedacht hätte.
@ FPGA-Fragender (Gast) >Hier der Link zu einem Eval Board für den AD9887. >http://www.analog.com/UploadedFiles/Evaluation_Boa... Sieht brauchbar aus. >Im DP-Ram werde die Bilddaten von z.B. Zeile 213 bis. 223 eingelesen, >statt z.B. Zeile 28 ...38. ( Zeile 28 ist Ende des Blanking Bereiches >und Anfang der sichtbaren Bild-Daten. >Manchmal klappt das ja auch , dann eben wieder nicht. >ICH HAB JETZT ERSTMAL AUFGEGEBEN !!!!!! ( schniiieeeeeefffff, seufz ) Naja, ohne halbwegs gescheite MEsstechnik tappst du da ziemlich im Dunkeln. >Bis ich den 100 Pin QFP mit 0,5 mil Abstand per Hand auf die >Adapterplatine gelötet hatte und das ganze mit Stützkondensatoren >versehen war und dann alle 100 Pins vom Baustein korrekt >verdrahtet...... Poste doch mal ein Bild davon, unter Berücksichtigung der Bildformate. >Ich denke ich bräuchte eine professionelle multilayer Adapterplatine mit >Masse Layer und SMD Block- Kondensatoren ganz unmittelbar an den PINs >des Bausteins, wie das in den Layout Empfehlungen von Analog ja auch >empfohlen wird. Kann nicht schaden. >Leider ist so eine Platine nirgends einzeln zu bekommen. Selber machen. GGf. reicht eine doppellagige Platine. >Eval Boards mit FPGAs bestückt sind für mich zu teuer. ( ca. 1200 Dollar >aufwärts ) Aber das Eval Board von dem IC kostet doch keine 1200 Dollar. MFG Falk
Nicht so schnell aufgeben ;) Hast du mal den Analog Eingang versucht ? Oder was du auch noch machen koenntest: (Etl meinte Falk sowas in der Art oben schon) Ein vhdl modul schreiben was dir das dvi IC emuliert. Also ein vhdl modul mit den selben I/Os wie das IC jedoch einfach ein Testsignal intern erzeugen (zb r,g,b jeweils durch zaehler erzeugen -> farbverlauf). Das bindest du dann anstelle den DVI inputs ein. Wenn dann alles stimmt hast du wirklich ein problem mit dem IC/DVI signalen. Wenn es damit aber immer noch nicht klappt dann hast du in der Weiterverarbeitung einen bug (kann man ja mal leicht was uebersehen). Das sollte schnell zusammengehackt sein da du dich ja (hoff ich mal) mit dem Ausgabeprotokoll des DVI ICs auseinander gesetzt hast ;) Also einfach das Protokoll laut datenblatt nachbilden und fertig :) Sind deine Lesefehler wirklich immer sowas wie 125, 126 ,126 anstelle 125,126,127 oder auch mal was wie 125, 126, 63 ? sprich: springt da ein bit (zufaellig) um oder bekommst du wirklich den vorgehenden wert nochmal ? Letzteres wuerde eher auf irgendeinen bug in der ram ansteuerung oder so hindeuten ;) Viel glueck!
Hallo Ssssss und Falk, ich finde das ganz toll dass, Ihr mir Mut machst nicht aufzugeben. >Hast du mal den Analog Eingang versucht ? Ja, aber aufgrund der noch wesentlich höheren Anzahl von Fehlerquellen, die sich durch die DA-Wandlung ergeben hab ich dan dem Ende erstmal nicht weitergemacht. DVI ist unkomplizierter, wobei der analoge Teil eigentlich das Ziel war. >Oder was du auch noch machen koenntest: (Etl meinte Falk sowas in der >Art oben schon) >Ein vhdl modul schreiben was dir das dvi IC emuliert. >Also ein vhdl modul mit den selben I/Os wie das IC jedoch einfach ein >Testsignal >intern erzeugen (zb r,g,b jeweils durch zaehler erzeugen -> >farbverlauf). >Das bindest du dann anstelle den DVI inputs ein. >Wenn dann alles stimmt hast du wirklich ein problem mit dem IC/DVI >signalen. Mal ein Überblick über meine Gesamtstruktur: SRAM: Dieses wird über ein eigenes Modul angesteuert. Der SRAM controller läuft als interleave Modus, d.h. er kann 3 Clients quasi gleichzeitig bediehnen. 1. Client: USB Modul. Über eine externen Cypres FX2 Erw. Platine habe ich eine High Speed USB Anbindung realisiert. Diese schreibt / liest jeweils in 512 Byte großen Blöcken Daten in einen frei vorgebbaren Bereich des SRAMs. Über ein eigenes Master Controller Modul wird jeweils der erste Block der 512 Byte Block Sequenz ausgewertet und dem Controller genau mittgeteilt, was er zu tun hat. Also z.B. lese / schreibe den 10 bis 58 zigtsten 512 Byte Block aus dem SRAM / in das Block RAM. Diese Funktionen wurde gründlich durch und durch getestet und laufen absolut verläßlich. 2. Client Interner logic Analyser: Weil ich bei manchen VHDL Fehlern nicht weiterkam hab ich mir einen eigenen FPGA internen logic Analyser als Modul gebaut. Dieser besteht aus 2 DP-RAMs mit je 512 Byte Tiefe und 64 Bit Breite. Es ist über den o.g. Master controller möglich die Stimuli Daten in das SRAM und von dort per weiteren Befehl in das DP-RAM zu schreiben. Über einen weiteren Command kann die Simulation dann gestartet werden und die Signale, welche mich interessieren werden als Dateneingang auf das RECORD DP-RAM gegeben. Dieses wiederum kann dann über den Umweg über das SRAM ausgelesen werden. Über eine eigene Host Software auf dem PC kann ich also ganz genau vorgeben, welches 64 Bit Simulations Muster ich / je Takt ausgeben will und die mich interessierenden Daten / je Takt einlesen. Das Teil ist ebenfalls gründlichst durchgestestet und funktioniert ebenfalls einwandfrei. 3. Client FPGA Logic ( Die Schaltung die eigentlich entwickelt werden soll) Über eine eigene Zeitschlitz Freigabelogic vom SRAM Ctrl weiß die eigentliche FPGA Logic, wann Sie auf das SRAM zugreifen darf. Also die eigentliche Schaltung ( = Bild und Ton / Kompression ) Kann die Daten über diesen Port in das SRAM schreiben bzw. lesen. Diese Funktion wurde auch gründlichst und vielfältig getestet. Einlesevorgang der DAten vom AD9880 ==================================== Ich habe also beim einlesen der Daten vom AD9880 2 Möglichkeiten a. die Daten werden direkt von der FPGA Logic in das SRAM geschrieben und über meine o.g. Betriebssystem zum PC übertragen und parallel dazu b. die Daten werden über meinen internen Logic analyser in ein DP-RAm eingelesen und dann über das SRAM über mein getestetes Betriebssystem an den Host übertragen. Im Augenblick lese ich die Daten in ein DP-RAM mit der AD9880 Clock Domäne und mit der FPGA clock Domäne lese ich die DAten per internem logic analyser. Meine Versuche haben ergeben, dass von den 3 * 8 Bits nichts hardwaremäßig klemmt. Also alle Bitmuster von 0 bis 255 laufen durch. Aber mit den o.g. Wiederholungs fehlern, welcher eben auch auf den Sync Signalen sind und deshalb das ganze Bild verhacken. Die Nadel im Heuhaufen suchen macht keinen Spass und ich hab einfach nicht das entsprechende Meßequippment. Ich gehe mittlerweile davon aus, dass meine Spannungsversorgung für den Chip nicht stabil genug ist und deshalb bereits am Ausgang des AD9880 falsche Daten ausgegeben werden, aber wer weiß ??? Die Eval Board Karten von Analog werden nicht mehr produziert bzw. die die bei Digi-key erhältlich wären kosten ca. 400 Dollar + Versand + Zoll usw. Gruß vom FPGA-Fragenden
@ FPGA-Fragender (Gast) >Mal ein Überblick über meine Gesamtstruktur: Zeichne mal ein Blockdiagramm. Ein Bild sagt mehr als tausend Worte. >Diese Funktionen wurde gründlich durch und durch getestet und laufen >absolut verläßlich. Jaja, das denkt man meist. Aber oft gilt das nur für den Betrieb des Moduls allein. Im Zusammspeil mit den anderen Komponenten kann das schon wieder anders aussehen. >Das Teil ist ebenfalls gründlichst durchgestestet und funktioniert >ebenfalls einwandfrei. Expect the unexpected! >Über eine eigene Zeitschlitz Freigabelogic vom SRAM Ctrl weiß die >eigentliche FPGA Logic, wann Sie auf das SRAM zugreifen darf. Hoffentlich kann sie kleine Zeiten zwischenpuffern. >Also die eigentliche Schaltung ( = Bild und Ton / Kompression ) Ne Menge Holz für nen VHDL-Anfänger! >Die Nadel im Heuhaufen suchen macht keinen Spass und ich hab einfach >nicht das entsprechende Meßequippment. Ich gehe mittlerweile davon aus, Mensch, es wurde doch schon ein kleiner, guter Ansatz genannt. BAU EINEN EMULATOR FÜR DEN AD-WANDLER! >dass meine Spannungsversorgung für den Chip nicht stabil genug ist und >deshalb bereits am Ausgang des AD9880 falsche Daten ausgegeben werden, >aber wer weiß ??? Reine Spekulation ohne Indizien. Gehe schrittweise vor und sichere die einzelnen Stufen. Wenn du irgendwann mal an den Eingangspins angekommen bist, musst du halt irgendwie eine gutes Oszi besorgen (leihweise) und messen. MfG Falk
Hallo Falk, >Mensch, es wurde doch schon ein kleiner, guter Ansatz genannt. >BAU EINEN EMULATOR FÜR DEN AD-WANDLER! Ich glaube jetzt ist bei mir der Groschen gefallen. Also wenn ich Euch richtig verstehe 1. AD-Erw. Plantine abtrennen 2. Ein Modul schreiben, welches z.B. 8 Bit Daten und V-Sync, H-Sync erzeugt und diese Daten auf echte Ausgangspins legen. 3. Diese Daten dann über die Eingangspins meiner Schaltung als Stimuli verwenden und schauen ob alles richtig gelesen wird ? OK auf diese Weise kann ich meine Schaltung auf logisch richtige Funktion testen. Der externe Takt des AD, welcher ja völlig unsynchron zu meinem FPGA Takt läuft, sollte dabei auch simuliert werden. Wie mach ich sowas ? Müßte über eine DCM gehen. Wenn ichs richtig weiß kann ich damit einen krummen Takt erzeugen z.B. 4/5 des FPGA Taktes, welcher zu meinem FPGA Takt eine einstellbare phasenverschiebung hat. Hab ich jetzt verstanden was ihr meintet ? Gruß vom FPGA-Fragenden
>Ein Modul schreiben, welches z.B. 8 Bit Daten und V-Sync, H-Sync >erzeugt und diese Daten auf echte Ausgangspins legen. Nciht unbedingt auf die Ausgangspins, erstmal direkt im fpga verdrahtet. Um es simpel zu halten nimm erstmal denselben takt wie sonst im design. Wenn das laeuft dann bau dir einen mit einer dcm. Ich vermute aber es wird auch mit dem normalen takt nicht gehen ;) Bzgl testen von Einzelkomponenten: Wenn du da irgendwodrin murks gebaut hast kann unter anderem folgendes passieren: - synthese nur mit dem modul -> geht - synthese mit allen modulen -> design komplexer -> anderes routing -> kritischeres timing -> irgendwo vermurksten asynchronen kram drin (nur nen beispiel) -> zack geht nicht mehr ;)
@ FPGA-Fragender (Gast) >1. AD-Erw. Plantine abtrennen Kann dranbleiben. >2. Ein Modul schreiben, welches z.B. 8 Bit Daten und V-Sync, H-Sync >erzeugt und diese Daten auf echte Ausgangspins legen. Jain. Das Modul ist auch im selben FPGA und wird anstatt der IO-Pins angeschlossen. >3. Diese Daten dann über die Eingangspins meiner Schaltung als Stimuli >verwenden und schauen ob alles richtig gelesen wird ? Jain, die Pins haben damit nix mehr zu tun. Damit ist die Fehlerquelle IO-Pins, Reflexionen etc. ausgeschlossen. >Der externe Takt des AD, welcher ja völlig unsynchron zu meinem FPGA >Takt läuft, sollte dabei auch simuliert werden. Den sollte man zum Takten des Emulatormoduls verwenden. Uund es ist eine Emulation, keine Simulation. >Müßte über eine DCM gehen. Nein. Lass das mal lieber weg. Am sichersten ist, einen normalen Quarzoszillator mit möglichst der gleichen Freqeunz wie dein AD-Wandler zu nehmen, in ein freies Taktpin einspeisen und zum Takten des Emulator benutzen. > Wenn ichs richtig weiß kann ich damit einen >krummen Takt erzeugen z.B. 4/5 des FPGA Taktes, welcher zu meinem FPGA >Takt eine einstellbare phasenverschiebung hat. Wozu DAS DENN??? >Hab ich jetzt verstanden was ihr meintet ? Noch nicht ganz. @ Ssssss (Gast) >- synthese mit allen modulen -> design komplexer -> anderes routing -> >kritischeres timing Das sollte duch ein einfaches Timingconsztraint abgefangen werden. Hoffentlich ist im UCF mindesten der Takt für den AD-Wandler und das FPAG angegeben? net fpga_takt period=xxns; net ad_takt period=yyns; > -> irgendwo vermurksten asynchronen kram drin (nur >nen beispiel) -> zack geht nicht mehr ;) DAS sollte auf jeden Fall nicht drin sein. Da kann man auf auf die Warnungen vom Compiler schauen (Latches, Gated clock etc.) Aber alles findet der auch nicht. MfG Falk P.S. Wenn du antwortest, dann bitte entweder mit einem CLick auf "Antwort mit Zitat" oder die Zitate manuell mit ">" (ohne Gänsefüsschen) markieren. Sonst ist dein Posting schlecht lesbar.
>DAS sollte auf jeden Fall nicht drin sein. Da kann man auf auf die >Warnungen vom Compiler schauen (Latches, Gated clock etc.) Aber alles >findet der auch nicht. Als Anfaenger baut man sowas aber schnell mal ein ;) Als ich mit vhdl angefangen habe hatte ich auch mit sowas zu kaempfen. Design minimal erweitert -> nur noch murks ergebnisse Dann nach und nach verstanden was man tut und was nicht (synchrones design etc) und siehe da seitdem kaempfe ich nichtmehr mit diesen problemen g
Hallo zusammen, >Bzgl testen von Einzelkomponenten: >Wenn du da irgendwodrin murks gebaut hast kann unter anderem folgendes >passieren: >- synthese nur mit dem modul -> geht >- synthese mit allen modulen -> design komplexer -> anderes routing -> >kritischeres timing -> irgendwo vermurksten asynchronen kram drin (nur >nen beispiel) -> zack geht nicht mehr ;) Ich denke ich verstehe die Problematik, die du damit ansprichst. Das Problem hatt ich anfangs bzgl. dem SRAM CTrl. > Wenn ichs richtig weiß kann ich damit einen >krummen Takt erzeugen z.B. 4/5 des FPGA Taktes, welcher zu meinem FPGA >Takt eine einstellbare phasenverschiebung hat. Wozu DAS DENN??? Ich wollt halt einen externes Quarzoszillator vermeiden und den ext. Quarzoszillator durch einen krummen phasenverschobenen DCM generierten Takt ersetzen. Nachdem Ihr mich ermutigt habt, werd ich das Material nochmal auspacken und mich nochmal dransetzen. Jetzt hab ich zumindest eine Möglichkeit den Fehler besser einzugrenzen. 1. Ich werde natürlich zuerst die logische Arbeitsweise testen, d.h. das Emulator Mudul mit FPGA Takt takten 2. Sollte das funktionieren werde ich einen ext. quarzoszillator nehmen und testen, ob die Schaltung mit 2 Clock Domains funktioniert. Gruß vom FPGA-Fragenden
@ FPGA-Fragender (Gast) >Ich wollt halt einen externes Quarzoszillator vermeiden und den ext. >Quarzoszillator durch einen krummen phasenverschobenen DCM generierten >Takt ersetzen. Und einen neue Front/Problemquelle aufmachen? Keine gute Idee. Deine Schritte sind voll korrekt. MFG Falk
Hallo zusammen,
wollt mal einen Zwischenstand geben.
Ich habe gestern alles nochmal "ausgepackt" und losgelegt.
1. Ein neues Modul Ad_EMU geschrieben welches folgendes leistet:
- Generierung von zyklisch wiederholenden
- H-Sync und V-Sync Signal
- einstellbare Länge des H-Sync und V-Sync Impuls ( Anzahl Takte )
- einstellbare Pausenzeit, Anzahl Pixel/ Zeile und Anzahl Zeilen
/Bild.
- Die Bilddaten R - aufsteigende Helligkeit mit Wert= Spaltenpos vom
Bild
G - absteigende Helligkeit
B - aufsteigende Helligkeit mit Wert = Zeilenpos vom
Bild
- Takteingang ist der "normale" FPGA Takt
2. Testbench dafür erstellt und im Simulator getestet alles ok
3. Signale des Emulators mit den Eingängen meiner Schaltung verbunden
Real Life Test durchgeführt. Takt 50 MHz
Läuft alles super !!
Einlesezyklus kann vielfach wiederholt werden und es werden immer die
gleichen Daten richtig eingelesen
Folgender Flow:
Bilddaten kommen aus dem Emulator
=> Mein Einlesemodul ( AD-Wandler Taktdomäne ) schreibt Daten in DP-RAM
mit 2 Taktdomänen
=> int. Logic Analyser liest die Daten aus DP-RAM und Protokolliert die
Daten in einem eigenen Aufnahme DP-RAM ( alles in FPGA Taktdomäne )
=> Master Controller holt die Daten aus dem Aufnahmer DP-RAM und liest
sie in das S-RAM
=> Master Controller liest die Daten aus SRAM über USB zum PC
=> PC vergleicht Wertet Daten aus.
Fazit: Die logisch richtige funktionsweise der Schaltung ist ab den
Eingangspins sichergestellt, wobei noch nicht mit einer 2. Taktdomäne
für den Einleseteil gearbeitet wird.
Nun meine Frage:
Wie genau soll ich jetzt mit dem zustätzlichen externen Quarzoszillator
( QO) vorgehen.
Wenn ichs richtig verstehe bleiben die o.g. Konfiguration exakt gleich,
lediglich der Takt vom QO wird als Takteingang für das Eumlations-Modul
und das Einlesemodul verwendet, richtig ?
Allerdings entspricht das dann nicht dem was ich ja eigentlich emulieren
möchte.
Eigentlich möchte ich doch EINGANGSDATEN AN DEN PINS herstellen, die das
Timing vom AD-WAndler Ausgang nachbilden. Also Takt, H-Sync, V-Sync und
zumindest 8 bit Farben.
Ich steh wohl grad auf dem Schlauch.
Würdet Ihr mir das bitte nochmals erläutern ?
Ganz herzlichen Dank
Gruß vom FPGA-Fragenden
@ FPGA-Fragender (Gast) >Fazit: Die logisch richtige funktionsweise der Schaltung ist ab den >Eingangspins sichergestellt, wobei noch nicht mit einer 2. Taktdomäne >für den Einleseteil gearbeitet wird. Sehr gut! >Wenn ichs richtig verstehe bleiben die o.g. Konfiguration exakt gleich, >lediglich der Takt vom QO wird als Takteingang für das Eumlations-Modul >und das Einlesemodul verwendet, richtig ? Ja. >Eigentlich möchte ich doch EINGANGSDATEN AN DEN PINS herstellen, die das >Timing vom AD-WAndler Ausgang nachbilden. Also Takt, H-Sync, V-Sync und >zumindest 8 bit Farben. Nein. Erstmal willst die logisch richtige Funktion mit zwei asynchronen Takten testen. Wenn das läuft ist es zu 99% ein Problem bei der Datenübertragung AD-Wandler FPGA. Dann muss ein gutes Oszi mit guten Taktköpfen her (300MHz++). MFG Falk
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.