( ESNUG 483 Item 2 ) -------------------------------------------- [11/30/09]

From: Robert Patti <rpatti=user domain=tezzaron hot mom>
Subject: We recently dumped Mentor Calibre for Magma Quartz DRC/LVS

Hi John,

My company's 3D IC designs are unique in that we integrate separate dice
vertically through a special manufacturing process.  For example, our
"design" is 24 chips stacked in 2 layers vertically, with interconnect
between them to keep parasitics low.  This leads to better performance
with lower power, and has some benefits for yield and IC fab costs, too.

We recently switched from Mentor Calibre to Magma Quartz DRC/LVS.

We had been using Calibre for many years, but were not satisfied with it.
In particular, we were looking for:

  - An ability to scale efficiently across a larger # of CPU's and
    machines.  Calibre is OK on a single machine, but doesn't do well
    outside of that. We need to get results faster.

  - Better technical support.  We do highly specialized designs.  DRC
    customization is the norm rather than an exception for us.

  - Native support for TCL.  This is really important, as we need to be
    able to customize both the runsets and tool ourselves.  Other EDA
    tools we use are TCL based.  Calibre is based on a legacy runset
    language, and newer design rules need a better language option.

Another key requirement for adopting Quartz is it must be 100% compatible
with Calibre.  We have too much previous work put into Calibre decks and
it is the starting point with many of the fabs we interact with.  Magma's
"Direct Read" feature was exactly what we were looking for, and it let us
transition quickly to Quartz.


During our eval period, we started with the most complicated process/runset
we had at 65 nm, which was over 750 unique manufacturing checks, and is
over 9000 lines long.  Both rule complexity and the syntax used in the
runset are complicated - and therefore was a good benchmark vehicle.  For
example, the end-of-line via enclosure rules, and width dependent checks on
metallization for 65 nm require 100's of lines of complex runset logic.

We validated Quartz Direct Read in 4 working days.  We did this remote, so
elapsed time was closer to a few weeks.  Magma was able to set up and show
us how to run the flow.  Our Quartz results matched Calibre for all rules,
except for one, "NET AREA RATIO", which was one of the more complex
commands.  This issue has since then been fixed.

We have also used Quartz Direct Read with 130 nm with success, and will be
using it with 45 nm and with a wider variety of foundries very soon.


Quartz vs. Calibre:

In our best "apples to apples" comparison we could do with Calibre (same
number of threads for both tools), we found Magma Quartz to be 2-4X
faster at a lower number of threads.  As the number of threads increase,
the gap grows even larger.  We have tested from 2 to 16 cores and find
the scaling to be very good.  When the final top level checks on a 24 chip
"design" is ~2 hours, it literally saves us days.

To illustrate this is data from our 9.9 GB GDSII full "design" database.
This is one whole 3D-IC device with 24 separate chips stacked 2 layers
vertically.  (Our "design" could not successfully load in Calibre.)


Quartz scalability:

We ran two sets of experiments.  In the first case, our "design" was run on
a network of machines to test scalability.   For this size "design", Magma
advises 8 to 16 CPU cores for best results (the cores can be on the same
machine, or more typically on multiple machines).   What we observed:

                  # of CPU cores      Runtime (hours)

                      8                    5.90
                     16                    2.97
                     32                    1.95
                     48                    1.48

The scalability is great from 8 to 16, and pretty good at 32.  Their results
match their claims.   At 48 CPU cores there were diminishing returns, but we
believe that for larger designs the scalability should continue from 48 to
64 CPU cores.  Why?  Because the design is larger.  More transistors and
wire in the design requires more testing of the data.  This means that a
task like checking metal spacing has more edges to check -- which also means
the tasks can be spread among more CPUs efficiently.

Linear or not, being able to do our full chip verification in under 2 hours
is what counts for us.


Intel hyperthreading:

In our second experiment, we tested the new Hapertown quad-core Intel CPUs.
Each CPU has 4 cores, but you can enable Intel hyperthreading to get
additional performance.  This allows you to take advantage of CPU latency,
and advertised as a way to get a ~15% speed boost; if your SW is scalable.

What we saw:

  - Quartz, 8 cores, 8 threads (2 Intel X5470's)              5:30
  - Quartz, 8 cores, 16 hyperthreads (2 Intel W5590's)        3:30

So on exactly the same hardware, Quartz saw a 2 hour speed-up.

In both of the above tests, the peak memory usage is 7.1 GB.


We have since done 3 tape outs using Quartz, and are happy with its accuracy
and performance.   We've run our "design" that's more than 20x larger than a
normal design, and Quartz with Direct Read handled it, while Calibre choked.
Not only is Quartz much faster than Calibre, but its scalability with the
increase of CPUs uses means fast results even as our "designs" get larger.

Another pleasant surprize; the support we got during eval did not disappear
after we purchased the tool!   We've received continued great 24x7 support
from Magma -- especially when we are in tape out.

    - Robert Patti
      Tezzaron Semiconductor Corp.               Naperville, IL
Join    Index    Next->Item












   
 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)