[SOLVED] Setup time slack and maximum clock frequency

[trav1s]

I have a design with specified 9MHz clock (~111.1 ns period). The final design timing report in SoC Encounter says that the worst slack is 88,862 ns. Note that this is a positive number indicating no setup violations exist. What is the equation for the minimum clock period given these two numbers?

 

[lostinxlation]

How about hold slack/viol ?

If you got 88000ns positive slack with 111ns cycle time, it must have a huge clock skew, pushing the capturing clock edge way ahead, and natually it's likely to have a hold violation.
THe clock skew remains the same regardless of the cycle time, and capturing edge is always at the same location in time. It seems to me even though you increse the clock speed, the slack doesn't change.

I could be missing something, though.

EDIT:
I think I wasn't right on the part., "capturing edge is always the same location in time". Should be rephrased that capturing edge minus clock period is always at the same location, and you get capturing edge moved depending on the clock speed. However, it moves its location only by less than 111ns. it means the slack changes by less than 111ns and doesn't seem affecting much on the slack.
So, even though cycle time is 1ns, it will meet the setup time based on the info given.

I'm under the impression that some other information is missing on this case.

 

[trav1s]

Yes, something doesn't seem right, I agree. There are no hold violations and the worst hold slack was 0.021 ns. Hold violations were quite severe before hold fixing and now about 36% of the standard cell count are buffers. That's way too many to be normal, right? Can you give me a expected value for this for a small microcontroller (~4000 gates)? What timing constraints could be causing so many hold violations before buffer insertion? I will take a deeper look at the clock tree to see if there is anything unexpected there.

---------- Post added at 18:06 ---------- Previous post was at 17:57 ----------

By the way, by saying 88,862 ns is the worst setup slack, I mean to say that this is the LOWEST value of setup slack in the design. That is, all other paths have a setup slack greater than this value.

 

[lostinxlation]

I think having 88000ns positive slack aginst 111ns cycle time suggests that there must be a huge clock skew or you have some multi cycle path.
If it's the former case, it would likely cause a huge hold violations and considering the degree of clock skew, a crazy amount of delay buffers might have been added to fix the hold. If it's the latter case, I'd double check if hold time is properly analyzed. The different tools take the multicycle path differently, especially with capturing edge for the hold analysis.(like multicycle_path command from synopsys moves the hold edge along with the setup edge, and you need to move the hold edge back manually. Other tools sometimes works differently in this regard).

 

[trav1s]

Ok I will show you my sdc.

set sdc_version 1.7
# time units are 1.0ps
create_clock -name "clkcpu" -add -period 111111.1 [get_ports clkcpu]
create_clock -name "clkper" -add -period 111111.1 [get_ports clkper]
create_clock -name "tck" -add -period 300000.0 [get_ports tck]
set_false_path -from [list \
  [get_clocks clkcpu]  \
  [get_clocks clkper] ] -to [get_clocks tck]
set_false_path -from [get_clocks tck] -to [list \
  [get_clocks clkcpu]  \
  [get_clocks clkper] ]
set_clock_gating_check -setup 0.0 

# I/O delay up to 10% of clock periods
set_input_delay -clock [get_clocks clkcpu] -add_delay -min 0.0             [all_inputs ]
set_input_delay -clock [get_clocks clkcpu] -add_delay -max 11111.1        [all_inputs ]
set_output_delay -clock [get_clocks clkcpu] -add_delay -min 0.0            [all_outputs]
set_output_delay -clock [get_clocks clkcpu] -add_delay -max 11111.1       [all_outputs]
set_input_delay -clock [get_clocks clkper] -add_delay -min 0.0             [all_inputs ]
set_input_delay -clock [get_clocks clkper] -add_delay -max 11111.1        [all_inputs ]
set_output_delay -clock [get_clocks clkper] -add_delay -min 0.0            [all_outputs]
set_output_delay -clock [get_clocks clkper] -add_delay -max 11111.1       [all_outputs]
set_input_delay -clock [get_clocks tck] -add_delay -min 0.0             [all_inputs ]
set_input_delay -clock [get_clocks tck] -add_delay -max 30000.0        [all_inputs ]
set_output_delay -clock [get_clocks tck] -add_delay -min 0.0            [all_outputs]
set_output_delay -clock [get_clocks tck] -add_delay -max 30000.0       [all_outputs]

# Input driver resistance used to calculate load-dependent delay
set_drive -max 100 [all_inputs]
set_drive -min 10 [all_inputs]

set_max_transition 88888.0 [current_design]

set_ideal_net [get_nets clkcpu]
set_ideal_net [get_nets clkper]
set_ideal_net [get_nets tck]
set_wire_load_mode "enclosed"

 

[lostinxlation]

can you double check the deifnition of set_output_delay -min/-max ? The last time I wrote a timing constraint was a long time ago, but I thought set_output_delay defines the setup time to the outside device, and it doesn't seem to make sense that -min has a smaller value than -max.

Also are you certain the unit is ps ? Seeing 88000ns or more positive slack, ns in unit seems to make more sense ?

 

[trav1s]

Thanks for the suggestions so far. Some more info- the timing related info I've given is based on a 3-corner analysis (ff, tt, ss), and I am using SoC Encounter. From the documentation:

set_input_delay
-max
Specifies that the delay refers to the setup analysis. If you do not specify the -max parameter, the input delay applies to both setup and hold analysis.
-min
Specifies that the delay refers to the hold analysis. If you do not specify the -min parameter, the input delay applies to both setup and hold analysis.

So that's right, right? For setup analysis you want a longer delay, and opposite for hold analysis.

set_output_delay
-max
Specifies that the delay refers to the setup analysis. If you do not specify the -max parameter, the output delay applies to both setup and hold analysis.
-min
Specifies that the delay refers to the hold analysis. If you do not specify the -min parameter, the output delay applies to both setup and hold analysis.

I think you are right about the timing units. Good intuition on that call. I am going to double check everything but at first look I can see that the library is defined in ns, the sdc in ps, and they are both treated as if they are ns. Now I need to figure out what this means for the design. It was taped out yesterday, so I can't change it. The situation is not good, but I need to find out how bad it is exactly... If there will be no hold violations in silicon, I will be satisfied.

---------- Post added at 10:34 ---------- Previous post was at 09:51 ----------

I overwrote the design SDC with an SDC with proper units. Rerunning timing analysis reveals setup mode WNS: -79.124ns hold mode WNS: (+)0.148ns. So there are still 0 hold violations, and the speed of the chip will be reduced due to setup violations. Debug clock, tck seems to have no setup violations. So in the worst case the maximum speed of the clock is found as follows

t_clkmin = 111.1ns + 79.123ns = 190ns

which means
f_clkmax = 5.256MHz

Quite acceptable in terms of what we want the design to do. The clock frequency was actually pretty arbitrarily chosen. The major penalty here is the power/area loss from those buffers, but that is acceptable for this version. Case closed I think, but I will leave the thread open for a bit in case you have some more insight.