DE69831332T2

DE69831332T2 - Lokales Bus und/oder-Schnittstellenerfassungsmodul für einen Diagnoseanalysator

Info

Publication number: DE69831332T2
Application number: DE69831332T
Authority: DE
Inventors: Simon James Emmersons Green Pelly; Lynne Harper
Original assignee: Hewlett Packard Development Co LP
Current assignee: Hewlett Packard Development Co LP
Priority date: 1998-10-15
Filing date: 1998-10-15
Publication date: 2006-08-03
Anticipated expiration: 2018-10-16
Also published as: DE69831332D1; EP0994418B1; JP2000194608A; EP0994418A1; US6510532B1

Description

Für einen einheitlichen und beständigen Betrieb folgt ein Daten- und Befehlsbus zwischen ansonsten getrennten und unabhängigen entfernten Elementen – die durch den Austausch von Daten, Abfragen und Befehlen oder Anweisungen interagieren müssen – im Allgemeinen einer vorgeschriebenen Verhaltensstruktur oder einem Protokoll.
Protokoll
Der Begriff „Protokoll" wird hierin verwendet, um eine Betriebsweise oder einen Regelsatz zum Regeln – in Bezug auf Kommunikationsverkehr über einen Datenübertragungsweg oder eine Datenbahn – der Art der Verbindung oder Schnittstelle, der Art der Interaktion und des Inhalts der Informationen, der Abfrage oder des Befehls zu umfassen; beim Datenaustausch oder bei der Übertragung von Elementen oder Modulen.
Ein Protokoll kann verschiedene Betriebsregeln und -standards annehmen und vorschreiben – denen sich alle physikalische Verbindungen mit und Kommunikationsweisen über den Übertragungsweg fügen müssen, mit denen dieselben übereinstimmen und an die dieselben sich halten müssen.
Somit stellen sogenannte SCSI und PCI Beispiele allgemeiner zeitgemäßer Protokolle für eine (parallele) Buskonfiguration dar.
Bus
Der Begriff „Bus" wird hierin verwendet, um jede Form von Kommunikationskanal, Datenübertragungsweg oder -bahn zu umfassen, insbesondere, aber nicht ausschließlich, eines parallelen oder mehrfach simultanen Kanal- oder Leitungscharakters oder einer solchen Konfiguration.
Dennoch können Aspekte der Erfindung auf andere beispielsweise serielle Buskonfigurationen anwendbar sein.
Ein Bus ist allgemein eine Übertragungsleitung, die allgemein als ein Hardwaresignalweg aus physikalischen Leitern ausgedrückt oder ausgeführt ist, entweder (Versorgungs-) Kabel oder Leiterstreifen einer gedruckten Schaltungsplatine (PCB).
Als solches könnte ein Bus vielfältige Anwendung finden, beispielsweise von einer Elektrische-Versorgung-, Motor-, Getriebe- und Bremsüberwachung eines Fahrzeugs über einen Befehlsmultiplexkabelbaum bis hin zu Personalcomputern.
Abgesehen von Hardware könnte ein Bus unterbrochen werden – oder sogar teilweise gebildet werden durch – Zwischenfunk-, Optikfaser- oder Infrarotverbindungen, vorausgesetzt, ein elektrisches Signal kann an irgendeiner Stelle (z. B. dem Busabschluss) physikalisch aufgenommen werden.
Schnittstelle
Eine Interaktion zwischen einem Bus, einem Primärbefehls- und Steuerprozessor oder einer zentralen Verarbeitungseinheit (CPU) und einem (Peripherie-) Gerät findet durch eine Schnittstelle statt – die sich selbst an das Busprotokoll halten muss, die aber eine physikalische (Impedanz- oder Last-) Anpassung von ansonsten nicht kompatiblen Elementen ermöglicht, um einen Dialog zwischen denselben zu ermöglichen.
Der Begriff „Schnittstelle" wird hierin verwendet, um eine Verbindung mit einem Bus zu umfassen, allgemein durch eine physikalische Interaktion.
(Schnittstellen-) ASIC
Es ist üblich, bei einer Schnittstelle zwischen einem Bus und einem Peripheriegerät eine zweckgebundene oder maßgeschneiderte (Halbleiter-) Vorrichtungskonfiguration zu verwenden, wie z. B. eine ASIC (anwendungsspezifische integrierte Schaltung).
Eine solche „zweckgebundene" ASIC ist dann hilfreich beim Steuern von Interaktionen zwischen einem Peripheriegerät und dem Bus – und insbesondere (wenn es das Protokoll erlaubt) in einem Peripheriegerät, das eine vorübergehende Steuerung über den Bus „aktiviert" und „deaktiviert", wie es nachfolgend erörtert wird.
Einige Aspekte der vorliegenden Erfindung beziehen sich auf das Ergänzen, Verbessern oder Verstärken der Verwendung einer solchen Schnittstellen-ASIC mit zusätzlicher Funktionalität und Speicher, um lokale Bindungen zu adressieren:

• an dem Treiberausgang der ASIC; und
• dem Eingang der ASIC.

