ASIC Technology

Design Reuse Enhances Productivity

EDA Industry Standards Roadmap for Design and Test research indicates large potential gains derive from reusing existing designs.

by George Chandler, Sumit Dasgupta, Gary Panzer, and Rita Glover

Less than a decade ago, 50,000-transistor microprocessors had 3µm feature sizes. Today, they have millions of transistors on a chip with feature sizes less than 0.75 µm. The product complexity and density continues to escalate, while costs and design times must continually decrease.

The Semiconductor Industry Association (SIA), National Technology Roadmap for Semiconductors, states that "new approaches must be found if industry is to continue on the 30% per-year, per-function cost reduction trend."

Over the past few years, we've seen development and exploitation of different technologies and methodologies to maintain this growth curve. Incremental and hierarchical design techniques have become increasingly important. Breaking a design into manageable segments allows us to put more total engineering resources into the design, and it also allows us to exploit concurrent software and design techniques.

Data management, continues to grow in importance. Today, a single chip design might be a massive system undertaking, with over a hundred engineers spread across global and corporate boundaries. Software and management techniques for controlling the engineering data allows us to maintain our senses without completely tripping over each other in the complex design.

Why reuse? Reuse can increase your productivity because there is less reinvention of the same thing. Reuse leverages other people's resources. By reusing existing components, you can focus on more advanced technology­instead of recreating what has already been done.

Reuse did work its way into chip-level design in a design methodology called Standard Cells. However, there is still more to gain through wider use of megacells and functional blocks. Furthermore, there is still vast potential for reuse at different levels of design abstraction.

Levels of reuse abstraction There are three implementations and time phases for reuse through which any industry will traverse:

1. Component reuse­short term.

2. Functional reuse­mid term.

3. Object reuse­long term.

In each phase, capturing the intellectual property is paramount. Figure 1 depicts the different complexity and breadth of each abstraction level.

Figure 1. The different complexity and breadth of each level of abstraction.

At the component level, each entity is generally self-contained and does not rely on, or interact with, other components, except at a functional level. Very little modification can be made to the component. Paper data books are now being replaced by on-line component information systems, but whatever the medium, designers essentially read a table of contents and look at the accompanying data tables to determine if the component meets their design requirements. However, given the limited selection and permanence of the component, designers sometimes had to modify the requirements. An example of a component could be an ALU standard cell or chip.

At the functional level, the entity now has a broader capability and is more flexible to modification, but usually does not contain physical information. The function is usually made up of other components in a hierarchy. In addition, the functional element now provides an interconnection method between the component. In most cases, these interaction links can be modified to accommodate replacement of the original component with next-generation technology. The functional entity is used as both a design implementation and search criteria. With this definition, the exact physical implementation is selected later by the designer. The function is captured in a high-level language such as VHDL, Verilog, Ada, or C, but it is usually more complex than just a single component. The function becomes more application-specific, so it is harder to define and reuse. This leads to a more intensive design phase and an increased implementation cost. An example of a functional entity would be an FFT filter, which is composed of ALUs and other logical components.

The object level defines an even higher level of abstraction. Now, multiple functions are used to create another design reuse element. The design database is a complex representation of specifications, functions, and components. However, it also captures the knowledge and processes by which the design was developed. Similarly, the time, cost, personnel, and tools needed to perform the task are captured.

Linked together, these three databases define all data necessary to recreate the item. Changing one database entity automatically ripples into the other databases. Thus, the ultimate reuse is at the object level. This requires a different library structure and support environment than previously described. The ability to browse libraries in familiar graphical paradigms is needed. It would need to provide different module views and store them as a linked data set.

Figure 2. The abstraction level axis is defined by the three levels of object, functional, and component entities.

In addition, we need common representations that are universally understood and can serve as a common method for conceptualizing and communicating the design intent. In essence, we need to encapsulate and easily represent the total knowledge required to build the item from the construction and optimization phases all the way down through the production phase.

An example of an object entity would be a notch filter (which is composed of an FFT filter and other functions) with a project database of labor hours, a schedule to design or modify the FFT function, and a spreadsheet to determine manufacturing costs.

What defines a reusable element? The essence of reuse is the capture and codification of knowledge. There is no way that engineers can reuse an entity without knowing its precise function and the parameters under which it operates. Therefore, the question is what elements of knowledge must be captured and communicated as data.

