Extras

Tool landscape

Nobody draws a chip by hand. Software does almost every step, from checking the idea to drawing the final chip. This page shows which programs do which job, who makes them, and what free tools can already build.

Every step of designing a chip, from checking that the design behaves correctly to drawing the final layout, runs on software called electronic design automation (EDA). Here is a step-by-step map of the paid commercial tools and the free open-source projects, the shared file formats that let them work together, and how teams choose between them.

The details behind tool choices: why factories approve only certain final-check tools, what the open-source stack built around OpenROAD can and can’t do today, the file formats that let teams mix vendors, and how modern layout tools keep the whole design in one shared in-memory database.

Stage by stage

The tool map

  1. 01Specification

    Open source

    • DoorstopRequirements stored as YAML files in version control, with traceability checks and publishing.
    • Sphinx-NeedsRequirements, specs and test cases as linked objects inside Sphinx documentation.
    • PeakRDLTurns a SystemRDL register-map spec into register RTL, C headers, IP-XACT and docs.

    Commercial

    • Engineering Requirements Management DOORS NextIBM
    • Polarion ALMSiemens
    • Jama ConnectJama Software
    • IDesignSpecAgnisys
  2. 02Architecture

    Open source

    • gem5Modular simulator for system architecture and processor microarchitecture studies.
    • SystemC reference implementationAccellera’s C++ library for transaction-level and cycle-level hardware models.
    • Timeloop / AccelergyModels performance, energy and area of accelerator dataflows and mappings.

    Commercial

    • Platform ArchitectSynopsys
    • VisualSim ArchitectMirabilis Design
    • MATLAB and SimulinkMathWorks
  3. 03RTL design

    Open source

    • VeribleSystemVerilog parser with style linter, formatter and language server.
    • Verilator (lint mode)Fast structural lint of Verilog and SystemVerilog with --lint-only.
    • ChiselScala-embedded hardware construction language that generates Verilog through FIRRTL.
    • sv2vConverts SystemVerilog to Verilog-2005 for tools with limited SystemVerilog support.

    Commercial

    • VC SpyGlassSynopsys
    • Questa LintSiemens EDA
    • Ascent LintReal Intent
    • Stratus HLSCadence
    • Catapult HLSSiemens EDA
  4. 04Verification

    Open source

    • VerilatorCompiles Verilog and SystemVerilog into a fast multithreaded C++ or SystemC model.
    • Icarus VerilogEvent-driven Verilog compiler and simulator.
    • cocotbWrite testbenches in Python that drive a running HDL simulator.
    • SymbiYosys (SBY)Front end for Yosys-based formal checks: bounded and unbounded proofs, cover, liveness.

    Commercial

    • VCSSynopsys
    • XceliumCadence
    • QuestaSiemens EDA
    • JasperCadence
    • VC FormalSynopsys
    • PalladiumCadence
    • ZeBuSynopsys
    • VeloceSiemens EDA
  5. 05Logic synthesis

    Open source

    • YosysRTL synthesis framework: elaboration, optimization and mapping to a Liberty cell library.
    • ABCBerkeley’s logic optimization and technology-mapping engine, called by Yosys and OpenROAD.
    • EQYYosys-based equivalence checking between RTL and gate-level netlists.

    Commercial

    • Design CompilerSynopsys
    • Fusion CompilerSynopsys
    • GenusCadence
    • FormalitySynopsys
    • ConformalCadence
  6. 06Design for test

    Open source

    • OpenROAD dftScan insertion: replaces flops with scan cells and stitches scan chains.
    • FaultOpen-source DFT toolkit from the American University in Cairo: test-pattern generation (ATPG) for netlists and scan-chain stitching.

    Commercial

    • TessentSiemens EDA
    • TestMAXSynopsys
    • ModusCadence
  7. 07Floorplanning

    Open source

    • OpenROAD (ifp, ppl, mpl)Die and core setup, rows and tracks, I/O pin placement and macro placement.
    • OpenRAMPython SRAM compiler that generates the layout, netlist, Liberty and LEF views of memory macros.

    Commercial

    • InnovusCadence
    • IC Compiler IISynopsys
    • Fusion CompilerSynopsys
    • AprisaSiemens EDA
  8. 08Power planning

    Open source

    • OpenROAD pdnBuilds power rings, straps, rails and via stacks from a grid specification.
    • OpenROAD psm (PDNSim)Static IR-drop and current-density analysis of the power grid.

    Commercial

    • InnovusCadence
    • IC Compiler IISynopsys
    • VoltusCadence
    • RedHawk-SCSynopsys (Ansys)
  9. 09Placement

    Open source

    • OpenROAD gpl / dplRePlAce-based global placement, legalization and detailed placement.
    • DREAMPlaceResearch placer that runs analytical placement on GPUs through a deep-learning toolkit.

    Commercial

    • InnovusCadence
    • IC Compiler IISynopsys
    • Fusion CompilerSynopsys
    • AprisaSiemens EDA
  10. 10Clock tree synthesis

    Open source

    Commercial

    • InnovusCadence
    • IC Compiler IISynopsys
    • Fusion CompilerSynopsys
    • AprisaSiemens EDA
  11. 11Routing

    Open source

    Commercial

    • InnovusCadence
    • IC Compiler IISynopsys
    • Fusion CompilerSynopsys
    • AprisaSiemens EDA
  12. 12Signoff

    Open source

    • OpenSTAGate-level static timing analysis from Verilog, Liberty, SDC and SPEF.
    • OpenRCXParasitic extraction from routed layout to SPEF.
    • KLayoutLayout viewer and editor with scriptable DRC and LVS engines.
    • MagicClassic layout editor with interactive DRC and netlist extraction.
    • NetgenNetlist comparison for layout-versus-schematic (LVS).

    Commercial

    • PrimeTimeSynopsys
    • TempusCadence
    • StarRCSynopsys
    • QuantusCadence
    • CalibreSiemens EDA
    • IC ValidatorSynopsys
    • PegasusCadence
    • RedHawk-SCSynopsys (Ansys)
    • VoltusCadence
  13. 13GDS & tapeout

    Open source

    • KLayoutReads and writes GDSII and OASIS; merges, XOR-compares and inspects final layouts.
    • MagicReads and writes GDSII; used by open flows for final layout checks.
    • gdstkC++/Python library for creating and manipulating GDSII and OASIS files.

    Commercial

    • CalibreSiemens EDA
    • ProteusSynopsys
    • CATSSynopsys

