( ESNUG 211 Item 1 ) ---------------------------------------------- [3/2/95]
Subject: (ESNUG 192 #1 206 #5) "Anyone Using Synopsys's Static Timing Analyzer?"
> The problem was that Synopsys was not doing a very good job of handling the
> elimination of multi-cycle paths.... The main problem was that you didn't
> know that Design Compiler didn't understand your multi-cycle command.
From: sgolson@trilobyte.com (Steve Golson)
I've encountered this problem also. After much experimentation what I found
is, if you want to specify the path from one flop to another as multi-cycle,
the start point should be the CLOCK PIN of the first flop and the end point
should be the DATA INPUT PIN of the second flop, thus
set_multicycle_path 2 -setup -from find(pin,lbarb1/Q_reg[0]/CK) \
-to find(pin,datapath1/mpar*lt/ff1/D)
set_multicycle_path 1 -hold -from find(pin,lbarb1/Q_reg[0]/CK) \
-to find(pin,datapath1/mpar*lt/ff1/D)
Yes, that's right, you need to specify the path twice if you want to get
rid of bogus hold problems.
You can tell when you do it right, because report_timing shows twice the
clock period when it reports the path.
Do not trust report_timing_requirements -- it will show a path as multicycle,
but it may not actually be a legal timing path.
> The other problem was that the more mulit-cycle paths specified, the more
> likely to run very slow or even crash and burn, Synopsys-FATAL style.
This was supposedly fixed (in 3.0c, maybe?).
- Steve Golson
Trilobyte Systems
|
|
