A Framework-Solution for the. based on Graphical Integration-Schema. W. John, D. Portner

Transcription

1 A Framework-Solution for the EMC-Analysis-Domain based on Graphical Integration-Schema W. John, D. Portner Cadlab - Analoge Systemtechnik, Bahnhofstrasse 32, D-4790 Paderborn, Germany 1 Introduction Especially in the CAD/CAE-domain, multi-tool design- and analysis-environments are applied. Many of the tools are oered by dierent CAD/CAE vendors and especially in the new domain of EMC-analysis are still in a development phase. A homogenous EMCanalysis-environment available to non-expert users cannot be built by a simple collection of tools. To provide a suitable solution, the integration of the tools based on a framework is required. Main features of the framework-solution described in this paper are the tool integration by graphical integration-schema and the version management including version browsing, consistency control and data handling by an object oriented data base. The use of graphical integration-schema is new and opens a wide range of interesting aspects. 2 Concept of Tool-Integration by Use of Integration- Schema The integration-schema to be described here consist of all required information on version management, version browsing, consistency control and control of the tools to be integrated. Furthermore, the integration-schema oer a graphical presentation of the actual state of integration. An integration-schema enables the administrator to adapt new tools on dierent conditions quickly. This aspect is of high importance when taken into account that in the domain of CAD/CAE-environments ( especially for EMC-tools ) developments are very dynamical. New tools have to be integrated continuously into the tool environment and already existing ones are further developed and have to be updated. The proposed concept of tool integration using a graphical integration-schema is shown in gure 1. The administrator is able to integrate tools into the environment using the schema-editor sc which generates so called 'integration-schema'. These integration-schema are used by

2 the version manager vsm for the setup of the integrated tool environment. The user can interact via the interface of the version manager vsm. The version manager starts tools and handles their data. The data handling is done by the data base OMS [11] which is connected to the version manager. Depending on the degree of tool-integration, tools can either interchange data via the UNIX le system or they can directly interact with the OMS data base ( the version manager provides the consistency with the OMS data base ). Message passing between the version manager and the tools is possible, too. Tools Schema-Editor sc Administrator Schema User-Interface vsm User OMS- Database Figure 1: Concept of tool integration by use of integration-schema 3 Meaning of the Integration-Schema An integration-schema forms a specication or a model of the integrated system. To reduce the complexity of the integration-schema, a 'natural' partitioning of the schema was found. The overall model of the workbench is divided into a model 1. for the tools and their data 2. for the management. These two models result in a tool-object-schema (TOS) and an administrationschema (ADS). 3.1 Tool-Object-Schema (TOS) A tool-object-schema forms a model of tools and their data. It represents a model of the tool behaviour. There are dierent schema elements for the tool-object-schema. A tool-object-schema is interactively constructed by the schema elements with the use of the schema-editor sc. Every schema element has its graphic representation, which consists of primary information. This primary information is the important integration information, which enables

3 the administrator to get an outline of the integration schema without overcharging with details. Secondary integration information is in contrast more detailed and is only visible in special menues of the schema-editor. This integration information concerns attributes of the schema elements. In the following the schema elements without secondary integration information are described : 1. A 'tool'. A tool has a symbolic tool name, which is graphically represented in italic letters. The way the tool is called with its options is - together with other attributes - secondary integration information. A 'tool' will be graphically represented by : 2. An 'object'. Objects are the data for the tools. There are dierent types of objects with a dierent graphic representation. Depending on its type an object has attributes, which are secondary integration information. There are three types of objects : (a) A 'basis object', which is seen as an atomic data unit. The contents of a basis object is known by the tools only, while the version manager deals with a basis object as a single data unit. A 'basis object' will be graphically represented by : (b) A 'multi basis object', which is a set of basis objects. Some tools work with an undeterminate number of data units of the same type. A multi basis object stands for an undeterminate number of basis objects. A 'multi basis object' will be graphically represented by : (c) An 'equivalence object', which is used for the construction of an object hierarchy. Like directories in UNIX, the objects can be structured by equivalence objects. Equivalence objects contain no data but they are the father for other objects of all types ( basis objects, multi basis objects and equivalence objects ).

