Articles
Infrastructure for Design Reuse
Solve Timing and Signal Integrity Problems
An Effective Way of Design Reuse

Success Stories
Alpha CPU goes 0.13 micron
Synopsys chooses RUBICAD's LADEE for layout migration of 0.13-micron memory compilers
Peregrine cuts design time and costs
IMI increases performance
OKI reuses Hard IP
Philips migrates microprocessor core
Qualcomm optimizes Standard Cell Libraries
Xilinx migrates FPGA

Developing an Alternative Infrastructure for Design Reuse

By Michael Reinhardt, CEO, Rubicad, San Jose, CA

Implementing a successful design-reuse strategy and methodology has to be a top management issue. What defines success? An approach that lets you reuse predictable hard IP blocks and combine them in a new SOC. Layout migration offers a solution.

Design reuse is nothing new; historically semiconductor companies have used a linear shrink method to scale designs to the latest process technology, but this technique has run out of steam. Design rules don't change in a linear way any more. With today's tiny geometries, power and signal lines need to be adjusted in width and distance to solve speed and cross-talk problems in IP design elements being reused in new contexts. On top of that, the grid of an IP element needs to be adjusted if it's to be reused in an SOC.

From the top
Without a design-reuse strategy, it will be tough to compete in the semiconductor industry, especially at 0.18 um and lower. The choice of a reuse methodology will be up to management, and the decision will be a significant one. Without reuse, SOC design is doomed to failure. Why? In an SOC, all different functions and applications, each requiring specific know-how, have to be combined onto a single piece of silicon. To do this in a timely manner, you have to reuse existing functions, blocks and cores that have been pre-designed by experts and integrate them into a new SOC architecture in the same way board designers use pre-designed components.

The bigger and more complex SOCs become, the more specific they'll be which means lower volumes and the need for chips to be cheaper to design. Not to mention the need to get to market in time to meet demand. Without reusing pre-defined parts, SOCs will be too expensive to produce and impossible to bring to market in a timely manner. Somehow today's IP elements have to be made usable in the same way that standard-cell library elements have been used in the past.

Soft or hard IP?
A design-reuse methodology based on migration employs hard IP. If you put soft and hard IP on a value scale, hard IP is superior because all the work for verification and simulation is built into it, and you can produce silicon  from it. Engineering time and talent required for reusing hard IP and migrating it to your target process technology will be significantly lower since you'll be reusing an existing working layout of silicon-proven IP. Time to integrate the converted hard IP into an SOC is minimized because you can use the IP as a black box (a migrated IP block becomes a white box because during the conversion the signal and power lines as well as device sizes have to be adjusted accordingly).

Of course, you need to simulate and verify a migrated design if you migrate to deep-submicron technology. But you start the migration process with a working and silicon-proven design. Therefore, the relative timing is given, and the migration to a new process is straightforward. The migrated result is predictable, because the layout is migrated in such a way that a circuit's timing and speed are maintained or enhanced, and signal integrity problems are solved.

As for cost in dollars, the purchase of an HDL description might not be so expensive, but  the actual costs lie hidden in the design process. Hard IP always has the advantage in silicon size since it's most times a  full-custom hand-crafted design. Though the initial design of a full-custom, manually drawn hard IP element might involve more time and expense than a placed and routed standard-cell design, it's a good investment since wafer costs will be much lower.

A soft core exists as Verilog or VHDL code. To produce silicon, the HDL description needs to be translated into a mask layout, and you need to have a detailed understanding of the HDL code to produce a reasonable result on the physical side. To reuse soft IP, you have to perform synthesis; create a physical layout; extract netlist capacitance and parasitic information; simulate for timing and power; check simulation results for timing, power consumption and signal-integrity problems like crosstalk; and re-place and re-route if necessary, or manually fix the design. The bottom line: each SOC design team needs to go through the complete design process to reuse a piece of soft IP.

With soft IP, you run into the same problems of verifying the complete design from scratch. You also need a standard-cell library in the appropriate process technology, and the layout of the standard-cell libraries needs to be available before you can start to place and route. Moreover, you can not assume that a piece of soft IP that's been implemented and is working will work again for you. You may be using a different place and route tool, or a different version of the same tool, or perhaps the same tool at a different parameter setting. The placement of individual devices will be different, and that is the dilemma of reusing soft IP.

Reuse any layout
Our customers like Oki Semiconductor, Japan and QualComm, San Diego reuse hard IP and use our tools to migrate libraries to different process technologies. With a layout migration tool like Rubicad's LACE, you can reuse any piece of layout, and the converted libraries will have the same density as manually drawn libraries. There's no need to care about how to create a working mask layout because the IP provider usually makes silicon from the existing layout and checks for functionality, timing and power. This mask layout may be a full-custom manually drawn layout, or a routed standard-cell design or a combination of both. It's usually created and optimized for a specific technology and a specific fab. A big advantage of hard IP is that the provider can optimize the design element for power, speed and area. Optimized hard IP is often manually drawn.

A drawback of hard IP for those who don't use migration tools is that the layout exists for a specific technology, has a specific grid, and specific power and timing behavior. To reuse the existing layout of a hard IP element for a new SOC, you have to adjust the geometrical structures--design rules, grid, device sizes, width of power and signal lines, distance of power and signal lines--of the existing layout to the requirements of the new process technology. This is precisely where layout migration tools eliminate the drawback of hard IP. Migration tools compact hard IP to new design rules, adjust the width of signal and power lines to the performance requirements of the target process technology, adjust the grid of all hard IP components that have to be combined on an SOC. All device sizes are adjusted according to the new process parameters, and signal integrity problems like crosstalk are solved by differentiating between high-load and high-speed nets.

