With every technology node, the number of parasitics extracted for the same kind of circuit or block rises quickly. The accuracy requirements are going up and up and the manageable capacity of simulation tools simply is limited. One of our tools, Jivaro, is dedicated to sophisticated netlist reduction, in production usage at different places in all different flows. The input for this tool is a parasitics netlist, the output is a reduced parasitics netlist. Over the last couple of years we have carried out tens of dozens of evaluations for different blocks and subcircuits.
I can easily confirm that the number of parasitics for the same kind of block is rising definitely more than linearly: a PLL in 90nm technology was sufficiently accurately extracted using 200.000 RC parasitics, while the same kind of PLL in 65nm technology needs more than 1.000.000 parasitics in order to satisfy the accuracy needs of the designers. If you are able to effectively reduce those parasitics by a factor of 100 or more, you will see you simulation speed increase by interesting multiples. In addition to the number of elements, the kind of parasitics and the problem it imposes to the algorithms is getting worse. You rightly mentioned coupling capacitors, on our side we see more and more designers taking inductive effects into account. Suddenly you have inductors, models for reluctance, controlled current and voltage sources and so on, which turn usual reduction schemes inadequate.

As said in your interview, this is not manageable for any simulator and there are several ways to address this issue, which all need to be used in order to get a hand on accurate, but efficient simulations:

1. Abstraction – the use of higher-level blocks will substantially speed up
the simulation, while the parasitic effects are voluntarily neglected. This
is definitely possible for parts of the circuit design.

2. FastSpice simulators – the choice of accelerated spice simulators exploiting
parallelism seems to be growing. The problem with the parasitics is
that due to the coupling capacitors and mutual inductances, the partitioning
is very difficult. Also, parasitics extraction usually is a flat extraction
and the parasitics introduce a large, flat block into the simulation, which
is connecting the whole circuitry everywhere.

3. Sophisticated netlist reduction. The good news is, that there is hope to
netlist reduction, taking coupling capacitances and mutual inductances into
account. Take our Jivaro tool for instance. It achieves 80% reduction and
more, accelerating simulations, which were blocked due to the sheer
amount of parasitics.

The key word for the latter is sophisticated. While filtering techniques based on a maximum value or a maximum delay value were sufficient in the recent past, today you must use approaches that are much more complicated in a mathematical sense. You need error control, in order to be sure that acceptable levels of deviation are respected. Not on an average scale, but for all reduction. You need to be able to locally degrade the accuracy in defined ranges. Not easy at all as a task.

You say that the full verification flow needs to be intelligent and selective.
I completely agree. In order to have an accurate, but effective flow, a reduction tool needs to apply selective approaches, too: be very accurate where necessary, but for the sake of performance, relax accuracy where possible.
Keep coupling information where it has an impact. And last but not least: it must be transparent in order to measure the loss in accuracy you have due to netlist reduction.

The parasitics netlist reduction is a problem, which is situated in between the two tool categories, extraction and simulation, respectively. Some effort has been done by all EDA vendors, our company comes along to help customers with respect to the parasitics. In that sense we are not competing at all with anybody, to make this point clear, too.

We see netlist reduction as a major problem, which does neither belong to extraction nor to simulation. Back in 2005, we started our business on Model Order Reduction on the assumption, that in order to have an effective flow, you need to keep as much accuracy of the extraction in the netlist until the very last moment before simulation. Once you know exactly what you want to simulate, you carry out dedicated parasitics reduction.

In addition to what you address well in your discussion, which I would call the “outer” loop with selective extraction strategies tailored to different simulations, we are starting to see customers working with a shorter, “inner” loops. This basically means that in a first place a detailed and fully accurate extraction is carried out and instead of going back to the layout and extract over and over again for each kind of simulation, different reduction schemes are applied on the ready-to-be-reduced data, which is contained in our parasitics database belonging to the Jivaro tool.

It has been a couple of years now that we have been fighting to address this problem with a solution, in technical partnership with all of the major EDA companies and that’s the most important part for me. We are grateful for the support we get by the way. This problem is annoying for everybody.

Mathias