4 A 'equivalence object' will be graphically represented by : 3. A 'hierachical dependency' of the objects. As mentioned in the description of equivalence objects, this type of object is used to build a hierarchy of objects. A hierarchy is graphically represented by a line from an equivalence object to a basis object, a multi basis object or an equivalence object : 4. 'Input and output relations' of tools to objects. This tool-object-schema element with its attributes describes the input and output behaviour of a tool. Input and output relations are graphically represented by arrows between tools and objects : Using the tool-object-schema elements described above a model of all tools of the workbench with their data and their behaviour can be constructed. Figure 2 gives an example for a tool-object-schema which applies all of the four toolobject-schema elements. The gure shows the user interface of the schema-editor sc, too. There is some integration information - the secondary integration information - hidden in this gure. It can be made visible interactively by the schema-editor. The tool-object-schema as a model of the tools, their data and their behaviour is the basis for the tool and data mangement of the version manager vsm. On the other hand the tool-object-schema gives a survey of the state of integration, of the tools and objects and their dependencies. So it is useful for the strategic planning of new tools or the faster integration and application of new tool releases.

5 Figure 2: Example of a tool-object-schema 3.2 Administration-Schema (ADS) The administration-schema is a model of the tool and the data management as it is presented to the user. With the administration-schema a version management and an analysis ow which ts to the tools can be constructed. This is done by distributing the tools with the aected objects into smaller scopes. The structure of a tree is chosen for the separation of the tool scopes. An administration-schema is built by the following elements: 1. A 'view' which is a data and method level. The views are the nodes in the tree mentioned above. A view comprises the tools and objects belonging to the same scope. A view itself consists of dierent elements: (a) A 'viewname' for the identication. (b) An 'iconic representation' ( bitmap ) for the view. Together with the viewname it is used for the identication of the view. (c) A 'set of objects'. Only objects dened in the tool-object-schema can be included into this set.

6 (d) A 'set of methods'. A method consists of several invocations of tools in sequential or parallel order. This order is dened in a special diagram. In this diagram, the tools dened in the tool-object-schema are the nodes of a directed graph. The directed graph determines the order of the invocations of the tools. (e) The 'multiple attribute'. This view attribute determines, whether the view can be instantiated once or multiple by the version manager. Multipleattribute Iconic representation Viewname Set of objects Set of methods Figure 3: Graphic representation of a 'view' 2. A 'father-son relationship' between the views. With this schema element a tree of views can be constructed. A father-son relationship is graphically represented by a line from the father view to the son view. An example for an administration-schema designed by the schema-editor sc is shown in gure 4.

7 Figure 4: Example of an administration-schema 4 Data Access and Information Exchange There are dierent ways for a tool to get the data and information it needs. The version manager supports the following levels of data access : 1. The 'black box integration level' : A data access at the UNIX le system is called black box integration level. On this level a tool can be integrated without changing its source code, which makes the integration process very fast. Moreover if the source code of a tool is not available, this integration level is the only possible way. For such a tool, the version manager creates the whole UNIX environment with all les as specied in the tool-objectschema. 2. The 'white box integration level' : A tool which accesses the data of the OMS data base directly is integrated on the white box integration level. One advantage of this integration level is the OMS support of the simultaneous access of the same data by several tools. Another advantage is the possibility of easy building data structures in OMS suitable for CAD/CAE applications. And if it is taken into account that a creation of the UNIX environment for a tool on the black box integration level can be very time