Bus- oder Schnittstellenprotokoll
Ein Bus- oder Schnittstellenprotokoll umfasst im Allgemeinen verschiedene Merkmale von Hardware und Software. Als solches kann ein Protokoll Signalpegel oder -bereiche vorgeben oder vorschreiben, und bestimmten Signalsequenzen oder -kombinationen eine bestimmte Bedeutung zuordnen.
Gemäß einer Bus- oder Schnittstellenkonfiguration kann das Protokoll auch bestimmte (Steuer-) Funktionen bestimmten einzelnen Signalleitungen oder -kanälen zuweisen oder Mehrkanalkombinationen auswählen.
Allgemein schreibt ein gegebenes Busprotokoll beabsichtigte oder vorgesehene „erlaubte" oder korrekte Bussofortsignalpegelbedingungen auf einzelnen Busleitungen vor.
Das Protokoll kann jedoch nicht übermäßig spezifisch sein bei erlaubten Abweichungen von empfohlenen oder festgelegten Pegeln – und daher in Bezug auf das, was einen „Fehler" oder eine Fehlerbedingung bilden könnte (und als solches Korrektur oder Auflösung bedarf), wie es nachfolgend erörtert wird.
Ein Protokoll kann auch Signalpegelübergänge oder -änderungen und -sequenzen definieren. Der kumulative oder kombinatorische Effekt von Signalpegeln kann auch berücksichtigt werden.
Einige, aber nicht alle Protokolle können es unterschiedlichen Peripheriegeräten vorübergehend erlauben, Befehl und Steuerung über den Bus zu übernehmen oder denselben zu „aktivieren".
Sollte ein Fehler oder eine Fehlerbedingung auftauchen, wie es nachfolgend beschrieben ist, ist es wichtig, zu wissen (an einem Bus, der dies erlaubt), welches (Peripherie-) Gerät den Bus zu dem Zeitpunkt aktiviert, um die Quelle des „abweichenden" Verhaltens genau zu lokalisieren.
Eine Form von lokaler Fehlerüberwachungsfähigkeit – wie sie durch Aspekte der vorliegenden Erfindung, die nachfolgend erörtert werden, geliefert wird – ist besonders vorteilhaft, wenn das Protokoll eine solche Peripheriegerätaktivierung erlaubt.
Unterbrechungssignale auf dem Bus könnten Weitergabe- und Rückgabesignalsequenzen einleiten, den Bus anderen Peripheriegeräten übergeben oder zurück zu einer zentralen Befehls-CPU. In der Praxis könnten in einem Computersystem das/die Peripheriegeräte in der Tat insgesamt mehr Zeit Verantwortung über den Bus haben als die CPU selbst.
Daraus folgt der Wert des Wissens, welches Gerät aktiv „aktiviert" und welche(s) Gerät(e) „passiv" ist, in jedem Abtastmoment. Wenn es den Bus nicht aktiviert, ist ein Peripheriegerät frei, Signale von dem Bus zu empfangen oder von demselben abzufragen.
Allgemein reflektiert ein Gerätezustand Signale, die auf dem Bus erfasst werden, durch eine zugeordnete Geräteschnittstelle.
Beim Betrachten der Interaktion zwischen einem Peripheriegerät und dem Bus muss folgendes getrennt oder einzeln betrachtet werden:

• der Abfluss von Signalanweisungen – in einem Bus-„Aktivierungs"- oder -Treibermodus; und
• der Zufluss von Signalen von dem Bus – in einem passiven Empfangsmodus oder getriebenen Modus.

