DE102008034500A1

DE102008034500A1 - Arbitrierung

Info

Publication number: DE102008034500A1
Application number: DE102008034500A
Authority: DE
Inventors: Helmut Dr. Reinig; Soeren Sonntag
Original assignee: Infineon Technologies AG
Current assignee: Intel Corp
Priority date: 2007-08-22
Filing date: 2008-07-24
Publication date: 2009-02-26
Anticipated expiration: 2028-07-25
Also published as: US7734856B2; US20090055566A1; DE102008034500B4

Abstract

Ein hierarchisches Arbitrierungssystem weist eine Mehrzahl von Arbitrierern auf, wobei die Mehrzahl von Arbitrierern in einem Pipeline-Betrieb betrieben werden können und zumindest ein Teil der Mehrzahl von Arbitrierern ausgebildet ist, um selektiv in einem Nicht-Pipeline-Betrieb betrieben zu werden.

Description

In vielen technischen Gebieten werden Ressourcen durch mehr als eine Einheit oder Vorrichtung geteilt. Beispielsweise kann in einer Master-Slave-Configuration eine Mehrzahl von Mastern einen gemeinsamen Slave teilen, eine Mehrzahl von Einheiten kann einen gemeinsamen Bus teilen, eine Mehrzahl von Prozessoren kann einen gemeinsamen Speicher teilen oder Teile von Informationen, wie beispielsweise Datenpakete können über einen gemeinsamen Datenkanal übertragen werden. Wenn mehr als eine Einheit einen Zugriff auf eine geteilte Ressource zur gleichen Zeit verlangt, liegt ein Konflikt zwischen den Einheiten, die hinsichtlich eines Zugriffs anfragen, vor, da bei einem gegebenen Zeitpunkt lediglich eine der Einheiten einen Zugriff erhalten kann, während für die anderen ein Zugreifen verhindert werden muss.
Um dieses Problem anzugehen, wird Arbitrierung verwendet. Arbitrierung ist ein Prozess, bei dem einer Einheit eine Priorität über eine anderen Einheit (oder einer Mehrzahl von anderen Einheiten) gegeben wird. Viele Arbitrierungstechniken mit unterschiedlichen Graden von Fairness für die Anfrager (requester) und unterschiedlichen Graden der Komplexität sind bekannt. Arbitrierung kann beispielsweise die Anzahl von vorhergehenden Anfragen einer bestimmten Einheit oder der Identität der Einheit (das heißt der Identität des Anschlusses) in Betracht ziehen. Ferner können faire Arbitrierungstechniken in Betracht ziehen, dass Anfrager fair gehandhabt werden und ein Anfrager beispielsweise nicht durch einen anderen Anfrager geblockt wird. Faire Arbitrierungstechniken umfassen beispielsweise eine round-robin-Arbitrierung (RR-Arbitrierung), eine weighted-round-robin-Arbitrierung (WRR-Arbitrierung) oder eine deficit-round-robin-Arbitrierung (DRR-Arbitrierung).
Die Aufgabe der vorliegenden Erfindung besteht darin, ein Konzept für eine verbesserte Arbitrierung zu schaffen.
Diese Aufgabe wird durch ein Verfahren gemäß Anspruch 1, ein Arbitrierungsknoten gemäß Anspruch 12, ein Arbitrierersystem gemäß Anspruch 16 und ein Arbitrierersystem gemäß Anspruch 20 gelöst.
Die vorliegende Erfindung schafft ein Verfahren bei dem eine Mehrzahl von Arbitrierern in einem Pipeline-Modus betrieben wird und zumindest eines Teils der Mehrzahl von Arbitrierern in einem Nicht-Pipeline-Betrieb erfolgen kann.
Bei einem Ausführungsbeispile umfasst der Pipeline-Modus ein Liefern eines ersten Signals von einem ersten Arbitrierer zu einem zweiten Arbitrierer basierend auf einer Arbitrierung bei dem ersten Arbitrierer und der Nicht-Pipeline-Betrieb ein Liefern eines zweiten Signals zu dem zweiten Arbitrierer unabhängig von einer Arbitrierung bei dem ersten Arbitrierer. Ein Arbitrieren bei dem zweiten Arbitrierer erfolgt basierend auf dem zweiten Signal.
Bei einem Ausführungsbeispiel ist wird das zweite Signal in dem Pipeline-Modus und dem Nicht-Pipeline-Betrieb geliefert, wobei in dem Pipeline-Modus eine Arbitrierung bei dem zweiten Arbitrierer basierend auf dem ersten Signal über eine Arbitrierung basierend auf dem zweiten Signal priorisiert wird.
Die Mehrzahl von Arbitrierern kann eine Mehrzahl von Arbitrierern eines hierarchischen Arbitrierungssystem sein, wobei das erste Signal ein Pipelineanfragesignal ist und das zweite Signal ein Vorausschausignal ist. Das Betreiben in dem Pipeline-Modus kann ein Liefern des Pipelineanfragesignals von dem ersten Arbitrierer zu einem ersten Eingangstor des zweiten Arbitrierers basierend auf der Arbitrierung zwischen der Mehrzahl von Eingangsports an dem ersten Arbitrierer umfassen, und der zweite Arbitrierer kann auf einer dem ersten Arbitriere übergeordneten Ebene implementiert sein. Der Nicht-Pipeline-Betrieb kann ein Liefern des Vorausschausignals zu einem ersten Eingangsport des zweiten Arbitrierers auf einer übergeordneten Ebene umfassen, wobei das Vorausschausignal unabhängig von einem Arbitrieren bei dem ersten Arbitrierer ist. Ferner wird ein drittes Signal basierend auf dem Vorausschausignal geliefert, das eine Gewährung für den ersten Eingangsport anzeigt.
Der zumindest eine Teil der Mehrzahl von Arbitrierer kann in einem Nicht-Pipeline-Betrieb betrieben werden, wenn der zumindest eine Teil der Mehrzahl von Arbitrierer in dem vorhergehenden Zyklus in einem Leerlaufzustand ist oder in dem vorhergehenden Zyklus keine aktive Pipelineanfrage aufweist.
Der Nicht-Pipeline-Betrieb kann hierbei ein paralleles Durchführen einer Arbitrierung einer Anfrage von zumindest einem Anfrager einer Mehrzahl von Anfragern umfassen.
Bei einem Ausführungsbeispiel wird für jeden der Mehrzahl von Arbitrierern Informationen gespeichert, die Tore anzeigen, denen durch einen jeweiligen der Mehrzahl von Arbitrierern Gewährung erteilt wurde. Ein weiteres Ausführungsbeispiel umfasst ein Liefern eines Datenpfads von einem Anfrager zu einer geteilten Ressource basierend auf den Informationen, die für einen jeweiligen Arbitrierer der Mehrzahl von Arbitrierern gespeichert sind. Ferner schreitet bei einem Ausführungsbeispiel in dem Pipeline-Modus eine Anfrage pro Taktzyklus eine Ebene vorwärts, während in dem Nicht-Pipeline-Betrieb eine Anfrage in der Lage ist zumindest zwei Ebenen der Pipeline pro Taktzyklus vorzuschreiten. Bei einem Ausführungsbeispiel kann die Anfrage in dem Nicht-Pipeline-Betrieb alle Ebenen der Pipeline innerhalb eines Taktzyklus vorschreiten. Bei einem Ausführungsbeispiel wird einem Anfrager durch die Mehrzahl von Arbitrierern Gewährung für einen Datentransfer zu einer geteilten Ressource innerhalb eines Taktzyklus nachdem der Anfrager eine Anfrage zum Gewähren zu der Mehrzahl von Arbitrierern ausgegeben hat, erteilt, wenn die Mehrzahl von Arbitrierern in einem Leerlaufzustand ist.
Die Erfindung schafft ferner einen Arbitrierungsknoten in einem hierarchischen Arbitrierungssystem, wobei der Arbitrierungsknoten einen ersten Knoten aufweist, der eine Mehrzahl von ersten Eingängen aufweist, um erste Signale von einem untergeordneten Arbitrierungsknoten zu empfangen. Der Knoten weist ferner einen ersten Ausgang auf, um ein Signal zu einem Arbitrierungsknoten einer höheren Ebene zu übertragen. Der Arbitrierungsknoten weist ferner einen zweiten Knoten auf, wobei der zweite Knoten eine Mehrzahl von zweiten Eingängen aufweist, um zweite Signale von zweiten Knoten von untergeordneten Arbitrierungsknoten zu empfangen. Der zweite Knoten weist ferner einen zweiten Ausgang auf, um ein Signal zu einem übergeordneten Arbitrierungsknoten zu übertragen. Der zweite Knoten kann hierbei eine kombinatorische Logik aufweisen, wobei die kombinatorische Logik implementiert sein kann, um eine Mehrzahl von Eingangssignalen, die an den zweiten Eingängen empfangen werden, zu kombinieren, und an dem Ausgang ein Ausgangssignal entsprechend einer Oder-Kombination der Eingangssignale zu liefern.
Bei einem Ausführungsbeispiel kann der Arbitrierer mit einem Register gekoppelt sein, das dem Arbitrierungsknoten zugeordnet ist, um Informationen zu speichern, die sich auf den durch den Arbitrierern gewährten Eingang beziehen.
Ferner schafft die Erfindung ein Arbitrierersystem, das einen ersten Arbitrierer, einen zweiten Arbitrierer und einen dritten Arbitrierer umfasst. Das Arbitrierersystem weist eine erste Verbindung, um ein erstes Signal von einem ersten Anfrager einer Mehrzahl von Anfragern zu dem zweiten Arbitrierer zu übertragen, und eine zweite Verbindung auf, um ein zweites Signal von einem zweiten Anfrager der Mehrzahl von Anfragern zu dem ersten Arbitrierer zu übertragen. Eine dritte Verbindung ist vorgesehen, um ein drittes Signal basierend auf dem ersten und zweiten Signal zu dem dritten Arbitrierer zu übertragen. Ferner ist eine vierte Verbindung vorgesehen, um ein viertes Signal von dem ersten Arbitrierer zu dem dritten Arbitrierer zu übertragen. Eine fünfte Verbindung ist in dem Arbitrierersystem vorgesehen, um ein fünftes Signal von dem zweiten Arbitrierer zu dem dritten Arbitrierer zu übertragen. Das Arbitrierersystem kann ein hierarchisches Arbitrierersystem sein, Arbitrierungsknoten, wobei die ersten und zweiten Arbitrierer einer hierarchischen Ebene zugeordnet sind, während der dritte Arbitrierer einer der ersten hierarchischen Ebene übergeordneten Ebene zugeordnet ist.
Die dritte Verbindung kann eine kombinatorische Logik aufweisen, wobei die kombinatorische Logik einen ersten und zweiten Eingang und einen Ausgang zum Ausgeben des dritten Signals aufweist, und wobei die vierte und fünfte Verbindung jeweils ein Register aufweisen, um das vierte und fünfte Signal zu speichern, wobei das Register mit einem Steuereingang eines Multiplexers gekoppelt ist.
Ferner kann ein Datenpfad vorgesehen sein, der den ersten Anfrager und den zweiten Anfrager mit einer geteilten Ressource koppelt, wobei der Datenpfad mit dem Multiplexer gekoppelt ist, um selektiv Daten basierend auf den in dem Register gespeicherten Signalen zu übertragen.
Die vorliegende Erfindung schafft ferner ein Arbitrierersystem mit einer Mehrzahl von Arbitrierern, wobei die Mehrzahl von Arbitrierern ausgebildet ist, um in einem Pipeline-Betrieb betrieben zu werden, und wobei zumindest ein Teil der Mehrzahl von Arbitrierern ausgebildet ist, um selektiv in einem Nicht-Pipeline-Betrieb betrieben zu werden.
Der zumindest eine Teil der Mehrzahl von Arbitrierern ist in einem Nicht-Pipeline-Betrieb betreibbar, wenn sich der zumindest eine Teil der Mehrzahl von Arbitrierern in einem Leerlaufzustand befindet.
Bei einem Ausführungsbeispiel kann die Mehrzahl von Arbitrierern konfiguriert sein, um, wenn sich die Mehrzahl von Arbitrierern ursprünglich in einem Leerlaufzustand befindt, eine Datenübertragung für einen Anfrager einen Taktzyklus nachdem der Anfrager bezüglich eines Zugriffs eine Anfrage gestellt hat, auszulösen. Die Mehrzahl von Arbitrierern kann ferner ein hierarchisches Arbitrierungssystem bilden.
Bei einem Ausführungsbeispiel kann jeder der Mehrzahl von Arbitrierern mit einem entsprechenden Register gekoppelt sein, um Informationen zu speichern, die Tore anzeigen, denen durch die Mehrzahl von Arbitrierern Gewährung erteilt wurde. Das entsprechende Register kann mit einem entsprechenden Multiplexer gekoppelt sein, um einen Datenpfad von einem Anfrager zu einer geteilten Ressource basierend auf Informationen zu liefern, die in jedem der entsprechenden Register gespeichert sind. Ferner kann die Mehrzahl von Arbitrierern konfiguriert sein, um in dem Pipeline-Betrieb ein erstes Signal von einem ersten Arbitrierer zu einem zweiten Arbitrierer auf einer nächst höheren Ebene basierend auf einer Arbitrierung bei dem ersten Arbitrierer zu liefern, wobei in dem Nicht-Pipeline-Betrieb ein zweites Signal zu dem zweiten Arbitrierer unabhängig von der Arbitrierung in dem ersten Arbitrierer geliefert wird. Das zweite Signal kann ferner bei dem Pipeline-Betrieb geliefert werden, wobei eine Arbitrierung basierend auf dem ersten Signal priorisiert wird über eine Arbitrierung basierend auf dem zweiten Signal.
Bevorzugte Ausführungsbeispiele werden nachfolgend unter Bezugnahme auf die beiliegenden Zeichnungen näher erläutert. Es zeigen:
1 ein Blockdiagramm gemäß einem Ausführungsbeispiel der vorliegenden Erfindung,
2 ein Blockdiagramm gemäß einem Ausführungsbeispiel der vorliegenden Erfindung,
3 ein Blockdiagramm gemäß einem Ausführungsbeispiel der vorliegenden Erfindung,
4a und 4b Blockdiagramme gemäß einem Ausführungsbeispiel der vorliegenden Erfindung,
5a bis 5f beispielhafter Blockdiagramme, um einen Betrieb gemäß einem Ausführungsbeispiel der vorliegenden Erfindung zu erläutern,
6a bis 6f beispielhafter Blockdiagramme, um einen Betrieb gemäß einem Ausführungsbeispiel der vorliegenden Erfindung zu erläutern,
7 ein Blockdiagramm gemäß einem Ausführungsbeispiel der vorliegenden Erfindung,
8a bis 8f beispielhafter Blockdiagramme, um einen Betrieb gemäß einem Ausführungsbeispiel der vorliegenden Erfindung zu erläutern,
9a bis 9f beispielhafter Blockdiagramme, um einen Betrieb gemäß einem Ausführungsbeispiel der vorliegenden Erfindung zu erläutern, und
10 ein Blockdiagramm gemäß einem Ausführungsbeispiel der vorliegenden Erfindung.
Im Folgenden werden exemplarische Ausführungsbeispiele der vorliegenden Erfindung erklärt. In den verschiedenen Figuren können identische oder gleichartige Einheiten, Module, Vorrichtungen etc. ein gleiches Bezugszeichen aufweisen.
Wie es nachfolgend ausführlicher erklärt wird, können Ausführungsbeispiele der vorliegenden Erfindung eine Arbitrierung bereitstellen, bei der eine Mehrzahl von Arbitrierern oder Sub-Arbitrierern verwendet wird. Die Mehrzahl von Sub-Arbitrierern kann in einer hierarchischen Architektur angeordnet sein und kann in einem Pipeline-Betrieb oder einem Nicht-Pipeline-Betrieb betrieben werden, wie es nachfolgend unter Bezugnahme auf die beigefügten Figuren näher beschrieben wird.
Unter Bezugnahme auf 1 umfasst ein grundlegendes Blockdiagramm eines Ausführungsbeispiels der vorliegenden Erfindung eine Mehrzahl von Anfragern 100, die mit einer Mehrzahl von Eingängen 102a eines Arbitrierungssystems 102 gekoppelt sind, um Anfragen zu dem Arbitrierungssystem 102 zu übertragen. Ein Ausgang 102b des Arbitrierungssystems 102 ist mit einer geteilten Ressource 104 gekoppelt, um einen Datentransfer von dem Anfrager, dem der Zugriff auf die geteilte Ressource gewährt wurde, zu ermöglichen.
Wie es nachfolgend genauer erklärt wird, kann das Arbitrierungssystem 102 gemäß Ausführungsbeispielen eine Mehrzahl von Arbitrierern oder Sub-Arbitrierern umfassen, die sowohl in einem Pipeline-Betrieb als auch in einem Nicht-Pipeline-Betrieb betrieben werden können. Die Mehrzahl von Arbitrierern kann in einer hierarchischen Architektur implementiert sein.
Die Mehrzahl von Anfragern 100 kann jede Vorrichtung, Einheit, Schaltung etc. umfassen, die die Ressource 104 mit einer oder mehreren Vorrichtungen, Einheiten, Schaltungen etc. teilt. Die Mehrzahl von Anfragern 100 kann beispielsweise, Speicher-Steuerungseinheiten, Prozessoren und Prozessressourcen einschließlich dedizierter Prozessoren, Bus-Steuerungseinheiten, Netzwerksteuerungseinheiten einschließlich drahtgebundene-Netzwerk-Steuerungseinheiten, drahtlos-Netzwerk-Steuerungseinheiten, Ethernet-Netzwerk-Steuerungseinheiten etc., geteilte Busse, geteilte Speicherressourcen einschließlich Cache-Speicher, DRAM-Speicher, Anwendungsbeschleunigungseinheiten, Datenerfassungsvorrichtungen etc. umfassen.
Die Mehrzahl von Anfragern kann lediglich einen Typ von Anfragern umfassen, beispielsweise lediglich eine Mehrzahl von Prozessoren eines gleichen Typs, oder kann unterschiedliche Typen von Anfragern umfassen, beispielsweise Prozessoren und dedizierte Prozessoren.
Die geteilte Ressource 104 kann jede Vorrichtungseinheit, Schaltung etc. sein, die mit mehr als einer Vorrichtung, Einheit oder Schaltung etc. geteilt werden kann. Die geteilte Ressource kann beispielsweise ein Speicher, ein Bus, ein Datenport, ein Datenkanal etc. sein. Gemäß Ausführungsbeispielen kann die Mehrzahl von Anfragern und die geteilte Ressource ein Master-Slave-System bilden, bei dem die Mehrzahl von Anfragern Master eines gleichen oder unterschiedlichen Typs und die geteilte Ressource ein Slave ist.
Unter Bezugnahme auf 2 wird nachfolgend ein Ausführungsbeispiel eines Arbitrierungssystems genauer erläutert.
2 zeigt eine exemplarische Implementierung des Arbitrierungssystems 102 in einer hierarchischen Arbitrierungsarchitektur gemäß einem Ausführungsbeispiel der vorliegenden Erfindung. Die hierarchische Arbitrierungsarchitektur umfasst eine Mehrzahl von Arbitrierungsknoten 200. Die Mehrzahl von Arbitrierungsknoten 200 ist in unterschiedlichen hierarchischen Ebenen angeordnet, derart, dass jeder der Arbitrierungsknoten 200 einer Ebene der hierarchischen Arbitrierungsarchitektur zugeordnet ist. Ein Arbitrierungsknoten, der einer Ebene zugeordnet ist, ist hierarchisch abwärts mit den Ausgängen eines oder mehreren Arbitrierungsknoten einer untergeordneten Ebene und hierarchisch aufwärts mit einem Arbitrierungsknoten einer übergeordneten Ebene verbunden. Die Arbitrierungsknoten der untersten Ebene sind mit den Anfragern verbunden.
Wie es in 2 zu sehen ist, bilden die Arbitrierungsknoten eine baum-artige Struktur, bei der jeder Knoten mit einem Knoten einer höheren Ebene gekoppelt ist mit Ausnahme der Arbitrierungsknoten der höchsten Ebene, das heißt die Arbitrierungsknoten am oberen Ende der hierarchischen Architektur sind mit dem Ausgang 102b des Arbitrierungssystems 102 gekoppelt. Ferner sind die Ar bitrierungsknoten 200 auf der untersten Ebene (Ebene 1) mit den Eingängen 102a des Arbitrierungssystems 102 gekoppelt. Jeder Arbitrierungsknoten 200 auf der untersten Ebene kann mit einem oder mehreren der Anfrager 100 gekoppelt werden, um Anfragesignal von jedem der Anfrager 100 zu empfangen.
Während 2 eine exemplarische Implementierung mit drei Ebenen zeigt, bei der die erste Ebene fünf Arbitrierungsknoten und die zweite Ebene zwei Arbitrierungsknoten aufweist, ist an dieser Stelle zu bemerken, dass die Anzahl von Ebenen und die Anzahl von Arbitrierungsknoten innerhalb einer Ebene in anderen Ausführungsbeispielen unterschiedlich sein kann. Ferner kann die Anzahl von Arbitrierungsknoten, die einem Arbitrierungsknoten einer übergeordneten Ebene zugeordnet oder mit derselben gekoppelt ist, in anderen Ausführungsbeispielen unterschiedlich sein. Ferner kann die Anzahl von Arbitrierungsknoten, die einem Arbitrierungsknoten auf einer höheren Ebene zugeordnet sind, für eine bestimmte Ebene gleich sein oder für Arbitrierungsknoten einer bestimmten Ebene unterschiedlich sein. Unter Bezugnahme auf 2 ist beispielsweise einer der Arbitrierungsknoten auf der Ebene 2 drei Arbitrierungsknoten der Ebene 1 zugeordnet, während dem anderen Arbitrierungsknoten lediglich zwei Arbitrierungsknoten der Ebene 1 zugeordnet sind.
Gemäß Ausführungsbeispielen, die nachfolgend detaillierter erklärt werden, kann das hierarchische Arbitrierungssystem 102 eine hierarchische Arbitrierungsanfragearchitektur und eine hierarchische Datenpfadarchitektur umfassen. Um die hierarchische Anfragearchitektur und die hierarchische Datenpfadarchitektur zu implementieren, weist jeder der Arbitrierungsknoten 200 gemäß einem Ausführungsbeispiel einen Arbitrierungsanfrageknoten auf, der durch einen Arbitrierer (oder Arbitriererschaltung) 300 implementiert ist, und weist einen Datenpfadanfrageknoten auf, der gemäß einem Ausführungsbeispiel durch einen Multiplexer 302, der in 3 gezeigt ist, implementiert ist. Der Arbitrierer 300 umfasst eine Mehrzahl von Eingängen 300a gemäß der Anzahl von Arbitrierungsknoten auf der nächst untergeordneten Ebene, die den jeweiligen Arbitrierungsknoten zugeordnet sind, so dass jeder Eingang 300a mit einem entsprechenden Ausgang des Arbitrierers 300 auf der nächst untergeordneten Ebene verbunden ist. Ferner ist ein Ausgang 300b des Arbitrierers 300 mit einem Eingang eines Arbitrierers 300 verbunden, der einem Arbitrierungsknoten einer übergeordneten Ebene entspricht.
Der Multiplexer 302 umfasst eine Mehrzahl von Datenpfadeingängen 302a, die mit Ausgängen von Multiplexern auf untergeordneten Ebenen gekoppelt sind, und einen Ausgang 302b, der mit einem Eingang eines Multiplexers auf einer übergeordneten Ebene gekoppelt ist.
Der Arbitrierer 300 ist mit einem Register 304 gekoppelt, um Informationen zu speichern, die identifizieren, welchem der Eingangsports oder Eingangstore, die in einem Arbitrierungsprozess des Arbitrierers 300 miteinander konkurrieren, Gewährung erteilt wurde. Das Register 304 ist ferner mit einem Steuereingang des Multiplexers 302 gekoppelt, um den Datenpfad entsprechend zu den Informationen, die in dem Register gespeichert sind, zu schalten. Gemäß Ausführungsbeispielen werden die Multiplexer gemäß den Informationen, die in dem Register 304 gespeichert sind, geschaltet.
Durch das Implementieren der oben beschriebenen Arbitrierungsknoten 200 in einer hierarchischen Arbitrierungsarchitektur wie es in 2 gezeigt ist, wird eine hierarchische Arbitrierungsanfragearchitektur zum Durchführen von Gewährungsentscheidungen in Arbitrierungsprozessen und eine hierarchische Datenpfadarchitektur zum Übertragen der Daten von den Anfragern, die Gewährung erhielten, zu der geteilten Ressource erhalten.
4a und 4b zeigen exemplarische Ausführungsbeispiele einer hierarchischen Arbitrierungsanfragearchitektur und einer hierarchischen Datenpfadarchitektur. 4a und 4b ent sprechen einem System mit drei Arbitrierungsknoten auf einer Ebene 1 und zwei Arbitrierungsknoten auf einer Ebene 2. Jeder der Arbitrierungsknoten auf der Ebene 1 weist vier Eingänge entsprechend zu der Anzahl von Anfragern M1...M12 auf, die einem jeweiligen Arbitrierungsknoten zugeordnet sind.
Die Mehrzahl von Arbitrierern, die Mehrzahl von Anfragern und die Mehrzahl von Multiplexern des Arbitrierungssystems können gemäß Ausführungsbeispielen auf einen einzigen Chip bereitgestellt sein. Ferner kann gemäß Ausführungsbeispielen das Arbitrierungssystem synchron getaktet sein.
Das Arbitrierungssystem 300 kann vollständig in Hardware (Hardwareschaltungen auf einem Chip) oder teilweise in Hardware und Software/Firmware bereitgestellt sein. Ferner kann jede bekannte Arbitrierungstechnik durch den Arbitrierer 300 implementiert sein, um eine Arbitrierung zwischen den Eingängen zu liefern. Beispielsweise können faire Arbitrierungstechniken, wie beispielsweise eine round-robin-Arbitrierung (RR-Arbitrierung), eine weighted-round-robin-Arbitrierung (WRR-Arbitrierung) oder eine deficit-round-robin-Arbitrierung (DRR-Arbitrierung) durch den Arbitrierer 300 implementiert sein. Gemäß Ausführungsbeispielen kann der Arbitrierer 300 ein Gedächtnis aufweisen, um ältere aktive Anfragen, die noch nicht durch den Arbitrierer 300 gewährt sind, in Betracht zu ziehen.
Ein erster exemplarischer Betrieb des Arbitrierungssystems der 4a und 4b, der einem Pipeline-Betrieb entspricht, wird nachfolgend unter Bezugnahme auf die 5a bis 5f und die 6a bis 6f näher erläutert.
Der Pipeline-Betriebsmodus entspricht einem Betrieb, bei dem der Prozess, um einem bestimmten Anfrager eine Gewährung zu liefern, in eine Mehrzahl von Unter-Prozessen geteilt ist, die jeweils bei einem der Arbitrierer in dem Arbitrierungssystem durchgeführt werden.
Jeder Unter-Prozess empfängt als Eingangssignal das Ergebnis einer vorhergehenden Ebene und führt den zugeordneten Unter-Prozess durch. Mit anderen Worten gesagt, wird der Prozess in der Pipeline von einer Ebene zu einer anderen Ebene weitergereicht, so dass durch den letzten Unter-Prozess der gesamte Prozess, das heißt die Gesamtarbitrierung für die Anfrage, die die höchste Ebene erreicht, beendet wird.
Der Pipeline-Betrieb wird in einem hierarchischen Arbitrierungssystem durchgeführt, indem bei einem gegebenen Zyklus auf jeder Ebene des hierarchischen Arbitrierungssystems eine Arbitrierung zwischen den Eingängen der Arbitrierer durchgeführt wird.
Basierend auf einer Gewährung, die durch einen Arbitrierer einem der Eingangssignale gegeben wird, wird ein Signal, das heißt eine Pipeline-Anfrage, als Eingangssignal zu einem Arbitrierer der nächst höheren Ebene übertragen, auf der es mit anderen Eingangssignalen von anderen Arbitrierern konkurriert. In einem nächsten Zyklus arbitriert der Arbitrierer auf der nächst höheren Stufe daraufhin auf der Basis der Anfragen, die für diesen Arbitrierer aktiv sind, das heißt auf der Basis der Anfragen, die empfangen wurden und/oder durch den Arbitrierer gespeichert sind. Der Zweig, der durch den Arbitrierer gewährt wird, wird in dem entsprechenden Register gespeichert. Da sich die Rechenzeit für einen Arbitrierer mit der Anzahl von Eingängen signifikant erhöht, werden die Anforderungen für eine Rechenzeit eines jeden Arbitrierer zum Beenden der Arbitrierung innerhalb eines Taktzyklus in dem hierarchischen Arbitrierungssystem mit Pipeline-Betrieb reduziert, verglichen mit dem Bereitstellen eines einzigen Arbitrierers für alle Anfrager. Dies ermöglicht beispielsweise einen Betrieb, bei dem viele Anfrager und kurze Taktperioden vorliegen. Der Pipeline-Betrieb wird nachfolgend unter Bezugnahme auf die 5a bis 5f und 6a bis 6f, die einen exemplarischen Pipeline-Betrieb zeigen, näher erklärt.
5a zeigt die Arbitrierungsanfragearchitektur bei einem Zyklus 0, bei dem alle der Mehrzahl von Arbitrierern im Leerlauf sind, beispielsweise nach einem in Betrieb nehmen. Es ist zu bemerken, dass in den folgenden Figuren die Eingänge der Arbitrierer A11, A12 und A13 auf der ersten Ebene entsprechend der Anzahl von Anfragern, die mit dem Eingang gekoppelt sind, gekennzeichnet sind, das heißt der Arbitrierer A11 hat die Eingänge 1 bis 4, der Arbitrierer A12 hat die Eingänge 5 bis 8 und der Arbitrierer A13 hat die Eingänge 9 bis 12. Für die Arbitrierer A21, A22 und A31, die alle in den beschriebenen Ausführungsbeispielen zwei Eingänge aufweisen, wird der erste Eingang mit 1 gekennzeichnet und der zweite mit 2 gekennzeichnet, wie es in 5a zusehen ist.
Bei einem Zyklus 1 geben der Anfrager M2 und der Anfrager M7 beide ein Anfragesignal an die entsprechenden Eingänge der Arbitrierer A11 und A12 der Ebene 1 des Arbitrierungssystems aus. Während des Zyklus 1 führt der Arbitrierer A11 einen Arbitrierungsprozess durch und erteilt der Anfrage des zweiten Eingangs, der M2 entspricht, eine Gewährung, da keine weitere Anfrage für den Arbitrierer A11 in dem Zyklus 1 aktiv ist. In entsprechender Weise führt während des Zyklus 1 der Arbitrierer A12 einen Arbitrierungsprozess durch und erteilt der Anfrage an dem zweiten Eingang, der M7 entspricht, eine Gewährung, da für den Arbitrierer A12 in dem Zyklus 1 keine weitere Anfrage aktiv ist. Nach der Arbitrierung, beispielsweise an dem Ende des Zyklus 1, wird das Ergebnis, das anzeigt, welchem Eingang eine Gewährung erteilt wurde, das heißt 2 für den Arbitrierer A11 und 7 für den Arbitrierer A12 in die Register geschrieben, die den Arbitrierern A11 und A12 entsprechen, wie es in 5b durch Pfeile angezeigt ist. Es ist hierbei zu bemerken, dass die Informationen, die in den 5a bis 5f für einen jeweiligen Zyklus gezeigt sind, die Informationen sind, die an dem Ende des Zyklus aktuell gültig sind. Diese Informationen werden dann an den entsprechenden Multiplexer beim Beginn des nächsten Zyklus vorliegen, um einen Datentransfer entsprechend zu den Informationen in dem nächsten Zyklus zu ermöglichen.
Zusätzlich gibt jeder der Arbitrierer A11 und A12 ein Anfragesignal zu einem Arbitrierer A21 der nächst höheren Stufe aus, welches in dem nächsten Zyklus arbitriert wird. Die gewährte Anfrage fällt dabei in dem hierarchischen System eine Stufe weiter.
Unter Bezugnahme auf 5c weist bei dem Zyklus 2 der Arbitrierer A21 zwei aktive Anfragen entsprechend den Eingängen auf, die mit den Arbitrierern A11 und A12 gekoppelt sind. Die Übertragung der Anfragen von den Arbitrierern wird in den Figuren jeweils durch Pfeile angezeigt. Wie es in 5a und 5b zu erkennen ist, ist aufgrund des Pipeline-Betriebs ein Inter-Zyklus-Pfeil gezeigt, der die Übertragung von dem Arbitrierer A11 zu dem Arbitrierer A21 anzeigt.
In dem Arbitrierungsprozess des Zyklus 2 erteilt der Arbitrierer A21 der Anfrage eine Gewährung, die von dem Arbitrierer A11 kommt und die Information, die den gewährten Eingangssignal entspricht, das heißt 1, wird in dem Register A21 gespeichert, nachdem die Arbitrierung beendet ist, beispielsweise am Ende des Zyklus. Ein Anfragesignal wird daraufhin durch den Arbitrierer A21 zu dem Arbitrierer A31 auf der nächst höheren Ebene ausgegeben. Ferner werden in dem Zyklus 2 neue Anfragen durch die Anfrager M1, M6 und M9 zu den Arbitrierern A11, A12, A13 jeweils ausgegeben und in dem Arbitrierungsprozess der jeweiligen Arbitrierer gewährt. Am Ende des Zyklus 2 werden Informationen bezüglich der gewährten Anfragen zu den entsprechenden Registern übertragen.
In dem nächsten Zyklus 3, der in 5 gezeigt ist, wurde die Anfrage, die von dem Arbitrierer A21 ausgegeben ist, zu dem Arbitrierer A31 auf der obersten Ebene übertragen und ist daher eine aktive Anfrage an dem Eingang des Arbitrierers A31, der mit dem Arbitrierer A21 gekoppelt ist. Der Arbitrierer A31 gewährt diese Anfrage, da keine weiteren Anfragen für diesen Zyklus aktiv sind. Ferner werden neue Anfragen von den Anfragern M4 und M8 bei den Arbitrierer A11 und A12 empfangen und in einem jeweiligen Arbitrierungsprozess gewährt.
Bei dem Arbitrierer A21 weisen beide Eingänge, die A11 und A12 entsprechen, aktive Anfragen auf. Es ist hierbei zu bemerken, dass die aktive Anfrage an dem Eingang, der A12 entspricht, eine alte Anfrage ist, die bereits bei dem Zyklus 2 aktiv war, wobei die Anfrage in dem Arbitrierungsprozess des Zyklus 2 bei dem Arbitrierer A21 nicht gewährt wurde, während die Anfrage an dem Eingang, der A11 entspricht, eine neue Anfrage ist, die von A11 übertragen wurde. Der Arbitrierer A21 führt eine Arbitrierung zwischen den Anfragen durch und erteilt die Gewährung dem Eingang der A12 entspricht, wodurch die aktive Anfrage, die von A12 initiiert ist, entfernt wird. Ferner führt der Arbitrierer A22 in Zyklus 3 eine Arbitrierung durch und gewährt die einzige aktive Anfrage von A13. Wie es oben bereits beschrieben wurde gibt jeder der Arbitrierer nach dem Gewähren ein Anfragesignal zu der nächst höheren Ebene, sofern nicht eine ältere Anfrage die Ausgabe der Anfrage zu der nächsten Ebene blockiert, wie es nachfolgend beschrieben wird.
Ferner werden in Zyklus 3 neue Anfragen durch die Anfrager M1 und M6 zu den Arbitrierern A11 und A12 ausgegeben. Es ist hierbei zu bemerken, dass der Arbitrierer A11 in Zyklus 3 eine Arbitrierung durchführt, während der Arbitrierer A12 in diesem Zyklus für die Arbitrierung geblockt ist, was durch eine graue Farbe des Arbitrierers 12 angezeigt ist. Der Arbitrierer A12 ist geblockt, da lediglich eine Anfrage zu einem gegebenen Zeitpunkt an einem Eingang aktiv sein kann. Die Anfrage, die durch den Arbitrierer A12 in dem vorhergehenden Zyklus 2 gewährt wurde kann daher nicht zu dem Arbitrierer A21 übertragen werden, da der Arbitrierer A12 die aktive Anfrage an dem Eingang, der dem Arbitrierer A12 entspricht, in dem vorhergehenden Zyklus nicht gewährt hat und diese alte Anfrage daher an dem Arbitrierer A12 noch aktiv ist. Anstelle eines Ausgebens der Anfrage zu der nächsten Ebene wird die Anfrage an dem Ausgang des Arbitrierers A12 in Zyklus 3 aufrechterhalten, wie es in 5d angezeigt ist. Weiterhin Bezug nehmend auf 5d werden die Informationen, die in dem Register von A12 gespeichert sind, nicht verändert, da keine Arbitrierung in dem Arbitrierer A12 durchgeführt wurde. In den Registern, die den Arbitrierern A11, A21 und A31 entsprechen, werden die in den jeweiligen Registern gespeicherten Informationen am Ende des Zyklus aktualisiert gemäß den Eingangssignalen, die von den jeweiligen Arbitrierern gewährt wurden.
Bezug nehmend nun auf Zyklus 4, der in 5e gezeigt ist, werden neue Anfragen von den Anfragern M2, M7 und M10 an den Arbitrierern A11, A12 und A13 empfangen. Ferner ist die Anfrage an dem Arbitrierer A12, die von M8 in dem Zyklus 3 ausgegeben wurde, noch aktiv, da keine Arbitrierung durch den Arbitrierer A12 in dem Zyklus 3 durchgeführt wurde. Der Arbitrierer A12 führt die Arbitrierung daher zwischen den Anfragen von M7 und M8 durch und erteilt der Anfrage M8 eine Gewährung, wie es in 5e dargestellt ist.
Ferner wurde die Anfrage von dem Arbitrierer A12, die in dem Zyklus 3 an dem Ausgang des Arbitrierers A12 aufrechterhalten wurde, nun zu dem entsprechenden Eingang des Arbitrierers A21 übertragen, während die die in dem Zyklus 3 nicht gewährte alte Anfrage an dem Eingang, der A11 entspricht, noch aktiv ist.
Infolge des Obigen konnte der Arbitrierer A11 die Anfrage nicht von A11 zu A21 übertragen und daher wird die Anfrage an dem Ausgang des Arbitrierers A11 aufrechterhalten, wie es in 5e dargestellt ist, wobei der Arbitrierer A11 in diesem Zyklus geblockt ist.
Der Arbitrierer A13, der lediglich eine aktive Anfrage von M10 aufweist gewährt diese Anfrage. Der Arbitrierer A31, der in dem Zyklus 4 an allen Eingängen Anfragen aufweist, gewährt die Anfrage an dem Eingang, der zu A21 gehört.
In Zyklus 5, der in 5f gezeigt ist, werden neue Anfragen von den Anfragern M1, M6 und M9 empfangen. Der Arbitrierer A12, der nunmehr aktive Anfragen von allen Ports aufweist, arbitriert und gibt die Gewährung dem Eingang, der mit A11 gekoppelt ist. Der Arbitrierer A21, der eine aktive Anfrage von dem Arbitrierer A13 aufweist, erteilt dem Eingang Gewährung, der zu dem Arbitrierer A11 gehört, und der Arbitrierer A31, der zwei aktive Anfragen von A21 und A22 aufweist, gibt dem Eingang die Gewährung, der mit A22 gekoppelt ist.
Es ist zu bemerken, dass in dem Pipeline-Betrieb für ein Arbitrierungssystem mit n hierarchischen Ebenen zumindest n-Zyklen erforderlich sind, damit eine Anfrage die Pipeline durchschreiten kann, da jeder der Arbitrierer auf einer Ebene auf das Eingangssignal des Arbitrierers der untergeordneten Ebenen zu warten hat. Daher beginnt in dem obigen Beispiel der erste Datentransfer von einem Anfrager, das heißt dem Anfrager M2, zu der geteilten Ressource bei einem Zyklus n + 1, das heißt in dem obigen Beispiel bei dem Zyklus 4. Es ist ferner zu bemerken, dass der in den 5a bis 5f gezeigte Betrieb lediglich einen exemplarischen Pipeline-Betrieb zeigt, wobei es andere Möglichkeiten gibt, den Pipeline-Betrieb der Arbitrierer zu implementieren.
Der Datentransfer in dem hierarchischen Datenpfadsystem, das in 4b gezeigt ist, von den Anfragern, denen durch das System Gewährung erteilt wurde, zu der geteilten Ressource wird nun unter Bezugnahme auf die 6a bis 6f beschrieben.
6a zeigt ein Datenpfadsystem bei dem Zyklus 1. Es ist zu bemerken, dass 6a bei dem Zyklus 1 startet, während 5a das Arbitrierungsanfragesystem bei einem Zyklus 0 zeigt, wobei hier in Betracht gezogen wird, dass Daten lediglich nach einer Gewährung durch das gesamte System lediglich einen Zyklus später verarbeitet werden können. Bei dem Zyklus 1 sind alle Multiplexer in einem Leerlauf oder einem unbestimmten Zustand, da bei dem Beginn des Zyklus 1 keine Informationen in den Registern gespeichert sind, die es ermöglichen würden, dass die Multiplexer ein entsprechendes Schalten durchführen können. Bezug nehmend auf Zyklus 2, der in 6b gezeigt ist, enthält das Register, das A11 zugeordnet ist, an dem Beginn des Zyklus 2 die Informationen, die den Eingang 2 als den Eingang identifizieren, der eine Gewährung erhalten hat, wie es durch Vergleich mit den Informationen, die in den in 5b gezeigten Registern gespeichert sind, zu erkennen ist. Der Multiplexer D11 versetzt daher seinen zweiten Eingang in einen aktiven Zustand. Ferner weist das Register, das zu A12 gehört, an dem Beginn des Zyklus 2 die Informationen auf, die den Eingang 7 als den gewährten Eingang identifizieren, wobei der Multiplexer D12 den Eingang, der mit M7 korrespondiert, in einen aktiven Zustand versetzt. Das Setzen der Multiplexer D11 ermöglicht, dass Daten von M2 eine Ebene weiter in dem System übertragen werden, das heißt zu dem Eingang des Multiplexers D21, wie es in 6b gezeigt ist. Zusätzlich ermöglicht das Setzen des Multiplexers D12, dass Daten von M7 zu dem entsprechenden Eingang des Multiplexers D21 übertragen werden.
In dem Zyklus 3, der in 6c gezeigt ist, wird der Eingang, der M1 entspricht, in dem Multiplexer D11 in einen aktiven Zustand versetzt, der Eingang, der M6 entspricht, wird in dem Multiplexer D12 in einen aktiven Zustand versetzt, und der Eingang, der mit D11 gekoppelt ist, wird in dem Multiplexer D21 in einen aktiven Zustand versetzt, wobei dies in Übereinstimmung mit den Informationen erfolgt, die in den Registern gespeichert sind, vergleiche 5c. Zusätzlich wird in dem Multiplexer D13 der Eingang, der M9 entspricht, in einen aktiven Zustand versetzt. Die Daten von M2 werden in Übereinstimmung mit der Einstellung des Multiplexers D21 eine Ebene weiter in dem hierarchischen Datensystem übertragen, das heißt von dem Eingang des Multiplexers D21 zu dem Eingang Multiplexers D31, wie es in 6c dargestellt ist. Die Daten von M1 werden zu dem Eingang des Multiplexers D21 übertragen gemäß der Einstellung des Multiplexers D11. Es sei gemerkt, dass von D12 zu D21 keine Daten übertragen werden, da die alten Daten M7 an dem Eingang des Multiplexers D21 noch aktiv sind.
Indem Zyklus 4, der in 6d gezeigt ist, werden die Multiplexer in Übereinstimmung mit den Informationen, die in den jeweiligen Registern gespeichert sind, eingestellt (siehe 5c). Es ist in 6d zu erkennen, dass mit der Einstellung des Multiplexers auf der höchsten Ebene ein Datenpfad entsprechend zu einem Zweig durch das hierarchische Datenpfadsystem, das heißt ein Datenpfad von dem Anfrager M2 zu der geteilten Ressource, vollendet ist. Daten von dem Anfrager M2 werden daher in diesem Zyklus zu der geteilten Ressource übertragen.
Daten von M7 werden ferner von dem Multiplexer D21 zu dem Multiplexer D31 in Übereinstimmung mit der Einstellung des Multiplexers D21 übertragen, während Daten von M6 zu dem Eingang des Multiplexers D21 und Daten von M9 zu dem Eingang des Multiplexers D22 übertragen werden.
In dem Zyklus 5, der in 6e gezeigt ist, werden schließlich Daten von M7 zu der geteilten Ressource übertragen, während die Daten von M1, M4, M9 und M10 jeweils eine Ebene weiter in dem Datenpfad vorschreiten.
In dem Zyklus 6, der in 6f gezeigt ist, werden Daten von M9 zu der geteilten Ressource übertragen, während Daten von M10 und M9 eine Ebene weiter in der Pipeline übertragen werden, das heißt von dem Multiplexer D22 zu dem Eingang des Multiplexers D31 und von dem Multiplexer D13 zu dem Eingang des Multiplexers M22.
Wie es bereits oben beschrieben wurde, erfordert es in dem Pipeline-Betrieb zumindest n-Zyklen, damit eine Anfrage die Pipeline durchschreitet. In Ausführungsbeispielen der vorliegenden Erfindung, die nachfolgend beschrieben werden, können das Arbitrierungssystem nicht nur dazu fähig sein, einen Pipeline-Betrieb zu liefern, sondern sind auch fähig eine schnelle Arbitrierung zu liefern, wenn diese benötigt wird.
In Ausführungsbeispielen, die nachfolgend beschrieben werden, kann das Arbitrierungssystem eine selektive Nicht-Pipeline-Arbitrierung einer Anfrage in zumindest einem Teil der Arbitrierer liefern, wenn diese benötigt wird. Die Nicht-Pipeline-Arbitrierung kann eine parallele Arbitrierung sein und kann gewählt werden, wenn Arbitrierer in einem Leerlauf sind, wie es nachfolgend beschrieben wird. In einer parallelen Arbitrierung, ist eine bestimmte Anfrage eines Anfragers oder eine bestimmte Anfrage eines Arbitrierers einer niedrigeren Ebene gleichzeitig an mehr als einer Ebene anliegend, das heißt mehr als ein Arbitrierer des Pfads, der der Anfrage entspricht (des Pfads, den die Anfrage zu nehmen hat) entscheiden innerhalb eines Taktzyklus (parallel), ob diese Anfrage gewährt wird oder ob eine andere Anfrage gewährt wird. Es ist zu bemerken, dass in dem Pipeline-Betrieb die Gewährung für eine Anfrage zu einem bestimmten Zeitpunkt oder Zyklus immer lediglich auf einer Ebene des Systems erfolgt, und, wenn der Anfrage eine Gewährung erteilt wird, die Anfrage eine Ebene weiter fortschreitet, wo eine Entscheidung in dem nächsten Zyklus durchgeführt wird. Gemäß Ausführungsbeispielen wird das Arbitrierungssystem in einen parallelen Modus betrieben, wenn ein oder mehrere Arbitrierer in dem Zyklus zuvor in einem Leerlaufzustand waren, das heißt keine Arbitrierung von Anfragen in dem Pipeline-Betrieb durchgeführt hatten.
Um selektiv das Arbitrierungssystem in einem Parallel-Betriebs-Modus zu betreiben sind die Arbitrierungsknoten 200, die in 3 gezeigt sind, modifiziert, um eine Schaltungsanordnung aufzuweisen, die es ermöglicht, ein paralleles oder fast-paralleles Zuführen der Anfragen auf die unterschiedlichen Ebenen zu ermöglichen. Parallel soll hierbei breit ausgelegt werden, so dass das Zuführen der Anfragen zu den unterschiedlichen Ebenen nicht exakt zu der gleichen Zeit erfolgen braucht sondern innerhalb eines Zeitintervalls, das kurz ist verglichen mit der Zykluszeitdauer oder zumindest geringer als die Zykluszeitdauer ist. Gemäß Ausführungsbeispielen kann die Schaltungsanordnung durch kombinatorische Schaltungsanordnungen, wie beispielsweise Oder-Logik-Komponenten, Und-Logik-Komponenten usw. gebildet werden, was ermöglicht, dass die Anfragesignale in kurzer Zeit vorwärts geleitet werden können.
7 zeigt eine exemplarische Implementierung zum Bereitstellen einer parallelen Zuführung von Anfragen zu den verschiedenen Ebenen. Im Unterschied zu 3 weist der Arbitrierungsknoten 200 in 7 eine Oder-Logik-Komponente 306 auf. Die Oder-Logik-Komponente 306 weist eine Mehrzahl von Eingängen auf, wobei jeder Eingang einem der Arbitrierungsknoten der nächst unteren Ebene zugeordnet ist, die dem Arbitrierungsknoten 200 zugewiesen sind. Wie es aus 7 ersichtlich ist, weist der Arbitrierungsknoten 200 zusätzlich zu den Eingängen 300a, die mit den Ausgängen der Arbitrierer der untergeordneten Ebenen verbunden sind, zweite Eingänge 300c auf. Die Eingänge 300c sind mit Knoten verbunden, die mit den Eingängen der Oder-Logik-Komponente 306 und mit zweiten Eingängen des Arbitrierers verbunden sind. Signale, die an die zweiten Eingänge 300c angelegt werden, werden parallel zu den zweiten Eingängen des Arbitrierers 300 und zu den Eingängen der Oder-Logik-Komponente 306 geliefert.
Durch den Arbitrierungsknoten, der in 7 gezeigt ist, werden daher zwei Signale in dem hierarchischen Arbitrierungsanfragesystem übertragen. Das erste Signal, das von einer Ebene zu der direkt nächst höheren Ebene übertragen wird, basiert auf einem Arbitrierungsprozess auf der untergeordneten Ebene, wie es bereits unter Bezugnahme auf die 3, 4, 5a bis 5f und 6a bis 6f beschrieben wurde. Das erste Signal entspricht daher einem Pipeline-Betrieb und wird im Folgenden als Pipelinesignal oder Pipelineanfrage bezeichnet. Das zweite Signal ist ein Signal, das ebenso dem Arbitrierer 300 zugeführt wird, wobei dasselbe jedoch durch die kombinatorische Schaltungsanordnung parallel, das heißt innerhalb einer kurzen Zeitspanne, zu zumindest einer weiteren Ebene übertragen wird. Das zweite Signal kann daher als ein Vorausschausignal oder eine Vorausschauanfrage angesehen werden und wird im Folgenden derart bezeichnet. Das zweite Signal, welches eine Oder-Funktion aller Eingänge darstellt, wird daher geliefert, wenn ein oder mehrere Signale an dem Eingang empfangen werden, kann als ein Signal angesehen werden, das auf eine schnelle Weise einer höheren Ebene anzeigt, dass es auf diesem Zweig eine Aktivität geben wird, wodurch es der höheren Ebene ermöglicht wird, bereits mit einer Arbitrierung vor dem Erhalten der Pipelineanfrage zu beginnen.
Der Arbitrierungsknoten 200 gemäß 7 weist daher zwei Knoten in dem Arbitrierungsanfrageabschnitt auf. Ein erster Knoten wird durch die Mehrzahl von ersten Eingängen 300a des Arbitrierers 300 implementiert, um die ersten Signale von untergeordneten Arbitrierungsknoten zu empfangen, wobei der erste Knoten ferner durch den Ausgang 300b des Arbitrierers 300 implementiert ist, um ein Signal zu einem Arbitrierungsknoten auf einer höheren Ebene zu übertragen. Ein zweiter Knoten ist durch die Mehrzahl von Eingängen 300c implementiert, die die zweiten Signale von zweiten Knoten von untergeordneten Arbitrierungsknoten empfangen, wobei der zweite Knoten ferner durch den Ausgang 300d implementiert ist, der bereitgestellt ist, um die Vorausschauanfrage zu einem übergeordneten Arbitrierungsknoten zu übertragen.
Da der Arbitrierer 300 gemäß 7 für jeden untergeordneten Arbitrierungsknoten, der dem Arbitrierungsknoten zugeordnet ist, zwei Signale empfängt, das heißt die Pipelineanfrage und die Vorausschauanfrage, führt der Arbitrierer im Betrieb eine Entscheidung durch, welche der Anfragen gültige Anfragen sind, beziehungsweise welche der Anfragen für eine Arbitrierung in Betracht gezogen werden.
Gemäß einem Ausführungsbeispiel werden die Pipelineanfragen absolut gegenüber den Vorausschauanfragen priorisiert. Mit anderen Worten gesagt, wenn eine Pipelineanfrage von einem der Eingänge 300a empfangen wird, oder wenn eine Pipelineanfrage aktiv ist aufgrund einer nicht gewährten älteren Pipelineanfrage, werden alle Vorausschauanfragen verworfen beziehungsweise in der Arbitrierung an diesem Arbitrierungsknoten nicht in Betracht gezogen. Da jedoch die Vorausschausignale zu mehreren weiteren Ebenen entlang des Zweigs des hierarchischen Systems übertragen werden, kann das Vorausschausignal auf anderen Ebenen in Betracht gezogen werden, bei denen keine Pipelineanfrage aktiv ist.
Folglich ist Arbitrierung der Pipelineanfragen absolut priorisiert über eine Arbitrierung der Vorausschauanfragen, derart, dass lediglich zwischen anderen Pipelineanfragen arbitriert werden kann jedoch nicht zwischen Pipelineanfragen und Vorausschauanfragen, und wobei Vorausschauanfragen lediglich unter einander arbitriert werden können, sofern diese für eine Arbitrierung zugelassen sind. Mit anderen Worten gesagt, werden Vorausschauanfragen verworfen, wenn eine Pipelineanfrage an einen der Eingänge eines jeweiligen Arbitrierers angelegt ist. Dies sichert zu, dass das hierarchische System in einem Pipeline-Betriebsmodus arbeitet, wenn die Pipeline mit Pipelineanfragen gefüllt ist, wobei das hierarchische System in einem Parallel-Betriebsmodus arbeitet, wenn einige oder alle der Arbitrierer in einem Leerlauf sind oder keine aktive Pipelineanfrage aufweisen.
Es ist hierbei zu bemerken, dass neben der oben beschriebenen strikten Trennung von Vorausschauanfragen und Pipelineanfragen in dem Arbitrierer 300, andere Wege eines Betriebs in anderen Ausführungsbeispielen geliefert werden können, wobei Vorausschauanfragen und Pipelineanfragen bei einer Arbitrierung gemischt werden können, beispielsweise indem den Vorausschauanfragen eine schwächere Priorität gegeben werden.
Es ist ferner zu bemerken, dass Pipelineanfragen immer an dem Ausgang 300b des Arbitrierers 300 erzeugt werden, wenn eine Arbitrierung in dem Arbitrierer durchgeführt wurde, wobei die Pipelineanfrage daraufhin zu dem Arbitrierer der nächst höheren Ebene übertragen wird, wie es vorgehend beschrieben wurde. Hat jedoch der Arbitrierer der nächst höheren Stufe eine Vorausschauanfrage in dem vorhergehenden Zyklus für diesen Eingang gewährt, so wird die Pipelineanfrage in den nächsten Zyklus verworfen, um eine Arbitrierung von verdoppelten Anfragen zu vermeiden.
Arbitrierer der untergeordneten Ebene empfangen direkt Anfragen von den Anfragern. Anstelle einer Kopplung der Ausgänge 300a mit den Anfragern, ist für die Arbitrierer der untersten Ebene der Eingang 300b mit den Anfragern gekoppelt, um die Anfragen zu empfangen und Vorausschausignale zu erzeugen, und um diese parallel zu dem Arbitrierer zum Arbitrieren der Anfrage zu liefern. Daher kann für die unterste-Ebene-Arbitrierer der Eingang 300a nicht vorgesehen sein oder abgeklemmt sein.
Um ein besseres Verständnis der oben beschriebenen Vorausschau-Implementation zu geben, wird im Folgenden das Beispiel, das in den 5a bis 5f und 6a bis 6f gegeben wurde, in den 8a bis 8f und 9a bis 9f auf die oben beschriebene Vorausschau-Implementation angewendet.
8a beginnt bei Zyklus 0, wobei das System in einem Leerlaufzustand ist. In 8b werden bei den Arbitrierern A11 und A12 in dem Zyklus 1 Anfragen von den Anfragen M2 und M7 empfangen. Aufgrund des Vorausschaumechanismus werden die Vorausschausignale werden von den Arbitrierern A11 und A12 zu A21 und von den Arbitrierern A21 zu dem Arbitrierer A31 übertragen. Mit anderen Worten gesagt, werden in dem Zyklus 1 die Vorausschausignale zu allen Ebenen des hierarchischen Systems übertragen. Es sei bemerkt, dass die Vorausschausignale (Vorausschauanfragen) in den Figuren durch Kreise angezeigt sind, während die Pipelineanfragen durch eine Raute angezeigt sind.
Die Anfragen von den Anfragern M2 und M7 sind bei den Arbitrierern A11 und A12 jeweils die einzigen aktiven Anfragen und werden daher gewährt. Bei dem Arbitrierer A21 sind zwei Vorausschauanfragen von A11 und A12 aktiv. Da keine Pipelineanfrage aktiv ist, wird bezüglich der zwei Vorausschauanfragen eine Arbitrierung durchgeführt und dem Eingang 1, der mit A11 korrespondiert, eine Gewährung erteilt. Bei dem Arbitrierer A31 ist die Voraus schauanfrage von A21 die einzig aktive Anfrage und daher wird dem ersten Eingang, der mit A21 korrespondiert, eine Gewährung erteilt.
In dem Zyklus 2, der in 8c gezeigt ist, werden Anfragen von den Anfragern M1, M6 und M9 bei den Arbitrierern A11, A12 und A13 empfangen und eine Gewährung für die selben erteilt, da keine weiteren Anfragen bei den jeweiligen Arbitrierern aktiv sind. Vorausschauanfragen werden für jeden Anfrager M1, M6 und M9 erzeugt und durch die jeweiligen Zweige geliefert, das heißt zu den Arbitrierern A21 und A31 für M1 und M6 und zu den Arbitrierern A22 und A31 für M9. Hinsichtlich des Arbitrierers A21 sind in Zyklus 2 drei Anfragen noch aktiv. Zwei Vorausschauanfragen und eine Pipelineanfrage. Die Pipelineanfrage bei dem Arbitrierer A21 ist eine Anfrage, die zu der Anfrage des Anfragers M7 in den vorhergehenden Zyklus korrespondiert. Es ist zu bemerken, dass keine Pipelineanfrage für die Arbitrierung in dem vorhergehenden Zyklus bei dem Arbitrierer A11 gültig war, da der Anfrage von A11, das heißt der Vorausschauanfrage von A11, die zur der Anfrage von M2 korrespondiert, bereits in dem vorhergehenden Zyklus Gewährung erteilt wurde. Da der Arbitrierer A21 nun eine aktive Pipelineanfrage enthält, wird die Pipelineanfrage über die Vorausschauanfragen priorisiert und dem Eingang 2 Gewährung erteilt. Der Vorausschauanfrage von M9 wird bei den Arbitrierern A13 und A22 Gewährung erteilt, wie es in 8c gezeigt ist. Ferner wird bei dem Arbitrierer A31, bei dem zwei Vorausschauanfragen von A21 und A22 aktiv sind, dem Eingang 1, der A21 entspricht, bei der Arbitrierung Gewährung erteilt.
In dem Zyklus 3, der in 8d gezeigt ist, werden Anfragen von den Anfragern M4 und M8 bei den Arbitrierern A11 und A12 jeweils empfangen. Vorausschauanfragen werden zu den Arbitrierern A21 und A31 übertragen. Der Arbitrierer A21 weist in dem Zyklus 3 vier Anfragen auf, zwei Vorausschauanfragen und zwei Pipelineanfragen jeweils von A11 und A21. In Übereinstimmung mit dem oben Beschriebenen werden die Pipelineanfragen priorisiert, weshalb eine Arbitrierung zwischen den zwei Pipelineanfragen durchgeführt wird, wobei dem ersten Eingang Gewährung erteilt wird.
Der Arbitrierer A31 weist in Zyklus 3 zwei Pipelineanfragen von den Arbitrierern A21 und A22 und eine Vorausschauanfrage auf. Eine Arbitrierung wird zwischen den Pipelineanfragen durchgeführt, wobei dem zweiten Eingang Gewährung erteilt wird. Es ist hierbei zu bemerken, dass in dem Zyklus 3 ein Lediglich-Pipeline-Betrieb erfolgt, da jeder der Arbitrierer, die in dem Zyklus 3 eine Arbitrierung durchführen, zwischen Pipelineanfragen arbitriert.
In Zyklus 4 werden neue Anfragen bei den Arbitrierern A11, A12 und A13 von den Anfragern M2, M7 und M10 jeweils empfangen. Vorausschauanfragen werden zu den Arbitrierern A21 und A31 für Anfragen von M2 und M7 übertragen und Vorausschauanfragen werden zu den Arbitrierern A22 und A31 für die Anfrage von M10 übertragen. In diesem Zyklus haben alle Arbitrierer A21 und A31 aktive Pipelineanfragen, wodurch die Vorausschauanfragen von M2 und M7 nicht in Betracht gezogen werden. Für den Zweig, der zu M10 korrespondiert, wird für die Anfrage von M10 durch die Vorausschauanfragen, die auf dieser Anfrage basieren, Gewährung durch die Arbitrierer A13 und A22 in einem Zyklus ermöglicht, da die Arbitrierer A13 und A22 in dem Zyklus 3 in einem Leerlaufzustand waren. Es ist zu bemerken, dass die Vorausschauanfrage von M10 bei dem Arbitrierer A31 verworfen wird, da an dem Eingang 1 eine aktive Pipelineanfrage vorliegt. Da den Vorausschauanfragen von M10 durch die Arbitrierer A13 und A22 Gewährung erteilt werden, schreitet die Anfrage in einem Zyklus zwei Ebenen durch die Pipeline hinunter. Die Arbitrierer A13 und A22 führen einen parallelen Betrieb bezüglich der Anfrage von M10 aus. Verglichen mit einem reinen Pipeline-Betrieb, bei dem Gewährung lediglich dem Arbitrierer A13 für diese Anfrage innerhalb des Zyklus erteilt werden würde, hat die Anfrage eine Stufe in der Pipeline gewonnen.
Bezüglich des Arbitrierers A21 ist zu bemerken, dass die Pipelineanfrage, die aus der Arbitrierung in dem vorhergehenden Zyklus resultiert (Zyklus 3) nicht zu dem entsprechenden Eingang des Arbitrierers A31 übertragen werden konnte, weil die Anfrage bei dem Arbitrierer A31 noch aktiv ist, da diesem Eingang in dem vorhergehenden Zyklus keine Gewährung erteilt wurde.
Die Ausgabeanfrage von dem Zyklus 3 wird daher an dem Ausgang des Arbitrierers A21 aufrechterhalten, und der Arbitrierer A21 wird in diesem Zyklus für die Arbitrierung geblockt, wie es durch die graue Farbe angezeigt ist. Zusätzlich ist der Arbitrierer A12 für eine Arbitrierung in diesem Zyklus geblockt, da dem Eingang des Arbitrierers A21, der zu A12 korrespondiert, in dem vorhergehenden Zyklus keine Gewährung erteilt wurde.
Der Arbitrierer A11, der eine neue Anfrage von dem Anfrager M2 empfangen hat, führt eine normale Arbitrierung durch, wobei dieser Anfrage Gewährung erteilt wird, wie in 8e gezeigt.
In dem Zyklus 5, der in 8f gezeigt ist, werden Anfragen von M1, M6 und M9 empfangen und entsprechende Vorausschauanfragen erzeugt. Da die Arbitrierer A21 und A31 aktive Pipelineanfragen aufweisen, werden die Vorausschausignale von M1 und M6 bei der Arbitrierung nicht in Betracht gezogen. Bezüglich der Anfrage von M9 wird der Vorausschauanfrage von M9 durch beide Arbitrierer A13 und A22 Gewährung erteilt, da der Arbitrierer A22 keine aktive Pipelineanfrage aufweist.
Es ist ferner zu bemerken, dass in dem Zyklus 5 die Arbitrierer A11 und A12 geblockt sind, da der Arbitrierer A21 in dem vorhergehenden Zyklus geblockt war, wodurch aktive Pipelineanfragen an dem Eingang des Arbitrierers A21 in dem vorhergehenden Zyklus nicht entfernt werden konnten, um zu ermöglichen, dass neue Anfragen vorwärts schreiten. Daher ist es für die Pipelineanfrage, die bei dem Zyklus 4 an dem Ausgang des Arbitrierers A21 aufrechterhalten ist, noch nicht erlaubt, zu dem Arbitrierer A21 übertragen zu werden. Ferner konnte die Anfrage von M2 der in dem Zyklus Gewährung erteilt wurde, am Ende des Zyklus 4 nicht zu dem Arbitrierer A21 übertragen werden, da die alte Anfrage an dem Eingang 1 des Arbitrierers A21 aufgrund des Blockierens des Arbitrierers A21 in dem vorhergehenden Zyklus noch anhängig ist.
Der Arbitrierer A21 führt während des Zyklus 5 normale Arbitrierung zwischen den anhängigen Pipelineanfragen durch, wobei dem Eingang 2, der A12 entspricht, in dem Arbitrierungsprozess Gewährung erteilt wird.
9a bis 9f zeigen nun das Datenpfadsystem für die oben beschriebene Operation. Wie es zu erkennen ist, sind in den Zyklus 1 die Multiplexer in einem Leerlaufzustand oder einem undefinierten Zustand, da keine Informationen von gewährten Eingängen in den Registern gespeichert sind. Bei dem Zyklus 2, werden die Multiplexer gemäß den gespeicherten Informationen in den jeweiligen Registern eingestellt (Vergleiche mit den Informationen, die in dem Register an dem Ende des vorhergehenden Zyklus, das heißt in dem Zyklus 1, der in 8b gezeigt ist, gespeichert sind), wobei ein Datentransfer für den Anfrager M2 durch alle Ebenen zu der geteilten Ressource innerhalb eines Zyklus ermöglicht wird. Ferner werden gemäß der Einstellung des Multiplexers D12 Daten von M7 von dem Anfrager M7 zu dem Eingang des Multiplexers D21 während des Zyklus 2 übertragen.
In dem Zyklus 3 werden die Multiplexer gemäß der aktuellen Informationen in jedem der Register (siehe 8c) geschaltet. Wie es in 9c zu erkennen ist, werden Daten von M7 von dem Eingang des Multiplexers D21 zu der geteilten Ressource während dieses Zyklus übertragen. Ferner wird ermöglicht, dass Daten von M1 und Daten M6 die Pipeline bis zu den jeweiligen Eingängen des Multiplexers D21 während dieses Zyklus durchschreiten. Zusätzlich werden Daten von M9 während des Zyklus 3 von dem Anfrager M9 zu dem Eingang des Multiplexers D31 übertragen.
In dem Zyklus 4, der in 9d gezeigt ist, wird der Multiplexer D31 auf den Eingang 2 geschaltet, wodurch ermöglicht wird, dass Daten von M9 an diesem Eingang verfügbar sind, um zu der geteilten Ressource übertragen zu werden. Ferner schreiten Daten von M1 durch die Pipeline durch von dem Eingang des Multiplexers D21 zu dem Eingang des Multiplexers D31 und Daten von M4 schreiten von dem Anfrager M4 zu dem Eingang des Multiplexers D21. Die Daten von M6 werden in diesem Zyklus nicht übertragen und sind noch an dem Eingang 2 des Multiplexers D21 verfügbar.
In dem Zyklus 5, der in 9e gezeigt ist, werden Daten von M1 von dem Eingang von D31 zu der geteilten Ressource übertragen, wobei Daten von M4 von dem Eingang des Multiplexers D21 zu dem Eingang des Multiplexers D31 übertragen werden. Ferner werden Daten von M2 von dem Anfrager M2 zu dem Eingang des Multiplexers D21 übertragen. Die Daten von M6 werden weiterhin nicht übertragen. Zusätzlich werden Daten von M10 von dem Anfrager M10 zu dem Eingang des Multiplexers D31 übertragen. Es sei wiederum darauf hingewiesen, dass Daten von M10 über mehr als eine Ebene in dem hierarchischen System übertragen werden.
In dem Zyklus 6, der in 9f gezeigt ist, werden Daten von M4 von dem Eingang von D31 zu der geteilten Ressource übertragen und die Daten von M6 werden von dem Eingang des Multiplexers D21 zu dem Eingang des Multiplexers D31 übertragen. Ferner werden Daten von M9 von dem Anfrager M9 zu dem Eingang des Multiplexers D22 übertragen.
Vergleicht man den Datentransferbetrieb, der unter Bezugnahme auf die 9a bis 9f beschrieben ist, mit dem Datentransferbetrieb, der unter Bezugnahme auf die 6a bis 6f beschrieben ist, so kann bemerkt werden, dass in dem Betrieb gemäß den 9a bis 9f der Datentransfer bereits bei dem Zyklus 2 beginnt, während bei dem reinen Pipeline-Betrieb das System n – 1 Zyklen, das heißt zwei Zyklen mehr, nach dem Leerlaufzustand des Systems benötigte. Es ist ein allgemeines Merkmal des oben beschriebenen Ausführungsbeispiels, dass nach einem Leer laufzustand des Systems unabhängig von der Anzahl von Ebenen der hierarchischen Architektur die erste Gewährungsentscheidung aufgrund des parallelen Betriebs innerhalb eines Zyklus gemacht werden kann, wobei Daten bereits in den nächsten Zyklus übertragen werden können.
Das oben beschriebene Ausführungsbeispiel überwindet daher Totzeiten der Pipeline aufgrund von Arbitrierern in einem Leerlaufzustand durch ein Erzeugen von Vorausschauanfragen entlang eines jeweiligen Zweigs des hierarchischen Systems für jede Anfrage, die von einem Anfrager empfangen wird. Eine weitere Modifikation kann gemäß einem Ausführungsbeispiel erhalten werden, indem die Vorausschauanfragen für jede Anfrage von einem Anfrager und für jede Pipelineanfrage erzeugt wird. Dies ermöglicht, Lücken (Leerlaufzustände) der Pipeline in der Mitte der Pipeline zu überbrücken. Der obige Betrieb kann gemäß einem Ausführungsbeispiel durch das Bereitstellen eines weiteren Eingangs für die Oder-Komponente zusätzlich zu der Mehrzahl von Eingängen 300c geliefert werden, wobei der weitere Eingang mit dem Ausgang 300b verbunden ist, wie in 10 gezeigt.

