"April 1, six months to target tapeout: Joined newly formed team to design 20 million gate SoC, 0.18 micron, beginning floorplan. Trying to reconstruct similar floorplan to previous chip version.
May 4: Changing to multiple power domains, have to rotate core with respect to pad ring.
June 11: After finally getting working timing models and library views, memory controller macro has to be redone. Block using this macro is on hold.
July 2: IR drop analysis shows more metal strapping and power pads needed. Missing milestones by weeks. Management is second-guessing us. They say we should've targeted 0.13 micron.
August 14: New version netlist (supposed to fix timing) has larger IP, sticks outside block boundary.
October 3: All blocks looking good, but XPS block won't route.
Three weeks to tapeout: Marketing wants new feature, 30K gate change, touches three blocks. Political issue now, CEO said 'No way!'
We've spent countless hours over the course of the project creating, refining, throwing away and recreating floorplans. Wake me up from this floorplanning nightmare!"
Floorplanning. It used to be easy and fun. Today's SoC complexity with millions of gates and hundreds of macro blocks has made floorplanning a headache. The vignette above is a combination of stories shared by SoC teams across the world. Floorplanning is a growing problem, and the large number of EDA companies chasing it is proof that designers are in pain.
However, conventional floorplanning has reached its limits. Today physical designers have no answers to this question: How can we stop churning floorplans, throwing them away and starting again?
Reuse has been practiced in the software and hardware design industries, through high-level languages and RTL, respectively, to better cope with complexity. But for physical designers to enjoy the benefits enjoyed by others, a higher level of abstraction is needed to remove a constraining dimension. In physical design that would mean removing the restriction that blocks, macros and cell locations be specified as hard-coded coordinates. By removing that hard coding restriction, floorplans could then be reused in a technology independent way.
A floorplan is truly reusable when your intent can be described in a technology independent, dimensionless manner and when the objects can be described relative to other objects. If those objects can be at different hierarchy levels, the floorplan is not only relational but also cross-hierarchical. With a tool suite and design methodology that solves problems associated with hierarchy and allows the floorplanning of all objects as if the chip is flat, thinking about and describing the chip and block floorplans become simpler. Replayable floorplans, which could also be described as programmable floorplans, bring significant advantages within a single SoC project as well as between various SoC projects.
Reduce, reuse, recycle the need for replayable floorplans
Reduce the workload associated with incremental changes.
Any design project involves a constant stream of incremental changes. A few months into a project, a new version of the netlist comes in, which is supposed to fix timing problems. You kick off the chip build that night, hoping to fix your timing violations. You come in the next morning to discover that the IP, which grew and now sticks outside of its block, caused the entire build to fail. You've lost a whole day of your time and machine time, and your floorplan needs to be changed. Who knows what will result from that?
Changing block size is one of the most frequent floorplanning problems. Without reusing whatever you can from a previous floorplan version, resizing blocks can be a daunting task. Also, if rectilinear blocks are supported, the block boundary can be bumped out just enough to fit the larger IP.
Another scenario: There's a set of RAMs placed on the upper edge of a block; there are blockages and some buffers near the output pins of the IP. This set now has to move 100 microns to the left. You select each of these objects in your GUI and move them. You continue your block build and find your timing is suddenly bad. You go back and try to discover those related standard cells that you missed and move them, too. Now you get other weird results. Eventually you reach a point where you have to start over.
What if you could anchor the entire structure? If objects inside the blocks are placed relative to other objects, the relationships are likely to remain the same despite the boundaries changing; this makes your floorplan fairly resilient to change. Of course, if an ECO no longer contains a block referenced in the floorplan, you'd have to eliminate references to the absent block and create new appropriate references (either in the GUI or in the floorplan script). The remainder of the floorplan could stay the same.
Reuse the floorplan to experiment.
Changing a floorplan captured in absolute coordinates is painful because of the domino effect if you change the numbers in one place, everything else is also affected. Early in the design cycle, you may be open to more radical experiments while in search of a "good" floorplan. This could include changing the die size, resizing blocks and/or their aspect ratios, moving blocks around, and changing orientation. If you have replayable floorplans, it's easy to try out something really different. For example, only a few lines of code would need to change in order to rotate a core 90 degrees to see if it would help routability.
Late in the design cycle you might also want to experiment. For example, three weeks before tapeout, under competitive pressure, marketing may want that 30K gate Christmas feature that impacts three blocks. With a replayable floorplan, you could slightly change the floorplan and still meet the schedule.
Recycle the floorplan in subsequent designs.
Replayable floorplans provide a standard way to ensure that the design team (perhaps different people than those who designed the previous chip) leverages the knowledge gained from the previous design. Perhaps you're migrating from one process to another, or doing a derivative design by removing a USB2 core and adding an Ethernet controller. The IP would almost certainly be different or some of the aspect ratios might have changed.
Replayable feature set
The techniques for reusing a floorplan vary; from re-executing a GUI log file or culling the pertinent commands from the log file, to reusing a dumped file with absolute coordinates, to programming a floorplan. State of the art floorplanners describe, or "program," the floorplanning algorithm. For example, they might place the upper left of the largest macro (Macro1) in the upper left corner of BlockA, place the second largest (Macro2) to the right of Macro1, place Macro3 to the right of Macro2, and so on. For describing such an algorithm, programming constructs such as variables, conditionals, and loops are useful.
This is not to say, however, that a floorplan must be programmed. Objects can be placed and moved in a GUI and the tool can generate floorplanning commands. If a GUI-generated floorplanning command is stated in a relational manner versus in hard coordinates, there's a higher likelihood that the command can be reused.
The floorplanner needs to know about such physical design objects as pin and instance locations. The description language must be able to describe locations relative to those physical objects, such as the upper left or the northwest corner of an instance object. If technology dimensions can be captured, then the floorplan can be easily ported across different process technologies. For example, you might want to open up a gap between two RAMs that is wide enough for a Metal4 power-ground pair. Or you could place an instance at a certain absolute location but also make sure it is snapped to an appropriate grid, which might be defined according to some technology unit.
To perform hierarchical optimization techniques such as optimal pin assignment on blocks and global repeater placement, physical design tools must know the content and location of the blocks. At the top level, it is difficult, but possible, to know exactly how to floorplan block internals. The "block jock" needs the flexibility to move some of the block internals around without depending on another top-level build. Of course, the block jock needs to ensure that any changes made at the block level are communicated back for the next top-level iteration.
Because of these iterative top-level and block-level builds, it is helpful if block-level floorplans are replayable from both the top and the block level. Then if a block jock makes a change, the subsequent top-level build can reuse the same floorplan. But one caveat: if you have loaded in a block out of context, the block does not know about its neighboring blocks, which can only be seen from the top level. So block floorplans written to be run at either the top or block level cannot use cross-hierarchical features, the advantages of which are described next.
With a cross-hierarchical, relational floorplanner, you can place macros in one block relative to some object in another block, or you can line up analog blocks with pads that are in a different block. You can designate that I/O affinity logic be placed near pads for timing purposes. If additional pads get inserted or the pads move, the I/O affinity logic follows the pad it is dependent on, without requiring any floorplan changes. With these deterministic capabilities, you can place the timing-sensitive logic and pre-routes within your blocks instead of creating a full custom macro, which requires creating library views and full timing models.
Figure 1 shows an example of two different blocks (m0 and m2) that use the same floorplan "algorithm" to place three RAMs. The upper left corner of ram1 is placed in the upper left corner of the block with an offset in both the X- and Y-directions equivalent to five standard cell rows. ram2 is placed to the right of ram1 with an offset of four metal2 tracks. The lower right corner of ram3 is placed halfway up the right edge of the block with an offset of five standard cell rows. The RAM in m3 is placed relative to the RAM in m2.
Figure 1 -- Floorplan "algorithm" places three RAMs
Replayable floorplan example
The more you iterate and fine-tune your floorplan, the more benefit you're likely to gain from a replayable floorplan, as is illustrated in this example. Recently a ReShape engineer working with an evaluation customer used ReShape's PD Planner to create a replayable floorplan for a cell phone baseband processor chip. Since the customer was very sensitive to the cost of their chip, they wanted to explore the tradeoffs associated with changing die size and metal layers.
Changing die size
The ReShape engineer working with the customer started with a 6-layer metal process and assumed a certain die size to begin the floorplan. It took about two hours per block. Although it would have taken less time to use a GUI than to program the floorplan, the payoff of the initial work became apparent with the subsequent changes he had to make.
He was later given a target die size, which was 47% smaller than his original assumption. He had to change only four lines of code to accommodate this change. When he shrank the die size, one block was too narrow for the macros so one macro had to be moved to a different location.
In general, for robustness to changing die size, blocks should be located in columns or rows and be placed relative to blocks (see Figure 2). For example, the column width can be relationally described as one-third of the core width; the relationship remains the same despite different absolute values for different die sizes. The column or row boundaries can then be adjusted to achieve certain block utilization.
Figure 2 -- Blocks are placed in columns or rows
Once the engineer placed the blocks, he tiled RAMs within each block. The whole structure could be moved simply by moving the "anchor" RAM. This is the floorplan equivalent of a subroutine: the anchor RAM can be placed relative to the location of a physical object or a keystone (a point of reference in space that doesn't correspond to any physical structure). If the physical object's location or the keystone coordinates change, the whole tile structure follows suit.
Figure 3 shows tiled macro placement in a core block. The anchor macro is leftmost in the horizontal tile row and topmost in the vertical tile column. In the bottom tile row, the lower left corner of the leftmost macro is the anchor point that is anchored relative to the lower left corner of u-core.
Figure 3 -- Tiled macro placement in a core block
Figure 4 shows the same block as in Figure 3, with a changed aspect ratio and lower left corner location. The macros are still shown in their absolute locations; the dashed box shows the outline of the block's previous size and location.
Figure 4 -- Changed aspect ratio
With Figure 5,the macros are placed with the replayable floorplan. No changes to the floorplan were needed. The original command used to place the leftmost anchor macro is shown here:
move_object LL($macro1) -to LL('u-core') -offset ...
The same command works for the original and the changed block.
Figure 5 -- Replayable floorplan
Changing metal layers
The customer wanted to know what could be achieved using five metal layers. The designer changed the 6-layer floorplan to widen the channels between macros and to put pins on layers 2-5 instead of layers 3-6. The power grid layers changed, but that did not require any floorplan command changes since the command's functionality was to use the top two layers, whatever those were.
Aside from the die size and layer changes, the pad locations changed and more power pads had to be added. Logic (DAC, I/O affinity logic) tied to the pads moved along without requiring the designer to do anything other than update the input spreadsheet containing the new pad locations. Not only was the logic placement replayable, but also the pre-routes were replayable, such as those needed for wide analog connections. When endpoints of the preroutes changed slightly with respect to each other, no floorplan code changes were required.
The results of the evaluation illustrated that the customer could achieve a 5% smaller die in 5-layer metal, and a 12% smaller die in 6-layer metal, when compared to the customer's original die.
Support for improving the productivity of physical designers has lagged behind that enjoyed by the software and hardware design communities through high-level languages and RTL. Physical designers responsible for complex SoC designs are quickly overstepping the capabilities of current tools. Just as RTL has enabled logic designers to work at a high level in a technology-independent way, replayable floorplans with cross-hierarchical, relational capabilities can enable physical designers to manage growing floorplan complexity and cope with design changes.
Replayable floorplans have saved weeks of time on many projects. They have saved time at the beginning of a design project by recycling previous full-chip and block floorplans, and have saved time at the end by enabling designers to insert revised netlists during the tapeout sequence, with no adverse change to the delivery date.
Sharlene Gee is a Senior Applications Engineer at ReShape. After developing
DSP applications and product software and supporting DSP tools for four
years, she transitioned to EDA when the tools generated HDL code. She has
since been working in the EDA industry, including Synopsys and Magma Design
Automation, in an applications or training function for nine years.