8 extensive in some cases, this is avoided on the white box integration level. On the other hand the integration process is slower since the tool must be adapted to the OMS data base functions. 3. The 'grey box integration level' : The grey box integration level is a compromise solution. A tool integrated on this level accesses its data directly at the OMS data base. But in contrast to the white box integration level the grey box integrated tool uses a possibility to access OMS data just like UNIX les. This makes the integration process faster than on the white box integration level. To push a black box integrated tool to the grey box integration level only a minimal change of the source code is necessary. On the other hand a grey box integrated tool cannot use all OMS support for simultaneous data access and building OMS data structures. For direct information exchange between dierent tools, the following communication concepts are supported : 1. The 'distributed communication level' : For a faster access of data, a function set for the direct exchange of data and messages between tools is provided. On this data access level the UNIX le system or the data base is not interconnected. 2. The 'central communication level' : This is a level for the communication of a tool and the version manager. The aim is to inuence the version management directly. For this purpose a tool can send messages to the version manager at any changes of the state of the tool. 5 Version Manager (vsm) The version manager vsm controls the analysis or design ow, the handling of tool data, the version management and the consistency of the tool data based on the integration-schema ( via a link to the OMS data base ). A 'version browser' is the user interface of the vsm. The user interface of the version manager vsm is shown in gure 5. In the center of gure 5 a so called 'versiontree' is visible. A versiontree is the instantiated tree of views dened in the administration-schema. Each of the boxes of the versiontree is an instantiated view of the administration-schema and is called 'version'. The user can 'browse' (or navigate) on the versiontree and can select one version as the 'current version'. For this current version, there are some administration methods ( like delete, copy, ect. ) available. On the other hand, there are the methods dened in the administration-schema for the view, which the current version instantiates. But not all these methods are sensible at all times. For that reason a selection is made during the runtime of the version manager. Depending on the state of the version manager, a subset of these methods is made available for the application by the user. The activation of methods may result in a generation of new versions. Versions are represented in the order of their creation time.

9 Figure 5: Example of the user interface of vsm including a versiontree 6 Example of an Integration 6.1 The Integration Process An example will demonstrate the integration process. A new simulator called 'FREACS' is integrated into the EMC-Workbench. The black box data integration level is taken for 'FREACS' and the tool-object-schema shown in gure 6 is the starting point. 'FREACS' needs an input-le 'freacs.in', which is generated by an other tool 'lde' as seen in gure 6. The rst step is the denition of the tool 'FREACS' with its describing attributes itself. When this is done in a special menue of the schema-editor, 'FREACS' exists in the toolobject-schema without any connection yet. The next step is to specify the input/output behaviour of 'FREACS' in relation to the object 'freacs.in' in an other menue of the schema-editor. The tool 'FREACS' has a relation to the 'freacs.in' object now. Analogous to this the other objects of 'FREACS' and thier input/output relations are specied.

10 Figure 6: Starting point for integrating 'FREACS' Figure 7: The complete tool-object-schema of 'FREACS' In gure 7 the complete tool-object-schema of 'FREACS' is shown. Two more objects are inserted : an object 'freacs.prot' for the protocol le of the simulator and an object 'NET.*dia' for the results. The input/output behaviour of 'FREACS' in relation to these

11 Figure 8: Administration-schema : 'System' - 'Modul' - 'PCB' objects is specied, too. Finally there are two new tool : 'less' for showing the protocol le and 'AnaRes' for visualizing the results. A further step is the specication of the administration-schema. In the administrationschema of the EMC-Workbench there are three hierarchic dependent views : 'System' - 'Modul' - 'PCB' ( see gure 8 ). Since the tool 'lde', which produces the input 'freacs.in' for the simulator 'FREACS', works on the view 'PCB', it makes sense to create a new view 'Simulation' as a son of the view 'PCB'. This is done in gure 9 which shows the complete administration-schema. Some more views are inserted. For example the view 'Protocol' is inserted as a son of the view 'Simulation' because of the dependency of every 'FREACS'-protocol to one simulation run.

12 Figure 9: The complete administration-schema The objects dened in the tool-object-schema are distributed among the new views. To apply the simulator 'FREACS', a simple method consisting of 'FREACS' and 'less' is constructed. A special window of the schema-editor is designated for the construction of a method. A method is represented by a directed graph with the tools as the nodes. In our example 'FREACS' and 'less' are the nodes in the graph, and a directed edge from 'FREACS' to 'less' expresses the order of invocations of these two tools. The new method is called 'Simulate' and it is assigned to the view 'Simulation'. Both the tool-object-schema and the administration-schema are complete now.