Claims

Verfahren mit folgenden Schritten: Betreiben einer Mehrzahl von Arbitrierern in einem Pipeline-Modus; und Betreiben zumindest eines Teils der Mehrzahl von Arbitrierern in einem Nicht-Pipeline-Betrieb.
Verfahren gemäß Anspruch 1, wobei der Pipeline-Modus folgende Schritte umfasst: Liefern eines ersten Signals von einem ersten Arbitrierer zu einem zweiten Arbitrierer basierend auf einer Arbitrierung bei dem ersten Arbitrierer; und wobei der Nicht-Pipeline-Betrieb folgende Schritte umfasst: Liefern eines zweiten Signals zu dem zweiten Arbitrierer unabhängig von einer Arbitrierung bei dem ersten Arbitrierer; und Arbitrieren bei dem zweiten Arbitrierer basierend auf dem zweiten Signal.
Verfahren gemäß Anspruch 2, bei dem das zweite Signal in dem Pipeline-Modus und dem Nicht-Pipeline-Betrieb geliefert wird, wobei in dem Pipeline-Modus eine Arbitrierung bei dem zweiten Arbitrierer basierend auf dem ersten Signal priorisiert wird über eine Arbitrierung basierend auf dem zweiten Signal.
Verfahren gemäß Anspruch 2 oder 3, wobei die Mehrzahl von Arbitrierern eine Mehrzahl von Arbitrierern eines hie rarchischen Arbitrierungssystem sind, wobei das erste Signal ein Pipelineanfragesignal ist und das zweite Signal ein Vorausschausignal ist und wobei das Betreiben in dem Pipeline-Modus ein Liefern des Pipelineanfragesignals von dem ersten Arbitrierer zu einem ersten Eingangstor des zweiten Arbitrierers basierend auf der Arbitrierung zwischen der Mehrzahl von Eingangsports an dem ersten Arbitrierer aufweist, wobei der zweite Arbitrierer auf einer übergeordneten Ebene verglichen mit dem ersten Arbitrierer implementiert ist; und wobei der Nicht-Pipeline-Betrieb folgende Schritte umfasst: Liefern des Vorausschausignals zu einem ersten Eingangsport des zweiten Arbitrierers auf einer übergeordneten Ebene, wobei das Vorausschausignal unabhängig von einem Arbitrieren bei dem ersten Arbitrierer ist; und Liefern eines dritten Signals, das eine Gewährung für den ersten Eingangsport anzeigt, basierend auf dem Vorausschausignal.
Verfahren gemäß einem der Ansprüche 1 bis 4, wobei der zumindest eine Teil der Mehrzahl von Arbitrierer in einem Nicht-Pipeline-Betrieb betrieben wird, wenn der zumindest eine Teil der Mehrzahl von Arbitrierer in dem vorhergehenden Zyklus in einem Leerlaufzustand ist oder in dem vorhergehenden Zyklus keine aktive Pipelineanfrage aufweist.
Verfahren gemäß einem der Ansprüche 1 bis 5, wobei der Nicht-Pipeline-Betrieb ein paralleles Durchführen einer Arbitrierung einer Anfrage von zumindest einem Anfrager einer Mehrzahl von Anfragern umfasst.
Verfahren gemäß einem der Ansprüche 1 bis 6, das ferner folgenden Schritt aufweist: Speichern von Informationen für jeden der Mehrzahl von Arbitrierern, wobei die Informationen diejenigen Tore anzeigen, denen durch einen jeweiligen der Mehrzahl von Arbitrierern Gewährung erteilt wurde.
Verfahren gemäß Anspruch einem der Ansprüche 1 bis 7, das ferner den folgenden Schritt aufweist: Liefern eines Datenpfads von einem Anfrager zu einer geteilten Ressource basierend auf den Informationen, die für einen jeweiligen Arbitrierer der Mehrzahl von Arbitrierern gespeichert sind.
Verfahren gemäß einem der Ansprüche 1 bis 8, wobei in dem Pipeline-Modus eine Anfrage pro Taktzyklus eine Ebene vorschreitet, und wobei in dem Nicht-Pipeline-Betrieb eine Anfrage zumindest zwei Ebenen der Pipeline pro Taktzyklus vorschreitet.
Verfahren gemäß Anspruch 9, wobei die Anfrage in dem Nicht-Pipeline-Betrieb alle Ebenen der Pipeline innerhalb eines Taktzyklus vorschreitet.
Verfahren gemäß einem der Ansprüche 1 bis 10, wobei einem Anfrager durch die Mehrzahl von Arbitrierern Gewährung für einen Datentransfer zu einer geteilten Ressource innerhalb eines Taktzyklus nachdem der Anfrager eine Anfrage zum Gewähren zu der Mehrzahl von Arbitrierern ausgegeben hat, erteilt wird, wenn die Mehrzahl von Arbitrierern in einem Leerlaufzustand ist.
Arbitrierungsknoten in einem hierarchischen Arbitrierungssystem, wobei der Arbitrierungsknoten folgende Merkmale umfasst: einen ersten Knoten, wobei der erste Knoten eine Mehrzahl von ersten Eingängen aufweist, um erste Signale von einem untergeordneten Arbitrierungsknoten zu empfangen und einen ersten Ausgang aufweist, um ein Signal zu einem Arbitrierungsknoten einer höheren Ebene zu übertragen; und einen zweiten Knoten, wobei der zweite Knoten eine Mehrzahl von zweiten Eingängen aufweist, um zweite Signale von zweiten Knoten von untergeordneten Arbitrierungsknoten zu empfangen, und einen zweiten Ausgang auweist, um ein Signal zu einem übergeordneten Arbitrierungsknoten zu übertragen.
Arbitrierungsknoten gemäß Anspruch 12, wobei der zweite Knoten kombinatorische Hardware-Logik aufweist.
Arbitrierungsknoten gemäß Anspruch 13, wobei die kombinatorische Hardware-Logik implementiert ist, um eine Mehrzahl von Eingangssignalen, die an den zweiten Eingängen empfangen werden, zu kombinieren, und an dem Ausgang ein Ausgangssignal entsprechend einer Oder-Kombination der Eingangssignale zu liefern.
Arbitrierungsknoten gemäß einem der Ansprüche 12 bis 14, wobei der Arbitrierer mit einem Register gekoppelt ist, das dem Arbitrierungsknoten zugeordnet ist, um Informationen zu speichern, die sich auf den durch den Arbitrierern gewährten Eingang beziehen.
Arbitrierersystem mit folgenden Merkmalen: einem ersten Arbitrierer; einem zweiten Arbitrierer; einem dritten Arbitrierer; einer ersten Verbindung, um ein erstes Signal von einem ersten Anfrager einer Mehrzahl von Anfragern zu dem zweiten Arbitrierer zu übertragen; einer zweiten Verbindung, um ein zweites Signal von einem zweiten Anfrager der Mehrzahl von Anfragern zu dem ersten Arbitrierer zu übertragen; einer dritten Verbindung, um ein drittes Signal basierend auf dem ersten und zweiten Signal zu dem dritten Arbitrierer zu übertragen; einer vierten Verbindung, um ein viertes Signal von dem ersten Arbitrierer zu dem dritten Arbitrierer zu übertragen; und einer fünften Verbindung, um ein fünftes Signal von dem zweiten Arbitrierer zu dem dritten Arbitrierer zu übertragen.
Arbitrierersystem gemäß Anspruch 16, wobei das Arbitrierersystem ein hierarchisches Arbitrierersystem ist, wobei die ersten und zweiten Arbitrierer einer hierarchischen Ebene zugeordnet sind, und wobei der dritte Arbitrierer einer unterschiedlichen hierarchischen Ebene, die der einen hierarchischen Ebene übergeordnet ist, zugeordnet ist.
Arbitrierersystem gemäß Anspruch 16 oder 17, wobei die dritte Verbindung eine kombinatorische Hardware-Logik aufweist, wobei die kombinatorische Hardware-Logik einen ersten und zweiten Eingang und einen Ausgang zum Ausgeben des dritten Signals aufweist, und wobei die vierte und fünfte Verbindung jeweils ein Register aufweisen, um das vierte und fünfte Signal zu speichern, wobei das Register mit einem Steuereingang eines Multiplexers gekoppelt ist.
Arbitrierersystem gemäß einem der Ansprüche 16 bis 18, wobei das System ferner folgendes Merkmal aufweist: einen Datenpfad, der den ersten Anfrager und den zweiten Anfrager mit einer geteilten Ressource koppelt, wobei der Datenpfad mit dem Multiplexer gekoppelt ist, um selektiv Daten basierend auf den in dem Register gespeicherten Signalen zu übertragen.
Arbitrierersystem mit folgenden Merkmalen: einer Mehrzahl von Arbitrierern, wobei die Mehrzahl von Arbitrierern ausgebildet ist, um in einem Pipeline-Betrieb betrieben zu werden, und wobei zumindest ein Teil der Mehrzahl von Arbitrierern ausgebildet ist, um in einem Nicht-Pipeline-Betrieb betrieben zu werden.
Arbitrierersystem gemäß Anspruch 20, wobei der zumindest eine Teil der Mehrzahl von Arbitrierern in einem Nicht-Pipeline-Betrieb betrieben wird, wenn sich der zumindest eine Teil der Mehrzahl von Arbitrierern in einem Leerlaufzustand befindet.
Arbitrierersystem gemäß Anspruch 20 oder 21, wobei die Mehrzahl von Arbitrierern konfiguriert ist, um, wenn sich die Mehrzahl von Arbitrierern ursprünglich in einem Leerlaufzustand befindet, eine Datenübertragung für einen Anfrager einen Taktzyklus nachdem der Anfrager bezüglich eines Zugriffs eine Anfrage gestellt hat, auszulösen.
Arbitrierersystem gemäß einem der Ansprüche 20 bis 22, wobei die Mehrzahl von Arbitrierern ein hierarchisches Arbitrierungssystem bildet.
Arbitrierersystem gemäß einem der Ansprüche 20 bis 23, wobei jeder der Mehrzahl von Arbitrierern mit einem entsprechenden Register gekoppelt ist, um Informationen zu speichern, die Tore anzeigen, denen durch die Mehrzahl von Arbitrierern Gewährung erteilt wurde.
Arbitrierersystem gemäß Anspruch 24, wobei das entsprechende Register mit einem entsprechenden Multiplexer gekoppelt ist, um einen Datenpfad von einem Anfrager zu einer geteilten Ressource basierend auf Informationen zu liefern, die in jedem der entsprechenden Register gespeichert sind.
Arbitrierersystem gemäß Anspruch 25, wobei die Mehrzahl von Arbitrierern konfiguriert ist, um in dem Pipeline-Betrieb ein erstes Signal von einem ersten Arbitrierer zu einem zweiten Arbitrierer auf einer nächst höheren Ebene basierend auf einer Arbitrierung bei dem ersten Arbitrierer zu liefern, und wobei in dem Nicht-Pipeline-Betrieb ein zweites Signal zu dem zweiten Arbitrierer unabhängig von der Arbitrierung in dem ersten Arbitrierer geliefert wird.
Arbitrierersystem gemäß Anspruch 26, wobei das zweite Signal ferner bei dem Pipeline-Betrieb geliefert wird, und wobei eine Arbitrierung basierend auf dem ersten Signal priorisiert wird über eine Arbitrierung basierend auf dem zweiten Signal.