Why tools matter

A big modern chip holds tens of billions of tiny switches called . That’s more than the number of people on Earth. Nobody could draw them all by hand. So engineers write down what the chip should do, and software does most of the drawing and checking. That software is called , short for electronic design automation.

There are two kinds of tools. Commercial tools come mostly from three big companies, and you pay to use them. Open-source tools are free, and anyone can read and change their code. Open tools have already been used to make hundreds of real chips.

(electronic design automation) is the category of software for designing and checking chips and circuit boards. Its programs work together as a design flow, each one doing one job and handing its result to the next.

The chain starts with code. Engineers describe what the chip does in a hardware description language such as Verilog, at a level called (register-transfer level): which values are stored, and how they are computed from one tick of the chip’s clock to the next. The tools then turn that code into a (a list of logic gates and the wires between them), decide where each gate sits on the silicon, draw the wires, and check the result. A complete flow takes four kinds of input, each in a standard file format: the RTL code, the timing goals (an SDC file, for example “this clock ticks every 2 ns”), the factory’s catalog of ready-made gates with their speed and power (a Liberty file), and the size and layer rules of those gates and the process (LEF files). Its output is a GDSII file, the drawing of every shape on every layer that the factory turns into masks.

Tools decide what a team can build, and how fast. The OpenROAD project, a large open-source effort, started from the observation that hardware innovation was held back by complex and expensive tools, a shortage of experts who can drive them, and high cost and risk. The map above lists, for each stage, open-source projects (linked) and well-known commercial products (named). Most real chip projects mix tools from several vendors, a practice called “best of breed.”

“The tools” means three layers, and it helps to separate them.

  1. Engines do the work: the placer (decides where each gate goes), the router (draws the wires), the timer (adds up delays along every path and compares them with the clock), the extractor (works out the resistance and capacitance of each drawn wire), and the DRC engine (checks every shape against the factory’s geometry rules).
  2. A runs the engines in order with scripts, and stops the run when a quality check between steps fails.
  3. Enablement ties both to one manufacturing process: the , the rule decks (scripts that tell a checking tool what the factory’s rules are), the characterized cell libraries (timing and power measured for each gate), and technology files.

Tool choice is constrained most by the third layer. The OpenROAD team found that parts of foundry enablement are encrypted and can be read only by tools the foundry has qualified, and that the workarounds needed qualified commercial tools, run by companies holding licenses from both the tool vendor and the foundry.

Foundries qualify specific tools for their processes, and many publish : lists of recommended tools and versions, with scripts to move data between them. Commercial and open tools also aim at different targets. Andrew Kahng, of the OpenROAD project, puts it plainly: commercial EDA chases the best possible (power, performance and area) at the newest processes, while OpenROAD aims for ease of use and push-button automation, “two different universes.”

The open side has an explicit long-term goal. OpenROAD set out to deliver tools that can take a design all the way to manufacturing, in source form under permissive licenses, to seed what its authors called a future “Linux of EDA,” and to cut the cost, expertise and risk barriers that keep system designers away from custom silicon.

RTLSynthesisPlacementRoutingSignoffGDSIIcurrent form:RTL codemodule counter( input clk, output reg [3:0] n); always @(posedge clk) n <= n + 1;endmodule
1 / 6

The designer writes RTL in Verilog. The flow also takes the timing goals (SDC), the gate catalog (Liberty) and the layer rules (LEF).

A design flow: each program does one job and passes its output to the next. A small generic design, not to scale.Share freely with credit: ‘Figure from chipfieldguide.com’

The commercial landscape

Three companies sell most chip design software: Synopsys, Cadence and Siemens. Each sells a big family of programs. A team can do nearly the whole job with one company’s tools. Smaller companies sell programs for single jobs.

The factory that builds the chip, called the foundry, cares most about the checking tools. A wrong answer from a checker could mean a chip that doesn’t work. Making it again costs months and millions of dollars. So many foundries publish a list of checking tools they trust, and many teams follow it.

Commercial EDA is concentrated in three vendors. Siemens bought Mentor Graphics in 2017 and renamed it Siemens EDA in 2021. Each vendor sells a suite that spans the flow. Some familiar names, by job:

  • Simulation and formal verification (running the design in software on test inputs, or proving mathematically that it can never break a stated rule): Synopsys VCS and VC Formal, Cadence Xcelium and Jasper, Siemens Questa.
  • Synthesis (turning the code into a netlist of gates): Synopsys Design Compiler and Fusion Compiler, Cadence Genus.
  • Place and route (placing the gates on the chip and drawing the wires): Cadence Innovus, Synopsys IC Compiler II and Fusion Compiler, Siemens Aprisa.
  • Signoff (the final checks before manufacturing): Synopsys PrimeTime and StarRC, Cadence Tempus and Quantus for timing and for measuring the electrical effect of the wires; Siemens Calibre, Synopsys IC Validator and Cadence Pegasus for checking the shapes against the factory’s rules (DRC) and against the netlist (LVS).
  • Test (adding circuitry that lets each manufactured chip be tested): Siemens Tessent, Synopsys TestMAX, Cadence Modus.

