DE102021111195A1

DE102021111195A1 - System und Verfahren zur On-Chip-Speicher- (OCM-) Port-Drosselung für Maschinenlern-Operationen

Info

Publication number: DE102021111195A1
Application number: DE102021111195.1A
Authority: DE
Inventors: Heeloo Chung; Sowmya Hotha; Saurabh Shrivastava; Chia-Hsin Chen
Original assignee: Marvell Asia Pte Ltd
Current assignee: Marvell Asia Pte Ltd
Priority date: 2020-04-30
Filing date: 2021-04-30
Publication date: 2021-11-04
Also published as: US20220164018A1; US11687144B2; US20210341988A1; US11287869B2

Abstract

Ein neuer Ansatz betrachtet Systeme und Verfahren zur Unterstützung der Steuerung des Stromverbrauchs eines Speichers auf einem Chip durch Drosselung von Portzugriffsanfragen an den Speicher über einen Speicher-Arbiter auf Grundlage eines oder mehrerer programmierbarer Parameter. Der Speicher-Arbiter ist so konfiguriert, dass er die Anzahl der Ports, die für den gleichzeitigen Zugriff auf den Speicher verwendet werden, auf weniger als die verfügbaren Ports des Speichers beschränkt, wodurch eine adaptive Leistungssteuerung des Chips ermöglicht wird. Es sind zwei Port-Drosselungsschemata aktiviert - strikte Port-Drosselung, die die Anzahl der für den Speicherzugriff gewährten Ports so drosselt, dass sie nicht mehr als eine vom Benutzer konfigurierte maximale Drossel-Port-Anzahl beträgt, und Leaky-Bucket-Port-Drosselung, die die Anzahl der für den Speicherzugriff gewährten Ports so drosselt, dass sie innerhalb eines Bereichs liegt, der auf einer Anzahl von Credit-Token basiert, die in einem Credit-Register geführt werden.

Description

HINTERGRUND
Eine der großen Herausforderungen beim System-Level-Design eines Chips ist es, seinen Stromverbrauch so zu steuern, dass er innerhalb einer Reihe von definierten Anforderungen liegt. Da 70 % der Fläche des Chips vom On-Chip-Speicher (OCM) eingenommen werden, der Daten speichert, auf die die Prozessoren/Kerne des Chips zugreifen (lesen und/oder schreiben), ist der OCM die Komponente, die den meisten Strom auf dem Chip verbraucht, da jede Speicheroperation (lesen/schreiben) viel Strom verbraucht. Das Problem des OCM-Stromverbrauchs ist besonders wichtig für ein hardwarebasiertes maschinelles Lernsystem (ML), das typischerweise mehrere Kerne/Subsysteme umfasst, die jeweils ihr eigenes OCM aufweisen. Folglich nehmen OCMs den größten Teil der Chipfläche des hardwarebasierten ML-Systems ein und sind die Hauptquelle für den Stromverbrauch des Chips.
Die Cache-Leistungsoptimierung wurde für die Energieverwaltung des Chips verwendet. Die meisten aktuellen Energieverwaltungssysteme sind jedoch proprietär und spezifisch für die tatsächliche Konfiguration des Chips. Einige Energieverwaltungsansätze entscheiden sich dafür, die Stromversorgung und den Zugriff auf bestimmte Speicherbänke/Komponenten auf dem Chip abzuschalten, wenn die Speicherbänke nicht verwendet werden. Ein solcher Ansatz schränkt jedoch den Zugriff auf diese Speicherbänke ein, wobei ein solcher Speicherzugriff nicht immer im Voraus vorhersehbar ist, was zu einer Leistungsverschlechterung des Chips führt.
Die vorstehenden Beispiele aus dem verwandten Bereich des Stands der Technik und die sie betreffenden Beschränkungen sind zur Veranschaulichung gedacht und nicht ausschließlich. Andere Beschränkungen des verwandten Standes der Technik werden beim Lesen der Beschreibung und beim Studium der Zeichnungen deutlich.
Figurenliste
Aspekte der vorliegenden Offenbarung sind am besten aus der folgenden detaillierten Beschreibung zu verstehen, wenn sie zusammen mit den begleitenden Figuren gelesen werden. Es wird darauf hingewiesen, dass in Übereinstimmung mit der üblichen Praxis in der Industrie, verschiedene Merkmale sind nicht nach Skalierung gezeichnet. Vielmehr können die Abmessungen der verschiedenen Merkmale zur Verdeutlichung der Diskussion willkürlich vergrößert oder verkleinert werden.

1 zeigt ein Beispiel eines Diagramms eines hardwarebasierten programmierbaren Systems/Architektur, das so konfiguriert ist, dass es den Speicherzugriff für Maschinenlernen gemäß einem Aspekt der vorliegenden Ausführungsformen unterstützt.
2A zeigt ein Beispiel des Pseudocodes unter dem Schema der strikten Port-Drosselung; 2B zeigt ein nicht-begrenzendes Beispiel eines Diagramms, das das Schema der strikten Port-Drosselung gemäß einem Aspekt der vorliegenden Ausführungsformen illustriert.
3A zeigt ein Beispiel des Pseudocodes, der verwendet wird, um die zufällige Port-Zugriffs-Gewährungsmaske in Abhängigkeit von einer vom Benutzer konfigurierten maximalen Drosselzahl im Bereich von 0 bis 7 einzustellen; 3B zeigt ein Beispiel eines Diagramms, das das Leaky-Bucket-Port-Drosselungsschema gemäß einem Aspekt der vorliegenden Ausführungsformen illustriert.

