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.