Where C++ Is Used in Semiconductor Engineering

Part I · Module 1 · Chapter 1.5 · Where C++ Is Used in Semiconductor Engineering

1. The Question Worth Asking

"Where is C++ used in chip design?" invites a list, and a list is the least useful form of this answer. Lists go stale, they do not transfer, and they do not help you when a new problem arrives and someone asks which language it belongs in.

So rather than a list, this chapter derives the answer. Chapters 1.1 and 1.2 established an unusual property combination:

• No managed runtime. No interpreter, no garbage collector, no layer between the program and the machine. Predictable timing; direct control of how data sits in memory.
• Abstraction that compiles away. Chapter 1.1 measured it: fifteen function calls at -O0, none at -O2. You can organise a large program without paying for the organisation at run time.
• Links against C. The whole installed base of C libraries, kernel interfaces and tool APIs is directly reachable.

Each of those alone is available elsewhere. C has the first and the third. Python has the second in a sense, and neither of the others. What is rare is having all three, and the places C++ dominates in this industry are precisely the places where a problem needs all three at once.

The test, stated once so you can apply it yourself:

A problem belongs in C++ when it is simultaneously large enough that it must be organised, and demanding enough that you cannot afford a runtime between you and the machine.

Large but undemanding — a regression dispatcher, a report generator — belongs in Python. Demanding but small — a bit of register-poking in a boot ROM — belongs in C. Both at once is the C++ region, and the five sections that follow are what it contains.

2. The Shape of It: C++ Is Not in the Design

Before the touch points, the structural point, because getting it backwards wastes a lot of a learner's time.

C++ does not describe hardware. The design — the thing that becomes gates and eventually silicon — is written in an HDL: Verilog, SystemVerilog, VHDL. Those languages exist because hardware is concurrent, clocked and structural, and a sequential imperative language is the wrong tool for describing it. No amount of C++ changes that, and a reader who hopes C++ is a way to avoid learning an HDL has misread the field.

What C++ builds is everything around the design: the tools that process it, the models that predict what it should do, the checkers that decide whether it did, and the software that runs on it afterwards. That is a large and well-paid territory, and it is a different one.

Keep that picture. Every section below is one of those four boxes, plus a fifth role that sits off to the side.

3. EDA Tool Internals

Start here, because it is the largest body of C++ in the industry and the one engineers are least aware of using.

Every tool in a semiconductor flow — the logic simulator, the synthesis engine, the place-and-route tool, the static timing analyser, the formal verification engine, the physical verification checker — is a large C++ program. You use several of them daily without seeing a line of their source.

The reason is structural rather than historical, and it is worth working through because the same reasoning applies to your own models:

The data structures are enormous and irregular. A netlist for a modern block is millions of instances connected by millions of nets, held as a graph you must traverse repeatedly. A timing analysis walks paths through that graph. An expensive data structure here is not a 20% problem; it is the difference between a tool that finishes overnight and one that does not finish.

Runtimes are measured in hours and the inner loops are hot. When one analysis runs for six hours, a constant factor in an inner loop is a direct cost in engineering schedule and compute budget. This is exactly Chapter 1.1's territory: these tools need abstraction to stay maintainable and they cannot afford it to cost anything at run time.

The codebases are decades old and still shipping. Several of these tools have been under continuous development since the 1990s. That longevity rewards a language with strong compile-time checking and strong module boundaries, and it is also why C++'s commitment to backward compatibility — irritating in the abstract — is a feature to the people maintaining them.

They must integrate with everything. Tcl interpreters for scripting, C libraries for file formats, licence managers, distributed-compute layers. The ability to link directly against C is not a nicety here.

This matters to you in two ways even if you never write a tool. It explains the performance behaviour you observe — why a tool's memory grows the way it does, why incremental mode exists. And it is a career path: tool development inside EDA vendors and inside the large chip companies' internal-tools groups is substantially C++ work.

4. Architectural and Performance Models

This is the touch point most engineers underestimate, and the one where the argument for C++ is sharpest.

