Der Einsatz von CORBA in verteilten EDA-Tools - Frank Grützmacher Technische Universität Ilmenau
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
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 SystemeAnforderungen 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 CORBAAnforderungen 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 ArchitekturCORBA in EDA-Tools ?
K1
Große, mono-
lithische Gebilde K2
K3
Heutige Tools sind Ähnlich wie bei
meistens „historisch“ Hardwarebausteinen
gewachsen , daher oft muß man auch bei
große, monolithische Software hin zu
Gebilde mit einer vorgefertigten, domain-
komplexen Schnitt- spezifischen Standard-
stellenarchitektur bausteinen kommenGrundlegende 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 JavaDienstvermittlung 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 .. -Server registrieren ihre
Objekte unter einen Namen
-Clients können über
diesen Namen-Referenzen
Technologie erfragen
Mitec AMS
0.25 0.35 0.5 0.8
0.35
-z.B. Modulgeneratoren 0.5
ID Kind objRef Cadence-PCell-Server
PCell ModulGenDienstvermittlung in einen
verteilten Werkzeug (2)
B) Mit dem Trader-Service
„Service Offer“ z.B. Modulgenerator
Service Typ
besteht aus Name, Type
Properties und Wert
z.B. „ChannelSize“ ,
objRef float , 0.5
...
0.5
Service Type Repository PCell-ServerDienstvermittlung in einen
verteilten Werkzeug (3)
Automatischer Start von benötigten Diensten
Client-Rechner Naming- Server-Rechner
oder -Server wird durch den
Trader- Daemon gestartet
Client 1.
Service -Client bekommt die
„richtige“ IOR mitgeteilt
A) Client „erfragt“ 2.
die Server-IOR
Server
B) Client macht
den ersten Aufruf
4.
über IIOP Implementation
3. Repository
Netzwerk
z.B. „orbixd“ bei OrbixInterfacegestaltung und Design (1)
• die „Kosten“ für entfernte Aufrufe
müssen im Design beachtet werden
IIOP Performance • Wieviele Nachrichten kann der ORB
maximal liefern ( „Call latency“ )
Einschränkungen :
• Wie groß und wie strukturiert sind die
Daten und wie lange braucht der ORB
um diese Daten zu konvertieren
(„Marshalling Rate“ )
✏ Vermeidung von „fetten“ Operationen
(siehe nächste Folie )
✏ keine zu feingranularen Interfaces
Der Weg : ( d.h. Ersetzen von Interfaces durch
Daten )
✏ Client-Side-Caching und Smart-ProxiesInterfacegestaltung und Design (2)
Bsp.: Für eine„fette“ Operation/Interface
Nachteil :
interface Cell {
- jede Teilinformation resultiert
attribute float woX; in einen Netzwerkcall
attribute float woY; - jede Zelle benötigt eine
attribute string inst_name; Klasse auf Server-Seite
attribute ORIENTATION orient;
... enum DIRECTION { MX, MY, MXR90,
MYR90, R90, R180, R270, NOT } ;
};
struct Point {
float x;
Vorteil: float y;
};
- beim Client benötigte Daten
struct Cell {
werden als Wert übertragen
Point location;
- Resourcen beim Server string inst_name;
DIRECTION orient;
geschont };Bsp.-Komponente :
Synthesebibliothek (1)
- verwaltet persistentes Synthesewissen
Aufgaben :
- ermöglicht Suchen nach Teilmodellen
bzw. bestimmten Eigenschaften in den Modellen
Anforderungen : - mehrere Suchanfragen dürfen die Synthese-
bibliothek 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
SuchanfragencontrollerBsp.-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 WordEDA-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ührtSie können auch lesen
