[Encounter] How to obtain clock frequency of core

Dear

As a newbie, my goal is to obtain clock frequency of the "core
design", after routing, in SOC Encounter 6.2.

My procedure was: Import -> Specify floorplaning -> Power ring and
stripes -> Specify clock tree -> Place -> Route -> Timing optimize.

When I tried to analyze timing, following result was obtained:

+--------------------+---------+---------+---------+---------
+---------
| Setup mode | all | reg2reg | in2reg | reg2out |
+--------------------+---------+---------+---------+---------
+---------
| WNS (ns): | -0.244 | -0.244 | 1.329 | N/A |
| TNS (ns): | -15.52 | -15.520 | 0.000 | N/A |
| Violating Paths:| 208 | 208 | 0 | N/A |
| All Paths: | 5016 | 2172 | 3288 | N/A |
+--------------------+---------+---------+---------+---------
+---------

+--------------------+---------+---------+---------+---------
+---------
| Hold mode | all | reg2reg | in2reg | reg2out |
+--------------------+---------+---------+---------+---------
+---------
| WNS (ns): | -2.099 | -0.001 | -2.099 | N/A |
| TNS (ns): | -5187.8 | -0.001 | -5187.8 | N/A |
| Violating Paths:| 3097 | 1 | 3096 | N/A |
| All Paths: | 5016 | 2172 | 3288 | N/A |
+--------------------+---------+---------+---------+---------
+---------

My question is that :

1. Can we derive the clock frequency from above?

2. If yes, when clock period constraint = 2 ns, is following
calculation correct?

Clock frequency of core = 1/(2 + 0.244 + 0.001) = 444MHz.

3. In summaryReport, following timing information is found.
I do not understand why "#clocks in design = 0".
Does this mean that "CTS" is not correct?

Timing Information
---------------------------------------------------
# Clocks in design = 0
# Generated clocks = 0
# "dont_use" cells from .libs = 67
# "dont_touch" cells from .libs = 60
# Cells in .lib with max_tran = 829
# Cells in .lib with max_cap = 828
# Cells in .lib with max_fanout = 0

 

2. If yes, when clock period constraint = 2 ns, is following

Setup mode slack is the important result for that. Basically means that your critical path is
0.244ns longer than the target -- which is 2ns minus any uncertainty and/or useful skew, depending
on your constraints and your flow.

Therefore 2+0.244 would be your maximum clock period.

Hold mode slack is not directly linked with the clock period -- though if you relax the clock
constraint it will be easier to meet the hold constraints.

It seems that you have done no hold optimization (optDesign -hold), because you have hold mode slack
on your in2reg paths, which should be easy to fix.

Though I can not verify, I find it strange. Are you sure you correctly set up your timing
constraints (i.e. create_clock in your sdf file). I also find it strange that your timing reports
more in2reg paths than reg2reg paths...

"Good constraining is the key to good results"



Cheers,

Stéphane