-
Die vorliegende Erfindung bezieht sich im Allgemeinen auf das Erfindungsgebiet des Entwurfs von asynchronen Schaltungen. Insbesondere bezieht sich die Erfindung auf Arbiter zum Handling mehrerer (fast) zeitgleicher Schaltungseingänge und auf die Anwendung solcher Arbiter in asynchronen Zustandsautomaten.
-
Die meisten digitalen Schaltungen, die heutzutage entworfen und angefertigt werden, sind „synchron”. Im Wesentlichen basieren synchrone Schaltungen auf zwei grundlegenden Annahmen, die ihren Entwurf bedeutend vereinfachen: (1) alle Signale sind binär, und (2) alle Komponenten nutzen einen gemeinsamen und diskreten Zeitbegriff, wie er durch ein Taktsignal definiert wird, das durch die gesamte Schaltung verteilt ist.
-
Asynchrone Schaltungen sind grundsätzlich anders. Auch sie nehmen Binärsignale an, doch es gibt keine gemeinsame und diskrete Zeit. Stattdessen verwenden diese Schaltungen Handshake-Verfahren zwischen ihren Komponenten, um die notwendige Synchronisierung, Kommunikation und Reihenfolgebildung der Operationen durchzuführen. Mit Begriffen ausgedrückt, die normalerweise in Hinsicht auf synchrone Schaltungen verwendet werden, führt dies zu einem Verhalten, das einer systematischen feinen Taktung und lokalen Takten ähnelt, die nicht phasengleich sind und deren Perioden von effektiven Schaltungsverzögerungen bestimmt werden. Dieser Unterschied verleiht den asynchronen Schaltungen inhärente Eigenschaften, die im Vergleich zu synchronen (getakteten) Schaltungen möglicherweise vorteilhaft sind (z. B. in Hinsicht auf Energieverbrauch, Operationsgeschwindigkeit, elektromagnetische Emissionen, Robustheit gegenüber Schwankungen der Versorgungsspannung, der Temperatur, von Herstellungsprozessparametern usw.).
-
Auf der anderen Seite sind auch einige Nachteile vorhanden. Asynchrone Schaltungen erfordern normalerweise eine Steuerungslogik zum Umsetzen der Handshake-Operationen, die notwendig sind, um verschiedene Schaltungselemente zu synchronisieren, da kein globales Taktsignal existiert. Die asynchrone Steuerungslogik, die den Handshake umsetzt, stellt normalerweise einen Overhead hinsichtlich der Schaltungskomplexität dar. Beispiele asynchroner Schaltungen sind beispielsweise in den Publikationen
US 2011/0121857 A1 und
US 5 404 556 A beschrieben. Die erstgenannte Publikation betrifft eine asynchrone Digitalschaltung mit Arbitrierungs- und Routingfunktionen für asynchrone Netzwerke. Dabei wird mit Hilfe eines Multiplexers zwishen verschiedenen Datenwegen umgeschaltet. Die zweitgenannte Publikation betrifft eine Vorrichtung zum Durchführen asynchroner Kommunikation zwischen integrierten Schaltungen.
-
Wichtige Handshake-Komponenten, die normalerweise zum Umsetzen der erwähnten Handshake-Operationen verwendet werden, erfordern, dass die Kommunikation auf mehreren (Eingangs-)Kanälen beiderseitig exklusiv ist, wenigstens an einem Punkt, an dem zwei Kanäle zu einem gemeinsamen Kanal zusammengefügt werden (siehe z. B. Jens Sparsø, Hg.: Kap. 5.8. ”Mutual exclusion, arbitration and metastability” in: PRINCIPLES OF ASYNCHRONOUS CIRCUIT DESIGN – A Systems Perspective, Kluwer Academic Publishers, 2001). Das heißt, ein High-Low-Zustandsübergang (oder umgekehrt) tritt möglicherweise zu einer gegebenen Zeit nur auf einem einzelnen Kanal auf. Zeitgleiche „Ereignisse” auf zwei oder mehr Kanälen werden normalerweise von Arbitern behandelt, die sogenannte Mutex-Elemente verwenden, um zu entscheiden, welches Ereignis zuerst verarbeitet werden soll. Allerdings sind Mutex-Elemente unerwünschten Metastabilitätseffekten ausgesetzt, wenn zwei Ereignisse zeitgleich oder fast zeitgleich auftreten (d. h. innerhalb eines kurzen Zeitraums).
-
Insbesondere beim Umsetzen endlicher Automaten (FSM, finite state machines) können gleichzeitig auftretende Ereignisse auf unterschiedlichen Kommunikationskanälen (z. B. auf unterschiedlichen Signalleitungen) problematisch sein, und geeignete Arbitrationsschaltungen (Arbiter) können erheblich komplex sein. Ein Ziel der vorliegenden Erfindung ist es, einen einfach herzustellenden Zustandsautomaten bereitzustellen, der einen Arbiter zum Handling von gleichzeitigen Ereignissen auf unterschiedlichen Kommunikationskanälen enthält. Dieses Ziel kann unter Verwendung des Arbiters nach Anspruch 1, des Systems nach Anspruch 8 und des Arbitrationsverfahrens nach Anspruch 11 erreicht werden. Unterschiedliche Ausführungsformen und weitere Entwicklungen werden durch die abhängigen Ansprüche abgedeckt.
-
Es wird ein Arbiter zur Verarbeitung mehrerer asynchroner Datensignale offenbart. Jedes Datensignal ist mit einem entsprechenden Anforderungssignal und mit einem entsprechenden Quittungssignal verknüpft. Gemäß einem Beispiel der Erfindung enthält der Arbiter ein Latch-Array, das die Datensignale und die Anforderungssignale als Eingangssignale empfängt und das einen Datenvektor und einen dazugehörigen Validitätsvektor als Ausgangssignale bereitstellt. Der Datenvektor enthält Werte, die von den Datensignalen abhängen, und der Validitätsvektor enthält Werte, die von den Anforderungssignalen abhängen, wenn der Latch in einem transparenten Zustand ist. Der Arbiter enthält weiterhin logische Schaltkreise, die dazu konfiguriert sind, die Anforderungssignale zu überwachen und den Latch zu triggern (d. h., den Latch-Ausgang „einzufrieren”), wenn irgendeines der Anforderungssignale aktiv wird. Die logischen Schaltkreise sind weiterhin dazu konfiguriert, ein globales Anforderungssignal eine Verzögerungszeit nach dem Triggern des Latches zu aktivieren und die Quittungssignale für den Kanal bzw. die Kanäle selektiv zu aktivieren, für den bzw. für die ein aktives Anforderungssignal gelatcht (zwischengespeichert) worden ist.
-
Die Erfindung kann unter Bezugnahme auf die folgenden Zeichnungen und die Beschreibung besser verstanden werden. Die Komponenten in den Figuren sind nicht notwendigerweise maßstabsgetreu, weil stattdessen die Betonung darauf gelegt wird, die Grundlagen der Erfindung zu veranschaulichen. Die Zeichnungen:
-
1 enthält die 1a und 1b und veranschaulicht den Handshake, der Anforderungs- und Quittungssignale zwischen einem Sender und einem Empfänger in einer asynchronen Schaltung verwendet;
-
2 enthält die 2a und 2b und veranschaulicht ein beispielhaftes Mutex-Element;
-
3 enthält die 3a und 3b und veranschaulicht einen Arbiter zum Handling von zwei Anforderungssignalen, die an die gleiche Ressource (z. B. Empfänger) gerichtet sind;
-
4 veranschaulicht einen Arbiter zum Handling mehrerer Anforderungssignale in einem Schritt gemäß einem Beispiel der Erfindung und dessen Anwendung in Verbindung mit einem endlichen Automaten;
-
5 veranschaulicht eine beispielhafte Anforderungsgenerator-Schaltung, die in Verbindung mit dem Arbiter aus 4 verwendet werden kann;
-
6 stellt Zeitdiagramme bereit, die die Funktion des Arbiters aus 4 veranschaulichen;
-
7 veranschaulicht ein Umsetzungsbeispiel des im Beispiel in 4 veranschaulichten Zustandsautomaten;
-
8 veranschaulicht ein Umsetzungsbeispiel der Anforderungsgenerator-Schaltung (Anforderer, requestor) aus 5; und
-
9 veranschaulicht ein Umsetzungsbeispiel des Arbiters aus 4.
-
In den Figuren bezeichnen gleiche Referenznummern die dazugehörigen Teile.
-
In asynchronen Schaltungen ist kein globaler Systemtakt erforderlich. Stattdessen werden Handshake-Operationen zum Synchronisieren unterschiedlicher Schaltungskomponenten verwendet. 1a veranschaulicht den Datenfluss von einem Sender 10 zu einem Empfänger 20. Eine Änderung des Datensignals wird vom Sender 10 mittels des Anforderungssignals REQ signalisiert, und der Empfang der Daten wird vom Sender durch das Quittungssignal ACK signalisiert. Die Anforderungs- und Quittungssignale werden mit den Datensignalen (in 1 mit DATA bezeichnet) „gebündelt”, und somit wird dieses Konzept häufig als „Datenbündelung” bezeichnet. Der Begriff Datenbündelung bezieht sich auf Umstände, bei denen die Datensignale normale boolesche Pegel zum Codieren von Informationen verwenden und bei denen separate Anforderungs- und Quittungssignale mit den Datensignalen gebündelt werden.
-
Unterschiedliche Handshake-Protokolle sind bekannt. Die als DATA bezeichneten Signale sollten stabil sein, kurz bevor und während das Anforderungssignal REQ aktiv ist (z. B. REQ = 1). 1b veranschaulicht als ein Beispiel ein Vier-Phasen-Protokoll, worin die Anforderungs- und Quittungssignale REQ und ACK ebenfalls normale boolesche Pegel zum Codieren von Informationen verwenden. Der Begriff „Vier-Phasen” bezieht sich auf die Anzahl der Kommunikationsaktionen: (1) der Sender 10 gibt Daten (Datensignale DATA) aus und setzt das Anforderungssignal REQ auf einen High-Pegel, (2) der Empfänger 20 empfängt die Daten und setzt das Quittungssignal ACK auf einen High-Pegel, sobald die Daten korrekt empfangen oder verarbeitet worden sind, (3) der Sender 10 antwortet, indem er das Anforderungssignal REQ auf einen Low-Pegel rücksetzt (ab diesem Punkt ist nicht länger garantiert, dass die Daten valide sind), und (4) der Empfänger 20 quittiert dies, indem er das Quittungssignal ACK auf einen Low-Pegel rücksetzt. An diesem Punkt initialisiert der Sender 10 möglicherweise den nächsten Kommunikationszyklus. Obwohl das veranschaulichte Handshake-Protokoll sehr verbreitet ist, sind auch andere Protokolle verfügbar und geeignet.
-
Das oben eingeführte Protokoll nimmt an, dass der Sender 10 der aktive Teilnehmer ist, der den Datentransfer über den Kanal initialisiert. Dies ist als Push-Kanal bekannt. Das Gegenteil, d. h. der Empfänger 20 fragt nach neuen Daten, ist ebenfalls möglich und wird ein Pull-Kanal genannt. In diesem Fall sind die Richtungen der Anforderungs- und Quittungssignale REQ und ACK umgekehrt, und die Validität der Daten wird darin angezeigt, dass das Quittungssignal ACK vom Sender 10 zum Empfänger 20 läuft (Pull-Kanäle). In abstrakten Schaltbildern, die Links/Kanäle (wie in 1a) als ein Symbol zeigen, wird das aktive Ende eines Kanals oft mit einem Punkt gekennzeichnet. Die Datensignale DATA werden möglicherweise in Fällen weggelassen, in denen lediglich die Synchronisierung von zwei Schaltungskomponenten erforderlich ist, ohne dass Daten ausgetauscht werden müssen. Weiterhin kann der Datenfluss bidirektional sein (Push-/Pull-Kanäle). Obwohl sich die weitere Erörterung auf Push-Kanäle konzentriert, können die hierin eingeführten Prinzipien auch auf Pull-Kanäle und auf Push-/Pull-Kanäle angewandt werden.
-
Angesichts des in 1 veranschaulichten Datenaustausch- und Synchronisierungsmechanismus ist klar, dass Empfänger, die mehrere Eingangskanäle empfangen, (fast) zeitgleich auftretende Anforderungen bewältigen müssen (d. h. einen Zustandsübergang im Anforderungssignal REQ). Normalerweise werden sogenannte „Mutex-Elemente” verwendet (Mutex ist ein Portmanteau-Wort aus „mutually” und „exclusiv” – beiderseitig exklusiv), um sicherzustellen, dass nur eine Anforderung (oder, allgemein, ein Ereignis), die in einem speziellen von mehreren Signalen auftritt, an den Empfänger übermittelt wird.
-
Ein beispielhaftes Mutex-Element (als MUTEX bezeichnet) wird in 2 veranschaulicht. Die Eingangssignale R1 und R2 sind zwei Anforderungen, die aus zwei unabhängigen Quellen stammen, und die Aufgabe des Mutex-Elementes ist es, diese Eingänge an die dazugehörigen Ausgänge G1 und G2 auf eine solche Weise weiterzureichen, dass zu jeder gegebenen Zeit höchstens ein Ausgang aktiv ist (das heißt z. B. auf einem High-Pegel). Wenn nur eine Eingangsanforderung ankommt, ist die Operation trivial. Wenn eine Eingangsanforderung deutlich vor der anderen ankommt, wird die letzte Anforderung blockiert, bis die erste Anforderung nicht geltend gemacht wurde. Das Problem tritt auf, wenn beide Eingangssignale zur gleichen Zeit geltend gemacht werden. Dann ist das Mutex-Element MUTEX erforderlich, um eine arbiträre Entscheidung zu treffen, und hier tritt die Metastabilität ins Blickfeld. Da dieses Problem der Metastabilität allgemein bekannt ist, wird es hier nicht weiter erörtert.
-
Es wird Bezug genommen auf die Literatur (siehe z. B. Jens Sparsø, Hg.: Kap. 5.8. ”Mutual exclusion, arbitration and metastability” in: PRINCIPLES OF ASYNCHRONOUS CIRCUIT DESIGN – A Systems Perspective, Kluwer Academic Publishers, 2001). Im Beispiel aus 2b ist das Mutex-Element aus einem Flipflop (umgesetzt mit den zwei NAND-Gattern) und einem dieser nachgeschalteten Metastabilitätsfilter (umgesetzt durch die CMOS-Transistorschaltung) zusammengesetzt.
-
Mutex-Elemente können zum Umsetzen eines Arbiters verwendet werden, der verwendet werden kann, um den Zugang zu einer Ressource (z. B. einem Empfänger) zu steuern, die von mehreren autonomen unabhängigen Teilnehmern (z. B. mehreren Sendern) gemeinsam genutzt wird. Eine mögliche Umsetzung wird in 3 gezeigt. Da die veranschaulichte Arbiter-Umsetzung ebenfalls allgemein bekannt ist, erfolgt hier nur eine grobe Erklärung, und es wird Bezug auf das oben erwähnte Fachbuch von J. Sparsø genommen.
-
In dem Beispiel in 3b stellt das Mutex-Element MUTEX sicher, dass die (Anforderungs-)Signale G1 und G2 (an der Schnittstelle a'-aa') beiderseitig exklusiv sind. Auf das Mutex-Element folgen zwei AND-Gatter, deren Zweck es ist sicherzustellen, dass Handshakes auf den y1/A1- und y2/A2-Kanälen (an der Schnittstelle b'-bb') beiderseitig exklusiv sind. Das heißt, dass das Anforderungssignal y2 nur High werden kann, wenn das Quittungssignal A1 Low ist, und dass das Anforderungssignal y1 nur High werden kann, wenn das Quittungssignal A2 Low ist. Wenn die Handshake-Funktion auf einem Kanal im Gange ist, blockiert der Arbiter auf diese Weise die Handshake-Funktion auf dem anderen Kanal. In Fällen, in denen der Arbiter mehr als zwei Eingänge behandeln muss, ist die Arbiter-Schaltung erheblich komplexer. Das mit „C” bezeichnete Gatter ist ein Muller-C Element, das ebenfalls ausführlich in dem oben erwähnten Fachbuch von J. Sparsø erörtert wird.
-
In Fällen, in denen der Arbiter zum Handling von Eingängen verwendet wird, die an einen endlichen Automaten (FSM) geliefert werden, kann nur ein Eingangssignal zur Zeit vom FSM verarbeitet werden. Beim Handling mehrerer Eingänge ist weiterhin eine große Anzahl von Mutex-Elementen (angeordnet z. B. in einer Ketten- oder Baumstruktur) erforderlich, wobei jedes Mutex-Element die aus der Metastabilität entstehenden, erwähnten Probleme bewältigen muss, was den Arbiter möglicherweise erheblich verlangsamt. Angesichts dessen ist ein neuartiger Arbiter entwickelt worden, der zum Handling mehrerer Eingangskanäle in der Lage ist und es somit einem endlichen Automaten (FSM) ermöglicht, mehrere „Ereignisse” (z. B. Anforderungen) in einem einzelnen Schritt zu verarbeiten. Ein Beispiel des Arbiters wird hierin nachstehend unter Bezugnahme auf die 4 und 5 beschrieben.
-
4 veranschaulicht ein Blockschaltbild eines asynchron betriebenen endlichen Automaten 40 (FSM), der mehrere Eingangsdatensignale D0, D1, D2, ..., Dn empfängt, wobei jedes Datensignal D0, D1, D2, ..., Dn mit dazugehörigen Anforderungssignalen R0, R1, R2, ..., Rn und dazugehörigen Quittungssignalen A0, A1, A2, ..., An verknüpft ist, um eine Handshake-Operation zu ermöglichen, z. B. wie hinsichtlich 1 erklärt. Die Eingangsdatensignale D0, D1, D2, ..., Dn und die dazugehörigen Anforderungssignale R0, R1, R2, ..., Rn werden nicht direkt an den FSM 40 geliefert. Die Daten- und Anforderungssignale Di, Ri (wobei i = 0, 1, 2, ..., n) werden stattdessen an einen Arbiter 30 geliefert, der dazu konfiguriert ist, die Anforderungssignale Ri auf allen Kanälen (Kanal 0 bis Kanal n) zeitgleich zu überwachen.
-
Sobald irgendein Anforderungssignal aktiv wird (z. B. einen High-Pegel annimmt), werden die Werte aller Anforderungs- und Datensignale Ri, Di in Latches (d. h. in einem Latch-Array) gespeichert. Zu diesem Zweck ist der Arbiter dazu konfiguriert, zeitgleich alle Anforderungssignale Ri auf Zustandsübergänge zu überwachen (darauf, ob Signale aktiv werden). Wenn eine oder mehr Anforderungen detektiert werden und die Signalwerte im Latch-Array gespeichert worden sind, wartet der Arbiter eine vordefinierte Zeitspanne ab, um es allen Latches zu ermöglichen, sich von möglichen metastabilen Zuständen zu erholen. Schließlich wird ein globales Anforderungssignal REQ erzeugt und an den FSM 40 geliefert. Die gelatchten Werte der Eingangsdatensignale D0, D1, ..., Dn werden dem FSM 40 als Datenvektor iDATA(0:n) bereitgestellt, wobei ein zusätzlicher Datenvektor iVALID(0:n) (Validitätsvektor) erzeugt und dem FSM 40 bereitgestellt wird, der die validen Daten anzeigt (z. B. die Werte derjenigen Datensignale Di, für die das dazugehörige gelatchte Anforderungssignal aktiv ist). Somit kann der Datenvektor folgendermaßen ausgedrückt werden: iDATA = (D0, D1, D2 ..., Dn), und der zusätzliche Datenvektor kann folgendermaßen ausgedrückt werden: iVALID = (R0, R1, R2 ..., Rn).
-
Das heißt, dass diejenigen Elemente Di des Datenvektors iDATA valide sind, für die das dazugehörige Anforderungssignal Ri, das im zusätzlichen Datenvektor iVALID gespeichert ist, aktiv ist (z. B. Ri = 1). Wenn der FSM die Datenvektoren iDATA, iVALID empfangen hat, wird ein dazugehöriges Quittungssignal ACK erzeugt und an den Arbiter zurückgesendet, wie hinsichtlich des allgemeinen Beispiels in 1 erklärt wurde. Das Quittungssignal ACK wird an diejenigen Kanäle übermittelt, für die ein aktives Anforderungssignal Ri detektiert worden ist, das heißt Ai = ACK, wenn Ri = aktiv (für i = 0, 1, 2, ... n).
-
Mit einem Arbiter, der wie oben erklärt betrieben wird, können mehrere Eingangsdatensignale zeitgleich verarbeitet werden. Nur die Anforderungen, die erfolgreich an den FSM 40 übermittelt werden, werden zurück an den Sender quittiert. Die Anforderungen, die nicht erfasst werden, werden im nächsten „Zyklus” verarbeitet. Es sei allerdings angemerkt, dass eine feste Zyklusperiode nicht erforderlich ist. Der Arbiter und der FSM bleiben stattdessen beim Verarbeiten von Anforderungssignalen, solange wie irgendein Anforderungssignal aktiv ist. Im Resultat erfolgt ein automatisches Verarbeiten von noch-nicht-bedienten Ereignissen (d. h. von aktiven Anforderungen, die noch nicht verarbeitet worden sind).
-
5 veranschaulicht einen „Anforderungsgenerator”, der eine Schaltung 35 ist, die dazu konfiguriert ist, ein Anforderungssignal als Reaktion auf eine Aktualisierung der Daten DATAi (i = 0, 1, 2, ..., n) zu erzeugen. Allerdings sind separate Anforderungsgeneratoren nicht erforderlich, wenn die Signalquelle (oder -quellen), die die Datensignale DATAi bereitstellt, in der Lage ist, geeignete, zu den Daten gehörige Anforderungssignale bereitzustellen. Es sei angemerkt, dass DATAi möglicherweise ein Einzelbit Signal oder ein n-Bit Signal darstellt, z. B. ein mit einem Datenwort von mehreren Bits verknüpftes Abtastsignal. Ein Umsetzungsbeispiel des Anforderungsgenerators wird weiter unten unter Bezugnahme auf 8 erörtert.
-
6 veranschaulicht die relevanten Signale (Anforderungs-, Daten- und Quittungssignale), die von einem Arbiter 30 verarbeitet werden, wie oben unter Bezugnahme auf 4 erklärt wurde. Im vorliegenden Beispiel werden nur zwei Datensignale D0 und D1 und sowohl zwei dazugehörige Anforderungssignale R0 und R1 als auch zwei dazugehörige Quittungssignale A0 und A1 in Betracht gezogen. Es sei angemerkt, dass die Datensignale D0 und D1 als valide in Betracht gezogen werden können, wenn die dazugehörigen Anforderungssignale R0 und R1 aktiv werden. Die beiden oberen Diagramme in 6 veranschaulichen die Anforderungssignale R0, R1, wobei beide Anforderungen (ansteigende Flanken) nahezu gleichzeitig am Arbiter ankommen. Die Anforderung R1 kommt allerdings ein bisschen später an, und somit triggert die Anforderung R0 das Latch-Array zu einem Zeitpunkt t1. Der Arbiter übermittelt dann die gelatchten Daten- und Anforderungssignale an eine nachfolgende Schaltung (z. B. an den FSM 40 im Beispiel aus 4). Um Metastabilitätseffekte zu vermeiden, wird für eine vordefinierte Zeit t2 – t1 gewartet, bevor das „globale” Anforderungssignal REQ (siehe 4) erzeugt wird, das an den Empfänger der Daten geliefert wird (z. B. an den FSM 40). Der Empfänger (z. B. der FSM 40) erzeugt das Quittungssignal ACK, wenn die Daten korrekt empfangen worden sind. Das Signal ACK wird an die Kanäle verteilt, für die ein aktives Anforderungssignal im Latch-Array erfasst worden ist; im vorliegenden Beispiel aus 6 wird das ACK-Signal an die Kanäle 0 und 1 als Signale A0 und A1 verteilt.
-
7 veranschaulicht ein Umsetzungsbeispiel eines endlichen Automaten (FSM) 40, der möglicherweise in Verbindung mit dem Arbiter 30 verwendet wird, wie im Beispiel aus 4 gezeigt wird. Der hier veranschaulichte FSM ist ein Zustandsautomat des Typs Mealy und enthält eine logische Schaltung 41, die dazu konfiguriert ist, aktualisierte Zustandsvariablen S'(0:k) aus den aktuellen Zustandsvariablen S(0:k) und den von Vektor iVALID(0:n) gegebenen Eingängen zu berechnen, das heißt S'(0:k) = f(S(0:k), iVALID(0:n)). Wenn die Berechnung abgearbeitet ist, dann werden die aktualisierten Zustandsvariablen S'(0:k) im Zustandsregister 43 gelatcht und werden somit zu den aktuellen Zustandsvariablen S(0:k), die auch als Ausgang des FSM angesehen werden können. Das Latchen der aktualisierten Zustandsvariablen S'(0:k) wird durch eine verzögerte Version ENB des Anforderungssignals REQ getriggert, das vom Arbiter 30 (siehe 4) bereitgestellt wird, wobei die Verzögerung (siehe Verzögerungselement 42) zwischen den Signalen REQ und ENB so entworfen wird, dass die Berechnung der aktualisierten Zustandsvariablen S'(0:k) abgearbeitet ist, bevor das Signal ENB aktiv wird und das Zustandsregister triggert (das auch als Latch-Array angesehen werden kann). Die verzögerte Version ENB des Anforderungssignals REQ wird ebenfalls zurück an den Arbiter als Quittungssignal ACK geliefert, um zu signalisieren, dass der Datenvektor iVALID(0:n) erfolgreich verarbeitet worden ist und dass der FSM zum Empfangen neuer Daten bereit ist. Es sei angemerkt, dass die hier vorgestellte Umsetzung als ein Beispiel betrachtet wird und dass z. B. eine Muller-Pipeline anstatt eines Zustandsregisters auf Flipflop-Basis zum Speichern verwendet werden kann.
-
Die 8 und 9 veranschaulichen Umsetzungsbeispiele der Anforderungsgenerator-Schaltung 35 aus 5 bzw. des Arbiters 40 aus 4. Die Anforderungsgenerator-Schaltung 35 empfängt ein Eingangsdatensignal DATAi (z. B. ein 1-Bit Signal im vorliegenden Beispiel) und stellt ein dazugehöriges Paar Anforderungssignal Ri und Ausgangsdatensignal Di als Reaktion auf einen Zustandsübergang (High nach Low und Low nach High) im Eingangsdatensignal DATAi bereit. Wenn das Anforderungssignal Ri nach einem Zustandsübergang des Eingangsdatensignals DATAi aktiv ist, dann werden alle nachfolgenden Zustandsübergänge ignoriert, bis ein Quittungssignal Ai empfangen wird. Das Datensignal DATAi ist nicht notwendigerweise ein 1-Bit Signal, sondern kann auch ein Multi-Bit Signal sein, das a – n parallele Bits enthält.
-
8 veranschaulicht ein Umsetzungsbeispiel des in 5 abgebildeten Anforderungsgenerators 35. In einem stabilen Zustand (initialisiert z. B. durch ein Signal Ai = 1) ist der Ausgang des OR-Gatters 353 aktiv (z. B. auf einem High-Pegel), und somit ist der Latch 355 transparent, während sich der Latch 356 im „Haltezustand” befindet (d. h. den Ausgang unabhängig vom Eingang beibehält). Als ein Resultat kann sich das Eingangsdatensignal DATAi durch den Latch 355 ausbreiten und ist direkt als Datensignal Di verfügbar. Die Ausgänge der beiden Latches 355 und 356 werden beide als Eingänge an das XOR-Gatter 354 geliefert. Im stabilen Zustand ist der Ausgang des XOR-Gatters 354 inaktiv (d. h. auf einem Low-Pegel). Wenn allerdings das Eingangsdatensignal DATAi seinen Pegel ändert (d. h. wenn einen Flanke im Signal DATAi auftritt), ändert sich der Ausgang des transparenten Latches 355 ebenfalls, während der Ausgang des undurchsichtigen Latches 356 beibehalten wird, und somit wird der Ausgang des XOR-Gatters 354 aktiv (d. h. er ändert sich auf einen High-Pegel).
-
Der aktive Ausgang des XOR-Gatters 354 triggert das Muller-C Gatter 351, und somit wird das Anforderungssignal Ri ebenfalls aktiv. Auf solche Weise erzeugt die Flanke im Eingangsdatensignal DATAi eine Anforderung. Das aktive Anforderungssignal Ri veranlasst (über das OR-Gatter 353) den Latch 355, seinen Zustand in einen Haltezustand zu ändern, während der Latch 356 transparent wird. Zu der Zeit sind die Ausgänge der beiden Latches – wieder – gleich, und somit kehrt der Ausgang des XOR-Gatters 354 in einen inaktiven Zustand (Low-Pegel) zurück. Wenn es das Quittungssignal Ai empfängt, wird das Muller-C Gatter 351 erneut getriggert (über den Inverter 352), und die Latches 355 und 356 ändern erneut ihren Zustand (Latch 355 wird transparent, und Latch 356 behält seinen Ausgang), weil das Quittungssignal Ai über das OR-Gatter 353 an die Latches übermittelt wird. An diesem Punkt ist der Anforderungsgenerator „frei”, um erneut das Datensignal DATAi zu überwachen und die nächste Anforderung nach Feststellen der nächsten Flanke im Datensignal DATAi zu erzeugen.
-
Es sei angemerkt, dass der Anforderungsgenerator 35 dazu konfiguriert ist, das Ausgangsdatensignal Di etwas früher als das dazugehörige Anforderungssignal Ri zu erzeugen, um es dem Arbiter zu ermöglichen, das Datensignal Di zuverlässig zu erfassen. Dieser Zeitunterschied ist durch die vom XOR-Gatter 354 und dem Muller-C Gatter 351 verursachte Ausbreitungsverzögerung bedingt.
-
Der in 9 veranschaulichte Arbiter 40 latcht die Anforderungssignale R0, R1 usw. und die Datensignale D0, D1 usw. im Mehrkanal-Latch 320. Der Latch ist transparent, wenn das Freigabesignal Low ist (EN = 0). In diesem Fall enthält der Ausgangsvektor iVALID die Anforderungssignale (d. h. iVALID = {R0, R1, ..., Rn}), und der Ausgangsvektor iDATA enthält die Datensignale (d. h. iDATA = {D0, D1, ..., Dn}). Als Reaktion auf das erste Anforderungssignal Ri, das aktiv wird, wird der Latch getriggert (Freigabesignal EN = 1), die Ausgangswerte (d. h. die Werte der Ausgangsvektoren iVALID und iDATA) werden „eingefroren”, und das globale Anforderungssignal REQ wird erzeugt. Der Latch 320 wird nicht abgeschaltet (d. h. transparent gesetzt), bis ein Quittungssignal ACK empfangen wird. Eine typische Signalsequenz (d. h. ein Anforderungs-Quittungs-Zyklus) wird nachstehend beschrieben, um die Funktion des Arbiters aus 9 zu veranschaulichen.
-
Nur zu Veranschaulichungszwecken wird angenommen, dass alle Anforderungs- und Quittungssignale Ri, Ai, REQ, ACK zu Anfang inaktiv sind (Ri = 0 und Ai = 0 für alle relevanten Werte von i, REQ = 0, ACK = 0). Weiterhin ist auch das Haltesignal HOLD (Ausgang des Muller-C Gatters 302) zu Anfang inaktiv (HOLD = 0), und somit ist das Latch-Array 320 transparent. Unter diesen Umständen sind die Werte der Eingangsdatensignale nicht relevant, der Ausgangsdatenvektor iVALID umfasst die aktuellen Werte der Eingangsdatensignale (d. h. iDATA = {D0, D1, ..., Dn}), was ein Resultat davon ist, dass das Latch-Array 320 transparent ist.
-
Für die weitere Erörterung wird angenommen, dass eines der Eingangssignaldaten und das dazugehörige Anforderungssignal aktiv werden (z. B. D0 = 1 und, sehr kurze Zeit später, R0 = 1). Als ein Resultat davon, dass das Latch-Array 320 transparent ist, werden die Werte an den Latch-Ausgang übermittelt, und somit werden iVALID(0) und iDATA(0) aktiv (iVALID(0) = R0 = 1 und iDATA(0) = D0 = 1). Dieses Resultat veranlasst den Ausgang des AND-Gatters X0, aktiv zu werden. Weil die Ausgänge der AND-Gatter X0, X1 usw. alle an das OR-Gatter 306 (als Eingänge) geliefert werden, wird der Ausgang RD des OR-Gatters 306 aktiv, wenn wenigstens eines der AND-Gatter ein aktives Anforderungssignal detektiert (RD ist die Abkürzung für „request detected”-Anforderung detektiert). Das heißt RD = 1, wenn (und nur wenn) wenigstens eines der Anforderungssignale Ri aktiv ist.
-
Wenn wenigstens eine Anforderung detektiert wird (RD = 1), dann schaltet das Muller-C Gatter 302 sein Ausgangssignal HOLD auf einen High-Pegel (HOLD = 1). Um eine definierte Verzögerungszeit TD später wird auch das verzögerte HOLD-Signal HOLDDEL aktiv (Verzögerungselement 303). Ebenfalls triggert (d. h. schließt) ein aktives HOLD-Signal den Latch mittels des OR-Gatters 304. Als Folge davon werden die Latch-Array-Ausgänge iVALID(0:n) und iDATA(0:n) „eingefroren”, und Änderungen an den Latch-Array-Eingängen haben keine Wirkung mehr auf die Ausgangsvektoren.
-
Einer der anderen Latch-Eingänge (d. h. Ri und/oder Di, mit i > 0 im vorliegenden Beispiel) könnte einen Zustandsübergang zu der Zeit „gesehen” haben, zu der das Latch-Array 320 getriggert worden ist. In diesem Fall sind die Latch-Array-Ausgänge möglicherweise metastabil geworden. Aus diesem Grund sollte nichts unternommen werden, bis sich diese möglicherweise metastabilen Latches wieder erholt haben. Eine definierte Erholungszeit wird vom Verzögerungselement 303 sichergestellt, so dass die Latches des Latch-Arrays 320 eine Zeit TD zur Verfügung haben, um sich von metastabilen Zuständen zu erholen.
-
Das verzögerte HOLD-Signal HOLDDEL wird dann (nachdem die Verzögerungszeit TD abgelaufen ist) als globales Anforderungssignal REQ ausgegeben. Zu der Zeit, zu der das globale Anforderungssignal aktiv wird, wird der Ausgang des AND-Gatters 305 ebenfalls aktiv, weil jetzt beide Signale HOLD und HOLDDEL aktiv sind. Als Folge davon empfangen alle Anforderer, für die ein aktives Anforderungssignal (im vorliegenden Beispiel nur R0 bzw. iVALID(0)) im Latch-Array „gefangen” worden ist, ein dazugehöriges aktives Quittungssignal (im vorliegenden Beispiel nur Signal A0) über die AND-Gatter Yi (i = 0, 1, ... n). Dies kann als selektive Quittung für alle Kanäle x, für die iVALID(x) aktiv ist, angesehen werden. Nach dem Empfang der (selektiven) Quittungssignale Ai werden die dazugehörigen Anforderer (im vorliegenden Beispiel der Anforderer 0) ihre Anforderungssignale Ri abschalten.
-
Wenn der FSM, der die Arbiter-Ausgangsvektoren iVALID(0:n) und iDATA(0:n) empfangen und verarbeitet hat, antwortet, indem er das globale Quittungssignal ACK aktiviert, dann deaktiviert das Muller-C Gatter 302 (das das ACK-Signal über den Inverter 301 empfängt) seinen Ausgang (HOLD = 0). Weiterhin werden die selektiven Quittungssignale Ai über das AND-Gatter 305 und die AND-Gatter Yi (i = 0, 1, ... n) deaktiviert. Eine Verzögerungszeit TD später wird auch das globale Anforderungssignal REQ (entspricht HOLDDEL) deaktiviert, was verursacht, dass das Latch-Array 320 erneut transparent wird (Freigabesignal EN wird 0 gesetzt über das OR-Gatter 304). Unter diesen Umständen ist der Arbiter im Leerlauf und bereit, weitere Anforderungen zu verarbeiten, die an irgendeinem Eingangskanal (von irgendeinem Anforderer) auftreten.
-
Obwohl verschiedene Ausführungsbeispiele der Erfindung offenbart worden sind, ergibt sich für Fachleute, dass verschiedene Änderungen und Modifikationen vorgenommen werden können, die einige der Vorteile der Erfindung erreichen werden, ohne damit vom Gedanken und Schutzbereich der Erfindung abzuweichen. Für Durchschnittsfachleute wird offensichtlich sein, dass andere Komponenten, die die gleichen Funktionen ausführen, in geeigneter Weise ausgetauscht werden können. Es soll erwähnt werden, dass Merkmale, die unter Bezugnahme auf eine spezielle Figur erklärt worden sind, mit Merkmalen aus anderen Figuren kombiniert werden können, auch dort, wo dies nicht ausdrücklich erwähnt worden ist. Weiterhin können die Verfahren der Erfindung entweder in reinen Software-Umsetzungsformen unter Verwendung der geeigneten Prozessorbefehle verwirklicht werden oder in hybriden Umsetzungsformen, die eine Kombination aus Hardware-Logik und Software-Logik nutzen, um die gleichen Resultate zu verwirklichen. Es ist beabsichtigt, dass solche Modifikationen des erfindungsgemäßen Konzepts durch die beigefügten Ansprüche abgedeckt sind.
