www.mikrocontroller.net

Forum: FPGA, VHDL & Co. "Ghost" Spannungsübertragung bei Spartan 3 Board?


Autor: FPGA-Fragender (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: FPGA-Fragender (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: FPGA-Fragender (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: FPGA-Fragender (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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_Boa...


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.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: Ssssss (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: FPGA-Fragender (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: FPGA-Fragender (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ssssss (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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 ;)

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  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.

Autor: Ssssss (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: FPGA-Fragender (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: FPGA-Fragender (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

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.