Static timing analysis is exhaustive by nature. Timing tool will exhaustively look at all
possible timing paths and will perform timing checks.
Because of this, it will also perform timing checks on timing paths which cannot really happen. Best way to
understand this is by examples.
This type of circuit configuration is very common in digital circuits. Functional clock
is active only in functional mode and test clock is active only test mode.
This means when a timing path starts with functional clock launching data at functional flop(FF)
output QF, it should be captured by receiving flop(RF) and capture clock should only
be functional clock.
Because of the exhaustive nature of timing tools, it will also time a path where
functional clock launches data at QF output of function flop(FF) and is captured at D
input of the receiving flop(RF) through test_clk.
Given that functional clock and test clock are not active at the same time, this timing path is false and can never happen.
When functional clock launches data at QF output of functional flop(FF) and it
captured at D input of receiving flop(RF), it can only be sampled through functional
clock and not test clock, as only functional clock will be active at that time.
To drive this point further, take a look at the following circuit.
In the above figure a mux is used to select between functional clock and test clock. In
functional mode only functional clock is active and test clock in inactive.
In test mode only test clock active and functional clock is turned off.
For the above circuit there are only two valid timing paths.
First timing path is where functional clock launches the data at Q output of launch flop
(LF) and this data is captured again by functional clock at capture flop(CF) input D.
Second timing path is similar but with test clock, i.e. where test clock launches the
data at Q output of launch flop(LF) and this data is captured by test clock at capture
flop(CF) input D.
But because of the exhaustive nature of the static timing analysis, timing tool by
default come up with four timing paths.
1) Functional clock launch => Functional clock capture.
2) Functional clock launch => Test clock capture.
3) Test clock launch => Test clock capture.
4) Test clock launch => Functional clock capture.
As you can see only paths 1) and 3) are valid and paths 2) and 4) are false. An explicit
exception or override needs to be provided to the timing tool to address this false
paths