Long before RTL exists, decisions have to be made that are extremely expensive to change later. How large should the last-level cache be? How many outstanding transactions should the interconnect support? Is the memory controller's scheduling policy adequate for the expected traffic? Does the proposed topology deliver the bandwidth the workload needs?

Those questions share a property: they can only be answered by running a realistic workload, and a realistic workload is billions of cycles. That constraint rules out the obvious approaches:

• RTL simulation cannot do it. A cycle-accurate RTL simulation of a full subsystem runs at a speed measured in tens or hundreds of cycles per second of wall time. The gap between that and billions of cycles is orders of magnitude — and in any case the RTL does not exist yet, which is the entire point of asking the question now.
• A spreadsheet cannot do it. The questions are about dynamic behaviour: queueing, contention, locality, interference between traffic streams. Those are emergent, not arithmetic.
• A scripting language cannot do it. The model must execute billions of events. A factor of fifty in per-event cost turns a twenty-minute experiment into a two-week one, which does not merely slow the work down — it stops the exploration happening at all, because nobody runs fifty variants if each takes a fortnight.

So you build a model: a program that reproduces the behaviour you care about — hit rates, latencies, queue occupancies, bandwidth — while deliberately abstracting away everything you do not, including most of the timing detail and all of the microarchitectural structure. It must be fast, because the whole value is in sweeping many configurations. It must be well-organised, because it has configurable components that get recombined. Fast and large at once: the C++ region exactly.

This is not a niche practice. gem5, the widely used open-source architectural simulator, is a C++ codebase, and the proprietary equivalents inside chip companies are too.

5. Verification Reference Models

The third box, and the one most directly relevant if you work in verification.

A testbench drives stimulus into a design and observes what comes out. To know whether the output is correct, something must independently compute what the output should have been. That something is a reference model — and when it is treated as the authority on correct behaviour, a golden model.

C++ is a common choice for it, for three reasons that are worth separating:

The algorithm may already exist in C or C++. Compression, encryption, error-correcting codes, signal processing, floating-point arithmetic, video codecs — the specification is frequently accompanied by, or defined by, a C reference implementation. Re-implementing it in SystemVerilog introduces a second chance to be wrong about the specification, which is precisely the risk a reference model exists to remove.

The work is algorithmic rather than temporal. Computing an expected CRC, decoding a packet header, modelling a cache's replacement decision — these are transformations of data. SystemVerilog is built for concurrency, timing and the signal-level interface to a design; it is capable of expressing algorithms, and it is not where a substantial one is most clearly written.

Speed matters more than it looks. A reference model runs once per transaction, and a regression may push hundreds of millions of transactions. A model that is slower than the design it checks becomes the bottleneck of the entire verification campaign.

The division of labour is the thing to get right, and it is a genuine architectural decision rather than a preference:

6. Firmware, Bring-Up and Embedded Software

The fourth box. Silicon arrives and something has to run on it.

Boot code, device drivers, the bring-up software that exercises a new chip on a bench, the diagnostic suites that qualify it, and the embedded software that ships inside the product — all of this is systems software on constrained hardware, and the field has historically been C with C++ steadily taking ground.

The property that matters here is the one from Chapter 1.1 §8: deterministic destruction. In firmware you are managing things that are not memory — a peripheral that must be disabled, a clock that must be re-enabled, an interrupt that must be unmasked, a lock that must be released. A language that releases resources whenever a collector decides cannot express "this register must be restored when this operation ends, including when it fails". C++ can, and Module 12 is where you learn how.

Honest caveats, because this area has real constraints:

• Embedded C++ is frequently used as a subset. Exceptions and run-time type information are often disabled, dynamic allocation after start-up is often forbidden, and the standard library is used selectively. None of that is a reason to learn less C++ — knowing what a feature costs is what lets you decide to do without it.
• Toolchain lag is real here, which is part of the argument in Chapter 1.3 for a C++17 baseline.

7. Infrastructure and Data Processing