Infrastructure promotes IP reuse
To make hard IP easily portable across process technologies and easily adjustable to the electrical requirements of a new process technology, some infrastructure has to be set up.
The following steps need to be taken to implement a successful reuse strategy based on migration:

1. Describe how a reusable design should look in guidelines that might include directions for documentation, structuring of designs, rules for layout design.

2. Place all existing designs that can be reused and re-targeted into a central repository. Ensure that appropriate documentation is available and accessible to design teams.

3. Build a migration methodology for layout conversion into your existing design flow in a way that either a central group takes care of the porting of IP blocks for a design team, and/or install a push-button solution so that every design team can retarget whatever IP it  needs to integrate into a new SOC.

4. Bring converted designs including new documentation back into the repository, and  make the technology available to other design teams.

It's mandatory for management to be involved in putting this infrastructure into place. Why? Since it may be not be in the interest of a team or division to provide access to its designs, management will have to stand behind this practice and promote healthy competition. Also, management needs to build a process that guarantees IP elements are documented at all levels of the design process, and to oversee that all SOC project teams have interdisciplinary team members who understand all the aspects of SOC design.

A reasonable strategy is to have a mixture of reusable soft cores and reusable hard cores that you migrate. Your choice will depend on the availability of designs and what form they're available in, who provides them, and whether they're critical or not. You don't need to have a black and white approach to design reuse. For instance, a lot of legacy microprocessor and microcontroller designs aren't available in a synthesizable form because they're full-custom designs, and the original designers aren't available. In this case, a layout migration strategy is the only way to reuse them in an SOC.

Who's the keeper of IP?
In the ideal case, the IP provider/original designer would be the one responsible for an IP block. Whether you do migration in-house or outside, and whether you use your own IP or third-party IP, the optimum solution is to have an IP repository with physical layout blocks in it. The documentation for hard IP blocks in an IP repository is similar to the documentation for chips. The board designer uses a chip as a black box without knowing every detail inside the chip. If there is no chip available that meets requirements, a request is made to a chip design company to design a particular piece. The same approach applies to SOC designs that reuse pre-defined IP. The difference is that individual chips or IP pieces are not in an individual package, and they need to be laid out for the same process technology.

The Internet is an excellent medium to retrieve and to distribute design data. It's fast, inexpensive, and within minutes or hours the data is at customer sites around the world. Both soft and hard IP can be distributed over the Internet. Look for the new IP broker-like systems and web-based IP catalogs for an overview of available designs.

How do you decide whether to use migration tools in-house or to enlist design services? It really depends on the structure of your company. Consider how many designs you'll be migrating. If it's just one a year, it  might be more efficient to enlist the aid of an external service house. If you have several designs and libraries to migrate per year, it might be worth it to establish a group in-house to do the migration.

Expertise required
It's very useful for the person or team who sets up a physical layout migration tool to be a back-end specialist. Ideally, this set-up will be done by the same engineers who set up physical verification tools.
There will most likely be a mixture of migration on an as-needed basis and special engineering groups assigned to do migrations. In big design houses, for instance, there are special engineering groups that do the setup for all different conversion tasks.

Once set up, LACE runs the conversion of blocks more or less on a push-button basis. As with DRC check tools there will be many users who use the tool but few who are expert in setting it up. LACE provides "wizards" for technology and parameter file setups You fill out a questionnaire about the target process design rules and about your layout style, and LACE automatically creates all the necessary files.

At present, there is no limitation on the size of blocks that LACE can migrate because it compacts a design in a hierarchical way and distributes layout blocks over a network on several CPUs. Our customers and our design services convert almost every type of design.  projects. We've migrated microprocessor cores, DSPs, datapath designs, RAMs, ROMs, standard-cell libraries, as well as complete chips for use in embedded applications. Preservation of hierarchy is total for all custom structured design. For standard-cell design, hierarchy is preserved if there is a clear hierarchy in the input.

We would define a successful design-reuse strategy as one that lets you, in the shortest possible time frame and with the least effort possible, to combine into a new SOC existing IP blocks that are predictable for performance, functionality and area. Key words are "least   effort" and "predictable". That brings us back to the approach of reusing predictable hard IP elements and stitching them together into an SOC as a board designer does
with chips.

Migration technology requirements for migration at 0.18 um:
A modern migration technology system has to consider the advanced requirements for deep-submicron technologies at 0.25 micron and below. It has to take into consideration signal integrity and circuit timing issues.

This means, it has to be coupled with an analyzes approach for crosstalk and considering the results of the crosstalk analyze during the migration. Similar has to be done for circuit timing to achieve the requirements for circuit speed and power consumption. This means such a tool has to have active control over the interconnect capacitance's created during the migration.

The more advanced technologies like 0.25 and below show already more sophisticated design rules which are often highly conditional for specific layout structures. This situations have to be recognized and solved by a physical migration tool.

For maintaining the hierarchy an automatic analyzes tool is needed, because for most legacy and even new layout data the hierarchical structures are not well documented. This information is needed to rebuild a hierarchical layout according to the input plan. Because new technologies often add additional mask layers like metal 0 or phase shift masks a comfortable migration tool contains automatic mask and polygon editing and manipulation capabilities.

As the user community of migration tools will extend from pure IC design teams to system design houses who want to reuse hard IP for their system on a chip design, the user interface has to be highly task oriented, provide semiautomatic setups and an easy to handle GUI to enable also non-expert users to use migration technology to build fast SOC from different sources.

Back to Top