( ESNUG 350 Item 6 ) --------------------------------------------- [4/27/00]

From: Christian Bohm <christian.bohm@analog.com>
Subject: How Can I Trick DC Into Synthesizing Fewer, Bigger, Richer Cells?

Hi John,

First of all I have to say I really enjoy ESNUG.  It's open, direct, and
pretty much unbiased.  Good work!  I have a question for your readers which
may be a bit off the beaten track.

Synthesising my design for a 3 layer metal process, I find that the cell
area utilisation after P&R (regardless which layout tool) ends up around 77
percent.  This means that 77 percent of the chip area is covered with cells
and the rest is "white space", only to be taken up by the routing overhead.
(Okay, control logic tends to have no structure, few cells and lots of
connections, so what I see is not really surprising.)

As in now happens, my design is a bit too big to fit into the space
allocated.  So I was wondering how I could use that 23 percent white space
for a few bigger, richer cells (e.g. AND-OR-INV) and reduce the wiring
overhead.  My idea is while the cell area increases, the routing overhead
decreases, and the overall design area should shrink (wishful thinking?)

Power and other side effects are not a primary concern.  How would one
constrain Design Compiler to achieve this?  We tried editing the .lib file
to increase the wire area in wireload model.  The idea being that each wire
now should have an "area penalty" associated.

    wire_load ("my_wire_load") {
    resistance     :    0.000083 ;
    capacitance    :  0.000116858 ;
    area           :  was: 1.319252 is: 5.319252; <== but didn't help a lot
                                                      (0.3% less nets)
    slope          :  101.342461 ;
    fanout_length (1, 149.84) ;
    ... more entries here ...
    }

To me it seems that this number is primarily used for the report_area output
but for nothing else.  Correct?

We were also thinking about making nets artificially longer, so that each
wire has a timing-penalty associated (I have no synth results yet) but I'm
somehow not convinced that that's a good strategy.  Any other suggestions
from ESNUG readers out there?

With respect to smaller geometries (0.18 um, 0.13 um) where it's the
interconnect delay which dominates and which causes your timing problems, a
strategy like this should really come in handy: Trying to minimize
interconnect rather-than/as-well-as cell area.  Agreed?  Disagreed?

    - Christian Bohm
      Analog Devices B.V.                        Somewhere, Europe


 Sign up for the DeepChip newsletter.
Email
 Read what EDA tool users really think.


Feedback About Wiretaps ESNUGs SIGN UP! Downloads Trip Reports Advertise

"Relax. This is a discussion. Anything said here is just one engineer's opinion. Email in your dissenting letter and it'll be published, too."
This Web Site Is Modified Every 2-3 Days
Copyright 1991-2024 John Cooley.  All Rights Reserved.
| Contact John Cooley | Webmaster | Legal | Feedback Form |

   !!!     "It's not a BUG,
  /o o\  /  it's a FEATURE!"
 (  >  )
  \ - / 
  _] [_     (jcooley 1991)