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

AboutRoadmapCareersInternshipsFAQContactPrivacyTerms
Skip to lesson

Course contents

  • Logic Synthesis Glossary
  • Logic Synthesis Cheatsheet
  • Synthesis Foundations14
    • Synthesis Flow Overview
      • What Synthesis Does
      • The Five Flow Stages
      • Why Constraints Change the Netlist
      • A Small Design Through Yosys
      • Concepts, Not Commands
    • Synthesizable RTL and Inference
    • Reading Netlists and Reports
  • 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

←Synthesis Flow Overview
  1. Topics
  2. Logic Synthesis
  3. Synthesis Foundations
  4. Synthesis Flow Overview
  5. Why Constraints Change the Netlist
On this page

    Part 1 of 9, lesson 3 of 14Part 1 of 9/Synthesis Foundations/Lesson 3 of 14Intermediate

    Why Constraints Change the Netlist

    Run one design against five delay targets and read what changes: cell sizes, area and delay, with the recorded Yosys and ABC output.

    A constraint is only a number until you see what the tool does with it. Without seeing it, tightening a clock looks free, and a team pays area for speed the library cannot give.

    After this lesson you can: explain how a delay target changes the netlist, read the area-against-delay trade from a sweep, and spot a target that is past the useful point.

    The question

    You rerun synthesis, change one number, and the netlist is different. Which number was it, what did the tool do with it, and what did you get for the extra area? This lesson answers with a real run, not a sketch.

    One function, five targets

    The design below is a small decoder: a 12-bit input, one output built from AND-OR terms and one from parity. It is only big enough to show the effect and small enough to draw. The script synthesizes it once, saves the generic gates, then maps the same gates five times with a different delay target -D, in picoseconds, against sized.lib. That library offers each cell in three sizes: plain, _X2 and _X4, where a bigger cell is faster and larger.

    yosys
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    read_verilog <<EOV
    module decode (input [11:0] x, output y, output z);
      assign y = ((x[0] & x[1]) | (x[2] & x[3] & x[4]) | (x[5] ^ x[6]) | (x[7] & ~x[8])) & (x[9] | x[10] | ~x[11]);
      assign z = ^x[7:0] ^ (x[8] & x[9]);
    endmodule
    EOV
    synth -top decode -flatten
    design -save generic
    tee -o abc_1000.txt abc -liberty sized.lib -constr typical.constr -D 1000
    tee -o stat_1000.txt stat -liberty sized.lib
    write_json net_1000.json
    select -assert-none t:*_X2 t:*_X4
    design -load generic
    tee -o abc_800.txt abc -liberty sized.lib -constr typical.constr -D 800
    tee -o stat_800.txt stat -liberty sized.lib
    design -load generic
    tee -o abc_700.txt abc -liberty sized.lib -constr typical.constr -D 700
    tee -o stat_700.txt stat -liberty sized.lib
    design -load generic
    tee -o abc_600.txt abc -liberty sized.lib -constr typical.constr -D 600
    tee -o stat_600.txt stat -liberty sized.lib
    write_json net_600.json
    select -assert-min 1 t:*_X2 t:*_X4 %u
    design -load generic
    tee -o abc_400.txt abc -liberty sized.lib -constr typical.constr -D 400
    tee -o stat_400.txt stat -liberty sized.lib
    design -load generic
    tee -o abc_one_size.txt abc -liberty course.lib -constr typical.constr -D 400
    tee -o stat_one_size.txt stat -liberty course.lib
    log PASS: a tighter delay target upsizes cells that a loose target leaves at size 1

    In a commercial flow the target comes from the clock: create_clock -period 0.7 asks for 700 ps per cycle, which must also cover clock-to-q, setup, and uncertainty on top of the combinational delay. Yosys and ABC take the combinational slice directly as -D 700. Both hand the mapper one number to meet. ABC also needs the drive on each input and the load on each output, which typical.constr gives it (a BUF driver on the inputs and 0.05 pF of load on every output).

    typical.constr and sized.lib ship with the course examples. The select lines are the script's assertions: the loose run uses only the smallest size of every cell, and the tight run uses at least one bigger one.

    What the five runs printed

    Predict first You ask for 400 ps, below anything this library can reach. Will ABC give you a faster netlist than the 600 ps run, or the same one?

    The same one. The 600 ps run already uses every size that helps (area 81, delay 594 ps), and the 400 ps run returns exactly those figures. A target tighter than the library allows buys nothing; the run table shows it.

    Target -D

    Cells

    Area

    Delay reached

    Cells upsized

    1000 ps

    18

    65

    750 ps

    0

    800 ps

    18

    65

    750 ps

    0

    700 ps

    18

    73

    671 ps

    1

    600 ps

    18

    81

    594 ps

    2

    400 ps

    18

    81

    594 ps

    2

    Read the table top to bottom. At 1000 and 800 ps the loose netlist already meets the target, so ABC stops at area 65 and 750 ps. At 700 ps it misses, so it upsizes some cells: area 73, delay 671 ps. At 600 ps and below it has upsized the cells on the slow path: area 81, delay 594 ps. That is 25% more area for 21% less delay, and nothing more at 400 ps.

    Area against delay for the netlists ABC produced from one decoder: 65 units at 750 ps, 73 at 671 ps and 81 at 594 ps. Faster costs more area.

    The two ends, side by side

    Below are the netlists at the two ends of the table, drawn from the write_json files the script saved. Same function, same inputs and outputs. The loose netlist is on top. Cells the mapper upsized are drawn in orange, and their labels end in X2 or X4.

    The decoder mapped for a 1000 ps target: 18 cells, all size 1, area 65.
    The same decoder for a 600 ps target: 18 cells, area 81, with the upsized cells in orange.

    The cell count and the structure barely moved. What changed is the size of the cells on the slow path. In this ABC script the trade takes the usual shape: the mapper rarely rewrites the logic to meet a tighter target; it first buys speed with drive strength.

    Break it: take away the choices

    The last run in the script maps the same logic against course.lib, where each cell exists in one size, with the same 400 ps target. It reaches area 65 and 750 ps, the loose result: there is nothing to upsize to. A constraint can only steer the tool among choices the library offers.

    Flowchart: delay target, library sizes and output load flow into the mapper, which produces a netlist with its area and delay; a missed target loops back to the mapper.
    The target, the library and the load all feed the mapper. A missed target sends it back to try bigger cells.

    Common mistakes

    Tightening the target past what the library can do buys nothing at all: in the table the 400 ps run returns exactly the 600 ps netlist, same area and same delay. The expensive step was earlier, from 700 to 600 ps, which bought shrinking returns in delay for more area. Read the report: if delay stops improving while you keep asking for more, you are past the useful point.

    Likely probes: why one RTL maps two ways, and what tightening buys.

    • Constraints set the target the mapper must meet; different targets give different netlists. Here 65, 73 and 81 area units from one design.

    • The first thing a tighter target buys is bigger cells on the critical path, not a new structure.

    • No target helps if the library offers no faster choice; the report tells you when you hit that wall.

    Check yourself Two runs of identical RTL give different netlists. Name two inputs that could differ, and say which one this lesson varied.

    The delay target and the cell library (or the output load). This lesson varied the target. Either one steers the mapper, so either can change the result.

    Check yourself A run at 700 ps gives area 73 and delay 671 ps. You need 600 ps. What do you try, and what could you learn?

    Tighten the target to 600 ps, as the table shows: area rises to 81 and delay falls to 594 ps. If a still tighter target changed nothing, as at 400 ps, you would learn the library has no faster cells to give, and you would look at the logic or the library instead.

    • One RTL and one library give a staircase of netlists, one plateau per target the tool can meet.

    • A tighter target first buys bigger cells on the critical path, not new logic.

    • A target below what the library can reach changes nothing; the report shows it.

    Rule of thumb: read the delay and area the tool reports before you tighten a target again.

    How this was checked

    Every number and picture on this page comes from one Yosys 0.69 run of the script shown, recorded by the course checker (scripts/tools/run-rtl-testbenches.mjs with COURSE=synth): ABC maps one decoder against the teaching library sized.lib at five delay targets, with a 0.05 pF output load. The libraries are fictional, with illustrative numbers like course.lib, so absolute values are teaching units; the shape of the trade, not the digits, is the point.

    • Interview: run a mock interview on this topic

    Related topics

    • A small design through Yosys

    • SDC for Synthesis

    • Area, Power and Timing Tradeoffs

    Previous

    5 / 139

    Next: A Small Design Through Yosys

    Up next

    Up nextA Small Design Through Yosys

    Sign in to save progress

    Practice this lessonPrevious lessonReport an error

    See also

    • What Synthesis Does
    • Concepts, Not Commands