Design Management Using Dynamically Defined Flows

Transcription

1 Design Management Using Dynamically Deine Flows Peter R. Sutton*, Jay B. Brockman** an Stephen W. Director* *Department o Electrical an Computer Engineering, Carnegie Mellon University, Pittsburgh, PA **Department o Computer Science an Engineering, University o Notre Dame, Notre Dame, IN Abstract Many CAD rameworks now use the notion o a esign low to help provie methoology management services. Most lowbase approaches are limite, however, in that they involve a ixe sequence o operations speciie in avance, restrict esigners to using only those lows, an harwire speciic tools to lows. To overcome this, we introuce the concept o ynamically eine lows as tool-inepenent lows that are built up, on eman, by esigners. Dynamically eine lows can be use to provie a semantically rich means or browsing the esign history atabase as well as to provie support or multiple esign approaches, such as goal-base, tool-base, ata-base an plan-base esign. 1 Introuction As CAD Frameworks evolve rom managing only tools an ata to managing the esign process itsel, the concept o a esign low has become an increasingly popular ounation on which to buil such a ramework. In general, a esign low escribes a sequence o operations require to achieve esign goals. Most approaches to esign low management, however, have a restricte view o a low. Flows are oten static, speciying a ixe sequence o esign activities that the esigner is oten require to ollow step by step (escribe in [1] as a low straight-jacket ). Flows are also usually harwire to speciic tools, an hence require moiication whenever tool changes are mae or new tools are ae to the system. In our view, it is isavantageous to speciy the exact tool sequences that shoul be ollowe by the esigner in a creative esign process. The esigner shoul be given the reeom to move about the low as necessary in orer to accomplish his or her esign goals. In this paper, we introuce the concept o a ynamically eine low which is constructe rom a schema representing the epenencies between tools an ata. We show how this approach gives the esigner greater reeom in choosing how to go about the esign, even within the bouns o a ixe methoology. A secon point that we wish to emphasize with this paper, This work is supporte in part by the Semiconuctor Research Corporation an IBM. Permission to copy without ee all or part o this material is grante provie that the copies are not mae or istribute or irect commercial avantage, the ACM copyright notice an the title o the publication an its ate appear, an notice is given that copying is by permission o the Association or Computing Machinery. To copy otherwise, or to republish, requires a ee an/or speciic permission. is the inherent power o a low-base approach to esign management or organizing esign ata. This power arises rom the act that all esign objects are create through the execution o lows an that each esign object may be uniquely ientiie accoring to the sequence o tool/ata transormations use in creating that object. A consequence o this is that i lows are properly eine, queries into the erivation history o esign objects obviate the nee or aitional version management schemes. Further, we will show that by associating a small amount o meta-ata with each esign object, inicating the immeiate tool an ata use in creating that object, the complete erivation history o a esign may be store. The paper is organize as ollows. Section 2 presents an overview o previous work in esign low management. Dynamically eine lows are then eine an escribe in Section 3. Section 4 outlines how ynamically eine lows have been implemente in the Hercules Task Manager, part o the Oyssey CAD Framework [2]. 2 Previous Work Over the past ew years, numerous papers have appeare that aress esign management through lows. The einition an representation o lows as use in the JESSI Common Framework project [3] is airly typical o these. JESSI uses the term low to mean a preeine sequence o activities, where an activity represents a particular eature o a tool (taking speciic input ata an proucing speciic output ata). Flows eine the temporal interrelation between activities an can be speciie with either linear or branche connections. Design work is then carrie out by associating lows with cells in a esign. Similar constructs may be oun in the lowmaps use by Philips [4] an the Technical University o Delt [5], task templates by U.C. Berkeley [6], our oler task trees [7] an the more generic task graphs introuce in this work. Casotto [8] has eine the term trace to reer to a historical recor o a sequence o tool invocations an ata transormations that have been perorme uring esign. A trace may be consiere one example o esign meta-ata inormation about esign ata that was escribe in [5]. One o the main issues in low-base esign management is eciing which ata to assign to lows. The Philips Data Flow Base Architecture or CAD Frameworks [4] was the irst work to suggest that a esign erivation history base on lows may be suicient or organizing esign ata without the nee or aitional constructs. By storing low einitions an esign

