The Conceptual-Level Design Approach to Complex Systems


ion: A methodology based on the conceptual-level of abstraction enables a number of complimentary tasks to aid the integration of a design flow. Firstly, and perhaps most important, it provides a means to integrate estimations from many tools into a single environment. Secondly, supporting high levels of abstraction enables a flexible system where during the early stages of design there is no restrictions on how a design is described. There are trade-offs, however, in that there are no checks on functionality, and there are time penalties of later translation into compilable descriptions. Until (if ever) there is a single means to describe a system which can be used by any tool this type of abstraction will be necessary. 2.4 Related Work in Conceptual Level Design and CAD 15 2.4 Related Work in Conceptual Level Design and CAD Though there is innumerable work at later stages of the design process, relatively little work focuses on the earliest stages of the design. As a large part of conceptual design requires abstraction of knowledge from these lower levels (e.g., structural, technological). Useful work from these levels is an integral part of the proposed methodology and will be referred to throughout the thesis when applicable. A limited number of tools do address (implicitly or explicitly) some of the principals of conceptual-level design. This section outlines some the most relevant of these works to the environment proposed in Chapters 3 and 4. 2.4.1 Equation Based Tools Perhaps the most standard early design method is to make sketches and simple equations. Hence the first conceptual design tool may be the calculator. For more complex systems, equations can still be used, but a more rigorous approach and tools are required. As will be discussed in Chapter 3, equation based tools will remain useful at the high level. They provide a significant freedom for design choices. However, their scope is limited to area where estimates can be performed using equations. The integration of this type of tool into an environment is one aspect of the proposed environment. Spreadsheets As will be shown, spreadsheets are an essential tool at the early stages of design. Hence early tools, such as VisiCalc and Lotus 1-2-3 [4], can be considered the first conceptual-level applicable tools. An intuitive interface is a necessity at the conceptual-level, hence Microsoft’s Excel spreadsheet[5], which has become a recent standard, is perhaps the most user friendly. Inclusion of O.L.E [6], which allows tools 2.4 Related Work in Conceptual Level Design and CAD 16 to be embedded inside other tools in the Windows environment may become a highly useful addition to this system. Analytic Tools Tools that aid in the solving of simultaneous equations are useful at the early stage of design. Matlab and Mathematica are perhaps the most common tools in this area. Matlab’s use of the “toolbox” allows customization for specific types of design. In affect this provides a limited form of design re-use. Matlab and Mathematica, though useful in the early stages, have most of their advantageous in the simulation of a system and do not provide aid in evaluating the costs of design choices. Design Sheet[7] Perhaps the first system focused toward electronic design to target the conceptual level explicitly is Rockwell Corporation’s Design Sheet. It is an environment focused on solving a series of constraint driven equations: “Design Sheet is a conceptual design system that integrates constraint management techniques, symbolic mathematics, and robust equation solving capabilities with a flexible environment for developing models and specifying trade-off studies. It encourages designers to explore a wider range of the design space than might otherwise be feasible.”[7] This work accurately identifies the importance of the early stage of the design process and also properly focuses on trade-off analyses. Though focusing solely on equation based estimation, it also provides a means of model creation supporting design re-use. Figure 2.3 illustrates the interface in the design sheet for describing constraints, and interfacing with models. As can be seen, this system provides a means for describing and analyzing very complex systems of equations. Therefore each design 2.4 Related Work in Conceptual Level Design and CAD 17 element requires an equation based description of constraints that are described in the same time domain so that they may interact in a meaningful manner. This description method enables rigorous analysis early in the design cycle, therefore such a system is not applicable to designs where these constraint driven equations do not exist or are hard to create. For a complex mathematical system this approach can be very useful, but for a more heterogeneous structure, this requirement may be prohibitive. As the Design Sheet is developed it may prove to be a valuable early verification tool, however it clearly requires to much detailed description to support early design decisions. Figure 2.3 Design Sheet’s constraint network and top-level interface[7] 2.4 Related Work in Conceptual Level Design and CAD 18 2.4.2 Graphical Environments The ability to provide analysis directly from a sketch may be valuable at the early stage of the design process. Though focused primarily on the behavioral level of digital systems, the Ptolemy project demonstrates many aspects useful for conceptual design. Ptolemy [24] Ptolemy is a research project and software environment focused on the design of reactive systems. It provides high-level support for signal processing, communications, and real-time control. The key underlying principle in the project is the use of multiple models of computation in a hierarchical heterogeneous design environment. The Ptolemy project, though focused solely on a DSP design space, exhibits an intuitive interface toward building a heterogeneous design model. Functional blocks, which can be described using a behavioral language such as C or silage, are represented by simple graphical blocks termed stars. Hierarchy is captured through the use of blocks termed galaxies which can be made up of other stars or galaxies. Heterogeneity is addressed by allowing the designer to arbitrarily partition their design to any number of stars or galaxies. Edward Lee identifies that there are counter goals to a design system. A design environment tries to support expressiveness and generality yet also must to support a system description which is both verifiable and either compilable or synthesizable. The choice of where a system tool should focus in this dichotomy most clearly defines the difference between the work proposed in this thesis versus Ptolemy and most other previous works. The conceptual-level system provides greater expressiveness at the expense of compilability or synthesizability. 2.4 Related Work in Conceptual Level Design and CAD 19 2.4.3 Non-electrical Based Domains One of the aspects of conceptual design is that it spans different domains. Electro-mechanical systems, for example, may often best be explored by abstracting away most details. Therefore it is not surprising that other, non-electrical domains, have also explored some aspect of conceptual design. It is worth noting that in many fields the term conceptual level is synonymous to the electrical engineering behavioral level. A prime example of conceptual-level design is the electrical-mechanical work of the Domain Unified CAD Environment (DUCADE) [23]. In this project, the authors unify the mechanical and electrical domains. Currently, Joint research on DUCADE is being conducted between the Wireless Computing Consortium (WCC) and the Integrated Manufacturing Lab (IML) at the University of California at Berkeley. This design environment will serve as a platform for the inter-disciplinary design of wireless computers and similar consumer products. Research focuses on tool integration and the development of a uniform database. Figure 2.4 DUCADE: A mechanical and electrical view of the same system[23] 2.5 Conceptual Design Methodology 20 Like this work, DUCADE is determining that the key to getting heterogeneous structures to interact is through the abstraction of all but the key components needed to solve a specific design problem. Figure 2.4 illustrates two views on the same system. On the left, is a view of a mechanical box being designed to fit around an electrical circuit board, which is shown on the right. Complex elements of the electrical board tool, regarding size and strength for example, needs to be communicated with a vastly different mechanical tool. This mechanical tool must interpret this information and be used to design a box which meets a number of non-electrical design constraints. 2.5 Conceptual Design Methodology As Example 1 illustrates, at the conceptual-level there is some concept of both the behavior and the structure. The key challenge is to relate these types of incomplete specifications to meaningful analyses of costs and constraints, thus enabling designers to make important decisions and trade-offs. This section describes the conceptual design methodology as it is usually done intuitively by designers. The intention is not to change this methodology, but to create tools and an environment which increases the speed and effectiveness in which this part of the design process is accomplished. The traditional methodology utilized at the conceptual level is a highly iterative process which can transcend the following trajectory in a number of ways: 1. Problem Formulation: The first step is to determine the desired properties of a design. This is in effect defining constraints and goals. 2. Rough sketch: A rough sketch is made of a possible implementation(s). This is usually a block diagram, pseudo-code, or a combination thereof. The design is now represented as a collection of interconnected sub-blocks. The sub-blocks are functional and/or behavioral. (Examples of sub-blocks are multipliers, FIR filters, 2.5 Conceptual Design Methodology 21 subroutines, comparators). The interconnections of the sub-blocks can be a representation of data flow, or contain physical information about connectivity. 3. Verification: At this point the designer will usually verify to the best of their ability the functionality of their design. With limited information, conventional simulators often can not be used. Therefore some form of verification is usually done by hand. This often takes the form of a worst case analysis. Tools to aid in this process is beyond the scope of this paper, but is a focus of future work. 4. Evaluation: Evaluating the design with respect to constraints and goals is the next step. This stage is the primary focus of this work. The evaluation process can be broken into the following steps: a. Sub-block estimation: At this point there is some information about the behavior and the structure of each sub-block. This must now be combined with information about the implementation platform(s) being considered. Traditionally this is done in a number of ad-hoc ways varying from estimations based on intuition, to extensive simulations of critical sub-blocks. Each small change in design can necessitate a long re-evaluation of some or all of the sub-blocks. Examined more rigorously, for each of the blocks a model F(input parameters) is evaluated, where the input parameters give information about the behavior and/or structure and the function, F, produces estimates on cost. b. Overhead estimation: Overhead (e.g., interconnect, controller, memory etc.) must be evaluated in the same manner. The output of one function may also be input parameters of overhead. For example, area of interconnect will be a function of the area of the rest of the circuit. Evaluating sub-blocks and overhead involves modeling the information known about each block’s implementation as a function of input parameters. Due to the 2.5 Conceptual Design Methodology 22 complexity of estimation, this step is often skipped in the traditional design flow. As line-widths shrink and speeds increase, this overhead, be it capacitance in a digital circuit, or noise effects of an analog circuits, dominate performance. Therefore neglecting this overhead will not be an option. c. Design estimation: The costs of each sub-block are then combined with the overhead analysis to give estimates of cost for the entire design. In the case of power, this involves simply adding the power of the sub-blocks. In other cases this analysis may be more complex (e.g., timing, inductive effects). 5. Analysis and evaluation: The design costs are then compared with the constraints and goals. The most common technique is identifying sub-blocks of the design which are the most costly, so design time can be focussed appropriately. The design environment should aid in this identification. Iteration back to any of the previous steps is common: The structure may need adjustment, or other structures need to be considered(2). It may become necessary to change constraints and/or goals (e.g., increasing timing budget)(1). Different implementation platforms maybe tried by simply switching in different models (e.g., switching in a different type of multiplier)(4). Behavior and architecture is often changed by simply changing input parameters (e.g., bit-widths, memory size)(4). In effect, the goal of the methodology is to combine incomplete behavioral, structural and implementation information to get the most information possible to aid in making crucial conceptual-level decisions. Absolute accuracy is obviously not possible. However, the important goal is to determine both rough order of magnitude estimates and relative estimates. Questions which are answered at this stage are “Which design choice is better?” or “Will this keep me within my cost budget(s)?”. Experiments have shown that both of these questions can often be answered at this level of abstraction [55]. 2.6 Challenges at the Conceptual Level 23 2.6 Challenges at the Conceptual Level 2.6.1 Problems With Current Methods Conceptual-level design has traditionally been done by hand analysis in an adhoc manner. For every iteration through the analysis process, a designer makes a great number of timely and often inaccurate estimations. These estimates are often performed through: Time consuming hand analyses: Sub-blocks are often modeled with an equation or groups of equations. Each time a designer changes even a simple parameter each subblock’s equation must be recalculated. Databooks: For off-the-shelf components, a designer may leaf through available databooks. Each change in a sub-block requires data to be rechecked. It also restricts estimation, and perhaps design, to parts for which exists data. Tool calls: A designer may run lengthy estimation(s) to analyze a sub-block. This must be redone each time a change is made. Tool calls are restricted to tools the designer uses and has available. Many options may go untried if the time to run, and perhaps learn, a new tool is prohibitive Intuition and approximation: When the above methods prove too time costly, a designer may rely on their intuition. For example s/he may know that a multiplier takes approximately 50 nsec to execute. This method relies heavily on the experience of the designer, and is obviously only a rough estimate. 2.6 Challenges at the Conceptual Level 24 2.6.2 Challenges of complex system design at the conceptual-level The properties of modern day systems further complicates the design process and must be considered in developing an environment. This section outlines several key properties of complex systems, and the associated challenges they create in conceptuallevel design. Heterogeneous systems are made up of many different types of entities. Heterogeneity resides at many different levels and can relate to types of functionality, implementation platforms, and ways of connecting components together. Heterogeneity presents many challenges to both the designer and the design tools. Different types of entities are analyzed and designed using different methods and different tools. A conceptual-level environment must enable smooth transitions between tools, as well as provide a means to make comparisons of cost across implementation platforms. Hierarchical systems are composed of smaller (heterogeneous) objects. For example, a portable device can be seen as composed out of separate entities such as the radio, processor, display, keyboard, etc. Each of these entities are also compositional (e.g., the radio can be partitioned into a a transceiver, transmitter, ADC, mixers, etc.). In complex systems, hierarchy transcends many layers creating several challenges. The higher the hierarchy level, the further the designer is removed from the actual implementation and the harder it becomes to get reasonable information about cost and performance. Varying abstraction levels further complicates the design process. Any given object at any hierarchy level can be described at various abstraction levels. This impacts the information that can be obtained about this object (and its accuracy) and what operations or actions can be performed on it. For example, getting power estimations for a piece of behavioral VHDL code is different (and typically less 2.7 Roles of a Conceptual-Level Environment 25 accurate) from getting an estimation from a structural VHDL description of the same object. Throughout the design process, abstraction levels tend to change as a design is further defined. This change in abstraction level must be tracked. A means to compare cost functions across abstractions in a meaningful way is important in system tools. Many designers: The more complicated the system, the more designers are required. Combined with the increasing size of design companies, the use of design consultants, and the rise in telecommuting the challenge of design flow increases. The challenge of bringing together more designers, at greater distances, working on many different types of computers will be a prime obstacle to present and future design teams. 2.7 Roles of a Conceptual-Level Environment The goal of the conceptual design environment is to provide means to make the early analysis process as quick and accurate as possible. By speeding up the estimate process the designer may go through more iterations and therefore focus their time on making critical decisions. The environment must also provide means for analyzing, and cost budgeting, complex systems throughout the design process. In addition to addressing the four challenges described in the previous section, a conceptual-level environment should aid in: Design evaluation: Once an estimate is found, the tool should relieve the designer from the task of evaluation. Estimations should be performed so as to relieve the designer of the tedium of equation evaluation, tool execution, etc. 2.8 The Conceptual-Level Design Environment 26 Design entry and manipulation: It should be easy for designers to enter their designs. It should also be easy for a designer to choose to switch how they evaluate each sub-block to track design changes. Data display: The data should be displayed in a way so that designers can identify the areas which need optimizations. A number of means should be provided ranging from ordered lists to various types of graphical representations. Data management and information gathering: A designer needs to keep track of different options in order to compare optimizations. The ability to archive a view of a design in process, as well as integrate documentation in an intuitive manner, is a necessity. Estimation creation: An estimation for a specific block may not already be in the framework. It should be easy for a designer to characterize and encapsulate new sub-blocks. 2.8 The Conceptual-Level Design Environment One goal of this thesis is to provide a framework for describing and evaluating designs at the conceptual-level of abstraction. This section lists the primary subcomponents of said system. The following sub-sections describe the important subcomponents of such as system. Parts of this proposed environment are similar to current CAD environments (for example, data management is an important aspect of any CAD system). Designing complex systems requires a number of specialized CAD functions incorporated into a unified framework. It is a primary tenet of this work that the re-deriving of specialized tools is not only impractical but infeasible. 2.8 The Conceptual-Level Design Environment 27 As technology changes so do the requirement of a CAD system. Hence a CAD tool has to be flexible to incorporate not only existing, but future work. In this thesis, related and useful work has been incorporated, with modifications as necessary. There are several key requirements for this level of design which have not received adequate attention and has been the primary focus of this work. Macromodeling at the conceptual stage of design (Section 2.8.1) and the use of hyperlinked spreadsheets (Section 2.8.2) have primary focus and are also explored in Chapters 3 and 5. The use of the WWW to facilitate design (Section 2.8.4) is also a key aspect of this work and will be described in Chapter 4. 2.8.1 Macromodeling (Chapter 3) The concept of macromodeling is the key enabler for providing the flexibility and adaptability required of a conceptual-level environment. Macromodels are the primary components used in evaluating costs of a complex system. In particular, analysis of heterogeneous systems and reuse are strongly supported with this approach. As will be seen, the macromodel approach provides the basis for an adaptive environment where changes in technologies and design goals will not necessitate a change in the design environment. Before describing the different tools in the environment, macromodels at the conceptual-level should be defined: Definition: A macromodel is a model which presents a quantified view of one or more cost metrics of a design as a function of a set of specification parameters. A macromodel can take on many forms: it can be represented by a fixed number, a table, a set of equations, an invocation of a tool such as an estimator, or it can be composed of a set of other macromodels. 2.8 The Conceptual-Level Design Environment 28 The main benefit of macromodels is that they may be used as a black box so that a designer interacts with designs in the same manner regardless of the subcomponents. Heterogeneous subcomponents can be evaluated by using orthogonal macromodels so that one can analyze a switch of implementation platforms simply and quickly. For example, using macromodels, the effects of changing a hardware library can be instantly evaluated without rewriting the behavioral or structural description. A macromodel presents a uniform entry of inputs, and return of outputs, regardless of the method used to calculate the outputs. Regardless of the type of estimation being evaluated, the user interacts with a macromodel in the same manner. Every analysis is just an entry of input parameters. It is up to the environment to interpret the input parameters, find the proper macromodel, evaluate the macromodel, and provide the estimate(s) to the user in a meaningful manner. The environment should also aid designers in incorporating new models into the environment. Macromodels can take a number of different forms. The primary primitive forms are analytical expressions, tables and estimators: Analytical expressions are used often to model a cost function as a function of any number of input parameters. It provides a flexible, and potentially highly accurate, means to analyze a block quickly. For example, power of a multiplier can be modeled as a function of the bitwidths of each multiplicand. Further accuracy can be attained by using details about input vectors if available. Constants, for example a constant current for a given amplifier architecture, are also classified as an analytical expression. Tables are useful for both nonlinear functions and for off-the-shelf components. An analog to digital converter (ADC) for example, can often not be characterized by simple equations, but can be pre-characterized for different precisions. 2.8 The Conceptual-Level Design Environment 29 Entire data books can be encapsulated into tables to enable fast estimation of discrete components. Dynamic models are estimators and predictors that can be used in a number of different situations. For most critical components a transistor level model may be necessary. In addition, to determine important behavioral characteristics, mathematical tools (e.g., Matlab) can be encapsulated into a model. Definition: A composite macromodel is a combination of primitive and other composite models and the description as to how they interact Perhaps the most important aspect of macromodels is they can also take the form of a (complex) combination of other macromodels. For example, a system may be a represented by a single macromodel consisting of a model of each subcomponent. In turn this same system’s macromodel may be combined with other models to “produce” a macromodel of a complex system. Regardless of the complexity of any of the models, designers interact with each of them in the same manner. This supports intuitive interaction with the environment during the early creative stages. Composite macromodels provide a conceptual-level representation of a system. All aspects of composite models are defined and explored in Section 3.3. Building and analyzing systems using composite macromodels is the focus of all of Chapter 6. 2.8.2 Hyperlinked Spreadsheet With Macromodels (Section 4.1) The spreadsheet is where the designer does most of their analysis. It is used to bring together and manipulate all the heterogeneous components in one framework. A list of all elements, with attributes enumerated, is a powerful means of tracking the status of a design, identifying bottlenecks, and evaluating effectiveness of 2.8 The Conceptual-Level Design Environment 30 optimizations. This thesis introduces a new more powerful spreadsheet which utilizes both hyperlinks and macromodels. By enabling interconnections of the elements, a powerful composite model can be described. As will be described in Section 4.1, a hyperlinked spreadsheet combined with a macromodeling technique will enable a designer to: • Evaluate designs across platforms (addressing a system’s heterogeneous nature) By modeling heterogeneous elements with orthogonal macromodels, and linking their inputs and outputs, the proper means of evaluation for each of the subcomponents can be utilized. • Evaluate designs throughout the design process (addressing a system’s varying abstraction levels) Macromodels which give a more accurate view of the final implementation may by utilized so that as the design evolves, the tool required does not change, just the models utilized. • Get hierarchical views of a design Nested spreadsheets are used to mirror the hierarchy of a system and hence give a natural view of the design. • Integrate the work of many designers in one framework. Many designers can work on subcomponents of a system, in a sense owning different macromodels, which can in turn be encapsulated in a single (or collection of) spreadsheet(s). In this means parallel work can be done and collected in a single environment. 2.8 The Conceptual-Level Design Environment 31 • Design flow management and cost budgeting (easing documentation and information transfer amongst designers). Documentation can be linked into the spreadsheets providing a single, yet expandable documentation focal point. Design managers can use a central spreadsheet(s) to perform cost budgeting and to track the progress of a design. The following example presents the basic properties of the hyperlinked spreadsheets and macromodels. Example 2 Hyperlinked spreadsheet and macromodels Figure 2.5 shows a spreadsheet analysis of the voltage regulation system of example 1. The analysis is from the conceptual-level tool PowerPlay[55]. Each spreadsheet has the general format seen in this example. Each row represents a sub-block of the example. The left column has the name of each entry. The second column allows the user to enter the parameters for each entry. The right hand columns are used to report information about the analysis to the designer. In this case, power is the cost function. Global parameters are defined in a box at the bottom of the spreadsheet. This spreadsheet is used as an interactive tool during the conceptual design process. At any time, blocks can be added or subtracted, or parameter values changed. To see the effect of a design change, the designer simply clicks the play button to get immediate feedback. 2.8 The Conceptual-Level Design Environment 32 The spreadsheet tool, in this case PowerPlay, evaluates the macromodels associated with each of the line entries and then categorizes and sums all the information for the designer. At any time the designer can choose new models for a block entry and re-evaluate. There are no restrictions on the type of models that can be included on any sheet. By partitioning the analysis into macromodels, the problem of heterogeneity is solved. The first two lines of this example (the reference voltage and comparator) are analog circuits modeled by equations. The following line is the analog to digital convertor (ADC) which is not a linear function of its input parameter, resolution, and should be evaluated by a table look-up. The digital circuitry, and power transistors, are modeled by a tool call to an estimator. If parts of the circuitry were further along in the design process, a macromodel appropriate for that level of abstraction may be used. Figure 2.5 Spreadsheet analysis of power dissipation of Example 2 2.8 The Conceptual-Level Design Environment 33 To facilitate both reuse and hierarchy, any spreadsheet may be encapsulated into a single macromodel. In other words this entire spreadsheet may be encapsulated into a single line and incorporated into another system. When the macromodel for a spreadsheet is a line-entry in another spreadsheet, the name in the left column is a hyperlink to the appropriate spreadsheet. When the play button is clicked, all levels of hierarchy are evaluated. Parameters are passed down to lower levels. There is no fundamental limit to the depth of hierarchy allowed. This utilization of hierarchy will be shown in section 5.2. For each sub-block in the spreadsheet, there are hyperlinks to documentation about the block and information about the macromodel. There is no restriction on the location of the model or the documentation so designers and models (and their associated tools and databases) can be located wherever is most appropriate. Finally documentation may easily be put on to a spreadsheet, and spreadsheets may be archived at any time. This makes it a useful tool for tracking design decisions and design flow. The outputs from the tools can be forwarded to a graphing tool to aid in analyzing the “problem” blocks. In addition, exploration can be done at this level by varying a local or global parameter and graphing the effects on the cost functions. 2.8.3 Macromodel Creation (Chapter 3) A design system is only as good as its underlying models. The design system can not rely on a fixed set of base models as system requirements are unpredictable and unlimited. Instead, the design system should enable the creation and inclusion of 2.8 The Conceptual-Level Design Environment 34 models as necessary. In addition, the system should encourage reuse and facilitate the sharing of models. An important part of the design environment is to enable the inclusion of any type of model. Mechanisms for this are given in Chapter 4. Section 3.4 details guidance as to how to create new models and include error metrics. 2.8.4 Distributed Infrastructure (Section 4.2) In order to bring together the different models and any number of designers, a distributive infrastructure is required. The Internet, and the World Wide Web (WWW) in particular, is the enabling technology to achieve this unification. To enable a designer to work where they want, using whatever computer they want, design tools should be made “web-compatible”. Tools, customized for the Internet, can exploit the features of the WWW more fully than simply encapsulating existing tools. Fully utilizing the WWW will enable: • shared libraries and documentation across the network, promoting re-use • tools accessible across the network • enable many designers to interact regardless of location or computer platform. Both the size of design teams, and the change in work habits require that CAD tools be available across networks. In addition, the creative nature of conceptual-level design requires a comfortable and flexible environment. The WWW’s facility at information transfer, platform independence, as well as its wide user base, makes it a clear choice for a system design platform. The use of the WWW is similar to a client-server configuration with a number of important differentiators. Included among them is the lack of dedicated connections, limited graphical interaction, and the fairly primitive protocols for data transfer and 2.8 The Conceptual-Level Design Environment 35 display. All of the work in the proposed conceptual-level environment are designed to leverage off the strengths, and overcome the limitations, of the World Wide Web. Details of networked implementation details are given in Chapter 4. The next section details the use of generic block entry for design ideas. As an example of network design, a generic entry tool, WebTop[36], which is located in M.I.T., is integrated into the Berkeley based PowerPlay design flow. A designer can enter a design utilizing a server in Massachusetts, and then to perform their estimations the relevant information is transferred to the California server where the design can be further specified. The results of estimations can then be back annotated onto the schematic entry tool. 2.8.5 Generic Block Entry The first step in the design process, is the sketching of an idea. To address the heterogeneity of complex designs, the interface for this entry has to be generic enough to support any type of description. In addition, this interface should be simple to use. If ideas do not flow into a tool as naturally as to a piece of paper, important aspects of the design process may be sacrificed. The tool will either go unused or, if used, hamper the design process. A first prototype of a Java based block editor addresses many of these issues (Figure 2.6)[46].Sub-blocks and connectors can be sketched and given any number of attributes or values with no restriction. The interpolation of these attributes will be handled by the macromodels. The generic nature of entry is essential so that a designer can use the same interface independent of the nature of the system being specified. This enables heterogeneous systems to be entered. Global parameters may also be defined in this environment. 2.8 The Conceptual-Level Design Environment 36 The ideal input media of a conceptual-level environment would be a simple pen and paper. To really enable the same creativity used today would require the integration of a pen interface. 2.8.6 Documentation and Design Management With an increasing amount of designs and macromodels spread throughout the Internet, management of this information becomes a priority. The current method is to encapsulate knowledge inside the spreadsheet tool. For each macromodel there is information about how to find and execute estimations. Equations can be stored locally to either the server or designer. For a more complex tool call, a pointer to a script encapsulating the model is stored locally. The script is accessed and run in the background whenever analysis is requested. Tools may be executed either locally or across the network. In time, this solution will become prohibitively restrictive. The next generation conceptual-level design environment may thus utilize a separate design agent/proxy to handle model calls. For information on design agents, the reader is referred to [43][44]. The main task of an agent is to quantify abstract requests for information. A design agent will aid in locating, encapsulating and running tools across the network. Figure 2.6 Java block editor with parameter entry form[46] 2.9 Scope of Thesis 37 The use of a design agent will give more added value to conceptual level design. A design agent can perform searches. For example a list of LCD displays which sell for less than $200 and dissipate less than 500 mW can be assembled. The user can then choose the most appropriate LCD and include the macromodel in their design.

DOI: 10.1023/A:1007985108367

75 Figures and Tables

Cite this paper

@article{Lidsky1998TheCD, title={The Conceptual-Level Design Approach to Complex Systems}, author={David Lidsky and Jan M. Rabaey}, journal={VLSI Signal Processing}, year={1998}, volume={18}, pages={11-24} }