( ESNUG 353 Item 2 ) --------------------------------------------- [5/24/00]

Subject: (  ESNUG 352 #1  )   Handling Scan Test Issues With Ultima ClockWise

> I recently taped out a design on which I inserted clock trees using the
> Ultima ClockWise tool and really liked it.  In the past I have used
> intentional skew in special situations to help improve timing, but it was
> difficult time consuming hand work...
>
>     - Jon Stahl, Principal Engineer
>       Avici Systems                             N. Billerica, MA


From: Tim Dunnington 

Hi, John,

I found Jon Stahl's discussion of Ultima ClockWise in ESNUG 352 #1 to be
the best I have seen yet.  I have some questions about how this relates to
scan testing though.  Did he insert the clock trees before adding scan
logic or after?  I have to assume the useful skew for functional mode is
not useful for scan testing.  Did he then go back in the netlist to add
delays to the scan paths to fix hold time problems?

    - Tim Dunnington
      Motorola SPS                               Chicago, IL

         ----    ----    ----    ----    ----    ----   ----

From: Jon Stahl 

Hi John,

We have a slightly involved methodology for scan related issues.

Our ASIC vendor LSI has "enhanced scan hold" flop equivalents for most of
the flops in thier library.  These have scan data in port hold times of up
to -700 ps (nominal) at the cost of a little extra area.  We limit
synthesis to the subset of flops that have these equivalents.

Post-synthesis we transform all flops into thier enhanced scan hold
equivalents, perform placement, and re-stitch the scan chain using nearest
neighbor flops.  This will give you the minimum routing impact for scan
but is guaranteed to create some hold problems even with the enhanced flops.

At this point we do timing analysis, functional and test modes, and start
work on automated/manual ECO's to meet placed timing.

And here is where I am a little unclear as to the best course of action when
ClockWise is brought into the picture.  On my latest design I just did the
automated upsizing/buffering that my tools were capable of, which brought me
to -1.2 ns of slack worst path.  In the past, assuming that the number of
violations were reasonable to the degree that I could see an end in sight,
I would have worked at manual ECO's and placement alterations to fix them.
Or gone back to synthesis (or arrgh ... RTL) and iterated.

This time I just let ClockWise rip, and was happy to see it get rid of ~90%
of the setup violations.  This will of course not always be the case.  But
anyway, a *little* bit of post-clock insertion work got me all the way to
placed timing.  This included adding in the necessary delay cells to fix
scan hold problems, something which we have automated (a PrimeTime script
spits out a set of commands for another tool to add the delay cells in the
appropriate spot.)

I should note that our telecom designs are mostly I/O limited in die size
and medium volume in any case (i.e. I feel that it is more than worth it to
burn the area for the enhanced hold flops and delay cells in order to
improve time to market.)  This might not be acceptable to others, and it
might be hard to merge in the necessary delay cells on really dense designs.
I (what the hell) ran ClockWise using only worst case libraries (it can take
best/worst and do both analyses) to have it focus on setup and ignore holds
which I fixed with delay cells later.  If I hadn't, it would have looked at
the best case scan arcs and been forced to build a tree so as not to violate
them.  This would have impaired it's ability to fix setup's, hold being
it's dominating constraint.

    - Jon Stahl, Principal Engineer
      Avici Systems                             N. Billerica, MA