From Concept to Tapeout: The ASIC Design Flow, Step by Step

One of the questions I get most often: “what actually happens between an idea for a chip and a design that’s ready to manufacture?” This is that walkthrough — the engineering end of the flow, concept to tapeout, with every step broken out: why it exists, what it produces, how it does it, roughly how long it takes, and the industry-standard tools used. It stops where the design leaves engineering and goes to the foundry; what happens inside the fab is a separate story.

An ASIC (Application-Specific Integrated Circuit) is a chip built for one job, as opposed to a general-purpose part you program after the fact. Designing one is a long pipeline of specialized steps, and the flow forks into two tracks that run in parallel and converge at the end: a digital track that is highly automated and synthesis-driven, and an analog / custom track that is hand-crafted and simulation-driven. Most real chips are mixed-signal — they need both.

Below, each step lists why it exists, its goal, how it works, a typical duration, and the tools — referencing the four vendors that dominate production EDA (electronic design automation): Synopsys, Cadence, Siemens EDA (formerly Mentor Graphics), and Ansys.

How to read the step tags. Each step is marked serial (it can’t start until the previous one finishes — its input is the previous step’s output) or concurrent (it overlaps with its neighbors, run at the same time on the same design). The durations are rough figures for a moderately complex SoC and vary enormously with size, node, and team; a run of one tool takes hours, but the activity around it iterates for weeks. End to end, a complex chip is typically a 1–3 year program. A separate ISO 26262 ASIL B/D safety overlay — for chips that go into cars — runs alongside the whole flow; it’s covered at the end.

Phase 1 — Define

1. Specification and architecture

Serial · typically 1–6 months.

Why. Everything downstream is built against this. A wrong architectural choice — too little memory bandwidth, the wrong bus, an unrealistic clock target — is essentially free to fix here and catastrophically expensive to fix after tapeout. This is the highest-leverage step in the whole flow.

Goal. A specification precise enough to design against, and an architecture that will hit the PPA (power, performance, area) targets.

How. Architects turn a product idea into a concrete engineering spec: what the chip must do, its interfaces, its PPA budget, and how the work is partitioned into blocks. They explore trade-offs — how many cores, how much cache, which memory and I/O standards — usually against an executable model of the system (SystemC/TLM transaction-level models) so performance and power can be profiled before any RTL exists.

Tools. Architectural and virtual-platform modeling — Synopsys Platform Architect and Cadence system design and verification.

Phase 2 — Design and verify (the “front end”)

2. RTL design

Serial (starts the front end) · typically 2–9 months, overlapping verification.

Why. This is the human-authored heart of the chip. Every later step is a mechanical (or verified) transformation of this description; if the RTL is wrong, the silicon is wrong.

Goal. Synthesizable, lint-clean RTL that correctly implements the architecture.

How. Engineers describe the chip’s behavior in a hardware description language (HDL) — Verilog, SystemVerilog, or VHDL — at the register-transfer level (RTL), specifying what happens to data as it moves between registers on each clock edge. Static checks run continuously as they write: lint (style and bug patterns) and CDC (clock-domain-crossing analysis, which catches metastability hazards where signals pass between unrelated clocks).

Tools. Lint and CDC — Synopsys VC SpyGlass, Cadence, and Siemens EDA Questa.

Verification runs concurrently. The next three steps — simulation, formal, and emulation — are not sequential stages. They run in parallel with each other and overlap RTL design: as each block stabilizes, all three engines attack it at once, each answering a question the others can’t. Together they are usually the single largest effort in the whole project.

3. Simulation

Concurrent (with steps 2, 4, 5) · continuous through the front end; often 40–60% of project effort.

Why. Simulation is the workhorse that proves the RTL does what the spec says — and, just as important, does not do what it shouldn’t. A functional bug that escapes here becomes a silicon respin: months and millions.

Goal. High functional coverage — quantified evidence that the intended behaviors have actually been exercised — with zero failing checks.

How. The RTL runs against a testbench, usually built in UVM (the Universal Verification Methodology, a standardized SystemVerilog framework of drivers, monitors, scoreboards, and coverage). Modern DV is constrained-random: instead of hand-writing every case, the testbench generates randomized-but-legal stimulus and tracks coverage to see which scenarios have been hit. SVA (SystemVerilog Assertions) embed checks directly in the design so violations are caught the instant they happen.

