PLL phase after compensation

[ALuPin]

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

 

[Vaughn Betz]

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

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

 

[ALuPin]

Hi,

thank you very much for your answer.

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.

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 <= '1', '0' after 150 ns;
wait;
end process;
---------------------------------------------
---------------------------------------------
process
begin
t_Clk_30 <= '1'; wait for 16.665 ns; -- 30MHz
t_Clk_30 <= '0'; wait for 16.665 ns;
end process;
---------------------------------------------
---------------------------------------------
end testbench;


Second testbench: The additional module "reg_help" does use the clocks C0 and
C1 as clocks for registers


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;

component reg_help
port ( Clk0 : in std_logic;
Clk1 : in std_logic;
Out_help : 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;
signal t_Out_help : 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
);

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

---------------------------------------------
---------------------------------------------
process
begin
t_Reset <= '1', '0' after 150 ns;
wait;
end process;
---------------------------------------------
---------------------------------------------
process
begin
t_Clk_30 <= '1'; wait for 16.665 ns; -- 30MHz
t_Clk_30 <= '0'; wait for 16.665 ns;
end process;