Sie sind auf Seite 1von 14

Der VMEbus

Allgemeines
VME steht für VERSAmodule Eurocard, der Begriff wurde von der Entwicklergruppe
geprägt. Diese bestand aus Mitarbeitern von Motorola, Mostek und Signetics, die sich zur
Entwicklung des Standards zusammenschlossen.
Da der Begriff ‚VME’ offiziell nie definiert wurde, sind auch andere Definitionen wie
VERSAbus-E, VERSAmodule Europe und VERSAmodule European weit verbreitet.
Da der VMEbus jedoch auf eine Kombination aus dem VERSAbus-Standard und dem
Eurocard Formfaktor zurückgeht scheint der Begriff ‚Eurocard’ am besten zu passen.

Der VERSAbus, der zuerst von Motorola 1979 für seine 68000 Mikropozessoren
entwickelt wurde, wird mittlerweile kaum noch genutzt.
Viele Bussysteme zeigten bereits 1980 ihr Alter. Sie arbeiteten zwar gut mit den ein bis
zwei Prozessortypen für die sie designed wurden, hatten aber meistens einen kleinen
Adressraum und waren langsam.
Die Entwickler des VMEbus hatten die Absicht einen Bus zu entwickeln der unabhängig
vom Mikroprozessor und leicht upzugraden (32 Bit) ist. Es sollten außerdem möglichst
viele Drittanbieter zur Entwicklung von VMEbus-Produkten animiert werden, dafür
verzichtete man auf proprietäre Rechten am Bus. Es mussten also keine Lizenzgebühren
bezahlt werden.
Als der VMEbus entwickelt wurde war das Eurocard-Format bereits seit einigen Jahren
in Europa verbreitet, dadurch waren bereits viele Bauteile am Markt vorhanden.

Die erste Version des Standards erschien 1981 (Revision A).


Seit damals wurde der Standard etliche Male weiterentwickelt und verbessert

• Revision B, C, C.1
• IEC 821, 60302-2, 61076-4-113
• IEEE 1014-1987, 1101.1-1998, 1101.11-1998
• ANSI/VITA 1-1994, 1.1-1997
• und viele mehr... (insgesamt ca. 25)

Durch die konsequenten Pflege dieser anerkannten Standards, und sein offenes Design
konnte der VMEbus sich schnell verbreiten und vorallem durch seine vollständige
Rückwärtskompatiblität bis heute halten.
Es gibt Hunderte Hersteller, Tausende von Produkten und die Anzahl wächst noch
immer. Etliche System in Industrie, Militär, Telekommunikation, Flugverkehr und sogar
Raumfahrt basieren auf dem VMEbus.
Viele der Hersteller sind in der Organisation VITA (VMEbus International Trade
Association), einer Non-Profit Organisation zur Unterstützung des VMEbus und offener
Technologiestandards.

Warum wurde der VMEbus entwickelt?


Um 1975 wurde der Computermarkt von ein paar wenigen Großfirmen beherrscht,
darunter Control Data, Cray Research, Data General, Digital Equipment, IBM und
Sperry-Univac. Die Computer waren sehr groß und sperrig, man nannte sie Mainframes
und Minicomputers.
Ende der 1970er Jahre erscheinen die ersten Personal Computer. Diese wurden von
kleinen, verhältnismäßig günstigen Mikroprozessoren angetrieben. Diese Computer
wurde extrem populär und wurden bald auch in industriellem Umfeld eingesetzt.
Allerdings hatten Sie zwei entscheidende Nachteile, sie waren nicht Langlebig genug und
Erweiterungen waren umständlich. Beides waren entscheidende Probleme für die
‚Embedded Control Systems’ dieser Zeit.
Die Entwicklung des VMEbus kombinierte die auf Mikroprozessoren basierende
VERSAbus Technologie und die modularen ‚Eurocards’. Diese Systeme waren bereits
bewährt und serienmäßig produziert.
Diese Kombination löste das Problem der Langlebigkeit und Skalarität durch
austauschbare Module.
Der VMEbus löste auch einige schwierige Marktprobleme, indem einen gemeinsamen
Standard schaffte und so den Wettbewerb ankurbelte. Was in niedrigeren Preisen aber
auch höheren Verkaufszahlen endete.
Der VMEbus beeinflusste den Markt also positiv für Hersteller und Endverbraucher.

Aktuelle VMEbus Eigenschaften


