Derived clock violation in Virtex4

Thu Feb 18, 2010 3:32 am   

Hi,

I have a V4 with input clock frequency running at 130MHz. This clock
goes into a DCM then CLK0 goes out to other logic. The CLK0 net is
named as "derived_clock" by Synplify. Now the timing report on the
input 130MHz is fine (positive slack) but the derived_clock doesn't
meet timing. How to contrain that?

Thanks.

Thu Feb 18, 2010 10:21 am   

You need to post your code so we can see how you have coded the DCM.

Jon

---------------------------------------
Posted through http://www.FPGARelated.com

Thu Feb 18, 2010 5:36 pm   

Verictor pisze:

Hi,

If incoming (external ) clock is used only to drive DCM, you have
problem with your design. In different words your logic is too slow.
Anyway you can find everything in timing report. I don't know xilinx
tools to well but clock coming from DCM should be constrained
automatically. Correct me if I'm wrong

Adam

Thu Feb 18, 2010 6:34 pm   

On Feb 18, 2:21 am, "maxascent" <maxascent_at_n_o_s_p_a_m.yahoo.co.uk>
wrote:

Here is it, thanks.

DCM_1 : DCM_ADV
generic map(
CLK_FEEDBACK => "1X",
CLKDV_DIVIDE => 2.0,
CLKFX_DIVIDE => 1,
CLKFX_MULTIPLY => 2,
CLKIN_DIVIDE_BY_2 => FALSE,
CLKIN_PERIOD => 7.6921, -- 7.69 for 130MHz
CLKOUT_PHASE_SHIFT => "NONE",
DCM_PERFORMANCE_MODE => "MAX_SPEED",
DESKEW_ADJUST => "SYSTEM_SYNCHRONOUS",
DFS_FREQUENCY_MODE => "LOW",
DLL_FREQUENCY_MODE => "LOW",
DUTY_CYCLE_CORRECTION => TRUE,
PHASE_SHIFT => 0,
STARTUP_WAIT => FALSE
)
port map (
CLK0 => SClkPre, -- *****violation here
CLK180 => open,
CLK270 => open,
CLK2X => open,
CLK2X180 => open,
CLK90 => open,
CLKDV => open,
CLKFX => open,
CLKFX180 => open,
DO => open,
DRDY => open,
LOCKED => DLL_LOCKED,
PSDONE => open,
CLKFB => SClk,
CLKIN => SClkIn,
DADDR => "0000000",
DCLK => '0',
DEN => '0',
DI => "0000000000000000",
DWE => '0',
PSCLK => '0',
PSEN => '0',
PSINCDEC => '0',
RST => MasterRst
);

Thu Feb 18, 2010 8:51 pm   

You havent added any clock buffers (BUFG) on the output of the DCM.

Jon

---------------------------------------
Posted through http://www.FPGARelated.com

Fri Feb 19, 2010 3:18 am   

On Feb 18, 12:51 pm, "maxascent" <maxascent_at_n_o_s_p_a_m.yahoo.co.uk>
wrote:

No, I do have inserted IBUFG to input clock and BUFG to the output of
the DCM. Just not shown on my post.

Fri Feb 19, 2010 10:00 am   

You should only need to specify the clock into the DCM in the Synplif
constraint file. If your design is not meeting timing then you need to loo
in the Synplify report and find the problem.

Jon

---------------------------------------
Posted through http://www.FPGARelated.com

Fri Feb 19, 2010 12:22 pm   

On Thu, 18 Feb 2010 17:18:14 -0800 (PST), Verictor <stehuang_at_gmail.com> wrote:


Then we have to guess that the BUFG has SClkPre as input and SClk as output,
since SClk is taken to ClkFB (feedback) on the DCM.

Then SClk should be correctly aligned with the DCM input clock, which means
there will be several ns skew (= the BUFG delay) on SClkPre (the DCM0 signal).
Is that what you are observing?

- Brian

Tue Feb 23, 2010 4:53 pm   

On Feb 19, 4:22 am, Brian Drummond <brian_drumm...@btconnect.com>
wrote:

Brian,

Your guess of BUFG is exactly right. Also yes, SClk should be aligned
with CLKIN, as you pointed out. When you said "observing", I think you
mean post-layout simulation? I haven't done that. But I think the
alignment should be ok.

Thanks,

Tue Feb 23, 2010 10:30 pm   

On Tue, 23 Feb 2010 06:53:08 -0800 (PST), Verictor <stehuang_at_gmail.com> wrote:


I actually meant "observing" because you observed in your original query, you
reported the "derived clock" DCM0 signal (skewed as above) didn't meet timing.

Since the skew is expected, the question is, what exactly doesn't meet timing?

If there is any logic clocked off DCM0 it will probably not meet timing; but
there shouldn't be any. DCM0 should only connect to the BUFG and nothing else.

- Brian

Sun Feb 28, 2010 2:08 am   

On Feb 17, 9:09 pm, Verictor <stehu...@gmail.com> wrote:

The fact you stated that "the derived_clock doesn't meet timing" means
the clock is already constrained. You need to look at the timing
report to figure out why it doesn't meet timing (.e.g. too many logic
levels, too big clock skews, bad placements, etc).

Cheers,
Jim
http://myfpgablog.blogspot.com/