Forum: FPGA, VHDL & Co. xilinx clocking wizard ip frage


von mutprobe (Gast)


Angehängte Dateien:

Lesenswert?

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.

von Duke Scarring (Gast)


Lesenswert?

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

von apollo2022 (Gast)



Lesenswert?

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?

von mutprobe apollo2022 (Gast)


Lesenswert?

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

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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.

von mutprobe (Gast)


Lesenswert?

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.

von Gustl B. (-gb-)


Angehängte Dateien:

Lesenswert?

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.

von Zoran (Gast)


Lesenswert?

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

von mutprobe (Gast)


Angehängte Dateien:

Lesenswert?

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?

von Christian R. (supachris)


Lesenswert?

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

von Gustl B. (-gb-)


Lesenswert?

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


Angehängte Dateien:

Lesenswert?

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.

von mutprobe (Gast)


Lesenswert?

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?

von Christian R. (supachris)


Lesenswert?

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.

von mutprobe (Gast)


Angehängte Dateien:

Lesenswert?

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.

von mutprobe (Gast)


Lesenswert?

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

von mutprobe (Gast)


Angehängte Dateien:

Lesenswert?

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

von mutprobe (Gast)



Lesenswert?

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

von mutprobe (Gast)


Lesenswert?

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

von Duke Scarring (Gast)


Lesenswert?

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

von mutprobe (Gast)


Angehängte Dateien:

Lesenswert?

Ja stimmt.

von Christian R. (supachris)


Lesenswert?

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.

von mutprobe (Gast)


Lesenswert?

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.

von Christian R. (supachris)


Lesenswert?

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.

von mutprobe (Gast)


Lesenswert?

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?

von Christian R. (supachris)


Lesenswert?

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.

von Christian R. (supachris)


Lesenswert?

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.

von mutprobe (Gast)


Angehängte Dateien:

Lesenswert?

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?

von mutprobe (Gast)


Lesenswert?

jetzt gibt es dort aber "timing issues" ich schaue mir mal mit der 
Vivado timing analysis an ob ich kritische Pfade erkenne...

von mutprobe (Gast)


Angehängte Dateien:

Lesenswert?

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?

von mutprobe (Gast)


Angehängte Dateien:

Lesenswert?

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

von Duke Scarring (Gast)


Lesenswert?

mutprobe schrieb:
> timing summary report
Was steht denn da drin?

von mutprobe (Gast)


Lesenswert?

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

von mutprobe (Gast)


Lesenswert?

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?

von Christian R. (supachris)


Lesenswert?

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.

von mutprobe (Gast)


Angehängte Dateien:

Lesenswert?

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

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.