DE102020119518A1

DE102020119518A1 - Verfahren und vorrichtung für mehrere asynchrone konsumenten

Info

Publication number: DE102020119518A1
Application number: DE102020119518.4A
Authority: DE
Inventors: Roni Rosner; Moshe Maor; Michael Behar; Ronen Gabbai; Zigi Walter; Oren AGAM
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2019-08-15
Filing date: 2020-07-23
Publication date: 2021-02-18
Also published as: US20190370074A1; KR20210021262A; CN112395249A

Abstract

Eine Vorrichtung umfasst einen Kommunikationsprozessor zum Empfangen von Konfigurationsinformationen von einem produzierenden Rechenbaustein; einen Credit-Generator zum Generieren einer Anzahl von Credits für den produzierenden Rechenbaustein, der den Konfigurationsinformationen entspricht, wobei die Konfigurationsinformationen Eigenschaften eines Puffers einschließen; einen Quellenidentifikator zum Analysieren eines zurückgegebenen Credits, um zu bestimmen, ob der zurückgegebene Credit von dem produzierenden Rechenbaustein oder einem konsumierenden Rechenbaustein stammt; und einen Duplikator zum Multiplizieren des zurückgegebenen Credits mit einem ersten Faktor, wenn der zurückgegebene Credit vom produzierenden Rechenbaustein stammt, wobei der erste Faktor indikativ für eine Anzahl von konsumierenden Rechenbausteinen ist, die in den Konfigurationsinformationen identifiziert sind.

Description

GEBIET DER OFFENBARUNG
Diese Offenbarung betrifft allgemein Konsumenten und insbesondere mehrere asynchrone Konsumenten.
HINTERGRUND
Computerhardwarehersteller entwickeln Hardwarekomponenten zur Verwendung in verschiedenen Komponenten von Computerplattformen. Beispielsweise entwickeln Computerhardwarehersteller Motherboards, Chipsätze für Motherboards, zentrale Verarbeitungseinheiten (CPUs, Central Processing Units), Festplattenlaufwerke (HDDs, Hard Disk Drives), Solid-State-Laufwerke (SSDs, Solid State Drives) und andere Computerkomponenten. Zusätzlich entwickeln Computerhardwarehersteller Verarbeitungselemente, die als Beschleuniger bekannt sind, um die Verarbeitung einer Arbeitslast zu beschleunigen. Beispielsweise kann ein Beschleuniger eine CPU, eine Grafikverarbeitungseinheit (GPU, Graphics Processing Unit), eine Vision-Verarbeitungseinheit (VPU, Vision Processing Unit) und/oder ein feldprogrammierbares Gate-Array (FPGA) sein.
Figurenliste

1 ist ein Blockschaltbild, das ein beispielhaftes Rechensystem veranschaulicht.
2 ist ein Blockschaltbild, das ein beispielhaftes Rechensystem veranschaulicht, das einen beispielhaften Compiler und einen beispielhaften Credit-Manager einschließt.
3 ist ein beispielhaftes Blockschaltbild, das den beispielhaften Credit-Manager aus 2 veranschaulicht.
4A und 4B sind grafische Darstellungen einer beispielhaften Pipeline, die für eine Operation des Credit-Managers während der Ausführung einer Arbeitslast repräsentativ ist.
5 ist ein Flussdiagramm, das für maschinenlesbare Anweisungen repräsentativ ist, die ausgeführt werden können, um einen beispielhaften produzierenden Rechenbaustein (CBB, Compute Building Block) aus 4A und/oder 4B zu implementieren.
6 ist ein Flussdiagramm, das für maschinenlesbare Anweisungen repräsentativ ist, die ausgeführt werden können, um den beispielhaften Credit-Manager aus 2, 3, 4A und/or 4B zu implementieren.
7 ist ein Flussdiagramm, das für maschinenlesbare Anweisungen repräsentativ ist, die ausgeführt werden können, um einen beispielhaften konsumierenden CBB aus 4A und/oder 4B zu implementieren.
8 ist ein Blockschaltbild einer beispielhaften Prozessorplattform, die strukturiert ist, um die Anweisungen aus 5, 6 und/oder 7 auszuführen, um den beispielhaften produzierenden CBB, den/die beispielhaften einen oder mehreren konsumierenden CBBs, den beispielhaften Credit-Manager und/oder den Beschleuniger aus 2, 3, 4A und/or 4B zu implementieren.

