# Data-Routing Funktionsbeschreibung # ************************************** *(Multiplexer für 16-Bit Dateneingabe)* März 1995 K. Huber, Strahlenzentrum Univ. Gießen Version 08.Jul.2003 1 Einleitung ************ Zur Datenerfassung und Experimentsteuerung existieren zwei verschiedene Rechner-Interfaces, das *Data-Routing* und das *Control-Routing*, so genannt nach den Aufgaben, zu denen sie im Wesentlichen eingesetzt werden: * Zur schnellen Erfassung von großen Datenmengen wird vorzugsweise das *Data-Routing* verwendet. Es ermöglicht eine schnelle Dateneingabe von bis zu 8 Eingabekanälen. Eine Datenausgabe ist damit nicht möglich. * Das *Control-Routing* hingegen wird hauptsächlich zur Steuerung des Experimentes eingesetzt. Es erlaubt die Ein- und Ausgabe von einzelnen Datenworten, wobei bis zu 8 Module mit je 8 Registern, also maximal 64 Register, adressierbar sind. Ferner ist eine Interrupt-Eingabe vorgesehen. Die vorliegende Funktionsbeschreibung befasst sich ausschließlich mit dem *Data-Routing*. Es wird im folgenden oft abgekürzt als *Routing* bezeichnet. Für das *Control-Routing* existiert eine eigene Beschreibung. Das Kapitel *Aufbau und Funktion* gibt einen Überblick über den Aufbau das Data-Routing. Das Kapitel *Standardkomponenten* enthält die Aufgabenbeschreibungen und Bedienungsanleitungen der Standardkarten des Routing. Das Kapitel *Standard-Interface-Karten* enthält die Aufgabenbeschreibungen und Bedienungsanleitungen der Routing-Karten, die allgemein bei Experimenten zum Einsatz kommen. Das Kapitel *Spezielle Interface-Karten* enthält eine Aufstellung der Routing-Karten, die für einzelne Experimente entwickelt wurden. Ihre Beschreibung findet man i.a. in den Unterlagen der Experimente, bei denen sie eingesetzt werden. Das Kapitel *Technische Details* gibt technische Detail-Informationen über die Komponenten und deren Schnittstellen. Im Kapitel *Oldies* sind überholte Beschreibungen gesammelt. 2 Aufbau und Funktion ********************* 2.1 Aufbau des Routing ====================== *Abb. 2.1.0.1 Dateneingabe mit dem Data-Routing-System* ----------------- | Rechner | | (PDP11-23) | |...............| | DMA-Interface | | (DRQ11-CA) | ----------------- | ...................................|................................ | Standard-Karten -------------------- im Routing-Einschub | Rechneranpassung | -------------------- | | -------------------- | Routing-Steuerung| | (Scanner) | -------------------- | | | | | | | | 8 Eingabekanaele / / ----------/------------ | Interface-Steuerung | ----------------------- | ...................................|................................ Spezielle Karten | im Routing-Einschub --------------------- | Quellen-Interface | --------------------- | ...................................|................................ Experiment | ------------------- | Daten-Quelle(n) | ------------------- + *Rechner* Das Data-Routing kann an jeden Rechner mit geeignetem I/O-Port angeschlossen werden. Realisiert wurden bisher Anschlüsse an TR86-Rechner, PDP11-Rechner und VME-Systeme. Zur Zeit ist das Data-Interface auf einem IP-Board (Industrie Pack) implementiert, so dass es an jeden Rechner angeschlossen werden kann, für den ein IP-Board-Carrier existiert (VME, PC usw.). + *Data-Routing* Das Data-Routing ist in einem 19"-Überrahmen mit 20 Steckplätzen für Europakarten untergebracht. + *Rechneranpassung* Diese Karte fügt den 16 Bit Eingabedaten Quellenkennungs- und Status-Bits hinzu, damit die Software Herkunft und Status der Eingaben unterscheiden kann und speichert sie in einem 2048 Worte tiefen und 3 Byte breiten Fifo zwischen. Ferner wickelt sie das Protokoll für die Übertragung der Daten über ein 50-poliges Kabel zum Rechner ab. + *Routing-Steuerung* Diese Karte koordiniert die Dateneingabe der 8 Eingabekanäle des Routing mittels zweier 16-fach Scanner mit zwei verschiedenen Prioritäten. Jedem Eingabekanal sind zwei Scanner-Schritte zugeordnet, wovon bei Einsatz der Standard-Interface-Steuerung einer zur Eingabe der Lifetime und der andere zur Eingabe der Daten verwendet wird. Die Wahl der Priorität bleibt der Datenquelle überlassen, zur Anpassung der Dateneingabe an die experimentellen Anforderungen. Die Beschränkung auf max. 8 Eingabekanäle in einem Routing wird relativiert durch die Möglichkeit über einen Kanal mehrere Datenquellen zu bedienen. + *Interface-Steuerungen* Zur Erleichterung des Anschlusses von Datenquellen wurde ein standardisiertes Interface entwickelt, das wenn möglich eingesetzt werden sollte. Zum Anschluss der Datenquellen ist dann zwar noch ein spezielles Quellen-Interface notwendig, dessen Aufbau im allgemeinen jedoch trivial ist. + *Quellen-Interfaces* Die Quellen-Interfaces setzen die vom Experiment kommenden Signale in digitale Daten um, die vom Routing übertragen werden können. Es gibt hier eine Reihe standardisierter Karten wie Zähler, Uhr, ADCs, ADC-Interfaces usw. und viele spezielle Entwicklungen, angepasst an die Anforderungen von Experimenten. So gibt es z.B. eine Karte, die unter zeitkritischen Bedingungen einen ganzen Satz von Messdaten aufnimmt und in einem FIFO zwischenspeichert, bis sie vom Routing übertragen werden. + *Datenquellen am Experiment* Die Datenquellen sind, abgesehen von Lifetime-Messung und ähnlichen 'Hilfsquellen', beim Experiment angesiedelt. Bei der Planung eines Experimentes sollte man sich möglichst an vorhandenen Quellen-Interfaces orientieren. Dies reduziert den Entwicklungsaufwand und ermöglicht im Falle eines Defektes den Austausch von Karten. 2.2 Überrahmen ============== Das Data-Routing ist in einem 19"-Überrahmen untergebracht mit 20 Steckplätzen für Europakarten (Abb. 2.2.0.1). Es wird der gleiche Überrahmen wie für das Control-Routing verwendet. In Ausnahmefällen können Data-Routing und Control-Routing im gleichen Überrahmen untergebracht werden, wenn die Bus-Verdrahtung in der Mitte durchtrennt wird und für die zweite Hälfte ein Bus-Abschluss nachgerüstet wird. Die Routing Back-Plane enthält 42 allgemeine Bus-Leitungen für die Routing-Steuerung und 11 Privat-Bus-Leitungen zur Kommunikation benachbarter Karten. Außer der Spannungsversorgung sind alle Schaltungskomponenten auf steckbaren Karten untergebracht. Als Steckverbindung zum Routing-Bus werden 64-polige VG-Stecker verwendet. Die Anschlüsse der VG-Leisten sind im Überrahmen zum Teil als durchgehender Bus verdrahtet (allg. Bus: 1a,1c,...,21c) und zu einem anderen Teil bestehen Verbindungen zu benachbarten Steckerleisten (Privat-Bus: 22a/c,...,32a/c) (*Note Routing-Bus::.). Ferner ist für jede Leiste von links beginnend eine Steckplatzkodierung von 0-7 verdrahtet, wobei jedoch jeweils zwei benachbarte Leisten die gleiche Kodierung haben. Die vier überbleibenden Steckplätze am rechten Ende erhalten alle die Kodierung 7. Sie sind vorzugsweise für die Rechner-Anpassung und Routing-Steuerung zu benutzen, da der Bus-Abschluss sich am linken Ende des Überrahmens befindet. Am äußersten rechten Ende ist die Netzkarte mit Netzschalter und Betriebsspannungsanzeigen fest installiert. Die Frontplattenbreite für eine Steckkarte ist üblicherweise 20 mm, es stehen jedoch auch 40 und 50 mm Frontplatten zur Verfügung. *Achtung:* Es wird dringend empfohlen, die Frontplatten der Steckkarten mit dem Überrahmen zu verschrauben zur Vermeidung von Betriebsstörungen. Bitte die Schrauben nicht gewaltsam anziehen, da dies zur Zerstörung der Gewinde im Überrahmen führt. Schrauben von min. 10mm Länge verwenden, sonst besteht ebenfalls die Gefahr der Zerstörung der Gewinde. *Abb. 2.2.0.1 Routing-Überrahmen* Steckplatz 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | | | | | | | | | | | | | | | | | |RS|RA|SV| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 0 0 1 1 2 2 3 3 4 4 5 5 6 6 7 7 7 7 7 7 Steckplatzkodierung RS = Routingsteuerung RA = Rechneranpassung SV = Spannungsversorgung 3 Standardkomponenten ********************* 3.1 Routing-Steuerung (RST) =========================== 3.1.1 Aufgabe ------------- Die Routing-Steuerung koordiniert die Eingabe der Daten von den bis zu acht anschließbaren Eingabekanälen. Ein Eingabekanal besteht aus den drei funktionellen Gruppen: * Interface-Steuerung * Datenquellen-Interface * Datenquellen *Note Aufbau des Routing::. *Note Komponenten und Schnittstellen::. Die Routing-Steuerung ist mit zwei alternativ laufenden Scannern unterschiedlicher Priorität ausgestattet, mit denen die Eingabekanäle abgefragt werden. Dadurch besteht die Möglichkeit, einen oder mehrere Eingabekanäle mit Vorrang vor den anderen abfragen zu lassen. Dazu müssen diese Eingabekanäle einen Vorrangwunsch bei der Routing-Steuerung anmelden, sobald sie bereit sind ein Datenwort zu übertragen. Der jeweils ruhende Scanner behält seine Position bei, so dass er an der unterbrochenen Stelle weiterlaufen kann. Um verkürzte Scanner-Umläufe zu ermöglichen, sind die Scanner-Adressen in vier Gruppen zusammengefasst, die in Einer-, Zweier- oder Vierer-Kombinationen durch einen Jumper aktiviert werden können. Die Scanner-Adressen werden stets in einer Reihenfolge durchlaufen in der sich höchstens 2 Bits gleichzeitig ändern, um Störungen auf dem Routing-Bus zu minimieren (*Note Routing-Steuerung::.). Es ist zu beachten, dass die verschiedenen Eingabekanäle von der Routing-Steuerung nicht nach einem 'first in - first out' Verfahren bearbeitet werden, sondern durch einen Scanner reihum abgefragt werden. Dies kann zur Folge haben, dass die einzelnen Eingabekanäle nicht in der Reihenfolge zum Rechner übertragen werden, in der sie zur Übertragung bereit waren. Die damit zusammenhängenden Probleme der Verkoppelung von Datenquellen z.B. bei Koinzidenzexperimenten sind jedoch berücksichtigt (*Note Kopplungskarte (KPL)::.). Ein Stop der Routing-Steuerung kann vom Rechner her erfolgen oder über einen Schalter auf der Frontplatte. Beide bewirken ein Anhalten der Daten-Scanner. Ferner wird der Stop den Eingabekanälen mitgeteilt und über die Interface-Steuerung den Datenquellen. Die Routing-Steuerung arbeitet eng mit der Rechneranpassungs-Karte zusammen und steckt deshalb direkt links neben ihr. 3.1.2 Bedienungselemente, Anzeigen ---------------------------------- *Schalter: Run/Stop* In Stellung _Stop_ wird die Abfrage der Eingabekanäle angehalten durch Stoppen des Daten-Scanners. An die Eingabekanäle geht ein Stopsignal. Der Schalter ist disjunktiv (ODER) verknüpft mit dem Stop vom Rechner. *Anzeige: Run* Wenn weder vom Rechner noch durch den Schalter _Run/Stop_ ein Stop erfolgt, d.h. die Routing-Steuerung läuft, so leuchtet die Anzeige _Run_. *Anzeige: Ready* Solange die Routing-Steuerung das Data Ready (_ReadyB_) eines Eingabekanals bearbeitet, leuchtet die Anzeige _Ready_. *Anzeige: Vorrang* Solange die Routing-Steuerung im Vorrangmodus arbeitet, leuchtet die Anzeige _Vorrang_. *Jumper: Group 0 1 2 3* Selektion von Scanner-Gruppen 0 1 2 3. Erlaubte Kombinationen von Gruppen sind 0, 1, 2, 3, 0-1, 0-2, 1-3, 2-3, 0-1-3-2. Bei unzulässigen Kombinationen, und falls kein Jumper gesetzt ist, wird 0-1-3-2 ausgeführt. 3.2 Rechneranpassung (RAP) ========================== 3.2.1 Aufgabe ------------- Die Rechneranpassungs-Karte hat die Aufgabe aus den Daten- und Kennungsbits auf dem Bus ein Datenwort zusammenzustellen, es in Fifos zwischenzuspeichern und dann an den Rechner zu übertragen. Darüberhinaus enthält die Rechneranpassungs-Karte Sender, Empfänger und eventuell Pegelwandler für die Dialog-Signale zwischen dem Rechner und dem Routing. Die Verbindung zum Rechner erfolgt über ein max. 40m langes 50-poliges Flachbandkabel. Kurze Kabellängen sind zu bevorzugen da die Länge in die Übertragungsgeschwindigkeit eingeht und kürzere Kabel störungssicherer sind. Für Testzwecke am Routing kann das 50-polige Verbindungskabel zum Rechner abgezogen werden. Die Rechneranpassung nimmt dann dem Routing die Daten mit höchstmöglicher Geschwindigkeit ab (und wirft sie weg). Bisher wurden drei Anpassungen an verschiedene Host-Rechner realisiert: * VME - Industry Pack - Anpassung * PDP11 - DRQ11-CA - Anpassung * TR86 - CALAS - Anpassung Aktuell ist die VME - Anpassung, die zusammen mit dem rechnerseitigen Interface eine Schnittstelle zu dem Industry Pack Standard darstellt. Für diesen IP-Standard werden Carrier-Boards für eine Anzahl weiterer Plattformen (z.B. PC) angeboten, so dass ein Anschluss des Data-Routing an einen anderen Rechnertyp ohne großen Aufwand möglich ist. Die TR86- und PDP11-Anpassungen wurden inzwischen ausgemustert. Ihre Beschreibung finden Sie bei den 'Oldies'. Die sogn. Silena-Änderung wurde in die aktuelle VME-Rechneranpassung nicht mit übernommen, sondern es wird vorausgesetzt, dass eine entsprechende Änderung auf *allen* Silena-Interface-Karten vorgenommen ist. Die Rechneranpassungs-Karte arbeitet sehr eng mit der Routing-Steuerung zusammen und steckt deshalb direkt rechts neben ihr. 3.2.2 Bedienungselemente, Anzeigen ---------------------------------- Die Rechneranpassungskarte besitzt keine Bedienungselemente. Auf dem Board (von außen nicht sichtbar) befindet sich eine grüne LED zum Anzeigen einer aktiven Verbindung mit dem Rechner und eine rote LED zum Anzeigen eines Fifo-Errors. 3.3 Interface-Steuerung (IFS) ============================= 3.3.1 Aufgabe ------------- Die Interface-Steuerung stellt eine standardisierte Karte zwischen der Routing-Steuerung und den Datenquellen dar. Im Zusammenspiel mit der Routing-Steuerung wickelt sie die Routing-Logik ab und bietet den Datenquellen eine bequeme Schnittstelle, die den Anschluss von Datenquellen wesentlich erleichtert. Ferner ist sie zur Lifetime-Messung, zur Eingabe von Daten im Vorrangmodus und zur Eingabe von gekoppelten Daten (Koinzidenz-Experimente) vorbereitet. Zum Anschluss von Datenquellen sind, je nach Komplexität der Aufgabe, noch ein oder mehrere Quellen-Interface-Karten notwendig, die im einfachsten Falle nur Pegelwandler und Bus-Leitungstreiber enthalten. Zur Verständigung mit den Quellen-Interface-Karten baut die IFS-Karte nach rechts einen Privat-Bus (IFS-Bus) auf. Die Quellen-Interface-Karten müssen deshalb stets rechts von der IFS-Karte stecken. Die Frontplatten der so miteinander kommunizierenden Karten müssen fest mit dem Überrahmen verschraubt sein, um eine gute Masseverbindung von den Karten zur Frontplatte herzustellen. Fehlt die Verschraubung so kann dies zu schwerwiegenden Betriebsstörungen führen, weil die Karten wie die Kondensatorplatten eines gedämpften Oszillators gegeneinander schwingen. Es existieren zwei Varianten (IFS und IFS1) der Interface-Steuerung, die sich in ihren Funktionen nicht wesentlich unterscheiden. Bei der älteren (IFS) sind die Konfigurationsbrücken als Lötbrücken (statt Steckbrücken) ausgeführt und unbeschriftet und auf der Frontplatte fehlt die Anzeige für den Vorrangbetriebsmodus. 3.3.2 Bedienungselemente, Anzeigen ---------------------------------- *Stop/Run/LFT* (Schalter) Schalter für den Betriebsmodus. + *Stop:* Stop Datenübertragung Die angeschlossene Quelle wird nicht abgefragt. Sie erhält außerdem ein Stop-Signal für Normierungszwecke. + *Run:* Normalbetrieb der Datenquellen Die Lifetime-Messung ist abgeschaltet. + *LFT:* Betrieb mit Lifetime-Messung Intern wird ein Lifetime-Signal (_LFTQ_) generiert, das sich konjunktiv (UND) zusammensetzt aus der negierten Busy-Meldung (_BusyQ\_) der Datenquelle, je nach Verdrahtung auf der IFS-Karte dem Eingang _GateQ_ der IFS-Karte und im Kopplungsmodus _K2_ der Lifetime-Meldung _LFTK_ der Kopplung (*Note Kopplungskarte (KPL)::.): _LFTQ = BusyQ\ * GateQ(Option) * (K2 * LFTK\)\_ Die Option wird eingeschaltet durch Stecken der Brücke LFT\= By+G statt By. Immer, wenn dieses Signal _LFTQ_ ansteht wird der interne Lifetime-Zähler mit 1MHz Takt hochgezählt. Sobald auf diese Weise 1s bzw. 0.1s (Brücke: 1s/0.1s) Lifetime zusammengekommen sind, wird ein Datenwort übertragen, das zur Unterscheidung neben der normalen Quellenkennung noch das Lifetime-Bit (*Note Rechneranpassung::.) gesetzt hat. Alle Daten-Bits sind null. Diese Funktion der IFS-Karte erlaubt totzeitkorrigierte Messungen. Da die Totzeitsignale intern mit einem 1MHz-Takt abgefragt werden, kann es zu Fehlmessungen der Lifetime kommen, wenn die Totzeitsignale phasensynchron mit dem internen 1MHz-Takt und in der Größenordnung der Taktperiode sind. Für völlig vom internen Takt unabhängige Totzeitsignale sollten hingegen vom Schaltungsentwurf her auch kürzere als 1us richtig verarbeitet werden, auf einer statistischen Basis, in dem sie mal einen Takt durchlassen und mal nicht (hab' dies aber bis jetzt noch nicht überprüft!). *Achtung:* Aus Kostengründen sind nicht alle IFS-Karten mit den für die LFT-Messung notwendigen Bausteinen (SAJ141) bestückt. *Frei/K1/K2* (Schalter) Sollen mehrere Datenquellen gekoppelt übertragen werden (z.B. bei Koinzidenz-Experimenten), so wird über diesen Schalter entschieden in welcher Weise die zugehörige Datenquelle an der Kopplung teilnimmt. Detailierte Information ist der Beschreibung der Kopplungskarte zu entnehmen (*Note Kopplungskarte (KPL)::.). + *Frei:* keine Kopplung Die Datenquelle läuft frei, sie nimmt nicht an der Kopplung teil. + *K1:* lose Kopplung Die Datenquelle läuft frei, sie wird durch das von der Kopplungskarte angelieferte Kopplungssignal (_KoppK_) nicht auf- und zugegatet. Meldet die Datenquelle 'busy' während das Kopplungssignal ansteht, so wird in dem zugehörigen Datenwort bei der Übertragung das Kopplungs-Bit (*Note Rechneranpassung::.) gesetzt. Die Software kann dadurch unterscheiden, ob die Quelle koinzident mit anderen Quellen ein Ereignis registriert hat. + *K2:* strenge Kopplung Die Datenquelle wird nur aufgegatet, wenn das Kopplungssignal ansteht. Im übertragenen Wort ist immer das Kopplungs-Bit gesetzt. *GateQ:* (TTL-Eingang) Über diesen Eingang kann die Datenquelle auf- und zugegatet werden. Bei Betrieb im Modus _K2_ erfolgt eine Verknüpfung mit dem Signal _GateK_ und dem Kopplungssignal (siehe _GateK_). High oder offener Eingang: Gate offen *GateK:* (TTL-Eingang) Über diesen Eingang kann, um spezielle Zeitbedingungen zu realisieren, das Kopplungssignal (siehe Modus _K1, K2_) extern zugeführt werden. Es wird mit dem internen Kopplungssignal (_KoppK_), das von der Kopplungskarte geliefert wird, konjunktiv (UND) verknüpft. Für den Kopplungsmodus _K2_ wird das Ergebnis noch mit dem Eingang _GateQ_ konjunktiv verknüpft und als Gate-Signal (_GateSQ_) an die Datenquelle übergeben. High oder offener Eingang: Gate offen _GateSQ= GateQ * (K2\ + K2 * KoppK * GateK)_ *Out:* (TTL-Ausgang) Je nach Konfiguration der IFS-Karte (Steckbrücke: Gate/By) kann über diesen Ausgang das Busy-Signal der Datenquelle oder das Gate-Signal für die Datenquelle beobachtet werden. High: Quelle Busy/Gate offen *Run* bzw. *R/S:* (LED-Anzeige) Run/Stop-Anzeige LED leuchtet: IFS-Karte läuft *B* bzw. *By:* (LED-Anzeige) Busy Anzeige LED leuchtet: Datenquelle meldet Busy *VR:* (LED-Anzeige; nur IFS1) Vorranganzeige LED leuchtet: Die Datenquelle arbeitet im Vorrangmodus *4 2 1:* (LED-Anzeige) Anzeige der Steckplatzadresse. Zur Unterscheidung der verschiedenen Datenquellen wird dem Datenwort die Steckplatzadresse als Quellenkennung mitgegeben. Da im allgemeinen beim Start eines Messprogrammes die Quellenkennung angegeben werden muss, wird die Steckplatzadresse von der IFS-Karte angezeigt. LED leuchtet: Bit der angegenbenen Wertigkeit ist gesetzt. *1s / 0.1s:* (Jumper) Zeitbasis für die Übertragung des Lifetime-Datenwortes (s.o.). *Out = Gate / Busy:* (Jumper) Beschaltung der 'Out' BNC-Buchse mit Gate- oder Busy-Signal (s.o.). *LFT = Busy / Busy & Gate:* (Jumper) Option für die Lifetime-Messung (s.o.). 3.4 Kopplungskarte (KPL) ======================== 3.4.1 Aufgabe ------------- Bei manchen Experimenten (z.B. Koinzidenzexperimente) werden zu einem Ereignis mehrere Datenworte erzeugt, die nach ihrer Übertragung für die Software als zusammengehörig erkenntlich sein müssen. Diesem Zweck dient die Kopplungskarte. 3.4.2 Funktion -------------- Die Kopplungskarte arbeitet wie eine normale Datenquelle, d.h. sie benötigt eine Standard-Interface-Steuerung (IFS-Karte). Der Schalter _Frei/K1/K2_ auf der IFS-Karte wird dabei außer Betrieb gesetzt, so dass die Kopplungskarte im Modus _"Frei"_ läuft. Die Kopplungskarte ist Ausgangspunkt für einen Privat-Bus, den Kopplungs-Bus, der sich nach links fortsetzt bis entweder ein Steckplatz frei ist, eine weitere Kopplungskarte auftritt, oder aber eine Karte steckt, die den Kopplungs-Bus unterbricht. Die Kopplung wird gestartet über den BNC-Eingang Start auf der Kopplungskarte. Nach erfolgtem Start geht die Kopplung sofort in den Zustand Busy (_BusyK_). Das Busy steht solange an wie irgendeine der gekoppelten Quellen Busy (_BusyQi_) an die Kopplung meldet. Die Übertragung des Kopplungswortes trägt ihr Busy (_BusyQK_) wie eine normale Quelle bei. Zur Überbrückung der Reaktionszeiten der verschiedenen gekoppelten Quellen geht die Kopplung mit dem Start in eine interne Wartephase (_Wait_) einstellbarer Dauer. Diese Wartephase trägt ebenfalls zum Busy der Kopplung bei: _BusyK = Wait + BusyQK + Sum(i,BusyQi)_ Eine eindeutige Zusammenfassung der gekoppelten Daten ist nur gewährleistet, wenn _BusyK_ lückenlos ansteht bis alle Quellen ihre Daten registriert und abgeliefert haben. Durch geeignete Einstellung der Wartephase sollte dies immer möglich sein. Das Signal _Wait_ steht den gekoppelten Quellen über den Kopplungs-Bus unter dem Namen Kopplungssignal (_KoppK_) zu Synchronisationszwecken (Aufgaten der Quellen) zur Verfügung (*Note Interface-Steuerung (IFS)::.). Je nach eingestelltem Start-Modus unterliegt der Start der Kopplung unterschiedlichen Bedingungen: * Im Normalmodus erfolgt der Start nur, wenn keine der am Kopplungs-Bus hängenden Quellen oder die Kopplungskarte selbst Busy meldet, d.h. wenn _BusyK_=O. * Im weniger strengen Spezialmodus kann ein Start immer erfolgen, wenn der vorhergehende Kopplungszyklus beendet ist. Ein Kopplungszyklus beginnt mit dem Start und endet sobald keine Busy-Meldungen mehr anstehen. Spätere Busy-Meldungen verhindern im Gegensatz zum Normalmodus einen erneuten Start nicht. Der Spezialmodus ist für Fälle gedacht, in denen die Datenquellen bereits Busy melden bevor der Kopplungsstart erfolgt. Nach erfolgtem Start meldet die Kopplungskarte einen vorrangigen Bearbeitungswunsch bei der Routing-Steuerung an zur Übertragung eines Datenwortes, dem Kopplungswort. Durch entsprechendes Timing auf den IFS-Karten ist sichergestellt, dass das Kopplungswort auf jeden Fall vor den Datenwörtern der gekoppelten Quellen übertragen wird. Diese folgen in beliebiger Reihenfolge je nach Bearbeitungszeit in den Quellen und Stand des Routing-Scanners. Nicht alle Datenquellen müssen notwendigerweise Daten übertragen, sondern nur die, die ein Ereignis erkannt haben. Die Synchronisierung der Software erfolgt durch das Kopplungswort am Anfang eines Blockes von gekoppelten Daten. Solange sich die Kopplung im Zustand 'Busy' befindet, werden alle abgewiesenen Startversuche im 'Pile-up-Zähler' registriert. Mit jeder Datenübertragung wird im Kopplungswort der Zählerstand übertragen und gleichzeitig gelöscht. Falls mehr als 255 Pile-ups auftreten, bleibt der Zähler bei 255 stehen. Das Kopplungswort ist wie ein normales Datenwort aufgebaut. Das Kopplungs-Bit ist null. In den Daten-Bits 0-7 steht der Inhalt des Pile-up-Zählers. Für jede am Kopplungs-Bus angeschlossene Datenquelle kann der Kopplungsmodus individuell gewählt werden über den Schalter _Frei/K1/K2_ auf der IFS-Karte. Im Modus _Frei_ nimmt die Quelle an der Kopplung nicht teil, sie läuft frei. Das von der Kopplung gelieferte Kopplungssignal (_KoppK_) wird nicht berücksichtigt und das Busy der Quelle wird nicht an die Kopplung gemeldet. Im Modus _K1_ läuft die Quelle im wesentlichen frei. Falls jedoch der Beginn der Busy-Meldung der Quelle in das von der Kopplungskarte vorgegebene Kopplungssignal fällt, wird in der Kennung des Datenwortes das Kopplungs-Bit gesetzt. Auf diese Weise können z.B. koinzidente und nicht koinzidente Ereignisse mit dem gleichen ADC aufgenommen werden. Für Ereignisse, die das Setzen des Kopplungs-Bits zur Folge haben, wird das Busy der Quelle an die Kopplung gemeldet. Dies verhindert einen weiteren Start der Kopplung bevor die Quelle mit ihrer Bearbeitung völlig fertig ist und garantiert, dass Datenworte verschiedener Koinzidenzereignisse sauber getrennt werden. Für höhere Zählraten ist der Modus _K1_ nicht gut geeignet, da mit wachsender Zählrate die Wahrscheinlichkeit zunimmt, dass eine der gekoppelten Quellen noch durch ein nicht koinzidentes Ereignis busy ist. Der Start der Kopplung würde in diesem Falle zwar erfolgen, aber das Datenwort der betreffenden Quelle würde bei der Koinzidenz fehlen. Im Modus _K2_ können die Quellen nur während der Dauer des Kopplungssignals Ereignisse registrieren. Das Kopplungs-Bit ist immer gesetzt, Busy wird stets an die Kopplung gemeldet. Es werden also nur koinzidente Ereignisse registriert. Ein nicht-koinzidenter Untergrund belastet das System nicht durch Totzeit. Es ist zu beachten, dass durch die unterschiedliche Wirkungsweise des Kopplungssignals in den Modi _K1_ und _K2_ sich für das Kopplungssignal ein unterschiedliches Timing ergibt. Der Unterschied besteht darin, dass im Modus _K1_ das Busy der Quelle während des Kopplungssignals zum Setzen des Kopplungs-Bits führt und im Modus _K2_ die Quelle vom Kopplungssignal aufgegated wird, was offensichtlich dem Busy zeitlich vorausgehen muss. 3.4.3 Bedienungselemente ------------------------ *Start:* (TTL-Eingang) Durch die positive Flanke eines Signals an diesem Eingang wird die Kopplung gestartet, falls sie nicht gerade busy ist. *Int/Ext:* (Schalter) In Stellung *Int* wird die Dauer der Wartephase intern erzeugt. Sie ist durch ein Potentiometer auf der Frontplatte im Bereich von etwa 1-100 us einstellbar. In Stellung *Ext* wird die Dauer der Wartephase durch das Startsignal vorgegeben (high: Wartephase). *Out:* (TTL-Ausgang) Über diesen Ausgang kann das Signal _Wait_ der Wartephase abgenommen werden. *norm./spez.:* (Steckbrücke auf der Karte) Über diese Steckbrücke auf der Kopplungskarte kann der Startmodus (normal bzw. spezial) eingestellt werden. *Abb. 3.4.3.1 Timing von gekoppelten Datequellen* (Kein Textformat-Bild vorhanden, siehe: html, pdf, dvi) 3.5 Test-Datenquelle (TST) ========================== 3.5.1 Aufgabe ------------- Die Testdatenquelle erzeugt 16-Bit Datenworte zu Testzwecken. Wahlweise liefert sie mit jedem Scannerzyklus ein Datenwort ab, die Daten werden also mit der maximal möglichen Geschwindigkeit übertragen, oder die Übertragung wird durch einen externen Takt gesteuert. 3.5.2 Bedienungselemente ------------------------ *set/count/reset:* (Schalter) + *set:* Alle 16 Datenbits sind gesetzt. + *count:* Nach jeder Übertragung wird das Datenregister inkrementiert bzw. dekrementiert. Bei Überlauf wird mit 0 bzw. 65535 fortgesetzt. + *reset:* Alle 16 Datenbits sind gelöscht. *ext/int:* (Schalter) + *ext:* Die Übertragung eines Datenwortes wird durch einen externen Takt angestoßen. + *int:* Mit jedem Routing-Zyklus wird ein Datenwort übertragen. *prio/norm:* (Schalter) + *prio:* Die Übertragung erfolgt im Vorrang-Modus (*Note Routing-Steuerung (RST)::.). + *norm:* Die Übertragung erfolgt im Normalmodus. *inc/alt/dec:* (Schalter) + *inc:* Im Modus 'Count' wird nach jeder Übertragung das Datenregister inkrementiert. + *alt:* Im Modus 'Count' wird nach jeder Übertragung das Datenregister alternierend inkrementiert/dekrementiert. + *dec:* Im Modus 'Count' wird nach jeder Übertragung das Datenregister dekrementiert. *Ext-Takt:* (BNC-Buchse, TTL-Eingang) Takteingang zum externen Anstoßen einer Übertragung (positive Flanke). 3.6 Bus-Signal Anzeige (BUS) ============================ Die Anzeigekarte übernimmt vom Routing-Bus die Daten- und Kontroll-Bits und zeigt sie über LED's auf der Frontplatte an. Anzeige: DO ...D15 Daten-Bits frei frei frei frei Kopp-Bit Kopplungs-Bit LFT-Bit Lifetime-Bit 3.7 Routing-Funktionsüberwachung (Alarm) ======================================== Es werden die beiden Scanner-Takte _TV_ und _TN_ der Routing-Steuerung (*Note Routing-Steuerung::.) überwacht, und falls sie länger als ca. 0.5s ausbleiben, ohne dass das Routing gestoppt ist, wird Alarm gegeben. Der Alarm wird beim nächsten Scanner-Schritt wieder aufgehoben. *Anzeige* (rote LED): leuchtet bei Alarm *BNC-Ausgänge* für High- und Low-Signale bei Alarm (2.5kOhm nach +5V; 330Ohm nach 0V) 3.8 Totzeitanzeige ================== Diese Karte bildet ein zeitliches Mittel über ein digitales Totzeitsignal (TTL-Pegel) und zeigt die Totzeit auf einem Drehspulinstrument mit 100er-Skala an. Die Karte erwartet das Totzeitsignal auf der P-Bus-Leitung 28a von ihrer direkten linken Nachbarkarte. Diese muss deshalb auf 28c ein entsprechendes Signal verdrahtet haben. Für die üblichen Interface-Karten ist 28a-28c gebrückt, so dass das Signal _BusyQ_ als Totzeitsignal zur Verfügung steht. 4 Standard-Interface-Karten *************************** 4.1 16-Bit-Digitaleingabe (Laben-ADC-Interface) =============================================== 4.1.1 Aufgabe, Funktion ----------------------- Die Digitaleingabe bietet eine universelle Schnittstelle zur Eingabe von 16 Daten-Bits. Sie ist so ausgelegt, dass Laben ADC's direkt angeschlossen werden können. Die Verbindung zur Datenquelle wird durch einen 37-poligen ERNI-Stecker hergestellt. Die Kabellänge sollte 1.5 m nicht überschreiten. Alle von der Datenquelle kommenden Leitungen sind mit 1 kOhm Pull-up-Widerständen versehen. Die Leitungen zur Datenquelle können mit max. 15 mA bei high Pegel und 24 mA bei low belastet werden. *Achtung:* Dieses Interface wurde früher auch zum Anschluss von Silena-ADCs verwendet. Durch einen Timer auf der alten Rechneranpassung war dafür gesorgt, dass _AcceptedB_ mindestens 1us lang ist. Diese Verlängerung (Silena-Änderung) war notwendig, da der Silena-ADC eine (im Manual nicht spezifizierte) Zeit von ca. 0.5us für ein Reset benötigt. Diese Silena-Änderung wurde in die VME-Rechneranpassung nicht mit übernommen, deshalb ist dieses Interface nicht mehr zum Anschluss von Silena-ADCs geeignet. Bitte das spezielle Silena-ADC-Interface verwenden. 4.1.2 Signalbeschreibung ------------------------ Mit *Stop* wird die Datenquelle gestoppt und gecleart. Mit *Ready* zeigt die Datenquelle an, dass sie bereit ist ein Datenwort zu übergeben. Mit *Request* wird die Datenquelle aufgefordert ihre Daten auf die Datenleitungen zu geben. Prinzipiell können die Daten immer an den Datenleitungen anstehen. Falls jedoch Pegeländerungen auf vielen Datenleitungen gleichzeitig auftreten, führt dies unweigerlich zu Störungsspitzen auf den Steuerleitungen, die zu Fehlfunktionen führen können (z.B. verfrühte Anmeldung von *Ready*). Mit *Accepted* zeigt die Digitaleingabe an, dass die Daten übernommen wurden. Je nach Auslastung des Rechners kann das *Accepted* u.U. recht lange auf sich warten lassen. Normalerweise löscht die Datenquelle mit *Accepted* das anstehende *Ready*, notwendig ist dies jedoch nicht, falls beim nächsten Routing-Zyklus sofort ein weiteres Datenwort übertragen werden soll. Mit *Busy* zeigt die Datenquelle an, dass sie beschäftigt ist mit der Erzeugung eines Datenwortes. *Busy* kann je nach Quelle mit der Vorder- oder Rückflanke von *Accepted* oder sonst wann verschwinden. Es wird bei einer eventuellen Totzeitmessung verarbeitet (*Note Interface-Steuerung (IFS)::.). Da je Datenleitung ein Strom von ca. 5 mA fließt, ist für eine Masseleitung von ausreichendem Querschnitt zu sorgen für die Rückführung der 16 * 5 mA = 80 mA. *Tab. 4.1.2.1 Schnittstelle zur Datenquelle* 37 poliger ERNI-Stecker Die nicht aufgeführten Anschlüsse sind unbelegt. Signale, die mit '^' beginnen, werden von der Digitaleingabe erzeugt. *Signal* *ERNI-Pin* Daten-Bit 0\ 19 Daten-Bit 1\ 18 Daten-Bit 2\ 17 Daten-Bit 3\ 16 Daten-Bit 4\ 15 Daten-Bit 5\ 14 Daten-Bit 6\ 13 Daten-Bit 7\ 12 Daten-Bit 8\ 11 Daten-Bit 9\ 10 Daten-Bit 10\ 9 Daten-Bit 11\ 8 Daten-Bit 12\ 7 Daten-Bit 13\ 6 Daten-Bit 14\ 5 Daten-Bit 15\ 4 Ready\ 3 ^Request 20 ^Accepted 23 ^Stop\ 22 Busy\ 2 ^Gate 1 Masse *Abb. 4.1.2.2 Timing zwischen Digital-Eingabe und Datenquelle* (Kein Textformat-Bild vorhanden, siehe: html, pdf, dvi) 4.2 Silena-ADC-Interface ======================== 4.2.1 Aufgabe, Funktion ----------------------- Das Silena-ADC-Interface ist eine modifizierte 16-Bit-Digitaleingabe. Es berücksitigt die spezielle Steckerbelegung des Silena-ADCs, so dass die Kabelverbindung mit einem 37-poligen Flachbandkabel hergestellt werden kann. Ferner berücksichtigt es den Umstand, dass der Silena-ADC ein unterschiedlich langes (bis zu 500ns, nicht im Manual spezifiziert) Accepted-Signal benötigt. Selbstverständlich kann diese Interface-Karte auch als universelle Schnittstelle zur Eingabe von 16 Daten-Bits verwendet werden. Die Verbindung zur Datenquelle wird durch einen 37-poligen ERNI-Stecker hergestellt. Die Kabellänge sollte 1.5 m nicht überschreiten. Alle von der Datenquelle kommenden Leitungen sind mit 1 kOhm Pull-up-Widerständen versehen. Die Leitungen zur Datenquelle können mit max. 15 mA bei high Pegel und 24 mA bei low belastet werden. 4.2.2 Signalbeschreibung ------------------------ Mit *Stop* wird der ADC gestoppt und gecleart. Mit *Ready* zeigt der ADC an, dass er bereit ist ein Datenwort zu übergeben. *Request* ist nicht verdrahtet, der Silena-ADC gibt deshalb seine Daten immer auf die Datenleitungen. Mit *Accepted* zeigt das Interface an, dass die Daten übernommen wurden. *Accepted* steht so lange an bis das *Ready*-Signal verschwindet. Dieses Verhalten von *Accepted* ist notwendig, da der Silena-ADC ein im Manual nicht spezifiziertes, unterschiedlich langes (bis 500ns) *Accepted* benötig. Mit *Busy* zeigt der ADC an, dass er beschäftigt ist mit der Erzeugung eines Datenwortes. Es wird bei einer eventuellen Totzeitmessung verarbeitet (*Note Interface-Steuerung (IFS)::.). Da je Datenleitung ein Strom von ca. 5 mA fließt, ist für eine Masseleitung von ausreichendem Querschnitt zu sorgen für die Rückführung der 16 * 5 mA = 80 mA. *Tab. 4.2.2.1 Schnittstelle zum Silena ADC* 37 poliger ERNI-Stecker Die nicht aufgeführten Anschlüsse sind unbelegt. Signale, die mit '^' beginnen, werden vom Interface erzeugt. *Signal* *ERNI-Pin* Daten-Bit 0\ 1 Daten-Bit 1\ 2 Daten-Bit 2\ 3 Daten-Bit 3\ 4 Daten-Bit 4\ 5 Daten-Bit 5\ 6 Daten-Bit 6\ 7 Daten-Bit 7\ 8 Daten-Bit 8\ 9 Daten-Bit 9\ 10 Daten-Bit 10\ 11 Daten-Bit 11\ 12 Daten-Bit 12\ 13 Daten-Bit 13\ 18 Daten-Bit 14\ 37 Daten-Bit 15\ 19 Ready\ 21 ^Request nicht verdrahtet ^Accepted 22 ^Stop\ 20 Busy\ 15 ^Gate 35 Masse 36 *Abb. 4.2.2.2 Timing zwischen Interface und ADC* (Kein Textformat-Bild vorhanden, siehe: html, pdf, dvi) 4.3 Uhr/Zähler (UHR) ==================== 4.3.1 Aufgabe ------------- Die Uhrkarte enthält eine 16 Bit Relativzeituhr, deren Zeitregister während des Betriebes (on flight) abgefragt werden kann. Sie kann mit einem internen quarzstabilisierten Takt von 10 MHz oder extern mit bis zu 4 MHz betrieben werden. Der externe Betrieb ist gleichbedeutend mit einem Betrieb als Zähler. Beim Betrieb als Uhr besteht die Möglichkeit parallel zur eigentlichen Messungen eine zeitabhängige Totzeitmessung laufen zu lassen, um eine nachträgliche rechnerische Totzeitkorrektur zu ermöglichen. Bei Kopplung der Uhr mit anderen Datenquellen kann die gemeinsame Totzeit der gekoppelten Quellen gemessen werden. 4.3.2 Bedienungselemente ------------------------ *Int/Ext:* (Schalter) In Stellung _Int_ wird die Uhr mit einem internen quarzstabilisierten 10 MHz Takt betrieben. In Stellung _Ext_ kann die Uhr mit einem externen Takt bis maximal 4 MHz betrieben werden. *Takt:* (TTL-Eingang) Über diesen Eingang kann der Uhr ein externer Takt bis zu 4 MHz zugeführt werden. Dieser wird auf den internen 10 MHz Takt aufsynchronisiert. Die positive Flanke taktet die Uhr. Sie wird durch die Synchronisation innerhalb 100 ns unscharf. Taktbreite und -pause müssen mindestens 125 ns betragen. *Reset:* (TTL-Eingang) Über diesen Eingang kann die Uhr auf Null gesetzt werden. High oder offener Eingang: _Reset_ min. Pulsbreite: 200 ns *Uhr:* (TTL-Eingang) Über diesen Eingang erfolgt die Abfrage der Uhr. Die positive Flanke des Abfragesignals veranlasst die Übernahme des Inhaltes des Uhrregisters in ein Pufferregister, wo es bis zur Übertragung zum Rechner gespeichert wird. Die Abfrage kann asynchron zum Takt erfolgen. Das Abfragesignal wird auf den internen 10 MHz Takt aufsynchronisiert. Von der Abfrage bis zur Übertragung des Datenwortes geht die Uhrkarte in den Zustand _Busy_ und ist für weitere Abfragen gesperrt. Dieser Eingang ist gatebar über die Eingänge _GateQ_ und _GateK_ auf der IFS-Karte. *LFT:* (TTL-Eingang) Über diesen Eingang kann zeitabhängig die 'Lifetime' der Uhrkarte und eventuell gekoppelter Datenquellen gemessen werden. Er hat im wesentlichen die gleiche Wirkung wie eine Abfrage über den Eingang _Uhr_ mit folgenden Unterschieden: Die _Gate_-Signale wirken nicht auf diesen Eingang (änderbar). Das Datenwort hat zur Unterscheidung zusätzlich das _Lifetime-Bit_ gesetzt. Die Abfrage ist gesperrt, wenn die IFS-Karte keine Lifetime (_LFTQ_) meldet. Es wird zur Lifetime-Messung die gleiche Lifetime (_LFTQ_) verwendet wie auf der IFS-Karte. Diese Lifetime enthält konjunktiv die negierte Totzeit der Uhrkarte, das Signal _GateQ_ der IFS-Karte (Option), und im Kopplungsmodus _K2_ die Lifetime-Meldung der Kopplung _LFTQ = BusyQ\ * GateQ(Option) * (K2\ + LFTK)_ *Achtung:* Wird als externer Takt und zur Abfrage der Uhr (_Uhr_ bzw. _LFT_) das gleiche Signal verwendet, so wird durch die Aufsynchronisierung der externen Signale auf den internen 10 MHz Takt mal der eine oder der andere Eingang früher sein. Soll ein Eingang mit Sicherheit vor dem anderen Eingang zum Zuge kommen, so müssen sie mindestens als Abstand die Taktbreite (100 ns) plus interne Laufzeitunterschiede (<50 ns) d.h. ca. 150 ns haben. Die gleiche Zeitdifferenz ist einzuhalten zwischen einer Abfrage der Uhr und einem nachfolgenden _Reset_-Signal, um mit Sicherheit ein Auslesen vor dem Löschen zu erreichen. 4.3.3 Beispiel: Lebensdauermessung mit Totzeitkorrektur ------------------------------------------------------- Über den Eingang _Uhr_ wird der Zeitpunkt des Auftretens der beobachteten Ereignisse zum Rechner übertragen. Die Software erzeugt daraus ein Zeitspektrum, in dem sie die Zeit als Kanaladresse interpretiert und wie im MCA-Mode im betreffenden Kanal ein 'addiere 1' ausführt. Über den Eingang _LFT_ wird ein fester Takt nicht zu hoher Frequenz (damit nicht zu hohe zusätzliche Totzeit entsteht) eingegeben. Auf die gleiche Weise wie oben wird ein LFT-Spektrum erzeugt, aus dem für jeden Zeitpunkt die zugehörige Lifetime der Messung entnommen werden kann. 4.4 Up/Down-Zähler (U/D-ZLR) ============================ 4.4.1 Aufgabe ------------- Diese Zählerkarte besitzt ein 16 Bit breites Zählerregister d.h. es kann 65535 Ereignisse registrieren. Bei Überlauf in Vorwärtsrichtung springt es auf 0 und in Rückwärtsrichtung auf 65535. Der Überlauf wird nicht angezeigt, es ist deshalb ggf. das Vorschalten eines Untersetzers zu empfehlen zur Vermeidung von Überläufen. Durch eine einfache Umverdrahtung sind jedoch auch (gekennzeichnete) Varianten entstanden, die bei Überlauf anhalten. Die Auflösungsgrenze für die Zählimpulse liegt bei ca. 200ns, d.h. 5 MHz max. Zählerfrequenz. Sollen geringere Zählimpulsabstände verarbeitet werden, bei statistisch ankommenden Signalen kann dies bereits bei geringeren Zählraten der Fall sein, so ist ein Untersetzer vorzuschalten (z.B. mit den Bausteinen 74196 (50MHz) oder 74S196 (100MHz)). Der Zählerstand kann asynchron zum Zählvorgang, d.h. ohne das Zählen zu beeinflussen, abgefragt werden. Sowohl der Zählereingang (_Count_) als auch der Eingang für das Auslesesignal (_Read_) können jeweils über Gate-Signale gesteuert werden. Alle Eingänge sind bis ca. 10V Dauerpegel gegen Überspannung geschützt und im Frequenzgang auf ca. 10 MHz begrenzt. 4.4.2 Funktion -------------- Alle Eingangssignale werden vollständig auf verschiedene Phasen des internen 10 MHz-Taktes aufsynchronisiert, so dass der Karte die Eingangssignale völlig asynchron angeboten werden können, ohne Fehlfunktionen befürchten zu müssen. Aus diesem Aufsynchronisieren resultiert die Begrenzung der Zählfrequenz auf max. 5 MHz. Mit dem _Read_-Signal wird der Inhalt des Zählregisters in ein Zwischenregister kopiert, wo er bis zur Übertragung zum Rechner gespeichert wird. Bis zum Abschluss der Übertragung befindet sich die Karte im Zustand _Busy_ und weist weitere _Read_-Signale ab, d.h. der Inhalt des Zwischenregisters bleibt vom Zählvorgang unbeeinflusst. Das Zählen selber kann während des Übertragungsvorgangs völlig ungestört weitergeführt werden. Das aus dem _Read_-Vorgang resultierende _Busy_-Signal steht, bei entsprechender Verdrahtung (*Note Interface-Steuerung (IFS)::.), auf der IFS-Karte an der Buchse _Out_ zur Verfügung. Die Lifetime-Messung auf der IFS-Karte basiert ebenfalls auf dem durch den _Read_-Vorgang erzeugten _Busy_ und zeigt nicht etwa die Zählverluste an. Die Totzeitverluste beim Zählen sind durch Vorschalten von Untersetzern leicht in vernachlässigbare Bereiche zu zwingen (*Note Totzeitbetrachtungen::.). 4.4.3 Eingänge (BNC-Buchsen) ---------------------------- *Count:* Zähleingang pos. flankengetriggert; ca. 5 MHz max. *Gate:* Gate-Eingang für Count High-Pegel: Gate offen *Read:* Übertragen des Zählerinhaltes zum Rechner pos. flankengetriggert; gatebar über den GateQ-Eingang auf der IFS-Karte *Reset:* Rücksetzen (auf 0) des Zählers High-Pegel: Reset (offener Eingang = High-Pegel!) *U/D\:* Steuerung für Vorwärts/Rückwärts-Zählen High-Pegel: Vorwärtszählen *Unbeschaltete Eingänge liegen auf High-Pegel!* Für alle Eingänge sind in Abhängigkeit von der Impulshöhe folgende minimalen Impulsbreiten erforderlich: Pulshöhe min. Pulsbreite 5 V 25 ns 2.5 V 50 ns Falls die Signale _Read_ und _Count_ bzw. _Read_ und _Reset_ gleichzeitig (_Read_ bis ca. 50ns später) eintreffen, so wird zuerst die _Read_-Funktion ausgeführt. Soll _Read_ nach der konkurrierenden Funktion ausgeführt werden, so muss es mindestens ca. 150ns nach dieser eintreffen. Liegt _Read_ ca. 50 bis 150ns nach _Count_ bzw. _Reset_, so ist die Reihenfolge unbestimmt. Das _Gate_-Signal muss mindestens 20ns vor dem _Count_-Signal anstehen, damit das Zählen freigegeben wird. Bei einer Änderung des _U/D_-Signals im Zeitraum von 0 bis 100ns nach dem _Count_-Signal ist die Zählrichtung unbestimmt. Die angegebenen Zeitwerte sind gültig für eine Bestückung mit 74LS-Bausteinen. Sie stellen Richtwerte dar, die aufgrund von Exemplarstreuungen variieren können. In kritischen Fällen wird empfohlen, respektvollen Abstand (ca. 20ns) von den oben angegebenen Werten zu halten. 4.5 12-Bit ADC (AD574) ====================== 4.5.1 Aufgabe ------------- Diese Routing-Karte verwendet den AD583 Sample-and-Hold-Baustein und den AD574 12-Bit-ADC-Baustein von Analog Devices zur Digitalisierung von analogen Signalen. Der ADC arbeitet nach dem Verfahren der "Sukzessiven Approximation": Konvertierungszeit : 15us - 35us max. Abtastrate : 26kHz max. Linear.-Fehler: 1/4 LSB Der Linearitätsfehler hat sich durch Alterung inzwischen deutlich verschlechtert! Durch zwei Schalter auf der Frontplatte (Uni/Bi, 10V/20V) können folgende Messbereiche gewählt werden: 10V 20V Uni: 0V - +10V 0V - +20V Bi : -5V - +5V -10V - +10V 4.5.2 Bedienungselemente ------------------------ *P1:* (Poti) Offset-Abgleich für Bipolar-Modus des AD574 ADC-Bausteins *P2:* (Poti) Full-Scale-Abgleich für Bipolar-Modus des AD574 ADC-Bausteins *P3:* (Poti) Offset-Abgleich für Unipolar-Modus des AD574 ADC-Bausteins *P4:* (Poti) Offset-Abgleich des AD583 Sample-and-Hold-Bausteins *Uni/Bi:* (Schalter) Einstellung von uni- oder bipolarem Modus *10V/20V:* (Schalter) Messbereichseinstellung 10V oder 20V *Analog:* (Analog-Eingang) Eingang für das zu messende Analog-Signal *Gate:* (TTL-Eingang) Gate-Eingang für das Sample-Signal High-Pegel: Gate offen (offener Eingang = High-Pegel) *Sample:* (TTL-Eingang) Eingang für das Trigger-Signal. Eine positive Flanke startet eine Konvertierung. 4.6 Zählerbatterie (ZLRS, ZLRx) =============================== 4.6.1 Aufgabe ------------- Die Zählerbatterie benötigt wie jede andere Datenquelle eine IFS-Karte (*Note Interface-Steuerung (IFS)::.) direkt links neben der Zählersteuerung (*ZLRS*). Rechts anschließend sind die Zählerkarten (*ZLRx*) zu stecken bis zu einer maximalen Anzahl von 255 einzelnen Zählern. Jeder Zähler kann im allgemeinen nur ein Ereignis speichern und verwirft dann alle folgenden Ereignisse bis das gespeicherte Ereignis zum Rechner übertragen wurde. Die Zählersteuerung fragt reihum alle Zähler ab und sobald sie auf ein gespeichertes Ereignis stößt, überträgt sie die Nummer des Zählers zum Rechner und löscht den Speicher. Mit der Standard-Software zur Aufnahme von Spektren wird jedem Zähler ein Kanal im Spektrum zugeordnet. Die Nummerierung der Zähler beginnt bei der ersten Karte rechts von der Zählersteuerung und setzt sich auf den jeweils folgenden Zählerkarten fort. Im allgemeinen sind acht Zähler auf einer Karte untergebracht, wobei jedoch möglicherweise nicht alle von extern zugänglich sind (z.B. nur 4), weil die restlichen die Totzeitverluste ihrer Nachbarn registrieren. Die Abfrage der Zähler erfolgt mit 5MHz. Ein voller Zyklus, in dem alle Zähler einmal abgefragt werden, dauert daher N * 200ns, falls keine Daten übertragen werden, wobei N die Anzahl der angeschlossenen Zähler ist. Werden Daten übertragen, so verlängert sich die Zeit. Die maximale Rate aller Zähler zusammen ist begrenzt durch die Übertragungskapazität der Verbindung zum Rechner. Bei zu hohen Zählraten ist zur Vermeidung von Totzeitverlusten die Vorschaltung eines Untersetzers zu empfehlen (z.B. 1/10) (*Note Vorgeschaltete Untersetzer::.). 4.6.2 Funktion -------------- Die Zählerbatterie besteht aus einer Zählersteuerung (*ZLRS*) und mehreren Zählerkarten (*ZLRx*) mit jeweils mehreren Zählern. Die Zählersteuerung fragt reihum alle Zähler mittels eines Abfrage-Bits (Select-Bit) ab (5MHz). Jede Zählerkarte enthält ein Schieberegister mit seriellem Eingang und parallelen Ausgängen, je einer für jeden Zähler, durch das dieses Abfrage-Bit geschoben wird. Ein Zähler ist selektiert, wenn das Bit auf dem ihm zugeordneten Ausgang erscheint. Falls er dann ein Ereignis gespeichert hat, meldet er über den PrivatBus ein '_Ready_' zur Zählersteuerung. Diese überträgt daraufhin (_ReadyQ_) die in einem 8-Bit-Register mitgezählte Nummer des selektierten Zählers an den Rechner. Mit der Quittung auf die Übertragung (_AcceptedQ_) wird der selektierte Zähler gelöscht und die Abfrage fortgesetzt. Der Abfragezyklus passt sich der Anzahl der vorhandenen Zähler an. Zu diesem Zweck übergibt jede Zählerkarte eine Anfangs- (_AM_) und Endemeldung (_EM_) an die Zählersteuerung. Erscheint mit dem folgenden Takt nach einer _EM_ keine _AM_, so bedeutet dies für die Zählersteuerung, dass die nächstfolgende Karte fehlt. Sie setzt daraufhin den Nummernzähler (8-Bit-Register) auf Null, löscht die Schieberegister aller Zählerkarten und generiert ein neues 'Select-Bit'. Falls der Nummernzähler überläuft aufgrund eines Funktionsfehlers, oder weil mehr als 255 Zähler angeschlossen sind, so wird dies über eine LED auf der Frontplatte angezeigt. Ferner wird der Abfragezyklus abgebrochen und bei Zähler Null wieder begonnen. Die Fehleranzeige ist nur durch einen '_Stop_' zu löschen. Die Zählersteuerung meldet Busy (_BusyQ_) solange das einsynchronisierte _Ready_ eines Zählers oder die Quittung des Routing (_AcceptedQ_) ansteht. Solange _BusyQ_ ansteht ist der Schiebetakt gesperrt. Ein manueller oder Rechner-Stop (_StopQ_) erzeugt ein Reset-Signal (_Reset_), das die Synchronisier-FF's für die Ready-Meldung und den gerade angewählten Zähler zurücksetzt. Da der Schiebetakt weiterläuft, werden bei anstehendem _StopQ_ reihum alle Zähler immer wieder gelöscht, ohne dass dabei Daten übertragen werden. 4.6.3 Zählerkarten ------------------ 4.6.3.1 ZLR1 - Vierfachzähler mit Überlaufregistrierung (TTL-Eingänge) ...................................................................... Die Karte enthält 8 Zähler, wobei jedoch nur die Zähler 0,2,4,6 extern zugänglich sind. Die Zähler 1,3,5,7 dienen dazu, die Totzeitverluste jeweils ihrer Vorgänger zu registrieren. Auf diese Weise können Totzeitkorrekturen durchgeführt werden. Über einen '_Gate_'-Eingang können die Zähler an- und abgestellt werden. Das _Gate_-Signal beeinflusst nicht bereits gespeicherte Ereignisse. Der _Gate_-Eingang ist konjunktiv (UND) verknüpft mit dem _Gate_-Signal von der IFS-Karte, d.h. beide Signale müssen auf High-Potential liegen, wenn die Zähler arbeiten sollen. Offene Anschlüsse liegen auf high. Über eine LED wird angezeigt, wenn einer der Zähler ein Ereignis an das Routing überträgt. *Bedienungselemente, Anzeigen* *0, 2, 4, 6:* (BNC-Buchsen, TTL-Eingänge) Eingänge für die vier Zähler 0,2,4,6. Gezählt werden die Low-High-Übergänge. Falls der geradzahlige Zähler bereits ein Ereignis speichert, wird der nächstfolgende ungeradzahlige Zähler gesetzt. Ist auch dieser belegt, so geht das Ereignis verloren. *Anzeige:* (LED) Die LED leuchtet immer, wenn einer der 8 Zähler ein Ereignis an den Rechner überträgt. 4.7 Messung der Breiten- und Abstandsverteilung von Signalen (BAV) ================================================================== 4.7.1 Aufgabe, Funktion ----------------------- Die BAV-Karte misst mit Hilfe der Uhr-/Zähler-Karte (s.h 4.2) die Breite eines TTL-Signals oder den Abstand von zwei aufeinander folgenden TTL-Signalen. Die zeitliche Auflösung der Messung ist die der Uhr-Karte, bei internem Takt also 100ns. Die maximal messbaren Breiten bzw. Abstände sind durch ein Poti auf der Frontplatte im Bereich von ca. 50us bis 2ms einstellbar. Nach Ablauf des Zeitlimits wird die Karte zurückgesetzt und kann nach ca. 100ns das nächste Signal verarbeiten, um eine neue Messung zu beginnen. Werden die von der Uhr-Karte übertragenen Messdaten mit einem Vielkanal-Programm (z.B. MCA) erfasst, so erhält man als 'Spektrum' die zeitliche Verteilung von Breite oder Abstand. Die BAV-Karte muss direkt rechts neben der Uhr-Karte stecken und erhält von dieser über die P-Bus-Leitung 28a das _BusyQ_-Signal. Solange die Uhr-Karte busy meldet, werden von der BAV-Karte keine Eingangssignale verarbeitet. *Breitenverteilung* Es wird der zeitliche Abstand zwischen ansteigender und abfallender Flanke des Eingangssignals gemessen. Bei nicht zu hoher Signalrate kann jedes Signal gemessen werden. *Abstandsverteilung* Es wird der zeitliche Abstand zwischen den ansteigenden Flanken zweier aufeinander folgender Eingangssignale gemessen. Daher kann bestenfalls nur jeder zweite Abstand gemessen werden. 4.7.2 Bedienungselemente ------------------------ *Breite/Abstand:* (Schalter) Umschaltung von Breite- auf Abstands-Messung *Limit:* (10-Gang-Poti) Einstellung des Zeitlimits (50us - 2ms) für die einzelne Messung *Reset:* (BNC-Ausgang) Ansteuerung des Reset-Eingangs der Uhr-Karte *Uhr:* (BNC-Ausgang) Ansteuerung des Uhr-Eingangs der Uhr-Karte *Puls:* (BNC-Eingang) Eingang für das zu messende TTL-Signal 4.7.3 Beispiel -------------- Die Abstände zeitlich statistischer Signale (Poisson-Verteilung) sind exponentiell abfallend verteilt, d.h. in Log-Darstellung als abfallende Gerade: (Kein Textformat-Bild vorhanden, siehe: html, pdf, dvi) Falls solche Signale mit einer Totzeit belastet sind, ergibt sich das nächste Bild. Dabei ist vorausgestzt, dass sich die Totzeiten nicht nahtlos hintereinander hängen können (nicht paralysierend), wie dies z.B. bei einem retriggerbaren Monoflop der Fall ist: (Kein Textformat-Bild vorhanden, siehe: html, pdf, dvi) Für eine paralysierende Totzeit, bei der jedes Signal, das in die Totzeit seines Vorgängers fällt, nur die Totzeit verlängert aber selbst nicht durchkommt, könnte folgendes Bild gemessen werden: (Kein Textformat-Bild vorhanden, siehe: html, pdf, dvi) Für eine periodische Störung in statistisch verteilten Signalen können nur maximale Abstände in der Länge der Periode der Störung auftreten: (Kein Textformat-Bild vorhanden, siehe: html, pdf, dvi) 5 Spezielle Interface-Karten **************************** Diese Interface-Entwicklungen werden hier nur aufgelistet und sind in den Unterlagen für die einzelnen Experimente im Detail beschrieben. Diese Aufstellung enthält auch Oldies, in der Hoffnung, sie eines Tages wieder recyclen zu können. 5.1 Elektron-Positron-Spaltfragment-Winkelverteilungs-Experiment (K5) ===================================================================== *EPOS-Steuerung* EPOS-Messprogramm Eingabe des LB-Triggers und Generierung von Gate- und Delay-Signalen für die "in beam" und "out of beam" Messphasen. 5.2 Ion-Ion-Stoß-Experiment (Labor 016) ======================================= *LIC-Interface* IIM-, IIC-, LIC-Messprogramme Umschalter IIM-, IIC-, LIC-Messungen; Kontrolle der LIC-Positions-Laufzeit-Messung *TAKT-Karte* IIC-, IIF-, IIP-, LIC-, LIP-Messprogramme Takte zum Auslesen der Zählerkarten; Totzeitmessung *IIM-Interface* IIM-, LIC-Messprogramme Interface zum SSL-2401 Position-Computer *LII-Interface* LII-, LIP-Messprogramme FIFO-gepufferte Dateneingabe für Pulsed-Beam-Koinzidenz-Experimente; Interface zum SSL-2401 Position-Computer 5.3 Elektron-Ion-Stoß-Experiment (Labors 017, SI) ================================================= *ESS-Kontrolle* ESS-Messprogramm Totzeit-Überwachung. *ESS-Kanalnummer-Eingabe* ESS-Messprogramm Interface für parallele Eingabe der aktuellen Kanalnummer. *DRM-Interface* DRM-Messprogramm Interface zum SSL-2401 Position-Computer 6 Totzeitbetrachtungen ********************** 6.1 Poisson-Verteilung ====================== Bei den folgenden Betrachtungen wird davon ausgegangen, dass die Ereignisraten Poisson-verteilt sind. Die Poisson-Verteilung wird in der folgenden Form benutzt: Wahrscheinlichkeit P[n] für das Eintreffen von genau n Ereignissen im Zeitintervall [0,t] P[n](R,t) = (R*t)^n / n! * e^-(R*t) t: Zeit R: Ereignisrate n: 0,1,...,~ Sum[n=0,~]P[n] = e^+(R*t) * e^-(R*t) = 1 Sum[n=0,~](n*P[n]) = R*t * Sum[n=0,~]P[n] = R*t P[n+1] = R*t / (n+1) * P[n] dP[n]/dt = R * (P[n-1] - P[n]) Int(P[n])dt = -1/R * Sum[i=0,n]P[i] Int[0,~]P[n]dt = 1/R 6.2 Totzeitverluste =================== *Totzeitkorrekturrechnung für nicht-paralysierende Totzeit:* Ereignisse, die in eine Totzeit fallen, tragen selber nicht zur Totzeit bei. v = R*T Totzeitverluste v im Totzeitintervall T bei poisson-verteilter Eingangsrate R S = r*T gesamte Totzeit S pro Sekunde bei der Bedienrate r V = R*S Rate der Totzeitverluste V R = r + V = r + R*r*T Bilanz der Raten R = r / (1 - r*T) Totzeitkorrektur r = R / (1 + R*T) inverse Totzeitkorrektur Die erste Gleichung ist nur für poisson-verteilte Eingangsraten richtig. Bei periodischer Eingangsrate und R*T < 1 würden keine Totzeitverluste auftreten. Diese Gleichung ist deshalb auch direkt aus der Poisson-Verteilung herzuleiten: v = 1*P[1] + 2*P[2] + + n*P[n] + = R*T*P[0] + R*T*P[1] + + R*T*P[n-1] + = R*T *Totzeitkorrekturrechnung für paralysierende Totzeit:* Ereignisse, die in eine Totzeit fallen, verlängern die Totzeit durch das Starten eines neuen Totzeitintervalls. A = R * e^-(R*t) Abstandsverteilung der Ereignisse bei Eingangsrate R w = R * Int[T,~](e^-(R*t))dt = e^-(R*T) Wahrsch. w für Abstand größer Totzeit T r = R * e^-(R*T) gemessene Rate R = ??? Totzeitkorrektur nur numerisch lösbar *Die folgenden Betrachtungen setzen stets eine feste, nicht-paralysierende Totzeit voraus!* 6.3 Lifetime-Messung ==================== Bei unbekannter bzw. variabler Totzeit eines Datenerfassungsgerätes oder wechselnder Ereignisrate ist es i.a. nicht möglich im Nachhinein eine Totzeitkorrekturrechnung durchzuführen. Deshalb bietet das Data-Routing zwei Möglichkeiten zur direkten Messung von Totzeiten an. *Lifetime-Messung mit der IFS-Karte* *Lifetime-Messung mit der Uhr-Karte* 6.4 Kaskadierte Zähler ====================== Einige der (Eigenbau-) Datenerfassungsgeräte liefern über einen Ausgang einen Zählimpuls für jeden Totzeitverlust. Da ein nachgeschalteter Zähler jedoch ebenfalls eine Totzeit hat, gehen dort wiederum Ereignisse verloren, die man mit einem weiteren Zähler registrieren könnte usw.. Prinzipiell sollte jedoch aus den ersten beiden Raten die Originalrate berechenbar sein, falls die Totzeiten gleich sind und die Originalrate konstant ist. Die Zählrate Z[0] und die Totzeitverluste V[0] der ersten Datenerfassung mit Totzeit T[0] sind Z[0] = R/(1 + R*T[0]) V[0] = R - Z[0] = R * R*T[0]/(1 + R*T[0]) Die zweite Datenerfassung erhält die gleiche primäre Datenrate R, jedoch um die V[0]/R verkürzte Zeit Z[1] = R/(1 + R*T[1]) * V[0]/R = R/(1 + R*T[1]) * R*T[0]/(1 + R*T[0]) V[1] = V[0] - Z[1] = R * R*T[0]/(1 + R*T[0]) * R*T[1]/(1 + R*T[1]) usw... Z[n] = R/(1 + R*T[n]) * V[n-1]/R = 1/T[n] * Prod[i=0,n](R*T[i]/(1 + R*T[i])) = Z[n-1] * T[n-1]/T[n] * R*T[n]/(1 + R*T[n]) V[n] = V[n-1] - Z[n] = R - Sum[i=0,n]Z[i] = R * Prod[i=0,n](R*T[i]/(1 + R*T[i])) = V[n-1] * R*T[n]/(1 + R*T[n]) V[n]/Z[n] = R*T[n] V[n]/R = Prod[i=0,n](R*T[i]/(1 + R*T[i])) V[~] = 0 -> R = Sum[i=0,~]Z[i] Für den Fall T[0]=T[1]=T genügen Z[0] und Z[1] zur Berechnung von V[1], R und T R = Z[0]^2 / (Z[0] - Z[1]) = Z[0] + Z[1] * Sum[i=0,~]((Z[1]/Z[0])^i) V[1] = Z[1]^2 / (Z[0] - Z[1]) T = Z[1] / Z[0]^2 Für den Fall T[0], T[1]=T[2]=T benötigt man Z[0], Z[1] und Z[2] zur Berechnung von R, V[2], T[0] und T R = Z[0] + Z[1]^2 / (Z[1] - Z[2]) = Z[0] + Z[1] + Z[2] * Sum[i=0,~]((Z[2]/Z[1])^i) V[2] = Z[2]^2 / (Z[1] - Z[2]) T[0] = Z[1]^2 / (Z[0]^2 * (Z[1] - Z[2]) + Z[0]*Z[1]^2) T = Z[2] / (Z[0] * (Z[1] - Z[2]) + Z[1]^2) 6.5 Vorgeschaltete Untersetzer ============================== Bei zu hohen Zählraten ist zur Vermeidung von Totzeitverlusten die Vorschaltung eines schnellen Untersetzers zu empfehlen (z.B. 1/10, 50MHz). Dies hat zum einen den Effekt, dass die zu übertragende Rate reduziert wird und zum anderen, dass die statistischen Schwankungen der Zählrate herabgesetzt werden, wodurch sich ebenfalls die Totzeitverluste reduzieren. R Originalrate, Poisson-verteilt Ru untersetzte Rate U >1 Untersetzungsverhältnis S 4 auf den Term n=1: V(u,R,n=1) = (R*T)/u * (R*T)^(u-1) / (u-1)! * e^-(R*T)) = (R*T) * (R*T)^(u-1) / u! * e^-(R*T)) Die Totzeitverluste werden im Vergleich zur Eingangsrate R um mehr als 1/u! reduziert und werden z.B. bei einer 1/10-Untersetzung (1/10! = 2.8*10^-7) völlig venachlässigbar. Im Vergleich zu einer Eingangsrate R/u werden sie um mehr als 1/(u-1)! reduziert. *Abstandsverteilung der untersetzten Datenrate* Die Änderung von P[0] zur Zeit t ist die Wahrscheinlichkeit für das Eintreffen des ersten Ereignisses seit t=0. Legt man t=0 auf den Zeitpunkt des vorausgegangenen Ereignisses, was man ohne Einschränkung tun kann, so erhält man die Wahrscheinlichkeit für das Auftreten des Abstandes t. P[0] wird um die Wahrscheinlichkeit kleiner, mit der das Ereingnis zur Zeit t eintrifft. Die Änderung von P[1] enthält zwei Komponenten: zum Einen muss es um den Betrag wachsen, den P[0] verloren hat, und zum Andern verliert es durch die Wahrscheinlichkeit des Eintreffens eines zweiten Ereignisses. dP[0]/dt = R * (0 - P[0]) dP[1]/dt = R * (P[0] - P[1]) ... dP[n]/dt = R * (P[n-1] - P[n]) Bei einem u-fachen Untersetzer ist die Wahrscheinlichkeit für das Eintreffen des u-ten Ereignisses von Interesse, da nur jedes u-te Ereignis am Ausgang erscheint. Analog zu oben ergibt sich für die Abstandsverteilung Au der u-ten Ereignisse: dP[u]/dt = R * (P[u-1] - P[u]) Au = R * P[u-1] Int[0,~](Au)dt = 1 Mittelwerte von Au: Au\ = Int[0,~](t * Au)dt / Int[0,~](Au)dt = u/R * Int[0,~](Au+1)dt = u/R (war ja zu erwarten) Au^2\ = Int[0,~](t^2 * Au)dt / Int[0,~](Au)dt = u * (u + 1) / R^2 * Int[0,~](Au+2)dt = u * (u + 1) / R^2 Streuung um den Mittelwert: Su = (Au - Au\)^2 = Au^2\ - Au\^2 = u / R^2 Die Streuung einer Poisson-verteilten gleichen Rate R/u hingegen ist S1(R/u) = u^2 / R^2, also das u-fache. Die "statistischen Spitzen" werden geglättet. *Abb. 6.5.0.1 Abstandsverteilungen* (Kein Textformat-Bild vorhanden, siehe: html, pdf, dvi) 6.6 Fifo-Speicher ================= Sobald ganze Datenworte mit einem Ereignis verbunden sind können vorgeschaltete Untersetzer oder Zählerkaskaden nicht benutzt werden zur Vermeidung von Totzeitverlusten. Hier können dann Fifo-Speicher weiterhelfen. Dies ist der nicht ganz überzeugende Versuch das Problem als Markov-System bzw. Markov-Kette zu betrachten. Aber die Ergebnisse scheinen zu stimmen.(?) *Markov-Ketten-Modell für einen Fifo:* .--> /----\ -----l----> /----\ -----l----> /----\ ---. m |S(0)| |S(1)| |S(M)| l `--- \----/ <----m----- \----/ <----m----- \----/ <--' S(n): Besetzungswahrscheinlichkeit für Zustand mit n Ereignissen im Fifo S(0): Fifo ist leer S(m): Fifo ist voll l,m: Übergangswahrscheinlichkeiten l: Einströmung m: Bedienung Ein Zustand S(n) wird zerstört mit der Wahrscheinlichkeit (l + m) * S(n) Und er wird aus den Nachbarn erzeugt mit der Wahrscheinlichkeit m * S(0) + m * S(1) (n=0) l * S(n-1) + m * S(n+1) l * S(M-1) + l * S(M) (n=M) Das System ist im Gleichgewicht, wenn beide Wahrscheinlichkeiten gleich sind l * S(0) = m * S(1) (l + m) * S(n) = l * S(n-1) + m * S(n+1) m * S(M) = l * S(M-1) Durch rekursives Einsetzen erhält man für die Besetzungswahrscheinlichkeiten S(n) S(1) = (l/m)^1 * S(0) S(2) = (l/m)^2 * S(0) ... S(n) = (l/m)^n * S(0) Für einen Fifo der Tiefe M gilt außerdem Sum[n=0,M]S(n) = 1 = Sum[n=0,M]<(l/m)^n * S(0)> S(0) = 1 / Sum[n=0,M]<(l/m)^n> = (1 - l/m) / (1 - (l/m)^(M+1)) l/m != 1 = 1 / (M + 1) l/m = 1 und damit S(n) = (l/m)^n * (1 - l/m) / (1 - (l/m)^(M+1)) l/m != 1 = 1 / (M + 1) l/m = 1 Die Wahrscheinlichkeit, dass der Fifo belegt ist, ergibt sich dann zu S(M) = (l/m)^M * (1 - l/m) / (1 - (l/m)^(M+1)) l/m != 1 = 1 / (M + 1) l/m = 1 und die Rate der Verluste zu V = S(M) * l Für l/m << 1 kann man abschätzen S(M) ~ (l/m)^M Bleibt noch die Frage, wie die Übergangswahrscheinlichkeiten l und m zu verstehen sind. Setzt man l = R Ereignisrate m = 1/T Bedienung mit Totzeit T (Bedienrate) so erhält man einleuchtende Ergebnisse für einige überprüfbare Fälle (M=1, M=~, R*T<<1, R*T=1), obwohl dies nicht den Markov-Vorausetztungen (zufällige Ereignisse, die Vergangenheit hat keinen Einfluss) entspricht. Insbesondere ist die Bedienung eine direkte Folge eines vorausgegangenen Ereignisses und nicht zufällig. Die Übergangswahrscheinlichkeit l kann man sich aus der Poisson-Verteilung der Ereignisrate als Wahrscheinlichkeit für das Auftreten des ersten Ereignisses "gleich jetzt" (t=0) folgendermaßen ableiten: d(P[1]) / dt [t=0] = R d(P[n>1]) / dt [t=0] = 0 Für die Bedienrate mit Totzeit T geht das so nicht. Es gibt Rechnungen mit "negativ exponentieller" Bedienrate. Da soll das analog funktionieren: B = 1 - e^-(t/T) (???) d(B) / dt [t=0] = 1/T Haben wir aber nicht! Wenn sowohl Ereignisrate als auch Bedienrate periodisch wären, so hätte man für R*T<1 garkeine Totzeitverluste zu erwarten. Mit einer zufälligen Ereignisrate scheint es aber noch zu funktionieren. Der Unterschied ist in der Formel für die Totzeitverluste V = R * S(M) zu berücksichtigen, die so nur richtig ist für eine zufällige Ereignisrate. Bei periodischen Ereignissen mit R*T<1 wäre die vorausgegangene Bedienung bereits beendet, wenn das nächste Ereignis eintrifft. Zufällige Ereignisse scheinen die Vergangenheit ausreichend abzukoppeln. *Beispiel:* Für ein Gerät mit Totzeit T und einem Datenregister (M = 1) sind die Totzeitverluste bei einer Rate R V = R * S(M) = R*R*T / (1 + R*T) Das gleiche Ergebnis erhält man mit der üblichen Totzeitrechnung (s.o.). *Ergebnis:* Ein Fifo kann die Totzeitverluste erheblich vermindern. V ~ R * (R/T)^M R*T << 1 V = R / (M + 1) R*T = 1 Für R*T << 1 genügt bereits ein Fifo mit wenigen Speicherplätzen. Für R*T = 1 können die Verluste mit einem M = 100 Fifo auf 1% begrenzt werden. Das Fifo auf der Rechneranpassung ist mit M = 2048 deutlich größer gewählt, da es mögliche Unterbrechungen bei der Datenverarbeitung durch den Rechner überbrücken muss: z.B.: M / R = 2000 / 100kHz = 20ms 7 Technische Details ******************** 7.1 Routing-Bus =============== 7.1.1 Routing-Bus Signale ------------------------- Der Routing-Bus (Tab. 7.1.1.1) besteht aus zwei Teilen, dem 'Allgemeinen Bus', der über die ganze Breite des Überrahmens geht und dem 'Privat-Bus', der erst durch das Stecken benachbarter Karten entsteht und auf diese begrenzt ist. *Allgemeiner Bus (A-Bus)* Der allgemeine Bus belegt die Anschlüsse 1a, 1c usw. bis 21c. Die Anschlüsse mit dem Suffix a und c führen im Gegensatz zum Privat-Bus zu verschiedenen Bus-Leitungen und dürfen nicht gebrückt werden. * *Stromversorgung (Standard):* + 5V / 10A +15V / 1A -15V / 1A * *DO - D15* (Datenleitungen): Sechszehn Datenleitungen stehen zur Verfügung. Low auf einer Leitung bedeutet, dass das Daten-Bit gesetzt ist. Offene Leitung heißt, das Daten-Bit ist nicht gesetzt. * *Kopp-, LFT-Bit*: Diese beiden Bits sind Kennungs-Bits, die von den Interfaces gesetzt werden können. Die Standard-Interface-Steuerung (IFS-Karte, *Note Interface-Steuerung::.) nutzt sie zur Anzeige von gekoppelten Daten bzw. bei der Lifetime-Messung. * *10 MHz-Clock/-Clock\*: Quarzstabilisierter Mastertakt der Routing-Steuerung. Tastverhältnis: 1:2 Stabilität: 10ppm * *1 MHz-Clock*: Vom Mastertakt abgeleiteter 1MHz Takt. Tastverhältnis: 1:2 * *PAddr1..3* (Steckplatzadresse): Für jeweils zwei benachbarte Steckplätze ist eine gemeinsame Steckplatzadresse 0-7 verdrahtet (Abb. 2.2.0.1). Die Interface-Steuerungen müssen so gesteckt werden, dass sie verschiedene Adressen einnehmen, da sie nur dann eindeutig zu adressieren sind. * *SAddr0..3* (Scanner-Adresse): Ein Steckplatz gilt als angewählt, wenn die Bits 1-3 von Steckplatz- und Scanner-Adresse übereinstimmen. Nur dann darf die Interface-Steuerung mit der Routing-Steuerung in Kontakt treten. Das Bit _SAddr0_ erlaubt noch das Ansprechen zweier unterschiedlicher Datenregister eines Eingabekanals. Die Scanner-Adresse wird den übertragenen Daten von der Rechneranpassung als Quellenkennung beigefügt, um sie unterscheidbar zu machen (*Note Rechneranpassung::.). * *TN, TV* (Freigabetakte für den Adressvergleich): _TN_, _TV_ erscheinen verzögert zu der Scanner-Adresse, so dass sichergestellt ist, dass die Adress-Bits eingeschwungen sind und keine Vergleichsfehler auftreten können. Ferner ermöglichen _TN, TV_ eine Unterscheidung welcher der beiden Scanner unterschiedlicher Priorität gerade aktiv ist. _TN_: Normal-Scanner _TV_: Vorrang-Scanner * *PrioReqB* (Vorrang Anmeldung): Über diese Leitung kann bei der Routing-Steuerung ein vorrangiger Bearbeitungswunsch angemeldet werden. Die Routing-Steuerung fragt in einer bestimmten Phase jedes Scan-Zyklus diese Leitung ab und schaltet auf den gewünschten Scanner. * *ReadyB* (Data Ready); *RequestB* (Data Request); *AcceptedB* (Data Accepted) Mit diesen drei Signalen synchronisiert sich die Datenübertragung eines vom Scanner angewählten Eingabekanals. Die Interface-Steuerung meldet _ReadyB_, falls sie Daten übertragen will. Dies hat ein Stoppen des Scanners zur Folge. Mit _RequestB_ wird die Datenquelle aufgefordert die Daten auf den Bus zu geben. Beendet wird die Übertragung mit _AcceptedB_. Mit diesem Signal wird im allgemeinen auch die Datenquelle zurückgesetzt, die dann das nächste Datenwort aufnehmen kann. * *StopB*: Dieses Signal teilt allen Eingabekanälen gleichzeitig mit, dass die Routing-Steuerung gestoppt wurde. *Privat-Bus (P-Bus)* Der Privat-Bus baut sich erst durch Stecken der Karten auf. Eine fehlende Karte oder das Fehlen entsprechender Brücken auf den Karten unterbrechen den Privat-Bus. Er reicht von den Leitungen 22 bis 32 einschließlich. Die Leitungen mit dem Suffix a führen zur linken Nachbarkarte und die mit c zur rechten. Soll ein Bus aufgebaut werden, so sind die Anschlüsse a und c einer Leitung zu brücken. Die individuelle Nutzung des Privat-Busses ist den einzelnen Kartenbeschreibungen zu entnehmen (z.B. RST-, IFS-, KPL- Karten). *Tab. 7.1.1.1 Data-Routing-Bus* a Pin c ---------------------------------------------------------- Spannungs- (digital) +5V 1 +5V (digital) Spannungs- Versorgung (digital) 0V 2 0V (digital) Versorgung ---------------------------------------------------------- D0\ 3 D1\ D2\ 4 D3\ D4\ 5 D5\ D6\ 6 D7\ D8\ 7 D9\ D10\ 8 D11\ D12\ 9 D13\ D14\ 10 D15\ A-Bus Kopp-Bit\ 11 LFT-Bit\ A-Bus SAddr0\ 12 1MHz-Clock SAddr1\ 13 PAddr1\ SAddr2\ 14 PAddr2\ SAddr3\ 15 PAddr3\ RequestB 16 ReadyB\ StopB\ 17 AcceptedB 10MHz-Clock\ 18 10MHz-Clock TV 19 TN (analog) 0V 20 PrioReqB\ (analog) +15V 21 -15V (analog) ---------------------------------------------------------- 22 23 24 25 P-Bus 26 P-Bus 27 28 29 30 31 32 ---------------------------------------------------------- (Signalnamen mit '\': aktiv low) 7.1.2 Routing-Bus Abschluss --------------------------- Der Bus-Abschluss ist normalerweise ganz links auf der Rückseite der ersten VG-Steckerleiste installiert. Es bestehen jedoch auch Sonderlösungen durch von vorne gesteckte Karten, insbesondere wenn der Überrahmen in einen Data-Routing-Bus und einen Control-Routing-Bus aufgeteilt ist. Der Bus-Abschluss ist je nach Aufgabe der Bus-Leitungen als aktiver Abschluss (ca. 3V) oder durch Pulldown-Widerstände realisiert (Abb. 7.1.2.1). Der 27 Ohm Widerstand, mit denen die Pulldowns zusammengefasst sind, ist experimentell ermittelt und verbessert die Signale ganz erheblich. Insbesondere vermindert er ein Übersprechen, das im Data-Routing zum Ausfall einzelner 10MHz-Takte beim Schalten der _SADR(0:3)_-Leitungen geführt hatte. Warum das Ganze gerade in dieser Beschaltung ordentlich läuft, weiß keiner so recht. Die von den Interface-Karten erzeugten Signale können mittels Treiber-Bausteinen mit mindestens 15mA (besser 24mA) Low-Signalstrom (z.B. 'LS245, 'LS373, 'LS374) auf den Bus gegeben werden. Bei der Entwicklung von Interface-Karten bitte stets darauf achten, dass sowohl *Sender- als auch Empfänger-Bausteine möglichst nahe am Bus platziert werden!* Denn ein solcher Bus ist eine sehr heikle Hf-Übertragungsstrecke (ca. 20MHz), die man durch falsch aufgebaute Steckkarten empfindlich stören kann. *Abb. 7.1.2.1 Routing-Bus-Abschluss* D00\ 3a <--220Ohm--| D01\ 3c <--220Ohm--| D02\ 4a <--220Ohm--| D03\ 4c <--220Ohm--| D04\ 5a <--220Ohm--| D05\ 5c <--220Ohm--| D06\ 6a <--220Ohm--| D07\ 6c <--220Ohm--| +---------+ D08\ 7a <--220Ohm--| | aktiver | D09\ 7c <--220Ohm--+---------|Abschluss| D10\ 8a <--220Ohm--| | 3 Volt | D11\ 8c <--220Ohm--| +----+----+ D12\ 9a <--220Ohm--| | D13\ 9c <--220Ohm--| === D14\ 10a <--220Ohm--| D15\ 10c <--220Ohm--| Kopp-Bit\ 11a <--220Ohm--| LFT-Bit\ 11c <--220Ohm--| 1MHz-Clock 12c <--220Ohm--| ReadyB\ 16c <--220Ohm--| PrioReqB\ 20c <--220Ohm--| PADR1\ 13c ) PADR2\ 14c ) Steckplatzkodierung 0V/5V PADR3\ 15c ) SADR0\ 12a <--220Ohm--| SADR1\ 13a <--220Ohm--| +---------+ SADR2\ 14a <--220Ohm--| |passiver | SADR3\ 15a <--220Ohm--+---------|Abschluss| RequestB\ 16a <--220Ohm--| | 27 Ohm | StopB\ 17a <--220Ohm--| +----+----+ AcceptedB 17c <--220Ohm--| | 10MHz-Clock\ 18a <--220Ohm--| === 10MHz-Clock 18c <--220Ohm--| TV 19a <--220Ohm--| TN 19c <--220Ohm--| (analog) 0V 20a <--220Ohm--| 7.2 Komponenten und Schnittstellen ================================== *Abb. 7.2.0.1 Komponenten und Schnittstellen des Routing* (Kein Textformat-Bild vorhanden, siehe: html, pdf, dvi) 7.2.1 Datenquellen <-> Quellen-Interfaces ----------------------------------------- Eine solche Schnittstelle existiert immer dann, wenn ein bereits vorhandenes Gerät angeschlossen werden soll (z.B. ein Silena ADC wird mittels Silena-ADC-Interface an das Routing angepasst) und ist i.a. ausschließlich für diesen Zweck ausgelegt. 7.2.2 Quellen-Interface <-> Interface-Steuerung ----------------------------------------------- Die IFS-Karte baut nach rechts einen Privat-Bus den IFS-Bus zum Quellen-Interface hin auf. Er endet normalerweise beim Quellen-Interface, wobei dieses jedoch aus mehreren Karten bestehen darf. Alle Signalnamen auf dem IFS-Bus enden mit Q. Die Signalbezeichnungen sind in positiver Logik angegeben, d.h. wenn an einer Leitung 'high' anliegt, so ist das zugehörige Signal wahr. Ein Backslash "\" bedeutet die Negierung eines Signals: BUSY\ = NOT (BUSY). Wenn also eine Datenquelle Busy meldet, dann liegt 'low' auf der Leitung BUSY\. Mit '^' gekennzeichnete Signale werden auf der IFS-Karte erzeugt. *^LFTQ\:* (Lifetime Quelle) Dieses Signal wird auf der IFS-Karte erzeugt und stellt die Lifetime (=NOT(Totzeit)) zur Verfügung. _LFTQ_ setzt sich konjunktiv (UND) zusammen aus der negierten Busy-Meldung der Datenquelle (_BusyQ\_), dem Eingang _GateQ_ der IFS-Karte (Option), und im Kopplungsmodus _K2_ der Lifetime-Meldung _LFTK_ der Kopplung. _LFTQ= BusyQ\ * GateQ(Option) * (K2 * LFTK\)\_ *PrioReqQ\:* (Vorrang Quelle) Dieses Signal zeigt der IFS-Karte an, dass die Quelle mit Vorrang bedient zu werden wünscht. Es kann statisch anstehen, mit _ReadyQ_ wird es wirksam. _PrioReqQ_ schaltet die IFS-Karte in den Kopplungsmodus _Frei_. Eine Datenquelle, die mit Vorrang läuft, kann deshalb nicht an einer Datenkopplung teilnehmen. *^GateSQ:* (Gate Quelle) Mit diesem Signal gatet die IFS-Karte die angeschlossene Datenquelle auf- und zu. *BusyQ:* (Busy Quelle) Mit diesem Signal meldet die Datenquelle ihr Busy an die IFS-Karte. *^StopQ:* (Stop Quelle) Dieses Signal teilt der Datenquelle mit, dass ihr keine Daten vom Routing abgenommen werden. Als Ursachen hierfür kommen in Frage: * Stop durch den Rechner. * Die RST-Karte ist manuell gestoppt. * Die IFS-Karte ist manuell gestoppt. Normalerweise cleart dieses Signal die Datenquelle. *ReadyQ\:* (Data Ready Quelle) *^RequestQ:* (Data Request Quelle) *^AcceptedQ:* (Data Accepted Quelle) Diese drei Signale bilden zusammen einen Hand-Shake-Dialog (Abb. 7.2.2.2) zur Übernahme der Daten von der Quelle. Mit _ReadyQ_ teilt die Datenquelle der IFS-Karte mit, dass sie ein Datenwort übertragen möchte. Dieses Signal muss zumindest bis zum Beginn von _RequestQ_ anstehen. Mit _RequestQ_ fordert die IFS-Karte die Datenquelle auf, für die Dauer des Signals ihre Daten auf den Bus zu geben. Mit _AcceptedQ_ wird der Datenquelle mitgeteilt, dass die Daten übernommen wurden. *Daten(0-15):* (Datenleitungen) Die Daten laufen nicht über die IFS-Karte sondern werden direkt auf den Routing-Bus gegeben. Sie sind über Treiber-Bausteine mit mindestens 24mA Low-Signalstrom (z.B. 'LS245, 'LS373, 'LS374) auf die Leitungen zu geben. *KoppK:* (Kopplungssignal) *BusyK:* (Busy Kopplung) *LFTK:* (Lifetime Kopplung) Diese Signale gehören dem Kopplungs-Bus an und werden zusammen mit der Kopplungskarte beschrieben (*Note Kopplungskarte <-> Interface-Steuerungen::.). *Tab. 7.2.2.1 Schnittstelle zur Datenquelle (IFS-Bus)* Signal Funktion Leitung IFS Quelle KPL LFTQ Lifetime 25 c a PrioReqQ\ Vorrang 26 c a GateSQ Gate 27 c a BusyQ\ Busy 28 c a StopQ Stop 29 c a AcceptedQ Data 30 c a RequestQ\ Data Request 31 c a ReadyQ\ Date Ready 32 c a KoppK\ Kopplungssignal 23 a,c a,c a BusyK\ Kopplung 24 a,c a,c a LFTK Lifetime 22 a,c a,c a *Abb. 7.2.2.2 Timing zwischen IFS-Karte und Datenquelle* (Kein Textformat-Bild vorhanden, siehe: html, pdf, dvi) 7.2.3 Interface-Steuerung ------------------------- *Abb. 7.2.3.1 Interface-Steuerung* (Kein Textformat-Bild vorhanden, siehe: html, pdf, dvi) 7.2.4 Interface-Steuerung <-> Routing-Steuerung ----------------------------------------------- Die Routing-Steuerung verständigt sich mit der Interface-Steuerung durch einen Hand-Shake-Dialog über Signalleitungen des Routing-Busses: Signalnamen ohne Backslash '\': aktiv high Signalnamen mit Backslash '\': aktiv low Ein '^' vor dem Signalnamen: die Routing-Steuerung ist die Quelle des Signals *^10 MHz-Clock,-Clock\* Quarzstabilisierter 10MHz Mastertakt der Routing-Steuerung. Tastverhältnis: 1:2 Stabilität: 10ppm *^1 MHz-Clock* vom Mastertakt abgeleiteter 1MHz-Takt. Tastverhältnis: 1:2 *^SAddr0..3\* (Scanner-Adresse) Scanner-Adresse (4 Bits) zur Abfrage der Interface-Steuerungen. *ReadyB\* Die abgefragte Interface-Steuerung meldet sich bei der Routing-Steuerung mit _ReadyB_, falls sie ein Datenwort übertragen will. *^StopB\* Dieses Signal teilt allen Interface-Steuerungen mit, dass die Routing-Steuerung gestoppt wurde (manuell oder durch Rechner). *^TN, ^TV* Freigabetakte für den Adressvergleich auf den Interface-Steuerungen für Normal- (_TN_) bzw. Vorrangmodus (_TV_). *PrioReqB\* Anmeldung eines vorrangigen Bearbeitungswunsches bei der Routing-Steuerung durch die Interface-Steuerungen. Dieses Signal muss mit 'Open-Collector-Technik' (wired OR) beschaltet werden. 7.2.5 Routing-Steuerung ----------------------- Im Mai 2000 wurde eine Neuentwicklung der Routing-Steuerung fertiggestellt und nach und nach zum Einsatz gebracht. Sie verwendet die alten Frontplatten. Die Schaltung ist im wesentlichen auf einem hochintegrierten, programmierbaren Baustein untergebracht. Ihre Funktionalität und Betriebssicherheit wurden verbessert. Die Routing-Steuerung ist mit zwei alternativ laufenden Scannern unterschiedlicher Priorität ausgestattet, mit denen die Eingabekanäle abgefragt werden. Sie schickt zu diesem Zweck über vier Bus-Leitungen (_SAddr0..3_) nacheinander die Scanner-Adressen 0-15 an alle Interface-Steuerungen. Diese vergleichen die drei höchstwertigen Bits der Scanner-Adressen mit ihrer Steckplatzadresse (_PAddr1..3_), die für jeden Steckplatz fest verdrahtet ist. Bei Gleichheit gilt der Eingabekanal als angewählt und kann bei Bedarf mit der Routing-Steuerung kommunizieren. Es besteht die Möglichkeit, einen oder mehrere Eingabekanäle mit Vorrang vor den anderen abfragen zu lassen. Dazu müssen diese Eingabekanäle einen Vorrangwunsch (_PrioReqB_) bei der Routing-Steuerung anmelden, sobald sie bereit sind ein Datenwort zu übertragen. Diese Anmeldung kann zu jeder Zeit asynchron erfolgen. Nach jedem Scanner-Schritt prüft die Routing-Steuerung die _PrioReqB_-Leitung ab und setzt den Betrieb mit dem gewünschten Scanner (Vorrang- bzw. Normal-Scanner) fort. Der jeweils ruhende Scanner behält seine Position bei, so dass er an der unterbrochenen Stelle weiterlaufen kann. Der im Vorrangmodus arbeitende Eingabekanal muss sich des Freigabetaktes _TV_ bedienen im Gegensatz zu _TN_ für den Normalmodus. Ein Stop der Routing-Steuerung kann vom Rechner her erfolgen (_StopR_) oder über einen Schalter auf der Frontplatte (_StopM_). Beide bewirken ein Anhalten der Daten-Scanner. Ferner wird der Stop den Eingabekanälen mitgeteilt (_StopB_) und über die Interface-Steuerung den Datenquellen (_StopQ_). Da das gleichzeitige Schalten aller Scanner-Adress-Bits zu massiven Störungen auf dem Routing-Bus geführt hat (einzelne 10MHz Takte wurden verstümmelt), ist die Folge der Scanner-Adressen so gewählt, dass sich stets nur möglichst wenig Bits gleichzeitig ändern. Da die IFS1-Karte das niederwertigste Bit als Clock-Signal verwendet, muss dieses eine 0-1-0 Folge haben. Unter dieser Voraussetzung und der Forderung nach der Möglichkeit für einen verkürzten Scanner-Umlauf, war eine Beschränkung auf 2-Bit-Wechsel möglich. Die Scanner-Adressen sind in vier Gruppen zusammengefasst, die sich am Anfang und Ende auch gegenüber einigen anderen Gruppen nur um maximal zwei Bits unterscheiden. Sie können deshalb in Einer-, Zweier- und Vierer-Kombinationen verknüpft werden. Gruppe 0, Adressen 0 - 3 0 0 0 0 0 0 0 1 0 0 1 0 0 0 1 1 Gruppe 1, Adressen 4 - 7 0 1 1 0 0 1 1 1 0 1 0 0 0 1 0 1 Gruppe 3, Adressen 12 - 15 1 1 0 0 1 1 0 1 1 1 1 0 1 1 1 1 Gruppe 2, Adressen 8 - 11 1 0 1 0 1 0 1 1 1 0 0 0 1 0 0 1 Erlaubte Kombinationen von Gruppen mit maximal 2-Bit-Wechsel sind: 0, 1, 2, 3, 0-1, 0-2, 1-3, 2-3, 0-1-3-2 Bei unzulässigen Kombinationen, und falls kein Jumper gesetzt ist, wird 0-1-3-2 ausgeführt. Es ist zu beachten, dass die verschiedenen Eingabekanäle von der Routing-Steuerung nicht nach einem 'first in - first out' Verfahren bearbeitet werden, sondern durch einen Scanner reihum abgefragt werden. Dies kann zur Folge haben, dass die einzelnen Eingabekanäle nicht in der Reihenfolge zum Rechner übertragen werden, in der sie zur Übertragung bereit waren. Die damit zusammenhängenden Probleme der Verkoppelung von Datenquellen z.B. bei Koinzidenzexperimenten sind jedoch berücksichtigt (*Note Kopplungskarte <-> Interface-Steuerungen::.). Da den 4 Bits der Scanner-Adresse nur 3 Bits der Steckplatzadresse gegenüberstehen, kann das niederwertigste Bit der Scanner-Adresse zur Adressierung zweier Register verwendet werden. Die Standard-Interface-Steuerung (IFS-Karte) macht bei der Lifetime-Messung von dieser Möglichkeit Gebrauch. Die von der Interface-Steuerung zugeführten Signale _ReadyB_ und _PrioReqB_ werden sorgfältig einsynchronisiert , so dass sie asynchron zu den internen Vorgängen auftreten dürfen. Das Protokoll mit den Eingabekanälen und der Rechneranpassung ist auf der Routing-Steuerung als Zustandsautomat realisiert (Abb. 7.2.5.1, 7.2.5.2): * Im Leerlauf durchläuft der Zustandsautomat die Zustände Z0-Z1-Z3. Beim Übergang nach Z1 wird von der Routing-Steuerung durch die Taktsignale _TN_ bzw. _TV_ der Vergleich von Scanner-Adresse und Steckplatzadresse freigegeben (A2). Ist ein Eingabekanal angewählt und bereit zur Datenübertragung, so teilt er dies der Routing-Steuerung durch das Signal _ReadyB_ über den Bus mit. Bei der Rückkehr nach Z0 wird die nächste Scanner-Adresse geschaltet und das Vorrangsignal (_PrioReqB_) einsynchronisiert (A4). * Antwortet ein Eingabekanal mit einer Data-Ready-Meldung (_ReadyB_), so wird diese beim Übergang nach Z2 mit A3 einsynchronisiert (_ReadyR_) und in Z2 zur Datenübertragung verzweigt (Z21, Z22). Dabei wird das Abfragesignal (_TN_ bzw. _TV_) erneuert (A5, A2). Ferner wird _ReadyR_ an die Rechneranpassung weitergegeben zur Anmeldung einer Datenübertragung. Sobald die Rechneranpassung bereit ist, ein Datenwort aufzunehmen, meldet sie sich mit einem Data-Request-Signal (_RequestB_) und veranlasst damit ein Öffnen der Datengatter des angewählten Eingabekanals (Quellen-Interface). Aus den 16 Daten-Bits, dem LFT- und Kopp-Bit und den 4 Bits der Scanner-Adresse setzt die Rechneranpassung ein Datenwort zusammen (*Note Rechneranpassung::.) und überträgt es zum Rechner. Der Empfang der Daten wird von der Rechneranpassung mit den Data-Accepted-Signalen _AcceptedB_ und _AcceptedR_ quittiert. Auf der Routing-Steuerung bewirkt die Rückflanke von _AcceptedR_ ein Weiterstarten des Daten-Scanners unabhängig davon ob _ReadyB_ noch ansteht oder nicht. Die Datenquelle wird durch _AcceptedB_ im allgemeinen zu einer Normierung veranlasst, zur Vorbereitung auf das nächste Datenwort. In Z21 wird auf das Data Accepted (AcceptedR) der Rechneranpassung gewartet und in Z22 auf dessen Ende. Bei der Rückkehr nach Z0 wird die nächste Scanner-Adresse geschaltet und das Vorrangsignal (_PrioReqB_) einsynchronisiert (A4). * Wenn in Z0 festgestellt wird (E4), dass das Vorrangsignal sich geändert hat, so wird ein Wechsel des Daten-Scanners durchgeführt (Z01, Z02, Z03). Dabei werden die vier Adress-Bits nacheinander umgeschaltet, um Störungen auf dem Bus gering zu halten (A6, A7, A8, A9). *Timing*: Der Zustandsautomat wird mit 10MHz getaktet. Daraus ergibt sich folgendes Timing (zum Vergleich die Werte für die ausgemusterte Routingsteuerung). _neu_ _alt_ Adressfortschaltung im A = 300ns 400ns Leerlauf Datenübertragung D = 400ns 500ns Scanner-Prioritätswechsel P = 400ns 0ns _4 Gruppen, 1 Sanner-Umlauf:_ Leerlauf (16A) 4800ns 6400ns 1 Prio 0 Datenübertragung (16A + D) 5200ns (192kHz) 7100ns (141kHz) 1 Prio 1 Datenübertragung (16A + 2P + D) 6000ns (167kHz) 7100ns (141kHz) _2 Gruppen, 1 Sanner-Umlauf:_ Leerlauf (8A) 2400ns 1 Prio 0 Datenübertragung (8A + D) 2800ns (357kHz) 1 Prio 1 Datenübertragung (8A + 2P + D) 3600ns (278kHz) _1 Gruppe, 1 Sanner-Umlauf:_ Leerlauf (4A) 1200ns 1 Prio 0 Datenübertragung (4A + D) 1600ns (625kHz) 1 Prio 1 Datenübertragung (4A + 2P + D) 2400ns (417kHz) *Abb. 7.2.5.1 Routingsteuerung* (Kein Textformat-Bild vorhanden, siehe: html, pdf, dvi) *Abb. 7.2.5.2 Zustandsdiagramm Scanner Control* (Kein Textformat-Bild vorhanden, siehe: html, pdf, dvi) *Abb. 7.2.5.3a Data Transfer Timing IFS1 Board / Control Board / Routing Board* *Prio 0:* (RtBoard Firmware 1.2, Hardware-Aenderung 1.2a) ns 0 100 200 300 400 500 600 700 800 900 0 100 200 300 400 500 600 700 25ns ..|...|...|...|...|...|...|...|...|...|...|...|...|...|...|...|...|...|... Clock \_/^\_/^\_/^\_/^\_/^\_/^\_/^\_/^\_/^\_/^\_/^\_/^\_/^\_/^\_/^\_/^\_/^\_/^\_ PrioReqB __________________________________________________________________________ TN ______/^^^\___/^^^^^^^^^^^^^^^\___/^^^\_______/^^^\_______/^^^\___________ TV __________________________________________________________________________ ReadyB _______/^^^\___/^^^^^^^^^^^^^^^\__________________________________________ ReadyR __________/^^^^^^^^^^^\___________________________________________________ RequestB ______________/^^^^^^^\___________________________________________________ AcceptR __________________/^^^^^^^\_______________________________________________ AcceptB ______________________/^^^^^^^\___________________________________________ 25ns ..|...|...|...|...|...|...|...|...|...|...|...|...|...|...|...|...|...|... ns 0 100 200 300 400 500 600 700 800 900 0 100 200 300 400 500 600 700 States S 0 1 2 21 21 22 22 0 1 2 0 1 2 0 1 2 0 States R 0 0 0 1 2 2 0 0 0 0 0 0 0 0 0 0 0 *Abb. 7.2.5.3b Data Transfer Timing IFS1 Board / Control Board / Routing Board* *Prio 0:* (RtBoard Firmware 1.2, *ohne* Hardware-Aenderung 1.2a) ns 0 100 200 300 400 500 600 700 800 900 0 100 200 300 400 500 600 700 25ns ..|...|...|...|...|...|...|...|...|...|...|...|...|...|...|...|...|...|... Clock \_/^\_/^\_/^\_/^\_/^\_/^\_/^\_/^\_/^\_/^\_/^\_/^\_/^\_/^\_/^\_/^\_/^\_/^\_ PrioReqB __________________________________________________________________________ TN ______/^^^\___/^^^^^^^^^^^^^^^^^^^^^^^\___/^^^\_______/^^^\_______/^^^\___ TV __________________________________________________________________________ ReadyB _______/^^^\___/^^^^^^^^^^^^^^^^^^^^^^^\__________________________________ ReadyR __________/^^^^^^^^^^^^^^^\_______________________________________________ RequestB ______________/^^^^^^^\___________________________________________________ AcceptR ______________________/^^^^^^^^^^^\_______________________________________ AcceptB ______________________/^^^^^^^^^^^\_______________________________________ 25ns ..|...|...|...|...|...|...|...|...|...|...|...|...|...|...|...|...|...|... ns 0 100 200 300 400 500 600 700 800 900 0 100 200 300 400 500 600 700 States S 0 1 2 21 21 21 22 22 22 0 1 2 0 1 2 0 1 2 States R 0 0 0 1 2 2 2 0 0 0 0 0 0 0 0 0 0 0 *Abb. 7.2.5.3c Data Transfer Timing IFS1 Board / Control Board / Routing Board* *Prio 1:* (RtBoard Firmware 1.2, Hardware-Aenderung 1.2a) ns 0 100 200 300 400 500 600 700 800 900 0 100 200 300 400 500 600 700 800 25ns ..|...|...|...|...|...|...|...|...|...|...|...|...|...|...|...|...|...|...|...| Clock \_/^\_/^\_/^\_/^\_/^\_/^\_/^\_/^\_/^\_/^\_/^\_/^\_/^\_/^\_/^\_/^\_/^\_/^\_/^\_/ PrioReqB ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\_______________________________ TN __/^^^\___________________________________________________________________/^^^\ TV ______________________________/^^^\___/^^^^^^^^^^^^^^^\________________________ ReadyB _______________________________/^^^\___/^^^^^^^^^^^^^^^\_______________________ ReadyR __________________________________/^^^^^^^^^^^\________________________________ RequestB ______________________________________/^^^^^^^\________________________________ AcceptR __________________________________________/^^^^^^^\____________________________ AcceptB ______________________________________________/^^^^^^^\________________________ 25ns ..|...|...|...|...|...|...|...|...|...|...|...|...|...|...|...|...|...|...|...| ns 0 100 200 300 400 500 600 700 800 900 0 100 200 300 400 500 600 700 800 States S 1 2 0 01 02 03 0 1 2 21 21 22 22 0 01 02 03 0 1 States R 0 0 0 0 0 0 0 0 0 1 2 2 0 0 0 0 0 0 0 7.2.6 Routing-Steuerung <-> Rechneranpassung -------------------------------------------- Die Routing-Steuerung verständigt sich mit der Rechneranpassung durch einen Hand-Shake-Dialog, zum Teil über Leitungen des Privat-Busses nach rechts. Die Routing-Steuerung muss deshalb stets direkt links von der Rechneranpassung stecken. Beide Karten sollten vorzugsweise ganz rechts im Überrahmen untergebracht werden. (*Note Überrahmen::.). Signalnamen ohne Backslash '\': aktiv high Signalnamen mit Backslash '\': aktiv low Ein '^' vor dem Signalnamen: die Routing-Steuerung ist die Quelle des Signals *^ReadyR\* (Data Ready) Mit diesem Signal wird die Rechneranpassung von der Routing-Steuerung aufgefordert, ein Datenwort zu übernehmen. Es steht solange an bis die Rechneranpassung _AcceptedR_ sendet. *RequestB* (Data Request) Mit diesem Signal zeigt die Rechneranpassung dem angewählten Eingabekanal an, dass das Datenwort auf den Bus zu schalten ist. *AcceptedB* (Data Accepted) Mit diesem Signal an den Eingabekanal quittiert die Rechneranpassung den Empfang des Datenwortes. *AcceptedR* (Data Accepted) Mit diesem Signal von der Rechneranpassung wird der Routing-Steuerung mitgeteilt, dass die Übertragung beendet ist. Diese nimmt _ReadyR_ zurück und startet den aktuellen Scanner nach dem Ende von _AcceptedR_. *StopR\* Stop der Routing-Steuerung durch den Rechner. *^SAddr0..3\* (Scanner-Adresse) Die Scanner-Adresse wird von der Rechneranpassung dem Datenwort als Quellenkennung beigefügt (*Note Rechneranpassung::.). *Tab. 7.2.6.1 Privat-Bus-Belegung (RST-Bus)* Signal Leitung RST RAP AcceptedR 24 c a StopR 25 c a ReadyR 27 c a 7.2.7 Rechneranpassung ---------------------- Die aktuelle Rechneranpassung ist mit einem 2048 Wort tiefen und 3 Byte breiten Fifo ausgerüstet, um vorrübergehende Unterbrechungen der Datenübertragung (z.B. durch Störungen) überbrücken zu können. Der Zustand des Fifo (halbvoll, voll), nach dem ein Datenwort gespeichert wurde, wird jedem Datenwort als Status-Bits mitgegeben. Ferner steht der aktuelle Zustand des Fifo (leer, halbvoll, voll, Fehler) stets dem Rechner zur Abfrage zur Verfügung. Mittels der Zustandssignale (leer, halbvoll, voll) der drei Fifo-Bausteine wird überwacht, ob die drei Bausteine noch synchron sind. Im Fehlerfall wird ein Status-Bit gesetzt, das von der Software nur durch ein 'Stop Datenübertragung' gelöscht werden kann. Diese Überwachung erkennt einen Fifo-Fehler u. U. nicht sofort, sondern erst, wenn die Zustands-Flags der drei Bausteine nicht mehr gleich sind. *Abb 7.2.7.1 Zustandsdiagramm Fifo Control* (Kein Textformat-Bild vorhanden, siehe: html, pdf, dvi) 7.2.8 Rechneranpassung <-> Rechner-Interface -------------------------------------------- *Hardware-Verbindung Rechneranpassung -> Rechner-Interface* Die Datenübertragung von der Rechneranpassung zum Rechner-Interface geschieht über ein 50-poliges Flachbandkabel. Tests mit einem 40m langen Kabel haben gezeigt, dass bis zu dieser Länge noch eine gesicherte Übertragung möglich ist. Möglichst kurze Kabellängen sind jedoch zu empfehlen, da die Kabellänge in die Übertragungsgeschwindigkeit eingeht (s.u.) und wegen höherer Störungssicherheit. *Tab. 7.2.8.1 Steckerbelegung 50 pol. Verbindungskabel* Pin Signal Pin Signal 1,2,..,50Ground Ground Ground 3 Fifo full 27 Routing online P 5 Fifo failure 29 Routing stopped 7 Fifo half full 31 Data Available bit 1 9 Routing online N 33 Data Available bit 0 11 not used 35 Data 7 13 not used 37 Data 6 15 Data Request bit 0 39 Data 5 17 Stop Routing 41 Data 4 19 Data Request bit 1 43 Data 3 21 IP-Board ID bit 2 45 Data 2 23 IP-Board ID bit 1 47 Data 1 25 IP-Board ID bit 0 49 Data 0 *Verbindungs-Check Rechneranpassung -> Rechner-Interface* Um Verwechslungen der IP-Boards (Rechner-Interfaces) für Data-Routing und Control-Routing zu erkennen (sie unterscheiden sich nur in unterschiedlicher Firmware), bieten die IP-Boards der Rechneranpassung eine 3 Bit Board-ID an, die mit der Board-ID der Rechneranpassung verglichen wird. Die Rechneranpassung schaltet nur auf Online wenn beide IDs gleich sind. Das Ergebnis des Vergleichs wird dem Rechner-Interface über die komplementären Leitungen 'Routing online P/N' mitgeteilt und kann vom Rechner als Status-Bit abgefragt werden. Ein negatives Ergebnis (Routing offline) entsteht ebenfalls, wenn das Routing abgeschaltet ist oder das Verbindungskabel fehlt. *Data Transfer Protokoll Rechneranpassung -> Rechner-Interface* Rechneranpassung: Rechner-Interface: Sender Empfänger Data Transfer Slave Data Transfer Master 10 Mhz Clock 8 Mhz Clock Ein vollständiger Übertragungszyklus (Abb. 7.2.8.2, 7.2.8.3) überträgt nacheinander drei Bytes (16 Bits Daten, 8 Bits Status). Der Empfänger (Rechner-Interface) zeigt mit 'DataRequestN' (N = 1,3,2) an, dass er zur Aufnahme von Daten-Byte N bereit ist. Der Sender (Rechneranpassung) antwortet mit 'DataAvailableN' und der Übertragung von Daten-Byte N. Mit 'DataRequest0' und 'DataAvailable0' wird die Übertragung beendet. Erst wenn 'DataRequest0' UND 'DataAvailable0' anstehen kann eine neue Übertragung starten. 'DataRequest1' wird vom Sender ignoriert, solange keine Daten vorhanden sind. N ist mit jeweils zwei Leitungen binaer kodiert. Die Reihenfolge von N ist so gewählt (N = 1,3,2), dass sich immer nur ein Bit ändert, um bei Flankenüberschneidungen falsche N zu vermeiden. Das Eintreffen eines unerwarteten 'DataRequestN' bzw. 'DataAvailableN' bei Sender oder Empfänger führt zu einem Abbruch der Datenübertragung durch 'DataRequest0' bzw. 'DataAvailable0'. Noch nicht gesendete Bytes eines Datenwortes gehen dabei verloren. Die Übertragung wird überwacht und im Falle von Störungen wiederholt. Zur Erkennung von Störungen auf dem Verbindungskabel werden 3 (Sender) bzw. 2 (Empfänger) Leitungen mit konstanten und komplementären Signalpegeln auf Signaleinbrüche sowohl nach High als auch nach Low überwacht. Störungen werden dadurch erkannt und registriert, dass zwischen zwei !Clock-Signalen eine überwachte Leitung sowohl High als auch Low war. Das Ergebnis wird mit einem nachfolgenden Clock überprüft und gibt Auskunft ob die mit dem vorhergehenden Clock (zwischen den beiden !Clock) übernommenen Signale gestört waren. Im Störungsfall werden 'DataRequestN' bzw. 'DataAvailableN' solange aufs Neue übernommen, bis dies fehlerfrei geklappt hat. Anfangs wurde ein deutlich schnelleres, jedoch nicht ausreichend fehlersicheres Übertragungsprotokoll verwendet: Die Übertragung eines Datenwortes (3 * 1Byte) startet mit dem Senden vom 'DataRequest'. Die Übertragung der Bytes erfolgt mit 3 Strobe-Signalen 'DataAvailable' (200ns, Pause 200ns). Um mögliche Störungen der Handshake-Signale durch den Datentransfer zu vermeiden, wird 'DataAvailable' sowohl mit Clock als auch mit !Clock übernommen und nur weiter verarbeitet, wenn beide Ergebnisse gleich sind. Bei länger andauernden Störungen kann dabei jedoch ein 'DataAvailable' völlig verloren gehen, was mit einem Timer überwacht werden muss und zu einem Datenverlust führt. Die neue, fehlersichere Übertragung mit Handshake-Protokoll benötigt mehr Zeit als die alte mit Strobe-Signalen und darüberhinaus geht die Kabellänge in die Übertragungszeit ein. Folgende Zeiten werden für den Transfer von der Rechneranpassung zum Rechner-Interface (Anfang erstes bis Ende letztes Data-Byte) benötigt. Durch das Einsynchronisieren auf die unterschiedlichen Clock-Signale von Rechneranpassung und Rechner-Interface entstehen min/häufigste/max Zeiten: altes Protokoll: 1200ns Handshake-Laufzeiten neues Protokoll 1m Kabel: 1600/1700/(1800)ns 6 *1m *5ns/m = 30ns neues Protokoll 5m Kabel: 1700/1800/1900ns 6 *5m *5ns/m = 150ns neues Protokoll 40m Kabel: 2900ns 6 *40m *5ns/m = 1200ns *EMV-Tests:* Durch periodisches Ein- und Ausschalten einer Weller 21021 Lötstation wurden in einem halb drumherum gelegten 50-pol., ca. 5m Verbindungskabel EM-Störungen erzeugt und deren Auswirkungen mit VMETST, Test Data-Routing, 10^7 Transfers, incrementierend, beobachtet. Fehlertyp 1: Wortfehler in der Form: n: expected: ABCD read: ABCD+1 Fehlertyp 2: Bitfehler in der Form: n: expected: ABCD read: XYCD n+1: expected: XYCD+1 read: ABCD+1 Fehlertyp 3: Data Errors: beim Transfer gingen Bytes verloren Fehlertyp 4: Data Errors Falschmeldung: da als Status 0xffff gelesen wird, wird fälschlicherweise ein Data Error gemeldet Ergebnisse für altes (schneller) und neues (verbesserte Fehlersicherung) Transfer-Protokoll und die verschiedenen IP-Carrier (10^7 Transfers): IP-Carrier Protokoll Typ1 Typ2 Typ3+4 VIPC616 alt 10 2 0 VIPC616 neu 1,4 1,4 0 IPC01 neu 2 5 1 Weitere Tests haben gezeigt, dass das IPC01 deutlich empfindlicher ist und insbesondere den Typ 4 auch ohne laufenden Daten-Transfer immer wieder bringt. Dabei ist sehr häufig das Auslesen des Status durch den Computer gestört (Status = 0xffff), was dann fälschlicherweise als Data-Error interpretiert wird (nur IPC01)! Passiert auch ohne Datentransfer und mit offenem Kabel! Einige Windungen des Kabels um einen Ferrit-Ring bringen möglicherweise eine Verbesserung. Das Verbinden der Abschirmflächen unter den IP-Boards mit Masse (Lötpunkte für Brücken waren vorgesehen, aber nicht gebrückt) bringt möglicherweise eine Verbesserung. Das Einlöten des zweiten Steckers zur IPC01 Seite hin (mit geerdeten Abschirmflächen) beseitigt schließlich diesen Fehlertyp 4 weitgehend, mit Ferrit-Ring (3 Windungen) auf der IPC01-Seite sogar vollständig! Danach taucht aber der Typ 2 offensichtlich verstärkt auf, und ebenso immer wieder FIFO Errors! Der geänderte VMETST liest jetzt die Daten zweimal aus und vergleicht. Dies hat gezeigt, dass beim Auslesen keine Fehler auftreten, sondern die Daten schon falsch übertragen werden. Das Problem hat sich jetzt möglicherweise auf die Routing Seite verlagert?! Ein Ferrit-Ring (3 Windungen) auf der Routingseite vermindert die Fehler deutlich (10**8 Transfers, neues Protokoll, 5m Kabel): (Wk = kleiner Ferrit, Wg = großer Ferrit) Carrier Ferrit Typ1 Typ2 Typ3 Typ4 FIFO-Errors IPC01 kein 2*10 14*10 1*10 0 ja IPC01 3Wg IPC01 45 51 0 0 ? IPC01 3Wg Routing 1 0 0 2 nein IPC01 1Wk IPC01+ 3Wg Routing 4 1 0 0 nein IPC01 3Wg IPC01+ 3Wg Routing 1 6 0 1 ja IPC01 1Wg IPC01+ 3Wg Routing 1 5 0 3 nein IPC01 1Wg IPC01+ 1Wg Routing viele viele 0 0 mehrere Der Erfolg hängt offensichtlich auch von der Anordnung der Ferrits und dem Typ ab. Großer, grüner Ferrit: IPC01 4Wg Routing 2 6 0 6 nein Großer, schwarzer, zerbrochener Ferrit: IPC01 4Wg Routing ja ja ja ja ja *Abb. 7.2.8.2 Data Transfer Zustandsautomat Rechneranpassung* (Kein Textformat-Bild vorhanden, siehe: html, pdf, dvi) *Abb 7.2.8.3 Data Transfer Zustandsautomat Rechner-Interface* (Kein Textformat-Bild vorhanden, siehe: html, pdf, dvi) 7.2.9 Rechner-Interface ----------------------- Das rechnerseitige Interface ist auf einem doppelten IP-Board (Industrie Pack) untergebracht. Es wird das gleiche IP Board Layout verwendet wie für das Control-Routing Interface, und unterscheidet sich lediglich in der Programmierung des ispLSI-Bausteins. Industrie Pack Carrier gibt es für eine ganze Reihe verschiedener Plattformen (z.B. VME, PC). Zur Zeit sind VME-Boards als Carrier im Einsatz (GreenSpring VIPC616, MicroSys IPC01, Motorola CPU-Boards MVME162, MVME172, MVME172P). Das Rechner-Interface empfängt von der Routing-Seite 2 Daten-Bytes (Data00-15) und ein Status-Byte (Data16-23), das den Status zur Zeit der Entstehung des Datenwortes enthält (Status00-07). Bei der Übertragung zum Rechner wird ein weiteres Status-Byte hinzugefügt, das den gerade aktuellen Status enthält (Status08-15). Das IP-Board besitzt je ein 16Bit-Register für Status und Daten, die mit und ohne Löschen vom Rechner gelesen werden können. Solange sie nicht gelöscht sind, werden keine neuen Daten vom Routing übertragen. Die Ein- und Ausgabe zu dem IP-Board erfolgt in 16 Bit Worten. Ein gültiges Datenwort und Routing-seitiges Status-Byte kann nur gelesen werden, wenn im Statuswort folgende Bedingungen erfüllt sind: * NOT Data transfer error * Routing online * NOT Data transfer stopped * Data ready * NOT Data transfer busy * NOT Fifo failure *Tab. 7.2.9.1 Programmierung des Rechner-Interfaces* *** Address decoding: A2 A1 A0 (Read) 0 0 0 Read Status only 0 1 0 Read Status and clear Data 1 0 0 Read Data only 1 1 0 Read and clear Data A2 A1 A0 (Write) 0 0 0 Write Control *** Bit Control word 15 Stop data transfer 14-00 not used *** Bit Data word Status word 15 Data15 Data transfer error - die Daten sind bei der Übertragung verloren gegangen 14 Data14 Routing online - das Routing ist angeschlossen und angeschaltet 13 Data13 Data transfer stopped - die Übertragung ist durch Rechner oder manuell gestoppt 12 Data12 Data ready - es steht ein Datenwort zum Lesen bereit 11 Data11 Fifo full (at Status read time) - das Fifo auf der Rechneranpassung meldet aktuell 'voll' 10 Data10 Fifo half full (at Status read time) - das Fifo auf der Rechneranpassung meldet aktuell 'halb voll' 09 Data09 Data transfer busy - es wird gerade ein Datentransfer von der Rechneranpassung zum IP-Board durchgeführt 08 Data08 Fifo failure - Funktionsstörung des Fifo auf der Rechneranpassung 07 Data07 Fifo full (at Data time) (Data23) - nach Ablage der Daten im Fifo war dieses voll 06 Data06 Fifo half full (at Data time) (Data22) - nach Ablage der Daten im Fifo war dieses mehr als halb voll 05 Data05 LFT-Bit (Data21) - Lifetime Kennungs-Bit 04 Data04 K-Bit (Data20) - Kopplungs Kennungs-Bit 03 Data03 Scanner addr. bit 3 (Data19) - Routing-Steckplatz-Kennungs-Bit 3 02 Data02 Scanner addr. bit 2 (Data18) - Routing-Steckplatz-Kennungs-Bit 2 01 Data01 Scanner addr. bit 1 (Data17) - Routing-Steckplatz-Kennungs-Bit 1 00 Data00 Scanner addr. bit 0 (Data16) - Routing-Steckplatz-Kennungs-Bit 0 7.2.10 Kopplungskarte <-> Interface-Steuerungen ----------------------------------------------- Der Kopplungs-Bus baut sich von der Kopplungskarte ausgehend nach links als Privat-Bus auf. Alle Karten sollten möglichst die Pins a und c der Leitungen 22, 23, 24 gebrückt haben, um den Kpl-Bus nicht zu unterbrechen. *LFTK:* (Lifetime Kopplung, Leitung 22) Über diese Leitung meldet die Kopplung ihre Totzeit. Es wird dazu das Lifetime-Signal _LFTQ_ der zur Kopplungskarte gehörigen IFS-Karte verwendet, die im Modus _Frei_ läuft (_K2_=0). Statt _BusyQ_ übergibt die Kopplung jedoch _BusyK_ an die IFS-Karte. high: Kopplung ist frei _LFTK = BusyK\ * GateQ_ (falls verdrahtet) *KoppK\:* (Kopplungssignal, Leitung 23) Über diese Leitung bietet die Kopplung den angeschlossenen IFS-Karten nach dem Start das Kopplungssignal an. Low: Kopplung aktiv *BusyK\:* (Busy Kopplung, Leitung 24) Auf diese Leitung geben die IFS-Karten der gekoppelten Quellen und die Kopplungskarte selber in 'wired-or'-Schaltung ihr Busy. 7.3 Schaltungsunterlagen ======================== 7.3.1 Board Interface-Steuerung ------------------------------- 7.3.2 Board Routing-Steuerung ----------------------------- *Abb. 7.3.r.2 Layout Routing-Steuerung* (Kein Textformat-Bild vorhanden, siehe: html, pdf, dvi) *Abb. 7.3.r.1 Schaltplan Routing-Steuerung* (Kein Textformat-Bild vorhanden, siehe: html, pdf, dvi) 7.3.3 Board Rechneranpassung ---------------------------- 7.3.4 Board Rechner-Interface ----------------------------- 8 Oldies ******** 8.1 Alte Routing-Steuerung ========================== Diese Variante der Routing-Steuerung war an TR86-, PDP11- und VME-Systemen im Einsatz. Sie ist inzwischen durch eine Karte mit einem hochintegrierten, programmierbaren Baustein und verbesserter Funktionalität ersetzt worden. 8.1.1 Funktion -------------- Die Routing-Steuerung koordiniert die Eingabe der Daten von den bis zu acht anschließbaren Eingabekanälen. Ein Eingabekanal besteht aus den drei funktionellen Gruppen: * Interface-Steuerung * Datenquellen-Interface * Datenquellen Im allgemeinen sind diese Funktionen auf getrennten Karten untergebracht, bzw. die Datenquellen können auch eigenständige Geräte am Experiment sein (z.B. spektroskopischer ADC). Es sind jedoch auch Einplatinen-Lösungen möglich, bei deren Einsatz aber unbedingt darauf geachtet werden muss, dass sie verschiedene Steckplatznummern belegen (Abb. 3.1.0.1). Die Routing-Steuerung ist mit zwei alternativ laufenden Scannern unterschiedlicher Priorität ausgestattet, mit denen die Eingabekanäle abgefragt werden. Sie schickt zu diesem Zweck über vier Bus-Leitungen (_SADRx_) nacheinander die Scanner-Adressen 0-15 an alle Interface-Steuerungen. Diese vergleichen die drei höchstwertigen Bits der Scanner-Adressen mit ihrer Steckplatzadresse (_PADRx_), die für jeden Steckplatz fest verdrahtet ist. Bei Gleichheit gilt der Eingabekanal als angewählt und kann bei Bedarf einer Datenübertragung mit der Routing-Steuerung kommunizieren. Der Vergleich von Scanner-Adresse und Steckplatzadresse wird von der Routing-Steuerung durch die Taktsignale _TN_ bzw. _TV_ freigegeben. Ist ein Eingabekanal angewählt und bereit zur Datenübertragung (_ReadyQ_), so teilt er dies der Routing-Steuerung durch das Signal _ReadyB_ über den Bus mit. Dies führt nach doppelter Einsynchronisierung der _Ready_-Meldung (_ReadyC_, _ReadyS_) zu einem Stop des Taktgenerators, und einer Erneuerung des, wegen der Laufzeiten durch die Interface-Steuerung bereits beendeten, _TN_ bzw. _TV_ Signals mittels _ReadyS_. Ferner wird das _ReadyS_ an die Rechneranpassung weitergegeben zur Anmeldung einer Datenübertragung. Sobald die Rechneranpassung bereit ist, ein Datenwort aufzunehmen bzw. an den Rechner weiterzuleiten, meldet sie sich mit dem Signal _RequestB_ und veranlasst damit ein Öffnen der Datengatter des angewählten Eingabekanals (Quellen-Interface). Aus den 16 Daten-Bits, dem LFT- und Kopp-Bit und den 4 Bits der Scanner-Adresse setzt die Rechneranpassung ein Datenwort zusammen (*Note Rechneranpassung::.) und überträgt es zum Rechner. Der Empfang der Daten wird von der Rechneranpassung mit den Signalen _AcceptedB_ und _AcceptedR_ quittiert. Auf der Routing-Steuerung bewirkt nach Einsynchronisierung von _AcceptedR_ die Rückflanke von _AcceptedS_ ein Weiterstarten des Taktgenerators unabhängig davon ob _ReadyB_ noch ansteht oder nicht. Die Datenquelle wird durch _AcceptedB_ im allgemeinen zu einer Normierung veranlasst, zur Vorbereitung auf das nächste Datenwort. Es besteht die Möglichkeit, einen oder mehrere Eingabekanäle mit Vorrang vor den anderen abfragen zu lassen. Dazu müssen diese Eingabekanäle einen Vorrangwunsch (_VANM_) bei der Routing-Steuerung anmelden, sobald sie bereit sind ein Datenwort zu übertragen. Diese Anmeldung kann zu jeder Zeit asynchron erfolgen. Nach jedem Scanner-Schritt _TZ_ prüft die Routing-Steuerung die _VANM_-Leitung mit _TUV_ ab und setzt den Betrieb mit dem gewünschten Scanner (Vorrang- bzw. Normal-Scanner) fort. Der jeweils ruhende Scanner behält seine Positon bei, so dass er an der unterbrochenen Stelle weiterlaufen kann. Der im Vorrangmodus arbeitende Eingabekanal muss sich des Freigabetaktes _TV_ bedienen im Gegensatz zu _TN_ für den Normalmodus. Ein Stop der Routing-Steuerung kann vom Rechner her erfolgen (_StopR_) oder über einen Schalter auf der Frontplatte. Beide bewirken ein Anhalten des Taktgenerators. Ferner wird der Stop den Eingabekanälen mitgeteilt (_StopB_) und über die Interface-Steuerung den Datenquellen. Die Scanner laufen mit 2.5MHz um, jeder Eingabekanal erhält also im Leerlauf alle 6.4us zwei Abfragen (eine mit _SADR0_=0 und eine mit _SADR0_=1). Soll ein Datenwort übertragen werden, so hält der Scanner für eine Zeit an, die im wesentlichen durch das Timing des Rechners oder der Rechneranpassung, falls diese einen FiFo Speicher besitzt, bestimmt wird (ca. 1 us). Es ist zu beachten, dass die verschiedenen Eingabekanäle von der Routing-Steuerung nicht nach einem 'first in - first out' Verfahren bearbeitet werden, sondern durch einen Scanner reihum abgefragt werden. Dies kann zur Folge haben, dass die einzelnen Eingabekanäle nicht in der Reihenfolge zum Rechner übertragen werden, in der sie zur Übertragung bereit waren. Die damit zusammenhängenden Probleme der Verkoppelung von Datenquellen z.B. bei Koinzidenzexperimenten sind jedoch berücksichtigt (*Note Kopplungskarte::.). Da den 4 Bits der Scanner-Adresse nur 3 Bits der Steckplatzadresse gegenüberstehen, kann das niederwertigste Bit der Scanner-Adresse zur Adressierung zweier Register verwendet werden. Bei Verwendung der Standard-Interface-Steuerung (IFS-Karte) macht diese bei der Lifetime-Messung von dieser Möglichkeit Gebrauch. Alle von außen zugeführten Signale werden sorgfältig einsynchronisiert (meistens doppelt, um Schaltspitzen durch Flankenüberschneidungen zu vermeiden), so dass sie asynchron zu den internen Vorgängen zugeführt werden können. 8.1.2 Bedienungselemente, Anzeigen ---------------------------------- *Schalter: Run/Stop* In Stellung _Stop_ wird die Abfrage der Eingabekanäle angehalten durch Stoppen des Taktgenerators. An die Eingabekanäle geht ein Stopsignal. Der Schalter ist disjunktiv (ODER) verknüpft mit dem Stop vom Rechner. *Anzeige: Run* Wenn weder vom Rechner noch durch den Schalter _Run/Stop_ ein Stop erfolgt, d.h. die Routing-Steuerung läuft, so leuchtet die Anzeige _Run_. *Anzeige: Ready* Solange die Routing-Steuerung den Übertragungswunsch eines Eingabekanals (_ReadyB_) bearbeitet, leuchtet die Anzeige _Ready_. *Anzeige: Vorrang* Solange die Routing-Steuerung im Vorrangmodus arbeitet, leuchtet die Anzeige _Vorrang_. 8.1.3 Schnittstellen -------------------- Signalnamen ohne Backslash '\': aktiv high Signalnamen mit Backslash '\': aktiv low Ein '^' vor dem Signalnamen: die Routing-Steuerung ist die Quelle des Signals *a) Schnittstelle zur Rechneranpassung* Die Routing-Steuerung verständigt sich mit der Rechneranpassung durch einen Hand-Shake-Dialog, zum Teil über Leitungen des Privat-Busses nach rechts. Die Routing-Steuerung muss deshalb stets direkt links von der Rechneranpassung stecken. Beide Karten sollten vorzugsweise ganz rechts im Überrahmen untergebracht werden. (*Note Überrahmen::.). *^ReadyS\* (Data Ready) Mit diesem Signal wird die Rechneranpassung von der Routing-Steuerung aufgefordert, ein Datenwort zu übernehmen. Es steht solange an bis die Rechneranpassung _AcceptedR_ sendet. *RequestB* (Data Request) Mit diesem Signal zeigt die Rechneranpassung dem angewählten Eingabekanal an, dass das Datenwort auf den Bus zu schalten ist. *AcceptedB* (Data Accepted) Mit diesem Signal quittiert die Rechneranpassung den Empfang des Datenwortes an den Eingabekanal. Durch einen Timer auf der Rechneranpassung wird dafür gesorgt, dass _AcceptedB_ mindestens 1us lang ist. Diese Verlängerung (Silena-Änderung) wurde notwendig, da z.B. der Silena-ADC eine (nicht spezifizierte) Zeit von ca. 0.5us für ein Reset benötigt. *AcceptedR* (Data Accepted) Mit diesem Signal von der Rechneranpassung wird der Routing-Steuerung mitgeteilt, dass die Übertragung beendet ist. Diese nimmt _ReadyS_ zurück und startet den aktuellen Scanner neu. *StopR\* Stop der Routing-Steuerung durch den Rechner. *^SADR(0-3)\* (Scanner-Adresse) Die Scanner-Adresse wird von der Rechneranpassung dem Datenwort als Quellenkennung beigefügt (*Note Rechneranpassung::.). *Privat-Bus-Belegung:* (Tab. 3.2.4.1) *StopR:* 25c *ReadyS:* 27c * b) Schnittstelle zu den Eingabekanälen* *^10 MHz-Clock,-Clock\* Quarzstabilisierter 10MHz Mastertakt der Routing-Steuerung. Tastverhältnis: 1:2 Stabilität: 10ppm *^1 MHz-Clock* vom Mastertakt abgeleiteter 1MHz-Takt. Tastverhältnis: 1:2 *^SADR(0-3)\* (Scanner-Adresse) Scanner-Adresse (4 Bits) zur Abfrage der Eingabekanäle. *ReadyB\* Der abgefragte Eingabekanal meldet sich bei der Routing-Steuerung mit _ReadyB_, falls er ein Datenwort übertragen will. *^StopB\* Dieses Signal teilt den Eingabekanälen mit, dass die Routing-Steuerung gestoppt wurde (manuell oder durch Rechner). *^TN, ^TV* Freigabetakte für den Adressvergleich auf den Interface-Steuerungen für Normal- (_TN_) bzw. Vorrangmodus (_TV_). *VANM\* Anmeldung eines vorrangigen Bearbeitungswunsches bei der Routing-Steuerung durch die Eingabekanäle. 8.1.4 Routing-Bus ----------------- Der Routing-Bus (Tab. 3.2.4.1) besteht aus zwei Teilen, dem 'Allgemeinen Bus', der über die ganze Breite des Überrahmens geht und dem 'Privat-Bus', der erst durch das Stecken benachbarter Karten entsteht und auf diese begrenzt ist. *Allgemeiner Bus (A-Bus)* Der allgemeine Bus belegt die Anschlüsse 1a, 1c usw. bis 21c (Tab. 3.2.4.1). Die Anschlüsse mit dem Suffix a und c führen im Gegensatz zum Privat-Bus zu verschiedenen Bus-Leitungen und dürfen nicht gebrückt werden. *Stromversorgung (Standard):* + 5V / 10A +15V / 1A -15V / 1A *DO - D15* (Datenleitungen): Sechszehn Datenleitungen stehen zur Verfügung. Low auf einer Leitung bedeutet, dass das Daten-Bit gesetzt ist. Offene Leitung heißt, das Daten-Bit ist nicht gesetzt. *Kopp-, LFT-Bit*: Diese beiden Bits sind Kennungs-Bits, die von den Interfaces gesetzt werden können. Die Standard-Interface-Steuerung (IFS-Karte) nutzt sie zur Anzeige von gekoppelten Daten bzw. bei der Lifetime-Messung. *10 MHz-Clock/-Clock\*: Quarzstabilisierter Mastertakt der Routing-Steuerung. Tastverhältnis: 1:2 Stabilität: 10ppm *1 MHz-Clock*: Vom Mastertakt abgeleiteter 1MHz Takt. Tastverhältnis: 1:2 *PADR(1-3)* (Steckplatzadresse): Für jeweils zwei benachbarte Steckplätze ist eine gemeinsame Steckplatzadresse 0-7 verdrahtet (Abb. 2.0.0.1). Die Interface-Steuerungen müssen so gesteckt werden, dass sie verschiedene Adressen einnehmen, da sie nur dann eindeutig zu adressieren sind. *SADR(0-3)* (Scanner-Adresse): Ein Steckplatz gilt als angewählt, wenn die Bits 1-3 von Steckplatz- und Scanner-Adresse übereinstimmen. Nur dann darf die Interface-Steuerung mit der Routing-Steuerung in Kontakt treten. Das Bit _SADR0_ erlaubt noch das Ansprechen zweier unterschiedlicher Datenregister eines Eingabekanals. Die Scanner-Adresse wird den übertragenen Daten von der Rechneranpassung als Quellenkennung beigefügt, um sie unterscheidbar zu machen (*Note Rechneranpassung::.). *TN, TV* (Freigabetakte für den Adressvergleich): _TN_, _TV_ erscheinen verzögert zu der Scanner-Adresse, so dass sichergestellt ist, dass die Adress-Bits eingeschwungen sind und keine Vergleichsfehler auftreten können. Ferner ermöglichen _TN,TV_ eine Unterscheidung welcher der beiden Scanner unterschiedlicher Priorität gerade aktiv ist. _TN_: Normal-Scanner _TV_: Vorrang-Scanner *VANM* (Vorrang Anmeldung): Über diese Leitung kann bei der Routing-Steuerung ein vorrangiger Bearbeitungswunsch angemeldet werden. Die Routing-Steuerung fragt in einer bestimmten Phase jedes Scan-Zyklus (Abb. 3.2.4.6) diese Leitung ab und schaltet auf den gewünschten Scanner. *ReadyB* (Data ready); *RequestB* (Data request); *AcceptedB* (Data accepted) Mit diesen drei Signalen synchronisiert sich die Datenübertragung eines vom Scanner angewählten Eingabekanals. Die Interface-Steuerung meldet _ReadyB_, falls sie Daten übertragen will. Dies hat ein Stoppen des Scanners zur Folge. Mit _RequestB_ wird die Datenquelle aufgefordert die Daten auf den Bus zu geben. Beendet wird die Übertragung mit _AcceptedB_. Mit diesem Signal wird im allgemeinen auch die Datenquelle gecleart, die dann das nächste Datenwort aufnehmen kann. *StopB*: Dieses Signal teilt allen Eingabekanälen gleichzeitig mit, dass die Routing-Steuerung gestoppt wurde. *Privat-Bus (P-Bus)* Der Privat-Bus baut sich erst durch Stecken der Karten auf. Eine fehlende Karte oder das Fehlen entsprechender Brücken auf den Karten unterbrechen den Privat-Bus. Er reicht von den Leitungen 22 bis 32 einschließlich. Die Leitungen mit dem Suffix a führen zur linken Nachbarkarte und die mit c zur rechten. Soll ein Bus aufgebaut werden, so sind die Anschlüsse a und c einer Leitung zu brücken. Die individuelle Nutzung des Privat-Busses ist den einzelnen Kartenbeschreibungen zu entnehmen (z.B. RST-, IFS-, KPL- Karten). *Tab. 8.1.4.1 Data-Routing-Bus* a Pin c ---------------------------------------------------------- Spannungs- (digital) +5V 1 +5V (digital) Spannungs- Versorgung (digital) 0V 2 0V (digital) Versorgung ---------------------------------------------------------- D0\ 3 D1\ D2\ 4 D3\ D4\ 5 D5\ D6\ 6 D7\ D8\ 7 D9\ D10\ 8 D11\ D12\ 9 D13\ D14\ 10 D15\ A-Bus Kopp-Bit\ 11 LFT-Bit\ A-Bus SADR0\ 12 1MHz-Clock SADR1\ 13 PADR1\ SADR2\ 14 PADR2\ SADR3\ 15 PADR3\ RequestB 16 ReadyB\ StopB\ 17 AcceptedB 10MHz-Clock\ 18 10MHz-Clock TV 19 TN (analog) 0V 20 VANM\ (analog) +15V 21 -15V (analog) ---------------------------------------------------------- 22 23 24 25 P-Bus 26 P-Bus 27 28 29 30 31 32 ---------------------------------------------------------- *Abb. 8.1.4.2 Symbole in den Blockdiagrammen (Abb. 8.1.4.3 - 8.1.4.5)* (Kein Textformat-Bild vorhanden, siehe: html, pdf, dvi) *Abb. 8.1.4.3 Routing-Steuerung Taktgenerator* (Kein Textformat-Bild vorhanden, siehe: html, pdf, dvi) *Abb. 8.1.4.4 Routing-Steuerung Scanner* (Kein Textformat-Bild vorhanden, siehe: html, pdf, dvi) *Abb. 8.1.4.5 Interface-Steuerung* (Kein Textformat-Bild vorhanden, siehe: html, pdf, dvi) *Abb. 8.1.4.6 Timing Routing-Steuerung* (Kein Textformat-Bild vorhanden, siehe: html, pdf, dvi) *Abb. 8.1.4.7 Timing Taktgenerator* (Kein Textformat-Bild vorhanden, siehe: html, pdf, dvi) *Abb. 8.1.4.8 Timing-Details Taktgenerator* (Kein Textformat-Bild vorhanden, siehe: html, pdf, dvi) 8.2 Alte Rechneranpassungen =========================== 8.2.1 PDP11 - DRQ11-CA - Anpassung ---------------------------------- *Aufbau der Datenwörter* Es werden die 16 Daten-Bits der Eingabedaten, die 4 Scanner-Adress-Bits, das Lifetime-Bit und das Kopplungs-Bit auf zwei 16 Bit Eingabeworte aufgeteilt und mit je einem Wortkennungs-Bit versehen (Tab. 8.2.1.1). Die Wortkennungs-Bits erlauben der Software die Unterscheidung von erstem und zweitem Eingabewort und damit die Erkennung von Datenverlusten. *Tab. 8.2.1.1 Aufbau der Datenwörter (PDP11)* Bit Wort 1 Wort 2 0 D8 D0 1 D9 D1 2 D10 D2 3 D11 D3 4 D12 D4 5 D13 D5 6 D14 D6 7 D15 D7 8 H SADR1 9 H SADR2 D0...15 Bits der Eingabedaten 10 H SDAR3 SADR0...3 Scanner-Adress-Bits 11 H H LFT Lifetime-Bit 12 H SADR0 KOPP Kopplungs-Bit 13 H LFT H High-Pegel = "0" 14 H KOPP L Low-Pegel = "1" 15 L H Bit 15 Wortkennungs-Bit 8.2.2 TR86 - CALAS - Anpassung ------------------------------ Von dieser inzwischen ersetzten Rechneranpassung existiert noch eine Reihe von Karten, deren spätere Verwendung z.B. an einem PC wegen ihrer einfachen Schnittstellen-Logik denkbar wäre. Deshalb wurde ihre ausführliche Beschreibung erhalten. Bei ihrem Einsatz muss jedoch die sogenannte Silena-Änderung auf der Routing-Steuerung berücksichtigt werden (s.h. Schaltungs-Unterlagen für PDP11-Rechneranpassung). Zwei Varianten dieser Rechneranpassungs-Karte wurden entwickelt. Eine leitet die Datenworte unmittelbar, lediglich durch Leitungstreiber verstärkt zum Rechner weiter. Die andere schiebt die Datenworte zuerst durch einen 24 Bit breiten und 64 Worte tiefen FiFo-Speicher. Der Füllstand des FiFo-Speichers wird durch LED's angezeigt und steht über Ausgänge zur Steuerung des Experimentes zur Verfügung. Der Einsatz dieser Karte ist angebracht, wenn die Daten stoßweise auftreten, jedoch nicht mehr als 64 Datenworte auf einmal. Bei statistisch ankommenden Daten ist ihr Einsatz von geringer Wirkung, falls die nachfolgende Rechner-Elektronik durch einige Speicherregister die statistischen Spitzen bereits weitgehend ausglättet. *Funktion* Die Rechneranpassungs-Karte sorgt mittels 74LS245 für das Senden und Empfangen von Daten und Steuersignalen über das Kabel zwischen Routing und Rechner. Die Schnittstelle zum Rechner besteht aus 21 Datenleitungen und 4 Steuerleitungen, über die ein einfacher 'Hand-Shake-Dialog' abläuft (Abb. 8.2.2.1). Mit dem Signal _Data Ready_ meldet das Routing dem Rechner, dass Daten bereit stehen zur Übergabe. Der Rechner fordert die Daten mit _Data Request_ an und quittiert deren Übernahme mit _Data Accepted_, worauf das Routing das _Data Ready_ zurücknimmt und nach Beendigung von _Data Accepted_ zum nächsten Eingabekanal weitergeht. Zu diesen drei Hand-Shake-Signalen kommt noch ein _Stop_-Signal hinzu, mit dem der Rechner mitteilt, dass die Datenübertragung gestoppt ist. Kritisch ist der Augenblick, in dem die Daten-Bits durchgeschaltet werden. Dies führt durch Übersprechen auf die Steuerleitungen durchweg zu erheblichen Störungsspitzen. Zwar sind die Polaritäten der Steuersignale so gewählt, dass diese Störungen keinen Einfluss auf die Funktion haben sollten, in der Praxis war dies jedoch nicht ausreichend. Folgende Effekte konnten beobachtet werden: * Die Kabelleitungen (Länge ca. 150 cm) neigen zum Schwingen, wodurch nach dem Schalten der Daten-Bits Störungen beider Polaritäten auftreten. Insbesondere kann dadurch kurzzeitig _Data Accepted_ ausgelöst werden, was ein verfrühtes Clearen von Routing-Steuerung und Datenquelle zur Folge hat. * Es gibt Datenquellen, die ihre Daten noch kurz nach _Data Request_ verändern, was zu störenden Low-high Übergängen auf den Datenleitungen führen kann. Dies führt zu den gleichen Folgen wie zuvor. * Am Ende von _Data Request_ können die nach high gehenden Datenleitungen auf der _Request_-Leitung eine solche Störung hervorrufen, dass die Daten wieder eingeschaltet werden. Diese Rückkopplung kann sich unendlich fortsetzen. Zur Unterdrückung dieser Effekte wurden _Data Accepted_ und _Data Request_ gegeneinander verriegelt. Jedes dieser Steuersignale kann nur durchkommen, wenn das andere nicht ansteht (nicht bei FiFo-Version und älteren Rechneranpassungs-Karten). Ferner wurden alle Steuerleitungen mit pull-up bzw. pull-down Widerständen und Kondensatoren belastet, um Störungen zu vermindern. *Abb. 8.2.2.1 Timing zwischen Routing und Rechner (CALAS)* (Kein Textformat-Bild vorhanden, siehe: html, pdf, dvi) *Aufbau des Datenwortes* Die Zusammenstellung des Datenwortes ist für beide Varianten der Rechneranpassungs-Karte gleich und der CALAS-Elektronik angepasst (Tab. 8.2.2.2). Die CALAS-Elektronik kennt 16 Daten-Bits (0-15), 7 Quellenkennungs-Bits (16-22) und ein Fehlerkennungs-Bit (23), mit dem das CALAS Übertragungsfehler anzeigt. Entsprechend überträgt die Rechneranpassungs-Karte 16 Daten-Bits, jedoch nur 5 Kennungs-Bits (3 Steckplatzadressen, Lifetime-Bit, Kopplungs-Bit). Mit den verbleibenden zwei Kennungs-Bits (CC-Kennung) kann die CALAS-Elektronik verschiedene direkt angeschlossene Datenquellen (z.B. Routings) unterscheiden. Als Kennungs-Bits werden die drei höchstwertigen Bits der Scanner-Adresse (SADR(1-3)=Steckplatzadresse), sowie die den Datenquellen verfügbaren Bits Lifetime-Bit (LFT-Bit) und Kopplungs-Bit (Kopp-Bit) übertragen. Die tatsächliche Anordnung der Bits im Datenwort hängt noch von der Verdrahtung im Rechner ab. Eine Standardverdrahtung zeigt die folgende Tabelle: *Tab. 8.2.2.2 Aufbau eines Datenwortes (CALAS)* Verdrahtungsvariante 1: 23 22 16 15 0 --------------------------------------- | 0 | P P P C C L K | X.............X | --------------------------------------- 7 Kennungs-Bits 16 Daten-Bits CC: 00: direkt angeschlossene Datenquellen (z.B. Testkarte '02'H) 01: 10: Routing oder direkte Datenquellen 11: Verdrahtungsvariante 2: 23 22 16 15 0 --------------------------------------- | 0 | P P P L K C C | X.............X | --------------------------------------- 7 Kennungs-Bits 16 Daten-Bits CC: 10: direkt angeschlossene Datenquellen (z.B. Testkarte '02'H) 00: 01: Routing oder direkte Datenquellen 11: PPP: Steckplatz der Datenquelle L: Lifetime-Bit K: Kopplungs-Bit *Variante mit FiFo-Speicher* Die Daten werden vom Routing entgegengenommen, durch einen 64 Worte tiefen und 24 Bit breiten FiFo-Speicher geschoben und anschliessend an den Rechner übergeben. Die Ein- und Ausgaben beim FiFo-Speicher laufen asynchron zueinander. Mit jeder Eingabe (_Ready_) und jeder Ausgabe (_Accepted_) wird ein Zähler hoch- bzw. runtergezählt zur Registrierung des Füllstandes des FiFo. Aus den drei Bits der Wertigkeit 16, 32, und 64 werden Signale abgeleitet, die den Füllstand anzeigen. Mit dem _Stop_-Signal (manuell oder Rechner) werden FiFo und Zähler gelöscht, um einen definierten Anfangszustand zu schaffen. *Anzeigen:* 1/4 - 1/1 (LED's) Über vier LED's wird der Füllstand des FiFo (1/4, 1/2, 3/4, 1/1) angezeigt. Eine LED, die leuchtet, zeigt an, dass der FiFo mindestens bis zu dem zugehörigen Wert gefüllt ist. Anzeige belegt 1/4 16-31 1/2 32-47 3/4 48-63 1/1 64 *BNC-Buchsen: 0, 1/4, 1/2, 3/4* (TTL-Ausgänge) Zur Steuerung des Experimentes können diesen Ausgängen Signale entnommen werden, die anzeigen wieviel freie Plätze im FiFo-Speicher mindestens noch frei sind. Ausgang high min. frei 0 0 1/4 16 1/2 32 3/4 48 *Simulatorkarte* Die Simulatorkarte ermöglicht das Testen einer Routing-Station ohne deren Anschluss an einen Rechner. Sie wickelt mit dem Routing den notwendigen Hand-Shake-Dialog ab, wertet die übergebenen Daten jedoch nicht aus. Die Breite der Hand-Shake-Signale _Data Request_ und _Data Accepted_ kann über Potentiometer auf der Karte eingestellt werden. (Die PDP11-DRQ11 Anpassung führt diesen Test selbständig aus, wenn die Verbindung zum Rechner offen ist.) Die Simulatorkarte kann in zwei Modi betrieben werden, die auf der Karte durch Schalter einzustellen sind: * Modus: über Routing-Bus In diesem Modus übernimmt die Simulatorkarte die Funktion der Rechneranpassungs-Karte und des Rechners. Sie muss deshalb wie die Rechneranpassungs-Karte direkt rechts neben der Routing-Steuerung plaziert werden, mit der sie sich über den Routing-Bus verständigt. Der frontseitige Kabelstecker bleibt unbenutzt. * Modus: über Kabelstecker In diesem Fall übernimmt die Simulatorkarte die Funktionen des Rechners. Vom Routing-Bus benötigt sie lediglich die Spannungsversorgung während Daten und Steuerungssignale von der Rechneranpassungs-Karte über den frontseitigen Kabelstecker zugeführt werden.