Der passive Modus ist wesentlich, da das Peripheriegerät angewiesen werden kann, den Betriebszustand oder die Betriebsbedingung ansprechend auf empfangene Bussignaländerungen zu ändern.
Verpasste oder falsch interpretierte Bussignale können zu einer verpassten oder ausgelassenen Gerätezustandsänderung führen und zu einer nachfolgenden Unterbrechung der Gerätbetriebssequenz in Synchronisation mit dem Bus – und einer damit verbundenen Verschlechterung bei der Peripheriegerätleistungsfähigkeit.
Physikalisch gibt es eine einmalige gemeinsame Punkt- oder Knotenstelle, von oder an der sowohl ausgehende als auch ankommende Signale angetroffen werden können – für die Analyse von Businteraktionen und Buslese-Schreibfehlern, die diesem Peripheriegerät zugeordnet sind.
Ein herkömmlicher, in sich geschlossener Busanalysierer, der an einer entfernten Stelle (von dem Peripheriegerät und seiner zugeordneten Schnittstelle) verbunden ist, kann diesen kritischen Schnittstelleneingabe-/Ausgabeknoten einfach nicht adressieren oder abbilden, der ein einmaliges Signalpegelprofil hat.
Die EP-A-0403207 offenbart einen SCSI-Adapter, der ein Diagnoseteilsystem umfasst, das die Funktionalität des SCSI-Adapters überprüft, wenn derselbe in einem Unterbrechungstestmodus ist, und die Antworten verschiedener Peripheriegeräte simuliert, die durch einen SCSI-Bus an dem Adapter befestigt und von demselben getrennt sind.
Ein herkömmlicher Busanalysierer kann auch den Betriebszustand oder die Betriebsphase einzelner Peripheriegeräte nicht direkt bestimmen.
Somit ist die Bussignalbedingung – von der ein herkömmlicher Busanalysierer wesentlich abhängt – nicht im ganzen Bus einheitlich. Außerdem weist eine Bussignalbedingung nicht notwendigerweise auf eine lokale Schnittstellensignalbedingung (für jedes bestimmte Peripheriegerät) oder den Betriebszustand dieses Peripheriegeräts hin.
Die Diagnosefähigkeit eines herkömmlichen Busanalysierers ist somit beschränkt – und für eine vollständige Diagnoserolle nicht angemessen.
Da darüber hinaus ein Bus effektiv eine Übertragungsleitung ist, mit inhärenten (charakteristischen) Impedanzverlusten, ergibt sich, dass relative „nachgeschaltete" oder „vorgeschaltete" Busabgriffe einen lokalisierten Lösungsansatz nicht wiedergeben können – wie es bei Aspekten der vorliegenden Erfindung in Betracht gezogen wird. Außerdem kann ein entfernter Busanalysierer keine Zustandsänderungen einzelner Peripheriegeräte erkennen.
Somit ist ein Teil der Leistungs- und somit Fehler-Abbildung bei dem herkömmlichen entfernten Fehlersignalerfassungs- und Diagnoselösungsansatz unvollständig und potentiell unangemessen.
Als eine Übertragungsleitung können sich die Buszugriffsschnittstellen und -abschlüsse als kritisch erweisen. Somit müssen für eine effektive Signalenergieübertragung die Buslasten an die Busübertragungsleitungscharakteristika angepasst sein. Fehlanpassung kann zu störenden Signalreflektionen oder Echos führen und zugehörigen Interpretationsfehlern und Unterbrechung. Das Anpassen eines externen Busanalysierers an einen Bus kann problematisch sein.
Der Charakter oder die Art und das Ausmaß oder der Grad von Fehlern, die durch ein Busprotokoll toleriert werden können, ist allgemein nicht gut spezifiziert. Nicht alle Protokollinterpretationen durch Peripheriegerät oder in der Tat der Busaufbau oder die CPU selbst sind einheitlich beständig oder „robust".
Es kann schwierig sein, zu bestimmen, welche Fehler zu einem totalen und nicht wieder behebbaren Busausfall führen können, und welche zu einer fortlaufenden kleinen Unterbrechung, die z. B. wiederholte automatische Buszustandsrücksetzungen auslöst. Obwohl eine bestimmte Fehlertoleranz in das Protokoll eingebaut sein kann, ist ein enges oder gut spezifiziertes Protokoll im Allgemeinen weniger tolerant gegenüber Fehlern oder Abweichungen vom Standard.
Die Einhaltung von und Übereinstimmung mit einem Protokoll ist Voraussetzung einer stabilen Leistungsfähigkeit. Nichtsdestotrotz unterbricht das Abweichen oder die Nichteinhaltung des Protokolls, wie auch immer dies auftritt, die Datenübertragung und hindert die Leistungsfähigkeit der Peripheriegeräte. Eine solche Unregelmäßigkeit kann jedoch schwierig zu identifizieren sein. Darüber hinaus kann es schwierig sein, bei mehreren miteinander verbundenen Geräten, die Stelle der Fehler genau zu bestimmen.
Ein Schnittstellenstandard, wie z. B. SCSI, erfordert eine Erkennung der aktuellen Phase des Betriebsprotokolls von aktuellen Bussignalen und eine Kenntnis dessen, wie entsprechend zu (re-)agieren ist.
Bei mehreren Peripheriegeräten, die durch einen gemeinsamen Bus (miteinander) verbunden sind, können Unterschiede bei der Interpretation der (beispielsweise SCSI-) Bus- oder der Schnittstellenprotokollspezifikation und folglich der Implementierung der Entscheidungslogik Probleme verursachen.
Neben der Software können auch Hardwareprobleme im Wesentlichen aus physikalischen Faktoren entstehen, wie z. B. gelegentlichen „Störimpulsen", unzufriedenstellenden Abschlüssen oder Positionen von Peripheriegeräten – die alle die Wahrnehmung von Bussignalen beeinträchtigen können.
Test- und Fehlerbeseitigungswerkzeuge, wie z. B. proprietäre, in sich geschlossene (SCSI-) Bus- (Schnittstellen-) Analysierer werden typischerweise verwendet, um die Systemleistungsfähigkeit von der „Silizium-Entstehnung" über Funktions- oder Produkttesten bis hin zu der Gesamtsystemintegration zu überprüfen.
Im Prinzip sollte ein solcher Analysierer durch Verbindung mit dem Bus als ein „passiver" Beobachter wirken, um Informationen auf eine Signalflankenänderung oder einen Pegelübergang hin zu erfassen, und ist als solcher sinnvoll bei der Fehlerbeseitigung bei Hardware niedriger Ebene und Chips.
Protokollfehler können jedoch auch gut außerhalb von Busanalysierertesten auftreten. Falls der Fehler nicht erfasst wurde, kann er im besten Fall zeitaufwändig zum Wiedergewinnen und im schlimmsten Fall nicht zu wiederholen sein.
Darüber hinaus kann das reine Vorliegen des Analysierers auf einem Bus dessen physikalischen Charakteristika materiell ändern – potentiell zu dem Ausmaß, dass ein Fehlerproblem nicht mehr wahrgenommen wird. Diese Fehlerbedingung kann jedoch wieder auftreten, wenn der Analysierer abgetrennt wird.
In der Tat kann es sich sogar als schwierig erweisen, einen Analysierer an einem Bus zu befestigen ohne vorgeschriebene physikalische Bus- oder (Bus/Schnittstellenabzweigungs- oder -zweig-) Stichleitungslängenmaxima zu verletzen.
Bestimmte Bussignalleitungen, wie z. B. diejenigen, die mit „BSY" oder „SEL" bezeichnet sind, können durch jedes Peripheriegerät aktiviert werden, das einem normalen Protokoll folgt – daher kann der Analysierer bei einer Fehlerbedingung nicht bestimmen, welches Peripheriegerät Bussignale aktiviert.
In der Tat reflektieren Bussignalwerte, die durch einen Analysierer in einem Testmodus empfangen werden, seine (unterschiedliche) Buspositionierung – und sind so eventuell nicht gleich denjenigen, die durch ein (verdächtiges) Gerät beobachtet und interpretiert werden.
Gleichartig dazu können sich Probleme an der (Kunden-) Stelle ergeben, entfernt von Diagnosewerkzeugen oder Expertise – und erneut ist es eventuell nicht möglich, dieselben wieder zu erzeugen – mit damit verbundener Kundenunzufriedenheit.
Somit erfordert eine Fehlerkorrektur sorgfältige Überwachung, Analyse und Interpretation. Fehler können im Zusam menhang mit Störungen eines physikalischen Geräts oder einer Zwischenverbindung und einer Fehlverfolgung von Signalsequenzen auftreten, die unabhängig oder verwandt sein können.
SCSI ist ein bestimmtes Beispiel einer hochspezifischen Schnittstelle und eines hochspezifischen Busprotokolls. SCSI-konfigurierte Peripheriegeräte umfassen interne oder externe (in Relation zu einem Computer) Festplatten, Laufwerke, CD-ROMs, Drucker, Scanner, usw.
Zusammenfassung der Erfindung
Gemäß einem Aspekt der Erfindung ist eine Schnittstellenschaltung vorgesehen, die ein Erfassungsmodul umfasst, wobei die Schnittstellenschaltung zwischen einem Befehls- und Datenbus, der sich nach einem vorgeschriebenen Protokoll richtet, und einem Peripheriegerät angeordnet ist; wobei das Erfassungsmodul ein lokales Erfassungsmodul ist, das in die Schnittstellenschaltung integriert oder eingebettet ist, und konfiguriert ist, um als Teil eines Busanalysierers zu dienen, wobei das Erfassungsmodul einen ersten Speicher für temporäre Speicherung von Befehls- und Datenbussignalbedingungen und einen zweiten Speicher für temporäre Speicherung der Aktivierung oder Deaktivierung von Signalen durch das Peripheriegerät für nachfolgenden Zugriff, entfernte Analyse und Diagnose umfasst.
Der Begriff Analyse umfasst Interpretation und Bewertung.
Die Speicher können beispielsweise als RAM oder FIFO konfiguriert sein, wobei Lese-Schreib-Modi entsprechend eingestellt sind.
Die erfassten Daten umfassen sowohl:

