( ESNUG 318 Item 7 ) --------------------------------------------- [5/21/99]
Subject: ( ESNUG 316 #1) Valid Paths Getting Defined As Bogus False Paths
> I would like to raise a question for discussion relating to Static Timing
> analysis and Synthesis.
>
> Is anyone doing anything to "Verify" their "False_Path" defines are
> correct? We are concerned that "Valid Paths" may get defined as "False"
> during timing analysis and synthesis but may, in fact, be a valid path.
>
> Proposed solution:
>
> For each defined false path, the designer could create a "Path Check"
> block for use during netlist simulation. These "Path Check" blocks could
> be contained in a single module that is at the testbench level.
>
> Rather than show the code, I'll describe the function of "Path Check"
>
>
> ff1 ff2
> ----- invalid path --------- -----
> |D Q|______________| |____________|D Q|
> | | | | | |
> CK __| | | MISC | CK __| |
> ----- | LOGIC | -----
> | |
> Valid Path ____| |
> | |
> ---------
>
> Verify that when ff1/Q changes state, that ff2/Q does NOT change
> state on the following clock. Also verify that ff1/Q has toggled
> to show that the test excited the source of the false path.
>
> I am also curious of some companies simply add gates (synchronizers,
> staging registers, etc) to remove the violations from these paths (they
> use the simple rule of "No False paths - anywhere").
>
> - Dan Pinvidic
> Qlogic Corp.
From: Chuck Benz <cbenz@nexabit.com>
John,
Actually, I think Dan might be referring to a multicycle path here, not
a false path (because he mentions the addition of staging registers and
also refers only to "the following clock"). And indeed, this really is a
concern for both multicycle and false paths.
To some extent, this is checked (albeit poorly/weakly at best) by
back-annotated gate simulation (thought you avoided it by using Static
Timing Analysis?).
I am aware of at least one IP vendor that will insert flops to break up
what could have been a multicycle path. IP vendors don't want the burden
of supporting lots of extra timing assertions. In general, that's a pretty
good approach -- in most cases the time/effort saved is worth the gates.
I believe that many of us have hopes that the model-checking side of
formal verification will eventually explore this concern. Today, it's a
matter of manual verification (combined inspection and simulation along
the lines you suggest), and trust between designers that it has been done
adequately.
- Chuck Benz
Nexabit Networks Marlboro, MA
---- ---- ---- ---- ---- ---- ----
From: Ken Rose <kenr@cisco.com>
John,
Maybe I use a different definition than Dan of false paths, but I don't
see how his solution will help. I often use false_path to eliminate from
timing optimization paths that I know are stable during normal system
operation; for example, I may have a threshold count that is settable by
the CPU in a n-bit register, but is typically set only during system
initialization and never changed. I don't want synopsys to waste time and
gates optimizing the timing from this register to the outputs, so I declare
it as a false path.
However Dan's proposed solution (a toggle-checker approach) does not seem
to allow this usage of false_path and would flag a violation.
And for those paths that are incorrectly marked as false when they should
not have been, Dan's solution relies on achieving high toggle coverage to
detect the fault. Creating such simulation vectors is a problem which is
why static timing has gained popularity.
- Ken Rose
Cisco Systems
|
|
