Forum Discussion

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

PLL clock question

Hi all,

I am working on a design using a Cyclone III EP3C25 FPGA, I am having some issues with timing closure and I am trying to understand the information Quartus is reporting.

First of all:

Quartus version : 13.1.4

Device : EP3C25Q240C8

The design uses 2 PLLs.

a) PLL4 takes in a 40MHz clock from pin 89 and converts it to a 160MHz clock

b) PLL1 takes in a 160MHz clock from pin 31 on Inclk[0] and the 160MHz output from PLL4 on Inclk[1] and produces 2 output clocks: 160MHz and 40MHz and operates in fail over mode, ie defaults to Inclk[0] but automatically switches over Inclk[1] if Inclk[0] is not present.

The entire design runs off the 2 clocks output from PLL1, the two input clocks are only used by the PLLs to generate the internal clocks.

Quartus picks up the 2 internal clocks and assigns them as global clocks:

160MHz clock: clk|ref_160_40|altpll_component|auto_generated|pll1|clk[0]

40MHz clock: clk|ref_160_40|altpll_component|auto_generated|pll1|clk[1]

What I am not understanding is how Quartus timing analysis is reporting the clocks. The timing analysis seems to report that there are 2 clock networks being generated for each of the above eg:

clk|ref_160_40|altpll_component|auto_generated|pll1|clk[0] and

clk|ref_160_40|altpll_component|auto_generated|pll1|clk[0]~1

The timing analysis is reporting that the timing is failing due to setup and hold violations certain paths that use the 160MHz clock, with the launch clock being reported as clk|ref_160_40|altpll_component|auto_generated|pll1|clk[0]~1 and the latch clock being reported as clk|ref_160_40|altpll_component|auto_generated|pll1|clk[0], and reporting a skew between the two of -0.846ns

From my understanding the clk[0]~1 clock is a name created during synthesis, but what I don't understand is if it is really the same as the clk[0] clock, ie the same signal on the same global routing resource, or are they actually different clocks on different global networks?

Or is the clk[0]~1 clock being deliberately skewed in the attempt to meet the timing constraints?

I have constrained all the I/O and clocks in the design and derived the clock uncertainty, but I haven't put any constraints on the transfers between 160MHz and 40MHz clock domains. I think I ought to put some multipath constraints on transfers between the two clock domains, but I am not sure of the syntax required, I have tried the following but it only seemed to make the timing worse:

set_multicycle_path 4 -from [get_clocks {*ref_160_40*pll|clk[1]*}] -to [get_clocks {*ref_160_40*pll|clk[0]*}] -end -setup

set_multicycle_path 1 -from [get_clocks {*ref_160_40*pll|clk[1]*}] -to [get_clocks {*ref_160_40*pll|clk[0]*}] -end -hold

set_multicycle_path 4 -from [get_clocks {*ref_160_40*pll|clk[0]*}] -to [get_clocks {*ref_160_40*pll|clk[1]*}] -end -setup

set_multicycle_path 1 -from [get_clocks {*ref_160_40*pll|clk[0]*}] -to [get_clocks {*ref_160_40*pll|clk[1]*}] -end -hold

Just about all the timing issues I have involve this clk[0]~1 signal but I'm struggling to know what it is and where it has come from, any so explanations are welcomed!

Thanks,

Tom

4 Replies

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

    When going between related clocks, the default relationship is the faster clock's period(6.25). If you want it to be 25ns, then your setup multicycle should be 4, like it is. If you want the hold relationship to remain at 0ns, then your multicycle -hold value should be 3. (The default hold relationship follows the setup relationship. I have a description of this in the TimeQuest User Guide on alterawiki.com).

    What you currently have is a 25ns setup relationship and 12.5ns hold relationship, which means the router has to add at least 12.5ns of routing delay to meet hold, so your timing should become worse. Just change the multicycle hold to 3 and you should be fine.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    Thanks for that explanation on multi-cycle. I've read the TimeQuest User Guide but hadn't twigged that was the way to do it, I've made the change in my constraints file, curiously the timing has got worse by 1ns or so...

    My design uses some LPM counters, which seem to both help and hinder. The timing improves when using them, but the timing violations reported all are inside the LPM auto-generated components and I'm not sure how I can fix that.

    I'm still curious about the clock ending with ...clk[0]~1, is it the same global clock as the clock ending with ...clk[0] and is the clock skew reported the skew across the device on that global clock?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    Look in the Fitter Report's Global usage to see if they're separate clocks. In TimeQuest you can look at them with:

    report_timing -full_path -to_clock {clk|ref_160_40|altpll_component|auto_generated|pll 1|clk[0]} -panel_name "clk0"

    report_timing -full_path -to_clock {clk|ref_160_40|altpll_component|auto_generated|pll 1|clk[0]~1} -panel_name "clk0~1"

    You can also do -from_clock -to_clock to analyze paths going between them. Naturally, I can't tell what's going on from the original post, but it does look like it's being split for some reason. Generally not good, but hard to tell.

    (I have seen cases where this is done and I applied a Global Signal assignment in Assignment Editor and it helped fit it, but not always. There may be a specific reason this is being done.)
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    Right, I think I've worked out the source of my problems : badly written timing constraints. Probably the source of 90% of people's problems!

    It also explains where that ...clk[0]~1 comes from.

    Here's what I think was going on:

    As mentioned at the start of this thread, there are 2 external clocks into this FPGA, an on board 40MHz clock and an off board 160MHz clock. The 40MHz is taken up to 160MHz internally by one PLL in the FPGA and the external 160MHz and internal 160MHz are both fed into a second PLL. The second PLL produces 160MHz (...clk[0]) and 40MHz (...clk[1]) out and is set up to default to use the external 160MHz source, but fail over to the internal 160MHz clock when the external 160MHz is not present. All the logic in the FPGA uses the two clocks out of the second PLL.

    In my constraints file I had the statement "derive_pll_clocks" which was doing the correct thing and resulting in two sets of internal clocks out of the second PLL, one set being ...clk[0] and ...clk[1] referenced from the external 160MHz clock and the other set being ...clk[0]~1 and ...clk[1]~1 referenced from the internal 160MHz clock from the first PLL.

    The problem I had was not properly excluded the timing path between these two sets, so Timing Quest was reporting on setup and hold between the two sets of clocks, even though only one set could be active at any one time.

    I changed the constraints file to explicitly create the PLL derived clocks and then created correct clock groups to exclude checking timing between the two sets of clocks and everything works fine now.

    The document found here really helped my understanding of what was going on and how to write constraints for derived clocks

    http://www.alteraforum.com/forum/attachment.php?attachmentid=1166&d=1243964687 (http://www.alteraforum.com/forum/attachment.php?attachmentid=1166&d=1243964687)

    Also thanks for your assistance Rysc in pointing me in the right direction!