Announcement: there is an English version of this forum on 
hallo guten Tag, wenn man ein clocking wizard einsetze, muss man dann den output noch als generated clock in die *.xdc liste reinschreiben? Meine Implementation funktioniert nicht. Und vielleicht liegt es daran.
Angehängte Dateien:
-
whiz.png
46 KB
M.E. kommt aus dem IP-Wizzard auch ein passendes xdc-File mit raus. mutprobe schrieb: > Meine Implementation funktioniert nicht. Jo, das ist mal eine super-konkrete Aussage. Wie ist denn Deine Erwartung? Und was beobachtest Du? Duke
Angehängte Dateien:
-
whiz2_impl_critical_error.png
6,4 KB -
whiz2_bitstream_critical_error.png
12 KB -
whizFrage.png
20 KB
Duke Scarring schrieb: > M.E. kommt aus dem IP-Wizzard auch ein passendes xdc-File mit raus. Es wurde keins generiert. Duke Scarring schrieb: > Jo, das ist mal eine super-konkrete Aussage. > Wie ist denn Deine Erwartung? > Und was beobachtest Du? * Die mmcm bekommt ein Eingangssignal. * Die externe Clock ist damit direkt verbunden. * Allerdings ist diese externe Clock auch noch mit meinem IP-Core verbunden * Der Ausgang wird mit einem Signal verbunden, dass dann auch mit meinem IP-Core verbunden ist.
1 | component clk_wiz_0 |
2 | port
|
3 | (-- Clock in ports |
4 | -- Clock out ports |
5 | DCLK_50MHz : out std_logic; |
6 | -- Status and control signals |
7 | reset : in std_logic; |
8 | locked : out std_logic; |
9 | clk_in1 : in std_logic |
10 | );
|
Wenn ich das ein-kommentiere geht es nicht mehr:
1 | clockgen_dclk : clk_wiz_0 |
2 | port map ( |
3 | -- Clock out ports |
4 | DCLK_50MHz => DCLK_50MHz, |
5 | -- Status and control signals |
6 | reset => reset_clock_wizards, |
7 | locked => locked, |
8 | -- Clock in ports |
9 | clk_in1 => a7_mgt216_clk_p_i |
10 | );
|
hiermit geht es: * Es lässt sich auch ein Bitstream erzeugen.
1 | clockgen_dclk : clk_wiz_0 |
2 | port map ( |
3 | -- Clock out ports |
4 | DCLK_50MHz => DCLK_50MHz, |
5 | -- Status and control signals |
6 | reset => reset_clock_wizards, |
7 | locked => locked, |
8 | -- Clock in ports |
9 | clk_in1 => testclk |
10 | );
|
* Es liegt also an meiner externen eingangs clk * Man muss diese doch sowohl für den IP-Core als auch für den Clock Wizard verwenden können oder nicht?
vielleicht finde ich noch eine andere Clock auf dem Board oder nehme die Output Clock von meinem IP Core :P Aber allgemein wundert es mich :D
mutprobe apollo2022 schrieb: > Aber allgemein wundert es mich :D Sieh dir die Dokumentaion deines FPGAs an. Da muss sehr wahrscheinlich noch ein CLK-Buffer rein, wenn du den selben Takt in einen Clock-Manager und auf ein Taktnetz geben willst.
Lothar M. schrieb: > mutprobe apollo2022 schrieb: >> Aber allgemein wundert es mich :D > Sieh dir die Dokumentation deines FPGAs an. > Da muss sehr wahrscheinlich noch ein CLK-Buffer rein, wenn du den selben > Takt in einen Clock-Manager und auf ein Taktnetz geben willst. Aber wie sieht denn so ein Clock Buffer aus? Warum macht Vivado das nicht einfach. Kann ich einen Clock Wizard direct an meinen externen Taktgeber anschließen und dann die Signale von dort aus zu meinem IP und zu meinem anderen Zeug leiten? Werde jetzt mal nem differentiellen clock wizard erstellen . Also mit differentiellem Eingang ... Nee gar keine Chance
1 | Clock gen -> Clocking Wizard ->156Mhz ->ip core |
2 | -> 50 Mhz ->anderes |
so was hatte ich glaube ich schon mal probiert. es will einfach nie klappen.
1 | [Vivado 12-1411] Cannot set LOC property of ports, Could not legally place instance your_instance_name/inst/clkin1_ibufgds at F13 (IPAD_X1Y46) since it belongs to a shape containing instance a7_mgt216_clk_n_i. The shape requires relative placement between your_instance_name/inst/clkin1_ibufgds and a7_mgt216_clk_n_i that can not be honoured because it would result in an invalid location for a7_mgt216_clk_n_i. ["srcs/constrs_1/new/myconstraints.xdc":62] |
2 | |
3 | und
|
4 | |
5 | |
6 | [DRC REQP-1619] IBUFDS_GTE2_driven_by_IBUF: IBUFDS_GTE2 xaui_core/U0/xaui_support_clocking_i/refclk_ibufds pins I and IB should be driven by IBUFs. |
Angehängte Dateien:
-
mmcm_xilinx.png
31 KB
Tja oben im ersten Post ist der Screenshot leider rechts abgeschnitten. Denn genau dort kann man einstellen ob der Takteingang für die PLL ein dedizierter FPGA Pin ist oder ob da ein interner Takt verwendet wird. Stell da einfach global Buffer ein und gut.
mutprobe schrieb: > Warum macht Vivado das nicht einfach. Macht es. Eine Seite weiter kannst du das einstellen, ob ein buffer drangehängt werden soll. Deine Doppelverdrahtung ist aber so! nicht "recommended".
Angehängte Dateien:
-
clk_bufferyesno.png
5,7 KB -
frage_clkwiorzard_diff.png
29 KB
Gustl B. schrieb: > Tja oben im ersten Post ist der Screenshot leider rechts abgeschnitten. > Denn genau dort kann man einstellen ob der Takteingang für die PLL ein > dedizierter FPGA Pin ist oder ob da ein interner Takt verwendet wird. > Stell da einfach global Buffer ein und gut. (Korrektur skizze)
1 | Clock gen_n -> |Clocking Wizard ->156Mhz ->ip core |
2 | Clock gen_p -> | -> 50 Mhz ->anderes |
* Habe gestern differentielle Clock im Wizard eingestellt, aber es hat nicht funktioniert. Zoran schrieb: > Eine Seite weiter kannst du das einstellen, ob ein buffer > drangehängt werden soll. > > Deine Doppelverdrahtung ist aber so! nicht "recommended". Vielleicht kann ich die für den Core entfernen. Sowohl beide 156 MHz Eingänge als auch der Transceiver Eingang haben intern schon Buffer.. Was meinst du mit Doppelverdrahtung? Wie würdest du das machen wenn du externe 156 Mhz hast und die für unterschiedliche Netzwerke verwenden möchtest?
mutprobe schrieb: > (Korrektur skizze)Clock gen_n -> |Clocking Wizard ->156Mhz ->ip core > Clock gen_p -> | -> 50 Mhz ->anderes > * Habe gestern differentielle Clock im Wizard eingestellt, aber es hat > nicht funktioniert. Das geht natürlich nicht. Du brauchst da am Eingang einen IBUFDS, und dahinter einen BUFG. Dann bist du mit dem Clock schon auf dem globalen Clock Netzwerk. Von da kannst du alle FlipFlops und sonstigen Elemente im FPGA erreichen. Wenn du dann parallel zur Logik an einen MMCM willst, musst du für dessen Eingang "No Buffer" einstellen. Dann gibts auch keine Fehler
Christian R. schrieb: > Wenn du dann parallel zur Logik an einen MMCM willst, > musst du für dessen Eingang "No Buffer" einstellen. Dann gibts auch > keine Fehler Global Buffer geht genauso. mutprobe schrieb: > Gustl B. schrieb: >> Tja oben im ersten Post ist der Screenshot leider rechts abgeschnitten. >> Denn genau dort kann man einstellen ob der Takteingang für die PLL ein >> dedizierter FPGA Pin ist oder ob da ein interner Takt verwendet wird. >> Stell da einfach global Buffer ein und gut. > > (Korrektur skizze)Clock gen_n -> |Clocking Wizard ->156Mhz ->ip core > Clock gen_p -> | -> 50 Mhz ->anderes > * Habe gestern differentielle Clock im Wizard eingestellt, aber es hat > nicht funktioniert. Ich hatte geschrieben "global Buffer" und du stellst einen differentiellen Eingang ein. Wenn du Hilfe nicht annimmst, dann bringt das nichts. BUFG ist der globale Buffer.
:
Bearbeitet durch User
Angehängte Dateien:
-
000_Frage_clockWuizzard.png
100 KB
Jetzt habe ich überall BUFG eingestellt. Habe nur einen Eingang mit der Externen Clk beschaltet. Dann die Ausgänge an meinen IP Core geleitet.
1 | your_instance_name : clk_wiz_0 |
2 | port map ( |
3 | -- Clock out ports |
4 | DCLK_50MHz => DCLK_50MHz, |
5 | REFCLKN_156_25_MHz => REFCLKN_156_25_MHz, |
6 | REFCLKP_156_25_MHz => REFCLKP_156_25_MHz, |
7 | -- Status and control signals |
8 | reset => reset_clock_wizards, |
9 | locked => locked, |
10 | -- Clock in ports |
11 | clk_in1 => a7_mgt216_clk_p_i |
12 | );
|
Jetzt bekomme ich die Meldung bei der Implementation:
1 | [DRC REQP-1619] IBUFDS_GTE2_driven_by_IBUF: IBUFDS_GTE2 xaui_core/U0/xaui_support_clocking_i/refclk_ibufds pins I and IB should be driven by IBUFs. |
https://www.xilinx.com/support/documentation/user_guides/ug472_7Series_Clocking.pdf#page=114 Appendix B: Clocking Resources and Connectivity Variations per Clock Region X-Ref Target - Figure B-4 Figure B-4: Clock Region in a Artix-7 XC7A200T Device with GTP Transceivers and I/O Banks (Right Side) Es hat wohl hiermit was zu tun oder?
Meines Wissens geht das nicht was du vor hast. Der GTP braucht seinen Takt direkt vom zugehörigen REF_CLK Eingang der GTP Bank. Du musst deine Logik dahinter dann mit dem USERCLK versorgen. Und zum Starten brauchen die GTP auch noch einen Takt der immer läuft, also unabhängig vom REFCLK.
Angehängte Dateien:
https://blog.actorsfit.com/a?ID=01700-3cc10027-7817-4984-87bc-a50585d54a1d Christian R. schrieb: > Der GTP braucht seinen > Takt direkt vom zugehörigen REF_CLK Eingang der GTP Bank. IBUFDS_GTPE2 ist schon sehr nah an den physikalischen pins oder? Deswegen kann man die REFCLK_N/P direkt dort anschließen oder? > Du musst deine > Logik dahinter dann mit dem USERCLK versorgen. Also einem separaten Takt? Man muss doch irgendwie auch die refclk_p/n verwenden können oder? >Und zum Starten brauchen > die GTP auch noch einen Takt der immer läuft, also unabhängig vom > REFCLK. Aber welchen? Wo soll der angeschlossen werden? Es gibt nur noch einen DCLK-Eingang. Aber ist der nicht nur für Debugzwecke da?
1 | Clock used as the DRP clock, and also as a stable reference clock for the |
2 | detection of the feedback and reference clock signals to the QPLL. The |
3 | input reference clock to the QPLL or any output clock generated from |
4 | the QPLL (for example, TXOUTCLK) must not be used to drive this clock. |
5 | For UltraScale devices this clock is also used in the internal state |
6 | machines for the configuration of the transceiver. |
sehe aber auch gerade im Datenblatt das ich das hier noch machen muss/ beachten muss.
1 | create_clock -name dclk -period 20.000 [get_ports dclk] |
2 | |
3 | ### und:
|
4 | |
5 | |
6 | set_property LOC GTXE2_CHANNEL_X1Y8 [get_cells -hierarchical -filter {NAME =~ */ |
7 | gt_wrapper_i/gt0_<CompName>_gt_wrapper_i/gtxe2_i}] |
8 | |
9 | ### bis zu gt3
|
Angehängte Dateien:
-
003IBUFDS_GTE2.png
47 KB
Also was wird denn hier gemeint?
1 | "[DRC REQP-1619] IBUFDS_GTE2_driven_by_IBUF: IBUFDS_GTE2 xaui_core/U0/xaui_support_clocking_i/refclk_ibufds
|
2 | |
3 | pins I and IB should be driven by IBUFs."
|
An I und IB, also der interne CLK-Buffer-Eingang des IP-Cores, soll ein IBUF dran? IBUFs sind die Buffer die mit den FPGA - Pins verbunden sind?
1 | Clock-Capable-Pin -> IBUFG -> I -IBUFDS_GTE2 |IP - |
2 | Clock-Capable-Pin -> IBUFG -> IB-IBUFDS_GTE2 |Core |
Ich glaube der Clock-Wizard hat da aber ein BUFG eingesetzt
1 | Clock-Capable-Pin ->"Global Buffer"? CLK-Wizard-> BUFG -> I -IBUFDS_GTE2 |IP - |
2 | Clock-Capable-Pin ->"Global Buffer"? CLK-Wizard -> BUFG -> IB-IBUFDS_GTE2 |Core |
Angehängte Dateien:
Im Anhang habe ich mal das Schematic. Ist das vlt. einfach so, das der IP Core Eingang dann IBUF Buffer als Verbindung benötigt und keine BUFG? Danke :)
Aber ich verstehe das nicht.. Ich wollte gerade mal mgt13 clk p nutzen.. habe gedacht ich kann das an eine MMCM anschließen. Zuerst habe ich gemacht
1 | 156Mhz-> "IBUFG"-> CLK-WIZARD["BUFG" ----->"BUFG"]-> 50 MHz |
Das ging nicht ... jetzt habe ich gemacht:
1 | 156Mhz-> "IBUFG"-> CLK-WIZARD["no_buffer" ----->"BUFG"]-> 50 MHz |
Und es steht dort trotzdem, dass es nicht optimal ist.
1 | [Place 30-575] Sub-optimal placement for a clock-capable IO pin and MMCM pair. If this sub optimal condition is acceptable for this design, you may use the CLOCK_DEDICATED_ROUTE constraint in the .xdc file to demote this message to a WARNING. However, the use of this override is highly discouraged. These examples can be used directly in the .xdc file to override this clock rule. |
2 | < set_property CLOCK_DEDICATED_ROUTE FALSE [get_nets a7_mgt213_clk_p_i_IBUF] > |
3 | |
4 | a7_mgt213_clk_p_i_IBUF_inst (IBUF.O) is locked to IPAD_X1Y10 |
5 | your_instance_name/inst/mmcm_adv_inst (MMCME2_ADV.CLKIN1) is provisionally placed by clockplacer on MMCME2_ADV_X0Y2 |
6 | |
7 | The above error could possibly be related to other connected instances. Following is a list of |
8 | all the related clock rules and their respective instances. |
9 | |
10 | Clock Rule: rule_mmcm_bufg |
11 | Status: PASS |
12 | Rule Description: An MMCM driving a BUFG must be placed on the same half side (top/bottom) of the device |
13 | your_instance_name/inst/mmcm_adv_inst (MMCME2_ADV.CLKFBOUT) is provisionally placed by clockplacer on MMCME2_ADV_X0Y2 |
14 | and your_instance_name/inst/clkf_buf (BUFG.I) is provisionally placed by clockplacer on BUFGCTRL_X0Y1 |
Ich glaube du solltest dich mal mit dem passenden clocking user guide eine Weile zurückziehen und intensiv beschäftigten. Alle deine Fragen zeugen von einem gewissen grundlegenden Unverständnis... Duke
Angehängte Dateien:
Ja stimmt.
mutprobe schrieb: > https://blog.actorsfit.com/a?ID=01700-3cc10027-7817-4984-87bc-a50585d54a1d > > Christian R. schrieb: >> Der GTP braucht seinen >> Takt direkt vom zugehörigen REF_CLK Eingang der GTP Bank. > IBUFDS_GTPE2 ist schon sehr nah an den physikalischen pins oder? > Deswegen kann man die REFCLK_N/P direkt dort anschließen oder? Du MUSST den da anschließen. Und dazwischen muss der IBUFDS_GTPE2 wie im Bild. Dein Bild ist doch eindeutig, es geht nur genau so und nicht anders. >> Du musst deine >> Logik dahinter dann mit dem USERCLK versorgen. > Also einem separaten Takt? > Man muss doch irgendwie auch die refclk_p/n verwenden können oder? Nein, das geht nicht, die REFCLK sind ausschließlich für die GTP. Siehe dein Bild, der 156MHz kommt dann hinten wieder raus, das ist ja am TXUSERCLK dran. >>Und zum Starten brauchen >> die GTP auch noch einen Takt der immer läuft, also unabhängig vom >> REFCLK. > > Aber welchen? Wo soll der angeschlossen werden? > Es gibt nur noch einen DCLK-Eingang. > Aber ist der nicht nur für Debugzwecke da? > Clock used as the DRP clock, and also as a stable reference clock for > the > detection of the feedback and reference clock signals to the QPLL. The > input reference clock to the QPLL or any output clock generated from > the QPLL (for example, TXOUTCLK) must not be used to drive this clock. > For UltraScale devices this clock is also used in the internal state > machines for the configuration of the transceiver. Genau der, im Text steht ja, dass er gebraucht wird, um den Transceiver zu starten und einzustellen. Die Transceiver und die zugehörigen Pins sind keine allgemeinen Ressourcen, da gibts nur diese Möglichkeit, die dein gepostetes Bild zeigt.
Hey vielen Dank. Christian R. schrieb: > Genau der, im Text steht ja, dass er gebraucht wird, um den Transceiver > zu starten und einzustellen. Das haben die so geschrieben, dass ich es nicht verstanden habe. Christian R. schrieb: > Die Transceiver und die zugehörigen Pins sind keine allgemeinen > Ressourcen, Ok muss mir das physikalisch anschauen. MGT213 CLK P / N sollte doch grundsätzlich auch mit einer MMCM verbunden werden können, damit ich 50 MHz erzeugen kann oder? Ich habe hier auch einen Beispielcode wo jmd die MGT zuerst in einen Clock buffer IBUFDS_GTE2 leitet und dann erst in den Wizard. Werde ich mal testen. Andererseits könnte ich auch die vom core bereitgestellten 156 MHz in eine MMCM leiten und dann 50 MHz wieder an ihn zurück leiten.
mutprobe schrieb: > MGT213 CLK P / N sollte doch grundsätzlich auch mit einer MMCM verbunden > werden können, damit ich 50 MHz erzeugen kann oder? Ne, das ist nicht vorgesehen, und auch aus den Blockschaltbildern im GTP User Guide ersichtlich. > Ich habe hier auch einen Beispielcode wo jmd die MGT zuerst in einen > Clock buffer IBUFDS_GTE2 leitet und dann erst in den Wizard. > Werde ich mal testen. Ja, das muss man machen, siehe dein Bild. Aber ein Abzweig zur "normalen" MMCM ist nicht möglich. > Andererseits könnte ich auch die vom core bereitgestellten 156 MHz in > eine MMCM leiten und dann 50 MHz wieder an ihn zurück leiten. Ach, daher weht der Wind, du hast vergessen, den DCLK auf´s Board zu bauen. Nee, das klappt nicht, denn der GTP wird mit Hilfe des DCLK über diese Startup State Machine erst eingestellt, der USERCLK kommt da erst nachher raus. Da bleibt als einzige Möglichkeit, wenn du keinen unabhängigen Takt hast, den CCLK intern zu benutzen, mit der STARTUPE2 Primitive geht das. Der ist zwar nicht genau und wackelt ein bissl, aber für den DCLK sollte es gehen.
ok ja ich sehe das jetzt auch hier: >The dclk clock provided to the core must be a free running clock since it >also used to clock the logic for transceiver reset/initialization >circuitry. The dclk clock must not be derived from any transceiver output ich sehe gerade nur noch M16 und M17 die angeschlossen sind. Dort steht zwar, dass sie "differential" gpios sind aber nicht, dass sie clock capable sind. Ansonsten ist da noch ein mgt213 aber das scheint ja auch nicht zu gehen, dass ich da 50 MHz her gewinne. Also ansonsten wirklich wie du vorschlägst durch interne clks. Muss der FPGA nicht irgendeinen Takt bekommen um überhaupt zu arbeiten? Wo wird denn angeschlossen?
mutprobe schrieb: > Also ansonsten wirklich wie du vorschlägst durch interne clks. > Muss der FPGA nicht irgendeinen Takt bekommen um überhaupt zu arbeiten? > Wo wird denn angeschlossen? Ja das ist der Configuration Clock, CCLK. Der wird intern in einem Ringoszillator erzeugt, den kannst du intern an der STARTUPE2 abgreifen, an CFGMCLK. So wie es aussieht ist der dauerhaft aktiv und bei ungefähr 65MHz...das ist aber eine üble Notlösung. Ob das zuverlässig klappt, muss man probieren. Da der DRP aber synchron ist, sollte es gehen.
mutprobe schrieb: > ich sehe gerade nur noch M16 und M17 die angeschlossen sind. Dort steht > zwar, dass sie "differential" gpios sind aber nicht, dass sie clock > capable sind. Zur Not geht das auch, für den MGT Start sollte es reichen. Da muss man dann halt über Constraints sagen dass man das so will, sonst gibt's viel Gemecker.
Angehängte Dateien:
-
forumfrage2.png
130 KB -
forumfrage.png
120 KB
Würde gerne trotzdem noch mal fragen, was gemeint ist in UG472
(Clocking) und UG482 (Transceiver).
Kann man MGTREFCLK[0/1]P/N doch indirekt nutzen?
Da steht das über einen MUX das Signal IBUFDS_GTE2 ("Output to Logic3")
an die Logik weitergegeben werden kann?
jetzt gibt es dort aber "timing issues" ich schaue mir mal mit der Vivado timing analysis an ob ich kritische Pfade erkenne...
Angehängte Dateien:
-
frage_clocking.png
100 KB
Bei **Report Timing Summary** kann man das Design sehen.
Habe jetzt eine MMCM an den Output von von IBUFDS angeschlossen.
Daran ist ein einfacher process angeschlossen.
Der ist jetzt schon stark gekürzt.
Aber es kommt immer zu dem gleichen critical warning:
```
[Timing 38-282] The design failed to meet the timing requirements.
Please see the timing summary report for details on the timing
violations.
```
```
p_counter : PROCESS (clk_156_25_p)
BEGIN
IF rising_edge(clk_156_25_p)THEN
-- counter_value <= counter_value + 1;
reset <= '1';
END IF;
END PROCESS p_counter;
```
Hat jemand eine Idee?
Angehängte Dateien:
-
froumFrage3.png
28 KB
Hier steht von meinem Process bis zu dem IP-Core gibt es timing Verletzungen. Warum? Ist der Weg so lang? Gibt es so viele Verzögerungen? Danke
Duke Scarring schrieb: >> timing summary report > Was steht denn da drin? ** Muss mir doch noch genauer anschauen! ** Das einzige was mir bis jetzt aufgefallen ist,ist dass dieser Pfad der von meinem Prozess zu dem Reset meines IP-Cores geht, eine zu große Verzögerung hat. Setup ist dabei rot. Das andere blaue. Design Timing Summary Timing constraints are not met _____________________________________________________________ # Inter clock paths ## Setup Path 41:
1 | * requirement: 0.8 |
2 | |
3 | * from: reset_reg/C |
4 | * to: xaui_core/U0/xaui_block_i/reset_sync_i/sync1_r_reg[0]/D |
5 | * total delay: 9.78 ns |
6 | * logic delay: 0.478 |
7 | * net delay: 9.302 |
8 | |
9 | |
10 | |
11 | * slack -3.637 |
12 | * high fanout = 5 |
13 | * route = 1 |
14 | * level = 0 |
15 | source: xaui_core/U0/xaui_block_i/gt_wrapper_i/gt0_xaui_0_gt_wrapper_i/gtpe2_i/TXOUTCLK |
16 | destination: dclk |
### Hold Path 42:
1 | requierement: 0 |
2 | from; reset_reg/C |
3 | to: xaui_core/U0/xaui_block_i/reset_sync_i/sync1_r_reg[0]/D |
4 | slack 0.644 |
5 | |
6 | |
7 | net delay: 7.966 |
8 | |
9 | xaui_core/U0/xaui_block_i/gt_wrapper_i/gt0_xaui_0_gt_wrapper_i/gtpe2_i/TXOUTCLK |
10 | dclk
|
Christian R. schrieb: >> MGT213 CLK P / N sollte doch grundsätzlich auch mit einer MMCM verbunden >> werden können, damit ich 50 MHz erzeugen kann oder? > > Ne, das ist nicht vorgesehen, und auch aus den Blockschaltbildern im GTP > User Guide ersichtlich. Und was sagst du zu dem abgezweigten Ausgang von dem IBUFDS_GTE2? >IBUFDS_GTE2 is a redundant output for additional clocking scheme >flexibility. Ist der nutzbar mit einer MMCM?
Offensichtlich kannst du das so verwenden, obwohl es dem eindeutigen "must not be used" widerspricht: "Clock used as the DRP clock, and also as a stable reference clock for the detection of the feedback and reference clock signals to the QPLL. The input reference clock to the QPLL or any output clock generated from the QPLL (for example, TXOUTCLK) must not be used to drive this clock.". Ob die PLL dann wirklich damit auf den REFCLK einrastet ist natürlich immer noch fraglich... Dein Timing error scheint eher daher zu kommen, dass der Reset offenbar gerne synchron zum TXOUTCLK sein möchte, soweit ich die Fehler Schnipsel interpretiere. Das musst du dann noch einsynchronisieren (Mindestanzahl Takte beachten) und wahrscheinlich ein multi cycle Constraint setzen.
Angehängte Dateien:
-
qpll.png
82 KB -
letztefrage.png
34 KB
# 1.) 50 MHz erzeugen aus eingehenden mgt216 clocks ## "Must not be used" * Ah, jetzt verstehe ich erst, dass (der Ausgang von IBUFDS) GTREFCLK0 zur QPLL ( PLL in COMMON) geht. * Das abgezweigte "O" durch den MUX ist also quasi die "input reference clock to the QPLL". * Und diese "must not be used to drive this clock". ## MMCM * Konnte auch noch nicht sehen, dass man irgendwo dazwischen eine MMCM setzen kann. * Würde gerne wissen warum das so ist, ob das möglich ist und ob man das in Ausnahmefällen macht. * Aber es würde vielleicht gar nichts bringen, weil es eine Ableitung der "input reference clock to the QPLL" wäre, die nicht genutzt werden soll. # 2.) Timing Christian R. schrieb: > Dein Timing error scheint eher daher zu kommen, dass der Reset offenbar > gerne synchron zum TXOUTCLK sein möchte, soweit ich die Fehler Schnipsel > interpretiere. Das musst du dann noch einsynchronisieren (Mindestanzahl > Takte beachten) und wahrscheinlich ein multi cycle Constraint setzen. Danke sehr! Muss ich mir anschauen.
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.