Forum: FPGA, VHDL & Co. Fragen zu Timing Constraints mit 2 PLL's


You were forwarded to this site from EmbDev.net. Back to EmbDev.net
von Steffen H. (avrsteffen)


Angehängte Dateien:

Lesenswert?

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?

von Gustl B. (-gb-)


Lesenswert?

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.

von Dussel (Gast)


Lesenswert?

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.

von Gustl B. (-gb-)


Lesenswert?

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.

von Steffen H. (avrsteffen)


Angehängte Dateien:

Lesenswert?

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?

von Steffen H. (avrsteffen)


Lesenswert?

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?

von Gustl B. (gustl_b)


Lesenswert?

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.

von Dussel (Gast)


Lesenswert?

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

von Steffen H. (avrsteffen)


Lesenswert?

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.

von Steffen H. (avrsteffen)


Lesenswert?

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?

von Michael W. (Gast)


Lesenswert?

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.

von Dussel (Gast)


Lesenswert?

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.

von Steffen H. (avrsteffen)


Lesenswert?

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.

von Steffen H. (avrsteffen)


Angehängte Dateien:

Lesenswert?

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.

von Steffen H. (avrsteffen)


Angehängte Dateien:

Lesenswert?

So, und hier mal noch das Projekt. Die Probleme habe ich im 
"Serializer_7to1.v"

von Gustl B. (-gb-)


Lesenswert?

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}));

von Steffen H. (avrsteffen)


Lesenswert?

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ß? 🤤

von Gustl B. (-gb-)


Lesenswert?

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
von Steffen H. (avrsteffen)



Lesenswert?

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.

von Gustl B. (-gb-)


Lesenswert?

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.

von Michael W. (Gast)


Lesenswert?

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.

von Christoph Z. (christophz)


Lesenswert?

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.

von Steffen H. (avrsteffen)


Angehängte Dateien:

Lesenswert?

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

von Christoph Z. (christophz)


Lesenswert?

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