tools get special treatment. Only a small set count as , meaning their answer is accepted as final, and a checking tool’s accuracy can only be proven once chips come back from the factory. Testing a new tool independently is expensive and risky, so only the largest design companies do much of it. Many foundries therefore publish naming recommended tools and versions.

Inside one vendor’s suite, the layout engines usually share a single in memory, so a change made by one engine is seen by the others at once. That makes tight optimization loops possible; the last section of this page explains how.

Kahng and Spyrou describe the EDA business model (licensing, pricing, support) and its structure (three dominant vendors) as focused on large contracts with a small number of enterprise customers. They describe government and defense users as underserved by traditional EDA companies, and smaller organizations and teams with niche needs (reliability, security, unusual device technologies) as natural users of open tools.

Foundry qualification is the strongest force in the market, and it is more than a name on a list. The foundry’s rule decks for DRC and LVS, and its technology files for wire extraction, are written in the formats of specific tools; an open PDK such as IHP’s, for example, ships its rules for KLayout and Magic. On commercial processes some of that collateral is encrypted. In the OpenROAD project, universities could not be foundry-qualified, so they could not read it, and calibrations had to be run with qualified commercial tools by companies licensed by both the tool vendor and the foundry. A team that leaves the qualified set takes on that correlation work itself: showing, design after design, that its tool’s answers match the ones.

Inside a suite, the selling point is integration. Since the early 2000s, every commercial place-and-route tool has used an incremental shared-netlist architecture, so synthesis-style changes (resizing a gate, adding a buffer) can be made and re-timed during placement and routing. Integration is also why a team that mixes vendors tends to switch at a clean handoff point, such as layout in one vendor’s tool and signoff in another’s, where the design is written out in standard files anyway.

SynopsysCadenceSiemensVerificationVCS +Xcelium +QuestaSynthesisDesign Compiler +Genus–Place & routeIC Compiler II +InnovusAprisaTiming + RCPrimeTime +Tempus +–DRC / LVSIC ValidatorPegasusCalibreDFTTestMAXModusTessent

Pick one tool for each job to build a toolchain.

Commercial suites by job, using the products this section names (a dash means none is named here, not that none exists). Pick one tool per job.Share freely with credit: ‘Figure from chipfieldguide.com’

The open-source ecosystem

Free tools now cover the whole path from an idea to the final chip drawing. One program, Yosys, turns the written plan into a list of simple logic parts. Another, OpenROAD, places those parts on the chip and draws the wires. Others test that the design works or check the drawing against the factory’s rules. Ready-made scripts run them all in the right order, like a recipe.

Some real factories have also given away their rulebooks for free. Each rulebook is called a . It says which shapes are allowed and how the factory’s switches behave.

Front end: from code to gates

The front end of chip design covers writing the code, testing it, and turning it into gates.

  • Yosys does logic synthesis: it reads the Verilog code, simplifies the logic, and maps it onto the gates available in the factory’s library, producing a . For the hardest part of that job it calls ABC, a logic optimization system from UC Berkeley.
  • Verilator tests the design by simulation. It converts the Verilog into a C++ program that behaves like the chip, then compiles and runs it, so its authors call it a compiler more than a traditional simulator. Icarus Verilog also compiles Verilog for simulation; it aims to cover the whole standard Verilog language, plus a growing part of SystemVerilog, its larger successor.
  • lets engineers write the (the code that feeds the design inputs and checks its outputs) in Python. It runs a Python interpreter inside the simulator, connected through the simulator’s standard programming interfaces.
  • SymbiYosys runs : instead of trying test inputs one by one, it uses solvers to prove that a stated rule (an assertion, such as “a full buffer never accepts new data”) holds, either for a fixed number of clock cycles or for all time.

Back end: from gates to layout

The back end turns the netlist into a physical layout and checks it.

  • OpenROAD is a single application, BSD-licensed and driven from Tcl or Python scripts. It plans the chip’s area (floorplanning), places the gates, builds the (the wiring that delivers the clock signal to every storage element at nearly the same moment), routes the wires, and finishes the layout. It includes OpenSTA for timing and OpenRCX for extraction (computing each wire’s resistance and capacitance from its drawn shape).
  • OpenSTA does : it adds up the delay along every path between storage elements and reports any path too slow for the clock. It is controlled with Tcl commands and reads the netlist (Verilog), the cell library (Liberty), the timing goals (SDC) and the extracted wire data (SPEF).
  • KLayout views and edits layouts in GDSII, OASIS and LEF/DEF, and runs scripted (checking every shape against the factory’s rules) and (checking that the drawn layout matches the intended netlist).
  • Magic, written at Berkeley in the 1980s, is still a widely used layout editor with built-in rule checking, and Netgen compares netlists for LVS.

Flows

A flow is the script that runs all these tools in order. OpenROAD-flow-scripts (ORFS) runs Yosys synthesis, the OpenROAD steps, and KLayout to write the final GDSII and run DRC and LVS. It ships ready-made setups for several processes: asap7, nangate45, sky130, gf180 and ihp-sg13g2. OpenLane combined OpenROAD, Yosys, Magic, Netgen, KLayout and other tools into one flow. It is now in maintenance mode, and its maintainers point new designs to its successor, LibreLane, a Python library for building flows.