2 meta-ata in a common atabase, van en Hamer an Treers were able to easily process queries such as in the simulations that were perorme or this netlist. Chiueh an Katz [6] use activity threas in a similar manner to assist esigners in ientiying neee ata. For example, i a esigner implemente a logic circuit using stanar cells an then wishe to re-implement the same circuit using a PLA, he or she coul reposition a cursor to the appropriate point in the stanar cell activity trace an create a new activity branch using a create PLA task. A secon issue in low-base esign management is eciing which activity to perorm next. The most restrictive option is to conine esigners to operate within preeine lows which may lea to the low straight-jacket escribe in [1]. While the approaches escribe in [4], [5], an [6] utilize preeine lows, in these systems users ultimately have control over eciing which lows are to be execute when, an thus may ynamically etermine the sequencing o esign activities. Casotto [8] avois the problem o low restriction entirely by merely capturing a trace o esigner activity an allowing existing traces to be use as prototypes or new activities. The problem with this approach is that it provies no means or enorcing a particular esign methoology (though one may be eine), nor oes it provie a means or organizing an inexing traces in a more generalize ashion than with regar to speciic esign ata iles. As Rumsey an Farquhar [1] suggest, esigners shoul have the option o accessing esign activities rom either a tool-, ata- or low-oriente viewpoint, with only the latter restricting the user to execute tools in a set sequence. In this case though, choosing the tool- or ata-oriente views allows the esigner to escape rom any ixe methoology. We now propose the notion o ynamically eine lows to maintain the avantages o a low-base approach while giving the esigner maximal control over the esign process. 3 Dynamically Deine Flows Beore being able to buil up ynamically eine lows, some knowlege o the kin o tasks that can be perorme an how they can be strung together is require. A task schema may be use to represent this inormation. In this section, we present an overview o the concept o a task schema an then introuce ynamically eine lows. We then show how they can be use to support various ramework services as well as multiple esign approaches. 3.1 Task Schema Overview A task schema (originally introuce in [7], an extene here) is a graph that speciies the epenencies between esign entities (both tools an ata). The epenency relationships escribe in a task schema serve two purposes. First, they state the construction rules by which tasks (tool inepenent esign unctions) can be built. Secon, they speciy the ata schema or a atabase that stores the esign erivation history. Tasks may be primitive perorming a single unction, such as extract a netlist rom a layout, or complex e.g., extract a Device Moel Eitor Device Moels Eitor Veriier Perormance Eite Veriication Extracte Perormance Plot Plotter Fig. 1. An example task schema. Eite eitor netlist rom a layout an simulate its perormance. A task schema can be expresse graphically as shown in Fig. 1.. Design entities (represente by rectangles) are connecte to other entities by irecte arcs labelle with or. An inicates a unctional epenency, e.g., a Perormance is unctionally epenent on a. A inicates a ata epenency. An entity can have at most one unctional epenency an an unlimite number o ata epenencies. In cases where there is more than one way o generating a esign entity, subtyping can be use to separate the ierent construction methos. For example, in Fig. 1., an Eite are two subtypes o entity type that have ierent construction methos. This igure also shows that loops in the task schema are possible: an Eite epens on a. Loops like this are broken by consiering the ata epenency as optional (shown by a ashe arc). Because tools an ata are both treate as entities, it is possible to support tools that are create uring the esign process. An example o such a tool is the switch-level simulator COS- MOS [10] which is compile or a given netlist an can then be execute on ierent stimuli. Fig. 2. shows how a task schema can represent such a process. Design ecomposition can also be represente by extening the original einition o a task schema to allow an entity (calle a compose entity) to have only ata epenencies an no unctional epenency. (For example, in Fig. 1., a is shown to epen only on the Device Moels an entities.) From our earlier experience with the task schema, we have oun it useul to allow esigners to group together two or more entities that are commonly use together, such as circuit escriptions an evice moels. This concept is also useul or grouping entities which can be simultaneously prouce by a single task. Although compose entities have no explicit unctional Simulate perormance Extraction Statistics Stimuli compiler Fig. 2. Task schema subgraph or a tool create uring a esign.

