Typical VLSI Design Flow

Chapter 2 · Page 1.2 · Foundations

1. The Map Most Engineers Assemble Slowly

Ask a beginner what happens to their Verilog and the answer is usually "it becomes a chip." Ask an engineer who has shipped silicon and you get a list of thirty disciplines, most of which the beginner has never heard of.

This chapter is that list, organised. It will not teach you any one discipline — each has its own track on this platform and years of practice behind it. What it will do is give you the map: where each activity sits, what it consumes, what it produces, and why it exists at all.

Two honest warnings before we walk it.

This is not a waterfall. The phases are drawn in order because information generally flows that way, but real projects loop constantly — §20 is about that.

Organisations differ. Team boundaries, tool choices and even the meanings of words like verification and validation vary between companies. Where something is genuinely a matter of local convention, this chapter says so rather than inventing a universal rule.

2. The Design Keeps Changing Representation

The single most useful idea in this chapter: a design is not one artefact that gets gradually decorated. It is a sequence of different representations, each one answering a question the previous one could not.

Your Verilog sits at row four. Everything above it decides what to write; everything below it turns what you wrote into something physical.

3. Phase 1 — Product Intent and Requirements

Long before anyone writes RTL, someone decides what the product must do. Requirements typically cover functionality, performance, power, area and cost, external interfaces, and often reliability, safety or security obligations depending on the market. They also fix hard constraints — the target technology, the package, the schedule.

This matters to you as an RTL engineer for one blunt reason: good RTL cannot rescue a bad specification. If the requirement is ambiguous, the architecture encodes the ambiguity, the RTL implements it confidently, and the testbench — written from the same misunderstanding — passes.

4. Phase 2 — System Architecture

Architecture decides what major pieces exist and how responsibilities are divided. On a system-on-chip that typically means processors, memories and memory controllers, the interconnect that joins them, accelerators for work the processors should not do, peripherals, and the external interfaces. It also establishes the skeleton later stages depend on: clock domains, reset strategy, and power domains.

4.1 Hardware / software partitioning

One architectural decision deserves naming on its own: which functions are built as hardware, and which are left to software or firmware? Hardware is fast and efficient but expensive to change once fabricated. Software is flexible and can be patched, but slower and more power-hungry for the same work. Almost every product is a negotiated mixture, and that negotiation happens here — before RTL exists.

4.2 SystemC and high-level modelling

Architects often want to run a model of the system before committing to RTL, to explore choices and estimate performance. SystemC — a C++ library with hardware-oriented constructs, standardised as IEEE 1666 — is one common way to build such models, frequently at transaction level (TLM), where communication is modelled as transactions rather than individual signal wiggles. Working above signal detail makes these models far faster to run and much quicker to write than RTL, which is exactly what architectural exploration and early software development need.

Two qualifications matter. Such a model is an executable specification, not an implementation — it informs the RTL, it does not become it. And the practice is not universal: whether a project builds SystemC/TLM models, uses another modelling approach, or skips the step entirely depends on the organisation, the product and the methodology.

5. CAE, CAD and EDA — What the Words Mean

These three get used loosely and confuse newcomers, so it is worth separating them once.

EDA is the term you will hear most in this industry; the simulator, synthesis tool, timing analyser and layout tools are all EDA tools.

One local usage worth knowing: inside many semiconductor companies a "CAD engineer" (sometimes "CAD/methodology") is not drawing anything. The role typically builds and maintains the design flows, scripts, tool integrations, compute infrastructure and methodology that everyone else runs on. Titles and boundaries vary between companies.

6. Phase 3 — Microarchitecture

Architecture says what blocks exist. Microarchitecture decides how a given block will actually achieve its required behaviour. This is where pipelines, state machines, datapaths, register stages, buffering, arbitration schemes and interface protocols get chosen, and where latency and throughput targets become concrete structures.

It is the last stage before RTL, and it is mostly what an RTL designer is doing when they appear to be staring out of a window. By the time you type always @(posedge clk), the interesting decision has usually already been made.

7. Phase 4 — RTL Design, Where Verilog Sits