Tools.Synopsys VCS, Cadence Xcelium, Siemens EDA Questa.

4. Formal verification

Concurrent (with steps 2, 3, 5) · days to weeks per property set.

Why. Simulation samples behavior with stimulus; it can only ever hit the cases you generate. Formal proves properties mathematically over all reachable states — so it catches corner cases no directed test would think to try. It’s the right tool for control logic, protocol correctness, and safety mechanisms.

Goal. Mathematically proven properties (or a concrete counter-example waveform when one fails), covering behaviors exhaustively rather than by sampling.

How. Properties are written as assertions and handed to a formal engine, which uses techniques like bounded model checking and k-induction to prove them over the design’s entire reachable state space, or produce the shortest trace that violates them.

Tools.Synopsys VC Formal and Cadence JasperGold.

5. Emulation and prototyping

Concurrent (with steps 2–4), begins once RTL is stable · brings up over weeks, then runs for months.

Why. A large SoC simulates at a handful of cycles per second — far too slow to boot an operating system or run real software. Emulation maps the RTL onto special-purpose hardware so it runs millions of times faster, which is the only practical way to exercise the whole system and to give firmware teams a target before silicon exists (the shift-left bridge, so software is ready on day one of bring-up).

Goal. Prove the assembled system runs — boots an OS/RTOS, executes driver and firmware stacks, survives long soak tests and real traffic — and get software validated pre-silicon.

How. The RTL is compiled onto an emulator (a large array of FPGAs or custom processors) or an FPGA prototype, then driven with real software and real interface traffic at near-hardware speed.

Tools.Synopsys ZeBu, Cadence Palladium, and Siemens EDA Veloce.

In short: simulation and formal prove the blocks are right; emulation proves the assembled system runs.

Where pre-verified IP saves you. Every block you buy already-verified is front-end effort you don’t repeat. Our safety soft-IP catalog ships each block with its FMEDA and a self-checking testbench, and our Verification IP provides independent, clean-room checkers to verify your own RTL against a genuine second source.

Phase 3 — Implement (the “back end” / physical design)

6. Logic synthesis

Serial · a run is hours to a day; the activity iterates over weeks.

Why. RTL describes behavior; a foundry builds gates. Synthesis is the bridge — and it’s where the first hard PPA optimization happens, because the same RTL can map to very different gate structures depending on the constraints.

Goal. A gate-level netlist that is logically equivalent to the RTL and meets the PPA targets.

How. The tool translates RTL into an interconnection of standard cells (pre- characterized gates and flip-flops from the foundry’s library), optimizing timing, area, and power against a formal timing-constraint file (SDC). Equivalence checking then proves the netlist still matches the RTL.

Tools.Synopsys Design Compiler and Fusion Compiler; Cadence Genus.

7. Design for test (DFT)

Serial (inserted around synthesis) · typically 2–6 weeks.

Why. Fabrication is imperfect — some dies come out defective. Without on-chip test structures there’s no economical way to tell a good die from a bad one, and defects ship to customers.

Goal. High test coverage so defective dies are caught and discarded after fabrication, protecting the quality of shipped parts.

How. The tool stitches flip-flops into scan chains (shift registers that load and observe test patterns), runs ATPG (Automatic Test Pattern Generation) to compute the patterns that expose faults, and inserts BIST/MBIST (built-in self-test, especially for embedded memories).

Tools.Synopsys TestMAX, Cadence Modus, and Siemens EDA Tessent.

Physical implementation is strictly serial. The next four steps — floorplanning, placement, clock tree synthesis, routing — happen in order, each consuming the previous step’s result, and (importantly) they run inside the same place-and-route tool. You don’t route before you’ve placed; you don’t place before you’ve floorplanned. They’re listed separately because each is a distinct optimization problem with its own goal — but they are one continuous, ordered database being refined, not four independent tools.

8. Floorplanning

Serial (P&R step 1 of 4) · days to ~3 weeks, highly iterative early on.

Why. The floorplan sets the stage for everything physical: get the big blocks or the power grid wrong and no amount of clever placement or routing later can recover the timing or the power delivery.

Goal. A chip-level arrangement in which every block fits, the aspect ratio and pin locations are sane, and power can be delivered cleanly.

How. The engineer decides where the major blocks, memories, and I/O sit, defines the power grid (the mesh of power/ground rails), and reserves routing and placement resources. This is the most human-guided of the physical steps.

