DE10324001A1

DE10324001A1 - Verfahren zur Steigerung von entweder Transfer-Leistung oder maximaler Leitungslänge bei einem Bussystem in einem Lenk-Flugkörper-System

Info

Publication number: DE10324001A1
Application number: DE2003124001
Authority: DE
Inventors: Ingo Bohr
Original assignee: Bohr Ingo Dipl-Ing (fh)
Current assignee: Bohr Ingo Dipl-Ing (fh)
Priority date: 2003-05-27
Filing date: 2003-05-27
Publication date: 2004-12-30

Abstract

Es wird ein Verfahren zur "Steigerung von entweder Transfer-Leistung oder maximaler Leitungslänge beim Bussystem IMBUS-M" vorgeschlagen, bei der die Synchronisier-Signale "SLAVE-IMBUS-CLK" und "SLAVE-IMBUS-SYNC", die via IMBUS-M zu den SLAVES übertragen werden, zur Korrektur bzw. Kompensation von Schalt- und Laufzeiten gegenüber den Synchronisier-Signalen "MASTER-IMBUS-CLK" und "MASTER-IMBUS-SYNC", die im MASTER verwendet werden, um eine geeignete Zeitspanne vorverschoben werden. (Predelay) DOLLAR A Bei der Auslegung dieses "Signal-Predelays" werden dabei folgende Kriterien berücksichtigt: DOLLAR A È gleiches Predelay für "SLAVE-IMBUS-CLK" und "SLAVE-IMBUS-SYNC" DOLLAR A È Zeitquantisierung entsprechend dem geradzahligen Vielfachen (1, 2 usw.) der Master-Grundtakt-Periode und DOLLAR A È Einhaltung der zulässigen Setup-Parameter beim Erkennen von Control-Byte, Adress-Bytes und Daten-Bytes durch die SLAVES.

Description

1 Oberbegriff
Methode zur „Steigerung von entweder Transfer-Leistung oder maximaler Leitungslänge beim Bussystem IMBUS-M"; das zum Zweck des Datenaustauschs im "Lenk-Flugkörper-System KEPD" vorgesehen ist und folgende Basisfunktionen aufweist:

• Ausführung als synchroner, byteserieller Bus
• Informationstransfer in Form von (8 Bit) Bytes
• Transfer von Control-Byte, Adress-Bytes und Daten-Bytes im Zeitmultiplex-Verfahren
• Zentraler „BUSMASTER" zur Steuerung der Bustransfers und der Systemsynchronisation
• Übertragung/Abfrage eines Alarm-Vektors mittels eines speziellen Alarm-Transfers
• Systemsynchronisation MASTER → SLAVES mittels Synchronisations-Transfers
• Anschluß von max. 16 Busteilnehmern (SLAVES), verteilt über die gesamte Leitungslänge
• Minimal erreichbare Zykluszeit entsprechend erforderlicher maximaler Leitungslänge
• Differentielle Datenübertragung entsprechend „EIA 422/485"
• Der IMBUS-M setzt sich zusammen aus: – 8 differentiellen Daten-Leitungen – 2 differentiellen Takt-Leitungen – 1 Masse-Leitung

Die genannte Methode ist gekennzeichnet durch folgende Merkmale, wobei diese zum Zweck der Übersichtlichkeit und Lesbarkeit mit Überschriften versehen sind:
2 Kennzeichnender Teil
2.1 Verzögerung zwischen MASTER und SLAVE-Synchronisier-Signalen
Die Synchronisier-Signale „SLAVE-IMBUS-CLK" und „SLAVE-IMBUS-SYNC", die via IMBUS-M zu den SLAVES übertragen werden, werden zur Korrektur/Kompensation von Schalt- und Laufzeiten gegenüber den Synchronisier-Signalen „MASTER-IMBUS-CLK" und „MASTER-IMBUS-SYNC", die im MASTER verwendet werden, um eine geeignete Zeitspanne vorverschoben. (Predelay).
2.1.1 Auslegung des „Predelays der Synchronisier-Signale"
Bei der Auslegung dieses „Signal-Predelays" werden folgende Kriterien berücksichtigt:

• Gleiches Predelay für „SLAVE-IMBUS-CLK" und „SLAVE-IMBUS-SYNC"
• Zeitquantisierung entsprechend dem geradzahligen Vielfachen (1, 2 usw.) der Master-Grundtakt-Periode
• Einhaltung der zulässigen Setup-Parameter beim Erkennen von Control-Byte, Adress-Bytes und Daten-Bytes durch die SLAVES

2.2 Zusätzliche Verzögerung des Master-Taktsignals „DATA-FETCH-IMBUS-CLK"
Der Zeitpunkt der Datenübernahme mit „DATA-FETCH-IMBUS-CLK" beim Lesen vom IMBUS-M wird gegenüber dem internen Takt des Masters „MASTER-IMBUS-CLK", der das IMBUS-Protokoll steuert um eine geeignete Zeitspanne verzögert (Postdelay).
2.2.1 Auslegung der „Datenübernahme-Verzögerung"
Bei Auslegung der „Datenübernahme-Verzögerung" werden folgende Kriterien berücksichtigt:

• Unverändertes Timing zwischen MASTER-IMBUS-CLK und MASTER-IMBUS-SYNC
• Zeitquantisierung entsprechend dem geradzahligen Vielfachen (1, 2 usw.) der Master-Grundtakt-Periode
• Einhaltung der zulässigen Setup-Parameter bei Übernahme (Lesen) von SLAVE-Daten durch den MASTER bei maximaler Leitungslänge (Entfernung MASTER ↔ SLAVE)

2.3 Verzögerung der Busfreigabe beim Senden des „Control-Bytes"
Der Zeitpunkt der Busfreigabe (Bus-Enable) beim Senden des „Control-Bytes" durch den MASTER wird um eine geeignete Zeispanne verzögert (Postdelay).
2.3.1 Auslegung der „Busfreigabe-Verzögerung"
Bei Auslegung der „Busfreigabe-Verzögerung" werden folgende Kriterien berücksichtigt:

• Zeitquantisierung entsprechend dem geradzahligen Vielfachen (1, 2 usw.) der Master-Grundtakt-Periode
• Einhaltung der zulässigen Setup-Parameter bei Übernahme/Dekodierung des Control-Bytes in den SLAVES
• Vermeidung von Buskonflikten beim Lesen von SLAVE-Daten bei maximaler Leitungslänge (maximale Entfernung MASTER ↔ SLAVE)

2.4 „Predelay des Aufschaltzeitpunkts" beim Lesen von SLAVE-Daten"
Die Busfreigabe (Bus-Enable) beim Senden von Daten durch die SLAVES wird auf den frühest möglichen Zeitpunkt vorverlegt (Predelay).
2.4.1 Auslegung des „Predelays des Aufschaltzeitpunkts"
Bei Auslegung des „Aufschaltzeitpunkts" werden folgende Kriterien berücksichtigt:

• Vermeidung von Buskonflikten bei sequentiellen Schreib-/Lese-Zyklen zu den SLAVES bei minimaler Leitungslänge (minimale Entfernung MASTER ↔ SLAVE)
• Einhaltung der zulässigen Setup-Parameter bei Übernahme (Lesen) von SLAVE-Daten durch den MASTER bei maximaler Leitungslänge (Entfernung MASTER ↔ SLAVE)

