PLL phase after compensation

Hi,

I have the following question concerning PLL use in Altera Cyclone devices:

In normal mode it said that the PLL phase aligns the input reference clock with the clock signal at the ports of the registers that is clock used for FPGA internal registers.

Functional simulation shows that PLL input clock (30MHz) and PLL output clock (90MHz) (which is NOT used for I/O pin!) are phase aligned that is three clock periods of Clock_out fit into the period of Clock_in.

But when doing timing simulation Clock_out is not phase aligned with the input clock but there is a delay. But why? I have compensated the PLL for the Clock_out so why is there a delay at all in the simulation?

I would appreciate your help.

Kind regards

Reply to
ALuPin
Loading thread data ...

Hi,

Exactly where you are measuring your 90 MHz clock signal?

The 90 MHz clock measured at the output of the PLL (but before the global clock network) will have a phase that is ahead of the 30 MHz clock. That is because the the 90 MHz clock should be phase-aligned with the 30 MHz clock at the logic cell register inputs, and there is a global clock delay between them and the PLL output.

If you bring the 90 MHz clock to an output pin, and monitor that point in the Quartus timing simulation, you will see its phase being behind the 30 MHz clock. That is because the 90 MHz clock at this point has both a global clock network delay *and* an IO output pad delay.

Unfortunately, there is no way to look at the clock at the input to a register in the Quartus simulator. You can only enter the names of signals that are the output of blocks, and that really limits you to the two possibilities I mention above.

In functional simulation, routing and block delays (such as the GCLK network delay and IO pad delays) are not included in the simulation, so you could bring the 90 MHz clock to an IO pad and see it phase aligned with the 30 MHz clock.

Another thing to remember is that the compensation for global clock network delays (normal compensation) is not quite perfect. There is some clock skew even on the dedicated global clock networks, so it is not possible to perfectly align the output clock of a PLL with the input clock phase at all destination registers. This skew is small though, so this is a small effect (at most a few hundred picoseconds).

Hope this helps,

Vaughn Altera

Reply to
Vaughn Betz

Hi,

thank you very much for your answer.

I have used the following testbench for my gate-level-simulation: The clock "C1" is not in phase with InClk0 (shwon in the plot is "t_c1_sys". Does that mean that I look at an IO pin and not at the clock at the input to a register? Would the second testbench be the solution ? But what is then t_c1_sys ? Is it the pll output before an input register or is the clock at an input register?

library ieee; use ieee.std_logic_1164.all; use ieee.std_logic_arith.all;

entity tb_pll1 is end tb_pll1;

architecture testbench of tb_pll1 is

component pll1 port ( Inclk0 : in std_logic := '0'; Areset : in std_logic := '0'; C0 : out std_logic; C1 : out std_logic; Locked : out std_logic ); end component;

signal t_Clk_30 : std_logic; signal t_Reset : std_logic; signal t_c0_sys : std_logic; signal t_c1_sys : std_logic; signal t_Locked : std_logic;

begin u1 : pll1 port map ( Inclk0 => t_Clk_30, Areset => t_Reset, C0 => t_c0_sys, C1 => t_c1_sys, Locked => t_Locked );

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

--------------------------------------------- process begin t_Reset t_c0_sys, C1 => t_c1_sys, Locked => t_Locked );

u2 : reg_help port map ( Clk0 => t_c0_sys, Clk1 => t_c1_sys, Out_help => t_Out_help );

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

--------------------------------------------- process begin t_Reset

Reply to
ALuPin

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.