Eine kleine Auswahl an Eigenschaften der aktuellen VMEbus Architektur
• Master/Slave Architektur, mehrere Master sind möglich
• Asynchrone Übertragung, d.h. kein zentraler Taktgeber
• Optionales Multiplexing
• 16 bis 64-Bit dynamische Adressierungsbreite
• 8 bis 64 Bit dynamische Datenbreite
• Fehlererkennung durch BERR* Signal
• 0-500+ MB/s Datentransferrate
• 7-Level Interrupt-Protokoll
• 1-21 Prozessoren
• Systemdiagnose durch SYSFAIL* Signal und VME64x Test & Maintenance Bus
• Live Insertion, d.h. Stecken von Karten während des Betriebs
• Plug & Play (Control & Status Register) unter VME64 und VME64x
• Formfaktoren:
o 3U single-height 160x100 mm
o 6U double-height 160x233 mm
o 9U (optionaler Standard) 367x400 mm
• Benutzerdefinierter I/O am Front-Panel und P2 (User Defined Pins)
• Konvektionsgekühlte (Mil.) Version unter IEEE 1101.2
• Bis zu 21 Card Slots in einer Backplane

Eigenschaften
Der VMEbus ist ein Backplanebus (Rückwandbus) und besitzt keine eigenen
elektronischen Bauteile. Die Karten werden auf den Bus gesteckt.
Als typischer Multiprozessorbus muss der VME Bus kontinuierlich prioritätengerecht die
Aufgaben an die unterschiedlichen Prozessorkarten verteilen.
Dieses erfolgt durch die bekannten Daisy Chain-Leitungen.
Info: Daisy Chain (English), wörtlich „Gänseblümchenkette“, bezeichnet in Serie
miteinander verbundene Hardware.
Deshalb müssen alle unbeschalteten Eingänge gebrückt werden, es sei denn es folgen
keine weiteren Karten. Es sind fünf parallele Daisy-Chains im Standard definiert.
Überbrückt werden kann ein freier Slot durch
• Dummykarten
• Jumper (fünf) an den entsprechenden Stellen der Backplane
• zusätzliche IC’s auf der BusPlatine (automatisches Daisy-Chaining)
• har-bus® 64 Steckverbinder mit Schaltfunktion

Master kontrollieren den Datenfluss von und zu Slaves. Da mehrere Master auf dem Bus
vorhanden sein können wird der VMEbus „Multiprocessing Bus“ genannt. Bevor jedoch
ein Master den Bus nutzen kann muss er ihn reservieren, dies geschieht über den
zentralen „Arbiter“ (engl. „Schiedsrichter“). Er ist Teil eines Modules das „System-
Controller“ genannt wird. Die Funktion des „Arbiters“ ist zu entscheiden welchem
Master der Zugriff auf den Bus gewährt wird.
Der Bus der VMEbus-Architektur teilt sich in fünf Subbusse auf
• Data Transfer Bus
• Data Transfer Bus Arbitration Bus
• Priority Interrupt Bus
• Utility bus
• Serial Bus

Der VMEbus ist ein asynchroner Bus, das bedeutet dass es keinen zentralen Taktgeber
gibt, der die Übertragungen koordiniert. Die Daten werden über sogenannte „Handshake-
Signale“ unter den Modulen ausgetauscht. Die Geschwindigkeit eines Transfers unter den
Modulen ist dabei durch das langsamte teilnehmende Modul begrenzt.

VME64
Ein neuerer Standard des VMEbus, genannt VME64 (ANSI/VITA 1-1994), wurde 1995
genehmigt. Seit damals sind eine Menge unterschiedlicher Boards und Chips entwickelt
worden die diesen Standard unterstützen. Er definiert unter anderem
• eine größere Bandbreite (80 MB/s)
• einen breiteren Adressraum (64-Bit)
• eine breitere Datenübertragung (64-Bit)
• nutzerfreundlichere Karten
• First-Slot-Detector
• Automatische Plug-and-Play Fähigkeit
• Neudefinition der SERCLK und SERDAT-Pins
All die Erneuerungen sind „Optional“ sodass auch ältere Karten problemlos auf einer
VME64-Backplane betrieben werden können (vörwärtskompatibel). Der Begriff VME64
ist deshalb etwas verwirrend, da alle alten Module (IEEE-1014-1987) auch dem VME64-
Standard entsprechen

VME64x (VME64 Extensions)