3 epenency, they o have implicit composition an ecomposition unctions associate with them. Composition unctions can be use, or example, to check or consistency between entities (e.g., can these evice moels be use with this circuit?). Decomposition unctions can be use, or example, to split an entity instance s ata into component parts 1. More complicate notions o esign ecomposition (such as a hierarchy o cells within a esign) can be hanle at a higher level o abstraction. In the Oyssey CAD Framework [2], this is the Design Process Level implemente in the Minerva Design Process Manager [11]. 3.2 Deinition an Representation A ynamically eine low is a sequence o primitive tasks (orming a complex task) which is generate, on eman, by the user o the esign system. Traitionally, lows have been represente by a bipartite low iagram such as that shown in Fig. 3.. We have chosen an alternative representation calle a task graph, that emphasizes the similar manner in which tools an ata may be hanle in a ynamically-eine low 2. An example o a task graph is shown in Fig. 3.. A task graph is a irecte acyclic graph, with each noe in the graph corresponing to an entity in the task schema, an each ege corresponing to a epenency. A ynamically eine low (represente by a task graph) is a temporary structure that can be built up by the esigner as esire (subject to the rules in the task schema). Expan operations can be use to incorporate urther primitive tasks into a low. For example, two possible expansions o the low in Fig. 3. are shown in Fig. 4.. Note that the circuit in Fig. 4. was specialize to an Extracte beore expansion. (Specialization is the selection o an entity subtype so that an expan operation can be perorme.) When the low is built up as the esigner esires, Eitor Eitor Fig. 3. Two possible representations o a ynamically eine low (base on the task schema in Fig. 1.), a traitional bipartite low iagram, an a task graph. 1. In practice, we have oun that this is rarely necessary. The esign ata is oten store separately anyway, with the composite entity storing pointers to the component parts. 2. Our representation o a low is analogous to the Lisp representation o a unction, whereas a traitional lowmap is analogous to the C or Pascal representation. For example, we may write Fig. 3. as: placement placer(circuit_eitor(circuit), placement_) whereas Fig. 3. may be written as: placement (placer, (circuit_eitor, circuit), placement_). We are treating the tool as just another parameter. Eitor Eitor Extracte Fig. 4. Two possible expansions o the low shown in Fig. 3.. the entities can be instantiate (an instance selecte or each lea noe) an the task execute. Alternatively, the esigner coul run each task as a primitive task, using the result o that to buil a new low an so on. More complex low structures are also possible. Fig. 5. shows a low, base on the task schema o Fig. 1., involving the reuse o an entity in several subtasks an the prouction o multiple outputs, incluing multiple outputs rom the same subtask. This low coul be constructe by starting at any one o the entities present an perorming expan operations until the low was built up. (Previous use o the task schema to construct lows 3 was restrictive in how entities were to be use. Construction was allowe rom the goal entity only, entities coul not be reuse, an tasks coul not prouce multiple outputs [7].) 3.3 Design Management Support Dynamically eine lows an the task schema provie support or various ramework services. These services are outline below. Support or esign methoology management is provie in the task schema itsel. The schema escribes the tasks that can be execute an how esign entities can be use to orm these tasks. While we cannot restrict a esigner to a ixe sequence o tasks, we believe that this is avantageous: the esigner shoul be able to perorm any allowable task in any orer. Dynamically eine lows easily allow or automatic task Device Moels Perormance Extraction Statistics Extracte Veriier Perormance Plot Veriication Plotter Fig. 5. A complex low structure, base on the task schema o Fig The lows were calle task trees an were true trees, looking like those in Fig. 4.. We have abanone the name task tree as the low structure is no longer restricte to being a tree.