Open PDKs

A (process design kit) is the factory’s package of rules, models and ready-made parts for one manufacturing process, and it is what lets these tools target a real factory. Three are public: SkyWater SKY130 (130 nm, from Google and SkyWater), GF180MCU (180 nm, from Google and GlobalFoundries) and IHP SG13G2 (130 nm, from the German research institute IHP). All three use the Apache 2.0 license. The IHP kit shows what a full PDK contains: libraries of logic gates (), input/output cells and memory blocks, each with a drawing (GDSII), an outline for placement (LEF), timing and power data (Liberty) and a Verilog model; DRC and LVS rule files for KLayout and Magic; and transistor models for circuit simulators.

Maturity varies by engine, and each engine’s history explains much of it. OpenSTA is the open-sourced Parallax timer, which was sold commercially for nearly two decades and built into more than a dozen companies’ timing tools. It remains dual-licensed: GPL v3 as OpenSTA, and commercially by Parallax. Its README adds that, unlike many open projects, it is not supported by a public community of developers; Parallax alone holds the copyright and does the development.

OpenRCX and OpenDB both came from code written at Athena Design Systems, a 2000s EDA startup. OpenRCX has been validated on 14, 28, 65 and 130 nm foundry processes. Timing computed from its output by OpenSTA, compared endpoint by endpoint with a commercial extractor and timer on a 12 nm design, stays on the pessimistic side: it reports less slack (timing margin) than the commercial flow does, which is the safe direction. Magic dates to the 1980s Berkeley tools, and Netgen’s author describes version 1.5 as competitive with commercial-grade LVS.

Coverage is thinnest outside the core RTL-to-GDS path. In 2020, community requests to OpenROAD included (test circuitry), functional simulation and a DRC/LVS engine, all beyond the project’s scope. On the map above, open DFT comes down to scan insertion in OpenROAD and test-pattern generation in Fault. Open signoff has timing, extraction, DRC and LVS, but none of these engines is a foundry-qualified tool: OpenROAD’s own developers listed physical verification, extraction and timing as signoff tools their program would not build.

The open process kits split two ways. SKY130, GF180MCU and IHP SG13G2 describe real processes that factories run, and all three carry preview labels. ASAP7 is a realistic 7 nm research PDK with no factory behind it; its design rules mimic advanced patterning, which makes it useful for studying how the tools cope with leading-edge rules.

Licenses differ across the stack, and they matter to companies that ship or embed tools. OpenROAD and the ORFS scripts are BSD 3-Clause. LibreLane is Apache 2.0. OpenSTA is GPL v3, and Parallax also licenses it for commercial products without the GPL’s requirements. cocotb is BSD-licensed, and the three open PDKs are Apache 2.0. Using these tools to design a chip raises few questions. The difference matters when a company links an engine into its own product: a permissive license (BSD, Apache) lets it keep its code closed, while a copyleft license (GPL) requires it to publish the combined source if it distributes the result.

verifysynthesislayoutDRC / LVSVerilatorIcaruscocotbSBYYosys+ ABCOpenROADOpenSTAOpenRCXKLayoutMagicNetgenORFSLibreLaneSKY130 · GF180MCU · IHP SG13G2flow scriptsopen PDKs

Tap a block to see what each tool does.

The open-source stack along the RTL-to-GDS path: front end (left), back end (right), the flow scripts that run them, and the open PDKs they target.Share freely with credit: ‘Figure from chipfieldguide.com’

What open tools can tape out today

Open tools make real chips. More than 600 designs laid out with OpenROAD have been built in real factories. Projects like Tiny Tapeout let a student or hobbyist put a small design on a shared chip.

There are limits. The free rulebooks are for older chip technology. Its parts are many times bigger than those in a new phone. Their makers still call them previews. The newest chips use paid tools and private rulebooks. Open tools are best for learning, research, test chips and simple products.

A is the moment a finished layout is sent to the factory to be made. Open tools have reached it many times.

OpenROAD tapeouts in SKY130 and GF180
600+
Open PDK process sizes
130–180 nm
Open PDKs with a production label
0 of 3

The first SKY130 tapeout with OpenLANE, a flow built on OpenROAD, was Efabless’s striVe system-on-chip (a processor plus memory and peripherals on one die) in May 2020. An early Google–Efabless SKY130 shuttle carried more than 40 designs completed with OpenROAD tools, and the count has since passed 600 across SKY130 and GF180. A (multi-project wafer) shares one set of masks and one batch of wafers among many designs, which cuts the cost for each. Tiny Tapeout runs shuttles of very small designs on IHP, SKY130 and GF180 processes.

What fits: digital blocks and small systems-on-chip at 130–180 nm; mostly analog chips whose digital part, a few thousand gates, is too big to draw by hand; and IHP’s process, which adds fast bipolar transistors for radio-frequency (RF) circuits. What doesn’t, yet: production at advanced processes. All three open PDKs are labeled preview or experimental, meant for test chips and early design work. Open tools also run on some private commercial PDKs. In 2020 OpenROAD produced layouts that passed all physical, electrical and timing checks in TSMC 65 nm and GlobalFoundries 12 nm processes, including a 12 nm chip handed to the factory. These were research proof points.