Im Jahre 1997 übernahm die VSO (VITA Standard Organisation) eine Erweiterung des
VME64 Standards. Dieser neue Standard wurde als „VME64 Extensions“ bekannt. Er
erweiterte VME64 um neue Fähigkeiten, z.B.
• eine neue 160-Pin Stecker Familie
• einen zusätzlichen 95-Pin Stecker (P0/J0)
• 3,3V PowerSupply Pins
• weitere +5V DC Pins
• „Geographical Adressing“
• mehr Bandbreite (bis zu 160 MB/s)
• weitere 141 benutzerdefiniere I/O-Pins
• Live Insertion (Hot-Swap)
• Möglichkeiten zur schadlosen Elekrostatischen-Entladung
Auch hier wurde auf Kompatibiltät der alten Module geachtet. Generell funktionieren
neuere VME64x Module auch auf alten VMEbus Backplanes (rückwärtskompatibel), es
gibt aber Ausnahmen. Braucht ein Modul beispielsweise den neuen 3,3V Pin, dann wird
es auf einer alten Backplane nicht funktionieren.
Anders als bei VME64 muss ein Board das VME64x-komform ist ein Minimum an
Merkmalen aufweisen.

Für ein Modul der Größe 6U sind das


• 160 Pin Steckverbindung
• Alle definierten Ground-Pins müssen verbunden sein

Für eine 6U Backplane sind das


• 160 Pin Steckverbindung
• Alle definierten Ground-Pins müssen verbunden sein
• einheitliche Leiterbahnen (z.B. müssen J1 und J2 Verbindungen angebracht sein)
• „Geographical Address“-Pins
• Muss alle VME64 und VME64x Bus-Signal-Leitungen routen und terminieren.
• Stromverteilung für +5V, +3.3V, +/- 12V, +/- V1, +/- V2 und VPC
• wenn benutzerdefinierte rückseitige I/O-Pins unterstütz werden müssen diese dem
IEEE 101.11 Standard entsprechen

VME 320
Von „Arizona Digital, Inc.“ wurde 1997 ein modifizierter VMEbus, genannt VME320,
vorgestellt. Diese Modifikation verdoppelte die Geschwindigkeit des VMEbus erneut.
Die Bandbreite lag nun bei 320 MB/s, in der Spitze sogar über 500 MB/s.
VME320 nutzt ein neues Protokoll und Backplane-Design, die Architektur ist proprietär
und die Entwickler besitzen zumindest in Amerika Patentrechte auf die Backplane-
Technologie. Diese basiert auf der Stern-Topologie. Module können hingegen ohne
Lizenzgebühr entwickelt und verkauft werden.
Anwendungen
Der VMEbus findet sich in einer vielzahl unterschiedlicher Anwendungen wieder für die
er mitunter in seinem Design auf die speziellen Bedürfnisse angepasst wurde.
Diese Anwendungen sind beispielsweise
• Industriellen Steuerungsanlagen,
z.B. in der automatisierten Automobilherstellung
• Militär,
z.B. in Kommandosystemene, Radar und Kommunikation
• Luft- und Raumfahrt,
z.B. in der Mars Pathfinder Mission
• Transportsysteme,
z.B. in der Schienenverkehr-Regelung
• Telekom,
z.B. in den Handystationen und Telefon-Switches
• Simulationen,
z.B. Aircraft Flight, Earthquake und diverse militärische Simulationen
• Wissenschaft,
z.B in Medizin für die CATSCAN Bildgebung und Physik in Partikeldetektoren
• Allgemeines,
z.B. in Netzwerkroutern, Servern, Kopierern und High-Speed-Druckern

Software
Der VMEbus hat von allem Computer-Architekturen die größte Anzah an
Betriebssystemen. Es gibt über 103, beispielsweise

UNIX Style OS: Solaris, SunOS, Berkeley, AT&T, Linux


WINTEL Style OS: DOS, OS-2, Windows 3.1, Windows 95/98/NT
Real Time OS: VwWorks, pSOS, LynxOS, QNX, RTLLinu

