3.2 Packager
| Bartels :: Bartels AutoEngineer :: BAE Dokumentation :: BAE Benutzerhandbuch :: Packager :: Packager |
Bartels AutoEngineer® - Benutzerhandbuch3.2 Packager |
|
Ein Packager-Lauf ist immer dann durchzuführen, wenn im Stromlauf Änderungen an der Netzliste (Laden neuer Symbole, Umverlegen von Verbindungen, Änderung von Attributwerten, usw.) vorgenommen wurden, die in das Layout gemeldet werden müssen.
Der Aufruf des Packagers erfolgt aus der Shell des Bartels AutoEngineer und sollte grundsätzlich in dem Verzeichnis vorgenommen werden, in dem die zu bearbeitende Projektdatei abgelegt ist. Die BAE-Shell wird von Betriebssystemebene aus mit folgendem Befehl gestartet:
> bae
Der AutoEngineer zeigt auf dem Schirm das Bartels-Logo sowie folgendes Menü (die Funktion ist nur unter Windows bzw. Motif verfügbar; die Menüpunkte und sind nur in speziellen Softwarekonfigurationen wie etwa in BAE HighEnd oder BAE IC Design verfügbar):
| Schaltplan |
| Layout |
| [ IC-Design ] |
| Packager |
| CAM-View |
| [ Setup ] |
| [ Weitere Task ] |
| Programmende |
Über das Kommando
| Packager |  |
wird der Packager des AutoEngineer geladen. Sollte der Programmaufruf fehlschlagen, dann deutet dies darauf hin, dass die Software nicht richtig installiert ist. Wir verweisen in diesem Zusammenhang auf die Bartels AutoEngineer® Installationsanleitung.
Nach dem Aufruf des Packagers befindet sich auf der rechten Bildschirmseite eine Menüleiste, bestehend aus dem Hauptmenü im oberen Bereich sowie dem im Hauptmenü selektierten Menü im unteren Bereich. Nach dem Laden des Packagers ist die Funktion mit dem zugehörigen Menü aktiviert. Das Hauptmenü ist ständig verfügbar und enthält folgende Funktionen:
| Start |
| Hauptmenue |
| Schaltplan |
| Layout |
| Parameter |
| Programmende |
Mit der Funktion werden die Parameter für den mit zu startenden Packager-Lauf eingestellt. Mit den Funktionen , und kann in das BAE-Hauptmenü, in den Schaltplaneditor oder in das Layoutsystem gewechselt werden. beendet die BAE-Sitzung. Beim Wechsel in das Layoutsystem wird automatisch die Erzeugung eines Layoutelements für die zuletzt vom Packager erzeugte Netzliste vorgeschlagen, wenn noch kein entsprechendes Layoutelement existiert.
Vor der Durchführung des eigentlichen Packager-Laufs mit der Funktion sind über die entsprechenden Funktionen aus dem Menü die Parameter für den Packager-Lauf einzustellen.
Nach dem Aufruf der Funktion hat der Benutzer nacheinander folgende Abfragen zu beantworten:
| Parameter |
| Alle Parameter |
| Design Dateiname ? |
| Design Bibliotheksname ? |
| Layout Elementname ? |
Diese Parameter können auch einzeln über die entsprechenden Funktionen aus dem Menü spezifiziert werden.
Für den Design Dateinamen ist der Name der Projektdatei einzugeben, für die die Netzlistenumsetzung durchgeführt werden soll. Die Projektdatei muss mit der Extension
.ddb verfügbar sein; der Dateiname ist ohne diese Extension anzugeben. Wird ein Leerstring (Betätigen der Eingabetaste
) für den Dateinamen eingegeben, dann verwendet das System den Dateinamen des im vorhergehenden Programm-Modul des
Bartels AutoEngineer geladenen Elements, d.h. den systemweiten Projektnamen.
Auf die Abfrage nach dem Design Bibliotheksnamen ist der Name der Layoutbibliothek einzugeben, die für das Leiterkartendesign verwendet werden soll, und in der auch die für die Netzlistenumsetzung notwendigen Informationen der logischen Bibliothek enthalten sind. Die Bibliotheksdatei muss mit der Extension
.ddb verfügbar sein, der Dateiname ist ohne diese Extension anzugeben. Betätigt der Anwender hier nur die Eingabetaste
(leerer String), dann trägt die Software automatisch den über das Setup (siehe Kommando
LAYDEFLIBRARY in
bsetup-Beschreibung) definierten Default-Layoutbibliotheksnamen ein.
Auf die Abfrage nach dem Layout Elementnamen ist der Name der zu generierenden Netzliste bzw. des zu erstellenden Layouts einzutragen (beim ersten
Packager-Lauf frei wählbar). Betätigt der Anwender hier nur die Eingabetaste
w (leerer String), dann trägt die Software automatisch den über das Setup (siehe Kommando
LAYDEFELEMENT in
bsetup-Beschreibung) definierten Default-Layoutelementnamen ein.
Nach der Eingabe des Layout Elementnamen arbeitet der
Packager nacheinander alle in der Projektdatei enthaltenen Stromlaufplanblätter ab und generiert in der Projektdatei unter dem Layout Elementnamen eine Netzliste. Unter dem Projektdateinamen wird mit der Extension
.fre eine Freelist ausgegeben. Die Freelist wird vom System nicht weiter benötigt und ist zur Auswertung durch den Benutzer bestimmt (Anzeige nicht angeschlossener Pins, Statistik).
Nach erfolgreichem Packager-Lauf erscheint die Meldung . Der Anwender gelangt anschließend durch Betätigung einer beliebigen Taste wieder in das Hauptmenü. Sollte es zu Fehlermeldungen kommen, dann deutet dies in der Regel darauf hin, dass die spezifizierte Layoutbibliothek falsche oder fehlende Zuweisungen von Stromlauf- zu Layoutsymbolen aufweist. In diesem Fall sind vor einem neuerlichen Packager-Lauf mit Hilfe einer entsprechenden loglib-Datei und dem Utilityprogramm loglib die richtigen logischen Bauteilreferenzen in die Layoutbibliothek einzutragen.
Falls im Layout für die relevante Modifikationen wie Pin-/Gate-Swaps oder Bauteilumbenennungen vorgenommen wurden, wird beim Speichern des Layouts ein spezieller Datenbankeintrag erzeugt, der im Packager ausgewertet wird, um den Anwender ggf. über eine Bestätigungsabfrage auf die Notwendigkeit zur Durchführung der vor dem nächsten Packager-Lauf hinzuweisen. Wird dieser Hinweis ignoriert und trotzdem ein Packager-Lauf durchgeführt, dann werden die Netzlistenänderungen aus dem Layout verworfen.
Die Namen der SCM-Symbolpins werden vom
Packager automatisch auf das Pinattribut
$llname übertragen und können im Layout durch die Definition entsprechender Texte auf Padstackebene visualisiert werden.
Das Pinattribut
$nettype wird vom
Packager automatisch von Pins auf die angeschlossenen Netze übertragen. Sind an einem Netz Pins mit unterschiedlichen Attributwerteinträgen für
$nettype angeschlossen so wird für das Netz der Wert
mixed eingetragen.
Das Pinattribut $drcblk wird vom
Packager automatisch von Pins auf die angeschlossenen Netze übertragen. Der Attributwerteintrag für
$drcblk addressiert in
BAE HighEnd einen Parameterblock mit Entwurfsregeln, der damit an das entsprechende Netz zugewiesen wird.
Der
Packager erlaubt nun über das Pinattribut
$pintype eine Plausibilitätsprüfung für die im Schaltplan vorgenommenen Verbindungen zwischen Pins verschiedener Typen. Die Pinattribute werden zweckmässigerweise in den logischen Definitionen der Symbole fest für die einzelnen Layoutbauteilpins vergeben. Unterstützt werden die folgenden Pintypen:
$pintype | Pintyp |
|---|---|
in | Eingabe-Pin |
out | Ausgabe-Pin |
bidi | Bidirektionaler Anschluss |
anl | Analoger Anschluss |
sup | Stromversorgungsanschluss |
Der ERC überprüft für Netze mit mindestens einem Eingang, ob an diesem Netz ein normaler Ausgang, ein bidirektionaler Anschluss oder ein Versorgungsspannungspin vorhanden ist und gibt ggf. die Warnmeldung aus. Außerdem überprüft der ERC, ob an einem normalen Ausgang ein anderer Ausgang, ein bidirektionaler Anschluss oder ein Versorgungsspannungspin angeschlossen ist und gibt ggf. die Warnmeldung aus.
Im Folgenden soll ein
Packager-Lauf für den in
Kapitel 2 in der Projektdatei
demo.ddb erstellten Stromlaufplan durchgeführt werden. Wechseln Sie hierzu in das Verzeichnis, in dem
demo.ddb abgelegt ist.
Starten Sie BAE, rufen Sie wie in
Kapitel 3.2.1 beschrieben den
Packager auf, und versuchen Sie mit den folgenden Kommandos die in
demo.ddb enthaltene logische Netzliste unter Verwendung der Bibliothek
demolib.ddb in eine physikalische Netzliste mit dem Namen
board zu transferieren:
| Parameter | |
| Alle Parameter | |
| Design Dateiname ? | demo |
| Design Bibliotheksname ? | demolib |
| Layout Elementname ? | board |
| Start | |
Der Packager-Lauf wird nicht erfolgreich sein, und auf dem Bildschirm erscheinen folgende Meldungen:
================ BARTELS PACKAGER ================ Design Dateiname ........: 'demo' Bibliothek Dateiname ....: 'demolib' Layout Elementname ......: 'board' Aktiver Planname ........: 'sheet1'. FEHLER : Bauteil 'cd4081' nicht in Bibliothek! Abbruch ohne Veraenderung der Datenbank.
Die Meldung erscheint immer dann am Ende des Packager-Protokolls, wenn der Packager-Lauf nicht ordnungsgemäß beendet werden konnte.
Unter Windows besitzt das Textfenster zur Ausgabe der durch den
Packager erzeugten Warnungen und Fehlermeldungen Scrollbars. Dies ermöglicht bei längeren Protokollen das Blättern in der gesamten Liste der Meldungen und erspart somit den Umweg über die Ansicht der Datei
bae.log (siehe unten).
Betätigen Sie jetzt die Eingabetaste
, um wieder in das
Packager-Hauptmenü zurückzugelangen, und beenden Sie den
AutoEngineer:
| Programmende | |
Sie befinden sich nun wieder auf Betriebssystemebene. Das
Packager-Protokoll, das zuvor auf dem Bildschirm sichtbar war, wurde auch in der Datei
bae.log (im aktuellen Verzeichnis) abgelegt. Sie können sich diese Datei mit Ihrem Editor ansehen, oder auf Drucker ausgeben, um die darin enthaltene Fehlerliste ggf. zu interpretieren. Der
Packager beendete die Bearbeitung mit der folgenden Fehlermeldung:
FEHLER : Bauteil 'cd4081' nicht in Bibliothek!
Diese Fehlermeldung besagt, dass für das Stromlaufsymbol
cd4081 kein Eintrag in der logischen Bibliothek
(demolib.ddb) enthalten ist.
cd4081 ist das in
Kapitel 2.2.2 neu erstellte Stromlaufsymbol, das auf dem Stromlaufblatt
sheet1 der Projektdatei
demo.ddb mehrfach verwendet wurde. Das Symbol
cd4081 stellt lediglich eines der vier Einzelgatter des kompletten Bausteins CD4081 dar. Die logischen Pins des Stromlaufsymbols wurden mit
A,
B und
Y benannt. Dies ist auch alles, was dem System zu diesem Bauteil bekannt ist. Dem
Packager fehlt also die Information, welchem Layoutsymbol das Stromlaufsymbol
cd4081 zuzuordnen ist. Außerdem fehlt dem System auch die Zuordnung der logischen Pins zu den physikalischen Anschlüssen, die Information über feste Anschlüsse zur Stromversorgung, sowie die Definition der Pin- und Gattervertauschbarkeit.
Tritt in den menügesteuerten Versionen des Packagers beim Packager-Lauf ein Fehler auf, der eindeutig einem Schaltplanblatt zuzuordnen ist, so wird dieses Schaltplanblatt beim anschließenden Wechsel in den Schaltplaneditor automatisch zur Bearbeitung in den Speicher geladen. Zusätzlich wird nach Möglichkeit ein auf das erste an einem Fehler beteiligte Schaltplansymbol durchgeführt.
Um einen fehlerfreien
Packager-Lauf für den Job
demo.ddb zu ermöglichen, ist die fehlende Information über die Zuordnung des Stromlaufsymbols
cd4081 zum entsprechenden Layoutsymbol in eine
loglib-Datei einzutragen. Diese Datei ist dann mit Hilfe des Programms
loglib in die für den
Packager-Lauf zu verwendende Bibliotheksdatei
demolib.ddb einzuspielen.
Erstellen Sie also zunächst mit Ihrem Editor die ASCII-Datei
cd4081.def mit der in
Abbildung 3-2 angegebenen Loglib-Definition als Inhalt.
Abbildung 3-2: Datenblatt für Bauteil CD4081 mit Loglib-Definition
Die Syntax für die durch das Programm loglib umzusetzenden Dateien ist im Kapitel 7.11> ausführlich beschrieben. An dieser Stelle sei nur der Inhalt der loglib-Definition aus Abbildung 3-2 näher erläutert.
Die Schlüsselwörter
loglib und
end. kennzeichnen den Dateianfang bzw. das Dateiende.
Das Kommando
part definiert die Zuordnung des Stromlaufsymbols zum Layoutsymbol. In obigem Beispiel gibt das Schlüsselwort
default an, dass diese Zuweisung nicht zwingend ist. Sie kann durch eine entsprechende Wertzuweisung an das Attribut
$plname (sofern im Stromlaufsymbol definiert) im Schaltplan geändert werden, um z.B. ein SMD-Gehäuse anstelle des DIL-Gehäuses einzusetzen.
Das Kommando
pin definiert die logischen Pins
A,
B und
Y des Stromlaufsymbols. Achten Sie darauf, dass diese Definition mit den bei der Symbolerstellung vergebenen Pinbezeichnungen übereinstimmt (andernfalls erzeugt der
Packager entsprechende Fehlermeldungen).
Die
xlat-Anweisung ist das Transformationskommando zur Definition der Gatter bzw. zur Zuweisung der logischen zu den physikalischen Pins.
Mit dem
swap-Kommando wird die Pin- und Gattervertauschbarkeit definiert. In obigem Beispiel sind die vier Einzelgatter untereinander vertauschbar, und es besteht Pinvertauschbarkeit für die Eingänge der Gatter.
Die beiden
net-Kommandos schließlich geben die am Bauteil fest definierten Anschlüsse zur Stromversorgung (Netz
Vss am physikalischen Pin
7, Netz
Vdd an Pin
14) an.
Spielen Sie nun mit Hilfe des Programms
loglib die Informationen aus der soeben erstellten
loglib-Datei
cd4081.def in die Bibliotheksdatei
demolib.ddb ein:
> loglib cd4081 demolib
Wenn Sie bei der Erstellung der loglib-Datei keine Fehler gemacht haben, dann sollte loglib folgende Meldungen ausgeben:
=================================== BARTELS LOGICAL LIBRARY MAINTENANCE =================================== Es wurden keine Fehler festgestellt.
Nun enthält die Datei
demolib.ddb alle für einen erfolgreichen
Packager-Lauf zur Umsetzung der Projektdatei
demo.ddb notwendigen Informationen (vergleichen Sie hierzu auch den Inhalt der bereits in
demolib.ddb eingespielten
loglib-Datei
demolib.def).
Das Menü des Schematic Editors enthält die Funktion zur Anzeige der logischen Bauteildefinitionen selektierbarer Symbole des aktuell geladenen Stromlaufplans.
Es erfolgt eine Dekodierung der mit dem Utilityprogramm
loglib erstellten internen logischen Bibliotheksdefinition sowie die Anzeige der derselben im ASCII-Format. Die Kopfzeile dieser Anzeige enthält die Angabe darüber, ob die Logische Bibliotheksdefinition in der aktuellen Projektdatei
(; hierin wird zuerst gesucht) oder in der Default-Layoutbibliothek
() gefunden wurde. Der Name der Default-Layoutbibliothek ergibt sich aus dem über das
LAYDEFLIBRARY-Kommando des Utilityprogramms
bsetup eingetragenen Pfadnamen (siehe hierzu auch
Kapitel 7.2).
Die Funktion gibt in der Statuszeile die Fehlermeldung aus, wenn der Zugriff auf die Default-Layoutbibliothek fehlschlägt. Die Fehlermeldung erscheint, wenn die angeforderte Loglib-Definition weder in der Projektdatei noch in der Default-Bibliothek verfügbar ist.
Starten Sie nun erneut den
Packager, und transferieren Sie mit den folgenden Kommandos die in
demo.ddb enthaltene logische Netzliste unter Verwendung der Bibliothek
demolib.ddb in eine physikalische Netzliste mit dem Namen
board:
| Parameter | |
| Alle Parameter | |
| Design Dateiname ? | demo |
| Design Bibliotheksname ? | demolib |
| Layout Elementname ? | board |
| Start | |
Der Packager gibt folgende Meldungen auf dem Bildschirm aus:
================ BARTELS PACKAGER ================ Design Dateiname ........: 'demo' Bibliothek Dateiname ....: 'demolib' Layout Elementname ......: 'board' Aktiver Planname ........: 'sheet1'. Aktiver Planname ........: 'sheet2'. Es wurden keine Fehler festgestellt.
Der
Packager-Lauf wurde erfolgreich beendet (Meldung
), und in der Datei
demo.ddb wurde eine gepackte, physikalische Netzliste mit dem Namen
board generiert.
Zusätzlich hat der
Packager mit dem Namenszusatz
_log (hier also mit dem Namen
board_log) auch eine logische Netzliste in der Projektdatei erzeugt. Diese logische Netzliste wird vom System nicht weiter benötigt, kann jedoch z.B. mit Hilfe des Utilityprogramms
userlist (siehe unten) für spezielle Schnittstellen zu Fremdsystem (z.B. in Richtung Simulation) benutzt werden (ein Beispiel hierzu finden Sie in
Kapitel 3.4.3).
Auch die vom
Packager erzeugte Freelist
demo.fre wird vom System nicht weiter benötigt. Sie sollten mit Hilfe wIhres Editors einen Blick auf die in dieser Datei enthaltenen statistischen Informationen werfen, um z.B. festzustellen, ob in Ihrem Schaltplan Signale mit nur einem Anschluss definiert sind.
Der
Packager bildet die gepackte, physikalische Netzliste auf den Stromlaufplan ab. Überprüfen Sie dies, indem Sie sich nach dem erfolgreichen
Packager-Lauf im Stromlauf-Editor die entsprechenden Stromlaufblätter ansehen. Dabei sollten Sie im Beispiel
demo.ddb insbesondere die vier Gatter
cd4081 auf dem
sheet1 beachten. Alle diese Gatter haben nun denselben Bauteilnamen (da Sie alle in dasselbe Gehäuse gepackt wurden), und anstelle der logischen Pinbezeichnungen (jeweils
A,
B,
Y) sind jetzt die physikalischen Anschlussbezeichnungen
(1,
2,
3, usw.) eingetragen.
Um nach einem erfolgreichen
Packager-Lauf zu einem Layout zu gelangen, ist das Layoutmodul (d.h., der
Layouteditor) des
Bartels AutoEngineer aufzurufen. Hier ist in der Projektdatei
demo.ddb zu der Netzliste
board ein entsprechendes Layout (also mit dem Elementnamen
board) zu erzeugen. Nachdem dann über das Menü
der Bibliothekspfad auf die beim
Packager-Lauf verwendete Bibliothek
demolib.ddb eingestellt wurde, können die in der Netzliste enthaltenen Bauteile (z.B. durch wiederholtes Anwenden der Funktion
aus dem Menü
) auf dem Layout platziert werden (siehe
Kapitel 4.3.2).
Dieser Abschnitt enthält eine alphabetisch sortierte Auflistung der Fehler-/Warnungs- und Statusmeldungen des
Packagers. Bei Fehler- und Warnungsmeldungen wurde das führende
bzw.
weggelassen, da einige Meldungen abhängig vom Parameter
als Fehler- oder als Warnungsmeldung ausgegeben werden. Die am Bildschirm erscheinenden Meldungen werden parallel in einer Textdatei
bae.log mitprotokolliert und können somit auch noch nach Verlassen des
Packagers eingesehen werden.
Wie bei den einzelnen Fehlermeldungen dokumentiert, wird nach einem Fehler, der einem Schaltplansymbol bzw. seinen logischen Definitionen zugeordnet werden kann, bei unmittelbarem Wechsel in den
Schaltplaneditor das Schaltplanblatt mit dem betreffendem Symbol geladen und ein
an die Symbolposition durchgeührt. Bei mehreren Fehlermeldungen während eines
Packager-Laufes trifft dies nur für die erste einem Symbol zuzuordnende Fehlermeldung zu. Ist das Problem der logischen Definition des Symbols zuzuordnen, so kann diese im Schaltplan mit
/ bzw.
/ betrachtet bzw. korrigiert werden. Diese Funktionen berücksichtigen auch, dass der Definitionsname über
$rlname- und/oder
$rlext-Attribute auf einen alternativen vom Symbolmakronamen abweichenden Definitionsnamen gelegt sein könnte.
Bei der Korrektur von logischen Definitionen ist zu beachten, dass der Packager die logischen Definitionen bei der Bearbeitung aus der Bibliothek in die Projektdatei kopiert und bei folgenden Packager-Läufen per Default den in der Projektdatei vorhandenen logischen Definitionen Priorität vor den Definitionen in der Bibliothek gibt. Unter / ) kann durch die Einstellung nach Korrekturen in der Bibliothek ein erneutes Kopieren der logischen Definitionen aus der Bibliothek in die Projektdatei erzwungen werden.
Bei Korrekturen in Symbolen ist zu beachten, dass nach dem Platzieren, Löschen oder Umbenennen von Symbolpins die Schaltpläne mit Platzierungen des bearbeiteten Symbols geladen und gespeichert werden müssen um die vom Packager bearbeiteten logischen Netzlisten auf den neuesten Stand zu bringen. Die Symbolmakros selbst werden vom Packager nicht gelesen. Beim einfachen Laden der Schaltpläne sieht man die neuen bzw. geänderten Pinnamen zwar auf dem Bildschirm, in die logische Netzliste werden modifizierte Pindefinitionen aber erst beim Speichern der Schaltplanblätter übertragen.
Beim Schreiben der zum Projekt gehörenden .fre-Datei mit der Auflistung der nicht benutzten Pins, Netzpinanzahlen und Netzzusammenfassungen in mit beliebigen Editoren lesbarer Textform ist ein Fehler aufgetreten. Zu diesem Zeitpunkt ist die Layoutnetzliste bereits erfolgreich geschrieben worden, mit dem Projekt kann also trotz des Fehlers normal weitergearbeitet werden. Die oben genannten Informationen stehen allerdings nicht oder nur unvollständig zu Kontrollzwecken zur Verfügung.
Wahrscheinlichste Fehlerursache ist ein Schreibschutz auf einer aus vorhergehenden Packager-Läufen stammenden .fre-Datei für das Projekt (wie er z.B. bei einfach von CD auf Festplatte kopierten Sicherungskopien gesetzt wird). Bei Reproduzierbarkeit des Problems ohne Schreibschutz und mit ausreichend freiem Festplattenplatz empfiehlt es sich, die Projektdatei zur näheren Untersuchung an den Bartels-Support zu senden.
Bei der Bearbeitung des Projektes traten ein oder mehrere Fehler auf, die das Erstellen einer korrekten Layoutnetzliste verhinderten. Der Vorgang wurde ohne Schreiben einer Netzliste abgebrochen. Eine ggf. bereits vorhandene alte Layoutnetzliste wurde nicht verändert und kann weiterhin verwendet werden. Die genauen Fehler sollten aus vorhergehenden Fehlermeldungen hervorgehen.
Es wird gerade ein Schaltplanblatt einer Blockreferenz eines hierarchischen Schaltplanes bearbeitet. nnn ist die laufende Nummer der Blockreferenzen, blockname der auf den Unterblöcken und in der logischen Definition zum Blocksymbol angegebene Blockname und blockplanname der Name des gerade bearbeiteten Schaltplanblattes (ein hierarchischer Block kann aus mehreren Schaltplanblättern mit gleichem Blocknamen zusammengesetzt sein). Unmittelbar nachfolgende Fehler- und Warnungsmeldungen beziehen sich auf Symbole dieses Blattes.
Es wird gerade das Schaltplanblatt mit dem Namen planname bearbeitet. Unmittelbar nachfolgende Fehler- und Warnungsmeldungen beziehen sich auf Symbole dieses Blattes.
Beim Zugriff auf eine DDB-Datei trat ein nicht näher spezifizierter Fehler auf. Es ist zunächst zu prüfen, ob die Datei nicht evtl. schreibgeschützt ist (wie es z.B. bei einfach von CD auf Festplatte kopierten Sicherungskopien der Fall ist). Bei Reproduzierbarkeit des Problems ohne Schreibschutz und mit ausreichend freiem Festplattenplatz empfiehlt es sich, die Projektdatei zur näheren Untersuchung an den Bartels-Support zu senden.
Hier wird der Name einer ggf. in den Einstellungen gesetzten Alternativbibliothek dokumentiert. Auf die Alternativbibliothek wird zugegriffen, wenn ein Layoutbauteilmakro oder eine logische Definition weder in der Projektdatei noch in der Standardlayoutbibliothek gefunden werden kann. Layoutbauteilmakros und logische Definitionen werden vom Packager in die Projektdatei kopiert, d.h. es ist nach einem erfolgreichen Packager-Lauf nicht notwendig, im Layouteditor die Bibliothek auf die Alternativbibliothek zu setzen um die in der Netzliste verwendeten Bauteile erfolgreich zu platzieren. Der Parameter Alternativbibliothek wird in der Projektdatei gespeichert und muss bei folgenden Packager-Läufen nicht erneut definiert werden.
Der zu dem auf dem Schaltplanblatt planname platzierten Symbol mit dem Namen symbolname gehörige Datenbankeintrag mit den Bauteilattributen konnte in der Projektdatei nicht gefunden werden. Vemutlich wurde dieser Datenbankeintrag im Schaltplaneditor mit Hilfe der Funktionen / / oder / / / von Hand gelöscht. Diese Funktionen sollten nur mit ässerster Sorgfalt angewendet werden, da die Attributwerte von platzierten Symbolen gelöscht werden können. Zur Bereinigung der Bauteilnamensliste sollte statt dessen die Funktion / / verwendet werden, die nur die Bauteilattributeinträge von im Projekt nicht mehr platzierten Symbolen löscht. Nach einem erfolgreichen Packager-Lauf werden nicht benützte Bauteildatenbankeinträge automatisch entfernt, ein manueller Cleanup ist in der Regel somit nur notwendig, wenn in einem aus Altprojekten abgeleiteten Projekt wegen fehlenden Definitionen noch kein Packager-Lauf möglich ist.
Bei unmittelbarem Wechsel in den Schaltplaneditor wird das Schaltplanblatt mit dem betreffenden Symbol geladen und ein an die Symbolposition eines der Teilsymbole durchgeführt.
Zur Behebung des Problems ist das Schaltplanblatt mit dem betroffenen Symbol (siehe "Aktiver Planname") im Schaltplaneditor zu laden und erneut zu Speichern. Dabei werden automatisch Bauteilattributdatenbankeinträge für alle auf dem Schaltplanblatt vorhandenen Symbole erzeugt. Für die betroffenen Symbole sind diese zunächst leer und müssen ggf. mit / erneut mit Werten belegt werden.
Der Wechsel in eines der anderen Programmmodule des BAE konnte nicht durchgeführt werden. Dies deutet auf ein Installationsproblem hin. Es wurden entweder .exe-Dateien aus dem BAE-Programmverzeichnis entfernt oder es liegt eine Mischinstallation zwischen .exe-Dateien der HighEnd-Version und .exe-Dateien anderer BAE-Versionen vor. So eine Mischinstallation kann z.B. entstehen, wenn von der Demoversion durch Entpacken der Datei baew32he.zip zur HighEnd-Version gewechselt werden soll und während dem Entpacken BAE-Module aktiv sind. Das Betriebssystem lässt das Überschreiben der aktiven .exe-Dateien nicht zu und es bleiben Teile der alten Version installiert.
Es wurde über das $rpname-Attribut versucht mehr Gatter eines Symbolmakrotypes in ein Layoutgehäuse zu packen, als über das xlat-Kommando in der logischen Definition aufgeführt wurden. symbolname gibt den Namen des Schaltplansymboles an, das die Überbelegung verursacht. In der Liste der symbolnamen werden die Namen der Schaltplansymbole aufgegührt, die bereits in das Layoutbauteil gepackt wurden.
Die Überbelegung kann auch dadurch entstehen, dass über das $rpname-Attribut zwar die richtige Anzahl Gatter in ein Layoutgehäuse gepackt wird, es aber noch ein gleichnamiges Schaltplansymbol mit dem angeforderten Namen gibt, das keine eigene Namenszuweisung über $rpname besitzt. Der Packager ist nicht in der Lage eigenständig einen alternativen Layoutbauteilnamen für dieses Symbol zu bilden.
Bei unmittelbarem Wechsel in den Schaltplaneditor wird das Schaltplanblatt mit dem betreffenden Symbol geladen und ein an die Symbolposition eines der Teilsymbole durchgeführt.
Zur Behebung des Problems sind die Namenszuweisungen über das $rpname-Attribut den tatsächlich vorhandenen Bauteilgattern anzupassen. Bei der Überprüfung der logischen Definitionen ist zu beachten, dass an den betroffenen Symbolen über $rlname-bzw. $rlext-Attribute alternative vom Symbolmakronamen abweichende Definitionen selektiert sein könnten.
Die gleiche Problematik kann bei Anwendung des $spname-Attributes entstehen, das im Gegensatz zum $rpname-Attribut aber nur bis zur ersten erfolgreichen Zuweisung eines Schaltplansymboles zu einem Layoutbauteil berücksichtigt wird und im Allgemeinen nur beim Import von Netzlisten aus Fremdsystemen Anwendung findet.
Es wurde versucht das Symbol mit dem Namen symbolname über ein $rpname-, $spname-oder $vgrp-Attribut in das Layoutbauteil mit dem Namen layoutbauteilname zu packen in das bereits die in der nachfolgenden Liste aufgeführten Symbole gepackt wurden. Die logische Definition des Symbols symbolname bzw. über ein $plname-Attribut vorgenommene Gehäusezuordnung sind nicht kompatibel zu den bereits in das Layoutbauteil gepackten Symbolen.
Bei unmittelbarem Wechsel in den Schaltplaneditor wird das Schaltplanblatt mit dem betreffenden Symbol geladen und ein an die Symbolposition eines der Teilsymbole durchgeführt.
Zur Behebung des Problems sind die logischen Definitionen der einzelnen in das Layoutbauteil gepackten Symbole für gleiche Symbolmakros gleich zu wählen, bzw. es ist bei den Symbolen eine einheitliche Gehäusezuweisung vorzunehmen.
Einem Bauteil, das in der logischen Definition eine Alternativbauformliste besitzt, wurde über das Attribut $plname ein fester Gehäusename zugewiesen. Die Alternativbauformliste wurde daher für dieses Bauteil deaktiviert.
Es ist zu überprüfen, ob das verwendete Symbol und die logische Definition zueinander passen, da eine gemischte Verwendung von $plname-Attributen und Alternativbauformlisten in der logischen Definition nicht vorgesehen ist. Es ist möglich, die Alternativbauformliste aus der logischen Definition zu entfernen und statt dessen auf Symbolebene in der Form [gehaeuse1,gehaeuse2,...] dem $plname-Attribut als Defaultwert zuzuweisen. Dann kann die als Attributwert beim ersten Platzieren des Symbols gesetzte Alternativbauformliste mit wahlweise in eine Einzelbauform umeditiert werden, ohne dass im Packager Warnungsmeldungen erscheinen.
Im Layoutbauteil mit dem Namen layoutbauteilname sind nicht für alle in xlat-Kommando(s) der logischen Definition(en) aufgeführten Gatter Entsprechungen im Schaltplan vorhanden, d.h. es sind noch Gatter zur Benutzung frei. Zur genaueren Spezifikation der freien Gatter wird jeweils der Namen des ersten im xlat-Kommando aufgeführten Pins des Layoutbauteils aufgeführt.
Dies ist nur eine Warnungsmeldung, die nicht zum Abbruch des Packager-Laufes führt. Es ist jedoch zu beachten, dass bei bestimmten Typen von Bausteinen der undefinierte Zustand der nicht angeschlossenen Eingänge von unbenutzten Gattern zu einem undefinierten Verhalten des gesamten Bausteines führen kann. In so einem Fall empfiehlt es sich im Schaltplan Symbole für die nicht benutzten Gatter zu platzieren und die Eingänge auf ein definiertes Potential zu legen. Da vom Packager auch nicht benutzte Gatter mit der Bauteilkennung versehen werden, kann es notwendig sein für neu platzierte Gatter das Packen in das bereits bestehende Bauteil durch Setzen des $rpname-Attributs auf den layoutbauteilnamen zu erzwingen.
Diese Fehlermeldung kann als Folgefehler der Meldung auftreten. Sollte die Meldung einzelen auftreten, deutet dies auf ein noch nicht bekanntes Problem im Packager hin. Lässt sich das Problem nicht mit den Hinweisen zur Meldung lösen, empfiehlt es sich die Projektdatei zur näheren Untersuchung an den Bartels-Support zu senden.
Dem Layoutbauteil mit dem Namen layoutbauteilname wurden über $plname-Attribute seiner Teilsymbole die unterschiedlichen Gehäuse mit den Namen gehaeusename1 und gehaeusename2 zugewiesen.
Bei unmittelbarem Wechsel in den Schaltplaneditor wird das Schaltplanblatt mit dem betreffenden Symbol geladen und ein
Dem Layoutbauteil mit dem Namen layoutbauteilname wurden für das Attribut attributname die beiden unterschiedlichen Attributwerte wert1 und wert2 zugewiesen. Dies kann dadurch zustande kommen, dass das Layoutbauteil aus mehreren Symbolen zusammengesetzt ist, die zusammengepackt werden und die unterschiedliche Attributwerte besitzen. Als Quelle für die unterschiedlichen Attributwerte des Layoutbauteils kommen das oder die zugehörigen Schaltplansymbole, ein newattr-Kommando in der oder den logischen Definitionen der Symbole oder an das oder die Symbole angehängte Tagsymbole mit Attributzuweisungen in Betracht. Dies ist nur eine Warnungsmeldung, der Packager setzt die Bearbeitung des Projektes fort und verwendet wert1 als Attributwert, der wert2 wird verworfen.
Zur Behebung des Problems sind die Attributzuweisungen der Symbole bzw. der logischen Definitionen anzugleichen.
Dem Layoutbauteil mit dem Namen layoutbauteilname wurden in der Variante mit der Nummer variantennummer für das Attribut attributname die beiden unterschiedlichen Attributwerte wert1 und wert2 zugewiesen. Dies kann dadurch zustande kommen, dass das Layoutbauteil aus mehreren Symbolen zusammengesetzt ist, die zusammengepackt werden und die unterschiedliche Attributwerte besitzen. Als Quelle für die unterschiedlichen Attributwerte des Layoutbauteils kommen das oder die zugehörigen Schaltplansymbole, ein newattr-Kommando in der oder den logischen Definitionen der Symbole oder an das oder die Symbole angehängte Tagsymbole mit Attributzuweisungen in Betracht. Dies ist nur eine Warnungsmeldung, der Packager setzt die Bearbeitung des Projektes fort und verwendet wert1 als Attributwert in der betreffenden Variante, der wert2 wird für diese Variante verworfen.
Zur Behebung des Problems sind die Attributzuweisungen der Symbole bzw. der logischen Definitionen für die betreffende Variante anzugleichen.
Diese Warnungsmeldung wird ausgegeben, wenn bei einem in den logischen Definitionen aus mainpart/subpart zusammengesetzten Baustein für das Layoutbauteil mit dem Namen layoutbauteilnamen das zu der mainpart-Definition gehörige Bauteil im Schaltplan nicht verwendet wird. Abhängig von den logischen Definitionen birgt dies das Risiko, dass wichtige für die Funktion des Bausteins benötigte Pins nicht angeschlossen sind. Das betreffende Symbol für das mainpart sollte auf dem Schaltplan platziert und dessen Eingangspins ggf. auf ein definiertes Potential gelegt werden. Da vom Packager auch nicht benutzte Gatter mit der Bauteilkennung versehen werden, kann es notwendig sein für neu platzierte Symbol das Packen in das bereits bestehende Bauteil durch Setzen des $rpname-Attributs auf den layoutbauteilnamen zu erzwingen.
Hier wird der Name der beim Packager-Lauf verwendeten Standardbibliothek dokumentiert. Auf die Standardbibliothek wird zugegriffen, wenn ein Layoutbauteilmakro oder eine logische Definition nicht in der Projektdatei gefunden werden kann. Layoutbauteilmakros und logische Definitionen werden vom Packager in die Projektdatei kopiert, d.h. es ist nach einem erfolgreichen Packager-Lauf nicht notwendig im Layouteditor die gleiche Layoutbibliothek zu setzen um die in der Netzliste verwendeten Bauteile erfolgreich zu platzieren. Der Parameter Bibliotheksname wird in der Projektdatei gespeichert und muss bei folgenden Packager-Läufen nicht erneut definiert werden.
An dem Symbol mit dem Namen symbolname ist das Attribut $plname zur Selektion einer alternativen Gehäuseform gesetzt, in der logischen Definition für das Symbol ist aber kein default-Kommando angegeben. Das default-Kommando signalisiert, dass alternative Gehäuseformen für dieses Symbol über das Attribut $plname gesetzt werden dürfen. Ohne default-Kommando gilt der in der logischen Definition vorgebenene Gehäusename als feste Vorgabe für das Symbol.
Zur Behebung des Problems ist das default-Kommando in der logischen Definition des Symbols nachzutragen oder das $noplc-Attribut zurückzusetzen und ggf. DANACH der $plname-Text vom Symbol zu entfernen um weitere Fehlzuweisungen zu verhindern.
Bei der Layoutnetznamensbildung für das lokale Netz netzname aus einem hierarchischen Schaltplanblock wurde die maximale Namenslänge von 40 Zeichen überschritten. Zur Bildung des Layoutnetznamens werden die lokalen Netznamen eines mehrfach verwendbaren hierarchischen Schaltplanblattes mit einem Prefix der Form [lblocknummer] versehen um eine Unterscheidung zwischen den lokalen Netzen mehrerer Blockreferenzen zur erhalten. Lokale Netze auf Top-Level Blättern erhalten den festen Prefix [lt]. Je nach Anzahl von Blöcken im Design und der damit verbundenen Länge der blocknummer muss man sich daher bei lokalen Netznamen auf eine Namenslänge von 34 bis 36 Zeichen beschränken. Für ist der Namensprefix [lsblockname]. Die Beschränkung der Netznamenslänge hängt hier wesentlich von der Länge des blocknamens ab.
Zur Problembehebung ist der Netzname im Schaltplan durch Umbenennen des Netzlabels entsprechend zu kürzen.
Bei Bildung des internen Portnetznamens für den Modulport modulportname eines hierarchischen Schaltplanblockes wurde die maximale Namenslänge von 40 Zeichen überschritten. Zur Bildung der internen Portnetznamen werden die Modulportname eines mehrfach verwendbaren hierarchischen Schaltplanblattes mit einem Prefix der Form [mblocknummer] versehen um eine Unterscheidung zwischen den internen Portnetzen mehrerer Blockreferenzen zur erhalten. Lokale Modulports auf Top-Level Blättern erhalten den festen Prefix [mt]. Je nach Anzahl von Blöcken im Design und der damit verbundenen Länge der blocknummer muss man sich daher bei Modulportnamen auf eine Namenslänge von 34 bis 36 Zeichen beschränken. Für ist der Namensprefix [msblockname]. Die Beschränkung der Modulportnamenslänge hängt hier wesentlich von der Länge des blocknamens ab.
Zur Problembehebung ist der Modulportname im Schaltplan durch Umbenennen des Portlabels und Blocksymbolpins entsprechend zu kürzen.
Bei der Layoutbauteilnamensbildung für das Symbol symbolname aus einem hierarchischen Schaltplanblock wurde die maximale Namenslänge von 40 Zeichen überschritten. Zur Bildung des Layoutbauteilnamens wird der Symbolname oder das $rpname-Attribut von Symbolen auf hierarchischen Schaltplanblättern mit einem Prefix der Form [pblocknummer] versehen um eine Unterscheidung zwischen den Layoutbauteilen mehrerer Blockreferenzen zur erhalten. Je nach Anzahl von Blöcken im Design und der damit verbundenen Länge der blocknummer muss man sich daher bei Symbolen auf mehrfach verwendbaren hierarchischen Schaltplanblättern auf eine Namenslänge von 34 bis 36 Zeichen beschränken.
Zur Problembehebung ist der betreffende Symbolname im Schaltplan durch Umbenennen des Symbols zu kürzen.
Der in den vorhergehenden Meldungszeilen aufgelistete Symbolpin ist in der logische Definition für das Symbol im pin-Kommando nicht aufgelistet bzw. falls kein pin-Kommando in der logischen Definition vorhanden ist war keine 1:1-Namenszuordnung zu einem Layoutbauteilpin layoutbauteilpinname des verwendeten Layoutbauteilmakros layoutbauteilmakroname möglich, da es auf dem Layoutbauteilmakro keinen Pin mit diesem Namen gibt.
Bei unmittelbarem Wechsel in den Schaltplaneditor wird das Schaltplanblatt mit dem betreffenden Symbol geladen und ein an die Symbolposition durchgeführt.
Zur Problembehebung ist der fragliche Pin mit einem xlat-Kommando der logischen Definition einem existierenden Layoutbauteilpin zuzuordnen oder in das pin-Kommando der logischen Definition aufzunehmen oder auf dem Layoutbauteilmakro zu platzieren oder auf dem Schaltplansymbol in einen in den pin-Kommandos definierten Namen umzubenennen. Es ist zu beachten, dass nach dem Platzieren/Löschen/Umbenennen von Symbolpins die Schaltpläne mit Platzierungen des bearbeiteten Symbols geladen und gespeichert werden müssen um die vom Packager bearbeiteten logischen Netzlisten auf den neuesten Stand zu bringen. Die Symbolmakros selbst werden vom Packager nicht gelesen. Beim einfachen Laden der Schaltpläne sieht man die neuen/geänderten Pinnamen zwar auf dem Bildschirm, in die logische Netzliste werden die Daten aber erst beim Speichern der Schaltplanblätter übertragen.
Der Lesezugriff auf die DDB- bzw. DAT-Datei mit dem Namen dateiname wurde verweigert. Dies dürfte an mangelnden Zugriffsrechten des Benutzers für diese Datei liegen.
In Betracht kommen für diese Fehlermeldung die Projektdatei, die Standardbibliothek, die Alternativbibliothek oder eine der Setupdateien bsetup.dat (Setupdatei mit Bibliotheksnamen und Defaultlayoutelementnamen), language.vdb (alternative Ausgabemeldungen) oder baewin.dat (Fensterposition und -größe) im BAE-Programmverzeichnis (bzw. einem über die Umgebungsvariable BAE_PROGDIR gesetzten Alternativverzeichnis oder über die Umgebungsvariablen BAE_BSETUP, BAE_LANG oder BAE_WINLIB gesetzte Alternativsetupdateien).
Die über den Namen dateiname spezifizierte Datei ist nicht im gültigen BAE-DDB-Dateiformat. Diese Datei wurde vermutlich nicht mit dem BAE erstellt oder von einem anderen Programm überschrieben. Eine automatische Carriage-Return/Linefeed-Konvertierung bei der Dateiübertragung per E-Mail oder beim Netzwerktransfer zwischen unterschiedlichen Betriebssystemen ist ebenfalls als Fehlerursache denkbar. Zur Überprüfung kann versucht werden die betroffene Datei in einen Texteditor zu laden und aus den ersten Zeichen auf den Inhalt bzw. den Dateityp zu schliessen. Eine gültige DDB-Datei beginnt mit der Zeichenkette DTYPE001.
In Betracht kommen für diese Fehlermeldung die Projektdatei, die Standardbibliothek, die Alternativbibliothek oder eine der Setupdateien bsetup.dat (Setupdatei mit Bibliotheksnamen und Defaultlayoutelementnamen), language.vdb (alternative Ausgabemeldungen) oder baewin.dat (Fensterposition und -größe) im BAE-Programmverzeichnis (bzw. einem über die Umgebungsvariable BAE_PROGDIR gesetzen Alternativverzeichnis oder über die Umgebungsvariablen BAE_BSETUP, BAE_LANG oder BAE_WINLIB gesetzte Alternativsetupdateien).
Der Schreibzugriff auf die DDB- bzw. DAT-Datei mit dem Namen dateiname wurde verweigert. Dies dürfte an einem gesetzten Schreibschutz für die Datei oder mangelnden Zugriffsrechten des Benutzers für diese Datei liegen. In Frage kommen insbesondere von CD-ROMs kopierte Dateien, da beim Kopiervorgang solcher Dateien der Schreibschutz beibehalten wird.
In Betracht kommen für diese Fehlermeldung die Projektdatei, die Standardbibliothek, die Alternativbibliothek oder eine der Setupdateien bsetup.dat (Setupdatei mit Bibliotheksnamen und Defaultlayoutelementnamen), language.vdb (alternative Ausgabemeldungen) oder baewin.dat (Fensterposition und -größe) im BAE-Programmverzeichnis (bzw. einem über die Umgebungsvariable BAE_PROGDIR gesetzten Alternativverzeichnis oder über die Umgebungsvariablen BAE_BSETUP, BAE_LANG oder BAE_WINLIB gesetzte Alternativsetupdateien).
Die über den Namen dateiname spezifizierte DDB- bzw. DAT-Datei ist mit einer neueren Version des BAE abgespeichert worden als die für den Packager-Lauf verwendete und kann daher Einträge enthalten, die von der verwendeten Packager-Version noch nicht unterstützt werden.
Zur Problembehebung ist mindestens auf die gleiche BAE-Versionsnummer upzudaten, die beim Speichern der Datei verwendet wurde. Neuere Versionen können problemlos genutzt werden. Falls die Bearbeitung im Kundenauftrag durchgeführt wird ist jedoch zu bedenken, dass der Kunden für den Rücktransfer der Daten wieder mindestens die gleiche BAE-Versionsnummer benötigt.
In Betracht kommen für diese Fehlermeldung die Projektdatei, die Standardbibliothek, die Alternativbibliothek oder eine der Setupdateien bsetup.dat (Setupdatei mit Bibliotheksnamen und Defaultlayoutelementnamen), language.vdb (alternative Ausgabemeldungen) oder baewin.dat (Fensterposition und -größe) im BAE-Programmverzeichnis (bzw. einem über die Umgebungsvariable BAE_PROGDIR gesetzen Alternativverzeichnis oder über die Umgebungsvariablen BAE_BSETUP, BAE_LANG oder BAE_WINLIB gesetzte Alternativsetupdateien).
Ein Lesezugriff auf die DDB- bzw. DAT-Datei mit dem Namen dateiname konnte nicht durchgeführt werden, da die Datei nicht exisitiert, bzw. keine Zugriffsrechte auf die Datei bzw. das Verzeichnis der Datei vorhanden sind.
Zur Problembehebung sind die Zugriffsrechte entsprechend zu ändern oder die Dateinamen in den Packager-Parametern zu ändern.
In Betracht kommen für diese Fehlermeldung die Projektdatei, die Standardbibliothek, die Alternativbibliothek oder eine der Setupdateien bsetup.dat (Setupdatei mit Bibliotheksnamen und Defaultlayoutelementnamen), language.vdb (alternative Ausgabemeldungen) oder baewin.dat (Fensterposition und -größe) im BAE-Programmverzeichnis (bzw. einem über die Umgebungsvariable BAE_PROGDIR gesetzen Alternativverzeichnis oder über die Umgebungsvariablen BAE_BSETUP, BAE_LANG oder BAE_WINLIB gesetzte Alternativsetupdateien).
Der Lesezugriff auf eine nicht näher spezifizierte DDB- bzw. DAT-Datei wurde verweigert. Dies dürfte an mangelnden Zugriffsrechten des Benutzers für diese Datei liegen.
In Betracht kommen für diese Fehlermeldung die Projektdatei, die Standardbibliothek, die Alternativbibliothek oder eine der Setupdateien bsetup.dat (Setupdatei mit Bibliotheksnamen und Defaultlayoutelementnamen), language.vdb (alternative Ausgabemeldungen) oder baewin.dat (Fensterposition und -größe) im BAE-Programmverzeichnis (bzw. einem über die Umgebungsvariable BAE_PROGDIR gesetzten Alternativverzeichnis oder über die Umgebungsvariablen BAE_BSETUP, BAE_LANG oder BAE_WINLIB gesetzte Alternativsetupdateien).
Eine nicht näher spezifizierte Datei ist nicht im gültigen BAE-DDB-Dateiformat. Diese Datei wurde vermutlich nicht mit dem BAE erstellt oder von einem anderen Programm überschrieben. Eine automatische Carriage-Return/Linefeed-Konvertierung bei der Dateiübertragung per E-Mail oder zwischen unterschiedlichen Betriebssystemen ist ebenfalls als Fehlerursache denkbar. Zur Überprüfung kann versucht werden, die betroffene Datei in einen Texteditor zu laden und aus den ersten Zeichen auf den Inhalt bzw. den Dateityp zu schliessen. Eine gültige DDB-Datei beginnt mit der Zeichenkette DTYPE001.
In Betracht kommen für diese Fehlermeldung die Projektdatei, die Standardbibliothek, die Alternativbibliothek oder eine der Setupdateien bsetup.dat (Setupdatei mit Bibliotheksnamen und Defaultlayoutelementnamen), language.vdb (alternative Ausgabemeldungen) oder baewin.dat (Fensterposition und -größe) im BAE-Programmverzeichnis (bzw. einem über die Umgebungsvariable BAE_PROGDIR gesetzen Alternativverzeichnis oder über die Umgebungsvariablen BAE_BSETUP, BAE_LANG oder BAE_WINLIB gesetzte Alternativsetupdateien).
Der Schreibzugriff auf eine nicht näher spezifizierte DDB- bzw. DAT-Datei wurde verweigert. Dies dürfte an einem gesetzten Schreibschutz für die Datei oder mangelnden Zugriffsrechten des Benutzers für diese Datei liegen. In Frage kommen insbesondere von CD-ROMs kopierte Dateien, da beim Kopiervorgang solcher Dateien der Schreibschutz beibehalten wird.
In Betracht kommen für diese Fehlermeldung die Projektdatei, die Standardbibliothek, die Alternativbibliothek oder eine der Setupdateien bsetup.dat (Setupdatei mit Bibliotheksnamen und Defaultlayoutelementnamen), language.vdb (alternative Ausgabemeldungen) oder baewin.dat (Fensterposition und -größe) im BAE-Programmverzeichnis (bzw. einem über die Umgebungsvariable BAE_PROGDIR gesetzten Alternativverzeichnis oder über die Umgebungsvariablen BAE_BSETUP, BAE_LANG oder BAE_WINLIB gesetzte Alternativsetupdateien).
Eine nicht näher spezifizierte DDB- bzw. DAT-Datei ist mit einer neueren Version des BAE abgespeichert worden als die für den Packager-Lauf verwendete und kann daher Einträge enthalten, die von der verwendeten Packager-Version noch nicht unterstützt werden.
Zur Problembehebung ist mindestens auf die gleiche BAE-Versionsnummer upzudaten, die beim Speichern der Dateien verwendet wurde. Neuere Versionen können problemlos genutzt werden. Falls die Bearbeitung im Kundenauftrag durchgeführt wird ist jedoch zu bedenken, dass der Kunden für den Rücktransfer der Daten wieder mindestens die gleiche BAE-Versionsnummer benötigt.
In Betracht kommen für diese Fehlermeldung die Projektdatei, die Standardbibliothek, die Alternativbibliothek oder eine der Setupdateien bsetup.dat (Setupdatei mit Bibliotheksnamen und Defaultlayoutelementnamen), language.vdb (alternative Ausgabemeldungen) oder baewin.dat (Fensterposition und -größe) im BAE-Programmverzeichnis (bzw. einem über die Umgebungsvariable BAE_PROGDIR gesetzen Alternativverzeichnis oder über die Umgebungsvariablen BAE_BSETUP, BAE_LANG oder BAE_WINLIB gesetzte Alternativsetupdateien).
Ein Lesezugriff auf eine nicht näher spezifizierte DDB- bzw. DAT-Datei konnte nicht durchgeführt werden, da die Datei nicht exisitiert, bzw. keine Zugriffsrechte auf die Datei bzw. das Verzeichnis der Datei vorhanden sind. Da im Packager für alle Dateizugriffe eigene Fehlermeldungen mit Dateinamen definiert sind, deutet diese Meldung auf ein internes Problem im Packager hin.
Zur Problembehebung kann versucht werden den Packager zu verlassen und erneut aufzurufen.
In Betracht kommen für diese Fehlermeldung die Projektdatei, die Standardbibliothek, die Alternativbibliothek oder eine der Setupdateien bsetup.dat (Setupdatei mit Bibliotheksnamen und Defaultlayoutelementnamen), language.vdb (alternative Ausgabemeldungen) oder baewin.dat (Fensterposition und -größe) im BAE-Programmverzeichnis (bzw. einem über die Umgebungsvariable BAE_PROGDIR gesetzen Alternativverzeichnis oder über die Umgebungsvariablen BAE_BSETUP, BAE_LANG oder BAE_WINLIB gesetzte Alternativsetupdateien).
Beim Zugriff auf eine nicht näher spezifizierte DDB- bzw. DAT-Datei wurde ein internes Limit für Blockgrössen oder verschachtelte Dateisektionen überschritten. Dies sollte im normalen Packager-Betrieb nicht vorkommen und könnte ein Folgefehler aus vorhergehenden Packager-Läfen der gleichen Packager-Sitzung sein oder auf Datenfehler in der bearbeiteten DDB- bzw. DAT-Datei hindeuten.
Zur Problembehebung kann versucht werden den Packager zu verlassen und erneut aufzurufen.
In Betracht kommen für diese Fehlermeldung die Projektdatei, die Standardbibliothek, die Alternativbibliothek oder eine der Setupdateien bsetup.dat (Setupdatei mit Bibliotheksnamen und Defaultlayoutelementnamen), language.vdb (alternative Ausgabemeldungen) oder baewin.dat (Fensterposition und -größe) im BAE-Programmverzeichnis (bzw. einem über die Umgebungsvariable BAE_PROGDIR gesetzen Alternativverzeichnis oder über die Umgebungsvariablen BAE_BSETUP, BAE_LANG oder BAE_WINLIB gesetzte Alternativsetupdateien).
Beim Zugriff auf die DDB- bzw. DAT-Datei mit dem Namen dateiname ist ein Fehler aufgetreten. Dies kann an einem Fehler auf dem Datenträger, einem vollen Datenträger oder mangelnden Zugriffsrechten des Benutzers für diese Datei liegen.
In Betracht kommen für diese Fehlermeldung die Projektdatei, die Standardbibliothek, die Alternativbibliothek oder eine der Setupdateien bsetup.dat (Setupdatei mit Bibliotheksnamen und Defaultlayoutelementnamen), language.vdb (alternative Ausgabemeldungen) oder baewin.dat (Fensterposition und -größe) im BAE-Programmverzeichnis (bzw. einem über die Umgebungsvariable BAE_PROGDIR gesetzen Alternativverzeichnis oder über die Umgebungsvariablen BAE_BSETUP, BAE_LANG oder BAE_WINLIB gesetzte Alternativsetupdateien).
Beim Zugriff auf eine nicht näher spezifizierte DDB- bzw. DAT-Datei ist ein Fehler aufgetreten. Dies kann an einem Fehler auf dem Datenträger, einem vollen Datenträger oder mangelnden Zugriffsrechten des Benutzers für diese Datei liegen.
In Betracht kommen für diese Fehlermeldung die Projektdatei, die Standardbibliothek, die Alternativbibliothek oder eine der Setupdateien bsetup.dat (Setupdatei mit Bibliotheksnamen und Defaultlayoutelementnamen), language.vdb (alternative Ausgabemeldungen) oder baewin.dat (Fensterposition und -größe) im BAE-Programmverzeichnis (bzw. einem über die Umgebungsvariable BAE_PROGDIR gesetzen Alternativverzeichnis oder über die Umgebungsvariablen BAE_BSETUP, BAE_LANG oder BAE_WINLIB gesetzte Alternativsetupdateien).
Die DDB- bzw. DAT-Datei mit dem Namen dateiname konnte nicht angelegt werden. Dies kann an mangelnden Zugriffsrechten auf das Verzeichnis der Datei liegen. Da im normalen Packager-Betrieb DDB- und DAT-Dateien nur geändert und nicht neu angelegt werden, deutet dies auf einen während dem Packager-Lauf aufgetreteten Fehler auf dem Datenträger oder das Fremdverschieben/Löschen der DDB- bzw. DAT-Datei während des Packager-Laufes hin (z.B. durch einen anderen Anwender im Netzwerk).
In Betracht kommt für diese Fehlermeldung nur die Projektdatei, da auf andere DDB- und DAT-Dateien nur lesend zugegriffen wird.
Eine nicht näher spezifizierte DDB- bzw. DAT-Datei konnte nicht angelegt werden. Dies kann an mangelnden Zugriffsrechten auf das Verzeichnis der Datei liegen. Da im normalen Packager-Betrieb DDB- und DAT-Dateien nur geändert und nicht neu angelegt werden, deutet dies auf einen während dem Packager-Lauf aufgetreteten Fehler auf dem Datenträger oder das Fremdverschieben/Löschen der DDB- bzw. DAT-Datei während des Packager-Laufes hin (z.B. durch einen anderen Anwender im Netzwerk).
In Betracht kommt für diese Fehlermeldung nur die Projektdatei, da auf andere DDB- und DAT-Dateien nur lesend zugegriffen wird.
Das Datenbankelement mit dem Namen elementname konnte in einer DDB- bzw. DAT-Datei nicht gefunden werden. Da im Packager für alle Elementzugriffe eigene Fehlermeldungen mit Elementnamen definiert sind, deutet diese Meldung auf ein internes Problem im Packager hin und die Projektdatei sollte zur näheren Untersuchung an den Bartels-Support gesendet werden.
Ein nicht näher spezifiziertes Datenbankelement konnte in einer DDB- bzw. DAT-Datei nicht gefunden werden. Da im Packager für alle Elementzugriffe eigene Fehlermeldungen mit Elementnamen definiert sind, deutet diese Meldung auf ein internes Problem im Packager hin und die Projektdatei sollte zur näheren Untersuchung an den Bartels-Support gesendet werden.
Die von der logischen Definition mit dem Namen definitionsname über das subpart-Kommando referenzierte logische Definition enthält kein mainpart-Kommando. Dies ist nicht erlaubt. Von subpart-Kommandos referenzierte logische Definition müssen als mainpart deklariert sein.
Bei unmittelbarem Wechsel in den Schaltplaneditor wird das Schaltplanblatt mit dem betreffenden Symbol geladen und ein an die Symbolposition durchgeführt.
Zur Behebung des Problems ist die referenzierte logische Definition um das mainpart zu ergänzen.
Das in der vorhergehenden Meldungszeile aufgeführte Symbol mit der logischen Definition definitionsname ist das mehr als 32. unterschiedliche subpart eines aus mainpart/subpart-Symbolen zusammengesetzten Bausteins. Für solche Unterbauteile ist das net internal-Kommando inaktiv und ggf. angeforderte interne Verbindungen werden nicht in der Netzliste realisiert.
Bei unmittelbarem Wechsel in den Schaltplaneditor wird das Schaltplanblatt mit dem betreffenden Symbol geladen und ein an die Symbolposition durchgeführt.
Zur Behebung dieses Problems können die gewünschten Verbindungen in net internal-Kommandos des mainpart angegeben werden.
Diese Meldung am Ende des Packager-Laufes signalisiert, dass über net-Kommandos dem Netz n.c. zugewiesene Pins für die Netzliste ignoriert wurden. Diese Zuordnung ist nützlich, wenn auf der ersten für das Symbol gelisteten Alternativbauform funktionslose Pins vorhanden sind, die auf anderen Bauformen der Alternativbauformliste fehlen. Da der Packager normalerweise für jeden Pin automatisch ein Netz anlegt, kommt es ohne Zuordnung zum n.c.-Netz nach dem Wechsel zu diesen Alternativbauformen ggf. zu Fehlermeldungen über fehlende Netzlistenpins.
Ein Datenbankelement in der Datei dateiname enthält Optionen, die vom Packager nicht verstanden werden. Dies kann von einem Fehler auf dem Datenträger oder der Verwendung einer neueren BAE-(Zwischen)Version beim Speichern der Schaltpläne, logischen Definitionen, Layoutbauteilmakros oder Layouts herrühren.
Zur Problembehebung kann versucht werden die logischen Definitionen erneut in das Projekt bzw. die verwendete Bibliothek einzuspielen bzw. die Schaltpläne zu laden und erneut zu speichern. Sollte dies nicht zur Behebung des Problems führen empfiehlt es sich die Projektdatei zur näheren Untersuchung an den Bartels-Support zu senden.
Ein Datenbankelement in einer nicht näher spezifizierten DDB- bzw. DAT-Datei enthält Optionen, die vom Packager nicht verstanden werden. Dies kann von einem Fehler auf dem Datenträger oder der Verwendung einer neueren BAE-(Zwischen)Version beim Speichern der Schaltpläne, logischen Definitionen, Layoutbauteilmakros oder Layouts herrühren.
Zur Problembehebung kann versucht werden die logischen Definitionen erneut in das Projekt bzw. die verwendete Bibliothek einzuspielen bzw. die Schaltpläne zu laden und erneut zu speichern. Sollte dies nicht zur Behebung des Problems führen empfiehlt es sich die Projektdatei zur näheren Untersuchung an den Bartels-Support zu senden.
Einer der für Projektdatei oder Bibliotheken angegebenen Dateinamen enthält für Dateinamen ungültige Steuerzeichen oder die ebenfalls ungültigen Zeichen ? und * oder der Projektdateiname ( / ) ist nicht gesetzt.
Zur Problembehebung ist der Projektdateiname zu setzen oder es sind Dateinamen zu verwenden, die diese ungültigen Zeichen nicht enthalten.
Der unter / angegebene Zielname für die Layoutnetzliste enthält für Elementnamen ungültige Steuerzeichen oder die ebenfalls ungültigen Zeichen ? und * oder ist nicht gesetzt.
Zur Problembehebung ist ein anderer Zielname für die Layoutnetzliste zu spezifizieren.
Diese Meldung dokumentiert den Namen der aktuell bearbeiteten Projektdatei. Die Verbindungsdaten und Symbole der in dieser Datei vorhandenen Schaltpläne werden vom Packager in eine Layoutnetzliste mit Bauteilen und Netzen zusammengefasst.
Die DDB- bzw. DAT-Datei mit dem Namen dateiname hat nicht das erwartete Format. Dies kann auf einen Fehler auf dem Datenträger hinweisen oder rührt daher, dass ein vorangegangener Schreibvorgang in die Datei nicht korrekt beendet wurde. Beim Beginn des Schreibzugriffs in DDB- und DAT-Dateien wird im Header des Datei ein Flag gesetzt, das erst nach dem erfolgreichem Abschluss des Schreibvorgangs zuruückgesetzt wird. Das Vorhandensein dieses Flags wird ebenfalls mit dieser Meldung signalisiert.
Zur Problembehebung kann die -Option des Utilityprogrammes copyddb verwendet werden. Sollte dies nicht zur Behebung des Problems führen kann die Projektdatei zur näheren Untersuchung an den Bartels-Support gesandt werden.
In Betracht kommen für diese Fehlermeldung die Projektdatei, die Standardbibliothek, die Alternativbibliothek oder eine der Setupdateien bsetup.dat (Setupdatei mit Bibliotheksnamen und Defaultlayoutelementnamen), language.vdb (alternative Ausgabemeldungen) oder baewin.dat (Fensterposition und -größe) im BAE-Programmverzeichnis (bzw. einem über die Umgebungsvariable BAE_PROGDIR gesetzen Alternativverzeichnis oder über die Umgebungsvariablen BAE_BSETUP, BAE_LANG oder BAE_WINLIB gesetzte Alternativsetupdateien).
Eine nicht näher spezifizierte DDB- bzw. DAT-Datei hat nicht das erwartete Format. Dies kann auf einen Fehler auf dem Datenträger hinweisen oder rührt daher, dass ein vorangegangener Schreibvorgang in die Datei nicht korrekt beendet wurde. Beim Beginn des Schreibzugriffs in DDB- und DAT-Dateien wird im Header des Datei ein Flag gesetzt, das erst nach dem erfolgreichem Abschluss des Schreibvorgangs zuruückgesetzt wird. Das Vorhandensein dieses Flags wird ebenfalls mit dieser Meldung signalisiert.
Zur Problembehebung kann die -Option des Utilityprogrammes copyddb verwendet werden. Sollte dies nicht zur Behebung des Problems führen kann die Projektdatei zur näheren Untersuchung an den Bartels-Support gesandt werden.
In Betracht kommen für diese Fehlermeldung die Projektdatei, die Standardbibliothek, die Alternativbibliothek oder eine der Setupdateien bsetup.dat (Setupdatei mit Bibliotheksnamen und Defaultlayoutelementnamen), language.vdb (alternative Ausgabemeldungen) oder baewin.dat (Fensterposition und -größe) im BAE-Programmverzeichnis (bzw. einem über die Umgebungsvariable BAE_PROGDIR gesetzen Alternativverzeichnis oder über die Umgebungsvariablen BAE_BSETUP, BAE_LANG oder BAE_WINLIB gesetzte Alternativsetupdateien).
Der in den Schaltplaneinstellungen als deklarierte hierarchische Schaltplanblock blockname wird von mehreren Blocksymbolen referenziert.
Zur Problembehebung sind überzählige Blockreferenzsymbole zu löschen oder der betreffende hierarchische Schaltplan ist als normaler mehrfach verwendbarer zu deklarieren.
In der für die Bearbeitung selektierten Projektdatei sind keine Schaltplannetzlisten hinterlegt. Sind in dem Projekt Schaltpläne ladbar deutet dies darauf hin, das diese lediglich als Gruppen gespeichert wurden, die keine logische Netzliste besitzen. In diesem Fall sind die Schaltpläne in den Schaltplaneditor zu laden und abzuspeichern. Beim Speichern wird eine logische Netzliste in der Projektdatei generiert. Beim Import von Netzlisten aus Fremdsystemen deutet diese Meldung darauf hin, dass das Einspielen der logischen Netzliste mit Hilfe der Anwenderfunktionen conconv oder netconv nicht erfolgreich war. Die Konvertierung sollte erneut gestartet und auf Fehlermeldungen geachtet werden.
Gratulation, Sie haben soeben erfolgreich eine Layoutnetzliste für das angegebene Projekt generiert! Evtl. ausgegebenen Warnungsmeldungen sollte noch einmal Beachtung geschenkt werden, sie können Hinweise auf unbeabsichtigte unterschiedliche Attributzuweisungen für Symbole und dergleichen enthalten. Wird nach erfolgreichem Abschluss des Packager-Laufes unmittelbar in den Layouteditor gewechselt, so wird das zur erzeugten Layoutnetzliste gehörige gleichnamige Projektlayout automatisch in den Layouteditor geladen. Gibt es das Layout noch nicht, so wird das Anlegen des Layouts vorgeschlagen. Es ist zu beachten, das im Layouteditor in der Projektdatei zwar andersnamige Layouts angelegt werden können, diese haben aber keinen Bezug zu der erzeugten Layoutnetzliste wenn der Name des Layouts nicht identisch mit dem Namen der Layoutnetzliste ist.
Beim Packager-Lauf ist ein unerwarteter Fehler aufgetreten (z.B. wenn die Suche nach einem Listenelement fehlschlägt, unmittelbar nachdem es in die Liste gespeichert wurde). Dies deutet entweder auf ein Problem mit der Rechnerhardware oder ein noch nicht bekanntes Problem im Packager hin. Tritt das Problem reproduzierbar nur bei einem Projekt auf, empfiehlt es sich die Projektdatei zur näheren Untersuchung an den Bartels-Support zu senden.
In der logischen Definition des in der vorhergehenden Meldungszeile aufgelisteten Symbols ist in einem net-Kommando das Attribut mit dem Namen attributname als Quelle für den Netznamen angegeben. Das Attribut ist an dem Symbol aber nicht gesetzt worden.
Bei unmittelbarem Wechsel in den Schaltplaneditor wird das Schaltplanblatt mit dem betreffenden Symbol geladen und ein an die Symbolposition durchgeführt.
Zur Problembehebung ist das Attribut attributname an dem betreffenden Symbol zu setzen.
In der logischen Definition des in der vorhergehenden Meldungszeile aufgelisteten Symbols ist in einem net-Kommando das Attribut mit dem Namen attributname als Quelle für den Netznamen angegeben. Der Attributwert dieses Attributes stellt keinen gültigen Netznamen dar. In Netznamen unzulässige Zeichen sind ?, *, sowie nicht druckbare Zeichencodes. Gross-/Kleinschreibung spielt keine Rolle, die Namen werden automatisch in Kleinschreibung umgewandelt. Leerzeichen werden ausgefiltert und gelten somit nicht als ungültige Zeichen. Es wird dabei nur der erste nicht aus Leerzeichen bestehende Teilstring als Netznamen verwendet.
Bei unmittelbarem Wechsel in den Schaltplaneditor wird das Schaltplanblatt mit dem betreffenden Symbol geladen und ein an die Symbolposition durchgeführt.
Zur Problembehebung ist in das Attribut attributname des betreffenden Symbols ein gültiger Netzname einzutragen.
In der logischen Definition des in der vorhergehenden Meldungszeile aufgelisteten Symbols ist in einem net-Kommando dem Layoutbauteilpin mit dem Namen layoutbauteilpinname ein festes Netz für die Netzliste vorgegeben. Der Pin ist auf dem über die logische Definition des Symbols oder das Symbolattribut $plname angeforderten Layoutbauteilmakro aber nicht vorhanden.
Abhängig vom eingestellten Modus für die ist dies eine Warnungs- oder eine Fehlermeldung. Im Falle einer Warnung setzt der Packager die Bearbeitung fort, als ob es den Pin auf dem Layoutbauteilmakro gäbe und man kann diesen nachträglich auf dem Layoutbauteilmakro platzieren um ein zur Netzliste passendes Layout zu erhalten. Im Falle eines Fehlers wird bei einem unmittelbarem Wechsel in den Schaltplaneditor das Schaltplanblatt mit dem Symbol, das das Layoutbauteil referenziert, geladen und ein an die Symbolposition durchgeführt.
Zur Problembehebung ist das Attribut attributname an dem betreffenden Symbol zu setzen.
Zur Problembehebung ist der Pin auf dem Layoutbauteilmakro zu platzieren oder der Gehäusename in der logische Definition bzw. dem $plname-Attribut des Symbols zu korrigieren.
Bei der Bearbeitung des Layoutbauteils mit dem Namen layoutbauteilname ist ein Problem aufgetreten, das in den nachfolgenden Meldungszeilen noch genauer spezifiziert wird.
Die für den Pin layoutbauteilpinname des Layoutbauteils mit dem Namen layoutbauteilname definierte Pinfunktion pinfunktionsname erzeugt im angeschlossenen Netz einen Konflikt bzw. Fehler, der in den vorhergehenden Meldungszeilen genauer spezifiziert ist.
In einem aus mehreren Symbolen/Gattern zusammengesetzten Layoutbauteil ist das $noplc-Attribut an den Untersymbolen unterschiedlich gesetzt. Der Packager gibt hierbei der Platzierungsanforderung Vorrang, wodurch aber auch als unplatziert markierte Untersymbole mitplatziert werden. Es bleibt dem Benutzer überlassen zu entscheiden, ob dies die Funktion der Schaltung beeinträchtigt. Die Symbole mit kollidierenden Platzierungsanforderungen werden in Folgemeldungszeilen aufgelistet.
Zur Problembehebung ist das $noplc-Attribut in den Untersymbolen ggf. auf einheitliche Werte zu setzen.
Bei der Bearbeitung des Schaltplansymbols mit dem Namen symbolname ist ein Problem aufgetreten, das in den nachfolgenden Meldungszeilen noch genauer spezifiziert wird.
Bei der Bearbeitung des Layoutbauteils mit dem Namen layoutbauteilname ist ein Problem aufgetreten, das in den nachfolgenden Meldungszeilen noch genauer spezifiziert wird.
Das Symbol mit dem Namen symbolname möchte über sein $vgrp-Attribut in das in der vorhergehenden Meldungszeile dokumentierte Layoutvariantenbauteil gepackt werden und signalisiert durch sein in der Variante mit der Nummer variantennummer nicht gesetztes $noplc-Attribut, dass es in dieser Variante platziert werden soll. Das Layoutvariantenbauteil ist für diese Variante aber bereits durch ein anderes Symbol mit gleich gesetzten $vgrp-und $noplc-Attributen belegt.
Bei unmittelbarem Wechsel in den Schaltplaneditor wird das Schaltplanblatt mit dem betreffenden Symbol geladen und ein an die Symbolposition durchgeführt.
Zur Problembehebung sind die $noplc-Werte der in das betreffende über $vgrp selektierte Layoutvariantenbauteil gepackten Symbole so zu koordinieren, dass pro Variante nur jeweils ein Symbol für die Platzierung aktiv ist.
Beim Zugriff auf eine mit einer sehr alten BAE-Version gespeicherte DDB- bzw. DAT-Datei ist ein Problem aufgetreten. Da der Packager für alle betreffenden alten Formateinträge Behandlungsroutinen implementiert sind, deutet diese Meldung auf ein internes Problem im Packager hin, und die Projektdatei sollte zur näheren Untersuchung an den Bartels-Support gesendet werden.
In den logischen Definition des in der vorhergehenden Meldungszeile aufgelisteten Blocksymbols eines hierarchischen Schaltplans wurde über das call-Kommando ein blockname referenziert, der auf keinem der als bzw. deklarierten Schaltpläne des Projektes als Plan Blockname definiert ist, d.h. der oder die Schaltpläne zu dem Blocksymbol fehlen.
Zur Problembehebung sind die Schaltpläne zu zeichnen, bzw. die Blocknamen im call-Kommando oder den Planeinstellungen zu korrigieren.
Der auf dem in der vorhergehenden Meldungszeile aufgelisteten Symbol vorhandene Pin mit dem Namen symbolpinname ist in der logische Definition für das Symbol im pin-Kommando nicht aufgelistet bzw. falls kein pin-Kommando in der logischen Definition vorhanden ist war keine 1:1-Namenszuordnung zu einem Layoutbauteilpin des verwendeten Layoutbauteilmakros möglich, da es auf dem Layoutbauteilmakro keinen Pin mit diesem Namen gibt.
Bei unmittelbarem Wechsel in den Schaltplaneditor wird das Schaltplanblatt mit dem betreffenden Symbol geladen und ein an die Symbolposition durchgeführt.
Zur Problembehebung ist der fragliche Pin mit einem xlat-Kommando der logischen Definition einem existierenden Layoutbauteilpin zuzuordnen oder in das pin-Kommando der logischen Definition aufzunehmen oder auf dem Layoutbauteilmakro zu platzieren oder auf dem Schaltplansymbol in einen in den pin-Kommandos definierten Namen umzubenennen. Es ist zu beachten, dass nach dem Platzieren/Löschen/Umbenennen von Symbolpins die Schaltpläne mit Platzierungen des bearbeiteten Symbols geladen und gespeichert werden müssen um die vom Packager bearbeiteten logischen Netzlisten auf den neuesten Stand zu bringen. Die Symbolmakros selbst werden vom Packager nicht gelesen. Beim einfachen Laden der Schaltpläne sieht man die neuen/geänderten Pinnamen zwar auf dem Bildschirm, in die logische Netzliste werden die Daten aber erst beim Speichern der Schaltplanblätter übertragen.
Diese Meldung dokumentiert den Namen der vom Packger zu erzeugenden Layoutnetzliste. Dieser sollte identisch mit dem später für das Layout verwendeten Elementnamen sein, das der Bezug zwischen Layout und Layoutnetzliste über den Namen hergestellt wird. Wird das Layout anders benannt, so werden die Einträge der Netzliste nicht berücksichtigt und eine leere Netzliste mit dem Namen des Layoutelementes erzeugt und verwendet.
Das von dem in der vorhergehenden Meldungszeile aufgelisteten Symbol über die logische Definition oder das Attribut $plname angeforderte Layoutbauteilmakro mit dem Namen layoutbauteilmakroname konnte weder in der Projektdatei noch in den angegebenen Bibliotheken gefunden werden.
Abhängig vom eingestellten Modus für die ist dies eine Warnungs- oder eine Fehlermeldung. Im Falle einer Warnung setzt der Packager die Bearbeitung fort, als ob es das Layoutbauteilmakro gäbe (für die referenzierten Pins wird dann noch jeweils eine eigene Warnung ausgegeben) und man kann das Layoutbauteilmakro erst nachträglich erstellen um ein zur Netzliste passendes Layout zu erhalten. Im Falle eines Fehlers wird bei einem unmittelbarem Wechsel in den Schaltplaneditor das Schaltplanblatt mit dem betreffenden Symbol geladen und ein an die Symbolposition durchgeführt.
Zur Problembehebung ist das Layoutbauteilmakro zu erstellen oder der Gehäusename in der logische Definition bzw. dem $plname-Attribut des Symbols zu korrigieren (Gross-/Kleinschreibung spielt im $plname-Attribut keine Rolle).
Die von dem in der vorhergehenden Meldungszeile aufgelisteten Symbol angeforderte logische Definition mit dem Namen definitionsname konnte weder in der Projektdatei noch in den angegebenen Bibliotheken gefunden werden. Der Name der logischen Definition ist per Default der Name des Symbolmakros. Über das Attribut $rlname (requested logical library name) kann auch ein alternativer vom Symbolmakronamen abweichender Definitionsname selektiert werden. Mit dem Attribut $rlext kann zur Definitionsnamensbildung dem Symbolmakronamen bzw. dem Wert von $rlname eine Namenserweiterung der Art basisname_rlextwert angehängt werden. Bei über das $vgrp-Attribut zusammengepackten variantenabhängig belegten Layoutbauteilen können $rlname-und $rlext-Attribute auch von den mit gleichem $vgrp benannten Nachbarsymbolen verwendet werden, wenn das Symbol keine eigenen Zuweisungen für diese Attribute besitzt.
Bei unmittelbarem Wechsel in den Schaltplaneditor wird das Schaltplanblatt mit dem betreffenden Symbol geladen und ein an die Symbolposition durchgeführt.
Zur Behebung des Problems kann entweder die angeforderte logische Definition angelegt werden, in die verwendeten Bibliotheken/das Projekt kopiert werden, andere Bibliotheken verwendet werden oder die angeforderte logische Definition in den Attributen $rlname bzw. $rlext korrigiert werden.
Der auf dem in der logischen Definition des in der vorhergehenden Meldungszeile aufgelisteten Symbols im pin-Kommando aufgelistete Pin mit dem Namen symbolpinname ist in keinem der xlat-Kommandos mit Zuordnungen zu Layoutbauteilpins aufgeführt und es ist auch keine 1:1-Namenszuordnung zu einem Layoutbauteilpin des verwendeten Layoutbauteilmakros möglich, da es auf dem Layoutbauteilmakro keinen Pin mit diesem Namen gibt.
Abhängig vom eingestellten Modus für die ist dies eine Warnungs- oder eine Fehlermeldung. Im Falle einer Warnung setzt der Packager die Bearbeitung fort, als ob es den Pin auf dem Layoutbauteilmakro gäbe und führt eine 1:1-Zuweisung des Symbolpins zu diesem Pin durch und man kann diesen nachträglich auf dem Layoutbauteilmakro platzieren um ein zur Netzliste passendes Layout zu erhalten. Im Falle eines Fehlers wird bei einem unmittelbarem Wechsel in den Schaltplaneditor das Schaltplanblatt mit dem betreffenden Symbol geladen und ein an die Symbolposition durchgeführt.
Zur Problembehebung ist der fragliche Pin in die xlat-Kommandos der logischen Definition aufzunehmen oder auf dem Layoutbauteilmakro zu platzieren oder auf dem Schaltplansymbol in einen in den xlat-Kommandos definierten Namen umzubenennen. Es ist zu beachten, dass nach dem Platzieren/Löschen/Umbenennen von Symbolpins die Schaltpläne mit Platzierungen des bearbeiteten Symbols geladen und gespeichert werden müssen um die vom Packager bearbeiteten logischen Netzlisten auf den neuesten Stand zu bringen. Die Symbolmakros selbst werden vom Packager nicht gelesen. Beim einfachen Laden der Schaltpläne sieht man die neuen/geänderten Pinnamen zwar auf dem Bildschirm, in die logische Netzliste werden die Daten aber erst beim Speichern der Schaltplanblätter übertragen.
Dem Netz mit dem Namen netzname wurden über das Netzattribut $nettype von verschiedenen Symbolen aus unterschiedliche Netztypen zugewiesen. netztyp1 gibt dabei den zuerst gefundenen Netztyp an und netztyp2 den davon abweichenden zweiten Netztyp, der über das Symbol mit dem Namen symbolname zugewiesen wurde. Wird für den Symbolnamen ein Leerstring ausgegeben, stammt die Netztypzuweisung aus einer dem Netzlabel zugeordneten logischen Definition. Bei Netzen mit unterschiedlichen Netztypzuweisungen trägt der Packager automatisch den Netztyp mixed ein.
Zur Problembehebung sind die Netztypzuweisungen für ein Netz zu vereinheitlichen.
Das Netz mit dem Namen netzname ist in der logischen Netzliste des unter "Aktiver Planname" dokumentierten Schaltplanblattes mit unterschiedliche Netznummern aufgeführt. Dies ist nicht erlaubt. Da die Netznummern im BAE automatisch vergeben werden, deutet dies evtl. auf ein internes Problem hin.
Zur Problembehebung kann versucht werden das betreffende Schaltplanblatt im Schaltplaneditor zu laden und erneut zu speichern. Dabei wird die logische Netzliste neu generiert. Sollte dies nicht zur Behebung des Problems führen empfiehlt es sich die Projektdatei zur näheren Untersuchung an den Bartels-Support zu senden.
Wurde die logische Netzliste mit Hilfe der Anwenderfunktionen conconv oder netconv aus einem Fremdsystem importiert, ist zu überprüfen, ob die ungültige Mehrfachzuweisung von Netznummern nicht von entsprechenden Vorgaben in der Quellnetzliste herrührt.
An das Netz mit dem Namen netzname sind ein oder mehrere Pins angeschlossen, die über das Attribut $pintype als vom Typ in (d.h. Eingang) deklariert sind aber keine Pins vom Typ out (output, d.h. Ausgang), bidi (bidirektional) oder sup (supply, d.h. Versorgungsspannung). Das Netz befindet sich dadurch auf keinem definierten Potential und die Funktionsfähigkeit der Schaltung ist zweifelhaft. Die Pins des Netzes und ihre Funktionen werden in folgenden Meldungszeilen aufgelistet.
Zur Problembehebung ist das Netz durch entsprechende Pins auf definiertes Potential zu legen.
Es wurde versucht dem Netz mit dem Namen netzname über das $drcblk-Netzattribut (das in der logischen Definition auch durch einen anderen Symbolattributnamen ersetzt oder auf einen festen Wert gesetzt werden kann) des in der vorhergehenden Meldungszeile aufgelisteten Symbols eine negative DRC-Blocknummer zuzuweisen. Es sind nur positive DRC-Blocknummern erlaubt größer gleich Null erlaubt. In den Standardbibliotheken des BAE kommen nur die Symbole att_drcblk, tag_net_drcblk, tag_netpin_drcblk und tag_netarea_drcblk aus der Bibliothek route.ddb für diese Fehlermeldung in Betracht.
Die DRC-Blocknummer wird nur in der HighEnd-Version des Layouteditors für den Abstands-DRC berücksichtigt.
Bei unmittelbarem Wechsel in den Schaltplaneditor wird das Schaltplanblatt mit dem die ungütige Zuweisung vornehmenden Symbol geladen und ein an die Symbolposition durchgeführt.
Zur Problembehebung ist dem Symbol in der logischen Definition bzw. im Schaltplan ein gültiger Wert für die DRC-Blocknummer des Netzes zuzuweisen.
Das Netz mit dem Namen netzname ist in der logischen Netzliste des unter "Aktiver Planname" dokumentierten Schaltplanblattes mit einer negativen Netznummer aufgeführt. Dies ist nicht erlaubt. Da die Netznummern im BAE automatisch vergeben werden, deutet dies evtl. auf ein internes Problem hin.
Zur Problembehebung kann versucht werden das betreffende Schaltplanblatt im Schaltplaneditor zu laden und erneut zu speichern. Dabei wird die logische Netzliste neu generiert. Sollte dies nicht zur Behebung des Problems führen empfiehlt es sich die Projektdatei zur näheren Untersuchung an den Bartels-Support zu senden.
Wurde die logische Netzliste mit Hilfe der Anwenderfunktionen conconv oder netconv aus einem Fremdsystem importiert, ist zu überprüfen, ob die ungültige Netznummer nicht von einer entsprechenden Vorgabe in der Quellnetzliste herrührt.
Es wurde versucht dem Netz mit dem Namen netzname über mehrere $drcblk-Netzattribute unterschiedliche DRC-Blocknummern zuzuweisen. Da nur eine DRC-Blocknummer pro Netz erlaubt ist, ist die Zuordnung somit nicht eindeutig.
Die DRC-Blocknummer wird nur in der HighEnd-Version des Layouteditor für den Abstands-DRC berücksichtigt.
Bei unmittelbarem Wechsel in den Schaltplaneditor wird das Schaltplanblatt mit dem Symbol, das die unterschiedliche Zuweisung vornimmt geladen und ein an die Symbolposition durchgeführt.
Zur Problembehebung ist eine der DRC-Blocknummernzuweisungen zurückzunehmen.
Dem Netz mit dem Namen netzname sind für das Netzattribut attributname unterschiedliche Werte zugewiesen worden. Dies kann durch in den logischen Definition von an das Netz angeschlossenen Labels und Symbolen vorgenommene Netzattributzuweisungen und/oder über Netzattributzuweisungen mit an das Netz zugewiesenen Tagsymbolen geschehen sein. Der Name des den Konflikt verursachenden Symbols wird unter symbolname angegeben.
Zur Problembehebung sind die Netzattributzuweisungen in den logischen Definitionen oder den Tagsymbolen anzugleichen oder überzählige Attributzuweisungen zu entfernen.
Einen Sonderfall stellt das Netzpinattribut $net dar, das von Packager und automatisch auf den Namen des angeschlossenen Netzes gesetzt wird. Beim ersten Packagerlauf nach Netzlistenänderungen werden diese Warnungsmeldungen durch Kollision alter Pinnetznamen mit neuen Pinnetznamen verursacht und können ignoriert bzw. als Dokumentation der Netznamensänderungen (vor allem bei den automatisch generierten mit @ beginnenden Netznamen) verwendet werden. Nach dem Abgleich der $net-Attribute durch den Packager treten die Warnungsmeldungen bei folgenden Packager-Läufen nicht mehr auf.
Die logische Netzliste mit dem Namen netlistenname konnte in der Projektdatei nicht gefunden werden. Da die Netzlisten anhand einer zu Beginn des Packager-Laufes durch Zugriff auf die Projektdatei gebildeten Liste geladen werden, deutet dies auf eine Änderung der Projektdatei während des Packager-Laufes hin (z.B. durch einen anderen Anwender im Netzwerk).
Zur Problembehebung kann versucht werden, das zu der logischen Netzliste gehörige gleichnamige Schaltplanblatt im Schaltplaneditor zu laden und erneut zu speichern. Dabei wird die logische Netzliste neu generiert. Sollte dies nicht zur Behebung des Problems führen empfiehlt es sich die Projektdatei zur näheren Untersuchung an den Bartels-Support zu senden.
In der Projekdatei projektdateiname wurden im Layout mit dem Namen layoutname Änderungen durchgeführt, die eine erforderlich machen. Diese wurde noch nicht durchgeführt. Bei Bestätigung der Abfrage werden die im Layout durchgeführten Netzlistenänderungen wie Bauteilumbenennungen, Alternativbauformwechsel und Pin/-Gate-Swaps verworfen. Die Bauteilplatzierungen und Leiterbahnverbindungen des Layouts passen dann eventuell nicht mehr zur erzeugten Netzliste.
Es ist im Allgemeinen zu empfehlen, zunächst in den Schaltplaneditor zu wechseln und dort die durchzuführen. Sie wird beim Modulwechsel automatisch vorgeschlagen, kann alternativ aber auch mit / von Hand durchgeführt werden.
Bei der automatischen Netznamensgenerierung über eine unter aktivierte Option wurde ein Netzname gebildet, der die Maximallänge von 40 Zeichen überschreitet.
Zur Problembehebung ist der Name des Layoutbauteils oder der Netznamensprefix entsprechend zu kürzen.
Bei der automatischen Netznamensgenerierung über eine unter aktivierte Option wurde aus Netznamensprefix, Layoutbauteilnamen und Layoutbauteilpinnanem ein Netzname gebildet, der im Schaltplan bereits explizit vergeben wurde. Durch Zusammenfassung der beiden Netze über den gemeinsamen Namen würden ungewollte Verbindungen und damit Kurzschlüsse entstehen.
Zur Problembehebung ist das Konfliktnetz im Schaltplan, das Layoutbauteil oder der Netznamensprefix umzubenennen.
Ein aufgerufener Menüpunkt konnte nicht gestartet werden. Dies deutet auf eine installierte Zwischenversion hin, in der neue Menüpunkte auf Vorrat definiert, aber noch nicht implementiert wurden. Die Funktion/Option wird in einer der nächsten Versionen verfügbar sein.
Diese Meldung signalisiert das Ende des Optimierungslaufes und listet die Anzahl der aus der Netzliste entfernten Bauteile. Beim Optimieren werden Bauteile aus der Netzliste entfernt, die über den Wert yes für das Attribut $optimize für die Optimierung freigegeben sind und bei denen sämtliche über das Attribut $pintype als out (output d.h. Ausgang) deklarierten Pins keine weiterführenden Verbindungen besitzen. Dies findet im Normalfall nur für über das architecture-Kommando in der logischen Definition synthetisierte Logikbausteine Anwendung.
Diese Meldung signalisiert den Start des Optimierungslaufes und listet die Anzahl der ursprünglich vorhandenen Netzlistenbauteile. Beim Optimieren werden Bauteile aus der Netzliste entfernt, die über den Wert yes für das Attribut $optimize für die Optimierung freigegeben sind und bei denen sämtliche über das Attribut $pintype als out (output d.h. Ausgang) deklarierten Pins keine weiterführenden Verbindungen besitzen. Dies findet im Normalfall nur für über das architecture-Kommando in der logischen Definition synthetisierte Logikbausteine Anwendung.
Dem Pin layoutbauteilpinname des Layoutbauteils layoutbauteilname wurden für das Attribut attributname die beiden unterschiedlichen Attributwerte wert1 und wert2 zugewiesen. Als Quelle für die unterschiedlichen Attributwerte des Layoutbauteilpins kommen ein newattr-Kommando in der logischen Definition des zugehörigen Symbols oder an den zugehörigen Symbolpin angehängte Tagpinsymbole mit Attributzuweisungen in Betracht. Dies ist nur eine Warnungsmeldung, der Packager setzt die Bearbeitung des Projektes fort und verwendet wert1 als Pinattributwert, der wert2 wird verworfen.
Zur Behebung des Problems sind die Attributzuweisungen der Tagpinsymbole bzw. der logischen Definitionen anzugleichen.
Dem Pin layoutbauteilpinname des Layoutbauteils layoutbauteilname wurden in der Variante mit der Nummer variantennummer für das Attribut attributname die beiden unterschiedlichen Attributwerte wert1 und wert2 zugewiesen. Als Quelle für die unterschiedlichen Attributwerte des Layoutbauteilpins kommen ein newattr-Kommando in der logischen Definition des zugehörigen Symbols oder an den zugehörigen Symbolpin angehängte Tagpinsymbole mit Attributzuweisungen in Betracht. Dies ist nur eine Warnungsmeldung, der Packager setzt die Bearbeitung des Projektes fort und verwendet wert1 als Pinattributwert, der wert2 wird für diese Variante verworfen.
Zur Behebung des Problems sind die Attributzuweisungen der Tagpinsymbole bzw. der logischen Definitionen für die betreffende Variante anzugleichen.
Der von einem newattr-Kommando in der logischen Definition des in der vorhergehenden Meldungszeile dokumentierten Symbols oder Netzlisteeinträge für das Pinattribut attributname referenzierte Layoutbauteilpin mit dem Namen layoutbauteilpinname ist auf dem über die logische Definition des Symbols oder das Symbolattribut $plname angeforderten Layoutbauteilmakro nicht vorhanden.
Bei unmittelbarem Wechsel in den Schaltplaneditor wird das Schaltplanblatt mit dem betreffenden Symbol geladen und ein an die Symbolposition durchgeführt.
Zur Problembehebung ist der Pin auf dem Layoutbauteilmakro zu platzieren oder der Pin- bzw. Gehäusename in der logische Definition bzw. dem $plname-Attribut des Symbols zu korrigieren.
Dem Pin mit dem Namen layoutbauteilpinname (der Layoutbauteilname ist in der vorhergehenden Meldungszeile dokumentiert) wird über das Pinattribut $pintype die nicht unterstützte Pinfunktion pinfunktionsspezifikation zugewiesen. Erlaubt sind nur die Pinfunktionen in (Input/Eingang), out (Output/Ausgang), bidi (bidirektional), anl (Analog) und sup (supply/Versorgung) wobei Gross-/Kleinschreibung keine Rolle spielt. Stammt die Zuweisung nicht aus einer logischen Definition sondern aus einen Tagpinsymbol, so wird statt des layoutbauteilpinname (und Layoutbauteilname in der vorhergehenden Meldungszeile) der Name des Tagsymbolpins und Tagsymbols angezeigt. (in den Standardbibliotheken des BAE kommt hierbei nur das Symbol tag_pin_pintype aus der Bibliothek route.ddb in Betracht).
Dies ist nur eine Warnungsmeldung, die nicht zum Abbruch des Packager-Laufes führt. Der Pin wird im weiteren Verlauf so behandelt, als ob er keine $pintype-Zuweisung besitzt.
Bei unmittelbarem Wechsel in den Schaltplaneditor wird das Schaltplanblatt mit dem zugehörigen Symbol geladen und ein an die Symbolposition durchgeführt.
Zur Problembehebung ist die $pintype-Zuweisung in der logischen Definition bzw. im referenzierenden Tagpinsymbol auf einen gültigen Wert aus obiger Liste zu bringen.
Dem Pin mit dem Namen layoutbauteilpinname (der Layoutbauteilname ist in der vorhergehenden Meldungszeile dokumentiert) wurden über das Pinattribut $pintype unterschiedliche Pinfunktionen zugewiesen. Dies ist nicht erlaubt. Die unterschiedlichen Zuweisungen können durch Tagpinsymbole (in den Standardbibliotheken des BAE das Symbol tag_pin_pintype aus der Bibliothek route.ddb) und newattr "$pintype"-Kommandos in der logischen Definition des Symboles vorgenommen worden sein.
Bei unmittelbarem Wechsel in den Schaltplaneditor wird das Schaltplanblatt mit dem Symbol, das den zugeordneten Pin enthält geladen und ein an die Symbolposition durchgeführt.
Zur Problembehebung sind die $pintype-Zuweisungen in der logischen Definition bzw. den referenzierenden Tagpinsymbolen auf einen einheitlichen Wert zu bringen, bzw. überzählige Tagpinsymbole zu entfernen.
Das in der vorhergehenden Meldungszeile aufgelistete Symbol referenziert über seine logische Definition oder eine 1:1-Zuordnung der Symbolpins zu Layoutbauteilpins einen Layoutbauteilpin mit dem Namen layoutbauteilpinname. Dieser wird bereits von einem anderen in das Layoutbauteil gepackten Symbol mit einer anderen logischen Definition referenziert. Die Mehrfachreferenzierung des Pins stammt vermutlich aus den unterschiedlichen logischen Definitionen einer mainpart/subpart-Kombination. Dabei ist zu bedenken, dass ein mainpart ohne Pins automatisch eine Komplettbelegung des Layoutbauteils mit Dummynetzen auslösst. Bei einem mainpart ohne Pins kommt es also unweigerlich zu dieser Fehlermeldung, sobald ein subpart mit Pins referenziert wird.
Bei unmittelbarem Wechsel in den Schaltplaneditor wird das Schaltplanblatt mit dem betreffenden Symbol geladen und ein an die Symbolposition durchgeführt.
Zur Problembehebung sind die Symbolpinzuordnungen für den Layoutbauteilpin in den logischen Definitionen zu korrigieren, bzw. das mainpart so zu definieren, dass es mindestens einen Pin mit Zuordnung besitzt.
Das in der vorhergehenden Meldungszeile aufgelistete Symbol referenziert über seine logische Definition oder eine 1:1-Zuordnung der Symbolpins zu Layoutbauteilpins einen Layoutbauteilpin mit dem Namen layoutbauteilpinname. Dieser wird bereits von einem anderen in das Layoutbauteil gepackten Symbol referenziert und ist dort an ein anderes Netz angeschlossen. Da beim Einspielen der logischen Definition für ein Symbol ein Konsistenzcheck für die verwendeten Pins durchgeführt wird stammt Mehrfachreferenzierung des Pins mit hoher Wahrscheinlichkeit aus den unterschiedlichen logischen Definitionen einer mainpart/subpart-Kombination.
Bei unmittelbarem Wechsel in den Schaltplaneditor wird das Schaltplanblatt mit dem betreffenden Symbol geladen und ein an die Symbolposition durchgeführt.
Zur Problembehebung sind die Symbolpinzuordnungen für den Layoutbauteilpin in den logischen Definitionen zu korrigieren.
Der Symbolbuspin mit dem Namen symbolbuspinname (der Symbolname ist in der vorhergehenden Meldungszeile dokumentiert) referenziert über ein xlat-Kommando in der logischen Definition des Symbols eine Busanzapfung mit dem Namen anzapfungsname. Bei der internen Netznamensbildung für das Netz der Anzapfung wurde die maximale Netznamenslänge von 40 Zeichen überschritten. Der interne Netznamen wird nach dem Schema busname.anzapfungsname gebildet.
Bei unmittelbarem Wechsel in den Schaltplaneditor wird das Schaltplanblatt mit dem den Buspin enthaltenden Symbol geladen und ein an die Symbolposition durchgeführt.
Zur Problembehebung ist der Busname im Schaltplan durch Umbenennen des Netzlabels entsprechend zu kürzen oder ein kürzerer Name für die Busanzapfung zu wählen.
Dem Symbolpin mit dem Namen symbolpinname (der Symbolname ist in der vorhergehenden Meldungszeile dokumentiert) wurde in der logischen Definition über ein netattr priority-Kommando ein Attributname oder fester Wert für die Bearbeitungspriorität des am symbolpinname angeschlossenen Netzes zugewiesen. Dieser feste Wert oder der Wert des angegegbenen Attributes ist negativ. Negative Prioritätswerte sind nicht erlaubt. In den Standardbibliotheken des BAE kommen nur die Symbole att_pr, tag_net_priority, tag_netpin_priority und tag_netarea_priority aus der Bibliothek route.ddb für diese Fehlermeldung in Betracht.
Bei unmittelbarem Wechsel in den Schaltplaneditor wird das Schaltplanblatt mit dem betreffenden Symbol geladen und ein an die Symbolposition durchgeführt.
Zur Problembehebung ist dem Symbol in der logischen Definition bzw. im Schaltplan ein positiver Wert größer gleich Null für die Bearbeitungspriorität des Netzes im Autorouter zuzuweisen.
Dem Symbolpin mit dem Namen symbolpinname (der Symbolname ist in der vorhergehenden Meldungszeile dokumentiert) wurde in der logischen Definition des Symbols über ein netattr-Kommando ein Attributname für ein Netzattribut zugeordnet, das Attribut wurde am betreffenden Symbol aber nicht gesetzt. In den Standardbibliotheken des BAE kommen nur Symbole aus der Bibliothekroute.ddb für diese Fehlermeldung in Betracht.
Bei unmittelbarem Wechsel in den Schaltplaneditor wird das Schaltplanblatt mit dem betreffenden Symbol geladen und ein an die Symbolposition durchgeführt.
Zur Problembehebung ist dem Symbol im Schaltplan ein Wert für das Netzattribut zuzuweisen (ansonsten wäre das Symbol überflüssig und könnte genausogut gelöscht werden).
Dem Symbolpin mit dem Namen symbolpinname (der Symbolname ist in der vorhergehenden Meldungszeile dokumentiert) ist in der logischen Netzliste des unter "Aktiver Planname" dokumentierten Schaltplanblattes eine Netznummer zugeordnet, zu der es in der Netzliste keine entsprechnung gibt. Da die Netznummern im BAE automatisch vergeben werden, deutet dies evtl. auf ein internes Problem hin.
Bei unmittelbarem Wechsel in den Schaltplaneditor wird das Schaltplanblatt mit dem betreffenden Symbol geladen und ein an die Symbolposition durchgeführt.
Zur Problembehebung kann versucht werden das betreffende Schaltplanblatt im Schaltplaneditor zu laden und erneut zu speichern. Dabei wird die logische Netzliste neu generiert. Sollte dies nicht zur Behebung des Problems führen empfiehlt es sich die Projektdatei zur näheren Untersuchung an den Bartels-Support zu senden.
Wurde die logische Netzliste mit Hilfe der Anwenderfunktionen conconv oder netconv aus einem Fremdsystem importiert, ist zu überprüfen, ob die ungültige Netznummerzuweisung nicht von entsprechenden Vorgaben in der Quellnetzliste herrührt.
In der Layoutnetzliste des Projektes sind Pin-/Gateswapinformationen für den Symbolpin mit dem Namen symbolpinname (der Symbolname ist in der vorhergehenden Meldungszeile dokumentiert) hinterlegt, der Symbolpin wurde in der logischen Netzliste des Schaltplanes aber nicht gefunden, d.h. er ist auf Schaltplansymbol nicht mehr vorhanden. Es ist nicht erlaubt, einmal im Layout geswappte Pins vom zugehörigen Schaltplansymbol zu entfernen (oder umzubenennen).
Bei unmittelbarem Wechsel in den Schaltplaneditor wird das Schaltplanblatt mit dem betreffenden Symbol geladen und ein an die Symbolposition durchgeführt.
Zur Problembehebung ist der Pin wieder auf dem Symbol zu platzieren. Es ist zu beachten, dass nach dem Platzieren/Löschen/Umbenennen von Symbolpins die Schaltpläne mit Platzierungen des bearbeiteten Symbols geladen und gespeichert werden müssen um die vom Packager bearbeiteten logischen Netzlisten auf den neuesten Stand zu bringen. Die Symbolmakros selbst werden vom Packager nicht gelesen. Beim einfachen Laden der Schaltpläne sieht man die neuen/geänderten Pinnamen zwar auf dem Bildschirm, in die logische Netzliste werden die Daten aber erst beim Speichern der Schaltplanblätter übertragen.
Ist es wirklich zwingend erforderlich einen Symbolpin nach dem Swap im Layout zu löschen/umzubenennen, muss ein neuer Symbolname/LAyoutbauteilname vergeben werden. Die Swapinformationen eines namentlich komplett aus der Netzliste entfernten Layoutbauteils werden verworfen. Mit / kann das alte Layoutbauteil an gleicher Position umbenannt werden. Die Swaps müssen von Hand nachgetragen werden.
Dem Symbolpin mit dem Namen symbolpinname (der Symbolname ist in der vorhergehenden Meldungszeile dokumentiert) wurde in der logischen Definition über ein netattr routwidth-Kommando ein Attributname oder fester Wert für die Standardleiterbahnbreite des am symbolpinname angeschlossenen Netzes zugewiesen. Dieser feste Wert oder der Wert des angegegbenen Attributes repräsentiert keine gültige Bahnbreite. Die Bahnbreite ist in Millimetern mit einem . als Dezimaltrennzeichen anzugeben und muss ein Wert größer als Null sein. Die Umwandlung der Zahl wird beim ersten ungültigen Zeichen beendet. Es ist also z.B. erlaubt zur Dokumentation ein mm an das Ende des Attributwertes zu setzen, führende Kommentare sind jedoch nicht erlaubt. In den Standardbibliotheken des BAE kommen nur die Symbole att_rw, tag_net_routwidth, tag_netpin_routwidth und tag_netarea_routwidth aus der Bibliothek route.ddb für diese Fehlermeldung in Betracht.
Bei unmittelbarem Wechsel in den Schaltplaneditor wird das Schaltplanblatt mit dem die ungültige Zuweisung vornehmenden Symbol geladen und ein an die Symbolposition durchgeführt.
Zur Problembehebung ist dem Symbol in der logischen Definition bzw. im Schaltplan ein gültiger Wert für die Standardleiterbahnbreite des Netzes zuzuweisen.
Dem Symbolpin mit dem Namen symbolpinname (der Symbolname ist in der vorhergehenden Meldungszeile dokumentiert) wurde in der logischen Definition über ein netattr powwidth-Kommando ein Attributname oder fester Wert für die Anschlussbreite von Versorgunspins an dem am symbolpinname angeschlossenen Netz zugewiesen. Dieser feste Wert oder der Wert des angegegbenen Attributes repräsentiert keine gültige Anschlussbreite. Die Anschlussbreite ist in Millimetern mit einem . als Dezimaltrennzeichen anzugeben und muss ein Wert größer als Null sein. Die Umwandlung der Zahl wird beim ersten ungültigen Zeichen beendet. Es ist also z.B. erlaubt zur Dokumentation ein mm an das Ende des Attributwertes zu setzen, führende Kommentare sind jedoch nicht erlaubt. In den Standardbibliotheken des BAE kommen nur die Symbole att_pw, tag_net_powwidth, tag_netpin_powwidth und tag_netarea_powwidth aus der Bibliothek route.ddb für diese Fehlermeldung in Betracht.
Bei unmittelbarem Wechsel in den Schaltplaneditor wird das Schaltplanblatt mit dem die ungültige Zuweisung vornehmenden Symbol geladen und ein an die Symbolposition durchgeführt.
Zur Problembehebung ist dem Symbol in der logischen Definition bzw. im Schaltplan ein gültiger Wert für die Versorgungsanschlussbreite des Netzes zuzuweisen.
Dem Symbolpin mit dem Namen symbolpinname (der Symbolname ist in der vorhergehenden Meldungszeile dokumentiert) wurde in der logischen Definition über ein netattr mindist-Kommando ein Attributname oder fester Wert für den Mindestabstand des am symbolpinname angeschlossenen Netzes zugewiesen. Dieser feste Wert oder der Wert des angegegbenen Attributes repräsentiert keinen gültigen Mindestabstand. Der Mindestabstand ist in Millimetern mit einem . als Dezimaltrennzeichen anzugeben und muss ein Wert größer als Null sein. Die Umwandlung der Zahl wird beim ersten ungültigen Zeichen beendet. Es ist also z.B. erlaubt zur Dokumentation ein mm an das Ende des Attributwertes zu setzen, führende Kommentare sind jedoch nicht erlaubt. In den Standardbibliotheken des BAE kommen nur die Symbole att_md, tag_net_mindist, tag_netpin_mindist und tag_netarea_mindist aus der Bibliothek route.ddb für diese Fehlermeldung in Betracht.
Bei unmittelbarem Wechsel in den Schaltplaneditor wird das Schaltplanblatt mit dem die ungültige Zuweisung vornehmenden Symbol geladen und ein an die Symbolposition durchgeführt.
Zur Problembehebung ist dem Symbol in der logischen Definition bzw. im Schaltplan ein gültiger Wert für den Mindestabstand des Netzes zuzuweisen.
Das in der vorhergehenden Meldungszeile aufgelistete Symbol ist über ein $vgrp-Attribut zusammen mit anderen Symbolen mit gleichem $vgrp-Attributwert in ein variantenabhängig belegtes Layoutbauteil eingebettet. Der Pin mit dem Namen symbolpinname ist bei diesem Symbol an ein anderes Netz angeschlossen, als die korrespondierenden Pins der anderen Symbole. Dies ist nicht erlaubt.
Bei unmittelbarem Wechsel in den Schaltplaneditor wird das Schaltplanblatt mit dem betreffenden Symbol geladen und ein an die Symbolposition durchgeführt.
Zur Problembehebung sind alle Symbole des Variantenbauteiles im Schaltplan parallel zu schalten.
Der im architecture-Kommando der logischen Definition des in der vorhergehenden Meldungszeile aufgeführten Symbols aufgelistete Laoyutbauteilpin mit dem Namen layoutbauteilpinname wurde nicht gefunden.
Abhängig vom eingestellten Modus für die ist dies eine Warnungs- oder eine Fehlermeldung. Im Falle einer Warnung setzt der Packager die Bearbeitung fort, als ob es den Pin auf dem Layoutbauteilmakro gäbe und man kann diesen nachträglich auf dem Layoutbauteilmakro platzieren um ein zur Netzliste passendes Layout zu erhalten.
Zur Behebung des Problems ist der Name des Pins im architecture-Kommando zu korrigieren oder der entsprechende Pin auf dem Layoutbauteil zu platzieren.
Diese Meldung könnte auch bei der Bearbeitung von Blocksymbolen für hierarchische Schaltplanblätter auftreten, deutet hier aber auf einen noch nicht bekannten Fehler im Packager hin, da Port-Pins von Blocksymbolen vor der Verwendung automatisch definiert sein sollten. Es kann versucht werden die Schaltplanblätter des Projektes im Schaltplaneditor zu laden und erneut zu speichern. Dabei werden die logischen Netzlisten neu generiert. Sollte dies nicht zur Behebung des Problems führen empfiehlt es sich die Projektdatei zur näheren Untersuchung an den Bartels-Support zu senden.
Diese Fehlermeldung wird ausgegeben, wenn in einem der Packager-Schritte die Schreibzugriffe auf die Projektdatei durchführen ein Fehler aufgetreten ist. Dies muss nicht notwendigerweise ein Schreibfehler gewesen sein der eine gestörte Datenbankstruktur hinterlassen hat (siehe vor dieser Meldung ausgegebene Fehlermeldungen). Es ist allerdings nicht davon auszugehen, dass eine korrekte Layoutnetzliste geschrieben wurde.
Zur Problembehebung siehe die vorangehenden Fehlermeldungen. Falls die Projektdatei tatsächlich unlesbar geworden ist, kann die -Option des Utilityprogrammes copyddb zur Restauration der Projektdatei verwendet werden. Sollte dies nicht zur Behebung des Problems führen, dann kann die Projektdatei zur näheren Untersuchung an den Bartels-Support gesandt werden.
In der logischen Definition des in der vorhergehenden Meldungszeile aufgelisteten Symbols ist in einem xlat-Kommando ein Layoutbauteilpin mit dem Namen layoutbauteilpinname aufgeführt. Dieser Pin ist auf dem über die logische Definition des Symbols oder das Symbolattribut $plname angeforderten Layoutbauteilmakro aber nicht vorhanden.
Abhängig vom eingestellten Modus für die ist dies eine Warnungs- oder eine Fehlermeldung. Im Falle einer Warnung setzt der Packager die Bearbeitung fort, als ob es den Pin auf dem Layoutbauteilmakro gäbe und man kann diesen nachträglich auf dem Layoutbauteilmakro platzieren um ein zur Netzliste passendes Layout zu erhalten. Im Falle eines Fehlers wird bei einem unmittelbarem Wechsel in den Schaltplaneditor das Schaltplanblatt mit dem Symbol, das das Layoutbauteil referenziert, geladen und ein an die Symbolposition durchgeführt.
Zur Problembehebung ist der Pin auf dem Layoutbauteilmakro zu platzieren oder der Pin- bzw. Gehäusename in der logische Definition bzw. dem $plname-Attribut des Symbols zu korrigieren.
Dem Symbol symbolname wurden in der logischen Definition über newattr-Kommandos mehrere unterschiedliche Werte für das Attribut attributname zugewiesen.
Zur Problembehebung sind die überzähligen newattr-Kommandos aus der logischen Definition für das Symbol zu entfernen.
Die für das Symbol mit dem Namen symbolname mit Hilfe von $rlname-bzw. $rlext-Attributeinträgen selektierte logische Definition besitzt eine andere Klasse als die zum Symbolmakronamen gehörige Definition.
Die Klasse wird in der logischen Definition über ein class-Kommando angegeben und dient dazu eine Konsistenzprüfung der über $rlname-und $rlext-Attribute selektierten Definitionen durchzuführen, so dass die versehentliche Zuweisung einer nicht zum Symbolmakro passenden logischen Definition vermieden wird.
Bei unmittelbarem Wechsel in den Schaltplaneditor wird das Schaltplanblatt mit dem Symbol, das die ungültige Zuweisung vornimmt geladen und ein an die Symbolposition durchgeführt.
Es wurde versucht für das Symbol mit dem Namen symbolname mit Hilfe von $rlname-bzw. $rlext-Attributeinträgen eine alternative logische Definition zu selektieren. In der zum Symbolmakronamen gehörigen Definition ist aber kein class-Kommando angegeben.
Mit dem class-Kommando wird die Klasse einer logischen Definition angegeben, die dazu dient eine Konsistenzprüfung der über $rlname-und $rlext-Attribute selektierten Definitionen durchzuführen, so dass die versehentliche Zuweisung einer nicht zum Symbolmakro passenden logischen Definition vermieden wird. Das class-Kommando ist demnach für Symbolmakros die alternative logische Definitionen besitzen obligatorisch.
Bei unmittelbarem Wechsel in den Schaltplaneditor wird das Schaltplanblatt mit dem Symbol, das die ungültige Zuweisung vornimmt geladen und ein an die Symbolposition durchgeführt.
Die für das Symbol mit dem Namen symbolname mit Hilfe von $rlname-bzw. $rlext-Attributeinträgen selektierte alternative logische Definition besitzt eine unterschiedliche mainpart/subpart-Zuordnung als die zum Symbolmakronamen gehörige Definition. Die mainpart/subpart-Zuordnung muss für alle zu einem Symbolmakronamen gehörigen logischen Definitionen einheitlich erfolgen (Ausnahme sind logische Definitionen mit der Spezialklasse universal in denen unter Umgehung von Konsistenzchecks alles erlaubt ist).
Bei unmittelbarem Wechsel in den Schaltplaneditor wird das Schaltplanblatt mit dem Symbol, das die unterschiedliche Zuweisung vornimmt geladen und ein an die Symbolposition durchgeführt.
Es wurde versucht über ein $rpname-, $spname-oder $vgrp-Attribut für das Symbol mit dem Namen symbolname einen Layoutbauteilnamen vorzugeben, der für Bauteilnamen nicht zulässige Zeichen enthält. Unzulässige Zeichen sind ?, *, sowie nicht druckbare Zeichencodes. Gross-/Kleinschreibung spielt keine Rolle, die Namen werden automatisch in Kleinschreibung umgewandelt. Leerzeichen werden ausgefiltert und gelten somit nicht als ungültige Zeichen. Es wird dabei nur der erste nicht aus Leerzeichen bestehende Teilstring als Namen verwendet.
Bei unmittelbarem Wechsel in den Schaltplaneditor wird das Schaltplanblatt mit dem betreffenden Symbol geladen und ein an die Symbolposition durchgeführt.
Es wurde versucht, dem Symbol mit dem Namen symbolname über ein $rlname-Attribut eine alternative logische Definition zuzuweisen, deren Namen nicht zulässige Zeichen enthält. Unzulässige Zeichen sind ? und *, sowie nicht druckbare Zeichencodes. Gross-/Kleinschreibung spielt keine Rolle, die Namen werden automatisch in Kleinschreibung umgewandelt. Leerzeichen werden ausgefiltert und gelten somit nicht als ungültige Zeichen. Es wird dabei nur der erste nicht aus Leerzeichen bestehende Teilstring als Namen verwendet.
Bei unmittelbarem Wechsel in den Schaltplaneditor wird das Schaltplanblatt mit dem betreffenden Symbol geladen und ein an die Symbolposition durchgeführt.
Es wurde versucht dem Symbol mit dem Namen symbolname über ein $plname-Attribut eine alternatives Layoutgehäuse zuzuweisen, dessen Namen nicht zulässige Zeichen enthält. Unzulässige Zeichen sind ? und *, sowie nicht druckbare Zeichencodes. Gross-/Kleinschreibung spielt keine Rolle, die Namen werden automatisch in Kleinschreibung umgewandelt. Leerzeichen werden ausgefiltert und gelten somit nicht als ungültige Zeichen. Es wird dabei nur der erste nicht aus Leerzeichen bestehende Teilstring als Namen verwendet.
Bei unmittelbarem Wechsel in den Schaltplaneditor wird das Schaltplanblatt mit dem betreffenden Symbol geladen und ein an die Symbolposition durchgeführt.
Das Symbol mit dem Namen symbolname kommt in mehreren logischen Netzlisten des Projektes vor, d.h. es ist auf mehreren Schaltplänen platziert. Vermutlich wurde ein Schaltplan mit in dem Projekt gespeichert oder mit Hilfe des Utilityprogrammes copyddb in das Projekt kopiert. Dabei können Namenskonflikte zwischen den Symbolen des gespeicherten/kopierten Schaltplanblattes und den Symbolen bereits in der Zieldatei vorhandener Schaltplanblätter entstehen. Zur Übernahme von Schaltplanblättern aus einer anderen Datei oder zur Kopie von Schaltplanblättern innerhalb einer Projektdatei sollte nur die Funktion (in ein leeres neues Schaltplanblatt) verwendet werden, die bei Namenskonflikten eine automatische Umbenennung der Symbole entsprechend dem durchführt. Beim kann auch ein normales Schaltplanblatt als Quelle selektiert werden, es ist nicht notwendig den zu kopierenden Schaltplan als Gruppe abzuspeichern. Neben kann auch in die Projektdatei zu solchen Namenskonflikten führen, wenn die gespeicherte Gruppe wie ein normaler Schaltplan geladen und wieder gespeichert wird. Schaltplangruppen sollten nicht in der Projektdatei, sondern in temporären anders benannten Dateien abgelegt werden.
Bei unmittelbarem Wechsel in den Schaltplaneditor wird ein Schaltplanblatt mit einem der betreffenden Symbole geladen und ein an die Symbolposition durchgeführt.
Zur Problembehebung ist eines der beiden Konfliktsymbole umzubenennen. Es ist zu beachten, dass für die Bauteilattribute für die Symbole in der Projektdatei separat von den Schaltplänen unter dem Symbolnamen gespeichert werden. Dieser Eintrag enthält nach dem Zusammenkopieren mit Namenskonflikt nur die Attribute eines der beiden ursprünglichen Symbole. Beim Umbenennen sind daher auch die Attributwerte der beiden Konfliktsymbole zu überprüfen und verlorengegangene/falsche Attribute ggf. neu zu setzen.
Als Sonderfall kann diese Meldung auch bei der automatischen Generierung von Testpunkten in der Layoutnetzliste auftreten. Die Namen der Testpunktbauteile werden aus dem mit angehängtem Netznamen gebildet. Für unbenannte Netze wird statt des Netznamens der Name bauteilname.pinname des ersten Netzpins verwendet. Der so gebildete Testpunktbauteilname wird auf 40 Zeichen beschränkt. Bei entsprechend langen und ähnlichen Netz- bzw. Bauteilnamen die sich nur am Namensende unterscheiden kann es durch die Namensbeschränkung auf 40 Zeichen zu Namenskonflikten bei den automatisch generierten Testpunktbauteilnamen kommen.
Das Symbol mit dem Namen symbolname konnte nicht erfolgreich in ein Layoutbauteil gepackt werden. Diese Meldung dokumentiert das Ende des gescheiterten Zuordnungsvorganges. Die genauen Gründe des Scheiterns sind in vorhergehenden Meldungen dokumentiert.
Bei unmittelbarem Wechsel in den Schaltplaneditor wird das Schaltplanblatt mit dem betreffenden Symbol geladen und ein an die Symbolposition durchgeführt.
Das Symbol mit dem Namen symbolname wird in der logischen Netzliste von einem Netzpin referenziert, wurde aber vorher nicht definiert. Da der Schaltplaneditor beim normalen Speichern die Symbollisten immer passend zu den Pinreferenzen generieren sollte, deutet dies auf einen Fehler auf dem Datenträger oder ein bisher unbekanntes Problem im Schaltplaneditor oder Packager hin.
Zur Problembehebung kann versucht werden die Schaltplanblätter des Projektes im Schaltplaneditor zu laden und erneut zu speichern. Dabei werden die logischen Netzlisten neu generiert. Sollte dies nicht zur Behebung des Problems führen empfiehlt es sich die Projektdatei zur näheren Untersuchung an den Bartels-Support zu senden.
Über das Attribut $rlext wurde eine definitionsextension für das Symbolmakro des Symboles symbolname spezifiziert, die zusammen mit dem Symbolmakronamen und dem Unterstrich die maximale Definitionsnamenslänge von 40 Zeichen überschreitet.
Dies ist nur eine Warnungsmeldung, die nicht zum Abbruch des Packager-Laufes führt. Für die weitere Bearbeitung wird der Wert des $rlext-Attributes ignoriert und der ursprüngliche logische Definitionsname verwendet.
Zur Behebung des Problemes ist ein kürzerer Wert für das Attribut $rlext und damit den Namen der logischen Definition zu verwenden oder zum Attribut $rlname zu wechseln, bei dem der Symbolmakronamen nicht zur Namensbildung herangezogen wird.
Die für den Pin symbolpinname des Schaltplansymbols mit dem Namen symbolname definierte Pinfunktion erzeugt im angeschlossenen Netz einen Konflikt bzw. Fehler, der in den vorhergehenden Meldungszeilen genauer spezifiziert ist.
Auf dem Schaltplanblatt mit dem Namen schaltplanblattname sind Symbole mit dem Makro symbolmakroname platziert, deren Makrodefinition in der Projektdatei nach dem Speichern des Schaltplanblattes geändert wurden. Die dabei evtl. vorgenommenen Änderungen an Pinnamen, Pinplatzierungen oder am Symboltagmodus werden vom Packager nicht berücksichtigt, da dieser nur die beim Speichern der Schaltplanblätter erzeugten logischen Netzlisten auswertet.
Zur Behebung des potentiellen Problems ist das betreffende Schaltplanblatt erneut zu speichern. Sind mehrere Schaltplanblätter betroffen kann im Schaltplaneditor die Funktion / / / verwendet werden, die vollautomatisch alle Schaltplanblätter eines Projektes lädt und speichert und somit die vom Packager gelesenen logischen Netzlisten auf den neuesten Stand bringt.
Dem Symbolpin mit dem Namen symbolpinname (der Symbolname ist in der vorhergehenden Meldungszeile dokumentiert) ist in der logischen Netzliste des unter "Aktiver Planname" dokumentierten Schaltplanblattes ein Pinattribut attributname zugewiesen, der Symbolpin konnte aber auf dem Symbol nicht gefunden werden. Da normalerweise nur auf dem Symbolpin vorhandene Pins mit Attributen belegt sein können, deutet dies auf einen Fehler auf dem Datenträger oder ein bisher unbekanntes Problem im Schaltplaneditor oder Packager hin.
Bei unmittelbarem Wechsel in den Schaltplaneditor wird das Schaltplanblatt mit dem betreffenden Symbol geladen und ein an die Symbolposition durchgeführt.
Zur Problembehebung kann versucht werden das betreffende Schaltplanblatt im Schaltplaneditor zu laden und erneut zu speichern. Dabei wird die logische Netzliste neu generiert. Sollte dies nicht zur Behebung des Problems führen empfiehlt es sich die Projektdatei zur näheren Untersuchung an den Bartels-Support zu senden.
Wurde die logische Netzliste mit Hilfe der Anwenderfunktionen conconv oder netconv aus einem Fremdsystem importiert, ist zu überprüfen, ob die ungültige Pinattributzuweisung nicht von entsprechenden Vorgaben in der Quellnetzliste herrührt.
Bei der Layoutbauteilnamensbildung für ein synthetisches aus dem architecture-Kommando der logischen Definition des Symbols symbolname stammendes Bauteil wurde die maximale Namenslänge von 40 Zeichen überschritten. Zur Bildung des Layoutbauteilnamens wird das Namensmuster [asymbolname_bauteilnummer] verwendet. Je nach Anzahl von synthetischen Bauteilen für das Symbol und der damit verbundenen Länge der bauteilnummer muss man sich daher bei Symbolen mit architecture-Kommando auf eine Namenslänge von 33 bis 35 Zeichen beschränken.
Zur Problembehebung ist der betreffende Symbolname im Schaltplan durch Umbenennen des Symbols zu kürzen.
Diese Meldung dokumentiert den Namen der bei der automatischen Generierung von Netztestpunktbauteilen verwendeten logischen Definition. In dieser logischen Definition können Attribute und das oder die Layoutbauteilmakro(s) für die Testpunktbauteile definiert werden. Das Netz wird an den ersten Pin der logischen Definition/des Layoutbauteils angeschlossen (in der Regel gibt es bei Testpunktbauteilen ohnehin nur einen einzigen Pin).
Diese Meldung dokumentiert den bei der automatischen Generierung von Netztestpunktbauteilen verwendeten Bearbeitungsmodus für Netze mit nur einem Bauteilanschluss. Im Modus wird für jedes Netz der Netzliste ein Testpunktbauteil generiert, im Modus hingegen werden nur Netze mit einem Testpunktbauteil versehen, die mindestens 2 Bauteilanschlüsse besitzen. Es is zu beachten, dass einzelne Netze auch explizit über das Netzattribut $notest von der Testpunktgenerierung ausgeschlossen werden können (zu Setzen z.B. über die Symbole att_testdisable, tag_net_testdisable, tag_netpin_testdisable und tag_netarea_testdisable aus der Bibliothek route.ddb).
Diese Meldung dokumentiert den bei der automatischen Generierung von Testpunkten zur Bildung des Testpunktbauteilnamens dem Netznamen vorangestellten Namensprefix. Wird dieser Prefixparameter auf einen Leerstring gesetzt, so erhalten die Testpunktbauteile den Netznamen. Für unbenannte Netze wird statt des Netznamens der Name bauteilname.pinname des ersten Netzpins verwendet. Ein Namensprefix bietet den Vorteil, dass die Testpunktbauteile in den alphabetisch sortierten Bauteilnamensselektionsboxen des Layouteditors einen Block bilden und somit einfach von den anderen Bauteilen unterschieden werden können. Ein einmal eingestellter Testpunktnamensprefix wird in der Projektdatei gespeichert und muss bei folgenden Packager-Läufen nicht erneut angegeben werden.
An das Netz mit dem Namen netzname sind entweder mehrere Pins angeschlossen, die über das Attribut $pintype als vom Typ out (d.h. Ausgänge) deklariert sind oder ein Pin vom Typ out und ein oder mehrere Pins der Typen bidi (bidirektional) oder sup (supply, d.h. Versorgungsspannung). In dieser Konstellation können unterschiedliche Potentiale direkt kurzgeschlossen werden. Dadurch ist der Zustand des Netzes undefiniert und die Funktionsfähigkeit der Schaltung ist zweifelhaft. Die Pins des Netzes und ihre Funktionen werden in folgenden Meldungszeilen aufgelistet.
Zur Problembehebung sind Ausgänge vom direkten Anschluss an das Netz zu trennen oder anders zu deklarieren, falls sie nicht ständig treibend sind.
In der logischen Definition des in der vorhergehenden Meldungszeile aufgelisteten Symbols sind widersprüchliche swap-Kommandos für den Layoutbauteilpin mit dem Namen layoutbauteilpinname enthalten. Da beim Einspielen der logischen Definition für ein Symbol ein Konsistenzcheck für die swap-Kommandos durchgeführt wird, stammen die widersprüchlichen swap-Kommandos evtl. aus den unterschiedlichen Definitionen einer mainpart/subpart-Kombination oder aus einer sehr alten BAE-Version ohne Konsistenzcheck.
Bei unmittelbarem Wechsel in den Schaltplaneditor wird das Schaltplanblatt mit dem betreffenden Symbol geladen und ein an die Symbolposition durchgeführt.
Zur Problembehebung sind die swap-Kommandos für den Layoutbauteilpin in der/den logischen Definition(en) zu korrigieren.
Diese Fehlermeldung erscheint an der Konsole, bzw. in einem Terminalfenster, wenn in der DOS bzw. in einer der UNIX/Linux-Versionen versucht wird, den Packager (logpack.exe bzw. logpack) direkt und nicht aus der BAE-Benutzeroberfläche heraus aufzurufen. Ein direkter Aufruf ist nicht erlaubt, da der Wechsel in andere BAE-Programmmodule nicht funktionieren würde und dem Packager die Pfade zu den Setup-Dateien/Bibliotheken nicht bekannt wären.
Die von dem Symbol mit dem Namen symbolname referenzierte logische Definition enthält Optionen, die vom Packager nicht verstanden werden. Dies kann von einem Fehler auf dem Datenträger oder der Verwendung einer neueren BAE-(Zwischen)Version beim Einspielen der logischen Definitionen herrühren.
Bei unmittelbarem Wechsel in den Schaltplaneditor wird das Schaltplanblatt mit dem betreffenden Symbol geladen und ein an die Symbolposition durchgeführt.
Zur Problembehebung kann versucht werden die logische Definition erneut in das Projekt bzw. die verwendete Bibliothek einzuspielen bzw. neu zu editieren. Sollte dies nicht zur Behebung des Problems führen empfiehlt es sich die Projektdatei zur näheren Untersuchung an den Bartels-Support zu senden.
Die logischen Netzlisten der Projektdatei enthalten Optionen, die vom Packager nicht verstanden werden. Dies kann von einem Fehler auf dem Datenträger oder der Verwendung einer neueren BAE-(Zwischen)Version beim Speichern der Schaltpläne herrühren.
Zur Problembehebung kann versucht werden die Schaltplanblätter des Projektes im Schaltplaneditor zu laden und erneut zu speichern. Dabei werden die logischen Netzlisten neu generiert. Sollte dies nicht zur Behebung des Problems führen empfiehlt es sich die Projektdatei zur näheren Untersuchung an den Bartels-Support zu senden.
Das angegebene Symbol mit dem Namen symbolname ist mit anderen Untersymbolen zusammen in das in der vorhergehenden Meldungszeile gelistete Layoutbauteil gepackt worden und hat das $noplc-Attribut auf einen Leerstring gesetzt, während an den anderen Untersymbolen das $noplc-Attribut gesetzt ist. Der Packager gibt hierbei der Platzierungsanforderung Vorrang, wodurch die anderen als unplatziert markierten Untersymbole mitplatziert werden. Es bleibt dem Benutzer überlassen zu entscheiden, ob dies die Funktion der Schaltung beeinträchtigt.
Zur Problembehebung ist das $noplc-Attribut in den Untersymbolen ggf. auf einheitliche Werte zu setzen.
Das angegebene Symbol mit dem Namen symbolname ist mit anderen Untersymbolen zusammen in das in der vorhergehenden Meldungszeile gelistete Layoutbauteil gepackt worden und hat das $noplc-Attribut gesetzt, während an den anderen Untersymbolen das $noplc-Attribut auf einen Leerstring gesetzt ist. Der Packager gibt hierbei der Platzierungsanforderung Vorrang, wodurch das gelistete Untersymbol mitplatziert wird. Es bleibt dem Benutzer überlassen zu entscheiden, ob dies die Funktion der Schaltung beeinträchtigt.
Zur Problembehebung ist das $noplc-Attribut in den Untersymbolen ggf. auf einheitliche Werte zu setzen.
Das Symbol mit dem Namen symbolname wurde über den Wert des $vgrp-Attributes in das variantenabhängig belegtes Layoutbauteil mit dem Namen layoutbauteilname eingebettet. Der ursprüngliche symbolname wird nun seinerseits von den in der folgenden Liste aufgeführten Schaltplansymbolen über das $rpname-Attribut als Layoutbauteilname angefordert (für ein vom Variantenbauteil verschiedenes Layoutbauteil). Dies kann zu Inkonsistenzen in der Attributverwaltung führen und ist daher nicht erlaubt.
Zur Problembehebung ist das Symbol mit dem Namen symbolname umzubenennen oder für die gelisteten Konfliktsymbole im $rpname-Attribut ein anderer Layoutbauteilname vorzugeben. Es ist zu empfehlen Symbole die über das Attribut $vgrp zur die Verwendung in variantenabhängigen Layoutbauteilen vorgesehen sind mit einem "exotischen" zu versehen, das nicht mit gängigen Layoutbauteilnamen kollidiert. Für diese Symbole spielt der Symbolname ohnehin eine untergeordnete Rolle, da der spätere Layoutbauteilname durch das $vgrp-Attribut festgelegt wird.
Das Symbol mit dem Namen symbolname wurde über ein $vgrp-Attribut in ein variantenabhängig belegtes Layoutbauteil eingebettet und durch ein auf einen Leerstring gesetztes $noplc-Attribut als variantenabhängig bestückt markiert. Dies ist für Mehrfachgatter (d.h. Symbole, die in der logischen Definition über das xlat-Kommando in mehreren Instanzen in ein Layoutbauteil gepackt werden) nicht erlaubt.
Bei unmittelbarem Wechsel in den Schaltplaneditor wird das Schaltplanblatt mit dem betreffenden Symbol geladen und ein an die Symbolposition durchgeführt.
Das in seiner logischen Definition als virtual deklarierte Symbol mit dem Namen symbolname wurde über ein $vgrp-Attribut in ein variantenabhängig belegtes Layoutbauteil eingebettet und durch ein auf einen Leerstring gesetztes $noplc-Attribut als bestückt markiert. Da ein virtual-Symbol nicht in die Layoutnetzliste übertragen wird, ist die Verwendung von $vgrp-/ $noplc-Attributen hier nicht sinnvoll.
Bei unmittelbarem Wechsel in den Schaltplaneditor wird das Schaltplanblatt mit dem betreffenden Symbol geladen und ein an die Symbolposition durchgeführt.
Zur Behebung des Problems sind die virtual-Deklaration aus der logischen Netzliste zu entfernen oder die Werte der $vgrp/$noplc-Attribute zurückzusetzen und ggf. DANACH die $vgrp-/ $noplc-Texte vom Symbol zu entfernen um weitere Fehlzuweisungen zu verhindern.
Einem Netz wurden über Netznamensattribute $netname die beiden unterschiedlichen Netznamen netzname1 und netzname2 zugewiesen.
Zur Problembehebung ist eine der Netznamenszuweisungen zurückzunehmen.
Das zum selektierten Netzlistennamen gehörige Layout layoutname ist gerade vom Benutzer benutzername in den Layouteditor geladen. Da hierbei die (alte) Netzliste mitgeladen ist, gefährdet diese Situation die Datenkonsistenz nach dem Packager-Lauf, da beim Speichern des Layouts die alte Netzliste mitgespeichert wird und damit ggf. die durch den aktuellen Packager-Lauf erzeugte Netzliste wieder überschreibt. Zur Vermeidung dieser Situation ist den weiteren Anweisungen der Warnungsmeldung zu folgen und zunächst das Layout zu speichern um dieses dann nach dem Packager-Lauf mit der neu erzeugten Netzliste wieder zu laden.
Die Information zum aktuellen Bearbeiter des Layouts wird aus der zum Projekt gehörigen .lck-Datei abgeleitet. Sollte diese von unkontrolliert beendeten früheren Sitzungen stehen geblieben sein und zu unnötigen Warnungen über nicht mehr aktive Bearbeiter führen, kann die .lck-Datei problemlos gelöscht werden, sie enthält keine Designdaten.
Es konnte nicht genügend Hauptspeicher für die Bearbeitung der Projektdaten allokiert werden. Diese Fehlermeldung sollte bei der Speicherausstattung heutiger Rechner nicht mehr erscheinen. Zumindest nicht, wenn der Rechner nicht durch parallel ablaufende speicherfressende Programme ausgelastet ist.
Dem in der Folgezeile dokumentierten Symbol wurde über das $gp-Attribut ein Layoutbauteilpinname zugeordnet, der in der logischen Definition in keinem der über das xlat-Kommando definierten Gatter als erster Pin aufgeführt ist.
Bei unmittelbarem Wechsel in den Schaltplaneditor wird das Schaltplanblatt mit dem betreffenden Symbol geladen und ein an die Symbolposition durchgeführt.
Zur Problembehebung ist das $gp-Attribut auf einen in der logischen Definition als ersten Gatterpin aufgeführten Layoutbauteilpinnamen zu setzen oder die logische Definition zu korrigieren.
Der Symbolpin mit dem Namen symbolpinname (der Symbolname ist in der vorhergehenden Meldungszeile dokumentiert) wurde in der logischen Definition über ein netattr-Kommando als Zielpin für ein Netzattributname angegeben, wurde auf dem Symbol aber nicht gefunden.
Bei unmittelbarem Wechsel in den Schaltplaneditor wird das Schaltplanblatt mit dem betreffenden Symbol geladen und ein an die Symbolposition durchgeführt.
Zur Problembehebung ist der Pin auf dem Symbol zu platzieren bzw. in der logischen Definition zu korrigieren. Es ist zu beachten, dass nach dem Platzieren/Löschen/Umbenennen von Symbolpins die Schaltpläne mit Platzierungen des bearbeiteten Symbols geladen und gespeichert werden müssen um die vom Packager bearbeiteten logischen Netzlisten auf den neuesten Stand zu bringen. Die Symbolmakros selbst werden vom Packager nicht gelesen. Beim einfachen Laden der Schaltpläne sieht man die neuen/geänderten Pinnamen zwar auf dem Bildschirm, in die logische Netzliste werden die Daten aber erst beim Speichern der Schaltplanblätter übertragen.
Die von dem in der vorhergehenden Meldungszeile aufgelisteten Symbol angeforderte logische Definition enthält in einem xlat-Kommando eine Zuordnung zu einem Layoutbauteilpin mit dem Namen layoutbauteilpinname der auf dem verwendeten Layoutbauteilmakro nicht gefunden werden konnte.
Abhängig vom eingestellten Modus für die ist dies eine Warnungs- oder eine Fehlermeldung. Im Falle einer Warnung setzt der Packager die Bearbeitung fort, als ob es den Pin auf dem Layoutbauteilmakro gäbe und man kann diesen nachträglich auf dem Layoutbauteilmakro platzieren um ein zur Netzliste passendes Layout zu erhalten. Im Falle eines Fehlers wird bei einem unmittelbarem Wechsel in den Schaltplaneditor das Schaltplanblatt mit dem Symbol, das das Layoutbauteil referenziert, geladen und ein an die Symbolposition durchgeführt.
Zur Problembehebung ist der fehlende Pin auf dem Layoutbauteilmakro zu platzieren oder im xlat-Kommando der logischen Definition durch einen auf dem Layoutbauteilmakro vorhandenen Pin zu ersetzen.
| Bartels :: Bartels AutoEngineer :: BAE Dokumentation :: BAE Benutzerhandbuch :: Packager :: Packager |
Packager
© 1985-2025 Oliver Bartels F+E