AUSFÜHRLICHE BESCHREIBUNG
Die folgende Offenbarung enthält verschiedene Ausführungsformen oder Beispiele für die Implementierung verschiedener Merkmale des Gegenstands. Zur Vereinfachung der vorliegenden Offenbarung werden im Folgenden spezifische Beispiele für Komponenten und Anordnungen beschrieben. Dies sind natürlich nur Beispiele und sollen nicht einschränkend sein. Darüber hinaus können sich in der vorliegenden Offenbarung Bezugszeichen in den verschiedenen Beispielen wiederholen. Diese Wiederholung dient der Einfachheit und Klarheit und stellt an sich keine Beziehung zwischen den verschiedenen diskutierten Ausführungsformen und/oder Konfigurationen her.
Bevor verschiedene Ausführungsformen detaillierter beschrieben werden, sollte verstanden werden, dass die Ausführungsformen nicht einschränkend sind, da Elemente in solchen Ausführungsformen variieren können. Es sollte ebenfalls verstanden werden, dass eine bestimmte hier beschriebene und/oder dargestellte Ausführungsform Elemente aufweist, die ohne weiteres von der bestimmten Ausführungsform getrennt und optional mit einer beliebigen von mehreren anderen Ausführungsformen kombiniert oder durch Elemente in einer beliebigen von mehreren anderen hier beschriebenen Ausführungsformen ersetzt werden können. Es sollte auch verstanden werden, dass die hier verwendete Terminologie dem Zweck dient, bestimmte Konzepte zu beschreiben, und die Terminologie ist nicht als einschränkend zu betrachten. Sofern nicht anders definiert, weisen alle hierin verwendeten technischen und wissenschaftlichen Begriffe die gleiche Bedeutung auf, wie sie in der Technik, zu der die Ausführungsformen gehören, allgemein verstanden wird.
Ein neuer Ansatz betrachtet Systeme und Verfahren zur Unterstützung der Steuerung des Stromverbrauchs einer Speichereinheit, beispielsweise des On-Chip-Speichers (OCM) eines Chips, durch Drosselung von Portzugriffsanfragen an den Speicher über einen Speicher-Arbiter auf Grundlage eines oder mehrerer programmierbarer Parameter. Dabei ist der Speicher-Arbiter so konfiguriert, dass er die Anzahl der Ports, die für den gleichzeitigen Zugriff auf den Speicher verwendet werden, auf weniger als die verfügbaren Ports des Speichers beschränkt, wodurch eine adaptive Leistungssteuerung des Chips ermöglicht wird. In einigen Ausführungsformen sind zwei Port-Drosselungsschemata aktiviert - die strikte Port-Drosselung, die die Anzahl der Ports, die für den Speicherzugriff gewährt werden, so drosselt, dass sie nicht mehr als eine vom Benutzer konfigurierte maximale Drossel-Port-Anzahl beträgt, und die Leaky-Bucket-Port-Drosselung, die die Anzahl der Ports, die für den Speicherzugriff gewährt werden, so drosselt, dass sie innerhalb eines Bereichs liegt, der auf einer Anzahl von Guthaben-Token basiert, die in einem Guthaben-Register geführt werden.
Der Port-Drosselungs-Ansatz ermöglicht eine adaptive Steuerung des Stromverbrauchs durch den OCM des Chips, so dass er innerhalb eines benutzerspezifischen Limits liegt, während er weiterhin einen ununterbrochenen Zugriff auf die Speicherbänke des OCM für verschiedene Speicheroperationen während einer bestimmten Zeitspanne ermöglicht, indem die Port-Drosselung unter bestimmten Umständen vorübergehend ausgesetzt wird. Darüber hinaus glättet die Port-Drosselung des OCM in der beschriebenen Weise den Stromverbrauch des Chips über die Zeit, um Spitzen und/oder Täler des Stromverbrauchs während desselben Zeitraums zu begrenzen und zu vermeiden. Der Port-Drosselungs-Ansatz ist somit in der Lage, den Zugriff auf die OCMs zu verwalten, um einen großen Teil des Stromverbrauchs des Chips zu kontrollieren und zu reduzieren, während die Auswirkungen einer solchen Port-Drosselung auf die Leistung (beispielsweise die OCM-Zugriffszeit) des Chips gemildert werden.
Obwohl OCM in den folgenden Erörterungen als nicht einschränkendes Beispiel zur Veranschaulichung des Ansatzes verwendet wird, ist es zu verstehen, dass die Ausführungsformen gleichermaßen auf alle Arten von Speichern angewendet werden können. Darüber hinaus können die Ausführungsformen verallgemeinert und auf jeden Ressourcenzugriff (beispielsweise Speicher, Verarbeitungsleistung usw.) erweitert werden, um den Stromverbrauch zu steuern.
1 zeigt ein Beispiel eines Diagramms eines hardwarebasierten programmierbaren Systems/Architektur 100, das so konfiguriert ist, dass es einen energieeffizienten Speicherzugriff für maschinelles Lernen unterstützt. Obwohl die Diagramme die Komponenten als funktional getrennt darstellen, dient diese Darstellung lediglich der Veranschaulichung. Es wird deutlich, dass die in dieser Figur dargestellten Komponenten beliebig kombiniert oder in separate Software-, Firmware- und/oder Hardware-Komponenten aufgeteilt werden können. Des Weiteren wird deutlich, dass solche Komponenten, unabhängig davon, wie sie kombiniert oder aufgeteilt sind, auf demselben Host oder mehreren Hosts ausgeführt werden können, wobei die mehreren Hosts durch ein oder mehrere Netzwerke verbunden sein können.
Im Beispiel von 1 umfasst die Architektur 100 einen OCM 110, eine erste Art von Verarbeitungseinheit (beispielsweise POD) 120, eine zweite Art von Verarbeitungseinheit (beispielsweise Processing Engine oder PE) 130 und einen Speicher-Arbiter 140. Jede dieser Komponenten in der Architektur 100 ist ein dedizierter Hardwareblock/eine dedizierte Hardwarekomponente, der/die von einem Benutzer an einem Host 102 über eine PCIe-Schnittstelle 106 mittels Software-Instruktionen für verschiedene maschinelle Lernoperationen programmiert werden kann. Wenn die Software-Instruktionen ausgeführt werden, wird jede der Hardware-Komponenten zu einer speziell dafür vorgesehenen Hardware-Komponente, um bestimmte maschinelle Lernfunktionen auszuführen. In einigen Ausführungsformen befindet sich die Architektur 100 auf einem einzigen Chip, beispielsweise einem System-on-Chip (SOC).
In einigen Ausführungsformen ist der OCM 110, der eine oder mehrere Speicherfelder/- bänke (nicht dargestellt) umfasst, so konfiguriert, dass er Daten in einer Stream-Art für den Zugriff durch das POD 120 und den PE 130 für verschiedene ML-Operationen akzeptiert und verwaltet. In einigen Ausführungsformen ist das POD 120 so konfiguriert, dass es dichte oder regelmäßige Berechnungen an den Daten im OCM 110 durchführt, beispielsweise Matrixoperationen wie Matrixmultiplikation und -manipulation, wobei die Eingangsdaten zu verschiedenen Registersätzen des POD 120 gestreamt werden und die Ausgangsdaten über einen anderen Registersatz des POD 120 zum OCM 110 und/oder zum PE 130 gestreamt werden. Der PE 130 ist so konfiguriert, dass er spärliche/unregelmäßige Berechnungen und/oder komplexe Datenformtransformationen der Daten im OCM 110 und/oder vom POD 120 durchführt, beispielsweise Speichertransponierung, Quantisierung, Additionsoperationen, Operationen an unregelmäßigen Datenstrukturen (wie Bäume, Graphen und Prioritätswarteschlangen).
Im Beispiel von 1 weist das OCM 110 eine Vielzahl von Ports (oder Speicheragenten) auf, wobei auf jeden Port einzeln durch das POD 120 und/oder das PE 130 zugegriffen werden kann, um über eine Portzugriffsanfrage auf Daten im OCM 110 zuzugreifen (lesen und/oder schreiben). Als nicht einschränkende Beispiele, wie in 1 gezeigt, umfassen solche Ports zum OCM 110 unter anderem Lesen und Schreiben, die Daten von/zum OCM 110 aus einem Speicher 104 streamen; POD-Lesen 0 und POD-Lesen 1, die Daten in verschiedene Registersätze des POD 120 lesen; POD-Schreiben, das Daten in das OCM 110 aus einem Registersatz des POD 120 schreibt; PE-Lesen und PE-Schreiben, die Daten zwischen dem OCM 110 und dem PE 130 lesen bzw. schreiben. Alle diese Ports können die Port-Zugriffsanfragen annehmen, um unabhängig und getrennt auf die Daten im OCM 110 zur gleichen Zeit während desselben Taktzyklus zuzugreifen.
In einigen Ausführungsformen wird der Speicher-Arbiter 140 vom Benutzer über den Host konfiguriert/programmiert, wobei der Host 102 es einem Benutzer ermöglicht, einen oder mehrere Parameter als Teil einer Speicherzugriffsrichtlinie (beispielsweise OCM) dynamisch zur Laufzeit zu setzen/programmieren. In einigen Ausführungsformen umfassen der eine oder die mehreren Parameter eine maximale Anzahl von Ports, die gleichzeitig Zugriff auf das OCM 110 anfordern dürfen, beispielsweise throttle_port_num, um den Stromverbrauch des OCM 110 innerhalb eines Budgets zu begrenzen. In einigen Ausführungsformen umfassen der eine oder die mehreren Parameter eine Identifikation (beispielsweise eine benutzerspezifische bevorzugte Port-Maske) eines oder mehrerer Ports, die für den OCM-Zugriff bevorzugt werden und die Port-Zugriffsanfragen an diese Ports nicht gedrosselt werden sollten. In einigen Ausführungsformen weisen der eine oder die mehreren Parameter einen benutzerdefinierten gewichteten Vektor auf, der Prioritäten/Gewichte für einen oder mehrere Ports für den OCM-Zugriff festlegt, und die Port-Zugriffsanfragen zu den Ports mit niedrigeren Prioritäten sollten zuerst gedrosselt werden, und die Port-Zugriffsanfragen zu den Ports mit höheren Prioritäten sollten zuletzt gedrosselt werden oder es sollte vermieden werden, dass sie gedrosselt werden, es sei denn, es ist absolut notwendig. In einigen Ausführungsformen umfassen der eine oder die mehreren Parameter eine benutzerdefinierte Obergrenze für den Gesamtstromverbrauch durch die Port-Zugriffsanforderungen an den OCM 110. In einigen Ausführungsformen ist der Speicher-Arbiter 140 so konfiguriert, dass er den einen oder die mehreren Parameter, die vom Host in einem OCM-Register 150 des OCM 110 eingestellt wurden, beibehält, wobei der eine oder die mehreren Parameter, die im OCM-Register 150 gespeichert sind, vom Host so eingestellt und aktualisiert werden können, dass sie zur Laufzeit höher oder niedriger sind, wenn der POD 120 und/oder der PE 130 über die Portzugriffsanfragen auf das OCM 110 zugreifen.
In einigen Ausführungsformen ist der Speicher-Arbiter 140 so konfiguriert, dass er eine Vielzahl von Speicherzugriffsanfragen an den entsprechenden Ports des OCM 110 in Form von Port-Zugriffsanfragen an das OCM 110 akzeptiert. Wenn es keinen Konflikt gibt (beispielsweise keine Lese- und Schreibanforderungen an dieselbe Speicherbank zur gleichen Zeit), kann der Speicher-Arbiter 140 alle diese Anforderungen während desselben Taktzyklus gewähren. Wenn diese Port-Anforderungen jedoch alle gleichzeitig in einem bestimmten Taktzyklus auf verschiedene Speicherbänke im OCM 110 zugreifen, könnte die Gewährung all dieser Port-Anforderungen zu viel Strom kosten, und der durch diese Port-Anforderungen verursachte Stromverbrauch muss eingeschränkt werden.
In einigen Ausführungsformen ist der Speicher-Arbiter 140 so konfiguriert, dass er eine oder mehrere der Portzugriffsanfragen drosselt, indem er nur einer Teilmenge solcher Anfragen den Zugriff auf das OCM 110 über die entsprechenden Ports zur gleichen Zeit gewährt, um den Stromverbrauch des OCM 110 auf Grundlage des einen oder der mehreren im OCM-Register 150 eingestellten Parameter zu begrenzen. In einigen Ausführungsformen ist der Speicher-Arbiter 140 so konfiguriert, dass er verschiedene Port-Drosselungsschemata annimmt, einschließlich, aber nicht beschränkt auf, strikte Port-Drosselung und Leaky-Bucket-Port-Drosselung, basierend auf der maximalen Anzahl von Ports, die Zugriff auf das OCM 110 anfordern dürfen, throttle_port_num, wie unten im Detail beschrieben. In einigen Ausführungsformen ist der Speicher-Arbiter 140 so konfiguriert, dass er die benutzerspezifische bevorzugte Port-Maske und/oder den benutzerspezifischen gewichteten Vektor während der Port-Drosselung berücksichtigt, um eine Drosselung der Port-Zugriffsanfragen an bestimmte Ports für den Zugriff auf das OCM 110 zu vermeiden.
In einigen Ausführungsformen ist der Speicher-Arbiter 140 so konfiguriert, dass er den einen oder die mehreren Ports, die auf das OCM 110 zugreifen dürfen, über eine strenge Port-Drosselung drosselt, wobei der Speicher-Arbiter 140 so konfiguriert ist, dass er nur eine Anzahl von Port-Zugriffsanfragen gewährt, die gleich der Drossel-Port-Anzahl ist, wenn die Anzahl der von allen Ports des OCM 110 empfangenen Port-Zugriffsanfragen größer ist als die Drossel-Port-Anzahl, die im OCM-Register 150 eingestellt ist. In einigen Ausführungsformen ist der Speicher-Arbiter 140 so konfiguriert, dass er den Rest der Speicherzugriffsanfragen basierend auf einer Zufallsauswahl unterdrückt, indem er eine Portzugriffs-Gewährungsmaske berechnet, die alle Ports des OCM 110 (die ein Bit pro Port darstellt) entsprechend abdeckt (beispielsweise bedeutet 1 Gewährung, 0 Unterdrückung). 2A zeigt ein nicht einschränkendes Beispiel des Pseudocodes unter dem oben diskutierten strikten Port-Drosselungsschema und 2B zeigt ein nicht einschränkendes Beispiel eines Diagramms, das das strikte Port-Drosselungsschema veranschaulicht. Wie in 2A und 2B gezeigt, berechnet der Speicher-Arbiter 140 bei 200 eine Portzugriffs-Gewährungsmaske, die nur fünf der Portzugriffsanfragen gewährt, und wählt zufällig eine der sechs Portzugriffs-Anfragen aus, die er unter Verwendung einer zufälligen Portzugriffs-Gewährungsmaske rand_5_mask (204) unterdrückt, wobei ein zufälliger Port von sechs unterdrückt wird, wenn die throttle_port_num auf fünf gesetzt ist und sechs Speicherzugriffsanfragen eingehen (202). Wenn throttle_port_num auf vier gesetzt ist (und mehr als vier eingehende Portzugriffsanfragen vorliegen) (206), berechnet der Speicher-Arbiter 140 bei 200 eine Portzugriffs-Gewährungsmaske, die vier der Portzugriffsanfragen gewährt, und wählt zufällig zwei der sechs zu unterdrückenden Portzugriffsanfragen aus, indem er eine zufällige Portzugriffs-Gewährungsmaske rand_4_mask (208) verwendet, wobei zwei zufällige Ports von sechs unterdrückt werden. Wenn fünf Portzugriffsanfragen eingehen (während die Throttle_port_num auf vier gesetzt ist), berechnet der Speicher-Arbiter 140 dennoch eine Portzugriffs-Gewährungsmaske bei 200, die genau vier der Portzugriffsanfragen gewährt, und wählt zufällig eine der fünf zu unterdrückenden Portzugriffsanfragen aus. In einigen Ausführungsformen ist der Speicher-Arbiter 140 so konfiguriert, dass er statt der zufälligen Portzugriffs-Gewährungsmaske die benutzerspezifische bevorzugte Port-Maske und/oder den benutzerspezifischen gewichteten Vektor während der Port-Drosselung verwendet, um zu vermeiden, dass die Portzugriffsanfragen an bestimmte Ports gedrosselt werden, um auf das OCM 110 zuzugreifen. In einigen Ausführungsformen ist der Speicher-Arbiter 140 so konfiguriert, dass er die Anzahl der zu drosselnden Port-Zugriffsanfragen auf einen Grenzwert, beispielsweise nicht mehr als zwei, begrenzt, und zwar aufgrund der zeitlichen Beschränkungen (beispielsweise werden alle Port-Zugriffsanfragen schließlich innerhalb eines bestimmten Zeitraums gewährt) und/oder der Komplexität der möglichen Permutationen, die unter den zu unterdrückenden Port-Zugriffsanfragen auszuwählen sind. Ein nicht einschränkendes Beispiel: Wenn die Throttle_port_num auf weniger als vier eingestellt ist (und es sechs eingehende Port-Zugriffsanfragen gibt) (210), ist der Speicher-Arbiter 140 so konfiguriert, dass er keine Port-Drosselung durchführt, um sicherzustellen, dass alle Port-Zugriffsanfragen rechtzeitig gewährt werden (212). In einigen Ausführungsformen ist der Speicher-Arbiter 140 so konfiguriert, dass er die Port-Drosselung wieder aufnimmt, wenn der Gesamtstromverbrauch durch die Speicherzugriffsanfragen die vom Benutzer festgelegte Obergrenze für den Gesamtstromverbrauch überschreitet.
In einigen Ausführungsformen ist der Speicher-Arbiter 140 so konfiguriert, dass er einen oder mehrere Ports, die auf das OCM 110 zugreifen dürfen, über eine Leaky-Bucket-Port-Drosselung drosselt, wobei der Speicher-Arbiter 140 die Anzahl der Ports, die für den Zugriff auf das OCM 110 zugelassen sind, so drosselt, dass sie innerhalb eines bestimmten Bereichs liegt, beispielsweise von 1 bis 5. 3A zeigt ein Beispiel des Pseudocodes, der verwendet wird, um die zufällige Portzugriffs-Gewährungsmaske in Abhängigkeit von der Throttle_port_num im Bereich von 0 bis 7 einzustellen, wobei die entsprechende zufällige Portzugriffs-Gewährungsmaske entsprechend 0 bis 6 Portzugriffsanforderungen gewähren würde. 3B zeigt ein Beispiel für ein Diagramm, das die Leaky-Bucket-Port-Drosselung veranschaulicht. In einigen Ausführungsformen ist der Speicher-Arbiter 140 so konfiguriert, dass er einen Credit-Zähler 160 einrichtet, der beim Betrieb im Modus der Leaky-Bucket-Port-Drosselung einen Eimer mit Credit-Tokens aufrechterhält. In einigen Ausführungsformen kann der Credit-Zähler 160 als Defizit-Zähler negativ werden. Der Speicher-Arbiter 140 ist dann so konfiguriert, dass er eine zufällige Portzugriffs-Gewährungsmaske (302) basierend auf der vom Benutzer eingestellten throttle_port_num erstellt. In einigen Ausführungsformen ist der Speicher-Arbiter 140 so konfiguriert, dass er anstelle der zufälligen Portzugriffs-Gewährungsmaske die benutzerspezifische bevorzugte Port-Maske und/oder den benutzerspezifischen gewichteten Vektor während der Port-Drosselung verwendet, um eine Drosselung der Portzugriffsanfragen an bestimmte Ports für den Zugriff auf das OCM 110 zu vermeiden.
In einigen Ausführungsformen ist der Speicher-Arbiter 140 so konfiguriert, dass er, wenn die Speicherzugriffsanfragen von allen Ports des OCM 110 bei jedem Taktzyklus eingehen, zunächst die Anzahl der Port-Zugriffsanfragen mit der angegebenen Throttle_port_num vergleicht. Wie in 3B gezeigt, ist der Speicher-Arbiter 140 so konfiguriert, dass er, wenn die Gesamtzahl der Portzugriffsanfragen größer ist als die Throttle_port_num (304), die zufällige Portzugriffs-Gewährungsmaske verwendet, um die an einigen der Ports empfangenen Anforderungen auszublenden. Da die Portzugriffs-Gewährungsmaske jedoch zufällig ohne Kenntnis eines Musters der Port-Zugriffs-Anforderungen erstellt wurde, können einige der Port-Zugriffs-Anforderungen übermäßig maskiert und übermäßig gedrosselt werden, was zu einer übermäßigen Drosselung der Port-Zugriffs-Anforderungen führt. Um diesen Effekt zu kompensieren, ist der Speicher-Arbiter 140 so konfiguriert, dass er ein Leaky-Bucket-Credit-Schema anwendet, das den Credit-Zähler 160 zunächst auf Null setzt und bei jedem Taktzyklus (306) zusätzliche Credit-Token in Höhe der Throttle_port_num zum Credit-Zähler 160 hinzufügt. Wenn eine Anzahl von Portzugriffsanfragen gewährt wird, ist der Speicher-Arbiter 140 so konfiguriert, dass er die Anzahl der gewährten Portzugriffsanfragen berechnet und von den Credit-Token im Credit-Zähler 160 subtrahiert (308). Wenn die Ports zum OCM 110 übermäßig belastet sind, werden die im Credit-Zähler 160 angesammelten Credit-Token positiv. Wenn dies geschieht (der Credit-Zähler 160 ist positiv), ist der Speicher-Arbiter 140 so konfiguriert, dass er die Port-Drosselung für einen Taktzyklus, d. h. für den nächsten Taktzyklus, vorübergehend deaktiviert/aussetzt. Während dieses nächsten Taktzyklus ist der Speicher-Arbiter 140 so konfiguriert, dass er alle Speicherzugriffsanfragen unabhängig von der Throttle_port_num gewährt, indem er alle Bits in der Portzugriffs-Gewährungsmaske auf 1s (310) setzt und die Credit-Token im Credit-Zähler 160 entsprechend aktualisiert. Dies kann dazu führen, dass mehr Credit-Token verbraucht werden, als sie zugewiesen wurden, wodurch der Credit-Zähler 160 negativ wird. In einigen Ausführungsformen ist der Speicher-Arbiter 140 so konfiguriert, dass er die Port-Drosselung wieder aufnimmt/aktiviert, wenn der Gesamtstromverbrauch durch die Speicherzugriffsanfragen die vom Benutzer festgelegte Obergrenze für den Gesamtstromverbrauch überschreitet. Sobald die Anzahl der Credit-Token im Credit-Zähler 160 negativ wird, ist der Speicher-Arbiter 140 so konfiguriert, dass er die Port-Drosselung wieder aktiviert, indem er die Portzugriffs-Gewährungsmaske beim nächsten Zyklus wieder aktiviert. Obwohl das Schema der Leaky-Bucket-Port-Drosselung zu einem vorübergehend hohen Stromverbrauch führen kann, wird die durchschnittliche Anzahl der Port-Zugriffsanfragen, die pro Zyklus gewährt werden, im Laufe der Zeit der Drossel-Port-Anzahl entsprechen, was den Stromverbrauch des OCM 110 im Durchschnitt auf den Grenzwert glättet. Beachten Sie, dass die Leaky-Bucket-Port-Drosselung nur von der Gesamtzahl der gewährten Port-Zugriffsanforderungen abhängt und daher keine zeitlichen Abhängigkeiten vom Takt aufweist und keine Logik erfordert, welche Port-Zugriffsanforderungen gewährt oder unterdrückt werden sollen.
Die vorstehende Beschreibung der verschiedenen Ausführungsformen des beanspruchten Gegenstands dient der Veranschaulichung und Beschreibung. Es ist nicht beabsichtigt, erschöpfend zu sein oder den beanspruchten Gegenstand auf die genauen offenbaren Formen zu beschränken. Viele Modifikationen und Variationen sind für den Fachmann auf dem Gebiet der Technik offensichtlich. Die Ausführungsformen wurden ausgewählt und beschrieben, um die Prinzipien der Erfindung und ihre praktische Anwendung bestmöglich zu beschreiben und dadurch den Fachmann in die Lage zu versetzen, den beanspruchten Gegenstand, die verschiedenen Ausführungsformen und die verschiedenen Modifikationen zu verstehen, die für die jeweils in Betracht gezogene Verwendung geeignet sind.

