Slides
Transcrição
Slides
Der Einsatz von CORBA in verteilten EDA-Tools Frank Grützmacher Technische Universität Ilmenau Fakultät für Elektrotechnik und Informationstechnik Fachgebiet Mikroelektronische Schaltungen und Systeme Anforderungen aus der Methodik des Strukturentwurfs analoger Systemkomponenten (1) ❧Ziel : Schaffung eines geeigneten Werkzeugs zur Unterstützung der High -Level Synthese ( Vortrag Dr. Kampe, Session 6 ) ➨ Weg : - platformunabhängige Realisierung mit Hilfe von Java - verteilte Architektur mittels CORBA Anforderungen aus der Methodik des Strukturentwurfs analoger Systemkomponenten (2) Anforderungen : • Höchstmaß an Verfügbarkeit • Vielzahl graphischer Sichten • möglichst große Freiheit bei der Implementierung • Gute Skalierbarkeit • potentielle Multiuserfähigkeit • offene Architektur CORBA in EDA-Tools ? K1 Große, monolithische Gebilde K2 K3 Heutige Tools sind meistens „historisch“ gewachsen , daher oft große, monolithische Gebilde mit einer komplexen Schnittstellenarchitektur Ähnlich wie bei Hardwarebausteinen muß man auch bei Software hin zu vorgefertigten, domainspezifischen Standardbausteinen kommen Grundlegende Architektur (2) •Applikation nicht mehr als ein großes monolithisches Gebilde • sondern : ➨ seperate Komponenten ➨ interne Realisierung wird hinter einen Interface versteckt ➨ Verteilung in einer heterogenen Umgebung durch den Einsatz von CORBA möglich ➨ freie Wahl der Implementierungsplatform beim Einsatz von Java Dienstvermittlung in einen verteilten Werkzeug (1) • Corba kennt keine fixe Client-Server Beziehung ➬ man stellt Dienste bereit ( z.B. einen spez. Router ) ➬ der potentielle Client kann über das ihm bekannte Interface auf diesen Dienst zugreifen aber : - Wie „erreicht“ der Client einen Dienst ? - Wie erzeugt/zerstört man einen Dienst ? - Kennt der Server „seine Clients“ ? Dienstvermittlung in einen verteilten Werkzeug (2) A) mit dem Namensdienst .. Technologie Mitec 0.25 0.35 -Server registrieren ihre Objekte unter einen Namen -Clients können über diesen Namen-Referenzen erfragen AMS 0.5 0.8 -z.B. Modulgeneratoren ID Kind objRef PCell ModulGen 0.35 0.5 Cadence-PCell-Server Dienstvermittlung in einen verteilten Werkzeug (2) B) Mit dem Trader-Service „Service Offer“ Service Typ Properties objRef z.B. Modulgenerator besteht aus Name, Type und Wert z.B. „ChannelSize“ , float , 0.5 ... 0.5 Service Type Repository PCell-Server Dienstvermittlung in einen verteilten Werkzeug (3) Automatischer Start von benötigten Diensten Client-Rechner Client A) Client „erfragt“ die Server-IOR Namingoder TraderService 1. 2. Server-Rechner -Server wird durch den Daemon gestartet -Client bekommt die „richtige“ IOR mitgeteilt Server B) Client macht den ersten Aufruf 4. über IIOP 3. Netzwerk Implementation Repository z.B. „orbixd“ bei Orbix Interfacegestaltung und Design (1) • die „Kosten“ für entfernte Aufrufe müssen im Design beachtet werden IIOP Performance Einschränkungen : • Wieviele Nachrichten kann der ORB maximal liefern ( „Call latency“ ) • Wie groß und wie strukturiert sind die Daten und wie lange braucht der ORB um diese Daten zu konvertieren („Marshalling Rate“ ) Der Weg : ✏ Vermeidung von „fetten“ Operationen (siehe nächste Folie ) ✏ keine zu feingranularen Interfaces ( d.h. Ersetzen von Interfaces durch Daten ) ✏ Client-Side-Caching und Smart-Proxies Interfacegestaltung und Design (2) Bsp.: Für eine„fette“ Operation/Interface interface Cell { attribute float woX; attribute float woY; attribute string inst_name; Nachteil : - jede Teilinformation resultiert in einen Netzwerkcall - jede Zelle benötigt eine Klasse auf Server-Seite attribute ORIENTATION orient; ... }; Vorteil: - beim Client benötigte Daten werden als Wert übertragen - Resourcen beim Server geschont enum DIRECTION { MX, MY, MXR90, MYR90, R90, R180, R270, NOT } ; struct Point { float x; float y; }; struct Cell { Point location; string inst_name; DIRECTION orient; }; Bsp.-Komponente : Synthesebibliothek (1) Aufgaben : - verwaltet persistentes Synthesewissen - ermöglicht Suchen nach Teilmodellen bzw. bestimmten Eigenschaften in den Modellen Anforderungen : - mehrere Suchanfragen dürfen die Synthesebibliothek nicht blockieren - Suchergebnisse selbst müssen persistent gespeichert werden - Option auf verteiltes Suchen Realisierung : - Synthesegraphen werden in einem OODBMS gespeichert - Aufsplittung der Funktionalität in Daten- und Suchanfragencontroller Bsp.-Komponente : Synthesebibliothek (2) Kopplung zu Standard-Tools - durch eine bidirektionale CORBA/DCOM -Bridge können Standard -Windows Applikationen auch mit verteilten CORBA-EDA-Applikationen interagieren - z.B. wären Reportgeneratoren in Word oder Statistiken in Excel denkbar Router Simulator Schematic ... ORB CORBA/DCOM-Bridge z.B. COMET von Iona Inc. Excel Word EDA-Komponenten Vision ? - eine Vielzahl von Standard-EDA-Bausteinen mit klar beschriebener Funktionalität und standardisierten Interface ( in IDL ) - z.B. austauschbare, „hot-plugable“ Router oder Simulatoren „Rent a EDA-Tool“ ? - Trennung der eigentlichen GUIs von den komplexen und datenintensiven Teilen .. - GUI beim Nutzer; Berechnungen werden auf High-End Maschinen beim Hersteller ausgeführt