Circuit simulation and parasitics: do we need more speed, or more insight (or both)?

[timof]

IC layout parasitics are playing increasingly important role in IC designs.

How to properly handle the parasitics?
Is speed of simulation (SPICE, IR/EM, timing, etc.) the only problem, or are there other important aspects beyond simulation speed - like deeper insight, better visualization, better identification and ranking of the critical parasitic elements and layout layers or shapes?

I discuss these and related questions in my LinkedIn article "Circuit simulation and parasitics: do we need more speed, or more insight (or both)?"

Please feel free to share your thoughts and experiences on this topic.

Circuit simulation and parasitics: do we need more speed, or more insight (or both)?

I recently read John Cooley’s interesting article on the Troublemakers panel discussion at DAC 2020 between Mentor’s Joe Sawicki and Cadence’s Anirudh Devgan. They were talking about Mentor’s AFS-XT SPICE simulator beating Cadence’s Spectre-X in speed by a factor of 3x-10x.

www.linkedin.com

 

[BradtheRad]

Our human tendency is that we request more features in computer programs, which leads to slowdowns and pauses.
So then we ask that programmers make them go faster.

Playing with circuit simulations, watching how they act, trying different concepts...
It's enhanced my understanding of electronics. In regard to IC layout parasitics, I have no experience with IC designing, although it becomes clear we need to remind ourselves that ideal components don't always act like real hardware.

So when component models portray real-world characteristics, it points us to places where heat is generated, power is wasted, efficiency lost. Certainly this is valuable to gaining insight. A simulator enhances our understanding, or it ought to.

With more detailed component models, comes longer simulation runs. Seems to me if we want greater speed, the simulator should offer a setting to omit some details in component models, or allow more fuzziness in order to reach convergence in a frame more quickly.

 

[dick_freebird]

For modern CAD systems there's a lot you can do
with the netlist. For example extraction usually has
a "minimum C filter" which will let you ignore the
attofarad capacitances that are found -everywhere-
and if you know how much C causes (say) a +5%
delay shift, you can set the minimum-C extraction
threshold to discard anything less significant. Of
course when you're talking finer points of RF where
C tuning of some nets is critical (like, say, on a
CMOS RF analog switch where C balance is key
to voltage division and breakdown / linearity, or low
power analog where incremental C could be a
much bigger timing influence than hard-banging
logic nets) you might need to take a more detailed
look with less pruning of those details.

Collecting parallel FETs into single large FET instances
is another high-leverage play. We had a CAD lady
make a PERL script to scrape through the netlist and
accumulate fully-parallel fingers (extract deck made
a FET per finger) for a big win in solution time.

These are simulator-external approaches to refining
the netlist and the netlisting process for layout
based SPICE (Spectre) simulation.

If you have a view-switching capability in your CAD
setup (like Cadence's Hierarchy Editor and "config"
views) then substitution of representations can be
done pretty "surgically" - you could for example
force the path of interest and any side dependencies
to be solved with full detail FET models, but gates not
relating to the path could be pointed at veriloga
views with faster solution in themselves, and fewer
nodes for SPICE. But not all SPICEs want to see veriloga
calls. And you may still want one full-detail simulation
of some functional vector set, just to know what it says,
whatever the time it takes.

 

[timof]

While extraction tools do have many control knobs (commands / settings / options), you cannot reduce the netlist size without losing some accuracy.
And one should be very careful with these settings - as most of them are not smart enough.
As an example, "minimum C filter" throws away (ignore) any capacitances lower than the specified value.
But if you have two nets with lots (let's say thousands) of these small couplings - at the end you will be ignoring a large coupling capacitance.
And there are many examples like that.

In multi-finger devices, different fingers may have a different resistance (to the port or to the other devices) - so collecting them together improperly (e.g. shorting) may give you a completely unintended, wrong result.

And while all such manipulations may help you reduce the size of the system, and get the result faster - you won't know where is your bottleneck, in parasitics or on the layout, if the simulated circuit behavior is wrong.
That was the main point of my article.

--- Updated Nov 9, 2020 ---

A simulator enhances our understanding, or it ought to.

Absolutely true.
Unfortunately, SPICE in its present shape, does not help understand parasitics, and to quickly fix those of them that are critical.

Seems to me if we want greater speed, the simulator should offer a setting to omit some details in component models, or allow more fuzziness in order to reach convergence in a frame more quickly.

Again, absolutely true - but it is an extremely hard task.
To omit the details that are irrelevant, and to retain the details that are important - the tool needs to understand the system, to understand what's important and what's not - and to achieve that, you need to transfer your knowledge and experience into the software.