( ESNUG 385 Item 16 ) -------------------------------------------- [12/19/01]

Subject: ( ESNUG 383 #17 ) More Setup/Hold Library Characterization Gotchas

> The .lib format has no mechanism for expressing any of these tradeoffs,
> even if you gather all the needed data.  That forces the guard-banding
> to be unnecessarily large, which in turn reduces the accuracy of timing
> analysis and synthesis.
>
>     - Howard Landman
>       Vitesse Semiconductor                      Longmont, CO


From: "Fred Obermeier" <fwo@z-circuit.com>

Hi, John,

Howard's comments concerning limitations of the .lib and this aspect of
timing analysis are correct.  To be safe, you end up creating models for
worst-case situations.

A widespread technique for picking setup and hold times involve a maximum
degraded clk-to-Q over nominal, such as 10%.  From a design standpoint,
you want the smallest combination of setup time and clk-to-Q for your models,
since these are used to determine the maximum operating frequency of your
design.  A conflicting design consideration is to have as small hold times
as possible.  Small hold times tremendously reduce the need to insert
buffers to fix hold time problems late in the design process.  So the
characterization of cells should reflect the design goals of circuits as
well as how these models will be used by timing analysis and/or synthesis.

Let's say you determine the minimum setup time given a large hold time and
the minimum hold time given a large setup time.  You can be more aggressive
when you don't see simultaneous minimum setup and hold conditions.  For
example, setup and hold times for a typical range of slew are +/- 150 psec
between slow and fast libraries.  Clk-to-Q times increase about +300 psec
when going from fast to slow libraries for typical loads and slews.  If you
consider a min/max design practice, setup time is analyzed with slow libs
and hold times are analyzed with fast libs.

This causes the setup/hold window to be wider than the minimum possible at a
specific PVT point which is where circuits closely operate.  Thus, even
though the flop may be vulnerable to dependent setup/hold failures at a
specific PVT, the min/max design practice usually prevents that from
occurring because that minimum window does not occur.

Let's look at the PVT variation for a typical FF at the same input slews
and output load conditions:

                setup   hold     clk-to-Q       clk-to-Q
                                 (small load)  (large load)
          slow  0.1766  -0.1382  0.4662        2.5090
          fast  0.0625  -0.0234  0.2115        1.0240

What you get if you use the minimum setup time will mostly likely be larger.
This represents a larger guard-band, to address the case where a path with
a minimum setup and minimum hold time can occur.

Z-circuit characterization software supports both of these techniques.

Therefore, dependent setup/hold is an area where you need to be careful not
to over-design when you characterize especially if you are pushing
performance.  Certainly, some types of flops can operate in unusual ways at
slow and fast PVT, so this is a case where dependent setup/hold may be
important and you can determine this by understanding the flop operation
at slow and fast PVT.

The issue of degraded clk-to-Q is more clearly an issue when better timing
analysis and .lib models would help.  Consider the case:

                                  ------
                           A -----|D  Q|----- B
                                  |    |
                         clk -----|>   |
                                  ------

Where A is the path going to the D input and B is the path from clk-to-Q
and on to the next flop.  Let's say A is a path where we barely meet
timing and thus setup time is minimum.  Then the clk-to-Q for B will really
be the degraded value and thus that better be what we model in the library.
However, let's say that path A meets timing easily.  Then the clk-to-Q will
NOT be degraded; however, we still will have used the degraded value because
thats the only option we have in the .lib model.  Thus we are over-designing
path B for no reason.  This is too bad since the timing analysis tool has
the information about path A, and knows how close to the setup time it
really is.  But there is no model to describe this.

A similar issue occurs for hold time and fast models.  However, in this case,
you better be sure to use the library that has the fastest value, rather than
the degraded value of clk-to-Q.  Otherwise, you risk a hold-time violation
even though the timing analysis report is clean.  The problem with this
fastest value is that you are over-designing again because you are using the
worst case.  Of course, circuits often operate faster than expected, so a
little extra margin for hold is good since hold-time violations have few
work-arounds.  With marginal setup time violations, you can slow the clock a
bit.

    - Fred Obermeier
      Z Circuit Automation, Inc.


============================================================================
 Trying to figure out a Synopsys bug?  Want to hear how 11,000+ other users
    dealt with it?  Then join the E-Mail Synopsys Users Group (ESNUG)!
 
       !!!     "It's not a BUG,               jcooley@world.std.com
      /o o\  /  it's a FEATURE!"                 (508) 429-4357
     (  >  )
      \ - /     - John Cooley, EDA & ASIC Design Consultant in Synopsys,
      _] [_         Verilog, VHDL and numerous Design Methodologies.

      Holliston Poor Farm, P.O. Box 6222, Holliston, MA  01746-6222
    Legal Disclaimer: "As always, anything said here is only opinion."
 The complete, searchable ESNUG Archive Site is at http://www.DeepChip.com
 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)