2.5 Busfreigabe beim sequentiellen Senden oder Empfangen von IMBUS-Daten
Beim sequentiellen Senden von Daten durch MASTER oder SLAVES (Control, Adressen, Daten) wird auf das Schalten von Transmit-Enable zwischen den einzelnen Bytes verzichtet (⇒ Permanent-Transmit).
Ebenso entfällt beim Empfangen von Daten durch MASTER oder SLAVES das Schalten von Receive-Enable zwischen den einzelnen Bytes (⇒ Permanent-Receive).
1 Titel
Methode zur „Steigerung von entweder Transfer-Leistung oder maximaler Leitungslänge beim Bussystem IMBUS-M", das zum Zweck des Datenaustauschs im "Lenk-Flugkörper-System KEPD" vorgesehen ist.
2 Gattung und Angaben zur Gattung
Die Erfindung betrifft eine Methode zur Realisierung einer größeren Transfer-Leistung oder maximalen Leitungslänge beim Bussystem „IMBUS-M" nach dem Oberbegriff des Hauptanspruchs, wobei dieses Bussystem zum Zweck des Datenaustauschs im "Lenk-Flugkörper-System KEPD" verwendet wird und folgende dafür übliche Basisfunktionen aufweist:

3 Stand der Technik

Zur Realisierung des Bussystems „IMBUS-M" mit den genannten Basisfunktionen, sind folgende Anpaß-Möglichkeiten für eine sichere Datenübertragung über größere Leitungslängen bekannt:

• Anpassung der Zykluszeiten für READ- und WRITE-Transfers
• Anpassung der Zykluszeit nur für die kritischen READ-Transfers

4 Kritik am Stand der Technik

Der Nachteil der bekannten Realisierungs-Methode besteht darin, daß entweder die Transfer-Leistung des IMBUS-M durch die an die Leitungslänge angepassten, erhöhten Zykluszeiten stark reduziert ist oder die erforderliche Leitungslänge bei vorgegebenen Zykluszeiten nicht realisierbar ist.

5 Fundstellen

1. TN AE13-27/87 Technical Description of the Bussystem IMBUS-M
2. TN AK243-2/87 Critical Item Product Specification for Missile-Computer DWS39
3. 5-DWS-16211 Critical Item Development Specification for Missile-Computer DWS39
4. TN AK352-20/90 Basiskonzept des MICOM-RT
5. EIA 485 Standard for electrical Characteristics of Generators and Receivers for use in balanced Digital-Multipoint-Systems
6. NATIONAL SEMICONDUCTOR Interface Databook, insbesondere: Multipoint RS-485 Transceivers
6. ALTERA Data Book (ALTERA 1993), insbesondere: Section3: „MAX 5000 Family" Section10: „Device Operation" Section11: „Development Tools"
7. ALTERA Applications Handbook (ALTERA 1992), insbesonders: Section1/AN22: „Designing with AHDL" Section1/AN28: „Waveform Design Entry" Section1/AB77: „Fitting Complex Designs for MAX 500 EPLD's" Section1/AB100: „Understanding EPLD Timing"
8. ALTERA MAX+PLUS2 „Users Guide" (ALTERA 1991)
9. ALTERA MAX+PLUS2 „Text-Editor and AHLD" (ALTERA 1991)
10. ALTERA MAX+PLUS2 „Compiler" (ALTERA 1991)
11. ALTERA MAX+PLUS2 „Simulator, Timing-Analyser and Waveform-Editor"

6 Aufgabe

Der Erfindung liegt die Aufgabe zugrunde, eine Realisierungsmethode für das „Bussystem IMBUS-M" zu entwickeln, die gegenüber der bekannten Methode entweder bei gleicher Leitungslänge eine wesentlich höhere Transfer-Leistung ermöglicht oder bei gleicher Transfer-Leistung eine größere Leitungslänge erlaubt.

7 Lösung

Die Aufgabe wird erfindungsmäßig durch die Verfahrensschritte nach dem „kennzeichnenden Teil des Hauptanspruches" gelöst, wobei es das Ziel der vorgeschlagenen Lösungsschritte ist, die dabei erreichten Zugriffs- bzw. Setup-Zeiten beim Datenempfang durch den IMBUS-M Master dem „theoretischen Maximum" d.h. der IMBUS-M Zykluszeit anzugleichen.

8 Erzielbare Vorteile

Verglichen mit der bekannten Methode erlaubt das vorgestellte Verfahren eine wesentliche effektivere Realisierung des IMBUS-M, wobei Effektivität in diesem Fall bedeutet:

• „Kürzere Zykluszeiten", d.h. mehr Botschafts-Transfers pro Zeiteinheit bei einer vorgegebenen Leitungslänge oder
• „Größere Leitungslänge" bei einer vorgegebenen Zykluszeit sowie
• „Erhöhung der Störsicherheit" beim Daten-Transfer durch Reduzierung bzw. Vermeidung von Bus-Konflikten.

9 Beschreibung eines Ausführungsbeispiels
9.1 Allgemeines zum IMBUS-M
Das verwendete Bus-Systems IMBUS-M stellt eine kostengünstige Hochgeschwindigkeits-Datenverbindung zwischen den verschiedenen Funktionseinheiten (wie z.B.: Lenkrechner, Inertial-System, Rudermaschinen usw.) eines Flugkörpers dar, wobei sich das Bus-System selbst aus folgenden Komponenten zusammensetzt:

• IMBUS-M Bus-Master Der Bus-Master wird normalerweise in den Lenkrechner integriert und hat die Aufgabe die Steuerung und Synchronisation der Bus-Transfers zu übernehmen.
• IMBUS-M Bus-Slave Mit Bus-Slaves werden die übrigen Funktionseinheiten (wie z.B.: Inertial-System, Ruder-Maschinen, Träger-Interface usw.), die am IMBUS-M angeschlossen sind, bezeichnet.
• IMBUS-M Verkabelung Die Verkabelung besteht aus 2 × 10 Signal-Leitungen sowie einer Masse-Leitung. Zudem sind Bus-Abschlüsse (Widerstände) an jedem Leitungs-Ende vorgesehen.

