Forum: FPGA, VHDL & Co. Vivado Clocking Wizard Clock-Output funktioniert nicht in Testbench


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Stephen P. (sandafoks)


Angehängte Dateien:

Lesenswert?

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

von Kommentator (Gast)


Lesenswert?

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.

von Kommentator (Gast)


Lesenswert?

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.

von Stephen P. (sandafoks)


Angehängte Dateien:

Lesenswert?

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
von Duke Scarring (Gast)


Angehängte Dateien:

Lesenswert?

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

von Jürgen S. (engineer) Benutzerseite


Lesenswert?

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
von Stephen P. (sandafoks)


Angehängte Dateien:

Lesenswert?

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.

von Stephen P. (sandafoks)


Lesenswert?

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! :)

von Klakx (Gast)


Lesenswert?

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.

von Christian R. (supachris)


Lesenswert?

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.

von Weltbester FPGA-Pongo (Gast)


Lesenswert?

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.

von Stephen P. (sandafoks)


Lesenswert?

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
Noch kein Account? Hier anmelden.