Physical Design


This article is the first in a series of three short articles that speaks in little details about the inner workings and steps of Physical design. Terminologies in bold italic are explained at the end of the article. So let’s start.

Imagine we are building a city that inhibits 1,000,000 citizens. We have our specs and we know that those citizens would need facilities like hospitals, schools and clubs.. We also know that we need to divide our real state into districts and assign to each one of them some of those citizens to live in. Roads have to be built to connect between those districts and also within the district itself. we have to be wise where we place our schools and hospitals.. we need to have our roads not congested to vital parts of the city. Many consideration we need to be aware of. In essense, this is what physical design is all about. It is a series of steps that designers follow in order to transform a schematic/RTL to an actual working chip.

Due to the tremendous expansion in transistor count per chip, we use EDA tools to aid us do the layout of millions of transistors into a single piece of silicon. This series of articles would be addressing standard-cell based ASIC designs.. That is we re-use a pre-designed library of logic gates (flops, ANDs, ORs, NANDs, NORs, XORs … etc) to transform a chip/block level RTL into a GDSII layout (RTL2GDSII) which goes to the Fab and gets manufactured.

This article is the first in a series of three short articles that speaks in little details about the inner workings and steps of Physical design. Terminologies in bold italic are explained at the end of the article. So let’s start.

Physical design is mainly cut into four tasks: Design planning, Implementation, physical verification and Timing signoff.


Design planning is where we take a gate-level netlist (out of synthesis) and start experimenting with it to reach a timing
and congestion
free floorplan.. Inputs for this stage are a timing clean synthesized netlist and a rough number of the allocated area to this block. This netlist contains references to the std cell library mentioned before. It can also contain references to hard IPs we use in our design (Like a ROM/RAM for example).

We use the implementation tool to figure out and settle on a couple of things:

  • the boundary of the block (we prefer to keep it in a rectangular shape and stay away of rectilinear shape if possible)
  • Location and orientation of the hard IPs (we also call these macros).
  • IO and port locations needs to be finalized and freezed.
    • For a block level, port locations are to be chosen wisely so that when the block gets integrated into the top level, we don’t get long connections that might require buffering at the top level. Moreover, in extreme cases, we can’t simply make the connection due to insufficient routing resources which triggers a reassignment of the port to another location. So to avoid that, we try to chose port locations to be facing their counterpart connections (at the top level). This is crucial for top level integration and a source of ambiguity that could kill a tapeout schedule.
    • If we are implementing a chip, we assign the IO locations based on lengthy discussions with the packaging house. There are numerous packaging types but currently, two are commonly used ; “wirebond” and “flip-chip”. There are numerous considerations in the process and it is a back-and-forth one where we go through many iterations to finalize IO assignment especially if the IO count is in hundreds.
  • In a timing critical design, we sometimes assign bounds …these are shapes that confine the placement of a certain module/s in a specific place in the core.. We do that to help meet the timing requirement (setup time).

Once we settle on the block’s floorplan, we discuss it with the chip integrator; whether

  • the shape we chose is fine and can be accommodated in the chip .
  • The area fits the specification.
  • location of the ports and layer assignment is fine.
  • Port location is revised with extra care not to be surprised later in the design cycle.

A few things to consider:

  1. In physical design, we are concerned with the timing aspect of the design (for example: meeting the maximum clock frequency of the design) in the same way we are concerning with the physical aspects (DRC, LVS and ANT checks) .. Some designs have more challenging physical problems than others while other designs, timing could be the culprit.
  2. Always Garbage in gives you garbage out.. Unoptimized floorplan can result in bad placement resulting in congested routing and/or unroutable design.

This concludes the design planning part.. We will talk about the implementation phase next time.



Every synchronous design we implement has certain timing constraints that we should meet.The clock frequency is a prime example, yet there are other constraints that the tool have to adhere to like:

  • Setup/hold checks for data pins of flip-flops.
  • Recovery/Removal checks for asynchronous set/reset pins of flip-flops.
  • input/output delays .. These are numbers used on every synchronous input/output port to ensure proper capture and release of data at the block boundary .. i.e. Meeting setup/hold time at the boundaries.
  • transition/fanout/capacitance constraints
    • every standard cell we use has a certain drive capability that can support a maximum load. If the tool needs to drive a bigger load, it uses a higher drive strength cell.
    • Transition time (slew rate) has be kept also within limits. Bigger transition times can lead to
      • inaccuracies in the timing calculations .. You could pass a failing path if the tool calculation is optimistic and vice-versa.
      • huge short-circuit current that pass in a cell when both pull-up and pull-down networks open at the same time.
    • every standard cell has a maximum capacitance/fanout that it can drive.
  • Duty cycle checks on clocks if present.


A design that is congested is a design that have limited routing resources to complete all the connections in a netlist. Congestion can be localized in the floorplan or a global floorplan issue. A congested area in the floorplan is an area that has less routing resources than the actual routes that pass through that area.

To measure that in a quantitative manner, Router divides the core area into small squares called “Gcells” .. Every edge (vertical or Horizontal) of a Gcell has a capacity.. The router start to assign nets that pass through every edge of all the Gcells then calculates if we have an edge that has an overflow (i.e. more routes than it can carries).. Finally, It gives the designer a weighted colored map of where in the floorplan there is a congestion of routes.

Related posts:


  • Fatal error: Uncaught Error: Call to undefined function ereg() in /customers/9/c/6/ Stack trace: #0 /customers/9/c/6/ commenter_link() #1 /customers/9/c/6/ custom_comments(Object(stdClass), Array, 1) #2 /customers/9/c/6/ Walker_Comment->start_el('', Object(stdClass), 1, Array) #3 /customers/9/c/6/ Walker->display_element(Object(stdClass), Array, '5', 0, Array, '') #4 /customers/9/c/6/ Walker_Comment->display_element(Object(stdClass), Array, '5', 0, Array, '') #5 /customers/9/c/6/ Walker->paged_walk(Array, '5', 0, 0, Array) #6 /customers/9/c/6/vlsi in /customers/9/c/6/ on line 28