DE102013004542A1 - Verfahren und system zur timeout-überwachung - Google Patents

Verfahren und system zur timeout-überwachung Download PDF

Info

Publication number
DE102013004542A1
DE102013004542A1 DE102013004542A DE102013004542A DE102013004542A1 DE 102013004542 A1 DE102013004542 A1 DE 102013004542A1 DE 102013004542 A DE102013004542 A DE 102013004542A DE 102013004542 A DE102013004542 A DE 102013004542A DE 102013004542 A1 DE102013004542 A1 DE 102013004542A1
Authority
DE
Germany
Prior art keywords
timeout
stream
frame
frames
command
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
DE102013004542A
Other languages
English (en)
Inventor
Ljudmil Anastasov
Karl Herz
Harald Zweck
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Infineon Technologies AG
Original Assignee
Infineon Technologies AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Infineon Technologies AG filed Critical Infineon Technologies AG
Publication of DE102013004542A1 publication Critical patent/DE102013004542A1/de
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0751—Error or fault detection not based on redundancy
    • G06F11/0754—Error or fault detection not based on redundancy by exceeding limits
    • G06F11/0757—Error or fault detection not based on redundancy by exceeding limits by exceeding a time limit, i.e. time-out, e.g. watchdogs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0721—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment within a central processing unit [CPU]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0745—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in an input/output transactions management context
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/079—Root cause analysis, i.e. error or fault diagnosis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3024—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system component is a central processing unit [CPU]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3027—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system component is a bus
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3466—Performance evaluation by tracing or monitoring
    • G06F11/3495—Performance evaluation by tracing or monitoring for systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/38—Information transfer, e.g. on bus
    • G06F13/42—Bus transfer protocol, e.g. handshake; Synchronisation
    • G06F13/4282—Bus transfer protocol, e.g. handshake; Synchronisation on a serial bus, e.g. I2C bus, SPI bus
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F5/00—Methods or arrangements for data conversion without changing the order or content of the data handled
    • G06F5/06—Methods or arrangements for data conversion without changing the order or content of the data handled for changing the speed of data flow, i.e. speed regularising or timing, e.g. delay lines, FIFO buffers; over- or underrun control therefor
    • G06F5/065—Partitioned buffers, e.g. allowing multiple independent queues, bidirectional FIFO's
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F5/00—Methods or arrangements for data conversion without changing the order or content of the data handled
    • G06F5/06—Methods or arrangements for data conversion without changing the order or content of the data handled for changing the speed of data flow, i.e. speed regularising or timing, e.g. delay lines, FIFO buffers; over- or underrun control therefor
    • G06F5/10—Methods or arrangements for data conversion without changing the order or content of the data handled for changing the speed of data flow, i.e. speed regularising or timing, e.g. delay lines, FIFO buffers; over- or underrun control therefor having a sequence of storage locations each being individually accessible for both enqueue and dequeue operations, e.g. using random access memory
    • G06F5/12—Means for monitoring the fill level; Means for resolving contention, i.e. conflicts between simultaneous enqueue and dequeue operations

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Computing Systems (AREA)
  • Mathematical Physics (AREA)
  • Computer Hardware Design (AREA)
  • Health & Medical Sciences (AREA)
  • Biomedical Technology (AREA)
  • Communication Control (AREA)
  • Bus Control (AREA)

Abstract

Ausführungsformen betreffen Systeme und Verfahren zur Timeout-Überwachung von gleichzeitig ausgeführten Befehlen oder parallelen Kommunikationskanälen, welche das Zuweisen oder Aufheben der Zuweisung jedes der Befehle oder Kommunikationskanäle zu einem entsprechenden einer Vielzahl von Timeout-Zeitgebern umfassen, wenn entsprechende Befehle übertragen werden sollen bzw. Befehlsbestätigungen empfangen werden.