Der System-Controller
Der Arbiter
Der VMEbus ist ein Multimaster-Bus. Das bedeutet dass ein VME-System mehrere
Master, sogar bis zu 21, haben kann. Jeder Master hat die Fähigkeit den Bus zu
reservieren und einen Datentransfer auszuführen. Module die dies nicht können nennt
man Slave. Sie können den Bus nicht reservieren. Slaves warten bis sie über den
Adressbus angesprochen werden (Adresse aus ihrem Bereich) und versenden erst dann
die angeforderten Daten.
Da sich alle Master den selben Bus teilen müssen, benötigt ein VME-System einen
Mechanismus der den Zugriff auf den Bus koordiniert. Diesen Mechanismus übernimmt
der Arbiter (engl. „Schiedsrichter“). Er befindet sich auf den System-Controller und
dieser steckt stets in Slot1.

Andere Funktionen
Neben dem Arbiter besitzt der SystenController noch andere Funktionen, so auch einen
16 MHz Taktgeber (SYSCLK) und den Interrupt Acknowledge (IACK) Daisy-Chain
Treiber.
Da der VMEbus ein asynchroner Bus ist gibt es keine Beziehung zwischen SYSCLK und
anderen Signalen auf dem Bus. Der 16 MHz Taktgeber ist eine Standardausstattung und
Designer können ihn anstatt eines On-Board Oszillators nutzen. Der Taktgeber wird zwar
auch in Zukunft vorhanden sein, aber die Nutzung könnte durch neue Standards
eingeschränkt werden. Von seiner Benutzung wird deshalb abgeraten.
Der IACK Daisy-Chain Treiber ist eine einfache Schaltung die das richtige Zeitverhältnis
zwischen IACK und IACK IN/OUT Signalen sicherstellt.

Der DTB Arbitration Bus


Der VMEbus besteht aus vier Subbussen. Einer davon ist der „Data Transfer Bus
Arbitration Bus“. Dieser Bus beinhaltet vier Bus-REQUEST-Signale (BR3* bis BR0*),
vier Bus-GRANT-Signalpaare (BG3IN*/BG3OUT* bis BG0IN*/BG0OUT*), ein Bus-
CLEAR-Signal (BCLR*) und ein Bus-BUSY-Signal (BBSY*).
Das BBSY* Signal wird von dem Master gesendet, der den Bus gerade belegt, durch
aufheben des Signals wird der Bus wieder freigegeben.
Info: Das Zeichen * nach dem Signalnamen bedeutet dass es sich um low-aktive Pegel
handelt, z.B. ist der Bus bei einem einem LOW Signal auf BBSY* belegt.
Der Arbiter auf dem System-Controller ist auf drei unterschiedliche Verteilungsmodi
einstellbar, das sind
• priority (PRI),
Verteilung nach Bus-Request-Level (3 - hohe Priorität bis 0 - niedrige Priorität)
• round-robin (RR),
Verteilung abwechselnd (3, 2, 1, 0, 3, 2, 1, ...)
• single level (SGL),
Verteilung nur an einen (Bus-Request-Level 3)
Die Einstellung des Verteilungsmodus ist Teil der Systeminitialisierung und verändert
sich während der System-Lebenszeit nicht mehr. Auch spezielle Kombinationen sind
möglich.

Die Busanforderung
Befor ein Master den Bus für den Datenverkehr nutzen darf muss er ihn anfordern. Er
mach dies in dem er eine der verfügbaren Bus-REQUEST-Leitungen (BR3* bis BR0*)
belegt. Abhängig vom Modus und der aktuellen Bus-Aktivität wird der Arbiter
entsprechend reagieren.

Beispiel 1 (priority mode):


Master 1 fordert den Bus an, dieser ist aber bereits durch einen anderen Master (2) belegt.
Master 2 hat den Bus über die BR3* Leitung angefordert. Hier wird der Arbiter warten
bis Master 2 den Bus wieder freigibt und erst dann an Master 1 zuteilen.

Beispiel 2 (priority mode):


Master 1 fordert den Bus über BR3* an, dieser ist aber bereits durch einen anderen
Master (2) belegt. Dieser Master (2) hat den Bus aber nur über BR2* angefordert. Der
Arbiter wird Master 2 über BCLR* signalisieren dass ein anderer Master mit höherer
Priorität den Bus angefordert hat. Der Bus muss dann „sobald wie möglich“ freigegeben
werden (genaue Angaben sind nicht spezifiziert).

Moduswahl
Die Wahl zwischen den Modi hängt von der Applikation ab und wird generell dem
System-Designer überlassen.
Bei einfachen Systemen, die keinen ausgeklügelten Arbitermechanismus brauchen kann
der single-level-Modus ausreichen.
In einem System in dem die Aufgaben hierarchisch abgearbeitet werden müssen oder die
Unterbrechung eines Prozesses ein Problem darstellt empfiehlt sich der priority-Modus.
Round-Robin wird empfohlen wenn alle Aufgaben von gleicher Priorität sind und
Unterbrechungen unproblematisch sind.

