Moderne Konzepte in Elektronik CAE Umgebungen am Beispiel eines verteilten Werkzeugs zur Unterstützung des mehrphasigen high-level Syntheseablaufs

Transkript

1 F. Grützmacher/ J. Kampe 43 rd International Scientific Colloquium Technical University of Ilmenau September 21-24, 1998 Moderne Konzepte in Elektronik CAE Umgebungen am Beispiel eines verteilten Werkzeugs zur Unterstützung des mehrphasigen high-level Syntheseablaufs 1. Einleitung Neuere Entwurfstrategien wie die mehrphasige high-level Synthese bedingen auch eine geeignete softwaretechnische Umsetzung, um sie auch in der Praxis einsetzen zu können. Basierend auf der Methodik des Strukturentwurfs analoger Systemkomponenten [1] soll ein Konzept für entwurfsunterstützende Werkzeuge vorgestellt werden. Ziel ist es, dem Entwerfer neben einer Reihe von Synthesemethoden und den erforderlichen Schnittstellen auch eine Vielzahl von Eingriffsmöglichkeiten in den Entwurfsablauf bereitzustellen. Um die parallele Entwicklung dieses Werkzeugs, seine Plattformunabhängigkeit sowie ein Höchstmaß an Verfügbarkeit zu gewährleisten, wurdeeine verteilte, auf Java basierendearchitektur gewählt. Im vorliegenden Beitrag wird die Gesamtkonzeption für die Realisierung dieses Werkzeugs erörtert und der Einsatz von modernsten Softwarestandards wie Java und CORBA 1 [2] in EDA- Tools demonstriert. 2. Entwurfsdomänen und daraus resultierende Werkzeugarchitektur Die Methodik verlangt, daß der Entwickler in einer Vielzahl unterschiedlicher Abstraktionsniveaus und Entwurfsdomänen agiert. Diese verschiedenen Sichten sollen allemit einem sich je nach aktueller Domäne selbst konfigurierbaren Visualisierungstool dargestellt werden, das in Abhängigkeit von der Anzahl der aktuellen Betrachtungsebenen instanziiert wird. Abb. 1. Komponentenansatz Zu jeder Visualiserungskomponente werden die Daten zentral im Entwurfsdatenserver gehalten. Die Entwurfsdaten repräsentieren den Entwurf jeweils in einer Modellsicht und auf einer Abstraktionsebene. Da sowohl automatisch bzw. interaktiv aus dem Visualisierungswerkzeuge angestoßene Syntheseschritte Entwurfsdaten in unterschiedlichen Ebenen und Modellsichten verändern können, bietet sich eine zentrale Verwaltung der Daten an. Die Manipulationen auf den Entwurfsdaten sollen ohne spezielles Wissen über die ausgeführten Syntheseschritte möglich sein. 1 Common Object Request Broker Architecture

2 Abgesehen von wenigen formalen Regeln, die durch Konfiguration an die jeweilige Abstraktionsebene angepaßt sind und das Wesen dieser Abstraktionsebene beschreiben, wird das Wissen über Syntheseschritte ausschließlich durch die Synthese-Algorithmen und nicht durch die Enturfsdaten repräsentiert Graphen- und Kommunikationsmodell Die Entwurfsdaten der unterschiedlichen Entwurfs-Ebenen werden durch einen Graphen repräsentiert. Der Informationsaustausch zwischen den einzelnen Programm-Komponenten erfolgt auf der Grundlage eines allgemeinen, hierachischen Graphen-Modells; die konkrete Struktur des Graphen wird durch Konfiguration an die Erfordernisse der konkreten Abstraktions-Ebenen angepaßt. Folglich werden vom Datenserver Graphen für die unterschiedlichen Sichten mit einer Vielzahl von domänenspezifischen Attributen gehalten. Jedes Werkzeug verfügt über seine spezifische Schnittstelle, welches in der Interface Definition Language definiert wird und die von einer Komponente angebotenen Operationen aufzählt und ihre Aufrufschnittstellen beschreibt. Zwischen den einzelnen Modulen zu übertragende Daten müssen in adäquate IDL-Typen übersetzt werden, d.h. auch das interne Graphenmodell mit den zugehörigen Attributen. Die Schwierigkeit besteht nun darin, ein möglichst einfaches, aber der notwendigen Funktionalität entsprechendes Interface für die einzelnen Komponenten zu finden. Bsp. für ein Interface : // IDL Interface zum Entwurfsdatenserver struct mssgraph {... }; interface ED_entry { }; void set_graph(in mssgraph g); mssgraph get_graph(); // weitere Funktionalitaet Der Objekt Request Broker (ORB) als universelles Kommunikations-Medium zwischen den Komponenten, nimmt die Klient-Aufträge (Requests) entgegen, leitet sie an die Interface-Implementierung im jeweiligen Server weiter, veranlaßt dort ihre Ausführung und liefert die Ergebniswerte zum aufrufenden Modul zurück. Die Abbildung 2 zeigt die von der OMG 2 definierte CORBA-Architektur. Aus der Interface- Beschreibung ( dem IDL-Interface) wird sowohl der Stub- als auch der serverseitigeskeleton-code generiert, der das Marshalling/Unmarshalling 3 der zu übertragenden Requests übernimmt. Die folgenden Details sind für den Nutzer vollkommen versteckt: Object Location: Für den Client ist es nicht ersichtlich, ob sich das Zielobjekt auf derselben Maschine, in derselben Domain oder gar im gleichen Prozeß befindet. Objekt Implementierung: Der Client muß nicht wissen, auf welcher Platform und in welcher Sprache das Zielobjekt läuft. Zustand: Wenn der Client einen Request an einen Server schickt, braucht er nicht zu wissen, ob das Objekt gerade aktiv ist und Requests empfangen kann. Falls notwendig, wird das Objekt auf den Request hin gestartet. Kommunikationsmedium: Durch den ORB spielt auch das Kommunikationsmedium (TCP/IP, shared memory oder lokale Aufrufe) keine Rolle. 2 Object Managment Group siehe auch 3 Wandlung/Rückwandlung in netzwerktransparente Bytefolgen