The fifth role, and the one that sits off to the side of the diagram rather than in it — because most of this work is correctly not C++, and knowing where the line falls is the useful part.

A verification flow produces an enormous amount of data: simulation logs, coverage databases, waveform files, timing reports, regression results. Something has to parse, merge, filter, correlate and summarise it.

Most of that is Python work, and should be. A script that reads yesterday's regression results and emails a summary has no performance constraint worth mentioning, and Python will be written in a tenth of the time.

C++ enters when the volume changes the problem:

• Merging coverage databases across thousands of runs, where the merge is a large data-structure operation rather than a text transformation.
• Processing waveform or trace files that are gigabytes each, where a per-event Python cost is multiplied by billions of events.
• Any tool that has become part of the inner loop of a flow — run on every commit, by every engineer — where its runtime is now everyone's problem.

The honest rule: start in Python; move to C++ when measurement says the volume demands it. Choosing C++ for a log parser that runs once a day is a cost with no benefit, and Chapter 1.2's design constraints do not make it one.

8. A Word on SystemC, Since You Will Hear It

If you have read anything about C++ in this industry you will have met the word SystemC, and it should be placed correctly rather than left vague.

SystemC is a C++ library. It is not a different language and not a C++ dialect — it is a set of C++ classes, plus a simulation kernel implemented in C++, used for building system-level models of hardware. Everything it provides is ordinary C++ underneath, which is exactly why it is mentioned in a chapter about where C++ is used: it is a significant application of the language in this field.

It is also a separate subject, and this curriculum does not teach it. SystemC has its own execution model, its own process and scheduling semantics, and its own transaction-modelling layer, and all of that is a course rather than a chapter. Learning it on top of weak C++ is the common mistake and produces engineers who can follow a SystemC tutorial and cannot debug a lifetime bug in their own model.

What this curriculum does instead is make you genuinely good at the C++ underneath: object lifetime, ownership, copy and move semantics, polymorphic interfaces, the standard library. That is the foundation SystemC assumes you already have, and it is the foundation its documentation does not teach.

9. Which C++ You Actually Need

A closing observation that should affect how you read the next twenty-seven modules.

Look back at the five roles. A performance model, a reference model, an EDA data structure and a piece of bring-up firmware are different programs, but the C++ they need overlaps far more than you would expect:

• Object lifetime and ownership. Every one of them holds resources — allocated data, a file, a handle, a device. Modules 10 through 14.
• Deliberate data representation. All four care exactly how bytes are laid out: a netlist node, a cache line, a packet, a register. Modules 3 and 9.
• The standard containers and algorithms. Every one of them is largely a data-structure program. Modules 19 and 20.
• Polymorphic interfaces. Swappable components — a replacement policy, a protocol checker, a tool back end. Modules 16 and 17.
• Debugging and performance discipline. All four are long-running programs where a lifetime bug surfaces far from its cause. Module 25.

What is not on that list is equally informative: no graphical interfaces, no web frameworks, no templates so advanced they need their own vocabulary. The C++ this field needs is a coherent, learnable core, which is the curriculum you are reading.

10. What You Should Be Able to Say Now

1. C++'s position comes from one property combination: no managed runtime, abstraction that compiles away, and direct linkage against C.
2. The test for whether a problem belongs in C++: it must be large enough to need organising and demanding enough that a runtime is unaffordable. Either one alone points elsewhere.
3. C++ does not describe hardware. The design is RTL in an HDL; C++ builds the tools, models, checkers and software around it.
4. EDA tools — simulation, synthesis, place and route, timing, formal — are large C++ programs, because of graph sizes, hot inner loops, decades-long lifetimes and the need to integrate with everything.
5. Architectural and performance models exist because the questions they answer require running a realistic workload, which is billions of cycles — orders of magnitude beyond RTL simulation, and asked before RTL exists.
6. The speed argument for models is really an exploration argument: it decides whether a team sweeps fifty configurations or three.
7. Reference and golden models are often C++ because the algorithm may already exist in C, the work is algorithmic rather than temporal, and model speed can bottleneck a whole regression.
8. C++ does not replace SystemVerilog in verification. SystemVerilog keeps the design interface, timing, concurrency, randomisation and coverage; C++ participates across a defined boundary, taught in Module 28.
9. Firmware and bring-up use C++ for deterministic destruction — releasing peripherals, clocks and locks on every path — frequently as a restricted subset.
10. Infrastructure and data processing is mostly Python and should be; C++ enters when volume makes per-event cost dominate. Start in Python, move on measurement.
11. SystemC is a C++ library and a separate subject. This curriculum teaches the C++ it assumes.

