DE102014225253B4

DE102014225253B4 - Reallokation für eine Systembustransaktionswarteschlange

Info

Publication number: DE102014225253B4
Application number: DE102014225253.9A
Authority: DE
Inventors: Franck Lunadier; Vincent Debout
Original assignee: Atmel Corp
Current assignee: Atmel Corp
Priority date: 2013-12-09
Filing date: 2014-12-09
Publication date: 2023-07-20
Anticipated expiration: 2034-12-10
Also published as: US20220107904A1; US11256632B2; US9471524B2; US20150161065A1; DE102014225253A1; US20170004097A1

Abstract

System, umfassend:einen Systembus; undeine Vielzahl von Modulen, die mit dem Systembus verbunden sind und dazu konfiguriert sind, miteinander unter Verwendung des Systembusses zu kommunizieren, beinhaltend:ein Mastermodul, das eine Mastertransaktionsanforderungswarteschlange implementiert; undein Slavemodul, das eine Slavetransaktionsanforderungswarteschlange implementiert, wobei das Slavemodul dazu konfiguriert ist, Slavemoduloperationen auszuführen, die umfassen:Empfangen einer ersten Transaktionsanforderung von dem Mastermodul;Feststellen, dass die Slavetransaktionsanforderungswarteschlange voll ist;als Reaktion auf die Feststellung, dass die Slavetransaktionsanforderungswarteschlange voll ist, festlegen auf Basis von zumindest einer ersten anhängigen Transaktion in der Slavetransaktionsanforderungswarteschlange, dass die erste anhängige Transaktion nicht aus der Slavetransaktionsanforderungswarteschlange entfernt werden soll, und dass die erste Transaktionsanforderung nicht in die Slavetransaktionsanforderungswarteschlange eingefügt werden soll; undals Reaktion auf die Festlegung, dass die erste anhängige Transaktion nicht entfernt werden soll, Verschieben der ersten Transaktionsanforderung durch Speichern einer ersten Aufzeichnung für die erste Transaktionsanforderung für ein späteres Wiederabspielen der ersten Transaktionsanforderung.

Description

Diese Offenbarung bezieht sich allgemein auf Architekturen für Datenkommunikationsbusse.
In manchen Mikrocontrollern sind Busmaster mit Busslaves ganz oder teilweise über einen oder mehrere Busmatrixports und Schalter verbunden. In diesen Mikrocontrollern müssen Datenübertragungsanforderungen von dem Master an die Slaves nacheinander durch mehrere Arbitrierungsknoten gehen. Zu jedem Zeitpunkt kann ein gegebener Master mehrere anhängige Datenübertragungsanforderungen haben. Jede dieser Übertragungsanforderungen kann eine sich auf Basis von Latenzzeiten und/oder Bandbreitenanforderungen dynamisch ändernde Dringlichkeit haben.
In diesen Mikrocontrollern wird eine Busarbitrierung verwendet, um die Bandbreiten und Latenzanforderungen der jeweiligen Master zu erfüllen, und um die insgesamt verfügbare Bandbreite des Systems zu maximieren. In diesen Mikrocontrollern arbitrieren die Arbitrierungsknoten Konflikte im Netzwerkraum häufig lokal und nur jeweils einmal an jedem Arbitrierungsknoten unter Verwendung eines Prioritätswerts, der statisch mit der Datenübertragungsanforderung assoziiert ist. Unabhängig von der Priorität einer Datenübertragungsanforderung an einem gegebenen Arbitrierungsknoten hängt der Fortschritt der Datenübertragungsanforderung an den Targetslave vom Fortschritt der vorhergehenden Übertragungsanforderung an dem nächsten nachfolgenden Arbitrierungsknoten ab.
Eine Lösung für das Verstopfungsproblem besteht darin, Busslaves mit langen Warteschlangen zu versehen, die eine signifikante Anzahl von ausgegebenen Übertragungsanforderungen speichern können. Eine Speicherung der Übertragungsanforderungen macht den Netzwerkübertragungsanforderungspfad frei. Wenn im Netzwerkübertragungsanforderungspfad keine Verstopfung vorliegt, können die Datenübertragungsanforderungen die Arbitrierungsendknoten in kurzer Zeit erreichen, so dass Übertragungsanforderungen mit hoher Priorität nicht für eine lange Zeit durch den Arbitrierungsendknoten ignoriert werden.
Diese Warteschlangenlösung hat mehrere Nachteile. Die meisten Slaves benötigen keine langen Warteschlagen, um zwischen wartenden Übertragungsanforderungen zu arbitrieren, um Optimierungsziele zu erreichen. Für diese Slaves sind Parkwarteschlangen eine Platzverschwendung. Für den Slave sollte die Warteschlange lang genug sein, um eine Anzahl von Übertragungsanforderungen zu speichern, die größer oder gleich ist der Gesamtzahl von Übertragungsanforderungen, die insgesamt durch alle Master, die mit dem Slave verbunden sind, gestellt werden können. Dies ist oft nicht der Fall. Wenn eine der Slaveparkwarteschlangen voll wird, da sie nicht korrekt dimensioniert ist, können Transaktionen in der Verbindung gespeichert werden.
Aufgrund der Reihenfolgeanordnung auf dem Bus oder damit zusammenhängender Blockierungsprobleme, kann es unmöglich oder komplex sein, mehr als eine Übertragungsanforderung gleichzeitig über einen Busumschaltknoten auszugeben, wenn zwei oder mehrere Ziele betroffen sind. Beispiele für Reihenfolgebeschränkungen sind Situationen, die an Busumschaltknoten für AMBA (Advances Microcontroller Bus Architecture) AXI (Advances Extensible Interface) Busschreibtransaktionen für zwei oder mehrere Ziele und für ABMA AXI Buslesetransaktionen für zwei oder mehrere Ziele mit der gleichen ID beobachtet werden. Eine Slavewarteschlange kann in der Lage sein, mehrere Transaktionsanforderungen zu speichern, aber das Netzwerk kann intrinsisch keine Transaktionsanforderungen mehr ausgeben. In diesen Situationen kann ein Arbitrieringsknoten noch immer eine Anforderung mit hoher Priorität weiter oben in dem Netzwerkübertragungsanforderungspfad blockieren, da lokal an dem Arbitrierungsknoten eine geringfügig höhere Priorität einem anderen Zweig des Netzwerkes gegeben wird, oder weil ein Algorithmus zur gerechten Verteilung (fair use) den ignorierten kritischen Netzwerkzweig erst später zuteilt, oder weil standardmäßig eine Bandbreitenoptimierung läuft, wenn an dem Arbitrierungsknoten keine Dringlichkeit ersichtlich ist. In diesen Situationen ist das Arbitrierungsschema über das gesamte Busnetzwerk inkonsistent, was zu Stabilitäts- und Performanzproblemen führt.
Andere Lösungen sind vorgeschlagen worden, um einige der oben beschriebenen Probleme zu umgehen, inklusive einer Beschränkung der Zahl der Anforderungen oder der Anforderungsrate an den Mastern, um eine Verstopfung des Netzwerkes und der Slavewarteschlange zu vermeiden, einer lokalen Bandbreitenreservierung an den Netzwerkknoten, längeren Slavewarteschlangen mit einer Warteschlangenplatzreservierung für manche kritische Master, einer Vergrößerung oder Duplizierung von Busschichten. Diese Lösungen erfordern jedoch häufig eine erhöhte Komplexität der Logik oder haben andere Beschränkungen, die eine Bandbreitenoptimierung verhindern.
Busprotokolle ohne Unterstützung für ausstehende Transaktionen und streng geordnete Busprotokolle, wie z.B. das AMBA High Speed Bus (AHB) Protokoll sind häufig weniger problematisch, da sie keine native Servicequalitätsunterstützung zur Verfügung stellen. Busse, die diese Protokolle implementieren, haben den Vorteil eines geringen Platzbedarfes und geringer Latenzen, aber sie haben auch Probleme mit der Stabilität und Performanz, die diese Busse daran hindert, ein konsistentes und effizientes systemweites Arbitrierungsschema zu haben.
Aus DE 601 27 357 T2 ist ein Buscontroller mit dynamischem Prioritätsschema bekannt. Dabei werden Anfragen mit niedriger Priorität zurückgestellt, wenn die Daten von dem Ziel nicht verfügbar sind.
US RE38 428 E beschreibt ein Bussystem mit jeweils mehreren Mastern und Slaves, wobei eine Umsortierung von Bustransaktionen stattfindet.
Es wird eine Busarchitektur offenbart, die eine Transaktionswarteschlangenreallokation auf den unter Verwendung des Busses kommunizierenden Modulen zur Verfügung stellt. Ein Modul kann mittels einer digitalen elektronischen Schaltung, z.B. Hardware oder Software oder einer Kombination derselben, eine Transaktionsanforderungswarteschlange implementieren. Manche Busverstopfungsprobleme, die herkömmliche Systeme betreffen, können vermieden werden, indem ein Außer-der-Reihe-Systembusprotokoll, das einen Transaktionsanforderungswiederabspielmechanismus verwendet, kombiniert wird. Module können weniger dringende Transaktionen aus der Transaktionsanforderungswarteschlange zwangsweise entfernen, um Platz zu schaffen für die Einfügung dringenderer Transaktionen. Mastermodule können einen Servicequalitätswert (QoS) für eine Transaktion dynamisch aktualisieren, während die Transaktion noch anhängig ist.
Bestimmte Implementierungen der Reallokationstechniken für die die Systembustransaktionswarteschlangen können einen oder mehrere der folgenden Vorteile haben: 1) Transaktionsanforderungen können in konsistenter Weise bis zu und inklusive eines Targetbusslaves durch die Busknoten in Übereinstimmung mit einer Servicequalitätsanforderungen für die Transaktionsanforderung vorangebracht werden, selbst wenn der Targetbusslave oder ein anderer Busslave eine volle Transaktionsanforderungswarteschlange hat; 2) Unter Verwendung eines Transaktionsanforderungswiederabspielmechanismus, der durch den Master initiiert wird, kann ein Busmaster die Servicequalitätsanforderung für jede seiner Transaktionen dynamisch aktualisieren, selbst wenn die Transaktionsanforderung den Targetbusslave bereits erreicht hat; 3) Unter Verwendung der zwangsweisen Entfernung von Transaktionsanforderungen und des durch den Busslave initiierten Transaktionsanforderungswiederabspielmechanismus kann ein Busslave seine bereits volle Warteschlange mit anstehenden Transaktionen mit den kritischeren oder relevanteren Transaktionsanforderungen aktualisieren, die die aktuellen Masteranforderungen erfüllen; 4) Eine kleine Zahl von zusätzlichen Signalen und Pufferressourcen kann einen Standardbus mit niedriger Komplexität und geringem Platzbedarf in einen Bus verwandeln, der kürzere Zugriffslatenzen zur Verfügung stellt, als Busse mit hoher Komplexität und hohem Platzbedarf; 5) Die Systembusarchitektur kann die Servicequalitätsbedürfnisse befriedigen, die bei Bussen und Geräten auftreten können, die eine Außer-der-Reihe-Handhabung von mehreren ausstehenden Transaktionen beherrschen; und 6) Die Systembusarchitektur ermöglicht die Koexistenz von außer der Reihe wieder abspielbaren ausstehenden Transaktionsanforderungen mit herkömmlichen, in einem Zug durchlaufenden, strikt geordneten klassischen Transfers über die gleichen Busschichten ohne Einschränkungen.
Figurenliste