A typical open path to silicon

  1. Write the design in Verilog and test it by simulation in Verilator or Icarus Verilog, with the tests written in Python using cocotb.
  2. Synthesize it with Yosys into a netlist of the PDK’s gates, using the PDK’s Liberty timing files.
  3. Run ORFS or LibreLane to take the netlist through floorplanning, placement, clock tree and routing in OpenROAD.
  4. Check timing with OpenSTA, and check the layout’s shapes (DRC) and connectivity (LVS) with KLayout, or with Magic and Netgen.
  5. Submit the GDSII file to a shared shuttle, such as a Tiny Tapeout run.

The open PDK is as much the gate as the tools. An open kit ships its rule decks in formats open tools can run (IHP provides KLayout DRC and LVS rules and Magic technology files), so signoff can stay open from end to end. On a commercial process, the same flow meets collateral covered by non-disclosure agreements and sometimes encrypted. The OpenROAD team built its early floorplanning and power-grid tool around user-written configuration files that described safe metal and via geometry, precisely to work around foundry files academic tools could not read. And because it had no golden signoff tools, the flow guardbanded: it added margin so that its results would be “correct and safe by construction” whatever the final checks found, at a cost in power, performance and area.

A realistic mixed pattern follows: open implementation, then qualified commercial signoff. The OpenROAD project itself separated its tool developers from “design advisors,” who ran commercial tools to verify results and calibrations. OpenROAD supports several closed commercial PDKs, and its GF12LP proof points, including a single-core version of the BlackParrot system-on-chip, passed all physical verification, electrical and timing checks.

Kahng’s 2020 assessment of who will use open back-end tools was blunt. Product teams at the leading edge never will, because only commercial EDA chases the best results at the latest processes; and academic teams with cheap commercial licenses have little reason to. The likely users are open hardware projects, teaching, research, small or underserved teams, mostly analog chips with a little digital logic, and cases where security or trust requires full ownership of the toolchain.

open PDK: SKY130 · GF180MCU · IHP SG13G2Write + testSynthesizeImplementCheckTape outtools:Verilator · Icarus · cocotb
1 / 5
PDK

Write Verilog and simulate it in Verilator or Icarus Verilog, with cocotb tests in Python.

A typical open path to silicon, from the section’s five steps. Switch the PDK to see what changes on a private commercial process.Share freely with credit: ‘Figure from chipfieldguide.com’

How tools talk: formats and scripting

Tools from different companies can share work because they agree on file types. It’s like shipping containers: any ship can carry them, and any port can unload them. The chip’s plan is written in a language called Verilog. The final drawing goes to the factory as a file called GDSII. In between, a handful of other shared file types carry the work from tool to tool.

Engineers rarely click through these programs by hand. They write short scripts, which are lists of typed commands. That way the same steps run the same way every time. A script is like a recipe the computer follows exactly.

Tools from different vendors can work on the same design because they read and write the same standard file formats. Each format carries one kind of information:

FormatCarriesTypical handoff
Verilog / SystemVerilogThe design’s code (RTL), and later the gate-level Designer → simulation, synthesis; synthesis → layout, timing
(.lib)Each library cell’s logic function, delay and powerCell library → synthesis, layout, timing
/ LEF: the process’s layers and each cell’s outline and pins. DEF: where every cell and wire sits in this designPDK → layout tool; layout tool → extraction, checks
Timing goals: clock speeds, when inputs arrive, paths to ignoreDesigner → synthesis, layout, timing
Each wire’s resistance and capacitance, extracted from the layoutExtractor → timing, power analysis
Power plan: which blocks can be switched off, and what protects their neighbors when they areDesigner → simulation, synthesis, layout
/ The final layout: every shape on every layerLayout tool → DRC/LVS checks → factory

OpenSTA, for example, reads Verilog, Liberty, SDC, SDF (pre-computed delays) and SPEF. LEF describes the process technology and the library of cell outlines, and DEF describes the physical layout of one design: its placement and routing. KLayout reads GDSII, OASIS and LEF/DEF, so it can open the layouts that place-and-route tools write.

Scripting is the other half of working together. is the common command language of chip design tools; Magic’s author, John Ousterhout, also wrote Tcl. OpenSTA and OpenROAD take Tcl commands, and OpenROAD also accepts Python. LibreLane is written in Python, and cocotb tests are Python. The two short scripts below show the shape of an open flow’s first steps. They are illustrative, and the library and file names are generic.

synth.ys (illustrative Yosys script)tcl
read_verilog -sv top.v
synth -top top
dfflibmap -liberty cells_typ.lib
abc -liberty cells_typ.lib
opt_clean
write_verilog -noattr top_synth.v
  1. 1L1Read the design’s code. -sv allows SystemVerilog features.
  2. 2L2Generic synthesis: work out the logic, simplify it, and express it in Yosys’s own internal gates.
  3. 3L3Replace each storage element (flip-flop) with the matching cell from the library’s Liberty file.
  4. 4L4ABC maps the remaining logic onto the library’s gates, choosing cells to meet timing.
  5. 5L6Write the gate-level netlist, the handoff to place-and-route.