9.1.1 Prinzip des IMBUS-M Informationsaustauschs
Eine IMBUS-M-Botschaft besteht aus einem Kontroll-Zyklus und einem oder mehreren Daten-Transfer-Zyklen (Daten/Adressen), die byteweise im Zeit-Multiplex-Verfahren über acht (8) bidirektionale Bus-Leitungen (B0 ... B7) übertragen und vom Bus-Master mittels der Signale „IMBUS-CLK (B9)" und „IMBUS-SYNC (B8)" synchronisiert werden.
Jede Botschaft beginnt mit einem Kontroll-Zyklus (IMBUS-SYNC = high bei steigender Flanke des IMBUS-CLK), wobei das zugehörige „Control-Byte" vom Master erzeugt und von allen Slaves dekodiert wird, um die angesprochene Funktionseinheit (Quelle/Ziel) sowie Daten-Transfer-Typ (Typ und Anzahl der Bytes) des folgenden Daten-Transfer-Zyklus zu erkennen.
Transfers mit einem „Typ-Feld des Control-Bytes = 0" sind Command-/Status-Transfers und dienen hauptsächlich der Fehler-Erkennung/-Behandlung des slaveseitigen Businterface.
Die zeitliche Synchronisation der MASTER/SLAVE-Echtzeitkommunikation wird durch Synchronisations-Transfers bewerkstelligt. Ein Synchronisations-Transfer ist eine Botschaft MASTER an alle SLAVES, wobei jedem Datenbit ein unterschiedliches Synchronisations-Signal (z.B.: Reset, Sync1, Sync2 usw.) zugeordnet wird.
Eine System-Synchronisation sowie eine Alarm-/Interrupt-Erkennung wird durch einen Bus-Transfer mit „Typ- und Slave-Feldern des Control-Bytes = 0" realisiert.
9.2 Aufbau und Funktion eines IMBUS-M Busmasters
Der Aufbau und die Wirkungsweise eines IBBUS-M-Busmasters mit „korrigiertem IMBUS-M-Timing zur Erhöhung von entweder Transfer-Leistung oder maximaler Leitungslänge", der sich aus dem Steuerwerk „IMBUS-CONTROL" und den „IMBUS-M Line-Driver/Receivern" zusammensetzt, ist in den 1 bis 3 dargestellt und wird nachstehend näher beschrieben.
Die einzelnen Abbildungen zeigen:
1: Zustands-Diagramm der State-Machine „M-STATE"
2: Zeitlicher Ablauf von IMBUS-M Zugriffen vom Botschafts-Typ # 0
3: Zeitlicher Ablauf von IMBUS-M Zugriffen vom Botschafts-Typ # 5
Liste 1: „Text-Design-File" des IMBUS-M Masters „IMBCTR.TDF"
Anmerkung zu Liste 1:
Bei der zusätzlich beigefügten Liste handelt es sich um die Zusammenfassung der sogenannten „Bool'schen Gleichungen", welche die Funktion des IMBUS-M Masters exakt beschreiben. Bei der zugrunde liegenden Beschreibungs-Sprache handelt es sich um ein, vom Hersteller ALTERA der verwendeten anwenderprogrammierbaren Logik-Elemente entwickeltes und von der standardisierten Beschreibungs-Sprache VHDL abgeleitetes Derivat und zwar AHDL (ALTERA-Hardware-Description-Language/siehe Fundstellen 7 und 9). Der Vorteil und auch der Zweck der beigefügten Liste ist, daß jeder beliebige Fachmann, falls er über eine Entwicklungs-Software MAX+pLUS2 von ALTERA verfügt, die Funktion des IMBUS-M Masters per MAX+pLUS2 Simulation (siehe Fundstelle 11) leicht nachvollziehen kann (siehe 4 und 5)
Zeichenerklärungen:

• Signale, die „active-low" sind, werden mit „_Signalname" gekennzeichnet.
• Ein beliebiger Signalwert wird mit „X " gekennzeichnet.
• Eine Zustandsveränderung wird gekennzeichnet mit: „Signalname → neuer Zustand"
• Das Halten eines Zustands wird gekennzeichnet mit: „Signalname = alter Zustand"
• Das „logische UND" wird mit „&"gekennzeichnet.
• Das „logische ODER" wird mit „#" gekennzeichnet.

9.2.1 Allgemeines zum IMBUS-M Busmaster
Bei der Anwendung des Bussystem IMBUS-M im "Lenk-Flugkörper-System KEPD" ist der IMBUS-M-Busmaster in den Lenkrechner MICOM-RT integriert. Auf Grund des weiten 32-Bit Adressraums des verwendeten „MOTOROLA MC 68040-Prozessors" bietet sich bei der Realisierung des IMBUS-M-Busmaster-Interfaces an, das IMBUS-M-Control-Byte in den Adressraum des Prozessors abzubilden. Dies bedeutet, daß der Zugriff des Prozessors auf die IMBUS-M Slaves aus programmtechnischer Sicht in einer speicherabbildenden Form (Memory-Mapped) erfolgt.
9.2.2 Steuerung des Datenverkehrs durch den IMBUS-M Busmaster
Der Datenverkehr zwischen Prozessor ↔ IMBUS-M Slaves wird in 2 Stufen durchgeführt:

• Datenverkehr zwischen Prozessor ↔ IMBUS-M Master, der vom Steuerwerk „BUS-CONTROL" gesteuert wird, wobei die verwendeten Steuersignale des Prozessors mit denen der Zugriffssteuerung für den Speicher identisch sind.
• Datenverkehr zwischen IMBUS-M Master ↔ IMBUS-M Slaves, der vom Steuerwerk „IMBUS-CONTROL" durchgeführt wird.

Die beiden Steuerwerke „BUS-CONTROL" und „IMBUS-CONTROL", die den Datentransfer zwischen dem Prozessor und den IMBUS-M Slaves kontrollieren, sind untereinander über zwei „Handshake-Leitungen" verbunden und zwar:

• IMBUS-REQUEST (_imb_rq)
• IMBUS-READY (_imb_rdy)

Diese „Handshake-Signale" haben folgende Funktion:

• IMBUS-REQUEST (_imb_rq): Wird durch das Steuerwerk BUS-CONTROL erzeugt und ist vorgesehen, um beim Zugriff auf die IMBUS-M Slaves durch Setzen (_imb_rq → true) das Steuerwerk IMBUS-CONTROL zum Start eines IMBUS-Transfers zu veranlassen. Der Start eines Transfers wird zudem davon abhängig gemacht, ob der vorhergehende Transfer abgeschlossen ist oder nicht, wobei das Kriterium dafür durch Abfrage des Signals IMBUS-READY (_imb_rdy = true/false) gewonnen wird: – Wird (_imb_rdy = true, d.h. letzter Transfer noch nicht abgeschlossen) erkannt, so wird (_imb_rq → true) durch Einfügen von Wartezyklen erst dann erzeugt, wenn (_imb_rdy = false) erkannt wird. – Wird (_imb_rdy = false, d.h. letzter Transfer beendet) erkannt, so wird (_imb_rq → true) erzeugt. Anschließend d.h. nach Start des Transfers durch (_imb_rq → true) wird IMBUS-REQUEST wieder rückgesetzt (_imb_rq → false), wenn (_imb_rdy = true, d.h. IMBUS-Transfer gestartet) erkannt wird.
• IMBUS-READY (_imb_rdy): Wird durch das Steuerwerk IMBUS-CONTROL erzeugt und ist vorgesehen, um: – Durch Setzen (_imb_rdy → true) dem Steuerwerk BUS-CONTROL mitzuteilen, daß der Start eines neuen Transfers mittels (_imb_rq → true) erkannt wurde. – Durch Halten (_imb_rdy = true) das Steuerwerk BUS-CONTROL daran zu hindern, einen neuen Transfer zu starten, solange der alte Transfer noch nicht abgeschlossen ist.

9.2.3 Aufbau und Funktion des Steuerwerks IMBUS-CONTROL
9.2.3.1 State-Machine „T-STATE"
Diese Zustands-Maschine dient zur Erzeugung von 4 phasenverschobenen, sich überlappenden, zyklischen Signalen mit einer Wiederholzeit, die der „Bus-Cycle-Time (300 ns @ 20 MHz)" des IMBUS-M Transfers entspricht und zwar dem 6-fachen der Grundtaktperiode (50 ns). Die Codierung dieser Signale ist so ausgelegt, daß sich mit jeder Flanke des erzeugenden Grundtaktes „BCLK" jeweils nur eines der „T-STATE-Bits (sog. One-Hot State Machine)" ändert. Damit lassen sich mit diesen Signalen innerhalb der Wiederholperiode (Bus-Cycle-Time) beliebige „glitch- und spikefreie" Signale (z.B. diskrete Steuersignale) mit einer Zeitquantisierung, die der Grundtaktperiode entspricht, herausdekodieren bzw. die nachgeschalteten Zustands-Maschinen M-STATE und S-STATE untereinander synchronisieren.
9.2.3.2 State-Machine „M-STATE"
Diese Zustands-Maschine hat die Aufgabe die IMBUS-M Transfers durchzuführen, wobei 2 Fälle zu unterscheiden sind:

• NO-REQUEST (_imb_rq = false) Im Normalfall/Ruhezustand, wenn vom Prozessor keine Schreib- oder Lese-Anforderung an den IMBUS-M Master vorliegt, schaltet die State-Machine dauernd zwischen den beiden States „CV" und „VI" hin und her und bewirkt damit die Übertragung des Interruptvektors von den SLAVES.
• REQUEST (_imb_rq = true) Wird dagegen vom Prozessor ein Schreib- oder Lesezugriff an den IMBUS-M Master initiiert (_imb_rq → true), so verzweigt die State-Machine nach der letzten Interruptvektor-Übertragung (VI-Phase) in die entsprechende Transfersequenz (CD...), wobei die Art der Übertragung (Typ) über die Adressen (A27, A28, A29) bestimmt wird.

Folgende IMBUS-M -Botschaften sind möglich:

– Typ-0 mit 8-Bit Daten
– Typ-1 mit 8-Bit Adresse/8-Bit Daten
– Typ-2 mit 8-Bit Adresse/16-Bit Daten
– Typ-3 mit 16-Bit Adresse/16-Bit Daten
– Typ-4 mit 8-Bit Adresse/32-Bit Daten
– Typ-5 mit 16-Bit Adresse/32-Bit Daten
– Typ-6 mit Direct R/W
– Typ-7 mit Direct R/W

Jede IMBUS-M Botschaft besteht aus einem CONTROL-CYCLE mit anschließenden DATA-TRANSFER-CYCLES, die byteweise zeitlich aufeinanderfolgend übertragen werden. Nach Beendigung der IMBUS-M Botschaft (State DLL) kehrt das Steuerwerk in den Ruhezustand (State CV ↔ State VI) zurück und bewirkt damit erneut die Übertragung des Interrupt-Vektors. Somit ist sichergestellt, daß ein weiterer Schreib- oder Lesezugriff des Prozessors erst nach Übertragung des Interruptvektors bearbeitet und damit die Reaktionszeit auf externe Interrupts möglichst klein gehalten wird.
9.2.3.3 State-Machine „S-STATE"
Die Zustands-Maschine S-STATE ist vorgesehen, um in den vorgesehenen Betriebsarten durch Erzeugung des Handshake-Quittungssignals IMBUS-READY (_imb_rdy) die Synchronisation des Steuerwerks M-STATE mit den State-Machines RIMB-STATE bzw. WIMB-STATE im Steuerwerk BUS-CONTROL zu erreichen, wobei der Zeitpunkt bzw. Bedingung bei dem das Quittungssignal IMBUS-READY auf true oder false geschaltet wird von der Betriebsart abhängt.
Es sind folgende Betriebsarten bei der Zustands-Maschine S-STATE vorgesehen:

• OPERATIONELLER Betrieb
• MONITOR Betrieb
• DIRECT-READ/WRITE Betrieb

9.2.3.3.1 Steuerung Betriebsart „MONITOR-MODE-READ"
Nach Erkennung (_imb_rq = true & read = true) wird das Quittungssignal IMBUS-READY erst dann geschaltet (_imb_rdy → true), wenn der initiierte IMBUS-M Transfer beendet ist. Die State-Machine RIMB-STATE im Steuerwerk BUS-CONTROL wird damit für die Dauer des IMBUS-M Transfers in den Wartezustand (Wait-States) gesetzt. Abschluß eines MONITOR-Zugriffs mit (_imb_rdy → false), sobald (_imb_rq = false) erkannt wird.
9.2.3.3.2 Steuerung der Betriebsarten „MONITOR-MODE-WRITE" oder „OPERATION-MODE-READ/WRITE" oder „DIRECT-READ/WRITE"
Nach Erkennung (_imb_rq = true) wird das Quittungssignal IMBUS-READY sofort geschaltet (_imb_rdy → true), damit die aktive State-Machine des Steuerwerks BUS-CONTROL den Zugriff auf den IMBUS-M Master abschließen kann.
Das Rücksetzen von IMBUS-READY (_imb_rdy → false) ist dagegen abhängig von der Betriebsart und zwar:

• In den Betriebsarten OPERATIONELL oder MONITOR-WRITE und unter der Bedingung, daß (_imb_rq = false) erkannt wurde, erst nach Beendigung des IMBUS-M Transfers. Damit wird erreicht, daß ein erneuter Zugriff des Prozessors auf den IMBUS-M Master von der BUS-CONTROL erst dann initiiert werden kann (mit: _imb_rq → true), wenn der vorhergehende IMBUS-M Transfer beendet ist.
• In der Betriebsart DIRECT R/W unmittelbar nach Erkennung (_imb_rq = false), da in diesem Fall kein IMBUS-M Transfer gestartet wird.

9.2.3.4 Erzeugung der diskreten Steuersignale für den IMBUS-M Datenverkehr
9.2.3.4.1 Erzeugung der Synchronisier-Signale „IMBUS-CLK" und „IMBUS-SYNC"
Die Signale IMBUS-CLK und IMBUS-SYNC sind vorgesehen, um den Datenverkehr auf dem IMBUS-M zu synchronisieren. Das Timing ist so ausgelegt, daß das Signal IMBUS-SYNC zu Beginn jeder IMBUS-M Botschaft für die Dauer des CONTROL-CYCLES (CV oder CD) auf high gesetzt wird und so mit der Vorderflanke von IMBUS-CLK den SLAVES den Start einer Botschaft signalisiert. Mit den Vorderflanken der nachfolgenden IMBUS-CLK-Pulse werden die Daten im MASTER bzw. in den SLAVES übernommen (get data).
9.2.3.4.1.1 Verzögerung zwischen MASTER- und SLAVE-Synchronisier-Signalen
Zum Zweck der „Steigerung von entweder Transfer-Leistung oder maximaler Leitungslänge" werden die Taktsignale „SLAVE-IMBUS-CLK" und „SLAVE-IMBUS-SYNC", die zu den SLAVES übertragen werden, gegenüber den Taktsignalen „MASTER-IMBUS-CLK" und „MASTER-IMBUS-SYNC", die im MASTER verwendet werden um eine geeignete Zeitspanne vorverschoben. (Predelay).
9.2.3.4.1.2 Auslegung der Verzögerung der Synchronisier-Signale
Bei Auslegung der „Synchronisier-Signal-Verzögerung (Δ t1)" werden folgende Kriterien berücksichtigt:

• Gleiches Predelay für „SLAVE-IMBUS-CLK" und „SLAVE-IMBUS-SYNC"
• Zeitquantisierung entsprechend dem geradzahligen Vielfachen (1, 2 usw.) der Master-Grundtakt-Periode (BCLK)
• Einhaltung der zulässigen Setup-Parameter beim Erkennen von Control-Byte, Adress-Bytes und Daten-Bytes durch die Slaves