1 ist ein Blockdiagramm eines Beispielmikrocontrollers mit zumindest einem Modul, das zur Durchführung einer Transaktionswarteschlangenreallokation konfiguriert ist.
2 ist ein schematisches Diagramm, das zwei beispielhafte Mastertransaktionsanforderungswarteschlangen für die Mastermodule Master 0 und Master 1 und eine beispielhafte Slavetransaktionsanforderungswarteschlange für das Slavemodul Slave 0 illustriert.
3 ist ein Blockdiagramm, das eine Anordnung von Modulen illustriert, die dem in 2 illustrierten Szenario entsprechen.
4 ist ein Zeitablaufdiagramm, das eine Reihe von Bussignalen in einer beispielhaften Transaktionssequenz über die AHB-Busschicht 1 illustriert.
5 ist ein schematisches Diagramm, das die beispielhaften Mastertransaktionsanforderungswarteschlangen und die Slavetransaktionsanforderungswarteschlange aus 2 nach der beispielhaften Transaktionssequenz aus 4 zeigt.
6 ist ein Zeitablaufdiagramm, das eine Reihe von Bussignalen in einer beispielhaften Transaktionssequenz zeigt.
7 ist ein schematisches Diagramm, das die beispielhaften Mastertransaktionsanforderungswarteschlangen und die Slavetransaktionsanforderungswarteschlange aus 5 nach der beispielhaften Transaktionssequenz aus 6 zeigt.
8 ist ein Zeitablaufdiagramm, das eine Reihe von Bussignalen in einer beispielhaften Transaktionssequenz zeigt.
9 ist ein schematisches Diagramm, das die beispielhafte Mastertransaktionsanforderungswarteschlangen und die Slavetransaktionsanforderungswarteschlange aus 7 nach der beispielhaften Transaktionssequenz aus 8 zeigt.
10 ist ein Zeitablaufdiagramm, das eine Reihe von Bussignalen in einer beispielhaften Transaktionssequenz zeigt.
11 ist ein schematisches Diagramm, das die beispielhaften Mastertransaktionsanforderungswarteschlangen und die Slavetransaktionsanforderungswarteschlange aus 9 nach der beispielhaften Transaktionssequenz aus 10 zeigt.
12 ist ein schematisches Diagramm, das ein Beispiel einer partitionierten Slavetransaktionsanforderungswarteschlange zeigt.
13 ist ein schematisches Diagramm, das beispielhafte Transaktionsanforderungswarteschlangen in einem Beispiel zeigt, in dem der Slave weiß, dass die durch einen Master ausgegebenen Transaktionen geordnet sind.

