Clk auf Portausgang

[Sebastian (Gast)]

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

[Klaus F. (kfalser)]

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.

    OFDDRRSE_inst : OFDDRRSE
        port map (
            Q  => Clk_Pin,
            C0 => SystemClk,            -- 0 degree clock input
            C1 => nSystemClk50,         -- 180 degree clock input
            CE => '1',                  -- Clock enable input
            D0 => '0',                  -- Posedge data input
            D1 => '1',                  -- Negedge data input
            R  => '0',                  -- Synchronous reset input
            S  => '0'                   -- Synchronous preset input
            );

Klaus

[Falk B. (falk)]

@ 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

[Sebastian (Gast)]

Der Wandler bekommt einen CLK von 12MHz. Trotzdem habe ich da ein 
schlechtes Gewissen.

[Johnsn (Gast)]

Das Problem habe ich auch, aber 25 MHz gehen auch noch gut raus.

[alex (Gast)]

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.

[Johnsn (Gast)]

Das wird aber das Clock-Skew Problem nicht lösen.

[Falk B. (falk)]

@ 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

[Sebastian (Gast)]

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

[Selbständiger Ingenieur (Gast)]

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

[Falk B. (falk)]

@ 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

[Ramon F. (tronixx)]

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

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

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?

[Ramon F. (tronixx)]

> 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

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

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?

[Ramon F. (tronixx)]

> 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

[Lattice User (Gast)]

Bandbreitenbegrenzung im Osci eingeschaltet?

[Ramon F. (tronixx)]

> 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

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

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.

[Lattice User (Gast)]

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?

[Duke Scarring (Gast)]

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

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

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?

[Achim S. (Gast)]

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.

[Ramon F. (tronixx)]

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

[Achim S. (Gast)]

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.