Skip to main content

IC Compiler II (ICC2) Overview

IC Compiler II (ICC2) Overview | The Silicon Stack
EDA Tools & Industry Guidance · Part 7

IC Compiler II (ICC2): From Netlist to Physical Layout

How floorplanning, placement, CTS, and routing turn a gate-level netlist into tapeout-ready layout.

1.Overview

IC Compiler II (ICC2) is Synopsys's place-and-route (physical implementation) tool: it takes a synthesized gate-level netlist and SDC constraints, and produces an actual physical layout — floorplan, cell placement, clock tree, and routed metal — ready for signoff and tapeout.

ICC2's place-and-route technology is also the physical engine embedded inside Fusion Compiler, which pairs it with Design Compiler's synthesis in a single unified data model rather than two separate tools handing off files.

Note If you've used the original IC Compiler (ICC1), ICC2 is a full architectural rewrite, not an incremental update — a native hierarchical data model built to scale to hundreds of millions of instances at advanced nodes.

2.Use Case & Who It's For

ICC2 is the primary tool for physical design engineers responsible for:

  • Floorplanning — defining die/core area, macro placement, power grid structure, and I/O layout
  • Placement — positioning standard cells to balance timing, congestion, and power
  • Clock tree synthesis (CTS) — building a balanced clock distribution network that meets skew and latency targets
  • Routing — connecting all placed cells with actual metal, honoring design rules and signal integrity constraints
  • Physical timing/power optimization, feeding data back and forth with PrimeTime for signoff-quality correlation during the flow, not just at the end

3.Where It Sits in the Design Flow

ICC2 is the physical implementation stage, positioned squarely between synthesis and signoff:

  1. A synthesized netlist from Design Compiler, plus SDC constraints, floorplan data, and technology files (LEF/DEF, standard-cell library) are loaded into ICC2
  2. Floorplanning defines the physical outline and macro/power structure of the chip
  3. Placement, clock tree synthesis, and routing proceed in stages, each with in-tool timing and congestion analysis to guide optimization
  4. Parasitics are extracted (via StarRC) from the routed design
  5. The routed netlist, with real parasitics, is handed to PrimeTime for final signoff timing, and to IC Validator for physical/DRC verification
Industry Insight ICC2's in-tool timing analysis is tuned to correlate closely with PrimeTime's signoff numbers, but it's deliberately not identical — running the actual golden signoff tool at the end remains standard practice precisely because "close enough during optimization" is not the same bar as "correct for tapeout."

4.Installation & Licensing

  1. Download the IC Compiler II installer from Synopsys SolvNetPlus, under the Galaxy Design Platform license agreement
  2. Install on supported 64-bit Linux, typically sharing a common install tree with Design Compiler and PrimeTime
  3. Configure the Synopsys FlexLM license server and SNPSLMD_LICENSE_FILE
  4. Source the environment setup so icc2_shell resolves on PATH
  5. Foundry-supplied technology files (LEF, standard-cell and I/O library views, DRC/LVS decks) must be installed and referenced correctly — these are typically distributed under NDA directly by the foundry or a PDK vendor, not by Synopsys

5.Hands-On Example: A Basic Place-and-Route Run

A minimal ICC2 flow taking a netlist through floorplan, placement, CTS, and routing:

# icc2_pnr.tcl - minimal place-and-route flow
create_lib top_lib -tech tech.tf -ref_libs {ref_libs.list}
read_verilog top_netlist.v
current_design top
read_sdc top_constraints.sdc

initialize_floorplan -core_utilization 0.70 -flip_first_row
create_placement

clock_opt -to final

route_auto

extract_rc
report_timing -delay_type max -nworst 3

write_verilog top_routed.v
write_parasitics -output top_routed.spef

clock_opt -to final runs ICC2's full clock tree synthesis and optimization in one pass, while route_auto hands routing to the tool's automatic router — in a production flow both steps are usually broken into intermediate checkpoints so you can inspect congestion and timing before committing to the next stage.

Tip Check placement-stage congestion and timing before running CTS and routing. A floorplan or placement that's already tight on congestion rarely gets better after routing — it's much cheaper to adjust utilization or macro placement early than to fight DRC violations after a full route.

Recap

  • ICC2 is Synopsys's place-and-route tool — floorplan, placement, clock tree, and routing.
  • It's a ground-up rewrite from the original IC Compiler, built for hundreds-of-millions-of-instance designs.
  • Its physical engine is also embedded inside Fusion Compiler's unified RTL-to-GDSII flow.
  • Core flow: floorplan → placement → clock_opt → route_auto → extract_rc → signoff handoff.
Next Up · Part 8

Fusion Compiler — how Synopsys unifies Design Compiler and IC Compiler II into one RTL-to-GDSII data model.

EDA Tools & Industry Guidance · Series
← Design Compiler Fusion Compiler →

Comments

Popular posts from this blog

Module 1 — SystemVerilog Basics

