( ESNUG 368 Item 5 ) --------------------------------------------- [04/12/01]
 
From: Tom Ayers <tomayers@believe.com>
Subject: The New "high_fanout_net_threshold" in DC 2000.11 Cost Us A Week
 
Hi, John,
 
Perhaps some of your readers have already stumbled onto this one.  In any
case, here's hoping this saves someone some pain.
 
We have encountered a poorly documented new variable in DC 2000.11 which is
poised to cause you some pain.  It's called high_fanout_net_threshold and
is a new, potentially useful feature whereby nets over a certain fanout
limit are considered to be clock trees which will be taken care of via
clock tree synthesis.  This provides a second strategy for the classic
set_drive 0 approach to clock trees during synthesis.  No attempt will be
made to buffer these nets.  It looks like this was thrown in last minute
without the usual Synopsys QA process.  Here are the problems:
 
  1) No attempt to buffer the nets will be made, but timing arc involving
     these nets still are in the timing driven synthesis path groups, so
     DC will try for days to optimize nets which can't be buffered.
 
  2) Variable does not exist in the distributed .synopsys_dc.setup file,
     therefore it is un-initialized.
 
  3) Printvar thinks this variable does not exist.
 
  4) Setting this variable to 0 causes the old operation, but it is not
     initialized and you can't check what its value is due to #3.
 
  5) pipeline_design no longer tries to buffer stall signals even when this
     variable is set to zero.  This may be a tangential issue, but is
     probably related to the implementation of this new feature.
 
We now set high_fanout_net_threshold to 0.  Personally, I think this was
the wrong idea altogether.  Implementing a feature that allows you to
identify nets that will later be CTS is a good idea, but this does not take
those nets out of the timing arcs which would be needed if thats what you
want (could be done with set_drive 0 if you knew what nets were involved).
Since it is implemented as an arbitrary bar, the user does not know what
nets are affected and the assumption that there is some bar over which CTS
is used and under which it is not is a bad one.  For instance, test_se is
often one of the highest fanout nets, but is rarely CTS.  A much better
implementation would be to have a port constraint that identifies ports
which are CTS, does not buffer them, and puts a set_drive 0 on that net.
 
Looking at their man page, it looks like this was an attempt to improve
compile time.  Cost us a week of schedule in total.
 
    - Thomas Ayers
      Believe, Inc.
 
 
 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)