11. Exercises

Exercise 1 — apply the test. For each, say whether it belongs in C++, and justify with §1's two-part test rather than with preference: (a) a script that renames 4,000 waveform files overnight; (b) a cache model that must run a 2-billion-instruction trace against twelve configurations; (c) a function that polls one status register during boot; (d) a coverage merge across 6,000 regression runs; (e) a tool that reads a netlist and reports fan-out outliers, run by forty engineers on every commit.

Exercise 2 — argue the model's existence. A project manager asks why the architecture team is building a C++ cache model when the RTL will be written in four months and can be simulated then. Give the two independent reasons from §4 — one about speed, one about time ordering — and state which is the more fundamental.

Exercise 3 — draw the boundary. A verification engineer proposes writing the entire scoreboard, including the clocked interface to the design, in C++ "for speed". Using §5's table, say precisely which parts of that proposal are reasonable and which cannot work, and why.

Exercise 4 — identify the property. Each of the five roles leans most heavily on one of the three properties in §1. Assign the dominant property to each role and defend one of your assignments in two sentences.

Exercise 5 — the misconception. A student says: "I'll learn SystemC instead of C++ — it's the one used for hardware modelling." Using §8, explain what is wrong with the plan, and what specifically will go wrong for them six months in.

Exercise 6 — predict a sixth role. Using §1's test, propose one place in a semiconductor flow — not among the five above — where you would expect to find C++, and justify it against both halves of the test. Then name one place you would expect not to find it despite it being demanding, and say what disqualifies it.

12. Summary

• One property combination explains the whole map: no managed runtime, abstraction that compiles away, direct C linkage. C++ lives where a problem needs all three.
• The test: large enough to need organising, demanding enough that a runtime is unaffordable. Large-but-easy is Python; small-but-demanding is C.
• C++ is not in the design. The design is RTL in an HDL. C++ is the tools, models, checkers and software around it — which is the point of Figure 1.
• EDA tool internals are the largest body of C++ in the field: million-node graphs, multi-hour runtimes, decades-old codebases, integration with everything.
• Architectural models answer questions that need billions of cycles, before RTL exists — orders of magnitude beyond RTL simulation. Speed here determines whether design-space exploration happens at all.
• Reference and golden models are C++ when the algorithm already exists in C, the work is algorithmic rather than temporal, or model speed would otherwise bottleneck the regression.
• SystemVerilog keeps the testbench. Interface, timing, concurrency, randomisation, coverage. C++ participates across the DPI boundary — Module 27 for the models, Module 28 for the boundary.
• Firmware wants deterministic destruction — peripherals, clocks and locks released on every path — often within a restricted C++ subset.
• Infrastructure is mostly Python, correctly. Move to C++ on measured volume, not on instinct.
• SystemC is a C++ library and a separate subject. This curriculum teaches the C++ it assumes you have.
• The required C++ is a coherent core: lifetime and ownership, data representation, containers and algorithms, polymorphic interfaces, debugging discipline.

Of the five roles, one deserves more than a section, because it is where most readers of this curriculum will meet C++ first and where the architecture is least obvious. A testbench is not a program with a model bolted on — it is a system with a signal-level half and an algorithmic half, and the seam between them has to be designed. Chapter 1.6 opens that up: where exactly the reference model, the predictor, the checker and the data generator sit, what each one is responsible for, and why a verification team reaches outside the HDL in the first place.