Figure 2 depicts three dimensions along which engineers base their design intent. As described previously, the abstraction level axis is defined by the three levels of object, functional, and component entities. The design process axis is well documented and understood by engineers. The basic process starts at the specification phase (architectural and algorithm), traverses through the design phase (schematics), and finishes with manufacturing (physical).

It's harder to capture the decision process that every engineer goes through at each step of the design phase and for each level of abstraction. Customer specifications are traded off and eventually transformed into design instructions. However, the decision details or the corporate knowledge that was used is rarely documented.

This process (the knowledge domain) is missing in the arsenal of today's engineer. What is needed is a translation from the knowledge domain to the data domain. We all know how to capture and codify data. However, the question is still, "what elements along the decision process axis constitute knowledge?"

Figure 3. Boundary conditions must be created so that knowledge can be transferred to different levels.

Reuse enables productivity Non-technical issues are some of the biggest inhibitors to reuse. Proper insertion of reuse methodologies requires proactive as well as reactive phases. In the proactive phase, the designer must include additional amenities (documentation, modularization, parameterization) without a substantial cost penalty. Many future design parameters need to be considered, including items such as timing specifications, power minimization, embedded test elements with high fault coverage, and compilation scripts.

Furthermore, design reuse must be considered at object, functional, and component levels. Reusability requires rethinking the initial capture of the design and its integration with other blocks. A component or module designed for reuse must be usable over changes such as hardware, software, technology, EDA systems, and operating systems. This requires standards that can be used with confidence to plug and play in the design of chips, boards, and systems. However, many organizations do not want to design for reuse because of the overhead involved.

Reactive phases should allow the designer to easily search and extract the pertinent data. There are several types of reuse, specification, functional, component, and physical, in decreasing order of implementation difficulty. Also, inserting testability may require changes to existing components.

At the back end, designers need knowledge of the reuse elements for high-quality insertion. For example, what does an ALU component do with the overflow for all possible data and logical operations? Maybe it was only designed for positive numbers. You can perform extensive simulation, but sometimes that's more costly than just creating a new design. The user must be able to easily find an element that will work in the situation at hand, or can be cost-effectively tailored.

Knowledge promotes standards Only by knowing what the original designer intended will the person using the element (the "reuser") have confidence in it. A certain level of knowledge is needed for confidence. Table 1 lists some knowledge elements that we've found are most necessary and examples of the types of data and standards available.

Table 1
Component design reuse model
Knowledge	Example of data	Standards
Functional = specification	Simulation models, switch models	Verilog, VHDL
Performance = speed delay equations	Timing model (estimated), ASIC delay calculation	DCL
Price = cost of intellectual property	Cost models	New study area
Footprint = physical	Dimensions, I/O positions, routing information, layers	EDIF convergence with other legacy standards
Reliability = specification	Failure rates, etc.	New study area
Quantity × price	Shipment volumes	New study area
Power = specification	Power models, AC, DC, noise, switching characteristics	Convergence of many standards (SPICE, SDF, PDEF, etc.)
Technology = specification	Design rules, TCAD	New study area
Physical = Design database framework	Geometry, boundaries, I/Os, constraints, placement specs, routing	EDIF layout convergence
Environment = specification	Voltage, temperature, designer constraints, placement specs, routing information	New study area
Testability = type of testing and measurement spec	Fault grading, BIST, patterns, test I/O, flush-through, scan design	New study area
Table 1. An example of standards that map knowledge to data. Many new study areas will be driven by design reuse needs.

At each level of design (macro, chip, or system), the unit of measure may differ, but the basic concept holds. For example, for "price," different units of measure may apply at each level. At the macro level, price may be the intellectual property price of that element. At the chip or system level, it may simply be the unit price.

Standards promote reuse Across the design cycle, from architectural design to physical design to fabrication, knowledge must be passed in a data format understandable to both the creator and the reuser. Only through standards can this knowledge be reliably moved from user to user, through time and across systems.

Design reuse demands reusable knowledge

