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
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.