Forum Discussion

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

Clock recovery violated: what to do?

Hi all,

we're trying to meet all timing requirements in a project we are closing.

Up till now we used the classic timing analyzer, but digging in this forum we recently switched to TimeQuest.

Thanks to the forum, we solved various problems about contraining our SOPC Builder system.

Anyway, we still have a recovery violation, as reported by TimeQuest, with about -0.2 ns of slack, on a path coming from our NIOS II processor, going to a synchronizer.

How can we solve the timing violation? Is there a "standard" way to solve a recovery violation?

Introducing physical synthesis doesn't seem to solve the problem, and anyway the two paths doesn't seem to affect the correct behavior of the system.

-0.258 testbed_EC102:my_system|cpu:the_cpu|cpu_nios2_oci:the_cpu_nios2_oci|cpu_nios2_oci_debug:the_cpu_nios2_oci_debug|resetrequest testbed_EC102:my_system|testbed_EC102_reset_pll_MCV_domain_synch_module:testbed_EC102_reset_pll_MCV_domain_synch|data_out my_system|the_pll_2|the_pll|altpll_component|pll|clk[0] my_system|the_pll_2|the_pll|altpll_component|pll|clk[1]

-0.258 testbed_EC102:my_system|cpu:the_cpu|cpu_nios2_oci:the_cpu_nios2_oci|cpu_nios2_oci_debug:the_cpu_nios2_oci_debug|resetrequest testbed_EC102:my_system|testbed_EC102_reset_pll_MCV_domain_synch_module:testbed_EC102_reset_pll_MCV_domain_synch|data_in_d1 my_system|the_pll_2|the_pll|altpll_component|pll|clk[0] my_system|the_pll_2|the_pll|altpll_component|pll|clk[1]

Thanks for any suggestion,

mantoz

3 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    At first glance, recovery is solved just like a setup violation, by reducing the levels of logic between registers, moving them closer together, etc. That being said:

    1) Is there any logic between the registers? Usually recovery is a register to register path, which usually makes it easy to meet timing(you generally don't want combinatorial logic on recovery paths since it feeds an asynch port on the destination register and a glitch would cause it to swtich).

    2) What's the requirement between the two registers? It's crossing domains, so maybe the requirement is unrealistic.

    3) Are you sure this is a valid path, i.e. that it has to make timing? This is something you probably can't say since it's not your code(I don't see the whole path, so not sure), and have to assume it does need to meet timing.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    Hi Rysc,

    thank you so much for your fast reply!

    I just downloaded your document about recovery and removal analysis, and I found it very useful indeed!

    I'll read it more accurately in the next few days.

    Regarding my design, it's a SOPC Builder design, so unfortunately I haven't full control on it. This is one of the reasons for which I don't like SOPC builder very much when something goes wrong.

    The clock domain crossing is from the clock of the NIOS II (100 MHz), to the clock of a MCV filter (175 MHz). I sincerely don't know what is the function of the signal "testbed_EC102:my_system|cpu:the_cpu|cpu_nios2_oci:the_cpu_nios2_oci|cpu_nios2_oci_debug:the_cpu_nios2_oci_debug|resetrequest"

    but by the name I think is something reset-related. Actually I don't think that my NIOS ever goes to request a reset to the hardware, but I'd like to get rid of this timing errors.

    But, my question is, how can I do that if that's not my code, but Altera's one? The synchronizer is put there by SOPC builder, and I'm not very comfortable with the SOPC Builder-generated code, and I would not like to break things now (the design seems to work well).

    Is declaring global/not global the signal coming to the affected synchronizer a viable option?

    Thanks so much,

    mantoz
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    The clocks are not synchronous, i.e. your recovery requirement is probably some really small number that's impossible to meet. And you really can't transfer a signal between a 100MHz clock and 175MHz clock in a synchronous manner.

    Note that all clocks are related by default in TimeQuest, and it is up to the user to put cut the analysis between domains. SOPC Builder will not automatically add this timing constraints because it doesn't know for certain that you want them cut. If you make them separate clocks in SOPC builder, it will build logic to handle them as if they were asynchronous, it just won't create the .sdc constraints.

    Since there are impossible to be synchronous, you absolutely want to false path them. If you have a set_clock_groups constraint in your design(I generally recommend it), then make sure they're in separate groups. Otherwise you could do:

    set_false_path -from [get_clocks 100MHz] -to [get_clocks 175MHz]

    set_false_path -from [get_clocks 175MHz] -to [get_clocks 100MHz]

    (Where you replace the name 100MHz and 175MHz with the correct PLL clock name.)