Hallo liebes Forum Ich habe versucht mich in die Problematik der Timing Constraints einzuarbeiten. Dabei ist auch schon eine kleine pdf-Doku entstanden. Nun stehe ich jedoch vor der Frage, wie geht man mit einer weiteren PLL die ihren Eingangstakt aus einer anderen PLL erhält im Design um. Vor allem kann man da derive_pll_clocks nutzen? Oder wie stellt man die erzeugten Takte der zweiten PLL zum Takt der ersten PLL in Beziehung? Kann ich die 840Mhz der ersten PLL als Master Takt definieren so dass nicht mehr der i_CLK24 der Master ist?
Steffen H. schrieb: > wie geht man mit einer weiteren PLL > die ihren Eingangstakt aus einer anderen PLL erhält im Design um. Das reicht normalerweise den extern ankommenden Takt zu constrainen. Bei Xilinx werden für die erzeugten Ausgangstakte automatisch weitere Constraints generiert. Steffen H. schrieb: > Vor > allem kann man da derive_pll_clocks nutzen? Damit erzeugst du keine echten im FPGA verwendbaren Takte, sondern du teilst der Toolchain "nur" mit, dass das ein Takt ist der aus einer PLL kommt. So habe ich das bisher verstanden. Steffen H. schrieb: > Kann ich die 840Mhz der ersten PLL als Master Takt definieren so dass > nicht mehr der i_CLK24 der Master ist? 840? Da ist die Frequenz sehr wahrscheinlich zu hoch, auch 480 MHz ist noch hoch. Diese Feedbackclock ist nicht zur Verwendung gedacht ausser eben für die PLL selbst. Du könntest alle dre Takte in einer PLL erzeugen lassen. Du kannst aber auch wie gezeichnet die 40 MHz aus der einen PLL in die nächste hineinfüttern.
Gustl B. schrieb: > Steffen H. schrieb: >> Vor >> allem kann man da derive_pll_clocks nutzen? > > Damit erzeugst du keine echten im FPGA verwendbaren Takte, sondern du > teilst der Toolchain "nur" mit, dass das ein Takt ist der aus einer PLL > kommt. So habe ich das bisher verstanden. So habe ich es auch verstanden. Wobei es doch nicht nur für einen Takt ist, sondern alle, oder. Also in der Art "Ich habe dir Takt(e) definiert und jetzt guck mal, ob daraus noch andere Takte abgeleitet werden." Steffen H. schrieb: > Kann ich die 840Mhz der ersten PLL als Master Takt definieren so dass > nicht mehr der i_CLK24 der Master ist? Was meinst du mit Mastertakt? Welchen Takt die Module verwenden, definiert deine Beschreibung. Davon abgesehen würde mich interessieren, welches FPGA 840 MHz schafft. Vor zwei Jahren war ich stolz, dass ich die maximal 450 MHz eines Arria 10 voll ausnutzen konnte. Übrigens solltes du dran denken, die Taktdomänen zu trennen. Ich habe mich gewundert, warum das Design in der Analyse so langsam ist, bis ich rausgefunden habe, dass der Synthesizer Signale zwischen zwei Taktdomänen auf beide Takte constrainen wollte.
Dussel schrieb: > Wobei es doch nicht nur für einen Takt > ist, sondern alle, oder. Das kann man auch für einzelne Takte machen. Was du meinst ist dass man nur den Eingangstakt constraint. Wenn der dann in eine PLL reingeht und weitere Takte erzeugt werden, dann weiß normalerwiese die Toolchain auch deren Details, sie erzeugt da selbständig weitere Constraints für die erzeugten Takte.
Gustl B. schrieb: > Du könntest alle dre Takte in einer PLL erzeugen lassen. Du kannst aber > auch wie gezeichnet die 40 MHz aus der einen PLL in die nächste > hineinfüttern. Das hat halt nicht wirklich geklappt. Ich arbeite übrigens nicht mit Xilynx sondern mit TD (Tang Dynasty von Anlogic). Die Toolchain ist ähnlich der von Intel - Quantus - oder wie die heißt. Der eingehende Takt in die zweite PLL wurde vom Net richtig erkannt. Allerdings wurde von der Timing Analyse der Eingangstakt i_CLK24 (primary) dafür verwendet und eben dann auch die Folgetakte / generierten Takte falsch berechnet. Komisch, oder? Dussel schrieb: > Was meinst du mit Mastertakt? So wie oben im Bild beschrieben. Stimmt denn das so? Dussel schrieb: > Davon abgesehen würde mich interessieren, welches FPGA 840 MHz schafft. Da hast du schon Recht, das ist der Feedback Takt der 1.PLL. Die FPGA (Eagle20 EG4S20256) schafft nur 400Mhz im System und an den Pads. Aber als Masterclock oder als Referenz aller abgeleiteten Clocks kann man diesen doch verwenden, oder?
Dussel schrieb: > Übrigens solltes du dran denken, die Taktdomänen zu trennen. Aber macht man das nicht nur dann, wenn man einen anderen nicht zum Systemtakt abgeleiteten Takt von außen in den FPGA führt wie zum Beispiel den Takt eines ADC oder so?
Steffen H. schrieb: > Der eingehende Takt in die zweite PLL wurde vom Net richtig erkannt. > Allerdings wurde von der Timing Analyse der Eingangstakt i_CLK24 > (primary) dafür verwendet und eben dann auch die Folgetakte / > generierten Takte falsch berechnet. > Komisch, oder? Deren Toolchain kenne ich nicht. Du könntest mal den Code hier hochladen. Weil beide PLLs den gleichen Feedbacktakt verwenden solltest du auch alle damit erzeugten Takte mit nur einer PLL erzeugen können. Steffen H. schrieb: > Die FPGA (Eagle20 EG4S20256) schafft nur 400Mhz im System und an den > Pads. Aber als Masterclock oder als Referenz aller abgeleiteten Clocks > kann man diesen doch verwenden, oder? Auch dieser Takt muss dann irgendwie durch das System geroutet werden. Ist eben die Frage worauf sich die 400 MHz beziehen, sind das die Taktleitungen oder die Logikzellen. Du hast da aber auch keinen Vorteil wenn du mit den 480 MHz in eine zweite PLL hineingingest. Dann ist deren Multiplikator eben 1. Das ist der PLL recht egal.
Gustl B. schrieb: > Dussel schrieb: >> Wobei es doch nicht nur für einen Takt >> ist, sondern alle, oder. > > Das kann man auch für einzelne Takte machen. Was du meinst ist dass man > nur den Eingangstakt constraint. Wenn der dann in eine PLL reingeht und > weitere Takte erzeugt werden, dann weiß normalerwiese die Toolchain auch > deren Details, sie erzeugt da selbständig weitere Constraints für die > erzeugten Takte. So meine ich das. Ich schließe clk mit zum Beispiel 10 MHz an eine PLL an und generiere damit zum Beispiel clk_pll_x, clk_pll_y und clk_pll_z. Dann constraine ich clk mit period 100 ns und schreibe einmal derive_pll_clocks, was dann für alle drei generierten Takte gilt. Steffen H. schrieb: > Dussel schrieb: >> Was meinst du mit Mastertakt? > > So wie oben im Bild beschrieben. Stimmt denn das so? Da fühle ich mich nicht sicher genug, um dazu irgendwas sagen zu können. Grundsätzlich kann man, soweit ich weiß, jedes Taktsignal auf die PLL routen und jedes Taktsignal (extern oder über PLL generiert) als Takt für die Logik verwenden. Steffen H. schrieb: > Dussel schrieb: >> Übrigens solltes du dran denken, die Taktdomänen zu trennen. > > Aber macht man das nicht nur dann, wenn man einen anderen nicht zum > Systemtakt abgeleiteten Takt von außen in den FPGA führt wie zum > Beispiel den Takt eines ADC oder so? Ich rede von den Timing Constraints. Sicher bin ich nicht mehr, aber ich glaube, das muss man auch für abgeleitete Takte machen. Der Analyser und Synthesiser wissen ja nicht, ob man da Clock Domain Crossing eingebaut hat oder ob er wirklich versuchen soll, das Signal auf beide Taktflanken zu synchronisieren (was dann zu sehr geringen maximalen Taktfrequenzen führt).
Gustl B. schrieb: > Deren Toolchain kenne ich nicht. Du könntest mal den Code hier > hochladen. Weil beide PLLs den gleichen Feedbacktakt verwenden solltest > du auch alle damit erzeugten Takte mit nur einer PLL erzeugen können. Ich glaube das wäre zu viel Code und ich komme da gerade nicht ran. Aber mit nur einer PLL geht es easy. Da kann man die Constraints auch schön zu Fuß schreiben. Also einen generierten Takt und alle anderen abgeleitet aus diesem. Das funktioniert sehr gut. Hatte ich vorher auch so. Die Zweite PLL ist nur deshalb entstanden, damit das Modul eher Modular gehalten werden kann. LVDS halt.
Dussel schrieb: > So meine ich das. Ich schließe clk mit zum Beispiel 10 MHz an eine PLL > an und generiere damit zum Beispiel clk_pll_x, clk_pll_y und clk_pll_z. > Dann constraine ich clk mit period 100 ns und schreibe einmal > derive_pll_clocks, was dann für alle drei generierten Takte gilt. Ja, aber ich denke genau dann bezieht sich jede weitere Analyse des Skew der Setup- und Holdzeiten auf genau diese 10Mhz Takt obwohl man die nirgends weiter verwendet. Alle Abweichungen der Flanke von dem Eingangstakt zum Ausgangstakt der PLL ist dann mit eingerechnet obwohl die doch keinen interessiert. Deswegen ist es doch meiner Meinung nach besser den schnellsten generierten Takt der PLL als **Master** (generierter Takt) zu machen. Alle anderen Takte werden ja normalerweise genau von diesem Takt abgeleitet, oder?
Fehlt da am Eingang nicht ein IBUFG? Und warum wird der feedback mit einem Bufg geführt? Und müsste man nicht die PLL 2 an ihrem eingang mit einem Ausgangh der PLL füttern, der NICHT über einen BUFG läuft? Ich habe das immer so, dass BUFG nur verwendet werden, wenn sie die Schaltung treiben. Zwischen PLLs sowie PLL und ODDR kommt kein BUFG, die meckert er immer an.
Steffen H. schrieb: > Ja, aber ich denke genau dann bezieht sich jede weitere Analyse des Skew > der Setup- und Holdzeiten auf genau diese 10Mhz Takt obwohl man die > nirgends weiter verwendet. Alle Abweichungen der Flanke von dem > Eingangstakt zum Ausgangstakt der PLL ist dann mit eingerechnet obwohl > die doch keinen interessiert. Entweder wir reden aneinander vorbei oder einer von uns versteht es nicht richtig. Das kann durchaus auch ich sein, weil ich mich mit den ganzen Constraints nicht vollkommen sicher fühle. Steup- und Hold beziehen sich auf einen Takt. Wenn du
1 | entity xy |
2 | port( clk : in std_logic |
3 | ...
|
schreibst, bezieht sich die Setup- und Hold-Analyse auf Takt clk, wenn du
1 | entity xy |
2 | port( clk_pll_x : in std_logic |
3 | ...
|
schreibst, bezieht sich die Analyse auf clk_pll_x. Woher clk oder clk_pll_x kommt, ist egal. Wichtig sind nur die Eigenschaften des jeweils eingehenden Taktes. Wenn du irgendwelche äußeren Abhängigkeiten hast, ist es dagegen wichtig, das Timing der internen Takte im Verhältnis zu den von außen kommenden zu kennen. Dann sollte das aber auch nicht ignoriert werden. Ich weiß halt nicht, was du mit Mastertakt meinst. Mir ist nicht bekannt, dass es für Analyse oder Synthese sowas wie einen Mastertakt gäbe. Du kannst sowas schreiben wie
1 | entity top is |
2 | port( |
3 | clk_a : in std_logic; -- Von außen über einen Pin |
4 | -- Weitere Portsignale
|
5 | )
|
6 | end entity; |
7 | |
8 | architecture xy of top is |
9 | clk_1 : in std_logic; |
10 | begin
|
11 | entity vendor.vendor_specific_pll |
12 | generic map( |
13 | factor => 10 |
14 | )
|
15 | port map( |
16 | clk_in => clk_a, |
17 | clk_out => clk_1 |
18 | );
|
19 | |
20 | entity work.entity_1 |
21 | port map( |
22 | clk => clk_1, |
23 | ...
|
24 | );
|
25 | |
26 | entity work.entity_2 |
27 | port map( |
28 | clk => clk_a, |
29 | ...
|
30 | );
|
31 | end architecture; |
und das constrainen mit
1 | create_clock -period 100ns get_ports[clk_a] |
2 | derive_pll_clocks |
(Die Syntax wird nicht ganz korrekt sein.) Dann wird für die Analyse und Synthese festgelegt, dass clk_a 10 MHz hat. Mit derive_pll_clocks erkennen Analyse und Synthese, dass clk_a auf eine PLL geht und ein Signal clk_1 mit 10 * 10 MHz (also 100 MHz) erzeugt. In top hängt nichts von den Takten ab, also passietr da auch nichts. Getaktete Signale in entity_1 werden auf clk_1 bezogen, in entity_2 auf clk_a. Da gibt es nichts mit Master. Relevant ist nur der Takt, der die getakteten Signale beeinflusst. Die Takte habe ich absichtlich mit 1 und a bezeichnet, um zu zeigen, dass beide gleichberechtig sind. Falls ich mit irgendwas falsch liege, bin ich an (fundierter) Korrektur interessiert.
Ich muss das erstmal sacken lassen. Markus W. schrieb: > Fehlt da am Eingang nicht ein IBUFG Der ist bestimmt vorhanden, hab den jetzt aber nicht mit gezeichnet weil der für meine Pfade nicht interessant ist. Markus W. schrieb: > Und müsste man nicht die PLL 2 an ihrem eingang mit einem Ausgangh der > PLL füttern, der NICHT über einen BUFG läuft? Das hab ich jetzt auch gesehen. Das wäre schonmal eine Maßnahme, den BUFG am Ausgang C1 der 1.PLL wegzulassen. Ich hatte den nur gesetzt, weil ich in einem Lattice Dokument mal gelesen habe, dass man mit einem BUFG bessere Timing Zeiten erreicht, da auf alle Fälle Clock-pfade verwendet werden. Jetzt hab ich aber in der Doku zur Eagle FPGA und der PLL gelesen, dass die Ausgänge immer einen Clock-Pfad benutzen. Markus W. schrieb: > Und warum wird der feedback mit einem Bufg geführt? Weil das der IP Generator so macht und es scheinbar so sein muss. Das hat scheinbar etwas mit der gewählten Signalsyncronisation zwischen Eingan und Ausgang der PLL zu tun. Dussel schrieb: > Entweder wir reden aneinander vorbei oder einer von uns versteht es > nicht richtig. Das könnte ich sein 🤦♂️ Deswegen muss ich das jetzt ersmal alles ausprobieren.
Markus W. schrieb: > Und warum wird der feedback mit einem Bufg geführt? In Abbildung 1 ist es erklärt. Und dann mal noch die PLL im Überblick.
So, und hier mal noch das Projekt. Die Probleme habe ich im "Serializer_7to1.v"
Hast du dir die txpll mit einem Wizard erzeugen lassen oder selber geschrieben? Ich finde seltsam dass: a) Im Feedbackpfad ein BUFG drinnen sitzt. b) Du hast über den BUFG clk0_buf mit dem Port .fbclk verbunden. clk0_buf steht in der Liste der Clocks aber ganz hinten. Ich kenne Verilog nicht sooo gut und mag generell dieses Protmepping mit Kommatrennung nicht. Für mich sieht das so aus als würde clk0_buf mit dem 5. Ausgang von .clkc verbunden werden. Ist das sicher clk0 wie es seien sollte? Im Datenblatt https://www.mikrocontroller.net/attachment/492387/Eagle_DataSheet_V2.8_english.pdf Seite 26 wäre das die CLKC4. EG_LOGIC_BUFG bufg_fbk( .i(clk0_buf), .o(clk0_out) ); .fbclk(clk0_out), .clkc({open, open, clk2_buf, clk1_buf, clk0_buf}));
Gustl B. schrieb: > Ich kenne Verilog nicht sooo gut und mag generell dieses Protmepping mit > Kommatrennung nicht. Für mich sieht das so aus als würde clk0_buf mit > dem 5. Ausgang von .clkc verbunden werden. Ist das sicher clk0 wie es > seien sollte? Ja, das stimmt schon so. Die geschweiften Klammern mappen nur die Bits. Von links (MSB) nach rechts (LSB). Also Byte [7:0] = {MSB,6,5,4,3,2,1,LSB} Ich habe zwar den 2.PLL nicht mit Wizard erzeugt, aber das sollte so passen. Verdammt - hab gerade die Zip Dateigröße gesehen - warum ist die so groß? 🤤
OK, ja dann ... ich würde das trotzdem um Fehler auszuschließen ausführlicher hinschreiben. .clkc0 (clk0_buf), .clkc1 (clk1_buf), .clkc2 (clk2_buf), .clkc3 (open), .clkc4 (open) ); Was auch komisch ist ist, dass man den Multiplikator anscheinend über .FBCLK_DIV(14), einstellt. Ist das wirklich so? Und dann kann die PLL auch ein REFCLK_SEL = "INTERNAL"; zusammen mit FEEDBK_PATH = "VCO_PHASE_0"; Quelle https://github.com/YosysHQ/yosys/blob/master/techlibs/anlogic/eagle_bb.v ab Zeile 881.
:
Bearbeitet durch User
So, da bin ich wieder. Ja die PLL ist schon recht komisch. Ich verstehe die ganze Sache mit den "LPF Capicator", "LPF Resistor", "IPC Current" usw. nicht. Ist ja auch nicht näher beschrieben. Somit kann ich die verschiedenen Modi nur durch den IP-Generator generieren lassen und mich darauf verlassen, dass dieser das richtig macht. Der BUFG zwischen Ausgang und Eingang Feedback wird in 3 Modi benutzt. Nur in dem "NO COMPENSATION" Mode nicht. Da ist dann der Feedback Eingang fest auf "0" gelegt. Ich hab mal die verschiedenen Modi als Bild des IP und als Code oben in den Bildern dargestellt.
Steffen H. schrieb: > ganze Sache mit den > "LPF Capicator", "LPF Resistor", "IPC Current" usw. nicht. Was IPC Current ist weiß ich auch nicht, aber LPF ist der Tiefpassfilter. Eine PLL ist schon auch ziemlich analog und hier kann man wohl R und C einstellen. Steffen H. schrieb: > Der BUFG zwischen Ausgang und Eingang Feedback wird in 3 Modi benutzt. > Nur in dem "NO COMPENSATION" Mode nicht. Genau, da ist dann nämlich .FEEDBK_PATH("VCO_PHASE_0"), eingestellt. Komisch finde ich, dass es keinen Multiplikator sondern .FBCLK_DIV(25), gibt. Aber ist ja auch OK. Die PLL sieht durchaus mächtig aus, aber mehr Dokumentation wäre fein.
Steffen H. schrieb: > Markus W. schrieb: >> Und warum wird der feedback mit einem Bufg geführt? > > Weil das der IP Generator so macht und es scheinbar so sein muss. Das > hat scheinbar etwas mit der gewählten Signalsyncronisation zwischen > Eingan und Ausgang der PLL zu tun. Das ist doch eigentlich nur bei einer externen Synchronisation nötig, oder? Vielleicht baut der Wizzard das pauschal immer ein, wie auch an anderen Stellen und schmeisst es hinterher raus. Steffen H. schrieb: > Der BUFG zwischen Ausgang und Eingang Feedback wird in 3 Modi benutzt. > Nur in dem "NO COMPENSATION" Mode nicht. Da muss man aufpassen: Der Wizzard hat im aktuellen Vivado eine Macke und merkt sich das nicht richtig. Beim hin-und-herschalten kann es passieren, dass Optionen angeboten werden, die zur externen Synchronisation passen, die aber zum internen loop gehören. Ich habe es leider nicht mehr auswändig im Kopf aber es gab Diskrepanzen zwischen dem erzeugten wrapper und dem Verilog file. Auch an einer anderen Stelle gab es eine Macke: Wenn man mehrere Ausgänge der PLL nutzt und dann wieder welche abschaltet, hat das Modell des Wizzards das nicht mehr drin und es ist grau, aber im erzeugten Verilog stehen die alle noch drin und er bringt eine Warnung. Von der ISE14.7 weiß ich noch, dass er Signale beibehält, die man wieder wegklickt, wie z.B: den reset und den locked. Das wird nach einer Bearbeitung schon inkonsistent. Xilinx haben sehr viel Unordnung in ihren Wizzards.
Markus W. schrieb: > Da muss man aufpassen: Der Wizzard hat im aktuellen Vivado eine Macke > und merkt sich das nicht richtig. Steffen H. schrieb: > Ich arbeite übrigens nicht mit Xilynx sondern mit TD (Tang Dynasty von > Anlogic). [...]FPGA (Eagle20 EG4S20256) Danke für die Warnung an alle Vivado Nutzer hier. Die Diskussion hier geht aber um einen anderen FPGA. Steffen H. schrieb: > Markus W. schrieb: >> Und warum wird der feedback mit einem Bufg geführt? > > In Abbildung 1 ist es erklärt. Und dann mal noch die PLL im Überblick. Nein, ich sehe in diesen zwei Bildern keinen Hinweis darauf, dass der 840 MHz Takt (auf der der VCO läuft) aus der PLL hinaus geht und um die PLL herum geführt wird. Der fbmux kann Ein-/Ausgangsclocks nutzen aber auch direkt den internen VCO Takt.
Christoph Z. schrieb: > Nein, ich sehe in diesen zwei Bildern keinen Hinweis darauf, dass der > 840 MHz Takt (auf der der VCO läuft) aus der PLL hinaus geht und um die > PLL herum geführt wird. Der fbmux kann Ein-/Ausgangsclocks nutzen aber > auch direkt den internen VCO Takt. Doch, sehe ich schon so. Schau mal den Wizzard an und was er daraus macht - siehe oben. https://www.mikrocontroller.net/attachment/500177/PLL_2_NORMAL.v
Steffen H. schrieb: > Doch, sehe ich schon so. Schau mal den Wizzard an und was er daraus > macht - siehe oben. > https://www.mikrocontroller.net/attachment/500177/PLL_2_NORMAL.v OK, diese Bilder hatte ich überlesen. Sorry. Trotzdem bin ich der Ansicht, das du für deine Anwendung keinen BUFG haben solltest und der üblicherweise eingesetzte Mode der PLL hier "no compensation" ist. Dann sollte es auch klappen um aus 24 MHz deine gewünschten 40 MHz zu machen (mit den von dir geschriebenen 480 MHz VCO Frequenz). Und dann auch (hoffentlich) ohne zusätzliche Constraints so wie es bei anderen Toolschains auch funktioniert.
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.