Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
14 years ago

Source Synchronous Interface - Hold Failure

Hi all,

I've a design in which FPGA receive data in DDR with the clock (200MHz) and they are edge aligned.

So FPGA shall shift clock 90° in order to capture data correctly and for that I've instantiated a PLL in source synchronous mode that shift it if 1.25ns

I gave the "usual" constraint for this kind of interface.

create_clock -name AD_CLK_IN -period 5.0 [get_ports AD_CLK]

create_clock -name virtual_ad_clk -period 5.0

derive_pll_clocks

derive_clock_uncertainty

From the AD datasheet (that feed clock and data to FPGA) it is stated that:

1- Data can come out respect to the clock +/- 50ps

2- Morever clock can have a dutycycle that is not 50% but could be 45% to 55%, so 5% is 250ps that I've to keep in account.

For theese reason I set up the following contraint

set_input_delay -max 0.050 -clock virtual_ad_clk [get_ports AD_IN[*]]

set_input_delay -min -0.300 -clock virtual_ad_clk [get_ports AD_IN[*]]

set_input_delay -max 0.050 -clock virtual_ad_clk -clock_fall [get_ports AD_IN[*]] -add_delay

set_input_delay -min -0.300 -clock virtual_ad_clk -clock_fall [get_ports AD_IN[*]] -add_delay

Until now it's only a confirm that I ask, moreover I've though of take care of 45% - 55% duty cycle with clock uncertainty, but in the end was simpler to take in account what this could do on data.

Ok now the problem is that in Timequest I've failing path in Hold analisys, in slow corner mode.

I report the paths in some panels as suggested by Rysc guide with this commands:

1) Create a setup panel under ADIN named setup

report_timing -setup -npaths 100 -detail full_path -from_clock virtual_ad_clk -panel_name ADIN||setup

2) Create a setup panel under ADIN named hold

report_timing -hold -npaths 100 -detail full_path -from_clock virtual_ad_clk -panel_name ADIN||hold

The problem is in the HOLD that has a slack of about -0.700ns.

Setup is ok and has a slack of + 1.6ns.

In order to fix them since I've the PLL that is phasing the clock what I assume is that I can move PLL out shift in order to center the window, is that right way to do?

It is the first time that happen to me to have path that fails in Source Sync mode.

The strange thing in my opinion is that I see that virtual clock and the clock generated by PLL has a lot of skew: 3.36ns!

In attachment there is also the Timequest analisys.

Thanks in advance for help.

5 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    --- Quote Start ---

    set_input_delay -min -0.300 -clock virtual_ad_clk [get_ports AD_IN

    [*]]

    --- Quote End ---

    How do you get -0.3 as the min input delay? Could you explain a little about it?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Of course.

    -0.3ns keep in account both the fact that data can goes out +/-50 ns and the fact that since clock has not 50% duty cycle, but only 45%-55%, means that if you look at edges the falling edge can be 250ps delayed or in advance from the point you expect it.

    For the SETUP timing analisys, this difference in Duty Cycle it does not really matter since the latch edge is exactly the launch one delayed by 1.25ns by the PLL.

    For the HOLD analisys things are different, since in this case the launch and latch clock are referring to two different edges and so if the following edge moves of 250ps in advance or in delay has to been considered.

    I hope that now all is a bit less obscure :)

    If you've some other doubts try to picture the waveform, they really help a lot.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Try setting max input delay to +50 ps and min to -50 ps then add clock uncertainty of 250 ps.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    I'll have a look at this, I'm not sure it address uncertainty on duty cycle..

    I'll take a look at it for sure (could make things simpler to understand).

    Thank you for the suggestion
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    The duty cycle variation is one component of clock jitter and it affects both edges.

    I believe you think that only falling edge is affected but that is not right.