( DAC 01 Item 35 ) --------------------------------------------- [ 7/31/01 ]

Subject: PrimeTime-SI, Mars Xtalk, Sequence, Incentia, Ansoft, Optem

CROSSTALK:  This is the year that Synopsys decided to push PrimeTime into
the backend with its new PrimeTime-SI tool.  It's an analysis tool that's
a lot like Avanti's Mars Xtalk, but users complain that the current version
of PrimeTime-SI lacks any way to do noise/IR-drop analysis.  The other big
question users complain about is what do you do one you find the problem?
Exactly how do you fix (in an automated way) designs that suffer from
severe SI issues?


    "I've used Synopsys PrimeTime a bit.  I spent a little while trying to
     persuade it to generate ILMs, but I just couldn't get it to work.
     Other guys in my group are working on that now.  I guess it's just a
     function of them being new, or something.  Still, it's frustrating to
     have this feature available and yet to be completely unable to use it.
     It seems like it would be really useful."

          - Natalie Overstreet Ramsey, Vitesse Semiconductor


    "Gate Level Static Timing Analysis

     In the gate level arena, Synopsys Primetime rules the roost here, in
     part because they bought their competitor (Viewlogic's Motive) and
     killed it off. Incentia now sells a tool that they claim is completely
     compatible with Primetime but at least 15X faster (some customers claim
     a lot more than that) and quite a bit cheaper. Cadence has been talking
     for more than a year about killing off their Pearl tool and making the
     static timing analyzer in Ambit a separate product, but it hasn't
     happened yet."

          - John Weiland, Intrinsix


    "Looking at PrimeTime-SI and MarsXtalk.  Both good tools.  SI looks to
     weigh in a bit more pessimistic than Xtalk, but both tools have their
     merits.  Depends on what you are looking for in a crosstalk solution.
     This problem BTW is a real scarry one.  The deeper we dig on this one,
     the more we're convinced this could be a real chip killer."

          - Phil Hoppes, Intersil


    "PrimeTime-SI:

     Synopsys is offering PrimeTime-SI and PrimeTime as a fully integrated
     package for full chip static timing and power analysis.  They think
     that full chip simulation to analyze noise and crosstalk induced delay
     will take a very long time.  Instead static crosstalk and noise
     analysis will give fast and accurate results.  The live demo was on a
     220 Kgate, 0.18um, 100 MHz.  It showed how a design that was originally
     timing clean, can have large crosstalk induced setup violations.  Key
     PrimeTime-SI features:

     * Ease of use.  This product is seamlessly integrated into the current
       PrimeTime and produces two reports analyzing the delta delay (noise
       induced crosstalk delay) and "bump" voltages on the victim nets. 
     * No noise analysis as yet.  However, they measure the small "bumps" in
       the voltage wave form when the victim is in transition.  They expect
       to have a complete noise analysis solution by Q3, 2001.
     * Option to write out a SPICE deck on critical portions of the design.
       They claim that they correlate with SPICE within 5-10%.
     * Very compute intensive.  The process of analyzing the crosstalk
       effects is iterative.  From the run times provided, it looked like
       the run times are also dependent on the number of nets with
       cross-coupling capacitances.

     If the noise analysis was incorporated into PrimeTime-SI, this product
     offers very similar analysis capabilities to Avanti Mars-Crosstalk."

          - [ An Anon Engineer ]


    "PrimeTime-SI is only for analysis of cross-talk.  It can't solve
     problems and can't analyze IP-drop now."

          - Jeong-Fa Sheu of Acute Communications


    "I think I'll only be using Avanti Star tools and Synopsys PrimeTime-SI
     in the future."

          - [ An Anon Engineer ]


    "I don't think much of Synopsys PrimeTime-SI since it has no detailed
     physical info."

          - [ An Anon Engineer ]


    "We are evaluating PrimeTime SI."  

          - Bruce Loyer, AMD


    "Saw a demo on PrimeTime-SI.  First impressions: DesignSphere may not
     be ready for 'primetime' yet.  It caused two interruptions during the
     PrimeTime-SI demo.  PrimeTime-SI, once it gets IR drop analysis
     capabilities, would be interesting to look into.  Until then, I don't
     see a reason to migrate to it, while still needing another tool for
     IR drop.  Currently, Avanti's MARS toolset seems adequate."

          - [ An Anon Engineer ]


    "We brought in PrimeTime-SI last December, and ran it through the
     paces using the same benchmark design we had used on PhysOpt, except
     this time in 0.15u with a higher frequency target.  We ran into a
     number of early-adopter-type bugs initially, but found:

      - accuracy within 5% of SPICE on most nets, errs on the pessimistic 
        side (which is OK in a synthesis tool, but less OK in a sign-off
        tool -- see below.)

      - good path into SPICE for those nets on which greater accuracy is
        required.

      - around 3X the CPU time in a normal PrimeTime run without crosstalk
        (using default 2 iterations, and a reasonable 2nd-pass filter, as
        recommended by Synopsys) -- note that it can take a *lot* longer if
        you set the wrong options!

      - easy to integrate into our existing post-layout analysis flow, 
        though it would have been even easier if they supported DSPF
        (instead of SPEF.)

      - good reports to identify the likely places for fixes, but a link
        to a layout viewer would be a great help when debugging.

     Overall we were quite happy with PrimeTime-SI, except for when you
     identify significant timing degradation due to crosstalk, how do
     you fix it?  In our case we found the critical path timing degraded
     around 7%.  We taped out the part anyway, and it seems to be working
     fine (though we haven't enough samples yet to determine if yield took
     a hit as a result).  Given the number of near-critical paths produced
     by synthesis, pessimistic analysis without an automated repair
     mechanism leads to lots of potential violators to wade through, to find
     the few that will truly limit a device's performance.

     I'd be interested to hear inputs from other designers as to how they
     have closed this loop, whether it be via methodology or via the new
     crop of tools aimed at solving this new variation on the timing-closure
     problem.  I can think of three ways to attack this problem:

       1) prevention (general routing restrictions on length of parallel 
          lines, or coupling cap limits)
       2) better ranking of crosstalk "victims" (to focus manual editing
          onto key problem areas)
       3) automated repair (driver-sizing, buffer insertion, ECO routing)

     Approach #1 seems conservative but possible,  #2 seems hard to do in a
     reasonable amount of time, and #3 is a step backward into a
     "links-to-layout" type methodology --  one that has clearly run out
     of gas at 0.18u & below.  Comments welcome... (except from vendors
     plugging their tools - get your customers to do it!)"

          - Ken Scott of Conexant


    "Sequence Design sells a tool that does crosstalk analysis. They can do
     an analysis after routing or after placement but before routing (the
     latter sounds crazy to me, but what do I know). If it's done before
     routing, they do the analysis on pairs of nets that could be close
     based on driver/receiver locations, and size drivers to eliminate
     problems before routing starts.

     After routing, they can analyze for both static glitch problems and
     dynamic timing problems. One issue they complain about is that most
     libraries are not characterized for the glitch propagation
     characteristics of the gate (i.e. how much of the delay is inertial
     and how much is transport). You can use a .lib format, ELF (which
     they prefer since it contains glitch information) or let the tool
     guess about inertial delays. When they do post-route static timing
     analysis they also calculate the supply drop at each gate and derate
     the delays individually based on their Synopsys library model (kind
     of like the Simplex/Silicon Metrics flow), rather than just assuming
     all gates will have maximum supply drop at worst case conditions.

     Cadence's PKS will try to solve crosstalk problems by basically
     varying driver sizes to equalize the rise and fall times of all gates.

     Synopsys says their new router is aware of signal integrity but I
     didn't get to find out exactly what that meant. Historically this
     has been one of their weakest areas.

     Ansoft, Optem, Zeland Design and Sigrity all sell EM tools. Ansoft
     sells a variety of tools for RF signal integrity and also
     electormechanical simulation. Optem sells a tool to do EM analysis
     of cables, connectors, boards and packages. They also say they can
     do full chip extraction remarkably fast, but only extracts the
     devices, not the interconnect (huh?). Maybe I missed something on
     that one. Zeland Design sells a tool that does electromagnetic
     simulation of packages, on-chip inductors, etc. It is PC based.

     Sigrity sells tools that do EM simulation and extraction of packages
     and boards.

     Sagantech sells a tool that does crosstalk analysis and correction,
     but it currently has no static timing analysis capability, so there
     will be a lot of spurious errors from nets which are coupled but
     change at different times."

          - John Weiland, Intrinsix


 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)