3 client object implementation Dynamic Invocation IDL-Stubs ORB- Interface DSI IDL-Skel. Object-Adapter ORB-CORE gleich fuer alle Orbs ORb spezifisch Abb. 2. Common Object Request Broker Architecture Damit kommen auch in den EDA 4 -Tools die Vorteile dieser Architektur vollkommen zum Tragen. Die Implementierungssprache ist frei wählbar. Einzelne Teile einer Applikation können im gesamten Netzwerk verteilt werden. Auf die Vielzahl von unterschiedlichen Formaten und Export/Import-Filtern könnte man verzichten, wenn sich die Hersteller auf standardisierte Schnittstellen, wie in anderen Bereichen(Telekommunikation) schon angestrebt, einigen könnten Entwurfsdatenserver und Synthesecontroller Beide Module kooperieren eng miteinander. Im Entwurfsdatenserver werden alle aktuellen Daten der unterschiedlichen Abstraktionsebenen zentral gehalten, die durch Syntheseschritte konkurrierend verändert werden müssen. Zu diesem Zweck kommuniziert der Synthesecontroller mit dem Concurrency Controller. Dieser veranlaßt, daß alle Entwurfsdaten, die bei einem Syntheseschritt verändert werden sollen, von den Bedienoberflächen aktualisiert werden und sperrt sie für die Dauer der Modifikation. Einzelne Syntheseschritte lassen sich dabei als Modifikation des Datengraphen ansehen. Je nach Konfiguration der Abstraktionsebene müssen dazu die Methoden Teilgraphen einfügen Teilgraphen entfernen Teilgraphen markieren Teilgraphen als Dekomprimierung anhängen Teilgraph hierachisch substituieren ( komponieren) Relation anwenden auf einfügen Attribute manipulieren auf den Enwurfsgraphen realisiert sein. Nach der Abschluß der Modifikationen müssen die Aktualisierungen an die Oberflächen propagiert werden. Der Synthese-Controller verwaltet und visualisiert die Beziehungen zwischen den Entwurfs- Datensätzen eines Entwurfs in Form eines Relations-Graphen. Die zwischen unterschiedlichen Modellsichten oder über mehrere Abstraktions-Ebenen hinweg bestehenden Abhängigkeiten beim Entwurf können durch die Entwurfs-Daten, die sich auf eine konkrete Modell-Sicht und eine konkrete Abstraktions-Ebene beschränken, nicht repräsentiert werden. Abbildung 3 soll diesen Aufbau veranschaulichen. 4 Electronic Design Automation

