Forum Discussion

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

the problem of timing constraint

Hi:

there are a lot of timing violations after synthesizing the SDRAM controller,the constrained clock is 150M. I noticed that the latch clock is about half period faster than the launch clock , but the launch clock and latch clock are in the same clock domain,which lead to a lot of timing violations.

I just want to know how to constraint the clock skew between launch flip-flop and latch flip-flop.is there anyone can help me?

thank you in advance!

5 Replies

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

    The info messages don't have enough detail. Run TimeQuest and do a report_timing -setup -detail full_path -npaths 2 -pairs_only -panel_name "2 worst paths" -file "worst_paths.txt"

    Feel free to attach the text file. I doubt the source and destination are on the same clock. You're using a PLL(hence negative delays) and they always drive a global clock tree, so the skew would be minimal. Anyway, the TimeQuest report will help analyze it better.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Yes ,the source and destination are on the same clock , and the clock of SDRAM controller comes from the PLL.

    thank you!
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Can you attach the report? They both originate at pll_clk, but something is causing huge skew. Either they're not on a global, or one of them goes through a gated clock(that's my guess without seeing the report).

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

    Ahh, I missed the oExt delay. This isn't an internal transfer, where clock skew is bad, but an external transfer to an output port. That being said, you're latch clock delay is usually 0(unless a source synchronous output), but in your case it's negative. The problem is that you're using the PLL clock as the external clock. The PLL clock name should never be used in a set_input/output_delay constraint. The -clock option of this constraint is saying what clock drives the external register off chip. The analysis you're getting will look at the clock tree up to the PLL output and then have it magically jump off chip. I talk about this in the Getting Started section of the user guide:

    http://www.alterawiki.com/wiki/timequest_user_guide

    Anyway, create a virtual clock:

    create_clock -name clk_ext -period 6.666

    Then have your I/O constraints based on this, e.g.:

    set_output_delay -max 2.5 -clock clk_ext [all_outputs]

    The Clock Network Delay on your latch clock will go to 0, which will help setup timing and it should meet timing. (Note that your setup time is 6.666ns and your external delay is 2.5ns, so you're basically asking the FPGA to get its data out in 6.666-2.5 ns, or 4.166ns.

    Also, be sure to do your timing analysis in TimeQuest, not just that info message you're posting. There is a more detailed breakdown there.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    This problem has been solved after creating the virtual clock.

    Thank you !