Managing design constraints

When a product marketing manager gives a specification to an engineer, he or she establishes a set of constraints and properties. Although the word constraints connotes limitation, in the engineering world, constraints, as well as properties, refer to the characteristics of a design that must be implemented and verified. The art of engineering involves interpreting marketing directives and generating a set of design rules that help in the production of a final product. Constraints come in different types. Product specifications always include functional constraints that describe what a product does or, in certain cases, does not do. In fact, marketing associates often call the document a functional specification. As fabrication technology continues to improve, both in ICs and in pc boards, performance requirements, environmental guidelines, and manufacturability directives increase in importance, and you must specify them as early as possible in the design cycle.

Unfortunately, specifying the characteristics of a new product or a revision of an existing product is still a manual operation, based on documents written in a language and a format that computers cannot easily parse. Physical constraints include the name of a parameter and its intended value or range of values; in most cases, you can define physical constraints using a spreadsheet-like form. Marketing professionals who are familiar with spreadsheets and computer programs can parse the files, so such spreadsheets may become an integral part of the product specification. But as products become faster and smaller, the methodology must evolve to address the significantly increasing complexity facing designers. Errors in translating properties and constraints into input parameters for various tools are difficult to find, and they result in significant design-repair costs. Costs increase tremendously the longer errors remain undetected.

Engineers must simultaneously contend with a number of issues that span hierarchical boundaries. Properties originate not just from the marketing-requirements document, but also from manufacturing specifications and even from EDA vendors because designers must consider tool limitations and operating characteristics. Design teams must reconcile functional characteristics with physical requirements and limitations that the target implementation technology imposes. Engineers must contend with simultaneous issues, including timing analysis, signal integrity, crosstalk, and power distribution and conservation. Although you can find EDA tools that address each of these issues, decisions made with respect to one issue might impact another. It is also no longer possible to defer manufacturing issues to the place-and-route phase or satisfy all of the timing requirements simply through synthesis directives. A constraints-management system must support both top-down analysis and bottom-up verification tools and span the design hierarchy.

Implementing a design is a process of decomposition. Engineers refine structures and properties expressed at a higher level of abstractions. The process must conserve functional and physical constraints in a way that allows engineers to correlate a property to its parent structure. During every step of the design process, you must integrate any constraints-management system to meet today’s challenges. The system must allow engineers to access properties through a real-time display that shows their status based on the design’s current state. Designers must also be able to capture, manage, and validate properties independent of specific tools. Otherwise, design companies lose the freedom to choose the best point tool for a given function and become captive to a specific EDA vendor.

Most people in the EDA industry avoid using “design framework” in favor of “design environment” or “design cockpit” when describing a tool that provides an overview of the design process. Framework is the best term because it gives you the mental picture of the Falcon Framework, a structure that frames and supports the design process. The industry should not be afraid of such an unfortunate experiment conducted more than 15 years ago, and should go back to using a more appropriate term for this class of tools. Database technology improved significantly in the period ensuing the Falcon Framework, and designers have learned a lot about the relationship of design items and hierarchical development methods. Unfortunately, existing environments are too often tool-centric, forcing designers to focus on the tools they are using instead of the design they are developing. A good constraints-management system is also a good design-management system. It is data-centric and tool-independent, causing designers to focus on the contents and requirements of the design, instead of the tools and their requirements. For example, although you may use a tool to build and verify a power network for your product, you need to keep track of the constraints and rules you use in making design decisions. In this way, it is easier to manage the impact that power-distribution decisions might have, for example, on crosstalk or signal-integrity aspects of the design.

Having a data-centric design environment means that engineers need not worry about the format of the design constraints or rules. Standards help considerably in such a situation (see sidebar “Standards for constraints management”). If every tool has its own way of dealing with design properties, integrating a tool into the environment becomes complex and at times even too expensive to be feasible. If users can express engineering data in standard forms throughout the development process, they can easily integrate the appropriate tools. This step not only increases the productivity of design engineers, but also fosters healthy competition among EDA vendors.


