Floorplanning: concept, challenges, and closure

Kushagra Khorwal, Naveen Kumar, and Sonal Ahuja, Freescale Semiconductor -September 19, 2012

In today’s world, there is an ever-increasing demand for SOC speed, performance, and features. To cater to all those needs, the industry is moving toward lower technology nodes. The current market has become more and more demanding, in turn forcing complex architectures and reduced time to market. The complex integrations and smaller design cycle emphasize the importance of floorplanning, i.e., the first step in netlist-to-GDSII design flow. Floorplanning not only captures designer’s intent, but also presents the challenges and opportunities that affect the entire design flow, from design to implementation and chip assembly.

A typical SOC can include many hard- and soft-IP macros, memories, analog blocks, and multiple power domains. Because of the increases in gate count, power domains, power modes, and special architectural requirements, most SOCs these days are hierarchical designs. The SOC interacts with the outside world through sensors, antennas, displays, and other elements, which introduce a lot of analog component in the chip. All of these limitations directly result in various challenges in floorplanning.

Floorplanning includes macro/block placement, design partitioning, pin placement, power planning, and power grid design. What make the job more important is that the decisions taken for macro/block placement, partitioning, I/O-pad placement, and power planning directly or indirectly impact the overall implementation cycle.

Lots of iterations happen to get an optimum floorplan. The designer takes care of the design parameters, such as power, area, timing, and performance during floorplanning. These estimations are repeatedly reviewed, based on the feedback of other stakeholders such as the implementation team, IP owners, and RTL designers. The outcome of floorplanning is a proper arrangement of macros/blocks, power grid, pin placement, and partitioned blocks that can be implemented in parallel.

In hierarchical designs, the quality of the floorplan is analyzed after the blocks are integrated at the top level. That can results in unnecessary iterative work, wasted resource hours, and longer cycle times, which could mean missed market opportunities. This underscores the importance of floorplanning.
In this paper, we will discuss some of the good practices, techniques, and complex cases that arise while floorplanning in an SOC.

The first rule of thumb for floorplanning is to arrange the hard macros and memories in such a manner that you end up with a core area (to be used for SOG placement) square in shape. This is always not possible, however, because of the large number of analog-IP blocks, memories, and various other requirements in design.

Before going into the details of floorplanning, here are few general terms that the designer has to understand:
  1. Track: Track is a virtual guideline/path for the tool at which the signal routing happens in an SOC design. Tracks are defined for each metal layer in both preferred and non-preferred directions, which are used by the router. The router routes the signal assuming the track to be at the center of metal piece.
  2. Row: This is the area defined for standard-cell placement in the design. A row height is based on the height of the standard cells used in design. There can be rows of various sites/heights in the design based on the type of standard cells used.
  3. Guide: A module guide is the guided placement of a logical module structure in the design. The guide is a soft constraint. Some of the module guide logic can get placed outside the guide, and other logical module logic can be placed in the guide region.
  4. Region: The region is a hard constraint in the design, and the design for the module is self-contained inside the physical boundary of region. However, it is possible for outside modules to have some logic placed inside the region boundary.
  5. Fence: This is a hard constraint specifying that only the design module can be placed inside the physical boundary of fence. No outside module logic can be placed inside the fence boundary.
  6. Halo: The halo/obstruction is the placement blockage defined for the standard cells across the boundary of macros.
  7. Routing blockage: Routing blockage is the obstruction for metal routing over the defined area.
  8. Partial blockage: This is the porous obstruction guideline for standard-cell placement. It is very helpful in keeping a check on placement density to avoid congestion issues at later stages of design. For example, if the designer has put a partial placement blockage of 40% over an area, then the placement density is restricted to a maximum value of 60% in the area.
  9. Buffer blockage/soft blockage: This is a type of placement obstruction in which only buffer cells can be placed while optimization or legalization. No other standard-cell placement is allowed in the specified area during placement, but while legalization and optimization some cells can be placed in this region.
Let us now explore the various considerations and special scenarios in an SOC design one by one.
Plan your partitions depending upon architectural requirements and different power modes in an SOC.
Today, the design approach is shifting toward hierarchical closure. The hierarchical approach is also derived by the architectural requirements, such as safety; tool limitations due to higher gate counts; late IP deliverables, and different power modes in an SOC. The hierarchically partitioned blocks are implemented independently in terms of placement, routing, timing, and noise closure.

When partitions are merged at the top level, there are cases of many top-level nets detouring across the boundary of these partitions, resulting in unnecessary timing violations, wasted routing resources due to large net lengths, and buffer insertion to avoid DRVs (design-rule violations) on these nets. All these, in turn, result in increased power consumption and increased placement density. It may also include some critical nets like clock nets which need to meet particular latency targets. These issues often result in reopening the timing and routing closed partitions, finally hitting in terms of the design cycle and design resources.

So the floorplanner has to plan at the beginning only for providing metal channels for top-level routes. The routing resources used inside the partition block can’t be used for routing at the top level. One has to define certain routing resource chunks inside the partition block that are not used inside the block and hence can be used for top-level routing. The early decision for providing routing chunks avoids iteration at later stages of design. Figure 1 explains the scenarios.

Next: Page 2

Loading comments...

Write a Comment

To comment please Log In