DETAILLIERTE BESCHREIBUNG
Die offenbarten Implementierungen können in einer integrierten SOC-Schaltung (System-on-a-chip) enthalten sein, die eine Vielzahl von Systembusmastern enthält, von denen manche oder alle über einen oder mehrere Masterports gekoppelt sein können, die wiederum über einen oder mehrere Systembusmatrixschalter mit einer Vielzahl von Systembusslaves gekoppelt sein können, von denen manche Multiportbusslaves oder Einzelportbusslaves sein können.
1 ist ein Blockdiagramm eines beispielhaften Mikrocontrollers 100 mit zumindest einem Modul, das zur Durchführung einer Transaktionswarteschlagenreallokation konfiguriert ist. In manchen Implementierungen kann der Mikrocontroller 100 Busmaster 101-105 und Busslaves 120-124 enthalten. Andere Implementierungen können eine größere oder eine kleinere Zahl von Mastern und Slaves enthalten.
In dem dargestellten Beispiel umfassen die Busmaster einen Mikroprozessorkern 101, einen DMA-Controller 102 (Direktspeicherzugriffscontroller), einen Displaycontroller 103, einen Hochgeschwindigkeitsperipheriebusmaster 104 und einen Busmaster M 105. Die Busslaves umfassen einen Multiportspeichercontroller 120, und On-Chip-Speicher 121, Busslaves 122, einen Massenspeicherperipheriebusslave 123 und eine Niedergeschwindigkeitsperipheriebusbrücke 124. Die Busslaves können Einzelport- oder Multiportslaves mit N Slaveports sein, die individuell mit einem von N oder weniger Slaveports von einer oder von mehreren Systembusmatrizen verbunden sind. Ein beispielhafter Multiportslave ist der Speichercontroller 120. Die Busmaster können mit einer oder mit mehreren Busmatrizen verbunden sein, oder unter Verwendung von einem oder von mehreren Masterports direkt mit Busslaves verbunden sein. Die Busmaster oder die Busslaveperipheriegeräte können über die dedizierte Verbindungsflächen 150-157 außerhalb des Mikrocontrollers 100 verbunden sein, müssen aber nicht.
Die Busmatrizen 110, 112 können in dem Entwurf von identischen oder unterschiedlichen Datenbusbreiten verwendet werden, wie z.B. den internen Bussen 111, 113, je nachdem ob sie mit der gleichen Taktgeschwindigkeit arbeiten oder nicht. Jedes Matrixpaar kann eine Verbindung zwischen einem oder mehreren Masterports und einem oder mehreren Slaveports zur Verfügung stellen, wie z.B. die Matrix 110, die mit nur einem ihrer Slaveports über die Busbrücke 131 mit dem Masterport der Matrix 112 verbunden dargestellt ist. Die Matrix 112 ist mit nur einem ihrer Slaveports über die Busbrücke 130 mit den Masterports der Matrix 110 verbunden dargestellt. Ob ein gegebener Busmatrixslave von einem gegebenen Master über einen eindeutigen oder über mehrere Pfade erreicht werden kann, ist designabhängig.
Die Module können über den Bus unter Verwendung eines nicht-blockierenden Datenbusprotokolls kommunizieren. Bei einem nicht-blockierenden Datenbusprotokoll halten die Slavemodule den Bus nicht an. Anstelle den Bus anzuhalten, gibt ein Slavemodul die Busschicht an seinen Ports nach einer gewissen Zeit frei, unabhängig vom internen Zustand des Slaves.
Die Busslaves können Endpunkte des Systembus sein, müssen aber nicht. Busslaves, die keine Systembusendpunkte sind, können z.B. als Busmaster auf einer nachgelagerten Busschicht agieren. Mögliche Beispiele sind die Busbrücken 130 und 131. Die Busbrücke 131 kann als Busslave der Busmatrix 110 und als Busmaster der Busmatrix 112 agieren. Zur Illustration eines weiteren Beispiels können Busslaves, wie z.B. Slave 0, nicht nur als temporäre Speicher für einen nachgelagerten Bus dienen, sondern auch als komplexere endgültige Zielbestimmung. Ein Beispiel einer komplexeren endgültigen Zielbestimmung ist der Multiportspeichercontroller 120.
In dem Beispielmikrocontroller implementieren zumindest ein Master und zumindest ein Slave jeweils eine Transaktionsanforderungswarteschlange. Eine Transaktionsanforderungswarteschlange speichert Informationen über eine Reihe von Anforderungen, die in Verarbeitung sind, oder darauf warten, verarbeitet zu werden. Ein Modul kann eine Transaktionsanforderungswarteschlange mittels einer digitalen elektronischen Schaltung implementieren, z.B. Hardware oder Software oder einer Kombination von beiden. In diesem Beispiel können bestimmte Busverstopfungsprobleme, die herkömmliche Systeme betreffen, vermieden werden, indem ein Außer-der-Reihe-Systembusprotokoll, das einen Transaktionsanforderungswiederabspielmechanismus verwendet, kombiniert wird. Module können weniger dringende Transaktionen aus den Transaktionsanforderungswarteschlangen zwangsweise entfernen, um Platz zu schaffen, um dringendere Transaktionen einzufügen.
Wenn ein Slave eine neu hereinkommende Transaktionsanforderung empfängt, aber die Transaktionsanforderungswarteschlange des Busses voll ist, dann kann der Slave das Anhalten des Busses vermeiden, indem Transaktionswarteschlangen-Reallokationstechniken verwendet werden. Jede neue Transaktionsanforderung kann entweder in die Slavetransaktionsanforderungswarteschlange eingefügt werden oder vorübergehend aufgeschoben werden, auf Basis des Servicequalitätswertes der hereinkommenden Transaktionsanforderung und der Servicequalitätswerte der Transaktionsanforderungen in der Transanforderungswarteschlange. Der Slave kann verschiedene Anforderungen, Dienstleistungen, Fortschritte und Abschlüsse der Transaktionen in jeder geeigneten Reihenfolge verarbeiten, um die Optimierungsziele innerhalb der durch die Datenkonsistenz erlaubten Grenzen zu verbessern oder zu maximieren.
Der Slave kann über die aufgeschobenen Transaktionsanforderungen Buch führen, z.B. unter Verwendung einer Warteschlange mit geringem Mehraufwand, z.B. einem Bit oder mehr pro Transaktion. Wenn in der Slavetransaktionsanforderungswarteschlange Platz frei wird, z.B. weil der Slave einige der Transaktionen abschließt, dann kann der Slave die aufgeschobenen Transaktionsanforderungen zurückrufen. Eine aufgeschobene Transaktionsanforderung kann bei dem Datenübertragungstakt wieder aufgenommen werden, bei dem die Transaktion unterbrochen wurde, bis die Transaktion vollständig abgeschlossen ist. In manchen Implementierungen ruft der Slave alle aufgeschobenen Transaktionsanforderungen zurück und alle zurückgerufenen Transaktionsanforderungen werden erneut ausgegeben, wobei die Einschränkungen der Transaktionsreihenfolge beibehalten werden. In manchen anderen Implementierungen ruft der Slave bestimmte Teilmengen der aufgeschobenen Transaktionsanforderungen zurück, z.B. solange bis alle aufgeschobenen Transaktionsanforderungen zurückgerufen wurden.
In manchen Fällen stellt ein Master fest, dass eine Transaktion oder ein Strom von Transaktionen in seiner Transaktionsanforderungswarteschlange die Priorität geändert hat. Der Master kann den Servicequalitätswert für die Transaktion oder den Strom von Transaktionen aktualisieren, indem die Transaktionsanforderungen erneut ausgegeben werden, wobei die Einschränkungen der Transaktionsreihenfolge beibehalten werden. Dies ist nützlich, da z.B. dringendere Transaktionsanforderungen im Pfad von dem Master zum Slave vor weniger dringende Transaktionsanforderungen gelangen können. Ein Master, der eine teilweise abgeschlossene Transaktionsanforderung initiiert hat, kann später eine oder mehrere Wiederabspielungen der Transaktionsanforderungen bei einem Datentransfertakt initiieren, an dem die Transaktion unterbrochen wurde, solange bis die Transaktion vollständig abgeschlossen ist. Der Master kann den Servicequalitätswert der Transaktion für die Transaktionsdaten aktualisieren, die für diese bestimmte Transaktion noch zu übertragen sind.
2 ist ein schematisches Diagramm, das zwei beispielhafte Mastertransaktionsanforderungswarteschlangen für die Mastermodule Master 0 und Master 1 und eine beispielhafte Slavetransaktionsanforderungswarteschlange für das Slavemodul Slave 0 zeigt. Die Transaktionsanforderungswarteschlangen speichern Transaktionsanforderungen, indem Eigenschaften der Transaktionen, wie z.B. Adressdaten und Datengrößen gespeichert werden.
Die Transaktionsanforderungswarteschlange für Master 0 ist dazu konfiguriert, bis zu m0-Transaktionen zu speichern. Die Transaktionsanforderungswarteschlange für Master 1 ist dazu konfiguriert, bis zu m1 Transaktionen zu speichern. Die Transaktionsanforderungswarteschlange für Slave 0 ist dazu konfiguriert, bis zu s0-Transaktionen zu speichern. Die Gesamtzahl der Transaktionsanforderungen, die am Slave 0 anhängig sein können, ist p0. In dem Beispiel, in dem Master 0 und Master 1 die einzigen Module in einem Master/Slaveverhältnis mit dem Slave 0 stehen, gilt p0 = m0 + m1. Abhängig von dem jeweiligen Design der Slave- und Mastermodule und der Verbindungen zwischen den Mastern und den Slaves kann s0 kleiner oder gleich p0 sein.
Der Slave ist dazu konfiguriert, anhängige Transaktionen zu markieren, die nicht in der Transaktionsanforderungswarteschlange gespeichert sind. Die Anzahl der anhängigen Transaktionen, die an dem Slave markiert werden können, ohne in der Transaktionsanforderungswarteschlange für den Slave gespeichert zu werden, beträgt r0. In manchen Implementierungen gilt p0 = s0 + r0.
Der Slave 0 kann z.B. einen Puffer mit geringem Mehraufwand enthalten, der anhängige Transaktionsanforderungen speichert, so dass die Eigenschaften der Transaktionsanforderungen nicht in der Transaktionsanforderungswarteschlange für den Slave gespeichert werden, sondern ausgelagert an dem Master gespeichert werden und darauf warten, später wieder abgespielt zu werden. Wie in 2 dargestellt ist, kann ein Bit für jede der p0 Transaktionen für die p0-Markierung verwendet werden, m0t0 bis m1t3. Jede Markierung entspricht einer möglichen anhängigen Transaktionsanforderung von einem der Mastermodule. Der Slave kann bis zu r0 entfernt gespeicherte Transaktionsanforderungen als anhängige Transaktionen markieren, die später an einem der Slaveports wieder abgespielt werden sollen.
In manchen Implementierungen umfasst eine Transaktionsanforderung Adress- und Steuersignale, die in geeigneter Weise durch die Busmatrixschalter für die Transaktionsanforderung dekodiert, weitergeführt und arbitriert werden, um den Slave zu erreichen, der von dem Master vorgesehen war, der die Transaktionsanforderung initiiert hat. Eine Transaktionsmarkierung kann jede Transaktion auf dem Systembus eindeutig kennzeichnen. Die Transaktionsmarkierung kann z.B. aus einem Paar aus der Identifikationsmarkierung des ursprünglichen Masters oder der Masternummer master_nb zusammen mit einer Transaktionsnummer tran_nb bestehen, die für diesen bestimmten Master eindeutig ist. Die Transaktionsmarkierung kann wie folgt notiert werden: {master_nb, tran_nb}. Die Transaktionsmarkierung kann, wie die anderen Adress- und Steuersignale der Transaktionsanforderungen, zeitlich abgestimmt werden.
Für jede der Transaktionsanforderungen auf dem Systembus kann das Zählen des Datenübertragungsfortschritts separat voneinander sowohl am Master als auch am Slave durchgeführt werden, oder eine explizite Längenangabe der verbleibenden Datenübertragung kann zu den durch den Mater angesteuerten Bussteuersignalen hinzuaddiert werden. Obwohl die explizite Längenangabe der verbleibenden Datenübertragung nicht erforderlich ist, wird sie in den Beispielen dieser Anmeldung zu Illustrationszwecken verwendet.
Eine Priorität oder ein Servicequalitätswert (QoS) kann mit jeder Transaktionsanorderung verknüpft sein. In manchen Implementierungen kann der QoS-Wert für eine Transaktionsanforderung während der Lebensdauer der Transaktionsanforderung variieren, was weiter unten stehend beschrieben wird. Abhängig von der Implementierung kann der QoS-Wert eine ähnliche zeitliche Abstimmung haben, wie die Adress- und Steuersignale, oder auch nicht. In den Beispielen dieser Anmeldung ist der QoS-Wert für den Slave während wohlbestimmter Abschnitte der Datenphase von Bedeutung.
Der Master kann dazu konfiguriert sein, die Transaktionsanforderungen in jeder Stufe des Transaktionsfortschritts zu initiieren oder erneut auszugeben. Der Master kann die durch die Slavetransaktionsrückrufe implizierte Reihenfolge oder die sich am Master aus neuen QoS-Anforderungen der Transaktionen ergebende Reihenfolge innerhalb der Grenzen verwenden, die durch die Datenkonsistenz gesteckt werden, z.B. herkömmliche Grenzen, die durch die Datenkonsistenz erlaubt werden. Manche Slaves, z.B. Busperipheriegeräte, können z.B. eine Adressierung in einer strikt geordneten Weise erfordern, wohingegen bei manchen Speichergeräten die Zugriffe nur in dem Fall geordnet sein müssen, in dem eine Adressraumkollision zwischen zwei Transaktionen vorliegt. Eine zusätzliche Signalisierung auf dem Bus kann auch die Reihenfolgebeschränkungen lockern, z.B. unter Verwendung eines Transaktionsstromkennzeichens.
Das in 2 illustrierte Beispielszenario zeigt einen komplexeren Fall, in dem die Master und die Slaves Transaktionen außer der Reihe verarbeiten können, woraus sich einige Mindestelemente für in der Reihe Transaktionspräsentationsanforderungen ergeben. Der Multiportspeichercontroller 120 in 1 kann z.B. mit gewisser Wahrscheinlichkeit eine Menge von Außer-der-Reihe-Transaktionsverarbeitungen ausführen. In einem anderen Beispiel können manche Master eine niedrige mittlere Zugriffslatenz haben, z.B. der Mikroprozessorkern 101 in 1. Für diese Master kann der Fortschritt der Transaktionen dargestellt werden, um die Anforderungen und/oder Datenübertragungseinheiten von zweien oder mehreren Transaktionen darzustellen, die auf dem Bus miteinander verschachtelt sind.
Aus Darstellungsgründen wird in den folgenden Illustrationen das Advances Microcontroller Bus Architecture (AMBA) Advanced High-performance (AHB)-Busprotokoll verwendet. Jedes andere geeignete Protokoll kann ebenfalls verwendet werden. Das System kann dazu konfiguriert werden, die folgenden Signale an das AMBA AHB Protokoll anzuhängen:

- Ein Transaktionsnummernsignal tran_nb, das während der Adressphase eines jeden AHB Bursts oder Einzelzugriffs gültig ist.
- Ein Restlängensignal tran_rlen, das während jeder AMBA AHB-Adressphase die nachfolgende Anzahl von Transaktionsadressphasen angibt, die noch durch eine Datenübertragung für die aktuelle Transaktion {hmaster, tran_nb} in ihrer Adressphase durchzuführen sind. Dieses tran_rlen-Signal ist optional, wird aber aus Darstellungsgründen angegeben.
- Ein Servicequalitätssignal QoS, das zumindest während des zweiten Zyklus der SPLIT-Antwort des Busslaves auf die zuvor im Adressraum befindliche Transaktionsanforderung gültig ist und die Priorität dieser Transaktion angibt. In manchen Implementierungen ist die Priorität der Transaktion umso höher, je höher der Wert dieses Signals ist.

Aus Darstellungsgründen wird angenommen, dass das AMBA AHB hburst-Signal, dass den Bursttyp angibt, in diesen Beispielen auf undefinierten inkrementierenden Burst INCR gesetzt ist. Für jede der p möglichen {hmaster, tran_nb} anhängigen Transaktionen an einem Busslave wird ein AMBA AHB entsprechendes HSPLIT-Bitsignal zum Zwecke eines Transaktionsrückrufs durch einen Busslave ausgegeben.
Eine Transaktion kann im Wesentlichen in einem von zwei Zuständen an dem Master sein:

1) Noch nicht gestartet, z.B. die {master_1, tran_1} Transaktion der 2.
2) Durch den Slave gesplittet sein, z.B. die {master_0, tran_0} oder {master_0, tran_1} Transaktionen in 2.

Eine Transaktion kann im Wesentlichen in einem von zwei Zuständen an dem Slave sein:

1) An dem Master entfernt anhängig sein; oder
2) innerhalb der Slavetransaktionsanforderungswarteschlange gespeichert sein.

Der Master muss nicht wissen, ob die Eigenschaften der Transaktion am Slave gespeichert wurden oder nicht. Der Slave darf in jedem der Transaktionsadresstakte mit einem SPLIT antworten. Der Master wartet üblicherweise darauf, dass der Slave eine gesplittete Transaktion über sein dediziertes HSPLIT-Bit zurückruft, bevor diese Transaktionsanforderung ausgehend von dem Adresstakt, den der Slave zuvor gesplittet hat, erneut ausgegeben wird, sofern der Master keine internen Gründe hat, diese erneute Ausgabe zu initiieren, wie bei einer Änderung in den QoS-Anforderungen der Transaktion, die am Slave aktualisiert werden müssen.
Jedesmal, wenn der Slave eine OKAY-Antwort für einen Transaktionsadresstakt ausgibt, werden die entsprechenden Daten übertragen und die Adresse für diese Transaktion und ihre Datentakte sind vollständig. Obwohl dies nicht vorgeschrieben ist, kann der Fortschritt der Transaktion unter Verwendung des tran_rlen-Wertes während jedes Adresstaktes bestimmt werden. Adresstakte, auf die mit einem SPLIT geantwortet wurde, werden später mit dem gleichen tran_rlen-Wert erneut ausgegeben, da für die Transaktionsdatenübertragung kein Fortschritt erzielt wurde.
Wenn auf die letzten Adresstakte der Transaktion mit OKAY geantwortet wurde, und somit die letzte Datenübertragung bestätigt wurde, ist die Transaktion selbst sowohl am Master als auch am Slave abgeschlossen. Die Transaktion wird dann sowohl von der Master- als auch der Slavetransaktionswarteschlange entfernt. Der Master kann die gleiche Transaktionsnummer sofort für eine neue Transaktion verwenden, die das erste Mal gestartet werden soll.
Solange eine Transaktion nicht abgeschlossen ist, können sowohl der Master als auch der Slave den Neustart der Transaktion an dem Adresstakt initiieren, an dem sie unterbrochen wurde. Dies kann so oft erfolgen, wie dies für alle Transaktionsadresstakte erforderlich ist, bis die Transaktion schließlich erfolgreich abgeschlossen ist.
In manchen Fällen wird der Slave nur auf einen oder auf zwei der Transaktionsadresstakte mit einem SPLIT antworten, z.B. auf den ersten Adresstakt für Lesetransaktionen und auf den ersten und/oder den letzten Adresstakt für eine Schreibtransaktion, abhängig davon, ob er die Schreibdaten sofort annehmen kann oder nicht. Falls alle Daten sofort übertragen werden können, z.B. für gepufferte Lesedaten oder gepufferte Schreibdaten, kann auf alle Transaktionsadresstakte mit OKAY geantwortet werden und die Transaktion wird nicht gesplittet und wird sich nicht in einem anhängigen Zustand befinden.
3 ist ein Blockdiagramm, das eine Anordnung von Modulen zeigt, die dem in 2 illustrierten Szenario entsprechen. 3 zeigt die AMBA AHB-Signale und die Zusatzsignale, die für die Transaktionswarteschlagenreallokationstechnik angefügt werden.
Slave 0 ist als AHB-Multiportslave dargestellt, bei dem ein AHB-Busmaster mit jedem seiner Slaveports verbunden ist. Man beachte, dass der AMBA AHB-Bus verschiedene andere Implementierungen ermöglicht, die mehrere Slaves oder Slaveports umfassen, die mit einem AHB-Master verbunden sind, und/oder einen Slaveport, der mit mehreren AHB-Mastern verbunden ist.
Die {hmaster_0, tran_nb_O}-Signale kodieren die aktuelle Transaktionsanforderung vom Master 0 während einer gültigen AHB-Adressphase. Die {hmaster _1, tran nb_1 }-Signale kodieren die aktuellen Transaktionsanforderungen vom Master 1 während einer gültigen AHB-Adressphase. Das tran_rlen_0-Signal kodiert die nachfolgende Anzahl von Transaktionsadressphasen, die noch an Master 0 abgeschlossen werden müssen. Das tran_rlen_1-Signal kodiert die nachfolgende Anzahl von Transaktionsadressphasen, die am Master 1 noch abgeschlossen werden müssen.
Das QoS_0-Signal kodiert bestimmte Servicequalitätsanforderungen am Master 0. Das QoS_1-Signal kodiert bestimmte Servicequalitätsanforderungen am Master 1. Das hsplit_0-Signal zeigt bei jedem Systembustaktzyklus die zurückgerufenen Master 0-Transaktionen an. Dieses Signal besteht aus einem Bit pro mögliche ausstehende Transaktionsnummer für Master 0. Das hsplit_1-Signal zeigt bei jedem Systembustaktzyklus die zurückgerufenen Master 1-Transaktionen an. Dieses Signal besteht aus einem Bit pro mögliche anhängige Transaktionsnummern für Master 1.
4 ist ein Zeitablaufdiagramm, das eine Reihe von Bussignalen in einer Beispieltransaktionssequenz auf der AHB-Busschicht 1 illustriert. Die Bussignale enthalten die AHB-Bussignale und die Zusatzsignale.
Die Beispielstransaktionssequenz zeigt eine eingehende Transaktionsanforderung {master_1, tran_1} für den Slave von dem Master 1-Modul. Die eingehende Transaktionsanforderung hat einen QoS-Wert von 1. Nachdem diese eingehende Transaktionsanforderung empfangen wurde, kann der Slave eine Transaktionsanforderungswarteschlangenreallokation durchführen.
5 ist ein schematisches Diagramm, das die beispielhaften Mastertransaktionsanforderungswarteschlangen und die Slavetransaktionsanforderungswarteschlange aus 2 nach der Beispieltransaktionssequenz aus 4 zeigt.
Die Slave 0-Transaktion {master_0, tran_3} wurde aus der Slavetransaktionsanforderungswarteschlange zwangsweise entfernt, da die Warteschlange voll war und da die eingehende Transaktion {master_1, tran_1} auf dem Bus einen QoS-Wert 1 hat, der größer ist als manche der s0 ausstehenden Warteschlangeneinträgen des Slave 0, z.B. des QoS-Wertes 0 der Transaktion {master_0, tran_3}. Die m0t3-Markierung für entfernte, verbleibende anhängige Transaktionsanforderungen wurde gesetzt. Die {master_1, tran_1}-Transaktionsanforderung ist jetzt im Slave 0 sO-Transaktionswarteschlangenpuffer.
Der Slave kann dazu konfiguriert sein, jeden geeigneten Reallokationsalgorithmus innerhalb der Slavetransaktionsanforderungswarteschlange zu verwenden. In manchen Implementierungen wird die zwangsweise entfernte Transaktion einen niedrigeren QoS-Wert haben, als die eingehende Transaktionsanforderung, und den niedrigsten QoS-Wert aller Einträge in der Transaktionsanforderungswarteschlange.
Wenn es mehrere Kandidaten für anhängige Transaktionsanforderungen gibt, die zwangsweise entfernt werden könnten, kann der zwangsweise entfernte Eintrag auf einem geeigneten Algorithmus basieren, z.B. auf Basis des Alters, so dass der neueste Kandidat entfernt wird, oder auf Basis von komplexeren Optimierungszielen an dem Slave, z.B. für einen dynamischen Speichercontroller, wobei ein Eintrag entfernt wird, dessen Adresse nicht zu einer offenen Speicherbank oder der aktuellen Speicherzeile gehört, anstelle eines Eintrags, bei dem dies der Fall ist. Abhängig von diesem Reallokationsalgorithmus und dem Zusammenhang, kann die entfernte Transaktionsanforderung zu dem gleichen Master wie die Transaktion, die die entfernte Transaktion ersetzt, gehören oder nicht.
6 ist ein Zeitablaufdiagramm, das eine Reihe von Bussignalen während einer Beispieltransaktionssequenz illustriert. Die Transaktionssequenz enthält einen Rückruf und Abschluss der {master_1, tran_2}-Transaktion durch einen hsplit_1 [2]-Puls für einen Taktzyklus.
7 ist ein schematisches Diagramm, das die beispielhaften Mastertransaktionsanforderungswarteschlangen und die Slavetransaktionsanforderungswarteschlange aus 5 nach der Beispieltransaktionssequenz aus 6 zeigt. Die {master_1, tran_2}-Transaktion ist abgeschlossen. Im Ergebnis gibt es keinen Platz mehr in der Slave 0-Transaktionsanforderungswarteschlange. Das Slave 0-Modul kann eine oder mehrere oder alle der entfernt anhängigen Transaktionsanforderungen zurückrufen. Wie in 7 dargestellt ist, sind die Markierungen für die entfernt anhängigen Transaktionsanforderungen für die m0t1, m0t3 und m1t3-Transaktionen gesetzt. Der Slave ruft diese Transaktionsanforderungen zurück, indem die entsprechenden hsplit-Bits hsplit_0[1], hsplit_0[3] und hsplit_1 [3] während eines Taktzyklusses gepulst werden.
8 ist ein Zeitablaufdiagramm, das eine Reihe von Busssignalen während einer Beispieltransaktionssequenz zeigt. Das Zeitablaufdiagramm zeigt den Slave, der die entfernt anhängigen Transaktionsanforderungen zurückruft, die in 7 dargestellt sind. Die beiden Master, Master 0 und Master 1, geben jede der zurückgerufenen Transaktionen in ihrer ursprünglichen Reihenfolge erneut aus, oder in jeder anderen Reihenfolge, wenn die Einhaltung der Reihenfolge nicht erforderlich ist. Der Slave 0 antwortet mit einem SPLIT auf beiden AHB-Busschichten.
9 ist ein schematisches Diagramm, das die beispielhaften Mastertransaktionsanforderungswarteschlangen und die Slavetransaktionsanforderungswarteschlange aus 7 nach der Beispieltransaktionssequenz aus 8 zeigt.
Die {master_0, tran_1} Transaktionsanforderung ist jetzt in der Slave 0 Transaktionsanforderungswarteschlange. Folglich wurde die Markierung m0 für eine entfernt anhängige Transaktion gelöscht. Der Slave kann jeden geeigneten Arbitrierungsalgorithmus für mehrere eingehende Anforderungen mit dem gleichen QoS-Wert an den Slaveports verwenden, wenn der Slave ein Multiportslave ist, oder innerhalb einer Busumschaltmatrix liegt, oder ansonsten. Ein Beispiel eines Arbitrierungsalgorithmus ist ein Round-Robin-Algorithmus, der es jedem Master der Reihe nach ermöglicht, einen verfügbaren Eintrag in dem Warteschlangenpuffer zugeteilt zu bekommen, wodurch zwischen den gleichzeitig wettstreitenden Mastertransaktionen arbitriert wird, die gleichermaßen den höchsten QoS haben.
10 ist ein Zeitablaufdiagramm, das eine Reihe von Bussignalen während einer Beispieltransaktionssequenz zeigt. Die Dringlichkeit der Master 1-Transaktion {master_1, tran_1} hat an dem Master von QoS=1 auf QoS=2 zugenommen. Der Master 1 gibt die {master_1, tran_1}-Transaktionsanforderung dann ausgehend von dem Adresstakt erneut aus, an dem sie zuvor gesplittet wurde, und zwar mit dem erhöhten QoS-Wert 2.
Wenn die Transaktionsanforderung nicht bereits Teil der Slave 0-Transaktionsanforderungswarteschlange war und stattdessen als entfernt anhängige Transaktion markiert war, dann wäre die zwangsweise Entfernung einer Transaktionsanforderung mit niedrigerem QoS aufgetreten, deren Platz der {master_1, tran_1}-Transaktionsanforderung zugewiesen worden wäre. Da aber die {master_1, tran_1}-Transaktionsanforderung bereits in der Transaktionsanforderungswarteschlange gespeichert ist, wird stattdessen der QoS-Wert für diese Transaktionsanforderung innerhalb der Transaktionsanforderungswarteschlange aktualisiert.
11 ist ein schematisches Diagramm, das die beispielhaften Mastertransaktionsanforderungswarteschlangen und die Slavetransaktionsanforderungswarteschlange aus 9 nach der Beispieltransaktionssequenz aus 10 zeigt. Die {master_1, tran_1}-Transaktionsanforderung hat nun einen QoS-Wert von 2 und der Master war somit in der Lage, den QoS dieser Transaktion zu aktualisieren, während sie am Slave noch anhängig war.
12 ist ein schematisches Diagramm, das ein Beispiel einer partitionierten Slavetransaktionsanforderungswarteschlange zeigt. Die Transaktionsanforderungswarteschlange ist in einen Bereich partitioniert, der nur von Lesetransaktionen verwendet werden kann, und einen Bereich, der sowohl von Lese- als auch von Schreibtransaktionen verwendet werden kann.
Schreibtransaktionen können im Gegensatz zu Lesetransaktionen bestimmte Herausforderungen mit sich bringen. In manchen Fällen können die Daten der Schreibtransaktionsanforderungen nicht rechtzeitig an dem Slave verarbeitet werden. Ein dynamischer Speichercontroller kann z.B. nur dazu in der Lage sein, Schreibzugriffe effizient zu behandeln, wenn er sicher weiß, dass die Daten rechtzeitig zur Verfügung stehen werden, wenn sie über seine externe Schnittstelle geschrieben werden sollen. Dies kann eine lokale Pufferung der Transaktionsdaten zusammen mit den anderen nützlichen Eigenschaften der Transaktion, wie z.B. der Adresse und der Größe, erfordern.
Da jedoch eine Reihe von Transaktionen mehrere Datenübertragungen über den Bus erfordern können, bevor diese vollständig an dem Slave gepuffert sind, kann es sich als unpraktikabel erweisen, eine bereits teilweise oder vollständig gepufferte Schreibtransaktion wieder zwangsweise zu entfernen. Dies könnte einen Neustart der Schreibtransaktion von einem höheren Punkt an erfordern, als wo sie unterbrochen wurde, wodurch eine gewisse Komplexität zu dem Busprotokoll hinzugefügt werden könnte. Dies wird z.B. durch das AMBA AHB-Protokoll nicht unterstützt. Darüberhinaus könnte dies zeit- und energieaufwendig sein.
Der Beispielslave, Slave 0, ist dazu konfiguriert, eine Transaktionswarteschlangenreallokation für Schreibtransaktionen auszuführen, indem eine beschränkte Anzahl von Lesetransaktionen für diesen Zweck zwangsweise entfernt wird. 12 zeigt eine Partitionierung der Transaktionsanforderungswarteschlange an dem Slave 0 in einem Beispielsszenario, in dem die möglichen QoS-Werte auf dem Bus in dem Bereich von 0 bis 2 liegen. Jede Lesetransaktionsanforderung kann jedem der bereits freien Plätze in dem Transaktionsanforderungspuffer zugewiesen werden. Dies ist möglich, da z.B. eine Lesetransaktionsanforderung zu einem späteren Zeitpunkt jederzeit wieder entfernt werden kann, falls erforderlich.
Eine Schreibtransaktionsanforderung kann einer gewissen begrenzten Anzahl von verfügbaren Slots innerhalb der Transaktionsanforderungswarteschlange zugeordnet werden. Damit wird eine Situation vermieden, in der die Transaktionswarteschlange bereits mit Schreibtransaktionen gefüllt ist, wenn eine einkommende Lesetransaktion eine höhere QoS-Anforderung hat, die dann nicht in die Transaktionsanforderungswarteschlange aufgenommen werden kann, da die Schreibtransaktionsanforderungen nicht entfernt werden können.
Die beschränkte Anzahl von Slots, die für Schreibtransaktionen verfügbar sind, wird durch QoS-Werte weiter beschränkt. Damit wird garantiert, dass eine eingehende Schreibtransaktion mit höherer QoS-Anforderung als die in der Transaktionsanforderungswarteschlange bereits gespeicherten Transaktionsanforderungen stets in den Transaktionswarteschlangenpuffer aufgenommen werden kann, ohne dass ein Warteschlangeneintrag entfernt werden muss.
Für die Schreibtransaktionen zeigt 12 nur einen der Transaktionsanforderungswarteschlangenslots, der zumindest einen QoS-Wert größer oder gleich 1 erfordert, und nur einen weiteren Slot für QoS-Werte größer oder gleich 2. Andere Implementierungen können mehrere mögliche Einträge haben, die mit jedem dieser mindestens erforderlichen QoS-Werte für eingehende Schreibtransaktionen verknüpft sind, z.B. zumindest einen für jeden Master.
13 ist ein schematisches Diagramm, das beispielhafte Transaktionsanforderungswarteschlangen in einem Beispiel zeigt, bei dem der Slave weiß, dass die von einem Master ausgegebenen Transaktionen geordnet sind.
Zum Beispiel sei angenommen, dass bekannt ist, dass die von dem Master ausgegebenen Transaktionen geordnet sind, entweder implizit, oder nur wenn sie ein gemeinsames Transaktionsstromkennzeichen haben, und dass der Slave diese Reihenfolge verfolgt oder dazu in der Lage ist, diese Reihenfolge durch Zurückrufen der entfernt anhängigen Transaktionsanforderungen wieder herzustellen. Dann kann innerhalb der Slavetransaktionsanforderungswarteschlange eine QoS-Aktualisierung für eingehende Transaktionen automatisch von den vorhergehenden ausstehenden Transaktionen von diesem Master geerbt werden. In 13 zeigen z.B. die resultierenden Zustände an dem Slave nach der in 10 durchgeführten QoS-Aktualisierung die zusätzliche QoS-Aktualisierung von {master_1, tran_0}, wenn der Slave feststellt, dass diese Transaktion ursprünglich am Master 1 vor {master_1, tran_1} ausgegeben wurde, und wenn die Transaktionsreihenfolge sowohl am Master 1 als auch am Slave 0 relevant ist.
Obgleich dieses Dokument zahlreiche spezifische Implementierungseinzelheiten enthält, sollten diese nicht als beschränkend für den Schutzumfang betrachtet werden, sondern als Beschreibung von Merkmalen, die bestimmten Ausführungsformen zu Eigen sein können. Bestimmte Merkmale, die in dieser Beschreibung im Zusammenhang mit getrennten Ausführungsformen beschrieben wurden, können auch in Kombination in einer einzigen Ausführungsform implementiert werden. Umgekehrt können verschiedene Merkmale, die im Zusammenhang mit einer einzelnen Ausführungsform beschrieben wurden, auch in mehreren Ausführungsformen getrennt voneinander oder in einer geeigneten Unterkombination implementiert werden. Obwohl darüberhinaus Merkmale als in bestimmten Kombinationen zusammenwirkend beschrieben wurden und sogar anfänglich solchermaßen beansprucht wurden, können in manchen Fällen ein oder mehrere Merkmale aus einer beanspruchten Kombination aus der Kombination herausgelöst werden und die beanspruchte Kombination kann auf eine Unterkombination oder eine Variation einer Unterkombination gerichtet werden.