FUNTIONAL REQUIREMENTS
Regardless of how your company refers to the functional requirements, it is most important that design engineers can readily understand its contents. The physical requirements are easier to extract and apply to the correct portion of the design flow. The process of establishing which EDA tool uses a given physical requirement is generally understood. Engineers use their experience with both the design process and the available EDA tools to make such determinations. Behavioral constraints are more difficult to factor into the process. A new discipline, ESL (electronic-system-level) design, helps define behavioral characteristics of the product and is finding initial acceptance from design engineers. Dataquest, a leading EDA market-analysis organization, is bullish on the potential for the sector and forecasts that revenues will have a compounded annual growth rate of 36% from 1998 to 2005. Yet so far, growth has been more modest, in spite of the tremendous implicit potential of the sector to shorten development times and increase quality. Two factors are mainly responsible for slower acceptance: the lack of a standard language for constraints and properties definition and EDA companies’ initial focus on behavioral synthesis. The lack of standards means that available EDA tools for ESL design are fragmented and cannot easily cooperate. Because constraints are likely to apply to more than one tool, the lack of standards discourages the generation and propagation of constraints (Reference 1).

Like formal verification 10 years ago, behavioral synthesis is in trouble because the results are suboptimal and tools are difficult to use properly. When most engineers can design more efficient hardware than EDA tools can generate, EDA tools loose credibility in the market. Engineers no longer purchase or use the tools or even consider buying tools in the same category. As with all pioneering tools, Behavioral Compiler from Synopsys has had its problems. Unfortunately, Synopsys is such a respected synthesis company that its prematurely released product caused engineers to believe that behavioral synthesis was impossible or not useful in most cases. You can argue that designers can always generate a better RTL (register-transfer-level) description of a design than an EDA tool can. The knowledge and experience of a top designer is difficult to reproduce in a software program. But getting equivalent results faster is valuable, and RTL synthesis has been a resounding success.

Get2Chip is another EDA vendor that has addressed behavioral synthesis with its Volare product, which aims to provide synthesis at various levels of abstraction. The portion of the tool that addresses the ESL space explores the design by allowing a user to vary bindings among blocks, signal-propagation latency, number of RAM ports, optimum location of operations and state machine among blocks, bus widths, and degrees of pipelining. You might think of these operations more like architecture optimization than synthesis. Because Volare accepts designs written only in Verilog or Co-Design’s Superlog, it has not received great market acceptance. Verilog is not very useful at the architectural level, and Superlog is too new and still evolving. Given the widespread availability of mixed HDL (hardware-description-language) simulators, it is surprising that EDA vendors have not supported VHDL for architectural design and then produced Verilog for RTL.

To synthesize a design, engineers specify constraints and are rethinking the purpose of behavioral synthesis. As a result, this class of products may see the same resurgence that formal verification is now experiencing. The semantics of a design at a high level of abstraction is difficult to understand because design intent is purposely vague. It would be better if behavioral synthesis concentrated on distilling functional blocks, interfaces, constraints, and properties and set up a framework to maintain a relationship among the fundamental architectural properties and the various levels of design implementation.

In the last two years, the industry has written and debated extensively about the use of C and its derivatives for hardware design. C and C++ do not offer any semantic or syntactic improvements over Verilog and VHDL when it comes to hardware design. The attraction of C-based design is simply its greater simulation speed that is achievable using C and the availability of a free C compiler. Unfortunately for designers, once the design is proved in C, the choices of tools to translate the representation into a product that you can fabricate are few and vendor-dependent. All available synthesis products that use C as the input language require a dialect of the language that has hardware-description capabilities similar to those of HDL.

Most engineers begin their designs at the RTL due to the popularity of HDLs, such as Verilog and VHDL. VHDL allows the definition of constraints through its assertion and package constructs. The latest version of Verilog has also incorporated assertions into the language, but only a few tools can currently support it. Much of the design’s functional constraints are still embedded in the RTL code. To check their presence and implementation conformance without using time-consuming simulations, engineers use formal verification tools, such as those that 0-In, Real Intent, and Verplex provide. These tools allow users to statically verify that the design meets certain constraints. Therefore, it would be helpful if you could automatically transform the constraints in the original product specification into the assertions that formal verification tools require.


