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.
Early in my career I wrote firmware that ran on chips other people designed. I read their datasheets, I worked around their errata, and when something went wrong at three in the morning I had to decide whether the bug was in my code or in the silicon underneath it. That question, software or hardware, turns out to be the same question that decides a great many patent cases involving semiconductors, and it is the question litigation teams most often get wrong.
Chip cases look like software cases from a distance. There is a repository. There are files full of text that engineers call code. There is a review room, a protective order, and an expert reading through it all. So counsel staffs the matter the way they would staff a software matter, and the review begins.
The trouble is that the text in those files is not software, the thing it describes does not execute in program order, and the accused product is not the file at all. It is a physical object, fabricated months later in a plant on the other side of the world, and what is in the repository may or may not describe what actually shipped.
This article is about that gap: what a semiconductor patent case actually asks an expert to prove, what the evidence really consists of, and the specific ways technically strong teams get it wrong.
The layers, and why the accused product is rarely a single one
A modern chip exists in several representations at once, and a patent claim can read on any of them. Getting explicit about which layer the claim covers is the first job in the case, and skipping it is the root of most of the confusion that follows.
RTL, written in Verilog or VHDL. This is the layer that looks like source code and is not. Register transfer level description says what logic exists and how it behaves across clock edges. Nearly everything in it happens concurrently, governed by clock domains rather than by the order the lines appear on the page. A reviewer who reads a Verilog always block the way they would read a C function will describe the design incorrectly, and will do so confidently.
The synthesized netlist. A synthesis tool turns RTL into a specific arrangement of gates and flip-flops for a specific fabrication process. Synthesis is not a neutral translation. It optimizes, it removes logic it can prove unreachable, and it can restructure a design substantially. What the RTL says and what the netlist contains are related but not identical, and for some claim limitations that difference is the case.
The physical layout, the GDSII. Where each transistor and wire actually sits on the die. Claims directed at structure, spacing, layer arrangement, or physical arrangement of cells read on this layer and nothing above it.
The fabricated die itself. The object that was sold. Everything above it is a description of intent.
Firmware and microcode running on the chip. Many claims that appear to be about hardware are partly implemented by embedded code within the component, and that code is often held by a different team, under a different production, than the RTL.
Third-party IP blocks. Much of a modern chip is licensed from outside: a processor core from one vendor, a memory controller from another, standard interface blocks from a third. If the accused functionality sits inside a licensed block, questions of who practices the claim, and what the license already covers, arrive before any technical analysis matters.
A claim limitation that reads cleanly on the RTL may be absent from the netlist. A limitation about physical structure cannot be proven from RTL at all. The first thing I want to establish in a chip case is a limitation-by-limitation map: for each element, which layer would show it, and do we 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 described and lost on the mechanism implemented, one layer down.
What the expert actually has to prove
Infringement in a chip case comes down to demonstrating that the accused part, as sold, contains or performs each limitation. In practice that means three things.
Tracing the limitation to a layer that was produced. If the claim requires a particular structural arrangement and the production is RTL only, the analysis has a hole in it, and opposing counsel will find it. Establishing early what exists and what has been produced is not housekeeping; it determines what can be proven.
Showing the accused behavior occurs in the shipped configuration. Chips are configurable. Blocks are enabled or disabled by fuse settings, by firmware, by package options, by what the customer bought. A feature present in the design may be disabled in every part actually sold. Demonstrating that the accused functionality is live in the accused product, not merely present in the design database, is frequently the difference between an opinion that holds and one that does not.
Connecting the design to the silicon. This is where chip cases diverge 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 real work: fabrication and test records, characterization data, and in some matters physical analysis of the part.
The evidence problem
Physical evidence in semiconductor matters is genuinely expensive, and the decision to pursue it should be made deliberately and early rather than in the last weeks of expert discovery.
Die-level analysis means acquiring parts, decapsulating them, imaging the die, and often delayering it to photograph each level in turn. Reconstructing circuit function from those images is slow, skilled work. It can be decisive, particularly where the design production is incomplete or where the defense contends the shipped part differs from the database. It is also the kind of work whose cost and schedule need to be understood before anyone promises a court a date.
Simulation is the cheaper instrument and it is often the right one, but it has to be handled honestly. Running the produced RTL in a testbench shows what that RTL does under the stimulus chosen. It does not by itself establish what the fabricated part does, and an expert who blurs that distinction will be cross-examined on it. Being precise about what the simulation demonstrates, and what it does not, is more persuasive than overclaiming.
Then there is the ordinary discovery question that decides more chip cases than any exotic technique: was the right thing produced at all. Design databases are enormous, versioned across years, and organized around tape-out milestones rather than around product names. Identifying which revision corresponds to the accused part, and whether that revision is what was produced, is a technical question that counsel should be asking a technical person early.
Where chip cases go wrong
Patterns I have seen from across the table, stated generally.
Staffing the review with software engineers. This is the most common and most damaging error. Verilog and VHDL are hardware description languages, and reading them as though they executed sequentially produces analysis that a competent opposing expert will dismantle. Semiconductor matters need reviewers who think in registers, clock domains, timing closure, and synthesis, which in practice means working hardware engineers.
Treating RTL as the product. Related, and just as costly. The RTL is evidence about the product. Where the claim reaches structure or physical arrangement, it is the wrong evidence entirely.
Ignoring configurability. An analysis that proves a feature exists in the design, without establishing that it is enabled in the accused parts, is an analysis with an obvious answer waiting for it.
Missing the third-party block. Discovering at deposition that the accused functionality lives in a licensed core, and that the license may already cover it, is a bad moment that early technical scoping usually prevents.
Deferring claim construction thinking. Terms like "coupled to," "logic circuit," "memory," and "substantially concurrently" carry specific meanings to a hardware engineer that differ from their software connotations. In chip cases especially, the construction decides which layer the claim reads on, which decides what evidence matters, which decides the budget. This is precisely why a neutral technology tutorial before the Markman hearing pays for itself in semiconductor matters more than almost anywhere else: the judge is being asked to fix the meaning of terms in a field where the everyday intuition is actively misleading.
Apportionment starts as a technical question
Damages in chip cases run into a problem of scale that counsel should anticipate from the beginning. A modern part may contain dozens of functional blocks and billions of transistors. If the accused feature is one block among many, the question of what portion of the part's value it accounts for is not primarily an economic question. It is a technical one that the economist depends on: what does the block do, how much die area does it occupy, is it necessary to the part's basic operation or an optional enhancement, and would a customer notice its absence.
A technical expert who can answer those questions cleanly gives the damages expert something to build on. One who cannot leaves the apportionment analysis resting on assumptions the other side will attack. Coordinating the technical and damages experts early, rather than handing a finished technical report to an economist late, consistently produces a stronger position in patent infringement matters of this kind.
The reviewer has to match the layer
The vetting questions that apply to any technical review apply here with an additional dimension. It is not enough to ask whether the review team knows hardware. The right question is which layer each reviewer is qualified to analyze.
RTL analysis needs a design engineer fluent in Verilog or VHDL and in synthesis behavior. Netlist and timing work needs someone who has closed timing on a real part. Physical and layout questions need someone who has worked in the physical design flow or in failure analysis. Die imaging and reconstruction is a specialist discipline of its own. Firmware and microcode questions come back to embedded software, which is a different skill again.
Most chip matters need several of these, working under one methodology with one testifying expert who genuinely directed the analysis and can defend it as their own. The general framework for interrogating a review team, including who testifies, who reviews, and how findings are documented, is set out in our guide to vetting a source code review team. For semiconductor work, the reviewer-to-layer match is the part to press hardest.
What we do at Barr Group
Our electronics and software expert witnesses include working hardware engineers as well as firmware and software specialists, which matters in chip cases because the analysis usually spans both. We start by mapping each claim limitation to the layer that would demonstrate it, so the scope of the review, and the cost of it, follows from what actually has to be proven rather than from what happens to have been produced. We match reviewers to layers rather than assigning generalists. We are explicit about what simulation shows and what it does not, and about when physical analysis is genuinely necessary rather than reflexive. And we keep the technical story consistent from claim construction through expert reports and testimony, including the underlying source code review where firmware or RTL is at issue.
The takeaway
Semiconductor patent cases punish teams that treat them as software cases with unusual file extensions. The accused product is a physical object; the repository holds a description of it written in a language that only resembles code; and the distance between the two is where these cases are won and lost. Decide early which layer each limitation reads on. Establish what has been produced and what has not. Staff the review by layer, not by the word "engineer." And get the technical and damages experts talking to each other before either analysis is finished, because on a part with a thousand functions, proving infringement and proving what it is worth are the same investigation viewed from two 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.