By Bob Yencha, National Semiconductor and Rita Glover, EDA Today The growing complexity of today's products is driving the increasing density of discrete design objects. To support an increasing need to capture design intent, the design community now needs a means for establishing more complex relationships between design objects and associated information at the object level. The Pinnacles Group is a consortium of semiconductor vendors that has developed the concept of the electronic databook. The Pinnacles Component Information Standard 1.2 is the first step in support of this concept, dealing with databook information that is currently published in paper format. The Pinnacles Group recognizes the need to go far beyond the limitations of hard copy, and it is addressing the present and future requirements for electronic distribution through the use of SGML (Standard Generalized Markup Language, ISO 8879). The initial implementations of electronic databooks deal with complex pieces of data that constitute a characteristic, a condition, and their relationships. These electronic databooks enable database searches on information that until now has been locked in text and tables. Commercial tools can use this data to perform parametric searches in component information systems that may be enterprise-wide, making the data accessible to not only designers, but to distributors, purchasing, and manufacturing departments as well. In addition, the Pinnacles Component Information Standard incorporates and endorses the use of other data standards through component information dictionaries. These dictionaries reduce ambiguity by providing access to the context in which data is expressed. Soon, virtually any design object can be referenced along with associated knowledge that resides outside the design object. For example, an electronic databook can associate a design object with supporting data such as a schematic symbol, simulation model, or testbench, and this data can be expressed in any standard format of choice such as VHDL, Verilog, SPICE, or EDIF. The Pinnacles Component Information Standard is setting the stage for a new means of communicating product knowledge that is essential for a wholistic approach to design reuse.

Today, the knowledge information model has not been developed. However, we do have efficient data information models and management processes. Therefore, until the knowledge information model is defined, we can start by capturing what we believe is knowledge (intellectual property, design decisions, performance parameters, etc.) and then translate that knowledge to data so that it can be efficiently managed.

Figure 3 shows some possible transfer points. In essence, the higher levels need to quantify the exact requirements and decisions made at their level so that the lower level(s) can make tradeoffs without adversely affecting the product. This is a basic push of information.

The lower levels need to communicate their need for specific types of information so they can make informed tradeoffs. This combination of push and pull of information is really known as concurrent engineering, integrated product teams, and other forms of integrated product development.

Conclusions Several things need to happen before the knowledge information model can be developed. In the short term, the minimum knowledge data sets must be determined that are required for high-quality reuse. We need to know the minimum base set that reusers must have before they have confidence in the element. For each element of knowledge (asset), the type of data must be defined, along with the associated standard. Not all assets will be known at first; the set will grow over time. Therefore, the high-impact areas of knowledge need to be prioritized along with the associated standards. Table 1 depicts a proposed matrix of knowledge that is mapped to data standards for the component model of an IC chip. This table is being developed under the auspices of the EDA Industry Standards Roadmap for Design and Test, sponsored by CFI, EDAC, and Sematech. Because this work is still in progress, we've shown only a few of the proposed standards. Ongoing status can be seen at the CFI Web site, http://www.cfi.org .

In the mid term, standards associated with modifiable parameters (assets) must be included for each of the abstraction levels (object, functional, and component) and the data transfer elements in the basic interoperability data model. Additionally, the knowledge information model itself needs to be standardized.

In the long term, the knowledge domain must be captured and codified, and we need to be able to translate intellectual knowledge into the data domain. By this time, reuse will be second nature, enabled by knowledge, motivation, and the knowledge system.

George Chandler has worked in Texas Instruments (Dallas, TX) in microprocessor design, CAD support, and is now the Product Manager for Layout Verification and Manufacture Interface CAD tools.

Sumit Dasgupta is manager of DFT and physical design at Sematech. He is on assignment from IBM (Hopewell Junction, NY), where he was responsible for chip physical design tools.

Gary Panzer is a Senior Scientist at Hughes Aircraft (Los Angeles, CA) working on advanced signal processing systems, VLSI technology, and design reuse.

Rita Glover is serving as Director of Business Development of the Pinnacles Group in addition to her activities as market analyst at EDA Today (Phoenix, Ariz.).

Bob Yencha is Senior Systems Analyst at National Semiconductor in South Portland, Maine and also serves as Program Manager for the Pinnacles Group.

To voice an opinion on this or any Integrated System Design article, please e-mail your message to: michael@asic.com.

integrated system design   February 1996