4 sequencing (low automation) because tool an ata epenencies are speciie in the task schema. It is also possible to support parallel task execution, wherein isjoint branches in the low can be execute in parallel, possibly on ierent machines (see Fig. 6.). As state earlier, the task schema ais esign ata management by orming the ata schema or a esign meta-ata (esign history) atabase. Further etails o this are given in [12]. As will be illustrate in section 4.2, this low structure can also be use as the orm or template or queries into the atabase. Tools which can perorm multiple unctions are oten hanle by eining separate activities or each tool behavior. Using our approach, i the multiple behaviors correspon to iering entity types (e.g., one tool that can unction both as a layout eitor an a circuit extractor), the tool (or its encapsulation) can be instantiate or each o those entity types. For behaviors corresponing to the same entity type (e.g., automatic layout using ierent algorithms speciie by arguments to the tool), multiple encapsulations can be use to speciy the iering arguments. Another approach is to eine the options or arguments themselves as an entity type. An example is the entity in Fig. 1.. It is also possible to share encapsulation coe among several tools. For example, we have encapsulate three statistical circuit optimization tools that take exactly the same input arguments an prouce the same type o output using this technique. Finally, tools themselves may serve as ata input to other tools. For example, an optimization proceure may have a circuit simulator passe to it as an argument. Design consistency maintenance (i.e., automatic retracing o a low to upate erive esign ata), is reaily supporte through the storage o the esign history. Queries into the esign history can quickly etermine whether such retracing nee occur. For example, a query such as in the netlist that was extracte rom this layout coul etermine whether such an extraction ha yet been perorme, or whether the extracte netlist was out-o-ate with respect to the layout. Another aspect o esign consistency maintenance is ensuring that ierent views o a esign are in corresponence. Designers oten think o a esign in terms o ierent views such as a logic view, a transistor level view, or a physical view, as shown in Fig. 7. View management is typically seen as the responsibility o a ata management system in a ramework, separate rom methoology management. I views o a esign are associate with entities in a task schema, however, lows in out in out logic view transistor view physical layout view Fig. 7. Three views o an inverter cell. can be use to represent the transormations between views. For example, given the task schema in Fig. 1, the low in Fig. 8 will synthesize the physical view o a circuit rom the transistor view, while the low in Fig. 8 will veriy that the physical view is consistent with the transistor view. As can be seen, ynamically eine lows enable the provision o many ramework services. Not only can they be use to support these services, they also make methoology maintenance easier by avoiing the requirement or the maintenance o a set o lows (only the task schema nee be maintaine), an by simpliying the incorporation o new tools. They allow esigners greater reeom by not restricting them to work on a static low, an, as will be seen in the ollowing section, they also allow greater reeom in how a esign is approache. 3.4 Multiple Design Approaches Dynamically eine lows allow esigners to be very lexible in their approach to solving a esign problem. Any one o our ierent approaches may be selecte. In the goal-base approach, esigners ientiy a task by irst selecting the goal entity o the task rom the task schema. The tool-base approach allows users to initially select either the tool-entity or the tool-instance that they wish to work with. In the ata-base approach users initially select an existing piece o ata that they in inverter cell out Extraction Statistics in out Separate branches Separate branches Extracte Veriier Veriication Fig. 6. Separate branches can be execute in parallel. Fig. 8. Flows or the synthesis o physical view o circuit, an veriication that physical view correspons to transistor view.

