( ESNUG 428 Item 6 ) -------------------------------------------- [04/28/04]
Subject: ( ESNUG 427 #3 ) That PrimeTime Magic Switch Is Tricky To Use!
> One problem that cropped up recently was when a user was checking his
> clock-to-output times and started getting a blank report. PrimeTime
> simply did not report any paths from the clock to the output! Come
> to find out that the user didn't constrain that path, and the newer
> versions of PrimeTime just don't report on unconstrained nets.
>
> I quickly came to the conclusion that this was a bad thing.
>
> A quick call to Synopsys turned up the magic switch, which is:
>
> set timing_report_unconstrained_paths true
>
> Which I now set in my default .synopsys_pt.setup files.
>
> - David Bishop
> Kodak Rochester, NY
From: Vijay Raghavan <vijay.raghavan=user domain=synopsys spot calm>
Hi John,
Wishing you well. I'm a Synopsys Instructor in PrimeTime.
David is quite correct about turning this variable (printvar *unconstrain*)
to true in order to:
+ report an unconstrained data path, clock/reset paths,
+ have backward compatibility with older (than U-2003.03) PT versions
and
+ have DC like default behavior
As you know, defaults are always with a reason. The advantage of keeping
the default (false) value of this variable is to avoid timing updates due
to unconstrained paths as explained by man UITE-413.
Some Guidelines:
1. Prefer the "true" usage for interactive (vs. batch) analysis only
2. Avoid placing non-default settings in the .synopsys_pt.setup
file. Prefer setting it within a PrimeTime script or use it
interactively. Keeping the .synopsys_pt.setup file simple, means
bringing up the pt_shell quicker. :)
3. If the design is completely unconstrained, default report_timing
only reports the longest path to an output port (vs. longest path
delay in the design).
A more efficient methodology is to constrain *all* the timing paths within
PrimeTime, ensure the same using check_timing and report_analysis_coverage
reports before invoking timing reports.
Hope this is helpful. Thanks to my fellow Instructor and our PT CAE.
- Vijay Raghavan
Synopsys, Inc. Marlboro, MA
---- ---- ---- ---- ---- ---- ----
From: Offer Kaye <oferk=user domain=oren.co.il>
Hi John,
We had the exact same problem here, and came up with the same "magic
switch". However note that it is not generally considered a good idea to
keep this variable true all the time, since report_timing will run slower
if this variable is true and there are lots of unconstrained paths in the
design. See:
man timing_report_unconstrained_paths
from the pt_shell or the documentation.
- Offer Kaye
Oren Semiconductor Israel
---- ---- ---- ---- ---- ---- ----
From: Shin Wu <sywu=user domain=atmel spot calm>
Hi John,
I recently took a full-chip STA training class that was conducted by
Synopsys Education Services. The instructor happened to mention about
this switch saying that starting from U-2003.03 PrimeTime will not report
any unconstrained paths (commands affected report_timing and
get_timing_paths).
I am also trying to setup some guidelines and structured template scripts
to do STA and I was wondering if I should set this switch. But,
personally, I feel switching back to old behavior would encourage
designers to get away with incomplete constraints which is a significant
problem in STA.
- Shin Wu
Atmel Corporation Columbia, MD
---- ---- ---- ---- ---- ---- ----
From: Chris Papademetrious <chrispy=user domain=synopsys spot calm>
Hi, John,
I noticed in ESNUG 427 #3 where David mentions putting the following
in his .synopsys_pt.setup file:
set timing_report_unconstrained_paths true
Before every ESNUG reader puts this in their setup file, I would like
to provide a little background on this variable. It was introduced in
PrimeTime 2003.03 to speed up the report_timing and get_timing_paths
commands. It works by limiting PrimeTime's path searching algorithms
to constrained paths. In cases where no constrained paths are found,
this avoids the runtime penalty of searching through the unsorted
unconstrained paths to find the longest one. (I'm sure we have all seen
how long this can take when doing timing reports on large clock and
reset trees!) Note that in such a case, PrimeTime specificially
states:
No constrained paths.
which is different than the message:
No paths.
During batch runs, limiting you analysis to constrained paths is
reasonable, and the runtime improvement is quite desirable. However,
when working interactively, it can be useful to poke around unconstrained
paths (clock, resets, unusued I/Os, etc.) to explore various areas of the
design. I also temporarily turn this on when obtaining PLL feedback
paths with get_timing_paths.
I personally keep the variable's default value of 'false', and add the
following line to the .synopsys_pt.setup file in my *home* directory:
alias un set timing_report_unconstrained_paths true
Then, if I encounter the dreaded "No constrained paths." message during an
interactive session while working in any directory, I can flip this
variable with just a few keystrokes, and repeat the report with !rep.
It doesn't require a timing update to take effect, so there's no penalty
for turning it on in mid-session. This way, you'll get the best of
both worlds.
- Chris Papademetrious
Synopsys, Inc. Brodheadsville, PA
|
|