9.2.3.4.2 Erzeugung der Enable-Signale für die IMBUS-M Line-Driver/Receiver
Mit dem Signal (IMBUS-SYNC = low) wird die Datenübertragung auf dem IMBUS-M gesteuert, indem durch Verknüpfung mit dem gespeicherten R/W-Signal und den entsprechenden M-STATES die „Enable-Signale" für die IMBUS-M-Receiver (get data) und IMBUS-M-Transmitter (put data) gewonnen werden und zwar:

• Enable IMBUS-M-Receiver (EBI = ENABLE-BUS-IN)
• Enable IMBUS-M-Transmitter (EBO = ENABLE-BUS-OUT)

9.2.3.4.2.1 Busfreigabe beim sequentiellen Senden oder Empfangen von IMBUS-Daten
Zum Zweck der „Steigerung von entweder Transfer-Leistung oder maximaler Leitungslänge" wird beim Senden von Daten durch den MASTER (Control, Adressen, Daten) auf das Schalten von „ENABLE-BUS-OUT (EBO)" zwischen den einzelnen Bytes verzichtet. Ebenso entfällt beim Empfangen von Daten durch den MASTER das Schalten von „ENABLE-BUS-IN (EBI)" zwischen den einzelnen Bytes.
9.2.3.4.2.2 Verzögerung der Busfreigabe beim Senden des „Control-Bytes"
Zum Zweck der „Steigerung von entweder Transfer-Leistung oder maximaler Leitungslänge" wird der Zeitpunkt der Busfreigabe „ENABLE-BUS-OUT (EBO)" beim Senden des „Control-Bytes" durch den MASTER um eine geeignete Zeitspanne verzögert (Postdelay).
9.2.3.4.2.3 Auslegung der „Busfreigabe-Verzögerung"
Bei Auslegung der „Busfreigabe-Verzögerung (Δ t2)" werden folgende Kriterien berücksichtigt:

9.2.3.5 Interface zum 32-Bit Prozessorbus
9.2.3.5.1 Erzeugung „Address-Latch"
Zu Beginn eines jeden Zugriffs auf den IMBUS-M Master, unabhängig von der Art des Zugriffs, werden die Adressen in diesem Register zwischengespeichert, damit der anschließende IMBUS-M Transfer autonom durchgeführt werden kann und der Prozessor nicht warten muß bis der Transfer abgeschlossen ist und somit der Zugriff mit einem Minimum an „Wait-States" durchgeführt werden kann. Das Kriterium für den Zeitpunkt der Adressen-Übernahme wird durch das Signal (_imb_rq = true) geliefert.
9.2.3.5.2 Erzeugung „32-Bit Data-Latch/Tri-State-Buffer"
Dieses Datenregister mit nachgeschaltetem Tri-State-Buffer wird abhängig von der Art des Zugriffs „READ oder WRITE" unterschiedlich gesteuert und zwar:

• WRITE-Zugriff Dabei dient das Register zur Zwischenspeicherung der 32-BIT Prozessordaten, die beim nachfolgenden IMBUS-M Write-Transfer zu den SLAVES übertragen werden. Zeitpunkt und Zweck der Zwischenspeicherung siehe „Address-Latch". Die Tri-State-Buffer bleiben bei diesem Zugriff gesperrt (disabled).
• READ-Zugriff Dabei werden die Daten während eines IMBUS-M Read-Transfers byteweise in das 32-Bit Data-Latch eingeschrieben und zwar derart, daß die Bytes am Ende der „DATA-CYCLES (DHH, DHL, DLH, DLL)" mit „T-STATE = t0" aus dem „8-Bit IMBUS-M Data-Latch", in dem sie zwischengespeichert waren, übernommen werden. Das Auslesen des „ 32-Bit Data-Latches", d.h. enable Tri-State-Buffer, wird vom Steuerwerk BUS-CONTROL mit dem Signal IMBUS-OUTPUT-ENABLE (_imb_oe → true) durchgeführt.

9.2.3.5.2.1 Späterer Zeitpunkt der Datenübernahme ins „32-Bit Data-Latch"
Zum Zweck der „Steigerung von entweder Transfer-Leistung oder maximaler Leitungslänge" werden die Daten, die während eines IMBUS-M Read-Transfers byteweise in das 32-Bit Data-Latch eingeschrieben werden sollen, erst zu Beginn des nächsten „DATA-CYCLES" mit „T-STATE = t1" (Grund: Zusätzliche Verzögerung des Taktsignals „DATA-FETCH-IMBUS-CLK") aus dem „IMBUS-M Data-Latch", in dem sie zwischengespeichert waren, übernommen.
Dies bedeutet im einzelnen Fall:
Datenübertragung → Datenübernahme
• DHH → DHL
• DHL → DLH
• DLH → DLL
• DLL → CV
9.2.3.6 Interface zum IMBUS-M
9.2.3.6.1 Erzeugung „8-Bit IMBUS-M Data-Latch"
In diesem Register werden im Fall eines IMBUS-M Read-Transfers während der „Data-Cycles (DHH, DHL, DLH, DLL)" die IMBUS-Daten mit der positiven Flanke von IMBUS-CLK zwischengespeichert, um dann am Ende des jeweiligen „Data-Cycles" mit „T-STATE = t0" byteweise in das „ 32-Bit Data-Latch" übernommen zu werden.
9.2.3.6.1.1 Zusätzliche Verzögerung des Taktsignals „DATA-FETCH-IMBUS-CLK"
Zum Zweck der „Steigerung von entweder Transfer-Leistung oder maximaler Leitungslänge" wird der Zeitpunkt der Datenübernahme mit DATA-FETCH-IMBUS-CLK beim Lesen vom IMBUS-M gegenüber dem internen Takt des Masters „MASTER-IMBUS-CLK", der das IMBUS-Protokoll steuert, um eine geeignete Zeitspanne verzögert (Postdelay).
9.2.3.6.1.2 Auslegung der Verzögerung des Taktsignals „DATA-FETCH-IMBUS-CLK"
Bei Auslegung der „Datenübernahme-Verzögerung (Δ t3)" werden folgende Kriterien berücksichtigt:

• Unverändertes Timing zwischen „MASTER-IMBUS-CLK" und „MASTER-IMBUS-SYNC"
• Zeitquantisierung entsprechend dem geradzahligen Vielfachen (1, 2 usw.) der Master-Grundtakt-Periode
• Einhaltung der zulässigen Setup-Parameter bei Übernahme (Lesen) von SLAVE-Daten durch den MASTER bei maximaler Leitungslänge (Entfernung MASTER ↔ SLAVE)

9.2.3.7 Erzeugung IMBUS-M Data/Address-Multiplexer und IMBUS-M Tri-State-Buffer
Aufgabe dieser Funktionsgruppe ist die byteweise Übertragung von Daten innerhalb einer IMBUS-M Botschaft und zwar:

• IMBUS-M Data/Address-Multiplexer Hat die Aufgabe, in Abhängigkeit vom gerade stattfindenden „Bus-Cycle", das innerhalb einer IMBUS-M Botschaft zu übertragende Daten-Byte (Control # Adressen # Daten) auszuwählen.
• IMBUS-M Tri-State-Buffer Diese werden für die Dauer jedes „IMBUS-M Write-Cycles" freigegeben (enabled)