RTL — register transfer level — describes digital hardware as registers holding state, combinational logic computing what those registers should hold next, and a clock deciding when the transfer happens. This is the abstraction Verilog was built to express, and it is what the rest of this course teaches.

`default_nettype none

module counter4 (
    input  wire       clk,
    input  wire       rst_n,
    output reg  [3:0] count_q
);

    always @(posedge clk or negedge rst_n) begin
        if (!rst_n) count_q <= 4'b0000;
        else        count_q <= count_q + 1'b1;
    end

endmodule

Four bits of state, logic that adds one, a clock that decides when, and a reset that forces a known starting value. Simulated, it behaves like this:

Three things RTL is not, all of which trip up beginners:

• RTL is not the final gates. It describes behaviour; a tool decides the structure.
• RTL is not physical layout. Nothing here says where anything sits on silicon.
• RTL is not software running line by line. Everything inside a module exists simultaneously.

RTL Designing (Chapter 3) develops this properly.

7.1 Verilog, SystemVerilog and UVM are three different things

These three are constantly confused, and the confusion is worth killing early.

So: SystemVerilog is a superset of Verilog, and UVM is built on top of SystemVerilog. You cannot write UVM without SystemVerilog, and SystemVerilog only makes sense once the Verilog core underneath it does. That is why this track starts where it does — and the SystemVerilog track continues it.

8. Phase 5 — Pre-Silicon Confidence

Silicon is expensive and slow to change. So before anything is manufactured, teams spend enormous effort building confidence that the design is right. This phase is where most engineering hours on a large chip actually go.

No single technique is sufficient, which is why there are so many. They are not a pipeline where one follows another — they are complementary sources of evidence pointing at the same design from different directions.

8.1 Simulation

A simulator executes the described behaviour over time against stimulus from a testbench, and reports what every signal did. It is the workhorse, it is flexible, and it catches functional mistakes cheaply. Its limitation is fundamental: a simulation only tells you about the scenarios you actually ran. Design and Testbench Creation (Chapter 9) covers the mechanics.

8.2 UVM

For large designs, hand-written testbenches stop scaling. UVM (Universal Verification Methodology) is a standardised SystemVerilog class library and set of conventions for building verification environments that are reusable across blocks and projects.

A UVM environment generates stimulus, drives it into the design, observes what happened through a monitor, and checks it against what was expected — with coverage reporting which behaviours were actually reached. The internals are a substantial subject taught in the UVM track; they are not Chapter 2 material.

8.3 Assertions and coverage

Assertions state a property the design must always satisfy — "a request is always eventually acknowledged" — and the tool checks it continuously rather than at one point in a test. SystemVerilog Assertions (SVA) are the common form; see concurrent assertions.

Coverage answers a different question: not did it pass but what did we actually exercise? Code coverage measures which lines, branches and states the tests reached. Functional coverage measures which meaningful scenarios occurred. Passing tests with low coverage mostly tell you how little was exercised.

8.4 Formal verification

Simulation checks the scenarios you run. Formal verification uses mathematical reasoning engines to search the design's state space for any way to violate a stated property — within the model and assumptions you give it. Where it applies, it can establish that no counterexample exists, rather than that none was found in the tests you wrote.

Two common orientation-level uses: property checking (does the design always satisfy this assertion?) and equivalence checking (are these two representations — say RTL and a synthesised netlist — logically equivalent?).

The important caveat: formal does not "prove the chip correct." It reasons about the properties you specified, under the constraints you supplied, and capacity limits mean it is usually applied to blocks and specific problems rather than a whole SoC.

8.5 Lint, CDC and RDC

These are static checks — they analyse the RTL structurally, without running it.

• Lint flags suspicious or risky coding patterns: unintended latches, incomplete sensitivity, width mismatches, unreachable code, multi-driver nets.
• CDC (clock-domain crossing) analysis examines signals passing between unrelated clock domains. Such crossings can produce metastability and data-coherency failures that ordinary RTL simulation, with its idealised timing, may not expose at all.
• RDC (reset-domain crossing) applies the same reasoning to signals crossing between different reset domains.

The reason these exist as separate tools is precise: some structural risks are invisible to simulation, because simulation models behaviour under idealised timing while these problems are about physical timing relationships and asynchrony.

8.6 Emulation and FPGA prototyping

RTL simulation is thorough but slow. Booting an operating system on a simulated SoC can be impractically slow. Two approaches execute the design far faster:

They are not interchangeable. Emulation generally offers much better debug visibility and faster compile turnaround; FPGA prototypes generally run faster but are harder to debug and can require more effort to map a large design. Which a project uses — often both — depends on size, budget and schedule.

8.7 Pre-silicon validation, firmware and software

Beyond checking blocks, teams validate that the whole system behaves correctly — integration, realistic scenarios, and increasingly hardware/software interaction. Firmware and driver development frequently begins long before silicon exists, running against architectural models, simulation, emulators and FPGA prototypes. That is a major reason fast pre-silicon execution platforms are worth their cost: they let software start early and let hardware/software bugs surface before fabrication.

A terminology note: the boundary between "verification" and "validation" is not standardised across the industry. Many organisations use verification for did we build the design right and validation for does the system do the right thing, but usage varies, and job titles vary more.

9. Phase 6 — Synthesis and Constraints

Synthesis reads synthesisable RTL and produces a logic implementation — a netlist — for a target technology. Conceptually it understands the logic your RTL describes, optimises it, and maps it onto available resources: storage elements, combinational logic, and the clock and reset structures connecting them.

Synthesis needs more than RTL. Constraints tell it what to aim for — above all the clock definitions and target frequency, plus timing relationships at the design's boundaries and any paths that should be treated specially. Without constraints a tool has no definition of "fast enough."

Two things to hold on to: synthesis optimises, so it may restructure, merge, share or remove logic, and there is no one-line-to-one-gate mapping. What is preserved is the behaviour you described, not the shape you pictured.

10. ASIC or FPGA — Where the Path Branches

Up to here the two common targets look broadly similar: requirements, architecture, RTL, verification and the idea of synthesis all apply. After synthesis they diverge, because the target is fundamentally different.

10.1 The FPGA path

An FPGA flow runs RTL and verification much as an ASIC flow does, then: synthesis targeting the device's resources, mapping onto those resources, placement and routing within the device's fixed fabric, timing analysis against the device's characterised data, and finally a bitstream that configures the part. Those resources typically include lookup tables (LUTs), flip-flops, block memories, DSP/arithmetic blocks and I/O resources.

Because reconfiguring is cheap, FPGAs are used both as final products and, as §8.6 described, as prototyping platforms for designs destined to become ASICs.

11. DFT — Designing So the Chip Can Be Tested

Everything so far asked whether the design is right. Design for Test asks a completely different question: once this part has been manufactured, how do we tell whether it came out free of defects?

The problem is access. A fabricated chip contains an enormous amount of internal state that cannot be directly controlled or observed from its external pins. Manufacturing defects — a broken connection, a short — can sit deep inside and never be visible to a functional test running from the outside.

DFT inserts structure to fix that. At orientation level:

• Scan reconfigures the design's registers, in a test mode, into long shift registers called scan chains, so values can be shifted in and results shifted out.
• ATPG (Automatic Test Pattern Generation) computes the patterns to shift in, and the expected responses, to detect modelled defects.
• BIST (built-in self-test) puts test logic on the chip itself, commonly for memories.
• Test coverage measures what fraction of modelled defects the pattern set can detect.

The distinction that matters most:

Verification asks: did we design the behaviour we intended? Manufacturing test asks: was this particular physical part built without unacceptable defects?

A perfectly verified design still needs manufacturing test, because verification says nothing about whether one specific die came out of the factory intact. DFT is normally inserted around synthesis and implementation so the test structures are carried through to the finished part; exactly where varies by flow. The DFT track covers it properly.

12. Gate-Level Simulation

GLS runs a simulation on the netlist rather than on the original RTL. Because the netlist is what implementation and manufacturing actually build from, simulating it can expose issues the RTL simulation could not.

Orientation-level reasons a project may run GLS: checking reset and initialisation behaviour on the actual netlist, investigating X-propagation (how unknown values spread) where the netlist behaves differently from RTL, running timing-aware simulation with back-annotated delays in flows that require it, validating DFT structures, and satisfying specific methodology or signoff requirements.

Two honest caveats. GLS is much slower than RTL simulation, so it is typically run on a targeted subset rather than a full regression. And how heavily a project relies on it varies substantially by methodology, design type and organisation — it is not a universal fixed step. See anatomy of a netlist for the detail.

13. STA — Static Timing Analysis

Correct logic is not enough; signals must also arrive in time. STA analyses the design's timing paths against its constraints without needing functional stimulus to exercise them. That is what makes it powerful — it does not depend on writing a test that happens to activate the slowest path.

Its reach is defined by what it is given: the constraints, the timing models for the technology, the analysis modes and corners run, and any exceptions declared. Paths excluded by a constraint are not analysed, so a wrong constraint can hide a real problem — which is why constraints are reviewed as carefully as RTL.

The mental model is one path:

The vocabulary worth recognising: clocks and constraints define what is required; setup relates to a signal arriving early enough before a capturing edge, hold to it remaining stable long enough after one; path delay is how long the route actually takes; and slack is the margin between required and actual — negative slack means a violation.

STA is not a single event at the end. It runs iteratively — after synthesis, through physical implementation, and at signoff — because the timing picture becomes more accurate as the physical design becomes real. The equations belong to Timing Checks (Chapter 18) and Delay Modeling (Chapter 17).

14. Physical Design

Physical design turns a logical netlist into physical geometry — actual shapes, positions and wires on silicon. This is where a design stops being a structure and starts being a thing with dimensions.

• Floorplanning decides the overall arrangement: where large macros and memories sit, how regions are allocated, where I/O goes, how power is distributed.
• Placement positions the individual standard cells within that plan.
• Clock tree synthesis (CTS) builds the network that delivers the clock to every element that needs it, aiming to control skew.
• Routing creates the actual metal connections between everything placed.
• Extraction derives the physical parasitics — resistance and capacitance — from the real geometry, so timing and power analysis can move from estimates to something much closer to reality.

Timing analysis and optimisation run throughout this pipeline, not just after it.

15. Foundry, Process, PDK, Libraries and IP

Implementation is impossible without technology-specific information. The vocabulary:

What is delivered in a "PDK" versus separately as libraries varies between foundries and organisations; treat the boundary as a local convention rather than a fixed definition.

Modern chips also integrate a great deal of IP — pre-existing blocks rather than everything built from scratch. Soft IP is delivered as RTL you synthesise yourself; hard IP arrives as a pre-implemented block for a specific technology. IP may be developed internally or licensed from third parties. Either way, integrating it does not remove the need to verify it in your context.

16. Analog and Mixed-Signal

A chip is rarely purely digital RTL. Real products contain PLLs generating clocks, ADCs and DACs converting between analog and digital, high-speed PHYs for external interfaces, voltage regulators, sensors and custom I/O.

These are designed differently. Rather than RTL and synthesis, analog and custom design typically works through schematic-level circuit design, circuit simulation, and custom layout, followed by extraction and verification against the intended circuit. The representations and the tools are different from the digital flow.

Mixed-signal verification addresses the interface between the two worlds: digital RTL interacting with analog blocks. Because simulating detailed analog circuits alongside a large digital design is expensive, teams commonly use abstracted models of the analog behaviour — real-number modelling and languages such as Verilog-AMS are among the approaches used, though methodology varies considerably by organisation and by how much analog content a design carries.

The orientation point: an SoC is a multi-disciplinary object, and the digital flow this chapter describes is one part of it.

17. Signoff — Physical Verification, Power and Reliability

"Signoff" is not a button. It is the set of final engineering checks a project requires before releasing a design for manufacturing.

Physical verification asks whether the layout is legal and correct:

• DRC (design rule check) — does the physical layout obey the manufacturing rules for this process?
• LVS (layout versus schematic) — does the connectivity in the layout correspond to the intended circuit or netlist?

Power and reliability analyses ask whether a functionally and temporally correct design will actually survive in physical reality: power analysis, IR drop (voltage lost across the power delivery network), electromigration (long-term degradation of conductors carrying high current density), signal integrity including crosstalk between neighbouring wires, and thermal behaviour where relevant.

This is why "the logic is right and the timing closes" is not the finish line. Which checks a specific project requires, and where the bar sits, depends on the process, the product and the methodology.

18. Tapeout

Tapeout is the milestone at which the design database intended for manufacturing is released toward fabrication and mask preparation. The name is historical — data once shipped on magnetic tape — but the milestone is very real: it is the point at which changing the design stops being a code edit and starts being a new manufacturing cycle.

The thing worth internalising is the distance. Your RTL sits far upstream of this point, separated from it by verification, synthesis, DFT, physical design, timing closure and signoff. Tapeout is not "compiling your Verilog." It is the release of a fully implemented, verified and checked physical database.

19. Silicon — Fabrication, Bring-Up and Validation

After tapeout, manufacturing proceeds broadly through mask and process preparation, wafer fabrication, wafer-level test, packaging, and testing of the packaged devices.

Then first silicon arrives, and a different kind of engineering begins.

Bring-up is the first hours and days: power the part on, check basic health, get clocks and resets behaving, establish communication, bring up interfaces one at a time. Post-silicon validation then exercises the real device — firmware, real software workloads, real interfaces, performance and power measurement, behaviour at temperature and voltage corners, and stress conditions.

Post-silicon finds things pre-silicon could not, because the real device combines effects no model fully captured: analog behaviour, physical timing, power delivery, temperature, real software, and real external components. It does not replace pre-silicon verification — by the time a bug reaches silicon it is dramatically more expensive, and the fix may mean a firmware workaround or a future revision rather than a quick change.

19.1 Production test

Post-silicon validation and production test are different activities. Validation asks whether the product behaves correctly in real conditions — a question asked about the design, on a modest number of parts. Production test asks whether each manufactured part meets its criteria and is free of unacceptable defects — a question asked about every unit shipped, and it must be fast and cheap per part.

This is where §11 pays off: the scan chains and patterns inserted long before tapeout are exactly what makes economical production test possible. The loop closes.

20. Nothing Here Is a Waterfall

The phases are ordered, but the work is not. Real projects iterate constantly:

• a verification failure sends you back to RTL
• a timing failure may be addressed in RTL, synthesis, constraints or physical design depending on where the problem really is
• routing congestion can force changes to the floorplan, the synthesis strategy, or occasionally the architecture
• a post-silicon bug may become a firmware workaround, a future revision, or a documented limitation

A useful habit: the stage where a problem appears tells you something about what kind of problem it is. A simulation mismatch is a behaviour question. A timing violation is usually not a logic bug. A DRC error is a geometry question. Knowing the map means knowing where to look.

21. Words That Are Easy to Confuse

If you remember nothing else from this chapter, remember these.

22. Lifecycle Reference Map

A compact reference to return to.

23. Exercises

Reason these through before reading the answers.

Exercise 1 — The invisible crossing

RTL simulation passes cleanly, but the design carries signals between two unrelated clock domains without proper synchronisation. Which discipline is most likely to catch this, and why did simulation miss it?

Exercise 2 — Fast enough?

A synthesised design is functionally correct but cannot run at the target clock frequency. Which analysis exposes this, and which stages might the fix live in?

Exercise 3 — Software before silicon

Firmware must boot months before any chip exists. Which pre-silicon approaches could make that possible, and what is the trade-off between them?

Exercise 4 — Screening the parts

A fabricated chip must be screened for manufacturing defects on a production tester. Which earlier decision made that possible, and why could functional tests not simply be reused?

Exercise 5 — Layout is done

The layout is complete. Name the categories of check that should still happen before tapeout, and what each one is asking.

Exercise 6 — First silicon

The first parts arrive in the lab. What changes about the engineering compared with pre-silicon work?

Answers

Exercise 1. CDC analysis. Simulation missed it because ordinary RTL simulation models timing as idealised — clocks tick cleanly and signals settle instantly — whereas the real failure mode is metastability and data incoherency arising from genuinely asynchronous physical timing. This is a structural risk, so a structural tool that inspects crossings is the right instrument. Lint is related but broader; CDC targets this specifically.

Exercise 2. STA exposes it, by analysing the timing paths against the constraints rather than waiting for a test to happen to exercise the slowest one. The fix can live in several places: restructuring the RTL so less logic sits between registers, different synthesis effort or strategy, corrected constraints if the requirement was misstated, or physical design if the problem is where things ended up. Notably it is usually not a logic bug — the design does what it says.

Exercise 3. Architectural models (for example SystemC/TLM) can run very early, well before RTL is complete, but are abstract. Emulation runs the real RTL fast with strong debug visibility. FPGA prototypes run faster still and are well suited to real interfaces and long software workloads, but are harder to debug and take effort to map. The trade-off is consistently speed and realism against debug visibility and how early the platform is available.

Exercise 4. DFT inserted before tapeout — scan chains that make internal state controllable and observable, plus ATPG patterns generated against a defect model. Functional tests cannot substitute, because they exercise intended behaviour through external pins and cannot reach or observe most internal nodes; they are also far too slow and provide no measure of defect coverage. Production test must be fast, cheap per part, and measurable.

Exercise 5. At minimum: physical verification (DRC — is the layout legal for this process; LVS — does its connectivity match the intended netlist), final timing on the extracted physical design, and power and reliability checks such as IR drop, electromigration and signal integrity. Exactly which checks and what thresholds depend on the process, product and methodology — the list is not universal.

Exercise 6. Everything becomes real and less observable. Pre-silicon you can see every internal signal and rerun deterministically; post-silicon you have limited visibility through pins and test structures, and bugs may involve analog behaviour, physical timing, temperature, power delivery and real software interacting. The work shifts toward bring-up, characterisation across corners, and running real workloads — and a fix is now a firmware workaround or a future revision rather than an edit and a rerun.

24. Summary

A silicon product travels a long way from idea to working device, and your Verilog sits at one specific point on that road.

• Before RTL: requirements decide what to build, architecture decides the major pieces and the hardware/software split, and modelling — sometimes in SystemC at transaction level — explores the choices. Microarchitecture then decides how a block will work.
• RTL describes clocked hardware behaviour. Verilog is the language, SystemVerilog is the larger language containing it, and UVM is a verification methodology written in SystemVerilog. These three are not the same thing.
• Pre-silicon confidence comes from many angles because none alone is enough: simulation, assertions and coverage, formal, lint, CDC and RDC, and fast platforms like emulation and FPGA prototyping that also let software start early.
• Implementation turns behaviour into something physical: synthesis produces a netlist, DFT makes the part testable, physical design gives it geometry, and STA checks it is fast enough — iteratively, not once.
• Signoff asks whether it is legal and survivable — DRC, LVS, power and reliability — and tapeout releases the database for manufacturing.
• Silicon brings fabrication, bring-up, post-silicon validation, and production test, which is where the DFT work inserted much earlier finally earns its place.
• None of it is a waterfall. Every stage can send you backwards, and the stage where a problem appears tells you what kind of problem it is.

The point of the map is not memorisation. It is that when someone says "the CDC run flagged a crossing" or "we are waiting on GLS before signoff," you now know what they mean, roughly where it sits, and why it exists.

Chapter 3 returns to the box you will spend your career inside — RTL — and starts teaching it properly.

Related Tutorials

• Introduction & Overview — Chapter 1; what Verilog is and how to read it as hardware.
• RTL Designing — Chapter 3; the abstraction this chapter placed in the flow.
• Design and Testbench Creation — Chapter 9; how simulation is actually driven.
• Timing Checks — Chapter 18; where timing requirements are treated properly.
• Anatomy of a Netlist — what synthesis actually produced, in detail.