Skip to content
Avecas

PHYSICAL DESIGN

Physical design

Convert a constrained netlist into a placed and routed implementation while balancing timing, power, area and routability.

Discuss your requirements
A patterned silicon wafer showing repeated device regions

Representative photograph · A patterned silicon wafer showing repeated device regions.

THE ENGINEERING SCOPE

Built around
your requirements.

Explore the approach ↓
01

Technical starting point

Netlist, timing constraints, floorplan requirements, libraries, LEF files and operating corners.

02

Acceptance evidence

Setup and hold timing, congestion, physical checks, power integrity assumptions and corner completeness.

03

Delivery package

Implementation databases, layout outputs, constraints, timing reports and open-violation summaries.

CLIENT GUIDE

Scope physical design with the right evidence.

Use these technical checkpoints to make the first project review productive.

Provide before the review

  • Netlist
  • Timing constraints
  • Floorplan requirements
  • Libraries
  • Lef files and operating corners

Review during execution

  • Setup and hold timing
  • Congestion
  • Physical checks
  • Power integrity assumptions and corner completeness

Agree for delivery

  • Implementation databases
  • Layout outputs
  • Constraints
  • Timing reports and open-violation summaries

HOW WE WORK

Clarity at each stage.

01

Establish the implementation baseline

Check the netlist, timing constraints, technology views, power intent and macro abstracts. Agree modes and corners, then review die dimensions, floorplan constraints and available routing resources.

02

Plan and place the design

Develop the floorplan and power structure, place cells and macros, and investigate congestion and early timing pressure. Review changes to utilization and hierarchy against the design goals.

03

Build clocks and route

Develop the clock distribution and route the design under the agreed constraints. Review timing, routing violations and electrical checks as the physical implementation becomes more detailed.

04

Review closure and handoff

Correlate the final implementation with the agreed signoff checks. Package databases, reports, constraints and unresolved waivers with explicit ownership; release criteria remain project and technology specific.

PROJECT DECISIONS

Know what moves the work forward.

Use these gates to agree readiness, review evidence and responsibility at each stage.

  1. 01

    Baseline ready

    Are the starting inputs complete enough to proceed?

    Review method and evidence

    Netlist, timing constraints, floorplan requirements, libraries, LEF files and operating corners.

    Review evidence

    Record input revisions, missing material and who can resolve each dependency.

  2. 02

    Implementation reviewed

    Has the work addressed the agreed technical objective?

    Review method and evidence

    Convert a constrained netlist into a placed and routed implementation while balancing timing, power, area and routability.

    Review evidence

    Keep the intermediate artifacts with review comments and the decisions that changed the design.

  3. 03

    Evidence checked

    Can the result be reproduced and interpreted?

    Review method and evidence

    Setup and hold timing, congestion, physical checks, power integrity assumptions and corner completeness.

    Review evidence

    Capture the configuration, expected result, observed result and unresolved findings.

  4. 04

    Handoff accepted

    Can the receiving team use the delivery package?

    Review method and evidence

    Implementation databases, layout outputs, constraints, timing reports and open-violation summaries.

    Review evidence

    Review build or execution instructions, known limitations and ownership of follow-up actions.

INPUTS & OUTPUTS

What the work involves.

The final statement of work defines the scope and acceptance criteria.

Client inputs
Netlist, timing constraints, floorplan requirements, libraries, LEF files and operating corners.
Engineering sequence
Review floorplan and macro access; place cells and optimise congestion; construct clocks; route and analyse extracted timing.
Outputs to agree
Implementation databases, layout outputs, constraints, timing reports and open-violation summaries.

TECHNICAL DECISIONS

Planning physical design.

Read the technical guide

The engineering objective

Convert a constrained netlist into a placed and routed implementation while balancing timing, power, area and routability.

The work starts from netlist, timing constraints, floorplan requirements, libraries, LEF files and operating corners. The team should identify the authoritative revision of each input and record any assumptions needed to proceed. This prevents a later result from being interpreted against a different specification or configuration.

What needs technical attention

A clean placement or global-route estimate is not final signoff; extracted analysis and project-specific checks remain necessary.

The review centres on setup and hold timing, congestion, physical checks, power integrity assumptions and corner completeness. Each finding should identify the input revision, observed behaviour and supporting evidence. Distinguish a confirmed defect from a configuration issue, an unsupported case or an open engineering question before deciding how to resolve it.

How the work is reviewed

The practical sequence is: review floorplan and macro access; place cells and optimise congestion; construct clocks; route and analyse extracted timing. Intermediate reviews allow the client to resolve decisions while changes are still manageable. If an input changes, identify the affected activities and repeat the checks that depend on it.

The expected package comprises implementation databases, layout outputs, constraints, timing reports and open-violation summaries. Acceptance criteria should specify what the receiving team needs to reproduce, inspect or integrate these artifacts. Include known limitations and outstanding actions in that package, rather than assuming that delivery of a file implies acceptance.

Separate implementation estimates from release evidence

Physical implementation starts with consistency between the logical design, constraints and technology views. Review clock definitions, generated clocks, I/O delays, operating modes and exceptions before interpreting timing. A missing constraint can make a report appear healthier while leaving a real path unevaluated. Record the library and extraction corners used so results from different stages can be compared on the same basis.

Floorplan decisions influence routing, clock distribution and power delivery together. Reserve space for macro access, power connections, congestion relief and the paths that need predictable delay. A local timing improvement may add buffering, increase switching power or create routing pressure elsewhere. Review these effects across the agreed modes and corners instead of accepting an improvement in one summary number.

As the design moves from placement through clock construction and routing, replace estimates with the appropriate extracted evidence. Classify violations by cause and ownership. An ECO should carry its logical intent, the affected paths, implementation changes and the checks that must be repeated. The release checklist should identify required reports and any formally accepted exceptions; the presence of a layout file alone is not a signoff decision.

An illustrative review scenario

An added pipeline register may improve a setup path while creating short hold paths and changing clock-tree loading. Compare both setup and hold at the agreed corners, review new buffering and check routing and power effects. Retain before-and-after reports from a controlled baseline. This illustrative example explains review scope; it does not promise a particular power, performance or area result.

BEFORE WE BEGIN

Project questions.

A clear conversation is the start of a strong engineering relationship.

What inputs are needed for physical design?

The starting review needs netlist, timing constraints, floorplan requirements, libraries, LEF files and operating corners. Share the current revision and known limitations so the scope reflects the actual design state.

What does the physical design handoff include?

The statement of work can define implementation databases, layout outputs, constraints, timing reports and open-violation summaries. The final package should include review results and any open actions.

Which technical risks need particular attention?

A clean placement or global-route estimate is not final signoff; extracted analysis and project-specific checks remain necessary.

Can we start with a focused technical review?

The first work package can be a review of the available inputs and the engineering questions that must be resolved. Agree its boundaries, access requirements and expected findings before committing to a larger implementation. A review should leave an actionable list of decisions, dependencies and next steps.

How are changes and unresolved findings handled?

Tie each finding to the relevant revision and supporting evidence. A change should identify the affected interfaces, activities and checks. Confirm its effect on scope and delivery with the responsible owner. At handoff, distinguish closed findings, accepted limitations and open work so that a file transfer is not mistaken for technical acceptance.

PUT THE WORKFLOW IN CONTEXT

Explore the engineering decisions.

Practical reading to help prepare your project discussion. Studies are illustrative; they do not report client results.

Reviewing a congested floorplan before timing closure ↗

YOUR NEXT CHAPTER STARTS HERE

What will you
build next?

Bring us your engineering challenge.
Let’s define the path from idea to implementation.

Start a conversation