strange timequest report

Altera_Forum · ‎01-16-2008

I just find that there exist two strange path in TimeQuest report which show that:

From Node & To Node are the same register, but launch clock & latch clock are different, pls see the detailed info below:


Info: Path# 2: Setup slack is 5.644 
    Info: ===================================================================
    Info: From Node    : FreqMeasure_NiosII:inst|freqmeasure_wholesystem_inst:the_freqmeasure_wholesystem_inst|freqmeasure_wholesystem:the_freqmeasure_wholesystem|FREQMeasure_StrobeGenerator:U1|OUT_STROBE
    Info: To Node      : FreqMeasure_NiosII:inst|freqmeasure_wholesystem_inst:the_freqmeasure_wholesystem_inst|freqmeasure_wholesystem:the_freqmeasure_wholesystem|FREQMeasure_StrobeGenerator:U1|OUT_STROBE
    Info: Launch Clock : OUT_STROBE (INVERTED)
    Info: Latch Clock  : FreqMeasure_NiosII:inst|pll:the_pll|altpllpll:the_pll|altpll:altpll_component|_clk0    Info: 
    Info: Data Arrival Path:
    Info: 
    Info: Total (ns)  Incr (ns)     Type  Element
    Info: ==========  ========= ==  ====  ===================================
    Info: 500000.000  500000.000           launch edge time
    Info: 500000.000      0.000  F        clock network delay
    Info: 500000.000      0.000 FF  CELL  inst|the_freqmeasure_wholesystem_inst|the_freqmeasure_wholesystem|U1|OUT_STROBE|regout
    Info: 500002.458      2.458 FF    IC  inst|the_freqmeasure_wholesystem_inst|the_freqmeasure_wholesystem|U1|OUT_STROBE~clkctrl|inclk
    Info: 500002.458      0.000 FF  CELL  inst|the_freqmeasure_wholesystem_inst|the_freqmeasure_wholesystem|U1|OUT_STROBE~clkctrl|outclk
    Info: 500004.396      1.938 FF    IC  inst|the_freqmeasure_wholesystem_inst|the_freqmeasure_wholesystem|U1|Selector9~9|datad
    Info: 500004.602      0.206 FF  CELL  inst|the_freqmeasure_wholesystem_inst|the_freqmeasure_wholesystem|U1|Selector9~9|combout
    Info: 500004.602      0.000 FF    IC  inst|the_freqmeasure_wholesystem_inst|the_freqmeasure_wholesystem|U1|OUT_STROBE|datain
    Info: 500004.710      0.108 FF  CELL  FreqMeasure_NiosII:inst|freqmeasure_wholesystem_inst:the_freqmeasure_wholesystem_inst|freqmeasure_wholesystem:the_freqmeasure_wholesystem|FREQMeasure_StrobeGenerator:U1|OUT_STROBE
    Info: 
    Info: Data Required Path:
    Info: 
    Info: Total (ns)  Incr (ns)     Type  Element
    Info: ==========  ========= ==  ====  ===================================
    Info: 500010.000  500010.000           latch edge time
    Info: 500010.314      0.314  R        clock network delay
    Info: 500010.354      0.040     uTsu  FreqMeasure_NiosII:inst|freqmeasure_wholesystem_inst:the_freqmeasure_wholesystem_inst|freqmeasure_wholesystem:the_freqmeasure_wholesystem|FREQMeasure_StrobeGenerator:U1|OUT_STROBE
    Info: 
    Info: Data Arrival Time  : 500004.710
    Info: Data Required Time : 500010.354
    Info: Slack              :     5.644 
    Info: ===================================================================
    Info: 
2 5.644

I have reviewed my RTL code & do some observation, the launch clock & latch clock should both be FreqMeasure_NiosII:inst|pll:the_pll|altpllpll:the_pll|altpll:altpll_component|_clk0.

P.S. OUT_STROBE is generated from FreqMeasure_NiosII:inst|pll:the_pll|altpllpll:the_pll|altpll:altpll_component|_clk0.

Any mistake I make?

Altera_Forum · ‎01-16-2008

This is what I think is happening in your design: You've had threads with a clock created by a divide-by-2 register. (I hope you checked out my posts that I referred you to with caveats for creating clocks that way.) I suspect that the register, which has a name ending in "OUT_STROBE", is a divide-by-2 register driving the clock signal constrained by the clock called "OUT_STROBE". If so, you have a clock-as-data-analysis situation. If the same signal is used as both a clock and as a data signal, the reporting can be confusing. A report like yours is given for the feedback path with the divide-by-2 register as both source and destination. The feedback path is a data path for the same signal that is used as a clock for other registers. That results in the confusing reporting for clock-as-data analysis. TimeQuest does it the way it does to be consistent with PrimeTime (as I understand it).

This is the first possibility I thought of, but it probably isn't what you have in your design: The same register can have more than one clock. An example is a register with clocks selected by a mux. Unless you tell TimeQuest otherwise (typically with a set_clock_groups command), TimeQuest will assume that one of the mux input clocks can be selected at the time of the launching edge and another mux input clock can be selected at the time of the latching edge.

Altera_Forum · ‎01-16-2008

You are absolutely correct in the first description.

So what should I do? Or just let it be?

Altera_Forum · ‎01-16-2008

As far as the timing analysis is concerned, the reporting is correct. As long as the slack is positive, you are OK.

As far as whether you followed good design practices, I still recommend that you review my posts at http://www.alteraforum.com/forum/showthread.php?t=754 if you haven't already.

Altera_Forum · ‎01-16-2008

I have read it twice. :)

But can't understand clearly.

It's hard to understand for me(a newer), but I will remember it and when I encounter similar problem, I'll return back to read it.

Thanks...

hmm...could you teach me some other ways to express my thanks :)

I feel it's not enough to express my appreciation by just a simple 'thanks' word.

Thanks again anyway. haha