Description

  • HINTERGRUND DER ERFINDUNG
  • Die vorliegende Erfindung betrifft im Allgemeinen ein Verfahren und ein System für flexible Timeout-Funktionalitäten, und insbesondere flexible Timeout-Funktionalitäten in Kommunikationskanälen zwischen Mikrocontrollern.
  • Im Folgenden wird die Erfindung zum Zwecke der Veranschaulichung unter Bezugnahme auf Timeout-Funktionalitäten in Kommunikationskanälen – in der folgenden Beschreibung nur als Kanäle bezeichnet – beschrieben, welche die Kommunikation zwischen Mikrocontrollern gemäß dem HSSL-Protokoll (High Speed Serial Link, Serielle Hochgeschwindigkeitsverbindung) ermöglichen. Die Erfindung ist jedoch nicht darauf beschränkt und kann Anwendung im Zusammenhang mit jedem anderen Typ von durch Timeout geschützten Kanälen finden.
  • Das neue HSSL-Protokoll für die Kommunikation zwischen Mikrocontrollern spezifiziert erweiterte Timeout-Funktionalitäten für die Ausführung von Befehlen. Insbesondere dienen die Timeout-Funktionalitäten zum Überwachen des Zeitraums von dem Zeitpunkt, zu dem ein entsprechender Befehlsrahmen gesendet wird, bis zu dem Zeitpunkt, zu dem ein entsprechender Antwortrahmen empfangen wird.
  • Der Antwortrahmen gibt eine erfolgreiche oder fehlerhafte Ausführung des entsprechenden Befehls an. In dem Fall, dass der überwachte Zeitraum überschritten wird, kann eine Timeout-Fehlermeldung generiert werden.
  • Ferner gibt das HSSL-Protokoll mehrere Kanäle für Befehle mit einer festgelegten Priorität an, wobei der Befehls- und der Antwortrahmen mittels Zeitmultiplexverfahren über dieselbe Schnittstelle übertragen werden.
  • Im Hinblick auf Kanalprioritäten erhalten Befehls- oder Antwortrahmen, die über einen Kanal mit einer niedrigen Kanalnummer übertragen werden, Priorität vor Befehls- oder Antwortrahmen, die über einen Kanal mit einer höheren Kanalnummer übertragen werden. Aufgrund der oben genannten Tatsache kann die Ausführung eines über einen vorbestimmten Kanal übertragenen Befehls im Wesentlichen durch Befehle verzögert werden, die über Kanäle mit einer niedrigeren Kanalnummer übertragen werden.
  • Darüber hinaus gibt das HSSL-Protokoll Pipelining für Befehle zur Handhabung großer Datenblöcke vor, die als Stream-Befehle bezeichnet werden, wobei mehrere Stream-Befehle parallel ausgeführt werden können. Folglich sollte die Timeout-Funktionalität eine parallele Überwachung mehrerer sich zeitlich überlappender Ausführungen von Stream-Befehlen vorsehen.
  • Aus diesen oder anderen Gründen besteht ein Bedarf an der vorliegenden Erfindung.
  • ZUSAMMENFASSUNG
  • Verfahren und Systeme für eine Timeout-Überwachung werden vorgesehen, im Wesentlichen wie im Zusammenhang mit wenigstens einer der Figuren gezeigt und/oder beschrieben, wie noch ausführlicher in den Ansprüchen dargelegt.
  • Gemäß einem Aspekt wird ein System zum Schützen einer Vielzahl von Kommunikationskanälen mit einem Timeout vorgesehen, das Folgendes aufweist:
    eine Vielzahl von Timeout-Zeitgebern, wobei jeder der Vielzahl von Timeout-Zeitgebern einem entsprechenden der Vielzahl von Kommunikationskanälen zugewiesen ist.
  • Zweckmäßigerweise ist jeder der Vielzahl von Timeout-Zeitgebern individuell auf einen entsprechenden einer Vielzahl von Zeitgeber-spezifischen Timeout-Zeiträumen konfigurierbar.
  • Zweckmäßigerweise ist jeder der Vielzahl von Zeitgeber-spezifischen Timeout-Zeiträumen auf einen entsprechenden einer Vielzahl von optimalen Timeout-Zeiträumen eingestellt, der spezifisch für den jeweils entsprechenden der Vielzahl von Kommunikationskanälen ist.
  • Zweckmäßigerweise ist jeder der Vielzahl von Timeout-Zeitgebern geeignet, mittels eines entsprechenden einer Vielzahl von Befehlsrahmen gestartet zu werden, der eine Arbitration für die Übertragung gewinnt und der mittels eines entsprechenden der Vielzahl von Kommunikationskanälen für die Übertragung geliefert wird.
  • Zweckmäßigerweise ist jeder der Vielzahl von Timeout-Zeitgebern geeignet, mittels eines entsprechenden einer Vielzahl von erwarteten Antwortrahmen gestoppt zu werden, die rechtzeitig ohne Fehler bei der zyklischen Redundanzprüfung (CRC-Fehler) ankommen.
  • Gemäß einem Aspekt wird ein System zum Überwachen von Pipelining-Befehlsausführungen vorgesehen, die mittels vorbestimmter Befehlsrahmen gestartet werden, wobei das System geeignet ist, die vorbestimmten Befehlsrahmen und entsprechende Bestätigungsrahmen zu empfangen und Folgendes aufweist:
    einen Schreib-Zeiger;
    einen Lese-Zeiger; und
    wenigstens zwei Timeout-Zeitgeber-Blöcke, die so konfiguriert sind, dass sie ein FIFO-Verhalten simulieren können, insofern als:
    der Schreib-Zeiger geeignet ist, einen nächsten, nicht aktiven Timeout-Zeitgeber der wenigstens zwei Timeout-Zeitgeber-Blöcke auszuwählen und zu starten, wenn einer der vorbestimmten Befehlsrahmen übertragen werden soll;
    der Lese-Zeiger geeignet ist, einen vorbestimmten, aktiven Timeout-Zeitgeber der wenigstens zwei Timeout-Zeitgeber-Blöcke bei dem Empfang des Bestätigungsrahmens, der dem einen der vorbestimmten Befehlsrahmen entspricht, der den vorbestimmten Timeout-Zeitgeber gestartet hat, auszuwählen und zu stoppen.
  • Zweckmäßigerweise ist der Schreib-Zeiger geeignet, auf denjenigen Timeout-Zeitgeber-Block der wenigstens zwei Timeout-Zeitgeber-Blöcke zu zeigen, in dem ein nächster der vorbestimmten, zu übertragenden Befehlsrahmen einen Timeout-Neuladewert, TOREL, und ein Transaktions-Tag, TTAG, des empfangenen einen der vorbestimmten Befehlsrahmen schreiben wird, um den entsprechenden Timeout-Zeitgeber zu starten.
  • Zweckmäßigerweise ist der Lese-Zeiger dazu geeignet, auf denjenigen Timeout-Zeitgeber-Block der wenigstens zwei Timeout-Zeitgeber-Blöcke zu zeigen, dessen gespeichertes Transaktions-Tag mit einem Transaktions-Tag eines aktuell empfangenen der Bestätigungsrahmen verglichen wird, um den entsprechenden Timeout-Zeitgeber zu stoppen.
  • Zweckmäßigerweise weist das System ferner einen Indikator für einen virtuellen Füllstand auf, der als EXFL (Expect FIFO Filling Level, Erwartungs-FIFO-Füllstand) bezeichnet wird, und der angibt, wie viele der wenigstens zwei Timeout-Zeitgeber-Blöcke aktiv sind.
  • Zweckmäßigerweise definiert der Timeout-Neuladewert eine Dauer eines Timeout-Zeitraums in Einheiten von vorgeteilten Taktperioden.
  • Gemäß einem Aspekt wird ein System für die parallele Timeout-Überwachung von Stream-Befehlen vorgesehen, die mittels entsprechender Stream-Befehlsrahmen, das heißt Schreib-Befehlsrahmen, die jeweils einen Datenblock mit vorbestimmter Länge aufweisen, eingeleitet werden, wobei das System Folgendes aufweist:
    eine Vielzahl von Timeout-Zeitgebern;
    einen Schreib-Zeiger, der geeignet ist, einen nächsten, nicht aktiven Timeout-Zeitgeber der Vielzahl von Timeout-Zeitgebern auszuwählen und zu starten, wenn einer der Stream-Befehlsrahmen übertragen werden soll; und
    einen Lese-Zeiger, der geeignet ist, einen vorbestimmten, aktiven Timeout-Zeitgeber der Vielzahl von Timeout-Zeitgebern bei dem Empfang eines Bestätigungsrahmens, der dem einen der Stream-Befehlsrahmen entspricht, der den vorbestimmten Timeout-Zeitgeber gestartet hat, auszuwählen und zu stoppen.
  • Zweckmäßigerweise definiert ein Timeout-Neuladewert eine Dauer eines Timeout-Zeitraums von einem der Vielzahl von Timeout-Zeitgebern.
  • Zweckmäßigerweise verwendet die Vielzahl von Timeout-Zeitgebern denselben Timeout-Neuladewert gemeinsam.
  • Zweckmäßigerweise weisen die Stream-Befehlsrahmen jeweils einen Datenblock mit einer Länge von 256 Bit auf.
  • Gemäß einem Aspekt wird ein Verfahren zum Schützen einer Vielzahl von Kommunikationskanälen mit einem Timeout vorgesehen, das Folgendes umfasst:
    Zuweisen jedes einer Vielzahl von Timeout-Zeitgebern zu einem entsprechenden der Vielzahl von Kommunikationskanälen.
  • Zweckmäßigerweise umfasst das Verfahren des Weiteren das individuelle Konfigurieren jedes der Vielzahl von Timeout-Zeitgebern auf einen entsprechenden einer Vielzahl von Zeitgeber-spezifischen Timeout-Zeiträumen.
  • Zweckmäßigerweise umfasst das individuelle Konfigurieren das Einstellen jedes der Vielzahl von Zeitgeber-spezifischen Timeout-Zeiträumen auf einen entsprechenden einer Vielzahl von optimalen Timeout-Zeiträumen, der spezifisch für den jeweils entsprechenden der Vielzahl von Kommunikationskanälen ist.
  • Zweckmäßigerweise umfasst das Verfahren ferner das Starten jedes der Vielzahl von Timeout-Zeitgebern mittels eines entsprechenden einer Vielzahl von Befehlsrahmen, der eine Arbitration für die Übertragung gewinnt und der mittels eines entsprechenden der Vielzahl von Kommunikationskanälen für die Übertragung geliefert wird.
  • Zweckmäßigerweise umfasst das Verfahren ferner das Stoppen jedes der Vielzahl von Timeout-Zeitgebern mittels eines entsprechenden einer Vielzahl von erwarteten Antwortrahmen, die rechtzeitig ohne Fehler bei der zyklischen Redundanzprüfung (CRC-Fehler) ankommen.
  • Gemäß einem Aspekt wird ein Verfahren zur parallelen Timeout-Überwachung von gleichzeitig ausgeführten Befehlen vorgesehen, wobei das Verfahren Folgendes umfasst:
    Zuweisen oder Aufheben der Zuweisung jedes der Befehle zu einem entsprechenden einer Vielzahl von Timeout-Zeitgebern in der Art und Weise eines FIFO, wenn entsprechende Befehle übertragen werden sollen bzw. Befehlsbestätigungen empfangen werden.
  • Zweckmäßigerweise umfasst das Verfahren die Verwendung eines virtuellen Erwartungs-FIFO, um die erwarteten der Befehlsbestätigungen zu verfolgen.
  • Zweckmäßigerweise weist der virtuelle Erwartungs-FIFO einen virtuellen Füllstand EXFL auf, wobei jeder neue der Befehle den virtuellen Füllstand erhöht und jede korrekt empfangene der Befehlsbestätigungen den virtuellen Füllstand verringert.
  • Zweckmäßigerweise wird kein weiterer der Befehle einem entsprechenden der Vielzahl von Timeout-Zeitgebern zugewiesen, wenn der virtuelle Füllstand des virtuellen Erwartungs-FIFO einen vorbestimmten Verfolgungs-Grenzwert überschreitet.
  • Gemäß einem Aspekt wird ein Verfahren zur parallelen Timeout-Überwachung von gleichzeitigen Stream-Befehlen vorgesehen, wobei das Verfahren Folgendes umfasst:
    Verwenden eines Schreib-Zeigers zum Auswählen und Starten eines nächsten, nicht aktiven Timeout-Zeitgebers einer Vielzahl von Timeout-Zeitgebern, wenn einer der Stream-Befehlsrahmen übertragen werden soll; und
    Verwenden eines Lese-Zeigers zum Auswählen und Stoppen eines vorbestimmten, aktiven Timeout-Zeitgebers der Vielzahl von Timeout-Zeitgebern bei dem Empfang einer Befehlsbestätigung, die dem einen der Stream-Befehle entspricht, der den vorbestimmten Timeout-Zeitgeber gestartet hat.
  • Gemäß einem Aspekt wird ein Verfahren zur Timeout-Überwachung von gleichzeitigen Befehlen oder parallelen Kommunikationskanälen vorgesehen, wobei das Verfahren Folgendes umfasst:
    Zuweisen oder Aufheben der Zuweisung jedes der Befehle oder Kommunikationskanäle zu einem entsprechenden einer Vielzahl von Timeout-Zeitgebern, wenn entsprechende Befehle übertragen werden sollen bzw. Befehlsbestätigungen empfangen werden.
  • Weitere Merkmale und Vorteile von Ausführungsformen werden aus der folgenden ausführlichen Beschreibung unter Bezugnahme auf die beigefügten Zeichnungen deutlich.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • Die begleitenden Zeichnungen sind beigefügt, um ein tieferes Verständnis zu ermöglichen, und sind in diese Schrift aufgenommen und bilden einen Teil davon. Die Zeichnungen beziehen sich auf Ausführungsformen und dienen zusammen mit der Beschreibung dazu, die Prinzipien der Erfindung zu erklären. Weitere Ausführungsformen und viele der angestrebten Vorteile von Ausführungsformen können ohne Weiteres gewürdigt werden, da sie durch Bezugnahme auf die folgende ausführliche Beschreibung besser verstanden werden.
  • 1a zeigt ein schematisches Blockdiagramm eines HSSL-Moduls (High Speed Serial Link), HSSL gemäß einem Beispiel;
  • 1b zeigt ein schematisches Blockdiagramm eines beispielhaften Moduls einer niedrigen Kommunikationsschicht, abgekürzt HSCT-Modul, gemäß einem Beispiel;
  • 1c zeigt ein schematisches Blockdiagramm der Ablaufsteuerung für einen einzelnen HSSL-Kommunikationskanal mit einem einzelnen Timeout-Zeitgeber, der die Ankunft eines letzten Antwortrahmens verfolgt, gemäß einem Beispiel;
  • 1d zeigt ein schematisches Blockdiagramm der Ablaufsteuerung für einen HSSL-Stream-Kommunikationskanal mit zwei Timeout-Zeitgebern, welche die Ankunftszeiten der letzten zwei Stream-Rahmen verfolgen, gemäß einem Beispiel;
  • 1e zeigt ein schematisches Blockdiagramm von mit einem HSSL-Modul verbundenen Schnittstellen und Bussen gemäß einem Beispiel;
  • 1f zeigt ein schematisches Blockdiagramm einer Architektur der HSSL-Schicht gemäß einem Beispiel;
  • 1g zeigt ein schematisches Blockdiagramm von Rahmenprioritäten in einem HSSL-Modul gemäß einem Beispiel;
  • 1h zeigt ein schematisches Blockdiagramm der Verwaltung für empfangene Rahmen und der Befehlsausführung über HSSL-Kanäle gemäß einem Beispiel;
  • 1i zeigt eine schematische Übersicht über die Anforderungskennzeichen und ein Beispiel für einen Kommunikationszyklus auf HSSL-Kanälen.
  • 1j zeigt ein schematisches Blockdiagramm einer Architektur von HSSL-Kanälen in dem Befehlsmodus gemäß einem Beispiel;
  • 1k zeigt ein schematisches Blockdiagramm einer Architektur eines HSSL-Stream-Kanals gemäß einem Beispiel;
  • 1l zeigt eine schematische Übersicht über HSSL-Kanalfunktionen gemäß einem Beispiel;
  • 1m zeigt ein schematisches Blockdiagramm von Busfehler-Rückmeldungspfaden in einer HSSL-Anwendung gemäß einem Beispiel;
  • 1n zeigt ein schematisches Blockdiagramm von Kreuzabhängigkeiten zwischen Stream-Rahmen und Befehlsrahmen und den entsprechenden Antwortrahmen für einen HSSL-Kanal in der Rolle eines Ziels;
  • 1o zeigt ein schematisches Blockdiagramm von Kreuzabhängigkeiten zwischen Stream-Rahmen und Befehlsrahmen und den entsprechenden Antwortrahmen für einen HSSL-Kanal in der Rolle eines Initiators;
  • 1 zeigt eine schematische Übersicht über Ereignisse, Prozesse, Verzögerungen und Signalfolgen bei einer Befehls-Timeout-Messung für Befehle gemäß einer Ausführungsform;
  • 2 zeigt eine Übersicht über die Anforderungskennzeichen und ein Beispiel für einen Kommunikationszyklus in Kanälen mit erweiterten Timeout-Funktionalitäten gemäß einer Ausführungsform;
  • 3 zeigt einen einzelnen Timeout-Funktionsblock mit erweiterten Timeout-Funktionalitäten gemäß einer Ausführungsform; und
  • 4 zeigt einen Timeout-Funktionsblock für Stream-Timeout-Funktionalitäten gemäß einer Ausführungsform; und
  • 5 zeigt Signalfolgen während einer Timeout-Messung für Stream-Rahmen in Kanälen mit erweiterten Timeout-Funktionalitäten gemäß einer Ausführungsform.
  • AUSFÜHRLICHE BESCHREIBUNG
  • In der folgenden ausführlichen Beschreibung wird auf die begleitenden Zeichnungen Bezug genommen, die einen Teil hiervon bilden und in denen zur Veranschaulichung spezifische Ausführungsformen dargestellt sind. Es versteht sich, dass weitere Ausführungsformen verwendet werden können und strukturelle oder andere Änderungen vorgenommen werden können, ohne dass von dem Schutzumfang der vorliegenden Erfindung abgewichen wird. Die folgende ausführliche Beschreibung soll daher nicht in beschränkendem Sinn aufgefasst werden, und der Schutzumfang der vorliegenden Erfindung wird durch die beigefügten Ansprüche definiert.
  • Wie oben bereits erwähnt, stellt eine Timeout-Funktionalität ein Sicherheitselement dar, um die Kommunikation zwischen einem Empfänger und einem Sender über wenigstens einen Kanal zu schützen. In der Regel ist eine geschützte Kommunikation besonders wichtig für die Übertragung von Befehlen zwischen Mikrocontrollern, um schwerwiegende Fehler zu vermeiden, die durch Befehle verursacht werden, die fehlerhaft oder zu spät empfangen werden.
  • Diese hohen Ansprüche, die an die Kommunikationen zwischen Mikrocontrollern gestellt werden, steigern sich noch, wenn eine Vielzahl von Kanälen mit unterschiedlichen Prioritäten zwischen den Mikrocontrollern vorhanden sind. Dies führt dazu, dass ein Problem auftritt, bei dem der Zeitraum für die Ausführung eines Befehls zwischen der Vielzahl von Kanälen und damit auch die optimale Einstellung für das Timeout variiert.
  • Mit anderen Worten wird in dem Fall, dass nur eine einzige Timeout-Einstellung für alle Kanäle vorhanden ist, der Zeitraum, bis zu dem ein Timeout auftritt, durch die Ausführung von Befehlen mit der niedrigsten Priorität bestimmt. Dies führt dazu, dass bei Befehlen mit höherer Priorität eine Timeout-Benachrichtigung später als notwendig ausgegeben wird.
  • Zudem besteht das Problem, das Timeout von Stream-Befehlen zu überwachen, die parallel ausgeführt werden können. Bislang war jedoch keine parallele Timeout-Überwachung für das Pipelining bei der Ausführung von Befehlen erforderlich.
  • Demgemäß kann bei einer Ausführungsform jeder Kanal seinen eigenen Timeout-Zeitgeber aufweisen, in den ein Timeout-Wert geladen werden kann, der für den jeweiligen Kanal konfigurierbar ist. Folglich können die entsprechenden kanalspezifischen Timeout-Zeitgeber optimale Timeout-Zeiträume für jeden Kanal individuell einstellen. Mit anderen Worten kann für jeden Kanal ein spezifischer optimaler Zeitraum für das Timeout von Befehlen auf diesem Kanal vorgesehen werden.
  • Im Hinblick auf Stream-Befehle kann eine weitere Ausführungsform eine Vielzahl von – beispielsweise zwei – Timeout-Zeitgeber zum Überwachen gleichzeitig ausführbarer Stream-Befehle aufweisen. Diese Vielzahl von Timeout-Zeitgebern kann wie die Elemente eines FIFO angesprochen und verwaltet werden.
  • Diesbezüglich kann ein Schreib-Zeiger einen nächsten freien der Vielzahl von Timeout-Zeitgebern als Antwort auf einen neuen Stream-Befehlsrahmen, der die Übertragung eines entsprechenden neuen Stream-Befehls startet, auswählen und starten. Des Weiteren kann ein Lese-Zeiger einen vorbestimmten der Vielzahl von Timeout-Zeitgebern als Antwort auf den vollständigen Empfang des Stream-Bestätigungsrahmens, der dem Stream-Befehlsrahmen entspricht, der den vorbestimmten der Vielzahl von Timeout-Zeitgebern gestartet hat, auswählen und stoppen.
  • Mit anderen Worten kann das FIFO-Prinzip für die Verwaltung der Vielzahl von Timeout-Zeitgebern verwendet werden, sodass die Timeout-Überwachung von parallelen Ausführungen von Stream-Befehlen ermöglicht wird.
  • Weitere Ausführungsformen werden insbesondere im Zusammenhang mit 1 bis 5 beschrieben. Zuvor erfolgt jedoch eine ausführlichere Beschreibung der Anwendung des HSSL-Moduls im Hinblick auf 1a bis 1o.
  • Im Folgenden wird eine Liste mit Abkürzungen, Akronymen und Begriffsdefinitionen bereitgestellt:
    • ACK
    Bestätigungsrahmen
    ASIC
    Application Specific Integrated Circuit (anwendungsspezifische integrierte Schaltung)
    BPI
    Bus Peripheral Interface (periphere Busschnittstelle)
    CRC
    Cyclic Redundancy Check (zyklische Redundanzprüfung)
    DMA
    Direct Memory Access (direkter Speicherzugriff)
    EMI
    Electromagnetic Interference (elektromagnetische Störung)
    EXFL
    Expect FIFO virtual Filling Level, (virtueller Füllstand des Erwartungs-FIFO)
    EXI
    Exception Interrupt (Ausnahme-Interrupt)
    FIFO
    First-in, First-out (zuerst hinein, zuerst heraus)
    HSSL
    High Speed Serial Link (serielle Hochgeschwindigkeitsverbindung)
    Initiator
    Vorrichtung, die eine HSSL-Transaktion durch Senden eines Befehlsrahmens startet
    ISB
    Initiator Stream Block (Initiator-Stream-Block)
    ISF
    Initiator Stream FIFO (Initiator-Stream-FIFO)
    JTAG
    Joint Test Action Group
    LSB
    Least Significant Bit (niedrigstwertiges Bit)
    MSB
    Most Significant Bit (höchstwertiges Bit)
    NACK
    Rahmen ”Not Acknowledge” (Ziel-Fehlerrahmen)
    SPB
    Serieller peripherer Bus
    SRI
    Shared Resource Interconnection (gemeinsam verwendete Ressourcen-Verbindung)
    SoC
    System on Chip (System auf Chip)
    Ziel
    Vorrichtung, die auf einen von einem Initiator gesendeten Befehlsrahmen antwortet
    TO
    Timeout
    TOREL
    Timeout Reload Value (Timeout-Neuladewert)
    TTAG
    Transaktions-Tag
    TTERR
    Transaktions-Tag-Fehler
    TXFIFO
    Sende-FIFO
    TXFL
    Transmit FIFO virtual Filling Level, (virtueller Füllstand des Sende-FIFO)
  • In der oben bereits erwähnten HSSL-Anwendung kann das HSSL-Modul eine Punkt-zu-Punkt-Kommunikation sowohl einzelner Datenwerte als auch großer Datenblöcke, der bereits erwähnten Streams, vorsehen. Bei den kommunizierenden Vorrichtungen, die mittels eines HSSL verbunden sind, kann es sich um komplexe Mikrocontroller handeln oder um einen Mikrocontroller und eine Vorrichtung, welche nur grundlegende Ausführungsfunktionen aufweist.
  • In einem Beispiel für die HSSL-Anwendung, wie in 1a gezeigt, können vier Kanäle vorhanden sein, um einzelne Werte zu oder von einem Ziel aus zu übertragen. Die Kanäle können direktes Schreiben von 8-, 16- oder 32-Bit-Daten von einem Initiator in das Register eines Ziels unterstützen, sowie das Lesen eines Werts aus einem Ziel, was durch den internen Master eines Moduls auf der Zielseite durchgeführt wird. Zum Übertragen großer Datenblöcke, das heißt für eine Streaming-Funktionalität, kann ein Kanal vorhanden sein, der FIFO-Speicher enthält.
  • Das HSSL-Modul kann Tasks auf der Transportschicht implementieren und die Daten an ein anderes Modul übergeben, welches Dienste auf der Sicherungsschicht und auf der Bitübertragungsschicht sowie Datenserialisierung und -übertragung vorsehen kann. Alle Übertragungen können mittels Sicherheitsfunktionen wie CRC und Timeout geschützt werden.
  • Das HSSL-Modul kann alle notwendige Protokollformate generieren, um es zwei Vorrichtungen zu ermöglichen, miteinander zu kommunizieren. Zwei grundlegende Modi können unterstützt werden. In dem Register-Übertragungsmodus kann der Sender („sendende Vorrichtung”) eine Adresse und einen Datenwert bereitstellen, indem er diese in speziell zugewiesene Register des HSSL-Moduls schreibt. Das HSSL-Modul kann die Daten in einen Umschlag – als Rahmen bezeichnet – verpacken und den Rahmen über die Bitübertragungsschicht an die Zielvorrichtung weiterleiten. Das Ziel kann die Informationen aus dem Rahmen extrahieren und die empfangenen Daten in die Adresse schreiben, die in demselben Rahmen übertragen wurde wie die Daten selbst. Wenn der Absender das Lesen des Inhalts eines Registers oder einer Speicherposition anfordert, kann er auch nur einfach die Adresse senden. Die Zielvorrichtung kann den Wert aus der angegebenen Position lesen und dem Absender bereitstellen, indem sie ihn durch einen Antwortrahmen überträgt, der sein eigenes Format aufweisen kann.
  • Die Übertragung von Register- oder Speicherinhalten kann mittels mehrerer Sicherheits- und Schutzstufen geschützt werden. Ein 16 Bit langer CRC-Wert – auch als CRC16 bezeichnet – kann an das Ende jedes Rahmens angehängt werden. Jeder Übertragungsprozess kann eine Funktionsüberwachung auslösen, die sicherstellen kann, dass die Kommunikation innerhalb eines deterministischen Zeitplans erfolgt. Die Zielvorrichtung selbst kann die Möglichkeit bieten, Zugriffsfenster zu definieren, welche das Lesen bzw. Schreiben nur aus bestimmten Adressbereichen bzw. in bestimmte Adressbereiche erlaubt.
  • Jeder Rahmen sollte von dem Ziel durch Senden eines geeigneten Antwortrahmens bestätigt werden. Wenn der Antwortrahmen nicht innerhalb eines vordefinierten Zeitfensters ankommt, kann das Initiatormodul einen Timeout-Interrupt auslösen.
  • In dem Datenstrommodus können Datenblöcke einer benutzerdefinierten Größe aus dem Speicher der sendenden Vorrichtung in den Speicher der Zielvorrichtung verlagert werden. Ein DMA-Master, der mit jeder beliebigen Quelladresse und Quell-Länge konfiguriert sein kann, holt Daten autonom ab, teilt sie in kleinere Blöcke mit programmierbarer Länge auf und stellt sie in einen FIFO.
  • Bei einer Anwendung kann ein Begleitmodul des HSSL-Moduls auf einer niedrigeren Schicht den FIFO von der „anderen Seite aus” in die physischen Leitungen leeren, welche die entsprechenden beiden Vorrichtungen verbinden. Demgemäß kann die Zielvorrichtung eine Struktur empfangen, die das Gegenstück zu dem Absendersystem ist (die Datenblöcke), diese in einen FIFO stellen, der wiederum von einem DMA-Master in den Zielspeicher geleert werden kann.
  • Bei dem Beispiel können alle Streaming-Datenübertragungen den Schutzfunktionen unterliegen, die für den Register-Übertragungsmodus verfügbar sind. Nach dem Zurücksetzen des Moduls können in einem typischen Beispiel die meisten Register nur für das Lesen für den Fernzugriff freigegeben werden. Sie müssen ggf. durch die lokale Software entsperrt werden.
  • Um eine konsistente Initialisierung eines HSSL-Kanals sicherzustellen, besteht eine Möglichkeit darin, den Merkmalssatz des HSSL-Moduls zu bestimmen, indem die JTAG-ID der Vorrichtung verwendet wird, welche die verfügbaren Hardware-Optionen des HSSL-Moduls eindeutig identifiziert. ASIC-Versionen der HSSL-Schnittstelle können nur reduzierte Instanzen nutzen.
  • In dem in 1b gezeigten Beispiel kann das Begleitmodul auf einer niedrigeren Schicht bzw. die Logik, abgekürzt HSCT-Modul, die niedrigeren Kommunikationsschichten steuern, die zwischen zwei Vorrichtungen positioniert sind, also die Sicherungsschicht und die Bitübertragungsschicht. Die Chip-zu-Chip-Schnittstelle kann für die Kommunikation zwischen Chips, zwischen einem Master-IC und einem Slave-IC eine digitale Schnittstelle nutzen. Die Schnittstelle kann in der Lage sein, in einem Master- oder in einem Slave-Modus zu laufen. Während einer Konfigurationsphase sollte die entsprechende Rolle der Schnittstelle – das heißt Master oder Slave – definiert werden. Es ist in der Regel nicht vorgesehen, die Rolle des Systems während einer Anwendung zu ändern.
  • Die Schnittstelle kann eine Vollduplex-Empfangs- und Sende-Hochgeschwindigkeits-Datenschnittstelle aufweisen, die auf zweiseitig gerichteten Differenzsignalen – das heißt insgesamt vier Leitungen – und einer Master-Taktgeber-Schnittstelle, SYS_CLK basiert. Das Master-IC kann über einen Quarzoszillator verfügen und den Takt für den Slave bereitstellen. Das Zurücksetzen der Schnittstelle kann von dem Zurücksetzen des Systems abgeleitet sein und von einer Chip-internen Rücksetzsignalisierung vorgesehen werden.
  • In einem Beispiel werden Merkmale eines HSSL beschrieben. Diesbezüglich kann ein HSSL die Übertragung von Symbolinformationen von dem Master-IC zu dem Slave-IC ermöglichen und von dem Slave-IC an den Master-IC gesendete Symbolinformationen empfangen. Der entsprechende Systemtakt kann von dem Master-IC – der über einen eigenen Quarzoszillator verfügt – an den Slave-IC bereitgestellt werden. Der HSSL kann den Austausch von Steuerinformationen in beide Richtungen ermöglichen.
  • Außerdem kann der HSSL Angaben von dem Typ „Bereit zum Senden” in beide Richtungen, von dem Typ „Unangeforderter Status” in beide Richtungen sowie eine reguläre Datenübertragung in beide Richtungen auf der Grundlage einer Vielzahl von Kanälen für Daten bereitstellen.
  • In einem Beispiel kann der Master-IC Daten mit Geschwindigkeiten von 5 MBaud und 320 MBaud übertragen. Außerdem können in einer Anwendung drei Slave-IC-Datenübertragungsgeschwindigkeiten auf der Grundlage eines 20-MHz-Systemtakts verfügbar sein, nämlich 5 MBaud (niedrige Geschwindigkeit), 20 MBaud (mittlere Geschwindigkeit) und 320 MBaud (hohe Geschwindigkeit). Des Weiteren können zwei Slave-IC-Datenübertragungsgeschwindigkeiten auf der Grundlage eines 10-MHz-Systemtakts SYS_Clk verfügbar sein, die eine geringere elektromagnetische Störung verursachen, nämlich 5 MBaud (niedrige Geschwindigkeit) und 320 MBaud (hohe Geschwindigkeit). Die Schnittstelle der HSSL-Schicht 1 kann auf LVDS-EAs gemäß IEEE 1596.3 basieren. Um den Spannungshub zu verringern, kann eine Konfigurationsoption verfügbar sein.
  • Im Folgenden wird eine Definition eines Protokolls auf hoher Ebene der HSSL-Schnittstelle beschrieben. Die HSSL-Kommunikation kann zweistufige Transaktionen umfassen, nämlich das Senden eines Befehls und ein Empfangen einer Antwort. Sie kann zwei Teilnehmer betreffen, nämlich einen Initiator, der eine Transaktion startet, indem er einen Befehl sendet, und ein Ziel, das auf den Befehl antwortet.
  • Im Folgenden werden das Generieren und die Typen von Kommunikationsrahmen beschrieben. Das HSSL-Modul kann einen seriellen Rahmen generieren, indem es die von einer CPU oder einem DMA-Modul gelieferten Nutzdaten übernimmt, diese zunächst mit einem HSSL-Rahmen umhüllt, indem es einen Header und CRC-Felder hinzufügt und dann den HSSL-Rahmen mit einem HSCT-Rahmen umhüllt, indem Felder für die Synchronisierung, den Header und das Ende-Bit hinzugefügt werden.
  • Es kann drei allgemeine Klassen von Rahmen geben, nämlich Befehlsrahmen, Antwortrahmen und Stream-Rahmen, die auch als Streaming-Rahmen bezeichnet werden. Befehlsrahmen können von dem Initiator gesendet werden, um eine Aktion durch das Ziel anzufordern. Im Folgenden werden Befehlsrahmen auch manchmal alternativ als WRT-Rahmen bezeichnet.
  • Es kann vier Typen von Befehlsrahmen geben: Erstens können Schreibrahmen von dem Initiator verwendet werden, um bei dem Ziel-Controller anzufordern, dass die Daten in die Adresse geschrieben werden, wobei beide von dem Initiator bereitgestellt werden.
  • Zweitens können Leserahmen von dem Initiator verwendet werden, um bei dem Ziel-Controller anzufordern, dass ein Inhalt von einer Adresse aus seinem Adressraum gelesen und geliefert wird.
  • Drittens können Lese-ID-Rahmen von dem Initiator verwendet werden, um bei dem Ziel-Controller anzufordern, dass ein Inhalt, der die Ziel-Vorrichtung eindeutig definiert, gelesen und geliefert wird. Bei der Antwort kann es sich um einen Standard-Datenlese-Antwortrahmen handeln.
  • Viertens können Trigger-Rahmen von dem Initiator verwendet werden, um einen Trigger-Interrupt in dem Zielmodul auszulösen.
  • Bei der oben genannten zweiten Klasse von Rahmen kann es sich um Antwortrahmen handeln. Antwortrahmen können mittels des Ziels gesendet werden, entweder um die angeforderten Daten zu liefern oder um einen erfolgreichen oder nicht erfolgreichen Abschluss einer Anforderung zu melden.
  • Es kann drei Typen von Antwortrahmen geben:
  • Erstens kann ein Datenlese-Antwortrahmen von dem Ziel verwendet werden, um die von dem Initiator mittels eines Lese-Befehlsrahmens angeforderten Daten zu liefern. Ein Datenlese-Antwortrahmen wird häufig auch einfach als Datenrahmen bezeichnet.
  • Zweitens können Bestätigungsrahmen von dem Ziel verwendet werden, um den Abschluss eines Schreib- oder Trigger-Befehls zu bestätigen. Oft wird ein Bestätigungsrahmen auch als ACK-Rahmen bezeichnet.
  • Drittens können Ziel-Fehlerrahmen von dem Ziel verwendet werden, um den erfolglosen Versuch, einen Schreib- oder Lesebefehl abzuschließen, zu melden. Oft wird ein Ziel-Fehlerrahmen auch als NACK-Rahmen bezeichnet.
  • Schließlich handelt es sich bei der oben genannten dritten allgemeinen Klasse von Rahmen um Stream-Rahmen. Stream-Rahmen können von dem Initiator-Controller verwendet werden, um Datenströme zu senden. Ein Stream-Rahmen kann sich ähnlich wie ein Schreib-Befehlsrahmen mit einem langen Datenblock mit 256 Bit verhalten. Ein Stream-Rahmen kann auf dieselbe Weise bestätigt werden. Die entsprechende Stream-Bestätigung kann jedoch, wie für einfache Befehlsrahmen, ein Schiebefenster (Sliding Window) mit einer Tiefe von zwei anstatt eins verwenden. Das entsprechende Schiebefensterprotokoll wird weiter unten im Zusammenhang mit 1c und 1d noch ausführlicher erörtert.
  • Im Folgenden werden die Typen von HSSL-Daten beschrieben. Insbesondere kann es vier Typen von HSSL-Daten geben, nämlich Stream-Blöcke mit 8 Bit, 16 Bit, 32 Bit und 256 Bit. In dem Fall von Datentypen mit 8, 16 oder 32 Bit beträgt die Anzahl der übertragenen Bits in der Regel 32, während die kürzeren Datentypen mehrfach kopiert werden können, um diese Länge zu erreichen.
  • Im Folgenden wird ein Beispiel für das CRC-Management des HSSL-Moduls beschrieben. Das HSSL-Protokoll verwendet in der Regel das CRC-16-CCITT-Polynom: x16 + x12 + x5 + 1 mit den folgenden Standardeigenschaften: Der Hexadezimalwert 0 × FFFF kann als Anfangswert gesetzt werden. Die Berechnung kann ausgehend von dem höchstwertigen Bit (MSB) durchgeführt werden, d. h. das höchstwertige Bit zuerst, nämlich von dem höchstwertigen Bit (MSB) zu dem niedrigstwertigen Bit (LSB) des Header und dann von dem höchstwertigen Bit (MSB) zu dem niedrigstwertigen Bit (LSB) der Nutzdaten. Das CRC-Ergebnis kann so ausgedrückt werden, dass es bei dem höchstwertigen Bit (MSB) beginnt.
  • Im Folgenden wird ein Beispiel für die Header-Struktur von HSSL-Rahmen beschrieben. Der HSSL-Header kann die Protokollinformationen aufweisen, die zusätzlich zu den rohen Nutzdaten erforderlich sind. Der HSSL-Header kann die Nutzdaten hinsichtlich der Länge und des Typs beschreiben und zusätzliche Informationen wie den Code für die Kanalnummer und das Transaktions-Tag übertragen. Der HSSL-Header kann außerdem in dem Fall von Rahmen ohne Nutzdaten, wie Bestätigungs- oder Trigger-Rahmen, eigenständige Informationen übertragen.
  • Im Folgenden wird ein Beispiel für die Übertragungsrichtlinien für die Übertragung von Einzelrahmen und für die Übertragung von Stream-Rahmen beschrieben. Diesbezüglich werden Übertragungen von Einzelrahmen in der Regel so durchgeführt, dass eine Bestätigung erwartet wird. Auf ähnliche Weise werden Übertragungen von Stream-Rahmen in der Regel mit Bestätigung durchgeführt. In der Regel sind nur Schreib-Streams möglich, während Lese-Streams nicht möglich sind.
  • Im Folgenden wird ein Beispiel für das Schiebefensterprotokoll beschrieben. Das HSSL-Modul kann wenigstens zwei Varianten des Schiebefensterprotokolls im Hinblick auf die Tiefe eines Schiebefensters für die Datenflusskontrolle implementieren.
  • Diesbezüglich kann für einfache Schreib-Befehlsrahmen eine Tiefe des Schiebefensters von eins verwendet werden. Die Tiefe von eins bedeutet, dass ein einzelner Timeout-Zeitgeber die Ankunft des entsprechenden Antwortrahmens verfolgen kann. Ein neuer Befehl kann nur gesendet werden, nachdem die Antwort auf den vorherigen Befehl empfangen wurde oder ein Timeout aufgetreten ist.
  • Im Gegensatz zu dem oben Dargelegten wird eine Tiefe des Schiebefensters von zwei für Stream-Rahmen verwendet. Die Tiefe von zwei bedeutet, dass es wenigstens zwei Timeout-Zeitgeber geben kann, welche die Bestätigungszeiten für die beiden letzten Stream-Rahmen verfolgen. In diesem Fall kann ein zweiter Stream-Rahmen gesendet werden, obwohl eine Bestätigung oder ein Timeout für den vorherigen Stream-Rahmen noch nicht empfangen wurde. Nach dem Beginn der Übertragung des zweiten Stream-Rahmens darf kein dritter Stream-Rahmen gesendet werden, bevor der erste Stream-Rahmen bestätigt wurde (vgl. 1d und auch 5).
  • Ein Beispiel der Kommunikation mittels des Schiebefensterprotokolls mit einer Tiefe von eins ist in 1c gezeigt. In dem Beispiel kann der Initiator Befehle senden (in 1c mit dem Großbuchstaben „A” bezeichnet, die aus ein und demselben Kanal stammen, zum Beispiel Kanal 0. Die entsprechenden Bestätigungsrahmen von dem Ziel sind in 1c mit dem Kleinbuchstaben „a” bezeichnet.
  • In dem Beispiel ist gemäß dem Schiebefensterprotokoll das Ziel in der Lage, Bestätigungsrahmen zu senden, während der Initiator in der Lage ist, Timeout-Zeitgeber zu betreiben. Jedes Mal, wenn das Ziel einen Rahmen empfängt, ohne einen Fehler zu entdecken, kann es einen Antwort- bzw. einen Bestätigungsrahmen an den Initiator senden.
  • Wenn jedoch das Ziel einen Rahmen mit einem CRC-Fehler entdeckt, sendet es keinen Bestätigungsrahmen. Die fehlende Bestätigung kann ein Timeout-Ereignis in dem Initiator-Kanal bewirken. 1d zeigt, dass wenn die Befehlsrahmen länger sind als die Bestätigungsrahmen plus der Reaktionszeit – wie zum Beispiel in dem Fall von Stream-Befehlen – Back-to-Back-Übertragungen auf einfache Weise möglich sind.
  • Im Folgenden wird ein Beispiel für das Fehlermanagement des HSSL-Protokolls beschrieben. In dem beschriebenen Beispiel definiert das HSSL-Protokoll vier Fehlertypen, nämlich Timeout-Fehler, Transaktions-Tag-Fehler, CRC-Fehler und Ziel-Fehler.
  • Ein Timeout-Fehler kann auf der Initiatorseite erkannt werden, wenn der erwartete ACK-Rahmen nicht innerhalb eines erwarteten Zeitfensters empfangen wurde. Dies kann vorkommen, wenn ein Rahmen von dem Initiator gesendet wurde und das Ziel einen CRC-Fehler erkannt und nicht mit einer Bestätigung geantwortet hat oder wenn die Verbindung zwischen dem Initiator und dem Ziel in der einen oder der anderen Richtung physisch beschädigt ist.
  • Ein Transaktions-Tag-Fehler kann auf der Initiatorseite auftreten, wenn anstelle des erwarteten ACK-Rahmens mit der erwarteten TAG-Nummer eine Bestätigung mit einem unerwarteten Transaktions-Tag empfangen wurde. Dies würde einen fehlenden Rahmen oder eine fehlende Bestätigung angeben. Ein Transaktions-Tag-Fehler kann Rahmen generieren, welche die CRC-Prüfungsstufe erfolgreich durchlaufen.
  • Ein CRC-Fehler kann in verschiedenen Fällen auftreten. Erstens kann er auf der Zielseite auftreten, wobei in diesem Fall das CRC-Fehlerkennzeichen gesetzt werden kann, der empfangene Befehlsrahmen mit dem CRC-Fehler verworfen werden kann, in der Regel kein Bestätigungsrahmen gesendet wird, und ein kanalunspezifischer EXI-Fehler-Interrupt generiert werden kann, wenn dieser aktiviert ist.
  • Zweitens kann ein CRC-Fehler auf der Initiatorseite auftreten, wobei in diesem Fall das CRC-Fehlerkennzeichen gesetzt werden kann, der empfangene Antwortrahmen mit dem CRC-Fehler verworfen werden kann und ein kanalunspezifischer EXI-Fehler-Interrupt generiert werden kann, wenn dieser aktiviert ist.
  • Beide Szenarien können zu einem Timeout auf der Initiatorseite führen. In beiden Fällen kann das CRC-Fehlerkennzeichen auf der Seite gesetzt werden, die den fehlerhaften Rahmen empfängt – d. h. entweder Initiator oder Ziel – und ein Interrupt kann generiert werden, wenn dieser aktiviert ist.
  • Zum Zweck der CRC-Fehlerinjektion kann ein Bit-Feld mit einer XOR-Maske zum Umschalten der Bits des berechneten CRC vorgesehen werden. Zum Einschalten dieser Funktion sollte das geschützte E-Bit (Endinit) durch die Anwendungssoftware gesetzt werden. Die Fehlerinjektion kann nur das Generieren des übertragenen CRC beeinflussen.
  • Ein Ziel-Fehler kann auf der Zielseite auftreten. Beim Zugriff auf den Zielspeicher kann ein Busfehler oder ein Speicherschutzfehler auftreten. In einem solchen Fall kann das Ziel mit einem NACK-Rahmen antworten, der den Fehler angibt.
  • Der folgende Teil der Beschreibung beschreibt eine beispielhafte Implementierung des HSSL-Protokolls.
  • Diesbezüglich zeigt 2 eine Übersicht über Anforderungskennzeichen und im Zusammenhang mit der entsprechenden 1i ein Beispiel eines Kommunikationszyklus in Kanälen mit erweiterten Timeout-Funktionalitäten gemäß einer Ausführungsform.
  • Bei der Ausführungsform in 2 werden Befehle auf Initiatorkanälen 230 eingeleitet. Diese Initiatorkanäle 230 können die Kanäle 0, 1, 2 und 3 sowie einen Streaming-Kanal aufweisen. Für diesen Zweck können die entsprechenden Initiator-Anforderungskennzeichen I0, I1, I2, I3 oder IS von einem TXFIFO wie in 1i gezeigt gesetzt werden.
  • Das Zurücksetzen oder Löschen eines Initiator-Anforderungskennzeichens, zum Beispiel I0, kann den Start der Übertragung eines entsprechenden Befehls und den Start eines entsprechenden einer Vielzahl von Initiator-Timeout-Zeitgebern 240 mittels Setzens eines entsprechenden Erwartungs-Kennzeichens, zum Beispiel E0, bewirken. Dieses Beispiel ist in 2 durch den Pfeil angegeben, der die Kennzeichen I0 und E0 verbindet.
  • Des Weiteren kann die Vielzahl von Initiator-Timeout-Zeitgebern 240 einen Timeout-Zeitgeber für jeden der Kanäle 0, 1, 2 und 3 sowie den Streaming-Kanal aufweisen.
  • Wenn auf den Initiatorkanälen 230 mehrere Befehlsanforderungen anstehen, kann der Initiator-Befehls-Arbiter 237 zwischen ihnen arbitrieren.
  • Zum besseren Verständnis zeigt 1i ein Beispiel eines vollständigen Kommunikationszyklus zwischen Initiator und Ziel, der in 1i durch die Kurve mit Pfeilen angegeben ist.
  • Der Befehl auf dem Kanal, welcher die Arbitration gewinnt – zum Beispiel der Befehl auf Kanal 1, wie durch das Initiator-Anforderungskennzeichen I1 in dem oben erwähnten Beispiel des Kommunikationszyklus in 1i ausgelöst – kann von einem Übertragungs-Arbiter 235 empfangen werden, der zwischen Ziel-Antwortanforderungen, die von dem Ziel-Antwort-Arbiter 236 arbitriert werden, und den Initiator-Anforderungen, die von dem Initiator-Befehls-Arbiter 237 arbitriert werden, arbitrieren kann.
  • Die entsprechende Übertragungs-Priorisierung wird außerdem ferner unten im Zusammenhang mit 1g beschrieben.
  • Der Übertragungs-Arbiter 235 kann die Übertragung des entsprechenden Befehlsrahmens über den HSSL auslösen. Die mittels der Rahmen übertragenen Informationen, wie durch den Übertragungs-Arbiter 235 arbitriert, können Informationen 270 umfassen, die sich auf Daten, die Zieladresse, den Kanal und das Transaktions-Tag des Rahmens beziehen.
  • Nach der Übertragung über den HSSL kann der Rahmen mittels eines Empfangsverteilers 245 empfangen werden. In dem in 1i gezeigten Beispiel kann der Empfangsverteiler 245 den übertragenen Befehlsrahmen an einen Ziel-Befehlsverteiler 246 weiterleiten. In dem Beispiel für den Kommunikationszyklus von 1i kann das Ziel-Anforderungskennzeichen T1 mittels des Ziel-Befehlsverteilers 246 gesetzt und mittels des Ziel-Arbiters 244 des SRI-Master 260 gelöscht werden, der in 1i auch als SRI-Master-Arbiter bezeichnet wird.
  • Nachdem der Befehl ausgeführt wurde, kann der SRI-Master 260 eine entsprechende Antwortanforderung über den Ziel-Antwortenverteiler 234 auslösen. In dem Beispiel für den Kommunikationszyklus von 1i kann das Antwort-Anforderungskennzeichen R1 mittels des Ziel-Antwortenverteilers 234 gesetzt und mittels des Ziel-Antwort-Arbiters 236 gelöscht werden.
  • Nach der entsprechenden Arbitration der Antwort mittels des Ziel-Antwort-Arbiters 236 und nachdem die entsprechende Antwort die Übertragungs-Arbitration an dem Übertragungs-Arbiter 235 gewonnen hat, kann ein entsprechender Antwortrahmen über das HSSL übertragen werden.
  • Nach dem vollständigen Empfang des Antwortrahmens an dem Initiator, der eine erfolgreiche Ausführung des ursprünglichen Befehls bei dem Ziel angibt – in dem Kommunikationszyklus von 1i – kann das Erwartungs-Kennzeichen E1 von dem Empfangsverteiler 245 über den Initiator-Antwortenverteiler 247 zurückgesetzt werden, um den entsprechenden einen der Vielzahl von Initiator-Timeout-Zeitgebern 240 für den erfolgreich ausgeführten Befehl zu stoppen. Dies stellt das Ende des Beispiels für einen vollständigen Kommunikationszyklus, wie in 1i gezeigt, dar.
  • Wie in dem Beispiel von 1e gezeigt, kann das HSSL-Modul unter Verwendung einer Schnittstelle des SRI-Master 260 mit dem SRI-Bus 255 verbunden sein, und unter Verwendung einer Slave-BPI mit dem SPB 250. Der SRI-Master 260 kann in der Lage sein, einfache und Burst-Lese- und Schreiboperationen auf dem SRI-Bus 255 durchzuführen. Zusätzlich kann ein Kernel des HSSL Logik für die Durchführung der Streaming-Kommunikation vorsehen. Die Schreib- und Lesezugriffe können in der Regel in einem Benutzermodus durchgeführt werden.
  • Bei der oben genannten SPB BPI-Schnittstelle kann es sich um eine Slave-Schnittstelle handeln, die zum Beschreiben von Registern des HSSL-Moduls mittels eines externen SPB-Master (DMA, CPU, SRI-zu-SPB-Bridge) verwendet werden kann, wodurch das HSSL-Modul konfiguriert wird und einzelne Lese- und Schreibvorgänge durchgeführt werden.
  • Im Folgenden wird ein Beispiel für den Betrieb des HSSL-Moduls beschrieben. Das HSSL-Modul kann einen separaten Sender und Empfänger aufweisen, von denen jeder die oben genannten vier Kanäle aufweist, die auch in dem Beispiel von 1f gezeigt sind. Der Sender kann einen entsprechenden Übertragungs-Arbiter-Block und einen Wrapper-Block aufweisen, die von allen Kanälen gemeinsam verwendet werden. Der Übertragungs-Arbiter kann die feste Arbitration zwischen den Kanälen vorsehen, die sendebereit sind, wenn das HSSL verfügbar ist, wobei Kanal 0 die höchste Priorität und Kanal 3 die niedrigste Priorität hat. Der Wrapper-Block kann die CRC-Daten generieren.
  • Der Empfänger kann die Umhüllung des HSSL-Rahmens entfernen, die Rahmen mit einem CRC-Fehler verwerfen und die fehlerfreien Befehle und Bestätigungen an die Kanäle verteilen. Ein gemeinsamer Vorteiler kann die Zeitbasis für alle Kanäle generieren, insbesondere für deren Timeout-Zeitgeber.
  • Der folgende Teil der Beschreibung betrifft eine Übertragungs-Priorisierung für Rahmen über einen HSSL-Kanal gemäß einem Beispiel. 1g zeigt ein Beispiel, in dem mehrere Rahmen anstehen. In diesem Fall kann eine Arbitration zwischen ihnen durchgeführt werden. Jeder Kanal kann zwei Kennzeichen aktivieren, nämlich das Initiator-Anforderungskennzeichen und das Antwort-Anforderungskennzeichen. Wie bereits im Zusammenhang mit 2 beschrieben, wird das Initiator-Anforderungskennzeichen für Kanal 0 als I0 abgekürzt und das Antwort-Anforderungskennzeichen als R0, für Kanal 1 als I1 und R1 und so weiter. Unter den Antwort- und Befehlsrahmen-Anforderungstypen können die Antwort-Anforderungstypen eine höhere Priorität haben. Unter den Anforderungen desselben Typs kann eine niedrigere Kanalnummer eine höhere Priorität haben. Ein anstehender Rahmen kann durch ein entsprechendes Anforderungskennzeichen in einem Register QFLAGS angegeben werden.
  • Der SRI-Master 260 kann die Antwortanforderungen (das heißt die Rx-Kennzeichen) setzen. Die Software-Schreibzugriffe über den SPB-Bus 250 können die Initiator-Anforderungen (das heißt die Ix-Kennzeichen) setzen. Der Übertragungs-Arbiter 235 kann die Initiator- und Antwort-Anforderungskennzeichen des Gewinners der Arbitration löschen.
  • Der folgende Teil der Beschreibung betrifft die Verwaltung von empfangenen Rahmen und die Befehlsausführung über einen HSSL-Kanal gemäß dem in 1h gezeigten Beispiel. Nachdem ein Rahmen die CRC-Prüfung bestanden hat, kann er auf seinen Typ hin geprüft werden. Ein empfangener Befehlsrahmen kann ein Ziel-Anforderungskennzeichen Tx für den SRI-Master 260 setzen, ein empfangener Antwortrahmen kann das Erwartungs-Kennzeichen Ex zurücksetzen und das jeweilige Kanal-Timeout stoppen.
  • Die Ziel-Anforderungskennzeichen Tx können von dem Ziel-Befehlsverteiler 246 gesetzt und von dem Ziel-Arbiter 244 des SRI-Master 260 gelöscht werden. Die Erwartungs-Kennzeichen Ex können mittels der Initiator-Anforderungen Ix über den Übertragungs-Arbiter 235 gesetzt und von dem Empfangsverteiler 245 zurückgesetzt werden.
  • Bei dem in 1i gezeigten Beispiel können das ISB- und das ISF-Kennzeichen zusammenwirken, um den Streaming-Vorgang zu steuern. Das ISB-Kennzeichen kann mittels der Software gesetzt werden, um das Streaming zu aktivieren. Das ISF-Kennzeichen kann mittels des TXFIFO gemäß seinem Füllstand gesetzt oder gelöscht werden.
  • Das CRC-Fehlerkennzeichen und das TTERR-Kennzeichen können sich in einem MFLAGS-Register befinden. Wenn bei dem Kanal kein Befehl ansteht und er keine Antwort erwartet, ist er bereit. Des Weiteren zeigt 1i die Übersicht über einen vollständigen Kommunikationszyklus über alle Abschnitte eines Kanals – das heißt Initiator, Ziel bzw. Empfangen, Senden.
  • In diesem Zusammenhang kann das oben erwähnte QFLAGs-Register des HSSL-Moduls relevant sein. Dieses Register kann Kennzeichen aufweisen, die angeben, ob eine geeignete Aktionsanforderung ansteht oder nicht. Die Aktionsanforderung kann in verschiedenen Stadien des in 1i gezeigten Kommunikationszyklus anstehen.
  • Das QFLAGs-Register kann die Ix-Initiator-Anforderungskennzeichen für eingeleitete Befehle aufweisen. Diese Kennzeichen können von dem entsprechenden Kanal gesetzt werden, wenn ein WRT-Befehl eingeleitet wird. Die WRT-Befehle können über den SPB-Bus eingeleitet werden. Die S(tream)-Befehle können durch das HSSL-Modul intern eingeleitet werden, mittels des TXFIFO wie in 1i angegeben, mit der Ausnahme des ersten Stream-Rahmen-Anfangs, der mittels des SPB-Busses eingeleitet werden kann.
  • Außerdem kann das QFLAGs-Register die Ziel-Anforderungskennzeichen Tx für an dem Ziel angekommene Befehle aufweisen. Diese Kennzeichen können durch die Hardware gemäß den Header-Informationen eines Rahmens gesetzt werden, der ohne CRC-Fehler bei dem Ziel angekommen ist. Sie können von dem Ziel-Arbiter 244 des SRI-Master 260 verwendet werden und gelöscht werden, wenn der geeignete Befehl ausgeführt wird.
  • Außerdem kann das QFLAGs-Register die Antwort-Anforderungskennzeichen Rx für Antwortrahmen an dem Ziel aufweisen. Nachdem ein Befehl mittels des SRI-Master 260 ausgeführt wurde, kann ein geeignetes Antwort-Anforderungskennzeichen Rx gesetzt werden, das angibt, dass ein ACK-, NACK- oder DATA-Rahmen ansteht.
  • Zusätzlich kann das QFLAGs-Register die Erwartungs-Kennzeichen Ex für die entsprechenden aktivierten Timeout-Zeitgeber aufweisen. Ein geeignetes zwei Bit langes Kennzeichen kann mittels der Hardware gesetzt werden, wenn ein Timeout-Zeitgeber für einen Kanal gestartet wird. Die Hardware kann das geeignete Kennzeichen löschen, wenn ein beliebiger Antwortrahmen bei dem Initiator ankommt. In dem Fall einer unerwarteten Antwort kann zusätzlich ein entsprechendes Kennzeichen UNEXPECTED gesetzt werden. In einem Beispiel kann der Wert 00B des Erwartungs-Kennzeichens angeben, dass keine Anforderung ansteht, der Wert 01B, dass eine Schreibanforderung ansteht, der Wert 10B, dass eine Leseanforderung ansteht, und der Wert 11B, dass eine Trigger-Anforderung ansteht.
  • Darüber hinaus kann das Register QFLAGs die entsprechenden Kennzeichen IS, RS, TS, ES für Stream-Rahmen aufweisen.
  • Im Folgenden wird die HSSL-Kanalarchitektur gemäß einem Beispiel beschrieben. 1j zeigt ein Beispiel für die Architektur der Kanäle 0, 1, 3 und des Kanals 2 in einem Befehlsmodus. Wie gezeigt, kann das HSSL-Modul die genannten vier Kanäle aufweisen.
  • Des Weiteren zeigt 1k ein Beispiel für die HSSL-Architektur von Kanal 2. In diesem Fall kann der Kanal 2 zwischen einer Befehls- und einer Streaming-Betriebsart umgeschaltet werden. In dem Einfach-Modus kann ein einzelnes Datenregister verwendet werden, und in dem Streaming-Modus kann ein FIFO verwendet werden. Kanal 2 kann einen Initiator und einen Zieladressenzähler aufweisen, der zum Füllen eines Speicherbereichs mit Daten verwendet werden kann. Jeder Adressenbereichszähler kann zwei Startadressenregister und ein Zählregister für Stream-Rahmen aufweisen. Bei Erreichen einer vordefinierten Rahmenanzahl kann automatisch ein Umlauf ausgeführt werden.
  • 1l zeigt, dass die Funktionalität jedes Kanals auf zwei Arten unterteilt werden kann. Zunächst kann die Funktionalität jedes Kanals in eine Sender- und eine Empfänger-Funktionalität unterteilt werden. Diesbezüglich kann die Übertragungsfunktionalität einen geeigneten Header für jeden Rahmen generieren, während die Empfangsfunktionalität einen geeigneten Bestätigungs-Header mit dem Tag und dem Code für die Kanalnummer generieren kann. Die Lese- und Schreibvorgänge können mittels des SRI-Master 260 durchgeführt werden. Daher kann das Modul einen Ziel-Fehlerrahmen an den Sender zurücksenden, wenn auf dem SRI-Bus 255 ein Fehler auftritt, und die Übertragung auf dem SRI-Bus 255 kann nicht ausgeführt werden. Außerdem können die Timeout-Überwachung auf der einen Seite und die Verwaltung der Bestätigungen auf der anderen Seite sowohl die Sender- als auch die Empfängerkanäle betreffen.
  • Zweitens kann – wie ferner in 1l gezeigt – die Funktionalität jedes Kanals ferner in eine Initiator- und eine Ziel-Funktionalität unterteilt werden. Die Initiator-Funktionalität kann Schreib-, Lese- oder Trigger-Befehlsrahmen in zufälliger Reihenfolge übertragen, nachdem auf den vorherigen Befehl geantwortet wurde. Zum Beispiel kann es sich bei dem Generieren oder Vergleichen eines Transaktions-Tag pro Kanal um eine Initiator-Funktionalität handeln. In dem vorliegenden Beispiel handelt es sich bei dem Timeout-Management um eine reine Initiator-Funktionalität. Schließlich kann die Ziel-Funktionalität so konfiguriert sein, dass sie Befehle empfängt, sie ausführt und Antworten generiert und überträgt.
  • Im Folgenden werden verschiedene Fälle des Bereitstellens von Bestätigungsantworten gemäß einem Beispiel erörtert. Diesbezüglich veranschaulicht 1m ein Beispiel von Busfehler-Rückmeldungspfaden. Ein Lese- oder Schreibbefehl kann mittels des SRI-Master 260 durchgeführt werden. Der SRI-Master 260 kann auf dem SRI-Bus 255 lesen oder schreiben und entweder eine erfolgreiche SRI-Transaktion oder einen Fehler signalisieren.
  • In dem Beispiel kann es die folgenden Fälle geben. Wenn der SRI-Master 260 in einen SRI-Speicher schreibt oder aus diesem liest, können beide Fälle bestätigt werden, sodass das HSSL-Modul auf jeden Fall eine Rückmeldung empfängt.
  • Wenn der SRI-Master 260 eine SPB-Adresse über die SRI- oder SPB-Bridge liest, können sowohl der erfolgreiche als auch der erfolglose Zugriff an das Modul zurück signalisiert werden.
  • Wenn der SRI-Master 260 in den SPB-Bus schreibt, kann er eine Rückmeldung liefern, wenn die Schreib-Transaktion in die Bridge erfolgreich war oder nicht, und nicht, ob die Schreib-Transaktion in das Register, das heißt den Endpunkt, erfolgreich war oder nicht. In einem solchen Fall kann das Ausführen eines Lese-Befehlsrahmens verwendet werden, um zu prüfen, ob die Schreib-Transaktion erfolgreich war.
  • Schließlich kann eine CPU eine Benachrichtigung über einen HSSL-Kanal innerhalb einer Fehler-Trap-Handhabungsroutine senden.
  • Der folgende Teil der Beschreibung betrifft Kreuzabhängigkeiten zwischen den Rahmentypen, die über einen HSSL-Kanal gemäß einem Beispiel übertragen werden. Diesbezüglich zeigt 1n ein Beispiel, bei dem es für einen Kanal in der Rolle eines Ziels Kreuzabhängigkeiten zwischen dem Ankommen eines Befehlsrahmens und dem Auslösen eines ACK- oder NACK-Rahmens für einen Kanal geben kann. Jeder mit korrektem CRC empfangene Befehlsrahmen der Typen Schreib-, Stream- oder Trigger-Rahmen kann entweder zu einem ACK oder einem NACK – das heißt einem Zielfehler-Antwortrahmen – führen. Jeder mit korrektem CRC empfangene Lese-Rahmen hat entweder einen Datenrahmen – das heißt einen Lese-Antwortrahmen – oder einen NACK-Rahmen als Ergebnis.
  • Des Weiteren kann das Generieren eines Antwortrahmens das Kopieren des Transaktions-Tag des Befehlsrahmens in den Antwortrahmen betreffen. Der Antwortrahmen kann mittels des SRI-Master 260 ausgelöst werden, der entweder eine erfolgreiche SRI-Bus-Transaktion oder einen SRI-Busfehler signalisiert. In dem Beispiel kann nur ein Trigger-Befehlsrahmen eine sofortige Bestätigung auslösen, weil er in der Regel zum Setzen eines Interrupt-Kennzeichens führt und nicht zu einer Bus-Transaktion.
  • Im Gegensatz zu dem oben Dargelegten zeigt 1o, dass es auf der Initiatorseite eine vorausschauende Kreuzabhängigkeit zwischen einem Befehlsrahmen und der erwarteten Antwort geben kann. Das Setzen eines Initiator-Anforderungskennzeichens Ix für einen bestimmten Befehl kann parallel von den folgenden Aktivitäten begleitet werden:
  • Hierbei handelt es sich um das Erfassen des aktuellen Transaktions-Tag in dem Bit-Feld ICONx (x = 0–3).CETT, das Generieren des nächsten Transaktions-Tag durch Inkrementieren eines drei Bit langen Zählers pro Kanal, ICONx (x = 0–3).ITTAG, das Starten des entsprechenden Timeout-Zählers zu dem Zeitpunkt, zu dem der Befehl die Arbitration gewinnt, und das Setzen des entsprechenden Erwartungs-Tag Ex, welches angibt, dass das Timeout läuft und ein Antwortrahmen erwartet wird.
  • Der folgende Teil der Beschreibung beschreibt den Befehlsschutz durch Befehls-Timeouts. Diesbezüglich zeigt 1 eine schematische Übersicht über Ereignisse, Prozesse, Verzögerungen und Signal- oder Kennzeichenfolgen bei einer Timeout-Messung für Befehle gemäß einer Ausführungsform. Insbesondere zeigt die obere Hälfte von 1, dass zu einem ersten Zeitpunkt 101 ein Kanal damit beginnen kann, einen Befehl zu liefern.
  • Nach einer anfänglichen Verzögerung 103 und einer ersten Verzögerung 105 des Moduls für die Bitübertragungsschicht und die Sicherungsschicht – das heißt des HSCT-Moduls – kann zu einem zweiten Zeitpunkt 109 eine Befehlsübertragung gestartet werden, indem ein Befehlsrahmen 110 über den Kanal gesendet wird. Eine Deaktivierung einer Eingabe von dem Typ „Bereit zum Senden” des HSSL-Moduls während des Zeitraums der anfänglichen Verzögerung 103 kann die Übertragung in dieser Phase stoppen.
  • Des Weiteren kann nach einer Antwortverzögerung 115 ein Antwortrahmen 120 auf den Befehlsrahmen 110 über den Kanal übertragen werden, um den korrekten Empfang des Befehlsrahmens 110 zu bestätigen. Die entsprechende Übertragung der Antwort kann zu einem dritten Zeitpunkt 121 enden.
  • Nach einer zweiten Verzögerung 125 des HSCT-Moduls und einer Endverzögerung 126 kann der Kanal das Empfangen der Antwort auf den Befehl zu einem vierten Zeitpunkt 129 abschließen.
  • Die untere Hälfte von 1 zeigt Signalfolgen von vorbestimmten Kennzeichen, die das Starten und Stoppen eines Timeout-Zeitgebers auslösen können. Wie bereits zuvor gibt der Platzhalter „x” in einer Kennzeichen-ID die Tatsache an, dass sich das entsprechende Kennzeichen auf einen beliebigen eines Satzes von vorbestimmten Kanälen bezieht, zum Beispiel auf die Kanäle „0”, „1”, „2”, „3” und einen Streaming-Kanal „s”.
  • Aus der Perspektive des Erwartungs-Kennzeichens Ex kann das Timeout mit der steigenden Flanke 104 des Erwartungs-Kennzeichens Ex starten und kann mit seiner fallenden Flanke 128 enden. Das Erwartungs-Kennzeichen Ex kann durch die fallende Flanke des Initiator-Anforderungskennzeichen Ix für den entsprechenden Befehl gesetzt werden, das zurückgesetzt werden kann, wenn die Befehlsanforderung die Übertragungs-Arbitration gewinnt. Während des Zeitintervalls 150 kann das entsprechende Anforderungskennzeichen Ix deaktiviert werden, damit es wieder gesetzt werden kann.
  • Wenn der dem Befehlsrahmen 110 entsprechende Antwortrahmen 120 nicht angekommen ist und der Timeout-Zeitgeber null erreicht, kann der Timeout-Zeitgeber gestoppt werden, es kann ein Timeout-Fehler ausgelöst werden, und das Erwartungs-Kennzeichen Ex kann gelöscht werden.
  • Mit anderen Worten und zusammenfassend kann der entsprechende Timeout-Zeitgeber gestartet werden, wenn der Befehlsrahmen 110 die Übertragungs-Arbitration gewinnt, und er kann durch den Kanal für die Übertragung geliefert werden. Der Timeout-Zeitgeber kann gestoppt werden, wenn der geeignete Antwortrahmen 120 rechtzeitig ohne CRC-Fehler angekommen ist.
  • Der folgende Teil der Beschreibung betrifft einen Befehls-Timeout-Betrieb gemäß einer Ausführungsform. Bei dieser Ausführungsform kann das HSSL-Modul einen Vorteiler aufweisen, wie in 1f gezeigt, das heißt einen Vorteiler für das Taktsignal, gemeinsam für alle Kanäle, und einen kanalspezifischen Timeout-Zeitgeber-Block pro Kanal.
  • Ein Ausführungsbeispiel eines einzelnen Timeout-Zeitgeber-Blocks ist in 3 gezeigt. Das Transaktions-Tag für den entsprechenden Kanal 305 und für seinen Timeout-Zeitgeber-Block 300 kann mittels eines funktionellen Blocks von dem Typ „Neues TTAG” 320 generiert werden. Dies kann durch Inkrementieren eines drei Bit langen Zählers erfolgen. Des Weiteren kann der Timeout-Neuladewert, das heißt die Dauer des Timeout in Einheiten der vorgeteilten Taktperioden, für den Timeout-Zeitgeber-Block 300 mittels eines funktionellen TOREL-Blocks 310 definiert werden.
  • Auf der Grundlage dieser Definition mittels des funktionellen TOREL-Blocks 310 kann ein tatsächlicher Timeout-Zeitgeber 350 mittels eines funktionellen Neuladeblocks 340 neu geladen werden, und das Herunterzählen kann ausgelöst werden, wenn ein Prozess zur Befehlsübertragung startet. Dieses Verhalten des funktionellen Neuladeblocks 340 wiederum wird mittels des Übertragungs-Arbiter-Blocks 330 ausgelöst.
  • Des Weiteren kann der Timeout-Zeitgeber-Block 300 das aktuelle Transaktions-Tag mittels eines funktionellen Erfassungsblocks 360 erfassen. Das aktuelle Transaktions-Tag kann mit dem Transaktions-Tag der angekommenen Antwort mittels eines funktionellen Vergleichsblocks 370 verglichen werden.
  • Bei der in 3 gezeigten Ausführungsform kann das Transaktions-Tag der angekommenen Antwort mittels eines funktionellen RXTTAG-Blocks 380 ermittelt werden. Die Bestimmung des Transaktions-Tag der angekommenen Antwort mittels des funktionellen RXTTAG-Blocks 380, der Vergleich des aktuellen Transaktions-Tag mittels des funktionellen Vergleichsblocks 370 und, in dem Falle eines positiven Vergleichs, das Stoppen des Timeout-Zeitgebers 350 können alle über den Empfangsverteilerblock 390 ausgelöst werden.
  • Darüber hinaus kann ein funktioneller kontinuierlicher Vergleichsblock 375 des Timeout-Zeitgeber-Blocks 300 vergleichen, ob der aktuelle Wert des Timeout-Zeitgebers 350 den Wert Null erreicht hat.
  • Wenn dies der Fall ist – das heißt in dem Fall eines Timeout-Fehlers – oder in dem Fall eines fehlerhaften CRC für einen entsprechenden Rahmen, kann der Timeout-Zeitgeber-Block 300 ein Timeout-Signal generieren.
  • Der aktuelle Wert des Timeout-Zeitgebers 350 kann in einem Bit-Feld ICON.TOCV angegeben werden, und der Timeout-Neuladewert kann in einem Bit-Feld ICON.TOREL konfiguriert werden. Das aktuell erwartete Transaktions-Tag kann in einem Bit-Feld ICON.CETT angegeben werden, und der erfasste Wert des letzten fehlerhaften Transaktions-Tag kann in einem Bit-Feld ICON.LETT angegeben werden.
  • Der folgende Teil der Beschreibung betrifft eine erweiterte Stream-Timeout-Funktionalität für Stream-Kanäle. Insbesondere wird eine Ausführungsform für die parallele Timeout-Überwachung von Stream-Befehlen beschrieben, wobei die Stream-Befehle durch entsprechende Stream-Befehlsrahmen eingeleitet werden können.
  • Diesbezüglich zeigt 4 eine Ausführungsform eines Stream-Timeout-Zeitgeber-Blocks 425 für einen Stream-Kanal 405.
  • Ähnlich der Ausführungsform eines einfachen Kanal-Timeout-Zeitgeber-Blocks in 3 zum Überwachen von einfachen Befehlsrahmen kann ein funktioneller Block von dem Typ „Neues TTAG” 420 vorhanden sein, um das Transaktions-Tag für den entsprechenden Stream-Kanal 405 und seinen Stream-Timeout-Zeitgeber-Block 425 zu generieren.
  • Des Weiteren kann der Timeout-Neuladewert, das heißt die Dauer des Timeout in Einheiten der vorgeteilten Taktperioden für den Stream-Timeout-Zeitgeber-Block 425 durch einen entsprechenden funktionellen TOREL-Block 410 definiert werden.
  • In dem Betrieb kann ein freier, das heißt nicht aktiver Timeout-Zeitgeber von zwei Timeout-Zeitgeber-Blöcken 450, 451 des Stream-Timeout-Zeitgeber-Blocks 425 gestartet werden, wenn ein Stream-Rahmen eine Arbitrationsrunde gewinnt und mittels des Stream-Kanals 405 zur Übertragung geliefert wird. Das Starten des freien Timeout-Zeitgebers der beiden Timeout-Zeitgeber-Blöcke 450, 451 kann mittels des Übertragungs-Arbiter-Blocks 430 ausgelöst werden.
  • Des Weiteren kann ein vorbestimmter der beiden Timeout-Zeitgeber-Blöcke 450, 451 auf null zurückgesetzt werden und gestoppt werden, wenn ein entsprechender Antwortrahmen rechtzeitig ohne CRC-Fehler angekommen ist. Das Stoppen des vorbestimmten der beiden Timeout-Zeitgeber-Blöcke 450, 451 kann mittels des Empfangsverteilerblocks 490 ausgelöst werden. Darüber hinaus kann der Empfangsverteilerblock 490 das Transaktions-Tag RXTTAG der angekommenen Antwort dem Stream-Timeout-Zeitgeber-Block 425 signalisieren.
  • Wenn eine Antwort mit einem geeigneten Transaktions-Tag RXTTAG nicht angekommen ist, kann ein Timeout-Fehler ausgelöst werden, und der entsprechende der beiden Timeout-Zeitgeber-Blöcke 450, 451 kann zurückgesetzt werden.
  • Der Stream-Initiator kann die erwarteten Bestätigungen mittels eines virtuellen Erwartungs-FIFO des Stream-Timeout-Zeitgeber-Blocks 425 mit einem virtuellen Füllstand EXFL 470 verfolgen. Jede neue Übertragung eines Stream-Rahmens kann den EXFL 470 inkrementieren, während das Empfangen einer korrekten Bestätigung den EXFL 470 verringern kann.
  • Solange der Erwartungs-FIFO voll ist – das heißt bei einem virtuellen Füllstand von zwei in der vorliegenden Ausführungsform von 4 – kann keine neue Übertragungsanforderung ausgegeben werden. Damit eine neue Stream-Rahmen-Anforderung ausgegeben werden kann, was bedeutet, dass das Kennzeichen IS durch das Modul gesetzt werden soll, sollten drei Bedingungen erfüllt sein, das heißt der Erwartungs-Füllstand sollte unter zwei sein (EXFL < 2), der TXFIFO sollte nicht leer sein (TXFL > 0) und das LSB-Bit sollte durch die Software gesetzt worden sein (LSB = 1).
  • Im Folgenden wird der weitere Betrieb des Stream-Timeout beschrieben. Diesbezüglich kann der Stream-Kanal 405 das Ankommen der Stream-Rahmen-Antworten über den Empfangsverteilerblock 490 durch Verwendung der beiden Timeout-Zeitgeber-Blöcke 450, 451 überwachen. Bei einer Ausführungsform können die beiden Timeout-Zeitgeber-Blöcke 450, 451 ähnlich wie der in 3 gezeigte, einzelne Timeout-Zeitgeber-Block 300 konfiguriert sein.
  • Der neue Initiator-TTAG-Wert, wie durch den funktionellen Block von dem Typ „Neues TTAG” 420 definiert und wie für den nächsten Rahmen verwendet, kann in dem Bit-Feld ICONx.ITTAG sichtbar sein. Das Register ICONx kann auch die Bit-Felder TOREL und TOCV aufweisen.
  • Die Streaming-Funktionalität kann zwei Zeitgeber der beiden Timeout-Zeitgeber-Blöcke 450, 451 verwenden, welche denselben Neuladewert gemeinsam verwenden, wie durch den funktionellen TOREL-Block 410 und das Bit-Feld ICON2.TOREL definiert. Bei der Ausführungsform von 4 können die beiden Timeout-Zeitgeber-Blöcke 450, 451 das Verhalten eines FIFO simulieren, nämlich des oben erwähnten Erwartungs-FIFO, indem sie zusätzlich einen „Schreib”-Zeiger 440 und einen „Lese”-Zeiger 460 aufweisen.
  • Der Übertragungs- oder „Schreib”-Zeiger 440 kann auf den Zeitgeberblock zeigen, wo der nächste Befehlsrahmen das Schreiben des Timeout-Neuladewerts und des Transaktions-Tag auslösen wird.
  • Im Gegensatz dazu kann der Empfangs- oder „Lese”-Zeiger 460 auf den Block zeigen, der den Vergleich des Transaktions-Tag mit dem TTAG der aktuell angekommenen Stream-Bestätigung vornimmt.
  • Entsprechend kann der EXFL 470 bzw. der virtuelle Füllstand angeben, wie viele Zeitgeber der beiden Timeout-Zeitgeber-Blöcke 450, 451 aktiv sind, wie beispielsweise null, einer oder zwei. Der EXFL 470 kann in einem SFSFLAGS-Register des HSSL-Moduls sichtbar sein.
  • 5 zeigt eine beispielhafte Übertragung von drei Stream-Rahmen SF1, SF2 und SF3 und entsprechende Stream-Timeout-Messungen mittels eines Stream-Timeout-Zeitgeber-Blocks gemäß einer in 4 abgebildeten Ausführungsform. Diesbezüglich zeigt die obere Hälfte von 5 die zeitliche Dauer der Stream-Rahmen SF1, SF2 und SF3, wie durch die entsprechenden horizontalen Balken dargestellt.
  • Bei der Ausführungsform von 5 kann der erste Stream-Rahmen SF1 nach einer ersten Antwortverzögerung 540 mittels eines ersten Bestätigungsrahmens ACK1 bestätigt werden. Demgemäß kann der zweite Stream-Rahmen SF2 nach einer zweiten Antwortverzögerung 550 mittels eines zweiten Bestätigungsrahmens ACK2 bestätigt werden.
  • In der unteren Hälfte von 5 sind Wertfolgen des Initiator-Anforderungskennzeichens IS des entsprechenden Stream-Kanals, des Erwartungs-FIFO-Füllstands EXFL und des Sende-FIFO-Füllstands TXFL gezeigt, die jeweils dem Anfang und Ende der drei Stream-Rahmen SF1, SF2 und SF3 in der oberen Hälfte entsprechen.
  • Im Hinblick auf das Initiator-Anforderungskennzeichen IS zeigt 5, dass die Übertragung des ersten Stream-Rahmens SF1 gestartet werden kann, wenn das Initiator-Anforderungskennzeichen IS zum ersten Mal zurückgesetzt wird.
  • Als Ergebnis des Starts der Übertragung des ersten Stream-Rahmens SF1 kann der Sende-FIFO-Füllstand TXFL von 2 auf 1 verringert werden, was angibt, dass ein Stream-Rahmen weniger zu übertragen ist. Gleichzeitig kann der Erwartungs-FIFO-Füllstand EXFL von 0 auf 1 erhöht werden, was angibt, dass nach einer erfolgreichen Übertragung des ersten Stream-Rahmens SF1 ein Antwortrahmen erwartet wird.
  • Da der Erwartungs-FIFO-Füllstand EXFL sich unterhalb des vorbestimmten Verfolgungs-Grenzwerts von zwei für Stream-Rahmen befindet, kann das Initiator-Anforderungskennzeichen IS mittels des nächsten zu übertragenden Stream-Rahmens in dem Übertragungs-FIFO gesetzt werden, kurz nachdem das Initiator-Anforderungskennzeichen IS zum ersten Mal zurückgesetzt wurde.
  • Das Initiator-Anforderungskennzeichen IS bleibt jedoch gesetzt und kann nur zum zweiten Mal zurückgesetzt werden, um die Übertragung des zweiten Stream-Rahmens SF2 zu starten, nachdem die Übertragung des ersten Stream-Rahmens SF1 beendet wurde.
  • Der Start der Übertragung des zweiten Stream-Rahmens SF2 kann den Sende-FIFO-Füllstand TXFL von 2 auf 1 verringern, was angibt, dass wiederum ein Stream-Rahmen weniger zu übertragen ist. Gleichzeitig kann der Erwartungs-FIFO-Füllstand EXFL wieder von 1 auf 2 erhöht werden, was angibt, dass zwei Antwortrahmen erwartet werden, welche die erfolgreiche Übertragung des ersten Stream-Rahmens SF1 und des zweiten Stream-Rahmens SF2 angeben, da der erste Stream-Rahmen SF1 zu Beginn der Übertragung des zweiten Stream-Rahmens SF2 noch nicht bestätigt worden ist.
  • Da der Erwartungs-FIFO-Füllstand EXFL gleich dem vorbestimmten Verfolgungs-Grenzwert von zwei für Stream-Rahmen ist, kann das Initiator-Anforderungskennzeichen IS mittels des nächsten zu übertragenden Stream-Rahmens in dem Übertragungs-FIFO erst gesetzt werden, wenn der erste Bestätigungsrahmen ACK1 vollständig empfangen worden ist, um den korrekten Empfang des ersten Stream-Rahmens SF1 zu bestätigen. Entsprechend kann das Initiator-Anforderungskennzeichen IS während des Intervalls 560 zwischen dem Start der Übertragung des zweiten Stream-Rahmens SF2 und dem vollständigen Empfang des ersten Bestätigungsrahmens ACK1 für den ersten Stream-Rahmen SF1 nicht gesetzt werden.
  • Nach dem vollständigen Empfang des ersten Bestätigungsrahmens ACK1 für den ersten Stream-Rahmen SF1 kann das Initiator-Anforderungskennzeichen IS zum dritten Mal gesetzt werden. Das Initiator-Anforderungskennzeichen IS kann dann gesetzt bleiben und kann nur zum dritten Mal zurückgesetzt werden, um die Übertragung des dritten Stream-Rahmens SF3 zu starten, nachdem die Übertragung des zweiten Stream-Rahmens SF2 beendet wurde.
  • Der Start der Übertragung des dritten Stream-Rahmens SF3 kann den Sende-FIFO-Füllstand TXFL von 2 auf 1 verringern, was angibt, dass wiederum ein Stream-Rahmen weniger zu übertragen ist. Gleichzeitig kann der Erwartungs-FIFO-Füllstand EXFL wieder von 1 auf 2 erhöht werden, was angibt, dass zwei Antwortrahmen erwartet werden, welche die erfolgreiche Übertragung des zweiten Stream-Rahmens SF2 und des dritten Stream-Rahmens SF3 angeben, da der zweite Stream-Rahmen SF2 zu Beginn der Übertragung des dritten Stream-Rahmens SF3 noch nicht bestätigt worden ist.
  • Da der Erwartungs-FIFO-Füllstand EXFL dann wieder gleich dem vorbestimmten Verfolgungs-Grenzwert von zwei für Stream-Rahmen ist, kann das Initiator-Anforderungskennzeichen IS mittels des nächsten zu übertragenden Stream-Rahmens in dem Übertragungs-FIFO erst gesetzt werden, wenn der zweite Bestätigungsrahmen ACK2 vollständig empfangen wurde, um den korrekten Empfang des zweiten Stream-Rahmens SF2 zu bestätigen. Entsprechend kann das Initiator-Anforderungskennzeichen IS während des Intervalls 570 zwischen dem Start der Übertragung des dritten Stream-Rahmens SF3 und dem vollständigen Empfang des zweiten Bestätigungsrahmens ACK2 für den zweiten Stream-Rahmen SF2 nicht gesetzt werden.
  • Im Hinblick auf die oben beschriebenen Ausführungsformen, die sich auf die Figuren beziehen, wird betont, dass die genannten Ausführungsformen im Wesentlichen dazu dienten, die Verständlichkeit zu verbessern. Zusätzlich sollen die folgenden weiteren Ausführungsformen ein allgemeineres Konzept veranschaulichen. Die folgenden Ausführungsformen sind jedoch nicht in einem beschränkenden Sinne aufzufassen. Vielmehr ist – wie zuvor schon zum Ausdruck gebracht – der Schutzumfang der vorliegenden Erfindung durch die beigefügten Ansprüche definiert.
  • Diesbezüglich betrifft eine erste Ausführungsform ein System zum Schützen einer Vielzahl von Kommunikationskanälen mit einem Timeout, das eine Vielzahl von Timeout-Zeitgebern aufweist. In diesem System ist jeder der Vielzahl von Timeout-Zeitgeber einem entsprechenden der Vielzahl von Kommunikationskanälen zugewiesen.
  • Bei einer Ausführungsform ist jeder der Vielzahl von Timeout-Zeitgebern individuell auf einen entsprechenden einer Vielzahl von Zeitgeber-spezifischen Timeout-Zeiträumen konfigurierbar.
  • Bei einer weiteren Ausführungsform ist jeder der Vielzahl von Zeitgeber-spezifischen Timeout-Zeiträumen auf einen entsprechenden einer Vielzahl von optimalen Timeout-Zeiträumen eingestellt, der spezifisch für den jeweils entsprechenden der Vielzahl von Kommunikationskanälen ist. Wenigstens in den vorherigen beiden Ausführungsformen können auch die Timeout-Zeiträume in vorgeteilten Taktperioden angegeben werden.
  • Bei einer weiteren Ausführungsform ist jeder der Vielzahl von Timeout-Zeitgebern geeignet, mittels eines entsprechenden einer Vielzahl von Befehlsrahmen gestartet zu werden, der eine Arbitration für die Übertragung gewinnt und der mittels eines entsprechenden der Vielzahl von Kommunikationskanälen für die Übertragung geliefert wird. Bei alternativen Ausführungsformen kann der Start des Timeout-Zeitgebers jedoch auch durch andere Ereignisse, wie zum Beispiel eine Übertragungsanforderung, den Start der Übertragung eines Befehlsrahmens, das Ende der Übertragung eines Befehlsrahmens oder andere geeignete Ereignisse ausgelöst werden.
  • Bei noch einer weiteren Ausführungsform ist jeder der Vielzahl von Timeout-Zeitgebern geeignet, mittels eines entsprechenden einer Vielzahl von erwarteten Antwortrahmen gestoppt zu werden, die rechtzeitig ohne Fehler bei der zyklischen Redundanzprüfung (CRC-Fehler) ankommen. Bei alternativen Ausführungsformen kann jedoch das Stoppen des Timeout-Zeitgebers bereits durch das einfache Empfangen einer Antwort ausgelöst werden. Die Bedingungen, ob kein CRC-Fehler aufgetreten ist, ob das Transaktions-Tag mit dem für die erwartete Antwort übereinstimmt und ob die korrekte Antwort empfangen wurde, stellen weitere Auslösebedingungen dar, die in beliebiger Kombination überprüft werden könnten, um alternativ das Stoppen des Timeout-Zeitgebers auszulösen.
  • Eine weitere Ausführungsform betrifft ein System zum Überwachen von Pipelining-Befehlsausführungen, die mittels vorbestimmter Befehlsrahmen gestartet werden. Das System ist geeignet, die vorbestimmten Befehlsrahmen und entsprechende Bestätigungsrahmen zu empfangen.
  • Das System weist einen Schreib-Zeiger, einen Lese-Zeiger und wenigstens zwei Timeout-Zeitgeber-Blöcke auf. Die wenigstens zwei Timeout-Zeitgeber-Blöcke sind so konfiguriert, dass sie ein FIFO-Verhalten simulieren können.
  • Das FIFO-Verhalten wird dadurch simuliert, dass der Schreib-Zeiger geeignet ist, einen nächsten, nicht aktiven Timeout-Zeitgeber der wenigstens zwei Timeout-Zeitgeber-Blöcke auszuwählen und zu starten, wenn einer der vorbestimmten Befehlsrahmen übertragen werden soll.
  • Ferner wird das FIFO-Verhalten der wenigstens zwei Timeout-Zeitgeber-Blöcke dadurch simuliert, dass der Lese-Zeiger geeignet ist, einen vorbestimmten, aktiven Timeout-Zeitgeber der wenigstens zwei Timeout-Zeitgeber-Blöcke bei dem Empfang des Bestätigungsrahmens, der dem einen der vorbestimmten Befehlsrahmen entspricht, der den vorbestimmten Timeout-Zeitgeber gestartet hat, auszuwählen und zu stoppen. Außerdem können bei dieser Ausführungsform die Bedingungen, ob kein CRC-Fehler aufgetreten ist, ob das Transaktions-Tag mit dem für die erwartete Antwort übereinstimmt und ob die korrekte Antwort empfangen wurde, in beliebiger Kombination überprüft werden, um alternativ das Stoppen des Timeout-Zeitgebers auszulösen.
  • Bei einer Ausführungsform ist der Schreib-Zeiger dazu geeignet, auf denjenigen Timeout-Zeitgeber-Block der wenigstens zwei Timeout-Zeitgeber-Blöcke zu zeigen, in dem ein nächster der vorbestimmten, zu übertragenden Befehlsrahmen einen Timeout-Neuladewert, TOREL, und ein Transaktions-Tag, TTAG, des empfangenen einen der vorbestimmten Befehlsrahmen schreiben wird, um den entsprechenden Timeout-Zeitgeber zu starten.
  • Bei einer weiteren Ausführungsform ist der Lese-Zeiger dazu geeignet, auf denjenigen Timeout-Zeitgeber-Block der wenigstens zwei Timeout-Zeitgeber-Blöcke zu zeigen, dessen gespeichertes Transaktions-Tag mit einem Transaktions-Tag eines aktuell empfangenen der Bestätigungsrahmen verglichen wird, um den entsprechenden Timeout-Zeitgeber zu stoppen.
  • Eine weitere Ausführungsform weist ferner einen Indikator für einen virtuellen Füllstand auf, der als EXFL (Expect FIFO Filling Level, Erwartungs-FIFO-Füllstand) bezeichnet wird und der angibt, wie viele der wenigstens zwei Timeout-Zeitgeber-Blöcke aktiv sind.
  • Bei einer Ausführungsform definiert der Timeout-Neuladewert eine Dauer eines Timeout-Zeitraums in Einheiten von vorgeteilten Taktperioden.
  • Eine noch weitere Ausführungsform betrifft ein System für die parallele Timeout-Überwachung von Stream-Befehlen, die durch entsprechende Stream-Befehlsrahmen, das heißt Schreib-Befehlsrahmen, die jeweils einen Datenblock mit vorbestimmter Länge aufweisen, eingeleitet werden.
  • Dieses System weist eine Vielzahl von Timeout-Zeitgebern auf, einen Schreib-Zeiger, der geeignet ist, einen nächsten, nicht aktiven Timeout-Zeitgeber der Vielzahl von Timeout-Zeitgebern auszuwählen und zu starten, wenn einer der Stream-Befehlsrahmen übertragen werden soll.
  • Darüber hinaus weist das System einen Lese-Zeiger auf, der geeignet ist, einen vorbestimmten, aktiven Timeout-Zeitgeber der Vielzahl von Timeout-Zeitgebern bei dem Empfang eines Bestätigungsrahmens, der dem einen der Stream-Befehlsrahmen entspricht, der den vorbestimmten Timeout-Zeitgeber gestartet hat, auszuwählen und zu stoppen.
  • Bei einer Ausführungsform definiert ein Timeout-Neuladewert eine Dauer eines Timeout-Zeitraums von einem der Vielzahl von Timeout-Zeitgebern.
  • Bei einer Ausführungsform verwendet die Vielzahl von Timeout-Zeitgebern denselben Timeout-Neuladewert gemeinsam.
  • Bei einer weiteren Ausführungsform weisen die Stream-Befehlsrahmen jeweils einen Datenblock mit einer Länge von 256 Bit auf.
  • Eine weitere Ausführungsform betrifft ein Verfahren zum Schützen einer Vielzahl von Kommunikationskanälen mit einem Timeout, wobei das Verfahren das Zuweisen jedes einer Vielzahl von Timeout-Zeitgebern zu einem entsprechenden der Vielzahl von Kommunikationskanälen umfasst.
  • Eine Ausführungsform des Verfahrens umfasst das individuelle Konfigurieren jedes der Vielzahl von Timeout-Zeitgebern auf einen entsprechenden einer Vielzahl von Zeitgeber-spezifischen Timeout-Zeiträumen.
  • Bei einer weiteren Ausführungsform umfasst das individuelle Konfigurieren das Einstellen jedes der Vielzahl von Zeitgeber-spezifischen Timeout-Zeiträumen auf einen entsprechenden einer Vielzahl von optimalen Timeout-Zeiträumen, der spezifisch für den jeweils entsprechenden der Vielzahl von Kommunikationskanälen ist.
  • Eine Ausführungsform des Verfahrens umfasst ferner das Starten jedes der Vielzahl von Timeout-Zeitgebern mittels eines entsprechenden einer Vielzahl von Befehlsrahmen, der eine Arbitration für die Übertragung gewinnt und der mittels eines entsprechenden der Vielzahl von Kommunikationskanälen für die Übertragung geliefert wird.
  • Eine weitere Ausführungsform des Verfahrens umfasst ferner das Stoppen jedes der Vielzahl von Timeout-Zeitgebern mittels eines entsprechenden einer Vielzahl von erwarteten Antwortrahmen, die rechtzeitig ohne Fehler bei der zyklischen Redundanzprüfung (CRC-Fehler) ankommen.
  • Eine weitere Ausführungsform betrifft ein Verfahren zur parallelen Timeout-Überwachung von gleichzeitig ausgeführten Befehlen, wobei das Verfahren das Zuweisen oder Aufheben der Zuweisung jedes der Befehle zu einem entsprechenden einer Vielzahl von Timeout-Zeitgebern in der Art und Weise eines FIFO umfasst, wenn entsprechende Befehle übertragen werden sollen bzw. Befehlsbestätigungen empfangen werden.
  • Eine Ausführungsform des Verfahrens umfasst ferner die Verwendung eines virtuellen Erwartungs-FIFO, um die erwarteten der Befehlsbestätigungen zu verfolgen.
  • Bei einer Ausführungsform weist der virtuelle Erwartungs-FIFO einen virtuellen Füllstand EXFL auf, wobei jeder neue der Befehle den virtuellen Füllstand erhöht und jede korrekt empfangene der Befehlsbestätigungen den virtuellen Füllstand verringert.
  • Bei einer Ausführungsform wird kein weiterer der Befehle einem entsprechenden der Vielzahl von Timeout-Zeitgebern zugewiesen, wenn der virtuelle Füllstand des virtuellen Erwartungs-FIFO einen vorbestimmten Verfolgungs-Grenzwert überschreitet.
  • Eine weitere Ausführungsform betrifft ein Verfahren zur parallelen Timeout-Überwachung von gleichzeitigen Stream-Befehlen. Dieses Verfahren umfasst einen Schritt des Verwendens eines Schreib-Zeigers zum Auswählen und Starten eines nächsten, nicht aktiven Timeout-Zeitgebers einer Vielzahl von Timeout-Zeitgebern, wenn einer der Stream-Befehlsrahmen übertragen werden soll. In einem weiteren Schritt wird ein Lese-Zeiger zum Auswählen und Stoppen eines vorbestimmten, aktiven Timeout-Zeitgebers der Vielzahl von Timeout-Zeitgebern bei dem Empfang einer Befehlsbestätigung verwendet, die dem einen der Stream-Befehle entspricht, der den vorbestimmten Timeout-Zeitgeber gestartet hat.
  • Eine noch weitere Ausführungsform betrifft ein Verfahren zur Timeout-Überwachung von gleichzeitig ausgeführten Befehlen oder parallelen Kommunikationskanälen, wobei das Verfahren das Zuweisen oder Aufheben der Zuweisung jedes der Befehle oder Kommunikationskanäle zu einem entsprechenden einer Vielzahl von Timeout-Zeitgebern umfasst, wenn entsprechende Befehle übertragen werden sollen bzw. Befehlsbestätigungen empfangen werden.
  • Obwohl in diesem Dokument spezifische Ausführungsformen veranschaulicht und beschrieben wurden, werden es die Durchschnittsfachleute auf dem Gebiet würdigen, dass die gezeigten und beschriebenen, spezifischen Ausführungsformen durch eine Vielzahl von alternativen und/oder äquivalenten Implementierungen ersetzt werden können, ohne dass von dem Schutzumfang der vorliegenden Erfindung abgewichen wird. Diese Anmeldung soll jegliche Adaptionen oder Variationen der in diesem Dokument erörterten, spezifischen Ausführungsformen umfassen. Daher soll die Erfindung nur durch die Ansprüche und deren Äquivalente beschränkt werden.

Claims (10)

  1. System zum Schützen einer Vielzahl von Kommunikationskanälen mit einem Timeout, wobei das System Folgendes aufweist: eine Vielzahl von Timeout-Zeitgebern, wobei jeder der Vielzahl von Timeout-Zeitgebern einem entsprechenden der Vielzahl von Kommunikationskanälen zugewiesen ist.
  2. System nach Anspruch 1, wobei jeder der Vielzahl von Timeout-Zeitgebern individuell auf einen entsprechenden einer Vielzahl von Zeitgeber-spezifischen Timeout-Zeiträumen konfigurierbar ist.
  3. System nach Anspruch 1, wobei jeder der Vielzahl von Zeitgeber-spezifischen Timeout-Zeiträumen auf einen entsprechenden einer Vielzahl von optimalen Timeout-Zeiträumen eingestellt ist, der spezifisch für den jeweils entsprechenden der Vielzahl von Kommunikationskanälen ist.
  4. System nach Anspruch 1, wobei jeder der Vielzahl von Timeout-Zeitgebern geeignet ist, mittels eines entsprechenden einer Vielzahl von Befehlsrahmen gestartet zu werden, der eine Arbitration für die Übertragung gewinnt und der mittels eines entsprechenden der Vielzahl von Kommunikationskanälen für die Übertragung geliefert wird.
  5. System zum Überwachen von Pipelining-Befehlsausführungen, die von vorbestimmten Befehlsrahmen gestartet werden, wobei das System geeignet ist, die vorbestimmten Befehlsrahmen und entsprechende Bestätigungsrahmen zu empfangen, und Folgendes aufweist: einen Schreib-Zeiger; einen Lese-Zeiger; und wenigstens zwei Timeout-Zeitgeber-Blöcke, die so konfiguriert sind, dass sie ein FIFO-Verhalten simulieren können, insofern als: der Schreib-Zeiger geeignet ist, einen nächsten, nicht aktiven Timeout-Zeitgeber der wenigstens zwei Timeout-Zeitgeber-Blöcke auszuwählen und zu starten, wenn einer der vorbestimmten Befehlsrahmen übertragen werden soll; der Lese-Zeiger geeignet ist, einen vorbestimmten, aktiven Timeout-Zeitgeber der wenigstens zwei Timeout-Zeitgeber-Blöcke bei dem Empfang des Bestätigungsrahmens, der dem einen der vorbestimmten Befehlsrahmen entspricht, der den vorbestimmten Timeout-Zeitgeber gestartet hat, auszuwählen und zu stoppen.
  6. System für die parallele Timeout-Überwachung von Stream-Befehlen, die durch entsprechende Stream-Befehlsrahmen, das heißt Schreib-Befehlsrahmen, die jeweils einen Datenblock mit vorbestimmter Länge aufweisen, eingeleitet werden, wobei das System Folgendes aufweist: eine Vielzahl von Timeout-Zeitgebern; einen Schreib-Zeiger, der geeignet ist, einen nächsten, nicht aktiven Timeout-Zeitgeber der Vielzahl von Timeout-Zeitgebern auszuwählen und zu starten, wenn einer der Stream-Befehlsrahmen übertragen werden soll; und einen Lese-Zeiger, der geeignet ist, einen vorbestimmten, aktiven Timeout-Zeitgeber der Vielzahl von Timeout-Zeitgebern bei dem Empfang eines Bestätigungsrahmens, der dem einen der Stream-Befehlsrahmen entspricht, der den vorbestimmten Timeout-Zeitgeber gestartet hat, auszuwählen und zu stoppen.
  7. Verfahren zum Schützen einer Vielzahl von Kommunikationskanälen mit einem Timeout, wobei das Verfahren Folgendes umfasst: Zuweisen jedes einer Vielzahl von Timeout-Zeitgebern zu einem entsprechenden der Vielzahl von Kommunikationskanälen.
  8. Verfahren zur parallelen Timeout-Überwachung von gleichzeitig ausgeführten Befehlen, wobei das Verfahren Folgendes umfasst: Zuweisen oder Aufheben der Zuweisung jedes der Befehle zu einem entsprechenden einer Vielzahl von Timeout-Zeitgebern in der Art und Weise eines FIFO, wenn entsprechende Befehle übertragen werden sollen bzw. Befehlsbestätigungen empfangen werden.
  9. Verfahren zur parallelen Timeout-Überwachung von gleichzeitigen Stream-Befehlen: Verwenden eines Schreib-Zeigers zum Auswählen und Starten eines nächsten, nicht aktiven Timeout-Zeitgebers einer Vielzahl von Timeout-Zeitgebern, wenn einer der Stream-Befehlsrahmen übertragen werden soll; und Verwenden eines Lese-Zeigers zum Auswählen und Stoppen eines vorbestimmten, aktiven Timeout-Zeitgebers der Vielzahl von Timeout-Zeitgebern bei dem Empfang einer Befehlsbestätigung, die dem einen der Stream-Befehle entspricht, der den vorbestimmten Timeout-Zeitgeber gestartet hat.
  10. Verfahren zur Timeout-Überwachung von gleichzeitigen Befehlen oder parallelen Kommunikationskanälen, wobei das Verfahren Folgendes umfasst: Zuweisen oder Aufheben der Zuweisung jedes der Befehle oder Kommunikationskanäle zu einem entsprechenden einer Vielzahl von Timeout-Zeitgebern, wenn entsprechende Befehle übertragen werden sollen bzw. Befehlsbestätigungen empfangen werden.
DE102013004542A 2012-03-16 2013-03-15 Verfahren und system zur timeout-überwachung Ceased DE102013004542A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US13/422,568 2012-03-16
US13/422,568 US9201719B2 (en) 2012-03-16 2012-03-16 Method and system for timeout monitoring

Publications (1)

Publication Number Publication Date
DE102013004542A1 true DE102013004542A1 (de) 2013-09-19

Family

ID=49044074

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102013004542A Ceased DE102013004542A1 (de) 2012-03-16 2013-03-15 Verfahren und system zur timeout-überwachung

Country Status (3)

Country Link
US (3) US9201719B2 (de)
CN (2) CN103309841B (de)
DE (1) DE102013004542A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017016744A1 (de) 2015-07-27 2017-02-02 Continental Automotive Gmbh Integrierter schaltkreis zum betreiben an einem bus und verfahren zum betreiben des integrierten schaltkreises

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9201719B2 (en) 2012-03-16 2015-12-01 Infineon Technologies Ag Method and system for timeout monitoring
CN103810074B (zh) * 2012-11-14 2017-12-29 华为技术有限公司 一种片上系统芯片及相应的监控方法
CN103618586B (zh) * 2013-11-07 2017-07-28 华为技术有限公司 一种发送响应帧的方法及装置
US9672182B2 (en) * 2014-08-21 2017-06-06 Infineon Technologies Ag High-speed serial ring
US9934117B2 (en) * 2015-03-24 2018-04-03 Honeywell International Inc. Apparatus and method for fault detection to ensure device independence on a bus
EP3329379A4 (de) * 2015-07-29 2019-06-12 Macom Connectivity Solutions, LLC Erzeugen eines zeitüberschreitungssignals basierend auf einem mit einer datenanforderung assoziierten taktzähler
US10042692B1 (en) * 2015-09-29 2018-08-07 Xilinx, Inc. Circuit arrangement with transaction timeout detection
CN107239378B (zh) * 2016-03-29 2022-06-03 北京忆恒创源科技股份有限公司 一种超时监测方法及系统
DE102016210984A1 (de) * 2016-06-20 2017-12-21 Robert Bosch Gmbh Verfahren zum Betreiben eines Steuergeräts
TWI633777B (zh) * 2016-12-13 2018-08-21 威盛電子股份有限公司 傳輸介面晶片以及其測試方法
JP6627786B2 (ja) * 2017-01-12 2020-01-08 株式会社アドヴィックス 車両の制御システム
KR20180090124A (ko) * 2017-02-02 2018-08-10 에스케이하이닉스 주식회사 메모리 시스템 및 메모리 시스템의 동작 방법
CN107122282B (zh) * 2017-03-28 2019-12-31 中国第一汽车股份有限公司 一种基于spi总线的功能安全通信方法
US10592322B1 (en) 2017-06-27 2020-03-17 Amazon Technologies, Inc. Adaptive timeout mechanism
CN110096399B (zh) * 2019-04-25 2023-07-07 湖南品腾电子科技有限公司 一种硬件接口的调试方法
US11775395B2 (en) * 2020-01-27 2023-10-03 International Business Machines Corporation Withdrawing a point-in-time snapshot copy operation within a data consistency application
CN113760509B (zh) * 2021-08-25 2023-11-10 北京百度网讯科技有限公司 一种超时管理方法、装置及电子设备
CN118115129B (zh) * 2024-04-28 2024-07-12 山东大学 一种应用于通用智慧实验室的应急监控方法、设备及介质

Family Cites Families (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH10502789A (ja) * 1995-04-28 1998-03-10 フィリップス エレクトロニクス ネムローゼ フェンノートシャップ 装置グループ間で信頼性のある通信を行う無線通信システム
US7013336B1 (en) * 1999-03-31 2006-03-14 International Business Machines Corporation Method and structure for efficiently retrieving status for SCSI accessed fault-tolerant enclosure (SAF-TE) systems
AT407582B (de) * 1999-08-13 2001-04-25 Fts Computertechnik Gmbh Nachrichtenverteilereinheit mit integriertem guardian zur verhinderung von ''babbling idiot'' fehlern
US6922741B2 (en) * 2002-02-01 2005-07-26 Intel Corporation Method and system for monitoring DMA status
US7689708B1 (en) * 2002-10-28 2010-03-30 Netapp, Inc. Apparatus to flow control frames in a networked storage virtualization using multiple streaming protocols
US20040174570A1 (en) * 2002-12-02 2004-09-09 Plunkett Richard Thomas Variable size dither matrix usage
US20040240388A1 (en) 2003-05-28 2004-12-02 Lee Albion System and method for dynamic assignment of timers in a network transport engine
JP2005025829A (ja) * 2003-06-30 2005-01-27 Toshiba Corp ディスク記憶装置及びデータストリーム制御方法
US6981074B2 (en) * 2003-10-14 2005-12-27 Broadcom Corporation Descriptor-based load balancing
US7266661B2 (en) * 2004-05-27 2007-09-04 Silverbrook Research Pty Ltd Method of storing bit-pattern in plural devices
US20060294312A1 (en) * 2004-05-27 2006-12-28 Silverbrook Research Pty Ltd Generation sequences
TWI276324B (en) 2004-07-30 2007-03-11 Mocana Corp Hardware acceleration for large volumes of channels
KR100648837B1 (ko) * 2004-12-08 2006-11-24 한국전자통신연구원 Ｔｃｐ 프로토콜의 재전송 및 지연확인 타이머 관리 장치및 방법
CN100356356C (zh) * 2004-12-24 2007-12-19 华为技术有限公司 采用直接存储器访问方式进行数据传送的方法
US7600049B2 (en) * 2006-09-14 2009-10-06 International Business Machines Corporation Method, system, and computer program product for timing operations of different durations in a multi-processor, multi-control block environment
CN100444143C (zh) * 2006-11-28 2008-12-17 北京中星微电子有限公司 一种内存访问仲裁装置和方法
KR101007046B1 (ko) * 2008-04-23 2011-01-12 주식회사 애트랩 오동작시 자동 복원할 수 있는 통신 시스템 및 이의 복원방법
US8443410B2 (en) * 2008-06-06 2013-05-14 Telefonaktiebolaget Lm Ericsson (Publ) Method and a user equipment for reserving bandwidth
CN101383781B (zh) * 2008-10-30 2010-10-06 中国人民解放军国防科学技术大学 虚拟域间短信息通讯方法
JP2010238150A (ja) 2009-03-31 2010-10-21 Toshiba Corp ＰＣＩＥｘｐｒｅｓｓ通信システム、及びその通信方法
EP2264954B1 (de) 2009-06-18 2012-02-01 Alcatel Lucent Verfahren und Vorrichtung zur Überlastungsregelung
CN101667152A (zh) * 2009-09-23 2010-03-10 华为技术有限公司 计算机系统及计算机系统的总线监控方法
JP2012114513A (ja) * 2010-11-19 2012-06-14 Toshiba Corp 無線通信装置
US9008113B2 (en) * 2010-12-20 2015-04-14 Solarflare Communications, Inc. Mapped FIFO buffering
US9465632B2 (en) * 2012-02-04 2016-10-11 Global Supercomputing Corporation Parallel hardware hypervisor for virtualizing application-specific supercomputers
US9201719B2 (en) 2012-03-16 2015-12-01 Infineon Technologies Ag Method and system for timeout monitoring

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017016744A1 (de) 2015-07-27 2017-02-02 Continental Automotive Gmbh Integrierter schaltkreis zum betreiben an einem bus und verfahren zum betreiben des integrierten schaltkreises
DE102015214133A1 (de) 2015-07-27 2017-02-02 Continental Automotive Gmbh Integrierter Schaltkreis zum Betreiben an einem Bus und Verfahren zum Betreiben des integrierten Schaltkreises
CN107851082A (zh) * 2015-07-27 2018-03-27 大陆汽车有限公司 用于在总线处运行的集成电路和用于运行该集成电路的方法
US10394748B2 (en) 2015-07-27 2019-08-27 Cpt Group Gmbh Integrated circuit for operating on a bus, and method for operating the integrated circuit
CN107851082B (zh) * 2015-07-27 2021-03-30 大陆汽车有限公司 用于在总线处运行的集成电路和用于运行该集成电路的方法

Also Published As

Publication number Publication date
US9727400B2 (en) 2017-08-08
US20130242749A1 (en) 2013-09-19
CN103309841B (zh) 2016-12-07
CN105117299A (zh) 2015-12-02
US20170293519A1 (en) 2017-10-12
US20160041862A1 (en) 2016-02-11
CN105117299B (zh) 2018-07-10
US9201719B2 (en) 2015-12-01
CN103309841A (zh) 2013-09-18
US10191795B2 (en) 2019-01-29

Similar Documents

Publication Publication Date Title
DE102013004542A1 (de) Verfahren und system zur timeout-überwachung
DE3887886T2 (de) Verfahren und anordnung zur sicherung von angepasstem zugriff zu betriebsmitteln in einem multiprozessordatenverarbeitungssystem.
DE60132735T2 (de) Fehlerkorrekturübertragungsverfahren zum Übertragen von Datenpaketen in einem Netzkommunikationssystem
DE3850097T2 (de) Rechnerverbinder für gruppen von datenverarbeitungseinrichtungen.
DE3882977T2 (de) Verfahren und anordnung zur implementierung von mehrverriegelungsanzeigen in einem multiprozessordatenverarbeitungssystem.
DE102012209016B4 (de) System und Verfahren zur Weiterleitung von Fibre-Channel-Eingangs- und Ausgangsdaten
DE3882989T2 (de) Verfahren und anordnung zur verwaltung von mehrverriegelungsanzeigen in einem multiprozessordatenverarbeitungssystem.
DE19900245B4 (de) Vorrichtung und Verfahren zum Senden von Daten von einem USB-Endpunkt an einen USB-Host
DE3331233C3 (de)
DE102012208803B4 (de) System und Verfahren zur Weiterleitung von Fibre-Channel-Eingangs- und Ausgangsdaten
DE602004012563T2 (de) Mehrfädiges DMA
DE102016200514A1 (de) Verfahren und Vorrichtungen für gesteuerte Wiederherstellung von Fehlerinformationen zwischen unabhängig voneinander betreibbaren Prozessoren
DE3888353T2 (de) Unterbrechungsknoten zum vorsehen von unterbrechungsanforderungen auf einem anstehenden bus.
DE3882988T2 (de) Verfahren und anordnung zur einleitung von vorgängen in einem multiprozessordatenverarbeitungssystem mit verwendung von mehrverriegelungsanzeigen.
DE19900369A1 (de) Vorrichtung und Verfahren zur Ausführung einer Steuerübertragung auf einem Universal Serial Bus
DE102017120447A1 (de) Halbleitervorrichtung, Verfahren zum Betreiben der Halbleitervorrichtung und ein System, das diese beinhaltet
DE112018002334T5 (de) Vorrichtungen und verfahren zur übertragung von ereignissen mit einer gleichförmigen latenz auf seriellen kommunikationsverbindungen
DE102012209009A1 (de) System und Verfahren zur Weiterleitung von Fibre-Channel-Eingangs- und Ausgangsdaten
DE112011103225T5 (de) Drosseln einer integrierten Verbindung
DE102019130756A1 (de) Steuerungseinheit-Diagnosevorrichtung und Verfahren davon
DE112013000812T5 (de) Variable Bestätigungsrate zum Verringern von Buskonflikt in Gegenwart von Datenübertragungsfehlern
DE102011122644A1 (de) Nachrichtenverlustverhinderung unter Verwendung eines Senderpuffers und Verkehrsgestaltung in durch ein Ereignis ausgelösten verteilten eingebetteten Echtzeitsystemen
DE102013107718A1 (de) Verfahren und Vorrichtungen zum Verfolgen von Verbindungselementen
EP3053050A1 (de) Kommunikationssystem zur inter-chip-kommunikation
EP1686732A1 (de) Verfahren und System zur Übertragung von Telegrammen

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R016 Response to examination communication
R082 Change of representative

Representative=s name: VIERING, JENTSCHURA & PARTNER MBB PATENT- UND , DE

R016 Response to examination communication
R002 Refusal decision in examination/registration proceedings
R003 Refusal decision now final