( ESNUG 202 Item 3 ) ---------------------------------------------- [11/18/94]
Subject: (ESNUG 201 #2) Design Compiler Producing Beaucoup Overdriven Nets
>We have a problem with Synopsys inserting extremely powerful buffers
>to drive nets with small loads (i.e. a buffer designed to drive a fan
>out of 180 or more driving a fanout of 1 or 2). ... The problem is that we
>can't simply not use the strong buffers as we have many cases where they are
>actually required (so we can't just put a dont_use on the strong buffers in
>the library) -- but we end up with literally hundreds of overdriven nets
>(which also costs us significant area). We have developed scripts which
>reduce the number of overdriven nets by iteratively compiling with and
>without a dont_use on the strong buffers -- but we still end up with dozens
>of overdriven nets.
From: M.A.Wilds@bnr.co.uk (Mark Wilds)
John, we had exactly the same problem with overdriven nets in our
design which was targetted at an LSI netlist. When Synopsys is given a
"real" delay/load file to use from LSI's CMDE program (instead of using
it's own wire length estimates) it can correct any ramp time warnings
from under driven nets, but doesn't fix any warnings to do with
overdriven nets. (This is despite the fact that replacing the cell
driving the net with a lower power version has negligible effect on the
timing, which isn't critical anyway.) The compile time of our device is
far too large to do any iterative compilations, and as you found out
that doesn't necessarily get around the problem. As far as we could see
there is no mechanism in Synopsys for persuading it to downsize any
oversized drivers.
In the end we had to resort to a solution outside of Synopsys, which
involved writing a program which reads in the LSI netlist, the seglen
file (LSI's delay/loading file) and the LSI file containing the
warnings about overdriven nets. This program then finds the offending
cells in the netlist, maps them onto lower power versions (which may
have different port names) and adjusts any references to these cells in
the seglen file. These modified netlist and seglen files are then read
back into CMDE which then produces new seglen and warning files. This
process has to be repeated 2-3 times because downsizing one driver
quite often reduced the loading on the previous driver, causing it be
an overdriving cell! Obviously you don't want to have to write a new
program for every different vendor and their associated technologies,
but apart from hand editing the net (not practical with 400+
overdriven nets!) we could see no alternative.
We'd appreciate any other workarounds that people may have found.
- Mark Wilds
BNR Europe Ltd.
|
|
