Datenaustauschformat für Bauteilbibliotheken?

Hatte ich am Mittwoch auch. War zwar nur ein Butterfly Laser Package, doch dabei kam es auf die genauen Abmasse an. Da sitzt man dann erstmal mit Mikrometerschraube und Ultranahsichtbrille. Danach alles huebsch in tausendstel Zoll umrechnen ...

Moeglich ist das. Als ich einen Cadsoft-Ingenieur danach fragte, kam die Antwort, die ich erwartet hatte: Sie wuerden das gern tun, aber die anderen EDA Unternehmen meist nicht. Dieses ganze EDIF Geraffel war IMHO ein grosser Mumpitz. Vielleicht sind die Leute auch nur zu den Meetings gegangen, weil es dort gutes Essen und Fassbier gab ;-)

Letzens feierte der DIN-Ausschuss 50jaehriges bestehen, der darueber diskutiert in welche Richtung man den Text auf Buchruecken zu schreiben hat....

Noch Fragen?

Olaf

EDIF 4 müsste es eigentlich können, wenn man den Wikipedia Artikel liest. Scheint aber nicht gerade ein einfaches Format zu sein. Eine neue Computersprache zu erfinden (EDIF verwendet EXPRESS) erscheint mir allerdings nicht gerade sinnvoll für ein Datenaustauschformat. Sowas ist gut für Dinge wie Postscript, wo das Ergebnis "dumm" ist (also ein paar Punkte, die gedruckt werden), aber wenn es sinnvoll weiterverarbeitet werden soll, dann müssen die Strukturen und Verbindungen direkt ersichtlich sein, auch für einen leichteren Export. Müsste ich mir aber mal anschauen, vielleicht ist es ja doch eine gute Idee.

EDIF 4 kann soll auch Layouts beschreiben können, somit müsste man damit dann auch Bauteile beschreiben können, oder? Allerdings scheint es mir so, als würde es eher für den Austausch von Schaltplänen und Layouts gedacht sein. Kennt sich einer mit EDIF aus und kann man damit auch einzelne Bauteile wiederverwendbar darstellen?

Die Unterteilung in Bauteile und Schaltpläne bei Eagle ist aber ohnehin eher willkürlich, denn eine komplette Schaltung ist nichts anderes als ein besonders großes Bauteil, was bestimmte Anschlüsse hat, z.B. Klemmleisten statt Pins. Oder ein Bauteil könnte auch eine Gruppe mehrerer Bauteile sein, fertig geroutet. Sind andere EDA-Programme so generell?

Man könnte dann die Internet-Datenbank erweitern, daß die nicht nur einzelne Chips bereitstellt, sondern auch komplette Referenzschaltungen bei kritischen Teilen, wie analoge Hochfrequenzschaltungen. In Eagle hat man leider keine Möglichkeit, sowas mit Bordmitteln leicht zu exportieren und importieren (könnte man ggf. mit ein paar Eagle-Scripte erreichen, aber wäre nicht gut integriert, also z.B. nachträgliche Änderungen von Teilschaltungen würde nicht alle Instanzen automatisch mit ändern).

"Frank Buss" schrieb im Newsbeitrag news:1mx4mu2o45ya6$.1va7m251wsuw1$. snipped-for-privacy@40tude.net...

EDIF. Gut gemeint heisst aber nicht immer gut gemacht. Andererseits wird ein neues Format nicht automatisch besser. Deine Vorstellung hat deutliche Defizite.

Ein moderneres EDA Programmm als die heute verfuegbaren wuerde seine Bauteile in Bibliotheken mit folgenden Eigenschaften halten: parametrisierbare Objekte, z.B. DIL(16) und DIL(20) erzeugen Footprint und 3D-Modell eines DIL Gehaeuses mit angegeben vielen Pins. Die Pins (der pinstack) ist von Fertigungsmethode zu Fertigungsmethode anders, ein DIL Objekt verwendet also (16 bzw. 20) andere Objekte, die DIL Pinstacks, und die kann man umdefieren, von hobbyniveau zu 16 fach Multilayer. Ein Objekt aendert sich also, wenn darin eingebundene Objekte umdefiniert werden. Kurz also:

DIL16 = DIL(16) uses 16 * DIL-Pinstack = 2 layer round Hole Loetstopp

Zusaetzlich wollen manche Fertigungsmethoden ihre Pads in Abhaengigkeit von der Ausrichtung der Platine im Wellenloetbad modifiziert sehen, und das hat gefaelligst automatisch zu passieren, ein Objekt enthaelt also Code, der in Abhaengigkeit von Plazierung zu anderem Aussehen (z.B. Nasen zum Abtropfen des Zinns) verhilft.

Ein statisches Bilbliotheksformat mit fest vorgegebenen Hierarchien ist also Steinzeit der EDA Software und waere mit modernen Konzepten nicht vertraeglich, also behindernd.

Sehe ich jetzt nicht, warum man dazu was dynamisches, wie eine Programmiersprache, einführen müsste. Man müsste sich nur ein umfassendes Model überlegen, wo das schon bedacht ist. Z.B. könnte man bei einem hierarchischen System, Platine->Modul->Package->Pad, jeweils alle Attribute der übergeordneten Ebene sichtbar machen, wenn es durch eine untergeordnete Ebene nicht überschrieben wird. "Platine" hätte dann ein Attribut "Wave Soldering Direction", in Grad. Wenn "Pad" jetzt das Attribut "Wave Soldering Adjustment = true" hätte, dann könnte man das Pad um den entsprechenden Wert drehen.

Ich denke nicht, daß es allzuviel solcher dynamischen Abhängigkeiten gibt, sodaß es einfacher ist, das explizit zu definieren, statt es voll generisch und dynamisch zu implementieren, denn das würde auch das Design neuer Bauteile erschweren und die Arbeit nur vom Design des Formats auf die konkreten Bauteilebeschreibungen verschieben.

Die Hierarchien müssen nicht fest vorgegeben sein. Wie bei einem Embedded System könnte das komplette System auch das Gehäuse umfassen, und einzelne Bestandteile, z.B. Steckmodule, die wiederum aus einer Platine mit Bauteilen darauf besteht. Auch 3D-Daten von den Komponenten ist eine gute Idee. Man müsste nur ein paar grundlegende Dinge festlegen, wie Platine, Bauteil, Pin, Via usw. und könnte das dann beliebig kombinieren.

