DE60011797T2

DE60011797T2 - Ausführung von mehreren fäden in einem parallelprozessor

Info

Publication number: DE60011797T2
Application number: DE60011797T
Authority: DE
Inventors: Debra Bernstein; F. Donald HOOPER; J. Matthew ADILETTA; Gilbert Wolrich; William Wheeler
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 1999-08-31
Filing date: 2000-08-17
Publication date: 2005-07-14
Anticipated expiration: 2020-08-18
Also published as: WO2001016718A1; CN1387641A; EP1221086B1; EP1221086A1; US20040054880A1; HK1049719A1; CN101221493B; US6668317B1; CN101221493A; CN100378655C; HK1049719B; CA2383384A1; DE60011797D1; US7191321B2; AU7061600A; ATE269988T1

Description

HINTERGRUND
Die vorliegende Erfindung betrifft Parallelprozessoren.
Parallelverarbeitung ist eine effiziente Form der Informationsverarbeitung von gleichzeitig ablaufenden Events in einem Rechenprozess. Die Parallelverarbeitung fordert die gleichzeitige Ausführung von vielen Programmen in einem Computer, im Gegensatz zur sequenziellen Verarbeitung. Im Zusammenhang mit einem Parallelprozessor beinhaltet Parallelität, dass gleichzeitig mehr als ein Vorgang abläuft. Im Gegensatz zu einem seriellen Paradigma, bei dem alle Tasks nacheinander in einer einzelnen Station oder in einer Pipelining-Maschine ausgeführt werden, bei der Tasks an spezialisierten Stationen ausgeführt werden, sind bei Parallelverarbeitung mehrere Stationen vorhanden, die jeweils alle Tasks ausführen können. Das heißt, im Allgemeinen arbeiten alle oder mehrere Stationen gleichzeitig und unabhängig an demselben oder an gemeinsamen Elementen eines Problems. Bestimmte Probleme sind für eine Lösung mittels Parallelverarbeitung geeignet.
So beinhalten Computerverarbeitungstypen einen einzelnen Anweisungsstrom, einen einzelnen Datenstrom, den konventionellen seriellen Von-Neumann-Computer mit einem einzelnen Anweisungsstrom. Ein zweiter Verarbeitungstyp ist SIMD (Prozess mit einem Anweisungsstrom und mehreren Datenströmen). Diese Verarbeitung kann mehrere Arithmetik-Logik-Prozessoren und einen einzigen Steuerprozessor haben. Alle Prozessoren führen Operationen an den Daten im Gleichschritt durch. Diese Maschinen werden vom Steuerprozessor synchronisiert. Ein dritter Typ ist MISD (Prozess mit mehreren Anweisungsströmen und einem einzigen Datenstrom). Diese Verarbeitung hat dieselben Datenstromflüsse durch eine lineare Array von Prozessoren, die unterschiedliche Anweisungsströme ausführen. Ein vierter ist MIMD (mehrere Anweisungsströme, mehrere Datenströme). Diese Verarbeitung läuft mit mehreren Prozessoren, die ihren Anweisungsstrom jeweils selbst ausführen, um einen den einzelnen Prozessoren zugeführten Datenstrom zu verarbeiten. MIMD-Prozessoren (mehrere Anweisungsströme, mehrere Datenströme) können mehrere Anweisungsverarbeitungseinheiten und somit mehrere Datenströme haben.
Die US-A-5 630 130 (Perotto et al) offenbart einen Multitasking-Controller mit einem Taskspeichermittel zum Speichern von bis zu N Tasks, die jeweils eine Folge von Anweisungen umfassen, einem Mikroprozessor, um durch Time-Sharing eine Mehrzahl solcher N Tasks zu verarbeiten, und einem Arbeitsspeicher zum Speichern von variablen Daten, die von dem genannten Mikroprozessor erzeugt und verwendet werden. Die Anordnung der US-A-5 630 130 kann keine Zuteilungsentscheidungen zwischen Tasks für Aktivierungsthreads treffen.
Byrd G.T. et al: „Multinational Processor Architectures", IEEE Spectrum, IEEE Inc. New York, US., Bd. 32, Nr. B. 1. August 1995 (1.8.1995), Seiten 38–46, XP000524855 ISSN: 0018-9235, ist eine Zusammenfassung von Multithread-Architekturen. Laut Byrd können Multithread-Architekturen als grob- oder feinkörnig klassifiziert werden. Beim grobkörnigen Ansatz läuft ein Thread über mehrere Zyklen oder mehr, bevor er umgeschaltet wird, im Allgemeinen aufgrund eines Vorgangs mit langer Latenz wie z.B. einer Speicheroperation, die nicht lokal erledigt werden kann. In einem feinkörnigen Ansatz werden Threads jedoch von Zyklus zu Zyklus umgeschaltet; dieses System erfordert mehr aktive Kontexte zum Maskieren von Vorgängen mit langer Latenz, aber es können auch jeweils mehrere Vorgänge mit langer Latenz gleichzeitig laufen (siehe S. 41, 5. Absatz). Spezifischer, laut Byrds können bei grobkörnigen Architekturen ungeladene Threads in verschiedenen Warteschlangen vorhanden sein, wie z.B. der Bereitschaftswarteschlange und der Suspendiert-Warteschlange. Intuitiv sollte die Umschaltung zwischen geladenen Warteschlangen lediglich das Ändern eines Kontextzeigers und das Vollendenlassen von laufenden Anweisungen erfordern (s. S. 42, mittlere Spalte, 1. Absatz). Byrd gibt an, dass bei feinkörniger Architektur ein Schlüssel zur Kontextumschaltung das Vorhandensein von genügend Registern ist, so dass ihre Kontexte nicht gespeichert und wieder abgerufen zu werden brauchen, wenn der Kontext umgeschaltet wird. Ein zweiter Schlüssel ist, dass, wenn ein Thread keine Anweisung mehr ausgeben kann, die Umschaltung auf einen anderen Thread nicht durch Warten auf die Vollendung aller laufenden Anweisungen verzögert wird (siehe S. 42, mittlere Spalte, 1. Absatz).
Byrd lehrt keinen Kontextzuteiler und schlägt auch keinen solchen vor, der als Reaktion auf externe Flags ermittelt, welcher aus einer Mehrzahl von Flags in der mikrogesteuerten Funktionsausführungseinheit für eine Promotion in einen Ausführungszustand ausführbar ist.
ZUSAMMENFASSUNG
Die Erfindung ist in den Ansprüchen definiert, auf die hiermit verwiesen wird. In einer Ausgestaltung der vorliegenden Erfindung beinhaltet eine mikrogesteuerte Funktionsausführungseinheit einen Steuerspeicher zum Speichern eines Mikroprogramms und einen Mikromaschinen-Controller zum Verwalten einer Mehrzahl von Mikroprogrammzählern. Die Einheit beinhaltet auch Decodierlogik zum Decodieren von Anweisungen und einen Kontext-Event-Zuteiler, der als Reaktion auf externe Flags ermittelt, welcher aus einer Mehrzahl von Threads, die in der mikrogesteuerten Funktionsausführungseinheit ausführbar sind, in einen Ausführungszustand promoviert werden soll.
Einer oder mehrere der folgenden Vorteile können von einem oder mehreren Aspekten der Erfindung erzielt werden.
Die Mikromaschine kann mehrere Hardware-Threads verarbeiten. Jede Mikromaschine verwaltet eine Mehrzahl von Programmzählern in Hardware und Zustände in Verbindung mit den Programmzählern. Es kann effektiv eine entsprechende Mehrzahl von Sätzen von Threads gleichzeitig auf einer Mikromaschine aktiv sein, während immer nur einer gerade tatsächlich arbeitet. Durch Hardware-Kontextumlagerung wird die Vollendung von Tasks synchronisiert. So könnten z.B. zwei Threads versuchen, auf dieselbe Gemeinschaftsressource zuzugreifen. Wenn eine Ressource eine angeforderte Task von einem der Mikromaschinen-Thread-Kontexten vollendet, dann sendet die Ressource einen Flag zurück, der die Vollendung eines Vorgangs signalisiert. Wenn die Mikromaschine den Flag erhält, kann sie bestimmen, welchen Thread sie einschaltet.
Mit Hilfe von Hardware-Multithreading kann ermöglicht werden, dass ein erster Thread auf einer Mikromaschine eine Transaktion wie z.B. einen Speicherzugriff einleitet. Wenn die Mikromaschine während des Speicherzugriffs nur einen einzigen Thread hatte, der arbeiten konnte, dann wäre diese Mikromaschine latent, bis Daten vom Speicher zurückgesendet werden. Durch Hardware-Kontextumlagerung in der Mikromaschine wird ermöglicht, dass andere Kontexte mit eindeutigen Programmzählern in derselben Mikromaschine ablaufen. So kann ein anderer Thread ablaufen, während der erste Thread wartet, bis gelesene Daten aus dem Speicher zurückkehren. Diese Merkmale können auf so viele Threads erweitert werden, wie gleichzeitig in einer Mikromaschine aktiv sind, um mehr Arbeit in einem Datenpfad zu erledigen.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
1 ist ein Blockdiagramm eines Kommunikationssystems, das mit einem Hardware-gestützten Multithread-Prozessor arbeitet;
2 ist ein ausführliches Blockdiagramm des Hardware-gestützten Multithread-Prozessors von 1;
3 ist ein Blockdiagramm einer Mikromaschinen-Funktionseinheit, die in dem Hardware-gestützten Multithread-Prozessor der 1 und 2 eingesetzt wird;
3A ist ein Blockdiagramm einer Pipeline in der Mikromaschine von 3;
3B ist ein Diagramm, das ein Format für eine Kontextschaltanweisung zeigt;
3C ist ein Blockdiagramm, das eine Universalregisteradressanordnung zeigt;
4 ist ein Blockdiagramm eines Speicher-Controllers für einen Betrieb mit größerer Bandbreite in dem Hardware-gestützten Multithread-Prozessor;
4A ist ein Ablaufdiagramm, das eine Zuteilungsrichtlinie in einem SDRAM-Controller von 4 repräsentiert;
4B ist ein Zeitsteuerdiagramm, das Vorteile der Optimierung des SDRAM-Controllers zeigt;
5 ist ein Blockdiagramm eines Speicher-Controllers für latenzbegrenzte Operationen, der in dem Hardware-gestützten Multithread-Prozessor verwendet wird;
5A ist ein Zeitsteuerdiagramm, das Vorteile des Optimierens des SRAM-Controllers zeigt;
6 ist ein Blockdiagramm einer Kommunikationsbusschnittstelle in dem Prozessor von 1.
BESCHREIBUNG
Architektur:
Gemäß 1 beinhaltet ein Kommunikationssystem 10 einen parallelen, Hardware-gestützten Multithread-Prozessor 12. Der Hardware-gestützte Multithread-Prozessor 12 ist mit einem Bus wie z.B. einem PCI-Bus 14, einem Speichersystem 16 und einem zweiten Bus 18 gekoppelt. Das System 10 ist besonders für Tasks nützlich, die in parallele Subtasks oder Funktionen gegliedert werden können. Insbesondere ist der Hardware-gestützte Multithread-Prozessor 12 für Tasks nützlich, die bandbreiten- anstatt latenzorientiert sind. Der Hardware-gestützte Multithread-Prozessor 12 hat mehrere Mikromaschinen 22, jeweils mit mehreren Hardwaregesteuerten Threads, die gleichzeitig aktiv sein und unabhängig an einer Task arbeiten können.
Der Hardware-gestützte Multithread-Prozessor 12 beinhaltet auch einen Zentralcontroller 20, der beim Laden von Microcode-Control für andere Ressourcen des Hardwaregestützten Multithread-Prozessors 12 assistiert und andere Universal-Computerfunktionen wie die Handhabung von Protokollen, Ausnahmen, zusätzliche Unterstützung für Paketverarbeitung ausführt, wobei die Mikromaschinen die Pakete für eine ausführlichere Verarbeitung wie beispielsweise in Grenzbedingungen weiterleiten. In einer Ausgestaltung ist der Prozessor 20 eine Architektur auf der Basis von Strong Arm^® (Arm ist ein Warenzeichen von ARM Limited, GB). Der Universal-Mikroprozessor 20 hat ein Betriebssystem. Durch das Betriebssystem kann der Prozessor 20 Funktionen zum Einwirken auf Mikromaschinen 22a–22f veranlassen. Der Prozessor 20 kann ein beliebiges unterstütztes Betriebssystem verwenden, aber es wird vorzugsweise ein Echtzeitbetriebssystem eingesetzt. Für den als Strong Arm Architektur implementierten Kernprozessor können Betriebssysteme wie MicrosoftNT Real-Time, VXWorks und μCUS, ein über das Internet erhältliches Freeware-Betriebssystem, verwendet werden.
Der Hardware-gestützte Multithread-Prozessor 12 beinhaltet auch eine Mehrzahl von Funktionsmikromaschinen 22a–22f. Funktionsmikromaschinen (Mikromaschinen) 22a–22f verwalten jeweils eine Mehrzahl von Programmzählern in Hardware sowie Zustände in Verbindung mit den Programmzählern. Effektiv kann eine entsprechende Mehrzahl von Sätzen von Threads gleichzeitig auf jeder der Mikromaschinen 22a–22f aktiv sein, während jeweils immer nur einer tatsächlich arbeitet.
In einer Ausgestaltung gibt es sechs Mikromaschinen 22a–22f wie gezeigt. Alle Mikromaschinen 22a–22f haben die Kapazität zur Verarbeitung von vier Hardware-Threads. Die sechs Mikromaschinen 22a–22f arbeiten mit gemeinsamen Betriebsmitteln wie dem Speichersystem 16 sowie den Busschnittstellen 24 und 28. Das Speichersystem 16 beinhaltet einen SDRAM-Controller 26a (Synchronous Dynamic Random Access Memory) und einen SRAM-Controller 26b (Static Random Access Memory). Der SDRAM-Speicher 16a und der SDRAM-Controller 26a werden gewöhnlich zum Verarbeiten großer Datenvolumen verwendet, z.B. zum Verarbeiten von Netzwerknutzdaten von Netzwerkpaketen. Der SRAM-Controller 26b und der SRAM-Speicher 16b werden in einer Vernetzungsimplementation für latenzarme Sofortzugriff-Tasks eingesetzt, z.B. zum Zugreifen auf Lookup-Tabellen, Speicher für den Kernprozessor 20 usw.
Die sechs Mikromaschinen 22a–22f greifen, je nach den Charakteristiken der Daten, entweder auf den SDRAM 16a oder den SRAM 16b zu. Somit werden die latenzarmen Daten niedriger Bandbreite im SRAM gespeichert und von dort abgerufen, während Daten mit höherer Bandbreite, für die Latenz nicht so wichtig ist, im SDRAM gespeichert und von dort abgerufen werden. Die Mikromaschinen 22a–22f können Speicherreferenzanweisungen entweder zum SDRAM-Controller 26a oder zum SRAM-Controller 16b ausführen.
Die Vorteile von Hardware-Multithreading können anhand von SRAM- oder SDRAM-Speicherzugriffen erläutert werden. So bewirkt beispielsweise ein von einem Thread 0 angeforderter SRAM-Zugriff von einer Mikromaschine, dass der SRAM-Controller 26b einen Zugriff auf den SRAM-Speicher 16b einleitet. Der SRAM-Controller steuert die Zuteilung für den SRAM-Bus, greift auf den SRAM 16b zu, ruft die Daten vom SRAM 16b ab und sendet die Daten zu einer anfordernden Mikromaschine 22a–22b zurück. Während eines SRAM-Zugriffs wäre die Mikromaschine, z.B. 22a, wenn sie nur einen einzigen Thread hätte, der arbeiten könnte, im Ruhezustand, bis Daten vom SRAM zurückgegeben werden. Mittels Hardware-Kontextumlagerung in den einzelnen Mikromaschinen 22a–22f kann ermöglicht werden, dass andere Kontexte mit eindeutigen Programmzählern in derselben Mikromaschine ablaufen. Somit kann ein anderer Thread, z.B. Thread_1, ablaufen, während der erste Thread, z.B. Thread_0, auf die Rückkehr der Lesedaten wartet. Während der Ausführung kann Thread_1 auf den SDRAM-Speicher 16a zugreifen. Während Thread_1 an der SDRAM-Einheit und Thread_0 an der SRAM-Einheit arbeitet, kann jetzt ein neuer Thread, z.B. Thread_2, in der Mikromaschine 22a arbeiten. Thread_2 kann für eine bestimmte Zeit arbeiten, bis er auf Speicher zugreifen oder eine andere Operation mit langer Latenz durchführen muss, wie z.B. die Durchführung eines Zugriffs auf eine Busschnittstelle. Somit kann der Prozessor 12 gleichzeitig einen Busvorgang, einen SRAM-Vorgang und einen SDRAM-Vorgang durchführen, die alle von einer Mikromaschine 22a vollendet oder bearbeitet werden, und noch einen Thread verfügbar haben, um mehr Arbeit im Datenpfad zu verrichten.
Hardware-Kontextumlagerung synchronisiert auch die Vollendung von Tasks. So könnten beispielsweise zwei Threads auf dieselbe Gemeinschaftsressource treffen, z.B. auf SRAM. Jede dieser separaten Funktionseinheiten, z.B. die FBUS-Schnittstelle 28, der SRAM-Controller 26a und der SDRAM-Controller 26b, sendet nach Vollendung einer angeforderten Task von einem der Mikromaschinen-Thread-Kontexten einen Flag zurück, der die Vollendung eines Vorgangs anzeigt. Wenn die Mikromaschine den Flag erhält, kann sie bestimmen, welchen Thread sie einschaltet.
Ein Beispiel für den Einsatz eines Hardware-gestützten Multithread-Prozessors 12 ist als Netzwerkprozessor. Als Netzwerkprozessor hat der Hardware-gestützte Multithread-Prozessor 12 Verbindung mit Netzgeräten wie z.B. einem Media-Access-Controller, z.B. einem 10/100BaseT Octal MAC 13a oder einem Gigabit-Ethernet-Gerät 13b. Im Allgemeinen kann der Hardware-gestützte Multithread-Prozessor 12 als Netzwerkprozessor Verbindung mit jedem beliebigen Kommunikationsgerät- oder Schnittstellentyp haben, der große Datenmengen empfängt/sendet. Das in einer vernetzten Anwendung arbeitende Kommunikationssystem 10 könnte eine Mehrzahl von Netzwerkpaketen von den Geräten 13a, 13b empfangen und diese Pakete auf parallele Weise verarbeiten. Mit dem Hardware-gestützten Multithread-Prozessor 12 kann jedes Netzwerkpaket unabhängig verarbeitet werden.
Ein weiteres Einsatzbeispiel für den Prozessor 12 ist als Druckmaschine für einen Postscript-Prozessor oder als Prozessor für ein Speichersubsystem, d.h. RAID-Plattenspeicherung. Ein weiterer Einsatzzweck ist als Anpassungsmaschine. So erfordert beispielsweise in der Wertpapierbranche der aufgekommene elektronische Handel den Einsatz von elektronischen Anpassungsmaschinen, um Käufer und Verkäufer für Aufträge zusammenzubringen. Diese und andere parallele Typen von Tasks können mit dem System 10 ausgeführt werden.
Der Prozessor 12 beinhaltet eine Busschnittstelle 28, die den Prozessor mit dem zweiten Bus 18 verbindet. Die Busschnittstelle 28 in einer Ausgestaltung verbindet den Prozessor 12 mit dem so genannten FBUS 18 (FIFO-Bus). Die FBUS-Schnittstelle 28 ist für die Steuerung und Verbindung des Prozessors 12 mit dem FBUS 18 verantwortlich. Der FBUS 18 ist ein 64 Bit breiter FIFO Bus für die Verbindung mit Media-Access-Controllern (MAC).
Der Prozessor 12 beinhaltet eine zweite Schnittstelle, z.B. eine PCI-Busschnittstelle 24, die andere auf dem PCI-Bus 14 befindliche Systemkomponenten mit dem Prozessor 12 verbindet. Die PCI-Busschnittstelle 24 bietet einen schnellen Datenpfad 24a zum Speicher 16, z.B. dem SDRAM-Speicher 16a. Dieser Datenpfad ermöglicht einen schnellen Transfer vom SDRAM 16a durch den PCI-Bus 14 per Direct Memory Access (DMA). Der Hardware-gestützte Multithread-Prozessor 12 unterstützt Bildübertragungen. Der Hardwaregestützte Multithread-Prozessor 12 kann eine Mehrzahl von DMA-Kanälen verwenden. Wenn also ein Ziel eines DMA-Transfers belegt ist, dann kann ein anderer DMA-Kanal den PCI-Bus zum Weiterleiten von Informationen zu einem anderen Ziel übernehmen, um den Prozessor 12 effizient zu halten. Darüber hinaus unterstützt die PCI-Busschnittstelle 24 Ziel- und Master-Vorgänge. Bei Zielvorgängen handelt es sich um Operationen, bei denen Slave-Geräte auf dem Bus 14 auf SDRAMs über Lese- und Schreibvorgänge zugreifen, die wie Slave-zu-Ziel-Operationen behandelt werden. Bei Master-Operationen sendet der Prozessorkern 20 Daten direkt zur Busschnittstelle 24 oder empfängt sie direkt davon.
Jede der Funktionseinheiten ist mit einem oder mehreren internen Bussen verbunden. Wie nachfolgend beschrieben, sind die internen Busse duale 32-Bit-Busse (d.h. ein Bus zum Lesen und einer zum Schreiben). Der Hardware-gestützte Multithread-Prozessor 12 ist auch so konstruiert, dass die Summe der Bandbreiten der internen Busse im Prozessor 12 größer ist als die Bandbreite von mit dem Prozessor 12 verbundenen externen Bussen. Der Prozessor 12 beinhaltet einen internen Kernprozessorbus 32, z.B. einen ASB-Bus (Advanced System Bus), der den Prozessorkern 20 mit dem Speicher-Controller 26a, 26c sowie mit einem nachfolgend beschriebenen ASB-Translator 30 verbindet. Der ASB-Bus ist eine Teilmenge des so genannten AMBA-Busses, der mit dem Strong Arm Prozessorkern verwendet wird. Der Prozessor 12 beinhaltet auch einen privaten Bus 34, der die Mikromaschineneinheiten mit dem SRAM-Controller 26b, dem ASB-Translator 30 und der FBUS-Schnittstelle 28 verbindet. Ein Speicherbus 38 verbindet den Speicher-Controller 26a, 26b mit den Busschnittstellen 24 und 28 sowie dem Speichersystem 16, einschließlich dem Flashrom 16c, der für Boot-Vorgänge usw. verwendet wird.
Mit Bezug auf 2, jede der Mikromaschinen 22a–22f beinhaltet einen Zuteiler, der Flags untersucht, um die verfügbaren Threads zu ermitteln, an denen gearbeitet werden kann. Jeder Thread von jeder der Mikromaschinen 22a-22f kann auf den SDRAM-Controller 26a, den SDRAM-Controller 26b oder die FBUS-Schnittstelle 28 zugreifen. Die Speicher-Controller 26a und 26b beinhalten jeweils eine Mehrzahl von Warteschlangen zum Speichern von ausstehenden Speicherreferenzanforderungen. Die Warteschlangen können entweder eine Reihenfolge von Speicherreferenzen führen oder Speicherreferenzen so arrangieren, dass die Speicherbandbreite optimiert wird. Wenn beispielsweise ein Thread_0 keine Abhängigkeiten und keine Beziehung zu einem Thread_1 hat, dann gibt es keinen Grund, warum Thread_1 und 0 nicht ihre Speicherreferenzen zur SRAM-Einheit außer der Reihe vollenden könnten. Die Mikromaschinen 22a–22f geben Speicherreferenzanforderungen an die Speicher-Controller 26a und 26b aus. Die Mikromaschinen 22a–22f fluten die Speichersubsysteme 26a und 26b mit so vielen Speicherreferenzoperationen, dass die Speichersubsysteme 26a und 26b für den Betrieb des Prozessors 12 zu einem Engpass werden.
Wenn das Speichersubsystem 16 mit Speicheranforderungen geflutet wird, die von ihrer Natur aus unabhängig sind, dann kann der Prozessor 12 Speicherreferenzen sortieren. Durch Sortieren von Speicherreferenzen wird die erzielbare Speicherbandbreite verbessert. Speicherreferenzsortierung reduziert, wie nachfolgend beschrieben, Totzeit oder eine Blase, die mit Zugriffen auf SRAM auftritt. Mit Speicherreferenzen auf SRAM wird durch Umschalten der aktuellen Richtung auf Signalleitungen zwischen Lese- und Schreibvorgängen eine Blase oder eine Totzeit erzeugt, während der gewartet wird, bis sich Strom auf Leitern einschwingt, die den SRAM 16b mit dem SRAM-Controller 26b verbinden.
Das heißt, die Treiber, die Strom auf dem Bus treiben, müssen sich einschwingen, bevor sie ihre Zustände ändern. So können wiederholte Zyklen eines Lesevorgangs, gefolgt von einem Schreibvorgang, die Spitzenbandbreite senken. Speicherreferenzsortierung erlaubt es dem Prozessor 12, Referenzen auf Speicher so zu organisieren, dass auf lange Folgen von Lesevorgängen lange Folgen von Schreibvorgängen folgen können. Damit kann die Totzeit in der Pipeline minimiert werden, um effektiv näher an die maximale verfügbare Bandbreite heranzukommen. Referenzsortierung hilft beim Verwalten paralleler Hardware-Kontextthreads. Am SDRAM ermöglicht Referenzsortierung das Verbergen von Vorladungen von einer Bank zu einer anderen Bank. Spezifisch ausgedrückt, wenn das Speichersystem 16b in eine ungeradzahlige Bank und eine geradzahlige Bank organisiert ist, während der Prozessor an der ungeradzahligen Bank arbeitet, dann kann der Speicher-Controller mit dem Vorladen der geradzahligen Bank beginnen. Ein Vorladen ist dann möglich, wenn Speicherreferenzen zwischen ungeradzahligen und geradzahligen Banken alternieren. Indem Speicherreferenzen so geordnet werden, dass sie zwischen Zugriffen auf entgegengesetzte Bänke alternieren, verbessert der Prozessor 12 die SDRAM-Bandbreite. Darüber hinaus können weitere Optimierungen verwendet werden. So können z.B. Mischoptimierungen, bei denen Operationen, die gemischt werden können, vor einem Speicherzugriff gemischt werden, Offene-Seiten-Optimierungen, bei denen aufgrund einer Untersuchung von Adressen eine offene Speicherseite nicht neu geöffnet wird, Verkettung wie nachfolgend beschrieben und Auffrischmechanismen verwendet werden.
Die FBUS-Schnittstelle 28 unterstützt Sende- und Empfangsflags für jeden Port, den ein MAC-Gerät unterstützt, zusammen mit einem Interrupt-Flag, das anzeigt, wenn ein Service gerechtfertigt ist. Die FBUS-Schnittstelle 28 beinhaltet auch einen Controller 28a, der eine Kopfzeilenverarbeitung an eingehenden Paketen vom FBUS 18 durchführt. Der Controller 28a extrahiert die Paketkopfzeilen und führt einen mikroprogrammierbaren hashcodierten Quelle/Ziel/Protokoll-Lookup-Vorgang (wird für Adressglättung verwendet) im SRAM durch. Wenn sich der Hash-Code nicht erfolgreich auflöst, dann wird die Paketkopfzeile zum Prozessorkern 20 zur Weiterverarbeitung gesendet. Die FBUS-Schnittstelle 28 unterstützt die folgenden internen Datentransaktionen:
Der FBUS 18 ist ein standardmäßiger Industriebus und beinhaltet einen Datenbus, z.B. 64 Bit breit, und Seitenbandsteuerung für Adress- und Lese-/Schreibsteuerung. Die FBUS-Schnittstelle 28 bietet die Möglichkeit, große Datenmengen über eine Reihe von Ein- und Ausgabe-FIFOs 29a-29b einzugeben. Von den FIFOs 29a–29b rufen die Mikromaschinen 22a–22f Daten vom SDRRM-Controller 26a ab oder weisen ihn an, Daten von einem Empfangs-FIFO, in dem Daten von einem Gerät auf dem Bus 18 gekommen sind, zur FBUS-Schnittstelle 28 zu verschieben. Die Daten können durch den Speicher-Controller 26a über einen Direct-Memory-Access zum SDRAM-Speicher 16a gesendet werden. Ebenso können die Mikromaschinen Daten vom SDRAM 26a zur Schnittstelle 28, zum FBUS 18, über die FBUS-Schnittstelle 28 übertragen.
Datenfunktionen werden unter den Mikromaschinen verteilt. Die Konnektivität zu SRAM 26a, SDRAM 26b und FBUS 28 ist über Befehlsanforderungen gegeben. Eine Befehlsanforderung kann eine Speicheranforderung oder eine FBUS-Anforderung sein. So kann eine Speicheranforderung beispielsweise Daten von einem Register in einer Mikromaschine 22a zu einer Gemeinschaftsressource senden, z.B. einer SDRAM-Stelle, einer SRAM-Stelle, zu einem Flash-Speicher oder zu einer MAC-Adresse. Die Befehle werden zu den einzelnen Funktionseinheiten und zu den Gemeinschaftsressourcen gesendet. In den Gemeinschaftsressourcen ist jedoch keine lokale Pufferung der Daten nötig, sondern die Gemeinschaftsressourcen greifen auf verteilte Daten in den Mikromaschinen zu. Dadurch haben die Mikromaschinen 22a–22f lokal Zugang zu Daten, ohne dass Buszugriffsberechtigungen zugeteilt werden müssen oder die Gefahr einer Konkurrenz auf dem Bus gegeben wäre. Mit dieser Funktion gibt es einen 0-Zyklus-Aufenthalt zum Warten auf Daten innerhalb der Mikromaschinen 22a–22f.
Die Datenbusse, z.B. ASB-Bus 30, SRAM-Bus 34 und SDRAM-Bus 38, die diese Gemeinschaftsressourcen verbinden, z.B. Speicher-Controller 26a und 26b, haben eine ausreichende Bandbreite, so dass es keine internen Engpässe gibt. Somit hat der Prozessor 12 zur Vermeidung von Engpässen eine Bandbreitenanforderung, bei der jede der Funktionseinheiten wenigstens das Zweifache der maximalen Bandbreite der internen Busse erhält. Zum Beispiel, der SDRAM kann einen 64 Bit breiten Bus mit 83 MHz betreiben. Der SRAM-Datenbus könnte separate Lese- und Schreibbusse haben, z.B. einen Lesebus von 32 Bit Breite mit 166 MHz und einen Schreibbus von 32 Bit Breite mit 166 MHz. Das heißt im wesentlichen, dass 64 Bit mit 166 MHz laufen, was effektiv das Zweifache der Bandbreite des SDRAM ist.
Der Kernprozessor 20 kann ebenfalls auf die Gemeinschaftsressourcen zugreifen. Der Kernprozessor 20 hat eine Direktkommunikation mit dem SDRAM-Controller 26a, der Busschnittstelle 24 und dem SRAM-Controller 26b über den Bus 32. Zum Zugreifen auf die Mikromaschinen 22a–22f und Transferregister in beliebigen der Mikromaschinen 22a–22f greift der Kernprozessor 20 jedoch über den ASB-Translator 30 über den Bus 34 auf die Mikromaschinen 22a–22f zu. Der ASB-Translator 30 kann sich physisch in der Busschnittstelle 28 befinden, ist aber logisch getrennt. Der ASB-Translator 30 führt eine Adressumsetzung zwischen Transferregisterstellen der FBUS-Mikromaschinen und Kernprozessoradressen (d.h. ASB-Bus) durch, so dass der Kernprozessor 20 auf Register zugreifen kann, die zu den Mikromaschinen 22a–22c gehören.
Mikromaschinen 22 können zwar den Registersatz zum Austauschen von Daten wie nachfolgend beschrieben verwenden, aber es ist auch ein Notizblockspeicher 27 vorgesehen, damit Mikromaschinen Daten auf den Speicher ausschreiben können, damit sie von anderen Mikromaschinen gelesen werden. Der Notizblockspeicher 27 ist mit dem Bus 34 gekoppelt.
Der Prozessorkern 20 beinhaltet einen RISC-Kern 50, der in einer fünfstufigen Pipeline implementiert ist, die eine Ein-Zyklus-Verschiebung von einem Operanden oder zwei Operanden in einem einzigen Zyklus durchführt und Multiplikationssupport sowie 32-Bit-Barrel-Shift-Support bietet. Dieser RISC-Kern 50 ist eine standardmäßige Strong Arm^® Architektur, ist aber aus Leistungsgründen mit einer fünfstufigen Pipeline ausgeführt. Der Prozessorkern 20 beinhaltet auch einen 16-KB-Befehlscache 52, einen 8-KB-Datencache 64 und einen Prefetch-Stream-Puffer 56. Der Kernprozessor 20 führt arithmetische Vorgänge parallel zu Speicherschreib- und Anweisungsabrufvorgängen durch. Der Kernprozessor 20 hat über den ARM-definierten ASB-Bus Verbindung mit anderen Funktionseinheiten. Der ASB-Bus ist ein bidirektionaler 32-Bit-Bus 32.
Mikromaschinen
3 zeigt ein Beispiel für eine der Mikromaschinen 22a–22f, z.B. Mikromaschine 22f. Die Mikromaschine hat einen Steuerspeicher 70, der in einer Implementation einen RAM von hier 1024 Wörtern von je 32 Bit beinhaltet. Der RAM speichert ein Mikroprogramm. Das Mikroprogramm kann vom Kernprozessor 20 geladen werden. Die Mikromaschine 22f beinhaltet auch Controller-Logik 72. Die Controller-Logik beinhaltet einen Anweisungsdecoder 73 sowie Programmzähler(PC) Einheiten 72a–72d. Die vier Mikroprogrammzähler 72a-72d sind in Hardware ausgeführt. Die Mikromaschine 22f hat auch Kontextevent-Umschaltlogik 74. Kontexteventlogik 74 empfängt Meldungen (z.B. SEQ # EVENT RESPONSE; FBI EVENT RESPONSE; SRAM EVENT RESPONSE; SDRAM EVENT RESPONSE; und ASB EVENT RESPONSE) von jeder der Gemeinschaftsressourcen, z.B. SRAM 26a, SDRAM 26b oder Prozessorkern 20, Steuer- und Statusregister usw. Diese Meldungen geben Informationen darüber, ob eine angeforderte Funktion vollendet wurde. Je nach dem, ob eine von einem Thread angeforderte Funktion vollendet und die Vollendung signalisiert ist, muss der Thread auf dieses Vollendungssignal warten, und wenn der Thread für den Betrieb freigegeben ist, dann wird er auf eine Verfügbarer- Thread-Liste (nicht dargestellt) gesetzt. Die Mikromaschine 22f kann maximal z.B. 4 Threads zur Verfügung haben.
Zusätzlich zu Event-Signalen, die lokal zu einem laufenden Thread sind, verwenden die Mikromaschinen 22 Signalisierungszustände, die global sind. Beim Signalisieren von Zuständen kann ein laufender Thread einen Signalzustand zu allen Mikromaschinen 22 rundsenden. Nach dem Empfang eines Anforderung-verfügbar-Signals können beliebige und alle Threads in den Mikromaschinen an diesen Signalisierungszuständen verzweigen. Anhand dieser Signalisierungszustände kann die Verfügbarkeit einer Ressource oder die Fälligkeit einer Ressource für einen Service ermittelt werden.
Die Kontexteventlogik 74 hat eine Zuteilung für die vier (4) Threads. In einer Ausgestaltung erfolgt die Zuteilung auf zyklische Weise. Es können auch andere Techniken zum Einsatz kommen, wie z.B. die Einreihung in eine Prioritätswarteschlange oder eine Gewichtete-Fairness-Warteschlange. Die Mikromaschine 22f beinhaltet auch einen Ausführungsbox- (EBOX) Datenpfad 76, der eine Arithmetik-Logik-Einheit 76a sowie einen Universalregistersatz 76b beinhaltet. Die Arithmetik-Logik-Einheit 76a führt Rechen- und Logikfunktionen sowie Verschiebungsfunktionen durch. Der Registersatz 76b hat eine relativ große Zahl von Universalregistern. Wie in 3B illustriert, gibt es in dieser Implementation 64 Universalregister in einer ersten Bank, Bank A, und 64 in einer zweiten Bank, Bank B. Die Universalregister haben eine Fensterstruktur, wie nachfolgend beschrieben wird, so dass sie relativ und absolut adressierbar sind.
Die Mikromaschine 22f beinhaltet auch einen Schreibtransferregisterstapel 78 und einen Lesetransferstapel 80. Auch diese Register haben eine Fensterstruktur, so dass sie relativ und absolut adressierbar sind. Der Schreibtransferregisterstapel 78 ist dort, wo sich Daten zu einer Ressource befinden. Ebenso ist der Leseregisterstapel 80 für die Rückgabe von Daten von einer Gemeinschaftsressource. Im Anschluss an die oder gleichzeitig mit der Ankunft von Daten wird ein Event-Signal von der jeweiligen Gemeinschaftsressource, z.B. SRAM-Controller 26a, SDRAM-Controller 26b oder Kernprozessor 20, zum Kontexteventzuteiler 74 gesendet, der dann den Thread darüber in Kenntnis setzt, dass die Daten zur Verfügung stehen oder gesendet wurden. Beide Transferregisterbänke 78 und 80 sind durch einen Datenpfad mit der Ausführungsbox (EBOX) 76 verbunden. In einer Implementation hat das Lesetransferregister 64 Register und das Schreibtransferregister hat 64 Register.
Wie in 3A gezeigt, verwaltet der Mikromaschinen-Datenpfad eine 5-stufige Mikropipeline 82. Diese Pipeline beinhaltet Nachschlagen von Mikrobefehlswörtern 82a, Bilden der Registerdateiadressen 82b, Lesen von Operanden von der Registerdatei 82c, ALU, Verschiebe- oder Vergleichsoperationen 82d sowie Zurückschreiben von Ergebnissen auf Register 82e. Durch die Bereitstellung einer Writeback-Datenumgehung in die ALU/Schieber-Einheiten und indem angenommen wird, dass die Register als Registerdatei (und nicht als RAM) implementiert werden, kann die Mikromaschine die Registerdatei gleichzeitig lesen und beschreiben, so dass der Schreibvorgang vollkommen verborgen wird.
Die SDRAM-Schnittstelle 26a sendet ein Signal über Lesevorgänge zurück zur anfordernden Mikromaschine, das anzeigt, ob ein Paritätsfehler an der Leseanforderung aufgetreten ist. Der Mikromaschinen-Microcode prüft den SDRAM-Leseparität-Flag, wenn die Mikromaschine Rückgabedaten verwendet. Nach dem Prüfen des Flags wird dieser, wenn er gesetzt ist, durch Verzweigen darauf entfernt. Der Paritätsflag wird nur dann gesendet, wenn der SDRAM zum Prüfen aktiviert und der SDRAM paritätsgeschützt ist. Die Mikromaschinen und die PCI-Einheit sind die einzigen Requestoren, die über Paritätsfehler in Kenntnis gesetzt werden. Wenn also der Prozessorkern 20 oder der FIFO Paritätsschutz benötigt, dann assistiert eine Mikromaschine bei der Anforderung. Die Mikromaschinen 22a-22f unterstützen konditionelle Verzweigungen. Die ungünstigste konditionelle Verzweigungslatenz (ohne Jumps) tritt dann auf, wenn die Verzweigungsentscheidung die Folge von Bedingungscodes ist, die von der vorherigen Mikrosteuerungsanweisung gesetzt wurden. Die Latenz ist nachfolgend in Tabelle 1 dargestellt:
Wie in Tabelle 1 gezeigt, werden die Konditionscodes von n1 erst bei Zyklus 4 gesetzt, und die Verzweigungsentscheidung kann getroffen werden (die in diesem Fall bewirkt, dass der Verzweigungspfad in Zyklus 5 nachgeschlagen wird). Die Mikromaschine verursacht einen 2-Zyklus-Verzweigungslatenz-Mehraufwand, weil sie Vorgänge n2 und n3 (die beiden Mikrowörter direkt hinter der Verzweigung) in der Pipe abbrechen muss, bevor der Verzweigungspfad damit beginnt, die Pipe mit Operation b1 zu füllen. Erfolgt die Verzweigung nicht, dann werden keine Mikrowörter abgebrochen und die Ausführung wird normal fortgesetzt. Die Mikromaschinen haben mehrere Mechanismen, um die effektive Verzweigungslatenz zu reduzieren oder zu eliminieren.
Die Mikromaschinen unterstützen verschobene Verzweigungen. Eine Verschiebung von Verzweigungen ist dann gegeben, wenn es eine Mikromaschine zulässt, dass 1 oder 2 Mikrowörter nach der Verzweigung auftreten, bevor die Verzweigung wirksam wird (d.h. der Effekt der Verzweigung wird zeitlich „verschoben"). Wenn also gefunden wird, dass nützliche Arbeit die verschwendeten Zyklen nach dem Verzweigungsmikrowort füllt, dann kann die Verzweigungslatenz verborgen werden. Eine um 1 Zyklus verschobene Verzweigung ist unterhalb der Stelle zu sehen, wo n2 nach cb, aber vor b1 ablaufen kann:
Eine um 2 Zyklen verschobene Verzweigung wird nachfolgend dargestellt, wo n2 und n3 vor dem Auftreten der Verzweigung zu b1 fertig werden können. Man beachte, dass eine um 2 Zyklen verschobene Verzweigung nur dann zulässig ist, wenn die Bedingungscodes an dem Mikrowort vor der Verzweigung gesetzt sind.
Die Mikromaschinen unterstützen auch Bedingungscode-Beurteilung. Wenn die Bedingungscodes, an denen eine Verzweigungsentscheidung getroffen wird, 2 oder mehr Mikrowörter vor der Verzweigung gesetzt werden, dann kann 1 Zyklus der Verzweigungslatenz eliminiert werden, weil die Verzweigungsentscheidung 1 Zyklus früher getroffen werden kann:
In diesem Beispiel setzt n1 die Bedingungscodes und n2 setzt die Bedingungscodes nicht. Daher kann die Verzweigungsentscheidung in Zyklus 4 (anstatt 5) getroffen werden, um 1 Zyklus Verzweigungslatenz zu eliminieren. In dem Beispiel unten wird die Verzweigungsverschiebung von 1 Zyklus und das frühzeitige Setzen von Bedingungscodes kombiniert, um die Verzweigungslatenz völlig zu verbergen: Bedingungscodes (cc's) werden 2 Zyklen vor einer um 1 Zyklus verzögerten Verzweigung gesetzt:
In dem Fall, in dem die Bedingungscodes nicht frühzeitig gesetzt werden können (d.h. sie werden in dem Mikrowort vor der Verzweigung gesetzt), unterstützt die Mikromaschine eine Verzweigungsschätzung, die versucht, den verbleibenden 1 Zyklus von exponierter Verzweigungslatenz zu reduzieren. Durch „Schätzen" des Verzweigungspfades oder des Folgepfades liest der Mikrosequencer den geschätzten Pfad einen Zyklus bevor er definitiv weiß, welchen Pfad er abarbeitet. Wenn er richtig schätzt, dann wird 1 Zyklus Verzweigungslatenz wie nachfolgend gezeigt eliminiert: Schätzung: Verzweigung genommen / Verzweigung wird genommen
Wenn der Mikrocode eine genommene Verzweigung falsch schätzt, dann verschwendet die Mikromaschine nur 1 Zyklus: Schätzung: Verzweigung genommen / Verzweigung wird NICHT genommen
Der Latenzmehraufwand wird jedoch anders verteilt, wenn der Mikrocode schätzt, dass eine Verzweigung nicht genommen wird:
Für ein Schätzung Verzweigung NICHT genommen / Verzweigung wird NICHT genommen, gibt es keine verschwendeten Zyklen, wie nachfolgend gezeigt wird.
Für eine Schätzung Verzweigung NICHT genommen / Verzweigung wird genommen gibt es jedoch 2 verschwendete Zyklen.
Die Mikromaschine kann Verzweigungsschätzung mit einer 1-Zyklus-Verzweigungsverschiebung kombinieren, um das Ergebnis noch weiter zu verbessern. Für "Schätzung: Verzweigung genommen mit um 1 Zyklus verschobener Verzweigung / Verzweigung wird genommen" sieht das Ergebnis so aus:
In dem obigen Fall werden die beiden Zyklen an Verzweigungslatenz durch die Ausführung von n2 und durch korrektes Schätzen der Verzweigungsrichtung verborgen. Wenn Mikrocode falsch schätzt, dann bleibt 1 Zyklus Verzweigungslatenz wie nachfolgend gezeigt exponiert:
Schätzung: Verzweigung mit um 1 Zyklus verschobener Verzweigung genommen / Verzweigung NICHT genommen
Wenn Mikrocode ein "Verzweigung NICHT genommen" richtig schätzt, dann fließt die Pipeline sequentiell im normalen ungestörten Fall. Wenn Mikrocode "Verzweigung NICHT genommen" falsch schätzt, dann exponiert die Mikromaschine wieder 1 Zyklus an unproduktiver Ausführung, wie nachfolgend gezeigt wird:
Schätzung: Verzweigung NICHT genommen / Verzweigung wird genommen
Im Falle einer Jump-Anweisung werden 3 zusätzliche Latenzzyklen verursacht, weil die Verzweigungsadresse erst am Ende des Zyklus bekannt ist, in dem der Jump in der ALU-Stufe ist:
Kontextschalter:
3B zeigt ein Format von einer Kontextschaltanweisung. Ein Kontextschalter ist eine spezielle Form einer Verzweigung, die bewirkt, dass ein anderer Kontext (und zugehöriger PC) gewählt wird. Auch Kontextschaltung verursacht ein gewisses Maß an Verzweigungslatenz. Man betrachte den folgenden Kontextschalter:
In einem Kontextschalter wird das Mikrowort „br" abgebrochen, um die Steuer- und Timing-Komplexitäten zu vermeiden, die durch Speichern des richtigen alten Kontext-PC entstehen könnten.
Konditionelle Verzweigungen, die an ALU-Bedingungscodes arbeiten, die vor der Verzweigung am Mikrowort gesetzt werden, können Verzweigungsverschiebungen von 0, 1 oder 2 Zyklen wählen. Bedingungscodes, die 2 oder mehr Mikroworte vor der daran tätigen konditionellen Verzweigung gesetzt werden, können eine Verzweigungsverschiebung von 0 oder 1 Zyklus wählen. Alle anderen Verzweigungen (inkl. Kontextneuzuteilung) können eine Verzweigungsverschiebung von 0 oder 1 Zyklus wählen. Die Architektur könnte so ausgelegt werden, dass sie ein Kontextzuteilungsmikrowort in einem Verzweigungsverschiebungsfenster eines vorherigen Verzweigungs-, Jump- oder Kontextzuteilungsmikrowortes zu einer illegalen Option macht. Das heißt, in einigen Ausgestaltungen würde eine Kontextumschaltung während eines Verzweigungsübergangs in der Pipeline nicht zugelassen, weil dies, wie erwähnt, das Speichern des alten Kontext-PC zu sehr verkomplizieren würde. Die Architektur könnte auch so ausgelegt werden, dass sie die Verzweigung in dem Verzweigungsverschiebungsfenster eines vorherigen Verzweigungs-, Jump- oder Kontextzuteilungsmikrowortes illegal macht, um kompliziertes und möglicherweise unvorhersehbares Verzweigungsverhalten zu vermeiden.
Jede Mikromaschine 22a–22f unterstützt eine Multithread-Ausführung von vier Kontexten. Ein Grund hierfür ist zuzulassen, dass ein Thread mit der Ausführung beginnt, unmittelbar nachdem ein anderer Thread eine Speicherreferenz ausgibt, und warten muss, bis diese Referenz beendet ist, bevor weitere Arbeiten durchgeführt werden. Dieses Verhalten ist kritisch, um die Hardware-Ausführung der Mikromaschinen effizient zu halten, weil die Speicherlatenz signifikant ist. Oder anders ausgedrückt, wenn nur eine einzige Thread-Ausführung unterstützt würde, dann würden die Mikromaschinen für eine signifikante Anzahl von Zyklen untätig sitzen und auf die Rückkehr von Referenzen warten und dadurch den Rechendurchsatz insgesamt reduzieren. Eine Multithread-Ausführung lässt es zu, dass Mikromaschinen Speicherlatenz verbergen, indem sie nützliche unabhängige Arbeit über mehrere Threads durchführen. Es werden zwei Synchronisationsmechanismen vorgesehen, damit ein Thread eine SRAM- oder SDRAM-Referenz ausgeben kann und dann nachfolgend auf den Zeitpunkt synchronisiert wird, an dem diese Referenz vollendet ist.
Ein Mechanismus ist Sofortsynchronisation. Bei Sofortsynchronisation gibt die Mikromaschine die Referenz aus und lagert den Kontext sofort aus. Dem Kontext wird mitgeteilt, wenn die entsprechende Referenz beendet ist. Nach der Mitteilung wird der Kontext wieder zur Ausführung eingelagert, wenn ein Kontextumlagerungsevent auftritt und er an der Reihe ist. Somit wird, vom Standpunkt des Anweisungsstroms eines einzigen Kontexts her gesehen, das Mikrowort nach der Ausgabe der Speicherreferenz erst nach Vollendung der Referenz ausgeführt.
Ein zweiter Mechanismus ist verzögerte Synchronisation. In verzögerter Synchronisation gibt die Mikromaschine die Referenz aus und führt dann weiter andere nützliche Arbeit unabhängig von der Referenz durch. Einige Zeit später könnte es notwendig werden, den Ausführungsstrom des Thread auf die Vollendung der ausgegebenen Referenz zu synchronisieren, bevor weitere Arbeit durchgeführt wird. An dieser Stelle wird ein Synchronisierungsmikrowort ausgeführt, das entweder den aktuellen Thread auslagert und ihn irgendwann später zurücklagert, wenn die Referenz fertig ist, oder mit der Ausführung des aktuellen Threads fortfährt, weil die Referenz bereits fertig ist. Verzögerte Synchronisation erfolgt mit zwei verschiedenen Signalisierungsschemata:
Wenn die Speicherreferenz mit einem Transferregister assoziiert ist, wird das Signal, von dem der Thread ausgelöst wird, generiert, wenn das entsprechende Transferregister-Gültig-Bit gesetzt oder gelöscht ist. Zum Beispiel würde ein SRAM-Lesevorgang, der Daten im Transferregister A ablegt, dann signalisiert, wenn das Gültig-Bit für A gesetzt ist. Wenn die Speicherreferenz mit dem Transfer-FIFO oder dem Empfangs-FIFO anstatt einem Transferregisters assoziiert ist, dann wird das Signal generiert, wenn die Referenz im SDRAM-Controller 26a fertig ist. Im Mikromaschinen-Scheduler wird nur ein Signalzustand pro Kontext gespeichert, und daher kann in diesem Schema nur ein ausstehendes Signal existieren.
Es gibt wenigstens zwei allgemeine Betriebsparadigmen, von denen Microcontroller-Mikroprogramme entwickelt werden könnten. Eines wäre, dass der gesamte Microcontroller-Rechendurchsatz und die gesamte Speicherbandbreite auf Kosten einer einzelnen Thread-Ausführungslatenz optimiert werden. Dieses Paradigma wäre dort sinnvoll, wo das System mehrere Mikromaschinen hat, die mehrere Threads pro Mikromaschine an nicht zueinander gehörigen Datenpaketen ausführt.
Ein zweites ist, Mikromaschinen-Ausführungslatenz auf Kosten von Mikromaschinen-Gesamtrechendurchsatz und Gesamtspeicherbandbreite zu optimieren. Dieses Paradigma könnte die Ausführung eines Thread mit einer Echtzeitbeschränkung beinhalten, d.h. einer Beschränkung, die diktiert, dass einige Arbeit unbedingt zu einer bestimmten Zeit ausgeführt werden muss. Eine solche Beschränkung erfordert, dass einer Optimierung der Einzelthread-Ausführung Priorität gegenüber anderen Faktoren wie Speicherbandbreite oder Gesamtrechendurchsatz gegeben wird. Ein Echtzeit-Thread würde implizieren, dass eine einzelne Mikromaschine nur einen Thread ausführt. Es würden nicht mehrere Threads gehandhabt, weil es das Ziel ist zuzulassen, dass der einzelne Echtzeit-Thread so bald wie möglich ausgeführt wird – eine Ausführung mehrerer Threads würde diese Möglichkeit behindern.
Die Codierungsweise dieser beiden Paradigmen könnte sich in Bezug auf die Ausgabe von Speicherreferenzen und Kontextumschaltung erheblich unterscheiden. Im Echtzeitfall besteht das Ziel darin, so bald wie möglich möglichst viele Speicherreferenzen auszugeben, um die Speicherlatenz zu minimieren, die von solchen Referenzen verursacht wird. Nach der frühestmöglichen Ausgabe möglichst vieler Referenzen wäre es das Ziel, so viele Rechenvorgänge als die Mikromaschinen parallel zu den Referenzen durchzuführen. [sic] Ein Rechenablauf, der einer Echtzeitoptimierung entspricht, lautet:

o) Ausgabe mem ref 1
o) Ausgabe mem ref 2
o) Ausgabe mem ref 3
o) Ausführung von Arbeit unabhängig von mem refs 1, 2 und 3
o) Synch auf Vollendung von mem ref 1
o) Ausführung von Arbeit abhängig von mem ref 1 und unabhängig von mem refs 2 und 3
o) Ausgabe neuer mem refs auf der Basis von vorheriger Arbeit
o) Synch auf Vollendung von mem ref 2
o) Ausführung von Arbeit abhängig von mem refs 1 und 2, unabhängig von mem ref 3
o) Ausgabe neuer mem refs auf der Basis vorheriger Arbeit
o) Synch auf Vollendung von mem ref 3
o) Ausführung von Arbeit abhängig von Vollendung aller 3 refs
o) Ausgabe neuer mem refs auf der Basis von vorheriger Arbeit