place.tcl (illustrative OpenROAD script)tcl
read_lef tech.lef
read_lef cells.lef
read_liberty cells_typ.lib
read_verilog top_synth.v
link_design top
read_sdc top.sdc
initialize_floorplan -utilization 60 -aspect_ratio 1.0 -core_space 10 -site CoreSite
global_placement -density 0.7
detailed_placement
report_checks -path_delay max
write_def top_placed.def
  1. 1L1Technology LEF: the metal layers, the vias between them, and the placement grid.
  2. 2L2Cell LEF: the outline and pin positions of every library cell.
  3. 3L5Connect the netlist to the library cells so every gate has its size and timing.
  4. 4L6The same timing goals synthesis used, so both tools aim at the same target.
  5. 5L7Make a square chip area with cells covering 60% of it, leaving room for wires.
  6. 6L8Spread the cells out, keeping connected cells close, at up to 70% local density.
  7. 7L9Snap each cell onto a legal row position with no overlaps.
  8. 8L10OpenSTA, inside the same program, reports the slowest path against the clock.
  9. 9L11DEF hands the placed design to any tool that reads it.

Formats carry data, but each tool implements its own subset of what the data means. Early OpenROAD synthesis handled only “a subset of commonly-used SDC commands.” So a team that mixes vendors keeps its timing constraints in the subset every tool supports, and checks that each tool reads them the same way. The usual check is to load the same netlist and constraints into both tools and compare their timing reports path by path: a clock or exception that one tool silently ignored shows up as a path with very different slack.

File handoffs also lose information. An early academic flow chained separate programs, each with its own LEF/DEF reader and writer, and passed data between steps through files or by matching names. OpenROAD removed those duplicate readers and writers by moving every engine onto one database. OpenDB’s data model follows LEF/DEF 5.6, and it adds a binary format that saves and loads much faster than the text files. In a mixed flow, each tool reads the shared files through its own parser, so every vendor boundary is a good place for an (a formal proof that two netlists compute the same logic) and a timing comparison.

DesignerwritesPDK / cellsSimulationSynthesiswritesLayoutExtractionDRC / LVSTimingPowerFactoryVerilog: highlighted tools write or read it
Format

Verilog / SystemVerilog: the design’s code (RTL), and later the gate-level netlist. Designer → simulation, synthesis; synthesis → layout, timing.

Standard formats and the handoffs that carry them, from the section’s table. Pick a format to see its writer and readers.Share freely with credit: ‘Figure from chipfieldguide.com’

How teams choose tools

Teams pick tools by asking a few plain questions:

  • Will the factory trust the results? Checkers on the factory’s list are the safe choice.
  • What does it cost? Paid tools cost a lot. Free tools still need computers and people’s time.
  • Who helps when something breaks? Companies sell help. Open projects have communities of users who answer questions.
  • Can it run on its own? Tools that take scripts can run every night with nobody watching.

A student learning chip design often starts with free tools. A company building a big chip buys paid tools. It may still use free ones for quick tests.

Will the factory accept the results?

For the final checks (), the foundry’s usually decides. For the earlier steps, building and testing the design, there is more freedom, because the independent signoff check at the end catches what earlier tools get wrong.

Cost: licenses and computers

A commercial caps how many copies of a tool can run at once. OpenROAD has no up-front license cost. Its authors note that thousands of complete runs can be gathered in a few hours on rented cloud machines; they did this to compare flow settings for ibex, a small open-source processor. With open tools, the limit becomes how many computers you can pay for.

Support

Vendors provide application engineers and bug fixes under contract. Open projects rely on public issue trackers and on community members who can provide support, changes or enhancements. Paid support for open tools exists too: Parallax licenses OpenSTA commercially, and the ORFS project thanks Precision Innovations for providing and supporting ready-built OpenROAD programs.

Does the PDK support it?

A tool is only useful if the factory’s kit supports it: the PDK has to ship its libraries in formats the tool reads, and rule files written for it. IHP’s open kit, for example, provides LEF and Liberty views plus DRC and LVS rules for KLayout and technology files for Magic. On commercial processes, some files are written for, or encrypted for, the foundry’s approved tools, which narrows the choice before any comparison is run.

Scripting and repeatability

Every serious flow is scripted, so a tool needs a stable command interface ( or Python) and reports a program can read. Teams also want the same inputs to give the same result next month. LibreLane, for example, is built to be reproducible, and it saves a snapshot of the design and its settings after every step.

Selection is a portfolio decision, made separately for each part of the flow. Signoff follows the foundry’s qualified set, because the foundry’s rule files target those tools and some are readable only by them. Layout tools are judged on (power, performance and area of the result), runtime, the largest design they can handle, and how closely their internal estimates match what the signoff tools later report. OpenROAD’s published correlation study (OpenRCX plus OpenSTA against a commercial flow on a GF12LP design) is the kind of evidence to ask for from any tool, open or commercial.

Evaluating a tool on your own designs

  1. Pick two or three representative blocks. Include one that is congestion-limited (so many wires compete for the same area that routing is the hard part) and one that is timing-limited (the clock target is hard to meet).
  2. Run the candidate and the current tool from the same netlist, SDC and floorplan, so differences come from the engines and not the inputs.
  3. Sign off both results with the same golden timer, extractor and DRC/LVS rules. Each tool’s own reports measure how optimistic it is as much as how good its result is.
  4. Compare the candidate’s internal timing with the golden timing, endpoint by endpoint (each endpoint is a storage element or output where a timing path ends). A tool that stays on the pessimistic side, as OpenROAD reports for its GF12LP correlation, is safer to steer timing fixes with: paths it calls passing should pass signoff too.
  5. Record runtime, peak memory, and license or compute cost per run, because these decide how many iterations fit in a schedule.

economics shape methodology as much as budget. License counts limit how many analysis corners run in parallel, how much exploration fits overnight, and whether renting extra cloud machines at peak times helps. Kahng argues that open-source EDA’s low adoption cost and cloud scalability suit early design-space exploration and pathfinding, the phase where a team tries many architectures and settings before committing, which needs many runs. Academic teams are a counterexample: cheap commercial licenses leave them little reason to switch.

