Skip to content
DenseChip
Learn
PracticeCode labInterview

DenseChip

Navigate

Menu

LearnPracticeCode labInterview

Tools

All toolsSV editorCode repoResume
DenseChip

Practice, courses, and chip-design tools in one focused workspace.

LearnPracticeCode labInterviewToolsLearning paths

© 2026 DenseChip

AboutContactPrivacyTerms
Skip to lesson

Course contents

  • Logic Synthesis Glossary
  • Logic Synthesis Cheatsheet
  • Synthesis Foundations14
    • Synthesis Flow Overview
    • Synthesizable RTL and Inference
    • Reading Netlists and Reports
      • Cell Counts from stat
      • Area by Cell Type
      • Hierarchy, Fanout and Net Names
      • Longest Path, Write and Read Back
  • Logic Optimisation and Mapping20
  • Constraints and Timing15
  • Sequential, FSM and Memory19
  • Datapath Synthesis14
  • Area, Power and Test14
  • Verification, ECO and Handoff15
  • Flows and Debugging15
  • Interview and Judgment11
Loading lesson

‹Reading Netlists and Reports
  1. Topics
  2. Logic Synthesis
  3. Synthesis Foundations
  4. Reading Netlists and Reports
  5. Hierarchy, Fanout and Net Names

Part 1 · Synthesis Foundations · Intermediate

Hierarchy, Fanout and Net Names

Hierarchy, fanout, net names, and constant pins in netlists and reports.

On this page

    Hierarchy in reports

    A hierarchical netlist keeps submodule instances, so counts span the modules. Flattening dissolves the instances into the parent while gate totals stay the same.

    The script below builds two instances of one AND submodule under an OR. It pins the instance count, flattens, and pins the counts again.

    yosys
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    read_verilog <<EOV
    module sub(input a, b, output y);
    assign y = a & b;
    endmodule
    module top(input a, b, c, output y);
    wire n1, n2;
    sub u1 (.a(a), .b(b), .y(n1));
    sub u2 (.a(a), .b(c), .y(n2));
    assign y = n1 | n2;
    endmodule
    EOV
    hierarchy -check -top top
    select -assert-count 2 t:sub
    select -assert-count 1 t:$or
    stat
    flatten
    select -assert-none t:sub
    select -assert-count 2 t:$and
    select -assert-count 1 t:$or
    stat
    log PASS: flatten dissolves instances and keeps gate counts

    Fanout

    Fanout counts how many gate inputs one net drives. High fanout means heavy load, which later stages must buffer.

    The calc block counts loads on the flattened design above. Input a is shared by both instances, so it leads.

    Diagram
    flattened loads:
    a -> u1.a, u2.a : fanout 2
    b -> u1.b : fanout 1
    c -> u2.b : fanout 1
    n1 -> OR input : fanout 1
    n2 -> OR input : fanout 1
    maximum fanout = 2 on net a
    gate input pins = 2 + 2 + 2 = 6 across 3 gates

    Generated names and constant pins

    Nets without a declared name get a tool-generated one. Those names shift with small edits, so scripts and constraints must use stable ports and hierarchical names instead.

    Constant pins fold away during optimisation. Tying an input to 1 or 0 removes the gate instead of building it, as the script below proves.

    yosys
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    read_verilog <<EOV
    module top(input a, b, output y, output z);
    assign y = a & 1'b1;
    assign z = b | 1'b0;
    endmodule
    EOV
    hierarchy -check -top top
    opt
    select -assert-none t:$and
    select -assert-none t:$or
    stat
    log PASS: tied constants fold away leaving no gates

    The block below is an illustrative layout, numbers invented for this lesson. Undriven pins deserve the same suspicion: a missing driver usually means a missing connection, so confirm each one.

    Diagram
    illustrative layout, numbers invented for this lesson (names stand in for generated ones):
    net n1 (declared) drives 1 load
    net GEN_042 (generated stand-in for an unnamed net) drives 1 load
    port a (shared by two instances) drives 2 loads

    Common mistakes

    Common pitfall

    Scripting against generated net names breaks on the next edit. Reference stable ports and hierarchical paths, and treat every generated name as temporary.

    Interview

    Likely probes: flattening, fanout, and constants.

    • Flattening dissolves the two sub instances into two $and cells while the $or stays put.

    • Fanout is loads per net, counted from the netlist, not guessed from the RTL.

    • Tied inputs fold to wires, so a gate count can drop without any RTL deletion.

    Check yourself Net a drives two gate inputs in the flattened example. What is its fanout, and which net is the maximum?

    Fanout 2. Net a is the maximum; every other net drives exactly one load.

    Check yourself A script greps the netlist for a generated net name and breaks after a small RTL edit. What went wrong?

    Generated names are unstable across edits. The script should reference stable ports and hierarchy instead.

    Related topics

    • Longest path, write and read back

    • Synthesizable RTL and Inference

    Previous

    15 / 139

    Next: Longest Path, Write and Read Back

    Up next

    Up nextLongest Path, Write and Read Back

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • Cell Counts from stat