( ESNUG 372 Item 16 ) ------------------------------------------- [05/31/01]
Subject: ( ESNUG 365 #9 ) Chip Express Clock Buffer Insertion Nightmare
> Chip Express claims that Synopsys should be able to automatically insert
> the (correctly sized) buffers for us. (Larger buffer sizes are used for
> larger clock domains). However this has never worked for us. This is
> SUPPOSED to work through two mechanisms: the 'max_capacitance' attribute,
> and the 'connection_class' attribute. Their library puts a
> connection_class of CLOCK_NETWORK on all its flop clock inputs (and
> NO connection class on its combinatorial cell inputs). The clock buffer
> output also has the CLOCK_NETWORK connection class. So Design Compiler
> should (in theory) use one of these clock buffers to fix connection_class
> violations on clock nets, and the correct size will be chosen via the
> max_capacitance attributes on the buffer output. ...
>
> Does anyone have a remedy for this? We are at our wits' end here, and
> we get VERY little support from Chip Express.
>
> - Matt Gavin
> Rockwell Collins
From: Robert Wiegand <RWiegand@NxtWaveComm.com>
Hi John,
I used to deal with Chip Express library issues my previous life at Creative
Labs. At the time I used the cx2001 library, but many of the hand repairs I
had to do migrated into their newer libraries as well.
First of all, to address the clock tree issues, I would NOT allow Synopsys
to attempt to insert Chipx's buffers. Instead, I would have a dedicated
clocks block, a pads block, and the chip core instanced from the top level.
In the clocks block, I would hand instantiate the required buffers for clock
and reset trees. At the time, Chipx did not want to deal with scan enables,
so I let Synopsys buffer them for me. The pads block had all the required
pad cells instantiated. The core was compiled with ideal clocks, but
defined to account for insertion delay and skew (this was very important for
multiple and divided clocks). One nice thing about these clock and reset
buffer cells, is that they were actually correltated to post layout results.
This would allow me to propagate my clocks at the full chip level pre-layout
to do any final fixes before shipping the netlist. To battle the
connection_class problems, I would eliminate them when I set up the library
as follows:
(I would set the cell_library variable to the name of the library being
used, and of course make sure the commands work before using the /dev/null
redirection)
echo "***********************************************************"
echo "*** Setting up ideal clock drivers and cells ***"
echo "***********************************************************"
remove_attribute cell_library + "/*/CP" connection_class -quiet >
/dev/null
remove_attribute cell_library + "/*/CPN" connection_class -quiet >
/dev/null
remove_attribute cell_library + "/*/G" connection_class -quiet >
/dev/null
remove_attribute cell_library + "/*/GN" connection_class -quiet >
/dev/null
dont_use cell_library + "/cdq*" > /dev/null
echo "***********************************************************"
echo "*** Setting up ideal reset drivers and cells ***"
echo "***********************************************************"
remove_attribute cell_library + "/*/CLN" connection_class -quiet >
/dev/null
remove_attribute cell_library + "/*/PR" connection_class -quiet >
/dev/null
remove_attribute cell_library + "/*/PRN" connection_class -quiet >
/dev/null
dont_use cell_library + "/rdq*" > /dev/null
echo "***********************************************************"
echo "*** Fixing clock and reset driver attributes ***"
echo "***********************************************************"
remove_attribute cell_library + "/cdq*/A" connection_class -quiet >
/dev/null
remove_attribute cell_library + "/cdq*/Z" connection_class -quiet >
/dev/null
remove_attribute cell_library + "/rdq*/A" connection_class -quiet >
/dev/null
remove_attribute cell_library + "/rdq*/Z" connection_class -quiet >
/dev/null
There were other problems with the library that I would fix as well. Chipx
would try to control fanout with capacitance only, making any max_fanout
commands useless. There was no default fanout load attribute in the libray,
and some -- but not all -- pins had a 0 fanout_load attribute. That means
that you could drive thousands of these pins and Synopsys would not even
know it! Here's how I fixed that:
echo" ** Fixing fanout_load attributes on library cell input pins **"
set_attribute filter(find(pin,cell_library + "/*/*"),"@fanout_load ==
0.000000") fanout_load 1 -quiet > /dev/null
Another problem was one particular cell's output pin didn't have a
max_fanout attribute set on it. Here's how I fixed that:
set_attribute cx2001_core/iv10d/Z max_fanout 6 -type float
Hope this help!
- Bob Wiegand
NxtWave Communications Langhorne, PA
|
|