Other drivers: control and trust (some users need to own and inspect the whole toolchain, for example for radiation-hardened or trusted chips), the ability to design and manufacture without signing IP agreements or explaining the design to vendors, and customization, since open code can be changed for a niche need. Against these sit vendor support, the best PPA at the leading edge, and the foundry ecosystem around commercial suites. Support for open engines also varies: OpenSTA, for instance, is developed by Parallax alone rather than by a public community. Many teams end up with a mixed toolchain: commercial layout and signoff for products, and open tools for verification infrastructure, exploration, teaching and research. cocotb, for one, reports many serious commercial users and sponsors.

VerificationOpendecided by:costExplorationOpendecided by:costLayoutOpendecided by:PDK supportSignoffOpendecided by:PDK support
Team

Tap a part of the flow to see the deciding question.

Tool choice is made per part of the flow. The picks restate this section’s text for three typical teams; real teams vary.Share freely with credit: ‘Figure from chipfieldguide.com’

Under the hood: one database, many engines

This part goes deeper, into the math, models and algorithms behind the chapter. It’s written for the Expert level.

Modern layout tools are built around a and an incremental timer, one that recomputes only the delays a change affects. OpenROAD describes its architecture in open papers, so it serves as the example here.

From file-chained tools to one program

OpenROAD’s 2019 alpha release chained separate programs. RePlAce placed the cells, TritonCTS built the clock tree, a modified BoxRouter did global routing (assigning each wire to a coarse region) and TritonRoute did detailed routing (drawing the exact tracks), with the routers reading LEF and the placed DEF from files. Kahng lists the “table stakes” for attracting users, including a unified tool covering the full flow and a shared-netlist architecture for tight incremental optimization loops. Nearly 20 projects were then integrated into a single program on OpenDB. Duplicate LEF/DEF readers and file- or name-based communication between steps went away, and every engine now works through OpenDB’s C++ and Tcl interfaces.

The database

OpenDB began at Athena Design Systems; Nefelus open-sourced it under the BSD 3-Clause license in 2019 for OpenROAD. Its structure follows LEF/DEF 5.6, it saves to a binary format, and it has Tcl and Python interfaces. OpenAccess, a similar and widely used database, was ruled out because the project had to release permissively licensed code. More than a year went into finding a database before Athena’s code was open-sourced.

Incremental shared netlist

The integrated tool implements the incremental shared-netlist architecture that commercial place-and-route tools have used since the early 2000s. Step by step:

  1. A shared netlist adapter lets synthesis, placement, clock tree synthesis, post-placement optimization and the timer all modify one netlist.
  2. When synthesis changes the netlist, place-and-route receives a callback.
  3. When placement moves a cell, or routing changes a wire, a physical-data adapter records the change.
  4. The timer listens for both kinds of change, and its delay calculation uses the updated locations and wire data.

Kahng and Spyrou call this “the heart of optimization in a modern RTL-to-GDS tool,” able to evaluate thousands of resizing or incremental moves per second. OpenSTA is tied directly to OpenDB, so an optimizer that resizes gates sees both the timing graph (every gate and wire as a node or edge with its delay) and the physical data.

Resizerown readerPlacerown readerRouterown readerTimerown reader.v .deftiming graph (illustrative)press Try one buffer
Architecture

Separate programs, joined by files. Press Try one buffer.

One optimization attempt, two architectures, after the section’s callout. The 20-gate graph is illustrative; real designs have millions, which is why file round trips lose.Share freely with credit: ‘Figure from chipfieldguide.com’

The flow layer and metrics

Above the engines sits orchestration. ORFS wraps OpenROAD in a scripted, autonomous RTL-to-GDSII flow that still allows step-by-step control through Tcl and Python. LibreLane is a Python library for composing flows from steps, built to be hermetic (each step’s inputs and outputs are captured) and reproducible, and it can drive commercial tools as well as open ones. To support machine learning, OpenROAD standardized the names and meanings of its metrics across tools. Metrics are extracted from the logs into JSON, so results from thousands of runs can be collected and compared. That fits the original DARPA brief: “no human in the loop” tools and flows with a 24-hour turnaround.

Check yourself

Novice · 0 of 4 correct

  1. Q1Which file format is the spec sheet for each ready-made building block (cell) in a library: what logic it computes, how long it takes and how much power it uses?

  2. Q2In a typical open-source flow, which tool does logic synthesis, turning the design’s code into a list of connected logic gates?

  3. Q3What does cocotb let an engineer do?

  4. Q4The open PDKs SKY130, GF180MCU and IHP SG13G2 are all labeled what by their publishers?

Sources