Die Figuren sind nicht maßstabsgetreu. Im Allgemeinen werden die gleichen Bezugszeichen durchweg in der/den Zeichnung(en) und der beigefügten schriftlichen Beschreibung verwendet, um auf die gleichen oder ähnliche Teile zu verweisen. Verbindungsreferenzen (z. B. angebracht, gekoppelt, verbunden und aneinandergefügt) sind breit auszulegen und können Zwischenglieder zwischen einer Sammlung von Elementen und Relativbewegung zwischen Elementen aufweisen, sofern nicht anders angegeben. Als solche lassen Verbindungsreferenzen nicht notwendigerweise den Schluss zu, dass zwei Elemente direkt miteinander verbunden sind und in einer festen Beziehung zueinander stehen.
Die Deskriptoren „erste(r/s)“, „zweite(r/s)“, „dritte(r/s)“ usw. werden hierin verwendet, wenn mehrere Elemente oder Komponenten identifiziert werden, auf die separat Bezug genommen werden kann. Sofern aufgrund ihres Verwendungskontexts nichts anderes angegeben oder verstanden wird, sollen derartige Deskriptoren keine Bedeutung von Priorität, physikalischer Reihenfolge oder Anordnung in einer Liste oder zeitlicher Reihenfolge unterstellen, sondern werden lediglich als Bezeichnungen für die Bezugnahme auf mehrere Elemente oder Komponenten separat verwendet, um die offenbarten Beispiele leichter verständlich zu machen. In einigen Beispielen kann der Deskriptor „erste(r/s)“ verwendet werden, um auf ein Element in der detaillierten Beschreibung Bezug zu nehmen, während auf dasselbe Element in einem Anspruch mit einem anderen Deskriptor, wie beispielsweise „zweite(r/s)“ oder „dritte(r/s)“, Bezug genommen werden kann. In solchen Fällen versteht es sich, dass derartige Deskriptoren lediglich der Einfachheit halber verwendet werden, um auf mehrere Elemente oder Komponenten Bezug zu nehmen.
DETAILLIERTE BESCHREIBUNG
Viele Rechenhardwarehersteller entwickeln Verarbeitungselemente, die als Beschleuniger bekannt sind, um die Verarbeitung einer Arbeitslast zu beschleunigen. Beispielsweise kann ein Beschleuniger eine CPU, eine GPU, eine VPU und/oder ein FPGA sein. Darüber hinaus sind Beschleuniger dazu konzipiert, bestimmte Typen von Arbeitslasten zu optimieren, obwohl sie in der Lage sind, jeden Typ von Arbeitslast zu verarbeiten. Während beispielsweise CPUs und FPGAs so konzipiert werden können, dass sie eine allgemeinere Verarbeitung handhaben, können GPUs so konzipiert werden, dass sie die Verarbeitung von Videos, Spielen und/oder anderen physikalisch und mathematisch basierten Berechnungen verbessern, und VPUs können so konzipiert werden, dass sie die Verarbeitung von Machine-Vision-Aufgaben verbessern.
Zusätzlich sind einige Beschleuniger speziell konzipiert, um die Verarbeitung von Anwendungen der künstlichen Intelligenz (KI) zu verbessern. Obgleich eine VPU ein spezieller Typ eines KI-Beschleunigers ist, können viele verschiedene KI-Beschleuniger verwendet werden. Tatsächlich können viele KI-Beschleuniger durch anwendungsspezifische integrierte Schaltungen (ASICs, Application-Specific Integrated Circuits) implementiert werden. Solche ASIC-basierten KI-Beschleuniger können konzipiert werden, um die Verarbeitung von Aufgaben zu verbessern, die sich auf einen bestimmten KI-Typ beziehen, wie beispielsweise maschinelles Lernen (ML), tiefes Lernen (DL, Deep Learning) und/oder andere künstliche maschinengesteuerte Logik einschließlich Unterstützungsvektormaschinen (SVMs, Support Vector Machines), neuronale Netze (NNs), rekurrente neuronale Netze (RNNs), konvolutionale neuronale Netze (CNNs, Convolutional Neural Networks), Long Short-Term-Memory (LSTM), Gate Recurrent Units (GRUs) usw.
Computerhardwarehersteller entwickeln auch heterogene Systeme, die mehr als einen Typ von Verarbeitungselement einschließen.
Beispielsweise können Computerhardwarehersteller Allzweck-Verarbeitungselemente wie CPUs entweder mit Allzweck-Beschleunigern wie FPGAs und/oder mit spezielleren Beschleunigern wie GPUs, VPUs und/oder anderen KI-Beschleunigern kombinieren. Solche heterogenen Systeme können als Systeme auf einem Chip (SoCs, Systems-on-a-Chip) implementiert werden.
Wenn ein Entwickler eine Funktion, einen Algorithmus, ein Programm, eine Anwendung und/oder einen anderen Code auf einem heterogenen System ausführen möchte, generiert der Entwickler und/oder die Software zur Kompilierungszeit einen Schedule (z. B. einen Graphen) für die Funktion, den Algorithmus, das Programm, die Anwendung und/oder den anderen Code. Sobald ein Schedule generiert ist, wird der Schedule mit der Funktion, dem Algorithmus, dem Programm, der Anwendung und/oder der anderen Codespezifikation kombiniert, um eine ausführbare Datei zu generieren (entweder für Ahead-of-Time- oder Just-in-Time-Paradigmen). Darüber hinaus kann der Schedule in Kombination mit der Funktion, dem Algorithmus, dem Programm, der Anwendung, dem Kernel und/oder dem anderen Code als ein Graph mit Knoten repräsentiert werden, wobei der Graph eine Arbeitslast repräsentiert und jeder Knoten (z. B. ein Arbeitslastknoten) eine bestimmte Aufgabe repräsentiert, die für diese Arbeitslast ausgeführt werden soll. Weiterhin repräsentieren die Verbindungen zwischen den verschiedenen Knoten im Graphen Kanten. Die Kanten der In-Arbeitslast repräsentieren einen Datenstream von einem Knoten zu einem anderen. Der Datenstream wird als Eingangsstream oder Ausgangsstream identifiziert.
In einigen Beispielen kann ein Knoten (z. B. ein Produzent) über eine Kante mit einem anderen Knoten (z. B. einem Konsumenten) verbunden sein. Auf diese Weise streamt der Produzentenknoten Daten (z. B. schreibt Daten) an einen Konsumentenknoten, der die Daten konsumiert (z. B. liest). In anderen Beispielen kann ein Produzentenknoten einen oder mehrere Konsumentenknoten aufweisen, so dass der Produzentenknoten Daten über eine oder mehrere Kanten an den einen oder die mehreren Konsumentenknoten streamt. Ein Produzentenknoten generiert den Datenstream für einen Konsumentenknoten oder mehrere Konsumentenknoten, um die Daten zu lesen und zu verarbeiten. Ein Knoten kann während der Kompilierung des Graphen als Produzent oder Konsument identifiziert werden. Beispielsweise empfängt ein Graph-Compiler einen Schedule (z. B. einen Graph) und weist verschiedene Arbeitslastknoten der Arbeitslast verschiedenen Rechenbausteinen (CBBs, Compute Building Blocks) zu, die sich innerhalb eines Beschleunigers befinden. Während der Zuweisung von Arbeitslastknoten weist ein Graph-Compiler dem CBB einen Knoten zu, der Daten produziert, und dieser CBB kann ein Produzent werden. Zusätzlich kann der Graph-Compiler dem CBB einen Knoten zuweisen, der die Daten der Arbeitslast konsumiert, und dieser CBB kann ein Konsument werden. In einigen Beispielen kann der CBB, dem ein Knoten zugewiesen ist, mehrere Rollen gleichzeitig aufweisen. Beispielsweise ist der CBB der Konsument von Daten, die durch Knoten im Graphen produziert werden, die über eingehende Kanten verbunden sind, und der Produzent von Daten, die durch Knoten im Graphen konsumiert werden, die durch ausgehende Kanten verbunden sind.
Die Datenmenge, die ein Produzentenknoten streamt, ist eine Laufzeitvariable. Wenn ein Datenstream eine Laufzeitvariable ist, kennt der Konsument beispielsweise die Datenmenge in diesem Stream nicht im Voraus. Auf diese Weise können die Daten im Stream datenabhängig sein, was anzeigt, dass ein Konsumentenknoten die Datenmenge, die der Konsumentenknoten empfängt, erst dann kennt, wenn der Stream vollständig ist.
In einigen Anwendungen, in denen ein Graph mehr als einen Konsumentenknoten für einen einzelnen Produzentenknoten konfiguriert hat, kann die relative Ausführungsgeschwindigkeit der Konsumentenknoten und der Produzentenknoten unbekannt sein. Beispielsweise kann ein Produzentenknoten Daten exponentiell schneller produzieren, als ein Konsumentenknoten diese Daten konsumieren (z. B. lesen) kann. Zusätzlich können die Konsumentenknoten in der Ausführungsgeschwindigkeit variieren, so dass ein Konsumentenknoten Daten schneller als ein zweiter Konsumentenknoten Daten lesen kann oder umgekehrt. In diesem Beispiel kann es schwierig sein, einen Graphen zu konfigurieren/kompilieren, um eine Arbeitslast mit mehreren Konsumentenknoten durchzuführen, da nicht alle Konsumentenknoten synchron ausgeführt werden.
Hierin offenbarte Beispiele schließen Verfahren und Vorrichtungen zum nahtlosen Implementieren von Multi-Konsumenten-Datenstreams ein. Beispielsweise ermöglichen hierin offenbarte Verfahren und Vorrichtungen einer Mehrzahl von verschiedenen Typen von Konsumenten, Daten zu lesen, die von einem einzelnen Produzenten bereitgestellt werden, indem Datentypen, Datenmenge und Anzahl von Konsumenten wegabstrahiert werden. Beispielsweise verwenden hierin offenbarte Beispiele einen zyklischen Puffer, um Daten zum Schreiben zu und Lesen von Konsumenten und Produzenten zu speichern. Wie hierin verwendet, sind „kreisförmiger Puffer“, „kreisförmige Warteschlange“, „Ringpuffer“, „zyklischer Puffer“ usw. als eine Datenstruktur definiert, die einen einzelnen Puffer fester Größe verwendet, als ob der Puffer Ende-zu-Ende verbunden wäre. Zyklische Puffer werden zum Puffern von Datenstreams genutzt. Ein Datenpuffer ist ein Bereich von physikalischer Speichereinrichtung, die zum temporären Speichern von Daten verwendet wird, während die Daten von einem Ort zu einem anderen bewegt werden (z. B. von einem Produzenten zu einem oder mehreren Konsumenten).
Zusätzlich nutzen hierin offenbarte Beispiele einen Credit-Manager, um einem Produzenten und mehreren Konsumenten Credits zuzuweisen, als ein Mittel, um Multi-Konsumenten-Datenstreams zwischen einem Produzenten und mehreren Konsumenten in einem Beschleuniger zu ermöglichen. Beispielsweise kommuniziert ein Credit-Manager Informationen zwischen dem Produzenten und mehreren Konsumenten, die indikativ dafür sind, wann ein Produzent Daten in den Puffer schreiben kann und wann ein Konsument Daten aus dem Puffer lesen kann. Auf diese Weise sind dem Produzenten und jedem einzelnen der Konsumenten die Anzahl von Konsumenten, an die der Produzent schreiben soll, gleichgültig.
In hierin offenbarten Beispielen ähnelt ein „Credit“ einem Semaphor. Ein Semaphor ist ein variabler oder abstrakter Datentyp, der verwendet wird, um den Zugriff auf eine gemeinsame Ressource (z. B. einen zyklischen Puffer) durch mehrere Prozesse (z. B. Produzenten und Konsumenten) in einem konkurrenten System (z. B. einer Arbeitslast) zu steuern. In einigen Beispielen generiert der Credit-Manager eine spezielle Anzahl von Credits oder passt die Anzahl von verfügbaren Credits basierend auf der Verfügbarkeit in einem Puffer und der Quelle des Credits an (z. B. woher der Credit kam). Auf diese Weise beseitigt der Credit-Manager die Notwendigkeit, dass ein Produzent konfiguriert werden muss, um direkt mit einer Mehrzahl von Konsumenten zu kommunizieren. Das Konfigurieren des Produzenten, um direkt mit einer Mehrzahl von Konsumenten zu kommunizieren, ist rechenintensiv, da der Produzent den Konsumententyp, die Geschwindigkeit, mit der der Konsument Daten lesen kann, den Ort des Konsumenten usw. kennen müsste.
1 ist ein Blockschaltbild, das ein beispielhaftes Rechensystem 100 veranschaulicht. Im Beispiel aus 1 schließt das Rechensystem 100 einen beispielhaften Systemspeicher 102 und ein beispielhaftes heterogenes System 104 ein. Das beispielhafte heterogene System 104 schließt einen beispielhaften Host-Prozessor 106, einen beispielhaften ersten Kommunikationsbus 108, einen beispielhaften ersten Beschleuniger 110a, einen beispielhaften zweiten Beschleuniger 110b und einen beispielhaften dritten Beschleuniger 110c ein. Jeder des beispielhaften ersten Beschleunigers 110a, des beispielhaften zweiten Beschleunigers 110b und des beispielhaften dritten Beschleunigers 110c schließt eine Vielzahl von CBBs ein, die generisch und/oder spezifisch für die Operation der jeweiligen Beschleuniger sind.
Im Beispiel aus 1 ist der Systemspeicher 102 mit dem heterogenen System 104 gekoppelt. Der Systemspeicher 102 ist ein Speicher. In 1 ist der Systemspeicher 102 eine gemeinsam genutzte Speichereinrichtung zwischen wenigstens einem vom Host-Prozessor 106, ersten Beschleuniger 110a, zweiten Beschleuniger 110b und dritten Beschleuniger 110c. Im Beispiel aus 1 ist der Systemspeicher 102 eine physikalische Speichereinrichtung, die sich lokal im Rechensystem 100 befindet; in anderen Beispielen kann der Systemspeicher 102 jedoch in Bezug auf das Rechensystem 100 extern sein und/oder anderweitig davon entfernt sein. In weiteren Beispielen kann der Systemspeicher 102 eine virtuelle Speichereinrichtung sein. Im Beispiel aus 1 ist der Systemspeicher 102 ein nichtflüchtiger Speicher (z. B. Nur-Lese-Speicher (ROM, Read-Only Memory), programmierbares ROM (PROM), löschbares PROM (EPROM, Erasable PROM), elektrisch löschbares PROM (EEPROM, Electrically Erasable PROM) usw.). In anderen Beispielen kann der Systemspeicher 102 ein nichtflüchtiges Basic-Input/Output-System (BIOS) oder eine Flash-Speichereinrichtung sein. In weiteren Beispielen kann der Systemspeicher 102 ein flüchtiger Speicher sein.
In 1 ist das heterogene System 104 mit dem Systemspeicher 102 gekoppelt. Im Beispiel aus 1 verarbeitet das heterogene System 104 eine Arbeitslast, indem die Arbeitslast auf dem Host-Prozessor 106 und/oder einem oder mehreren vom ersten Beschleuniger 110a, zweiten Beschleuniger 110b oder dritten Beschleuniger 110c ausgeführt wird. In 1 ist das heterogene System 104 ein System auf einem Chip (SoC, System-on-a-Chip). Alternativ kann das heterogene System 104 ein beliebiger anderer Typ von Rechen- oder Hardwaresystem sein.
Im Beispiel aus 1 ist der Host-Prozessor 106 ein Verarbeitungselement, das konfiguriert ist, um Anweisungen auszuführen (z. B. maschinenlesbare Anweisungen), um den Abschluss von Operationen, die mit einem Computer und/oder einer Rechenvorrichtung (z. B. dem Rechensystem 100) assoziiert sind, durchzuführen und/oder anderweitig zu ermöglichen. Im Beispiel aus 1 ist der Host-Prozessor 106 ein primäres Verarbeitungselement für das heterogene System 104 und schließt wenigstens einen Kern ein. Alternativ kann der Host-Prozessor 106 ein co-primäres Verarbeitungselement sein (z. B. in einem Beispiel, in dem mehr als eine CPU genutzt wird), während der Host-Prozessor 106 in anderen Beispielen ein sekundäres Verarbeitungselement sein kann.
Im veranschaulichten Beispiel aus 1 sind einer oder mehrere des ersten Beschleunigers 110a, zweiten Beschleunigers 110b und/oder dritten Beschleunigers 110c Verarbeitungselemente, die durch ein Programm genutzt werden können, das auf dem heterogenen System 104 für Rechenaufgaben wie Hardwarebeschleunigung ausgeführt wird. Beispielsweise ist der erste Beschleuniger 110a ein Verarbeitungselement, das Verarbeitungsressourcen einschließt, die konzipiert und/oder anderweitig konfiguriert oder strukturiert sind, um die Verarbeitungsgeschwindigkeit und die Gesamtleistung der Verarbeitung von Machine-Vision-Aufgaben für KI zu verbessern (z. B. eine VPU).
In hierin offenbarten Beispielen steht jeder des Host-Prozessors 106, des ersten Beschleunigers 110a, des zweiten Beschleunigers 110b und des dritten Beschleunigers 110c mit den anderen Elementen des Rechensystems 100 und/oder des Systemspeichers 102 in Kommunikation. Beispielsweise stehen der Host-Prozessor 106, der erste Beschleuniger 110a, der zweite Beschleuniger 110b, der dritte Beschleuniger 110c und/oder der Systemspeicher 102 über den ersten Kommunikationsbus 108 in Kommunikation. In einigen hierin offenbarten Beispielen können der Host-Prozessor 106, der erste Beschleuniger 110a, der zweite Beschleuniger 110b, der dritte Beschleuniger 110c und/oder der Systemspeicher 102 über ein beliebiges geeignetes drahtgebundenes und/oder drahtloses Kommunikationsverfahren in Kommunikation stehen. Zusätzlich kann in einigen hierin offenbarten Beispielen jeder des Host-Prozessors 106, des ersten Beschleunigers 110a, des zweiten Beschleunigers 110b, des dritten Beschleunigers 110c und/oder des Systemspeichers 102 über ein beliebiges geeignetes drahtgebundenes und/oder drahtloses Kommunikationsverfahren mit einer beliebigen Komponente extern zum Rechensystem 100 in Kommunikation stehen.
Im Beispiel aus 1 schließt der erste Beschleuniger 110a eine beispielhafte Faltungs-Engine 112, eine beispielhafte RNN-Engine 114, einen beispielhaften Speicher 116, eine beispielhafte Speicherverwaltungseinheit (MMU, Memory Management Unit) 118, einen beispielhaften digitalen Signalprozessor (DSP) 120 und eine beispielhafte Steuerung 122 ein. In hierin offenbarten Beispielen kann jedes der Faltungs-Engine 112, der RNN-Engine 114, des Speichers 116, der Speicherverwaltungseinheit (MMU, Memory Management Unit) 118, des DSP 120 und/oder der Steuerung 122 als ein CBB bezeichnet werden. Jedes von der beispielhaften Faltungs-Engine 112, der beispielhaften RNN-Engine 114, des beispielhaften Speichers 116, der beispielhaften MMU 118, des beispielhaften DSP 120 und der beispielhaften Steuerung 122 schließt wenigstens einen Scheduler ein.
Im Beispiel aus 1 ist die Faltungs-Engine 112 eine Vorrichtung, die konfiguriert ist, um die Verarbeitung von Aufgaben zu verbessern, die mit der Faltung assoziiert sind. Darüber hinaus verbessert die Faltungs-Engine 112 die Verarbeitung von Aufgaben, die mit der Analyse von visueller Imagery und/oder anderen mit CNNs assoziierten Aufgaben assoziiert sind. In 1 ist die RNN-Engine 114 eine Vorrichtung, die konfiguriert ist, um die Verarbeitung von Aufgaben zu verbessern, die mit RNNs assoziiert sind. Zusätzlich verbessert die RNN-Engine 114 die Verarbeitung von Aufgaben, die mit der Analyse von nicht segmentierter, verbundener Handschrifterkennung, Spracherkennung und/oder anderen mit RNNs assoziierten Aufgaben assoziiert sind.
Im Beispiel aus 1 ist der Speicher 116 eine gemeinsam genutzte Speichereinrichtung zwischen wenigstens einem von der Faltungs-Engine 112, der RNN-Engine 114, der MMU 118, dem DSP 120 und der Steuerung 122, einschließlich Speicherdirektzugriffs-Funktionalität (DMA, Direct Memory Access). Darüber hinaus ermöglicht der Speicher 116 wenigstens einem von der Faltungs-Engine 112, der RNN-Engine 114, der MMU 118, dem DSP 120 und der Steuerung 122, unabhängig vom Host-Prozessor 106 auf den Systemspeicher 102 zuzugreifen. Im Beispiel aus 1 ist der Speicher 116 eine physikalische Speichereinrichtung, die sich lokal im ersten Beschleuniger 100a befindet; in anderen Beispielen kann der Speicher 116 jedoch in Bezug auf den ersten Beschleuniger 110a extern sein und/oder anderweitig davon entfernt sein. In weiteren Beispielen kann der Speicher 116 eine virtuelle Speichereinrichtung sein. Im Beispiel aus 1 ist der Speicher 116 eine persistente Speichereinrichtung (z. B. Nur-Lese-Speicher (ROM, Read-Only Memory), programmierbares ROM (PROM), löschbares PROM (EPROM, Erasable PROM), elektrisch löschbares PROM (EEPROM, Electrically Erasable PROM) usw.). In anderen Beispielen kann der Speicher 116 ein persistentes Basic-Input/Output-System (BIOS) oder eine Flash-Speichereinrichtung sein. In weiteren Beispielen kann der Speicher 116 ein flüchtiger Speicher sein.
Im Beispiel aus 1 ist die beispielhafte MMU 118 eine Vorrichtung, die Verweise auf alle Adressen des Speichers 116 und/oder des Systemspeichers 102 einschließt. Die MMU 118 übersetzt zusätzlich virtuelle Speicheradressen, die von einem oder mehreren von der Faltungs-Engine 112, der RNN-Engine 114, dem DSP 120 und/oder der Steuerung 122 genutzt werden, in physikalische Adressen im Speicher 116 und/oder im Systemspeicher 102.
Im Beispiel aus 1 ist der DSP 120 eine Vorrichtung, die die Verarbeitung digitaler Signale verbessert. Beispielsweise ermöglicht der DSP 120 die Verarbeitung zum Messen, Filtern und/oder Komprimieren kontinuierlicher Signale aus der realen Welt wie Daten von Kameras und/oder anderen Sensoren im Zusammenhang mit Computer Vision. In 1 ist die Steuerung 122 als eine Steuereinheit des ersten Beschleunigers 110a implementiert. Beispielsweise steuert die Steuerung 122 die Operation des ersten Beschleunigers 110a. In einigen Beispielen implementiert die Steuerung 122 einen Credit-Manager. Darüber hinaus kann die Steuerung 122 eines oder mehrere von der Faltungs-Engine 112, der RNN-Engine 114, dem Speicher 116, der MMU 118 und/oder dem DSP 120 anweisen, wie auf maschinenlesbare Anweisungen zu reagieren ist, die vom Host-Prozessor 106 empfangen werden.
Im Beispiel aus 1 schließen die Faltungs-Engine 112, die RNN-Engine 114, der Speicher 116, die MMU 118, der DSP 120 und die Steuerung 122 einen jeweiligen Scheduler ein, um zu bestimmen, wann jedes von der Faltungs-Engine 112, der RNN-Engine 114, dem Speicher 116, der MMU 118, dem DSP 120 und der Steuerung 122 jeweils einen Teil einer Arbeitslast ausführt, die abgeladen wurde und/oder anderweitig an den ersten Beschleuniger 110a gesendet wurde.
In hierin offenbarten Beispielen steht jedes von der Faltungs-Engine 112, der RNN-Engine 114, dem Speicher 116, der MMU 118, dem DSP 120 und der Steuerung 122 mit den anderen Elementen des ersten Beschleunigers 110a in Kommunikation. Beispielsweise stehen die Faltungs-Engine 112, die RNN-Engine 114, der Speicher 116, die MMU 118, der DSP 120 und die Steuerung 122 über einen beispielhaften zweiten Kommunikationsbus 140 in Kommunikation. In einigen Beispielen kann der zweite Kommunikationsbus 140 durch eine Computing Fabric implementiert werden. In einigen hierin offenbarten Beispielen können die Faltungs-Engine 112, die RNN-Engine 114, der Speicher 116, die MMU 118, der DSP 120 und die Steuerung 122 über ein beliebiges geeignetes drahtgebundenes und/oder drahtloses Kommunikationsverfahren in Kommunikation stehen. Zusätzlich können in einigen hierin offenbarten Beispielen jedes von der Faltungs-Engine 112, der RNN-Engine 114, dem Speicher 116, der MMU 118, dem DSP 120 und der Steuerung 122 über ein beliebiges geeignetes drahtgebundenes und/oder drahtloses Kommunikationsverfahren mit einer beliebigen Komponente extern zum ersten Beschleuniger 110a in Kommunikation stehen.
Wie zuvor erwähnt, kann jeder des beispielhaften ersten Beschleunigers 110a, des beispielhaften zweiten Beschleunigers 110b und/oder des beispielhaften dritten Beschleunigers 110c eine Vielzahl von CBBs einschließen, die entweder generisch und/oder spezifisch für die Operation der jeweiligen Beschleuniger sind. Beispielsweise schließt jeder des ersten Beschleunigers 110a, des zweiten Beschleunigers 110b und des dritten Beschleunigers 110c generische CBBs wie Speicher, eine MMU, eine Steuerung und jeweilige Scheduler für jeden der CBBs ein. Zusätzlich oder alternativ können externe CBBs, die in keinem des ersten Beschleunigers 110a, des beispielhaften zweiten Beschleunigers 110b und/oder des beispielhaften dritten Beschleunigers 110c angeordnet sind, eingeschlossen sein und/oder hinzugefügt werden. Beispielsweise kann ein Benutzer des Rechensystems 100 eine externe RNN-Engine betreiben, die einen beliebigen von dem ersten Beschleuniger 110a, dem zweiten Beschleuniger 110b und/oder dem dritten Beschleuniger 110c nutzt.
Obgleich der erste Beschleuniger 110a im Beispiel aus 1 eine VPU implementiert und die Faltungs-Engine 112, die RNN-Engine 114 und den DSP 120 einschließt (z. B. CBBs, die für die Operation des ersten Beschleunigers 110a spezifisch sind), können der zweite Beschleuniger 110b und der dritte Beschleuniger 110c zusätzliche oder alternative CBBs einschließen, die für die Operation des zweiten Beschleunigers 110b und/oder des dritten Beschleunigers 110c spezifisch sind. Falls beispielsweise der zweite Beschleuniger 110b eine GPU implementiert, können die CBBs, die für die Operation des zweiten Beschleunigers 110b spezifisch sind, einen Thread-Dispatcher, eine Grafiktechnologie-Schnittstelle und/oder einen anderen CBB einschließen, der wünschenswert ist, um die Verarbeitungsgeschwindigkeit und die Gesamtleistung der Verarbeitung von Computergrafiken und/oder Bildverarbeitung zu verbessern. Falls der dritte Beschleuniger 110c ein FPGA implementiert, können die CBBs, die für die Operation des dritten Beschleunigers 110c spezifisch sind, darüber hinaus eine oder mehrere arithmetische Logikeinheiten (ALUs, Arithmetic Logic Units) und/oder einen anderen CBB einschließen, der wünschenswert ist, um die Verarbeitungsgeschwindigkeit und die Gesamtleistung der Verarbeitung von allgemeinen Berechnungen zu verbessern.
Obgleich das heterogene System 104 aus 1 den Host-Prozessor 106, den ersten Beschleuniger 110a, den zweiten Beschleuniger 110b und den dritten Beschleuniger 110c einschließt, kann das heterogene System 104 in einigen Beispielen eine beliebige Anzahl von Verarbeitungselementen (z. B. Host-Prozessoren und/oder Beschleuniger) einschließen, einschließlich anwendungsspezifischer Befehlssatzprozessoren (ASIPs, Application-Specific Instruction Set Processors), Physikbeschleuniger (PPUs, Physics Processing Units), designierter DSPs, Bildprozessoren, Koprozessoren, Gleitkommaeinheiten, Netzprozessoren, Mehrkernprozessoren und Front-End-Prozessoren.
2 ist ein Blockschaltbild, das ein beispielhaftes Rechensystem 200 veranschaulicht, das eine beispielhafte Eingabe 202, einen beispielhaften Compiler und einen beispielhaften Beschleuniger 206 einschließt. In 2 ist die Eingabe 202 mit dem Compiler 204 gekoppelt. Die Eingabe 202 ist eine Arbeitslast, die vom Beschleuniger 206 ausgeführt werden soll.
Im Beispiel aus 2 ist die Eingabe 202 beispielsweise eine Funktion, ein Algorithmus, ein Programm, eine Anwendung und/oder ein anderer Code, der vom Beschleuniger 206 ausgeführt werden soll. In einigen Beispielen ist die Eingabe 202 eine graphische Beschreibung einer Funktion, eines Algorithmus, eines Programms, einer Anwendung und/oder eines anderen Codes. In zusätzlichen oder alternativen Beispielen ist die Eingabe 202 eine Arbeitslast im Zusammenhang mit der KI-Verarbeitung, wie beispielsweise tiefes Lernen und/oder Computer Vision.
Im veranschaulichten Beispiel aus 2 ist der Compiler 204 mit der Eingabe 202 und dem Beschleuniger 206 gekoppelt. Der Compiler 204 empfängt die Eingabe 202 und kompiliert die Eingabe 202 in eine oder mehrere ausführbare Dateien, die durch den Beschleuniger 206 ausgeführt werden sollen. Beispielsweise ist der Compiler 204 ein Graph-Compiler, der die Eingabe 202 empfängt und verschiedene Arbeitslastknoten der Arbeitslast (z. B. die Eingabe 202) verschiedenen CBBs des Beschleunigers 206 zuweist. Zusätzlich weist der Compiler 204 Speicher für einen oder mehrere Puffer im Speicher des Beschleunigers 206 zu. Beispielsweise bestimmt der Compiler 204 den Ort und die Größe (z. B. Anzahl von Slots und Anzahl von Bits, die in jedem Slot gespeichert werden können) der Puffer im Speicher. Auf diese Weise wird eine ausführbare Datei der vom Compiler 204 kompilierten ausführbaren Dateien die Puffereigenschaften einschließen. Im veranschaulichten Beispiel aus 2 wird der Compiler 204 durch eine Logikschaltung, wie beispielsweise einen Hardwareprozessor, implementiert. Es kann jedoch jeder andere Typ von Schaltung zusätzlich oder alternativ verwendet werden, wie beispielsweise eine oder mehrere analoge oder digitale Schaltungen, Logikschaltungen, programmierbare Prozessoren, anwendungsspezifische integrierte Schaltungen (ASIC(s), Application-Specific Integrated Circuit(s)), programmierbare Logikvorrichtungen (PLD(s), Programmable Logic Device(s)), feldprogrammierbare Logikvorrichtungen (FPLD(s), Field-Programmable Logic Device(s)), DSP(s) usw.
Während des Betriebs empfängt der Compiler 204 die Eingabe 202 und kompiliert die Eingabe 202 (z. B. Arbeitslast) in eine oder mehrere ausführbare Dateien, die durch den Beschleuniger 206 ausgeführt werden sollen. Beispielsweise empfängt der Compiler 204 die Eingabe 202 und weist verschiedenen CBBs (z. B. einem beliebigen von der Faltungs-Engine 214, der MMU 216, der RNN-Engine 218, dem DSP 220 und/oder der DMA 226) des Beschleunigers 206 verschiedene Arbeitslastknoten der Eingabe 202 (z. B. der Arbeitslast) zu. Zusätzlich weist der Compiler 204 Speicher für einen oder mehrere Puffer 228 im Speicher 222 des Beschleunigers 206 zu.
Im Beispiel aus 2 schließt der Beschleuniger 206 eine beispielhafte Konfigurationssteuerung 208, einen beispielhaften Credit-Manager 210, eine beispielhafte Fabric zur Steuerung und Konfiguration (CnC, Control and Configure) 212, eine beispielhafte Faltungs-Engine 214, eine beispielhafte MMU 216, eine beispielhafte RNN-Engine 218, einen beispielhaften DSP 220, einen beispielhaften Speicher 222 und eine beispielhafte Daten-Fabric 232 ein. Im Beispiel aus 2 schließt der Speicher 222 eine beispielhafte DMA-Einheit 226 und einen oder mehrere beispielhafte Puffer 228 ein.
Im Beispiel aus 2 ist die Konfigurationssteuerung 208 mit dem Compiler 204, der CnC-Fabric 212 und der Daten-Fabric 232 gekoppelt. In hierin offenbarten Beispielen ist die Konfigurationssteuerung 208 als eine Steuereinheit des Beschleunigers 206 implementiert. In hierin offenbarten Beispielen erhält die Konfigurationssteuerung 208 die ausführbare Datei vom Compiler 204 und stellt den verschiedenen CBBs Konfigurations- und Steuernachrichten bereit, um die Aufgaben der Eingabe 202 (z. B. Arbeitslast) durchzuführen. In einem derartigen hierin offenbarten Beispiel können die Konfigurations- und Steuernachrichten durch die Konfigurationssteuerung 208 generiert und an die verschiedenen CBBs und/oder Kernels 230, die sich im DSP 220 befinden, gesendet werden. Beispielsweise parst die Konfigurationssteuerung 208 die Eingabe 202 (z. B. ausführbare Datei, Arbeitslast usw.) und weist eines oder mehrere von der Faltungs-Engine 214, der MMU 216, der RNN-Engine 218, dem DSP 220, den Kerneln 230 und/oder dem Speicher 222 an, wie auf die Eingabe 202 und/oder andere maschinenlesbare Anweisungen zu reagieren ist, die vom Compiler 204 über den Credit-Manager 210 empfangen werden.
Zusätzlich wird die Konfigurationssteuerung 208 mit Puffereigenschaftsdaten von den ausführbaren Dateien des Compilers 204 bereitgestellt. Auf diese Weise initialisiert die Konfigurationssteuerung 208 die Puffer (z. B. den Puffer 228) im Speicher auf die in den ausführbaren Dateien angegebene Größe. In einigen Beispielen stellt die Konfigurationssteuerung 208 Konfigurationssteuernachrichten an einen oder mehrere CBBs bereit, einschließlich der Größe und des Orts jedes durch die Konfigurationssteuerung 208 initialisierten Puffers.
Im Beispiel aus 2 ist der Credit-Manager 210 mit der CnC-Fabric 212 und der Daten-Fabric 232 gekoppelt. Der Credit-Manager 210 ist eine Vorrichtung, die Credits verwaltet, die mit einem oder mehreren von der Faltungs-Engine 214, der MMU 216, der RNN-Engine 218 und/oder dem DSP 220 assoziiert sind. In einigen Beispielen kann der Credit-Manager 210 von einer Steuerung als Credit-Manager-Steuerung implementiert werden. Credits sind repräsentativ für Daten, die mit Arbeitslastknoten assoziiert sind, die im Speicher 222 verfügbar sind, und/oder für die Menge an Platz, die im Speicher 222 für die Ausgabe des Arbeitslastknotens verfügbar ist. Beispielsweise können der Credit-Manager 210 und/oder die Konfigurationssteuerung 208 den Speicher 222 in einen oder mehrere Puffer (z. B. die Puffer 228) partitionieren, die mit jedem Arbeitslastknoten einer gegebenen Arbeitslast assoziiert sind, basierend auf der einen oder den mehreren ausführbaren Dateien, die vom Compiler 204 empfangen werden.
In hierin offenbarten Beispielen stellt der Credit-Manager 210 in Reaktion auf Anweisungen, die von der Konfigurationssteuerung 208 empfangen werden und anzeigen, dass ein bestimmter Arbeitslastknoten ausgeführt werden soll, dem CBB, der als der anfängliche Produzent fungiert, entsprechende Credits bereit. Sobald der CBB, der als der anfängliche Produzent fungiert, den Arbeitslastknoten abschließt, werden die Credits an den Ursprungspunkt aus Sicht des CBB zurückgesendet (z. B. Credit-Manager 210). Der Credit-Manager 210 sendet in Reaktion auf das Erhalten der Credits vom Produzenten die Credits an den CBB, der als der Konsument fungiert. Eine derartige Reihenfolge von Produzent und Konsumenten wird unter Verwendung der ausführbaren Datei bestimmt, die vom Compiler 204 generiert wird und der Konfigurationssteuerung 208 bereitgestellt wird. Auf diese Weise kommunizieren die CBBs eine Anzeige der Fähigkeit, über den Credit-Manager 210 zu arbeiten, unabhängig von ihrer heterogenen Natur. Ein Produzenten-CBB produziert Daten, die von einem anderen CBB genutzt werden, während ein Konsumenten-CBB Daten, die von einem anderen CBB produziert werden, konsumiert und/oder auf andere Weise verarbeitet. Der Credit-Manager 210 wird nachstehend in Verbindung mit 3 detaillierter erörtert.
Im Beispiel aus 2 ist die CnC-Fabric 212 mit dem Credit-Manager 210, der Faltungs-Engine 214, der MMU 216, der RNN-Engine 218, dem DSP 220, dem Speicher 222, der Konfigurationssteuerung 208 und der Daten-Fabric 232 gekoppelt. Die CnC-Fabric 212 ist ein Netz von Drähten und wenigstens einer Logikschaltung, die einem oder mehreren von dem Credit-Manager 210, der Faltungs-Engine 214, der MMU 216, der RNN-Engine 218 und/oder dem DSP 220 ermöglichen, Credits an einen oder mehrere von dem Credit-Manager 210, der Faltungs-Engine 214, der MMU 216, der RNN-Engine 218, dem DSP 220, dem Speicher 222 und/oder der Konfigurationssteuerung 208 zu senden und/oder von diesen zu empfangen. Zusätzlich ist die CnC-Fabric 212 konfiguriert, um beispielhafte Konfigurations- und Steuernachrichten an den und/oder von dem einen oder den mehreren Selektoren zu senden. In anderen hierin offenbarten Beispielen kann eine beliebige geeignete Rechen-Fabric verwendet werden, um die CnC-Fabric 212 zu implementieren (z. B. ein Advanced eXtensible Interface (AXI) usw.).
Im veranschaulichten Beispiel aus 2 ist die Faltungs-Engine 214 mit der CnC-Fabric 212 und der Daten-Fabric 232 gekoppelt. Die Faltungs-Engine 214 ist eine Vorrichtung, die konfiguriert ist, um die Verarbeitung von Aufgaben zu verbessern, die mit einer Faltung assoziiert sind. Darüber hinaus verbessert die Faltungs-Engine 214 die Verarbeitung von Aufgaben, die mit der Analyse von visueller Imagery und/oder anderen mit CNNs assoziierten Aufgaben assoziiert sind.
Im veranschaulichten Beispiel aus 2 ist die beispielhafte MMU 216 mit der CnC-Fabric 212 und der Daten-Fabric 232 gekoppelt. Die MMU 216 ist eine Vorrichtung, die Verweise auf alle Adressen des Speichers 222 und/oder einen Speicher einschließt, der in Bezug auf den Beschleuniger 206 entfernt ist. Die MMU 216 übersetzt zusätzlich virtuelle Speicheradressen, die von einem oder mehreren von dem Credit-Manager 210, der Faltungs-Engine 214, der RNN-Engine 218 und/oder dem DSP 220 genutzt werden, in physikalische Adressen im Speicher 222 und/oder im Speicher, der in Bezug auf den Beschleuniger 206 entfernt ist.
In 2 ist die RNN-Engine 218 mit der CnC-Fabric 212 und der Daten-Fabric 232 gekoppelt. Die RNN-Engine 218 ist eine Vorrichtung, die konfiguriert ist, um die Verarbeitung von Aufgaben zu verbessern, die mit RNNs assoziiert sind. Zusätzlich verbessert die RNN-Engine 218 die Verarbeitung von Aufgaben, die mit der Analyse von nicht segmentierter, verbundener Handschrifterkennung, Spracherkennung und/oder anderen mit RNNs assoziierten Aufgaben assoziiert sind.
Im Beispiel aus 2 ist der DSP 220 mit der CnC-Fabric 212 und der Daten-Fabric 232 gekoppelt. Der DSP 220 ist eine Vorrichtung, die die Verarbeitung digitaler Signale verbessert. Beispielsweise ermöglicht der DSP 220 die Verarbeitung zum Messen, Filtern und/oder Komprimieren kontinuierlicher Signale aus der realen Welt wie Daten von Kameras und/oder anderen Sensoren im Zusammenhang mit Computer Vision.
Im Beispiel aus 2 ist der Speicher 222 mit der CnC-Fabric 212 und der Daten-Fabric 232 gekoppelt. Der Speicher 222 ist eine gemeinsam genutzte Speichereinrichtung zwischen wenigstens einem von dem Credit-Manager 210, der Faltungs-Engine 214, der MMU 216, der RNN-Engine 218, dem DSP 220 und/oder der Konfigurationssteuerung 208. Der Speicher 222 schließt die DMA-Einheit 226 ein. Zusätzlich kann der Speicher 222 in den einen oder die mehreren Puffer 228 partitioniert werden, die mit einem oder mehreren Arbeitslastknoten einer Arbeitslast assoziiert sind, die mit einer ausführbaren Datei assoziiert ist, die von der Konfigurationssteuerung 208 und/oder dem Credit-Manager 210 empfangen wird. Darüber hinaus ermöglicht die DMA-Einheit 226 des Speichers 222 wenigstens einem von dem Credit-Manager 210, der Faltungs-Engine 214, der MMU 216, der RNN-Engine 218, dem DSP 220 und/oder der Konfigurationssteuerung 208, unabhängig von einem jeweiligen Prozessor (z. B. dem Host-Prozessor 106) auf einen vom Beschleuniger 206 entfernten Speicher (z. B. den Systemspeicher 102) zuzugreifen. Im Beispiel aus 2 ist der Speicher 222 eine physikalische Speichereinrichtung, die sich lokal im Beschleuniger 206 befindet. Zusätzlich oder alternativ kann der Speicher 222 in anderen Beispielen in Bezug auf den Beschleuniger 206 extern sein und/oder anderweitig davon entfernt sein. In weiteren hierin offenbarten Beispielen kann der Speicher 222 eine virtuelle Speichereinrichtung sein. Im Beispiel aus 2 ist der Speicher 222 eine nichtflüchtige Speichereinrichtung (z. B. ROM, PROM, EPROM, EEPROM usw.). In anderen Beispielen kann der Speicher 222 ein persistentes BIOS oder eine Flash-Speichereinrichtung sein. In weiteren Beispielen kann der Speicher 222 ein flüchtiger Speicher sein.
Im veranschaulichten Beispiel aus 2 ist die Kernel-Bibliothek 230 eine Datenstruktur, die einen oder mehrere Kernels einschließt. Die Kernels der Kernel-Bibliothek 230 sind beispielsweise Routinen, die für einen hohen Durchsatz auf dem DSP 220 kompiliert wurden. In anderen hierin offenbarten Beispielen kann jeder CBB (z. B. ein beliebiges von der Faltungs-Engine 214, der MMU 216, der RNN-Engine 218 und/oder dem DSP 220) eine jeweilige Kernel-Bank einschließen. Die Kernels entsprechen beispielsweise ausführbaren Unterabschnitten einer ausführbaren Datei, die auf dem Beschleuniger 206 ausgeführt werden soll. Obgleich der Beschleuniger 206 im Beispiel aus 2 eine VPU implementiert und den Credit-Manager 210, die CnC-Fabric 212, die Faltungs-Engine 214, die MMU 216, die RNN-Engine 218, den DSP 220, den Speicher 222 und die Konfigurationssteuerung 208 einschließt, kann der Beschleuniger 206 zusätzliche oder alternative CBBs zu den in 2 veranschaulichten einschließen.
Im Beispiel aus 2 ist die Daten-Fabric 232 mit dem Credit-Manager 210, der Faltungs-Engine 214, der MMU 216, der RNN-Engine 218, dem DSP 220, dem Speicher 222 und der CnC-Fabric 212 gekoppelt. Die Daten-Fabric 232 ist ein Netz von Drähten und wenigstens einer Logikschaltung, die einem oder mehreren von dem Credit-Manager 210, der Faltungs-Engine 214, der MMU 216, der RNN-Engine 218 und/oder dem DSP 220 ermöglichen, Daten auszutauschen. Beispielsweise ermöglicht die Daten-Fabric 232 einem Produzenten-CBB, Kacheln von Daten in Puffer eines Speichers zu schreiben, wie beispielsweise des Speichers 222 und/oder der Speicher, die in einem oder mehreren von der Faltungs-Engine 214, der MMU 216, der RNN-Engine 218 und dem DSP 220 angeordnet sind. Zusätzlich ermöglicht die Daten-Fabric 232 einem konsumierenden CBB, Kacheln von Daten aus Puffern eines Speichers zu lesen, wie beispielsweise des Speichers 222 und/oder der Speicher, die in einem oder mehreren von der Faltungs-Engine 214, der MMU 216, der RNN-Engine 218 und dem DSP 220 angeordnet sind. Die Daten-Fabric 232 überträgt Daten abhängig von den im Datenpaket bereitgestellten Informationen zum und vom Speicher. Beispielsweise können Daten durch Paketverfahren übertragen werden, wobei ein Paket einen Header, eine Nutzlast und einen Trailer einschließt. Der Header eines Pakets ist die Zieladresse der Daten, die Quelladresse der Daten, der Typ des Protokolls, mit dem die Daten gesendet werden, und eine Paketnummer. Die Nutzlast sind die Daten, die das CBB produziert oder konsumiert. Die Daten-Fabric 232 kann den Datenaustausch zwischen CBBs basierend auf dem Header des Pakets durch Analysieren einer beabsichtigten Zieladresse ermöglichen.
3 ist ein beispielhaftes Blockschaltbild des Credit-Managers 210 aus 2. Im Beispiel aus 3 schließt der Credit-Manager 210 einen beispielhaften Kommunikationsprozessor 302, einen beispielhaften Credit-Generator 304, einen beispielhaften Zähler 306, einen beispielhaften Quellenidentifikator 308, einen beispielhaften Duplikator 310 und einen beispielhaften Aggregator 312 ein. Der Credit-Manager 210 ist konfiguriert, um mit der CnC-Fabric 212 und der Daten-Fabric 232 aus 2 zu kommunizieren, kann aber so konfiguriert sein, dass er direkt mit verschiedenen CBBs (z. B. der Konfigurationssteuerung 208, der Faltungs-Engine 214, der MMU 216, der RNN-Engine 218 und/oder dem DSP 220) gekoppelt ist.
Im Beispiel aus 3 schließt der Credit-Manager 210 den Kommunikationsprozessor 302 ein, der mit dem Credit-Generator 304, dem Zähler 306, dem Quellenidentifikator 308, dem Duplikator 310 und/oder dem Aggregator 312 gekoppelt ist. Der Kommunikationsprozessor ist eine Hardware, die Aktionen basierend auf empfangenen Informationen ausführt. Beispielsweise stellt der Kommunikationsprozessor 302 Anweisungen für wenigstens jeden von dem Credit-Generator 304, dem Zähler 306, dem Quellenidentifikator 308, dem Duplikator 310 und dem Aggregator 312 basierend auf den durch die Konfigurationssteuerung 208 aus 2 empfangenen Daten, wie beispielsweise Konfigurationsinformationen, bereit. Derartige Konfigurationsinformationen schließen Puffereigenschaftsinformationen ein. Beispielsweise schließen Puffereigenschaftsinformationen die Größe des Puffers, wohin der Zeiger zeigen soll, den Ort des Puffers usw. ein. Der Kommunikationsprozessor 302 kann Informationen wie Credits verpacken, um sie einem Produzenten-CBB und/oder einem Konsumenten-CBB bereitzustellen. Zusätzlich steuert der Kommunikationsprozessor 302, wohin Daten vom Credit-Manager 210 ausgegeben werden sollen. Beispielsweise empfängt der Kommunikationsprozessor 302 Informationen, Anweisungen, eine Benachrichtigung usw. vom Credit-Generator 304, die anzeigen, dass dem Produzenten-CBB Credits bereitgestellt werden sollen.
In einigen Beispielen empfängt der Kommunikationsprozessor 302 Konfigurationsinformationen von einem produzierenden CBB. Beispielsweise bestimmt ein produzierender CBB während der Ausführung einer Arbeitslast den aktuellen Slot eines Puffers und stellt dem Kommunikationsprozessor 302 eine Benachrichtigung zur Verwendung beim Initialisieren der Generierung einer Anzahl von Credits bereit. In einigen Beispielen kann der Kommunikationsprozessor 302 Informationen zwischen dem Credit-Generator 304, dem Zähler 306, dem Quellenidentifikator 308, dem Duplikator 310 und/oder dem Aggregator 312 kommunizieren. Beispielsweise initiiert der Kommunikationsprozessor 302 den Duplikator 310 oder den Aggregator 312 abhängig von der Identifikation des Quellenidentifikators 308. Zusätzlich empfängt der Kommunikationsprozessor 302 Informationen, die einer Arbeitslast entsprechen. Beispielsweise empfängt der Kommunikationsprozessor 302 über die CnC-Fabric 212 Informationen, die vom Compiler 204 und der Konfigurationssteuerung 208 bestimmt werden und die indikativ für den als Produzenten initialisierten CBB und die als Konsumenten initialisierten CBBs sind. Der beispielhafte Kommunikationsprozessor 302 aus 3 kann Mittel zum Kommunizieren implementieren.
Im Beispiel aus 3 schließt der Credit-Manager 210 den Credit-Generator 304 ein, um einen Credit oder eine Mehrzahl von Credits basierend auf Informationen zu generieren, die von der Zentrums-Fabric 212 aus 2 empfangen werden. Beispielsweise wird der Credit-Generator 304 initialisiert, wenn der Kommunikationsprozessor 302 Informationen empfängt, die der Initialisierung eines Puffers (z. B. des Puffers 228 aus 2) entsprechen. Derartige Informationen können eine Größe und eine Anzahl von Slots des Puffers (z. B. Speichergröße) einschließen. Der Credit-Generator 304 generiert eine Anzahl n von Credits basierend auf der Anzahl n von Slots im Puffer. Die Anzahl n von Credits ist daher indikativ für eine verfügbare Anzahl n von Plätzen in einem Speicher, in den ein CBB schreiben oder aus dem es lesen kann. Der Credit-Generator 304 stellt dem Kommunikationsprozessor die Anzahl n von Credits zum Verpacken und Senden an einen entsprechenden Produzenten bereit, bestimmt durch die Konfigurationssteuerung 208 aus 2 und über die CnC-Fabric 212 kommuniziert. Der beispielhafte Credit-Generator 304 aus 3 kann Mittel zum Generieren implementieren.
Im Beispiel aus 3 schließt der Credit-Manager 210 den Zähler 306 ein, um die Steuerung der Credit-Menge bei jedem Produzenten oder Konsumenten zu unterstützen. Beispielsweise kann der Zähler 306 eine Mehrzahl von Zählern einschließen, wobei jeder der Mehrzahl von Zählern einem Produzenten und einem oder mehreren Konsumenten zugewiesen ist. Ein einem Produzenten zugewiesener Zähler (z. B. ein Produzenten-Credit-Zähler) wird vom Zähler 306 gesteuert, wobei der Zähler 306 einen Produzenten-Credit-Zähler auf Null initialisiert, wenn für den Produzenten keine Credits verfügbar sind. Ferner inkrementiert der Zähler 306 den Produzenten-Credit-Zähler, wenn der Credit-Generator 304 Credits für den entsprechenden Produzenten generiert. Zusätzlich dekrementiert der Zähler 306 den Produzenten-Credit-Zähler, wenn der Produzent einen Credit verwendet (z. B. wenn der Produzent Daten in einen Puffer wie den Puffer 228 aus 2 schreibt). Der Zähler 306 kann einen oder mehrere Konsumenten-Credit-Zähler auf ähnliche Weise wie die Produzenten-Credit-Zähler initialisieren. Zusätzlich und/oder alternativ kann der Zähler 306 interne Zähler jedes CBB initialisieren. Beispielsweise kann der Zähler 306 kommunikativ mit der beispielhaften Faltungs-Engine 214, der beispielhaften MMU 216, der beispielhaften RNN-Engine 218 und dem beispielhaften DSP 220 gekoppelt sein. Auf diese Weise steuert der Zähler 306 interne Zähler, die an jedem von der Faltungs-Engine 214, der MMU 216, der RNN-Engine 218 und/oder dem DSP 220 angeordnet sind.
Im Beispiel aus 3 schließt der Credit-Manager 210 den Quellenidentifikator 308 ein, um zu identifizieren, woher eingehende Credits stammen. Beispielsweise analysiert der Quellenidentifikator 308 in Reaktion darauf, dass der Kommunikationsprozessor 302 einen oder mehrere Credits über die CnC-Fabric 212 empfängt, eine Nachricht, eine Anweisung, Metadaten usw., um zu bestimmen, ob der Credit von einem Produzenten oder einem Konsumenten stammt. Der Quellenidentifikator 308 kann bestimmen, ob der empfangene Credit von der Faltungs-Engine 214 stammt, indem die Aufgabe oder ein Teil einer Aufgabe analysiert wird, die mit dem empfangenen Credit und der Faltungs-Engine 214 assoziiert ist. In anderen Beispielen identifiziert der Quellenidentifikator 308 nur, ob der Credit von einem Produzenten oder einem Konsumenten bereitgestellt wurde, indem Informationen aus der Konfigurationssteuerung 208 extrahiert werden. Wenn ein CBB der CnC-Fabric 212 einen Credit bereitstellt, kann der CBB zusätzlich eine entsprechende Nachricht oder ein entsprechendes Tag, wie beispielsweise einen Header, bereitstellen, die bzw. das identifiziert, woher der Credit stammt. Der Quellenidentifikator 308 initialisiert den Duplikator 310 oder den Aggregator 312 über den Kommunikationsprozessor 302 basierend darauf, woher der empfangene Credit stammt. Der beispielhafte Quellenidentifikator 308 aus 3 kann Mittel zum Analysieren implementieren.
Im Beispiel aus 3 schließt der Credit-Manager 210 den Duplikator 310 ein, um einen Credit mit einem Faktor von m zu multiplizieren, wobei m einer Anzahl von entsprechenden Konsumenten entspricht. Beispielsweise wurde eine Anzahl m von Konsumenten durch die Konfigurationssteuerung 208 aus 2 bestimmt und in den Konfigurationsinformationen bereitgestellt, als die Arbeitslast als eine ausführbare Datei kompiliert wurde. Der Kommunikationsprozessor 302 empfängt die Informationen, die dem Produzenten-CBB und den Konsumenten-CBBs entsprechen, und stellt dem Duplikator 310 relevante Informationen bereit, beispielsweise wie viele Konsumenten Daten aus dem Puffer (z. B. dem Puffer 228 aus 2) konsumieren. Der Quellenidentifikator 308 arbeitet auf eine Weise, die die Initialisierung des Duplikators 310 steuert. Wenn beispielsweise der Quellenidentifikator 308 bestimmt, dass die Quelle eines empfangenen Credits von einem Produzenten stammt, benachrichtigt der Kommunikatorprozessor 302 den Duplikator 310, dass ein Produzenten-Credit empfangen wurde, und dem/den Konsumenten kann ein Credit bereitgestellt werden. Auf diese Weise multipliziert der Duplikator den einen Produzenten-Credit mit einer Anzahl m von Konsumenten, um jedem Konsumenten einen Credit bereitzustellen. Falls es beispielsweise zwei Konsumenten gibt, multipliziert der Duplikator 310 jeden empfangenen Produzenten-Credit mit 2, wobei einer der beiden Credits dem ersten Konsumenten bereitgestellt wird und der zweite der beiden Credits dem zweiten Konsumenten bereitgestellt wird. Der beispielhafte Duplikator 310 aus 3 kann Mittel zum Duplizieren implementieren.
Im Beispiel aus 3 schließt der Credit-Manager 210 den Aggregator 312 ein, um Konsumenten-Credits zu aggregieren, um einen Produzenten-Credit zu generieren. Der Aggregator 312 wird durch den Quellenidentifikator 308 initialisiert. Der Quellenidentifikator 308 bestimmt, wann ein oder mehrere Konsumenten dem Credit-Manager 210 einen Credit bereitstellen, und initialisiert den Aggregator 312. In einigen Beispielen wird der Aggregator 312 nicht benachrichtigt, Credits zu aggregieren, bis jeder Konsument einen Credit genutzt hat, der dem gleichen verfügbaren Platz im Puffer entspricht. Falls beispielsweise zwei Konsumenten jeweils einen Credit zum Lesen von Daten aus einem ersten Platz in einem Puffer haben und nur der erste Konsument den Credit genutzt hat (z. B. Daten aus dem ersten Platz im Puffer konsumiert/gelesen hat), wird der Aggregator 312 nicht initialisiert. Ferner wird der Aggregator 312 initialisiert, wenn der zweite Konsument den Credit nutzt (z. B. die Daten aus dem ersten Platz im Puffer konsumiert/liest). Auf diese Weise kombiniert der Aggregator 312 die beiden Credits zu einem einzelnen Credit und stellt dem Kommunikatorprozessor 302 den Credit zum Senden an den Produzenten bereit.
In hierin offenbarten Beispielen wartet der Aggregator 312 darauf, alle Credits für einen einzelnen Platz in einem Puffer zu empfangen, da der Platz im Puffer erst obsolet ist, wenn die Daten dieses Platzes im Puffer von allen geeigneten Konsumenten konsumiert wurden. Der Datenverbrauch wird durch die Arbeitslast bestimmt, so dass die Arbeitslast entscheidet, welcher CBB Daten konsumieren muss, um die Arbeitslast in der beabsichtigten Weise auszuführen. Auf diese Weise fragt der Aggregator 312 den Zähler 306 ab, um zu bestimmen, wann die mehreren zurückgegebenen Credits zu einem einzelnen Produzenten-Credit kombiniert werden sollen. Beispielsweise kann der Zähler 306 einen Slot-Credit-Zähler steuern. Der Slot-Credit-Zähler kann indikativ für eine Anzahl von Credits sein, die einem Slot im Puffer entsprechen. Falls der Slot-Credit-Zähler gleich der Anzahl m von Konsumenten der Arbeitslast ist, kann der Aggregator 312 die Credits kombinieren, um den einzelnen Produzenten-Credit zu generieren. Zusätzlich kann der Produzent in einigen Beispielen, wenn die Ausführung einer Arbeitslast abgeschlossen ist, zusätzliche Credits haben, die nicht verwendet wurden. Auf diese Weise setzt der Aggregator 312 Credits beim Produzenten auf Null, indem die zusätzlichen Credits vom Produzenten entfernt werden. Der beispielhafte Aggregator 312 aus 3 kann Mittel zum Aggregieren implementieren.
Obgleich eine beispielhafte Art der Implementierung des Credit-Managers aus 2 in 3 veranschaulicht ist, können eines oder mehrere der in 3 veranschaulichten Elemente, Prozesse und/oder Vorrichtungen auf eine beliebige andere Weise kombiniert, geteilt, neu angeordnet, weggelassen, eliminiert und/oder implementiert werden. Ferner können der beispielhafte Kommunikationsprozessor 302, der beispielhafte Credit-Generator 304, der beispielhafte Zähler 306, der beispielhafte Quellenidentifikator 308, der beispielhafte Duplikator 310, der beispielhafte Aggregator 312 und/oder allgemeiner der beispielhafte Credit-Manager 210 aus 2 durch Hardware, Software, Firmware und/oder eine beliebige Kombination von Hardware, Software und/oder Firmware implementiert werden. So könnte beispielsweise ein beliebiges von dem beispielhaften Kommunikationsprozessor 302, dem beispielhaften Credit-Generator 304, dem beispielhaften Zähler 306, dem beispielhaften Quellenidentifikator 308, dem beispielhaften Duplikator 310, dem beispielhaften Aggregator 312 und/oder allgemeiner dem beispielhaften Credit-Manager 210 durch ein(e) oder mehrere analoge oder digitale Schaltungen, Logikschaltungen, programmierbare Prozessoren, programmierbare Steuerungen, Grafikverarbeitungseinheiten (GPU(s), Graphics Processing Unit(s)), DSP (s), anwendungsspezifische integrierte Schaltungen (ASIC(s), Application-Specific Integrated Circuit(s)), programmierbare Logikvorrichtungen (PLD(s), Programmable Logic Device(s)) und/oder feldprogrammierbare Logikvorrichtungen (FPLD(s), Field-Programmable Logic Device(s)) implementiert werden. Beim Lesen einer der Vorrichtungs- oder Systemansprüche dieses Patents, um eine reine Software- und/oder Firmwareimplementierung abzudecken, ist/sind wenigstens eines von dem beispielhaften Kommunikationsprozessor 302, dem beispielhaften Credit-Generator 304, dem beispielhaften Zähler 306, dem beispielhaften Quellenidentifikator 308, dem beispielhaften Duplikator 310 und/oder dem beispielhaften Aggregator 312 hiermit ausdrücklich definiert, dass sie eine nichtflüchtige computerlesbare Speicherungsvorrichtung oder Speicherungsplatte einschließen, wie beispielsweise einen Speicher, eine Digital Versatile Disk (DVD), eine Compact Disk (CD), eine Blu-ray Disk usw., einschließlich der Software und/oder Firmware. Ferner kann der beispielhafte Credit-Manager 210 aus 2 ein(e/n) oder mehrere Elemente, Prozesse und/oder Vorrichtungen zusätzlich zu oder anstelle der in 3 veranschaulichten einschließen und/oder kann mehr als eines oder alle der veranschaulichten Elemente, Prozesse und Vorrichtungen einschließen. Wie hierin verwendet, umfasst der Ausdruck „in Kommunikation“, einschließlich Variationen davon, eine direkte Kommunikation und/oder indirekte Kommunikation über eine oder mehrere Zwischenkomponenten und erfordert keine direkte physische (z. B. drahtgebundene) Kommunikation und/oder ständige Kommunikation, sondern schließt zusätzlich eine selektive Kommunikation in periodischen Intervallen, geplanten Intervallen, aperiodischen Intervallen und/oder einmaligen Ereignissen ein.
4A und 4B sind Blockschaltbilder, die eine beispielhafte Operation 400 des Flusses von Credits zwischen Produzent und Konsumenten veranschaulichen. 4A und 4B schließen den beispielhaften Credit-Manager 210, einen beispielhaften Produzenten 402, einen beispielhaften Puffer 408, einen beispielhaften ersten Konsumenten 410 und einen beispielhaften zweiten Konsumenten 414 ein.
Bezug nehmend auf 4A schließt die beispielhafte Operation 400 den Produzenten 402 ein, um einen Datenstream für den ersten Konsumenten 410 und den zweiten Konsumenten 414 zu produzieren. Der Produzent 402 kann wenigstens eines von der Faltungs-Engine 214, der MMU 216, der RNN-Engine 218, dem DSP 220 und/oder einem beliebigen anderen CBB sein, der sich intern oder extern zum Beschleuniger 206 aus 2 befindet. Der Produzent 402 wird von der Konfigurationssteuerung 208 so bestimmt, dass er Produzentenknoten aufweist, die Knoten sind, die Daten produzieren, die von einem Konsumentenknoten ausgeführt werden sollen. Der Produzent 402 partitioniert einen Datenstream in kleine Quanten, die als „Kacheln“ bezeichnet werden und in einen Slot des Puffers 408 passen. Beispielsweise wird der Datenstream in der Reihenfolge der Produktion partitioniert und im Puffer 408 gespeichert, so dass der Anfang des Datenstreams zuerst partitioniert und gespeichert werden soll usw., während der Prozess chronologisch fortgesetzt wird. Eine „Kachel“ von Daten ist ein Datenpaket, das in vordefinierte mehrdimensionale Blöcke von Datenelementen zur Übertragung über die Daten-Fabric 232 aus 2 verpackt ist. Der Produzent 402 schließt einen jeweiligen Produzenten-Credit-Zähler 404 ein, um die vom Credit-Manager 210 bereitgestellten Credits zu zählen. In einigen Beispielen ist der Produzenten-Credit-Zähler 404 eine interne digitale Logikvorrichtung, die innerhalb des Produzenten 402 angeordnet ist. In anderen Beispielen ist der Produzenten-Credit-Zähler 404 eine externe digitale Logikvorrichtung, die im Credit-Manager 210 angeordnet und mit dem Produzenten 402 assoziiert ist.
In 4A schließt die beispielhafte Operation 400 den Credit-Manager 210 ein, um zwischen dem Produzenten 402 und dem ersten und zweiten Konsumenten 410, 414 zu kommunizieren. Der Credit-Manager 210 schließt einen jeweiligen Credit-Manager-Zähler 406 ein, der Credits zählt, die entweder vom Produzenten 402 oder vom ersten und zweiten Konsumenten 410, 414 empfangen werden. Der Credit-Manager 210 ist mit dem Produzenten 402, dem ersten Konsumenten 410 und dem zweiten Konsumenten 414 gekoppelt. Die Operation des Credit-Managers 210 wird nachstehend in Verbindung mit 6 detaillierter beschrieben.
In 4A schließt die beispielhafte Operation 400 den Puffer 408 ein, um vom Produzenten 402 produzierte Daten zu speichern und um für eine Mehrzahl von Konsumenten, wie beispielsweise den ersten und den zweiten Konsumenten 410, 414, zugänglich zu sein. Der Puffer 408 ist ein zyklischer Puffer, der als Array veranschaulicht ist. Der Puffer 408 schließt die jeweiligen Slots 408A-408E ein. Ein Slot in einem Puffer ist eine Festwertgröße des Speicherungsplatzes im Puffer 408, wie beispielsweise ein Index in einem Array. Die Größe des Puffers 408 wird pro Datenstream konfiguriert. Beispielsweise kann der Puffer 408 durch die Konfigurationssteuerung 208 so konfiguriert werden, dass der aktuelle Datenstream in den Puffer 408 produziert werden kann. Der Puffer 408 kann so konfiguriert werden, dass er mehr als die jeweiligen Slots 408A-408E einschließt. Beispielsweise kann der Puffer 408 von der Konfigurationssteuerung 208 so konfiguriert werden, dass er 16 Slots einschließt. Die Konfigurationssteuerung 208 kann auch die Größe der Slots im Puffer 408 basierend auf ausführbaren Dateien konfigurieren, die vom Compiler 204 kompiliert werden. Beispielsweise können die jeweiligen Slots 408A-408E eine Größe aufweisen, die für eine Datenkachel zum Speichern passt. Im Beispiel aus 4A sind die mit schrägen Linien repräsentierten Slots indikativ für einen gefüllten Platz, so dass der Produzent 402 Daten in den Slot schrieb (z. B. die Kachel speicherte). Im Beispiel aus 4A sind die ohne schräge Linien repräsentierten Slots indikativ für einen leeren Platz (z. B. verfügbaren Platz), so dass der Produzent 402 Daten in den Slot schreiben kann. Beispielsweise ist der Slot 408A ein produzierter Slot und 408B-408E sind verfügbare Slots.
In hierin offenbarten Beispielen schließt jeder Puffer (z. B. der Puffer 228 aus 2, der Puffer 408 oder ein beliebiger anderer Puffer, der in einem verfügbaren oder zugänglichen Speicher angeordnet ist) Zeiger ein. Ein Zeiger zeigt auf einen Index (z. B. einen Slot), der einen verfügbaren Platz enthält, in den geschrieben werden soll, oder zeigt auf einen Index, der Daten (z. B. einen Datensatz) enthält, die verarbeitet werden sollen. In einigen Beispielen gibt es Schreibzeiger und Lesezeiger. Der Schreibzeiger entspricht dem Produzenten 402, um den Produzenten 402 zu informieren, wo sich der nächste verfügbare Slot zum Produzieren von Daten befindet. Die Lesezeiger entsprechen den Konsumenten (z. B. dem ersten Konsumenten 410 und dem zweiten Konsumenten 414) und folgen den Schreibzeigern in chronologischer Reihenfolge der Speicherungs- und Puffer-Slot-Nummer. Falls ein Slot beispielsweise leer ist, zeigt der Lesezeiger den Konsumenten nicht zu diesem Slot. Stattdessen wartet der Lesezeiger, bis sich ein Schreibzeiger von einem Slot bewegt hat, in den geschrieben wurde, und zeigt auf den jetzt gefüllten Slot. In 4A sind die Zeiger als Pfeile veranschaulicht, die den Produzenten 402 mit dem Puffer 408 und den Puffer 408 mit dem ersten Konsumenten 410 und dem zweiten Konsumenten 414 verbinden.
In 4A schließt die beispielhafte Operation 400 den ersten Konsumenten 410 und den zweiten Konsumenten 414 ein, um Daten aus dem Puffer 408 zu lesen. Der erste Konsument 410 und der zweite Konsument 414 können ein beliebiges von der Faltungs-Engine 214, der MMU 216, der RNN-Engine 218, dem DSP 220 und/oder einem beliebigen anderen CBB sein, der sich intern oder extern zum Beschleuniger 206 aus 2 befindet. Die Konsumenten 410, 414 werden von der Konfigurationssteuerung 208 so bestimmt, dass sie Konsumentenknoten aufweisen, die Knoten sind, die Daten zur Verarbeitung und Ausführung einer Arbeitslast konsumieren. Im veranschaulichten Beispiel sind die Konsumenten 410, 414 so konfiguriert, dass sie jeweils den vom Produzenten 402 produzierten Datenstream konsumieren. Beispielsweise soll der erste Konsument 410 mit der im Datenstream identifizierten ausführbaren Aufgabe arbeiten, und der zweite Konsument 414 soll mit der im Datenstream identifizierten gleichen ausführbaren Aufgabe arbeiten, so dass sowohl der erste Konsument 410 als auch der zweite Konsument 414 die gleiche Leistung erbringen.
In hierin offenbarten Beispielen schließt der erste Konsument 410 einen ersten Konsumenten-Credit-Zähler 412, und der zweite Konsument schließt 414 einen zweiten Konsumenten-Credit-Zähler 416 ein. Der erste und der zweite Konsumenten-Credit-Zähler 412, 416 zählen die vom Credit-Manager 210 bereitgestellten Credits. In einigen Beispielen sind der erste und der zweite Konsumenten-Credit-Zähler 412, 416 interne digitale Logikvorrichtungen, die im ersten und zweiten Konsumenten 410, 414 eingeschlossen sind. In anderen Beispielen sind der erste und der zweite Konsumenten-Credit-Zähler 412, 416 externe digitale Logikvorrichtungen, die im Credit-Manager 210 beim Zähler 306 angeordnet sind und mit den Konsumenten 410, 414 assoziiert sind.
In 4A beginnt die beispielhafte Operation 400, wenn der Produzent 402 aus Konfigurationssteuernachrichten bestimmt, dass der Puffer 408 fünf Slots aufweisen soll. Gleichzeitig zeigen die Konfigurationssteuernachrichten von der Konfigurationssteuerung 208 dem Credit-Manager 210 die Größe des Puffers an, und der Credit-Manager 210 generiert 5 Credits für den Produzenten 402. Derartige Puffereigenschaften können Konfigurationseigenschaften, Konfigurationsinformationen usw. sein, die von der Konfigurationssteuerung 208 aus 2 empfangen werden. Beispielsweise kann der Credit-Generator 304 aus 3 eine Anzahl n von Credits generieren, wobei n gleich der Anzahl von Slots im Puffer 408 ist. Wenn dem Produzenten 402 die Credits bereitgestellt werden, wird der Produzenten-Credit-Zähler 404 inkrementiert, um der Anzahl von empfangenen Credits zu entsprechen (z. B. insgesamt 5 Credits). Im veranschaulichten Beispiel aus 4A hat der Produzent 402 Daten für den ersten Slot 408A produziert (z. B. geschrieben). Auf diese Weise wurde der Produzenten-Credit-Zähler 404 um eins dekrementiert (z. B. jetzt indikativ für 4 Credits, weil ein Credit verwendet wurde, um Daten in den ersten Slot 408A zu produzieren), der Credit-Manager-Zähler 406 wurde um eins inkrementiert (z. B. gab der Produzent den verwendeten Credit an den Credit-Manager 210 zurück), der Schreibzeiger wurde zum zweiten Slot 408B bewegt, und die Lesezeiger zeigen vom ersten Slot 408A. Der erste Slot 408A ist derzeit verfügbar, um Daten vom ersten Konsumenten 410 und/oder vom zweiten Konsumenten 414 zu konsumieren (z. B. zu lesen).
Bezug nehmend auf 4B veranschaulicht das veranschaulichte Beispiel der Operation 400, wie Credits vom Credit-Manager 210 vergeben werden. In einigen Beispielen veranschaulicht 4B die Operation 400, nachdem Credits bereits durch den Credit-Generator 304 des Credit-Managers 210 generiert wurden. In der veranschaulichten Operation 400 aus 4B ist der Produzenten-Credit-Zähler 404 gleich 2, der Credit-Manager-Zähler 406 gleich 2, der erste Konsumenten-Credit-Zähler 412 gleich 1 und der zweite Konsumenten-Credit-Zähler 416 gleich 3.
Der Produzent 402 hat 2 Credits, weil drei Slots (z. B. der erste Slot 408A, der vierte Slot 408D und der fünfte Slot 408E) gefüllt sind und nur 2 Slots zum Füllen verfügbar sind (z. B. Schreiben oder Produzieren). Der erste Konsument 410 hat 1 Credit, weil der erste Konsument 410 die Kacheln im vierten Slot 408D und im fünften Slot 408E konsumiert hat. Auf diese Weise gibt es nur einen weiteren Slot (z. B. den ersten Slot 408A), aus dem der erste Konsument 410 lesen kann. Der zweite Konsument 414 hat 3 Credits, da der Credit-Manager 210, nachdem der Produzent drei Slots gefüllt hatte, sowohl dem ersten Konsumenten 410 als auch dem zweiten Konsumenten 414 jeweils 3 Credits bereitstellte, um auf 3 Kacheln von den drei Slots (z. B. dem ersten Slot 408A, dem vierten Slot 408D und dem fünften Slot 408E) zuzugreifen und diese zu konsumieren. Im veranschaulichten Beispiel hat der zweite Konsument 414 keine Kacheln vom Puffer 408 konsumiert. Auf diese Weise kann der zweite Konsument 414 langsamer als der erste Konsument 410 sein, so dass der zweite Konsument 414 Daten mit einer niedrigeren Bitrate pro Minute als der erste Konsument 410 liest.
Im veranschaulichten Beispiel aus 4B hat der Credit-Manager 210 2 Credits, da der erste Konsument 410 die 2 Credits weggegeben hat, die der erste Konsument 410 verwendet hat, nachdem er die Kacheln aus dem vierten Slot 408D und dem fünften Slot 408E gelesen hat. Der Credit-Manager 210 wird erst Credits an den Produzenten 402 weitergeben, wenn jeder Konsument die Kachel von jedem Slot konsumiert hat. Wenn der zweite Konsument 414 beispielsweise den vierten Slot 408D konsumiert, kann der zweite Konsument 414 dem Credit-Manager, der dem Slot entspricht, einen Credit senden, und der Credit-Manager 210 aggregiert den Credit vom ersten Konsumenten 410 (z. B. den Credit, der bereits vom ersten Konsumenten 410 gesendet wurde, nachdem der erste Konsument 410 eine Kachel im vierten Slot 408D konsumiert hat) mit dem Credit vom zweiten Konsumenten 414. Ferner stellt der Credit-Manager 210 dem Produzenten 402 den aggregierten Credit bereit, um anzuzeigen, dass der vierte Slot 408D zum Produzieren verfügbar ist. Die Operation 400 des Weitergebens von Credits zwischen Produzent (z. B. dem Produzenten 402) und Konsumenten (z. B. 410, 414) kann fortgesetzt werden, bis der Produzent 402 den gesamten Datenstream produziert hat und die Konsumenten 410, 414 die ausführbare Datei im Datenstream ausgeführt haben. Die Konsumenten 410, 414 können eine Aufgabe erst ausführen, wenn die Konsumenten 410, 414 alle im Datenstream angebotenen Daten konsumiert (z. B. gelesen) haben.
Flussdiagramme, die repräsentativ für beispielhafte Hardwarelogik, maschinenlesbare Anweisungen, hardwareimplementierte Zustandsmaschinen und/oder eine beliebige Kombination davon zum Implementieren des Credit-Managers 210 aus 3 sind, sind in 5-7 gezeigt. Die maschinenlesbaren Anweisungen können ein oder mehrere ausführbare Programme oder Teile eines ausführbaren Programms zur Ausführung durch einen Computerprozessor sein, wie beispielsweise den Prozessor 810 und/oder Beschleuniger 812, die in der nachstehend in Verbindung mit 8 erörterten beispielhaften Prozessorplattform 800 gezeigt sind. Das Programm kann in Software verkörpert sein, die auf einem nichtflüchtigen computerlesbaren Speicherungsmedium gespeichert ist, wie beispielsweise auf einer CD-ROM, einer Diskette, einer Festplatte, einer DVD, einer Blu-ray Disk oder in einem Speicher, der mit dem Prozessor 810 assoziiert ist, aber das gesamte Programm und/oder Teile davon könnten alternativ von einer anderen Vorrichtung als dem Prozessor 810 ausgeführt werden und/oder in Firmware oder dedizierter Hardware verkörpert sein. Obwohl das beispielhafte Programm unter Bezugnahme auf die in 5-7 veranschaulichten Flussdiagramme beschrieben wird, können ferner alternativ viele andere Verfahren zum Implementieren des Beispiels verwendet werden. Beispielsweise kann die Reihenfolge der Ausführung der Blöcke geändert werden, und/oder einige der beschriebenen Blöcke können geändert, eliminiert oder kombiniert werden. Zusätzlich oder alternativ können einige oder alle der Blöcke durch eine oder mehrere Hardwareschaltungen (z. B. diskrete und/oder integrierte analoge und/oder digitale Schaltungen, ein FPGA, ein ASIC, einen Komparator, einen Operationsverstärker (Op-Amp), eine Logikschaltung usw.) implementiert werden, die strukturiert sind, um die entsprechende Operation durchzuführen, ohne Software oder Firmware auszuführen.
Die hierin beschriebenen maschinenlesbaren Anweisungen können in einem oder mehreren von einem komprimierten Format, einem verschlüsselten Format, einem fragmentierten Format, einem verpackten Format usw. gespeichert werden. Maschinenlesbare Anweisungen, wie hierin beschrieben, können als Daten (z. B. Teile von Anweisungen, Code, Repräsentationen von Code usw.) gespeichert werden, die zum Erstellen, Herstellen und/oder Produzieren von maschinenausführbaren Anweisungen genutzt werden können. Beispielsweise können die maschinenlesbaren Anweisungen fragmentiert und auf einer oder mehreren Speichervorrichtungen und/oder Rechenvorrichtungen (z. B. Servern) gespeichert werden. Die maschinenlesbaren Anweisungen können eines oder mehrere von Installation, Modifikation, Anpassung, Aktualisierung, Kombination, Ergänzung, Konfiguration, Entschlüsselung, Dekomprimierung, Auspacken, Verteilung, Neuzuweisung usw. erfordern,um sie durch eine Rechenvorrichtung und/oder eine andere Maschine direkt lesbar und/oder ausführbar zu machen. Beispielsweise können die maschinenlesbaren Anweisungen in mehreren Teilen gespeichert werden, die einzeln komprimiert, verschlüsselt und auf separaten Rechenvorrichtungen gespeichert werden, wobei die Teile, wenn sie entschlüsselt, dekomprimiert und kombiniert werden, einen Satz ausführbarer Anweisungen ausbilden, die ein Programm wie das hierin beschriebene implementieren. In einem anderen Beispiel können die maschinenlesbaren Anweisungen in einem Zustand gespeichert werden, in dem sie von einem Computer gelesen werden können, erfordern jedoch das Hinzufügen einer Bibliothek (z. B. einer Dynamic Link Library (DLL)), eines Software Development Kits (SDK), einer Anwendungsprogrammierschnittstelle (API, Application Programming Interface) usw., um die Anweisungen auf einer bestimmten Rechenvorrichtung oder einer anderen Vorrichtung auszuführen. In einem anderen Beispiel müssen die maschinenlesbaren Anweisungen möglicherweise konfiguriert werden (z. B. Einstellungen gespeichert werden, Daten eingegeben werden, Netzadressen aufgezeichnet werden usw.), bevor die maschinenlesbaren Anweisungen und/oder das/die entsprechende(n) Programm(e) ganz oder teilweise ausgeführt werden können. Somit sollen die offenbarten maschinenlesbaren Anweisungen und/oder das/die entsprechende(n) Programm(e) solche maschinenlesbaren Anweisungen und/oder Programme unabhängig vom bestimmten Format oder Zustand der maschinenlesbaren Anweisungen und/oder des/der Programms/Programme umfassen, wenn sie gespeichert oder anderweitig in Ruhe oder im Transit sind.
Wie oben erwähnt, können die beispielhaften Prozesse aus 5-7 unter Verwendung von ausführbaren Anweisungen (z. B. computer- und/oder maschinenlesbaren Anweisungen) implementiert werden, die auf einem nichtflüchtigen computer- und/oder maschinenlesbaren Medium wie einem Festplattenlaufwerk, einem Flash-Speicher, einem Nur-Lese-Speicher, einer Compact Disk, einer Digital Versatile Disk, einem Cache, einem Direktzugriffsspeicher und/oder einer beliebigen anderen Speicherungsvorrichtung oder Speicherungsplatte gespeichert sind, auf dem/der Informationen für eine beliebige Dauer gespeichert sind (z. B. für längere Zeiträume, permanent, für kurze Instanzen, zum temporären Puffern und/oder zum Zwischenspeichern der Informationen). Wie hierin verwendet, ist der Begriff „nichtflüchtiges computerlesbares Medium“ ausdrücklich so definiert, dass er einen beliebigen Typ von computerlesbarer Speicherungsvorrichtung und/oder Speicherungsplatte einschließt und sich ausbreitende Signale ausschließt und Übertragungsmedien ausschließt.
„Einschließend“ und „umfassend“ (und alle Formen und Zeitformen davon) werden hierin als offene Begriffe verwendet. Wenn also ein Anspruch irgendeine Form von „einschließen“ oder „umfassen“ (z. B. umfasst, beinhaltet, umfassend, einschließend, aufweisend usw.) als Präambel oder innerhalb einer Anspruchsrezitation jeglicher Art verwendet, versteht es sich, dass zusätzliche Elemente, Begriffe usw. vorhanden sein können, ohne außerhalb des Schutzbereichs des entsprechenden Anspruchs oder der entsprechenden Rezitation zu fallen. Wie hierin verwendet, ist der Ausdruck „wenigstens“, wenn er beispielsweise in einer Präambel eines Anspruchs als Übergangsbegriff verwendet wird, auf die gleiche Weise offen wie die Begriffe „umfassend“ und „einschließend“. Der Begriff „und/oder“, wenn er beispielsweise in einer Form wie A, B und/oder C verwendet wird, bezieht sich auf eine beliebige Kombination oder Teilmenge von A, B, C, wie beispielsweise (1) A allein, (2) B allein, (3) C allein, (4) A mit B, (5) A mit C, (6) B mit C und (7) A mit B und mit C. Wie hierin im Zusammenhang mit der Beschreibung von Strukturen, Komponenten, Gegenständen, Objekten und/oder Dingen verwendet, soll sich der Ausdruck „wenigstens eines von A und B“ auf Implementierungen beziehen, die ein beliebiges von (1) wenigstens einem A, (2) wenigstens einem B und (3) wenigstens einem A und wenigstens einem B einschließen. In ähnlicher Weise, wie hierin im Zusammenhang mit der Beschreibung von Strukturen, Komponenten, Gegenständen, Objekten und/oder Dingen verwendet, soll sich der Ausdruck „wenigstens eines von A oder B“ auf Implementierungen beziehen, die ein beliebiges von (1) wenigstens einem A, (2) wenigstens einem B und (3) wenigstens einem A und wenigstens einem B einschließen. Wie hierin im Zusammenhang mit der Beschreibung der Durchführung oder Ausführung von Prozessen, Anweisungen, Aktionen, Aktivitäten und/oder Schritten verwendet, soll sich der Ausdruck „wenigstens eines von A und B“ auf Implementierungen beziehen, die ein beliebiges von (1) wenigstens einem A, (2) wenigstens einem B und (3) wenigstens einem A und wenigstens einem B einschließen. In ähnlicher Weise, wie hierin im Zusammenhang mit der Beschreibung der Durchführung oder Ausführung von Prozessen, Anweisungen, Aktionen, Aktivitäten und/oder Schritten verwendet, soll sich der Ausdruck „wenigstens eines von A oder B“ auf Implementierungen beziehen, die ein beliebiges von (1) wenigstens einem A, (2) wenigstens einem B und (3) wenigstens einem A und wenigstens einem B einschließen.
Das Programm aus 5 ist ein Flussdiagramm, das für maschinenlesbare Anweisungen repräsentativ ist, die ausgeführt werden können, um einen beispielhaften produzierenden CBB (d. h. den Produzenten 402) aus 4A und/oder 4B zu implementieren. Der beispielhafte Produzent 402 kann ein beliebiges von der Faltungs-Engine 214, der MMU 216, der RNN-Engine 218, dem DSP 220 und/oder einem geeigneten CBB des Beschleunigers 206 aus 2 sein, der durch die Konfigurationssteuerung 208 konfiguriert ist, um Datenstreams zu produzieren, die für Aufgaben indikativ sind, mit denen ein Konsument arbeiten soll. Das Programm aus 5 beginnt, wenn der Produzent 402 den Produzenten-Credit-Zähler auf Null initialisiert (Block 502). Beispielsweise kann in den veranschaulichten Beispielen aus 4A und 4B der Produzenten-Credit-Zähler 404 eine digitale Logikvorrichtung sein, die innerhalb des Produzenten 402 angeordnet ist und vom Credit-Manager 210 gesteuert wird (2), oder der Produzenten-Credit-Zähler 404 kann extern zum Produzenten 402 angeordnet sein, so dass der Produzenten-Credit-Zähler 404 am Zähler 306 des Credit-Managers 210 angeordnet ist.
Der beispielhafte Produzent 402 bestimmt einen Puffer (Block 504) (z. B. den Puffer 228 aus 2, den Puffer 408 aus 4A und 4B oder einen beliebigen geeigneten Puffer, der in einem Allzweckspeicher angeordnet ist) durch Empfangen von Konfigurationssteuernachrichten von der Konfigurationssteuerung 208. Beispielsweise informieren die Konfigurationssteuernachrichten den Produzenten, dass der Puffer eine Anzahl x von Slots ist, der Zeiger am ersten Slot beginnt usw. Auf diese Weise partitioniert der Produzent einen Datenstream in Kacheln, und die Kacheln sind gleich der Größe der Slots im Puffer, so dass die Slots die Kacheln speichern sollen. Zusätzlich initialisiert der Produzent 402 den aktuellen Slot des Puffers so, dass er dem ersten Slot (Block 508) entspricht. Beispielsweise bestimmt der Produzent 402, wohin der Schreibzeiger zuerst im Puffer zeigt. Ein Puffer wird in einer Reihenfolge, wie beispielsweise einer chronologischen Reihenfolge, geschrieben und gelesen. Der aktuelle Slot im Puffer soll vom Produzenten 402 als ältester Slot initialisiert werden und den Puffer vom ältesten zum neuesten durcharbeiten, wobei der neueste Slot der zuletzt geschriebene Slot ist.
In Reaktion darauf, dass der Produzent 402 den aktuellen Slot des Puffers so initialisiert, dass er dem ersten Slot entspricht (Block 506), stellt der Produzent 402 dem Credit-Manager 210 (Block 508) eine Benachrichtigung über die Konfigurationssteuerung 208 bereit (2). Beispielsweise benachrichtigt der Produzent 402 den Credit-Manager 210, dass der Produzent 402 die Bestimmung der Puffereigenschaften abgeschlossen hat.
Wenn der Schreibzeiger initialisiert ist und der Credit-Manager 210 benachrichtigt wurde, wartet der Produzent 402 darauf, Credits vom Credit-Manager 210 zu empfangen (Block 510). Beispielsweise kann der Credit-Manager 210 in Reaktion darauf, dass der Produzent 402 den Credit-Manager 210 benachrichtigt, eine Anzahl n von Credits generieren und diese an den Produzenten 402 zurückgeben. In einigen Beispielen empfängt der Credit-Manager 210 die Konfigurationssteuernachrichten von der Konfigurationssteuerung 208, die der Größe und dem Ort des Puffers entsprechen.
Falls der Produzent 402 keine Credits vom Credit-Manager 210 empfängt (z. B. gibt Block 510 ein NEIN zurück), wartet der Produzent 402, bis der Credit-Manager 210 die Credits bereitstellt. Beispielsweise kann der Produzent 402 eine zugewiesene Aufgabe erst ausführen, wenn Credits vergeben werden, da der Produzent 402 erst Zugriff auf den Puffer hat, wenn ein Credit verifiziert, dass der Produzent 402 Zugriff hat. Falls der Produzent 402 Credits vom Credit-Manager 210 empfängt (z. B. gibt Block 510 ein JA zurück), wird der Produzenten-Credit-Zähler inkrementiert, um den empfangenen Credits zu entsprechen (Block 512). Beispielsweise kann der Produzenten-Credit-Zähler um eins inkrementiert werden, bis der Produzenten-Credit-Zähler gleich der Anzahl n von empfangenen Credits ist.
Der Produzent 402 bestimmt, ob der Datenstream bereit ist, in den Puffer geschrieben zu werden (z. B. Block 514). Falls der Produzent 402 beispielsweise noch keine Kacheln für die Produktion partitioniert und verpackt hat oder der Produzenten-Credit-Zähler keine korrekte Anzahl von Credits empfangen hat (z. B. gibt Block 514 ein NEIN zurück), kehrt die Steuerung zu Block 512 zurück. Falls der beispielhafte Produzent 402 Kacheln des Datenstreams für die Produktion partitioniert und verpackt hat (z. B. gibt Block 514 ein JA zurück), schreibt der Produzent 402 Daten in den aktuellen Slot (Block 516). Beispielsweise speichert der Produzent 402 Daten im aktuellen Slot, der durch den Schreibzeiger angezeigt und ursprünglich vom Produzenten 402 initialisiert wurde.
In Reaktion darauf, dass der Produzent 402 Daten in den aktuellen Slot schreibt (Block 516), wird der Produzenten-Credit-Zähler dekrementiert (Block 518). Beispielsweise kann der Produzent 402 den Produzenten-Credit-Zähler dekrementieren und/oder der Credit-Manager 210 kann den Produzenten-Credit-Zähler dekrementieren. In diesem Beispiel gibt der Produzent 402 dem Credit-Manager 210 einen Credit zurück (Block 520). Beispielsweise nutzt der Produzent 402 einen Credit, und der Produzent 402 gibt den Credit zur Verwendung durch einen Konsumenten weiter.
Der Produzent 402 bestimmt, ob der Produzent 402 noch weitere Credits zur Verwendung hat (Block 522). Falls der Produzent 402 bestimmt, dass es zusätzliche Credits gibt (z. B. gibt Block 522 ein JA zurück), kehrt die Steuerung zu Block 516 zurück. Falls der Produzent 402 bestimmt, dass der Produzent 402 keine zusätzlichen Credits zur Verwendung hat (z. B. gibt Block 522 ein NEIN zurück), aber dennoch zu produzierende Daten einschließt (z. B. gibt Block 524 ein JA zurück), wartet der Produzent 402 darauf, Credits vom Credit-Manager 210 zu empfangen (z. B. kehrt die Steuerung zu Block 510 zurück). Beispielsweise haben die Konsumenten möglicherweise keine vom Produzenten 402 produzierten Kacheln konsumiert, und daher gibt es keine verfügbaren Slots im Puffer, in die geschrieben werden kann. Falls der Produzent 402 keine zusätzlichen Daten zum Produzieren hat (z. B. gibt Block 524 ein NEIN zurück), ist die Datenproduzierung vollständig (Block 526). Beispielsweise wurde der Datenstream vollständig in den Puffer produziert und von den Konsumenten konsumiert. Das Programm aus 5 kann wiederholt werden, wenn ein Produzent 402 einen anderen Datenstream für einen oder mehrere Konsumenten produziert.
6 ist ein Flussdiagramm, das für maschinenlesbare Anweisungen repräsentativ ist, die ausgeführt werden können, um den beispielhaften Credit-Manager aus 2, 3, 4A und/or 4B zu implementieren. Das Programm aus 6 beginnt, wenn der Credit-Manager 210 Konsumentenkonfigurationseigenschaftsdaten von der Konfigurationssteuerung 208 (2) empfängt (Block 602). Beispielsweise kommuniziert die Konfigurationssteuerung 208 Informationen, die den CBBs, die Daten einer Eingabe 202 (z. B. Arbeitslast) verarbeiten, und den CBBs, die die Daten zur Verarbeitung produzieren, entsprechen. Die Konfigurationssteuerung 208 kommuniziert Nachrichten an den Kommunikationsprozessor 302 (3) des Credit-Managers 210.
Im beispielhaften Programm aus 6 initialisiert der Zähler 306 (3) den Slot-Credit-Zähler auf Null (Block 604). Beispielsweise ist der Slot-Credit-Zähler indikativ für eine Anzahl von Credits, die einem einzelnen Slot und mehreren Konsumenten entsprechen, so dass es für jeden Slot im Puffer einen Zähler gibt. Die Anzahl der durch den Zähler 306 initialisierten Slot-Credit-Zähler entspricht der Anzahl der Slots in einem Puffer (z. B. der Anzahl der Datenkacheln, die der Puffer speichern kann). Falls beispielsweise 500 Slots im Puffer vorhanden sind, initialisieren die Zähler 306 500 Slot-Credit-Zähler. Während des Betriebs zählt jeder der Slot-Credit-Zähler die Anzahl der Konsumenten, die aus einem Slot gelesen haben. Falls beispielsweise der Slot 250 eines 500-Slot-Puffers von einem oder mehreren Konsumenten gelesen wird, kann der dem Slot 250 entsprechende Slot-Credit-Zähler für jeden des einen oder der mehreren Konsumenten, der aus dem Slot liest, durch den Zähler 306 inkrementiert werden. Falls sich darüber hinaus 3 Konsumenten in der Arbeitslast befinden und jeder Konsument so konfiguriert ist, dass er aus dem Slot 250 des 500-Slot-Puffers liest, wird der Slot-Credit-Zähler, der dem Slot 250 entspricht, auf drei inkrementiert. Sobald der Slot-Credit-Zähler, der dem Slot 250 des 500-Slot-Puffers entspricht, auf drei inkrementiert wird, setzt der Zähler 306 den Slot-Credit-Zähler, der dem Slot 250 des 500-Slot-Puffers entspricht, auf Null zurück und/oder löscht ihn anderweitig.
Zusätzlich unterstützt der Slot-Credit-Zähler den Aggregator 312 bei der Bestimmung, wann jeder Konsument 410, 414 die im Slot gespeicherte Kachel gelesen hat. Falls es beispielsweise 3 Konsumenten gibt, die eine Kachel aus einem Slot im Puffer lesen sollen, wird der Slot-Credit-Zähler bis auf 3 inkrementiert, und wenn der Slot-Credit-Zähler gleich 3 ist, kann der Aggregator 312 die Credits kombinieren, um einen einzelnen Credit des Produzenten 402 für diesen einen Slot zu generieren.
Der Kommunikationsprozessor 302 benachrichtigt den Credit-Generator 304, um Credits für den Produzenten 402 basierend auf empfangenen Puffereigenschaften zu generieren (Block 606). Der Credit-Generator 304 generiert entsprechende Credits. Beispielsweise empfängt der Kommunikationsprozessor 302 Informationen von der Konfigurationssteuerung 208, die den Puffereigenschaften entsprechen, und empfängt zusätzlich eine Benachrichtigung, dass der Produzent 402 einen Zeiger initialisiert hat.
In Reaktion darauf, dass der Credit-Generator 304 Credits generiert (Block 606), verpackt der Kommunikationsprozessor 302 die Credits und sendet die Credits des Produzenten 402, wobei die Produzenten-Credits gleich der Anzahl der Slots im Puffer sind (Block 608). Beispielsweise kann der Credit-Generator 304 speziell Credits für den Produzenten 402 (z. B. Produzenten-Credits) generieren, da der Puffer anfänglich leer ist und vom Produzenten 402 gefüllt werden kann, wenn Credits verfügbar werden. Zusätzlich generiert der Credit-Generator 304 eine Anzahl n von Credits für den Produzenten 402, so dass n einer Anzahl von Slots im Puffer entspricht, die dem Produzenten 402 zum Schreiben zur Verfügung stehen.
Der Credit-Manager 210 wartet darauf, einen zurückgegebenen Credit zu empfangen (Block 610). Wenn der Produzent 402 beispielsweise in einen Slot in einem Puffer schreibt, wird ein diesem Slot entsprechender Credit an den Credit-Manager 210 zurückgegeben. Wenn der Credit-Manager 210 keinen zurückgegebenen Credit empfängt (z. B. gibt Block 610 ein NEIN zurück), wartet der Credit-Manager 210, bis ein Credit zurückgegeben wird. Wenn der Credit-Manager 210 einen zurückgegebenen Credit empfängt (z. B. gibt Block 610 ein JA zurück), stellt der Kommunikationsprozessor 302 den Credit dem Quellenidentifikator 308 bereit, um die Quelle des Credits zu identifizieren (Block 612). Beispielsweise kann der Quellenidentifikator 308 ein Paket analysieren, das dem zurückgegebenen Credit entspricht, das einen Header einschließt. Der Header des Pakets kann indikativ dafür sein, woher das Paket gesendet wurde, so dass das Paket von einem CBB gesendet wurde, der als ein Produzent 402 oder Konsument 410, 414 zugewiesen ist.
Ferner bestimmt der Quellenidentifikator 308, ob die Quelle des Credits vom Produzenten 402 oder von wenigstens einem der Konsumenten 410, 414 stammte. Falls der Quellenidentifikator 308 bestimmt, dass die Quelle des Credits vom Produzenten 402 stammt (z. B. gibt Block 612 ein JA zurück), initialisiert der Quellenidentifikator 308 den Duplikator 310 (3) über den Kommunikationsprozessor 302, um eine Anzahl m von Konsumenten basierend auf den empfangenen Konsumentenkonfigurationsdaten von der Konfigurationssteuerung 208 zu bestimmen (Block 614). Beispielsweise wird der Duplikator 310 initialisiert, um einen Produzenten-Credit zu multiplizieren, so dass jeder Konsument 410, 414 in der Arbeitslast einen Credit empfängt. In einigen Beispielen gibt es einen Konsumenten pro Produzenten 402. In anderen Beispielen gibt es eine Mehrzahl von Konsumenten 410, 414 pro einem Produzenten 402, von denen jeder Daten, die vom Produzenten 402 produziert werden, konsumieren und verarbeiten soll.
In Reaktion darauf, dass der Duplikator 310 Credits für jeden der Anzahl m von Konsumenten 410, 414 multipliziert, verpackt der Kommunikationsprozessor 302 die Credits und sendet einen Konsumenten-Credit an m Konsumenten 410, 414 (Block 616). Die Steuerung kehrt zu Block 610 zurück, bis der Credit-Manager 210 keinen zurückgegebenen Credit empfängt.
Im beispielhaften Programm aus 6, falls der Quellenidentifikator 308 identifiziert, dass die Quelle des Credits ein Konsument 410, 414 ist (z. B. gibt Block 612 ein NEIN zurück), inkrementiert der Zähler 306 einen dem Slot zugewiesenen Slot-Credit-Zähler, aus dem der wenigstens eine der Konsumenten 410, 414 eine Kachel gelesen hat (Block 618). Beispielsweise verfolgt der Zähler 306 die Konsumenten-Credits, um zu bestimmen, wann der Aggregator 312 (3) initialisiert werden muss, um Konsumenten-Credits zu kombinieren. Auf diese Weise inkrementiert der Zähler 306 den Konsumenten-Credit-Zähler (z. B. den Konsumenten-Credit-Zähler 412 und 416) nicht, da der Konsumenten-Credit-Zähler mit der Anzahl von Credits assoziiert ist, die wenigstens einer der Konsumenten 410, 414 besitzt. Stattdessen inkrementiert der Zähler 306 einen Zähler, der einer Anzahl von Credits entspricht, die der Credit-Manager 210 von einem oder mehreren Konsumenten 410, 414 entsprechend einem speziellen Slot empfangen hat.
In Reaktion darauf, dass der Zähler 306 einen Zähler inkrementiert, der einem der Konsumenten 410, 414 zugewiesen ist, die den Credit zurückgegeben haben, fragt der Aggregator 312 den Zähler ab, der einem der Konsumenten 410, 414 zugewiesen ist, um zu bestimmen, ob der Slot-Credit-Zähler größer als Null ist (Block 620). Falls der Zähler 306 den Aggregator 312 benachrichtigt, dass der Slot-Credit-Zähler nicht größer als Null ist (z. B. gibt Block 620 ein NEIN zurück), kehrt die Steuerung zu Block 610 zurück. Falls der Zähler 306 den Aggregator 312 benachrichtigt, dass der Slot-Credit-Zähler größer als Null ist (z. B. gibt Block 620 ein JA zurück), multipliziert der Aggregator 312 Konsumenten-Credits zu einem einzelnen Produzenten-Credit (Block 622). Beispielsweise wird der Aggregator 312 durch den Zähler 306 über den Kommunikationsprozessor 302 darüber informiert, dass ein oder mehrere Credits von einem oder mehreren Konsumenten zurückgegeben wurden. In einigen Beispielen analysiert der Aggregator 312 den zurückgegebenen Credit, um den Slot zu bestimmen, für den der Credit verwendet wurde, um von einem der Konsumenten 410, 414 konsumiert zu werden.
In Reaktion darauf, dass der Aggregator 312 Konsumenten-Credits kombiniert, verpackt der Kommunikationsprozessor 302 den Credit und sendet den Credit an den Produzenten 402 (Block 624). Beispielsweise gibt der Aggregator 312 den Credit an den Kommunikationsprozessor 302 weiter, um den Credit zu verpacken und über die CnC-Fabric 212 an den beabsichtigten CBB zu senden. In Reaktion darauf, dass der Kommunikationsprozessor 302 einen Credit an den Produzenten 402 sendet, dekrementiert der Zähler 306 den Slot-Credit-Zähler (Block 626), und die Steuerung kehrt zu Block 610 zurück.
Bei Block 610 wartet der Credit-Manager 210 darauf, einen zurückgegebenen Credit zu empfangen. Wenn der Credit-Manager 210 nach einer Schwellenwert-Zeitspanne keinen zurückgegebenen Credit empfängt (z. B. gibt Block 610 ein NEIN zurück), prüft der Credit-Manager 210, ob zusätzliche, nicht verwendete Produzenten-Credits vorhanden sind (Block 628). Falls der Credit-Manager 210 beispielsweise keine zurückgegebenen Credits vom Produzenten 402 oder den Konsumenten 410, 414 empfängt, wird der Datenstream vollständig konsumiert und wurde von den Konsumenten 410, 414 ausgeführt. In einigen Beispielen kann ein Produzent 402 nicht verwendete Credits aufweisen, die von der Produktion übrig geblieben sind, wie beispielsweise Credits, die nicht benötigt wurden, um die letzten paar Kacheln in den Puffer zu produzieren. Auf diese Weise setzt der Credit-Manager 210 die Produzenten-Credits auf Null (Block 630). Beispielsweise entfernt der Credit-Generator 304 Credits vom Produzenten 402, und der Zähler 306 dekrementiert den Produzenten-Credit-Zähler (z. B. den Produzenten-Credit-Zähler 404), bis der Produzenten-Credit-Zähler gleich Null ist.
Das Programm aus 6 endet, wenn keine Credits für eine Arbeitslast übrig bleiben, so dass der Credit-Manager 210 nicht arbeitet, um zwischen einem Produzenten 402 und mehreren Konsumenten 410, 414 zu kommunizieren. Das Programm aus 6 kann sich wiederholen, wenn ein als ein Produzent 402 initialisierter CBB dem Credit-Manager 210 Puffereigenschaften bereitstellt. Auf diese Weise generiert der Credit-Generator 304 Credits zum Initiieren von Produktion und Verbrauch zwischen CBBs, um eine Arbeitslast auszuführen.
7 ist ein Flussdiagramm, das für maschinenlesbare Anweisungen repräsentativ ist, die ausgeführt werden können, um einen oder mehrere der beispielhaften konsumierenden CBBs (z. B. den ersten Konsumenten 410 und/oder den zweiten Konsumenten 414) aus 4A und/oder 4B zu implementieren. Das Programm aus 7 beginnt, wenn der Konsumenten-Credit-Zähler (z. B. der Konsumenten-Credit-Zähler 412, 416) auf Null initialisiert wird (Block 702). Beispielsweise kann der Zähler 306 des Credit-Managers 210 eine digitale Logikvorrichtung steuern, die mit wenigstens einem der Konsumenten 410, 414 assoziiert ist, die indikativ für eine Anzahl von Credits ist, die wenigstens einer der Konsumenten 410, 414 verwenden kann, um Daten aus einem Puffer zu lesen.
Der wenigstens eine der Konsumenten 410, 414 bestimmt ferner einen internen Puffer (Block 604). Beispielsweise sendet die Konfigurationssteuerung 208 Nachrichten und Steuersignale an CBBs (z. B. eine beliebige von der Faltungs-Engine 214, der MMU 216, der RNN-Engine 218 und/oder dem DSP 220), die die CBBs über einen Konfigurationsmodus informieren. Auf diese Weise wird der CBB als Konsument, 410 oder 414, mit einem internen Puffer zum Speichern von Daten konfiguriert, die von einem anderen CBB (z. B. einem Produzenten) produziert werden.
Nachdem das Bestimmen der internen Puffer abgeschlossen ist (Block 704), warten die Konsumenten 410, 414 darauf, Konsumenten-Credits vom Credit-Manager 210 zu empfangen (Block 706). Beispielsweise stellt der Kommunikationsprozessor 302 des Credit-Managers 210 den Konsumenten 410, 414 einen Credit bereit, nachdem der Produzent 402 den Credit zum Schreiben von Daten in den Puffer verwendet hat. Falls die Konsumenten 410, 414 einen Credit vom Credit-Manager empfangen (z. B. gibt Block 706 ein JA zurück), inkrementiert der Zähler 306 den Konsumenten-Credit-Zähler (Block 708). Beispielsweise wird der Konsumenten-Credit-Zähler um eine Anzahl von Credits inkrementiert, die der Credit-Manager 210 an die Konsumenten 410, 414 weitergibt.
In Reaktion auf das Empfangen eines Credits bzw. von Credits vom Credit-Manager 210 bestimmen die Konsumenten 410, 414, ob sie bereit sind, Daten zu konsumieren (Block 710). Beispielsweise können die Konsumenten 410, 414 Daten aus einem Puffer lesen, wenn die Initialisierung abgeschlossen ist und wenn genügend Credits für die Konsumenten 410, 414 verfügbar sind, um auf die Daten im Puffer zuzugreifen. Falls die Konsumenten 410, 414 nicht bereit sind, Daten zu konsumieren (z. B. gibt Block 710 ein NEIN zurück), kehrt die Steuerung zu Block 706 zurück.
Falls die Konsumenten 410, 414 bereit sind, Daten aus dem Puffer zu konsumieren (z. B. gibt Block 710 ein JA zurück), lesen die Konsumenten 410, 414 eine Kachel aus dem nächsten Slot im Puffer (Block 712). Beispielsweise wird ein Lesezeiger initialisiert, nachdem der Produzent 402 Daten in einen Slot im Puffer geschrieben hat. In einigen Beispielen folgt der Lesezeiger dem Schreibzeiger in der Reihenfolge der Produktion. Wenn die Konsumenten 410, 414 Daten aus einem Slot lesen, bewegt sich der Lesezeiger zum nächsten Slot, der vom Produzenten 402 produziert wird.
In Reaktion auf das Lesen einer Kachel aus dem nächsten Slot im Puffer (Block 712) dekrementiert der Zähler 306 den Konsumenten-Credit-Zähler (Block 714). Beispielsweise wird jedes Mal ein Credit verwendet, wenn der Konsument eine Kachel aus einem Slot in einem Puffer konsumiert (z. B. liest). Daher wird der Konsumenten-Credit-Zähler dekrementiert, und gleichzeitig senden die Konsumenten 410, 414 einen Credit an den Credit-Manager 210 zurück (Block 716). Der Konsument prüft, ob zusätzliche Credits für die Konsumenten 410, 414 zur Verwendung verfügbar sind (Block 718). Falls es für die Konsumenten 410, 414 zusätzliche Credits zur Verwendung gibt (z. B. gibt Block 718 ein JA zurück), kehrt die Steuerung zu Block 712 zurück. Beispielsweise lesen die Konsumenten 410, 414 weiterhin Daten aus dem Puffer.
Falls es für die Konsumenten 410, 414 keine zusätzlichen Credits zur Verwendung gibt (z. B. gibt Block 718 ein NEIN zurück), bestimmen die Konsumenten 410, 414, ob zusätzliche Daten konsumiert werden sollen (Block 720). Falls die Konsumenten 410, 414 beispielsweise nicht über genügend Daten verfügen, um eine Arbeitslast auszuführen, gibt es zusätzliche Daten zum Konsumieren (z. B. gibt Block 720 ein JA zurück). Auf diese Weise kehrt die Steuerung zu Block 706 zurück, wo die Konsumenten 410, 414 auf einen Credit warten. Falls die Konsumenten 410, 414 genügend Daten aufweisen, um eine vom Compiler 204 kompilierte ausführbare Datei auszuführen, dann gibt es keine zusätzlichen Daten zum Konsumieren (z. B. gibt Block 720 ein NEIN zurück) und dann ist die Datenkonsumierung vollständig (Block 722). Beispielsweise lesen die Konsumenten 410, 414 den gesamten vom Produzenten 402 produzierten Datenstream.
Das Programm aus 7 endet, wenn die ausführbare Datei von den Konsumenten 410, 414 ausgeführt wird. Das Programm aus 7 kann sich wiederholen, wenn die Konfigurationssteuerung 208 CBBs konfiguriert, um eine andere Arbeitslast auszuführen, die als ausführbare Datei von einer Eingabe kompiliert wird (z. B. Eingabe 202 aus 2).
8 ist ein Blockschaltbild einer beispielhaften Prozessorplattform 800, die so strukturiert ist, dass sie die Anweisungen aus 5-7 ausführt, um den Credit-Manager 210 aus 2-3 zu implementieren. Die Prozessorplattform 800 kann beispielsweise ein Server, ein Personal Computer, eine Workstation, eine selbstlernende Maschine (z. B. ein neuronales Netz), eine mobile Vorrichtung (z. B. ein Mobiltelefon, ein Smartphone, ein Tablet wie ein iPad™), ein persönlicher digitaler Assistent (PDA), eine Internet-Appliance, ein DVD-Player, ein CD-Player, ein digitaler Videorecorder, ein Blu-ray-Player, eine Spielekonsole, ein persönlicher Videorecorder, eine Set-Top-Box, ein Headset oder eine andere tragbare Vorrichtung oder ein beliebiger anderer Typ von Rechenvorrichtung sein.
Die Prozessorplattform 800 des veranschaulichten Beispiels schließt einen Prozessor 810 und einen Beschleuniger 812 ein. Der Prozessor 810 des veranschaulichten Beispiels ist Hardware. Beispielsweise kann der Prozessor 810 durch eine oder mehrere integrierte Schaltungen, Logikschaltungen, Mikroprozessoren, GPUs, DSPs oder Steuerungen von einer beliebigen gewünschten Familie oder einem beliebigen gewünschten Hersteller implementiert werden. Der Hardwareprozessor kann eine halbleiterbasierte (z. B. siliziumbasierte) Vorrichtung sein. Zusätzlich kann der Beschleuniger 812 beispielsweise durch eine(n) oder mehrere integrierte Schaltungen, Logikschaltungen, Mikroprozessoren, GPUs, DSPs, FPGAs, VPUs, Steuerungen und/oder andere CBBs von einer beliebigen gewünschten Familie oder einem beliebigen gewünschten Hersteller implementiert werden. Der Beschleuniger 812 des veranschaulichten Beispiels ist Hardware. Der Hardwarebeschleuniger kann eine halbleiterbasierte (z. B. siliziumbasierte) Vorrichtung sein. In diesem Beispiel implementiert der Beschleuniger 812 den beispielhaften Credit-Manager 210, die beispielhafte CnC-Fabric 212, die beispielhafte Faltungs-Engine 214, die beispielhafte MMU 216, die beispielhafte RNN-Engine 218, den beispielhaften DSP 220, den beispielhaften Speicher 222, die beispielhafte Konfigurationssteuerung 208, die beispielhafte Kernel-Bank 230 und/oder die beispielhafte Daten-Fabric 232. In diesem Beispiel kann der Prozessor 810 den beispielhaften Credit-Manager 210 aus 2 und/oder 3, den beispielhaften Compiler 204, die beispielhafte Konfigurationssteuerung 208, den beispielhaften Credit-Manager 210, die beispielhafte CnC-Fabric 212, die beispielhafte Faltungs-Engine 214, die beispielhafte MMU 216, die beispielhafte RNN-Engine 218, den beispielhaften DSP 220, den beispielhaften Speicher 222, die beispielhafte Kernel-Bank 230, die beispielhafte Daten-Fabric 232 und/oder allgemeiner den beispielhaften Beschleuniger 206 aus 2 implementieren.
Der Prozessor 810 des veranschaulichten Beispiels schließt einen lokalen Speicher 811 (z. B. einen Cache) ein. Der Prozessor 810 des veranschaulichten Beispiels steht über einen Bus 818 mit einem Hauptspeicher, einschließlich eines flüchtigen Speichers 814 und eines nichtflüchtigen Speichers 816, in Kommunikation. Darüber hinaus schließt der Beschleuniger 812 des veranschaulichten Beispiels einen lokalen Speicher 813 (z. B. einen Cache) ein. Der Beschleuniger 812 des veranschaulichten Beispiels steht über den Bus 818 mit einem Hauptspeicher, einschließlich des flüchtigen Speichers 814 und des nichtflüchtigen Speichers 816, in Kommunikation. Der flüchtige Speicher 814 kann durch Synchronous Dynamic Random Access Memory (SDRAM), Dynamic Random Access Memory (DRAM), RAMBUS® Dynamic Random Access Memory (RDRAM®) und/oder einen beliebigen anderen Typ von Direktzugriffsspeichervorrichtung implementiert werden. Der nichtflüchtige Speicher 816 kann durch einen Flash-Speicher und/oder einen beliebigen anderen gewünschten Typ von Speichervorrichtung implementiert werden. Der Zugriff auf den Hauptspeicher 814, 816 wird durch eine Speichersteuerung gesteuert.
Die Prozessorplattform 800 des veranschaulichten Beispiels schließt auch eine Schnittstellenschaltung 820 ein. Die Schnittstellenschaltung 820 kann durch eine beliebige Art von Schnittstellenstandard implementiert werden, wie beispielsweise eine Ethernet-Schnittstelle, einen universellen seriellen Bus (USB), eine Bluetooth® Schnittstelle, eine Nahfeldkommunikationsschnittstelle (NFC-Schnittstelle, Near-Field-Communication-Schnittstelle) und/oder eine PCI-Express-Schnittstelle.
Im veranschaulichten Beispiel sind eine oder mehrere Eingabevorrichtungen 822 mit der Schnittstellenschaltung 820 verbunden. Die Eingabevorrichtung(en) 822 ermöglicht/ermöglichen es einem Benutzer, Daten und/oder Befehle in den Prozessor 1012 einzugeben. Die Eingabevorrichtung(en) kann/können beispielsweise durch einen Audiosensor, ein Mikrofon, eine Kamera (Standbild oder Video), eine Tastatur, eine Taste, eine Maus, einen Berührungsbildschirm, ein Trackpad, einen Trackball, einen Isopoint und/oder ein Spracherkennungssystem implementiert werden.
Eine oder mehrere Ausgabevorrichtungen 824 sind auch mit der Schnittstellenschaltung 820 des veranschaulichten Beispiels verbunden. Die Ausgabevorrichtungen 824 können beispielsweise durch Anzeigevorrichtungen (z. B. eine Leuchtdiode (LED, Light Emitting Diode), eine organische Leuchtdiode (OLED, Organic Light Emitting Diode), eine Flüssigkristallanzeige (LCD, Liquid Crystal Display), eine Kathodenstrahlröhrenanzeige (CRT-Anzeige, Cathode-Ray-Tube-Anzeige), eine In-Place-Switching-Anzeige (IPS-Anzeige), einen Berührungsbildschirm usw.), eine taktile Ausgabevorrichtung, einen Drucker und/oder einen Lautsprecher implementiert werden. Die Schnittstellenschaltung 820 des veranschaulichten Beispiels schließt somit typischerweise eine Grafiktreiberkarte, einen Grafiktreiberchip und/oder einen Grafiktreiberprozessor ein.
Die Schnittstellenschaltung 820 des veranschaulichten Beispiels schließt auch eine Kommunikationsvorrichtung wie einen Sender, einen Empfänger, einen Transceiver, ein Modem, ein Residential-Gateway, einen drahtlosen Zugangspunkt und/oder eine Netzschnittstelle ein, um den Datenaustausch mit externen Maschinen (z. B. Rechenvorrichtungen jeglicher Art) über ein Netz 826 zu ermöglichen. Die Kommunikation kann beispielsweise über eine Ethernet-Verbindung, eine Digital-Subscriber-Line-Verbindung (DSL-Verbindung), eine Telefonleitungsverbindung, ein Koaxialkabelsystem, ein Satellitensystem, ein Line-of-Site-Drahtlossystem oder ein Mobiltelefonsystem usw. erfolgen.
Die Prozessorplattform 800 des veranschaulichten Beispiels schließt auch eine oder mehrere Massenspeicherungsvorrichtungen 828 zum Speichern von Software und/oder Daten ein. Beispiele für derartige Massenspeicherungsvorrichtungen 828 schließen Diskettenlaufwerke, Festplatten, Compact-Disk-Laufwerke, Blu-ray-Disk-Laufwerke, Systeme für redundante Arrays unabhängiger Festplatten (RAID, Redundant Array of Independent Disks) und Digital-Versatile-Disk-Laufwerke (DVD-Laufwerke) ein.
Die maschinenausführbaren Anweisungen 832 aus 5, 6 und/oder 7 können in der Massenspeicherungsvorrichtung 828, im flüchtigen Speicher 814, im nichtflüchtigen Speicher 816 und/oder in einem entfernbaren nichtflüchtigen computerlesbaren Speicherungsmedium, wie beispielsweise CD oder DVD, gespeichert werden.
Beispielhafte Verfahren, Vorrichtungen, Systeme und Herstellungsartikel für mehrere asynchrone Konsumenten werden hierin offenbart. Weitere Beispiele und Kombinationen davon schließen die folgenden ein:

Beispiel 1 schließt eine Vorrichtung ein, umfassend einen Kommunikationsprozessor, um Konfigurationsinformationen von einem produzierenden Rechenbaustein zu empfangen, einen Credit-Generator zum Generieren einer Anzahl von Credits für den produzierenden Rechenbaustein,
der den Konfigurationsinformationen entspricht, wobei die Konfigurationsinformationen Eigenschaften eines Puffers einschließen, einen Quellenidentifikator zum Analysieren eines zurückgegebenen Credits, um zu bestimmen, ob der zurückgegebene Credit von dem produzierenden Rechenbaustein oder einem konsumierenden Rechenbaustein stammt, und
einen Duplikator zum Multiplizieren des zurückgegebenen Credits mit einem ersten Faktor, wenn der zurückgegebene Credit vom produzierenden Rechenbaustein stammt, wobei der erste Faktor indikativ für eine Anzahl von konsumierenden Rechenbausteinen ist, die in den Konfigurationsinformationen identifiziert sind.

Beispiel 2 schließt die Vorrichtung von Beispiel 1 ein, wobei der produzierende Rechenbaustein einen Datenstream für einen oder mehrere konsumierende Rechenbausteine produzieren soll, mit denen gearbeitet werden soll.
Beispiel 3 schließt die Vorrichtung von Beispiel 1 ein, die ferner einen Aggregator einschließt, um, wenn der Quellenidentifikator identifiziert, dass der zurückgegebene Credit vom konsumierenden Rechenbaustein stammt, mehrere zurückgegebene Credits von einer Anzahl von konsumierenden Rechenbausteinen, die dem ersten Faktor entsprechen, zu einem einzelnen Produzenten-Credit zu kombinieren.
Beispiel 4 schließt die Vorrichtung von Beispiel 3 ein, wobei der Aggregator einen Zähler abfragen soll, um zu bestimmen, wann die mehreren zurückgegebenen Credits zu einem einzelnen Produzenten-Credit kombiniert werden sollen, wobei der Zähler jedes Mal inkrementiert werden soll, wenn ein Credit, der einem Ort in einem Speicher entspricht, zurückgegeben wird.
Beispiel 5 schließt die Vorrichtung von Beispiel 4 ein, wobei ein produzierender Rechenbaustein den einzelnen Produzenten-Credit erst empfangen kann, wenn jeder der Anzahl von konsumierenden Rechenbausteinen, die dem ersten Faktor entsprechen, einen Credit zurückgegeben hat.
Beispiel 6 schließt die Vorrichtung von Beispiel 1 ein, wobei der Kommunikationsprozessor jedem der Anzahl von konsumierenden Rechenbausteinen einen Credit senden soll.
Beispiel 7 schließt die Vorrichtung von Beispiel 1 ein, wobei der produzierende Rechenbaustein eine Größe des Puffers bestimmen soll, wobei der Puffer eine Anzahl von Slots, die einem zweiten Faktor entsprechen, zum Speichern von Daten aufweisen soll, die vom produzierenden Rechenbaustein produziert werden.
Beispiel 8 schließt die Vorrichtung von Beispiel 1 ein, wobei die Konfigurationsinformationen die Anzahl von konsumierenden Rechenbausteinen pro einzelnen produzierenden Rechenbaustein identifizieren.
Beispiel 9 schließt ein nichtflüchtiges computerlesbares Speicherungsmedium ein, das Anweisungen umfasst, die bei ihrer Ausführung einen Prozessor veranlassen, wenigstens Konfigurationsinformationen von einem produzierenden Rechenbaustein zu empfangen, eine Anzahl von Credits für den produzierenden Rechenbaustein zu generieren, der den Konfigurationsinformationen entspricht, wobei die Konfigurationsinformationen Eigenschaften eines Puffers einschließen, einen zurückgegebenen Credit zu analysieren, um zu bestimmen, ob der zurückgegebene Credit von dem produzierenden Rechenbaustein oder einem konsumierenden Rechenbaustein stammt, und wenn der zurückgegebene Credit vom produzierenden Rechenbaustein stammt, den zurückgegebenen Credit mit einem ersten Faktor, der indikativ für eine Anzahl von konsumierenden Rechenbausteinen ist, die in den Konfigurationsinformationen identifiziert sind, zu multiplizieren.
Beispiel 10 schließt das nichtflüchtige computerlesbare Speicherungsmedium ein, wie in Beispiel 9 definiert, wobei die Anweisungen bei ihrer Ausführung den Prozessor veranlassen, einen Datenstream für einen oder mehrere konsumierende Rechenbausteine zu produzieren, mit denen gearbeitet werden soll.
Beispiel 11 schließt das nichtflüchtige computerlesbare Speicherungsmedium ein, wie in Beispiel 9 definiert, wobei die Anweisungen bei ihrer Ausführung den Prozessor veranlassen, wenn der zurückgegebene Credit vom konsumierenden Rechenbaustein stammt, mehrere zurückgegebene Credits von der Anzahl von konsumierenden Rechenbausteinen, die dem ersten Faktor entsprechen, zu einem einzelnen Produzenten-Credit zu kombinieren.
Beispiel 12 schließt das nichtflüchtige computerlesbare Speicherungsmedium ein, wie in Beispiel 11 definiert, wobei die Anweisungen bei ihrer Ausführung den Prozessor veranlassen, einen Zähler abzufragen, um zu bestimmen, wann die mehreren zurückgegebenen Credits zu einem einzelnen Produzenten-Credit kombiniert werden sollen, wobei der Zähler jedes Mal inkrementiert werden soll, wenn ein Credit, der einem Ort in einem Speicher entspricht, zurückgegeben wird.
Beispiel 13 schließt das nichtflüchtige computerlesbare Speicherungsmedium ein, wie in Beispiel 12 definiert, wobei die Anweisungen bei ihrer Ausführung den Prozessor veranlassen, dem produzierenden Rechenbaustein erst den einzelnen Produzenten-Credit bereitzustellen, wenn jeder der Anzahl von konsumierenden Rechenbausteinen, die dem ersten Faktor entsprechen, einen Credit zurückgegeben hat.
Beispiel 14 schließt das nichtflüchtige computerlesbare Speicherungsmedium ein, wie in Beispiel 9 definiert, wobei die Anweisungen bei ihrer Ausführung den Prozessor veranlassen, einen Credit an jeden der Anzahl von konsumierenden Rechenbausteinen zu senden.
Beispiel 15 schließt das nichtflüchtige computerlesbare Speicherungsmedium ein, wie in Beispiel 9 definiert, wobei die Anweisungen bei ihrer Ausführung den Prozessor veranlassen, die Anzahl von konsumierenden Rechenbausteinen pro einzelnen produzierenden Rechenbaustein basierend auf den Konfigurationsinformationen zu bestimmen.
Beispiel 16 schließt ein Verfahren ein, umfassend Empfangen von Konfigurationsinformationen von einem produzierenden Rechenbaustein, Generieren einer Anzahl von Credits für den produzierenden Rechenbaustein, der den Konfigurationsinformationen entspricht, wobei die Konfigurationsinformationen Eigenschaften eines Puffers einschließen, Analysieren eines zurückgegebenen Credits, um zu bestimmen, ob der zurückgegebene Credit von dem produzierenden Rechenbaustein oder einem konsumierenden Rechenbaustein stammt, und wenn der zurückgegebene Credit vom produzierenden Rechenbaustein stammt, Multiplizieren des zurückgegebenen Credits mit einem ersten Faktor der erste Faktor ist, der indikativ für eine Anzahl von konsumierenden Rechenbausteinen ist, die in den Konfigurationsinformationen identifiziert sind.
Beispiel 17 schließt das Verfahren von Beispiel 16 ein, ferner einschließlich Kombinieren von mehreren zurückgegebenen Credits von der Anzahl von konsumierenden Rechenbausteinen, die dem ersten Faktor entsprechen, zu einem einzelnen Produzenten-Credit, wenn der zurückgegebene Credit vom konsumierenden Rechenbaustein stammt.
Beispiel 18 schließt das Verfahren von Beispiel 17 ein, ferner einschließlich Abfragen eines Zählers, um zu bestimmen, wann die mehreren zurückgegebenen Credits zu einem einzelnen Produzenten-Credit kombiniert werden sollen, wobei der Zähler jedes Mal inkrementiert werden soll, wenn ein Credit, der einem Ort in einem Speicher entspricht, zurückgegeben wird.
Beispiel 19 schließt das Verfahren von Beispiel 18 ein, ferner einschließlich Warten, um dem produzierenden Rechenbaustein den einzelnen Produzenten-Credit bereitzustellen, bis jeder der Anzahl von konsumierenden Rechenbausteinen einen Credit zurückgegeben hat.
Beispiel 20 schließt das Verfahren von Beispiel 16 ein, ferner einschließlich Senden eines Credits an jeden der Anzahl von konsumierenden Rechenbausteinen, die dem ersten Faktor entsprechen.
Beispiel 21 schließt eine Vorrichtung ein, umfassend Mittel zum Kommunizieren, wobei die Mittel zum Kommunizieren Konfigurationsinformationen von einem produzierenden Rechenbaustein empfangen sollen, Mittel zum Generieren, wobei die Mittel zum Generieren eine Anzahl von Credits für den produzierenden Rechenbaustein, der den Konfigurationsinformationen entspricht, generieren sollen, wobei die Konfigurationsinformationen Eigenschaften eines Puffers einschließen, Mittel zum Analysieren, um zu bestimmen, ob der zurückgegebene Credit von dem produzierenden Rechenbaustein oder einem konsumierenden Rechenbaustein stammt, und Mittel zum Duplizieren, um, wenn der zurückgegebene Credit vom produzierenden Rechenbaustein stammt, den zurückgegebenen Credit mit einem ersten Faktor zu multiplizieren, wobei der erste Faktor indikativ für eine Anzahl von konsumierenden Rechenbausteinen ist, die in den Konfigurationsinformationen identifiziert sind.
Beispiel 22 schließt die Vorrichtung von Beispiel 21 ein, ferner einschließlich eines Mittels zum Aggregieren, wobei das Mittel zum Aggregieren mehrere zurückgegebene Credits von der Anzahl von konsumierenden Rechenbausteinen, die dem ersten Faktor entsprechen, zu einem einzelnen Produzenten-Credit kombinieren soll, wenn der zurückgegebene Credit vom konsumierenden Rechenbaustein stammt.
Beispiel 23 schließt die Vorrichtung von Beispiel 22 ein, wobei das Mittel zum Aggregieren einen Zähler abfragen soll, um zu bestimmen, wann die mehreren zurückgegebenen Credits zu einem einzelnen Produzenten-Credit kombiniert werden sollen, wobei der Zähler jedes Mal inkrementiert werden soll, wenn ein Credit, der einem Ort in einem Speicher entspricht, zurückgegeben wird.
Beispiel 24 schließt die Vorrichtung von Beispiel 23 ein, wobei die Mittel zum Kommunizieren warten sollen, um dem produzierenden Rechenbaustein den einzelnen Produzenten-Credit bereitzustellen, bis jeder der Anzahl von konsumierenden Rechenbausteinen einen Credit zurückgegeben hat.
Beispiel 25 schließt die Vorrichtung von Beispiel 21 ein, wobei die Mittel zum Kommunizieren jedem der Anzahl von konsumierenden Rechenbausteinen, die dem ersten Faktor entsprechen, einen Credit senden sollen.
Aus dem Vorstehenden wird ersichtlich, dass beispielhafte Verfahren, Vorrichtungen und Herstellungsartikel offenbart wurden, die ein Credit-System zwischen einem produzierenden Rechenbaustein und mehreren konsumierenden Rechenbausteinen verwalten. Die offenbarten Verfahren, Vorrichtungen und Herstellungsartikel verbessern die Effizienz der Verwendung einer Rechenvorrichtung, indem ein Credit-Manager bereitgestellt wird, um eine Anzahl von konsumierenden CBBs wegzuabstrahieren, um die Logik zu entfernen und/oder zu eliminieren, die typischerweise erforderlich ist, damit ein konsumierender CBB während der Ausführung einer Arbeitslast mit einem produzierenden CBB kommuniziert. Als solche muss eine Konfigurationssteuerung den produzierenden CBB nicht konfigurieren, um direkt mit einer Mehrzahl von konsumierenden CBBs zu kommunizieren. Eine derartige Konfiguration der direkten Kommunikation ist rechenintensiv, da der produzierende CBB den Typ des konsumierenden CBB, die Geschwindigkeit, mit der der konsumierende CBB Daten lesen kann, den Ort des konsumierenden CBB usw. kennen müsste. Zusätzlich ermöglicht der Credit-Manager mehrere konsumierende CBBs zur Ausführung einer Arbeitslast, unabhängig von der Geschwindigkeit, mit der die mehreren konsumierenden CBBs arbeiten. Die offenbarten Verfahren, Vorrichtungen und Herstellungsartikel sind dementsprechend auf eine oder mehrere Verbesserungen in der Funktionsweise eines Computers gerichtet.
Obwohl hierin bestimmte beispielhafte Verfahren, Vorrichtungen und Herstellungsartikel offenbart wurden, ist der Geltungsbereich dieses Patents nicht darauf beschränkt. Dieses Patent erstreckt sich im Gegenteil auf alle Verfahren, Vorrichtungen und Herstellungsartikel, die fairerweise in den Schutzbereich der Ansprüche dieses Patents fallen.
Die folgenden Ansprüche werden hiermit durch diese Bezugnahme in diese detaillierte Beschreibung aufgenommen, wobei jeder Anspruch für sich als eine separate Ausführungsform der vorliegenden Offenbarung steht.

