Re: Warum analoge und digitale Masse trennen?

Hallo Oliver,


Ok, aber man koennte sich fragen, welche weiteren Gruende es gibt, warum das EDA Geschaeft so muehsam ist.


Ja, wir kommen der Sache langsam näher ;-)

Es liegt wohl nicht nur daran, dass der Anbieter zu dumm ist, eine
Werbeagentur zu beauftragen ;-)


Gerhard sprach einen sehr wunden Punkt an: EDIF hat de-fakto fuer User wie mich nichts gebracht. Manche Firmen wie Cadsoft sind zur Offenheit der Schnittstellen bereit, die meisten anderen nicht.


Nack, offene Schnittstellen bekommst Du bei den allermeisten
Systemen, die sind nicht das Problem.


Leider nicht. O-Ton von Eagle: Koennten wir machen, doch Cadence rueckt die Format-Info nicht raus.


Hast Du schon mal probiert, auf so einer Schnittstelle zu
programmieren ?


Nein, ich bin kein Programmierer. Als Designer wuerde ich erwarten, dass die Schnittstelle einfach funktioniert. Z.B. OrCad Schaltplan in Eagle oder umgekehrt. Nicht mal das geht.


Ich schon, und dabei merkt man schnell zwei Dinge:
a) Nicht jedes Zielsystem unterstützt jede Funktion des Quellsystems,
weil letztlich jede Funktion mit Datenrelevanz Einzug in eine solche
Schnittstelle findet.
Konkret:
b) Viele Layoutsysteme haben nur eine sehr eingeschränkte
Connectivität und erlauben den Import von geometrischen Elementen
nur in einer Form, welche konform zur systemspezifischen Anbindung
der Geometrie an die Verbindungsinformation ist.


Waere ok. Ich wuerde nicht erwarten, dass aber auch alles funktioniert. Ein Schaltbild mit Chips, Transistoren und Widerstaenden ist jedoch nicht gerade Raketenwissenschaft. Layout schon, das ist was anderes.


Auch darum ist EDIF im Bereich der Geometrie gescheitert, wohingegen
es bei Netzlisten sehr gut funktioniert.


Die sind IMHO an mangelnder Bereitschaft einiger "Stake Holders" gescheitert.


Und exakt deshalb funktioniert auch Gerber, es hängt schlicht keine
editierfähige Connectivity dran.


Das ging wohl eher auf die uebliche: Eine Firma wurde Marktfuehrer und deren Format wurde Standard. So wie *.doc und *.pdf.


Es ist kein böser Wille, die Formate sind meistens recht gut
dokumentiert.


Das hatte mir Cadsoft aber ganz anders erzaehlt.


Nur: Was willst Du denn bitte machen, wenn das Zielsystem schlicht
nicht kann, was man von ihm per Format verlangt ?


Ein geschicktes System meldet sich dann zu Wort bzw. zu Bildschirm ;-)


Bei uns im System kann eine Leiterbahn z.B. mitten auf Kupfer
enden und wird korrekt erkannt, dahinter steht ein _erheblicher_
Rechenaufwand, da dies in Realtime geschehen muss.
Deshalb hab' ich auch keine Probleme damit, wenn Gerhard
irgendwelche HF Filter von ADS & Co als Kupfer importieren
möchte, geht, wird längst praktiziert, wird längst drüber
telefoniert (über die importierten Filter ;-)

Aber was bitte soll denn ein armes "kleines" System machen,
dessen Connectivity Rubberband- oder bestenfalls Eckpunkt-
basierend ist, da _fehlen_ schlicht die Routinen, um bei Import
den Schnitt der Leiterbahn mit dem Polygon zu erkennen, da
_fehlen_ Routinen, um besagtes Polygon in einen Vergleich
Soll- zu Ist-Netzliste einzubinden, da _fehlen_ die Routinen
für Kreisbögen bei HF-tragenden Stripline Leiterbahnen.

Und Du wirst doch jetzt nicht allen Ernstes erwarten, dass jetzt
alle auf den kleinsten gemeinsamen Nenner gehen und keine
Filter mehr mit Polygonen bauen, jede Ecke in einer Stripline
von Hand korrigieren, weil Kreisbögen nicht gehen usw.


Warum klappt das bei Messgeraeten, wo es ebenso harte Konkurrenz gibt?


Weil es dort auch nur bezüglich der Ansteuerung per se klappt,
nicht aber bezüglich des Funktionsumfangs.


Das muss es doch gar nicht. Wenn ich ":acquire:average_8" eingebe und es diese Funktion hat, antwortet es entsprechend. Sonst eben nicht.


Konkretes Beispiel: Neues DSO hier auf dem Tisch, per PC auf Fernsteuerbarkeit getestet. Der komplette Instrument Command Set offengelegt und an die Industriegepflogenheiten angelehnt.


Und, was machst Du, wenn Du eine Anwendung hast, die z.B.
Sequences a'la LeCroy auf dem DSO verlangt und Dein DSO
das halt nicht kann und auch nie können wird ?

Oder wenn Du ein Signal erzeugen willst und das IEEE488
Programm spricht den Arbiträrgenerator beim Vektormodulator
an, der in Deiner Kiste nicht eingebaut ist.


Dann erscheint von meinem Scope eine Meldung, dass es diese Funktion nicht kennt.


Genau _daran_ scheitert EDIF für Geometrien.


Der Instumentenbus ist offenbar nicht dran gescheitert.


Nicht am bösen Willen der Anbieter, die wären heilfroh, wenn man
nur noch _ein_ Interface pflegen bräuchte. Zumindest kann ich das
für uns klipp und klar sagen. Btw. Wir haben z.B. einen EDIF
Geometrie Import im Schaltplan, den nutzt nur kaum einer.

Gruß Oliver

P.s.: Ich hab' das bei einem IC-Layout gehabt, das Zielsystem
der Foundry konnte _formal_ GDS2, hat aber bei bestimmten legalen
Konstrukten, die wirklich nicht komplex waren, Gift und Galle
gespuckt. Die Jungs waren fix- und fertig, weil die Daten eindeutig
legal waren und die noch nie erlebt hatten, dass ihr _Fertigungs_-
system derartige Zicken macht. Wir haben die dann im Interface
umgeschrieben. Seitdem gibt es unterschiedliche GDS2 Outputs
für diese und für jene Foundry. Wie kommt das: Nun ja, der
Anbieter des Systems hatte halt nur gegen Vendor M und Vendor C
Daten getestet und hatte mal eben ein paar Elemente des Standards
nicht implementiert, von denen er glaubte, dass sie eh' in den
Daten nicht vorkommen.


Bei mir vorige Woche schiefgelaufen: SC-75 Pinout. Nicht mal das haben die EDIF Jungens auf die Reihe bekommen. Die Hersteller auch nicht, denn offenbar redet man nicht miteinander. Nur drei Pins, au Mann.

Also haben wir jetzt einen Autonetics-Analogconsultants Standard eingefuehrt:

3
=====
1 2

--
Gruesse, Joerg

http://www.analogconsultants.com
.

Relevant Pages