Architektur
Funktionielle Module
Die VMEbus Archtitektur wird unter anderem mit einem Konzept von funktionellen
Modulen beschrieben. Diese Module beschreiben in diesem Zusammenhang keine
Hardware sondern Konzept-Instrumente
Die einzelnen Module des VME64 werden hier aufgelistet.
Master,
kann Buszyklen auf dem Data Transfer Bus initiieren.
Slave,
kann Buszyklen erkennen und an ihnen teilnehmen.
Location Monitor,
überwacht den Data Transfer Bus und erzeugt On-Board Signale wenn bestimmte
Adressen ausgewählt sind.
Bus Timer,
mißt wie lange ein Data Transfer Bus Zyklus dauert und erzeugt gegebenenfalls ein
BERR* Signal. Es handelt sich um eine Art Watchdog-Timer.
Interrupter,
erzeugt Interrupt-Anforderungen.
Handler,
reagiert auf Anforderungen von Interruptern.
IACK Daisy-Chain Driver,
treibt die IACK Daisy-Chain. Normalerweise ein Teil des System-Controller-Moduls in
Slot 1.
Requester,
fordert den Data Transfer Bus an.
Arbiter,
Überwacht den Data Transfer Bus und teilt ihn zu.
System Clock Driver,
leifert einen stabilen 16 MHz Takt.
Power Monitor,
erzeugt SYSRESET* und ACFAIL* Signale.

Subbusse
Der VMEbus gliedert sich in mehrere Subbusse (dt. „Unterbusse“). Diese Busse sind
ebenso Konzept-Instrumente wie die funktionellen Module.
Data Transfer Bus (DTB),
wird genutzt um Adress und Dateninformationen zu übertragen.
Data Transfer Arbitration Bus,
wird genutzt um die Rechtevergabe des DTB zu regeln.
Priority Interrupt Bus,
wird genutzt um Interrupts zwischen Modulen auszutauschen.
Utility Bus,
beeinhaltet eine Sammlung von Nutzsignalen wie „System Reset Signal“ und „Utility
Clock“.
Serial Bus,
ein zweiadriger serieller Bus.
Test & Maintenance Bus ??? generell, was ist mit VME64x Bussen?

Buszyklen
Der Standard VME-Buszyklus ist der READ/WRITE Zyklus. In jeder Transaktion
können mit ihm 8, 16, 24 oder 32 Bit Daten übertragen werden. Andere Buszyklen sind
spezialisierter oder ermöglichen schnellere Operationen.

Ein Buszyklus besteht generell grob aus


• Anforderung,
• Zuteilung und
• Übertragung.

Data Transfer Bus Cycles


Read/Write Cycles,
Standard Datentransfer-Zyklus, wird genutzt um je einen Teil an Daten pro Zyklus zu
übertragen.
Read-Modify-Write Cycles,
ein unteilbarer Zyklus der genutzt wird um „Semaphore“-Informationen im
Multiprocessing-System weiterzugeben.
Block Transfer Cycles,
ein Buszyklus der Daten in Blöcken überträgt. Für gewöhnlich schneller als der
Read/Write-Zyklus.
Multiplexed Block Transfer Cycles,
wie Block Transfer Cycles, allerdings werden Adress- und Dateninformationen
kombiniert übertragen. So können größere Adress- und Datenbusse genutzt werden.
Schließt MBLT und MD32 Cycles mit ein.
Two-edge Cycles,
wie Multiplexed Block Transfer Cycles, allerdings wird “Two Edge Handshake” genutzt.
Schließt 2eVME und 2eSST Cycles mit ein.
Adress-only Cycle,
überträgt nur eine Adresse. Schließt ADO und ADOH Cycles mit ein.

Data Transfer Arbitration Bus Cycles


Arbitration Cycle,
dient zur Verteilung der Zugriffsrechte auf den Bus.
Priority Interrupt Bus Cycles
IACK* Cycle,
wird zur Übertragung der Interrupt über die Backplane genutzt.

Der VMEbus Standard erlaubt unterschiedliche Address und Daten-Breiten. Während


