CLK Durchschleifen

[Ramon F. (tronixx)]

Hallo zusammen,

seit Tagen sitze ich vor einem Problem, welches ich irgendwie nicht so
richtig in den Griff bekomme und hoffe einfach mal darauf, dass jmd. von
euch mir evtl. helfen kann

Mein Ziel war es eine bestehende Videokommunikation (siehe Abb.)
aufzutrennen, bzw. die Signale zu duplizieren, um diese einmal wieder
wie im Original an das ursprüngliche Display zu senden, zum andern über
ein FPGA-Board einzulesen, ggf. zu scalen und an ein zweites Display
höherer Auflösung wieder auszugeben. Prinziepiell funktioniert das
Ganze.

Nun zu meinem Problem.
Da die Leitungen via Flachbandkabel übertragen werden (ca. 30 cm) treten 
Reflexionen auf der Clk-Leitung (9 MHz) auf. Dem Original-Display ist 
das egal, nur mein FPGA sieht dann am Eingang Flanken wo keine seien 
sollten.

Hab das Ganze mit Terminierung schon etwas in den Griff bekommen, aber 
nicht vollständig. (ohne das Original-Display funktioniert alles, d.h. 
keinerlei Reflexion!!!!!!).

Jetz habe ich die CLK-Leitung vor dem Y-Adapter aufgetrennt und direkt 
an das FPGA geführt, durchgeschleift und von da aus das Original-Display 
angesteuert. Auch hier meckert dieses überhaupt nicht.

Problem: mein FPGA erkennt den CLK jetz gar nicht mehr????
Kann ja eig nur an meiner Umsetzung in VHDL liegen.
Ich weiss das man den CLK hegen und pflegen sollte, die Frage ist aber 
in dem Fall wie ? :)

clk_in   :   in std_logic;
clk_out  :  out std_logic;
.....



--Kombinatorik:

clk_out <= clk_in;
.....

process (clk_in)
begin
       if rising_edge (clk_in)
       .........

also was mache ich hier grundlegend falsch? Brauche ich noch Buffer etc.
clk_in läuft über einen speziell dafür vorgesehenen Pin!!

hoffe jmd kann mir einen tipp geben

[Thomas L. (thomas_hx)]

Und wenn Du den Adapter rausschmeist und das Signal für Display 1 
einfach durch das FPGA Routest?

[Ramon F. (tronixx)]

ich hab  ja 18 Bit parallel RGB + clk + DE aber nicht genug IOs um 
einzulesen und 2 mal auszugeben.

mein porblem ist ja das bei der oben dargestellten vhdl variante mein 
fpga den takt gar nicht erst erkennt, d.h. der takt wird zwar 
durchgeschleift und kommt auch am D2 an, mein FPGA reagiert aber auf 
keine Flanke, also als ob kein signal anliegen würde

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Ramon F. schrieb:
> also als ob kein signal anliegen würde
Und was sagt das Oszilloskop?

Ramon F. schrieb:
> Da die Leitungen via Flachbandkabel übertragen werden (ca. 30 cm) treten
> Reflexionen auf der Clk-Leitung (9 MHz) auf.
Wie hast du das festgestellt?
Wie wäre es, wenn du da eine (Serien-)Terminierung vorsehen würdest?

[Ramon F. (tronixx)]

