( ESNUG 465 Item 12 ) ------------------------------------------- [06/28/07]
Subject: ( ESNUG 454 #12 ) One user's eval of the Gradient CircuitFire tool
> I know you like user reviews of new EDA tools, so I thought I'd share
> with you our first cut at evaluating Gradient FireBolt. Our first
> question about Gradient was whether or not it predicted real life
> thermal behavior of a chip, so we used a test chip used to validate
> the tool for package temperature analysis.
>
> actual Tj (C) FireBolt Tj (C)
> Power JA measured average diode
> Package (W) (K/W) using diode temperature
> --------- ----- ----- ----------- -----------
> Epad1 2.19 29.7 87 87.91
> Epad2 2.18 29.4 86 86.97
> Slug1 2.13 28.2 82 82.96
> Slug2 2.12 27.8 81 81.88
>
> Personally, I think this is a good indication of accuracy but a more
> detailed investigation must be made. We are currently considering
> how to investigate a test chip dedicated to our unusually high voltage
> and high current designs.
>
> - [ Obelix of Armorica ]
From: Morgan Ercanbrack <morgan_ercanbrack=user domain=amis bot calm>
Hi, John,
There's a flaw in mixed-signal design for top level simulations and even
circuit simulation in general: Spectre/Eldo/Hspice/whatever all assume that
all your transistors are at the same temperature. Not good.
During the initial design of our automotive chip, our engineers didn't find
any problems with Spectre. During testing of fabricated parts, our part was
found to have a serious problem when the power circuitry turned on. It took
3 ECO's and a trememdous amount of engineering effort to figure out what was
wrong. What made the problem so maddening was it couldn't be simulated.
i.e. When we simulated in Spectre the circuit in the same mode that caused
it to fail on the test floor, the circuit functioned correctly!
It was our design engineers worst nightmare because it violated the axiom
of "If it can be simulated, it can be fixed." Eventually our engineers
determined the problem was caused by two temperature sensing devices on our
chip that were at different temperatures. Since our engineers could not
directly simulate the situation, we measured the outputs of the chip on a
testbench and mathematically derived the internal temperature gradient based
on the outputs. This created an offset that caused the circuit to fail. By
orienting the devices differently we found that the part performed better
and subsequent iterations of the part improved its performance until we
achieved reasonable results and our part met the specs.
Given our knowledge of this part, we wanted to use it as a test case to see
if CircuitFire could predict this problem based on our original layout, and
secondly show why our final layout fixed the problem. Therefore we used
it to analyze 2 different layouts, *before* and *after* the fix.
1. Before the fix. We ran CircuitFire on the original circuit to see if
it could identify the problem. CircuitFire calculated the temperature
gradient across the die and the temperature difference between the two
devices. Since CircuitFire dovetails with Cadence Spectre Verilog, it
then back annotated the results from CircuitFire to our netlist and
re-simulated the design.
CircuitFire correctly showed that we didn't meet our spec, and matched
our mathematical models within 1/2 of a degree. It was interesting
to note that the actual temperature delta between the 2 devices was
quite small, only 3.5 deg F.
2. After the fix. Next we wanted Gradient to simulate our layout that
seemed to have solve the problem. The goal of this experiment was
to verify that if a temperature gradient was indeed the problem, that
on this version of silicon, the temperature gradient should have
disappeared and the predicted output voltage should still be correct.
After re-running CircuitFire, the new gradient between the suspect
devices had been reduced to approximately 0.5 deg F. Thus validating
our hypothesis that a temperature gradient between these 2 devices was
indeed the problem and provided a good explanation why the latest
revision of silicon worked.
If we had run CircuitFire at the chip level *before* tape-out, we would have
spotted the problem before going to silicon. We wouldn't have spun the part
twice - that alone would have paid for the tool! It could have saved us 2
ECOs, un-realized revenue due to not getting the part into production, plus
all of our design and debug time trying to identify and solve the problem.
CircuitFire's Inputs:
- You need a technology file showing the process profile of the die's
conductivity. Most parasitic extraction tools, like Calibre xRC
require this information.
- A simulation testbench. Something you normally use to design a
circuit. (e.g. Cadence Spectre Verilog)
- Your circuit layout
CircuitFire's Outputs:
- Individual temperatures for each power source/instance that are
automatically back annotated as a new trise parameter to each transistor
in your design. Note that this is transparent to the designer. It is
automatically handled by the tool.
- A 3-D temperature map/profile of the die, showing temperature contours
across the die, including the Z direction as you start from the surface
and descend into the silicon.
- The simulation results defined by your testbench with a backannotated
trise parameter for each transistor. Thus the bad assumption of all the
transistors being simulated at the same temperature has be eliminated.
There are 3 major use models for CircuitFire:
1. At beginning of the design cycle. If you have a circuit that you know
will consume a lot of power, you can use CircuitFire to identify the
temperature gradients in your analog circuitry after doing basic
floorplanning. For example, if you have a opamp differential pair,
you can ensure that the differential pair is oriented so there is no
temperature gradient across the transistors. With this use model, the
analysis is quite simple and doesn't take long because you have a
limited number of devices.
2. Full chip analysis at end of design cycle. You can use CircuitFire
to look for temperature gradient issues on the entire chip to make
sure you meet your spec and haven't created reliability issues.
The tool must also have the performance and capacity to work at chip
level, which CircuitFire does have. Note: CircuitFire still uses the
same standard analog simulators - Spectre, Hspice, Eldo, etc - and it
so won't be any faster then the engine that it uses.
Typically a full-chip mixed-signal simulation can easily take a day,
provided you use a mixed-signal simulator.
3. Full chip analysis - post-silicon debug. If you did not use Gradient
during your design and verification process, and your simulations show
no problems, but your silicon still doesn't work, then you can use
CircuitFire to debug your circuit to determine if your chip's trouble
is related to temperature issues. Normally in chip debug, if you can't
simulate it, you can't fix it.
CircuitFire is very well thought out. It takes into account the impact of
the package on all surfaces the die touches, top, bottom, sides etc. It
takes into account bond wires and the 3 dimensions of the die. I had no
clue that a bond wire could have such a big impact! In fact, by looking at
some CircuitFire graphs showing the impact of bond wires, I was able to
later look at a plot with a motor driver and a sensitive analog circuit,
and tell the engineer to move the bond wire and reorient the analog circuit.
Gradient also opened my eyes to the impact the metallization of the chip
has on temperature gradients. For example, power buses, ground buses, and
wide metal traces conduct heat faster than silicon so they tend to act as
a heat sinks.
We had identified one issue with CircuitFire: it predicted an overly high
temperature when there was a pulse power source. Gradient had initially
decided to assume a steady state power source to keep the analysis faster;
the transient power source calculations are lengthier and your simulation
times go up substantially. But based on our input, Gradient has now
implemented a transient solution with the product. Our problem automotive
chip was simulated in a pulsed condition and despite using a steady state
solution Circuitfire still produced accurate results.
We used Calibre rules to extract the power sources within the database. We
then wrote some scripts to get the bounding boxes around our power sources
(e.g. diodes, transistors, resistors), so we had an accurate representation
of where the power was being dissipated. Gradient wrote the scripts,
because we needed to interface the info into Virtuoso.
The lynch pin of CircuitFire is the fact that it does temperature-aware
design, giving each transistor a different temperature coefficient so you
can simulate accordingly. You can no longer assume that all devices are
at the same temperature. This will become more critical with SOCs because
of the integration of disparate circuits like power amps, audio amps,
stepper motor drives, etc. with high resolution DACs, ADCs, PLLs, high
performance opAmps, etc.
- Morgan Ercanbrack
AMI Semiconductor Pocatello, ID
Index
Next->Item
|
|