13 6.2 The User-Session A short example of an user-session will demonstrate how the user works with the just integrated simulator 'FREACS'. Figure 10 shows the user interface of the version manager. Figure 10: Creating a new 'FREACS' input by activating 'LayoutDataExtractor' As a rst step the user activates the tool 'lde' which creates the input 'freacs.in' for the simulation. The now generated version 'Simulation' ( to be seen as a son of the version 'Basisprocessor-4' in gure 11 ) contains the input 'freacs.in'. On this version the method 'Simulate' which itself starts 'FREACS' is activated. When the tool 'FREACS' is nished, the protocol le is displayed and the situation is as shown in gure 12. There are some new versions containing the protocol le and the results. In this way the user may go on and create more simulations.

14 Figure 11: Activating the method 'Simulate' Figure 12: Situation after the simulator 'FREACS' is nished

15 7 Summary and Outlook The intention of the framework solution presented in this paper is to integrate new tools fast, to react on new tool developments quickly and to give a survey of all tools, their behaviour and their dependencies. This is reached by using graphical integration schema. The use of a schema-editor for creating graphical integration schema makes the integration process easier and faster. With the dierent levels of data integration and tool communication, the best way of integration can be chosen for every tool. An object oriented data base makes a deep integration possible and easy. Finally the version manager as the user interface manages the tools and the data and controls all user activities in connection with the data base. As for the quality of the integrated software, valuable experience-knowledge was obtained from integrating tools of an EMC-Workbench under real conditions. Scope of the EMC- Workbench is the analysis of electromagnetic compatibility of printed circuit boards. In this respect the integration of simulators, layout programs, display tools, editors and other more has already been performed. References [1] W. John, An EMC-Workbench to Support the Design of Printed Circuit Boards, International Symposium on Electromagnetic Compatibility, 1992, Beijing, China, May 25-27th ( accepted for presentation ) [2] W. John, An EMC-Analysis-Workbench for Component Design Based on a Framework Approach, Microsystem Technologies 91, 2. Internationaler Kongre und Fachmesse fur Microsystemtechnik, Berlin, Oct./Nov [3] W. John, Unterstutzung des Leiterplattenentwurfs mit Hilfe einer EMC-Workbench, EMV 92, 3. Internationale Fachmesse und Kongre fur elektromagnetische Vertraglichkeit, Karlsruhe, Feb [4] K. Gottheil et al., The Cadlab Workstation CWS - An Open, Generic System for Tool Integration, Proceedings of the IFIP WG 10.2 'Workshop on Tool Integration and Design Environments' Paderborn, FRG, Nov., 1987 [5] K. Gottheil, H. Kaufmann, T. Kern, R. Zhao, X und Motif - Einfuhrung in die Programmierung des Motif-Toolkits und des X-Window-Systems, Springer Verlag, ISBN [6] M.L. Bushnell, S.W. Director, VLSI CAD Tool Integration using the Ulysses Environment, Proc. 23rd ACM/IEEE Design Automation Conference, 1986, pp [7] R.H. Katz, R. Batheja, E. Chang, D. Gedye, V. Trijanto, Design Version Management, IEEE Design & Test, Feb. 1987, pp

16 [8] P. van der Wolf et al., Meta Data Management in the NELSIS CAD Framework, Proc. 27th ACM/IEEE Design Automation Conference, 1990 [9] J. Daniell, S.W. Director, An Object Oriented Approach to CAD Tool Control Within a Design Framework, Proc. 26th ACM/IEEE Design Automation Conference, 1989, pp [10] M. Mehendale, An Approach to Design Flow Management in CAD Frameworks, Proc. IEEE/The European Conference on Design Automation, Feb. 1991, pp [11] W. Fox, J. Friedrich, R. Hopp, T. Kathofer, A. Meckenstock, D. Nolte, K. Pielsticker, G. Reitmeyer, F. Rupprecht, M. Schrewe, The Architecture of the Object Management System within the CADLAB Framework, Proceedings of Second International IFIP WG 10.2 Workshop on Electronic Design Automation Frameworks, Charlotteville, USA, Nov This research was supported by the BMFT ( Bundesministerium fur Forschung und Technologie ) of the Federal Republic of Germany under grant 13AS0097.