5 wish to work with. The plan- or low-base approach allows esigners to choose rom a set or library o lows that they (or another user) have built up previously. This approach woul normally be use when repeating a common esign activity. Allowing the esigner to approach the problem in any way they choose provies the greatest possible esigner lexibility. 4 Implementation The concepts escribe above have been implemente in the moiie version o the Hercules Task Management System [7], part o the Oyssey CAD Framework [2]. 4.1 Execution o a Simple Task Importantly, as in [1], an as escribe in 3.4 above, Hercules allows users to be very lexible in their approach to a esign task, being able to approach the task rom multiple viewpoints 4. In [1], this is one using ierent user interaces or each approach. Hercules, however, uses the same user interace or each approach. A visualization o a task graph orms the basis o the Hercules user interace, as shown in Fig. 9.. Suppose, or example, that the esigner wishes to obtain a circuit perormance rom an existing netlist. To start the task, the esigner may select a preeine low rom the low-catalog, a esign entity type rom the entity-catalog, a tool rom the tool-catalog, or a piece o ata rom the ata-catalog. In this example, suppose that the user elects to start by choosing an entity rom the entity-catalog. I the task schema is the one shown in Fig. 1., then the entitycatalog will list all o the entities in Fig. 1.. The user can select either the goal type o the task ( Perormance), the entity corresponing to the tool to be use ( ), or, the entity corresponing to the netlist to be simulate (). An icon representing this entity then appears on the screen. Using a pop-up menu associate with the icon, the user can then buil up the low simply an easily using expan operations (see Fig. 9.) escribe earlier ( 3.2). (Expan operations woul not be necessary i the user ha chosen a preeine low.) Once the low is built up, the user can select an ill in instances or the lea noes o the low by using the browser associate with each lea noe entity (see Fig. 9.). Once instances have been selecte or the lea noes, the non-lea noes become executable an may then be run. Flows o any complexity can be create. Flows can be expane in either irection an can be o any epth. A sublow may be run at any stage as long as its epenencies are satisie inepenently o the remainer o the low. Instance browsing (an selecting) also nee not wait until the complete low has been generate; it may be one at any time that an icon or the given entity exists on the screen. Also, the selection mae in the atabase browser nee not be unique: it is possible to select more than one instance, or a set o instances causing the task to be run or each ata instance speciie. (The relevant 4. The original version o the Hercules Task Manager supporte only the goal base approach. Task winow Hercules Exit Clear New Task... Keywors Date Limits From: User Limits: Use Depenencies Browser 10/1/1992 To: 10/31/1992 Select Install Delete Move Set Eit Comment jbb Oct 2, :22 Low pass ilter irector Oct 13, :30 CMOS Full aer sutton Oct 20, :30 Operational Ampliier OK Unexpan Expan Browse Help Perormance Help Menu Bar Task graph Pop-up menu associate with the icon. Fig. 9. Two parts o the Hercules User Interace: the task winow, an entity instance browser. encapsulation may cause the tool to be run or each instance selecte or it may pass all o the ata to a single call o the tool.) As can be seen rom the browser in Fig. 9., metaata such as user-i an creation time-stamp are recore. The user is also able to annotate entity instances proviing both a name an a more etaile textual escription i esire. This annotation can be use to help ocument the esign steps taken. An instance s most important meta-ata is its esign history which recors the entity instances use to create that instance. This esign history can be querie, using the low itsel as a query template. It also allows previously execute tasks to be recalle, possibly moiie, an execute. Details o this are given in the ollowing section. 4.2 Using the Design History The task graph can be use to ormulate an return the result o queries into the esign history atabase. Simple queries about an entity instance can be orme using the browser associate with each entity (see Fig. 9.). More complex queries involving backwar-chaining an orwar-chaining through the esign history can also be orme. Backwar-chaining queries into the esign history atabase are use to in an instance s erivation history. For example, ater selecting a unique instance o an entity, a esigner may select History rom the icon s pop-up menu to reveal the instances use to create it (see Fig. 10.). The other meta-ata (user, time-stamp, comment) can be examine by browsing on the reveale instances. Forwar-chaining queries are use to in the entity instances which epen upon a given instance, or instances, e.g., ining all o the circuit perormances erive rom a given

