| Physical design for reuse remains stuck at the hard macro, which prevents intellectual property from being optimized to the target design or easily migrated to the next process generation. By contrast, techniques for IP reuse have become commonplace in the logic design world. Reuse became practical with the advent of logic synthesis, which separated logic function from implementation technology (i.e., a gate library). But physical design intent is captured in a technology-specific way. Floor plans are hard to reuse. Block pins, macros and the power grid are specified in hard-coded coordinates. IP implementation scripts are written for a specific tool set, specific netlist and specific cell library. And they are written quickly, and are not intended to be used again by other engineers. One of the top 10 integrated-device manufacturers recently achieved high-level physical design reuse with a complex double-data-rate memory controller between projects by employing a new methodology for reuse. The DDR memory controller is a common interface, yet it is one of the more tricky to implement. The IDM wanted to use a DDR block in many designs with different bit-width configurations. A two-person team working on a 32-bit implementation achieved 225-MHz performance in silicon on a 180-nanometer process. A second team decided to use this successful 32-bit DDR controller as the basis for a 16-bit version. The design had to be cut down, since only two delay-locked loops (DLLs) of the original four would be used. Given the division's chip development road map, the decision was made to make the DDR reusable. Because DDR functions are very high-performance, making the block reusable is a high-touch process. Implementing the block in a traditional coordinate-based floor plan would mean high touch would be required on subsequent implementations. To overcome this problem, the lead designer chose to implement the design using relational physical design techniques found in modern floor planners. In relational design, object locations are specified in relation to other object locations (e.g., cell A located N tracks from pin 15), rather than to hard-coded absolute XY coordinates. For example, the left side of a layout could show a physical block layout in the context of a system-on-chip. The right side could show the original design was reused in a new SoC. In the new design, the block might need to be placed in the upper left corner of the new chip because of a new pad ring specification. The pads that required special preroutes to the D/A converter also had to move, and therefore the D/A's position in the block had to change. The addition of IP to the SoC meant that the optimal die size could be obtained only with a more-vertical aspect ratio. In the DDR design, each DLL was placed in relation to its dedicated power pads in the I/O ring. Edge logic (standard cells that needed to be near certain I/O cells) was placed relative to the respective I/O so that if the I/O cell ordering changed, the edge logic moved with the I/O cells. Custom buffer trees between the DLLs and the critical flops were also placed relationally. Even custom power rings that were required around the DLLs were specified using relational techniques.  The second issue the team needed to address was the tool scripts necessary to implement and verify the design in a repeatable way. Historically, the team made use of tool scripting and the Unix "make" utility. The scripts were generally written by the original designer with the tapeout in mind — giving little, if any, consideration to the idea that the scripts might have to be used by another engineer. To solve this "script reuse" problem, the team turned to second-generation flow automation, which raises the flow specification from individual tool commands to a series of high-level physical design steps (for example, "place block A" that executes all the steps to prepare the data, run the placement command, do error checking, save the data, etc.) called stages. Stages are elaborated with the design' s floor plan, netlist, technology files and tool settings of interest to generate the hundreds of thousands of design-specific tool commands necessary to build a full chip. Using this technology, the design team specified the implementation/verification flow, called a "subflow," for each block. A subflow is created quickly by connecting stages, much like putting Lego blocks together. The designer then optimizes each block subflow by tuning tool variables for each block in the context of the full chip. The designer codifies all hand edits or engineering change orders (ECOs) by creating ECO stages. To construct the full chip, each subflow is elaborated at run-time, and tool commands are executed automatically to build the chip of interest. The design team will optimize the chip/block floor plans, and each subflow, to create the optimal design. Since the team could leverage the 32-bit implementation floor plan, the effort to redo the initial 32-bit DDR controller as a 16-bit relational design was about 75 percent of the effort of creating the original DDR design. The relational 16-bit DDR design was successfully implemented in a 180-nm SoC. Since the floor plan and DDR subflow are captured in a reusable way, subsequent uses of the DDR will require 25 percent of the effort expended on the original 32-bit design. Lane Albanese (lane@reshape.com) is director of design and application engineering at ReShape Inc. (Mountain View, Calif.). | 