9.2.3.8 Erzeugung der „IMBUS-M Interrupts"
9.2.3.8.1 Erzeugung „IMBUS-M Interrupt-Latch"
Beim Interrupt- bzw. Alarm-Transfer wird maximal acht (8) alarmberechtigten SLAVES je eine bestimmte Datenleitung/Datenbit zugeordnet. Der so gebildete Sammelalarm wird zum MASTER übertragen und von diesem ausgewertet, indem während der „VI-Phase" mit der Vorderflanke von IMBUS-CLK der Zustand der IMBUS-Leitungen (0..7) übernommen wird. Der gespeicherte Zustand der vorhergehenden „VI-Phase" wird überschrieben.
9.2.3.8.2 Erzeugung des „IMBUS-M READY-Interrupts"
Im Fall eines „MONITOR-Read-Zugriffs" wird am Ende eines IMBUS-M Transfers (DLL) ein READY-Interrupt erzeugt und zwar für die Dauer eines "Bus-Cycles".
9.3 Aufbau und Funktion eines IMBUS-M Busslaves
9.3.1 Allgemeines zum IMBUS-M Busslave
Zu Beginn jeder Botschaft wird das vom IMBUS-M-Busmaster während des CONTROL-CYCLES (CV oder CD) gesendete „Control-Byte (IMBUS-SYNC = high bei steigender Flanke des IMBUS-CLK)" von allen Slaves dekodiert, um die angesprochene Funktionseinheit (Quelle/Ziel) sowie den Daten-Transfer-Typ (Typ und Anzahl der Bytes) des folgenden Daten-Transfer-Zyklus zu erkennen.
Mit den Vorderflanken der nachfolgenden IMBUS-CLK-Pulse werden die Daten in den SLAVES übernommen (get data).
9.3.2 Realisierung eines IMBUS-M Busslaves
Der Aufbau und die Wirkungsweise eines IMBUS-M-Busslaves mit „korrigiertem IMBUS-M-Timing zur Erhöhung von entweder Transfer-Leistung oder maximaler Leitungslänge", ist in den 4 bis 5 dargestellt und wird nachstehend näher beschrieben.
Die einzelnen Abbildungen zeigen:
4: Beispiel eines IMBUS-M-Busslave State-Diagramms
5: Beispiel eines IMBUS-M-Busslave Timing-Diagramms
9.3.2.1 „Predelay des Aufschaltzeitpunkts" beim Lesen von SLAVE-Daten
Zum Zweck der „Steigerung von entweder Transfer-Leistung oder maximaler Leitungslänge wird die Busfreigabe „ENABLE-BUS-OUT (Enable Transmitter)" beim Senden von Daten durch den SLAVE auf den frühest möglichen Zeitpunkt vorverlegt (Predelay).
9.3.2.1.1 Auslegung des Predelays des Aufschaltzeitpunkts
Beim „Predelay des Aufschaltzeitpunkts (Δt4)" werden folgende Kriterien berücksichtigt:

• Vermeidung von Buskonflikten bei sequentiellen WRITE-/READ-Zyklen zu den SLAVES bei minimaler Leitungslänge (minimale Entfernung MASTER ↔ SLAVE)
• Einhaltung der zulässigen Setup-Parameter bei Übernahme (Lesen) von SLAVE-Daten durch den MASTER bei maximaler Leitungslänge (Entfernung MASTER ↔ SLAVE)

9.3.2.2 Busfreigabe beim Senden oder Empfangen von IMBUS-Daten durch SLAVES
Zum Zweck der „Steigerung von entweder Transfer-Leistung oder maximaler Leitungslänge" wird beim Senden von Daten durch die SLAVES auf das Schalten von „ENABLE-BUS-OUT (Enable Transmitter)" zwischen den einzelnen Bytes verzichtet.
Ebenso entfällt beim Empfangen von Daten durch die SLAVES das Schalten von „ENABLE-BUS-IN (Enable Receiver)" zwischen den einzelnen Bytes.
9.4 Bestimmung der kritischen Parameter wie: Zugriffszeiten und maximale Leitungslänge beim IMBUS-M
Die nachfolgenden Berechnungen erfolgen auf der Basis einer geforderten „IMBUS-M Zykluszeit" von: t(Cycle) = 300 nssowie einer „Master-Grundtakt-Periode" von: T(BCLK) = 50 ns
Zudem werden folgende den entsprechenden Datenblättern entnommenen „Worst-Case-Werte" verwendet:
t(sus) = Setup-Zeit-Slave (z.B. Dual-Port-Ram) = 20 ns (worst-case) ... 40 ns (typisch)
t(susd) = Setup-Zeit-Slave-Daten = t(sus)
t(hds) = Hold-Zeit-Slave (z.B. Dual-Port-Ram) = 0 ns
t(hdsd) = Hold-Zeit-Slave-Daten = t(hds)
t(susc) = Setup-Zeit-Slave-Command (z.B. PAL 22V10-15) = 10ns
t(hdsc) = Hold-Zeit-Slave-Command (z.B. PAL 22V10-15) = 0ns
t(sum) = Setup-Zeit-Master (z.B. EPLD-5130) = 25 ns
t(hdm) = Hold-Zeit-Master (z.B. EPLD-5130) = 0ns
t(D) = Dekoder-Delay (z.B. PAL 22V 10-15) = 15ns
t(T) = Verzögerungs-Zeit IMBUS-M Transceiver = Driver-Enable t(DE) + Receiver-Delay t(RD) = (25 ... 35 ns) + (16 ... 25) ns = 41 ns (worst-case) ... 60 ns (typisch)
9.4.1 Bestimmung der kritischen Parameter beim nicht korrigierten IMBUS-M Timing
(1) Datenverkehr MASTER → SLAVE (Write)
Für ein sicheres Erkennen der übertragenen Data- und Command-Words im SLAVE gilt für die „Slave-Data/Command-Access-Time t(sac)" folgende Bedingung: t(sac) = t(get/n) – t(sus) ≥ 0 t(sac) = 150 – (20 ... 40) = 110 ns (worst-case) ... 130 ns (typisch)
mit:
t(get/n) = 150 ns (IMBUS-M Parameter bei nicht korrigiertem Timing)
Ergebnis: Bedingung erfüllt (Parameter ist unabhängig von der Leitungslänge)
(2) Datenverkehr SLAVE → MASTER (Real)
Für ein sicheres Erkennen der ausgelesenen SLAVE-Daten im MASTER gilt für die „Master-Access-Time t(mac)" folgende Bedingung: t(mac) = t(get/n) – 2·[t(T) + t(L)] – t(D) – t(sum) ≥ 0
Für eine Verzögerungs-Zeit auf der Leitung t(L) = 0 ergibt sich: t(mac) = t(get/n) – 2·t(T) – t(D) – t(sum) = 150 – 2·(41 ... 60) – 15 – 25 = 150 – (122 ... 160) = –10 ns (worst case) ... + 28 ns (typisch)
mit:
t(get/n) = 150 ns (IMBUS-M Parameter bei nicht korrigiertem Timing)
t(L) = Verzögerungs-Zeit auf der Leitung
Ergebnis:
Im „Worst-Case-Fall, d.h. t(T/max) = 60 ns, reicht die verbleibende „Master-Access-Time t(mac) = – 10 ns" selbst ohne zusätzliche Leitungsverzögerung, d.h. t(L) = 0 ns, nicht aus, um ein sicheres Erkennen der ausgelesenen Slave-Daten im MASTER zu gewährleisten.
Folgerung:
Zum Betreiben einer IMBUS-M Datenstrecke bei einer „Cycle-Time = 300 ns" ist daher eine Korrektur des IMBUS-M Timings zwingend erforderlich.
(3) Bestimmung der „Bus-Idle-Zeiten" bei nicht korrigiertem IMBUS-M Timing