Tools.Synopsys Fusion Compiler / IC Compiler II and Cadence Innovus — the same tool used for steps 9–11.

9. Placement

Serial (P&R step 2 of 4) · a run is hours to a day; iterate over days–weeks.

Why. Where each cell sits determines how long its wires are, and wire length dominates delay and power at modern nodes. Placement quality sets the ceiling on the timing the design can ultimately close at.

Goal. A legal, timing-aware placement of every standard cell that leaves the design routable.

How. The tool positions hundreds of thousands to billions of standard cells to minimize wire length and timing cost while obeying density and congestion limits, running incremental timing optimization as it goes.

Tools. Same place-and-route tool as step 8 — Synopsys Fusion Compiler / IC Compiler II, Cadence Innovus.

10. Clock tree synthesis (CTS)

Serial (P&R step 3 of 4) · hours to a couple of days per run.

Why. Every flip-flop needs the clock to arrive at nearly the same instant. Uncontrolled clock arrival (skew) directly eats into the timing budget and can break the chip outright.

Goal. A balanced clock-distribution network that reaches every flip-flop with minimal skew and acceptable insertion delay and power.

How. The tool builds a physical tree (or mesh) of buffers and inverters that distributes the clock, balancing path delays to equalize arrival times, then re-optimizes timing around the now-real clock.

Tools. Same place-and-route tool as steps 8–9.

11. Routing

Serial (P&R step 4 of 4) · one to several days per run; iterate over weeks.

Why. This is where the design becomes physically complete — every logical connection becomes actual metal. It’s also where late timing, signal-integrity, and manufacturability problems concentrate.

Goal. Every net connected in real metal, with no design-rule violations and timing still met.

How. The router connects all cells with wires across the chip’s many metal layers, inserting vias between layers, honoring spacing/width rules and the timing and signal-integrity constraints, and repairing violations iteratively.

Tools. Same place-and-route tool as steps 8–10.

Post-route analysis and sign-off is an iterative loop. The next steps — extraction, timing, power, and signal integrity — all read the routed layout, and a fix demanded by one (say, a timing repair) changes the inputs to the others, so the design loops through them repeatedly until everything closes at once.

12. Parasitic extraction

Serial input to sign-off (loops with 13–15) · hours per run.

Why. At modern nodes the wires themselves — their resistance and capacitance — dominate delay and power. Signing off on estimated wire models would be signing off on a fiction.

Goal. Accurate electrical (RC) models of the physical interconnect, so every downstream sign-off reflects the real layout.

How. The extractor measures the resistance and capacitance of every routed wire and via from the layout geometry and the process stack, producing an annotated model (SPEF) that feeds timing, power, and SI analysis.

Tools.Synopsys StarRC and Cadence Quantus.

13. Static timing analysis (STA)

Iterative sign-off (loops with 12, 14, 15) · a run is hours; iterate across the whole back end.

Why. The chip must run at its target frequency not just nominally, but at the slow-cold and fast-hot extremes of manufacturing and use. Checking that by simulation would be hopeless; STA does it exhaustively without simulation.

Goal.Timing closure — every path proven to meet setup and hold across all conditions.

How. STA walks every signal path and checks its setup/hold margins over multiple PVT corners (process, voltage, temperature) and operating modes, using the extracted parasitics for accuracy. Failing paths are fed back to placement/routing/CTS for repair.

Tools.Synopsys PrimeTime — the long-standing sign-off standard — and Cadence Tempus.

14. Power, IR-drop and electromigration

Iterative sign-off (loops with 12, 13, 15) · hours to days per run.

Why. A chip that meets timing can still fail if it can’t be powered correctly — the grid sags, the metal erodes, or it overheats. These are lifetime-reliability and correctness issues, not nice-to-haves.

Goal. A power-delivery network and thermal profile that keep every transistor inside its safe operating envelope for the life of the product.

How.Power analysis covers dynamic, static, and leakage power; IR-drop analysis checks the grid voltage doesn’t sag too far under load; electromigration (EM) checks current density won’t erode the metal over time; thermal analysis checks temperature. Power intent is captured formally in a UPF (Unified Power Format) file describing domains, switching, and isolation.

Tools.Ansys RedHawk-SC for power integrity, IR-drop, and EM; Cadence Voltus; Ansys Totem for the analog side.