CONSTRAINTS IN PC-BOARD DESIGN
Although Innoveda is pioneering the use of HDL in pc-board design, most engineers still use schematic entry to begin pc-board design. Contrary to IC design, which closely follows the progress in optical and manufacturing technology and obeys Moore’s Law, pc-board design covers a much wider area of capabilities. Therefore, the types of constraints that are challenging designers vary considerably. For most pc-board designers, the constraints fall into the performance and the manufacturability categories. Constraints that are related to performance are signal-propagation delays, clock frequency, and power consumption. Manufacturing constraints include trace and component placement, as well as component type. Engineers that are developing more advanced pc boards have to also deal with a host of electromagnetic issues.

Ansoft offers a signal-integrity suite that allows designers to investigate the impact of board structures, stackups, materials, technologies, and design rules on routing when you consider frequency-dependent electrical parasitic properties. Therefore, you can analyze constraints you specified during design entry and transmit the appropriate directives to the place-and-route tool.

Cadence Design Systems offers a constraint manager that provides a spreadsheet interface to design rules combined with hierarchical rule management. The constraint manager integrates with design capture, physical design, and simulation tools to allow engineers to capture, manage, and validate high-speed design rules at all stages of the design cycle.

The constraint management from Electronics Workbench spans its Multisim, Ultiboard, and Ultiroute product. Ultiboard checks pick-and-place machine constraints when placing components. Multisim can calculate peak current during logic simulation and direct Ultiroute in properly sizing the traces. Designers can manage mechanical constraints by using a CAD drawing package to explore area and shape constraints before beginning the place-and-route process. Mentor Graphics allows designers to enter a number of constraints using the schematic editor and pass them to the place-and-route tool. In addition, it offers the Tau board-level timing-verification tool and the ICX interconnect- design-and-verification product. When you use them together, the products support high-speed-board design. ICX provides an environment for signal-integrity analysis during layout, whereas Tau performs timing analysis and verification on either a schematic database or a pc-board-layout database.

Zuken offers the Board Integrity Solution suite that allows engineers to experiment and investigate signal performance during design. You can investigate and constrain design parameters, such as crosstalk, interconnect delay, overshoot limits, and characteristic impedance.

Cadence seems to have an advantage in the area of constraint management for pc-board design by providing a product that targets the problem and spans levels of design abstraction. Most EDA vendors still focus on improving the predictive capabilities of analysis tools or the accuracy and performance of verification tools. Such improvement is welcome, but progress cannot be limited to it.


PHYSICAL CONSTRAINTS IN ICs AND ASICs
Whether you are developing a standard IC or an ASIC, physical constraints have become the most important aspect of IC design. Engineers have dealt with constraints definition and management since the introduction of synthesis. Synthesis programs required directives to optimize the resulting logic. Not so many years ago, designers worried mostly about area and propagation delays, so the trade-off was between a fast and large circuit versus a small and usually slow circuit. As physical effects, such as signal integrity, became more relevant, designers introduced new constraints. Given that Synopsys has been the market leader in logic synthesis for a dozen years, the EDA industry has accepted its constraints-definition format as the standard as well as its Liberty (.lib) cell-library format.

As semiconductor-process geometries progressed to less than 0.25 microns, logic synthesis proved insufficient. EDA companies developed physical synthesis, combining logic synthesis with cell placement, which permits the integrated use and management of physical and timing constraints across these two steps of the design process. Synopsys’ Physical Compiler will eventually replace Design Compiler to allow designers better control over the resulting silicon. But placement alone is not enough. Many of the constraints violations in modern designs result from routing results, so integrating the router in the process is important. Cadence has taken this approach by combining its SE (Silicon Ensemble) with its PKS (Physical Knowledgeable Synthesis). The SE/PKS environment manages top-down and bottom-up properties and constraints. It generates and optimizes logic while working on a number of constraints. Although Synopsys last year announced its own router, its proposed purchase of Avanti will provide it with industry-proven routing that will enable the company to try to match the functions that Cadence offers.

A number of other vendors have introduced constraints-driven products for IC design. Although designers cannot find a product that provides constraints and properties management for IC design, the attention that a number of vendors give to design-constraints handling indicates that such a product may be commercially viable.