• „korrekte", (protokoll-) konforme oder entsprechende; und
• „inkorrekte", nicht- (protokoll-) konforme, nicht-entsprechende, d. h. Fehler- oder Versagens-Signalbedingungen und/oder Betriebszustände.

Ein solches Erfassungsmodul ist herkömmlicherweise eingebaut in oder angehängt an eine Schnittstellen-ASIC eines Computer-Peripheriegeräts und konfiguriert, um eine lokale Bus- und/oder Schnittstellensignalbedingung und einen Betriebszustand des Peripheriegeräts zu erfassen, für nachfolgenden Zugriff, entfernte Analyse und Diagnose.
In der Praxis könnte das Erfassungsmodul einen Speicher umfassen, der strukturiert ist, um eine Historie von Bussignalübergängen und die Aktivierung oder Deaktivierung von Signalen durch das zugeordnete Peripheriegerät zu speichern, in dessen Schnittstelle das Modul eingebaut ist.
Die Erfindung umfasst ein Peripheriegerät, mit einer Busschnittstelle, die ein Erfassungsmodul umfasst.
Die Erfindung umfasst auch einen Computer, der durch einen Bus und eine Peripheriegerätschnittstelle mit einem Peripheriegerät verbunden ist, das ein Bus- und/oder Schnittstellenbedingungserfassungsmodul umfasst.
Gemäß einem weiteren Aspekt der Erfindung ist ein Verfahren vorgesehen, wie es in dem angehängten Anspruch 5 definiert ist.
Sowohl „korrekte" als auch „inkorrekte" Signalpegel oder Bedingungen und verwandte oder sich ergebende Peripheriegerätbetriebszustände oder Phasen könnten fortlaufend aufgezeichnet werden – einem gelegentlichen „Räumen" in einen lokalen RAM unterzogen werden, unter der Steuerung einer lokalisierten Schnittstellen- (z. B. ASIC-) Firmware, bereit für entferntes Herunterladen oder Entlasten durch Bustore für eine übertragene Analyse und Diagnose.
Falls das Peripheriegerät selbst ein großer Arbeitsspeicher ist oder einen solchen umfasst, könnte ein Teil der langfristigen (Vordiagnose-) Speicherung von Bus- und/oder Schnittstellenbedingung und Peripheriegerätzustand zugewiesen sein.
Es wird in Betracht gezogen, dass die Lokalisierung – an einer einmaligen Peripheriegerät-zu-Busschnittstelle – eines solchen Erfassungsmoduls eine detailliertere und genauere Aufzeichnung von Schnittstellenbedingungen und zugeordnetem Peripheriegerätzustand liefern würde als bisher von herkömmlichen in sich geschlossenen Busanalysierern verfügbar ist.
Kurzfristig ermöglicht dies die Diagnose von Maschinen entfernt von einem Testlabor, wie z. B. beim Kunden. Es würde auch die Trennung oder Isolation von Fehlerbedingungen ermöglichen, die sich aus einmaligen Umständen der Kundenumgebung oder -verwendung ergeben – wie z. B. Leistungsversorgungsspitzen. Langfristig sollte das Fehlerprotokoll dazu beitragen, Bedingungen, die zu Fehlern führen, „aus dem Design zu nehmen" oder eine stärkere Widerstandsfähigkeit gegenüber Fehlerbedingungen, wie z. B. störendem Rauschen, zu erreichen.
In der Praxis könnte das Erfassungsmodul in oder entlang einer bestehenden maßgefertigten Schnittstellen-ASIC implementiert sein, mit minimaler Störung der bestehenden Funktionalität. Trotzdem stünden die potentiellen Vorteile (vorteilhafterweise) in keinerlei Verhältnis zu dem relativ moderaten „Mehraufwand"-Nachteil der Implementierung.
Der Erfassungsabschnitt oder das Erfassungsmodul zeichnet beide Bussignalpegelantriebssignale auf, die durch die Schnittstellen-ASIC initiiert werden. Der erforderliche Erfassungsmodulspeicher ist relativ bescheiden, da er fortlaufend geräumt wird – beispielsweise zu einem entfernten Speicher für eine Analyse – und mit aktuelleren Busbedingungsdaten aufgefrischt wird.
Bei einer Variante ist der Erfassungsmodulspeicher praktischerweise in einem FIFO- (Zuerst-Hinein-Zuerst-Hinaus-) Betriebsspeicher-Erfindungsmodus konfiguriert.
Insgesamt wirkt das Erfassungsmodul effektiv als ein lokalisierter Erfassungsabschnitt eines „fokussierten" Busanalysierers.
Die Erfassungsoperation ist herkömmlicherweise unter der Steuerung von Firmware, die das Auftreten von Protokollfehler und Bus/Gerätrücksetzung erfassen könnte; woraufhin die Busbedingungsdaten in den lokalen Prozessorspeicher eingelesen werden könnten, für eine nachfolgend entfernte Extraktion über den Bus selbst oder durch ein maßgeschneidertes Diagnosetor oder eine Emulatorschnittstelle.
Die Lokalisierung der Protokollfehlerbedingungserfassung – durch eine Schnittstellen-ASIC – erübrigt es, sich auf Fehlermoduswiederholung unter geplanten Testbedingungen zu verlassen.
Ohne dies würde Vollspektrumfunktionstesten eine Unmenge an teuren Analysierern zur Folge haben, die sich wiederum auf statistische Wahrscheinlichkeiten verlassen, um Fehler für eine Analyse zu erfassen.
Mit einem Peripheriegerät an einer entfernten Kundenstelle können Fehlerdaten von eingebauten Erfassungsmodulen unter Verwendung eines Software-Hilfsprogramms elektronisch zu einer Diagnosebasis heruntergeladen werden. Ohne Fehlermoduswiederholung wird Fehlerbeseitigung leichter durchgeführt.
Das Erfassungsmodul speichert eine Historie von Bussignalübergängen zusammen mit Aktivierungs/Deaktivierungsfällen durch das zugeordnete Peripheriegerät. Dies wiederum ermöglicht die Isolation von Peripheriegeräten, die Protokollfehler erzeugen und eine dazugehörige Fehlerbeseitigung.
Genauer gesagt, das lokale Erfassungsmodul zeichnet die „Aktualität der Wahrnehmung und Reaktion" des Peripheriegeräts auf, das untersucht wird – anstatt einen Wert, der an einer anderen Busposition wahrgenommen wird.
Ausführungsbeispiele
Es folgt eine Beschreibung einiger bestimmter Ausführungsbeispiele von Bus- und/oder Schnittstellenerfassungsmodulen gemäß der Erfindung, lediglich beispielhaft mit Bezugnahme auf die beiliegenden schematischen Zeichnungen.
Diese Zeichnungen reflektieren Aspekte der Schaltungsanordnungskonfiguration oder des Organisationslogiklayout und der -sequenz. Es zeigen:
1 ein allgemeines Layout eines (SCSI-) Busses, der mehrere Peripheriegeräte unterstützt, jedes mit lokalisierten Bus- und/oder Schnittstellenerfassungsmodulen, die in eine jeweilige Peripheriegerätschnittstellen-ASIC eingebaut sind;
2 eine Peripheriegerät-zu-Bus-Schnittstelleneinzelheit des Layouts von 1;
3 eine Anhäufung einer lokalisierten Bussignalbedingungserfassung auf bestimmten einzelnen Busleitungen;
4A eine Dual-Peripheriegerät-Treiber- und -Passiv-Getriebener-Modus-Lokalbus- und/oder -Schnittstelle-Signalbedingungssignalerfassung;
4B ein verallgemeinertes Bus-Analysiererschema;
5 Firmware-Steuerung von Bus- und/oder Schnittstellensignalbedingung und Peripheriegerätbetriebszustandserfassung und vorübergehende Speicherung;
6 ein höher entwickeltes Schema für Bus- und/oder Schnittstellensignalbedingung und Betriebszustandserfassung;
7A und 7B Erfassungsmodul- (RAM-) Speicheradresskonfigurationen jeweils für einzelne Speicherung von Bus- und/oder Schnittstellensignalbedingung und Peripheriegerätbetriebszustand oder Phasenvektor;
8A bis 8E Betriebszustände der Speicherkonfigurationen von 7A und 7B.
Mit Bezugnahme auf die Zeichnungen unterstützt ein Bus 21 – in diesem Fall auf ein SCSI-Protokoll konfiguriert – verschiedene Peripheriegeräte 22, 32, die durch jeweilige lokale Schnittstellen 24, 34 mit dem Bus 21 verbunden sind. Der Vollständigkeit halber ist der Bus mit einem passenden Endabschlusselement 28 dargestellt. Es kann auch eine Bereitstellung (nicht gezeigt) für eine zusätzliche Peripheriegerätzwischenverbindung geben.
Der Bus 21 wird durch einen zentralen Befehlsprozessor oder CPU 12 getrieben, durch eine jeweilige lokale Schnittstelle 14. Die Peripheriegerätschnittstellen 24, 34 umfassen zweckgebundene oder maßgeschneiderte konfigurierte ASIC-Halbleitervorrichtungen.
Die Schnittstellen-ASICs umfassen oder werden unterstützt durch lokale Bus- und/oder Schnittstellen- (Bedingungs-) Erfassungsmodule (26, 36). Diese Erfassungsmodule (26, 36) leiten Anfangs- oder Einleitungsstufen dessen, was effektiv lokale Bus- und/oder Schnittstellenanalysierer sind, ein oder stellen diese dar – selbst wenn eine analytische oder diagnostische Einrichtung selbst nicht lokalisiert werden muss.
Im Prinzip erlaubt das Ausmaß der „lokalen Intelligenz" unter der Firmwaresteuerung eine gewisse Variation – von Rohdatenerfassung über eine gewisse Überwachung oder Unterscheidung von Datenerfassung und sogar vorläufiger Interpretation bis hin zu einer fokussierteren oder zweckgebundeneren Analyse und Diagnose.
Die Schnittstelle 14 der CPU 12 ist auch mit einer zweckgebundenen ASIC und einem zugeordneten Erfassungsmodul 16 dargestellt. Wie es in 2 gezeigt ist, adressiert eine zweckgebundene Peripherieschnittstellen-ASIC 41 den Bus 21 durch eine nominale Verbindung 42 und ist mit einem lokalisierten Erfassungsmodul 43 konfiguriert. Das Erfassungsmodul 43 ist effektiv Teil eines lokalen Busanalysierers.
Eine solche Erfassung hat eine doppelte Fähigkeit, die in dem herkömmlichen Busanalysiererlösungsansatz nicht verfügbar ist, nämlich:

• lokale Bus- und/oder Schnittstellensignalbedingung; und
• Peripheriegerätbetriebszustand oder -phase.

Genauer gesagt, die Bus- und/oder Schnittstellensignalbedingung ist sowohl in dem Lese- (getriebenen) oder dem Schreib- (Treiber-) Modus verfügbar – d. h., wenn das Peripheriegerät passiv auf dem Bus ist oder wenn die Schnittstelle „aktiviert hat" oder den Befehl übernommen hat, und vorübergehend den Bus treibt.
Dadurch kann genaues lokales Wissen darüber erhalten werden, welches Peripheriegerät den Bus aktiviert, wenn ein Fehler oder eine Störung auftritt – was kritisch für die Diagnose sein kann. Dies ist schwieriger entfernt zu erreichen als bei einem herkömmlichen Busanalysierer.
Die Dualität der Erfassung wird bewirkt durch zusätzliche einzelne Speicher 51, 52, die integriert oder eingebettet sind in die Schnittstellen-ASIC 41 oder ein Zusatz oder benachbart zu derselben sind – und jeweils konfiguriert sind für eine getrennte Speicherung von Bus- und/oder Schnittstellensignalbedingung und Peripheriegerätbetriebszustand. In der Praxis könnten die Speicher 51, 52 FIFOs anstatt RAM sein.
Genauer gesagt, eine fortlaufende oder selektive Aufzeichnung aufeinanderfolgender Änderungen in Bus- und/oder Schnittstellensignalbedingung und Betriebsphase des zugeordneten Peripheriegeräts 24, 34 kann in den Speichern 51, 52 gespeichert sein. Dies wird durch wiederholtes Taktzyklusschreiben erreicht.
Somit sind bei einer Betriebsvariante die Speicher 51, 52 selektiv adressierbar durch einen Speicheradresszeiger 49. Der Speicheradresszeiger 49 wird inkrementiert (d. h. bewegt oder indexiert, um eine Folgespeicheradresse zu laden) durch einen Zähler 48, der wiederum unter der Steuerung der Firmware 50 sein kann.
Regelmäßig kann die Firmware 50 anweisen, dass die Speicher 51, 52 „geräumt" werden in eine größere, langfristigere entfernte Speicherung, wie z. B. einen Prozessor-RAM 61. Alternativ könnte ein RAM-konfigurierter Speicher mit inhärent größerer Kapazität direkt geladen werden.
Die Lokalisierung von Bus- und/oder Schnittstellensignalbedingungserfassung kann bestimmte kritische Busleitungen besonders berücksichtigen. 3 zeigt die lokalisierte Bus- und/oder Schnittstellenüberwachungs- und Signalbedingungserfassung von bestimmten „SEL"- und „BSY"-Busleitungen 63, 65 – durch jeweilige Eingabe/Ausgabe-Abschnitte 66, 67 in der Schnittstellen-ASIC 41 unter der Steuerung der Firmware 50.
Taktpulssignale 69 zu der Firmware 50 von einem Zeitgeber 68 können das schrittweise Verlaufen durch eine Betriebssequenz regeln. Die Inhalte der einzelnen Speicher 51, 52 könnten durch eine Übertragungsleitung 64 regelmäßig zu einem entfernten temporären SRAM 61 geräumt werden.
4A reflektiert Bus- und/oder Schnittstellen-21-Abfragung oder Überwachung für eine fortlaufende Signalbedingungserfassung durch eine Eingabestufe 71 und eine Ausgabe- oder Treiberstufe 72 mit einer gemeinsamen Knotenverbindung zu der Busverbindung 42.
4B zeigt einen Busanalysierer 74, der sowohl eine Signalbedingung von einer Eingangsstufe 73 als auch den Zustand der Betriebslogik 75 untersucht.
5 stellt Firmware 50 dar, die aufeinanderfolgende Bus- und/oder Schnittstellensignalbedingungen der Schnittstellen-ASIC 41 umleitet, um Stellen 91, 92 in Speichern 51, 52 zu adressieren, gemäß Vergleichsauslöserkriterien 76, unter Berücksichtigung vorhergehender Bedingungen.
6 zeigt ein entwickelteres Bus- und/oder Schnittstellenschema, bei dem ein Bus 21 den Betriebszustand oder die Betriebsphase einer Peripheriegerätmaschine 98 anweist.
Es werden Vorkehrungen getroffen zum Unterbringen der „normalen" Peripheriegerätschnittstellen und der zugehörigen Logik (nicht gezeigt).
Die aktuelle Bus- und/oder Schnittstellensignalbedingung wird in einem (Bus-) Register 102 gespeichert, für den Vergleich mit einer vorhergehenden Bus- und/oder Schnittstellensignalbedingung, die in einem anderen Bus-Register 101 gespeichert wird, durch einen Komparator 103.
Jede Bedingungsänderung wird in einen Speicher 51 geladen, der wie hierin mit Bezug auf 7A beschrieben konfiguriert ist. Gleichartig dazu wird der aktuelle Peripheriegerätbetriebszustand oder die Peripheriegerätbetriebsphase in ein Zustandsregister 116 geladen.
Ein Komparator 150 vergleicht den aktuellen Peripheriegerätzustand mit einem vorhergehenden Zustand, der in einem anderen Zustandsregister 114 gespeichert wird. Jede Änderung wird einem Zustandsspeicher 52 zugeführt, dessen Konfiguration in Bezug auf 7B beschrieben ist.
Mit Bezugnahme auf 7A und 7B reduziert die Anpassung getrennter Speicher 51 bzw. 52 für Bus- und/oder Schnittstellensignalbedingung und Peripheriegerätbetriebszustand oder -phase den Gesamtspeichergrößenbedarf, da jede Änderung bei den Bussignalen ansonsten auch eine dazugehörige „Zustands"-Speicherstelle verwenden würde. Das heißt, nicht jede Bus- und/oder Schnittstellensignalbedingungsänderung wird notwendigerweise von einer Peripheriegerätbetriebszustands- oder Phasenänderung begleitet.
Obwohl die Speicher 51, 52 unabhängig arbeiten, ist der Betrieb desselben ähnlich. Somit ist die folgende Beschreibung des Betriebs des Speichers 51 relevant für den des Speichers 52.
Am Beginn einer Überwachungssequenz setzt ein Rücksetzsignal einen Zähler 48 und einen RAM-Adresszeiger 49 auf Null, wobei die Analysiererkonfiguration auf einen Analysiererbetriebsmodus gesetzt ist. Der Anfangszustand des (SCSI-) Busses wird dann in das zugeordnete RAM-Modul 51 geschrieben, unter Verwendung des ersten Adressblocks 91, woraufhin der Adresszeiger 49 inkrementiert wird.
Jede Abtastperiode – beispielsweise ein Taktzyklus – der (SCSI-) Busleitungen wird verglichen mit dem anfangs gespeicherten Wert und der Zähler 48 wird inkrementiert. Sollte zwischen dem neuen aktuellen Wert und dem vorher gespeicherten Wert ein Unterschied auftreten, wird dieser neue Wert in dem RAM 51 gespeichert, zusammen mit dem Wert des Zählers 48 zu diesem Zeitpunkt. Der Zähler 48 wird dann zurückgesetzt und der Adresszeiger 49 wird inkrementiert.
Die Busleitungsbedingungsüberwachung ist eine fortlaufende Operation, wobei die RAM-Stellenadressen 91, 92 usw. aufeinanderfolgend im Kreis übernommen werden, rund um die Größe des FIFO-Speichermodus – wobei die ältesten Daten progressiv oder inkremental überschrieben werden, so dass die letzte(n) Änderung(en) immer verfügbar sind.
Die Analyseoperation wird angehalten, um Datenlesen von den Speicherinhalten zu ermöglichen. Dies wiederum hemmt den fortlaufenden Vergleich und weiteres Schreiben in den RAM 61. Der Adresszeiger 49 wird gelesen, um zu bestimmen, welche Adresse bei der nächsten Schreiboperation verwendet worden wäre. Somit werden die ältesten Daten an dieser Adresse gespeichert und die Firmware kann alle Einträge von diesem Punkt an von dem FIFO-Speichermodus lesen, unter Berücksichtigung der (Adress-) „Umwicklung".
Diese Informationen werden in einem Prozessor-RAM 61 gespeichert, bereit für eine spätere Extraktion, wie beispielsweise durch den (SCSI-) Bus selbst, ein Diagnosetor oder Emulationswerkzeuge. Sobald dieselbe gespeichert ist, kann die Firmware die Analysiereroperation zurücksetzen, ohne die RAM-Adresse vor dem Neustart auf einen spezifischen Wert zurücksetzen zu müssen. Dieser Betriebsmodus wird nur mit einer RAM-Implementierung des Speichers benötigt.
Allgemein wird mit einer FIFO- (im Gegensatz zu beispielsweise einer RAM-) Implementierung des Speichers die Speicherung angehalten, während die Werte einer nach dem anderen von der gleichen Speicheradresse ausgelesen werden. Bei jeder Gelegenheit, bei der Daten geladen werden, verkleinert sich der Speicherstapel und „verliert" die ältesten Daten, während die Stapelkapazität „zurückgeht".
Gleichartig dazu, während Daten von der „Oberseite" des FIFO-Stapels gelesen werden, findet ein „Aufwärts"-Neuzusammensetzen von Daten statt. Wenn kein Auslesevorgang vorliegt, gehen somit die jeweils ältesten Daten verloren. Jede Implementierung ist möglich oder in der Tat eine Kombination der beiden.
Der gesamte Speicheradressblock wird nicht durch die (SCSI-) Busrücksetzung zurückgesetzt, obwohl Hardware- und Software-Rücksetzungen effektiv sind. Dies ist betriebstechnisch wesentlich. Das Peripheriegerätbetriebszustand- oder das -phasenvektorspeichererfassungsmodul 52 arbeitet auf entsprechende Weise.