Claims

Hardwarebasiertes programmierbares System zur Unterstützung eines energieeffizienten Speicherzugriffs für Maschinenlernen (ML), umfassend: einem On-Chip-Speicher (OCM), umfassend: ein oder mehrere Speicherfelder, die so konfiguriert sind, dass sie Daten in einer Stream-Art für den Zugriff durch eine oder mehrere Verarbeitungseinheiten für verschiedene ML-Operationen annehmen und verwalten; eine Vielzahl von Ports, wobei jeder Port der Vielzahl von Ports individuell freigegeben ist, um durch die eine oder mehrere Verarbeitungseinheiten zugreifbar zu sein, um die Daten in dem OCM über eine Port-Zugriffsanforderung einer Vielzahl von Port-Zugriffsanforderungen zu lesen und/oder zu schreiben, wobei jeder Port der Vielzahl von Ports konfiguriert ist, um die Port-Zugriffsanforderung zum Zugriff auf die Daten in dem OCM zur gleichen Zeit während des gleichen Taktzyklus zu akzeptieren; einen Speicher-Arbiter, der konfiguriert ist zum: Akzeptieren der Vielzahl von Port-Zugriffsanforderungen an der entsprechenden Vielzahl von Ports des OCM; Drosseln von einer oder mehreren Port-Zugriffsanforderungen der Vielzahl von Port-Zugriffsanforderungen, indem nur einer Teilmenge solcher Anforderungen der Zugriff auf den OCM über die entsprechenden Ports zur gleichen Zeit basierend auf einem oder mehreren Parametern gewährt wird, um den Stromverbrauch des OCM zu begrenzen.
Verarbeitungseinheit nach Anspruch 1, wobei: die eine oder mehreren Verarbeitungseinheiten eine erste Verarbeitungseinheit umfassen, die so konfiguriert ist, dass sie dichte oder regelmäßige Berechnungen an den Daten in dem OCM durchführt.
Verarbeitungseinheit nach Anspruch 2, wobei: die eine oder die mehreren Verarbeitungseinheiten eine zweite Verarbeitungseinheit umfassen, die so konfiguriert ist, dass sie spärliche/unregelmäßige Berechnungen und/oder komplexe Datenformtransformationen der Daten im OCM und/oder von der ersten Verarbeitungseinheit durchführt.
Verarbeitungseinheit nach Anspruch 1, wobei: der Speicher-Arbiter von einem Benutzer über einen Host konfiguriert wird, um den einen oder die mehreren Parameter als Teil einer Speicherzugriffsrichtlinie dynamisch zur Laufzeit zu setzen oder zu programmieren, wenn auf den OCM von der einen oder den mehreren Verarbeitungseinheiten über die Port-Zugriffsanfragen zugegriffen wird.
Verarbeitungseinheit nach Anspruch 1, wobei: der eine oder die mehreren Parameter eine maximale Anzahl von Ports umfassen, die gleichzeitig Zugriff auf den OCM anfordern dürfen, um den Stromverbrauch des OCM so zu begrenzen, dass er innerhalb eines Budgets liegt.
Verarbeitungseinheit nach Anspruch 1, wobei: der eine oder die mehreren Parameter eine benutzerspezifizierte bevorzugte Port-Maske eines oder mehrerer Ports umfassen, die für den OCM-Zugriff bevorzugt werden, wobei die Port-Zugriffsanforderungen an diese Ports nicht gedrosselt werden.
Verarbeitungseinheit nach Anspruch 1, wobei: der eine oder die mehreren Parameter einen benutzerspezifizierten gewichteten Vektor aufweisen, der Prioritäten/Gewichte auf einem oder mehreren Ports für den OCM-Zugriff festlegt, und die Port-Zugriffsanforderungen zu den Ports mit niedrigeren Prioritäten zuerst gedrosselt werden und die Port-Zugriffsanforderungen zu den Ports mit höheren Prioritäten zuletzt gedrosselt werden oder es vermieden wird, gedrosselt zu werden, es sei denn, es ist absolut notwendig.
Verarbeitungseinheit nach Anspruch 7, wobei: der Speicher-Arbiter so konfiguriert ist, dass er eine benutzerspezifische bevorzugte Port-Maske und/oder den benutzerspezifischen gewichteten Vektor verwendet, um eine Drosselung der Portzugriffsanfragen an bestimmte Ports zu vermeiden, um auf den OCM zuzugreifen.
Verarbeitungseinheit nach Anspruch 1, wobei: der eine oder die mehreren Parameter eine benutzerspezifizierte Obergrenze für den Gesamtstromverbrauch durch die Port-Zugriffsanforderungen an den OCM umfassen.
Verarbeitungseinheit nach Anspruch 1, wobei: der Speicher-Arbiter so konfiguriert ist, dass er die eine oder mehreren Portzugriffsanfragen über eine strenge Port-Drosselung drosselt, wobei, wenn die Anzahl der von allen Ports des OCM empfangenen Portzugriffsanfragen größer ist als die konfigurierte maximale Anzahl von Ports, die gleichzeitig Zugriff auf das OCM anfordern dürfen, nur eine Anzahl von Portzugriffsanfragen gewährt wird, die gleich der konfigurierten maximalen Anzahl von Ports ist.
Verarbeitungseinheit nach Anspruch 10, wobei: der Speicher-Arbiter so konfiguriert ist, dass er den Rest der Portzugriffsanfragen basierend auf einer Zufallsauswahl unterdrückt, indem er eine Portzugriffs-Gewährungsmaske setzt, die alle Ports des OCM abdeckt und entsprechend ein Bit pro Port darstellt.
Verarbeitungseinheit nach Anspruch 10, wobei: der Speicher-Arbiter so konfiguriert ist, dass er die Anzahl der zu unterdrückenden Portzugriffsanfragen aufgrund der Zeitbeschränkungen und/oder der Komplexität der möglichen Permutationen zur Auswahl unter den zu unterdrückenden Portzugriffsanfragen begrenzt.
Verarbeitungseinheit nach Anspruch 1, wobei: der Speicher-Arbiter so konfiguriert ist, dass er die eine oder die mehreren Port-Zugriffsanfragen über Leaky-Bucket-Port-Drosselung drosselt, wobei der Speicher-Arbiter so konfiguriert ist, dass er die Anzahl der Port-Zugriffsanfragen, die auf den OCM zugreifen dürfen, so drosselt, dass sie innerhalb eines bestimmten Bereichs liegt, basierend auf einem Credit-Zähler, der einen Bucket von Credit-Token verwaltet.
Verarbeitungseinheit nach Anspruch 13, wobei: der Speicher-Arbiter so konfiguriert ist, dass er in dem Credit-Zähler zu Beginn null Credit-Token setzt und dem Credit-Zähler bei jedem Taktzyklus zusätzliche Credit-Token hinzufügt, die der konfigurierten maximalen Anzahl von Ports entsprechen, die gleichzeitig Zugriff auf den OCM anfordern dürfen.
Verarbeitungseinheit nach Anspruch 14, wobei: der Speicher-Arbiter konfiguriert ist zum Subtrahieren der Anzahl der gewährten Port-Zugriffsanforderungen von den Credit-Token im Credit-Zähler, wenn eine Anzahl von Port-Zugriffsanforderungen gewährt wird; vorübergehenden Deaktivieren der Port-Drosselung für einen Taktzyklus beim nächsten Taktzyklus, wenn die im Credit-Zähler akkumulierten Credit-Token positiv werden, wobei alle Port-Zugriffsanforderungen unabhängig von der konfigurierten maximalen Anzahl von Ports, die gleichzeitig Zugriff auf den OCM anfordern dürfen, gewährt werden; Aktualisieren des Credit-Tokens im Credit-Zähler entsprechend.
Verarbeitungseinheit nach Anspruch 15, wobei: der Speicher-Arbiter so konfiguriert ist, dass er die Port-Drosselung durch erneutes Aktivieren einer Portzugriffs-Gewährungsmaske beim nächsten Zyklus wieder aktiviert, sobald die Anzahl der Credit-Token im Credit-Zähler negativ wird.
Verarbeitungseinheit nach Anspruch 15, wobei der Speicher-Arbiter so konfiguriert ist, dass er die Port-Drosselung wieder aktiviert, wenn der Gesamtstromverbrauch durch die Speicherzugriffsanfragen eine benutzerspezifizierte Obergrenze für den Gesamtstromverbrauch überschreitet.
Verfahren zur Unterstützung eines energieeffizienten Speicherzugriffs für Maschinenlernen (ML), umfassend: Akzeptieren und Halten von Daten in einem On-Chip-Speicher (OCM) für den Zugriff durch eine oder mehrere Verarbeitungseinheiten für verschiedene ML-Operationen; Freigeben einer Vielzahl von Ports des OCM, wobei jeder Port der Vielzahl von Ports individuell freigegeben wird, um durch die eine oder mehrere Verarbeitungseinheiten zugreifbar zu sein, um die Daten in dem OCM über eine Port-Zugriffsanforderung einer Vielzahl von Port-Zugriffsanforderungen zu lesen und/oder zu schreiben, wobei jeder Port der Vielzahl von Ports konfiguriert ist, um die Port-Zugriffsanforderungen zum Zugriff auf die Daten in dem OCM zur gleichen Zeit während des gleichen Taktzyklus zu akzeptieren; Akzeptieren der Vielzahl von Port-Zugriffsanforderungen an der entsprechenden Vielzahl von Ports des OCM; Drosseln einer oder mehrerer Port-Zugriffsanforderungen der Vielzahl von Port-Zugriffsanforderungen, indem nur einer Teilmenge solcher Anforderungen der Zugriff auf das OCM über die entsprechenden Ports zur gleichen Zeit gewährt wird, basierend auf einem oder mehreren Parametern, um den Stromverbrauch des OCM zu begrenzen.
Verfahren nach Anspruch 18, des Weiteren umfassend: Ermöglichen, dass ein Benutzer einen Speicher-Arbiter über einen Host konfiguriert und/oder programmiert, wobei der Host den einen oder die mehreren Parameter als Teil einer Speicherzugriffsrichtlinie dynamisch zur Laufzeit einstellt, wenn auf den OCM durch die eine oder die mehreren Verarbeitungseinheiten über die Port-Zugriffsanfragen zugegriffen wird.
Verfahren nach Anspruch 18, des Weiteren umfassend: Verwenden einer benutzerspezifizierten bevorzugten Port-Maske und/oder eines benutzerspezifizierten gewichteten Vektors, um ein Drosseln der Port-Zugriffsanforderungen auf bestimmte Ports zu vermeiden, um auf den OCM zuzugreifen.
Verfahren nach Anspruch 18, des Weiteren umfassend: Drosseln der einen oder mehreren Port-Zugriffsanforderungen über strikte Port-Drosselung, wobei, wenn die Anzahl der von allen Ports des OCM empfangenen Port-Zugriffsanforderungen größer ist als die konfigurierte maximale Anzahl von Ports, die gleichzeitig Zugriff auf das OCM anfordern dürfen, wobei nur eine Anzahl von Port-Zugriffsanforderungen gewährt wird, die gleich der konfigurierten maximalen Anzahl von Ports ist.
Verfahren nach Anspruch 21, des Weiteren umfassend: Unterdrücken der restlichen Portzugriffs-Anforderungen auf Basis einer Zufallsauswahl durch Setzen einer Portzugriffs-Gewährungsmaske, die alle Ports des OCM abdeckt und entsprechend ein Bit pro Port darstellt.
Verfahren nach Anspruch 21, des Weiteren umfassend: Begrenzen der Anzahl der zu unterdrückenden Port-Zugriffsanforderungen aufgrund der Zeitbeschränkungen und/oder der Komplexität der möglichen Permutationen zur Auswahl unter den zu unterdrückenden Port-Zugriffsanforderungen.
Verfahren nach Anspruch 18, des Weiteren umfassend: Drosseln der einen oder mehreren Port-Zugriffsanfragen über Leaky-Bucket-Port-Drosselung, wobei der Speicher-Arbiter so konfiguriert ist, dass er die Anzahl der Port-Zugriffsanfragen, die auf das OCM zugreifen dürfen, so drosselt, dass sie innerhalb eines bestimmten Bereichs liegt, basierend auf einem Credit-Zähler, der einen Bucket von Credit-Token verwaltet.
Verfahren nach Anspruch 24, des Weiteren umfassend: Setzen von Null Credit-Token in dem Credit-Zähler, um mit diesem zu beginnen, und Hinzufügen von zusätzlichen Credit-Token, die der konfigurierten maximalen Anzahl von Ports entsprechen, die gleichzeitig Zugriff auf den OCM anfordern dürfen, zu dem Credit-Zähler bei jedem Taktzyklus.
Verfahren nach Anspruch 25, des Weiteren umfassend: Subtrahieren der Anzahl der gewährten Port-Zugriffsanforderungen von den Credit-Token im Credit-Zähler, wenn eine Anzahl von Port-Zugriffsanforderungen gewährt wird; vorübergehendes Deaktivieren der Port-Drosselung für einen Taktzyklus beim nächsten Taktzyklus, wenn die im Credit-Zähler angesammelten Credit-Token positiv werden, wobei alle Port-Zugriffsanforderungen gewährt werden, unabhängig von der konfigurierten maximalen Anzahl von Ports, die gleichzeitig Zugriff auf den OCM anfordern dürfen; entsprechendes Aktualisieren der Credit-Token im Credit-Zähler.
Verfahren nach Anspruch 26, das des Weiteren umfasst: erneutes Aktivieren der Port-Drosselung durch erneutes Aktivieren einer Portzugriffs-Gewährungsmaske im nächsten Zyklus, sobald die Anzahl der Credit-Token im Credit-Zähler negativ wird.
Verfahren nach Anspruch 26, das weiterhin umfasst: erneutes Aktivieren der Port-Drosselung, wenn der Gesamtstromverbrauch durch die Port-Zugriffsanforderungen eine benutzerspezifizierte Obergrenze für den Gesamtstromverbrauch überschreitet.