Im Gegensatz dazu wäre der Ansatz für die Optimierung für Durchsatz und Bandbreite anders. Bei Optimierung für Mikromaschinen-Rechendurchsatz und Gesamtspeicherbandbreite würde der Einzelthread-Ausführungslatenz weniger Bedeutung eingeräumt. Um dies zu erzielen, wäre es das Ziel, Speicherreferenzen über das Mikroprogramm für jeden Thread gleichmäßig zu beabstanden. Dies ergäbe einen gleichmäßigen Strom von Speicherreferenzen zu den SRAM- und SDRAM-Controllern und würde die Wahrscheinlichkeit maximieren, dass ein Thread immer verfügbar ist, um die Speicherlatenz zu verbergen, die entsteht, wenn ein anderer Thread ausgelagert wird.
Registerdatei-Adresstypen
Gemäß 3C sind die beiden existierenden Registeradressräume alle lokal zugängige Register und global zugängige Register, auf die alle Mikromaschinen zugreifen können. Die Universalregister (GPR) werden als zwei separate Bänke (Bank A und Bank B) implementiert, deren Adressen auf einer Wort-für-Wort-Basis verschachtelt sind, so dass A-Bank-Register lsb=0 und B-Bank-Register lsb=1 haben. Jede Bank kann gleichzeitig Lese- und Schreibvorgänge an zwei verschiedenen Wörtern in der Bank durchführen.
Über die Bänke A und B ist der Registersatz 76b auch in vier Fenster 76b₀–76b₃ von 32 Registern organisiert, die pro Thread relativ adressierbar sind. Somit findet thread_0 sein Register 0 bei 77a (Register 0), thread_1 findet sein Register_0 bei 77b (Register 32), thread_2 findet sein Register_0 bei 77c (Register 64) und thread_3 bei 77d (Register 96). Relative Adressierung wird unterstützt, so dass mehrere Threads genau denselben Steuerspeicher und dieselben Stellen verwenden können, aber auf andere Registerfenster zugreifen und andere Funktionen ausführen. Die Anwendung von Registerfensteradressierung und Bankadressierung ergibt die benötigte Lesebandbreite unter Verwendung von nur Zwei-Port-RAMs in der Mikromaschine 22f.
Diese Fensterregister brauchen keine Daten von einer Kontextumschaltung zur nächsten zu speichern, so dass das normale „Pushen und Poppen" einer Kontextumlagerungsdatei oder eines Stapels wegfällt. Kontextumschaltung hat hier einen 0-Zyklus-Overhead für den Wechsel von einem Kontext zum anderen. Relative Registeradressierung unterteilt die Registerbänke in Fenster über die Adressbreite des Universalregistersatzes. Relative Adressierung erlaubt den Zugriff auf beliebige der Fenster relativ zum Ausgangspunkt des Fensters. Absolute Adressierung wird auch in dieser Architektur unterstützt, wo beliebige der Threads auf beliebige der absoluten Register zugreifen können, indem die exakte Adresse des Registers bereitgestellt wird.
Die Adressierung von Universalregistern 78 kann in 2 Modi je nach Mikrowortformat auftreten. Die beiden Modi sind absolut und relativ. Im Absolutmodus wird die Adressierung einer Registeradresse direkt im 7-Bit-Quellfeld (a6-a0 oder b6-b0) vorgegeben:
Registeradressen, die direkt im 8-Bit-Zielfeld (d7-d0) vorgegeben sind:
Wenn <a6:a5>=1,1, <b6:b5>=1,1 oder <d7:d6>=1,1 ist, dann werden die tieferen Bits als kontextrelatives Adressfeld (nachfolgend beschrieben) interpretiert. Wenn eine nicht-relative A- oder B-Quelladresse im A, B Absolutfeld vorgegeben wird, dann kann nur die untere Hälfte der SRAM/ASB- und SDRAM-Adressräume adressiert werden. Effektiv hat das Lesen von absoluten SRAM/SDRAM-Geräten den effektiven Adressraum; da jedoch diese Beschränkung nicht auf das Zielfeld zutrifft, benutzt der SRAM/SDRAM-Schreibvorgang weiterhin den vollen Adressraum.
Im Relativmodus werden Addressen eine vorgegebene Adresse [sic] im Kontextraum gemäß Definition durch ein 5-Bit-Quellfeld (a4-a0 oder b4-b0) versetzt:
oder gemäß Definition im 6-Bit-Zielfeld (d5-d0):
Wenn <d5:d4>=1,1 ist, dann adressiert die Zieladresse kein gültiges Register, und somit wird kein Zieloperand zurückgeschrieben.
Auf die folgenden Register kann von den Mikromaschinen und den Speicher-Controllern global zugegriffen werden:

Hash-Einheitsregister
Notizblock- und gemeinsame Register
Empfangs-FIFO und Empfangs-Status-FIFO
Sende-FIFO
Sende-Steuer-FIFO

Die Mikromaschinen sind nicht Interrupt-gesteuert. Jeder Mikrofluss wird bis zur Vollendung ausgeführt, dann wird ein neuer Fluss auf der Basis des Zustands gewählt, der von anderen Geräten im Prozessor 12 signalisiert wird.
Gemäß 4 beinhaltet der SDRAM-Speicher-Controller 26a Speicherreferenzwarteschlangen 90, bei denen Speicherreferenzanforderungen von den verschiedenen Mikromaschinen 22a–22f ankommen. Der Speicher-Controller 26a beinhaltet einen Zuteiler 91, der die nächsten der [sic] Mikromaschinen-Referenzanforderungen auswählt, die zu einer der Funktionseinheiten gehen sollen. Unter der Annahme, dass eine der Mikromaschinen eine Referenzanforderung gibt, kommt die Referenzanforderung durch die Adress- und Befehlswarteschlange 90 im SDRAM-Controller 26a. Wenn in der Referenzanforderung ein Bit mit der Bezeichnung „optimiertes MEM-Bit" gesetzt ist, dann wird die eingehende Referenzanforderung entweder in die geradzahlige Bankwarteschlange 90a oder in die ungeradzahlige Bankwarteschlange 90b sortiert. Wenn in der Speicherreferenzanforderung kein Speicheroptimierungsbit gesetzt ist, dann geht die Anforderung vorgabemäßig in eine Order-Warteschlange 90c. Der SDRAM-Controller 26 ist ein von FBUS-Schnittstelle 28, Kernprozessor 20 und PCI-Schnittstelle 24 gemeinsam genutztes Betriebsmittel. Der SDRAM-Controller 26 führt auch eine Zustandsmaschine zum Durchführen atomarer READ-MODIFY-Write-Operationen. Der SDRAM-Controller 26 führt auch eine Byte-Ausrichtung für Anforderungen von Daten vom SDRAM durch.
Die Order-Warteschlange 90c verwaltet die Reihenfolge von Referenzanforderungen von den Mikromaschinen. Bei einer Serie von ungeradzahligen und geradzahligen Bankreferenzen ist es möglicherweise erforderlich, dass ein Signal nur nach Abschluss einer Sequenz von Speicherreferenzen zu ungeradzahligen und geradzahligen Bänken zurückgegeben wird. Wenn die Mikromaschine 22f die Speicherreferenzen in ungeradzahlige und geradzahlige Bankreferenzen sortiert und einer der Bänke, z.B. der geradzahligen Bank, die Speicherreferenzen vor der ungeradzahligen Bank ausgehen, aber das Signal auf der letzten geradzahligen Referenz aufgedrückt wird, dann wäre es denkbar, dass der Speicher-Controller 26a einer Mikromaschine signalisiert, dass die Speicheranforderung fertig ist, auch wenn die ungeradzahlige Bankreferenz noch nicht bearbeitet wurde. Dies könnte ein Kohärenzproblem verursachen. Die Situation wird dadurch vermieden, dass die Order-Warteschlange 90c bereitgestellt wird, so dass eine Mikromaschine mehrere ausstehende Speicherreferenzen haben kann, von denen nur die letzte Speicherreferenz einen Abschluss zu signalisieren braucht.
Der SDRAM-Controller 26a beinhaltet auch eine Hohe-Priorität-Warteschlange 90d. In der Hohe-Priorität-Warteschlange 90d geht eine eingehende Speicherreferenz von einer der Mikromaschinen direkt zur Hohe-Priorität- Warteschlange und wird mit einer höheren Priorität bearbeitet als andere Speicherreferenzen in den anderen Warteschlangen. Alle diese Warteschlangen, die Geradzahlige-Bank-Warteschlange 90a, die Ungeradzahlige-Bank-Warteschlange 90b, die Order-Warteschlange 90c und die Hohe-Priorität-Warteschlange, werden in einer einzigen RAM-Struktur implementiert, die logisch in vier verschiedene Fenster segmentiert ist, wobei jedes Fenster seinen eigenen Anfangs- und Endezeiger hat. Da Füll- und Leer-Operationen nur eine einzige Eingabe und eine einzige Ausgabe sind, können sie in dieselbe RAM-Struktur gesetzt werden, um die Dichtigkeit von RAM-Strukturen zu erhöhen.
Der SDRAM-Controller 26a beinhaltet auch Kernbusschnittstellenlogik, d.h. ASB-Bus 92. Die ASB-Busschnittstellenlogik 92 verbindet den Kernprozessor 20 mit dem SDRAM-Controller 26a. Der ASB-Bus ist ein Bus mit einem 32-Bit-Datenpfad und einem 28-Bit-Adresspfad. Auf die Daten wird zu und von dem Speicher durch das MEM-ASB-Datengerät 98 zugegriffen, z.B. ein Puffer. Das MEM-ASB-Datengerät 98 ist eine Warteschlange für Schreibdaten. Wenn Daten vom Kernprozessor 20 über die ASB-Schnittstelle 92 ankommen, dann werden die Daten im MEM-ASB-Gerät 98 gespeichert und nachfolgend aus dem MEM ASB Gerät 98 durch die SDRAM-Schnittstelle 110 zum SDRAM-Speicher 16a entfernt. Obwohl nicht dargestellt, kann dieselbe Warteschlangenstruktur für die Lesevorgänge vorgesehen werden. Der SDRAM-Controller 26a hat auch eine Maschine 97 zum Holen von Daten aus den Mikromaschinen und dem PCI-Bus.
Zusätzliche Warteschlangen sind u.a. die PCI-Adresswarteschlange 94 und die ASB-Lese/Schreib-Warteschlange 96, die eine Reihe von Anforderungen verwalten. Die Speicheranforderungen werden über den Multiplexer 106 zur SDRAM-Schnittstelle 110 gesendet. Der Multiplexer 106 wird vom SDRAM-Zuteiler 91 gesteuert, der den Füllegrad der einzelnen Warteschlangen sowie den Status der Anforderungen erfasst und davon ausgehend eine Prioritätsentscheidung auf der Basis eines programmierbaren Wertes trifft, der in einem Prioritätsservice-Steuerregister 100 gespeichert ist.
Wenn die Steuerung zu Multiplexer 106 eine Speicherreferenzanforderung wählt, dann wird die Speicherreferenzanforderung zu einem Decoder 108 gesendet, wo sie decodiert und eine Adresse erzeugt wird. Die decodierte Adresse wird zur SDRAM-Schnittstelle 110 gesendet, wo sie in Reihen- und Spaltenadress-Strobes zerlegt wird, um auf den SDRAM 16a zuzugreifen und um Daten über Datenleitungen 16a, die Daten zum Bus 112 senden, zu schreiben oder zu lesen. In einer Implementation ist der Bus 112 tatsächlich zwei separate Busse anstatt eines einzelnen Busses. Die separaten Busse würden einen Lesebus, der die verteilten Mikromaschinen 22a–22f koppelt, und einen Schreibbus beinhalten, der die verteilten Mikromaschinen 22a–22f verbindet.
Ein Merkmal des SDRAM-Controllers 26a ist, dass es, wenn eine Speicherreferenz in den Warteschlangen 90 gespeichert wird, zusätzlich zu dem optimierten MEM-Bit, das gesetzt werden kann, ein „Verkettungsbit" gibt. Ein gesetztes Verkettungsbit ermöglicht eine spezielle Handhabung von benachbarten Speicherreferenzen. Wie zuvor erwähnt, steuert der Zuteiler 12, welche Mikromaschine dafür ausgewählt wird, Speicherreferenzanforderungen über den Befehlsbus zur Warteschlange 90 (4) zu senden. Das Aufdrücken des Verkettungsbits steuert den Zuteiler so, dass er die Funktionseinheit wählt, die zuvor diesen Bus angefordert hat, weil das Setzen des Verkettungsbits anzeigt, dass die Mikromaschine eine Verkettungsanforderung ausgegeben hat.
Aneinandergrenzende Speicherreferenzen werden in die Warteschlange 90 aufgenommen, wenn das Verkettungsbit gesetzt ist. Diese aneinandergrenzenden Referenzen werden typischerweise in der Reihenfolge-Warteschlange 90c gespeichert, weil die aneinandergrenzenden Speicherreferenzen mehrere Speicherreferenzen von einem einzigen Thread sind. Zur Erzielung von Synchronisation braucht der Speicher-Controller 26a nur am Ende der verketteten Speicherreferenzen zu signalisieren, wenn sie fertig sind. In einer optimierten Speicherverkettung (z.B. dann, wenn das optimierte MEM-Bit und das Verkettungsbit gesetzt sind), könnten die Speicherreferenzen jedoch in verschiedene Bänke gehen und potentiell an einer der Bänke enden und das Signal „fertig" ausgeben, bevor die andere Bank völlig leer ist, wodurch die Kohärenz zerstört wird. Daher wird das Verkettungsbit vom Controller 110 benutzt, um die Speicherreferenzen von der aktuellen Warteschlange zu verwalten.
4A zeigt eine Ablaufdarstellung der Zuteilungsrichtlinie im SDRAM-Controller 26a. Die Zuteilungsrichtlinie favorisiert verkettete Mikromaschinen-Speicheranforderungen. Der Prozess 115 beginnt mit dem Untersuchen auf verkettete Mikromaschinen-Speicherreferenzanforderungen 115a. Der Prozess 115 bleibt so lange bei den verketteten Anforderungen, bis das Verkettungsbit entfernt wird. Der Prozess untersucht ASB-Busanforderungen 115b, dann PCI-Busanforderungen 115c, Hohe-Priorität-Warteschlangenservice 115d, Entgegengesetzte-Bank-Anforderungen 115e, Order-Warteschlangenanforderungen 115f und Selbe-Bank-Anforderungen 115g. Verkettete Anforderungen werden vollständig bearbeitet, während Services 115b–115d in zyklischer Folge bearbeitet werden. Erst wenn Services 115a–115d völlig leer sind, bearbeitet der Prozess die Services 115e–115g. Verkettete Mikromaschinen-Speicherreferenzanforderungen erfolgen dann, wenn in der vorherigen SDRAM-Speicheranforderung das Verkettungsbit gesetzt ist. Wenn das Verkettungsbit gesetzt ist, dann bearbeitet die Zuteilungsmaschine einfach die Services derselben Warteschlange nochmal, bis das Verkettungsbit entfernt wird. Der ASB hat eine höhere Priorität als PCI wegen des hohen Leistungsmehraufwands, der am Strong-Arm-Kern entsteht, wenn sich der ASB im Wartezustand befindet. Der PCI hat eine höhere Priorität als die Mikromaschinen wegen der Latenzanforderungen von PCI. Bei anderen Bussen könnte die Zuteilungspriorität jedoch anders sein.
4B zeigt eine typische Zeitsteuerung eines Speichers ohne aktive Speicheroptimierung und mit aktiver Speicheroptimierung. Wie ersichtlich ist, maximiert die Verwendung von aktiven Speicheroptimierungen die Auslastung des Busses und verbirgt somit die inhärente Latenz in physikalischen SDRAM-Geräten. In diesem Beispiel kann ein nicht optimierter Zugriff 14 Zyklen erfordern, während ein optimierter Zugriff 7 Zyklen erfordern kann.
5 zeigt den Speicher-Controller 26b für den SRAM. Der Speicher-Controller 26b beinhaltet eine Adress- und Befehlswarteschlange 120. Während der Speicher-Controller 26a (4) eine Warteschlange für die Speicheroptimierung auf der Basis von geradzahligen und ungeradzahligen Banken hat, wird der Speicher-Controller 26b auf der Basis des Speicheroperationstyps optimiert, d.h. Lesen oder Schreiben. Die Adress- und Befehlswarteschlange 120 beinhaltet eine Hohe-Priorität-Warteschlange 120a, eine Lesewarteschlange 120b, die die vorherrschende Speicherreferenzfunktion ist, die ein SRAM ausführt, und eine Order-Warteschlange 120c, die im Allgemeinen alle Schreibvorgänge auf SRAM beinhaltet und liest, die nicht-optimiert sein sollen. Obwohl nicht dargestellt, könnte die Adress- und Befehlswarteschlange 120 auch eine Schreibwarteschlange beinhalten.
Der SRAM-Controller 26b beinhaltet auch Kernbusschnittstellenlogik, d.h, den ASB-Bus 122. Die ASB-Busschnittstellenlogik 122 verbindet den Kernprozessor 20 mit dem SRAM-Controller 26b. Der ASB-Bus ist ein Bus mit einem 32-Bit-Datenpfad und einem 28-Bit-Adresspfad. Auf die Daten wird zu und von dem Speicher durch das MEM ASB Datengerät 128 zugegriffen, z.B. ein Puffer. Das MEM ASB Datengerät 128 ist eine Warteschlange für Schreibdaten. Wenn Daten vom Kernprozessor 20 über die ASB-Schnittstelle 122 eingehen, dann können die Daten im MEM ASB Gerät 128 gespeichert und nachfolgend durch die SRAM-Schnittstelle 140 aus dem MEM ASB Gerät 128 zum SRAM-Speicher 16b entfernt werden. Obwohl nicht dargestellt, kann dieselbe Warteschlangenstruktur auch für Lesevorgänge vorgesehen werden. Der SRAM-Controller 26b beinhaltet auch eine Maschine 127 zum Holen von Daten aus den Mikromaschinen und dem PCI-Bus.
Die Speicheranforderungen werden über den Multiplexer 126 zur SRAM-Schnittstelle 140 gesendet. Der Multiplexer 126 wird vom SRAM-Zuteiler 131 gesteuert, der den Füllegrad der Warteschlangen sowie den Status der Anforderungen erfasst und der davon ausgehend die Priorität auf der Basis eines programmierbaren Wertes entscheidet, der im Prioritätsservice-Steuerregister 130 gespeichert ist. Wenn die Steuerung zu Multiplexer 126 eine Speicherreferenzanforderung gewählt hat, dann wird die Speicherreferenzanforderung zu einem Decoder 138 gesendet, wo sie decodiert und eine Adresse generiert wird.
Die SRAM-Einheit verwaltet die Steuerung von Memory Mapped Off-Chip SRAM und Expansion-ROM. Der SRAM-Controller 26b kann z.B. 16 MB adressieren, z.B. 8 MB für SRAM 16b gemappt und 8 MB für Sonderfunktionen reserviert, wie z.B.: Boot-Raum über Flashrom 16c; und Konsolenport-Zugang für MAC-Geräte 13a, 13b und Zugang zu assoziierten (RMON) Zählern. Der SRAM wird für lokale Lookup-Tabellen und Warteschlangenmanagementfunktionen verwendet.
Der SRAM-Controller 26b unterstützt die folgenden Transaktionen:

Mikromaschinenanforderungen (über privaten Bus) zu/von SRAM
Kernprozessor (über ASB-Bus) zu/von SRAM

Der SRAM-Controller 26b sortiert Speicherreferenzen, um Verzögerungen (Blasen) in der Pipeline von der SRAM-Schnittstelle 140 zum Speicher 16b minimal zu halten. Der SRAM-Controller 26b sortiert Speicherreferenzen auf der Basis der Lesefunktion. Eine Blase kann 1 oder 2 Zyklen lang sein, je nach dem verwendeten Speichergerätetyp.
Der SRAM-Controller 26b beinhaltet ein Lock-Lookup-Gerät 142, das ein acht (8 Eingabeadressinhalt adressierbarer Speicher zum Nachschlagen von Read-Locks ist [sic]. Jede Position hat ein gültiges Bit, das von nachfolgenden Read-Lock-Anforderungen untersucht wird. Die Adress- und Befehlswarteschlange 120 beinhaltet auch eine Read-Lock-Fail-Warteschlange 120d. Die Read-Lock-Fail-Warteschlange 120d dient zum Speichern von Lese-Speicherreferenzanforderungen, die aufgrund einer Sperre an einem Teil des Speichers erfolglos verlaufen. Das heißt, eine der Mikromaschinen gibt eine Speicheranforderung aus, die eine Read-Lock-Anforderung hat, die in der Adress- und Steuerwarteschlange 120 verarbeitet wird. Die Speicheranforderung wirkt auf der Order-Warteschlange 120c oder der Lesewarteschlange 120b und erkennt sie als Read-Lock-Anforderung. Der Controller 26b greift auf das Lock-Lookup-Gerät 142 zu, um zu ermitteln, ob diese Speicherstelle bereits gesperrt ist. Wenn diese Speicherstelle gegen eine vorherige Read-Lock-Anforderung gesperrt ist, dann verläuft die Speicher-Lock-Anforderung erfolglos und wird in der Read-Lock-Fail-Warteschlange 120d gespeichert. Wenn sie entsperrt ist oder wenn 142 keine Sperre an dieser Adresse zeigt, dann wird die Adresse dieser Speicherreferenz von der SRAM-Schnittstelle 140 zum Durchführen einer traditionellen SRAM-Adress-Lese/Schreib-Anforderung auf Speicher 16b verwendet. Der Befehls-Controller und der Adressgenerator 138 geben die Sperre ebenfalls in das Lock-Lookup-Gerät 142, so dass nachfolgende Read-Lock-Anforderungen die Speicherstelle gesperrt vorfinden. Eine Speicherstelle wird durch Ausführen der Microcontroller-Anweisung in einem Programm entsperrt, wenn die Notwendigkeit für die Sperre nicht mehr besteht. Die Stelle wird durch Entfernen des Gültig-Bits im CAM entriegelt. Nach einer Entsperrung wird die Read-Lock-Fail-Warteschlange 120d zur Warteschlange mit der höchsten Priorität, so dass alle Lese-Lock-Misses in der Warteschlange die Möglichkeit erhalten, eine Speicher-Lock-Anforderung auszugeben.
5A zeigt eine typische Zeitsteuerung eines statischen Direktzugriffsspeichers ohne aktive Speicheroptimierung und mit aktiver Speicheroptimierung. Wie ersichtlich ist, wird durch Gruppieren von Lese- und Schreibvorgängen die Zykluszeit verbessert und Totzyklen entfallen.
6 zeigt die Kommunikation zwischen den Mikromaschinen 22 und der FBUS-Schnittstellenlogik (FBI). Die FBUS-Schnittstelle 28 in einer Netzwerkanwendung kann die Kopfzeilenverarbeitung von eingehenden Paketen vom FBUS 18 durchführen. Eine Schlüsselfunktion, die die FBUS-Schnittstelle ausführt, ist die Extraktion von Paketkopfzeilen, und ein mikroprogrammierbares hashcodiertes Quell/Ziel/Protokoll-Lookup im SRAM. Wenn sich die Hash-Codierung nicht richtig auflöst, dann wird die Paketkopfzeile für eine weitergehende Verarbeitung zum Kernprozessor 28 weitergeleitet.
FBI 28 enthält einen Sende-FIFO 182, einen Empfangs-FIFO 183, eine HASH-Einheit 188 sowie FBI-Steuer- und Statusregister 189. Diese vier Einheiten kommunizieren mit den Mikromaschinen 22 über einen zeitmultiplexierten Zugriff auf den SRAM-Bus 38, der mit den Transferregistern 78, 80 in den Mikromaschinen verbunden ist. Das heißt, alle Kommunikationen zu und von den Mikromaschinen erfolgen über die Transferregister 78, 80. Die FBUS-Schnittstelle 28 beinhaltet eine Push-Zustandsmaschine 200 zum Pushen von Daten in die Transferregister während der Zeitzyklen, in denen der SRAM den SRAM-Datenbus (Teil von Bus 38) NICHT benutzt, und eine Pull-Zustandsmaschine 202 zum Abrufen von Daten aus den Transferregistern in der jeweiligen Mikromaschine.
Die Hash-Codiereinheit beinhaltet ein Paar FIFOs 188a, 188b. Die Hash-Einheit stellt fest, dass der FBI 28 eine FBI_hash-Anforderung empfangen hat. Die Hash-Einheit 188 holt die Hash-Codierschlüssel aus der abrufenden Mikromaschine 22. Nach dem Holen und Hash-Codieren der Schlüssel werden die Anzeigen zurück zur abrufenden Mikromaschine 22 gesendet. Unter einer einzigen FBI_hash-Anforderung sind bis zu drei Hash-Codiervorgänge möglich. Die Busse 34 und 38 sind jeweils unidirektional: SDRAM_push/pull_data und Sbus_push/pull_data. Jeder dieser Busse benötigt Steuersignale, die Lese/Schreib-Controls zu den geeigneten Transferregistern der Mikromaschine 22 senden.
Im Allgemeinen benötigen Transferregister Schutz vor dem sie steuernden Kontext, um die Lesekorrektheit zu garantieren. Insbesondere darf thread_1, wenn ein Schreibtransferregister von einem thread_1 benutzt wird, um Daten zum SDRAM 16a zu senden, dieses Register erst dann überschreiben, wenn das Rücksignal vom SDRAM-Controller 26a anzeigt, dass dieses Register fertig ist und jetzt wieder verwendet werden kann. Es braucht nicht jeder Schreibvorgang ein Rücksignal vom Ziel, das besagt, dass die Funktion abgeschlossen ist, weil, wenn der Thread auf dieselbe Befehlswarteschlange an diesem Ziel mit mehreren Anforderungen schreibt, die Reihenfolge der Vollendung innerhalb dieser Befehlswarteschlange garantiert wird, so dass nur der letzte Befehl eine Signalisierung zurück zum Thread erfordert. Wenn der Thread jedoch mehrere Befehlswarteschlangen (Reihenfolge und Lesen) benutzt, dann müssen diese Befehlsanforderungen in separate Kontexttasks untergliedert werden, so dass die Reihenfolge über Kontextumlagerung erhalten bleibt. Der zu Beginn des vorliegenden Absatzes angedeutete Ausnahmefall bezieht sich auf eine bestimmte Klasse von Operationen unter Verwendung eines unerwünschten PUSH zu Transferregistern vom FBI um FBUS-Statusinformationen. Um den Lese/Schreib-Determinismus an den Transferregistern zu schützen, erzeugt der FBI ein spezielles Push_protect-Signal, wenn diese speziellen FBI-Push-Operationen eingerichtet werden.
Jede Mikromaschine 22, die die vom FBI unerwünschte Push-Technik anwendet, muss vor dem Zugreifen auf die von FBUS-Schnittstelle und Mikromaschine vereinbarten Transferregister den Schutzflag prüfen. Wenn der Flag nicht gesetzt ist, dann kann die Mikromaschine auf die Transferregister zugreifen. Wenn der Flag gesetzt ist, muss der Kontext N Zyklen lang warten, bevor auf die Register zugegriffen wird. Diese Zahl wird zuvor von der Zahl der gepushten Transferregister ermittelt, plus einem Frontend-Schutzfenster. Die Grundidee ist, dass die Mikromaschine diesen Flag testen und die Daten, die sie von den Lesetransferregistern lesen möchte, schnell zu GPRs in aneinandergrenzenden Zyklen bewegen muss, damit die Push- Maschine nicht mit dem Mikromaschinenlesevorgang kollidiert.
Weitere Ausgestaltungen
Es ist zu verstehen, dass die Erfindung zwar in Verbindung mit der ausführlichen Beschreibung davon beschrieben wurde, dass die obige Beschreibung den Umfang der Erfindung jedoch lediglich illustrieren und nicht einschränken soll. Dieser Umfang wird durch die beiliegenden Ansprüche definiert. Weitere Aspekte, Vorteile und Modifikationen liegen innerhalb des Umfangs der nachfolgenden Ansprüche.

Claims

Mikrogesteuerte Funktionsausführungseinheit, die Folgendes umfasst: einen Steuerspeicher (70) zum Speichern eines Mikroprogramms; einen Mikromaschinen-Controller (72) zum Verwalten einer Mehrzahl von Mikroprogrammzählern und Decodierlogik (73) zum Decodieren von Anweisungen; einen Kontext-Event-Zuteiler (74), der als Reaktion auf externe Flags ermittelt, welcher aus einer Mehrzahl von Threads, die in der mikrogesteuerten Funktionsausführungseinheit abgearbeitet werden können, in einen Ausführungszustand promoviert werden soll; einen Universalregistersatz (76) zum Speichern und Beschaffen von Operanden, wobei der Universalregistersatz in zwei Bänke unterteilt ist, die separat adressierbar sind, und wobei jede Registerbank logisch in eine Mehrzahl von Fenstern unterteilt, ist, die der Zahl der Mikroprogrammzähler entsprechen, die in dem Mikromaschinen-Controller unterstützt werden; einen Lese-Transferregistersatz (80); und einen Schreib-Transferregistersatz (78), wobei der Lese- und der Schreib-Transferregistersatz in zwei Bänke und eine Mehrzahl von Fenstern unterteilt werden, die der Zahl der Mikroprogrammzähler entsprechen, die in dem Mikromaschinen-Controller unterstützt werden.
Mikrogesteuerte Einheit nach Anspruch 1, bei der der Kontext-Event-Zuteiler Meldungen von einer Gemeinschaftsressource empfängt.
Mikrogesteuerte Einheit nach Anspruch 2, bei der die Gemeinschaftsressource ein statischer Arbeitsspeicher (SRAM) ist.
Mikrogesteuerte Einheit nach Anspruch 2, bei der die Gemeinschaftsressource ein synchroner dynamischer Arbeitsspeicher (SDRAM) ist.
Mikrogesteuerte Einheit nach Anspruch 2, bei der die Gemeinschaftsressource ein Prozessorkern ist.
Mikrogesteuerte Einheit nach Anspruch 2, bei der die Gemeinschaftsressource eine Mehrzahl von Steuer- und Statusregistern ist.
Mikrogesteuerte Einheit nach Anspruch 2, bei der die Meldungen Informationen darüber geben, ob eine angeforderte Funktion vollendet ist.
Mikrogesteuerte Einheit nach einem der vorherigen Ansprüche, bei der der Kontext-Event-Zuteiler Zuteilung für vier Threads umfasst.
Mikrogesteuerte Einheit nach Anspruch 8, bei der die Zuteilung eine Round-Robin-Zuteilung ist.
Mikrogesteuerte Einheit nach Anspruch 8, bei der die Zuteilung eine Prioritätswarteschlangenzuteilung ist.
Mikrogesteuerte Einheit nach Anspruch 8, bei der die Zuteilung eine Weighted-Fair-Queuing-Zuteilung ist.
Mikrogesteuerte Einheit nach Anspruch 8, bei der die mikrogesteuerte Einheit eine aus einer Mehrzahl von mikrogesteuerten Einheiten ist, die in demselben Prozessor integriert ist.