( ESNUG 316 Item 1 ) ----------------------------------------------- [4/8/99]
From: d_pinvidic@qlc.com (Dan Pinvidic)
Subject: Concern That Valid Paths Get Defined As Bogus False Paths
Hi John,
First off, I want to Thank You for your time & effort in running ESNUG.
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").
Thanks in advance to all who take the time to ponder this question.
- Dan Pinvidic
Qlogic Corp.
|
|