15. Signal integrity (SI)

Iterative sign-off (loops with 12–14) · hours per run.

Why. Densely packed wires switching fast couple into each other. Uncontrolled crosstalk adds delay or injects glitches, silently breaking a design that “passed” nominal timing.

Goal. Signals that arrive clean and on time despite dense, coupled interconnect.

How. SI analysis quantifies crosstalk-induced delay and noise and feeds the effect back into timing; on high-speed I/O it extends to full electromagnetic channel modeling.

Tools. Analyzed within the timing/PI sign-off tools above, with electromagnetic modeling from Ansys (HFSS / SIwave) for the toughest high-speed channels.

16. Mixed-signal integration

Serial (the two tracks merge here) · weeks, when the chip has analog content.

Why. Most real chips aren’t purely digital. The digital and analog/custom blocks (see the analog track below) are designed separately and must be assembled and verified together — a class of bug (level mismatches, missing connections, timing between domains) that neither track finds alone.

Goal. A single, correctly-assembled chip in which analog and digital behave together as specified.

How. The blocks are integrated and verified with AMS (analog/mixed-signal) co- simulation and real-number modeling (fast digital-style models of analog behavior) so the whole system can be exercised at speed.

Tools.Cadence Virtuoso AMS and Synopsys Custom Compiler / PrimeSim.

17. Physical verification — DRC, LVS, and friends

Serial (the gate before sign-off) · a run is hours; closing all violations takes days–weeks.

Why. This is the last line of defense before committing millions to masks. It proves two things the foundry absolutely requires: that the layout can be built, and that what you’re about to build is what you designed.

Goal. A layout that is provably manufacturable and provably matches the intended netlist.

How.DRC (Design Rule Check) verifies every geometric foundry rule (spacing, width, density, and hundreds more). LVS (Layout Versus Schematic) proves the layout is electrically identical to the netlist. Antenna checks guard against charge damage during fabrication, ERC catches connectivity errors, and DFM tightens yield.

Tools.Siemens EDA Calibre is the de facto sign-off standard; Synopsys IC Validator and Cadence Pegasus are the other production options.

Phase 4 — Sign-off and tapeout

18. Sign-off

Serial convergence gate · typically 2–8 weeks of looping.

Why. Any single green check is meaningless if another is red — the chip has to satisfy every constraint simultaneously, on the same final database. Sign-off is where all the iterative analyses are forced to agree at once.

Goal. A design that meets every specification and every manufacturing requirement, with the evidence to prove it.

How. Every check — timing (STA across all corners), power and IR, EM, SI, DRC, LVS, antenna, test coverage — must be green together, with the final extracted parasitics. Because a fix in one domain can break another, teams loop until everything closes at once.

Tools. The sign-off engines from steps 12–17, run to convergence.

19. Tapeout — the GDSII handoff

Serial (the end of the engineering flow) · days.

Why. The foundry needs one unambiguous, complete database to build from. Tapeout is the formal handoff of that database — the point of no return before mask costs are committed.

Goal. A complete, verified, foundry-ready database.

How. The final layout is streamed out as a GDSII (or newer OASIS) file — the industry-standard format the foundry consumes — together with the test patterns and documentation. A final full-chip DRC/LVS confirms the streamed database is clean.

Tools. Streamout from the P&R tool plus a final Calibre (or IC Validator / Pegasus) run.

Inside the fab — mask making, lithography, etching, deposition, packaging — is a separate discipline this article doesn’t cover; see our companion piece on process geometry for the technology those steps build. But engineering doesn’t end at tapeout: weeks to months later the first physical chips come back, and the flow picks up again on the bench.

Phase 5 — First silicon and post-silicon validation

Tapeout hands off a database; some weeks later the foundry returns first silicon — a handful of the first real chips. Now the engineering shifts from proving the design on models to proving the physical part behaves, in the lab. This is where the value of everything upstream — especially verification and DFT — is finally cashed in.

20. Bring-up

Serial · days to ~2 weeks.

Why. Before any detailed testing, you have to establish that the part has basic life — otherwise you’re debugging a brick. Everything else in Phase 5 depends on this succeeding.

Goal. Get from “powered” to “executing real code and talking to the outside world” — the first proof the silicon is fundamentally sound.

