Ich verwende einen Spartan 3E Package CP132, Board Basys2 und habe mir die DCM dazu konfiguriert. Nun gebe ich eine Taktfrequenz, extern von einem Funktionsgenerator, hinein und habe festgestellt, beim abgreifen des Signals über CLK0, dass bei 16MHZ Schluss ist und es mir das Signal dann auf dem Oszi nicht mehr anzeigt. Das verstehe ich nicht ganz, ist da irgendeine Begrenzung vom FPGA her? Normalerweise müsste ja an dem Ausgang an dem ich abgreife das Signal genauso wieder herausgegeben werden. Wenn ich die interne Clock vom Board verwende kann ich doch auch bis 100MHZ gehen. Oder habe ich da irgendeinen Denkfehler? :-/ Ich gebe den Takt auf den Anschluss B2 des JA Connectors und greife ihn wieder ab am Anschluss C6 des JB Connectors.
@ A. P. (jamaram90) >einem Funktionsgenerator, hinein und habe festgestellt, beim abgreifen >des Signals über CLK0, dass bei 16MHZ Schluss ist und es mir das Signal >dann auf dem Oszi nicht mehr anzeigt. Dein DCM synchronisiert nicht. Entweder falsch konfiguriert oder deine Taktquelle hat zuviel Jitter. >Das verstehe ich nicht ganz, ist da irgendeine Begrenzung vom FPGA her? Nicht bei 16 MHz.
Aber wenn ich von einem MHZ schrittweise die Frequenz nach oben schraube ändert sich doch auch die Frequenz am Ausgang. Wieso dann auf einmal ab 16 MHZ nicht mehr. Ich denke schon das es richtig synchronisiert sonst würde es doch bis dahin auch nicht gehen oder?
Die DCMs sind nicht dafür gemacht, sich ändernden Eingangsfrequenzen zu folgen. Besonders bei sprunghaften Änderungen verlieren sie den Lock und kommen oft ohne externen Reset nicht mehr von selbst wieder rein. Die DCMs der älteren FPGAs eignen sich z.B. daher auch manchmal nicht, einer Spread-Spectrum-Clock zu folgen. Näheres steht auch im Datenblatt (Electrical Characteristics -> Switching Characteristics). Probier einfach mal nach der Frequezänderung einen Reset auszulösen, z.B. mit einem Taster (vielleicht Entprellen).
Mit dem Reset habe ich schon gearbeitet. Die Frequenz hat es am Ausgang dann auch angezeigt, wenn ich ihn betätigt habe. Aber ab 16MHZ klappte auch das nicht mehr :-/.
Also ich kann dir versichern, dass aus den DCMs auch höhere Frequenzen rauskommen können. Hast du Constraints gesetzt, um der Toolchain mitzuteilen mit welchen Frequenzen, bzw. hier mit welcher Maximalfrequenz zu rechnen ist? - Ist der Takt-Eingangspin ein GCLK-Pin? - Kommt ein sauberes Signal am Eingangspin an? (Mit Oszi kontrolliert?) - Wie ist der DCM konfiguriert? (noch andere Funktionen genutzt? CLK_FX?) - Was tut der restliche Code? Generell, was ist eigentlich der Sinn der Ganzen? Soll das Design später mit veränderbaren Input-Frequenzen klarkommen?
Ich bin noch am Anfang der ganzen Sache. Ich möchte mit dem internen DLL über die DFS die Taktfrequenz möglichst hoch bekommen und dann vier um 90 Grad verschobene Signale ausgeben. Jetzt stelle ich mal eine doofe Frage aber wie setze ich bitte die Constraints? Meinst du damit jetzt die Attribute die in der 'generic map' genutzt werden? Wo kann man das denn einstellen mit welcher maximalen Frequenz er rechnen muss? Ich nutze Xilinx. Der Takteingangs Pin ist wahrscheinlich kein GCLK. Zumindest habe ich nicht darauf geachtet. Ich habe den erst besten genommen. Werde mich aber darüber im DataSheet des FPGAs mal belesen welcher einer ist. Das Signal des Funktionsgenerator kommt sauber an, dass habe ich kontrolliert. Bisher habe ich erstmal keine weiteren Funktionen probiert, da mich das schon etwas stutzig gemacht hat da es nicht mehr als 16MHZ ausgibt. Der restliche Code tut noch nicht viel da ich wie gesagt erstmal nur die DCM konfiguriert habe um damit etwas rumzuspielen.
Constraints werden in der UCF-Datei (User Constraints File) gesetzt. Hier kommen alle Infos rein, die für die Implementation (der Schritt nach der Synthese...) wichtig sind. Zum Beispiel Pin-Zuordnungen, Periodendauern und FPGA-spezifische Eigenschaften. Xilinx ISE bietet zwar auch eine GUI-Funktionalität dafür an, ich finde es aber einfacher und schneller, die paar einfachen Sachen von Hand zu schreiben. Für Beispiele einfach mal in anderen Projekten schauen. Hier wäre der PERIOD-Constraint wichtig, der dem Netz des Takteingangs zugeordnet wird. In den Generics bei der Instanzierung des DCMs kann man aber auch die Periodendauer einstellen, richtig. Das ist für die Initialisierung des DCMs wichtig und wird eventuell auch von den Tools für die Ausgangsfrequenzen erkannt. Hier sollte dann auch eine entsprechende Info-Meldung auftauchen. Der Pfad zum DCM bleibt aber undefiniert. Daher im UCF spezifizieren. Die Toolchain bekommt es übrigends dann recht problemlos hin, neue Spezifikationen für vom DCM erzeugte Takte automatisch zu generieren. Allerdings ist es schon etwas verwunderlich, dass auch nach einem DCM-Reset bei stabilem Takt nichts mehr rauskommt. Ich habe hier immernoch den Reset selbst, die DCM-Konfiguration oder den Eingangstakt in Verdacht.
Danke für die ausführliche Erklärung. Ich werde mir es nochmal genauer anschauen und dann berichten. :-)
Die "Maximale" Taktfrequenz ist hier sicher nichr das Problem - wenn schon, die minimale. Bei Spartan 3e liegt die bei 5MHz. Ich glaube eher, dass das runterdrehen zu zuviel Jitter führt. Die Toleranz liegt bei einigen 100ps habe ich mal gelesen und man muss auch den long term Wert beachten.
Duke Scarring schrieb: > Welches Modell verwendest Du? Einen von der Firma RIGOL. Ich hab jetzt mal den Spartan 6 ausprobiert und siehe da, wenn ich da eine DLL implementiere kann ich ohne Probleme den Takt hochdrehen. Allerdings zittert das Signal am Ausgang noch etwas. Hat jemand einen Tip wie ich dieses noch verringern kann? Felix schrieb : > Hier wäre der PERIOD-Constraint wichtig, der dem Netz des Takteingangs > zugeordnet wird. Ich habe dies jetzt auch in meiner .ucf mit eingebracht allerdings bekomme ich beim Übersetzen zwei Warnungen :
1 | ConstraintSystem:197 - The following specification is invalid because the referenced TNM constraint was removed: |
2 | <TIMESPEC TS_CLKIN_IN = PERIOD "CLKIN_IN" 100 MHZ HIGH 50%;> [Nexys3_Master.ucf(9)] |
3 | |
4 | ConstraintSystem:195 - The TNM 'CLKIN_IN', does not directly or indirectly drive any flip-flops, latches and/or RAMs and will be removed from the design. This TNM is used in the following user groups and/or specifications: |
5 | <TIMESPEC TS_CLKIN_IN = PERIOD "CLKIN_IN" 100 MHZ HIGH 50%;> [Nexys3_Master.ucf(9)] |
Ich weiß das Warnungen nicht unbedingt bedenklich sein müssen aber ich würde doch schon gern wissen wollen was damit gemeint ist. Hat es damit zu tun das ich ausser der DCM/DLL nichts weiter an Beschaltung implementiert habe?
Mit den constraints wirst Du den Jitter nicht wegbekommen, der ist physikalisch bedingt, sofern das Signal korrekt getaktet ist. Das aber scheint mir fraglich, weil da irgendwas wegsynthetisiert wird: Der Clock scheint ja zu verschwinden, weil das Constraint ins Leere läuft. Ich würde mal die DLL-Funktionalität / feedback mal komplett rauslassen, dann kann der Frequenz-Synthesizer nochmal deutlich tiefer. In wieweit Du dann aber schnell verdrehen kannst, ist dennoch zu prüfen.
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.