zwar alle Kombinationen erlaubt sind, gibt es einige die sich mehr durchgesetzt haben als
andere.
So wird zum Beispiel A16/D8 meist für einfache und A32/D32 bzw. A32/D64 für High-
Performance-Boards genutzt. A24 wird nur noch selben und dann auf älteren U6 Boards
gefunden, es wurde schnell durch A32 ersetzt.

Durch die zahlreichen Erweiterungen von VME64 und VME64x entstanden noch mehr
Buszyklen. Ermöglicht haben das die sogenannten „Address Modifier Codes“, diese
„kennzeichnen“ die unterschiedlichen Buszyklen.
Neu entwickelte Buszyklen werden durch einen neuen „Address Modifier Code“
gekennzeichnet, so wird die Kompatiblität zwischen den Modulen gewährleistet.

Address Modifier Code


Dynamische Adressbreitenanpassung ist durch einen 6-Bit Code möglich der jede
Adressangabe begleitet. Es gibt bisher 47 definierte „Adress Modifier Codes“.
Der Address Modifier Code (AM) wird vom Master an die eigentlichen
Adressinformationen angehängt, der Slave weiß dadurch wieviele Bits die Adresse
repräsentieren. Außerdem enthält der AM Informationen zum Buszyklus, dadurch kann
der Slave zwischen Befehls-fetching und Daten-Zyklen unterscheiden.
Befehle werden allerdings kaum noch über den VMEbus übertragen, lokale Speicher in
er CPU sind mittlerweile schnell, groß und billig genug. Der VMEbus würde hier einen
Flaschenhals bilden. Meistens wird der VMEbus genutzt um Daten zwischen CPU und
Peripherie zu übertragen.
In Interrupt Acknowledge Cycles wird der Address Modifier Code ignoriert.
IACK* wird bei einem Interrupt Acknowledge Cycle von Interrupt Handler gesetzt und
bei einem Data Cycle vom Master negiert. IACK* ist sozusagem das 7. Address Modifier
Code Bit.
Durch den Address Modifier Code können auch Kosten bei der Herstellung gespart
werden, ein Modul muss nur so komplex sein wie es die Applikation erfordert. Ein
einfaches I/O Board kann z.B. A16 Adressierung nutzen, das reduziert die Anzahl an
Bauteilen.
Ohne AMCwäre auch die Kompatiblität von 3U zu 6U Boads heikel geworden, da 3U
Module nur die Pins A01 bis A23 sehen und dadurch auf max. A40 Zyklen begrenzt sind.
Mit 2eVME wurde ein weiterer Address Modifier Code eingeführt, genannt Extended
Address Modifier Code (XAM). Ausschlaggebend dafür war dass bereits viele der AM-
Codes belegt waren, so wurde Platz für zukünftige Codes geschaffen.
Konkurrenzprodukt von Intel: Multibus II

32 Bit:
DIN 41612
C96 Steckverbindung
3 Reihen mit je 32 Kontakten, insgesamt 96 je Steckverbinder

64 Bit:
VME64x ANSI/VITA 1.1-1997 unfasst Normentwurf für
• 5-reihigen Steckverbinder IEC 61076-4-113 (har-bus® von HARTING)
• Mittigen J0/P0 auf 6HE VME Karten.

5 Reihen mit je 32 Kontakten, insgeamt 160 je Steckverbinder

J0/P0
• IEC 61076-4-101
• für zusätzliche Ein-/Ausgänge, Unterbusse, Ein-/Ausgängen bei
Zwischenmodulen (z.B. IP-Modulen) ist
• zwischen den anderen Steckeverbindungen angebracht
• 5 Reihen mit je 19 Signalkontakte, optional eine Reihe zusätzlich auf jeder Seite
zur Abschirmung
• Alle 95 Signalkontakte sind benutzerdefiniert

Durch vier „voreilende“ Kontakte die während des Steckvorgangs die Logik in einen
definierten Zustand setzen kann ein VME64x Board während des Betriebs gesteckt
werden (Live Insertion).
Quellen:
• http://www.harkis.harting.com/WebHelp/DhHM/WebHelp/DhHMVME64x_-
_Allgemeine_Informationen.htm
• http://www.harkis.harting.com/WebHelp/DGds/WebHelp/DgdsTechDataharbus64.ht
m
• http://de.wikipedia.org/wiki/VMEbus
• http://www.vita.com/vmefaq.html
• http://www.vita.com/vme-faq/systemcontroller.html
• http://www.vita.com/vme-faq/vmeamcod.html