cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
muellera
Adventurer
Adventurer
337 Views
Registered: ‎02-22-2016

Frequency offset PCIe AXI/DMA IP axi_aclk output

Hi,

my design contains a test block which verifies the correct frequency of all clocks inside the FPGA (fabric). This is done by counting the clock ticks which happen inside a time interval and compare the result to the expected number of clock ticks.

This simple method works well for all my clocks, but one, the axi_aclk clock from the PCIe AXI/DMA IP core. This axi_aclk signal is off by about -2200 ppm. The frequency deviation is the same across several hardware units which I tested, +- 25 ppm variance. The reference clock input to the PCIe block is well within specifications (is 50 ppm, needs 300 ppm) and the PCIe link training is successful and the link operates flawlessly. The nominal frequency of axi_clk is 250 MHz.

However, there must be an logical explanation for a frequency offset this big! Is this a known issue of the axi_aclk output of the PCIe AXI/DMA IP core? The documentation (PG195, PG213) does not specify the quality of the axi_aclk clock signal.

Cheers,
/amu

 

Tags (2)
0 Kudos
2 Replies
muellera
Adventurer
Adventurer
314 Views
Registered: ‎02-22-2016

Could the issue be related to the fact that user_clk from the PCIe block does not run continuously?

From PG 213, p. 77:

"The user_clk signal is the derived clock from the TXOUTCLK pin which is the output from the GT Wizard IP. TXOUTCLK is dependent on the pmareset, progdivreset, and txpisopd signals, and also on sys_clk or refclk which is connected to GT Wizard IP.
So, user_clk is not expected to run continuously."

Or does this part only refer to a possible reset condition?

0 Kudos
muellera
Adventurer
Adventurer
167 Views
Registered: ‎02-22-2016

Okay, probably a false alarm.

The PCIe reference clock already has a frequency deviation, even though the datasheet states that the frequency is 100 MHz +- 300 ppm. So it looks like everything as it should be expected from the FPGA side.

0 Kudos