4 Synthese Controller IIOP Concurrency Controller Entwurfsdaten Entwurfsdaten Server Server ED Thread1 ED Thread 2 IIOP GUI Komponente Abb. 3. Zusammenspiel zwischen Entwurfsdatenserver und Synthesecontroller 2.3. Visualisierung und Interaktion Die Visualisierung und Interaktion wird durch ein allgemeines Anzeige- und Kommando-Tool für Graphen realisiert. Es wertet die Laufzeitkonfiguration für das Graphen-Modell und die Graphen- Transformation aus und präsentiert die Entwurfsdaten in Abhängigkeit von der Abstraktionsebene. Darüber hinaus können über die Visualisierung und Interaktion die konfigurierten Manipulationen an den Entwurfsdaten-Daten vorgenommen werden. Die Implementierung basiert auf einen Framework von zahlreichen Softwareentwurfsmustern (beschrieben z.b. in [3], [4]). Mittels dieser Muster kann man auf bewährte Lösungen für wiederkehrende Designprobleme in komplexer Software zurückgreifen und sie für die eigenen Anforderungen adaptieren, in unserem Fall auf die Handhabung sehr unterschiedlicher graphischer Objekte und deren Modifikation sowohl interaktiv als auch durch die Kommunikation mit anderen Komponenten. Graphische Elemente werden in diesem Framework gemäß dem Composite Pattern als Zusammenfassung von unterschiedlichen Figuren gehandhabt. Wobei ein einfaches graphisches Objekt das gleiche Java-Interface realisiert, wie eine komplexe, zusammengesetzte Figur. In Abhängigkeit von der Entwurfsdomäne und dem Abstraktionslevel sind unterschiedliche Modifkationen der Attribute der einzeln Teile des Entwurfs erlaubt, was über eine Zustandsführung gemäß dem State Pattern erreicht wird. Während des Designablaufs kann es auch zu Aktualisierungen in den einzelnen Sichten kommen, deshalb müssen die Visualisierungskomponenten auch in der Lage sein, Veränderungen bei anderen Tools wahrzunehmen. Erreicht wird dieses verteilte change propagation durch ein CORBA-Server-Interface in der Nutzeroberfläche selbst. Jede neue Sicht meldet sich an den Enwurfsdatenserver an, wobei er einen Verweis auf sein callback -Interface übergibt. Alle anderen Komponenten sind damit in der Lage, aktiv Aktionen in den unterschiedlichen Sichten auszulösen, z.b. daß graphische Objekte modifiziert, Aktionen ermöglicht bzw. gesperrt werden.

5 2.4. Synthese-Bibliothek Die Synthese-Bibliothek stellt alle zur Synthese, zur Simulation und zur Visualisierung der Aspekte erforderlichen Repräsentationen bereit. Auf diese Weise soll wiederum das Wissen über die Elemente vom Wissen über die Synthese-Schritte getrennt werden. Die Synthese-Schritte erhalten die Informationen über die Aspekte durch Anfragen an die Synthese-Biltiothek. Die Synthese- Bibliothek enthält deshalb für jeden Aspekt : 1. den Teilgraphen entsprechend der Abstraktionsebene 2. eine Beschreibung der Visualisierung 3. die Modelle zur Simulation (xxhdl, Matlab, Spice, etc.) 4. Verhaltensbeschreibungen als Menge von Verhaltens-Ausdrücken Diese Vielzahlt von unterschiedlichen Daten werden zweckmässigerweise von einer objektorientierten Datenbank (z.b. Versant oder ObjectStore PSE) verwaltet. Folgende Funktionlität muß dabei gewährleistet werden. 1. Einfügen, Entfernen usw. und 2. Suche nach Ausdrücken der Verhaltensbeschreibung Attributen der Graphen-Elemente Daraus können komplexe Suchanfragen resultieren, die in der von der ODMG 5 definierten Object Query Language [5] zu formulieren sind. 3. Ausblick heterogene Rechnerwelt Corba/IIOP Inter-/Intranet Corba/IIOP Abb. 4. Verteilte EDA-Tools in heterogenen Rechnerwelten Abbildung 4 demonstriert, daß eine solche Architektur sich leicht auch für die Arbeit im Team bzw. über Tool- und Firmengrenzen eignet. Das Internet Inter-ORB Protokoll (IIOP) ermöglicht, daß ORBs verschiedener Hersteller miteinander kommunizieren. Da IIOP auf der im Internet üblichen Protokollfamilie TCP/IP basiert, sind weltweit verteilte Applikationen denkbar. Vielleicht kommt man über diese neuen Architekturen zu einem EDA-Komponentenmarkt, wo man leicht Werkzeuge unterschiedlicher Anbieter über definierte IDL-Schnittstellen miteinander kombinieren kann oder gar leistunsgfähige verteilte Werkzeuge mietet, indem man die Oberflächenkomponente über das Internet downloadet. 5 Object Database Management Group

6 Literatur- bzw. Quellenhinweise [1] J. Kampe and G. Scarbata, Automatisierbare Synthesemethoden für analoge Systemkomponenten, [2] Object Managment Group, The Common Object Request Broker : Architecture and Specification,, 2.2 edition, [3] E. Gamma, H. Richard, R. Johnson, and J. Vlissides, Design Patterns, Addision Wesley Publishing Company, 1. edition, [4] E. Gamma, Framework-Entwurf in Java mit Entwurfsmustern, in OOP 98, [5] R. Cattel and et all, The Object Database Standard 2.0, Morgan Kaufmann Publishers, Inc., 1. edition, Autorenangabe: Dipl.-Ing. Frank Grützmacher Dr.-Ing. Jürgen Kampe Technische Universität Ilmenau Fakultät für Elektrotechnik und Informationstechnik PSF Ilmenau Tel: 03677/ grue@inf-technik.tu-ilmenau.de