Show Hide 25 sources
  1. Electronic design automationWikipedia contributors · WikipediaDefinition of EDA; tools work together in a design flow; Siemens acquired Mentor in 2017 and renamed it Siemens EDA in 2021.
  2. Signoff (electronic design automation)Wikipedia contributors · Wikipedia“Golden” signoff-quality tools; accuracy known only after fabrication; best-of-breed mixing across vendors; independent evaluation costly; foundry reference methodologies listing recommended tools and versions.
  3. Toward an Open-Source Digital Flow: First Learnings from the OpenROAD ProjectT. Ajayi, V. A. Chhabria, M. Fogaça, et al. · DAC 2019 (author-hosted, UCSD VLSI CAD Lab) · 2019Barriers of cost, expertise and risk; flow inputs (Verilog, SDC, Liberty, LEF); OpenSTA’s commercial lineage; universities not foundry-qualified and unable to read encrypted enablement; no golden signoff tools, so heavy guardbanding; “no human in the loop” and 24-hour goals.
  4. The OpenROAD Project: Unleashing Hardware InnovationAndrew B. Kahng, Tom Spyrou · GOMACTech 2021 (author-hosted, UCSD VLSI CAD Lab) · 2021Incremental shared netlist with callbacks; OpenRCX origin and correlation; GF12LP and TSMC 65LP proof points; three dominant vendors; no up-front license cost; closed commercial PDK support; ASAP7; metrics in JSON.
  5. Open-Source EDA: If We Build It, Who Will Come?Andrew B. Kahng · IFIP/IEEE VLSI-SoC 2020 (author-hosted, UCSD VLSI CAD Lab) · 2020Nearly 20 projects integrated into one binary on OpenDB; file-based handoffs eliminated; OpenAccess ruled out by licensing; design advisors run commercial tools; who will and will not use open-source EDA.
  6. OpenROAD (repository README)The OpenROAD Project · GitHubRTL-to-GDS application with Tcl and Python APIs; BSD 3-Clause license; over 600 tapeouts in SKY130 and GF180.
  7. OpenDB (odb)The OpenROAD Project · OpenROAD documentationPhysical design database from Athena Design Systems, open-sourced by Nefelus in 2019; data model based on LEF/DEF 5.6; binary save format; Tcl and Python APIs.
  8. OpenROAD-flow-scripts (repository README and platforms)The OpenROAD Project · GitHubAutonomous RTL-GDSII flow: Yosys synthesis, OpenROAD implementation, KLayout GDS and DRC/LVS; platforms include asap7, nangate45, sky130, gf180 and ihp-sg13g2; BSD 3-Clause scripts; prebuilt binaries from Precision Innovations.
  9. OpenLane (repository README)The OpenROAD Project / Efabless · GitHubRTL-to-GDSII flow combining OpenROAD, Yosys, Magic, Netgen, CVC, SPEF-Extractor and KLayout; in maintenance mode, with LibreLane as its successor.
  10. LibreLane (repository README)LibreLane contributors · GitHubPython library for building ASIC implementation flows from open-source and commercial tools; based on OpenLane 2; hermetic, with snapshots at every step; reproducible; Apache 2.0 license (.nix files MIT).
  11. What is YosysYosysHQ · Yosys documentationOpen-source framework for RTL synthesis; logic optimization and gate mapping with ABC; used for FPGA flows and for the synthesis step of open ASIC flows.
  12. ABC: A System for Sequential Synthesis and VerificationBerkeley Logic Synthesis and Verification Group · UC BerkeleyProject page for the ABC logic synthesis and verification system: AIG-based optimization and technology mapping to standard cells.
  13. OpenSTA (repository README)Parallax Software (James Cherry) · GitHubGate-level static timing verifier with a Tcl interpreter; reads Verilog, Liberty, SDC, SDF, SPEF, VCD/SAIF; GPL v3 plus commercial licensing; not supported by a public developer community.
  14. KLayoutMatthias Köfferlein · klayout.deReads GDS2, OASIS, LEF/DEF and more; DRC and LVS scripts; layout XOR and diff.
  15. Magic VLSI layout toolTim Edwards · Open Circuit DesignWritten at Berkeley in the 1980s by John Ousterhout, who also wrote Tcl; Berkeley open-source license; popular with universities and small companies.
  16. Netgen netlist comparison (LVS)Tim Edwards · Open Circuit DesignLVS netlist comparison; version 1.5 described as competitive with commercial-grade tools; part of the Tcl-based suite with Magic.
  17. Verilator overviewVerilator contributors · Verilator documentationCompiles Verilog/SystemVerilog into a multithreaded C++ or SystemC model; a compiler more than a traditional simulator.
  18. Icarus Verilog (repository README)Stephen Williams and contributors · GitHubCompiles IEEE 1364 Verilog and a growing subset of SystemVerilog; a compiler that generates code for back-end tools rather than a traditional simulator.
  19. cocotb documentationcocotb contributors · cocotbCoroutine-based cosimulation testbench environment; embeds Python in the simulator through VPI, VHPI or FLI; BSD license; many commercial users and sponsors.
  20. SymbiYosys (sby) documentationYosysHQ · YosysHQ documentationFront-end driver for Yosys-based formal verification: bounded and unbounded safety, cover, liveness.
  21. SkyWater SKY130 PDK (repository README)Google and SkyWater Technology · GitHubOpen-source 130 nm PDK under Apache 2.0; experimental preview, not intended for production use.
  22. GF180MCU PDK (repository README)Google and GlobalFoundries · GitHub (archived repository)Open-source PDK for GlobalFoundries’ 180 nm MCU process; Apache 2.0; experimental preview.
  23. IHP-Open-PDK (repository README)IHP · GitHub130 nm SiGe BiCMOS (SG13G2) open PDK for analog, digital, mixed-signal and RF design; cell, I/O and SRAM libraries; KLayout DRC/LVS decks; Magic tech files; ngspice/Xyce models; preview status; Apache 2.0.
  24. Tiny TapeoutTiny Tapeout · tinytapeout.comShared-shuttle tapeouts of small designs on IHP, SKY130 and GF180 processes.
  25. LEF/DEF 5.7 Language ReferenceCadence Design Systems (open LEF/DEF standard) · ISPD 2018 contest site (public copy) · 2009LEF for process technology and cell models; DEF for the physical layout of a design: placement and routing.