• Zur Vermeidung von „Bus-Konflikten" gilt für die „Idle-Zeit WRITE/READ t(iwr)" folgende Bedingung: t(iwr) = t(idle/n) + 2·t(L) + t(T) + t(D) ≥ 0Für eine Verzögerungs-Zeit auf der Leitung t(L) = 0 ergibt sich: t(iwr) = t(idle/n) + t(T) + t(D) = 100 + (41 ... 60) + 15 = 156 ns (worst-case) ... 175 ns (typisch) Folgerung: t(L)↑ ⇒ t(iwr)↑ mit: t(idle/n) = 100 ns (IMBUS-M Parameter bei nicht korrigiertem Timing) Ergebnis: Bedingung erfüllt, da mit t(L)↑ ⇒ t(iwr)↑
• Zur Vermeidung von „Bus-Konflikten" gilt für die „Idle-Zeit READ/WRITE t(irw)" folgende Bedingung: t(irw) = t(idle/n) – 2·t(L) – t(T) – t(D) ≥ 0Für eine Verzögerungs-Zeit auf der Leitung t(L) = 0 ergibt sich: t(irw) = t(idle/n) – t(T) – t(D) = 100 – (41 ... 60) – 15 = 25 ns (worst-case) ... 44 ns (typisch) Folgerung: t(L)↑ ⇒ t(irw)↓ mit: t(idle/n) = 100 ns (IMBUS-M Parameter bei nicht korrigiertem Timing) Ergebnis: Bedingung bis zum Grenzwert: L(max) erfüllt, da mit t(L)↑ ⇒ t(irw)↓ Der Vergleich der beiden kritischen Zeiten beim IMBUS-M Datenverkehr: – Idle-Zeit READ/WRITE t(irw/min) = 25 ns – Master-Access-Time t(mac/min) = –10 ns zeigt zudem, daß die „Master-Access-Time t(mac)" der kritischere Parameter ist.

9.4.2 Bestimmung der kritischen Parameter bei korrigiertem IMBUS-M Timing
(1) Datenverkehr MASTER → SLAVE (Write)

• Für ein sicheres Erkennen der übertragenen Data-Words im SLAVE gilt für die „Slave-Data-Access-Time t(sacd)" folgende Bedingung: t(sacd) = t(dget/k) – t(susd) ≥ 0 t(sacd) = 100 – (20 ... 40) = 60 ns (worst-case) ... 80 ns (typisch)mit: t(dget/k) = t(get/n) – Δt1 = 150 – 50 = 100 nst(get/n) = 150 ns (IMBUS-M Parameter bei nicht korrigiertem Timing) Δ t1 = 50 ns (Predelay der Synchronisier-Signale im MASTER) Ergegbbnis: Bedingung erfüllt (Parameter ist unabhängig von der Leitungslänge)
• Für ein sicheres Erkennen der übertragenen Command-Words im SLAVE gilt für die „Slave-Command-Access-Time t(sacc)" folgende Bedingung: t(sacc) = t(cget/k) – t(susc) ≥ 0 t(sacc) = 50 – 10 = 40 nsmit: t(dget/k) = t(get/n) – Δt1 – Δt2 = 150 – 50 – 50 = 50 nst(get/n) = 150 ns (IMBUS-M Parameter bei nicht korrigiertem Timing) Δt2 = 50 ns (Busfreigabe-Verzögerung beim Senden des Command-Words) Ergebnis: Bedingung erfüllt (Parameter ist unabhängig von der Leitungslänge)

(2) Datenverkehr SLAVE → MASTER (Read)
Für ein sicheres Erkennen der ausgelesenen SLAVE-Daten im MASTER gilt für die „Master-Access-Time t(mac)" folgende Bedingung: t(mac) = t(sput/k) – 2·[t(T) + t(L)] – t(D) – t(sum) ≥ 0für eine Verzögerungs-Zeit auf der Leitung t(L) = 0 ergibt sich: t(mac) = t(sput/k) – 2·t(T) – t(D) – t(sum) = 300 – 2·(41 ... 60) – 15 – 25 = 140 ns (worst-case) ... 178 ns (typisch)mit: t(sput/k) = t(sput/n) + Δt3 + Δt4 = 200 + 50 + 50 = 300 nst(sput/n) = 200 ns (IMBUS-M Parameter bei nicht korrigierem Timing)
Δt3 = 50 ns (Datenübernahme-Verzögerung beim Lesen der Daten-Worte)
Δt4 = 50 ns (Predelay des Aufschaltzeitpunkts beim Senden der Daten-Worte)
Ergebnis: Bedingung bis zum Grenzwert: L(max) erfüllt
(3) Bestimmung der „maximalen Leitungslänge"
Die „max Leitungslänge L(max)" bei Berücksichtigung einer „minimal zulässigen Master-Access-Time t(mac) = 0" errechnet sich: t(mac) = t(sput/k) – 2·[t(T) + t(L)]- t(D) – t(sum) = 0 t(L) = [t(sput/k) – 2·t(T) – t(D) – t(sum)]:2 = [300 – 2·(41 ... 60) – 15 – 25]:2 = 70 ns (worst-case) ... 89 ns (typisch)bei einer spezifischen IMBUS-M Leitungsverzögerung von: Δt(L) = 6 ns/mergibt sich eine maximale Leitungslänge L(max) von: L(max) = t(L/worst-case):Δt(L) = 70:6 = 11,7 m
(4) Bestimmung der „Bus-Idle-Zeiten" bei korrigiertem IMBUS-M Timing