12: CPU
14: CPU-Schnittstellen-ASIC
16: CPU-Schnittstellen-ASIC-Erfassungsmodul
21: (SCSI)-Bus
22: Peripheriegerät
24: Peripheriegerätbus- und/oder Schnittstellen-ASIC
26: Peripheriegerätbus- und/oder Schnittstellen-ASIC-Er
: fassungsmodul
28: Abschlusselement
32: Peripheriegerät
34: Peripheriegerätbus- und/oder Schnittstellen-ASIC
36: Peripheriegerätbus- und/oder Schnittstellen-ASIC-Er
: fassungsmodul
41: Peripheriegerätbus- und/oder Schnittstellen-ASIC
42: Nominalbus- und/oder Schnittstellenverbindung
43: lokales Bus- und/oder Schnittstellenerfassungsmodul
48: Zähler
49: Adresszeiger
50: Firmware
51: Speicher-Bussignalbedingung
52: Speicher-Peripheriegerätszustand
61: Prozessor-RAM
63: Bussignalleitung „SEL"
64: Speicherübertragung
65: Bussignalleitung-„BSY"
66: Eingabe/Ausgabegerät
67: Eingabe/Ausgabegerät
68: Zeitgeber
69: Zeitpuls
71: Eingang
72: Ausgangstreiber
73: Eingang
74: Bus-Analysierer
75: Betriebslogik
76: Auslöser
91: Speicheradresse
92: Speicheradresse
98: Betriebsmaschine
101: Busbedingungsregister
102: Busbedingungsregister
103: Busbedingungskomparator
114: Betriebszustandregister
115: Betriebszustandskomparator
116: Betriebszustandsregister