Claims

Vorrichtung, umfassend: einen Kommunikationsprozessor zum Empfangen von Konfigurationsinformationen von einem produzierenden Rechenbaustein; einen Credit-Generator zum Generieren einer Anzahl von Credits für den produzierenden Rechenbaustein, der den Konfigurationsinformationen entspricht, wobei die Konfigurationsinformationen Eigenschaften eines Puffers einschließen; einen Quellenidentifikator zum Analysieren eines zurückgegebenen Credits, um zu bestimmen, ob der zurückgegebene Credit von dem produzierenden Rechenbaustein oder einem konsumierenden Rechenbaustein stammt; und einen Duplikator zum Multiplizieren des zurückgegebenen Credits mit einem ersten Faktor, wenn der zurückgegebene Credit vom produzierenden Rechenbaustein stammt, wobei der erste Faktor indikativ für eine Anzahl von konsumierenden Rechenbausteinen ist, die in den Konfigurationsinformationen identifiziert sind.
Vorrichtung nach Anspruch 1, die ferner einen Aggregator einschließt, um, wenn der Quellenidentifikator identifiziert, dass der zurückgegebene Credit vom konsumierenden Rechenbaustein stammt, mehrere zurückgegebene Credits von einer Anzahl von konsumierenden Rechenbausteinen, die dem ersten Faktor entsprechen, zu einem einzelnen Produzenten-Credit zu kombinieren.
Vorrichtung nach einem der Ansprüche 1 bis 2, wobei der Aggregator einen Zähler abfragen soll, um zu bestimmen, wann die mehreren zurückgegebenen Credits zu einem einzelnen Produzenten-Credit kombiniert werden sollen, wobei der Zähler jedes Mal inkrementiert werden soll, wenn ein Credit, der einem Ort in einem Speicher entspricht, zurückgegeben wird.
Vorrichtung nach einem der Ansprüche 1 bis 3, wobei der produzierende Rechenbaustein den einzelnen Produzenten-Credit erst empfangen kann, wenn jeder der Anzahl von konsumierenden Rechenbausteinen, die dem ersten Faktor entsprechen, einen Credit zurückgegeben hat.
Vorrichtung nach einem der Ansprüche 1 bis 4, wobei der produzierende Rechenbaustein einen Datenstream für einen oder mehrere konsumierende Rechenbausteine produzieren soll, mit denen gearbeitet werden soll.
Vorrichtung nach einem der Ansprüche 1 bis 4, wobei der Kommunikationsprozessor jedem der Anzahl von konsumierenden Rechenbausteinen einen Credit senden soll.
Vorrichtung nach einem der Ansprüche 1 bis 4, wobei der produzierende Rechenbaustein eine Größe des Puffers bestimmen soll, wobei der Puffer eine Anzahl von Slots, die einem zweiten Faktor entsprechen, zum Speichern von Daten aufweisen soll, die vom produzierenden Rechenbaustein produziert werden.
Vorrichtung nach einem der Ansprüche 1 bis 4, wobei die Konfigurationsinformationen die Anzahl von konsumierenden Rechenbausteinen pro einzelnen produzierenden Rechenbaustein identifizieren sollen.
Wenigstens ein computerlesbares Medium, das Anweisungen umfasst, die bei ihrer Ausführung wenigstens einen Prozessor wenigstens veranlassen zum: Empfangen von Konfigurationsinformationen von einem produzierenden Rechenbaustein; Generieren von einer Anzahl von Credits für den produzierenden Rechenbaustein, der den Konfigurationsinformationen entspricht, wobei die Konfigurationsinformationen Eigenschaften eines Puffers einschließen; Analysieren eines zurückgegebenen Credits, um zu bestimmen, ob der zurückgegebene Credit von dem produzierenden Rechenbaustein oder einem konsumierenden Rechenbaustein stammt; und wenn der zurückgegebene Credit vom produzierenden Rechenbaustein stammt, Multiplizieren des zurückgegebenen Credits mit einem ersten Faktor, der indikativ für eine Anzahl von konsumierenden Rechenbausteinen ist, die in den Konfigurationsinformationen identifiziert sind.
Wenigstens ein computerlesbares Medium nach Anspruch 9, wobei die Anweisungen bei ihrer Ausführung den wenigstens einen Prozessor veranlassen, wenn der zurückgegebene Credit vom konsumierenden Rechenbaustein stammt, mehrere zurückgegebene Credits von der Anzahl von konsumierenden Rechenbausteinen, die dem ersten Faktor entsprechen, zu einem einzelnen Produzenten-Credit zu kombinieren.
Wenigstens ein computerlesbares Medium nach einem der Ansprüche 9 bis 10, wobei die Anweisungen bei ihrer Ausführung den wenigstens einen Prozessor veranlassen, einen Zähler abzufragen, um zu bestimmen, wann die mehreren zurückgegebenen Credits zu einem einzelnen Produzenten-Credit kombiniert werden sollen, wobei der Zähler jedes Mal inkrementiert werden soll, wenn ein Credit, der einem Ort in einem Speicher entspricht, zurückgegeben wird.
Wenigstens ein computerlesbares Medium nach einem der Ansprüche 9 bis 11, wobei die Anweisungen bei ihrer Ausführung den wenigstens einen Prozessor veranlassen, dem produzierenden Rechenbaustein erst den einzelnen Produzenten-Credit bereitzustellen, wenn jeder der Anzahl von konsumierenden Rechenbausteinen, die dem ersten Faktor entsprechen, einen Credit zurückgegeben hat.
Wenigstens ein computerlesbares Medium nach einem der Ansprüche 9 bis 12, wobei die Anweisungen bei ihrer Ausführung den wenigstens einen Prozessor veranlassen, einen Datenstream für einen oder mehrere konsumierende Rechenbausteine zu produzieren, mit denen gearbeitet werden soll.
Wenigstens ein computerlesbares Medium nach einem der Ansprüche 9 bis 12, wobei die Anweisungen bei ihrer Ausführung den wenigstens einen Prozessor veranlassen, einen Credit an jeden der Anzahl von konsumierenden Rechenbausteinen zu senden.
Wenigstens ein computerlesbares Medium nach einem der Ansprüche 9 bis 12, wobei die Anweisungen bei ihrer Ausführung den wenigstens einen Prozessor veranlassen, die Anzahl von konsumierenden Rechenbausteinen pro einzelnen produzierenden Rechenbaustein basierend auf den Konfigurationsinformationen zu bestimmen.
Verfahren, umfassend: Empfangen von Konfigurationsinformationen von einem produzierenden Rechenbaustein; Generieren von einer Anzahl von Credits für den produzierenden Rechenbaustein, der den Konfigurationsinformationen entspricht, wobei die Konfigurationsinformationen Eigenschaften eines Puffers einschließen; Analysieren eines zurückgegebenen Credits, um zu bestimmen, ob der zurückgegebene Credit von dem produzierenden Rechenbaustein oder einem konsumierenden Rechenbaustein stammt; und wenn der zurückgegebene Credit vom produzierenden Rechenbaustein stammt, Multiplizieren des zurückgegebenen Credits mit einem ersten Faktor der erste Faktor ist, der indikativ für eine Anzahl von konsumierenden Rechenbausteinen ist, die in den Konfigurationsinformationen identifiziert sind.
Verfahren nach Anspruch 16, ferner einschließlich Kombinieren von mehreren zurückgegebenen Credits von der Anzahl von konsumierenden Rechenbausteinen, die dem ersten Faktor entsprechen, zu einem einzelnen Produzenten-Credit, wenn der zurückgegebene Credit vom konsumierenden Rechenbaustein stammt.
Verfahren nach einem der Ansprüche 16 bis 17, ferner einschließlich Abfragen eines Zählers, um zu bestimmen, wann die mehreren zurückgegebenen Credits zu einem einzelnen Produzenten-Credit kombiniert werden sollen, wobei der Zähler jedes Mal inkrementiert werden soll, wenn ein Credit, der einem Ort in einem Speicher entspricht, zurückgegeben wird.
Verfahren nach einem der Ansprüche 16 bis 18, ferner einschließlich Warten, um dem produzierenden Rechenbaustein den einzelnen Produzenten-Credit bereitzustellen, bis jeder der Anzahl von konsumierenden Rechenbausteinen einen Credit zurückgegeben hat.
Verfahren nach einem der Ansprüche 16 bis 19, ferner einschließlich Senden eines Credits an jeden der Anzahl von konsumierenden Rechenbausteinen, die dem ersten Faktor entsprechen.
Verfahren nach einem der Ansprüche 16 bis 19, ferner einschließlich Produzieren eines Datenstreams für einen oder mehrere konsumierende Rechenbausteine, mit denen gearbeitet werden soll.
Verfahren nach einem der Ansprüche 16 bis 19, ferner einschließlich Bestimmen einer Größe des Puffers, wobei der Puffer eine Anzahl von Slots, die einem zweiten Faktor entsprechen, zum Speichern von Daten aufweisen soll, die vom produzierenden Rechenbaustein produziert werden.
Verfahren nach einem der Ansprüche 16 bis 19, ferner einschließlich Identifizieren der Anzahl von konsumierenden Rechenbausteinen pro einzelnen produzierenden Rechenbaustein.
Vorrichtung, umfassend: Mittel zum Kommunizieren, um Konfigurationsinformationen von einem produzierenden Rechenbaustein zu empfangen; Mittel zum Generieren, um eine Anzahl von Credits für den produzierenden Rechenbaustein zu generieren, der den Konfigurationsinformationen entspricht, wobei die Konfigurationsinformationen Eigenschaften eines Puffers einschließen; Mittel zum Analysieren, um einen zurückgegebenen Credit zu analysieren, um zu bestimmen, ob der zurückgegebene Credit von dem produzierenden Rechenbaustein oder einem konsumierenden Rechenbaustein stammt; und Mittel zum Duplizieren, um, wenn der zurückgegebene Credit vom produzierenden Rechenbaustein stammt, den zurückgegebenen Credit mit einem ersten Faktor zu multiplizieren, wobei der erste Faktor indikativ für eine Anzahl von konsumierenden Rechenbausteinen ist, die in den Konfigurationsinformationen identifiziert sind.
Vorrichtung nach Anspruch 24, ferner einschließlich eines Mittels zum Aggregieren zum: Abfragen eines Zählers, um zu bestimmen, wann die mehreren zurückgegebenen Credits von der Anzahl von konsumierenden Rechenbausteinen, die dem ersten Faktor entsprechen, zu einem einzelnen Produzenten-Credit kombiniert werden sollen, wobei der Zähler jedes Mal inkrementiert werden soll, wenn ein Credit, der einem Ort in einem Speicher entspricht, zurückgegeben wird; und Kombinieren der mehreren zurückgegebenen Credits zu einem einzelnen Produzenten-Credit, wenn der zurückgegebene Credit vom konsumierenden Rechenbaustein stammt.