VLSI Verification  •  SystemVerilog Series Module 1 — SystemVerilog Basics A complete, example-driven walkthrough of SystemVerilog fundamentals: data types, variables vs nets, arrays of every flavor, strings, enums, structs, unions, and typedef — the building blocks every verification engineer needs before UVM. 🧩 Beginner → Intermediate ⏱ ~25 min read 💻 Code Examples Included 📑 Table of Contents Introduction to SystemVerilog Verilog vs SystemVerilog Data Types: 2-State vs 4-State Logic Variables and Nets Arrays: Packed vs Unpacked Dynamic Arrays Queues Associative Arrays Strings Enumerations Structures Unions Typedef 1 Introduction to SystemVerilog SystemVerilog (IEEE 1800) is a unified hardware description and verification language (HDVL). It extends Verilog (IEEE 1364) with powerful constructs for design (interfaces, always_comb/always_ff, enhanced d...

GPU Memory System & Interconnect: How Data Travels Inside a Modern GPU

GPU Memory System & Interconnect: How Data Travels Inside a Modern GPU Modern GPUs deliver incredible computing power by processing thousands of operations simultaneously. While compute cores often receive the spotlight, the real performance of a GPU depends heavily on how efficiently data moves between memory and compute units. A GPU memory system is designed to provide extremely high bandwidth while keeping latency as low as possible. This is achieved through a collection of specialized hardware components working together, including the Memory Controller, HBM/GDDR memory, Crossbar, Network-on-Chip (NoC), DMA Engine, PCIe Interface, and NVLink. In this article, we'll explore each component in detail and understand how they collectively enable high-performance parallel computing. Why Does GPU Memory Matter? Every GPU application—from gaming and graphics rendering to AI model training and scientific simulations—requires continuous movement of enormous amounts of data. For examp...

Clock Domain Crossing (CDC): A Complete Beginner's Guide to Metastability, Synchronizers & Safe Data Transfer

Clock Domain Crossing (CDC): A Complete Beginner's Guide to Metastability, Synchronizers & Safe Data Transfer Modern System-on-Chip (SoC) designs rarely operate with a single clock. Instead, different modules such as CPUs, GPUs, memory controllers, communication interfaces, and peripherals often run at different clock frequencies or even use completely independent clock sources . When data moves from one clock domain to another, timing uncertainty can cause serious problems such as metastability , data corruption , and unpredictable system behaviour . This challenge is known as Clock Domain Crossing (CDC) . CDC is one of the most important topics in ASIC Design , RTL Design , ASIC Verification , FPGA Design , and SoC Architecture . Every modern chip—from smartphones to automotive processors—uses CDC techniques to ensure reliable communication between multiple clock domains. In this article, we'll explore CDC fundamentals, metastability, synchronization techniques, asynchro...

AXI Verification Interview Questions and Real-World Debugging

AMBA Protocol Series · Part 10 of 10 AXI Verification Interview Questions and Real-World Debugging Common protocol violations, how to read them off a waveform, and a curated set of interview questions with concise, correct answers — the capstone of the core 10-day series. AMBA Protocol Series: From APB & AHB to AXI — A Complete Guide for VLSI Engineers This wraps up the core 10-day series. Everything here draws directly on Days 1–9 — if any answer below feels unfamiliar, that's a good signal for which earlier post to revisit. (If you want to go further, see the 20-day extended list at the end of this post.) In This Article Common Protocol Violations Debugging From a Waveform Interview Questions and Answers Series Recap Extending the Series 1. Common Protocol Violations VALID deasserted before handshake — a source drops VALID before READY ever went high (violates the Day 8 stabi...

Cache Basics and Cache Mapping Techniques

  Cache Basics and Cache Mapping Techniques  Modern processors execute billions of instructions every second. However, processor speed has increased much faster than main memory (RAM) speed. This difference, known as the memory wall , creates a performance bottleneck because the CPU often has to wait for data from slower memory. To solve this problem, computer systems use cache memory —a small, high-speed memory located between the CPU and the main memory. In this article, we will understand the fundamentals of cache memory, the principle of locality, cache organization, and the three major cache mapping techniques. What is Cache Memory? Cache memory is a small, high-speed memory that stores copies of frequently accessed data from the main memory. Since accessing cache is much faster than accessing RAM, the CPU first checks whether the required data is available in the cache. If the data is found in the cache, it is called a cache hit . Otherwise, the CPU fetches the dat...

Timing Basics in Static Timing Analysis (STA): Delay Models, Sequential Timing, and Wire Delays

Timing Basics in Static Timing Analysis (STA) Static Timing Analysis (STA) is one of the most important verification techniques used in modern VLSI design. Before a chip is manufactured, engineers must verify that every signal reaches its destination within the required clock period. Even if a design passes functional simulation, it may still fail after fabrication because of timing violations. Unlike simulation, Static Timing Analysis mathematically analyzes every timing path without applying input test vectors. This makes STA significantly faster and capable of analyzing millions of timing paths efficiently. Table of Contents What is Static Timing Analysis? Why STA is Required Propagation Delay Contamination Delay Cell Delay Models Combinational Gate Delay Sequential Timing Setup Time Hold Time Wire Delay RC Delay Model PVT Corners Worked Examples Interview Questions Key Takeaways What is Static Timing Analysis? Static Ti...

Computer Architecture Interview Question Part 1

Skip to content Computer Architecture Interview Series Part 1 · CPU Basics · RISC vs CISC · ISA 50 Most Asked Computer Architecture Interview Questions (Part 1) The foundational round every VLSI, ASIC, and CPU design interview opens with: instruction set architecture, RISC vs CISC trade-offs, Von Neumann vs Harvard design, registers, endianness, and the fetch-decode-execute cycle — explained the way interviewers actually expect you to answer.  40 Questions (Q1–Q40) ⌛ 22 min read  VLSI & Computer Architecture Interviews On this page Foundations of Computer Architecture RISC vs CISC — Core Differences Von Neumann, Harvard & the Semantic Gap Architecture Styles, Endianness & Registers ILP, VLIW, Superscalar & Amdahl's Law Register Files, Microcontrollers & the Fetch Cycle Tip...