Claims

Eine Schnittstellenschaltung (41), die ein Erfassungsmodul (43) umfasst, wobei die Schnittstellenschaltung zwischen einem Befehls- und Datenbus (21), der einem vorbestimmten Protokoll entspricht, und einem Peripheriegerät angeordnet ist; wobei das Erfassungsmodul (53) ein lokales Erfassungsmodul ist, das in die Schnittstellenschaltung (41) integriert oder eingebettet ist, und konfiguriert ist, um als Teil eines Busanalysierers zu dienen, wobei das Erfassungsmodul einen ersten Speicher (51) für temporäre Speicherung von Befehls- und Datenbussignalbedingungen und einen zweiten Speicher (52) umfasst, für temporäre Speicherung von Aktivierung oder Deaktivierung von Signalen durch das Peripheriegerät für einen nachfolgenden Zugriff, eine entfernte Analyse und Diagnose.
Eine Schnittstellenschaltung gemäß Anspruch 1, bei der der oder jeder Speicher (51, 52) strukturiert ist, um eine Historie von Bussignalübergängen und die Aktivierung oder Deaktivierung von Signalen durch das Peripheriegerät zu speichern.
Ein Peripheriegerät (22) mit einer Schnittstellenschaltung (24) gemäß Anspruch 1 oder 2.
Ein Computer (12), der durch einen Bus (21) mit einem Peripheriegerät (22) verbunden ist, über eine Schnittstellenschaltung (24) gemäß einem der vorhergehenden Ansprüche.
Ein Verfahren für Busbedingungserfasssung in einer Schnittstellenschaltung, die ein Erfassungsmodul umfasst, wobei die Schnittstellenschaltung zwischen ei nem Befehls- und Datenbus, der einem vorbestimmten Protokoll entspricht, und einem Peripheriegerät angeordnet ist; wobei das Erfassungsmodul ein lokales Erfassungsmodul ist, das in die Schnittstellenschaltung integriert oder eingebettet ist, und konfiguriert ist, um als Teil eines Busanalysierers zu dienen, wobei das Verfahren folgende Schritte umfasst: lokales Überwachen von Befehls- und Datenbussignalbedingungen und Speichern von Änderungen bei den Befehls- und Datenbussignalbedingungen in einem ersten Speicher; und lokales getrenntes Überwachen der Aktivierung oder Deaktivierung von Signalen durch das Peripheriegerät und Speichern von Änderungen bei der Aktivierung oder Deaktivierung von Signalen durch das Peripheriegerät in einem zweiten Speicher für einen nachfolgenden Zugriff, eine entfernte Analyse und Diagnose.