Celestry provides tools that allow the accurate calibration and modeling of a cell library. Semiconductor vendors can use a Spicelike simulator, UltraSim, and Nautilus-VT to provide the correct parameters and values to designers to use in setting relevant constraints in their designs.

Incentia offers DesignCraft Pro, a physical-synthesis solution that simultaneously performs both logic and physical optimization from an RTL description. The company sees the lack of a true industry standard for constraints definition as a significant obstacle to increased efficiency in IC design.

Monterey Design Systems has developed its System-Driven Physical Design methodology. Its aim is to move critical physical details to early planning stages, establishing a top-down constraints-driven approach for IC design. IC Wizard provides hierarchical block-based physical-design planning and generates the timing constraints for block implementation. Sonar provides physical-prototyping capabilities that allow the validation of design properties before final routing. Dolphin automatically implements the final routing according to the constraints that IC Wizard and Sonar developed.

Recognizing the importance of physical constraints in chip routing, Plato Design has incorporated both a signal-integrity and an RC-extraction engine with the NanoRoute product. The resulting system deals with not only timing constraints, but also power, noise, and manufacturability rules.

Sequence Design’s PhysicalStudio helps engineers concurrently predict and correct chip-timing, power, and signal-integrity issues before and after routing. It allows the hierarchical optimization of designs at the block level as well as at higher levels of abstraction.

All of these vendors have acknowledged the importance of constraints and offer constraints management limited to their tools. But designers are still left with the difficult task of solving the syntax and semantics differences among tools.

TransEDA has developed the Verification Navigator system, which provides an integrated properties-management system that allows dynamic property checking at various levels of design abstraction. In addition to the library of properties that TransEDA offers, engineers can also add their own constraints definitions by writing Perl scripts that Verification Navigator integrates into the library.

Both IC and pc-board designers are still waiting for a true data-centric design environment that will allow them to focus on the design and not on the required tools.


REFERENCES
1. Moretti, Gabe, “System-level design merits a closer look,” EDN, Feb 21, 2002, pg 43.


STANDARDS FOR CONSTRAINTS MANAGEMENT
Most of the work that standards-making organizations do in areas involving design constraints supports IC design. Any design intended to be fabricated with a technology using a resolution of less than 0.25 microns demands that engineers solve a host of electrical problems involving signal integrity, crosstalk, power distribution, and coupling capacitance.

One of the organizations active in this area is the SI2 (Silicon Integration Initiative). The group has two projects directly involved with improving the use of constraints in IC design. One project, OLA (Open Library Architecture), has been active for a few years. The work is based on a previous standard called SDF (Standard Delay Format) that Open Verilog International (now Accellera) developed. OLA aims to provide an API that EDA tools can use to determine cell and interconnect characteristics of very-deep-submicron ICs using a semiconductor vendor “golden” delay calculator.

Other relevant work, OpenAccess, is based on the Genesis database that Cadence Design Systems donated in February. The goal is to allow greater tools interoperability by constructing an API to the database and then allowing access to the source code of both the database and the API through an open-source licensing system. The major problem with this approach is that it is tool-centric and not data-centric. But an approach that provides an improved method of interfacing various point tools to the design database offers a better foundation on which to build a constraints-management system than with what is available today.

Accellera is also working on improving the way to handle design constraints. One of the activities, ALF (Advanced Library Format), is similar to OLA. The objective is to provide a standard specification for generating models for use in timing, synthesis, power and test analysis, and signal integrity. The board of directors of Accellera has approved Version 2.0 of the specification and has submitted that document to an IEEE working group whose goal is to produce a standard. A standard for incorporating design constraints in a model would be helpful to designers, because a common way would exist for handling constraints and properties in models. ALF does not go far enough, because the management of constraints is not in its mission, but it is a step forward.

Accellera is also sponsoring Rosetta, a system-level design language developed to address requirement specification. Rosetta will allow designers to develop and integrate specifications written in multiple semantic models. The language has undergone a number of alpha tests, and a proof of suitability is planned for the Design Automation Conference this June. The language will allow designers to better manage constraints by localizing them and expressing them in a computer-readable form. The drawback is that it is yet another language that people unskilled in programming may have difficulty learning.



You can contact Technical Editor Gabe Moretti at
(1) 303-517-2328
E-mail gabe@eda.org