How. Power the first chips on a bring-up board and check the essentials: clocks running, reset and power sequencing correct, the boot ROM executing, the lowest-level interfaces responding. Because emulation (step 5) let firmware be developed ahead of silicon, the software to exercise the chip is usually ready and waiting.

Tools. Bench instruments — power supplies, oscilloscopes, logic and protocol analyzers — plus the pre-built firmware.

21. Silicon validation and debug

Serial · weeks to months.

Why. Some bugs only appear on real silicon at real speed — exactly the workloads that were too slow to simulate. Finding and precisely characterizing them decides whether the fix is cheap (software or a metal-layer ECO) or expensive (a full respin).

Goal. Confirm the design works on real silicon, and characterize any bug precisely enough to choose the cheapest correct fix.

How. Systematically exercise every function at real speed — running the software stacks, driving every interface, replaying the workloads simulation couldn’t reach. When something misbehaves, silicon debug uses on-chip debug and trace, the DFT scan chains from step 7, and lab instruments to localize the cause. Bugs are triaged into software-fixable, metal-layer ECO (a small change to a few upper masks, far cheaper than a remake), or full respin.

Tools. On-chip trace/debug, DFT scan (Tessent / TestMAX / Modus), and lab instruments.

22. Characterization

Serial · weeks.

Why. The datasheet numbers a product is sold on — its real operating margins across voltage, temperature, and frequency — have to be measured, not assumed. This is where margin becomes known rather than hoped-for.

Goal. Prove the silicon meets spec across the whole operating envelope, and establish the margins and datasheet numbers.

How. Measure behavior across the full range of conditions, not just nominal. The classic method is the shmoo plot: sweeping two parameters (say voltage vs. frequency) and mapping the pass/fail boundary. Power, timing margins, analog performance, and yield-limiters are all characterized here.

Tools.ATE (automated test equipment) and bench instruments.

23. Production test

Serial to set up, then ongoing · program development is weeks; per-part test is seconds.

Why. Every single chip that ships must be screened, cheaply and fast, so defective dies never reach a customer. This is the payoff for the DFT investment in step 7.

Goal. A production screen that ships good parts and rejects bad ones, at a test time cheap enough for volume.

How. Each fabricated chip is tested on ATE using the patterns generated in step 7 — the scan/ATPG vectors and BIST routines — to screen out manufacturing defects.

Tools.Automated test equipment (Advantest, Teradyne) running the DFT pattern set.

Closing the loop

Post-silicon findings feed back upstream: characterization data refines the models used on the next design, silicon bugs sharpen the verification plan, and pre-silicon emulation models are correlated against measured silicon so future projects start from a trusted baseline. Getting working silicon on the first attempt — first-pass success — is the goal the entire flow is built to achieve, because every respin costs months and millions.

The analog / mixed-signal track

Everything above describes the automated digital flow. Analog and custom blocks — PLLs, SerDes, ADCs/DACs, bandgaps, high-speed I/O PHYs — are designed very differently, because their behavior lives in continuous voltages and currents, not logic levels, and can’t be synthesized from an HDL. This track runs in parallel with the digital one and merges into it at step 16.

Schematic capture — the analog designer draws the transistor-level circuit by hand.
SPICE simulation — the circuit is simulated with a SPICE-class analog solver at the transistor level, across PVT corners and Monte-Carlo device variation.
Custom layout — the physical layout is hand-crafted, because analog performance depends on matching, symmetry, and parasitics that automated placement won’t respect.
Analog physical verification — the same DRC/LVS gate applies.

The two tracks meet at mixed-signal integration (step 16), where full-chip DRC/LVS then signs off the combined layout.

Tools. Analog design and layout — Cadence Virtuoso and Synopsys Custom Compiler. SPICE simulation — Cadence Spectre and Synopsys PrimeSim / HSPICE. Transistor-level power/reliability — Ansys Totem.

Digital vs analog design tracks

Optional overlay — the ISO 26262 ASIL B/D safety flow

If the chip goes into a car — or any system where a malfunction can hurt someone — the standard flow above is necessary but not sufficient. ISO 26262 (“Road vehicles — Functional safety”) requires a parallel set of activities that run alongside every phase, each producing its own evidence, all assembled into a safety case. None of these steps replaces anything above; they overlay it, and most of the work is concurrent with the standard flow (concurrent safety engineering).

The rigor scales with the ASIL (Automotive Safety Integrity Level), from A (least) to D (most stringent). ASIL B and ASIL D are the two common targets; the quantitative bars a hardware design must clear differ sharply between them:

Metric	What it means	ASIL B	ASIL D
SPFM (single-point fault metric)	fraction of faults covered by a safety mechanism or safe by design	≥ 90%	≥ 99%
LFM (latent-fault metric)	fraction of undetected faults that a second mechanism still catches	≥ 60%	≥ 90%
PMHF (probabilistic metric for random hardware failures)	residual dangerous-failure rate, in FIT (failures per 10⁹ h)	< 100 FIT	< 10 FIT

The ISO 26262 ASIL B/D safety overlay

Each overlay activity below notes where it hooks into the standard flow.

S1. Item definition, HARA and safety goals

Hooks into step 1 · concurrent, weeks.Why: you can’t design for safety until you know what “unsafe” means for this part. How: the HARA (Hazard Analysis and Risk Assessment) identifies hazards and rates each on severity, exposure, and controllability — which determines the ASIL — and yields the top-level safety goals. Tools:Ansys medini analyze; requirements management (e.g. IBM DOORS).

S2. Safety requirements (functional → technical → hardware)

Hooks into steps 1–2 · concurrent.Why: safety goals are too abstract to build against; they must be refined into implementable requirements. How: each goal becomes functional safety requirements, then technical safety requirements, then concrete hardware safety requirements allocated to specific blocks — a traceable chain from hazard to RTL. Tools: requirements management + medini analyze.

S3. Safety mechanisms in the RTL

Hooks into step 2 · concurrent with RTL design.Why: the metrics in the table above are only reachable if the design actively detects and reacts to faults. How: designers add safety mechanisms — ECC/SECDED on memories and buses, lockstep (dual-core DCLS) comparison, parity/CRC, TMR/voting, LBIST/MBIST, watchdogs, register protection, and an error-collection/reaction unit (FCCU-style) that drives the chip to a safe state. Tools: the standard RTL flow (step 2) — this is exactly the content our safety soft-IP ships pre-built.

S4. FMEDA — the quantitative safety analysis

Hooks across steps 2–6 · concurrent, iterative.Why: ISO 26262 doesn’t take “we added ECC” on faith — it demands numbers. How: the FMEDA (Failure Modes, Effects, and Diagnostic Analysis) enumerates every failure mode, assigns base failure rates (from handbooks such as SN 29500 or IEC 62380), credits each safety mechanism with a diagnostic coverage, and rolls the result up into SPFM, LFM, and PMHF to check them against the ASIL targets in the table. Tools:Ansys medini analyze.

S5. FMEA, FTA and dependent-failure analysis (DFA)

Hooks into the architecture (steps 1–2) · concurrent.Why: the FMEDA assumes faults are independent; real chips have common-cause and cascading failures (a shared clock, supply, or physical region taking out “redundant” logic together). How:FMEA (bottom- up), FTA (top-down fault trees), and DFA (dependent-failure analysis) hunt for mechanisms that defeat redundancy, driving mitigations like physical separation and diverse redundancy. Tools: medini analyze; Isograph.

S6. Fault-injection campaign

Hooks into verification (steps 3–5) · concurrent.Why: the diagnostic-coverage numbers the FMEDA claims have to be proven — a mechanism credited with 99% coverage that actually achieves 70% invalidates the whole safety case. How: faults are systematically injected into the RTL/gate model (stuck-at, transient/SEU) during simulation or on the emulator, and the campaign measures how many the safety mechanisms actually detect — the measured coverage that validates (or refutes) the FMEDA. Tools:Synopsys Z01X, Cadence fault simulation (Xcelium Safety / Midas), Siemens Tessent SafetyScope / Austemper.

S7. Tool qualification and confirmation reviews

Hooks throughout · concurrent.Why: if a tool that generates or checks safety-relevant output has a bug, it can mask a real defect — so the tools themselves must be trusted, and the work independently reviewed. How: each tool is qualified per ISO 26262-8 (assessed for a tool confidence level), and independent confirmation reviews and a functional-safety audit check the work products. Tools: vendor tool-qualification kits; independent assessors.

S8. Safety case assembly

Hooks in before sign-off/tapeout (step 18) · concurrent, finalized late.Why: all the evidence above is worthless if it isn’t assembled into a coherent, auditable argument that the part is safe. How: the safety case collects the HARA, requirements traceability, FMEDA, DFA, fault-injection results, and reviews, together with a safety manual (the “assumptions of use” the integrator must honor) and, for licensed IP, a DIA (Development Interface Agreement) splitting safety responsibilities between supplier and integrator. Tools: medini analyze; document/requirements management.

