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