( ESNUG 203 Item 1 ) ---------------------------------------------- [12/2/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: aluxs!alsun121!jte (John Emmott)
John,
The root causes of overdriven nets can be summarized into three categories:
1. User DID NOT set max_area to less than achievable.
2. Some cells were inserted in critical paths and at some point in the
synthesis were thought to be required. At a later point like fix design
rules this thought was changed. But, the cell remains. The path
containing the cell never fails and is not looked at in later compiles
that try to remove the large area cells.
3. Marginal Timing ( <<1ns ) improvement to meet user requirements.
Work-Arounds:
1.) Set Max Area to less than achievable and recompile.
2.) set_dont_use "high power cells"
translate
remove_attribute dont_use "high power cells"
compile -incremental
(also works and better/faster than work-around #1.)
3.) when all else fails be brave and use vi or your favorite editor.
4.) Best Design Practice: request from the Synopsys support center a
vendor attribute for libraries of a minimum capacitance a cell that can
drive as a design rule addition to the vendor library. (e-mail:
support_center@synopsys.com) As a vendor we have requested this
feature and with end user support its priority could be raised.
Problems associated with 1 and 2 have achieved acceptable yet reliable
results in a number of cases. Resorting to hand editing is not satisfactory
for the user and/or vendor -- and results in slipping schedules, numerous
retesting runs from the danger that the edit is incorrect.
- John Emmott
AT&T
|
|
