Hi Ich möchte einen AD-Wandler ansteurn. Der AD-Wandler ist ein serieller Wandler. Dieser Wandler benötigt einen CLK. Um dies zu realisieren wollte ich einen den Systemclock des Programms auf einen FPGA-Port geben. Wenn ich dies mache, erhalte ich folgende Warnung: ProcessFlowWarning FPGA_PROJECT_map.ncd Place & Route WARNING:Route:455 - CLK Net:SCLK_int may have excessive skew because 0 CLK pins and 1 NON_CLK pins failed to route using a CLK template. Ich habe einfach das Clocksignal auf den Port gegeben. Gibt es vielleicht eine bessere Lössung z.B einen Buffer oder so? Grüsse Sebastian
Wenn Du ein Spartan-3 oder Virtex verwendest, könntest Du ein DDR Output FF einsetzen. Du brauchst dazu aber auch den invertierten Systemtakt (wird mit DCM) erzeugt.
1 | OFDDRRSE_inst : OFDDRRSE |
2 | port map ( |
3 | Q => Clk_Pin, |
4 | C0 => SystemClk, -- 0 degree clock input |
5 | C1 => nSystemClk50, -- 180 degree clock input |
6 | CE => '1', -- Clock enable input |
7 | D0 => '0', -- Posedge data input |
8 | D1 => '1', -- Negedge data input |
9 | R => '0', -- Synchronous reset input |
10 | S => '0' -- Synchronous preset input |
11 | );
|
Klaus
@ Sebastian >Wandler. Dieser Wandler benötigt einen CLK. Um dies zu realisieren >wollte ich einen den Systemclock des Programms auf einen FPGA-Port >geben. Wenn ich dies mache, erhalte ich folgende Warnung: >ProcessFlowWarning FPGA_PROJECT_map.ncd Place & Route >WARNING:Route:455 - CLK Net:SCLK_int may have excessive skew because 0 >CLK pins and 1 NON_CLK pins failed to route using a CLK template. Naja, für langsame Sachen so bis 10..20 MHz kann man das so machen. Wenns schneller wird muss man die Taktverteilung besser lösen. MfG Falk
Der Wandler bekommt einen CLK von 12MHz. Trotzdem habe ich da ein schlechtes Gewissen.
Könnte man da nicht ein BUFG verwenden? Aus dem Library Guide: BUFG, an architecture-independent global buffer, distributes high fan-out clock signals throughout a PLD device. The Xilinx implementation software converts each BUFG to an appropriate type of global buffer for the target PLD device. To use a specific type of buffer, instantiate it manually.
@ alex
>Könnte man da nicht ein BUFG verwenden?
Nein, der wird sowieso schon verwendet.
Das Problem ist, dass Taktnetze eben sehr speziell sind. Wenn nun aber
ein Taktsignal direkt auf ein IO-Pin gegeben wird, dann ist das
technologisch/logistisch bedingt nur mit viel Zwischenpuffern zu machen.
Diese verursachen eine erhebliche Verzögerung, sprich Skew.
Sowas könne man mittels DLL/DCM ausgleichen, aber die laufen erst ab 25
MHz. Das zeigt aber auch, dass das Problem nur bei höheren
Taktfreqeunzen wirklich zum Problem wird. Bei 12 MHz passt das schon.
GGF einfach auf der anderen Taktflanke die Daten ausgeben/abtasten und
alles ist gut.
MFG
Falk
Es gibt noch eine Lösung: Ich nehme eine höhere Taktfrequenz, zum das doppelte (da ich diese auch benötige passt dies gut) Diesen Takt teit man einfach mit Hilfe eines Zählers durch 2. Somit habe ich die benötigte Taktfrequenz. Diese kann ich dann auf einen Port geben. Somit sollte der Compiler keine Warnung mehr ausgeben, da nicht der CLOCK auf den Port gegeben wird, sondern der Ausgang eines FlipFlops. Einziger Nachteil man benötigt den doppelten Takt. Grüsse Sebastian
>Einziger Nachteil man benötigt den doppelten Takt.
Dieser "Nachteil" sollte sich in Grenzen halten, angesichts der
benötigten Frequenz. Ich jage mit einem Spartan3E 40Mhz problemlos
händisch getaktet mit internen 80 Meg raus. Geht fein. Man kann den Takt
auch noch einmal verzögern, wenn man auf der negativen Flanke arbeitet.
Das ist fürs Rücklesen manchmal nötig.
@ Selbständiger Ingenieur >benötigten Frequenz. Ich jage mit einem Spartan3E 40Mhz problemlos >händisch getaktet mit internen 80 Meg raus. Geht fein. Man kann den Takt Händisch? Du bist Morseweltmeister? ;-) MFG Falk
Hallo zusammen, möchten dieses thema noch einmal aufgreifen, da ich ebenfalls ein problem mit meinem Ausgangstakt habe. Spartan 3 Board von Digilent CLK: 25 MHz Ausgabe über standerd I/O A3 UCF File Eintrag: NET clock LOC = A3; Jetz frag ich mich warum der Pegel noch nicht einmal unterhalb 1V fällt. Das der Takt nicht ideal aussieht is mir klar, aber sowas is doch icht normal, oder? Will damit ein weiteren IC ansteuern, der momentan aber nichts tut. Meine Vermutung ist nun das dieses Problem am Takt liegt. Bei 3,3VCC und max low_pegel =0,3VCC -> entspricht dann knapp 1V. Also 25 MHz sind ja nicht gerade viel, dachte es geht so. Wie kann ich den Fehler denn am schnellsten beheben? MfG
Ramon F. schrieb: > Das der Takt nicht ideal aussieht is mir klar Ideal? Das ist ein Dreieck! So sieht garantiert kein 25 MHz Signal aus, das aus einem FPGA-Pin herauskommt. > Jetz frag ich mich warum der Pegel noch nicht einmal unterhalb 1V fällt. Hast du den Pegel mal ohne Last angeschaut, also wenn der FPGA-Pin keinen Baustein treiben muss?
> Hast du den Pegel mal ohne Last angeschaut, also wenn der FPGA-Pin > keinen Baustein treiben muss? ja hab ich , kommt genau das gleiche raus. Also um genauer zu werden, ich gehe vom 50MHz Systemtakt aus und teile diesen einfach mit einem Taktteiler runter und geb Ihn auf den Ausgang. Da ich zum ersten Mal mit externen I/Os arbeite, hab ich da wenig Erfahrung. Nur das das nicht mein Takt sein kann weiss ich sogar auch :) Was kann ich jetzt VHDL technisch ändern? MfG
Ramon F. schrieb: > Also um genauer zu werden, ich gehe vom 50MHz Systemtakt aus und teile > diesen einfach mit einem Taktteiler runter und geb Ihn auf den Ausgang. Warum auch nicht? > Was kann ich jetzt VHDL technisch ändern? Das ist kein VHDL-Problem. Ich tippe auf den Messaufbau. Miss mal den 50MHz Takteingang (Quarzoszillator) am FPGA. Ist der rechteckig?
> Ich tippe auf den Messaufbau. Miss mal den > 50MHz Takteingang (Quarzoszillator) am FPGA oha den muss ich erst mal Suchen beim Grid ball array. Also du meinst nicht direckt am Oszillator oder, weil da siehts nicht grad besser aus, eher schlimmer. MfG
> Bandbreitenbegrenzung im Osci eingeschaltet
mmmh is mir auch grad eingefallen. Mein Oszi hat nur ne Bandbreite von
100MHz. Da wirds natürlich schon verdammt schwer was anständiges zu
messen.
Denk daran wirds liegen
MfG
Ramon F. schrieb: > Also du meinst nicht direckt am Oszillator oder, weil da siehts nicht > grad besser aus, eher schlimmer. Hatte ich erwartet (mit meinem Tipp auf den Messaufbau). Und den Grund hast du ja selber herausgefunden... ;-) Ramon F. schrieb: > Denk daran wirds liegen Denke, du hast Recht.
100 MHz ist zwar nicht gerade toll, aber sollte für ein 25 MHz Signal noch ausreichen. Da muss noch was anderes sein das die Bandbreite begrenzt. Wie z.B. der zuschaltbare Bandbreitenbegrenzer, die meisten Oscis haben so was (typisch auf 20 MHz). Kann natürlich auch sein, dass der Probe defekt ist, Masseclip ist doch angeschlossen, oder?
Hier mal ein Beispiel, wie die 50 MHz bei einem Spartan3E aussehen. Die Ausgangssignalform hängt stark von der Treiberstärke (und vom Leitungsabschluß) ab. In diesem Fall hängt nur das Oszi mit 1 MOhm dran. Duke
Duke Scarring schrieb: > Die Ausgangssignalform hängt stark von der Treiberstärke (und vom > Leitungsabschluß) ab. In diesem Fall hängt nur das Oszi mit 1 MOhm dran. Dann wäre es sinnvoll, im UCF mit dem DRIVE-Constraint die Treiberstärke hochzubiegen. Allerdings sind eigentlich schon per Default 12mA eingestellt... @ Ramon F. (tronixx) Kannst du das UCF mal hier anhängen?
das "Dreieck" hat einen Spannungsanstieg von ca. 1,8V/18ns. Wenn der Treiber 10mA schafft, entspricht das gerade einer kapazitiven Last von 100pF. Das ist ein halbwegs typischer Wert für einen passiven Tastkopf ohne Teiler. Falls dein Tastkopf sich umstellen lässt (von x1 auf x10): einfach die x10 Einstellung wählen.
hallo, > Falls dein Tastkopf sich umstellen lässt (von x1 auf x10): einfach die > x10 Einstellung wählen. hab ich gemacht, ändert aber auch nichts. jetz hab ich aber noch einmal paar allgemeine Fragen zu I/O Ports. Im Anhang findet ihr die Daten zu dem anzusteuernden Chip. Da ich sowas noch nie gemacht habe bin ich bei erneutem Einlesen in diese Geschichte etwas skeptisch geworden. z.B. kann ich bei den I/Os ja den Storm begrenzen > For Spartan-II, Spartan-IIE, Spartan-3, Spartan-3A, Spartan-3E, Virtex, > Virtex-E, Virtex-II, > Virtex-II Pro, Virtex-II Pro X, Virtex-4, and Virtex-5 devices: > INST “instance_name” DRIVE={2|4|6|8|12|16|24}; > where > • 12 mA is the default 1. Als das bedeutet ja nur, das der jeweilige max. Wert nicht überschritten wird, oder? Die Eingänge vom Chip sind hier mit max 25yA angegeben. Muss ich in der UCF File jetzt überhaupt dahingehend was angeben? 2. Meine Spannungsversorgung regel ich über die VCC (3,3V) des expansion Connectors. Wo finde ich denn eine Angabe darüber welchen Max. Strom diese liefern kann? Da ich 7 VCC Eingänge habe, bin ich mir jetz unsicher ob die Stromversorgung ausreicht. Hab die 7 Eingänge jetzt auf 3 quellen aufgeteilt, funkt aber immer noch nichts. MfG
Ramon F. schrieb: >> Falls dein Tastkopf sich umstellen lässt (von x1 auf x10): einfach die >> x10 Einstellung wählen. > > hab ich gemacht, ändert aber auch nichts. das kann ich mir eigentlich nicht vorstellen. Ich schätze mal, du hast am Oszi die Einstellung für den 10x Teiler angewählt. Das ändert aber nur die Skalierung des Oszis, die kapazitive Last des Teilers bleibt dabei gleich. Mein Vorschlag war eigentlich, dass du am Tastkopf selbst den Schiebeschalter umlegst (angehängtes Foto zeigt das für Hameg-Tastkopf). Damit reduzierst du die Kapazität des Tastkopf um ca. einen Faktor 7, und das muss sich in der Messung bemerkbar machen. Zur Demonstration habe ich dir zwei Messungen angehängt. (10MHz Takt aus CPLD-Pin mit 4mA Treiberstärke. Der Teilerfaktor war mal auf x1 und mal auf x10 eingestellt. Die Bandbreite des Oszis war in beiden Fällen 100MHz) Ramon F. schrieb: >> • 12 mA is the default > > 1. Als das bedeutet ja nur, das der jeweilige max. Wert nicht > überschritten wird, oder? Die Eingänge vom Chip sind hier mit max 25yA > angegeben. Muss ich in der UCF File jetzt überhaupt dahingehend was > angeben? Das bedeutet, dass der Ausgang nominell 12mA treiben kann. Der tatsächliche Strom hängt von der Last ab (Transistorkennlinie des Treibers) und wird meist deutlich geringer sein. Da 12mA der Default ist, musst du diesen Wert im ucf nicht überschreiben. Die 25µA, die für die Eingänge des angeschlossenen Chips angegeben sind, beziehen sich auf statische Signale. Wenn das Signal schaltet ergibt sich der Strom vor allem aus der Umladung der Kapazität des Eingangs. Und aus zusätzlichen kapazitiven Lasten (wie dem Tastkopf). Ramon F. schrieb: > Da ich 7 VCC Eingänge habe, bin ich mir jetz > unsicher ob die Stromversorgung ausreicht. Hab die 7 Eingänge jetzt auf > 3 quellen aufgeteilt, funkt aber immer noch nichts. Bin nicht sicher,ob ich die Frage verstehe: du hast 3 Ausgänge, die schalten? Normalerweise kommt deren Versorgung aus genau einem zugehörigen VCC_IO Pin. Wenn du mit "funkt aber immer noch nichts" meinst, dass das gemessene Signal keine ausreichenden Pegel erreicht: ich glaube immer noch, dass das durch die kapazitive Belastung des Tastkopfes kommt.
Bitte 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.