2. Strong Physical Designers
• Physical Design engineers need to be flexible, self-sufficient, and proactive. ASIC
design is still evolving, and the goal is to field a robust team that can grow and
adapt.
o PD Engineers must be able to work on all aspects of back-end design, from
floorplanning to STA to physical verification. Too often we see engineers who
solely work on a single facet of design, such as timing closure. This is a
problem, as timing is so closely related to placement, power, and clock design
that we should not think of it as a separate task.
o Scripting skills and an understanding of clean methodology is key to fielding a
team that can create, maintain, and expand upon its own design flow and CAD
tools. A separate CAD team is unnecessary, as design and methodology are
intricately connected and should be driven by the same engineers.
o Two roles which may require specialization are Power and LVS verification.
Both often require a deeper understanding of specific 3rd party CAD tools
along with technical knowledge not usually gained from performing physical
design.
3. Front-end Collaboration
• A strong relationship between the Front-end designers and the Physical designers
is key to meeting schedule and quality. Communication should be open, timely,
and goes both ways.
o SDC constraints will be adjusted and corrected over the entire course of the
project.
o Connectivity and dataflow should be communicated early on to aid in
floorplanning trials.
o Clock design should be well understood by both sides with diagrams being
provided at the start, early discussions will enable the physical design team to
balance trees properly.
o Upcoming changes or uncertainties about the netlist should be conveyed as
soon as they are known, to prepare the physical design team for future
changes.
• Problems often arise when the Front-end and Physical designers are in disparate
time zones, having conflicting interests, or are blockaded on sharing information
by policies or management.
4. Team Dynamics
• Physical Design members need to work as a tight-knit team. Complex hierarchical
designs require strong collaboration, and the group’s collective experience should
be utilized by every individual. While a single engineer might “own” a block,
he/she should be periodically seeking reviews of their own work from all members
of the team.
• Peer floorplan reviews should be regularly scheduled. All members of the team
should be involved in reviewing the top level floorplan in a hierarchical design.
Having a uniform structure for organizing files and runs allows any engineer to
quickly understand (or even take over) any block owned by a fellow team member.
• The top level owner/technical lead must often receive large amounts of
information from all team members and have to digest or disseminate it quickly.
To aid them in this, block owners should always ask and answer 3 primary
questions when presenting block status or a specific situation to the top level lead
and the rest of the team. These 3 questions are called the “What-Why-How”
approach, and is described on the next slide.
5. What-Why-How
• Having everyone follow the What-Why-How approach is critical to streamlining
problem solving amongst team members.
WHAT: What is your block’s instance count? What is the utilization? What are the
congestion or timing problems, and where are they specifically? Knowledge of basic
statistics and properties about your block should be in your memory at all times. The
primary problems and challenges should be well known, and you should be thoroughly
versed in the overall quality of recent results.
WHY: Why is congestion very poor in this part of your block? Why is timing violating by
so much to this memory? Why is your standard cell density very high in this part of the
block? It is insufficient to merely present problems to your lead, you must have
performed analysis as well. Understanding root causes to the issues you’ve raised is
crucial debug work that you have to go through in order to save time and enlist help
from others.
HOW: How do you plan to fix this many hold violations? How do you think you can
lower route density in this channel? How will you resolve these shorts near the
memories? With the knowledge of what the issues are and why they’re happening, you
should have spent some time brainstorming ideas on how to resolve them. This is
where experience and collaboration are key, as your team members are there to help
you figure this part out if you’re having difficulties.
6. Starting Out
• Zero Wire Load (ZWL) analysis is an important first step in determining the overall
quality and feasibility of the initial netlist. This gives us an idea of how “clean” the
design is prior to any implementation, and what logical modules might be at risk
for being timing critical, leading to floorplan decisions.
• Pre-CTS clock tracing is also important in order to understand the clock’s structure.
Constructing a visual diagram of key points and comparing this to front-end
documentation of the clock will aid in designing the initial floorplans. Clock
analysis of this type is often a step that many engineers skip.
• Connectivity tracing analyzes the major logical modules and what they are
connected to, be it other logical modules or blocks/macros. Minimizing the
distances between elements with large amounts of signal connections will heavily
determine overall layout.
7. Principle Design Flow
• The first stage for intensive analysis is the Placement stage. Many engineers don’t
realize the importance of analyzing the state of the design at this stage. Poor
placement results will never result in good Route results.
• CTS is also a major design stage. Many engineers rely too heavily on tool
automation to construct CTS. Expert designers will always guide CTS manually.
Floorplan Placement CTS Route
Design
- Size/Shape
- Macro placement
- Pin Placement
- Regions
- Blockages
- Power Grid
Analysis
- Congestion
- Timing
- Utilization
Design
- Pruning
- Reconvergence
- Preplacement
- Balancing
Analysis
- Shorts
- Timing
- DRCs
- Spreading
8. Floorplan
• Top-down or bottom-up? In a hierarchical design, does the top level owner dictate
floorplan for the blocks, or do the block owners dictate top level design?
o Answer: Neither. Floorplanning is a collaborative effort. The top level owner
tends to have more say in elements such as clock pin placement (since he
constructs the top level clock tree). The block owners tend to work out bus
placement between themselves, with guidance about routing channel usage
from the top level. Almost every design decision is a negotiation between
everyone involved.
• When does floorplanning begin?
o Answer: As soon as any usable netlist comes through. Starting early is crucial
to finding major design problems before they can impact schedule. Working
closely with the frontend designers from the beginning is important, but often
avoided or obstructed.
9. Placement
• Too often, engineers skip straight to CTS/Route without doing due diligence. If
quality of results from Placement is poor, then CTS/Route will not have good
results. Time can be saved by only allowing runs with good placement results to
continue on to the rest of PNR. Iterating between the Floorplan and Placement
stages can result in reaching better results earlier, but it’s a common mistake for
engineers to wait for post-Route results to analyze the design.
• It’s crucial to analyze congestion and timing carefully. Congestion most directly
leads to floorplan or partitioning issues, timing leads to refinement of constraints
(SDC) and detection of problems with the clock design. Most of the core design
decisions are made at this stage without ever seeing post-Route results.
10. CTS
• CTS can be fully driven by the tool. This is both common, and a complete mistake.
Tool-driven CTS may work, but it will produce longer clock insertion delays, which
leads to larger amounts of skew. CTS tools will build the trees and balance them,
but manual guidance is essential.
• The tool will balance everything, but if not every element is accounted for, the tool
may balance two trees that should not be balanced. All MUXs in the tree must be
dealt with, every clock source needs to be built and all leaf points accounted for.
Certain leaf points might be excluded from balancing, IO endpoints should be
accounted for, and all tree crossover points need to be checked.
• A visual diagram of key points of the clock tree is extremely helpful in designing
the tree properly. This should be constructed as early as possible and maintained
with all changes throughout the design process.
11. Route
• Routing is one of the most tool-intensive steps, and requires thorough knowledge
and proper use of the tool to choose the right settings and optimization steps.
Every technology and every tool has quirks and issues to navigate, often requiring
trial and error to find the optimal routing definitions for a particular design.
• After routing is complete, the short count is ultimately what decides routability.
Early timing analysis will lead to the refining of SDC constraints on ports, false
paths, and multicycle paths.
• Iterations from Floorplan to Route may have long runtimes, so it’s important that
most of the major floorplan decisions have been hammered out during the
Floorplan->Placement iterations.
12. Chip Size and Manpower
• Chip size does not necessarily scale linearly with the number of engineers
required. A single complex block might consume the same amount of attention as
5 simple blocks. Most complex hierarchical chips are a mixture of difficult and
easy blocks. On average, a strong engineer can handle 3-5 blocks.
• Generally speaking, a single person owns the top level. This is usually the technical
lead, the most experienced engineer in the team.
Simple flat
1-2 Engineers Simple Hierarchical
2-3 engineers
Complex Hierarchical
3+ Engineers
13. Block Sizing
• Block size does not scale linearly with runtime. The larger the block, the
exponentially longer runtimes can be.
• Depending on compute machines and licenses available, most blocks are best kept
below 800k instances and 100 memories.
• Blocks can be merged together if they are too small, as this increases runtime
efficiency.
• Blocks can and should be split up if they are too large, to avoid becoming a
bottleneck late in the design cycle. Splitting up blocks requires cooperation from
the front-end team early on, as they might have to make logical module changes
to accommodate this.
14. Tools and Licenses
• The more licenses, the better. Everything can be run with multithreading, and this
always consumes additional licenses.
• Typically, you want to look at the licenses needed per engineer, although this
changes from project to project. A rough example of how many might be needed
per engineer:
Encounter: 2
Starrc: 2
PTSI: 4
Calibre: 1
Formality: 0.5
• Single licenses for Power tools, GDS manipulation tools, and DFT tools are usually
sufficient.
• Which tool you use should depend on the Physical Design team’s preferences and
what has been proven to work with the technology node in question.
15. Technology Nodes
• Technology Nodes affect the complexity and difficulty of the design. Metal Layers,
DRC types, SI impact, PTSI corners, are just a few examples.
• The smaller the technology node, the harder the design. Cells become more
compact and routing becomes denser, with more metal layers and more rules
regarding these layers. Tools often struggle with newer technology nodes, having
bugs or optimization problems due to a lack of time for maturation.
• In general, the smaller the technology node, the more tool licenses you will
consume. Runtimes are longer, and parallel processing becomes required to meet
schedule. More signoff criteria are added, which results in a greater number of
timing and verification runs.
130nm 90nm 40nm 28nm
3 PTSI Corners 4 PTSI Corners 7 PTSI Corners 12 PTSI Corners
