By Michael Barr
Note: This article offers practical guidance for attorneys engaging technical experts. It is general commentary, not legal advice. Consult counsel about any specific matter.
My first engineering job was writing firmware for chips that other people had designed. I lived inside their datasheets, I built workarounds for their errata, and when a product misbehaved at two in the morning I had to settle one question before I could fix anything: was the fault in my code, or in the silicon underneath it? That same question now decides a surprising share of semiconductor patent cases, and it is the one litigation teams most reliably get wrong.
Chip matters arrive wearing the costume of software matters. There is a repository. There are files full of text that engineers call code. There is a secure review room, a protective order, and an expert working through the production. So counsel staffs the case the way a code case gets staffed, and the review begins.
What breaks is that the text in those files is not software, the thing it describes does not run in the order the lines appear, and the accused product is not the file at all. The accused product is a manufactured object, built months later in a fab on the other side of the world, and it may or may not match what the repository says.
This article is about that distance: what a semiconductor patent case actually asks an expert to establish, what the evidence consists of, and the specific places capable teams lose the thread.
The layers, and why the accused product is rarely a single one
A modern chip exists as several different representations at the same time, and a patent claim can read on any one of them. Deciding which layer the claim reaches is the first real task in the case. Most of the confusion that follows comes from skipping it.
RTL, written in Verilog or VHDL. The layer that resembles source code without being source code. A register transfer level description states what logic exists and how it behaves from one clock edge to the next. Almost everything in it happens at once, organized by clock domains rather than by line order. A reviewer who reads a Verilog always block the way they would read a C function will get the design wrong, and will be sure of the answer.
The synthesized netlist. A synthesis tool converts RTL into a particular arrangement of gates and flip-flops for a particular fabrication process. That conversion is not neutral. It optimizes, it deletes logic it can prove unreachable, and it can reorganize a design heavily. RTL and netlist are related but not the same, and for certain claim limitations the space between them is the whole case.
The physical layout, the GDSII. Where every transistor and wire actually sits on the die. Claims written to structure, spacing, layer arrangement, or cell placement read here and nowhere above.
The fabricated die. The object that was sold. Every layer above it is a statement of intent.
Firmware and microcode running on the chip. Many claims that look like hardware claims are practiced partly in code that ships inside the part, and that code frequently belongs to a different team and arrives in a different production than the RTL.
Third-party IP blocks. A large fraction of any modern chip is licensed from elsewhere: a processor core from one vendor, a memory controller from another, standard interface logic from a third. When the accused functionality sits inside a licensed block, the questions of who practices the claim and what the license already permits arrive before any technical analysis matters.
A limitation that reads cleanly on the RTL can be missing from the netlist. A limitation about physical structure cannot be proven from RTL at all. So the first thing I want in a chip case is a limitation-by-limitation map: for each element, which layer would demonstrate it, and do we actually have that layer.
The cost of skipping that map has a case caption. In Wisconsin Alumni Research Foundation v. Apple, a Wisconsin jury awarded over $234 million after finding that the load-store dependency predictor in Apple's A7 and A8 processors infringed WARF's prediction patent. The Federal Circuit reversed outright: the claims required a prediction associated with a particular load instruction, and the accused predictor indexed its prediction table with 12-bit hashed tags, so multiple load instructions could share a single tag and a single prediction. No reasonable juror, the court held, could find that mechanism met the limitation. 905 F.3d 1341 (Fed. Cir. 2018). The verdict was won on the architecture as described and lost on the mechanism as built, one layer down.
What the expert actually has to prove
Infringement in a chip case reduces to showing that the accused part, in the form it was sold, contains or performs every limitation. Three things carry that burden.
Tracing each limitation to a layer that was produced. If a claim requires a specific structural arrangement and the production consists of RTL alone, the analysis has a hole in it and opposing counsel will find that hole. Working out early what exists and what has been handed over is not administrative tidying. It sets the boundary of what can be proven at all.
Showing the accused behavior happens in the shipped configuration. Chips are configurable. Blocks get enabled or disabled by fuse settings, by firmware, by package option, by what the customer ordered. A feature sitting in the design may be switched off in every part that ever shipped. Proving the accused functionality is live in the accused product, rather than merely present in the design database, is often the whole difference between an opinion that survives and one that does not.
Connecting the design to the silicon. Here chip cases separate most sharply from software cases. In a software case the produced code usually is the product. In a chip case the produced design is a description of the product, and closing that gap takes genuine work: fabrication and test records, characterization data, and in some matters physical examination of the part itself.
The evidence problem
Physical evidence in semiconductor matters costs real money, and the choice to pursue it belongs early in the case rather than in the closing weeks of expert discovery.
Die-level analysis means buying parts, decapsulating them, imaging the die, and frequently delayering it to photograph each level in sequence. Rebuilding circuit function from those images is slow work for skilled hands. It can also decide a case, particularly where the design production is incomplete or where the defense argues the shipped part differs from the database. It is the kind of undertaking whose cost and schedule need to be understood before anyone commits to a date in front of a judge.
Simulation is the cheaper instrument and frequently the correct one, but it demands honesty about its limits. Running produced RTL in a testbench shows what that RTL does under the stimulus you chose. It does not by itself establish the behavior of the fabricated part, and an expert who lets those two blur together will be cross-examined on exactly that. Saying precisely what a simulation demonstrates, and what it leaves open, persuades better than overclaiming.
Then comes the plain discovery question that settles more chip cases than any specialized technique: was the right thing produced in the first place. Design databases are vast, versioned across years, and filed by tape-out milestone rather than by product name. Working out which revision corresponds to the accused part, and whether that revision is what arrived in the production, is a technical question counsel should put to a technical person early.
Where chip cases go wrong
Patterns I have watched from across the table, described generally.
Staffing the review with software engineers. The most frequent error and the most expensive. Verilog and VHDL are hardware description languages, and reading them as though they ran line by line yields analysis that a competent opposing expert will take apart in an afternoon. These matters need reviewers who think in registers, clock domains, timing closure, and synthesis, which in practice means practicing hardware engineers.
Treating RTL as the product. The same mistake wearing a different hat. RTL is evidence about the product. Where a claim reaches structure or physical arrangement, it is simply the wrong evidence.
Ignoring configurability. An analysis proving a feature exists in the design, without establishing that it runs in the accused parts, is an analysis with an obvious rebuttal already waiting for it.
Missing the third-party block. Learning at deposition that the accused functionality lives inside a licensed core, and that the license may already cover it, is a bad afternoon that early technical scoping almost always prevents.
Putting off claim construction thinking. Terms such as "coupled to," "logic circuit," "memory," and "substantially concurrently" mean specific things to a hardware engineer that differ from their software connotations. In chip cases the construction determines which layer the claim reads on, which determines what evidence counts, which determines the budget. That is why a neutral technology tutorial before the Markman hearing repays its cost in semiconductor matters more than almost anywhere else. The judge is being asked to fix the meaning of words in a field where ordinary intuition points the wrong way.
Apportionment starts as a technical question
Damages in chip cases run into a problem of scale that counsel should see coming from the first week. A modern part can hold dozens of functional blocks and billions of transistors. When the accused feature is one block among many, working out what share of the part's value it represents is not chiefly an economic exercise. It is a technical one the economist has to lean on: what does the block do, how much die area does it take, is it required for basic operation or an optional extra, and would a customer notice if it vanished.
A technical expert who answers those questions cleanly hands the damages expert something solid to build from. One who cannot leaves the apportionment resting on assumptions the other side will go after. Getting the technical and damages experts talking early, instead of delivering a finished technical report to an economist late, produces a stronger position in patent infringement matters of this kind.
The reviewer has to match the layer
Every vetting question that applies to a technical review applies here, plus one more dimension. Asking whether the review team knows hardware is not enough. The question is which layer each individual reviewer is qualified to analyze.
RTL work needs a design engineer fluent in Verilog or VHDL and in how synthesis behaves. Netlist and timing questions need somebody who has closed timing on a shipping part. Physical and layout questions need somebody from the physical design flow or from failure analysis. Die imaging and reconstruction is a specialty in its own right. Firmware and microcode questions land back in embedded software, which is different again.
Most chip matters need several of these people working under one methodology, with one testifying expert who genuinely ran the analysis and can defend it as their own work. The general framework for interrogating a review team, covering who testifies, who reviews, and how findings get documented, is laid out in our guide to vetting a source code review team, and the criteria for judging an electronics candidate specifically are in what makes a great electronics expert witness. For semiconductor work, the reviewer-to-layer match is the point to press hardest.
What we do at Barr Group
Our electronics and software expert witnesses include practicing hardware engineers alongside firmware and software specialists, which matters here because the analysis almost always crosses both. We begin by mapping every claim limitation to the layer that would demonstrate it, so the scope of the review, and its cost, follow from what has to be proven rather than from whatever happened to arrive in the production. We match reviewers to layers instead of assigning generalists. We say plainly what simulation shows and what it does not, and when physical analysis is genuinely required rather than reflexive. And we hold the technical story steady from claim construction through expert reports and testimony, including the underlying source code review wherever firmware or RTL is in dispute.
The takeaway
Semiconductor patent cases punish teams that treat them as software cases with unfamiliar file extensions. The accused product is a physical object, the repository holds a description of it written in a language that only looks like code, and the distance between those two is where these cases are won and lost. Settle early which layer each limitation reads on. Establish what has been produced and what has not. Staff the review by layer rather than by the word "engineer." And get the technical and damages experts into the same conversation before either analysis is finished, because on a part with a thousand functions, proving infringement and proving what it is worth turn out to be one investigation approached from opposite ends.
Barr Group's team of electronics and software expert witnesses provide experienced and unbiased source code reviews of software and hardware description languages alike, expert reports and testimony for product liability, patent infringement, software copyright, and trade secrets litigation involving computer-based technology and software. HIRE AN EXPERT
Get a matched recommendation >
Free, confidential, conflicts-checked, and our fee is built into the expert's hourly rate, so we are paid only if you retain.