This overlay is most of what “safety IP” actually means. When we say our catalog ships safety-ready, we mean each block arrives with S3–S8 already done: the safety mechanisms are in the RTL, the FMEDA is computed against the ASIL target, the fault-injection campaign has validated the diagnostic coverage, and the safety manual and DIA are written. That’s the months of ISO 26262 work you don’t repeat per block. See circuit-design.space.

MPW: a cheaper path for small chips and prototypes

Making the photomask set for a chip is enormously expensive — the single biggest fixed cost of a tapeout, and it’s the same whether you make ten chips or ten million. For a small design, a prototype, or an academic project, that’s prohibitive.

A multi-project wafer (MPW), also called a shuttle run, solves it: many independent designs share one wafer and one mask set, and split the cost. You get a modest number of packaged prototype dies for a fraction of a dedicated run. Shuttle programs are offered by foundries and brokers (for example Europractice, MOSIS, and imec), and it’s the standard way to prove a chip in silicon before committing to volume production — where a dedicated mask set finally makes economic sense.

The design flow above is identical for an MPW; only the manufacturing arrangement and cost structure change.

Where verified IP fits in

Two phases dominate schedule and risk: verification (Phase 2) and physical closure (Phase 3) — and for automotive parts, the ISO 26262 overlay on top of both. The fastest way to compress all of it is to not re-originate what you can license already-proven.

That’s what we build: a catalog of safety soft-IP — synthesizable blocks that ship with their functional-safety work products already done — and Verification IP to check your own RTL against an independent second source. Each block carries its own FMEDA, safety manual, and self-checking testbench, so it drops into the flow above as a finished element rather than one you have to design, verify, and safety-qualify from scratch. See circuit-design.space.

Glossary

AMS — Analog/Mixed-Signal. Co-simulation and modeling that verifies analog and digital blocks together.

ASIC — Application-Specific Integrated Circuit. A chip built for a specific function.

ASIL — Automotive Safety Integrity Level (A–D). ISO 26262’s risk classification; D is the most stringent, and it sets the quantitative safety targets a design must meet.

ATE — Automated Test Equipment. The tester that screens each fabricated chip in production using the DFT patterns.

ATPG — Automatic Test Pattern Generation. Computes the test vectors that expose manufacturing faults.

BIST / MBIST — (Memory) Built-In Self-Test. On-chip logic that tests the chip (or its memories) without external equipment.

Bring-up — Powering and validating the first physical chips in the lab.

Characterization — Measuring silicon behavior across voltage, temperature, and frequency (e.g., via shmoo plots).

CDC — Clock-Domain Crossing. Analysis of signals passing between unrelated clocks, to prevent metastability failures.

CTS — Clock Tree Synthesis. Building a balanced clock-distribution network with minimal skew.

Constrained-random — A verification style where the testbench generates randomized but legal stimulus, rather than hand-written directed tests.

Coverage (functional / code) — Metrics of how much of the design’s intended behavior a test suite has actually exercised.

DFA — Dependent-Failure Analysis. Hunting for common-cause and cascading failures that defeat redundancy (shared clock, supply, or physical region).

DFM — Design for Manufacturability. Layout adjustments that improve yield.

DFT — Design for Test. Structures (scan, BIST) added so fabricated chips can be tested.

DIA — Development Interface Agreement. The ISO 26262 contract splitting safety responsibilities between an IP supplier and the integrator.

Diagnostic coverage — The fraction of a component’s dangerous faults that a safety mechanism actually detects.

DRC — Design Rule Check. Verifies the layout obeys the foundry’s geometric manufacturing rules.

DV — Design Verification. The discipline of proving the RTL is functionally correct.

ECC / SECDED — Error-Correcting Code / Single-Error-Correct, Double-Error-Detect. A safety mechanism that detects and corrects bit errors in memory and buses.

ECO — Engineering Change Order. A late, localized fix; a metal-layer ECO changes only a few upper masks, far cheaper than a full remake.

EDA — Electronic Design Automation. The software tools used to design chips.

EM — Electromigration. Metal erosion from high current density over time; checked to ensure lifetime reliability.