>Und was sagt das Oszilloskop?
Naja leider nicht viel, ich hab keins :(

>Serienterminierung?
Ist drin

also ich versuch mein Problem noch einmal detailierter darzustellen.
Bezogen auf die Abbildung oben.

Wenn ich die Daten einzig und allein mit dem FPGA abgreife, speichere, 
konvertiere etc. und auf Display2 ausgebe, funktioniert alles soweit.
Wenn ich über den Y-Adapter gehe (mit Display1) hab ich natürlich aus 
einem ursprünglich angepassten 2-Tor ein 3-Tor gebastelt. Folge ist 
demnach eine Fehlanpassung -> Reflexionen.

Mehrere Tests haben mir gezeigt, dass das Hauptproblem mit der 
Taktleitung zu tun hat. Da ich nicht mehr viele IOs zur Verfügung habe, 
dachte ich mir nur den GLK erst durch das FPGA zu schleifen und von da 
aus direkt an Display 1 zu gehen. Alle anderen Leitungen (RGB+De) laufen 
wie ursprünglich über den Y-Adapter.

Jetz passiert aber folgendes:
1.Fall: alles angeschlossen: Original-Display 1 läuft einwandfrei
                            FPGA erkennt keine eine Taktflanke mehr

2. Fall: CLK-Verbindung zwischen FPGA_out und OriginalDisplay_in 
unterbrochen:

           Original-Display 1 läuft nicht mehr, da der Takt fehlt ( 
macht ja auch Sinn) und jetz erkennt mein FPGA den Takt auch wieder und 
arbeitet sorgenlos.


Also ich hab ja nichts anderes gemacht , als das ich den Y-Abzweig der 
CLK-Leitung vom Adapter ins FPGA verschoben habe.

Gibts andere Möglichkeiten wie ich das in VHDL umsetzen kann ?
Das kann ja eig nicht an Reflexionen liegen, da ich gar keine flanke 
mehr sehe.
Habs mim bufferport versucht- auch ohne Erfolg

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Ramon F. schrieb:
>> Und was sagt das Oszilloskop?
> Naja leider nicht viel, ich hab keins :(
Woher weißt du dann, dass dein Problem Reflexionen sind?

> Wenn ich über den Y-Adapter gehe (mit Display1) hab ich natürlich aus
> einem ursprünglich angepassten 2-Tor ein 3-Tor gebastelt. Folge ist
> demnach eine Fehlanpassung -> Reflexionen.
Du kannst das nicht so einfach folgern. Das stimmt nur, wenn die Enden 
nicht terminert sind...

> Mehrere Tests haben mir gezeigt, dass das Hauptproblem mit der
> Taktleitung zu tun hat.
Dir ist klar, dass es die Taktleitung allein nur die kleinere Hälfte der 
Miete ist? Zur Taktleitung gehört auch immer das Bezugspotential (aka. 
Masse, GND).

> Gibts andere Möglichkeiten wie ich das in VHDL umsetzen kann ?
Das ist kein VHDL-Problem. Das ist ein Hardwareproblem. Du brauchst 
geeignete Messgeräte. Zuallererst ein Oszilloskop.

[Dieter (Gast)]

Ramon F. schrieb:
>>Und was sagt das Oszilloskop?
> Naja leider nicht viel, ich hab keins :(

wer macht denn FPGA Entwicklung ohne Scope? Das erinnert mich an einen 
ehemaligen Controller der einen Kollegen in der Entwicklung fragte wofür 
er denn einen Lötkolben für 300 € bestellt hat. Tritt mal Deinem Chef in 
den Hintern dass Du nen DSO bekommst. Muss ja kein LeCroy sein, aber 500 
MHz Bandbreite und bezahlbar sind schon ein Anfang (auch für zukünftige 
Projekte). Ab 1 GHz wirds dann teuer, aber immernoch günstiger als wenn 
der Ing. 1 Monat im dunkeln rumtappt.

[Freddy (Gast)]

Ramon F. schrieb:
> clk_out <= clk_in;
> .....
>
> process (clk_in)
> begin
>        if rising_edge (clk_in)

was für ein FPGA hast Du?
Nimm mal einen Clock Buffer und passe Deine Timing Constraints an den 
clk_out an.
Wobei das Problem mit den Reflexionen nach wie vor besteht und gelöst 
werden muss.

[J. S. (engineer)]

Bei 9 MHz trotz Abschluss noch relevante Reflektionen auf der Leitung? 
Kommt mir etwas seltsam vor.

Warum filterst Du sie nicht einfach weg? Du musst / solltest 9MHz nicht 
als echten Takt für einen FPGA verwenden, zumal es einige Typen gibt, 
die erst ab 10 aufwärts korrekt arbeiten, z.B. der Cyclone II, meine ich 
mich zu erinnern ab 11 MHz. Am Besten Du sampeltest Daten und Takt und 
prozessierst bei einer sauberen Flanke, in dem Du den einlaufenden Takt 
mit dem Solltaktmuster faltest:

Beitrag "Re: Takt sieht schlimm aus - FPGA-Eingang optimieren?"

Diese etwas aufwändigere Taktinterpretation verhindert die Reaktion auf 
einzelne spikes. Wenn es aber tatsächlich nur Reflektionen sind, kannst 
Du auch direkt auf die erste Flanke reagieren und mit einem timeout 
arbeiten.

[Ramon F. (tronixx)]

so ,

mir ist für einen Tag ein Oszi in die Hände gefallen, was meine ganzen 
Überlegungen übern haufen schmeisst.

Problem liegt nicht an Reflexionen sondern allg. an der Amplitude.

Das Original-Display eine geringe Impedanz (ca. 30-40 Ohm).
Am FPGA CLK-Input selbst hab ich nur 2V   !!!!! UNd ich geh stark davon 
aus das hier mein Problem sitzt.


Das Orinale Display kommt anscheinend damit klar, mein FPGA aber nicht.

So, jetz sollte ich das Problem doch mit einen OP-Impedanzwandler, siehe 
Abb.t1 lösen können?

Oder gehts noch einfacher ?

MfG

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Ramon F. schrieb:
> Problem liegt nicht an Reflexionen sondern allg. an der Amplitude.
Wie sieht dein Taktsignal ohne Display aus?

> Am FPGA CLK-Input selbst hab ich nur 2V   !!!!!
Und wieviel brauchst du da?

> So, jetz sollte ich das Problem doch mit einen OP-Impedanzwandler, siehe
> Abb.t1 lösen können?
Analogtechnik ist hier irgendwie Käse, oder nicht? Insbesondere, wenn 
dein OP dann auf jeden Fall mit mindestens 50..70 MHz zu kämpfen hat.
Digitale Signale werden am besten durch digitale Bausteine 
weiterverarbeitet. In deinem Fall wäre das ein Buffer...

[Ramon F. (tronixx)]

>Wie sieht dein Taktsignal ohne Display aus
saubere 3,3V

>Analogtechnik ist hier irgendwie Käse, oder nicht?
Stimmt, an sich muss ich ja nur dafür sorgen, das das Original-Display 
die Amp nicht runter zieht.
Also du meinst so ein 100MHz-OP schafft das nicht?
Kannst du mir aus dem Stehgreif einen bestimmer Taktpuffer empfehlen ? 
habe dahingehend leider noch keine Erfahrung.

[Ramon F. (tronixx)]

>>Am FPGA CLK-Input selbst hab ich nur 2V   !!!!!
>Und wieviel brauchst du da?
Naja, wenn ich mal einen Blick in die Tabelle für TTL / LVTTL bzw 
LVCMOS33 werfe:

für U_in (H-Pegel)   >= 2.0V

d.h. ich lieg genau an der Grenze, was dazu führt, dass ich nicht jede 
Taktflanke detektiere.
zumin. ist das meinem Verständnis nach das aktuelle Problem.

MfG

[Ramon F. (tronixx)]

Thema hat sich erledigt.

Habs. Also manchmal steckt man da einfach nicht drin. Hab das ganze 
nochmal zusammengebaut und auf einmal funktioniert es mit dem 
CLK-Durchziehen. Unfassbar.

Ich möchte mich trotzdem für eure kommis bedanken. Die haben mich 
lerntechnisch wieder einmal einen Schritt nach vorne gebracht:)



thx und MfG