( ELSE 06 Item 22 ) -------------------------------------------- [ 06/23/06 ]
Subject: ClearShape InShape
ANTI-HYPE -- I liked having UMC (a foundry!) plus an anon hands-on DFM user
be the first two to break the ClearShape InShape story instead of the usual
bullshit press releases with the usual contrived hype. Nothing beats a
*first* impression of your customers speaking up in technical detail (with
benchmark numbers and all) on behalf of your tool. My congrats go to the
ClearShape folks.
InShape is ClearShape's DFM checker. It's a model-based DRC tool that
predicts systematic manufacturing shape variations. It highlights the
layout hotspots (i.e. low litho process margin locations) in your
design, but it's fast enough to run during layout.
For older technologies, most of our DFM concerns were problems somehow
related to random variations. We could control them by having designers
use rule-based DRCs. However, at 65 nm, these systematic manufacturing
variations are becoming significant. Also, with such a small geometry,
the differences in critical dimensions (CD) has a non-linear impact on
timing, leakage power and signal integrity. Our post-GDSII OPC works,
but InShape lets designers check the printability and silicon contour
hotspots early in the design phase *prior* to tapeout.
Here are the criteria that we used to select InShape as a DFM tool:
- The tool's silicon contour predictions had to be accurate.
- The tool had to be fast enough for our designers to run during
layout, meaning that it had to take minutes/hours and not days
to run a design through it with usable accuracy.
- Ideally we wanted a tool to handle an entire design as well as
blocks and cell libraries.
- The tool should not require that our fab's proprietary OPC scripts
to be released.
- The tool needed the ability to secure IP protection/encryption, so
we could safely deliver our proprietary manufacturing models to our
external designers.
To analyze our libraries in InShape, we ran each standard cell component
hundreds/thousands of times in randomized context in it. InShape
generated reports highlighting printability problems on some cells,
which we then modified at the transistor level. After hotspot detection,
InShape reported the poly critical dimension distribution of each cell,
which we used to do a detailed electrical analysis (timing and leakage
power) of our cell library in the contexts of different environments.
We used InShape to analyze the variability caused by the sensitivity of
each std cell's interaction with its neighboring cells, as well to
compare different cell layout styles for designs in different contexts.
This sensitivity analysis of the std cell abutment during P&R (as in real
chips) was a key part of creating a quality standard cell library. We
were able to do numerous electrical predictions during library design,
without needing to wait for actual silicon data.
Here is an example of InShape's runtimes:
Die Size Time CPUs
---------- ------- ----
65 nm Project A (metal 1) 4.5 x 8 mm2 2.0 hrs 5
65 nm Project B (metal 1) 8 x 8 mm2 2.5 hrs 5
What we liked:
- Full-chip and/or IP hotspot detection. Due to InShape's fast speed
and distributed scalability, we are comfortable running full-chip
hotspot detection during design with reasonable TAT.
- InShape's use model is similar to traditional DRC. It is used during
layout. It also reports violations in the same way as DRCs are,
producing error markers for hotspots, and providing contours around
hotspots that can be loaded in our existing layout viewer or editor.
- We captured manufacturing information such as our lithography models
and retargeting rules into InShape's tech file, which can be encrypted
to protect our manufacturing IP while providing customers with access
to this data for DFM checking.
- InShape's contour predictions result in CD data that's based on the
device and interconnect variations in the context of the entire chip.
This CD data potentially can be used for electrical parametric
analysis (e.g. timing, signal integrity, and leakage power).
- We can do "what-if" analysis with InShape without being dependent on
our FAB OPC/litho group.
- InShape's ability to accept multiple EDA vendors' OPC results.
What needs fixing:
- InShape needs an easier setup for foundries. Much of our setup time
was spent on calibrating the models, and learning the patterns.
- They need to improve the "fixing guidelines" for the hotspots that
the tool reports.
Our first step of controlling these systematic variations is avoiding the
catastrophic errors due to printability issues. The next step will be to
analyze the electrical impact of these silicon contour variations.
ClearShape has shown us their tools and product roadmap where they will
link the shape contours to parametric data to help with timing, signal
integrity and leakage power. We do appreciate that as well.
- Chien Kuo Wang of UMC
InShape analyzes a specific set of constructs for systematic variations
by looking at printability issues associated with lithography and etch.
It is like a model-driven DRC, with a similar look, feel and speed...
the tool clearly identifies a very specific local construct that needs
to be fixed, and outputs the coordinates. Their shape simulator finds
catastrophic failures based on how one polygon is laid out in relation
to another polygon around it, and lets you know when it is okay to have
a space of X and when it is not.
We chose InShape because it met TSMC's accuracy requirements. We are
now in the process of validating the flow for other top tier foundries,
as we want to use *one* DFM tool for all of our foundries.
We also liked its speed. InShape is the only shape-simulation product
I have seen that can run the full chip. We could do multi-million gate
full chip simulations in reasonable times with reasonable number of CPUs,
and it was fairly scalable with CPU count (almost linear.)
For a full-chip, 45.4 mm2 design, running flat with no hierarchy across
the process window:
runtime CPUs
M2 2.3 hrs 60
M2 3.4 hrs 40
M1 5.0 hrs 60
M1 7.5 hrs 40
In contrast, most of today's post-OPC contour simulations take 4-7 days
per layer; this is just not viable during the design phase.
You can deploy InShape by running the design flat or hierarchically,
plus you can run at a single level or several levels. So the runtime
number is not actually a single number. In general, I expect we would
first use InShape to analyze a number of hard blocks, and then use it
hierarchically on the full chip. In that case, we might use only 4 or
5 CPUS for an overnight run for the full chip.
- [ An Anon Engineer ]
Index
Next->Item
|
|