Emulation — Running the design on special hardware for massive speed-up over software simulation.

FIT — Failures In Time: one FIT is one failure per 10⁹ operating hours. The unit for PMHF and base failure rates.

FMEDA — Failure Modes, Effects, and Diagnostic Analysis. The quantitative ISO 26262 analysis that computes SPFM, LFM, and PMHF.

Formal verification — Mathematically proving design properties over all reachable states, rather than sampling with stimulus.

FTA — Fault Tree Analysis. Top-down analysis tracing a hazardous event back to its contributing faults.

Fault injection — Deliberately inserting faults into the model to measure how many a safety mechanism actually detects, validating the FMEDA’s claimed coverage.

GDSII / OASIS — The industry-standard layout database formats handed to the foundry.

HARA — Hazard Analysis and Risk Assessment. Identifies hazards and rates them, determining the ASIL and the safety goals.

HDL — Hardware Description Language (Verilog, SystemVerilog, VHDL).

IR-drop — Voltage sag across the power grid under current load.

ISO 26262 — The automotive functional-safety standard governing electrical/electronic systems in road vehicles.

Leakage — Static power dissipated by transistors even when not switching.

LFM — Latent-Fault Metric. The fraction of undetected faults still caught by a second mechanism; an ISO 26262 hardware metric.

Lint — Static analysis of RTL for style issues and bug patterns.

Lockstep — Running two copies of a core in parallel and comparing them, a safety mechanism that detects faults by mismatch.

LVS — Layout Versus Schematic. Proves the physical layout matches the intended netlist electrically.

Netlist — A gate-level (or transistor-level) description: which cells connect to which.

PMHF — Probabilistic Metric for random Hardware Failures. The residual dangerous-failure rate (in FIT) an ISO 26262 design must stay under.

PPA — Power, Performance, Area. The three primary optimization targets.

Parasitic extraction (RC) — Measuring the resistance and capacitance of routed wires for accurate analysis.

PDK — Process Design Kit. The foundry’s package of rules, models, and libraries for a given process node.

Physical design / P&R — Place-and-Route: turning a netlist into placed, routed physical geometry.

Post-silicon validation — Proving and characterizing the real fabricated chip in the lab, after tapeout.

PVT corners — Process, Voltage, Temperature combinations at which the design must be verified (e.g., slow-cold, fast-hot).

Power intent / UPF — Unified Power Format: a formal description of power domains, switching, and isolation.

Respin — Re-fabricating the chip after a bug fix; the costly outcome a good flow avoids.

RTL — Register-Transfer Level. The abstraction at which digital designs are coded: data moving between registers each clock.

Safe state — A defined condition the chip is driven to when a fault is detected, so the fault doesn’t propagate to a hazard.

Safety case — The assembled, auditable body of evidence arguing that a design is acceptably safe.

Safety mechanism — On-chip logic (ECC, lockstep, watchdog, parity…) that detects or controls faults so they don’t cause a hazard.

Setup / hold — The two fundamental timing constraints a signal must satisfy relative to the clock edge.

Shift-left — Doing verification/software work earlier (e.g., via emulation) so problems surface before silicon.

Shmoo plot — A pass/fail map over two swept parameters (e.g., voltage vs. frequency) used in characterization.

Signal integrity (SI) — Analysis of crosstalk and coupling between fast-switching wires.

Silicon debug — Localizing a bug on real silicon using on-chip trace, DFT scan, and lab instruments.

Simulation — Executing the design model against a testbench to observe behavior.

Skew — Difference in clock arrival time between points in the design.

SPFM — Single-Point Fault Metric. The fraction of faults covered or safe-by-design; an ISO 26262 hardware metric.

SPICE — The transistor-level analog circuit simulator class.

STA — Static Timing Analysis. Exhaustive, simulation-free timing verification.

Standard cell — A pre-characterized logic gate or flip-flop from the foundry’s library.

SVA — SystemVerilog Assertions. In-design checks that continuously assert intended behavior.

Synthesis — Translating RTL into a gate-level netlist.

Tapeout — Handing the final verified layout database to the foundry; the end of the engineering flow.

Timing closure — Achieving a design that meets all timing constraints across all corners.

TLM / SystemC — Transaction-Level Modeling; used for fast architectural exploration.

UVM — Universal Verification Methodology. The standard SystemVerilog framework for building reusable testbenches.