A dynamic design estimation and exploration environment

Abstract

many techniques that can be used to obtain estimates of power, so the design environment has to dynamically resolve which technique to use, based on all given parameters and constraints. The more constraints a designer gives, the more accurate or detailed the estimation can be, limited only by the available estimators.The observation that estimations generally are limited to a specific knowledge domain inspired the organization of estimation techniques, and all related parameters, constraints, etc., into entities called "domains".Definition: A "domain" is an encapsulation of knowledge regarding a specific design-related area of expertise. The knowledge which is captured in a domain includes parameters, constraints, tool encapsulations, file type definitions, etc. Domains are discussed in detail in section 3.1. A domain is intended to capture one dimension in the design space (e.g. architecture, cell library, technology, etc.), and domains can derive from other domains to capture increasingly confined portions of a particular dimension.By bringing together orthogonal domains, (i.e. domains that represent different dimensions in the design space) we can create a "context" which contains knowledge in the dimensions represented by the domains. This knowledge is as general or specific as the domains define.Definition: A "context" is a union of domains. Each design, or portion of a hierarchical design, has an associated context. The context can either be chosen by the designer, or it can be automatically chosen by the design environment, based on what is known about the design (parameters, constraints, properties, etc.). Intuitive commands are interpreted within a context, i.e. it is resolved what the meaning of a command is based on the knowledge contained in the union of domains.Example: To illustrate how intuitive commands are interpreted, consider the nine domains shown in figure 2. The six domains on the bottom are derived from the more general domains on top. The four sample contexts show by example how the command "area" is interpreted based on which domains are in the context.The presented environment offers ubiquitous access through the world wide web (WWW) to allow designers to use the environment remotely, for example from a portable terminal. The environment has a flexible application programming interface that allows a variety of external user interfaces to be used. In addition, since information resources and design data are becoming increasingly distributed across both the internet and company intranets, future versions of our design environment will be able to communicate with each other to share and reuse information and knowledge.Previous efforts in this area includes the work presented as "Clio", which offers design assistance within the Odyssey CAD framework [1][2] [3]. In Odyssey, knowledge is also organized in domains, but different domain hierarchies are not "orthogonal", i.e. representing different aspects of design. Thus, a context is represented by one domain, instead of a union of domains, an...