Claims

System, umfassend: einen Systembus; und eine Vielzahl von Modulen, die mit dem Systembus verbunden sind und dazu konfiguriert sind, miteinander unter Verwendung des Systembusses zu kommunizieren, beinhaltend: ein Mastermodul, das eine Mastertransaktionsanforderungswarteschlange implementiert; und ein Slavemodul, das eine Slavetransaktionsanforderungswarteschlange implementiert, wobei das Slavemodul dazu konfiguriert ist, Slavemoduloperationen auszuführen, die umfassen: Empfangen einer ersten Transaktionsanforderung von dem Mastermodul; Feststellen, dass die Slavetransaktionsanforderungswarteschlange voll ist; als Reaktion auf die Feststellung, dass die Slavetransaktionsanforderungswarteschlange voll ist, festlegen auf Basis von zumindest einer ersten anhängigen Transaktion in der Slavetransaktionsanforderungswarteschlange, dass die erste anhängige Transaktion nicht aus der Slavetransaktionsanforderungswarteschlange entfernt werden soll, und dass die erste Transaktionsanforderung nicht in die Slavetransaktionsanforderungswarteschlange eingefügt werden soll; und als Reaktion auf die Festlegung, dass die erste anhängige Transaktion nicht entfernt werden soll, Verschieben der ersten Transaktionsanforderung durch Speichern einer ersten Aufzeichnung für die erste Transaktionsanforderung für ein späteres Wiederabspielen der ersten Transaktionsanforderung.
System nach Anspruch 1, wobei die Festlegung, dass die erste anhängige Transaktion nicht entfernt werden soll, eine Feststellung umfasst, dass ein Servicequalitätswert für die erste anhängige Transaktion größer ist als ein Servicequalitätswert für die erste Transaktionsanforderung.
System nach Anspruch 1, wobei die Slavemoduloperationen weiterhin umfassen: Empfangen einer zweiten Transaktionsanforderung von dem Mastermodul; Feststellen, dass die Slavetransaktionsanforderungswarteschlange voll ist; als Reaktion auf die Feststellung, dass die Slavetransaktionsanforderungswarteschlange voll ist, festlegen, dass eine zweite anhängige Transaktion von der Slavetransaktionsanforderungswarteschlange entfernt werden soll, und dass die zweite Transaktionsanforderung in die Slavetransaktionsanforderungswarteschlange eingefügt werden soll; und als Reaktion auf die Entfernung der zweiten anhängigen Transaktion, verschieben der zweiten anhängigen Transaktion durch Speichern einer zweiten Aufzeichnung für die zweite anhängige Transaktion für eine spätere Wiederaufspielung der zweiten anhängigen Transaktion.
System nach Anspruch 3, wobei die Festlegung, die zweite anhängige Transaktion zu entfernen, eine Feststellung umfasst, dass ein Servicequalitätswert der zweiten Transaktionsanforderung größer ist, als ein Servicequalitätswert der zweiten anhängigen Transaktion.
System nach Anspruch 1, wobei das Mastermodul dazu konfiguriert ist, Mastermoduloperationen auszuführen, die umfassen: Senden der ersten Transaktionsanforderung über den Systembus an das Slavemodul mit einem ersten Servicequalitätswert, wodurch das Slavemodul veranlasst wird, die erste Transaktionsanforderung in der Slavetransaktionswarteschlange mit dem ersten Servicequalitätswert zu speichern; und Senden eines zweiten Servicequalitätswertes für die erste Transaktionsanforderung, wodurch das Slavemodul veranlasst wird, den ersten Servicequalitätswert in der Slavetransaktionswarteschlange mit dem zweiten Qualitätswert zu aktualisieren.
System nach Anspruch 1, wobei das Mastermodul dazu konfiguriert ist, eine oder mehrere Wiederabspielungen der ersten Transaktionsanforderung zu initiieren, bis die erste Transaktionsanforderung abgeschlossen ist, wobei jede Wiederabspielung der ersten Transaktionsanforderung bei einem Datenübertragungstakt beginnt, an dem die erste Transaktionsanforderung unterbrochen wurde, und wobei das Mastermodul dazu konfiguriert ist, einen Servicequalitätswert für die erste Transaktionsanforderung bei zumindest einer der einen oder der mehreren Wiederabspielungen der ersten Transaktionsanforderung zu aktualisieren.
System nach Anspruch 1, wobei die Slavemoduloperationen desweiteren umfassen: Rückrufen, für jede Aufzeichnung einer verschobenen Transaktionsanforderung, die durch das Slavemodul gespeichert wurde, einer Wiederabspielung der verschobenen Transaktionsanforderung, wobei jedes entsprechende Mastermodul veranlasst wird, jede verschobene Transaktionsanforderung wieder abzuspielen; Durchführen einer Arbitrierung zwischen den wieder abgespielten Transaktionsanforderungen, um zu ermitteln, welche der wieder abgespielten Transaktionsanforderungen in der Slavetransaktionsanforderungswarteschlange gespeichert werden soll.
System nach Anspruch 1, wobei die Vielzahl von Modulen dazu konfiguriert ist, über den Systembus unter Verwendung eines nicht blockierenden Transaktionsprotokolls zu kommunizieren.
System nach Anspruch 1, wobei der Systembus eine Vielzahl von Masterbusschichten und eine Vielzahl von Slavebusschichten umfasst, und wobei der Systembus dazu konfiguriert ist, Signale der Masterbusschicht dynamisch zu den Slavebusschichten zu leiten, und wobei der Systembus enthält: eine Vielzahl von Decodern, wobei jeder Decoder der Vielzahl von Decodern mit einer der Vielzahl von Masterbusschichten verbunden ist und dazu konfiguriert ist, Adresssignale zu decodieren, die von der verbundenen Masterbusschicht empfangen wurden; eine Vielzahl von Arbitrierern, wobei jeder Arbitrierer der Vielzahl von Arbitrierern mit jedem der Vielzahl von Decodern verbunden ist und dazu konfiguriert ist, ein Auswahlsignal auf Basis eines Ergebnisses einer Arbitrierung von Übertragungsanforderungen und Servicequalitätssignalen, die von zwei oder mehreren Masterbusgeräten erzeugt wurden, auszugeben; und eine Vielzahl von Schaltern, wobei jeder Schalter der Vielzahl von Schaltern mit einem Arbitrierer der Vielzahl von Arbitrierern und jeder der Vielzahl von Masterbusschichten verbunden ist, wobei jeder der Vielzahl von Schaltern durch eines der Auswahlsignale dazu konfiguriert ist, eine der Vielzahl von Masterbusschichten mit einer der Vielzahl von Slavebusschichten zu verbinden.
System nach Anspruch 1, wobei das Slavemodul dazu konfiguriert ist, einen oder mehrere Slots in der Slavetransaktionsanforderungswarteschlange für Schreibtransaktionsanforderungen zu reservieren.
Verfahren zur Durchführung durch ein Slavemodul, das über einen Systembus kommuniziert, umfassend: Empfangen einer ersten Transaktionsanforderung von einem Mastermodul; Feststellen, dass eine Slavetransaktionsanforderungswarteschlange voll ist; als Reaktion auf die Feststellung, dass die Slavetransaktionsanforderungswarteschlange voll ist, Festlegen auf Basis von zumindest einer ersten anhängigen Transaktion in der Slavetransaktionsanforderungswarteschlange, dass die erste anhängige Transaktion nicht von der Slavetransaktionsanforderungswarteschlange entfernt werden soll, und dass die erste Transaktionsanforderung nicht in die Slavetransaktionsanforderungswarteschlange eingefügt werden soll; und als Reaktion auf die Festlegung, die erste anhängige Transaktion nicht zu entfernen, Verschieben der ersten Transaktionsanforderung durch Speichern einer ersten Aufzeichnung für die erste Transaktionsanforderung für eine spätere Wiederabspielung der ersten Transaktionsanforderung.
Verfahren nach Anspruch 11, wobei die Festlegung, die erste anhängige Transaktion nicht zu entfernen, eine Feststellung umfasst, dass ein Servicequalitätswert für die erste anhängige Transaktion größer ist, als ein Servicequalitätswert für die erste Transaktionsanforderung.
Verfahren nach Anspruch 11, desweiteren umfassend: Empfangen einer zweiten Transaktionsanforderung von dem Mastermodul; Feststellen, dass die Slavetransaktionsanforderungswarteschlange voll ist; als Reaktion auf die Feststellung, dass die Slavetransaktionsanforderungswarteschlange voll ist, Festlegen, dass eine zweite anhängige Transaktion aus der Slavetransaktionsanforderungswarteschlange entfernt werden soll, und dass die zweite Transaktionsanforderung in die Slavetransaktionsanforderungswarteschlange eingefügt werden soll; und als Reaktion auf das Entfernen der zweiten anhängigen Transaktion, Verschieben der zweiten anhängigen Transaktion durch Speichern einer zweiten Aufzeichnung für die zweite anhängige Transaktion für eine spätere Wiederabspielung der zweiten anhängigen Transaktion.
Verfahren nach Anspruch 13, wobei die Festlegung, die zweite anhängige Transaktion zu entfernen, eine Feststellung umfasst, dass ein Servicequalitätswert der zweiten Transaktionsanforderung größer ist als ein Servicequalitätswert der zweiten anhängigen Transaktion.
Verfahren nach Anspruch 11, desweiteren umfassend: Zurückrufen, für jede Aufzeichnung einer verschobenen Transaktionsanforderung, die durch das Slavemodul gespeichert wurde, einer Wiederabspielung der verschobenen Transaktionsanforderung, wodurch jedes jeweilige Mastermodul veranlasst wird, jede verschobene Transaktionsanforderung wieder abzuspielen; und Durchführung einer Arbitrierung zwischen den wieder abgespielten Transaktionsanforderungen, um festzustellen, welche der wieder abgespielten Transaktionsanforderungen in der Slavetransaktionsanforderungswarteschlange gespeichert werden soll.
Verfahren nach Anspruch 11, desweiteren umfassend eine Kommunikation über den Systembus unter Verwendung eines nicht-blockierenden Transaktionsprotokolls.
Verfahren nach Anspruch 11, desweiteren umfassend Reservieren von einem oder von mehreren Slots in der Slavetransaktionsanforderungswarteschlange für Schreibtransaktionsanforderungen.
Verfahren zur Durchführung durch ein Mastermodul, das über einen Systembus kommuniziert, umfassend: Senden einer ersten Transaktionsanforderung über den Systembus an ein Slavemodul mit einem ersten Servicequalitätswert, wodurch das Servicemodul veranlasst wird, die erste Transaktionsanforderung in einer Slavetransaktionswarteschlange mit dem ersten Servicequalitätswert zu speichern; und Senden eines zweiten Servicequalitätswertes für die erste Transaktionsanforderung an das Slavemodul, wodurch das Slavemodul veranlasst wird, den ersten Servicequalitätswert in der Slavetransaktionswarteschlange mit dem zweiten Servicequalitätswert zu aktualisieren.
Verfahren nach Anspruch 18, desweiteren umfassend Initiieren von einer oder von mehreren Wiederabspielungen der ersten Transaktionsanforderung, bis die erste Transaktionsanforderung abgeschlossen ist.
Verfahren nach Anspruch 19, wobei jedes Wiederabspielen der ersten Transaktionsanforderung an einem Datentransfertakt beginnt, an dem die erste Transaktionsanforderung unterbrochen wurde.