6 netlist. This is achieve by constructing a task graph, speciying the known instances, an then browsing on the parent entity using the Use epenencies option in the browser (see Fig. 9.). As every esign object create has its esign history instance store in the esign history atabase 5, it is possible to use this history to keep track o ierent versions o esign objects. Versioning is closely associate with eiting tasks which, in a task schema, are characterize by having a ata epenency whose source an target are o the same entity type. (For example, in Fig. 1. an Eite epens (optionally) upon a.) Versioning o a esign is traitionally represente by a version tree (see Fig. 11.). Our representation a low trace is a semantically richer superset o a version tree, not only showing the relationship between the ata, but also showing the tools that were use in creating that ata (see Fig. 11.). A low trace has the same orm as a task graph an can be built up using the orwar- an backwar-chaining approaches escribe above. 5 Conclusions Hercules Exit Clear New Task... HSpice Low pass ilter Perormance LPF Simulation Expan Use History Browse Help Fig. 10. Browsing the esign history. Note that the an entities o not appear until ater History is chosen. The inverse isplay means that the icon represents a unique instance. The name o this instance appears within the icon. We have introuce the concept o ynamically eine lows tool inepenent lows (represente by a task graph) that are built up, on eman, by a esigner subject to the rules containe in a task schema. Dynamically eine lows provie support or various ramework services (incluing esign methoology management an automatic task execution) in a tool inepenent manner. Design ata management support is also provie: the task graph itsel can be use to ormulate an return the results o queries into the esign history atabase. Dynamically eine lows also provie support or multiple esign approaches esigners can choose a goal-base, toolbase, ata-base or plan-base approach to solving their esign problem. 5. Note that, although each instance o an entity (incluing ierent versions o the same esign) has its own associate meta-ata, it may share the actual (physical) ata with other instances. For example, several esign history instances coul point to the same Unix RCS (Revision Control Sotware) or SCCS (Source Coe Control Sotware) ile, but have ierent version numbers store in the meta-ata. Cct E. e1 The concepts presente here have been implemente in the latest version o the Hercules CAD Task Manager, part o the Oyssey CAD Framework. Reerences c1 c3 Cct E. e2 c2 Cct E. e1 c3 c4 Cct E. e2 c5 [1] M. Rumsey an C. Farquhar. Uniying Tool, Data an Process Flow Management. In Proceeings o First European Design Automation Conerence, GI/ACM/IEEE/IFIP, 1992, pages [2] J.B. Brockman, T.F. Cobourn, M.F. Jacome, an S.W. Director. The Oyssey CAD Framework. In IEEE DATC Newsletter on Design Automation, Spring [3] D.C. Liebisch an A. Jain. JESSI Common Framework Design Management The Means to Coniguration an Execution o the Design Process. In Proceeings o First European Design Automation Conerence, GI/ACM/IEEE/IFIP, 1992, pages [4] P. van en Hamer an M.A. Treers. A Data Flow Base Architecture or CAD Frameworks. In Proceeings o the International Conerence on Computer-Aie Design, IEEE, 1990, pages [5] K.O. ten Bosch, P. Bingley, an P. van er Wol. Design Flow Management in the NELSIS CAD Framework. In Proceeings o the 28th ACM/IEEE Design Automation Conerence, ACM, 1991, pages [6] T. Chiueh an R. Katz. A History Moel or Managing The VLSI Design Process. In Proceeings o the International Conerence on Computer-Aie Design, IEEE, 1990, pages [7] J.B. Brockman an S W. Director. The Hercules CAD Task Management System. In Proceeings o the International Conerence on Computer-Aie Design, IEEE, 1991, pages [8] A. Casotto, A.R. Newton, an A. Sangiovanni-Vincentelli. Design Management base on Design Traces. In Proceeings o the 27th ACM/ IEEE Design Automation Conerence, ACM, 1990, pages [9] P. van er Wol, G.W. Sloo, P. Bingley, an P. Dewile. Meta Data Management in the NELSIS CAD Framework. In Proceeings o the 27th ACM/IEEE Design Automation Conerence, ACM, 1990, pages [10] R.E. Bryant, D. Beatty, K. Brace, K. Cho, an T. Sheler. COSMOS: A Compile or MOS s. In Proceeings o the 24th ACM/IEEE Design Automation Conerence, ACM, 1987, pages [11] M.F. Jacome an S.W. Director. Design Process Management or CAD Frameworks. In Proceeings o the 29th ACM/IEEE Design Automation Conerence, IEEE Computer Society Press, 1992, pages [12] J.B. Brockman an S.W. Director, A Schema-Base Approach to CAD Task Management, In Proceeings o the Thir IFIP WG 10.2 Workshop on Electronic Design Automation Frameworks, Eite by T. Rhyne an F.J. Rammig, Elsevier Science Publishers, c1 c2 Fig. 11. Representations o version trees: a traitional version tree, an a low trace as represente in Hercules. A low trace shows the tool use to create each version. c4 c5