Skip to content

Explainer 5 min read

What an independent-solver check shows, and what it does not

Grading a fast predictor against solvers its authors did not write is stronger than grading it against their own, but it still has limits.

A dotted magenta underline marks a number read straight from a published file when this page was built.

In this post
  1. Why who grades matters
  2. The two referees
  3. What the record reports
  4. The limits, in the record's words
  5. How to read a margin
  6. What this means for you
  7. What this does not show

Why who grades matters

Any accuracy claim needs a referee. If a team grades its tool against software it wrote itself, the grade only shows the tool agrees with its authors. A buyer’s reviewer cannot treat that as independent.

An independent check changes who the referee is. The team picks a solver that other people wrote, runs both on the same layouts, and reports who came closer. The referee has no stake in the answer.

Why now: chip makers are moving to packages that hold several chiplets, and Intel has announced glass substrates for such packages, planned for the latter part of this decade. More of the coupling that decides whether such a package works sits between its vertical connections, so a buyer needs to know how far a fast estimate of it can be trusted.

That is the idea behind the check in this result’s published record. The tool graded is a fast predictor of coupling between a package’s vertical connections; the baseline is a pairwise sum, which adds up the coupling one pair at a time.

The two referees

The record names two outside solvers. The first is FastCap, a three-dimensional capacitance solver distributed by the MIT Computational Prototyping Group. It rests on the boundary element method.

The second is Palace, an open-source code that uses the finite element method. Its documentation lists capacitance extraction among its features, and its source is on GitHub.

Using two solvers built on different methods is deliberate. If they agreed with each other everywhere, one would be enough. The record says they do not agree about absolute accuracy, and it reports that difference instead of hiding it.

What the record reports

The record states that the fast predictor beat the pair-by-pair shortcut on every sampled population it measured. It also says that three FastCap comparisons exist side by side and that none replaces another.

  • The first comparison reports a margin of 15.567 times in the predictor’s favour, on 11 layouts, where the pair-by-pair baseline is the team’s own solver.
  • The second is a wider run of 43 layouts, where the pair-by-pair baseline comes from the team’s own solver. Its margin is 12.093 times.
  • The third is the like-for-like comparison, on 24 layouts, where FastCap supplies both the baseline and the truth. Its margin is 6.1172 times.

Read these together. The largest margin is not the fairest one, and the record says so. For the Palace run, the record gives a margin of 4.781 times, on one slice of layouts in which 85 of 103 sampled points were left out.

The limits, in the record’s words

The published record says, word for word (an excerpt)

Capacitance coupling only; inductance still comes from our own BEM because the FastHenry multi-via deck returns a non-finite matrix.

Two limits stand out. The check grades capacitance only. Inductance still comes from the team’s own solver, because the outside tool the team tried returned an unusable result for the multi-via case. And both the predictor and the referees are simulations, not measurements on silicon.

The Palace comparison also covers a narrow slice. It is a useful second opinion, but it is not a broad test.

How to read a margin

A margin of several times sounds dramatic, so it is worth being careful about what it means. It is a ratio of errors. If the shortcut is off by a certain amount and the predictor is off by a much smaller amount, the ratio is large, even though both numbers are small in absolute terms.

A ratio also depends on the baseline:

  • When the baseline is the team’s own solver, the comparison crosses two solver families.
  • When one tool supplies both sides, the comparison is like for like, and the record singles it out.

There is a second reason to prefer the like-for-like figure. It removes a tempting argument, which is that the predictor only looks good because the baseline was weak. When the same tool supplies the baseline and the truth, the cross-solver part of that argument goes away. Whether a pairwise sum reflects what production extraction tools do is a separate question.

What a buyer should ask next

A careful reader would ask three things:

  • Were the layouts chosen before the run, or after?
  • Do they resemble the layouts I care about?
  • What happens at the edge of the sampled range?

The published record describes the sampling and lists the commands used. The record does not claim to answer the second and third questions, because only a run on your own layouts can.

Why a second solver is not a tie-breaker

It is natural to hope that two outside solvers will settle everything. They rarely do. Each makes approximations, and each is a simulation, so they can disagree with each other by more than either disagrees with a good predictor.

The record treats this honestly. It says the two solvers’ disagreement about absolute accuracy was partly broken down into its causes, not averaged away. For a reader, the practical message is to treat the outside solvers as referees with known quirks, not as oracles.

What this means for you

  • Package signal-integrity teams. Treat the check as evidence that the predictor tracks FastCap more closely than a pairwise sum does, on the layouts tried. Ask for the same comparison on your layouts before you rely on it.
  • Makers of extraction tools. The pattern is the useful part. Grade against a solver you did not write, report every sample, and say which comparison is the fair one.
  • Diligence teams. The sampled layouts and the comparison files are listed on this site. Read the published record first. For the solver comparisons, the files record each result and a hash of the underlying run, which is not published, so those runs cannot be redone from this site alone.

What this does not show

It does not show that the predictor is accurate for inductance, for full-wave behaviour, or for a built package. It does not show that the margin holds on layouts outside the samples. And it does not settle which of the two outside solvers is closer to the truth, because the record leaves that disagreement only partly measured and mostly attributed, not resolved.

Keep reading

All posts

Sources and further reading

Where the numbers come from

Each number with a dotted magenta underline was read from one of these published files, field by field, when the page was built.

Every file this site publishes

Ask about a result, or check one yourself

Founder: Nick Harris. AI agents do our research and engineering. Each result is graded against an outside solver, checked by Lean, or held to a pass mark set before the run; these checks ran on our own machines. Why this team.

Every result on this site links to the file it comes from. Acquisition, licensing and partnership enquiries go to one address, and a person reads it.

Write to us Read the results

Each number links to the file it comes from; every file is listed, with its checksum, on Published files.

When a number is left off

We leave a number off a page, or mark it, when

  • its file has not loaded yet
  • nobody has looked into it yet
  • a search for it found nothing
  • its file holds no value for it
  • its file is missing or altered
  • files disagree on what it describes
  • its sample is too small for the claim
  • two files give different values
  • its file cannot be published
  • it was measured over ninety days ago
  • the question does not apply here
  • the program behind it stopped with an error