Hallo Community! Ich arbeite mit Vivado 2018 von Xilinx und vorerst ohne Hardware. Somit soll alles erst einmal simuliert werden. Ich möchte aus einem 100 MHz Signal ein 66 MHz und ein 33 MHz Signal erstellen. Ich besitze das Buch "FPGAs für Maker" von Cord Elias, in dem auch beschrieben wird wie man den Clocking Wizard in das "Projekt" einfügt. Ich habe als Input 100 MHz angegeben und als Outputs 66 und 33 MHz. Ich habe den Wizard dann als Component in meiner ".VHD Datei" implementiert und ein port mapping erstellt. Als letzten Schritt habe ich eine Simulation erstellt. Ich verstehe einfach nicht, wieso die jeweiligen Output Clocks nicht vernünftig generiert werden. BEIDE Ausgänge geben nur 2 Takte aus, welche auch noch jeweils gleich aussehen und dann war es das. (siehe Anhang). Ich bin echt am Verzweifeln und habe auch schon auf mehreren Seiten meinen Code und meine Arbeitsschritte bis hin zur Testbench verglichen. Liegt es vielleicht daran, dass man diesen Clocking Wizard nicht einfach so in einer Testbench simulieren kann? Ich weiß sonst nicht, was ich falsch mache. Sonst hatte ich nie Probleme meine Projekte zu simulieren. Dies ist allerdings das erste mal, dass ich etwas aus dem IP Catalog benutze. Vielleicht muss ich nun etwas anders machen :). Bin offen für Kritik und Unterstützung! :) Beste Grüße
Das sind irgendwie überhaupt keine Takte. Das sind zwei lausige Pulse.
>Ich arbeite mit Vivado 2018 von Xilinx
Da scheint mir schon ein Fehler zu sein. Nimm Lattice!
Um zu beurteilen, wo da der Fehler ist, müsste sich ein xilinx Experte
mal das erzeugte XCI ansehen, denke ich.
Peter P. schrieb: > dass ich etwas aus dem IP Catalog benutze. Welche hast Du denn da genommen? Also bei Lattice ist es so, dass es ein Symbol gibt, welches man anschließen kann. Dort sind die Eingänge und Ausgänge klar bezeichnet. Ich könnte mir vorstellen, dass Du irgendwo dran hängst, wo gar keine Takte rauskommen. So wie das da aussieht, sind das keinesfalls Taktausgänge. Oder es ist kein Clock-Generator.
Kommentator schrieb: > Das sind irgendwie überhaupt keine Takte. Das sind zwei lausige Pulse. Ja eben! Und beide besitzen auch noch die gleiche Periode, obwohl ich sie unterschiedlichen Ausgängen zugeordnet habe. Normal sollte er ja den 100 MHz Takt eben als 66MHz und als 33 MHz dort ausgeben. Das ist mein Problem. Kommentator schrieb: > Um zu beurteilen, wo da der Fehler ist, müsste sich ein xilinx Experte > mal das erzeugte XCI ansehen, denke ich. Ich vermute es auch. Kommentator schrieb: > Also bei Lattice ist es so, dass es ein Symbol gibt, welches man > anschließen kann. Dort sind die Eingänge und Ausgänge klar bezeichnet. > Ich könnte mir vorstellen, dass Du irgendwo dran hängst, wo gar keine > Takte rauskommen. So wie das da aussieht, sind das keinesfalls > Taktausgänge. Oder es ist kein Clock-Generator. Im Anhang kannst du den Wizard sehen. Wie gesagt: Das Buch erklärt es im Grunde genau so, bis auf die Testbench. Vielleicht funktioniert das auch einfach nicht mit einer Testbench.
:
Bearbeitet durch User
Kannst Du mal die beiden Verilog-Dateien vom Wizard hier einstellen? Bei manchen Simulatoren muß man die Zeitauflösung des Simulators hochstellen (ps) damit PLL und DCM richtig simuliert werden. Außerdem könntest Du noch länger simulieren, z.B. bis zu einer Millisekunde. Wenn Dir der Wizard da eine PLL reingezaubert hat, braucht die eine gewisse Zeit bis da ein Takt rauskommt. Duke
Das muss funktionieren. Die Testbench und das Generierte sehen ok aus. Mich wundert nur, dass kein reset und logged mit erzeugt wurden. Die sollte man mal aktivieren, um zu sehen, woran es hängt und ob sich da was tut. Es kann aber auch sein, dass dort einfach wieder eine reset-Polarität voreingestellt ist, die nicht richtig bedient wird. Den Unfug treibt Xilinx seit Jahren, physische Polaritäten ins Logikdesign zu ziehen, wo sie nichts zu suchen haben und dies schon deshalb nicht, weil auch physisch die internen resets der Komponenten wie PLL und RAM definitiv NICHT mit zwei Polaritäten ansteuerbar sind, wie mir auch Xilinx versichert hat. Die bauen das nur ein, weil es nach wie vor Hansels gibt, die glauben, mit lowaktive Signalen im Logikdesign hantieren zu müssen. Der Gipfel des Unsinns ist bei Xilinx, dass die IP-Blöcken teilweise einen negierten und einen nicht negierten Ausgang / Eingang haben, die bedient werden können aber nicht müssen- teilweise aber doch müssen, weil es sonst nicht geht, weil der Automatismus der Verdrahtung im Fall der Nichtnutzung nicht funktioniert. Mir sieht das nämlich so aus, also ob die Ausgänge zweimal zucken und dann in einen Reset gehen. Ansonsten bleibt noch ein Problem mit dem IP Container oder Pfaden, dass eine Komponente nicht richtig angeschlossen wird. Das scheint aber grundsätzlich stimmig, weil die Perioden der Takte nach 66MHz aussehen. Dieser ganze Quark ist der Grund, warum ich Wizzards, Blocksymbole und andere grafische "Vereinfachungen" möglichst meide. Von vielen Xilinx FAEs hört man Ähnliches: Die instanziieren schon zu ISE-Zeiten lieber alles per Hand, statt es den CoreGEN machen zu lassen. Von dem weiß Ich z.B. dass er - ausgerechnet in der letzten ISE 14.7, die es gibt - gerne dazu neigt, beim Umbau von PLLs manche Signale wegzulassen. Mapping und Component passen dann nicht zur IP. Gfs ist das auch hier so etwas und der Student, der den Parser geschrieben hat, hat geschlampt. Nachtrag zu Dukes Idee: Normalerweise sind die Takte nach 10..20 Eingangstakten spätestens da. Was noch sein kann wäre eine unglückliche Zeiteinstellung im Simulator. PLLs brauchen mitunter ein ps-Einstellung, damit sie laufen. Ich würde auch mal über ModelSIM nachdenken. Der Xilinx Sim ist ja so extraordinär gut nicht.
:
Bearbeitet durch User
Duke Scarring schrieb: > Bei manchen Simulatoren muß man die Zeitauflösung des Simulators > hochstellen (ps) damit PLL und DCM richtig simuliert werden. > Außerdem könntest Du noch länger simulieren, z.B. bis zu einer > Millisekunde. > Wenn Dir der Wizard da eine PLL reingezaubert hat, braucht die eine > gewisse Zeit bis da ein Takt rauskommt. > > Duke Direkt ins Schwarze getroffen! Bei einer Millisekunde sieht man, dass die Takte erst nach ca. 4,17µs beginnen. Dann laufen sie aber korrekt ab! (Siehe Anhang). Warum ist das denn so, dass der erst diese zwei "komischen" Takte erzeugt, und dann nach 30 ns erstmal Pause macht? Duke Scarring schrieb: > Kannst Du mal die beiden Verilog-Dateien vom Wizard hier einstellen? Kann ich noch andere Dateitypen hochladen oder nur Bilder? Die zweite Verilog Datei ist ein wenig länger. Sonst mach ich mehrere Screenshots. Falls noch benötigt :P.
Jürgen S. schrieb: > Das muss funktionieren. Die Testbench und das Generierte sehen ok aus. > Mich wundert nur, dass kein reset und logged mit erzeugt wurden. Die > sollte man mal aktivieren, um zu sehen, woran es hängt und ob sich da > was tut. Achso ok. Gut zu wissen. Im Buch wurden die auch erstmal deaktiviert, da die für sowas simples angeblich nicht benötigt werden. Jürgen S. schrieb: > Mir sieht das nämlich so aus, also ob die Ausgänge zweimal zucken und > dann in einen Reset gehen. Ansonsten bleibt noch ein Problem mit dem IP > Container oder Pfaden, dass eine Komponente nicht richtig angeschlossen > wird. Das scheint aber grundsätzlich stimmig, weil die Perioden der > Takte nach 66MHz aussehen. Eine höhere Simulationsdauer (siehe oben) ergab, dass nach 4,17 µs Pause die Takte letzten Endes doch kommen. Komisch. Danke für deinen informativen Text! :)
normalerweise springt das Clockmodul viel schneller an. Jedoch nutze ich immer einen Reset am Eingang (mindestens 3 Takte auch halten). Da kein Reset verwendet wird, kann dieses Verhalten entstehen. Außerdem würde ich mit dem "locked"-Signal für die nachfolgende Logik arbeiten. Das ist eines der einfachsten Komponenten. So kompliziert ist das eigentlich nicht.
Bei den 7er Chips klappt es auch, wenn man den Locked invertiert auf den Reset legt. Dann geht das auch in der Simulation schnell. Im übrigen gibts auch die Unifast Library da simulieren die meisten Cores schneller. Kann man in den Simulator Optionen einstellen.
Christian R. schrieb: > Bei den 7er Chips klappt es auch, wenn man den Locked invertiert auf den > Reset legt. Das kann aber nix werden, weil dann das Signal "not locked" immer als reset wirkt und die PLL festhält. Dann käme die nie aus dem Reset.
Moin! Danke erstmal für die Vielzahl an Antworten. Ich werde mal noch mit dem Reset und Locked etwas probieren. Bis dahin! :)
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.