AXI Bridge for PCI Express Gen3 Subsystem sys_clk_gt use?

[whitleda]

What do I connect sys_clk_gt on the AXI Bridge for PCI Express Gen3 Subsystem block?  The user guide only list the port and says it is only availalbe on Ultrascale.  Do I connect it to the same source as the refclk pin as shown in the attachment?

[whitleda]

Second try at the attachment..

[yenigal]

Hi

NO, you should connect the sysclk to any other stable clock.

The ref clock of the GT should be connected to external reference clock and it should not be shared or used for any other clocks in the design.

[whitleda]

Ok.  What is sys_clk_gt for then?

[kotir]

Hi ,

sys_clk_gt input is for referance clock input for GT.

sys_clk is given for DRP port of the GT blocks.

Have a look at the snapshot i took below with example design  pf pcie core.

The reason for providing the different clock is DRPCLK has limitation which might be below the allowed ref clocks.

You have to check the device datasheet to check the mac DRPCLK allowed in your device.

If its equal to ref clock you can give the same to sys_clk and sys_clk_gt.

Other wise you should use the devided output to DRPCLK.

Regards,

KR

[whitleda]

Seems to be conflicting info...please refer to the block in the image from the first post.  For the KU040 device, I have the following clock inputs:

axi_ctl_aclk

sys_clk_gt

refclk

axi_ctl_aclk is self explanatory but what is the difference between sys_clk_gt & refclk?  In the past, the PCIe Reference Clock was connected to refclk.  This block does not have the plain sys_clk input shown in the screenshot above.  

[yenigal]

Hi

The sys clk and the ref clk are the same and just renamed at different modules.

The explantion given by koti is correct regading the Sys_clk_gt and ref_clk(same as sys_clk).

Refer below snapshot which clearly shows this.

Hope this clarifies your query.

I suggest you to generate the example design for the core from IP catalog and refer the connections if you still have any further doubts about the cloking to the core.

[whitleda · Accepted solution]

Thank you for clarifying this.  The example design does help now that you mention "refclk" and "sys_clk" are referred to interchangeably. 

This is very confusing when reading PG194.  Table 2-5 lists "refclk" as PCIe Reference Clock and "sys_clk_gt" as system clock.  Figure 2-1 shows "refclk" connected to the output of the IBUFDS_GTE3.  This contradicts our conversation but after seeing the example design, it seems PG194 needs to be updated for UltraScale.

I have changed the connections per our conversation as seen in the attached screenshot.

[yenigal]

Hi

I do agree that the PG is confusing for the Ultrascale clocking description,I will let the internal team know and see that it get corrected.

Your modified clocking connections look good now.

[jg_bds]

Good job: the documentation for this IP is getting better.  But we've run into a snag.  We're using Rev. 2.0 of the IP within Vivado 15.3. 

PG194 says, for the "refclk" port: "UltraScale: DRP Clock and Internal System Clock (Half frequency from sys_clk_gt frequency). Should be driven by the ODIV2 port of reference clock IBUFDS_GTE3". (emphasis added.)

However, by default, the output of the IBUFDS_GTE3 port called "ODIV2" is the same as the output on the the port called "O".  (Both are divide-by-one versions of the input to the buffer.) 

Furthermore, the KCU105 PCIe TRD assigns the same fequency to both clocks when creating the constraints for those signals (in trd01.xdc):

--------------------------------------------------------------------------

create_clock -period 10.000 -name sys_clk [get_pins refclk_ibuf/ODIV2]
create_clock -period 10.000 -name sys_clk_gt [get_pins refclk_ibuf/O]

--------------------------------------------------------------------------

Just looking for clarification here: should the clock into the "refclk" port have the same frequency as the clock into the "sys_clk_gt" port, or should it have half of the frequency?

[olwefin]

Hello,

we're facing the same question as jg_bds.

any answers to his question ?

regards,

[jg_bds]

olwefin,

Our best guess is the frequency of both clocks should be (or can be) the same: 100 MHz, in our case.  Our 'top-level' design is maintained in IPI.  Below is a relevant snippet.  (This design is working in our lab right now.)

The Utility Buffer IP does not make accessible, customization parameters for the underlying buffer.  We assume it's using the buffer's default settings, so both outputs are 1x versions of the input.

Looking at our Implemented Design, only our top-level constrained clock (the PCI reference clock) is shown explicitly as being 100 MHz in the Clock Networks Report.  The frequencies of the derived clocks (from the "O" and "ODIV2" outputs of the buffer) are not shown.  One can assume the frequency didn't change through the buffer.... right?  :-)

To bolster this argument, I looked at the 'worst' Intra-clock path for the clock realm constrained by our top-level 100-MHz constraint into the PCIe clock input buffer.  The report shows that path has a "Requirement" of 10.000 nS.  The path in question is driven directly by the "ODIV2" output of the IBUFDS_GTE3 buffer. 

Good luck,

Joe G.

[jg_bds]

Sorry--forgot to point out: the DIV[2:0] inputs of the BUFG_GT (in the timing schematic at the bottom of the post) are all tied to GND.

[olwefin]

many thanks