( ESNUG 377 Item 21 ) ------------------------------------------- [09/19/01]
Subject: ( ESNUG 375 #6 ) PrimeTime Reports Ignored Exceptions; But Not WHY
> PrimeTime reports "ignored exceptions" yet doesn't state -WHY- the
> exception was ignored. Nor is there any capability to help debug the
> cause for the ignored exception. I'm painfully aware of all the reasons
> why the exception *may* be ignored, but what would be really nice would
> be for PrimeTime to give me the answer so when I push the button on a new
> customer's design I won't be faced with days of work to analyze reams of
> ignored exceptions.
>
> I've requested this enhancement from Synopsys yet there has been no
> action. Anyone out there have a home grown solution? Does Ambit also
> have this shortcoming?
>
> - [ Feeling Exceptionally Ignored ]
From: [ A Synopsys PrimeTime CAE ]
Hi John,
PrimeTime currently allows you to report ignored exceptions but does not
list a reason why an exception was ignored. Admittedly, it would be nice
to report the reason why it was ignored to help in the debug of PrimeTime
analysis scripts.
Much of the reason why PrimeTime only lists the ignored exceptions is
for the sake of memory efficiency; PrimeTime drops or does not save the
information that would be needed to determine the reason why, thereby
reducing memory usage. In a future release, Synopsys will investigate
some method of maintaining the information needed to report a reason for
an ignored exception, but such behavior needs to be balanced with how
much it impacts memory usage.
Most ignored exceptions are caused by invalid startpoints or endpoints
or non-existent paths, so here are some basic tips for writing proper
exceptions:
1. Ensure all *-from* points are valid startpoints:
- Primary input ports
- Register clock pins
- Segmented path startpoints
2. Ensure all *-to* points are valid endpoints:
- Primary output ports
- Register data input pins
- Segmented path endpoints
3. Avoid excessive use of -through option or excessive use of wildcards,
which can result in many redundant or invalid exceptions.
Here is an example of a bad exception that will result in lots of ignored
exceptions:
set_multicycle_path 2 -setup -end -from A_reg*/CP -to B_reg*/*
Since the exception terminates at ALL of the pins associated with registers
B_reg, most of the exceptions will be ignored because invalid endpoints
have been included in the "to" list. The "-to B_reg*/*" includes the clock
pin and data output pins of B_reg, which are all invalid endpoints. Only
the data input pin is a valid endpoint. This bad example should be written
like this:
set_multicycle_path 2 -setup -end -from A_reg*/CP -to B_reg*/D
Lastly, users can use the following checklist to locate the root of ignored
timing exceptions:
- check to see if the timing path might not exist
- check for invalid startpoint and endpoint
- check if a set_disable_timing command blocks the path specified by the
exception
- check the output of check_timing -ignored_attributes
- check the order of precedence for timing exceptions
- check if the exception is applied on an unconstrained path
- path segmentation might have been specified incorrectly
Understanding and writing good exceptions at the start is *key* to reducing
the amount of ignored exceptions by PrimeTime.
- [ A Synopsys PrimeTime CAE ]
|
|