• Zur Vermeidung von „Bus-Konflikten" gilt für die „Idle-Zeit WRITE/READ t(iwr)" folgende Bedingung: t(iwr) = t(iwr/min) + 2·t(L) + t(T) + t(D) ≥ 0Für eine Verzögerungs-Zeit auf der Leitung t(L) = 0 ergibt sich: t(iwr) = t(iwr/min) + t(T) + t(D) = 0 + (41 ... 60) + 15 = 56 ... 75 ns Folgerung: t(L)↑ ⇒ t(iwr)↑mit: t(iwr/min) = t(idle/n) – Δt1 – Δt4 = 100 – 50 – 50 = 0 nst(idle/n) = 100 ns (IMBUS-M Parameter bei nicht korrigiertem Timing) Δt1 = 50 ns (Predelay der Synchronisier-Signale im Master) Δt4 = 50 ns (Predelay des Aufschaltzeitpunkts beim Senden der Daten-Worte) Ergebnis: Bedingung erfüllt, da mit t(L)↑ ⇒ t(iwr)↑
• Zur Vermeidung von „Bus-Konflikten" gilt für die „Idle-Zeit READ/WRITE t(irw)" folgende Bedingung: t(irw) = t(irw/max) – 2·t(L) – t(T) – t(D) ≥ 0Für eine Verzögerungs-Zeit auf der Leitung t(L) = 0 ergibt sich: t(irw) = t(irw/max) – t(T) – t(D) = 200 – (41 ... 60) – 15 = 125 ... 144 ns Folgerung: t(L)↑ ⇒ t(irw)↓ mit: t(irw/max) = t(idle/n) + Δt1 + Δt2 = 100 + 50 + 50 = 200 nsΔt1 = 50 ns (Predelay der Synchronisier-Signale im Master) Δt2 = 50 ns (Busfreigabe-Verzögerung beim Senden des Command-Words) Eregebnis: Bedingung bis zum Grenzwert: L(max) erfüllt, da mit t(L)↑ ⇒ t(irw)↓
• Bestimmung der „maximalen Leitungslänge" Die „max Leitungslänge L(max)" unter Berücksichtigung einer „minimal zulässigen Idle-Zeit READ/WRITE t(irw) = 0" errechnet sich: t(irw) = t(irw/max) – 2·t(L) – t(T) – t(D) = 0 t(L) = [t(irw/max) – t(T) – t(D)]:2 = [200 – (41 .. 60) – 15]:2 = 62 ns (worst-case) ... 72 ns (typisch)bei einer spezifischen IMBUS-M Leitungsverzögerung von: Δ t(L) = 6 ns/mergibt sich eine maximale Leitungslänge L(max) von: L(max) = t(L/worst-case) : Δt(L) = 62:6 = 10,3 mErlebnis: Der Vergleich der beiden Alternativen zur Berechnung der „max Leitungslänge L(max)" bei korrigiertem IMBUS-M Timing: – unter Berücksichtigung einer „minimal zulässigen Master-Access-Time t(max) = 0" – unter Berücksichtigung einer „minimal zulässigen Idle-Zeit READ/WRITE t(irw) = 0" zeigt, daß letztere Alternative der kritischere Fall ist, der zur Ermittlung der „max Leitungslänge L(max)" anzuwenden ist.

Liste 1: „Text-Design-File" des IMBUS-M Busmasters „IMBCTR.TDF"

Claims

Verfahren zur Steigerung von entweder Transfer-Leistung oder maximaler Leitungslänge beim Bussystem IMBUS-M, das zum Zweck des Datenaustauschs im Lenk-Flugkörper-System KEPD vorgesehen ist und folgende Basisfunktionen aufweist: – Ausführung als synchroner, byteserieller Bus – Informationstransfer in Form von (8 Bit) Bytes – Transfer von Control-Byte, Adress-Bytes und Daten-Bytes im Zeitmultiplex-Verfahren – Zentraler „BUSMASTER" zur Steuerung der Bustransfers und der Systemsynchronisation – Übertragung/Abfrage eines Alarm-Vektors mittels eines speziellen Alarm-Transfers – Systemsynchronisation MASTER → SLAVES mittels Synchronisations-Transfers – Anschluß von max. 16 Busteilnehmern (SLAVES), verteilt über die gesamte Leitungslänge – Minimal erreichbare Zykluszeit entsprechend erforderlicher maximaler Leitungslänge – Differentielle Datenübertragung entsprechend „EIA 422/485" – Der IMBUS-M setzt sich zusammen aus: – 8 differentiellen Daten-Leitungen – 2 differentiellen Takt-Leitungen – 1 Masse-Leitung gekennzeichnet durch folgende Merkmale: Die Synchronisier-Signale „SLAVE-IMBUS-CLK" und „SLAVE-IMBUS-SYNC", die via IMBUS-M zu den SLAVES übertragen werden, werden zur Korrektur/Kompensation von Schalt- und Laufzeiten gegenüber den Synchronisier-Signalen „MASTER-IMBUS-CLK" und „MASTER-IMBUS-SYNC", die im MASTER verwendet werden, um eine geeignete Zeitspanne vorverschoben. (Predelay). Bei der Auslegung dieses „Signal-Predelays" werden dabei folgende Kriterien berücksichtigt: – Gleiches Predelay für „SLAVE-IMBUS-CLK" und „SLAVE-IMBUS-SYNC" – Zeitquantisierung entsprechend dem geradzahligen Vielfachen (1, 2 usw.) der Master-Grundtakt-Periode – Einhaltung der zulässigen Setup-Parameter beim Erkennen von Control-Byte, Adress-Bytes und Daten-Bytes durch die SLAVES
Verfahren nach Anspruch 1, gekennzeichnet durch folgende Merkmale: Der Zeitpunkt der Datenübernahme mit „DATA-FETCH-IMBUS-CLK" beim Lesen vom IMBUS-M wird gegenüber dem internen Takt des Masters „MASTER-IMBUS-CLK", der das IMBUS-Protokoll steuert um eine geeignete Zeitspanne verzögert (Postdelay). Bei Auslegung der „Datenübernahme-Verzögerung" werden folgende Kriterien berücksichtigt: – Unverändertes Timing zwischen MASTER-IMBUS-CLK und MASTER-IMBUS-SYNC – Zeitquantisierung entsprechend dem geradzahligen Vielfachen (1, 2 usw.) der Master-Grundtakt-Periode – Einhaltung der zulässigen Setup-Parameter bei Übernahme (Lesen) von SLAVE-Daten durch den MASTER bei maximaler Leitungslänge (Entfernung MASTER ↔ SLAVE)
Verfahren nach Anspruch 1 oder 2, gekennzeichnet durch folgende Merkmale: Der Zeitpunkt der Busfreigabe (Bus-Enable) beim Senden des „Control-Bytes" durch den MASTER wird um eine geeignete Zeispanne verzögert (Postdelay). Bei Auslegung der „Busfreigabe-Verzögerung" werden dabei folgende Kriterien berücksichtigt: – Zeitquantisierung entsprechend dem geradzahligen Vielfachen (1, 2 usw.) der Master-Grundtakt-Periode – Einhaltung der zulässigen Setup-Parameter bei Übernahme/Dekodierung des Control-Bytes in den SLAVES – Vermeidung von Buskonflikten beim Lesen von SLAVE-Daten bei maximaler Leitungslänge (maximale Entfernung MASTER ↔ SLAVE)
Verfahren nach einem der Anspruch 1 bis 3, gekennzeichnet durch folgende Merkmale: Die Busfreigabe (Bus-Enable) beim Senden von Daten durch die SLAVES wird auf den frühest möglichen Zeitpunkt vorverlegt (Predelay). Bei Auslegung des „Aufschaltzeitpunkts" werden dabei folgende Kriterien berücksichtigt: – Vermeidung von Buskonflikten bei sequentiellen Schreib-/Lese-Zyklen zu den SLAVES bei minimaler Leitungslänge (minimale Entfernung MASTER ↔ SLAVE) – Einhaltung der zulässigen Setup-Parameter bei Übernahme (Lesen) von SLAVE-Daten durch den MASTER bei maximaler Leitungslänge (Entfernung MASTER ↔ SLAVE)
Verfahren nach einem der Anspruch 1 bis 4, gekennzeichnet durch folgende Merkmale: – Beim sequentiellen Senden von Daten durch MASTER oder SLAVES (Control, Adressen, Daten) wird auf das Schalten von Transmit-Enable zwischen den einzelnen Bytes verzichtet (⇒ Permanent-Transmit). – Ebenso entfällt beim Empfangen von Daten durch MASTER oder SLAVES das Schalten von Receive-Enable zwischen den einzelnen Bytes (⇒ Permanent-Receive).