Hallo,
Ich möchte bei meinen zedboard einen Takt, sagen wir mal 50Mhz ausgeben.
Vom Systemtakt teile ich mit dem Clock Wizard nun auf 50MHZ herunter und
geben das ganze dann auf den Ausgang.
Natürlich habe ich kein Rechteck erwartet, aber einen so schlechten
Sinus auch nicht. Ich messe mit einen 300Mhz Ossi, daran liegt es also
auch nicht.
Ich habe mal gelesen einen ODDR dazwischenzuschalten, aber das Signal
ist damit auch nicht besser geworden.
Liegt mein Problem wohl eher Softwareseitig oder zwischen den Ohren.
Warum hängst du nicht mal einen screenshot vom Oszi an?
Und wie sind die Rahmenbedingungen, d.h. eingestellter IOStandard, Länge
der Leiterbahn, evtl. Terminierung?
Wie ist die Kapazität deiner Probe, misst du mit 10:1 oder 1:1? Bei den
meisten passiven Probes mit 1:1 sind 300 MHz am Oszi nicht mehr als ein
frommer Wunsch.
FPGAler schrieb:> Hallo,>> Ich möchte bei meinen zedboard einen Takt, sagen wir mal 50Mhz ausgeben.> Vom Systemtakt teile ich mit dem Clock Wizard nun auf 50MHZ herunter und> geben das ganze dann auf den Ausgang.
Also die neueren Xilinx Familien und damit auch der Zynq können selbst
single ended deutlich mehr als 100MHz erkennbar, d.h. noch mit sauberen
Flanken raushauen...
D.h. Du müsstest schon ein paar weitere Fakten nennen...
Was für ein Oszi und was für Tastköpfe nutzt Du zum messen?
Welcher IO-Standard ist eingestellt?
Geht der genutzte IO-Pin / Leitung irgendwo hin, oder misst Du sogar
bereits über einen Serienwiderstand?
>> Natürlich habe ich kein Rechteck erwartet, aber einen so schlechten> Sinus auch nicht. Ich messe mit einen 300Mhz Ossi, daran liegt es also> auch nicht.
Es gibt/gab auch früher 300W PC-Aktivlautsprecherboxen...
>> Ich habe mal gelesen einen ODDR dazwischenzuschalten, aber das Signal> ist damit auch nicht besser geworden.>> Liegt mein Problem wohl eher Softwareseitig oder zwischen den Ohren.
Mutmaßlich, aber s.o.
Ja...
Also Ossi ist ein Hameg HMO3004 und Messprobe ist HZ350. Schon nicht
ganz so schlecht.
10/1 Teilung.
Leitungen sind ca. 10Cm zu den Pmods auf dem zedboard.
Eingestellt ist IOstandart LVCmos33. Fast
Ich messe direkt am Portpin, Terminierung mit 100Ohm hat auch nichts
gebracht.
Einen Sinus kann man sich vorstellen denke ich.
FPGAler schrieb:>> Ich messe direkt am Portpin, Terminierung mit 100Ohm hat auch nichts> gebracht.
Und wo ist die Probemasse angeklemmt?
>> Einen Sinus kann man sich vorstellen denke ich.
Natürlich. Einen sauberen Sinus hast du aber nicht, sondern irgendetwas.
Und aus dem tasächlichen Bild kann jemand mit Erfahrung eventuell schon
erkennen was du falsch machst.
Bist Du sicher, ein DDR-FF genutzt und es richtig beschaltet zu haben?
Dir ist klar, wozu Du das tun solltest?
Wenn das richtig gemacht wird, sind auch 100 MHz bei kurzen Leitungen
gut darstell- und nutzbar. Entscheidend sind die geschaltete
Treiberleistung und die Art der Terminierung. Wie sieht Deine
Beschaltung aus?
Ausserdem solltest Du von einem 300MHz Scope nicht zuviel erwarten. Je
nach tatsächlicher Auflösung/Samplezahl und Güte des Tastkopfes siehst
Du da alles andere, als das, was auf der Leitung war. War der
OSZI-Eingang bei der Messung abgeschlossen? Wie?
Wenn ich mir sicher wäre würde ich ja nicht fragen, außerdem ist mir
klar etwas falsch gemacht zu haben. Aber so kommen wir ja auch nicht
weiter.
Kann mir eventuell einer ein komplettes Projekt für einen Zynq,
möglichst ein zedboard mit ordentlich verschaltetem Taktausgang
generieren.
Zunächst reicht mir einfach z.B. JA4 (Pin AA9).
Ziel ist es irgendwann ein Display zu befeuern über LVDS. Da ich gerne
sehe was ich programmiert habe, habe ich halt diese Variante gewählt.
Gerade vergangene Woche hatte ich ein zedboard in Händen, aber nur
drübergeschaut. Ich kenne auch die Verschaltung nicht im Detail und vor
allem weiß ich nicht, was Du dort konkret ansprechen willst.
Grundsätzlich ist das aber immer dieselbe Problematik und vom board
ziemlich unabhängig, wenn man von SI-Themen und dem konkreten Layout
absieht.
Du musst zunächst einen out-DDR buffer einbauen (siehe XI Library
Guide). Beschaltet wird der mit einem Takt und einem virtuell negierten
Takt oder einen echten negierten Takt aus einer PLL (180°). Die beiden
Takte steuern das DDR-FF an, welches statisch mit 0 und 1 belegt ist,
wodurch genau der Takt rauskommt. Als nächstes setzt Du im UCF ein
gültiges Treibercontraint für den Strom, z.B. DRIVE = 12. Wieviele mA
das sind, steht in der Anleitung für den Zynq. Der Strom muss zu Deinem
Z passen, also z.B. eine 50 Ohm-Leitung (wenn es eine ist) treiben
können. Den Eingang Deines getriebenen Chips musst Du ebenfalls noch
abschliessen. In dem Fall am besten seriell oder mit einem internen
parallel-R wenn es ein FPGA ist. Dann stellst Du den Ausgang im UCF noch
auf "fast". Das Ganze gilt für einen z.b. CMOS25 Ausgang.
Wenn Du Dir unsicher bist, simuliere Dir das mal in SPICE. Da kannst Du
eine Transmission-line einbauen und auch die Kapazitäten und
Innenwiderstände des treibenden FPGA Pins ins Spiel bringen. Baue z.B.
mal folgende Schaltung auf: FPGA-Pin über (27 Ohm parallel 150 pF) an
die Leitung (50 Ohm) und diese an den ZielChip und einmal direkt, einmal
parallel abgeschlossen.
Wenn Du nunmehr einen LVDS-Clock zu Deinem Display treiben willst, sieht
das wieder anders aus. Dann brauchst Du ein p-n-Paar am Ausgang, die
auch beide als LVDS deklariert werden müssen. Angeschlossen wird dann
der "p", der "n" ist indirekt mitverdrahtet. Die LVDS-Terminierung ist
ebenfalls anders. Guck mal im Wiki. Herausfinden musst Du, ob Dein LVDS
Clock Eingang am Zielchip abgeschlossen ist oder Du das selber machen
musst.
Jürgen Schuhmacher schrieb:> Als nächstes setzt Du im UCF ein> gültiges Treibercontraint für den Strom, z.B. DRIVE = 12. Wieviele mA> das sind, steht in der Anleitung für den Zynq. Der Strom muss zu Deinem> Z passen, also z.B. eine 50 Ohm-Leitung (wenn es eine ist) treiben> können. Den Eingang Deines getriebenen Chips musst Du ebenfalls noch> abschliessen. In dem Fall am besten seriell oder mit einem internen> parallel-R wenn es ein FPGA ist. Dann stellst Du den Ausgang im UCF noch> auf "fast". Das Ganze gilt für einen z.b. CMOS25 Ausgang.
Gemeint ist wohl duie Slew rate also SLEW = "FAST";
Also im UCF etwa so:
NET "CLK_o" LOC = "D26" |IOSTANDARD = "LVTTL"| DRIVE = 12 | SLEW =
"FAST";
Statt D26 muss die passende Pinnummer in deinem Design stehen, was für
deinen FPGA-typ an Einstellungen für Drive und IOstandard möglich und
passend ist steht im Constraint guide:
http://www.xilinx.com/support/documentation/sw_manuals/xilinx13_4/cgd.pdf
MfG,
Was hier zum UCF gesagt wurde ist wichtig, sollte beachtet werden.
Die Aktion mit dem DDR-FF ist prinzipiell auch gut, allerdings mehr für
ein sauberes 50/50-Tastverhältnis und einen festen zeitlichen Bezug zum
internen Takt wichtig. Das DDR-FF beeinflusst ja nicht die
Treibercharakteristik des IO-PADs. Deren Einstellung steht im UCF. Das
DDR-FF ist nur der Workaround dafür, dass die Spartans (zumindest 3 und
6) keinen Takt direkt auf die IO-Buffer führen können. Der Takt muss so
aus dem Taktnetzwerk raus auf den normalen Routing-Resourcen geführt
werden. Das kann halt Skew geben. Mit dem DDR-FF kann der Takt im FPGA
auf dem Taktnetzwerk bleiben und treibt die Takteingänge genannten FFs.
Toolchain glücklich, Skew gering, konstant und berechenbar!
Ich habe schon sehr oft Takte ohne DDR-FF aus FPGAs rausgeführt,
allerdings Spartan3er und 6er. Die Signale sehen dabei auch ohne
Terminierung eigentlich ganz gut aus, die FPGA-Treiber sind auch recht
niederimpedant. Denke nicht, dass das ganze Problem da liegt...
Ich würde hier wie schon "Lattice User" die Probe-Masse vermuten.
Genanntes Scope und Probe sollten ein 100MHz-Signal, korrekte Bedienung
vorausgesetzt (BW-Limit?) ordentlich darstellen können. Wenn die Masse
nur mit dem Krokodilklemmen-Kabelschwanz hergestellt wurde, ist das
Verhalten völlig klar. Es muss eine kurze und mit dem Tastkopf parallel
geführte Masseverbindung bestehen, die auf der Platine auch möglichst
nah an der Messstelle die Systemmasse kontaktiert. Bei den meisten
Probes liegen kleine Federdraht-Metallspitzen bei, die auf den vorn
hinterm Tastkopf freiliegenden Schirm aufgesteckt werden. Die wären hier
zu verwenden und direkt neben der Messstelle in irgendein Massepad oder
Via zu versenken! Dann wird aus dem Sinus auch ein Rechteck.
Wenn man dann Reflektionen sieht, oder verschliffene Flanken kann man
sich an die Terminierung machen. Ist aber auch stark vom
Leiterplattenlayout und dessen Routingimpedanz abhängig.
Felix schrieb:> Was hier zum UCF gesagt wurde ist wichtig, sollte beachtet werden.>> Ich würde hier wie schon "Lattice User" die Probe-Masse vermuten.> Genanntes Scope und Probe sollten ein 100MHz-Signal, korrekte Bedienung> vorausgesetzt (BW-Limit?) ordentlich darstellen können. Wenn die Masse> nur mit dem Krokodilklemmen-Kabelschwanz hergestellt wurde, ist das> Verhalten völlig klar. Es muss eine kurze und mit dem Tastkopf parallel> geführte Masseverbindung bestehen, die auf der Platine auch möglichst> nah an der Messstelle die Systemmasse kontaktiert. Bei den meisten> Probes liegen kleine Federdraht-Metallspitzen bei, die auf den vorn> hinterm Tastkopf freiliegenden Schirm aufgesteckt werden. Die wären hier> zu verwenden und direkt neben der Messstelle in irgendein Massepad oder> Via zu versenken! Dann wird aus dem Sinus auch ein Rechteck.
Ich stimme in diesen Chor ein, mit langer statt mit kurzer Masse
gemessen wird aus einem Rechteck ein Sinus. Mach doch mal eine
Vergleichmessung an dem Clockeingang des FPGA oder an einem anderen
clock vergleichbarer Frequenz.
MfG