Schwierig wird es natürlich, wenn man komplette Referenzdesigns mit x Layern auf eine Platine mit y Layern platzieren möchte, aber da muß dann das EDA-Programm helfen und ein Mensch nachbearbeiten, denn das wäre zu komplex, es algorithmisch in eine Komponente unterzubringen. Aber schon alleine nur für Bauteile (und wenn x

"Frank Buss" schrieb im Newsbeitrag news:r0kd8lyzlvr8.v2av9p3qx3yr$. snipped-for-privacy@40tude.net...

Na ja, beispielsweise in TQFP Pattern bekommt in den 4 Ecken je nach Zinnflussrichtung mal das eine und mal das andere Pad. Das ist praktisch schon Programmierung, zumindest "IF"s.

Prust. LOL. Beweisbar falsches Grundkonzept, das muss scheitern. NIEMAND kann alles im Voraus bedenken, gewisse Zukunft ist noch nicht erfunden.

Alles will ich ja gar nicht im voraus bedenken, nur was heute so allgemein verwendet wird. Wenn eine wichtige Technologie dazukommt, kann man es erweitern. Also erstmal der pragmatische Ansatz, der zumindest so 99% aller Bauteile, die man auf Platinen auflöten kann, abdeckt.

"Frank Buss" schrieb im Newsbeitrag news:luzbk1xja27j.tlvhenqycq66$. snipped-for-privacy@40tude.net...

Computerprogramme (oder Datenaustauschformate), die schon konzeptionell nur in 99% der Faelle funktionieren, braucht kein Mensch.

Datenformate, die 1000% komplexer sind, um 1% Punkte Bauteile zusätzlich vollständig abdecken zu können, wird keiner verwenden.

Ein flexibler Ansatz ist innerhalb des EDA-Programms sinnvoll, z.B. indem solche Dinge wie die automatische Drehung anhand von Attributen, per Scripting eingebaut werden und ggf. auch vom Benutzer angepasst und erweitert werden können. Aber über sowas wird man sich über die Grenzen mehrere EDA-Hersteller hinweg nicht einigen können und ist auch egal, wie die es implementieren, wenn das Datenformat einigermaßen kompletten Export und Import erlaubt.

Ich sehe das nur als pragmatische Erleichterung: Statt daß jeder Entwickler und EDA-Hersteller 100% der Bauteilebibliothek selbst macht, muß man nur noch 1% ein wenig anpassen, falls man gerade eine spezielle Funktion braucht, die im Datenformat nicht vorhanden ist und man die tatsächlich braucht.

Schon, doch ich glaube, dass die meisten EDA Hersteller genau das nicht wollen und an verkrusteten Protektionsmechanismen festhalten. "Wir kochen unser eigenes Sueppchen, sagen niemandem was drin ist und kleben einen richtig hohen Preis dran".

Bei SPICE ist das, was Du beschreibst, so gut wie Realitaet. Man holt sich beim Hersteller den Model File, ist praktischerweise reines ASCII. Das geht in allen Programmen bis auf ein paar Exoten. Natuerlich kam dann eines Tages LTSpice und die fetten Profite der Branche loesten sich in Wohlgefallen auf.

Cadsoft zumindest würde das unterstützen, meintest du ja. Und ich gehe mal davon aus, daß jedes größere EDA-Programm eine Scripting-Sprache hat, womit man zumindest Bauteil-Export/-Import leicht innerhalb des Programms implementieren könnte, auch ohne Unterstützung der Hersteller oder das Bibliotheksformat entschlüsseln zu müssen, was natürlich auch notfalls möglich wäre.

Ja, Scripts unterstuetzen die meisten. Da muesste sich aber jemand hinsetzen und Transfer-Routinen von einem Script zum naechsten und dann weiter zum naechsten zu schreiben. Alle paar Jahre fallen die dann auseinander, weil mal wieder bei einem neuen Release die Rueckwaertskompatibilitaet ueber den Jordan ging. Eine richtige Sisyphus-Arbeit, die vermutlich nie jemand machen wird.

Es gibt EDIF für Schemasymbole, das wird z.B. vom BAE SCM (in der V3) unterstützt und kann genau das und es funktioniert auch.

Nützt nur nix, wenn kaum einer mitzieht.

Der Knackpunkt ist: EDA besteht zu 80% aus kundenseitig "gepflegter" Altsoftware, die keiner umstellen möchte und die häufig mangels Update irgendein alter Stand ist. Selbst wenn sich alle Hersteller heute auf ein Format einigen und das in allen aktuellen EDA System einbauen würden, es täte vielleicht gerade mal 20-30% des Marktes bedienen, wenn überhaupt.

Ich erinnere nur an Firmen, die z.B. gebaruchte Integra Lizenzen kaufen, obwohl das Programm seit vielen Jahren abgekündigt ist und nicht mehr gepflegt wurde und auch nicht mehr verkauft wird. Aber lieber fällt man irgendwann mit der Hardware auf die Nase, als dass man eine Umstellung angeht. Und bei Dienstleistern ist das meistens kein Stück besser, der Kostendruck ist enorm, vielfach fehlt es am Etat für ein Update, von neuer Software ganz zu schweigen.

Es liegt nicht nur an den EDA-Anbietern.

Gruß Oliver

Ich kann es nur fuer OrCad sagen, da das hier an der Westkueste (noch) der de-facto Standard ist. Ein gewichtiger Grund, warum Kunden Upgrades herauszoegern, ist das Problem der Rueckwaertskompatibilitaet. Einmal mit Version X angetatzt und schon ist der ganze Schaltplan mit X-1 oder frueher nicht mehr zu lesen. Damit reduziert man den Pool an Consultants und Layoutern ganz erheblich und das will man nicht wirklich. Denn diese Jungens haben i.d.R. keinen fetten Batzen Geld, der gerade ein Loch in die Hosentasche brennt. Mag bei ganz grossen Bueros anders sein, aber, aehm, wie soll ich's hoeflich sagen, das sind nicht immer die, welche die Kuh auch vom Eis bringen.

Und ja, ich gestehe, dass auch ich schonmal bei einem Liquidator eine Altlizenz gekauft habe. Ganz legal.

Technisch ist klar warum: Wenn Version X ein neues Feature hat, kann X-1 das nicht verarbeiten und müsste die Daten verwerfen. Aufwärtskompatibel ist kein Problem und wird vielfach auch gemacht.

Dann sollte man nur ehrlich sein und nicht den EDA Herstellern die Schuld am fehlenden einheitlichen Format in die Schuhe schieben.

Bitte an die eigene Nase fassen. Danke!

Es ist in der Tat so: Es gibt eine unheilige Allianz aus Auftraggebern, die "billig" wollen, Zukunftssicherheit ist egal, da ist $MANAGER, der das Geld spart, eh weg, und vielen Dienstleistern, welche dann keine Updates kaufen.

Aber:

Das EDA System ist das Haupt-Werkzeug des Dienstleisters, daher sollten die 10-20% Updategebühr vom Neupreis nicht wirklich das Problem sein, das entspricht in etwa der Abschreibung auf 5 bis 10 Jahre. Dafür ist die Software immer auf dem neuesten Stand, d.h. die tatsächliche (nicht steuerliche => stille Reserve) Abschreibung ist Null, obwohl die Steuer gespart wird, da ja auch die Update-Kosten sofort absetzbar sind (Erhaltung).

Und wenn auch das nicht reicht, weil es noch billiger als billig sein soll, dann bitte nicht beschweren, wenn es veraltete Technik und zusätzlichen Arbeitsaufwand gibt.

Von Sprüchen wie "ich will ihr System ja noch 10 Jahre nutzen, ich bin treuer Kunde, aber die Updates sind mir zu teuer" kann nämlich kein EDA Hersteller leben. (Alles schon dagewesen, als z.B. die Uralt-Version die neuen Grafikkarten nicht mehr unterstützt und man glaubte, so einen Treiber für den 10 Jahre alten DOS-Software-Stand zu bekommen, man hat ja sonst nix zu tun.)

Dann lieber keine_Kunden als solche, weil keine_Kunden nicht mit Kostenlos-Requests nerven und nicht Neuinteressenten vom Kauf abhalten ("ich will ja mit der Altsoftware weiter dienstleisten, also lieber Interessent, kaufe gebraucht") und ebenso keinen Umsatz bringen ;-/

Sorry, aber gerade bei Dienstleisterjobs für einfache Projekte (CPU mit etwas Getreibere drumherum) haben sich inzwischen in der Branche fast Bau-ähnliche Verhältnisse eingeschlichen, irgendwann werden sicher auch die Fremdarbeiter auf die Layout-Galeere geschafft ;-/

Gruß Oliver

Hier muss ich Microsoft loben, was ich sehr selten tue. Die haben (bislang) bei Office die Option "Use only '97 compatible features" zusammen mit '97 File Format vorgesehen. Hier ist es ein ungeschriebenes Gesetz, darin zu speichern und alle koennen es lesen. Letzte Woche hatte das ein Ingenieur eines Kunden mit neuem PC bei Excel mal verschwitzt. Doch nach Wegklicken einiger Fehlermeldungen liess sich der File dennoch laden und die Formeln stimmten. So macht man das.

Bei OrCad kam keine Fehlermeldung, nur eine komplette Weigerung. So macht man das nicht.

Alte amerikanische Weisheit, haengt in vielen Firmen: Only what the customer wants matters. If we don't deliver, someone else will.

Das ist eben bei vielen Dienstleistern nicht so. Bei mir und vielen anderen ist das Labor das Hauptwerkzeug. EDA ist eher wie ein glorifiziertes Reissbrett. Bei Chip Designern, die vermutlich die Mehrzahl Eurer BAE Kunden stellen, ist das natuerlich so wie Du schriebst. Die brauchen ausser EDA und PC oft nur noch eine gut funktionierende Kaffeemaschine.

Alte SW hat bei mir noch keine Mehrarbeit verursacht. Eher im Gegenteil :-)

Layouts werden hier fast immer extern vergeben. Das mache ich auch. Mein Layouter benutzt eine etwas aeltere PADS Version, funzt wunderbar.