DE102022118656A1

DE102022118656A1 - Verwenden eines Vektorprozessors zum Konfigurieren eines Direktspeicherzugriffssystems für Merkmalsnachverfolgungsoperationen in einem System auf einem Chip

Info

Publication number: DE102022118656A1
Application number: DE102022118656.3A
Authority: DE
Inventors: Ahmad Itani; Yen-Te Shih; Jagadeesh Sankaran; Ravi P. Singh; Ching-Yu Hung
Original assignee: Nvidia Corp
Current assignee: Nvidia Corp
Priority date: 2021-08-02
Filing date: 2022-07-26
Publication date: 2023-02-02
Also published as: JP2023024945A; CN115701594A; CN115701593A; DE102022118655A1

Abstract

In verschiedenen Beispielen können eine VPU und zugehörige Komponenten optimiert werden, um die Leistung und den Durchsatz der VPU zu verbessern. Zum Beispiel kann die VPU einen Min/Max-Sammler, eine automatische Speicherprädikationsfunktionalität, eine SIMD-Datenpfadorganisation, die eine gemeinsame Nutzung zwischen Spuren ermöglicht, einen transponierten Lade-/Speichervorgang mit Schrittparameterfunktionalität, einen Ladevorgang mit Permutations- und Nulleinfügungsfunktionalität, Hardware-, Logik- und Speicherlayoutfunktionalität, um Zwei-Punkt- und Zwei-mal-Zwei-Punkt-Abfragen zu ermöglichen, und Lade-Caching-Fähigkeiten pro Speicherbank beinhalten. Zusätzlich können entkoppelte Beschleuniger verwendet werden, um VPU-Verarbeitungs-Tasks auszulagern, um Durchsatz und Leistung zu erhöhen, und ein Hardware-Sequenzer kann in einem DMA-System beinhaltet sein, um die Programmierkomplexität der VPU und des DMA-Systems zu reduzieren. Der DMA und die VPU können einen VPU-Konfigurationsmodus ausführen, der es der VPU und dem DMA ermöglicht, ohne eine Verarbeitungssteuerung zum Durchführen von Datenbewegungsoperationen auf Grundlage dynamischer Bereiche zu arbeiten.

Description

ALLGEMEINER STAND DER TECHNIK
Vektorverarbeitungseinheiten (Vector Processing Unit - VPU) werden verwendet, um Operationen mit einer Anweisung für viele Daten (Single Instruction Multiple Data - SIMD) parallel durchzuführen. Verbreitete Verwendungen von VPUs beinhalten Operationen wie Bildverarbeitung, Computer-Vision, Signalverarbeitung, Deep Learning (z. B. für Faltungsoperationen) und/oder dergleichen.
In manchen Computer-Vision-Anwendungen werden zum Beispiel dynamische Bereiche von Zwischenwerten gut verstanden. Somit können berechnete Werte mit diesen dynamischen Bereichen verglichen werden, um Anomalien zu erkennen. Herkömmliche Lösungen zum Erkennen und Analysieren dieser Minimal- und Maximalwerte beinhalten jedoch das Schreiben aller Werte in einen Speicher und das anschließende Durchführen einer Analyse der Werte im Speicher, was zusätzliche Verarbeitungszyklen erfordert. Zusätzlich können Prozessoren mit hoher Taktrate, um einen hohen Durchsatz trotz Lade-Verwendung-Latenz zu erreichen, Software-Pipelining und/oder Schleifenentrollen durchführen. Wenn sich jedoch eine ursprüngliche Iterationszahl nicht gleichmäßig durch den Entrollungsfaktor dividieren lässt, kann es eine gewisse Anzahl von Iterationen geben, die nach Abschluss der entrollten Schleife verbleiben, wodurch eine zusätzliche Restschleife erforderlich ist, um die Werte der letzten Iteration(en) zu berechnen. Diese Restschleife erhöht die Codegröße und die Latenz des Systems - z. B. weil die Restschleife nicht entrollt werden kann, um eine optimale Leistung zu erzielen. Bei herkömmlichen SIMD-Operationen kann jede SIMD-Einheit parallel und unabhängig von anderen in ihrer eigenen Datenspur arbeiten. Einige Architekturen können die gemeinsame Nutzung durch angrenzende Nachbarn ermöglichen, aber diese begrenzte gemeinsame Nutzung ist restriktiv und führt dazu, dass die Implementierung von Operationen häufig das Kopieren eines gleichen Operanden auf jede Datenspur zur Verarbeitung erfordert. Außerdem können Vektor-SIMD-Prozessoren erfordern, dass jede Speicherleseoperation eine standardmäßige oder konsistente Einheit verwendet, z. B. gleich einer Vektorverarbeitungsbreite, was ineffizient sein kann, wenn die Speicherbank breit ist. Wenn beispielsweise von den Elementen 4 bis 67 mit einer Speicherbreite von 64 Bytes gelesen wird, können zwei Speicherlesevorgänge erforderlich sein - z. B. einer von 0 bis 63 und einer von 64 bis 67. Dies führt jedoch dazu, dass viele zusätzliche Werte gelesen werden - z. B. die Werte 0-3 und die Werte 68-127 - selbst wenn diese Werte für die aktuelle Operation nicht benötigt werden. In herkömmlichen Anweisungssätzen, bei denen eine zusätzliche Datenmanipulation erforderlich ist, können die zusätzlichen Anweisungen verwendet werden, um Speicherdaten in Registern zu bearbeiten, nachdem die Daten ausgelesen und in den Registern gespeichert wurden. Dies kann beispielsweise das Laden der Daten, das Durchführen von Permutationen an den Daten und das anschließende Verwenden der reorganisierten Daten zum Durchführen von Operationen erfordern. Somit erfordert die Datenmanipulation zusätzliche Zyklen und erhöht die Latenz. Beim Durchführen von Tabellenabfragen unter Verwendung vorhandener VPUs können die Tabellen so repliziert werden, dass jeder einzelne Wert aus einer replizierten Tabelle entnommen werden kann, oder es können zusätzliche Leseports zu jeder Speicherbank hinzugefügt werden, damit mehrere Werte aus einer gleichen Tabelle in einer gleichen Bank gelesen werden können. Das Replizieren einer Tabelle für jeden Wert erfordert jedoch zusätzlichen Speicher und Verarbeitung, und das Hinzufügen zusätzlicher Leseports erfordert zusätzlichen Platz auf dem Chip. Da die VPUs bei herkömmlichen VPUs so programmiert ist, dass sie auf einem kleineren Satz hochoptimierten Codes ausgeführt wird, können Daten-Caches nicht implementiert werden, da Programmierer die Inhalte im lokalen Datenspeicher verwalten können. Dadurch erfordert jedoch jeder Zugriff das Lesen von Werten aus jeder Speicherbank, selbst wenn die Daten für eine nächste Iteration eine Überlappung mit einer oder mehreren vorherigen Leseoperationen beinhalten.
Um die Leistung von Prozessoren - wie etwa VPUs - zu optimieren, kann die Anweisungssatzarchitektur (Instruction Set Architecture - ISA) verbessert werden, um benutzerdefinierte Anweisungen zu erstellen, um häufig auftretende Operationen zu beschleunigen - wie etwa Tabellenabfragen, Faltungsoperationen und/oder dergleichen. Die Verwendung der ISA auf diese Weise erfordert jedoch, dass der Prozessor selbst auch diese Operationen ausführt, was bedeutet, dass der Prozessor während der Ausführung dieser erweiterten Anweisungen beschäftigt ist.
Außerdem kann eine VPU ein System mit Direktspeicherzugriff (Direct Memory Access - DMA) verwenden, um Daten zur Verarbeitung durch die VPU abzurufen. Somit kann das DMA-System als eine Datenbewegungs-Engine arbeiten, kann aber auch zusätzliche Operationen durchführen, wie Bildauffüllung, Adressmanipulation, überlappende Datenverwaltung, Verwaltung der Durchquerungsreihenfolge, Frame-Größenverwaltung und/oder dergleichen. Die Programmierkomplexität zum Programmieren des DMA-Systems und der VPU wird jedoch erhöht, wenn DMA-Ressourcen - z. B. Deskriptoren, Kanäle, Auslöser usw. - erhöht werden. Wenn Kacheln eines Frames räumliche oder zeitliche Abhängigkeiten beinhalten, wird die dynamische Aktualisierung von DMA-Ressourcen zu einer Verarbeitungslast für das System. Beim Abrufen unbekannter oder datenabhängiger Daten haben herkömmliche DMA-Systeme eine Verarbeitungssteuerung erfordert (z. B. einen R5- oder ARM-Verarbeitungskern), um in den Verarbeitungszyklus einzugreifen, um aktualisierte Informationen zum Anweisen einer nächsten Verarbeitungsiteration zu bestimmen. Beispielsweise kann die VPU bei der Objekt- oder Merkmalsnachverfolgung eine nächste Stelle eines Objekts oder Merkmals berechnen, und die Verarbeitungssteuerung würde dann eingreifen, die Speicheradressierungsinformationen aktualisieren und dann das DMA-System auslösen, um die aktualisierten Informationen zu verwenden. Das Eingreifen der Verarbeitungssteuerung erhöht jedoch die Latenz und erfordert eine komplexere Programmierung für Operationen mit bereichsabhängigen Datenbewegungsalgorithmen.
Darüber hinaus gibt es in sicherheitskritischen Anwendungen wie autonomen und halbautonomen Maschinenanwendungen strenge Anforderungen an die permanente Fehlererkennung und -isolierung. Wenn beispielsweise Deep Learning, Computer-Vision, Sensorverarbeitung und/oder andere Anwendungen in einer Maschine ausgeführt werden, muss die permanente Fehlererkennung regelmäßig und innerhalb eines zugewiesenen Zeitbudgets ausgeführt werden, um genaue Tests zu ermöglichen, aber auch um zu ermöglichen, dass die Anwendung richtig funktioniert - z. B. mit geringer Latenz. Dazu kann eine Ende-zu-Ende-Abdeckung mit geringer Latenz erforderlich sein, während das Laufzeitbudget jeder konkreten Anwendung eingehalten wird. Herkömmliche Ansätze verwenden einen integrierten Selbsttest (Built-In Self-Test - BIST) zum Feststellen von Fehlern, aber diese BIST-Techniken beinhalten entweder keine angemessene Abdeckung, führen zu viel Latenz in das System ein und/oder erfüllen nicht die Laufzeitbudgets für gewisse Anwendungen.
KURZDARSTELLUNG
Ausführungsformen der vorliegenden Offenbarung beziehen sich auf Verbesserungen an Vektorverarbeitungseinheiten (VPUs), auf entkoppelte Beschleuniger, die verwendet werden können, um eine ausgelagerte Verarbeitung von der VPU zu handhaben, und auf ein System mit Direktspeicherzugriff (DMA), das eine Datenbewegung zwischen einem Speicher und der VPU unterstützt. Um verschiedenen Nachteilen herkömmlicher oder vorhandener Lösungen Rechnung zu tragen, kann die VPU der vorliegenden Offenbarung einen Min/Max-Hardware-Sammler beinhalten, der in einem Datenpfad von der VPU zum Speicher beinhaltet ist, sodass Min/Max-Werte vor der Speicherung in dem Speicher gespeichert werden können. Auf diese Weise können die Min/Max-Werte unmittelbar nach Abschluss der Speicherschreiboperation verfügbar sein, wodurch die Latenz zum Bestimmen von Min/Max verringert wird, nachdem die Werte im Speicher gespeichert wurden. Zusätzlich kann die VPU eine automatische Prädikationfunktion beinhalten, die ein Prädikations-Flag anwenden kann, indem sie ein Prädikations-Bit für jeden Wert setzt, der bei Iterationen nach einer letzten Iteration berechnet wird. Als Ergebnis kann jeder Satz von Iterationen eine gleiche Anzahl von ausgeführten Iterationen beinhalten, aber einer oder mehrere der Werte aus dem letzten Satz von Iterationen werden aufgrund des Prädikations-Flags möglicherweise nicht in den Speicher geschrieben. Um die Einschränkungen bei der gemeinsamen Nutzung zwischen Datenspuren bestehender Lösungen zu berücksichtigen, kann die SIMD-Architektur der vorliegenden Offenbarung Slices in einem Prozessor definieren, die jeweils mehrere Spuren beinhalten, und jede der Spuren kann konfiguriert sein, um mit anderen zu kommunizieren. Somit können Operanden von einer Spur durch andere Spuren verwendet werden, wodurch die Anforderung beseitigt wird, dass jeder der Operanden zur Verarbeitung in jede Spur kopiert werden muss. Um die Ineffizienzen beim Laden aus einer einzigen breiten Speicherbank zu berücksichtigen, kann die VPU eine Vielzahl von kleineren Speicherbanken beinhalten, um kleinere Bitausrichtungen zu ermöglichen - z. B. 16-Bit-Ausrichtungen, wobei Speicherbanken jeweils 16 Bits sind. Auf diese Weise kann das Beispiel des Lesens der Werte 4 bis 67 in einem einzigen Speicherlesevorgang statt in zwei Speicherlesevorgängen von 0-63 und 64-127 stattfinden. Zusätzlich zu dieser Speicherbankorganisation kann die VPU eine transponierte Lade- und/oder Speicherfunktionalität beinhalten, um zu ermöglichen, dass gespeicherte Werte in Speicherbanken versetzt sind, sodass keine Bankkonflikte auftreten und mehr Daten pro Zyklus gelesen oder geschrieben werden können. Um die Datenmanipulationsnachteile herkömmlicher Anweisungssätze zu berücksichtigen, kann eine Lade-mit-Permutation-Anweisung verwendet werden, um ein Permutationsmuster zusammen mit einer Speicheradresse an den lokalen Speicher zu senden, um die Daten gemäß dem Permutations- oder Datenmanipulationsmuster aus dem Speicher abzurufen. Somit können die Datenmanipulation und das Datenladen in einem gleichen Zyklus ausgeführt werden, wodurch die Latenz reduziert wird. Um die Nachteile der Tabellenreplikation pro Wert oder zusätzlicher Leseports für Tabellenabfragen anzugehen, kann eine Zwei-Punkt- oder Zwei-mal-Zwei-Punkt-Abfrage ausgeführt werden, sodass zwei bzw. vier Punkte pro Tabelle pro Zyklus abgefragt werden können. Um dies zu erreichen, kann ein versetztes Speichermuster für die Tabelle und Adressbusse pro Speicherbank und die zugeordnete Logik und das zugeordnete Routing verwendet werden, um parallele Abfragen von zwei Punkten oder vier Punkten zu ermöglichen. In Ausführungsformen kann jede Speicherbank einen zugeordneten Daten-Cache beinhalten, der abhängig von einer gegebenen Operation aktiviert oder deaktiviert werden kann. Zum Beispiel können die Daten-Caches für Filteroperationen, bei denen viele Datenüberlappungen zwischen Iterationen vorhanden sind, verwendet werden, um Werte von einer oder mehreren vorherigen Abfragen zu speichern, sodass nur minimale Lesevorgänge von jeder Bank erforderlich sind, wodurch Energie und Strom für das System gespart werden.
Um die Nachteile herkömmlicher ISAs für VPUs oder andere Prozessortypen anzugehen, können die Systeme und Verfahren der vorliegenden Offenbarung entkoppelte Beschleuniger verwenden, die durch die VPU konfiguriert und über einen gemeinsam genutzten Speicher mit ihr kommunizieren können, aber bestimmte Tasks unabhängig von der VPU ausführen können, um der VPU zu ermöglichen, andere Verarbeitungs-Tasks parallel mit dem/den Beschleuniger(n) fortzusetzen. Beispielsweise kann ein Beschleuniger einer entkoppelten Lookup-Tabelle (Decoupled Lookup Table - DLUT) verwendet werden, um die Leistung des Systems zu erhöhen, wenn Tabellenabfragen durchgeführt werden. Auf diese Weise kann der DLUT-Beschleuniger Konflikte identifizieren, Konflikte umgehen und den Durchsatz des Systems erhöhen, anstatt dass die VPU Speicherbankkonflikterkennung und -auflösung inline durchführt.
Um den Nachteilen herkömmlicher DMA-Systeme Rechnung zu tragen, können die Systeme und Verfahren der vorliegenden Offenbarung einen Hardware-Sequenzer beinhalten, der Frame-Daten bearbeitet, die eine Abfolge von Befehlen für den Hardware-Sequenzer beinhalten. Zum Beispiel kann der Hardware-Sequenzer eher auf Frame-Ebene als auf Kachelebene arbeiten und kann eine Sequenzierung für eine DMA-Engine durchführen, um die Programmierkomplexität zum Programmieren der DMA-Engine zum Ausführen derselben Operationen - wie Auffüllen, Adressmanipulation usw. - zu beseitigen. In einigen Ausführungsformen kann das DMA-System einen DMA-Auslösemodus umfassen, in dem die DMA-Engine die Bewegung von Kacheln in den Vektorspeicher (Vector Memory - VMEM) steuert, anstatt von der VPU zu verlangen, dass sie den DMA auslöst, um eine nächste Kachel zu laden. Somit wird die Befehlsabfolge umgekehrt und der DMA wird zum Auslöser für die VPU. Um die Nachteile von bereichsabhängigen Datenbewegungsoperationen in einem DMA-System zu berücksichtigen, kann das DMA-System den DMA und die VPU verwenden, um in einer eng gekoppelten Schleife zu arbeiten, ohne dass ein Eingriff der Verarbeitungssteuerung erforderlich ist. Beispielsweise kann die VPU Positionsinformationen im VMEM für die verschiedenen nachverfolgten Merkmale und/oder Objekte aktualisieren, und der DMA kann diese aktualisierten Informationen verwenden, um Deskriptoren im Deskriptorspeicher zu aktualisieren, sodass die nächsten Daten, die der VPU zur Verarbeitung bereitgestellt werden, der nächsten Position für das Merkmal oder Objekt entsprechen. Dieser Prozess kann sich wiederholen, bis die Verarbeitung abgeschlossen ist, wodurch das Erfordernis des Eingreifens der Verarbeitungssteuerung entfällt und die Latenz des Systems verringert wird.
Zusätzlich können die vorliegenden Systeme und Verfahren, um den Mängeln herkömmlicher BIST-Ansätze Rechnung zu tragen, einen Mehrfacheingangs-Signaturregister (Multiple Input Signature Register - MISR)-BIST ausführen - z. B. um eine Fehlererkennung eines programmierbaren Visionsbeschleunigers (Programmable Vision Accelerator - PVA) eines Systems auf einem Chip (System on a Chip - SoC) durchzuführen. Beispielsweise kann ein PVA in verschiedenen Ausführungsformen der vorliegenden Offenbarung ein oder mehrere DMA-Systeme und eine oder mehrere VPUs beinhalten, die unter Verwendung einer oder mehrerer Verarbeitungssteuerungen (oder Steuerprozessoren), wie etwa einem R5-Prozessor und einem ARM-Prozessor, einer CPU und/oder dergleichen, gesteuert werden. Somit kann jede Komponente des PVA ein Testen erfordern, und die vorliegenden Systeme und Verfahren führen den MISR-BIST aus, um permanente Fehler in einer Ende-zu-Ende-Weise zu erkennen. Auf diese Weise kann die permanente Fehlererkennung ausgeführt werden, um Ende-zu-Ende-Blöcke sowohl für die Steuer- als auch für die Datenlogik abzudecken, mit direkter Fehlermeldung an einen Sicherheitsprozessor, um die Latenz zu reduzieren, und mit Anpassung für konkrete Anwendungen, um die damit verbundenen Laufzeitbudgets zu erfüllen.
Figurenliste
Die vorliegenden Systeme und Verfahren für Verbesserungen an Vektorverarbeitungseinheiten (VPUs) werden im Folgenden unter Bezugnahme auf die beigefügten Zeichnungsfiguren ausführlich beschrieben, wobei Folgendes gilt:

1A ist ein beispielhaftes Minimum/Maximum-Sammlungssystem gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
1B ist ein Flussdiagramm, das ein Verfahren für eine Min/Max-Sammlung gemäß einiger Ausführungsformen der vorliegenden Offenbarung zeigt;
2A ist ein beispielhaftes System, das einen Prozessor mit einer Adressengenerierungseinheit mit automatischer Prädikationsfähigkeit beinhaltet, gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
2B ist eine Tabelle, die eine Abfolge von Zustandsänderungen im Zeitverlauf gemäß einigen Ausführungsformen der vorliegenden Offenbarung veranschaulicht;
2C ist ein Flussdiagramm, das ein Verfahren für automatische Speicherprädikation gemäß einiger Ausführungsformen der vorliegenden Offenbarung zeigt;
3A ist eine Veranschaulichung einer beispielhaften Datenpfadorganisation für Single Instruction Multiple Data (SIMD) gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
3B-3D veranschaulichen die gemeinsame Nutzung von Operanden zwischen Slices einer SIMD-Architektur für eine Filteroperation, eine Punktproduktoperation bzw. eine Operation zum Sortieren mit Nutzdaten gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
3E beinhaltet ein Flussdiagramm für ein Verfahren zum Berechnen von Ausgaben unter Verwendung gemeinsam genutzter Operanden über Spuren einer SIMD-Architektur gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
4A ist eine logische Ansicht transponierter Ladevorgänge zum Lesen aus und Schreiben in einen Speicher und eine Speicherbankansicht der transponierten Ladevorgänge entsprechend der logischen Ansicht gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
4B ist eine logische Ansicht transponierter Ladevorgänge mit verschiedenen Zeilenabständen und Schrittparametern zum Lesen aus und Schreiben in einen Speicher und eine Speicherbankansicht der transponierten Ladevorgänge entsprechend der logischen Ansicht gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
4C ist ein Flussdiagramm, das ein Verfahren zum Konfigurieren von Schreiboperationen der transponierten Ladevorgänge mit einem Schrittparameter gemäß einigen Ausführungsformen der vorliegenden Offenbarung zeigt;
4D ist ein Flussdiagramm, das ein Verfahren zum Durchführen von Schreiboperationen der transponierten Ladevorgänge mit einem Schrittparameter gemäß einigen Ausführungsformen der vorliegenden Offenbarung zeigt;
5A-5B veranschaulichen Tabellen von Daten und Koeffizientenlayouts in einer SIMD-Architekturfür unterschiedliche Funktionen gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
5C veranschaulicht eine Hardwarearchitektur zum Durchführen eines Ladevorgangs mit Permutation und Nulleinfügung gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
5D veranschaulicht eine beispielhafte Verwendung der Hardwarearchitektur der 5C gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
5E ist ein Flussdiagramm, das ein Verfahren zum Laden mit Permutation gemäß einiger Ausführungsformen der vorliegenden Offenbarung zeigt;
6A veranschaulicht eine parallele 16-Wege-Tabellenorganisation für eine Ein-Punkt-Abfrage gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
6B veranschaulicht eine parallele 8-Wege-Tabellenorganisation für eine Zwei-Punkt-Abfrage gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
6C veranschaulicht eine logische Ansicht von parallelen 2-Wege-Worttyptabellen für eine 2x2-Punkt-Abfrage gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
6D veranschaulicht eine Speicheransicht der parallelen 2-Wege-Worttyptabellen für die 2x2-Punkt-Abfrage der 6C gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
6E veranschaulicht ein Layout zum Verarbeiten von Spurpaaren unter Verwendung einer horizontalen Kombination mit einer Datenverschachtelungsoperation gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
6F veranschaulicht Zwischen- und Endergebnisse einer horizontalen Kombination mit einer Datenverschachtelungsoperation gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
6G ist ein Flussdiagramm für ein Verfahren zum Durchführen von Mehrpunktabfragen gemäß einigen Ausführungsformen der vorliegenden Offenbarung zeigt.
7A veranschaulicht Datenelemente und Koeffizientenanordnungen gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
7B-7C veranschaulichen Leseoperationen, die für Datenoperanden bzw. Koeffizientenoperanden erforderlich sind, unter Verwendung von Daten-Caches für Speicherbanken gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
7D veranschaulicht eine Speicherbankorganisation zur Verwendung mit Lade-Caches gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
7E veranschaulicht eine Hardwarearchitektur zum Verwenden von Daten-Caches in Speicherbanken gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
7F ist ein Flussdiagramm für ein Verfahren zum Verwenden von Daten-Caches für Speicherbanken gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
8A veranschaulicht ein System mit einem oder mehreren entkoppelten Beschleunigern gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
8B ist ein Flussdiagramm für ein Verfahren zum Verwenden eines entkoppelten Beschleunigers zum Durchführen einer oder mehrerer Operationen gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
9A veranschaulicht ein System mit einem entkoppelten Lookup-Tabellen-Beschleuniger gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
9B ist eine Tabelle, die Maßnahmen unterschiedlicher Komponenten eines entkoppelten Lookup-Tabellen-Beschleunigers veranschaulicht, wenn verschiedene Operationen durchgeführt werden, gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
9C ist ein Flussdiagramm für ein Verfahren zum Verwenden eines entkoppelten Lookup-Tabellen-Beschleunigers zum Durchführen einer oder mehrerer Operationen gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
10A ist eine Visualisierung, die das Auffüllen eines Frames mit aufgefüllten Werten gemäß einigen Ausführungsformen der vorliegenden Offenbarung veranschaulicht;
10B ist eine Visualisierung, die eine Adressenmanipulation für Deskriptoren eines Frames gemäß einigen Ausführungsformen der vorliegenden Offenbarung veranschaulicht;
10C ist eine Visualisierung, die überlappende Daten zwischen Kacheln eines Frames gemäß einigen Ausführungsformen der vorliegenden Offenbarung veranschaulicht;
10D beinhaltet Visualisierungen, die verschiedene Rasterdurchquerungsreihenfolgen gemäß einigen Ausführungsformen der vorliegenden Offenbarung veranschaulichen;
10E ist eine Visualisierung, die eine kubische Durchquerungsreihenfolge gemäß einigen Ausführungsformen der vorliegenden Offenbarung veranschaulicht;
10F beinhaltet Visualisierungen, die verschiedene Durchquerungsreihenfolgen für vertikales Mining gemäß einigen Ausführungsformen der vorliegenden Offenbarung veranschaulichen;
10G ist eine Visualisierung, die verschiedene Bildgrößen in einer Pyramidenkonfiguration gemäß einigen Ausführungsformen der vorliegenden Offenbarung veranschaulicht;
10H ist ein System mit Direktspeicherzugriff (DMA) mit einem Hardware-Sequenzer gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
10I ist ein Frame-Format zum Speichern von Sequenzierbefehlen für eine Hardware-Sequenzer-Steuerung des DMA-Systems der 10H gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
10J ist ein Beispiel des Frame-Formats der 10I für eine Rasterabtastsequenz gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
10K ist eine beispielhafte Kachelstruktur mit Hardware-Sequenzierung in der Rasterabtastsequenz mit Frame-Adressenverarbeitung unter Verwendung des beispielhaften Frame-Formats der 10J gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
10L ist ein Flussdiagramm für ein Verfahren zur Verwendung eines Hardware-Sequenzers in einem DMA-System gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
11A veranschaulicht ein Datenflussdiagramm für einen Prozess zum Konfigurieren eines Systems mit Direktspeicherzugriff (DMA) unter Verwendung einer Vektorverarbeitungseinheit (VPU) gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
11B ist eine Tabelle, die ein VPU-Konfigurationsformat veranschaulicht, das durch eine VPU in einen Vektorspeicher (VMEM) geschrieben und durch ein DMA-System gelesen wird, gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
11C ist ein Flussdiagramm für ein Verfahren zum Konfigurieren eines DMA-Systems unter Verwendung einer VPU gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
12A ist ein Diagramm eines Systems eines integrierten Selbsttests (BIST) zum Durchführen von Berechnungen zur zyklischen Redundanzprüfung (Cyclic Redundancy Check - CRC) eines programmierbaren Visionsbeschleunigers (PVA) gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
12B ist ein BIST-Systemdiagramm für parallele Kanal-CRC-Berechnungen eines PVA gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
12C ist ein Flussdiagramm für ein Verfahren zum Ausführen (BIST) für die permanente Fehlererkennung in einem PVA gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
13A ist eine Veranschaulichung eines beispielhaften autonomen Fahrzeugs gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
13B ist ein Beispiel für die Positionen und Sichtfelder der Kameras für das autonome Fahrzeug von 13A gemäß einiger Ausführungsformen der vorliegenden Offenbarung;
13C ist ein Blockdiagramm einer beispielhaften Systemarchitektur für das beispielhafte autonome Fahrzeug von 13A gemäß einigen Ausführungsformen der vorliegenden Offenbarung;
13D ist ein Systemdiagramm für die Kommunikation zwischen dem/den cloudbasierten Server(n) und dem beispielhaften autonomen Fahrzeug der 13A, gemäß einigen Ausführungsformen der vorliegenden Offenbarung.
14 ist ein Blockdiagramm einer beispielhaften Rechenvorrichtung, die zur Verwendung bei der Implementierung einiger Ausführungsformen der vorliegenden Offenbarung geeignet ist; und
15 ist ein Blockdiagramm eines beispielhaften Rechenzentrums, das zur Verwendung bei der Implementierung einiger Ausführungsformen der vorliegenden Offenbarung geeignet ist.

DETAILLIERTE BESCHREIBUNG
Es werden Systeme und Verfahren offenbart, die sich auf verschiedene Komponenten eines Systems auf einem Chip (SoC) beziehen - etwa eine oder mehrere Vektorverarbeitungseinheit(en) (VPU), eine Steuerung für Direktspeicherzugriff (DMA) und einen oder mehrere Hardwarebeschleuniger (z. B. einen programmierbaren Visionsbeschleuniger (PVA), wie etwa einen PVA, der ein oder mehrere Paare von VPUs und DMAs beinhaltet). Beispielsweise kann ein PVA in verschiedenen Ausführungsformen der vorliegenden Offenbarung ein oder mehrere DMA-Systeme und eine oder mehrere VPUs beinhalten, die unter Verwendung einer oder mehrerer Verarbeitungssteuerungen (oder Steuerprozessoren), wie etwa einem R5-Prozessor und einem ARM-Prozessor, einer CPU und/oder dergleichen, gesteuert werden. Auch wenn die vorliegende Offenbarung - einschließlich der verschiedenen Komponenten eines SoC - in Bezug auf ein beispielhaftes autonomes Fahrzeug 1300 (hierin alternativ auch als „Fahrzeug 1300“ oder „Ego-Fahrzeug 1300“ bezeichnet, von dem ein Beispiel mit Bezug auf die 13A-13D beschrieben wird), beschrieben werden kann, soll dies nicht einschränkend sein. Die hierin beschriebenen Systeme und Verfahren können ohne Einschränkung beispielsweise von nicht autonomen Fahrzeugen, teilautonomen Fahrzeugen (z. B. in einem oder mehreren fortschrittlichen Fahrerassistenzsystemen (advanced driver assistance system - ADAS)), gelotsten und nicht gelotsten Robotern oder Rotoberplattformen, Lagerhausfahrzeugen, Offroad-Fahrzeugen, an einen oder mehrere Anhänger gekoppelten Fahrzeugen, Fischereifahrzeugen, Booten, Shuttles, Rettungsfahrzeugen, Motorrädern, elektrischen oder motorisierten Fahrrädern, Flugzeugen, Baufahrzeugen, Unterwasserfahrzeugen, Drohnen und/oder anderen Fahrzeugtypen verwendet werden. Auch wenn die vorliegende Offenbarung in Bezug auf Computer-Vision, maschinelles Lernen, künstliche Intelligenz, Bildverarbeitung und/oder dergleichen beschrieben werden kann, soll dies außerdem nicht einschränkend sein, und die hierin beschriebenen Systeme und Verfahren können für Augmented Reality, Virtual Reality, Mixed Reality, Robotik, Sicherheit und Überwachung, autonome oder halbautonome Maschinenanwendungen und/oder alle anderen Technologieräume, in denen eine Vektorverarbeitungseinheit (VPU), ein System mit Direktspeicherzugriff (DMA), eine Anweisungssatzarchitektur (ISA), ein programmierbarer Visionsbeschleuniger (PVA), ein entkoppelter Beschleuniger, eine entkoppelte Lookup-Tabelle, ein Hardware-Sequenzer, eine SIMD-Architektur und/oder eine oder mehrere andere Komponenten eines SoC verwendet werden können, verwendet werden. Auch wenn die hierin beschriebenen Komponenten und zugehörigen Prozesse in Bezug auf ein SoC beschrieben werden können, soll dies ferner nicht einschränkend sein, und diese Komponenten können als eigenständige Komponenten, als einzelne Komponenten eines Systems und/oder als integrierte Komponenten auf einem SoC implementiert sein. In einigen Ausführungsformen können Systeme, Komponenten, Merkmale, Funktionen und/oder Verfahren der vorliegenden Offenbarung in das beispielhafte autonome Fahrzeug 1300 der 13A-13D, die beispielhafte Rechenvorrichtung 1400 der 14 und/oder das beispielhafte Rechenzentrum 1500 der 15 integriert sein.
MIN/MAX-HARDWARE-SAMMLER ZUR ERKENNUNG VON ANOMALIEN
Beispielsweise in Computer-Vision-Anwendungen und insbesondere in sicherheitskritischen Vision-Anwendungen ist die Berechnung dynamischer Bereiche von Zwischenergebnissen eine wichtige Aufgabe. Um beispielsweise Rauschen oder Fehler in Zwischenberechnungen zu erkennen, können bekannte oder erwartete dynamische Wertebereiche verwendet werden, um Werte zu identifizieren, die außerhalb dieser Bereiche liegen. Wenn in einem solchen Beispiel ein Wert außerhalb eines bekannten oder erwarteten dynamischen Bereichs liegt, können diese Werte als einem Rauschen, einem Fehler und/oder einem anderen Problem entsprechend mit einem Flag gekennzeichnet werden. Daher kann es wünschenswert sein, minimale (min) und maximale (max) Werte von Zwischenergebnissen zu sammeln, um Datenanomalien zu erkennen. In der Praxis können diese Anomalien ohne Einschränkung durch Rauschen in Bildsensoren, Algorithmus-Eckfälle oder Datenverfälschung im Speicher oder in Verbindungen verursacht werden. Um diesen Problemen Rechnung zu tragen, ist das Sammeln von Min/Max-Werten ein effektives Verfahren, um anomale Werte in diesen Daten zu erkennen. Min/Max wird auch in gewissen Algorithmen verwendet.
Bei einem konkreten Beispiel können in autonomen Fahrzeuganwendungen Laufzeitausnahmen - wie etwa unendlich oder keine Zahl - ungültige Werte sein oder Fehler erzeugen, Ausfälle verursachen oder anderweitig unerwünschte Ergebnisse hervorrufen. Um dies zu berücksichtigen, können Algorithmen, die als Teil der autonomen Fahrzeugplattform ausgeführt werden, ausgewertet werden, um die Wertebereiche - Zwischenwerte oder andere - zu bestimmen, die sich während der Verarbeitung ergeben können. Sobald der Wertebereich bekannt ist, können die tatsächlichen berechneten Werte mit dem bekannten Bereich verglichen werden, und Werte außerhalb eines Minimal- oder Maximalschwellenwerts können als Fehler mit einem Flag gekennzeichnet werden. Wenn ein Fehler mit einem Flag gekennzeichnet ist, kann eine Änderung in der Verarbeitung durchgeführt werden - wie etwa Ignorieren der Daten für eine gegebene Iteration, Identifizieren und Beheben des Problems usw. Auf diese Weise sind Laufzeitausnahmen nicht zulässig, da potenzielle Laufzeitausnahmen durch das autonome Fahrzeug berücksichtigt werden und nicht darauf zurückgegriffen wird.
Als weiteres Beispiel kann die Min/Max-Sammlung in gewissen Algorithmen verwendet werden, um Zwischenergebnisse auf einen gewissen numerischen Bereich zu normalisieren, um eine höhere Genauigkeit bei der Verarbeitung zu erreichen - z. B. Block-Gleitkomma. Dieser Normalisierungsprozess kann einen Schritt zum Sammeln dynamischer Bereiche zum Sammeln von Minimal- und/oder Maximalwerten eines Arrays und einen Anpassungsschritt beinhalten, der einen Skalierungsfaktor auf das Array anwendet. Um die Min/Max-Werte zu sammeln, erfordern herkömmliche Prozesse jedoch, dass alle Werte in den Speicher geschrieben werden, dann die Werte auf Min/Max analysiert und für die Skalierung angepasst werden.
Daher werden diese herkömmlichen Ansätze zur Min/Max-Bewertung in Software ausgeführt und erfordern zusätzliche Verarbeitungszyklen. Beispielsweise kann der Algorithmus selbst ausgeführt werden, um Werte zu berechnen, und dann kann Software ausgeführt werden, um die Min/Max-Werte zu bestimmen und die Min/Max mit einem bekannten Bereich von Werten zu vergleichen, um Anomalien zu identifizieren. Diese Software erfordert die Ausführung zusätzlicher Anweisungen, um Elemente im Zwischenergebnis-Array zu lesen und dann Min/Max-Operationen durchzuführen. Als Ergebnis wird die Laufzeit des Systems zum Erkennen von Anomalien erhöht, wenn der Algorithmus vollständig ausgeführt wird, und dann werden zusätzliche Prozesse ausgeführt, um das Min/Max der Ausgaben des Algorithmus zu berechnen. Dies kann dazu führen, dass die nachgelagerte Verarbeitung verzögert wird, bis die Min/Max-Werte berechnet und mit Schwellenwerten verglichen wurden, oder kann dazu führen, dass nachgelagerte Tasks damit beginnen, Berechnungen an Daten durchzuführen, die Fehler beinhalten, während die Min/Max-Evaluierung stattfindet. Dies führt nicht nur zu einer erhöhten Laufzeit, sondern erhöht auch die Verarbeitungsanforderungen und den Energieverbrauch des Systems, wenn diese zusätzlichen Zyklen ausgeführt werden, um anomale Daten zu identifizieren.
Unter Bezugnahme auf 1A ist 1A eine beispielhafte Prozessorarchitektur 100 für die Min/Max-Sammlung gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Es versteht sich, dass diese und andere hierin beschrieben Anordnungen nur als Beispiele aufgeführt werden. Andere Anordnungen und Elemente (z. B. Maschinen, Schnittstellen, Funktionen, Befehle, Gruppierungen von Funktionen usw.) können zusätzlich oder anstelle der gezeigten verwendet werden, und einige Elemente können ganz weggelassen werden. Ferner sind viele der hierin beschriebenen Elemente funktionale Einheiten, die als diskrete oder verteilte Komponenten oder in Verbindung mit anderen Komponenten und in jeder geeigneten Kombination und Position implementiert werden können. Verschiedene hierin als von Einheiten ausgeführt beschriebene Funktionen können durch Hardware, Firmware und/oder Software ausgeführt werden. Beispielsweise können verschiedene Funktionen durch einen Prozessor ausgeführt werden, der im Speicher gespeicherte Anweisungen ausführt. In einigen Ausführungsformen kann die Architektur 100 ähnliche Komponenten, Merkmale und/oder Funktionen wie die des beispielhaften autonomen Fahrzeugs 1300 der 13A- 13D, der beispielhaften Rechenvorrichtung 1400 der 14 und/oder des beispielhaften Rechenzentrums 1500 der 15 beinhalten.
Um den Mängeln herkömmlicher Min/Max-Evaluierungsprozesse Rechnung zu tragen, wie etwa den hierin beschriebenen, beinhaltet die vorliegende Offenbarung Systeme und Verfahren zur Min/Max-Sammlung unter Verwendung von Hardware. Beispielsweise können die Werte der Berechnung während der Berechnung in den Speicher 106 - z. B. den lokalen Speicher - geschrieben und für nachgelagerte Berechnungen innerhalb desselben Algorithmus oder eines anderen Algorithmus verwendet werden. Um Laufzeit und Verarbeitung zu reduzieren, kann Min/Max-Sammlungs-Hardware (z. B. Min/Max-Sammler 104) verwendet werden, um Min/Max-Werte zu erfassen, bevor oder während sie in den Speicher 106 geschrieben werden - z. B. anstatt auf Werte zu warten, die aus dem Speichers 106 gelesen werden, und die Werte für Min/Max anschließend zu analysieren. Beispielsweise kann ein Aktivierungsbit verwendet werden, um die Min/Max-Sammlungsfunktionalität des Min/Max-Sammlers 104 zu aktivieren, und nach Aktivierung kann der Min/Max-Sammler 104 Min/Max-Werte aktualisieren, wenn die Werte unter Verwendung des Prozessors/der Prozessoren 102 berechnet und in den Speicher 106 geschrieben werden (z. B. vor der Speicherung oder gleichzeitig mit der Speicherung in den Speicher 106). In Ausführungsformen kann das Aktivierungsbit den Typ des berechneten Arrays angeben - z. B. vorzeichenbehaftet oder vorzeichenlos -, sodass der Min/Max-Sammler 104 konfiguriert ist, um Min/Max für den konkreten Typ des Arrays zu sammeln. Beispielsweise können ein oder mehrere Aktivierungsbits oder eine andere Art von Steuermerkmal verwendet werden, um den Min/Max-Sammler 104 zu deaktivieren und/oder den Min/Max-Sammler 104 so zu konfigurieren, dass er Min/Max-Werte ohne Vorzeichen sammelt oder Min/Max-Werte mit Vorzeichen sammelt. Im Datenpfad des Datenspeichers kann eine Min/Max-Sammlungslogik des Min/Max-Sammlers 104 beinhaltet sein, die Werte liest, während sie unter Verwendung des/der Prozessor(en) 102 berechnet - und in einer Registerdatei gespeichert - werden, um die Min/Max-Werte zu aktualisieren oder beizubehalten.
Zum Beispiel kann während des Betriebs ein aktueller Minimalwert und/oder ein aktueller Maximalwert im Min/Max-Sammler 104 beibehalten werden und der aktuelle Minimalwert und/oder der aktuelle Maximalwert können als neue, niedrigere Minimalwerte aktualisiert werden und/oder neue höhere Maximalwerte werden in den Speicher 106 geschrieben. Wenn neu berechnete Werte größer als das Minimum und/oder kleiner als das Maximum sind, können das aktuelle Minimum und/oder Maximum durch den Min/Max-Sammler 104 beibehalten werden. Auf diese Weise kann der Min/Max-Sammler 104 den aktuellen Minimal- und/oder Maximalwert beibehalten, während jeder Wert während einer vollständigen Berechnung berechnet wird. Sobald die Berechnung für eine gegebene Iteration abgeschlossen ist, sind die Min/Max-Werte sofort im Min/Max-Sammler 104 verfügbar, und Software und/oder Hardware können verwendet werden, um diese gespeicherten Werte mit den zugeordneten Min- und/oder Max-Schwellenwerten zu vergleichen, wobei der konkrete Algorithmus oder die konkrete Berechnung ausgeführt wird, um zu bestimmen, ob eine Anomalie vorliegt. Beispielsweise kann ein Mechanismus beinhaltet sein, der es ermöglicht, die gesammelten Min/Max-Werte zur Auswertung auszulesen. Somit ist/sind im Vergleich zu früheren Ansätzen kein weiterer Zyklus/keine weiteren Zyklen erforderlich, um Min/Max zu berechnen, nachdem der Algorithmus vollständig ausgeführt wurde, da die Min/Max-Werte sofort verfügbar sind. Ferner kann der Min/Max-Sammler 104 (z. B. einschließlich Hardware und/oder Logik) in Ausführungsformen eine Speicherprädikation kennen, sodass, wenn ein konkretes Datenelement daran gehindert ist, in den Speicher 106 gespeichert zu werden, z. B. über eine Prädikation der Pro-Spur-Speicherung, die Min/Max-Sammlung dieses konkrete Datenelement ausschließen kann. Wenn beispielsweise eine Adresse von einem Adressengenerator ein Speicherprädikations-Flag beinhaltet, können die berechneten Werte sowohl zum Speichern in den Speicher 106 als auch zum Aktualisieren des Min/Max-Sammlers 104 ignoriert werden.
In einigen Ausführungsformen kann der Min/Max-Sammler 104 als ein Merkmal eines Systems implementiert sein, das einen Adressengenerator beinhaltet - wie etwa den/die Adressengenerator(en), der/die in der nicht vorläufigen US-Anmeldung Nr. 15/141,703 , eingereicht am 28. April 2016, beschrieben ist, die hiermit durch Bezugnahme in ihrer Gesamtheit aufgenommen wird. Der Adressengenerator kann in jeder Art von Prozessor(en) oder anderen Verarbeitungseinheit(en) beinhaltet sein - wie etwa einer Vektorverarbeitungseinheit (VPU), einer zentralen Verarbeitungseinheit (Central Processing Unit - CPU), einer Grafikverarbeitungseinheit (Graphics Processing Unit - GPU), einem Digitalsignalprozessor (Digital Signal Processor - DSP), einer Datenverarbeitungseinheit (Data Processing Unit - DPU) und/oder einer anderen Art von Verarbeitungseinheit (wie etwa die mit Bezug auf die 13A-13D, 14 und/oder 15 beschriebenen). In einigen Ausführungsformen können eine oder mehrere VPUs in einem programmierbaren Visionsbeschleuniger (PVA) und/oder als Teil eines Systems auf einem Chip (SoC) beinhaltet sein.
Als nicht einschränkendes Beispiel können Eingaben für einen konkreten Sensortyp oder Algorithmus auf Einheiten von 16 Bits beschränkt sein. Um den dynamischen Bereich für diesen konkreten Sensor und/oder Algorithmus zu bestimmen, können die Operationen, die dem Algorithmus zugeordnet sind, der die Sensoreingabe verarbeitet, ausgewertet werden. In einem solchen Beispiel ist unter der Annahme, dass die erste Operation darin besteht, zwei 16-Bit-Zahlen zu addieren, das erste Zwischenergebnis eine 17-Bit-Zahl. Die 17-Bit-Zahl kann dann mit einer 5-Bit-Zahl multipliziert werden, um eine 22-Bit-Zahl zu erzeugen. Wenn dies das Ende des Algorithmus ist, kann dann bestimmt werden, dass die Ausgabe 22 Bits nicht überschreiten darf. Ebenso kann ein Mindestwert bewertet werden. Daher kann während des Einsatzes, wenn ein Min/Max-Wert außerhalb dieses bekannten Bereichs liegt - z. B. 22 Bits - die Ausgabe mit einem Flag gekennzeichnet werden.
In einigen Ausführungsformen kann ein Speicherdatenpfad (z. B. zwischen dem/den Prozessor(en) 102 und dem Speicher 106) eine Sättigungs- und/oder Rundungslogik 108 beinhalten, um zu bewirken, dass in den Speicher 106 gespeicherte Werte zwischen einer Ober- und Untergrenze oder einem oberen und unteren Schwellenwert liegen oder basierend auf einer konkreten Konvention gerundet werden. Daher kann bei herkömmlichen Ansätzen die Auswertung für Min/Max nach Sättigung und/oder Rundung erfolgen. Wenn Anomalien vorhanden sind, können diese herkömmlichen Ansätze die Anomalien möglicherweise nicht erkennen, da die Sättigung und/oder Rundung die Anomalie verbergen kann - z. B. können die niedrigen und/oder hohen Werte zwischen der oberen und unteren Grenze, für die die Sättigungslogik konfiguriert ist, gesättigt sein.
Es können jedoch die nicht gesättigten, nicht gerundeten oder absoluten Min/Max-Werte sein, die für eine konkrete Implementierung wertvoll oder erwünscht sind - z. B. zusätzlich oder alternativ zu den gesättigten Min/Max-Werten. Somit kann der Min/Max-Sammler 104 der vorliegenden Offenbarung die Min/Max-Werte aus den rohen oder nicht gesättigten Daten (z. B. bevor die Werte unter Verwendung der Sättigungs-/Rundungslogik 108 manipuliert werden) zur Verwendung bei der Anomalieerkennung sammeln. In Ausführungsformen kann das Sammeln von Durchschnittswerten von Daten oder durchschnittlichen Absolutwerten von Daten ausgeführt werden. Der Durchschnittswert kann berechnet werden, z. B. durch Aufsummieren von Elementen, Rücklesen einer Summe aus einem Adressengenerator-Konfigurationsregister und Durchführen einer Division durch eine Anzahl von gespeicherten Datenelementen (die der Anwendung bekannt sein können). Auf diese Weise können Min/Max von Absolutwerten, Summen von Werten und/oder Summen von Absolutwerten zu einem Prozessorspeicher-Datenpfad addiert werden, und eine Konfiguration und Sammlung von resultierenden Statistiken kann ausgeführt werden - kann z. B. zu dem Adressengenerator-Konfigurationsmerkmalssatz addiert werden oder kann separat verwaltet werden. In einigen Ausführungsformen kann der Min/Max-Sammler 104 die Werte vor und/oder nach Sättigung, Rundung oder einer anderen Berechnung unter Verwendung der Sättigungs-/Rundungslogik 108 sammeln.
Unter nunmehriger Bezugnahme auf 1B umfasst jeder Block des hierin beschriebenen Verfahrens 110 einen Rechenprozess, der unter Verwendung einer beliebigen Kombination von Hardware, Firmware und/oder Software durchgeführt werden kann. Beispielsweise können verschiedene Funktionen durch einen Prozessor ausgeführt werden, der im Speicher gespeicherte Anweisungen ausführt. Das Verfahren 110 kann auch als computerverwendbare Anweisungen verkörpert sein, die auf Computerspeichermedien gespeichert sind. Die Verfahren 110 kann durch eine eigenständige Anwendung, einen Dienst oder einen gehosteten Dienst (eigenständig oder in Kombination mit einem anderen gehosteten Dienst) oder ein Plug-in zu einem anderen Produkt bereitgestellt werden, um nur einige zu nennen. Auch wenn es in Bezug auf die Architektur 100 der 1A beschrieben wird, kann das Verfahren 110 durch ein beliebiges System oder eine beliebige Kombination von Systemen ausgeführt werden, einschließlich unter anderem der hierin beschriebenen.
1B ist ein Flussdiagramm, das ein Verfahren 110 für eine Min/Max-Sammlung gemäß einiger Ausführungsformen der vorliegenden Offenbarung zeigt. Das Verfahren 110 beinhaltet bei Block B102 das Berechnen eines oder mehrerer Werte. Wenn zum Beispiel ein oder mehrere Algorithmen ausgeführt werden - z. B. neuronale Netze, Computer-Vision-Algorithmen, Filteralgorithmen usw. - können ein oder mehrere Werte unter Verwendung des/der Prozessor(en) 102 berechnet werden.
Das Verfahren 110 beinhaltet bei Block B104 das Vergleichen eines Werts des einen oder der mehreren Werte mit einem aktuell gespeicherten Minimalwert und einem aktuell gespeicherten Maximalwert. Beispielsweise kann der Min/Max-Sammler 104 jeden Wert einer beliebigen Anzahl von Werten, die in den Speicher 106 gespeichert werden sollen - z. B. Werte, die sich in einer Registerdatei befinden - mit einem aktuell gespeicherten Minimalwert und einem aktuell gespeicherten Maximalwert vergleichen (z. B. aktuell durch den Hardware-Min/Max-Sammler 104 gespeichert). In einem solchen Beispiel kann der Min/Max-Sammler die Werte mit aktuell gespeicherten Minimal- und/oder Maximalwerten vergleichen, wenn die Werte berechnet werden und bevor oder gleichzeitig mit der Speicherung der Werte in den Speicher. In einer oder mehreren Ausführungsformen kann der Min/Max-Sammler entlang eines Datenpfads zwischen einer Hardwareeinheit, die den einen oder die mehreren Werte berechnet, und einer Speichereinheit, die den einen oder die mehreren Werte speichert, beinhaltet sein.
Das Verfahren 110 beinhaltet bei Block B106 das Bestimmen, ob der Wert größer als der aktuell gespeicherte Maximalwert oder kleiner als der aktuell gespeicherte Minimalwert ist. Beispielsweise kann das System (z. B. der Hardware-Min/Max-Sammler 104) basierend auf dem Vergleich in Block B104 bestimmen, ob jeder im Speicher zu speichernde Wert größer als ein aktuell gespeicherter Maximalwert oder kleiner als ein aktuell gespeicherter Minimalwert ist.
Das Verfahren 110 beinhaltet bei Block B108 das Aktualisieren des aktuell gespeicherten Minimalwerts auf den Wert basierend darauf, dass der Wert kleiner als der aktuell gespeicherte Minimalwert ist. Wenn beispielsweise ein im Speicher zu speichernder berechneter Wert kleiner als der aktuell gespeicherte Minimalwert des Hardware-Min/Max-Sammlers ist, kann der Hardware-Min/Max-Sammler den aktuell gespeicherten Minimalwert auf den berechneten Wert aktualisieren.
Das Verfahren 110 beinhaltet bei Block B110 das Aktualisieren des aktuell gespeicherten Maximalwerts auf den Wert basierend darauf, dass der Wert größer als der aktuell gespeicherte Maximalwert ist. Wenn beispielsweise ein im Speicher zu speichernder berechneter Wert größer als der aktuell gespeicherte Maximalwert des Hardware-Min/Max-Sammlers ist, kann der Hardware-Min/Max-Sammler den aktuell gespeicherten Maximalwert auf den berechneten Wert aktualisieren.
Auf diese Weise können Min/Max während des Speicherns der Werte dynamisch aktualisiert werden, sodass, sobald eine gewisse Anzahl (z. B. alle) der Werte gespeichert sind, Min/Max-Wert sofort durch Auslesen von Min/Max aus den aktuell gespeicherten Werten des Min/Max-Sammlers verfügbar ist.
AUTOMATISCHE SPEICHERPRÄDIKATION
Unter Prozessoren mit hoher Taktrate besteht eine verbreitete Implementierung darin, den Prozessor in mehrere Pipeline-Stufen zu konfigurieren. Infolgedessen kann es zwischen der Ausgabe einer Anweisung zum Laden eines Registers aus dem lokalen Speicher und der Verfügbarkeit des Registers für eine andere Anweisung zur Bearbeitung zu einer Latenz kommen - z. B. einer Lade-Verwendung-Latenz. Um trotz der Lade-Verwendung-Latenz einen hohen Durchsatz zu erreichen, können Prozessor-Compiler und Anwendungsentwicklung Software-Pipelining und/oder Schleifenentrollen (Lopp Unrolling) verwenden. Zum Beispiel kann Software-Pipelining verwendet werden, um die Ausführung mehrerer Iterationen der Schleife zu überlappen, und Schleifenentrollen kann verwendet werden, um einen Schleifenkörper zu erweitern, indem der Inhalt des Schleifenkörpers viele Male wiederholt wird. Zusammen können diese Techniken ermöglichen, dass mehrere Iterationen von Schleifeninhalten gleichzeitig ausgeführt werden, sodass es weniger Leerlaufzyklen - idealerweise keine - im Zeitplan gibt. Beim Durchführen des Schleifenentrollens kann ein Compiler die Anzahl der Schleifeninteraktionen durch einen Entrollungsfaktor dividieren. Beispielsweise kann der Compiler davon ausgehen, dass die ursprüngliche Iterationszahl ein Vielfaches des Entrollungsfaktors ist, damit die entrollte Schleife mit äquivalentem Funktionsverhalten ausgeführt werden kann. Wenn in einem solchen Beispiel die ursprüngliche Iterationszahl 60 ist und die Schleife um einen Faktor von 6 entrollt werden soll, kann die entrollte Schleife für 10 Iterationen ausgeführt werden. Wenn jedoch die ursprüngliche Anzahl der Schleifeniterationen 64 beträgt, ergibt 64/6 bei normaler ganzzahliger Division ebenfalls 10, sodass die Schleife nicht ausreichend oft ausgeführt würde (z. B. werden die zusätzlichen 4 Iterationen möglicherweise nicht ausgeführt), was zu unterschiedlichem Codeverhalten nach dem Entrollen führen kann, was zu Fehlern in der Anwendung führen kann. Bei einigen Techniken wird eine Assertionsanweisung hinzugefügt, um sicherzustellen, dass die Anzahl der Iterationen tatsächlich ein Vielfaches des Entrollungsfaktors ist.
Die Sammlung von Schritten oder Operationen in einem Schleifenkörper kann einen engen Bereich optimaler oder gewünschter Entrollungsfaktoren aufweisen. Beispielsweise kann der Entrollungsfaktor durch eine minimale Anzahl von Kopien des zu planenden Schleifencodes nach unten begrenzt sein, um Lücken aufgrund verschiedener Latenzen zu füllen und die beste Leistung zu erzielen, und kann auch durch eine maximale Anzahl von Kopien nach oben begrenzt sein, um mit begrenzter Fähigkeit in den Registerdateien zu planen - was z. B. zu übermäßigem Überlaufen von Registern (Speichern auf und Wiederherstellen aus dem Stack) und zu suboptimaler Planung führen kann. Als ein weiteres Beispiel ist aufgrund der Realisierbarkeit, eine Kombination aus Kachelbreite und Kachelhöhe zu wählen, die eine Iterationszahl ermöglicht, die eine Potenz von 2 ist (z. B. 2, 4, 8 usw.), ein Entrollen um eine Potenz von 2 für viele Anwendungen akzeptabel. In Ausführungsformen kann ein Schlaufenkörper jedoch auch 6- oder 7-mal optimal entrollt werden, während ein Entrollen um 4 oder 8 Mal nicht so effizient sein kann. In jedem Fall kann das Schleifenentrollen zum Erzielen einer optimalen Planung zu unpraktischen Beschränkungen der Anzahl von Iterationen führen. Daher können herkömmliche Techniken zum Angehen dieses Problems zu einer Leistungsverschlechterung und einer Zunahme der Codegröße führen.
Beispielsweise ist die Beschränkung der Iterationszahl nicht praktisch, sodass der Programmierer möglicherweise zwei Schleifen schreibt - z. B. eine „Mehrfach“-Schleife und eine „Rest“-Schleife - wenn es keine solche Beschränkung der Iterationszahl geben soll. Als Beispiele zeigen die folgenden veranschaulichenden Beispielcodesegmente: Code 1 - eine Vektoradditionsschleife ohne Entrollen der Schleife; Code 2 - die gleiche Schleife mit Entrollen der Schleife um 6, was möglicherweise nur funktioniert, wenn die Anzahl der Iterationen ein Vielfaches von 6 ist; und Code 3 - eine Lösung mit zwei Schleifen, die mit jeder Iterationszahl funktioniert, aber die Restschleife wird nicht entrollt und ist daher weniger effizient, was auch zu einer größeren Codegröße aufgrund der zusätzlichen Schleifen- und Iterationszahlberechnung führt.
Code 1:

      für (i = 0; i < niter; i++) chess_vorbereiten_für_pipelining {
            dva = dvshort_laden(agen_a);
            dvb = dvshort_laden(agen_b);
            dvc = dva + dvb;
            vspeichern (dvc, agen_c);
      }

Code 2:

      assert ((niter/6) * 6 == niter); // niter muss ein Vielfaches von 6 sein
      für (i = 0; i < niter; i++) chess_vorbereiten_für_pipelining
                          chess_entrollen_schleife(6) {
            dva = dvshort_laden(agen_a);
            dvb = dvshort_laden(agen_b);
            dvc = dva + dvb;
            vspeichern(dvc, agen_c);
       }

Code 3

      int niter_multiple = (niter/6) * 6;
      int niter_rest = niter - niter_mehrfach;
      für (i = 0; i < niter_mehrfach; i++) chess_vorbereiten_für_pipelining
                               chess_entrollen_schleife(6){
            dva = dvshort_laden(agen_a);
            dvb = dvshort_laden(agen_b);
            dvc = dva + dvb;
      vspeichern(dvc, agen_c);
      }
      für (i = 0; i < niter_rest; i++) chess_vorbereiten_für_pipelining {
            dva = dvshort_laden(agen_a);
            dvb = dvshort_laden(agen_b); 

            dvc = dva + dvb;
            vspeichern(dvc, agen_c);
      }

Unter Verwendung einer Vektorverarbeitungseinheit (VPU) der vorliegenden Offenbarung kann Code 1 6 Zyklen pro Iteration erreichen, kann Code 2 1 Zyklus pro Iteration erreichen und kann die Leistung von Code 3 von der Iterationszahl abhängen. Für eine Anzahl von Iterationen (niter), niter = 60 (ein Vielfaches von 6, sodass der Rest nicht ausgeführt wird), kann Code 3 1,0 Zyklen pro Iteration erreichen, und für niter = 64 (mit einer 4-mal ausgeführten Restschleife) kann Code 3 durchschnittlich 1,3125 Zyklen (z. B. (60 * 1 + 4 * 6) / 64 = 84 / 64 = 1,3125) pro Iteration erreichen.

Unter Bezugnahme auf 2A ist 2A ein beispielhaftes System 200, das einen Prozessor 202 (wie etwa eine VPU) mit einer Adressengenerierungseinheit mit automatischer Prädikationsfähigkeit gemäß einigen Ausführungsformen der vorliegenden Offenbarung beinhaltet. Es versteht sich, dass diese und andere hierin beschrieben Anordnungen nur als Beispiele aufgeführt werden. Andere Anordnungen und Elemente (z. B. Maschinen, Schnittstellen, Funktionen, Befehle, Gruppierungen von Funktionen usw.) können zusätzlich oder anstelle der gezeigten verwendet werden, und einige Elemente können ganz weggelassen werden. Ferner sind viele der hierin beschriebenen Elemente funktionale Einheiten, die als diskrete oder verteilte Komponenten oder in Verbindung mit anderen Komponenten und in jeder geeigneten Kombination und Position implementiert werden können. Verschiedene hierin als von Einheiten ausgeführt beschriebene Funktionen können durch Hardware, Firmware und/oder Software ausgeführt werden. Beispielsweise können verschiedene Funktionen durch einen Prozessor ausgeführt werden, der im Speicher gespeicherte Anweisungen ausführt. In einigen Ausführungsformen kann der Prozessor 202 in ähnlichen Komponenten, Merkmalen und/oder Funktionen wie die des beispielhaften autonomen Fahrzeugs 1300 der 13A-13D, der beispielhaften Rechenvorrichtung 1400 der 14 und/oder des beispielhaften Rechenzentrums 1500 der 15 beinhaltet sein und/oder kann diese beinhalten.

In Ausführungsformen der vorliegenden Offenbarung können Lade- und Speichervorgänge in den Codesegmenten einen oder mehrere Adressengeneratoren 204 in dem (den) Prozessor(en) 202 (z. B. einer VPU) verwenden. Beispielsweise kann bei jedem Laden und Speichern ein Adressengenerator (agen)-Argument (agen_a, agen_b, agen_c) an die Lade-/Speicherfunktionen geliefert werden. Das Argument kann ein Adressengeneratorregister identifizieren, das Parameter enthält, die für die Adressenberechnung der konkreten Lade- und/oder Speicheroperation verwendet werden können - z. B. Adresszeiger, Anzahl von Iterationen, aktuelle Schleifenvariablenwerte usw. In einigen Ausführungsformen kann die VPU so ausgelegt sein, dass jedes Adressengeneratorregister 6 (oder anderen Wert) Dimensionen der Adressierung unterstützt, was somit 6 (oder den anderen Wert) Iterationszahlen und 6 (oder den anderen Wert) Schleifenvariablen beinhaltet.

Um die Beschränkung der Anzahl von Iterationen mit Schleifenentrollen zu berücksichtigen, können Systeme und Verfahren der vorliegenden Offenbarung einen Adressengenerator 204 mit Logik (z. B. einem Prädikations-Flag oder -Bit 208) zur automatischen Prädikation von Speichervorgängen von dem Adressengenerator 204 beinhalten. Beispielsweise kann eine Prädikation verwendet werden, um einen Hinweis auf eine bedingte Ausführung bereitzustellen, beispielsweise ob (oder nicht) etwas ausgeführt werden soll. Ein Wert (z. B. 0 zum Speichern oder 1 zum Verhindern des Speicherns oder umgekehrt) eines Prädikationsbits 208 kann verwendet werden, um anzugeben, ob eine Anweisung ausgeführt wird oder nicht. Ausführung bezieht sich möglicherweise nicht auf die tatsächliche Ausführung der Iteration, sondern kann sich darauf beziehen, ob die resultierenden Werte aus der Ausführung der Iteration in den Speicher gespeichert werden. Somit kann sich in Ausführungsformen eine Anweisung, die aufgrund eines Prädikat-Flags nicht ausgeführt wird, auf eine Anweisung oder Iteration beziehen, die ausgeführt wird, wobei jedoch verhindert oder ausgeschlossen wird, dass die Ergebnisse der Ausführung eine Änderung des Zustands des Speichers 206 vornehmen. Die Prädikation kann eine Prädikation auf Anweisungsebene und eine Prädikation auf Spurebene beinhalten. Die Prädikation auf Anweisungsebene kann verwendet werden, um anzugeben, ob eine vollständige Anweisung ausgeführt werden soll oder nicht, während die Prädikation auf Spurebene verwendet werden kann, um anzugeben, welche Datenspuren ausgeführt werden sollen oder nicht.

In einigen Ausführungsformen wird, nachdem die Schleifenvariablen die Anzahl der Iterationen erschöpft haben, jede nachfolgende Ausführung der Speicheranweisung automatisch als ohne Prädikation behandelt, um weitere Schreibvorgänge in den Speicher 206 zu verhindern. Auf diese Weise kann das Merkmal der automatischen Speicherprädikation ermöglichen, dass Code eindeutig geschrieben wird, indem eine Iterationszahl, die kein Vielfaches von z. B. 6 (oder eines anderen Entrollungsfaktors) ist, auf das nächste Vielfache von 6 aufgerundet wird, und indem eine Iterationszahl, die kein Vielfaches von 6 (oder eines anderen Entfollfaktors) ist, nicht verändert wird. Obwohl ein Faktor von 6 verwendet wird, soll dies nicht einschränkend sein, und jeder Entrollungsfaktor kann verwendet werden, ohne vom Umfang der vorliegenden Offenbarung abzuweichen. Der nachstehende Code 4 beinhaltet ein Beispiel einer Vektoraddition mit automatischer Speicherprädikation.

Code 4:

      int niter_aufrunden = ((niter + 5)/6 ) * 6; // obergrenze(niter/6) * 6
      für (i = 0; i < niter_aufrunden; i++) chess_vorbereiten_für_pipelining
                              chess_entrollen_schleife(6){
            dva = vshort_laden(agen_a);
            dvb = vshort_laden(agen_b);
            dvc = dva + dvb;
            vspeichern(dvc, agen_c);
      }

Code 4 mit einer ursprünglichen Anzahl von Iterationen (niter) von 64 kann die entrollte Schleife 11 Mal mit 1,03125 Zyklen pro Iteration ausführen (z. B. 11 x 6/64 = 1,03125). Eine andere Möglichkeit, die Einschränkung der Iterationszahl zu berücksichtigen, die ein Vielfaches des Entrollungsfaktors ist, besteht darin, das notwendige Prädikations-Flag in der Schleife zu berechnen und das Prädikations-Flag in der Speicheranweisung bereitzustellen. Beispielsweise veranschaulicht der nachstehend abgebildete Code 5 eine beispielhafte Implementierung der Prädikations-Flag-Berechnung.

Code 5:

      int niter_aufrunden = ((niter + 5)/6 ) * 6; // obergrenze(niter/6) * 6
      int j = 0; 
      für (i = 0; i < niter_aufrunden; i++) chess_vorbereiten_für_pipelining
            chess_entrollen_schleife(6){
            dva = vshort_laden(agen_a);
            dvb = vshort_laden(agen_b);
            dvc = dva + dvb;
            präd = (j++ < niter) ? -1 : 0;
            vspeichern (dvc, agen_c, präd);
      }

Code 5 kann in der VPU der vorliegenden Offenbarung in 1,5 Zyklen pro Iteration kompiliert werden, sodass die automatische Prädikation einen Leistungsvorteil gegenüber der in der Schleife berechneten Prädikation beinhalten kann. In Ausführungsformen kann die VPU ein 7-Wege-Very-Long-Instruction-Word(VLIW)-Anweisungsschema beinhalten und kann 2 skalare Slots pro Zyklus für skalare Operationen beinhalten, die für die Prädikationsberechnung benötigt werden. Wenn die Schleife mehr Vektoroperationen pro Iteration aufweist, kann es genügend skalare Slots geben, sodass die Prädikationsberechnung in verfügbare Slots passen und keine Leistungsverschlechterung verursachen kann. Selbst in den Rechenschleifen, in denen es keine Auswirkungen auf die Leistung gibt, um die Prädikation in Echtzeit zu berechnen, kann die automatische Prädikation immer noch einen Vorteil in Bezug auf die Codegröße und den Energieverbrauch haben.

Somit kann Software verwendet werden, um eine Anzahl von Iterationen (z. B. N1-N6) zu konfigurieren, und Software kann die Ausführung eines auf einem Adressengenerator basierenden Lade-/Speichervorgangs veranlassen - typischerweise in einer Schleife. Die Adressengeneratorhardware kann die Schleifenvariable (z. B. Variable 11-16) beibehalten und kann den Adresszeiger geeignet vorrücken. Wenn der auf dem Adressengenerator basierende Lade/Speichervorgang über die vorkonfigurierte Anzahl von Iterationen ausgeführt wurde, kann der Adresszeiger an einer letzten gültigen Adresse stecken bleiben und die automatische Prädikation kann (z. B. durch Setzen eines Prädikations-Flags) ausgeschaltet werden, um nachfolgende Speichervorgänge in den Speicher zu blockieren. Somit kann ein interner boolescher Zustand „automatische Prädikation aus“ in dem Adressgenerator 204 beinhaltet sein, und die Schleifenvariablen-Iterationslogik kann so konfiguriert sein, dass sie unterstützt, dass die automatische Prädikation ausgeschaltet wird. Beispielsweise und in Bezug auf 2B kann, wenn ein Adressengenerator initialisiert wird, zusätzlich zu den Schleifenvariablen 11-16 ein Wert des Parameters „automatische Prädikation aus“ („Auto_Präd._Aus“) (z. B. das Prädikationsbit 208) initialisiert oder auf „0“ zurückgesetzt werden. Nachdem die Schleifenvariablen die programmierten Iterationszahlen erschöpft haben, kann Auto_Präd._Aus auf „1“ aktualisiert werden. Jegliche nachfolgende Ausführung der Speicheranweisung kann dann als Ergebnis davon, dass das Prädikationsbit „1“ ist, automatisch ohne Prädikation erfolgen, und weitere Schreibvorgänge in den Speicher können verhindert werden.

In dem Beispiel der 2B kann die Anzahl der Iterationen des Adressengenerators für die Register N1-N6 als N1=4, N2=2, N3=N4=N5=N6=1 programmiert werden. Die programmierte Gesamtzahl der Iterationen kann somit 4*2*1 *1 *1 *1 = 8 sein, und die in 2B veranschaulichte Abfolge kann als Ergebnis ausgeführt werden. Wie veranschaulicht, können der Anfangszustand und die folgenden 7 Ausführungen (z. B. die ersten 8 Iterationen) einem Auto_Präd._Aus-Bitwert von 0 entsprechen, und die achte und neunte Ausführung (z. B. die letzten 2 Iterationen) können einem Auto_Präd._Aus-Bitwert von 1 entsprechen, wodurch verhindert wird, dass die Ergebnisse der neunten und zehnten Ausführung in den Speicher gespeichert werden.

In der Praxis kann eine VPU so konfiguriert sein, dass sie eine gewisse Anzahl von Vektoreinheiten verarbeitet, die gleichzeitig arbeiten - z. B. 8, 16 usw. - und daher kann die VPU ein Array erfordern, das ein Vielfaches der Anzahl von Vektoreinheiten ist. Wenn ein Array ein Vielfaches der Anzahl von Vektoreinheiten ist, funktioniert diese Anordnung gut. Üblicherweise ist ein Array jedoch möglicherweise kein Vielfaches der Vektoreinheiten (z. B. weil es keine Garantie gibt, dass Daten gemäß einem Array gleicher Größe berechnet werden), und infolgedessen wird das Array aufgefüllt, sodass die Verarbeitung immer an einem Stapel gleicher Größe ausgeführt wird. Beispielsweise können die verbleibenden Iterationen mit „0“-Werten aufgefüllt werden, aber dies erfordert immer noch zusätzliche Zyklen in der Software, um die aufgefüllten Werte zu verarbeiten. Daher kann das Auffüllen ineffizient sein, da die hinzugefügten Daten zu verschwendeten Berechnungen führen und auch die Software verkomplizieren - ein häufiges Problem bei SIMD-Software. Daher kann die automatische Speicherprädikation verwendet werden, um dieses Problem zu berücksichtigen.

Bei einem nicht einschränkenden Beispiel, bei dem Stapel von 16 verwendet werden, können beliebig viele Stapel von 16 aus einem Array generiert werden, und die verbleibenden Werte können in einem abschließenden Stapel beinhaltet sein, wobei der übrige oder verbleibende Platz innerhalb des Stapels von 16 unter Verwendung eines Prädikations-Flags ohne Prädikation bleibt. Wenn beispielsweise eine Array-Größe 82 beträgt, können 5 vollständige Sätze von 16 generiert werden, und in der letzten Iteration können die verbleibenden 2 Elemente beinhaltet sein und die anderen 14 können automatisch ohne Prädikation bleiben - wodurch die verschwendete Berechnung bei Auffüllung des Stapels mit 14 Werten und unnötige Berechnungen an den aufgefüllten Daten minimiert werden. Als ein weiteres Beispiel können, wenn eine Vektorverarbeitungsgranularität eine Breite von 32 beinhaltet und ein Array 100 Elemente aufweist, 3 volle Vektoren mit 32 Elementen verarbeitet werden und die verbleibenden 4 Elemente können durch 4 der 32 Spuren verarbeitet werden (z. B. kann ein Prädikations-Flag eingeschaltet sein), während die anderen 28 Spuren ohne Prädikation bleiben. Auf diese Weise kann ein Programmierer möglicherweise Arrays vektorisieren, die kein Vielfaches der Anzahl von Einheiten in der Probe sind. Beispielsweise kann die Hardware für jeden Speichervorgang tatsächlich berechnen, wie viele Elemente in den Speicher zu schreiben sind, und diese Informationen an die Speichereinheit übermitteln. Selbst wenn die Mathematik an aufgefüllten oder zusätzlichen Elementen ausgeführt und gespeichert werden kann, ist diese zusätzliche Berechnung und Speicherung als solche ineffizient. Somit kann das Prädikations-Flag so gesetzt werden, dass die zusätzlichen Lesevorgänge nicht erforderlich sind, und das Schreiben von berechneten Werten aus aufgefüllten Werten in den Speicher nicht stattfindet (z. B. verhindert oder ausgeschlossen wird). Diese automatische Prädikation kann auf der Anweisungsebene stattfinden, und es kann Software hinzugefügt werden, um zusätzlich eine Prädikation auf Spurebene durchzuführen.

Außerdem sind für die automatische Prädikation möglicherweise keine zusätzlichen Informationen erforderlich, da der Adressengenerator eine Anzahl von Iterationen programmieren kann - sodass der Adressengenerator den Speicher aufweist, um die automatische Prädikation zu unterstützen - und Softwareanweisungen können hinzugefügt werden, um ein Prädikat und ein Prädikat-Aus des Speichervorgangs automatisch zu verschieben. Auf diese Weise kann die Hardware bei einer abschließenden Iteration bestimmen, wann ein vollständiges Ergebnis gespeichert werden soll oder wann weniger als ein vollständiges Ergebnis gespeichert werden soll - z. B. aufgrund einer ausgeschalteten oder anderweitig als aus signalisierten Prädikation - und dies kann ohne Kosten ausgeführt werden, während die Leistung aufrechterhalten wird. Wenn nur Software verwendet wird, würde der Prozess zusätzliche Zyklen erfordern, wodurch der Prozess verlangsamt würde.

In einigen Ausführungsformen kann die Prädikation auf einer Pro-SpurEbene verwendet werden, sodass diese Implementierungen nicht nur Iterationszahlen handhaben können, die kein Vielfaches eines Schleifenentrollungsfaktors sind, sondern jede Problemgröße, die kein Vielfaches der Vektorbreite ist, kann effizient gehandhabt werden. In solchen Ausführungsformen kann die Pro-Spur-Prädikation unter Verwendung eines Vektorregisters angesteuert werden, was einen Vorteil dahingehend bieten kann, dass die Informationen in Echtzeit berechnet werden, und durch die Verwendung eines Vektorregisters kann eine Abkürzung realisiert werden, die eine Anforderung zum Kopieren aus dem Vektorregister in ein Skalar-PrädikatRegister und dann Verwenden des Skalar-Prädikat-Registers zum Anwenden des Prädikat-Flags pro Spur beseitigt. Zum Beispiel kann die Pro-Spur-Prädikation von dem Vektorregister ausgeführt werden, was vorteilhaft sein kann, wenn Pro-Spur-Prädikationsinformationen in der Schleife berechnet werden, und die Berechnung kann vektorisiert werden.

Wenn beispielsweise eine gewisse Wertersetzung in einem Array ausgeführt werden soll - z. B. Ersetzen eines beliebigen Werts über 100 durch 999 - kann der Code wie folgt geschrieben werden:

      für (i = 0; i < len_arr; i++)
      {
            wenn (array [i] > 100) array [i] = 999;
      }

Dieser Code kann zwar funktional korrekt sein, kann aber zu einer schlechten Leistung führen. Somit kann der Code mit Pro-Spur-Prädikation vektorisiert werden, indem beispielsweise der folgende Code integriert wird:

      vint * vptr = (vint *) array; // eingeben von cast skalarzeiger in vektorzeiger
      agen aout = init(array); // agen as ausgabezeiger konfigurieren
      aout.n1 = len_arr/vecw;
      aout.mod1 = größe(vint);
      vrepl = replizieren mit(999); // jede spur als 999 initialisieren
      für (i = 0; i < len_arr/vecw; i++)
      {
            vintx vdaten = zeichen_erweitern(*vptr++); // vektor laden
            vintx vtemp = vbitcmp (vdaten, 100); // pro-spur-prädikate und bitpaket
            berechnen
            int präd = smovb(vtemp); // verschieben von vektorspur0 zu
            skalarregister
            vspeichern(vrepl, aout, präd); // prädizierter vektorspeicher
    }

Wenn die Prädikatberechnung auf diese Weise vektorisiert wird und die Prädikation pro Spur nur über ein skalares Prädikatregister übermittelt werden kann, müssten Prädikatsinformationen aus dem Vektorregister in das skalare Prädikatregister kopiert werden, wodurch die Ausführungszeit verlängert wird.

In diesem Beispiel kann jedoch eine direkt von der hierin beschriebenen Vektorregisterfunktion angesteuerte Pro-Spur-Prädikation verwendet werden, um eine bessere Leistung zu erzielen, als beim Durchführen von Bitpacken und Bewegen der Prädikationsmaske von Vektorspur 0 in das Skalarregister, wie im folgenden Code veranschaulicht:

      vint * vptr = (vint *) array; // eingeben von cast skalarzeiger in vektorzeiger
      agen aout = init(array); // agen als ausgabezeiger konfigurieren
      aout.n1 = len_arr/vecw;;
      aout.mod1 = größe(vint); 

      vrepl = replizieren mit(999); // jede spur als 999 initialisieren
      niter = ((len_arr/vecw + 5) / 6) * 6; 

      für (i = 0; i < niter; i++)
      chess_vorbereiten_für_pipelining chess_entrollen_schleife(6)
      {
            vintx vdaten = zeichen_erweitern(*vptr++); // vektor laden
            vintx vpred = vdaten > 100; // vektorprädikat berechnen
            vspeichern(vrepl, aout, vpräd); // prädizierter vektorspeicher
      }

Unter nunmehriger Bezugnahme auf die 2C umfasst jeder Block des hierin beschriebenen Verfahrens 220 einen Rechenprozess, der unter Verwendung einer beliebigen Kombination von Hardware, Firmware und/oder Software ausgeführt werden kann. Beispielsweise können verschiedene Funktionen durch einen Prozessor ausgeführt werden, der im Speicher gespeicherte Anweisungen ausführt. Das Verfahren 220 kann auch als computerverwendbare Anweisungen dargestellt werden, die auf Computerspeichermedien gespeichert sind. Die Verfahren 220 kann durch eine eigenständige Anwendung, einen Dienst oder einen gehosteten Dienst (eigenständig oder in Kombination mit einem anderen gehosteten Dienst) oder ein Plug-in zu einem anderen Produkt bereitgestellt werden, um nur einige zu nennen. Auch wenn es in Bezug auf das System 200 der 2A beschrieben wird, kann das Verfahren 220 durch ein beliebiges System oder eine beliebige Kombination von Systemen ausgeführt werden, einschließlich unter anderem der hierin beschriebenen.

2C ist ein Flussdiagramm, das ein Verfahren 220 für automatische Speicherprädikation gemäß einiger Ausführungsformen der vorliegenden Offenbarung zeigt. Das Verfahren 220 beinhaltet bei Block B202 das Bestimmen einer Gesamtanzahl von Iterationen. Beispielsweise kann der Adressengenerator 204 eine Gesamtzahl von Iterationen bestimmen, die für eine gegebene Anweisung auszuführen sind.

Das Verfahren 220 beinhaltet bei Block B204 das Trennen der Gesamtanzahl von Iterationen in eine Vielzahl von Sätzen von Iterationen. Beispielsweise kann der Adressengenerator 204 die Iterationen durch einen Entrollungsfaktor trennen, um Schleifenkörper zu generieren, die eine Anzahl von Iterationen einer Schleife beinhalten.

Das Verfahren 220 beinhaltet bei Block B206 das Bestimmen, dass ein Satz von Iterationen der Vielzahl von Sätzen von Iterationen eine erste Anzahl von Iterationen beinhaltet, die kleiner als eine zweite Anzahl von Iterationen ist, die anderen Sätzen von Iterationen der Vielzahl von Sätzen von Iterationen entspricht. Beispielsweise kann der Adressengenerator 204 bestimmen, dass nach der Trennung der Iterationen durch den Entrollungsfaktor ein Satz von Iterationen weniger Iterationen beinhaltet als andere Sätze. Wenn beispielsweise der Entrollungsfaktor 6 und die Anzahl der Iterationen 62 beträgt, kann es 11 Sätze von Iterationen geben - 10 mit 6 Iterationen und 1 mit 2 Iterationen. Somit kann der Adressengenerator 204 bestimmen, dass die 2 Iterationen des Satzes von Iterationen einschließlich der verbleibenden 2 Iterationen ausgeführt werden soll und die anderen vier ohne Prädikation bleiben sollen.

Das Verfahren 220 beinhaltet bei Block B208 während der Ausführung des Satzes von Iterationen das Generieren eines Prädikat-Flags, das mindestens einer Iteration des Satzes von Iterationen entspricht. Zum Beispiel kann der Adressengenerator 204, wenn bestimmt wird, dass der Satz von Iterationen keinen vollständigen Satz mit derselben Anzahl von Iterationen wie die anderen Sätze von Iterationen beinhaltet, ein Prädikations-Flag aktivieren (einen Wert eines Prädikation-Aus-Bits 208 ändern), um anzugeben, dass die Ergebnisse der überschüssigen Iterationen gespeichert oder in den Speicher geschrieben werden sollen.

Das Verfahren 220 beinhaltet bei Block B210, zumindest teilweise basierend auf dem Prädikat-Flag, das Verhindern des Schreibens von Werten, die der zumindest einen Iteration des Satzes von Iterationen entsprechen, in den Speicher. Beispielsweise können die berechneten Werte auf der Grundlage des gesetzten Prädikat-Flags daran gehindert oder berechnet werden, in den Speicher geschrieben zu werden.

VERBESSERTE SIMD-DATENPFADORGANISATION FÜR VEKTORPROZESSOREN

In einer herkömmlichen Single-Instruction-Multiple-Data(SIMD)-Architektur arbeitet jede SIMD-Verarbeitungseinheit parallel und unabhängig von anderen auf ihrer eigenen Datenspur. Einige Maschinen ermöglichen jeder SIMD-Verarbeitungseinheit, direkt mit nahen Nachbarn zu kommunizieren (z. B. linker Nachbar und rechter Nachbar als eine lineare Anordnung von Verarbeitungseinheiten, oder nördliche, südliche, östliche und westliche Nachbarn in einer zweidimensionalen (2D) Anordnung oder zweidimensionalen Verarbeitungseinheiten). Die Kommunikation nur zwischen benachbarten Datenpfaden ist jedoch restriktiv und macht die Implementierung von Operationen teuer, die mehr als ein paar Eingangsoperanden erfordern. Beispielsweise ist Faltung eine gängige Operation bei Bildverarbeitung, Computer-Vision, maschinellem Lernen und dergleichen. Während der Faltung können verschiedene Filter auf benachbarte Pixel angewendet werden, wie etwa als nicht einschränkendes Beispiel eine eindimensionale (1D) Filterung mit drei Abgriffen, die drei Datenoperanden und drei Koeffizientenoperanden involviert. Wenn diese Operanden nicht von Datenspuren einer SIMD-Architektur gemeinsam genutzt werden können, müssen sechs Operanden in jede Datenspur gebracht werden, um das Ergebnis dieser konkreten Spur zu erzeugen. Um dies zu berücksichtigen, implementieren einige gängige Ansätze mehrere Leseports in einer Registerdatei, aber dies erfordert zusätzlichen Flächenbereich für die SIMD-Architektur sowie zusätzliche Leistung für den Betrieb.

Um den Mängeln herkömmlicher SIMD-Architekturen Rechnung zu tragen, kann die SIMD-Architektur der vorliegenden Offenbarung eine Kommunikation zwischen Spuren ermöglichen, indem Slices in einem Prozessor - wie etwa einer Vektorverarbeitungseinheit (VPU) - definiert werden, der aus mehreren Spuren als Gruppe besteht. Als nicht einschränkendes Beispiel kann in einem Prozessor die SIMD-Spurorganisation eine hierarchische Organisation beinhalten, die einen 384-Bit-Datenpfad beinhaltet, der in z. B. 8 Spuren mit 48 Bits (erweitertes Wort), 16 Spuren mit 24 Bits (erweitertes Halbwort) oder 32 Spuren mit 12 Bits (erweitertes Byte) partitioniert sein kann. In solchen Beispielen kann jedes Byte um 4 Bits erweitert sein. Eine erste Ebene der Kommunikation über einzelnen Spuren kann als SIMD-Slice bezeichnet werden und kann (als Beispiel und ohne Einschränkung) 96 Bits breit sein und aus zwei erweiterten Wortspuren (z. B. zwei 48-Bit-Spuren), vier erweiterten Halbwortspuren (z. B. 4 24-Bit-Spuren) oder acht erweiterten Byte-Spuren (z. B. 8 12-Bit-Spuren) bestehen. Der gesamte Prozessordatenpfad kann in nicht einschränkenden Ausführungsformen vier SIMD-Slices beinhalten, und eine zweite Kommunikationsebene kann global sein, zwischen allen vier (oder einer anderen Anzahl von) SIMD-Slices und allen Spuren. Auf diese Weise kann eine gemeinsame Nutzung von Operanden zwischen Spuren jedes Slice erreicht werden, was bei Anweisungen wie Filtern, Punktprodukt, Sortieren mit Nutzdaten usw. nützlich sein kann. Die SIMD-Architektur kann in einer VPU oder einem anderen Prozessortyp, wie etwa einem Prozessor des beispielhaften autonomen Fahrzeugs 1300 der 13A-13D , der beispielhaften Rechenvorrichtung 1400 der 14 und/oder des beispielhaften Rechenzentrums 1500 der 15, beinhaltet sein.

Die Anweisungssatzarchitektur (ISA) für SIMD kann aufgrund des physischen Routings der SIMD-Architektur die gemeinsame Nutzung durch eine gewisse Anzahl - z. B. 8 - Spuren innerhalb eines Slice ermöglichen. Wie beispielsweise in 3A veranschaulicht, kann innerhalb jedes Slice eine Kommunikation zwischen 32-Bit-Wortdatentypen, 16-Bit-Halbwortdatentypen und 8-Bit-Bytedatentypen möglich sein. Als Ergebnis kann in einem Beispiel, wie etwa einer in 3B veranschaulichten Filteroperation, bei der es vier Eingangsoperanden und vier Koeffizienten gibt, eine 8-Bit-mal-8-Bit-Multiplikation und -Akkumulation in einem Halbwort ausgeführt werden, wobei Koeffizienten mit Daten von unterschiedlichen Spuren gemeinsam genutzt werden können. In einer herkömmlichen SIMD-Architektur würde jede Spur erfordern, dass alle 8 Operanden geladen werden, um die gleiche Berechnung durchzuführen, die unter Verwendung von nur drei Eingangsoperanden in der SIMD-Architektur der vorliegenden Offenbarung durchgeführt werden kann. Als Ergebnis, und weil jeder Leseport einem vergrößerten Flächenbereich und Energieverbrauch zugeordnet ist, spart das Erfordernis von nur drei Leseports Platz und Energie zum Ausführen solcher Anweisungen. Im Betrieb können die vier Akkumulatoren - z. B. 0, 1, 2 und 3 - aufgrund der gemeinsamen Nutzung durch die Spuren innerhalb eines Slice mit den Ergebnissen der nachstehenden Berechnungen gefüllt werden.

\begin{array}{l} ACC [0] + = D [0] * C [0] + D [1] * C [1] + D [2] * C [2] + D [3] * C [3] \\ ACC [1] + = D [1] * C [0] + D [2] * C [1] + D [3] * C [2] + D [4] * C [3] \\ ACC [2] + = D [2] * C [0] + D [3] * C [1] + D [4] * C [2] + D [5] * C [3] \\ ACC [3] + = D [3] * C [0] + D [4] * C [1] + D [5] * C [2] + D [6] * C [3] \end{array}

Wie veranschaulicht, kann ACC[0] beispielsweise auf andere Spuren von src1 a einschließlich D[1], D[2] und D[3] zugreifen und kann auch auf andere Spuren von src2 zugreifen, einschließlich C[1], C[2] und C[3]. In ähnlicher Weise können die anderen Akkumulatoren (ACC) auf verschiedene Spuren von src1 und src2 zugreifen. In einem herkömmlichen Vektorprozessor mit begrenzter oder minimaler gemeinsamer Nutzung zwischen Spuren wäre diese Art von Operation nicht möglich. Diese Berechnungen können beispielsweise einen Ansatz eines gleitenden Fensters beinhalten, bei dem jeder Akkumulator die Ergebnisse der Bewegung eines gleitenden Fensters in Bezug auf einen vorherigen Akkumulator beinhaltet. Beispielsweise arbeitet der erste Akkumulator mit D[0], D[1], D[2] und D[3], arbeitet der zweite Akkumulator mit D[1], D[2], D[3] und D[4] und so weiter. Jeder Akkumulator verwendet die gleichen Koeffizienten C[0], C[1], C[2] und C[3]. Dies ist aufgrund des gemeinsam genutzten physischen Routings zwischen den Spuren des Slice der SIMD-Architektur möglich.

Als eine weitere beispielhafte Implementierung der SIMD-Architektur der vorliegenden Offenbarung und in Bezug auf 3C kann ein Punktprodukt in einer Vektormultiplikationsoperation unter Verwendung einer gemeinsamen Spurnutzung durchgeführt werden. In einem solchen Beispiel geben die beiden Indizes - z. B. D[0][0] - an, zu welcher Spur die Daten gehören und zu welchem Satz von Ausgaben diese Daten gehören. Für die Punktproduktberechnungen verwendet jede Spur nur die Datenoperanden von ihrer eigenen Spur, aber die Koeffizienten werden zwischen den Bahnen gemeinsam genutzt. Somit können die Ausgaben von jeder Spur alle vier Koeffizienten zu irgendeinem Zeitpunkt während der Punktproduktoperation verwenden. Im Betrieb können die vier Akkumulatoren -z. B. 0, 1, 2 und 3 - aufgrund der gemeinsamen Nutzung durch die Spuren innerhalb eines Slice mit den Ergebnissen der nachstehenden Berechnungen gefüllt werden.

\begin{array}{l} ACC [0] + = D [0] [0] * C [0] + D [1] [0] * C [1] + D [2] [0] * C [2] + D [3] [0] * C [3] \\ ACC [1] + = D [0] [1] * C [0] + D [1] [1] * C [1] + D [2] [1] * C [2] + D [3] [1] * C [3] \\ ACC [2] + = D [0] [2] * C [0] + D [1] [2] * C [1] + D [2] [2] * C [2] + D [3] [2] * C [3] \\ ACC [3] + = D [0] [3] * C [0] + D [1] [3] * C [1] + D [2] [3] * C [2] + D [3] [3] * C [3] \end{array}

Als eine weitere beispielhafte Operation, die von der SIMD-Architektur der vorliegenden Offenbarung profitieren kann, kann eine Zweipunkt-Sortieroperation der 3D ausgeführt werden. Bei der Zweipunktsortierung werden zwei Werte verwendet, um Nutzdaten zu sortieren. Diese Zweipunktsortierung nutzt die Kommunikation zwischen Spurpaaren innerhalb eines Slice und ist beispielsweise in verschiedenen Computer-Vision-Anwendungen nützlich. Zum Beispiel gibt es in Spur 0 Schlüssel für Element 0 und in Spur 1 entsprechende Nutzdaten usw., sodass die Nutzdaten gemäß dem Vergleich der Schlüssel sortiert werden können - z. B. wie im nachstehenden Code für jedes Schlüssel /Nutzdaten-Paar:

      wenn (schlüssel1 [i] <= schlüssel2[i]) {    // schlüssel vergleichen
            aus_schlüssel1 [i] = schlüssel1 [i];       // schlüssel und nutzdaten
            bewegen
            aus_schlüssel2[i] = schlüssel2[i];
            aus_nutzdaten1 [i] = nutzdaten1 [i];
            aus_nutzdaten2[i] = nutzdaten2[i];
      }
      sonst {
            aus_schlüssel1 [i] = schlüssel2[i];
            aus_schlüssel2[i] = schlüssel1 [i];
            aus_nutzdaten1 [i] = nutzdaten2[i];
            aus_nutzdaten2[i] = nutzdaten1 [i];
      }

Bezugnehmend nun auf 3E umfasst jeder Block des hierin beschriebenen Verfahrens 300 einen Rechenprozess, der mit einer beliebigen Kombination aus Hardware, Firmware und/oder Software durchgeführt werden kann. Beispielsweise können verschiedene Funktionen durch einen Prozessor ausgeführt werden, der im Speicher gespeicherte Anweisungen ausführt. Das Verfahren 300 kann auch als computerverwendbare Anweisungen dargestellt werden, die auf Computerspeichermedien gespeichert sind. Die Verfahren 300 kann durch eine eigenständige Anwendung, einen Dienst oder einen gehosteten Dienst (eigenständig oder in Kombination mit einem anderen gehosteten Dienst) oder ein Plug-in zu einem anderen Produkt bereitgestellt werden, um nur einige zu nennen. Auch wenn es in Bezug auf die SIMD-Architektur der vorliegenden Offenbarung beschrieben wird, kann das Verfahren 300 durch ein beliebiges System oder eine beliebige Kombination von Systemen ausgeführt werden, einschließlich unter anderem der hierin beschriebenen.

3E beinhaltet ein Flussdiagramm für ein Verfahren 300 zum Berechnen von Ausgaben unter Verwendung gemeinsam genutzter Operanden über Spuren einer SIMD-Architektur gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Das Verfahren 300 beinhaltet bei Block B302 das Partitionieren einer Bitbreite eines Prozessors in eine Vielzahl von Daten-Slices, die jeweils eine zweite Bitbreite beinhaltet, die kleiner als die erste Bitbreite ist, wobei jedes Daten-Slice der Vielzahl von Daten-Slices jeweils eine Vielzahl von Spuren beinhaltet, die eine dritte Bitbreite kleiner als die zweite Bitbreite beinhaltet. Beispielsweise kann ein Vektorprozessor in eine gewisse Anzahl - z. B. 4 - Slices partitioniert sein, und jedes Slice kann eine gewisse Anzahl von Spuren beinhalten.

Das Verfahren 300 beinhaltet bei Block B304 das Laden eines ersten Vektors in ein erstes Vektorregister, sodass eine erste Spur der Vielzahl von Spuren einen ersten Operanden des ersten Vektors beinhaltet und eine zweite Spur der Vielzahl von Spuren einen zweiten Operanden des ersten Vektors beinhaltet. Beispielsweise kann in Bezug auf 3B ein erster Datenoperand D[0] eines ersten Vektors in eine erste Spur geladen werden und kann ein zweiter Datenoperand D[1], der dem ersten Vektor entspricht, in eine zweite Spur geladen werden.

Das Verfahren 300 beinhaltet bei Block B306 das Laden eines zweiten Vektors in ein zweites Vektorregister, sodass die erste Spur der Vielzahl von Spuren einen dritten Operanden des zweiten Vektors beinhaltet und die zweite Spur der Vielzahl von Spuren einen vierten Operanden des zweiten Vektors beinhaltet. Beispielsweise kann in Bezug auf 3B ein erster Koeffizientenoperand C[0] eines dritten Vektors in die erste Bahn geladen werden und kann ein zweiter Koeffizientenoperand C[1], der dem dritten Vektor entspricht, in die zweite Bahn geladen werden.

Das Verfahren 300 beinhaltet bei Block B308 das Berechnen einer Ausgabe unter Verwendung einer Anweisung zumindest teilweise basierend auf dem ersten Operanden, dem zweiten Operanden, dem dritten Operanden und dem vierten Operanden. Beispielsweise kann in Bezug auf 3B der erste Akkumulator (ACC[0]) die Ergebnisse der Berechnung ACC[0] += D[0] * C[0] + D[1] * C[1] + D[2] * C[2] + D[3] * C[3] empfangen, was neben anderen die Werte von D[0], D[1], C[0] und C[1] beinhaltet. Diese Berechnung kann aufgrund der internen gemeinsamen Nutzung und des Routings zwischen Spuren jedes Slice stattfinden.

Das Verfahren 300 beinhaltet bei Block B310 das Speichern der Ausgabe in ein Register. Beispielsweise in Bezug auf 3B kann die Ausgabe der Berechnung in den Akkumulatorregister ACC[0] gespeichert werden und kann dann in den Speicher gespeichert werden.

TRANSPONIERTE LADE- UND SPEICHEROPERATIONEN MIT EINEM SCHRITTPARAMETER

In einem herkömmlichen SIMD-Prozessor kann der lokale Datenspeicher so bemessen sein, dass er mit einer Vektorverarbeitungsbreite übereinstimmt. Beispielsweise kann für einen 256-Bit-Vektor-SIMD-Prozessor, der in der Lage ist, 32 Spuren mit 8 Bits, 16 Spuren mit 16 Bits oder 8 Spuren mit 32 Bits zu verarbeiten, der lokale Datenspeicher beispielsweise einen 256 Bit breiten Speicher oder 512 Bit breiten Speicher (z. B. doppelt so breit wie die Verarbeitungsbitbreite) beinhalten. In solchen Beispielen ist der lokale Datenspeicher als eine einzelne Speicherbank organisiert, die Speicherwörter mit voller Breite aufweist. Ein breiter Vektor-SIMD-Prozessor mit einer einzelnen Bank von Speicherwörtern voller Breite kann jedoch ineffizient sein - insbesondere für fehlausgerichtete Speicherzugriffe. Um beispielsweise ein Array für ein 32-Bit-Array mit 16 Elementen an den Byteadressen 4 bis 67 zu laden, benötigt der Prozessor möglicherweise zwei Speicherlesevorgänge - z.. einen Lesevorgang der Adressen 0 bis 63 (einschließlich Adressen 0 bis 3 mit Daten, die für die aktuelle Operation nicht erforderlich sind) und einen zweiten Lesevorgang der Adressen 64 bis 127 (einschließlich Adressen 68 bis 127 mit Daten, die für die aktuelle Operation nicht erforderlich sind). Somit kann das Zugriffsmuster ohne die Speicherbankarchitektur der vorliegenden Offenbarung über mehrere Lade- oder Speichervorgänge erreicht werden, was zu einer Verlangsamung eines Rechen-Kernels, einer verringerten Leistung und einem erhöhten Energieverbrauch führen kann.

Um dies zu berücksichtigen, kann die einzelne breite Speicherbank stattdessen als eine Vielzahl von Speicherbanken organisiert sein - wie etwa 16-Bit-Speicherbänke (z. B. 32 Bänke mit 16-Bit-Speicher, die eine Speicherbandbreite von 512 Bits pro Taktzyklus bereitstellen). Auf diese Weise können Lese- und/oder Schreiboperationen innerhalb eines beliebigen 16-Bit-Ausrichtungen stattfinden - wodurch die Menge an überflüssigen Lese-/Schreiboperationen, wie sie im obigen Beispiel beschrieben wurden, reduziert wird. Bei einer solchen Speicherorganisation kann das Lesen der Adressen 4 bis 67 nur einen einzelnen Lesevorgang des Speichers erfordern. Zusätzlich zu der Speicherbankorganisation mit kleineren einzelnen Speicherbanken kann eine transponierte Lade- und/oder Speicherfunktionalität implementiert sein. Beispielsweise kann ein Spur-Offset-Parameter K verwendet werden, um einen Zeilenadressen-Offset zu definieren, der auf jede nachfolgende Spur im Speicher angewendet wird. Die Spurgröße kann einer Datenelementgröße entsprechen - z. B. 8 Bits, 16 Bits, 32 Bits usw. Ein gestaffeltes Zugriffsmuster kann in ein vertikales Muster übersetzt werden, wenn ein 2D-Array mit einem Zeilenabstand von W*K +1 Elementen gespeichert wird, wobei K der Offset-Parameter ist und W 64/Spurgröße (oder Größe der Datenelemente) ist. Zum Beispiel kann der Zeilenabstand für ein 32-Bit-Datenelement 16*K + 1 sein. In einigen Ausführungsformen kann der SIMD-Prozessor als eine Komponente beinhaltet sein und/oder kann ähnliche Komponenten, Merkmale und/oder Funktionalität beinhalten wie die des beispielhaften autonomen Fahrzeugs 1300 der 13A-13D, der beispielhaften Rechenvorrichtung 1400 der 14 und/oder des beispielhaften Rechenzentrums 1500 der 15.

Als ein Beispiel und in Bezug auf 4A kann die Tabelle 400 eine Veranschaulichung einer logischen Ansicht von transponierten Ladevorgängen und eine Speicherbankansicht von transponierten Ladevorgängen mit einem Zeilenabstand von 17 über 256 Bits beinhalten. Die Speicherbänke enden bei 18 separaten 16-Bit-Bänken in der Speicherbankansicht und dienen lediglich der Veranschaulichung. Beispielsweise kann die Speicherbank insgesamt 256 Bits, insgesamt 512 Bits oder eine andere Anzahl von Gesamtbits aufweisen - wobei z. B. jede Speicherbank 16 Bits breit sein kann. In der Speicherbankansicht, die die transponierten Ladevorgänge verwendet, mit einem Zeilenabstand von 17, kann eine einzelne Ladeoperation ausgeführt werden, um jeden der hervorgehobenen Werte des Arrays abzurufen.

Obwohl transponierte Lasten unter Verwendung der Technik für viele Operationen vorteilhaft sind, müssen gewisse Algorithmen - wie einige Computer-Vision-Algorithmen - möglicherweise auf Datenmuster zugreifen, die nicht mit einem einzigen Lesevorgang und/oder Schreibvorgang erreicht werden können, selbst mit den in Bezug auf 4A beschriebenen transponierten Ladetechniken. Anstelle des Ladens eines 16 hohen vertikalen Vektors kann es beispielsweise Fälle geben, in denen das Laden einer 8 hohen mal 2 Elemente breiten Untermatrix, einer 4 hohen mal 4 Elemente breiten Matrix oder einer anderen Matrix- oder Untermatrixgröße erforderlich sein kann. Bei einer Punktproduktoperation kann die Akkumulation zum Beispiel zu zwei Zeilen von 16 Elementen mit jeweils 16 Bits gleichzeitig erfolgen, sodass beim Ausspeichern eine T16-transponierte Speicheroption mit geeignetem Zeilenabstand wünschenswert sein kann, sodass zwei Zeilen als eine Speicherschreibtransaktion ausgeschrieben werden können. Um dies zu berücksichtigen, kann ein Schrittparameter mit dem transponierten Laden und/oder Speichern verwendet werden. In einigen Ausführungsformen kann der Schrittparameter einen Leistungsschritt von zwei beinhalten (obwohl dies nicht einschränkend sein soll), wie etwa einen Schritt von 2, 4, 8, 32 usw., der als T2, T4, T8, T32 usw. bezeichnet werden kann. Beispiele für unterschiedliche transponierte Ladevorgänge mit Schrittparametern sind in Tabelle 410 der 4B veranschaulicht, die eine logische Ansicht der transponierten Ladevorgänge und eine Speicherbankansicht beinhaltet. Das Beispiel von 4A, gespiegelt in 4B, beinhaltet einen Schrittparameter von 1, jedoch sind die anderen Schrittparameter ein Vielfaches von 2. Beispielsweise ermöglicht T2 mit einem Zeilenabstand von 18, dass die 2 Elemente breite mal 8 hohe Matrix als ein transponierter Ladevorgang gespeichert wird, sodass eine einzelne Ladetransaktion verwendet werden kann, um jeden der Werte abzurufen. In ähnlicher Weise kann für T4 mit einem Zeilenabstand von 20 und einer Schrittgröße von 4 die 4 Elemente breite mal 4 hohe Matrix gespeichert werden, sodass eine einzelne Ladetransaktion verwendet werden kann, um jeden der Werte abzurufen, und so weiter. Obwohl als Ladetransaktionen beschrieben, kann dieser Formattyp auch für Speichertransaktionen verwendet werden, um die Daten gemäß dem transponierten plus Schrittparameter im Speicher zu speichern.

In solchen Beispielen kann die Zeilenabstandsbeschränkung gemäß der Schrittgröße angepasst werden. Für den T-transponierten Zugriff vom Worttyp kann der Zeilenabstand 16K + 1 sein, für den T2-transponierten Zugriff vom Worttyp (z. B. für eine Schrittgröße von 2) kann der Zeilenabstand 16K + 2 sein, für den T4-transponierten Zugriff vom Worttyp sein (z. B. für eine Schrittgröße von 4) kann Zeilenabstand 16K + 4 sein und so weiter. Somit kann der Zeilenabstand gleich 16K + Schrittwert oder 16K + 1 + (T-1) sein, wobei T der Schrittparameter ist.

Im Betrieb können eine Architektur des VMEM der VPU und eine Anweisungssatzarchitektur (ISA) der VPU konfiguriert sein, um die transponierten Lade- und/oder Speicheroperationen mit oder ohne Schrittparameter auszuführen, um das Lesen oder Schreiben von Daten, die in Spalten in logischer Ansicht organisiert sind, in einem einzelnen Lesevorgang zu ermöglichen. Beispielsweise kann die ISA so konfiguriert sein, dass sie Informationen empfängt, die eine Startadresse zum Lesen von Daten oder zum Schreiben von Daten (z. B. zum Lesen oder Schreiben von Daten aus einer bzw. in eine Registerdatei), eine Angabe des Schreibtyps (z. B. eine transponierte Schreiboperation mit oder ohne Schrittparameter), einen Zeilenabstandswert (z. B. den Wert von K in 16*K + 1) und/oder einen Schrittparameterwert angeben. Es sei angemerkt, dass der Wert von 16 der Anzahl von Datenelementen einer konkreten Implementierung entspricht, aber der Wert von 16 (oder W) in unterschiedlichen Ausführungsformen unterschiedlich sein kann. Wenn Daten gemäß einer transponierten Schreiboperation in den Speicher geschrieben werden, kann die ISA somit die Startadresse zum Schreiben in den VMEM, den Zeilenabstand und/oder den Schrittparameter empfangen. Als Ergebnis können beim Schreiben der Werte, anstatt sie in eine einzelne Datenspalte in eine einzelne Speicherbank zu schreiben, die Daten gemäß einer Transponierung oder eines Offset ausgeschrieben werden, wie beispielsweise in den 4A und 4B veranschaulicht. Wenn ein Schrittparameter verwendet wird, kann ein erster Wert der Schrittgröße in den Speicher geschrieben werden, gefolgt von der nächsten Anzahl von Elementen, die der Schrittgröße entsprechen, und dann kann der Zeilenabstand angewendet werden, um einen nächsten Satz von Werten in Speicherbänke zu schreiben, sodass jeder der Werte in einem einzelnen Zyklus in den Speicher geschrieben werden kann. In ähnlicher Weise kann die ISA während der Leseoperation mit den gemäß der transponierten Speicherung organisierten oder ausgeschriebenen Daten die Startadresse, den Ladetyp (z. B. ein transponiertes Laden mit oder ohne Schrittparameter), den Zeilenabstandswert (z. B. der Wert von K) und den Schrittparameterwert (z. B. einen Datentypindikator, wie etwa Byte, Halbwort usw.) empfangen. Die ISA kann dann gemäß der transponierten Ladeanweisung (und/oder dem Schrittparameter) auf die Daten aus den verschiedenen Speicherbanken zugreifen, um eine Spalte (oder Spalten) von Daten in einem einzelnen Lesezyklus abzurufen. Auf diese Weise kann ein einzelner Vektor von einer einzelnen Leseoperation zurückgegeben werden, indem ein Element aus jeder Speicherbank abgerufen wird.

Bezugnehmend nun auf die 4C-4D umfasst jeder Block der hierin beschriebenen Verfahren 420 und 430 einen Rechenprozess, der unter Verwendung einer beliebigen Kombination von Hardware, Firmware und/oder Software ausgeführt werden kann. Beispielsweise können verschiedene Funktionen durch einen Prozessor ausgeführt werden, der im Speicher gespeicherte Anweisungen ausführt. Die Verfahren 420 und 430 können auch als computerverwendbare Anweisungen verkörpert sein, die auf Computerspeichermedien gespeichert sind. Die Verfahren 420 und 430 können durch eine eigenständige Anwendung, einen Dienst oder einen gehosteten Dienst (alleinstehend oder in Kombination mit einem anderen gehosteten Dienst) oder ein Plug-In für ein anderes Produkt bereitgestellt sein, um nur einige zu nennen. Auch wenn sie in Bezug auf die SIMD-Architektur der vorliegenden Offenbarung beschrieben werden, können die Verfahren 420 und 430 durch ein beliebiges System oder eine beliebige Kombination von Systemen ausgeführt werden, einschließlich unter anderem der hierin beschriebenen.

4C beinhaltet ein Flussdiagramm für ein Verfahren 420 zum Konfigurieren transponierter Speicheroperationen unter Verwendung eines Schrittparameters gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Das Verfahren 420 beinhaltet bei Block B402 das Bestimmen von Dimensionen einer Matrix. Beispielsweise kann eine Breite einer Matrix bestimmt werden.

Das Verfahren 420 beinhaltet bei Block B404 das Bestimmen eines Schrittparameters und eines Zeilenabstands zum Speichern der Matrix basierend auf den Abmessungen. Beispielsweise kann ein Zeilenabstand unter Verwendung von 16K + Schrittwert bestimmt werden, und der Schrittwert kann basierend auf der Breite der Matrix bestimmt werden.

Das Verfahren 420 beinhaltet bei Block B406, dass veranlasst wird, dass Werte der Matrix unter Verwendung des Schrittparameters und des Zeilenabstands im Speicher gespeichert werden. Beispielsweise können die Werte der Matrix, sobald der Zeilenabstand und die Schrittgröße bestimmt sind, im Speicher gespeichert werden, sodass der Zeilenabstand und die Schrittparameterwerte zu keinen Bankkonflikten führen, wenn die Matrixwerte aus dem Speicher gelesen werden.

Bezugnehmend nun auf 4D beinhaltet 4D ein Flussdiagramm für ein Verfahren 430 zum Konfigurieren transponierter Speicheroperationen unter Verwendung eines Schrittparameters gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Das Verfahren 430 beinhaltet bei Block B408 das Empfangen von Daten, die für einen Zeilenabstand und eine Startspeicheradresse in einer Speicherbank einer Vielzahl von Speicherbanken repräsentativ sind, wobei die Startspeicheradresse einem Element einer Vielzahl von Elementen entspricht, die einer Spalte eines Arrays entspricht.

Das Verfahren 430 beinhaltet bei Block B410 das Lesen der Vielzahl von Elementen aus der Vielzahl von Speicherbanken in einer einzelnen Leseoperation, wobei jedes Element der Vielzahl von Elementen aus einer jeweiligen Speicherbank der Vielzahl von Speicherbanken zumindest teilweise basierend auf dem Zeilenabstand gelesen wird.

LADEN MIT PERMUTATION UND NULLEINFÜGUNG IN EINER EINZELNEN ANWEISUNG

In einem herkömmlichen Prozessoranweisungssatz kann eine Ladeanweisung eine Speicheradresse durch eine Indizierungsberechnung bilden, die angeforderten Speicherdaten aus dem lokalen Speicher lesen und die Speicherdaten in einem Register ablegen. Wenn die Anwendung eine zusätzliche Datenmanipulation erfordert, können zusätzliche Anweisungen verwendet werden, um die Speicherdaten in dem Register zu bearbeiten. In einigen Fällen kann die Datenmanipulation eine einfache Datenreorganisation beinhalten. Bei einem herkömmlichen Prozessor erfordert selbst diese einfache Datenmanipulation in der Registerdatei zusätzliche Anweisungen und somit zusätzliche Latenz. Zum Beispiel können herkömmliche Systeme die Daten laden, die Permutation an den geladenen Daten durchführen und dann die reorganisierten Daten verwenden, um eine oder mehrere Operationen auszuführen. Wenn eine Ladeanweisung mit dieser Datenreorganisationsfähigkeit verbessert wird, kann etwas Verarbeitungszeit eingespart werden und die Rechen-Kernel können mit höherer Leistung und geringerem Energieverbrauch ausgeführt werden.

Um diesen Nachteilen Rechnung zu tragen, fügen Systeme und Verfahren der vorliegenden Offenbarung eine Laden-mit-Permutation-Anweisung hinzu, die ein Permutationsmuster zusammen mit einer Speicheradresse an den lokalen Speicher sendet. Als Ergebnis können bestehendes Daten-Routing und Multiplexing, die verwendet werden, um fehlausgerichtete Ladevorgänge zu handhaben, verwendet werden, um die Permutation ohne eine signifikante Menge an zusätzlicher Logik durchzuführen. Zusätzlich zum Einsparen von Anweisungen, die andernfalls ausgegeben würden - z. B. Permutieren mit doppelten Vektoreingaben und doppelten Vektorausgaben, wobei fünf auszuführende Anweisungen benötigt werden - kann die Gesamtlatenz der Permutationsoperationen reduziert werden. Zum Beispiel ist die einzige Latenz die Lade-Verwendung-Latenz, anstatt einer Lade-Verwendung-Latenz und einer Rechen-Latenz (z. B. zum Durchführen von Permutationen). In einigen Ausführungsformen kann der hierin beschriebene Ladevorgang mit Permutation und/oder Nulleinfügung in Komponenten, Merkmalen und/oder Funktionalität des beispielhaften autonomen Fahrzeugs 1300 der 13A-13D der beispielhaften Rechenvorrichtung 1400 der 14 und/oder des beispielhaften Rechenzentrums 1500 der 15 beinhaltet sein oder diesen ähnlich sein.

Somit kann das Merkmal Laden mit Permutation beim Manipulieren geladener Daten aus dem Speicher in ein gewünschtes Format zum Bearbeiten nützlich sein. Beispielsweise können Koeffizientendaten, die für verschiedene Filter- und Punktproduktanweisungen benötigt werden, spezifische sich wiederholende Muster beinhalten, die mit Laden und Permutation implementiert werden können. In Bezug auf eine Filteroperation, wie beispielsweise in Bezug auf 3C beschrieben, können Koeffizienten von 0, 1, 2 und 3 über eine Vektorbreite (z. B. 16 Bits) wiederholt werden - wie z. B. in 5A veranschaulicht. In einem solchen Beispiel kann das Ausschreiben in ein erstes Register mit D[0]-D[15] beginnen, dann kann ein gleitendes Fenster von 4 verwendet werden, um ein nächstes Register mit D[0]-D[19] zu starten und so weiter. In diesem Filterbeispiel können die Koeffizienten C[0]-C[3] über die Breite des Vektors wiederholt werden, sodass das Laden mit Permutation hilfreich sein kann, um die Koeffizienten in dieser Reihenfolge direkt aus einem Ladevorgang zu schreiben, anstatt alle Daten zu laden, dann eine Permutation durchzuführen und dann den Vektor in das Register zu schreiben. Somit kann in diesem Beispiel das Permutationsmuster für die Koeffizientendaten {0, 1, 2, 3, 0, 1, 2, 3, 0, 1, 2, 3, 0, 1, 2, 3) beinhalten. In demselben Beispiel kann das Permutationsmuster des Datenoperanden {0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19} sein. Somit können die Datenoperanden und die Koeffizientenoperanden gemäß der Permutationsreihenfolge ausgelesen werden, anstatt der Reihe nach ausgelesen und dann permutiert zu werden, bevor sie zur Berechnung in die Register geschrieben werden. Als weiteres Beispiel, wie etwa in 5B veranschaulicht, kann eine Filteranweisung einen Doppelvektorkoeffizientenoperanden beinhalten und kann somit ein Permutationsmuster wie etwa {0, 1, 2, 3, 0, 1, 2, 3, 0, 1, 2, 3, 0, 1, 2, 3, 4, 5, 6, 7, 4, 5, 6, 7, 4, 5, 6, 7, 4, 5, 6, 7} beinhalten. Das Permutationsmuster kann statisch oder fest sein oder kann im laufenden Betrieb algorithmisch berechnet werden, wodurch die Permutationsmuster flexibel und dynamisch sein können. Wenn ein Muster ein wiederholtes Muster ist, kann eine erste Instanz der wiederholten Elemente in Ausführungsformen geladen und dann repliziert und dann in die SIMD-Spuren der SIMD-Einheit geschrieben werden.

In einigen Fällen kann es vorzuziehen sein, gewisse Teile von Speicherdaten auf Nullwerte auszumaskieren. Zum Beispiel können für eine einfachere Visualisierung in der Softwareentwicklung oder um weniger Energie zu verbrauchen (z. B. im Gegensatz zum Belassen zufälliger Datenwerte) Nullen für unbenutzte Einträge eingefügt werden. In anderen Beispielen können Nullen eingefügt werden, um Datenblöcke in einer Datenstruktur abzugrenzen, beispielsweise wenn die Länge jedes Datenblocks nicht festgelegt ist. In solchen Beispielen können die Nullwerte eine Lücke zwischen zwei Datenblöcken angeben. Beim Verarbeiten eines Bildausschnitts konstanter Größe, wenn zum Beispiel einige variable Längeninformationen (z. B. Positionen von Merkmalspunkten) aus jedem Bildausschnitt extrahiert werden, können Nullen verwendet werden, um den Rest der Daten aufzufüllen, der nicht den extrahierten Informationen entsprechen.

In der Praxis können Permutationsindizes normalerweise 32 oder 16 Elemente beim Auslesen beinhalten - z. B. im Bereich von 0-31 bzw. 0-15. Um Nullwerte in das Auslesen aufzunehmen, können negative Indexwerte in das Laden-mit-Permutation-Operationen aufgenommen werden, um Nullen in die entsprechenden Spuren des Zielregisters zu schreiben. Somit können während des Schreibvorgangs beispielsweise negative Werte stattdessen als Nullen in die entsprechenden Spuren einer SIMD-Architektur geschrieben werden.

Als Beispiel kann ein Bildausschnitt von 30 breit mal 30 hoch durch Vektoroperationen unter Verwendung von 16 aufeinanderfolgenden Einträgen gleichzeitig verarbeitet werden. Da die Breite von 30 nicht durch 16 teilbar ist, kann jede Reihe durch zwei Vektoroperationen verarbeitet werden, wobei beim ersten Mal eine volle Vektorbreite von 16 Einträgen verarbeitet wird und beim zweiten Mal eine Teilvektorbreite von 14 Einträgen verarbeitet wird. In einem solchen Beispiel kann es vorteilhaft sein, wenn das Laden des zweiten Vektors mit 14 Einträgen mit Nullen aufgefüllt wird, um die letzten zwei Vektorspuren anstelle der zufälligen Datenwerte zu füllen, die derzeit im Speicher vorhanden sein können.

In einer oder mehreren Ausführungsformen können die aufgefüllten Nullen beispielsweise in gewünschte Spurpositionen einer SIMD-Architektur eingefügt werden, um die Verarbeitungszeit einzusparen, die andernfalls benötigt wird, um Nullen in diese Spurstellen zu schreiben. Wenn 16 Spuren vorhanden sind, können normale Permutationsmuster aus 16 Spurindizes bestehen - z. B. 0-15. In einem solchen Beispiel, wenn die Werte von {100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115} vorhanden sind und Indizes, die als Permutationsmuster bereitgestellt sind, {0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, -1, - 1} sind, sollten die Werte, die letztendlich in das Zielregister geladen werden, {100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 0, 0} sein. Somit werden die zwei Werte von -1 im Zielregister basierend auf dem Permutationsmuster, das negative Werte beinhaltet, automatisch in 0 umgewandelt. Bei früheren Ansätzen würden -1, -1 14 bzw. 15 beinhalten, und die Werte im Speicher bei 14, 15 würden in das Register geschrieben werden. Diese können jedoch zufällige Werte beinhalten, die im Vergleich zum Einschließen von 0-Werten möglicherweise zusätzliche Verarbeitungszeit erfordern.

Um das Merkmal Laden-mit-Permutation zu implementieren, kann Routing und Multiplexing in der Speicherlogik verwendet werden - z. B. ähnliches Routing und ähnliche Logik, die verwendet werden, um nicht ausgerichtetes Speicherladen auszuführen. Um beispielsweise das Laden einer vollen Speicherbreite (z. B. 32 x 16 Bits) von einer beliebigen 16-Bit-Adresse (oder 16 x 32-Bit-Spuren von einer beliebigen 32-Bit-Adresse) zu unterstützen, kann die Speicherlogik eine Multiplexlogik beinhalten, um eine beliebige von 32 Spuren von Speicherdaten auszuwählen, um sie in eine beliebige Zielregisterspur zu routen. Für nicht ausgerichtete Speicherladevorgänge kann die Logik beispielsweise wie folgt angesteuert werden:

ausgabe_spur[0] = auswählen( start_spur, speicher_spur[0 .. 31]);
ausgabe_spur[1] = auswählen( (start_spur + 1) % 32, speicher_spur[0 .. 31]);
ausgabe_spur[2] = auswählen( start_spur + 2) % 32, speicher_spur[0 .. 31]);
...
ausgabe_spur[31] = auswählen( (start_spur + 31) % 32, speicher_spur[0 .. 31]).

Die Gesamtzahl von Spuren kann in Ausführungsformen unter Verwendung eines Modulo-Operators (%) umgebrochen werden. Wenn also beispielsweise Spur 3 eine Startspur ist, würden die Spuren 3, 4, 5, ..., 31, 0, 1, 2 als Ausgabe in Registerspuren verwendet.

Für ein Merkmal Laden mit Permutation kann dieselbe Logik im Wesentlichen wiederverwendet werden, kann aber eine überarbeitete Logik beinhalten, um die Permutationsoperation durchzuführen. Ein Beispiel für die überarbeitete Logik ist nachstehend beinhaltet:

ausgabe_spur[0] = auswählen( (start_spur + permutiere[0]) % 32, speicher_spur[0 .. 31]);
ausgabe_spur[1] = auswählen( (start_spur + permutiere[1]) % 32, speicher_spur[0 .. 31]);
ausgabe_spur[2] = auswählen( (start_spur + permutiere[2]) % 32, speicher_spur[0 .. 31]);
...
ausgabe_spur[31] = auswählen( (start_spur + permutiere[31]) % 32, speicher_spur[0 .. 31]).

Als ein Beispiel und in Bezug auf 5C kann eine Hardwarestruktur 500 (die als Teil einer VPU, einer SIMD-Einheit, eines SoC oder eines anderen Vorrichtungstyps beinhaltet sein kann) mit einer Crossbar 510 (z. B. einem Crossbar-Schalter) verwendet werden, um Daten von jeder beliebigen Stelle des Speichers 512 zu entnehmen und die Daten durch einen oder mehrere entsprechende Multiplexer (mux(es)) 514A-514N zu einer beliebigen Spur in SIMD zu treiben. Auf diese Weise kann jede von 16 Eingaben (oder Speichern oder Registern anderer Breite) in der Lage sein, in jede von 16 Ausgabestellen oder -spuren geschrieben zu werden. Dies kann bei nicht ausgerichteten Zugriffen helfen, sodass eine Ladeoperation von einer beliebigen Adresse beginnen und dann nach unten ausgerichtet werden kann. Wenn beispielsweise Daten im Speicher von den Stellen 2-18 gelesen werden, können die Daten von 2-18 ausgelesen werden, aber mit den Spuren 0-16 ausgerichtet werden (z. B. geht 2 zu Spur 0, geht 3 zu Spur 1 und so weiter). Dies war in herkömmlichen Systemen nicht möglich, bei denen Vektorladevorgänge an Stellen starten mussten, die Vielfache von 16 waren, wie etwa 0, 16, 32 usw. Innerhalb dieser Struktur der 5C kann auch eine Permutation abgeschlossen werden, da Daten von einem beliebigen Speicherindex an eine beliebige Spur in der SIMD-Einheit von z. B. einer VPU ausgegeben werden können. Die Multiplexer 518 können verwendet werden, um eine Permutationssteuerung für jede Spur einzubringen oder einzufügen, um die Multiplexer 514 der Crossbar 510 zu informieren, von welcher Speicherstelle Daten auf der Grundlage der Startposition (die ausgerichtet oder fehlausgerichtet sein kann) und des Permutationsmusters zu lesen sind. Anstatt einfach Daten von ausgerichteten Stellen zu entnehmen, kann das Permutationsmuster somit verwendet werden, um die Stelle für Speicherlesevorgänge zu aktualisieren, sodass jeder Multiplexer 514 die richtigen Daten an jede der Spuren der SIMD-Einheit sendet. Außerdem können die Multiplexer 516 verwendet werden, um Nullen für Permutationsmuster einzufügen, die negative Werte oder andere Werte beinhalten, die das Einfügen von Nullen angeben (z. B. wenn ein anderer Wert als ein negativer Wert verwendet wird, um das Einfügen von Nullen zu bewirken). Sobald die Speicherzugriffsstellen von den Multiplexern 518 an die Crossbar 510 gesendet werden und die Werte von den Speicherzugriffen an die Multiplexer 516 zum Einfügen von Nullen gesendet werden, können die Werte, die negativen Werten in dem Permutationsmuster entsprechen, in Nullwerte umgewandelt werden, um die Werte für die jeweiligen SIMD-Spuren aufzufüllen. Auch wenn in 5C nur vier Sätze von Spuren, Multiplexern und Speicherindizes veranschaulicht sind, soll dies nicht einschränkend sein, und es kann eine beliebige Anzahl von Sätzen beinhaltet sein, ohne vom Umfang der vorliegenden Offenbarung abzuweichen.

5D veranschaulicht eine beispielhafte Verwendung der Hardwarearchitektur 500. Beispielsweise kann die Veranschaulichung in 5D auf den folgenden Informationen basieren:

      crossbar_modus = 1;
      start_spur = 2;
      muster permutieren = {3, 1, -1, ..., 2} = {011b, 001b, 111b, ..., 01 0b};
      speicherlesebus = {100, 101, 102, ..., 103}
      permutiere_low = {3, 1, 3, ..., 2}; // untere 2-bit-permutation
      permutiere_zeichen = {0, 0, 1, ..., 0}; // bit 3 der permutation
      datenausgabe lesen = {103, 101, 0, ..., 102}

Zusätzlich kann der folgende C-Code die Logikschaltung der Hardwarearchitektur der 5C und 5D beschreiben:

      log2N = fp_int_runden(log2(N)); // z. B. N = 16, log2N = 4




      für (i = 0; i < N; i++) {
            permutiere_low[i] = permute[i] & (N-1);
            permutiere_zeichen[i] = (permutiere[i] >>log2N) & 1;
            wenn (crossbar_modus == 0)
                  crossbar_auswählen[i] = (start_spur + i) % N;
            sonst
                  crossbar_auswählen[i] = permutiere_low[i]; 

      }
      für (i = 0; i < N; i++) {
            crossbar_aus[i] = D[crossbar_auswählen[i]];
      }
      für (i = 0; i < N; i++) {
            wenn (crossbar_modus && permutiere_zeichen[i] == 0)
                  null_einfügen_aus[i] = crossbar_aus[i];
            sonst
                  null_einfügen_aus[i] = 0;
      }

Somit kann in dem Beispiel von 5D der Bitwert von 1 in den Multiplexern 518 angeben, dass der Wert Lade Permutieren ausgewählt werden soll, und diese Werte {3, 1, 3, ..., 2} können an die jeweiligen Multiplexer 514 der Crossbar 510 übertragen werden. Somit können die Werte von {103, 101, 103, ..., 102} aus dem Speicher gelesen und an die Multiplexer 516 gesendet werden, wobei das Permutationsmuster eine -1 für den dritten Wert beinhalten kann, und somit kann der Wert 103 durch Einfügen von Nullen in eine 0 umgewandelt werden. Somit können die Endwerte von {103, 101, 0, ..., 102} in die Vektorregister zurückgelesen werden.

Bezugnehmend nun auf 5E umfasst jeder Block des hierin beschriebenen Verfahrens 550 einen Rechenprozess, der mit einer beliebigen Kombination aus Hardware, Firmware und/oder Software durchgeführt werden kann. Beispielsweise können verschiedene Funktionen durch einen Prozessor ausgeführt werden, der im Speicher gespeicherte Anweisungen ausführt. Das Verfahren 550 kann auch als computerverwendbare Anweisungen dargestellt werden, die auf Computerspeichermedien gespeichert sind. Die Verfahren 550 kann durch eine eigenständige Anwendung, einen Dienst oder einen gehosteten Dienst (eigenständig oder in Kombination mit einem anderen gehosteten Dienst) oder ein Plug-in zu einem anderen Produkt bereitgestellt werden, um nur einige zu nennen. Zusätzlich wird das Verfahren 550 beispielhaft in Bezug auf die Hardwarestruktur der 5C beschrieben. Dieses Verfahren 550 kann jedoch zusätzlich oder alternativ durch ein beliebiges System, eine beliebige Struktur oder Komponente oder eine beliebige Kombination von Systemen, Strukturen oder Komponenten ausgeführt werden, einschließlich, jedoch nicht beschränkt auf die hierin beschriebenen.

5E ist ein Flussdiagramm, das ein Verfahren 550 zum Durchführen von Laden-mit-Permutation-Operationen gemäß einiger Ausführungsformen der vorliegenden Offenbarung zeigt. Das Verfahren 550 beinhaltet bei Block B502 das Bestimmen eines Permutationsmusters zum Laden von Daten aus dem Speicher. Beispielsweise kann ein Permutationsmuster statisch sein oder kann dynamisch berechnet werden. Das Permutationsmuster kann ausgerichtet (z. B. 0 bis 16 oder 0 bis 32), fehlausgerichtet (z. B. 2 bis 18), wiederholt (z. B. 0, 1, 2, 3, 0, 1, 2, 3, ..., usw.) und/oder ein anderer Mustertyp sein.

Das Verfahren 550 beinhaltet bei Block B504 zumindest teilweise basierend auf dem Permutationsmuster das Bestimmen von Speicheradressenstellen für jede Spur einer Vielzahl von Spuren. Beispielsweise kann das Permutationsmuster angeben, aus welchen Speicheradressenstellen die Daten für eine konkrete Spur oder ein konkretes Register geladen werden sollen. Das Permutationsmuster kann unter Verwendung der Multiplexer 518 implementiert werden, sodass die richtigen Speicheradressen gemäß dem Permutationsmuster an die Crossbar 512 gesendet werden.

Das Verfahren 550 beinhaltet bei Block B506 das Laden von Werten in jede Spur der Vielzahl von Spuren zumindest teilweise basierend auf den Speicheradressenstellen. Beispielsweise können die Multiplexer 514 von der Crossbar 512 auf Grundlage der Speicheradressenorte die entsprechenden Werte aus dem Speicher abrufen, um sie in eine oder mehrere Spuren innerhalb eines oder mehrerer Vektorregister zu schreiben. In einigen Ausführungsformen können die Multiplexer 516 auch verwendet werden, um Werte, die negativen Werten in dem Permutationsmuster (oder anderen Werten, die ein Auffüllen mit Null angeben) zugeordnet sind, in Nullen umzuwandeln. Wenn also ein oder mehrere negative Werte in dem Permutationsmuster beinhaltet sind, können die aus dem Speicher geladenen Werte in Nullen umgewandelt werden, bevor sie in das/die Vektorregister geschrieben werden.

Das Verfahren 550 beinhaltet bei Block B508 das Durchführen einer oder mehrerer Operationen innerhalb jeder Spur der Vielzahl von Spuren unter Verwendung der Werte und mindestens einer Anweisung. Sobald die Vektorregister oder die Verarbeitungsspuren der SIMD-Einheit belegt sind, können zum Beispiel eine oder mehrere Operationen - z. B. arithmetische Anweisungen, logische Anweisungen, Verschiebe-/Rotationsanweisungen, Bitoperationsanweisungen, Vergleichsanweisungen, Umwandlungsanweisungen, Konstantengenerierungsanweisungen und/oder dergleichen - unter Verwendung einer oder mehrerer Verarbeitungseinheiten ausgeführt werden, die der einen oder mehreren Verarbeitungsspuren entsprechen.

MEHRPUNKTABFRAGE MIT KOMBINATION ZUR DURCHFÜHRUNG VON TABELLENABFRAGEN

In einem herkömmlichen Prozessor mit Vektor-SIMD-Berechnung kann der lokale Speicher eine Bitbreite beinhalten, die mit der Bitbreite der Vektor-SIMD übereinstimmt. Infolgedessen können diese Prozessoren im Allgemeinen nur Lese- und/oder Schreibausrichtung und Granularität entsprechend der Bitbreite unterstützen. Die Tabellenabfrage ist jedoch eine gängige Technik z. B. in der Digitalsignalverarbeitung (DSP) und Computer-Vision für eingebettete Umgebungen, wie etwa zum Implementieren verschiedener nichtlinearer Funktionen. Quadratwurzel-, Logarithmus-, Sinus- und Cosinus-Funktionen können beispielsweise erfordern, dass Tabellenabfragen ausgeführt werden. Um diese Funktionen auszuführen, kann ein Eingaberaum gleichmäßig in einem eindimensionalen (1D) Gitter abgetastet werden, und die Ausgaben können an diesen Eingabepunkten in einer 1 D-Tabelle aufgezeichnet werden. Wenn eine nichtlineare Funktion mit einer Tabellenabfrage implementiert wird, gibt es jedoch häufig einen Zielkonflikt zwischen Tabellengröße (z. B. einer Anzahl von Einträgen in der Tabelle) und Genauigkeit. Um die Genauigkeit zu verbessern, ohne eine große Tabellengröße zu erfordern, kann eine interpolierte Abfrage durchgeführt werden, wobei zwei Punkte um einen Bruchindex herum für eine lineare Interpolation abgefragt werden, oder drei Punkte um einen Bruchindex herum für eine quadratische Interpolation abgefragt werden.

Wenn beispielsweise eine Sinusfunktion unter Verwendung einer Lookup-Tabelle implementiert wird und die Sinuswerte in ganzzahligen Graden tabelliert werden, dann gilt: Tabelle[0] = sin(0 Grad), Tabelle[1] = sin(1 Grad), Tabelle[ 2] = sin(2 Grad) und so weiter. In einem solchen Beispiel, in dem die Auswertung sin(1,7 Grad) ist, kann eine Interpolation zwischen den zwei ganzzahligen Gradeinträgen linear unter Verwendung des Bruchs als Tabelle[1]*0,3 + Tabelle[2]*0,7 stattfinden. In diesem Beispiel erhält der zweite Eintrag für Tabelle[2] den Bruch als Gewichtung, und der erste Eintrag erhält 1 minus den Bruch, sodass je näher der Bruch an 1,0 oder an der Position liegt, der der zweite Eintrag entspricht, desto höher der zweite Eintrag gewichtet wird.

Als ein weiteres Beispiel kann ein Bild oder ein Ausschnitt eines Bildes erneut abgetastet werden, was das Abfragen verfügbarer Pixel um einige Buchteilpixelkoordinaten herum und das anschließende Durchführen einer interpolierten Abfrage beinhalten kann. In einem solchen Beispiel kann die Tabelle einen Bildausschnitt beinhalten und zweidimensional sein. In diesem Fall kann eine bilineare Interpolation durchgeführt werden, um in zwei Dimensionen jeweils linear zu interpolieren. Beispielsweise kann ein Bildausschnitt an Position Y = 5,1, X = 7,6 gemäß der folgenden Berechnung interpoliert werden:

\begin{matrix} (ausschnitt [5] [7] * 0.4 + ausschnitt [5] [8] * 0.6) * 0.9 + (ausschnitt [6] [7] * 0.4 + \\ ausschnitt [6] [8] * 0.6) * 0.1 \end{matrix}

Die Durchführung dieser Art von interpoliertem Abfragen in einem herkömmlichen Prozessor ist jedoch teuer, da separate Abfragevorgänge für jeden Wert aus jeder Tabelle durchgeführt werden müssen. Um diesen Prozess zu beschleunigen, kann eine Tabelle repliziert werden, um eine beliebige Anzahl von Abfragen gleichzeitig unter Verwendung unterschiedlicher Instanzen der Tabelle zu ermöglichen. Beispielsweise kann im obigen Beispiel beim Abfragen von Ausschnitten bei 5, 6, 7 und 8 eine Tabelle mindestens viermal repliziert werden, um das parallele Abfragen in den vier Tabellen zu ermöglichen. Wenn ein Prozessor - wie etwa eine VPU - beispielsweise 32-Wege-Parallelität unterstützt, kann die Tabelle 32-mal repliziert werden. Während das Replizieren der Tabelle den Durchsatz pro Zyklus erhöhen kann, erfordert die Replikation jedoch auch zusätzliche Speicherkapazität und - nutzung, die in gewissen Implementierungen möglicherweise nicht verfügbar oder optimal ist.

Um dies zu berücksichtigen, verwenden die hierin beschriebenen Systeme und Verfahren Zwei-Punkt- und/oder Zwei-mal-Zwei-(2x2)-Punkt-Abfrageoperationen, um den Durchsatz zu erhöhen (oder sich zum Beispiel den Durchsatz einer 32-Wege-Parallelität anzupassen), während Speicherplatz gespart wird. Beispielsweise können unter Verwendung von Adressbussen pro Speicherbank und zugeordneter Logik und zugeordnetem Routing parallele Abfragen von zwei Punkten oder 2 × 2 Punkten (z. B. 4 Punkten) mit weniger Speicherverbrauch ausgeführt werden. Somit kann eine einzelne Abfrage in einer Tabelle zwei Punkte bei einer Zwei-Punkt-Abfrage oder vier Punkte bei einer 2x2-Punkt-Abfrage ergeben. Dies kann basierend auf der Hardwareeinrichtung - z. B. Bankadressen, Logik, Routing usw. - und dem Speicherungsmuster im Speicher erreicht werden, was das Auslesen mehrerer Daten ohne Bankkonflikte ermöglicht. Ohne diese Merkmale, wie vorstehend erwähnt, müsste eine Tabelle 32 Mal repliziert werden, um z. B. eine parallele 32-Wege-Abfrage zu erreichen. Diese parallele 32-Wege-Abfrage kann beispielsweise mit dem folgenden C-Code ausgeführt werden:

      für (...) {
            ...
            eintrag1 = dvlut_32h(tabelle, index); // ersten eintrag in 32 spuren
            erhalten
            eintrag2 = dvlut_32h(tabelle + 32, index); // zweiten eintrag in 32 spuren
            erhalten, 32 hinzufügen
                                         // zu tabellenzeiger anstatt hinzufügen
                                         // indizes zum zeitsparen
            aus = dvkomb (eintrag1, eintrag2, bruch); // doppelte vektorkombination,
            um 32 ausgaben zu erhalten
            ...
      }

In diesem Beispiel kann der Abfrageteil der Schleife 32 Abfragevorgänge pro Zyklus für zwei Zyklen durchführen (wobei Abfragen und Kombinationen in Speicher- bzw. Vektormath.-Slots ausgeführt und in zwei Zyklen pro Iteration gepipelinet werden) und interpoliert werden, um 32 Ausgaben zu erzeugen. Der Abfrage/Interpolationsdurchsatz beträgt somit 16 Ausgaben pro Zyklus und erfordert eine 32-malige Replikation der Tabelle.

Als weiteres Beispiel und in Bezug auf 6A ist eine parallele 16-Wege-Tabellenorganisation zum Durchführen einer Ein-Punkt-Abfrage mit dem Indexvektor {0, 1, 2, 3, 4, 5, 4, 3, ...} veranschaulicht. In einem solchen Beispiel müssten unter Verwendung herkömmlicher Architekturen und Speicherlayouttechniken das erste Abfragen und ein zweites Abfragen sequentiell durchgeführt werden, um die zwei Einträge aus jeder Speicherbank zu lesen. Zum Beispiel beinhaltet eine erste Speicherbank T0 Werte bei T0[0] und T0[1], die in der Abfrageoperation ausgelesen werden sollen, aber da sich die Werte beide in derselben Speicherbank T0 (die nur einen einzelnen Leseport beinhalten kann) befinden, wird der erste Wert T0[0] in einem ersten Durchlauf gelesen und wird der zweite Wert T0[1] in einem zweiten, sequentiellen Durchlauf gelesen. Wenn bei einem solchen Speicherlayout zwei Lesevorgänge in derselben Speicherbank stattfinden sollen, würde ein Bankkonflikt auftreten, der eine Verzögerung bei der Verarbeitung einführen und/oder bewirken kann, dass ein Algorithmus oder eine andere Berechnung nicht richtig ausgeführt wird.

Unter Verwendung der Architektur der vorliegenden Offenbarung können dieselben 32 Abfragevorgänge jedoch nur 16 Tabellenreplikationen für eine Zwei-Punkt-Abfrage oder nur 8 Mal für eine 2 × 2-Punkt-Abfrage erfordern. Beispielsweise kann mit einer Zweipunkt-Abfrage die gleiche Leistung von 16 Ausgaben pro Taktzyklus mit nur 16-maliger Replikation der Tabelle erreicht werden, wodurch der Speicherbedarf um einen Faktor von zwei reduziert wird. Eine parallele 16-Wege-Variante der Anweisung kann einen Doppelvektor mit ersten Einträgen in einem niedrigeren Einzelvektor und zweiten Einträgen in einem höheren Einzelvektor zurückgeben. In C-Code kann diese parallele 16-Wege-Abfrage und Interpolation wie folgt dargestellt werden:

      für (...) {
            ...
            eintrag12 = dvlut_2pt_16h(tabelle, index); // ersten eintrag in 16 unteren
            spuren erhalten,
                                         // zweiter eintrag in 16 oberen spuren 

            aus = vkomb(eintrag12.lo, eintrag12.hi, bruch.lo);// kombinieren, um
            16 ausgaben zu erhalten
            ...
     }

In einem solchen Beispiel kann der Abfrage- und Interpolationsteil der Schleife nur einen einzigen Taktzyklus erfordern (wobei das Abfragen und Kombinieren in Speicher- bzw. Vektormath.-Slots ausgeführt und in einen Zyklus pro Iteration gepipelined wird) und interpoliert werden, um 16 Ausgaben zu erzeugen. Abfrage/Interpolation beträgt somit 16 Ausgaben pro Zyklus. Als ein Beispiel und in Bezug auf 6B ist eine parallele 8-Wege-Tabellenorganisation zum Durchführen einer Zwei-Punkt-Abfrage mit dem Indexvektor {0, 1, 2, 3, 4, 5, 4, 3, ...} veranschaulicht. Da in einem solchen Beispiel jede Speicherbank T0, T1, T2 usw. nur einen einzelnen Wert beinhaltet, der während einer Abfrageoperation auszulesen ist, können alle 16 Werte in einem einzigen Durchlauf ausgelesen werden, im Gegensatz zu dem Beispiel der 6A, bei dem wegen der Möglichkeit von Bankkonflikten nur 8 Werte in jedem von zwei Durchläufen ausgelesen werden können. Hierfür können die Anweisungen für die Abfrage in Ausführungsformen einen einzelnen Index und ein Muster beinhalten, das das Abrufen nicht nur des Index, sondern auch des Index plus einer Stelle beinhaltet. Somit können die Anweisungen das Lesen der zwei Werte für eine Zwei-Punkt-Abfrage bewirken, und die Werte können in diesem Format in die Lookup-Tabelle geschrieben werden, um zu ermöglichen, dass dieser einzelne Lesevorgang ohne Bankkonflikte ausgeführt wird.

Wenn beispielsweise Vektoroperationen durchgeführt werden, kann jede Spur einer VPU einen Satz von Pixelwerten verarbeiten, die aus dem Speicher abgerufen werden. In einigen Fällen kann eine Spur mehrere Werte von derselben Speicherbank verarbeiten, was zu einem Bankkonflikt führen kann, da die Speicherbank möglicherweise nur einen einzelnen Leseport beinhaltet. Somit verteilen die Verfahren und Systeme der vorliegenden Offenbarung die Werte über Speicherbänke, sodass keine Bankkonflikte auftreten und jeder der Werte für eine einzelne Verarbeitungsspur einer VPU zum Beispiel auf jeden entsprechenden Wert in einem einzelnen Lesezyklus zugreifen kann.

Bei herkömmlichen Systemen, bei denen bilinear interpolierte 2D-Abfragen durchgeführt werden, sind vier Abfragen (z. B. 2 × 2) für jede Ausgabe erforderlich, was einen optimalen Durchsatz von 8 Ausgaben pro Taktzyklus mit 32 Kopien der Tabelle ermöglicht. Mit einer 2x2-Punkt-Abfrage können 8 Ausgaben pro Zyklus mit einer 8-fachen Replikation der Tabelle (im Vergleich zu 32) erreicht werden, wodurch der für parallele Untertabellen benötigte Speicherbedarf um einen Faktor von vier reduziert wird. Beispielsweise können bei einer 2x2-Punkt-Abfrage zwei Einträge aus einer Reihe einer 2D-Tabelle und dann zwei Einträge aus einer nächsten Reihe gelesen werden. Um Speicherbankkonflikte innerhalb jeder Speicherbank zu vermeiden, kann ein Zeilenabstand in der 2D-Tabelle auf m*k + 2 beschränkt werden, wobei m die Anzahl von Einträgen in jeder horizontal gespeicherten Untertabelle ist und k eine beliebige ganze Zahl ist, die zum Speichern einer Reihe der Tabelle ausreichend ist. Für eine parallele 8-Wege-16-Bit-Tabelle ist m = 32 (16-Bit-Speicherworte) / 8 (Parallelität) = 4. Für eine parallele 2-Wege-32-Bit-Tabelle ist m = 16 (32-Bit-Speicherworte) / 2 (Parallelität) = 8.

Als ein Beispiel und in Bezug auf die 6C-6D kann die Zeilenabstandsbeschränkung verwendet werden, um eine Speicherkonkurrenz zu vermeiden. In einem solchen Beispiel ist eine parallele 2-Wege-Worttyptabelle für eine 2x2-Punkt-Abfrage mit einem Zeilenabstand von 10 veranschaulicht. Die Anzahl aufeinanderfolgender Elemente in einer Untertabelle (m) ist 8, wobei A[0][0...7] aufeinanderfolgend in einer Untertabelle platziert ist, was der Formel 8k +2 entspricht, wobei k eine beliebige ganze Zahl sein kann. Unabhängig davon, welcher Indexwert zu Beginn verwendet wird, können die abzurufenden 2x2-Punkte in verschiedenen Banken platziert werden, was durch Mathematik sichergestellt wird. Beispielsweise sind die Banknummern für die 2x2-Punkte relativ zur Untertabelle nachstehend aufgeführt:

\begin{array}{l} index % 8, \\ (index + 1) % 8, \\ (index + zeilen_abstand) % 8 = (index + 8 k + 2) % 8 = (index + 2) % 8, \\ (index + zeilen_abstand + 1) % 8 = (index + 8 k + 2 + 1) % 8 = (index + 3) % 8 \end{array}

Im Allgemeinen gibt es 4 abzurufende Einträge mit 2x2-Abfrage in Banknummern im Verhältnis zur Untertabelle, die Index % m, (Index + 1) % m, (Index + 2) % m, (Index + 3) % m) sind. Solange m >= 4 ist, sollte es keine Bankkonflikte geben. Im Beispiel der 6C-6D kann die Abfrage 2D-Indizes von (0, 1) und (1, 3) beinhalten, wobei Y dann X als Konvention verwendet wird, um Pixel in der Reihenhauptreihenfolge zu speichern. In 6C ist eine logische Ansicht von zwei 2D-Tabellen veranschaulicht, und in 6D ist eine Speicherlayoutansicht der Werte aus den Tabellen veranschaulicht. In der logischen Ansicht sind die Abfragen 2x2, wie veranschaulicht, und die Speicherlayoutansicht veranschaulicht die vier Punkte jeweils in einer anderen Speicherbank (oder einer anderen Spalte in der Veranschaulichung), sodass jeder dieser Werte in einem einzelnen Zyklus oder Durchlauf ausgelesen werden kann. Die Werte aus den Tabellen können auf diese Weise im Speicher gespeichert werden, basierend auf Anweisungen, die Indizes (z. B. (0, 1) und (1, 3)) und ein Lesemuster verwenden, um jeden der Werte in einem einzelnen Durchlauf aus dem Speicher zu lesen. Somit können unter Verwendung dieses Speicherlayouts und dieser Leseanweisung vier Einträge pro Untertabelle in jedem Zyklus im folgenden Format zurückgegeben werden:

ziel unterer einzelvektor: A[0][1], A[0][2], B[1][3], B[1][4], (rest mit nullen gefüllt)
ziel oberer einzelvektor: A[1][1], A[1][2], B[2][3], B[2][4], (rest mit nullen gefüllt)

Obwohl in 6C als zwei 2D-Tabellen mit 10 Elementen breit und 3 hoch veranschaulicht - z. B. eine A-Tabelle und eine B-Tabelle - soll dies nicht einschränkend sein, und die Tabellen können abhängig von der Ausführungsform eine beliebige Breite und/oder Höhe aufweisen. In ähnlicher Weise beinhaltet das Speicherlayout in 6D ein 16 Elemente breites mal 3 hohes Layout, aber dies soll nicht einschränkend sein, und die Speicherbreite und/oder -höhe kann eine beliebige Konfiguration sein, abhängig von der Ausführungsform.

Bei einigen Implementierungen, wie etwa beim Abtasten eines Bildausschnitts, kann eine Interpolation zwischen einem Bruchteil eines Pixels ausgeführt werden. In einigen Ausführungsformen kann zum Interpolieren von Abfragewerten ohne zusätzliche Anweisungen zum Manipulieren von Daten eine Anweisung zum horizontalen Vektorkombinieren mit Verschachtelung (VHKomb_I) ausgeführt werden, der horizontales Kombinieren mit verschachtelten Daten zum Kombinieren zwischen Spurpaaren beinhalten kann. Beispielsweise kann mit dieser Anweisung eine bilineare Nach-Abfrage-Interpolation in derselben Schleife ausgeführt werden. Diese Anweisung kann jedes Spurpaar gemäß dem Layout der Tabelle von 6E verarbeiten. Auf diese Weise können die Berechnungen von Y0 und Y1 wie folgt berechnet werden:

Y 0 = x * (1 - alpha 0) + y * alpha 0

Y 1 = z * (1 - alpha 1) + w * alpha 1

Somit kann die Anweisung ein horizontales Kombinieren zwischen Spurpaaren x und y, z und w bewirken und kann bewirken, dass die Ausgaben in dem Zielregister verschachtelt werden. Zum Beispiel kann das folgende C-Codesegment verwendet werden, um eine optimale Leistung an einer parallelen 8-Wege-Tabelle unter Verwendung einer 2x2-Punkt-Abfrage zu erreichen.

      für (...) {


            ...
            einträge1 = dvlut_2x2pt_8h(tabelle, index. niedrig);    // 8 indizes ->
            32 einträge
            einträge2 = dvlut_2x2pt_8h(tabelle, index. hoch);    // 8 indizes ->
            32 einträge
            y_intrp1 = vhkomb_i(einträge1.lo, einträge1.hi, x_bruch.lo); // horz-intrp
            32->16
            y_intrp2 = vhkomb_i(einträge2.lo, einträge2.hi, x_bruch.hi); // horz-intrp
            32->16
            out = vhkomb_i (y_intrp1, y_intrp2, y_bruch);    // vert-intrp 32->16
            vspeichern(aus);
      }

Bei dieser parallelen 8-Wege-Tabellenorganisation mit Untertabellen, die als A, B, ..., H bezeichnet sind, kann eine Schleife eine Abfrage und Interpolation durchführen, die zu 16 Ausgaben pro Iteration führt. In einem solchen Beispiel können Eingaben wie folgt organisiert sein:

      index. niedrig = {index0, index1, index2, index3, index4, index5, index6, index7,
      (rest ignoriert) }
      index.hoch = {index8, index9, index10, index11, index12, index13, index14,
      index15, (rest ignoriert)} 

      x_bruch.niedrig = {xf0, xf0, xf1, xf1, ..., xf7, xf7}    // wiederholungsmuster
      beachten
      x_bruch.hoch = {xf8, xf8, xf9, xf9, ..., xf15, xf15}   // wiederholungsmuster
      beachten
      y_bruch = {yf0, xf8, yf1, yf9, ..., yf15}    // verschachtelungsmuster beachten

Eine beispielhafte Veranschaulichung der Zwischen- und Endergebnisse dieser Anweisung ist in 6F veranschaulicht, die Pfeile beinhaltet, die die Kombinations- und Verschachtelungsmuster der Daten angeben.

Unter nunmehriger Bezugnahme auf 6G umfasst jeder Block des hierin beschriebenen Verfahrens 600 einen Rechenprozess, der unter Verwendung einer beliebigen Kombination von Hardware, Firmware und/oder Software durchgeführt werden kann. Beispielsweise können verschiedene Funktionen durch einen Prozessor ausgeführt werden, die im Speicher gespeicherte Anweisungen ausführt. Das Verfahren 600 kann zudem als computerverwendbare Anweisungen verkörpert sein, die auf Computerspeichermedien gespeichert sind. Das Verfahren 600 kann durch eine eigenständige Anwendung, einen Dienst oder gehosteten Dienst (eigenständig oder in Kombination mit einem anderen gehosteten Dienst) oder ein Plug-in für ein anderes Produkt bereitgestellt werden, um nur einige zu nennen. Das Verfahren 600 kann zusätzlich durch ein beliebiges System, eine beliebige Struktur oder Komponente oder eine beliebige Kombination von Systemen, Strukturen oder Komponenten ausgeführt werden, einschließlich, jedoch nicht beschränkt auf die hierin beschriebenen.

6G ist ein Flussdiagramm, das ein Verfahren 600 zum Durchführen einer Mehrpunktabfrage (z. B. in einem einzelnen Taktzyklus in einem Beschleuniger mit entkoppelter Lookup-Tabelle (DLUT), wie etwa mit Bezug auf die 9A-9C beschrieben) gemäß einigen Ausführungsformen der vorliegenden Offenbarung zeigt. Das Verfahren 600 beinhaltet bei Block B602 das Replizieren einer Tabelle in den Speicher, um einen ersten Wert an einer ersten physischen Adresse in einer ersten Speicherbank und einen zweiten Wert an einer zweiten physischen Adresse in einer zweiten Speicherbank zu beinhalten, wobei der erste Wert und der zweite Wert in derselben Spalte in einer logischen Speicheransicht der Tabelle beinhaltet sind. Beispielsweise kann eine Tabelle beliebig oft in den Speicher repliziert werden, um die Parallelität des Speicherzugriffs eines Systems auszunutzen. Die Tabelle kann einen ersten Wert an einer ersten logischen Adresse und einen zweiten Wert an einer zweiten logischen Adresse in derselben Spalte wie der erste Wert beinhalten, der, wenn er in dieser Konfiguration im Speicher gespeichert wird, zu Bankkonflikten führen kann, da die zwei Werte in dieselbe Speicherbank gespeichert werden können. Somit können die Schreibanweisungen beim Replizieren der Tabelle in den Speicher den ersten Wert an eine benachbarte erste physische Adresse - z. B. in einer anderen Speicherbank - als einen zweiten Wert schreiben, sodass die beiden Werte in demselben Zyklus abgerufen werden können.

Das Verfahren 600 beinhaltet bei Block B604 das Bestimmen eines ersten Index, der der ersten physischen Adresse im Speicher entspricht. Beispielsweise kann eine Leseoperation einen Index verwenden, der eine erste Stelle im Speicher angibt, von der aus mit dem Lesen von Werten begonnen werden soll.

Das Verfahren 600 beinhaltet bei Block B606 zumindest teilweise basierend auf einer Leseanweisung, die einer Mehrpunktabfrage entspricht, das Lesen des ersten Werts, der sich an der ersten physischen Adresse befindet, und des zweiten Werts an der zweiten physischen Adresse während eines einzelnen Zyklus. Wenn zum Beispiel eine Tabelle in den Speicher repliziert wird, kann die Tabelle so repliziert werden, dass Paare von Punkten, die sich in derselben Spalte oder einer Tabelle befinden (z. B. Pixeln in derselben Spalte von Pixeln entsprechen), in getrennten Speicherbanken gespeichert werden. Somit werden unter Verwendung einer Leseanweisung für eine Zwei-Punkt-Abfrage, die einen Index eines ersten Punkts des Punktpaars verwendet, um zu bewirken, dass der erste Punkt und ein benachbarter zweiter Punkt, der in einer anderen Speicherbank gespeichert ist, gelesen werden, wobei der erste Wert und der zweite Wert in einem einzelnen Zyklus aus einer ersten Speicherbank, die den ersten Wert speichert, und einer zweiten Speicherbank, die den zweiten Wert speichert, gelesen werden können. Diese Operation kann für jedes Wertepaar in jeder replizierten Tabelle durchgeführt werden, um einen hohen Vektor einschließlich der ersten Werte aus jeder Tabelle und einen niedrigen Vektor einschließlich der zweiten Werte aus jeder Tabelle zu erzeugen, und diese Vektoren können als Vektorregister in einer VPU verwendet werden, zusätzlich zu einem Befehl (z. B. Interpolation usw.), um Ausgaben zu generieren.

Das Verfahren 600 beinhaltet bei Block B608 das Durchführen einer oder mehrerer Operationen unter Verwendung des ersten Werts und des zweiten Werts. Beispielsweise können der erste Wert und der zweite Wert in eine oder mehrere Spuren einer VPU geladen werden und kann eine Quadratwurzel-, logarithmische, Sinus- und Cosinusfunktion ausgeführt werden, kann eine lineare oder bilineare Interpolation ausgeführt werden und/oder kann ein anderer Operationstyp ausgeführt werden. Wenn eine Interpolation durchgeführt wird und eine Tabelle beispielsweise 16 Mal repliziert wird, können 16 Zweipunkt-Abfrageoperationen stattfinden, um 32 Werte zu erzeugen - 2 Werte für jede Vektorspur einer VPU - und die Interpolation kann auf jeder Spur ausgeführt werden, um 16 Ergebnisse auszugeben. Somit können 16 interpolierte Ausgaben pro Zyklus unter Verwendung von nur 16-facher Replikation einer Tabelle erzeugt werden. Dies kann das Ergebnis der Verwendung einer Zwei-Punkt-Abfrage sein, da die Tabelle mit den Werten möglicherweise nur halb so oft repliziert werden muss (z. B. 16 Mal statt 32 Mal) wie bei herkömmlichen Einzelpunkt-Abfrageoperationen, um denselben 32-Wert-Durchsatz bei halbiertem Speicherbedarf zu ermöglichen.

LADE-CACHES PRO SPEICHERBANK IM VEKTORSPEICHER

In einem herkömmlichen Prozessor kann ein Daten-Cache eine Breite von beispielsweise 32 Bytes pro Cache-Zeile aufweisen. Eine Cache-Zeile ist eine Dateneinheit, die von der Hardware verfolgt wird. Zum Beispiel kann die Hardware die Nutzungsinformationen der Cache-Zeilen im Tag-Speicher verfolgen, einschließlich der vollständigen Systemadresse, ob die Cache-Zeile geschrieben wurde, wann die Cache-Zeile zuletzt relativ zu anderen Cache-Zeilen gelesen wurde, um zu bestimmen, wann die Cache-Zeile zu räumen ist usw. In einigen Implementierungen ist der Daten-Cache der lokale Speicher oder ein Teil des lokalen Speichers, um eine größere Datenstruktur, die vorübergehend im externen Speicher gespeichert ist, auf den lokalen Speicher abzubilden, sodass die Daten verarbeitet werden können, ohne lange Speicherlatenz bei der direkten Verarbeitung des externen Speichers zu erleiden. In herkömmlichen Desktop- oder Laptop-Computern werden Daten-Caches dieser Art häufig eingesetzt.

Ein programmierbarer Visionsbeschleuniger und/oder eine VPU beinhalten als nicht einschränkende Beispiele einen eingebetteten Prozessor, der zum Ausführen eines kleineren Satzes hochoptimierten Codes vorgesehen ist. In solchen Prozessortypen können Daten-Caches nicht implementiert werden, da Programmierer Inhalte im lokalen Datenspeicher verwalten können. Systeme und Verfahren der vorliegenden Offenbarung können lokalen Speicher beinhalten, der durch einen Programmierer verwaltet wird, anstatt zwischengespeichert zu werden, können aber auch eine zusätzliche Daten-Caching-Fähigkeit in einer oder mehreren - z. B. jeder - Speicherbank beinhalten. Die Daten-Caches können im Vergleich zu herkömmlicheren Daten-Caches, die beispielsweise 32 Bytes enthalten, schmal sein, beispielsweise ohne Einschränkung 16 Bits breit. Die Daten-Caches können hauptsächlich verwendet werden, um den Energieverbrauch zu reduzieren, im Gegensatz zu dem primären Ziel herkömmlicher Daten-Caches, das darin besteht, die Latenz zu reduzieren.

Bei der Computer-Vision-Verarbeitung zum Beispiel haben Datenzugriffsmuster oft einen gewissen Grad an Lokalität (verbleiben z. B. einige Zeit in einer Nachbarschaft, bevor sie sich in die nächste Nachbarschaft bewegen). Wenn beispielsweise eine 7x7-2D-Filterung unter Verwendung der hierin beschriebenen VFilt4HHW-Anweisung ausgeführt wird (die 4 Abgriffe gleichzeitig berechnet), kann der Datenlesestrom aus einer Nachbarschaft für drei Speicherlesevorgänge lesen und sich dann in eine andere Nachbarschaft bewegen und drei weitere Male lesen usw. Beim Koeffizientenlesevorgang der Operation kann ein gleiches Array von mit Nullen aufgefüllten Werten verwendet werden (z. B. 7*2*4 = 56 Halbwörter), wobei jeweils um vier Halbwörter vorgerückt wird, bis die letzte Gruppe von 4 Halbwörtern gelesen ist, und dann wird wieder vom Anfang des 56-Halbwort-Arrays gestartet, bis der Filter-Kernel abgeschlossen ist.

Um diese lokalen Zugriffsmuster vorteilhaft zu nutzen und den Energieverbrauch aufgrund von Speicherzugriffen zu reduzieren, kann somit ein Ladedaten-Caching in jeder Speicherbank mit Zweiwege-Satzassoziativität (das z. B. insgesamt 64 Halbwörter hält) implementiert werden. Wenn der Lade-Cache aktiviert ist, können die zuletzt gelesenen Sätze (z. B. die neuesten, die zwei neuesten, die drei neuesten usw.) von gelesenen Daten im Cache aufgezeichnet werden, ebenso wie die Reihenadressen und der zuletzt gelesene Eintrag im Tag-Speicher. Wenn dieselbe Speicheradresse erneut gelesen wird, kann folglich ein Cache-Treffer vorhanden sein, und der Cache kann die Daten liefern, anstatt zu verlangen, dass die Daten erneut aus dem lokalen Speicher gelesen werden. In Ausführungsformen kann sich der Lade-Cache zwischen Speicherprotokollierungslogik und dem Speicher selbst befinden, sodass immer dann, wenn ein Cache-Treffer auftritt, der Speicherlesevorgang für diese konkrete Adresse oder diesen konkreten Wert gestoppt wird oder nicht stattfindet, um Energie zu sparen.

Unter Verwendung dieser Cache-Struktur und in Bezug auf das vorstehende 7×7-2D-Filterungsbeispiel kann der Lade-Cache dem System ermöglichen, fast zwei Drittel der Datenlesevorgänge und fast alle Koeffizientenlesevorgänge im stationären Zustand zu überspringen. Eine Veranschaulichung der Verwendung des Daten-Caches in jeder Bank ist in den 7A-7C veranschaulicht. Beispielsweise kann eine VFilt4HHW-Anweisung 4 Abgriffe einer potenziell größeren Filter-Task ausführen und kann zwei einzelne Halbwortvektoren von Daten - z. B. Daten [0-15] und Daten [4-19] - und einen einzelnen Halbwortvektor von Koeffizienten - z. B. koef [0-3] - viermal wiederholt, um den 16-Elemente-Einzelvektor zu füllen, verbrauchen. In einer 7x7-2D-Filterimplementierung unter Verwendung der VFilt4HHW-Anweisung in beiden Vektormath.-Slots können die Elemente der Daten- und Koeffizienten-Arrays von 7A verwendet werden. Da die VPU der vorliegenden Offenbarung zum Lesen eines Doppelvektors konfiguriert sein kann, können daten[y][0-15] und daten[y][16-31] als Doppelvektor gelesen werden. In ähnlicher Weise können daten[y][4-19] und daten[y][20-35] und daten[y][8-23] und daten[y][24-39] als Doppelvektoren gelesen werden. Somit können die Daten- und Koeffizienten-Lesemuster denen der 7B-7C entsprechen, unter der Annahme, dass ein Zeilenabstand für die Daten 100 ist und der Zeilenabstand für die Koeffizienten 8 ist.

7D veranschaulicht eine Speicherbankorganisation. Zum Beispiel hält ein vollständig assoziatives Caching mit zwei Einträgen einen Zweistellenwert von Daten in jeder Superbank, und Daten und Koeffizienten können in unterschiedlichen Superbanken platziert werden, damit das Caching effektiv arbeiten kann. Bei Koeffizientenlesevorgängen können die Bänke 0-3 zuerst die Koeffizientenelemente 0-3 beibehalten und die Elemente 32-35 hinzufügen, und dann würden die Leseelemente 64-67 die Elemente 0-3 räumen, die in einem nächsten Koeffizientenlesevorgang erneut gelesen werden sollen, wenn das Muster wiederholt wird. Im stationären Zustand mit aktiviertem Lade-Cache können nur vier Bänke für jeden Durchlauf des Koeffizienten-Lesemusters gelesen werden. Als Ergebnis können die Speicherbank-Leseeinsparungen durch Verwendung eines Lade-Caches für Daten (3*32 - (32+4+4))/(3*32) = 58,3 % und für koef (14*16 - 4)/(14*16) = 98,2 % sein.

Somit kann der Lade-Cache in gewissen Algorithmen - wie Computer-Vision-Algorithmen mit gleitenden Fenstern - nützlich sein, um Energie zu sparen. Ohne einen Lade-Cache müsste beispielsweise jede Bank bei jedem Zyklus gelesen werden, obwohl viele der Daten gleich sind. In einem Beispiel, in dem 512 Bits bei jeder Iteration ausgelesen werden, können die ersten 512 Bits ausgelesen werden und dann können weitere 512 ausgelesen werden und so weiter. Wenn das gleitende Fenster beispielsweise nur 8 Bytes groß ist, dann sind nur 64 Bits bei jeder Iteration neu und die verbleibenden 448 Bits sind gleich. Ohne Daten-Cache müssten diese 448 Bits wieder aus den Datenbanken ausgelesen werden. Unter Verwendung eines Daten-Caches für jede Speicherbank können diese 448 Bits jedoch aus dem Lade-Cache entnommen werden, und nur die 64 neuen Bits müssten aus den anderen Speicherbanken ausgelesen werden. Dadurch wird die zum Lesen der 448 Bits aus den Speicherbanken benötigte Energie eingespart. Beispiele für Algorithmen, die von der Verwendung von Lade-Caches profitieren können, sind räumliche Filteroperationen, Deep-Learning-Inferenzoperationen (wie etwa Faltungsoperationen) und/oder dergleichen.

In Bezug auf 7E ist eine Hardwarearchitektur oder -logik für eine Speicherbank mit einem Lade-Cache veranschaulicht. Zum Beispiel können zur Unterstützung eines nicht ausgerichteten Zugriffs im Speicher (z. B. Vektorspeicher (VMEM)) Datenzugriffe mit gleitendem Fenster beschleunigt werden. Dies ist ein wichtiges Speicherzugriffsmuster für viele Computer-Vision-Algorithmen, einschließlich Filterung und Faltung. Für Vektorladevorgänge mit gleitendem Fenster bleiben die meisten Daten aus den Banken 702 des Direktzugriffsspeichers (RAM) gleich. In einem solchen Beispiel ändern sich nur 4 B an Daten in einem 64 B-Vektorladevorgang, wenn sie um 4 B verschoben werden, sodass nur 4 B an neuen Daten aus den RAM-Banken 702 gelesen werden. Um die Leistung für VMEM-RAMs zu optimieren, kann jeder Bank für jede Superbank ein winziger Cache namens „Lade-Cache“ hinzugefügt werden - also insgesamt 3 Superbänke × 32 Bänke = 96 Lade-Caches für jeden VMEM. Die Konfiguration jedes der Lade-Caches kann in nicht einschränkenden Ausführungsformen eine Zwei-Zeilen-Kapazität (2 × 2B = 4B), volle Assoziativität und eine Ersetzungsrichtlinie für „scheinbar am längsten nicht mehr verwendet“ (pseudo least recently used - pLRU) beinhalten.

Wenn die Daten-Caches die letzten Zugriffe speichern, sind sie in zwei Teile aufgeteilt - einen Tag-Speicher 706 und einen Datenspeicher 704. Im Tag-Speicher 706 können die zwischengespeicherten Adressen und Steuerinformationen, die früheren Zugriffen entsprechen, gespeichert werden, und im Datenspeicher 704 können die Daten von früheren Zugriffen gespeichert werden. Die Steuerinformationen im Tag-Speicher 706 können ein Gültig-Flag (z. B. ob der Eintrag gültig ist), ein Dirty-Flag (z. B. ob der Eintrag modifiziert wurde und in den Speicher zurückgeschrieben werden muss) und/oder ein Flag der letzten Verwendung (z. B. um anzugeben, welcher Eintrag ersetzt werden soll, wenn ein Eintrag durch eine Richtlinie für „am längsten nicht mehr verwendet“ ersetzt werden soll) beinhalten. Da der Cache ein Lade-Cache ist, können Schreibdaten den Cache nicht aktualisieren, aber die Gültig- und Letzte-Verwendung-Flags können im Tag-Speicher 706 beinhaltet sein. Das Gültig-Flag oder -Bit kann verwendet werden, um den Adressabgleich zu qualifizieren, und jeder Schreibvorgang sollte den Eintrag ungültig machen. Bei jedem Zugriff kann das Letzte-Verwendung-Flag aktualisiert werden.

Damit das Cache-Schema effektiv ist, ist die Speicherkapazität des Lade-Caches, wie hierin beschrieben, viel kleiner als die des Speichers oder der RAM-Bank 702, um Zugriffszeiten zu reduzieren und Energie zu sparen. In einer Ausführungsform kann jeder Lade-Cache einer einzelnen RAM-Bank 702 entsprechen, die RAM-Bänke 702 können jeweils 2048 × 16-Bit-Speicher sein und die Lade-Caches können jeweils 2 × 16 Bit-Datenspeicher 704 mit 23 Bits Tag-Speicher 706 sein (z. B. 2 Einträge × (11 Bit-Adresse + 1 Bit gültig) + 1 Bit letzte Verwendung)).

Im Betrieb können Offset 722, Zeilenadresse 724 und Inkrement 726 verwendet werden, um eine Speicheradresse für einen Speicherzugriff zu generieren. Diese Speicheradresse kann abgegriffen werden, um sie mit dem Tag-Speicher 706 zu vergleichen - z. B. um sie mit einer Anzahl von früheren Zugriffsadressen (z. B. 2 frühere Zugriffe) zu vergleichen. Der Pfeil nach oben in den Tag-Speicher 706 kann die Speicheradresse darstellen. In einigen Ausführungsformen kann die gesamte Speicheradresse durch den Tag-Speicher 706 verwendet werden, um sie mit den gespeicherten Speicheradressen von dem/den vorherigen Zugriff(en) zu vergleichen. In anderen Ausführungsformen kann eine Teilmenge von Adressenbits aus der Speicheradresse verwendet werden, um eine Teilmenge der Tags zu adressieren, sodass nur eine Teilmenge der Tags mit der Speicheradresse verglichen wird. Wenn beispielsweise eine größere Anzahl von Tags des früheren Zugriffs im Tag-Speicher 706 gespeichert ist, kann nur eine Teilmenge der Tags unter Verwendung einer Teilmenge der Speicheradressenbits verglichen werden, um Fläche zu reduzieren und Energie zu sparen. In Lade-Cache-Designs mit weniger Tags - wie beispielsweise Tags, die zwei früheren Zugriffen entsprechen - kann das gesamte Tag früherer Einträge mit der gesamten Speicheradresse verglichen werden. Der „==?“-Entscheidungsblock 720 vergleicht die aktuelle Speicheradresse für die RAM-Bank 702 mit den im Tag-Speicher 706 gespeicherten Adressen. Wenn es einen Fehlschlag gibt (z. B. ein Tag und eine Speicheradresse stimmen nicht überein), kann das Lesen der RAM-Bank 702 unter Verwendung der Lesefreigabe 708 aktiviert werden, und der Lesedatenmultiplexer (rd data mux) 712 und die RAM-Bank 702 können ausgewählt und ausgelesen werden, um sie an ein Zurückspeicherungs-Flop 716 zu senden. Wenn es einen Treffer gibt (z. B. eine Tag- und Speicheradressenübereinstimmung), kann der Datenspeicher 704 mit einer 0 oder 1 (in Ausführungsformen mit zwei Einträgen) adressiert werden, um anzugeben, welchem früheren Zugriff der Treffer entspricht. Der entsprechende Eintrag im Datenspeicher kann durch den Lesedatenmultiplexer 712 und an das Zurückspeicherungs-Flop 716 gesendet werden. Das Zurückspeicherungs-Flop 716 kann die zurückgelesenen Daten an die Prozessor-Pipeline zurückgeben, damit sie schließlich zu einem Ziel-Skalar- oder - Vektorregister der Ladeanweisung geroutet werden.

Das Zurückspeicherungs-Flop 714 kann der Paritätsprüfung entsprechen. Beispielsweise können Speicher erforderlich sein, die groß genug sind, um Paritätsbits aufzuweisen (z. B. in einem Paritätsterminal 710), um eine Fehlererkennung und/oder Fehlerkorrektur zu ermöglichen. In dem Speicher (z. B. VMEM) kann eine Fehlererkennung verwendet werden und/oder eine Fehlerkorrekturlogik kann an den zurückgelesenen Daten implementiert werden.

Somit kann der Lade-Cache Tag-Bits im Tag-Speicher 706 für weg0 und weg1 beinhalten, die jeweils 11 Adressenbits und ein Gültig-Bit mit 1 Bit beinhalten können. Der Lade-Cache kann ferner eine 1-Bit-pLRU und Datenbits im Datenspeicher 704 für weg0 und weg1 beinhalten, die jeweils 16 Datenbits und 2 Paritätsbits beinhalten. Die Lade-Caches können, wenn sie aktiviert sind, in der D1-Stufe abgefragt werden. Um den Energieverbrauch zu minimieren, kann nur der Lade-Cache für die RAM-Bänke 702 aktiviert werden, die an einem Ladevorgang teilnehmen. Zum Beispiel können für ein einzelnes Vektorladen nur 16 der 32 Lade-Caches abgefragt werden. Bei einem Ladetreffer (z. B. wenn der Lade-Cache die Daten beinhaltet, auf die zugegriffen werden soll) kann die Lesefreigabe für eine gegebene RAM-Bank 702 unterdrückt werden, wodurch ein Aufleuchten der RAM-Bank 702 verhindert wird. pLRU 720 kann auch in der D1-Stufe aktualisiert werden. In der D2-Stufe können die Daten und die Paritätsbits aus dem Lade-Cache-Trefferweg gelesen und mit dem RAM-Ergebnis gemultiplext werden.

Bei einem Lade-Cache-Fehlschlag kann in der D1-Stufe auf dem Opferweg ein bestehender Eintrag, der geräumt werden soll, um Platz für einen neuen Eintrag zu schaffen, basierend auf den gültigen Bits und der pLRU bestimmt werden. Das Tag für den Opferweg kann dann mit der Fehlschlagadresse aktualisiert werden und die Lesefreigabe 708 für die RAM-Bank 702 wird möglicherweise nicht unterdrückt. In der D2-Stufe werden die Daten/Parität von der RAM-Bank 702 nicht nur an die Lesedaten-Crossbar gesendet, sondern auch, um die Daten in die geräumte Cache-Zeile zu füllen. Speichervorgänge können auch die Lade-Caches abfragen, wenn sie aktiviert sind und teilnehmen. Ein Speichertreffer kann dazu führen, dass der Trefferweg ungültig gemacht wird, und Speicherfehlschläge können ignoriert werden.

Bei einem Treffer im Lade-Cache wird die Energie zum Lesen der RAM-Bänke 702 eingespart. Andererseits verbraucht ein Fehlschlag im Lade-Cache nicht nur Energie aus dem Lesen der RAM-Bänke 702, sondern verbraucht auch Energie, um den Lade-Cache abzufragen, um den Opferweg zu füllen. Da nicht alle Arten von Speicherzugriffsmustern hohe Trefferraten im Lade-Cache erzielen - insbesondere wenn auf die Superbank in indizierten Adressierungsmodi zugegriffen wird - können nur vektorlineare Ladevorgänge in den Lade-Caches abgefragt werden.

Alle Speichervorgänge können im Lade-Cache abgefragt werden, wenn dieser aktiviert ist, um sicherzustellen, dass die Lade-Caches niemals mit den Daten in den z. B. VMEM-RAM-Banken 702 asynchron sind. Für Anwendungen, die niedrige Trefferraten für Lade-Caches für eine gegebene Superbank erwarten, kann Software verwendet werden, um die Lade-Caches für die RAM-Bänke 702 für diese Superbank zu deaktivieren, um die Abfrageleistung des Speichers zu minimieren, wie nachstehend ausführlicher beschrieben.

Beispielsweise kann in einigen Ausführungsformen die Verwendung des Daten-Caches keinen Vorteil bieten. Beispielsweise ist bei Operationen, bei denen sich Zugriffsmuster nicht wiederholen, der Daten-Cache möglicherweise nicht nützlich, sodass das Durchführen einer zusätzlichen Task zum Überprüfen des Caches vor einem Lesevorgang Zeit und/oder Energie verschwenden kann, da die Datenbanken möglicherweise gelesen werden müssen, um auf die richtigen Daten zuzugreifen. Somit kann das Lade-Caching aktiviert oder deaktiviert werden, wodurch die Leistungseinbuße aufgrund von Zugriffsmustern verringert wird, bei denen die Lade-Cache-Fehlschlagrate hoch ist, aber auch die Verwendung des Lade-Cache für Zugriffsmuster ermöglicht wird, bei denen der Daten-Cache verwendet werden kann, um Energie sparen. In einigen Ausführungsformen kann das Aktivieren oder Deaktivieren unter Verwendung von Anwendungscode programmiert werden, sodass der Programmierer den Code programmieren kann, um den Daten-Cache zu aktivieren, wenn dies erwünscht ist, und den Daten-Cache zu deaktivieren, wenn dies nicht erwünscht ist. In anderen Ausführungsformen kann das Aktivieren oder Deaktivieren durch Hardware ausgeführt werden, die die Lesemuster analysiert und ein überlappendes Muster erkennt. Zum Beispiel kann die Hardware für einen Überlappungsschwellenwert zwischen aufeinanderfolgenden Leseoperationen den Lade-Cache aktivieren. Wenn die Überlappung jedoch kleiner als der Schwellenwert bzw. die Schwellenwerte ist, können die Lade-Caches deaktiviert werden. Der Schwellenwert kann, als nicht einschränkende Beispiele, 25 %, 40 %, 50 %, 75 % oder ein anderer Schwellenbetrag der Überlappung zwischen Lesevorgängen sein.

Wenn die Lade-Caches deaktiviert sind, und in Bezug auf 7E, kann auf den Tag-Speicher 706 nicht zugegriffen werden, und die Lesefreigabe 708 kann so gesetzt werden, dass Lesevorgänge in die RAM-Bank 702 für jeden Lesevorgang freigegeben werden. Auf ähnliche Weise kann auf den Datenspeicher 704 nicht zugegriffen werden, und der Lesedatenmultiplexer 712 kann die Daten der RAM-Bank 702 immer an das Zurückspeicherungs-Flop 716 weiterleiten.

Ferner kann die Speicherbankstruktur in einigen Ausführungsformen eine Vielzahl von Superbanken - z. B. drei Superbänke - beinhalten, und die einzelnen Superbänke können abhängig von den konkreten Zugriffsmustern innerhalb jeder Superbank die Lade-Caches aktiviert oder deaktiviert haben. Wenn beispielsweise drei Superbänke verwendet werden, kann jede Superbank 32 RAM-Speicherbanken beinhalten, und der Daten-Cache für jede Speicherbank kann zwei Einträge beinhalten, wobei jeder Eintrag ein Wort ist, also 16 Bits. Wenn zwei oder mehr Superbanken verwendet werden, können die Superbanken jede Größe, unterschiedliche Größen, dieselbe Größe oder eine Kombination davon aufweisen. Beispielsweise kann eine erste Superbank 128 KB groß sein, kann eine zweite Superbank 256 KB groß sein und kann eine dritte Superbank 512 KB groß sein.

Unter Bezugnahme nun auf 7F umfasst jeder Block des hierin beschriebenen Verfahrens 750 einen Rechenprozess, der unter Verwendung einer beliebigen Kombination von Hardware, Firmware und/oder Software durchgeführt werden kann. Beispielsweise können verschiedene Funktionen durch einen Prozessor ausgeführt werden, der im Speicher gespeicherte Anweisungen ausführt. Das Verfahren 750 kann zudem als computerverwendbare Anweisungen verkörpert sein, die auf Computerspeichermedien gespeichert sind. Die Verfahren 750 kann durch eine eigenständige Anwendung, einen Dienst oder einen gehosteten Dienst (eigenständig oder in Kombination mit einem anderen gehosteten Dienst) oder ein Plug-in zu einem anderen Produkt bereitgestellt werden, um nur einige zu nennen. Das Verfahren 750 kann zusätzlich durch ein beliebiges System, eine beliebige Struktur oder Komponente oder eine beliebige Kombination von Systemen, Strukturen oder Komponenten ausgeführt werden, einschließlich, jedoch nicht beschränkt auf die hierin beschriebenen.

7F ist ein Flussdiagramm, das ein Verfahren 750 zum Verwenden von Daten-Caches für Leseoperationen gemäß einigen Ausführungsformen der vorliegenden Offenbarung zeigt. Das Verfahren 750 beinhaltet bei Block B702 das Empfangen von Daten, die für eine Speicherleseadresse repräsentativ sind. Beispielsweise kann nach einer ersten Leseoperation unter Verwendung einer gewissen Anzahl von Speicherbanken eine zweite Leseoperation ausgeführt werden, die eine oder mehrere der Speicherbanken zusätzlich zu einer oder mehreren zusätzlichen oder anderen Speicherbanken beinhaltet. Da die erste Leseoperation das Speichern der Ausgaben des Lesevorgangs in dem Daten-Cache entsprechend jeder jeweiligen Speicherbank beinhalten kann, können diese Werte wiederverwendet werden, anstatt einen weiteren Lesevorgang der Speicherbank zu erfordern. Somit kann die Speicherleseadresse entsprechend einer nächsten Leseoperation empfangen werden, und auf die Lade-Caches - wenn aktiviert - kann zugegriffen werden, um zu bestimmen, ob beliebige der Daten in den Lade-Caches gespeichert sind.

Das Verfahren 750 beinhaltet bei Block B704 das Vergleichen der Speicherleseadresse mit einer Lade-Cachespeicheradresse, die einem früheren Speicherlesevorgang entspricht, der in dem Lade-Cache gespeichert ist. Zum Beispiel können nach einem vorherigen Speicherlesevorgang die Daten aus dem Speicherlesevorgang in dem Lade-Cache gespeichert werden, der der konkreten RAM-Bank 702 entspricht. Um diese Informationen abzuspeichern, kann der Tag-Speicher 706 die Speicheradresse beinhalten, die einem oder mehreren vorherigen Lesevorgängen aus der RAM-Bank 702 entspricht.

Das Verfahren 750 beinhaltet bei Block B706 das Bestimmen, dass die Speicherleseadresse zumindest teilweise mit der Lade-Cachespeicheradresse überlappt. Beispielsweise kann die Speicherleseadresse mit der vorherigen Speicherleseadresse eines vorherigen Lesevorgangs verglichen werden, wie sie im Tag-Speicher 706 gespeichert ist. Wenn es einen Treffer gibt, kann der Lade-Cache verwendet werden, um zumindest einige der Daten auszulesen, die der Speicherleseadresse für den aktuellen Speicherlesevorgang entsprechen.

Das Verfahren 750 beinhaltet bei Block B708 das Lesen mindestens eines Abschnitts von Daten, der der Speicherleseadresse entspricht, aus dem Lade-Cache. Beispielsweise kann aufgrund des Treffers im Lade-Cache, wie vom Tag-Speicher 706 bestimmt, der Abschnitt der Daten aus den überlappenden Speicheradressen aus dem Lade-Cache ausgelesen werden, und der Rest der Daten - falls vorhanden - kann aus der RAM-Bank 702 ausgelesen werden.

ENTKOPPELTE KONFIGURIERBARE BESCHLEUNIGER

Um die Leistung von Prozessoren für spezifische Anwendungen - wie etwa Echtzeitanwendungen - zu optimieren, kann eine Anweisungssatzarchitektur (ISA) verbessert werden, um benutzerdefinierte Anweisungen zu erstellen, um häufig auftretende Operationen zu beschleunigen. Dadurch kann der Prozessor die Anzahl der Zyklen verringern, die zum Ausführen einer konkreten Task erforderlich sind. Der Prozess des Anpassens einer ISA wird durchgeführt, bis die Leistungsziele des Systems erreicht sind. Diese neuen Anweisungen werden jedoch hinzugefügt, um mit Daten entweder in der Prozessorregisterdatei oder direkt als Speicher als Operand zu arbeiten, die unter Verwendung der vorhandenen Prozessorsteuerung sowie der vorhandenen Speicheradressierungs- und Zugriffshardware ausgeführt werden. In solchen Beispielen ist es wünschenswert, dass die neuen Anweisungen in die Registerdatei-Lese-/Schreib-Operandenzählungen des Prozessors passen (z. B. um vorhandene Ports wiederzuverwenden), in die Breite der Registerdatei passen (z. B. in die Datentypen des Prozessors passen) und in die Prozessor-Pipeline-Stufen passen. Aufgrund dieser Anforderungen für das erfolgreiche Hinzufügen von Anweisungen zur ISA ist die Flexibilität beim Hinzufügen neuer Anweisungen begrenzt. Wenn eine ISA zum Verarbeiten von Pipelines erstellt wird, die viele Stufen (z. B. 30, 40, 50 usw. Stufen) sind, wird die Konfiguration der ISA außerdem komplex.

Darüber hinaus bieten Prozessoren ein hohes Maß an Flexibilität auf Kosten der Energieaufnahme - da jede hinzugefügte Anweisung abgerufen, decodiert/versendet, aus Registerdateien und/oder Speicher gelesen bzw. in diese geschrieben werden muss und so weiter. Somit erhöht das Hinzufügen zusätzlicher Funktionseinheiten zum Implementieren dieser benutzerdefinierten Anweisungen den Druck auf die Lese-/Schreibports der Registerdatei, was zu einer Erhöhung der erforderlichen Fläche (z. B. können zusätzliche Lese-/Schreibports erforderlich sein) und der Leistung (z. B. kann zusätzliches Laden an Registerdateien realisiert werden) führt. Außerdem weisen Verarbeitungspipelines für eingebettete Anwendungen im Allgemeinen mehrere Stufen auf - wobei die Ausgabe einer Stufe die Eingabe einer nächsten Stufe zuführt. Techniken wie das Ausführen mehrerer Threads (z. B. für unterschiedliche Verarbeitungsstufen) in einem Prozessor können die Verlängerungszeit verringern und dadurch eine verringerte Latenz bereitstellen. Multithreading geht jedoch zu Lasten der Hardware - es müssen Anweisungen von mehreren Threads abgerufen/decodiert/versendet werden, die Zustandsinformationen (z. B. in Registerdateien) für jeden Zustand jedes Threads erhalten werden und Steuerlogik für die Handhabung mehrerer Threads im Prozessor beinhaltet sein. Dies führt zu erhöhten Flächen- und Energieanforderungen, während der Prozessor komplexer zu verifizieren und zu programmieren ist. Obwohl es verschiedene Verfahren zum Verringern der Latenz in Verarbeitungspipelines gibt, erfordern die bestehenden Verfahren somit einen zusätzlichen Flächenbereich für die Prozessorhardware, erfordern einen zusätzlichen Energieverbrauch aufgrund der zusätzlichen Hardware und erhöhen die Komplexität der Programmierung der Prozessoren zur Ausführung der verschiedenen Tasks.

Um den Beschränkungen von primären Prozessorkonfigurationen und den Mängeln eines Multithread-Prozessors Rechnung zu tragen, verwenden die Systeme und Verfahren der vorliegenden Offenbarung eine oder mehrere Einheiten eines Primär- oder Hauptprozessors - wie etwa eines Singlethread-Prozessors wie einer VPU - zusätzlich zu domänenspezifischen Beschleunigern oder Koprozessoren, die vom Hauptprozessor entkoppelt sind und mit dem Hauptprozessor über gemeinsam genutzten Speicher - wie etwa einen Vektorspeicher (VMEM) - kommunizieren. Somit können die Beschleuniger als Teileinheiten des Hauptprozessors bzw. der Hauptprozessoren arbeiten, aber anstatt Prozessoranweisungen zur Ausführung zu benötigen, können die Beschleuniger, sobald sie konfiguriert sind, unabhängig von den Anweisungen des Hauptprozessors bzw. der Hauptprozessoren ausgeführt werden. Beispielsweise können Beschleunigerzugriffsanweisungen verwendet werden, um dem/den Hauptprozessor(en) zu ermöglichen, die Beschleuniger zu konfigurieren und zu sequenzieren, und der gemeinsam genutzte Speicher kann ermöglichen, dass Datenstrukturen zwischen den Stufen zwischen dem/den Hauptprozessor(en) und dem/den Beschleuniger(n) gemeinsam genutzt werden. Sobald der/die Hauptprozessor(en) den Beschleuniger startet oder starten (z. B. über eine gemeinsame Beschleunigerschnittstelle und unter Verwendung einer oder mehrerer Lade-/Speicheranweisungen), steht es dem/den Hauptprozessor(en) frei, entweder eine andere Stufe zu verarbeiten (und dadurch die Fähigkeit bereitzustellen, gleichzeitig mit reduzierter Laufzeit an mehreren Stufen einer Verarbeitungspipeline zu arbeiten) oder in einen Zustand mit niedrigem oder niedrigstem Energieverbrauch zu wechseln, in dem darauf gewartet wird, dass der/die Beschleuniger die Verarbeitung abschließt/abschließen (z. B. um den Energieverbrauch zu minimieren, wenn keine aktive Verarbeitung erfolgt). Somit kann jeder der einen oder mehreren Beschleuniger, sobald er durch den/die Hauptprozessor(en) konfiguriert ist, unabhängig und gleichzeitig mit dem/den Hauptprozessor(en) arbeiten. Der/die Hauptprozessor(en) und der/die Beschleuniger können sich während der Verarbeitung über eine Handshake-Schnittstelle synchronisieren, sodass der/die Hauptprozessor(en) wissen, wann der/die Beschleuniger die Verarbeitung beendet hat/haben und/oder für eine neue Task bereit ist/sind oder umgekehrt. Der gemeinsam genutzte Speicher kann Konfigurationsnachrichten (z. B. zum Konfigurieren des Beschleunigers/der Beschleuniger, wenn die Konfigurationsanweisungen aufgrund von Größenbeschränkungen nicht so effizient über die Beschleunigerschnittstelle gesendet werden), Eingabepuffer (z. B. zum Speichern der Daten zur Verarbeitung durch den/die Beschleuniger) und/oder Ausgabeergebnisse für den/die Beschleuniger (z. B. nachdem die Verarbeitung abgeschlossen ist, können die Daten von z. B. Registerdateien des Beschleunigers/der Beschleuniger zurück in den gemeinsam genutzten Speicher an einer Stelle gespeichert werden, die in den Konfigurationsanleitungen des Hauptprozessors/der Hauptprozessoren angegeben sind) speichern. Somit können der/die Beschleuniger nach dem Auslösen aus dem gemeinsam genutzten Speicher Konfigurationsparameter und/oder Eingabedatenstrukturen lesen und die Ausgangsergebnis-Datenstrukturen in den gemeinsam genutzten Speicher schreiben.

Infolgedessen ermöglicht dieses kombinierte System aus Hauptprozessor(en), gemeinsam genutztem Speicher und entkoppeltem/entkoppelten Beschleuniger(n) die Flexibilität des/der programmierbaren Hauptprozessor(en), während Energieverbrauchsniveaus von Hardware mit fester Funktion erreicht werden (z. B. da stark rechnergestützte Verarbeitungsstufen einer Verarbeitungspipeline als Beschleuniger implementiert werden können), ohne dass eine wesentliche Erhöhung der Komplexität des Hauptprozessors bzw. der Hauptprozessoren erforderlich ist (z. B. weil der Hauptprozessor bzw. die Hauptprozessoren möglicherweise nur eine zusätzliche Beschleunigerkonfiguration oder Zugriffsanweisungen zum Programmieren des/der Beschleunigers benötigen). Beispielsweise können die Pipeline- und Datentypen (z. B. Datenbreiten) des/der Beschleuniger unabhängig von denen des Hauptprozessors/der Hauptprozessoren sein, was eine weitere individuelle Anpassung und Optimierung ermöglicht, die mit einem oder mehreren Hauptprozessoren allein nicht möglich ist, was erfordert, dass Anweisungen in die Registerdatei-Lese-/Schreib-Operandenzahlen, die Registerdateibreite und die Pipeline-Stufen passen.

In einigen Ausführungsformen können der/die Beschleuniger und der/die Hauptprozessor(en) bei der Anweisungsausführung gekoppelt sein, um etwas von der Energieeinsparung eines Beschleunigers zu realisieren, während die Ausführung mit der Hauptprozessor-Pipeline gekoppelt wird. In solchen Ausführungsformen würde jedoch die Fähigkeit, unterschiedliche Stufen einer Pipeline gleichzeitig zu verarbeiten, reduziert, da die Anweisungen zwischen dem/den Beschleuniger(n) und dem/den Hauptprozessor(en) verschachtelt wären. In einer oder mehreren Ausführungsformen können der/die Beschleuniger und der/die Hauptprozessor(en) anstatt über einen gemeinsamen Speicher verbunden zu sein, durch einen Speicher der zweiten Ebene (L2) auf höherer Ebene gekoppelt sein. In solchen Ausführungsformen kann jedoch die höhere Ebene der Entkopplung (z. B. das Entfernen der Kopplung durch den gemeinsam genutzten Speicher zu einer höheren Ebene) den Kommunikationsaufwand mit dem/den Hauptprozessor(en) erhöhen.

Die entkoppelten Beschleuniger können für jede Task innerhalb einer beliebigen Domain verwendet werden, wie etwa als nicht einschränkende Beispiele zum Durchführen von 1D-, 2D-Abfragevorgängen usw. als ein entkoppelter Lookup-Tabellen-Beschleuniger zum Erkennen und Auflösen von Bankkonflikten, zum Durchführen einer 1 D/2D-Interpolation und /oder dergleichen, für Computer-Vision-Algorithmen wie Merkmalsnachverfolgung, Objektnachverfolgung, Bildverzerrung, Pyramidenerstellung und/oder dergleichen, zur Sensorverarbeitung wie etwa Matrixmultiplikation oder andere Operationen an LiDAR-Daten, RADAR-Daten und/oder dergleichen und/oder für maschinelles Lernen oder Deep-Learning-Anwendungen. Somit kann die hierin beschriebene Topologie auf jede Verarbeitungspipeline angewendet werden, bei der ein Teil der Verarbeitung an einen Beschleuniger ausgelagert werden kann.

Abhängig von der Implementierung kann es eine beliebige Anzahl entkoppelter Beschleuniger auf einem oder mehreren Chips geben, die über einen gemeinsam genutzten Speicher mit einem oder mehreren Hauptprozessoren kommunizieren. Beispielsweise kann ein System auf einem Chip (SoC) oder eine andere integrierte Schaltung (IC) den/die Hauptprozessor(en) und einen oder mehrere Beschleuniger beinhalten, und Programmierer können sich der verschiedenen Beschleuniger bewusst sein und Anweisungen oder Code schreiben, die diese Beschleuniger verwenden, die die Leistung für verschiedene Tasks des Systems erhöhen können. Obwohl der Hauptprozessor bzw. die Hauptprozessoren hauptsächlich als VPU beschrieben werden, soll dies nicht einschränkend sein, und der Hauptprozessor kann jeden Prozessortyp beinhalten, wie etwa eine CPU, GPU, DPU oder einen anderen Prozessor, ohne vom Umfang der vorliegenden Offenbarung abzuweichen.

Bezugnehmend nun auf 8A veranschaulicht 8A ein System 800 mit einem oder mehreren entkoppelten Beschleunigern gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Es versteht sich, dass diese und andere hierin beschrieben Anordnungen nur als Beispiele aufgeführt werden. Andere Anordnungen und Elemente (z. B. Maschinen, Schnittstellen, Funktionen, Befehle, Gruppierungen von Funktionen usw.) können zusätzlich oder anstelle der gezeigten verwendet werden, und einige Elemente können ganz weggelassen werden. Ferner sind viele der hierin beschriebenen Elemente funktionale Einheiten, die als diskrete oder verteilte Komponenten oder in Verbindung mit anderen Komponenten und in jeder geeigneten Kombination und Position implementiert werden können. Verschiedene hierin als von Einheiten ausgeführt beschriebene Funktionen können durch Hardware, Firmware und/oder Software ausgeführt werden. Beispielsweise können verschiedene Funktionen durch einen Prozessor ausgeführt werden, der im Speicher gespeicherte Anweisungen ausführt. In einigen Ausführungsformen kann das System 800 in ähnlichen Komponenten, Merkmalen und/oder Funktionen wie die des beispielhaften autonomen Fahrzeugs 1300 der 13A-13D, der beispielhaften Rechenvorrichtung 1400 der 14 und/oder des beispielhaften Rechenzentrums 1500 der 15 beinhaltet sein und/oder kann diese beinhalten.

Das System 800 kann einen oder mehrere Prozessoren 802 (z. B. einen Hauptprozessor), wie etwa eine VPU, CPU, GPU, DPU usw., einen oder mehrere entkoppelte Beschleuniger 804 und/oder einen gemeinsam genutzten Speicher 806 (z. B. Vektorspeicher oder VMEM) beinhalten. Der/die Prozessor(en) 802 kann/können mit einem Anweisungs-Cache (I-Cache) 810 gekoppelt sein, der Befehle für den/die Prozessor(en) 802 zur Ausführung zwischenspeichern kann. Der/die Prozessor(en) 802 kann/können einen Mehrzweckeingang/-ausgang (General Purpose Input/Output - GPIO) 808 (z. B. einen digitalen Signalstift auf der IC, der als Eingang, Ausgang oder beides verwendet werden kann und zur Laufzeit steuerbar sein kann) und einen IC-Konfigurator 812 beinhalten. In einigen Ausführungsformen kann/können, wie dargestellt, der/die Prozessor(en) 802 chipintern unter Verwendung einer fortschrittlichen erweiterbaren Schnittstelle (Advanced Extensible Interface - AXI) kommunizieren, wie etwa, ohne Einschränkung, einer 256-Bit-AXI-Schnittstelle. Der IC-Konfigurator 812 kann verwendet werden, um das System 800 zu konfigurieren.

Der/die Prozessor(en) 802 kann/können mit dem/den entkoppelten Beschleuniger(n) 804 direkt kommunizieren - z. B. über eine Coprozessor- oder Beschleunigerschnittstelle, wie etwa eine erweiterte Peripheriebus(Advances Peripheral Bus - APB)-Schnittstelle, und/oder einen Handshake, eine Programmierung oder eine Ereignisschnittstelle. Beispielsweise kann/können der/die Prozessor(en) 802 den/die Beschleuniger 804 unter Verwendung der Beschleunigerschnittstelle (oder des Konfigurationsbusses) konfigurieren, die Verarbeitung des/der Beschleuniger/s 804 unter Verwendung der Ereignisschnittstelle starten oder auslösen und mit dem/den Beschleuniger(n) 804 unter Verwendung der Handshake- oder Ereignisschnittstelle synchronisieren. Somit kann jeder Beschleuniger 804 einen Mechanismus beinhalten, der für die Kommunikation mit dem/den Prozessor(en) 802 über eine entsprechende Beschleunigerschnittstelle oder einen entsprechenden Konfigurationsbus konfiguriert werden soll. Wenn beispielsweise die Verarbeitung abgeschlossen ist, können der/die Beschleuniger 804 dies dem/den Prozessor(en) 802 über den Handshake-Mechanismus angeben, oder wenn der/die Prozessor(en) 802 darauf warten, dass der/die Beschleuniger 804 die Verarbeitung beenden, kann/können der/die Prozessor(en) 802 den/die Beschleuniger 804 periodisch abfragen, um einen Status oder eine Endzeit anzufordern. In einigen Ausführungsformen kann die Beschleunigerschnittstelle eine 32-Bit-Schnittstelle (oder eine andere kleinere Schnittstelle) beinhalten, sodass Konfigurationsanweisungen an den/die Beschleuniger 804 übertragen werden können. Jedoch kann/können die Konfigurationsnachricht(en) in einigen Ausführungsformen groß sein (z. B. größer als 32 Bits oder ein Vielfaches davon), und die Konfigurationsnachricht(en) kann/können stattdessen im gemeinsam genutzten Speicher 806 gespeichert werden, und die Stelle der Konfigurationsinformationen im Speicher 806 können über die Beschleunigerschnittstelle an den/die Beschleuniger 804 gesendet werden, um anzugeben, wo die Konfigurationsinformationen abzurufen sind.

Der Konfigurationsbus kann somit den/die Beschleuniger 804 konfigurieren und die Ereignis- (oder Programmierschnittstelle) kann verwendet werden, um dem/den Prozessor(en) 802 zu ermöglichen, die Verarbeitung durch den/die Beschleuniger 804 auszulösen oder zu starten. Einmal ausgelöst oder gestartet, kann/können der/die Beschleuniger 804 alleine arbeiten, wobei der/die Prozessor(en) 802 darauf warten, dass die Verarbeitung abgeschlossen wird, und/oder eine andere Verarbeitungstask oder -stufe ausführen. Beispielsweise kann ein Anwendungsprogrammierer den/die Prozessor(en) 802 und den/die Beschleuniger 804 mit Wissen darüber programmieren, wozu jeder fähig ist, sodass das Anwendungsprogramm in Teile aufgeteilt werden kann - einige Teile für den/die Prozessor(en) 802 und einige Teile für den/die Beschleuniger 804. Die Verarbeitung kann somit in Ausführungsformen parallel zwischen dem/den Prozessor(en) 802 und dem/den Beschleuniger(n) 804 ausgeführt werden, um die Laufzeit zu verringern und die Effizienz zu erhöhen. Eine Konfigurationsnachricht - über die Beschleunigerschnittstelle und/oder über den gemeinsam genutzten Speicher 806 geteilt - kann durch den/die Prozessor(en) 802 generiert und verwendet werden, um dem/den Beschleuniger(n) 804 anzugeben, wo die zu verarbeitenden Daten im gemeinsam genutzten Speicher 806 starten, wie viele Daten zu verarbeiten sind und wohin die Ergebnisse in den gemeinsam genutzten Speicher 806 zurückzuschreiben sind. Der/die Prozessor(en) 802 kann/können einen Eingabepuffer in dem gemeinsam genutzten Speicher 806 an der spezifizierten Stelle generieren, der die Daten für den/die Beschleuniger 804 beinhaltet, um damit zu arbeiten. Sobald die Konfigurationsnachricht übertragen und der/die Eingangspuffer im gemeinsam genutzten Speicher 806 gespeichert ist/sind, kann/können der/die Beschleuniger 804 ein Auslösesignal von dem/den Prozessor(en) 802 über die Ereignisschnittstelle (z. B. eine Programmierschnittstelle) empfangen und der/die Beschleuniger 804 können die Daten verarbeiten. Sobald der/die Beschleuniger 804 ausgelöst wurde(n), kann/können der/die Prozessor(en) 802 dann andere Arbeiten ausführen oder in einen Niedrigleistungszustand eintreten, und sobald der/die Beschleuniger 804 die Verarbeitung beendet hat/haben, können der/die Beschleuniger 804 dies dem/den Prozessor(en) 802 angeben und auf zusätzliche Arbeit warten.

Der/die Prozessor(en) 802 kann/können die Eingabepuffer oder Eingabedatenstrukturen für den/die Beschleuniger 804 zur Verarbeitung einrichten und diese im Speicher 806 speichern. Der/die Beschleuniger 804 kann/können unter Verwendung von Lade-/Speicheroperationen durch den/die Prozessor(en) 802 konfiguriert werden, die speziell dazu dienen, den/die Beschleuniger 804 zu konfigurieren und mit ihnen zu kommunizieren. Die Konfigurationsnachricht kann die verschiedenen Register (z. B. 256 32-Bit-Register in einer Ausführungsform) des Beschleunigers/der Beschleuniger 804 konfigurieren. Zum Beispiel können die Konfigurationsinformationen für einen entkoppelten Lookup-Tabellenbeschleuniger (wie hierin ausführlicher beschrieben) angeben, ob die Abfrage für eine 1 D-Abfrage mit Interpolation, eine 2D-Abfrage mit bilinearer Interpolation und/oder eine andere Art von Abfrage dient. Sobald der/die Beschleuniger 804 den konkreten Modus oder die konkrete Funktion kennen, können sie die Register konfigurieren, um die Daten richtig aus dem Speicher 806 zu lesen, zu verarbeiten und die Daten zurück in den Speicher 806 zu schreiben.

In einigen Ausführungsformen kann/können der/die Prozessor(en) 802 den/die Beschleuniger 804 konfigurieren, um mehrere Tasks gleichzeitig auszuführen, um die Effizienz zu steigern. Wenn beispielsweise der/die Beschleuniger 804 verschiedene kleinere Tasks durchführen sollen, kann das individuelle Konfigurieren des/der Beschleuniger 804 die Laufzeit verlängern, da jede Task schnell abgeschlossen werden kann, wodurch der/die Prozessor(en) 802 die Verarbeitung stoppen, den/die Beschleuniger 804 für eine andere Taks konfigurieren muss/müssen und so weiter. Dazu kann eine erste Task-Nachricht eine Adresse zu einer zweiten Task-Nachricht beinhalten, was eine Selbstverkettung mehrerer Tasks ermöglicht. Somit kann/können der/die Prozessor(en) 802 Konfigurationsnachrichten für eine Vielzahl von Tasks auf einmal generieren und die Konfigurationsinformationen und die Eingabepuffer für jede Task generieren, sodass der/die Beschleuniger 804 die verschiedenen Tasks nacheinander durchführen kann/können, bevor dem/den Prozessor(en) 802 angegeben wird, dass die Verarbeitung abgeschlossen ist und dass der/die Beschleuniger 804 bereit ist/sind, mehr Arbeit zu empfangen. Um die Effizienz zu steigern, kann/können der/die Beschleuniger 804 ferner konfiguriert sein, Tasks zu überlappen, sodass, wenn eine erste Aufgabe kurz vor dem Abschluss steht, der/die Beschleuniger 804 damit beginnen kann/können, die nächste Task zu decodieren und die Register für die nächste Task zu konfigurieren. Letztendlich können der/die Beschleuniger 804 dadurch, dass er/sie getrennte Anweisungen für den/die Prozessor(en) 802 und den/die Beschleuniger 804 beinhaltet/beinhalten, in der Lage sein, mit Datenformaten oder -typen zu arbeiten, die anders sind, als der/die Prozessor(en) 802 ansonsten unterstützen würde(n). Dies kann darauf zurückzuführen sein, dass die Architektur und das Layout der Register des Beschleunigers bzw. der Beschleuniger 804 unterschiedlich und für bestimmte Verarbeitungs-Tasks spezialisiert sind.

In Ausführungsformen kann/können der/die Prozessor(en) 802 mit dem gemeinsam genutzten Speicher 806 über eine beliebige Anzahl von Speicherschnittstellen (z. B. statische 512-Bit-Random-Access-Memory(SRAM)-Schnittstellen) kommunizieren. In ähnlicher Weise können der/die Beschleuniger 804, wie veranschaulicht, mit dem gemeinsam genutzten Speicher 806 über eine beliebige Anzahl von Speicherschnittstellen (z. B. eine 512-Bit-SRAM-Schnittstelle) kommunizieren. Der Arbiter 814 kann für jeden Zyklus entscheiden, welcher der Prozessoren 802 und/oder Beschleuniger 804 auf den gemeinsam genutzten Speicher 806 zugreifen darf.

Bezugnehmend nun auf 8B umfasst jeder hierin beschriebene Block des Verfahrens 850 einen Rechenprozess, der mit einer beliebigen Kombination aus Hardware, Firmware und/oder Software durchgeführt werden kann. Beispielsweise können verschiedene Funktionen durch einen Prozessor ausgeführt werden, der im Speicher gespeicherte Anweisungen ausführt. Das Verfahren 850 kann auch als computerverwendbare Anweisungen dargestellt werden, die auf Computerspeichermedien gespeichert sind. Die Verfahren 850 kann durch eine eigenständige Anwendung, einen Dienst oder einen gehosteten Dienst (eigenständig oder in Kombination mit einem anderen gehosteten Dienst) oder ein Plug-in zu einem anderen Produkt bereitgestellt werden, um nur einige zu nennen. Desweiteren wird das Verfahren 850 in Bezug auf das System 800 der 8A beschrieben, aber das Verfahren 850 kann durch ein beliebiges System, eine beliebige Struktur oder Komponente oder eine beliebige Kombination von Systemen, Strukturen oder Komponenten ausgeführt werden, einschließlich, jedoch nicht beschränkt auf die hierin beschriebenen.

8B ist ein Flussdiagramm, das ein Verfahren 850 zum Verwenden von entkoppelten Beschleunigern gemäß einigen Ausführungsformen der vorliegenden Offenbarung zeigt. Das Verfahren 850 beinhaltet bei Block B802 das Empfangen von Konfigurationsinformationen für eine oder mehrere erste Verarbeitungs-Tasks einer Verarbeitungspipeline. Beispielsweise kann/können der/die Beschleuniger 804 Konfigurationsinformationen (z. B. eine Konfigurationsnachricht über die Beschleunigerschnittstelle) von dem/den Prozessor(en) 802 empfangen.

Das Verfahren 850 beinhaltet bei Block B804 das Konfigurieren eines oder mehrerer Register des Beschleunigers zumindest teilweise basierend auf den Konfigurationsinformationen. Beispielsweise können der/die Beschleuniger 804 ein oder mehrere Register basierend auf den Konfigurationsinformationen konfigurieren.

Das Verfahren 850 beinhaltet bei Block B806 das Lesen von Daten aus einem Eingabepuffer in dem Speicher zumindest teilweise basierend auf einer Angabe einer Anfangsstelle des Eingabepuffers, die in den Konfigurationsinformationen beinhaltet ist. Beispielsweise können die Konfigurationsinformationen eine Angabe darüber beinhalten, wo im Speicher 806 ein Eingabepuffer gespeichert ist, und der/die Beschleuniger 804 können die Daten aus dem Eingabepuffer in die Register lesen.

Das Verfahren 850 beinhaltet bei Block B808 das Verarbeiten der Daten aus dem Eingabepuffer, um Ausgabedaten zu berechnen. Beispielsweise können der/die Beschleuniger 804 die Daten aus den Eingabepuffern verarbeiten, um Ausgaben zu generieren oder zu berechnen.

Das Verfahren 850 beinhaltet bei Block B810 das Schreiben der Ausgabedaten in den Speicher an einer Stelle, die zumindest teilweise auf Grundlage der Konfigurationsinformationen bestimmt wird. Beispielsweise können der/die Beschleuniger 804 die Ergebnisse der Berechnungen in den Speicher 806 schreiben und dem/den Prozessor(en) 802 angeben, dass die Verarbeitung abgeschlossen ist. Der Prozessor 802 kann dann die Ausgabedaten verwenden, um eine oder mehrere zweite Verarbeitungs-Tasks der Verarbeitungspipeline auszuführen.

ENTKOPPELTER LOOKUP-TABELLENBESCHLEUNIGER

Parallelverarbeitung wird verwendet, um viele Rechenaufgaben zu beschleunigen, einschließlich, aber nicht beschränkt auf: Computer-Vision-Anwendungen, Deep-Learning-Anwendungen, Sensorverarbeitungsanwendungen und/oder andere Anwendungen, die von Parallelität profitieren (z. B. wenn Verarbeitungs-Tasks von anderen Verarbeitungs-Tasks unabhängig sind). Vektorprozessoren können zum Beispiel an mehreren Elementen in derselben Operation arbeiten, um die Effizienz zu gewinnen, die erforderlich ist, um diese Arten von Parallelverarbeitungsalgorithmen in Echtzeit auszuführen, während sie wenig Energie verbrauchen. Eine gängige Operation für Computer-Vision- oder Deep-Learning-Tasks besteht beispielsweise darin, eine Abfrage aus einer Lookup-Tabelle, einem Bildausschnitt oder einer Fläche basierend auf einem Index oder einer Koordinatenposition durchzuführen. Dazu kann auf Daten von mehreren Elementen zugegriffen werden, indem eine einzelne Vektorlade- oder -speicheroperation verwendet wird. Sofern die abgefragten Indizes nicht regelmäßig sind (z. B. aufeinanderfolgende oder feste ganzzahlige Schritte in horizontaler oder vertikaler oder Tiefenrichtung), führt dies zu zufälligen indizierten Zugriffen aus dem Speicher.

Um regelmäßige, aber nicht ausgerichtete Vektorzugriffe aus dem Speicher zu unterstützen, kann ein Prozessor einen Vektorspeicher unter Verwendung kleinerer RAM-Bänke konstruieren. Auf diese Weise ist die Hardware in der Lage, interessante Adressierungsmuster für den Vektorspeicher zu erstellen, indem eindeutige Adressen für jede der RAM-Banken unabhängig generiert werden. Da die Indizes für unterschiedliche Vektorelemente unabhängig voneinander sein können, kann dies bei nicht regelmäßigen indizierten Vektorladeoperationen aus dem Speicher zu Bankkonflikten in einer oder mehreren Banken des RAM führen. Die Bankkonflikte können nicht statisch bestimmt werden, da sie datenabhängig sind, wodurch es dem Compiler nicht ermöglicht wird, die Bankkonflikte zu umgehen.

In einigen herkömmlichen Systemen können verschiedene architektonische Entwürfe implementiert werden, um nicht regelmäßige indizierte Vektorladeoperationen zu unterstützen. Beispielsweise können den Banken des RAM mehrere Leseports hinzugefügt werden. Wenn die Hardware in einem solchen Beispiel 32 Vektoren verarbeiten kann, würde jede Bank 32 Leseports erfordern, was Kosten, Fläche und Energie hinzufügen sowie die Platz- und Routenüberlastung um RAM-Bänke herum erhöhen würde. Ein weiteres Beispiel beinhaltet das Reduzieren des Durchsatzes von indizierten Abfragen, um eine einzelne skalare Abfrage pro Ladevorgang durchzuführen. Dies erzeugt jedoch einen Engpass für die Vektorausführung und wird zum begrenzenden Faktor der Ausführungszeit. Ein weiteres Beispiel beinhaltet das Erstellen von Multipolkopien der Datenstruktur im Speicher, sodass jede Vektorspur auf die Daten von einer einzelnen Bank zugreifen kann. Während dieses Beispiel einige Durchsatzprobleme anderer Ansätze lösen kann, ist die Speicherkapazität begrenzt, indem sie das N-fache (wobei N die Anzahl der Einträge ist, auf die zugegriffen werden soll) des Platzes für die Datenstruktur einnimmt, was zu einer Gesamtleistungsverschlechterung für einen zugehörigen Algorithmus führen kann, zusätzlich zu dem Mehraufwand für das Erstellen von Kopien. Wenn jedoch die Datenstruktur klein ist, ist dieses Verfahren geeignet. In einigen Beispielen können Konflikte dynamisch erkannt und gelöst werden, indem die in Konflikt stehenden Abfragen serialisiert werden. Dies kann jedoch zu einer erhöhten Komplexität der Hardware führen, da die Bankkonflikte dynamisch erkannt und gelöst werden müssen. Ferner erhöhen diese zusätzlichen Stufen die Lade-Verwendung-Latenz für diese Operationen, wodurch die Fähigkeit des Compilers beeinträchtigt wird, Code effizient zu planen. Zusätzlich kann eine datenabhängige Ausführungslatenz eingeführt werden, was ein Problem für Compiler für eine effiziente Zeitplanung ist. In einigen Beispielen können Kombinationen dieser Verfahren ausgeführt werden.

Um diese Nachteile anderer Architekturen zu berücksichtigen, beinhalten die Systeme und Verfahren der vorliegenden Offenbarung einen entkoppelten Lookup-Tabellenbeschleuniger, der so konfiguriert ist, dass er nicht regelmäßige indizierte Vektorladeoperationen unterstützt. Der entkoppelte Lookup-Tabellenbeschleuniger kann als ein Beschleuniger 804 des Systems 800 beinhaltet sein und kann mit einem Prozessor 802 - wie etwa einer VPU - über einen gemeinsam genutzten Speicher 806 kommunizieren. Die entkoppelte Lookup-Tabelle (DLUT) kann mehrere Modi zum Durchführen von Tabellenabfragen unterstützen, wie etwa einen 1 D-Abfragemodus, einen 2D-Abfragemodus, einen konfliktfreien 2D-Abfragemodus, eine 1 D-Abfrage mit Interpolationsmodus, eine 2D-Abfrage mit Interpolationsmodus, einen Tabellenumformatierungsmodus und/oder andere Modi. In jedem Lookup-Modus kann die DLUT ein Array von Indizes in VMEM akzeptieren, die im 1 D-Format (x) oder im 2D-Format (x, y) vorliegen können. Jedes Element kann zum Beispiel 16 Bits oder 32 Bits beinhalten, die vorzeichenlos sein können. Die DLUT kann dann eine vorgeschriebene Indexberechnung durchführen, die als nicht einschränkende Beispiele 2D-zu-1 D-Abbildung, Abschneiden/Runden, Ganzzahl-/Bruchteilung und/oder Erkennung eines gültigen Bereichs beinhalten kann. Beispielsweise kann die DLUT doppelte Lesevorgänge erkennen oder konsolidieren, Bankkonflikte innerhalb von Indizes erkennen und Leseanforderungen an VMEM ausgeben, um die angeforderten Tabelleneinträge abzufragen. Jedes Element kann 8 Bits, 16 Bits oder 32 Bits beinhalten, die entweder vorzeichenbehaftet oder vorzeichenlos sein können. Die DLUT kann dann wie konfiguriert eine Interpolations-Nachverarbeitung durchführen und kann die Ausgabe zurück in VMEM schreiben. Jede dieser Verarbeitungsoperationen kann in einer Pipeline ausgeführt werden, um den Durchsatz zu erhöhen, die Latenz zu verringern und den Energieverbrauch zu verringern.

Infolgedessen überwindet der DLUT-Beschleuniger die Mängel der Implementierung dynamischer Konflikterkennung und -auflösung in der Prozessorpipeline, sodass der Compiler die deterministischen Ausführungslatenzen für alle Speicheroperationen effizient planen kann, während die Komplexität einer Konflikterkennung inline vermieden wird. Da der Beschleuniger als eng gekoppelter Beschleuniger arbeitet - z. B. durch gemeinsam genutzten VMEM mit einer VPU - kann der Prozessor den Beschleuniger konfigurieren und starten, während er mit der Verarbeitung anderer unabhängiger Teile oder Stufen einer Verarbeitungspipeline oder eines Algorithmus fortfährt. In einigen Ausführungsformen kann der Beschleuniger zusätzliche Merkmale beinhalten, um die Belastung des Hauptprozessors weiter zu reduzieren, wie beispielsweise das Auslagern der Indexgenerierung für Bildausschnitte mit spezifischen Abfragemustern, das Durchführen einer optionalen 1 D-Kombination und 2D-Interpolation an den Daten für die Abfragen und/oder Bereitstellen von Unterstützung für die Neuformatierung von Tabellen ohne Abfrage oder Interpolation. In der Praxis hat sich gezeigt, dass das Gesamtsystem - einschließlich eines Prozessors 802 und eines Beschleunigers 804 zum Durchführen von Abfragen - die Verarbeitung verschiedener Computer-Vision-Algorithmen (z. B. Merkmalsnachverfolgung, Objektnachverfolgung, Bildverzerrung, Pyramidenerzeugung usw.) um einen Faktor von zwei beschleunigt, während eine Reduzierung des Energieverbrauchs um über 50 % im Vergleich zur Ausführung des gesamten Algorithmus ausschließlich auf einem Hauptprozessor erreicht wird.

Bezugnehmend nun auf 9A veranschaulicht 9A ein System 900 mit einem entkoppelten Lookup-Tabellen(DLUT)-Beschleuniger gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Es versteht sich, dass diese und andere hierin beschrieben Anordnungen nur als Beispiele aufgeführt werden. Andere Anordnungen und Elemente (z. B. Maschinen, Schnittstellen, Funktionen, Befehle, Gruppierungen von Funktionen usw.) können zusätzlich oder anstelle der gezeigten verwendet werden, und einige Elemente können ganz weggelassen werden. Ferner sind viele der hierin beschriebenen Elemente funktionale Einheiten, die als diskrete oder verteilte Komponenten oder in Verbindung mit anderen Komponenten und in jeder geeigneten Kombination und Position implementiert werden können. Verschiedene hierin als von Einheiten ausgeführt beschriebene Funktionen können durch Hardware, Firmware und/oder Software ausgeführt werden. Beispielsweise können verschiedene Funktionen durch einen Prozessor ausgeführt werden, der im Speicher gespeicherte Anweisungen ausführt. In einigen Ausführungsformen kann das System 900 in ähnlichen Komponenten, Merkmalen und/oder Funktionen wie die des Systems 800 der 8A, des beispielhaften autonomen Fahrzeugs 1300 der 13A-13D, der beispielhaften Rechenvorrichtung 1400 der 14 und/oder des beispielhaften Rechenzentrums 1500 der 15 beinhaltet sein und/oder kann diese beinhalten.

Das System 900 kann einen oder mehrere Prozessoren 902 (die dem/den Prozessor(en) 802 von 8A entsprechen können), einen Speicher 904 (der dem gemeinsam genutzten Speicher 806 von 8A entsprechen kann) und einen entkoppelten Lookup-Tabellen(DLUT)-Beschleuniger 906 (der als ein Beschleuniger 804 des Beschleunigers/der Beschleuniger 804 von 8A beinhaltet sein kann) beinhalten. Der/die Prozessor(en) 902 kann/können in Ausführungsformen eine VPU beinhalten, und der Speicher 904 kann einen VMEM beinhalten. Der DLUT-Beschleuniger 906 (oder „DLUT 906“) kann eine Prozessoreinheit(Processing Unit - PU)-Schnittstelle (Interface - I/F) 908 zum Kommunizieren mit dem/den Prozessor(en) 902, eine Steuerung 912 zum Kommunizieren mit dem/den Prozessor(en) 902 und einen Konfigurator 910 zum Konfigurieren des DLUT 906 basierend auf Informationen von dem/den Prozessor(en) 902, die über die PU-Schnittstelle 908 gemeinsam genutzt werden, und/oder vom Speicher 904 basierend auf einer Angabe von dem/den Prozessor(en) 902, wo die Konfigurationsnachricht oder -informationen im Speicher 904 gespeichert ist/sind, beinhalten. Beispielsweise können die PU-Schnittstelle 908 und die Steuerung 912 dem erweiterten Peripheriebus (APB) bzw. der Ereignis- oder Programmierschnittstelle des Systems 800 entsprechen. Die Steuerung 912 kann Start- oder Auslösebefehle oder -signale (z. B. über den mit „Start“ bezeichneten Pfeil) von dem/den Prozessor(en) 902 empfangen, die angeben, dass der DLUT 906 mit der Verarbeitung beginnen kann und/oder Abfragesignale von dem/den Prozessor(en) 902 empfangen kann, um beim Synchronisieren des Prozessors/der Prozessoren 902 mit dem DLUT 906 zu helfen. Ferner kann der DLUT 906 ein Signal (z. B. über den mit „erledigt“ bezeichneten Pfeil) für den/die Prozessor(en) 902 generieren, wenn der DLUT 906 die Verarbeitung einer oder mehrerer zugewiesener Tasks beendet hat, sodass der/die Prozessor(en) 902 beginnen können, den DLUT 906 für eine oder mehrere nächste Tasks zu konfigurieren.

Während der Konfiguration können der/die Prozessor(en) 902 den DLUT 906 direkt über die PU-Schnittstelle 908 und/oder indirekt durch Angeben einer Stelle der Konfigurationsinformationen im Speicher 904 über die PU-Schnittstelle 908 konfigurieren. Im letzteren Beispiel kann der DLUT 906 die Konfigurationsinformationen z. B. über den gemeinsam genutzten Leseport strm1_dm_rd aus dem Speicher abrufen und kann die gespeicherten Konfigurationsinformationen verwenden, um den DLUT 906 (z. B. um Teileinheiten (z. B. IAU, CDRU, PPU usw.) und/oder andere Komponenten des DLUT 906 zum Durchführen einer oder mehrerer Tasks zu konfigurieren. Zum Beispiel kann/können der/die Prozessor(en) 902 Datenstrukturen im Speicher 904 einrichten, die benötigt werden, um eine oder mehrere Tasks durch den DLUT 906 auszuführen. Zum Beispiel können der/die Prozessor(en) 902 für eine 1000-Koordinaten-Abfrage eine Datenstruktur im Speicher 904 mit jeder der 1000 Koordinaten einrichten und können ferner einen Puffer im Speicher 904 zuweisen, wohin der DLUT 906 Ausgaben schreiben soll. Der/die Prozessor(en) 902 kann/können auch angeben, welche Operationen durch den DLUT 906 durchzuführen sind - z. B. 1D- oder 2D-Abfrage, mit oder ohne Interpolation, Tabellenneuformatierung usw. - und der DLUT 906 kann diese Information verwenden, um die Teileinheiten zu konfigurieren. Die von dem/den Prozessor(en) 902 eingerichteten Konfigurationsinformationen können auch eine Angabe einer Bitbreite für die Koordinatenindizes und eine Bitbreite für Einträge der Tabelle usw. beinhalten. Sobald der/die Eingangspuffer und Ausgangspuffer im Speicher 904 eingerichtet sind und die Konfigurationsinformationen wie Bitbreite, Operationstyp usw. an den DLUT 906 gesendet sind, können der/die Prozessor(en) 902 den DLUT 906 starten oder auslösen, um mit der Verarbeitung zu beginnen. Infolgedessen und im Gegensatz zu Systemen, die allein auf den/die Prozessor(en) 902 angewiesen sind, kann/können der/die Prozessor(en) 902 andere Tasks durchführen, während der DLUT 906 die Abfragen, Interpolationen, Tabellenneuformatierung und/oder dergleichen durchführt, wodurch die Laufzeit verringert und die Effizienz verbessert wird.

Im Betrieb kann eine Koordinaten entsprechende Liste von Indizes durch den DLUT 906 aus dem Speicher 904 empfangen werden, und der DLUT 906 kann die Werte aus einer den Indizes entsprechenden Tabelle entnehmen (z. B. wenn die Werte ganzzahlige Werte sind) und/oder kann Umgebungswerte (z. B. einen linken und rechten Wert für eine 1 D-Abfrage oder einen linken oberen, linken unteren, rechten oberen und rechten unteren Wert für eine 2D-Abfrage) für Bruchwerte entnehmen und eine Interpolation oder andere Operation an den Umgebungswerten durchführen. Sobald die endgültigen Werte bestimmt sind (z. B. direkt über die Abfrage, wenn keine Nachverarbeitung durchgeführt wird, oder nach der Verarbeitung durch eine Nachverarbeitungseinheit (Post-Processing Unit - PPU) 930), können die Werte mit einer Eins-zu-Eins-Entsprechung zu den Indizes aus dem Eingabepuffer in einen Ausgabepuffer im Speicher 904 geschrieben werden. Um diese Aufgaben effizient auszuführen, können in Ausführungsformen eine Indexadresseneinheit (Index Address Unit - IAU) 922, eine Konflikterkennungs- und -auflösungseinheit (Conflict Detection and Resolution Unit - CDRU) 924, eine First-In-First-Out(FIFO)-Steuerung (CTL) 928, ein Bruch(FRAC)-FIFO 926, eine Nachverarbeitungseinheit (PPU) 930, eine Datenkoaleszenzeinheit (Data Coalesce Unit - DCU) 932 und/oder andere Komponenten verwendet werden.

Beispielsweise kann ein Index-Stream (IDX) 916 einen Stream von aus dem Speicher 904 ausgelesenen Indizes (z. B. über einen Leseanschluss strm1_dm_rd) beinhalten, die in einer oder mehreren Lookup-Tabellen abzufragen sind, und die den Indizes entsprechenden Werte können aus dem Speicher 904 (z. B. über einen Leseport strm0_dm_rd) über den Lookup-Tabllen(LUT)-Stream 918 ausgelesen werden. Der Ausgabe-Stream (OUT) 920 können die Werte sein, die nach der Verarbeitung unter Verwendung des DLUT 906 (z. B. über einen Schreibport strm0_dm_wr) in den Speicher 904 zurückgeschrieben werden.

Der/die Prozessor(en) 902 kann/können während der Konfiguration dem Index-Stream 916 angeben, wie auf die Datenstruktur für die Indizes zuzugreifen ist. Beispielsweise können für eine 1 D-Abfrage, bei der eine Schnittstelle mit dem Speicher 904 64 Bytes breit ist, 64 Bytes in jedem Zyklus ausgelesen werden. Wenn eine 1 D-Abfrage durchgeführt wird, kann eine einzelne Koordinate für jeden Indexwert ausgelesen werden (z. B. ein (x)-Wert), und für eine 2D-Abfrage können zwei Koordinatenindizes für jeden Index ausgelesen werden (z. B. ein (x, y)-Wert). Jeder Index kann in nicht einschränkenden Ausführungsformen 16 oder 32 Bits beinhalten, sodass sich in jedem 64-Byte-Lesevorgang 8, 16 oder 32 Koordinaten aus dem Index-Stream 916 ergeben könnten.

Die Daten des Index-Streams 916 können im Rohformat als Rohindizes an die IAU 922 gesendet werden, und jede Koordinate kann ein ganzzahliger Wert oder ein Bruchwert sein. Wenn der Index ein Bruchwert ist, kann die IAU 922 den Bruchwert teilen, um die Bruchbits an das FRAC FIFO 926 zu geben, um beim Kombinieren der abgefragten Umgebungswerte in der Tabelle unter Verwendung der PPU 930 zu helfen. Die IAU 922 kann dann einen Satz von Indizes zum Senden an die CDRU 924 bestimmen, wobei die Anzahl der gesendeten Indizes einer Anzahl von Abfragen entsprechen kann, die der LUT-Stream 918 in einem einzelnen Zyklus durchführen kann. Wenn beispielsweise der LUT-Stream 918 z. B. 32 Abfragen in einem Zyklus durchführen kann (basierend auf der Bitbreite jedes Werts in der Lookup-Tabelle), dann kann die IAU 922 bei jeder Iteration 32 Indizes an die CDRU 924 senden. In einigen Beispielen, beispielsweise wenn die Werte aus dem Index-Stream 916 an die IAU 922 ganzzahlige Werte sind, kann die IAU 922 jeden Satz von Indizes ohne jegliche Verarbeitung senden. Wenn jedoch die Werte aus dem Index-Stream 916 Bruchwerte sind, kann die IAU 922 bestimmen, welche Indizes abgefragt werden müssen, um jeden der erforderlichen Umgebungswerte (z. B. 2 Indizes für 1 D-Interpolation oder 4 Indizes für 2D-Interpolation) zu erhalten, die zum Durchführen einer Interpolation oder einer anderen Operation erforderlich sind, um den kombinierten Wert zu erhalten, der dem Bruchwert entspricht. Wenn beispielsweise der Bruchwert (5,3, 6,2) entsprechend einer (x, y)-Koordinate für 2D-Abfrage und Interpolation ist, kann die IAU 922 bestimmen, dass Abfragen bei (5, 6), (5, 7), (6, 6) und (6, 7) stattfinden sollen, und dann kann die PPU 930 die Werte mischen, um einen Endwert zu generieren, der dem Index (5,3, 6,2) entspricht. Beispielsweise können die Werte gleichgewichtet kombiniert werden oder können unter Verwendung einer bilinearen Interpolation kombiniert werden, sodass Werte, die näher an (5, 6) anstatt (6, 7) liegen, stärker gewichtet werden, um einen Endwert für (5,3, 6,2) zu berechnen.

Der Satz von Abfragen (z. B. 32 Abfrageindizes, wenn der LUT-Stream 918 in der Lage ist, 32 Werte in jedem Lesezyklus zu lesen) kann an die CDRU 924 in einer richtigen Reihenfolge gesendet werden, die der Indexreihenfolge im Eingabepuffer im Speicher 904 entspricht, der unter Verwendung des Index-Streams 916 gelesen wird. Die CDRU 924 führt dann eine Konflikterkennung und -auflösung durch, indem sie Bankkonflikte identifiziert, die sich ergeben würden, wenn die Lesevorgänge der Lookup-Tabelle in dem LUT-Stream 918 in der von der IAU 922 empfangenen Reihenfolge stattfinden würden, und die Bankkonflikte durch Ändern der Reihenfolge der Indizes auflöst, um Bankkonflikte zu vermeiden. Wenn zum Beispiel die Abfrage des Satzes von Indizes einen Bankkonflikt verursachen würde und ein anderer (z. B. ein späterer oder früherer) Satz von Indizes für einen weiteren Abfragezyklus verfügbar ist, kann die CDRU 924 nicht in Konflikt stehende Abfragen aus dem/den anderen Abfragezyklus(sen) finden und die nicht in Konflikt stehenden Abfragen mit in Konflikt stehenden Abfragen für diesen Zyklus austauschen. Als Ergebnis können ein oder mehrere Bankkonflikte vermieden werden, wodurch der Durchsatz erhöht wird. Wenn zum Beispiel die IAU 32 Indizes in jedem Zyklus sendet und 6 der Indizes für einen gegebenen Zyklus Bankkonflikte aufweisen, kann die CDRU 924 bis zu 6 Indizes aus einer anderen Abfrage bestimmen, die keinen Konflikt in der aktuellen Abfrage verursachen würden, und kann diese 32 Abfragen durchführen - z. B. 26 Abfragen von den ursprünglichen 32 und 6 Abfragen von einem anderen Satz, der von der IAU 922 gesendet wird. Sobald der Satz von Abfragen bestimmt ist (z. B. mit oder ohne Ersetzung zur Berücksichtigung von Konflikten), kann der Satz von Abfragen unter Verwendung des LUT-Streams 918 aus dem Speicher 904 ausgelesen werden.

Um die Abfragen außerhalb der Reihenfolge zu berücksichtigen, bei denen Ersetzungen stattfinden, kann die CDRU 924 den CTL FIFO 928 verwenden, um der Datenkoaleszenzeinheit die Reihenfolge der Abfragen jedes Satzes von Abfragen von der IAU 922 anzugeben. Zum Beispiel kann die DCU für einen anfänglichen Satz von 32 Abfragen bestimmen, dass 8 im ersten Zyklus durchgeführt wurden, dann 8 in einem anderen Zyklus, dann 16 in einem anderen Zyklus, und kann dann bestimmen, dass der gesamte Satz von 32 verarbeitet wurde, und kann dann die 32 Abfragen zur Nachverarbeitung an die PPU 930 pushen, falls zutreffend, oder kann sie direkt an den OUT-Stream 920 pushen, um sie in den Ausgabepuffer im Speicher 904 zu schreiben. Diese zusätzlichen Informationen, die die tatsächliche Reihenfolge der Abfragen angeben, die durch die CDRU 924 bestimmt und in den LUT-Stream 918 ausgelesen werden, können über das CTL FIFO 928 an die DCU 932 übermittelt werden. Somit kann die DCU 932 alle Änderungen berücksichtigen, die die CDRU 924 an der Reihenfolge der von der IAU 922 empfangenen Indizes vornimmt. Das CTL FIFO 928 kann nützlich sein, da die Anzahl der Zyklen, die durch die IAU 922, die CDRU 924 usw. gehen sollen, nicht deterministisch und datenabhängig ist. Da beispielsweise Konflikte nicht im Voraus bekannt sind (z. B. weil die Daten nicht deterministisch sein können) und ein Ergebnis der Programmierung sind, gibt es keine Lösung, um Konflikte vollständig zu vermeiden, sodass das CTL FIFO 928 hilft, der DCU 932 die Organisation von Abfragen als Ergebnis einer Konfliktlösung anzugeben.

Bei Bedarf - beispielsweise wenn eine zusätzliche Operation an den Werten der Lookup-Tabelle durchgeführt werden muss - kann die PPU 930 einen oder mehrere Endwerte für jeden Index berechnen, der in den Speicher 904 ausgelesen werden kann. Wenn keine Nachbearbeitung erforderlich ist, wird die PPU 930 möglicherweise nur für das Erheben von Ergebnissen benötigt. Wenn zum Beispiel normale 1D- oder 2D-Abfragen an Indizes durchgeführt werden, die ganzzahlige Werte sind, die direkt auf Stellen in einer Lookup-Tabelle abgebildet sind, können die PPU 930 und das FRAC FIFO 926 nicht verwendet werden, um eine zusätzliche Verarbeitung durchzuführen. Wenn Interpolation - z. B. linear bei 1 D-Abfragen oder bilinear bei 2D-Abfragen - und/oder andere Operationen durchgeführt werden, können die PPU 930 und das FRAC FIFO 926 verwendet werden, um gesammelte Ergebnisse in aktualisierte Ergebnisse oder Werte zum Schreiben in den Speicher 904 umzuwandeln.

In einigen Ausführungsformen kann der DLUT 906 in einem Tabellenneuformatierungsmodus verwendet werden. Beispielsweise können der Index-Stream 916 und der OUT-Stream 920 zum Aktualisieren von Adressen für den Zugriff und/oder die Transponierung verwendet werden. In einem solchen Beispiel, in dem ein Puffer im Speicher 904 vorhanden ist und die Indizes im Puffer zu transponieren sind, kann diese Operation an den DLUT 906 ausgelagert werden (anstatt eine Adressengenerierungseinheit des/der Prozessor(en) 902 die Transponierung ausführen zu lassen). Die Konfigurationsinformationen von dem/den Prozessor(en) 902 - z. B. von einer Adressengenerierungseinheit - können ein Lesemuster zum Lesen aus einem Puffer im Speicher 904 und ein Schreibmuster zum Zurückschreiben der Adressen in den Speicher 904 in einem anderen Muster angeben. Wenn beispielsweise ein Programmierer weiß, dass viele Konflikte aus einem bestimmten Zugriffsmuster resultieren, kann der Programmierer den/die Prozessor(en) 902 so programmieren, dass er den DLUT 906 konfiguriert, um eine Tabellenumformatierung durchzuführen, um die Daten so zu mischen, dass weniger oder keine Konflikte auftreten können.

Als ein weiteres Beispiel kann der DLUT 906 für einen Erkennungssentinel-Rückgabewert außerhalb des Bereichs oder einen Prädikat-Aus-Ausgabeschreibvorgang außerhalb des Bereichs verwendet werden. Wenn sich beispielsweise Koordinaten im Index-Stream 916 außerhalb eines gegebenen Bildausschnitts befinden und die entsprechenden Werte nicht geschrieben werden sollen, kann der DLUT 906 stattdessen einen Sentinelwert ausschreiben, der dem/den Prozessor(en) 902 angeben kann, dass die Sentinelwerte nicht als verlässlich angesehen oder bei der Verarbeitung verwendet werden sollen, wenn die Informationen im Ausgabepuffer verarbeitet werden. In einigen Ausführungsformen kann dieser Sentinelwert dem/den Prozessor(en) 902 angeben, dass die Werte nicht in den Speicher geschrieben werden sollen, sodass die als Fehlerwerte identifizierten Werte möglicherweise nicht gespeichert werden.

Somit kann der DLUT 906 als eine Pipeline von Teileinheiten implementiert werden, die zusammenarbeiten, um konkrete Tasks oder Operationen auszuführen. Jede Teileinheit kann unabhängig arbeiten und über gemeinsam genutzte Schnittstellen mit anderen Teileinheiten kommunizieren. In Bezug auf 9B veranschaulicht Tabelle 940 die Tasks verschiedener Teileinheiten des DLUT 906 während der Verarbeitung konkreter Operationen.

Als Ergebnis des hierin beschriebenen DLUT-Beschleunigers kann die Prozessorpipeline deterministisch bleiben, indem die dynamische Konflikterkennung und -auflösung an den entkoppelten Beschleuniger ausgelagert wird. Außerdem kann der Beschleuniger unabhängig und gleichzeitig mit dem Hauptprozessor (z. B. einer VPU) arbeiten, wodurch die Laufzeit verkürzt wird. Der DLUT-Beschleuniger kann ferner eine 1D- und/oder 2D-Abfrage aus einer gemeinsamen Tabelle mit Konflikterkennung/-auflösung ermöglichen. Der Beschleuniger kann verschiedene Nachverarbeitungsoperationen durchführen, wie etwa 1 D-Abfrage mit linearer Interpolation, 2D-Abfrage mit bilinearer Interpolation, eine Rückgabe eines Erkennungssentinel außerhalb des Bereichs (sowohl 1D als auch 2D) und/oder Prädikat-Aus-Ausgabeschreibvorgang außerhalb des Bereichs (sowohl 1D und 2D). Der DLUT-Beschleuniger kann so konfiguriert werden, dass er eine Interpolation mit einer konfigurierbaren Anzahl von Bruchbits durchführt, und kann verschiedene Index- und Datenformate unterstützen - wie etwa 8-, 16- und 32-Bit-Datenformate mit und ohne Vorzeichen und 16- und 32-Bit-1 D- und 2D-Koordinaten für Indexformate. Der DLUT-Beschleuniger kann auch in der Lage sein, einen konfigurierbaren XIY-Offset zu verwenden, um zwischen globalen Koordinaten und lokalen Koordinaten zu übersetzen. Der DLUT-Beschleuniger kann ferner Datenstromeinheiten unterstützen, um Indexpuffer aus dem VMEM zu lesen, eine Abfrage aus dem VMEM durchzuführen und Ergebnisse (oder Abfrage oder Interpolation) in den VMEM zu schreiben. Die Datenstromeinheiten können bis zu 2D-Adressierung von linearen und transponierten Zugriffen unterstützen. Um die Anzahl der für die Abfrage/Interpolation benötigten Zyklen zu optimieren, können Indizes für Abfragen außerhalb der Reihenfolge liegen, um Bankkonflikte zu minimieren - wenn z. B. der VMEM N Abfragen unterstützt, kann der Beschleuniger M × N Indizes verwenden, um die Anzahl der Indizes zu maximieren, die eine Konflikterkennung überleben können - und Duplikaterkennung kann durchgeführt werden, um doppelte Indizes herauszufiltern, die garantiert einen Konflikt generieren. Ferner kann ein 2D-Abfrage- und Interpolationsmodus des DLUT-Beschleunigers automatisch generierte Indizes (als Auto-Index-Modus bezeichnet) innerhalb des Beschleunigers aus wenigen Parametern beinhalten, im Gegensatz zu einem Programmierer, der einen Block von Indexdaten bereitstellt. Dies verlagert die Vorbereitung des Index vom Hauptprozessor auf den Beschleuniger.

Unter nunmehriger Bezugnahme auf 9C umfasst jeder Block des hierin beschriebenen Verfahrens 950 einen Rechenprozess, der unter Verwendung einer beliebigen Kombination von Hardware, Firmware und/oder Software durchgeführt werden kann. Beispielsweise können verschiedene Funktionen durch einen Prozessor ausgeführt werden, der im Speicher gespeicherte Anweisungen ausführt. Das Verfahren 950 kann auch als computerverwendbare Anweisungen dargestellt werden, die auf Computerspeichermedien gespeichert sind. Die Verfahren 950 kann durch eine eigenständige Anwendung, einen Dienst oder einen gehosteten Dienst (eigenständig oder in Kombination mit einem anderen gehosteten Dienst) oder ein Plug-in zu einem anderen Produkt bereitgestellt werden, um nur einige zu nennen. Desweiteren wird das Verfahren 950 in Bezug auf das System 900 der 9A beschrieben, aber das Verfahren 950 kann durch ein beliebiges System, eine beliebige Struktur oder Komponente oder eine beliebige Kombination von Systemen, Strukturen oder Komponenten ausgeführt werden, einschließlich, jedoch nicht beschränkt auf die hierin beschriebenen.

9C ist ein Flussdiagramm, das ein Verfahren 950 zum Verwenden eines entkoppelten Lookup-Tabellen-Beschleunigers gemäß einigen Ausführungsformen der vorliegenden Offenbarung zeigt. Das Verfahren 950 beinhaltet bei Block B902 das Konfigurieren einer oder mehrerer Teileinheiten eines DLUT-Beschleunigers zumindest teilweise basierend auf Konfigurationsinformationen, die unter Verwendung eines Prozessors generiert werden. Beispielsweise kann der DLUT 906 die Teileinheiten des DLUT 906 unter Verwendung von Informationen konfigurieren, die von dem/den Prozessor(en) 902 empfangen und/oder aus dem Speicher 904 abgerufen werden.

Das Verfahren 950 beinhaltet bei Block B904 das Bestimmen eines ersten Teilsatzes von Indizes ohne Bankkonflikte aus einem ersten Satz von Indizes eines aus dem Speicher gelesenen Stream von Indizes. Beispielsweise kann die IAU 922 einen Satz von Indizes für die CDRU 924 generieren, um Konflikte zu verarbeiten, und die CDRU 924 kann einen Teilsatz der Indizes in dem Satz bestimmen, die keine Bankkonflikte aufweisen.

Das Verfahren 950 beinhaltet bei Block B906 das Bestimmen eines zweiten Teilsatzes von Indizes ohne Bankkonflikte mit dem ersten Teilsatz von Indizes aus einem zweiten Satz von Indizes eines aus dem Speicher gelesenen Stream von Indizes. Beispielsweise kann die IAU 922 einen weiteren Satz von Indizes für die CDRU 924 zum Verarbeiten auf Konflikte generieren, und die CDRU 924 kann bestimmen, einen oder mehrere der Indizes mit Konflikten aus dem ersten Satz durch einen oder mehrere Indizes aus dem zweiten Satz von Indizes zu ersetzen, die nicht zu Konflikten mit dem ersten Satz von Indizes führen würden.

Das Verfahren 950 beinhaltet bei Block B908 das Durchführen einer Abfrage einer oder mehrerer Lookup-Tabellen unter Verwendung des ersten Teilsatzes von Indizes und des zweiten Teilsatzes von Indizes in einem einzelnen Lesezyklus aus dem Speicher, um eine Vielzahl von Werten abzurufen. Beispielsweise kann der DLUT 906 Werte aus dem Speicher 904 in den LUT-Stream 918 lesen, indem der Teilsatz von Werten aus dem Satz von Indizes und die Werte von dem zweiten Satz von Indizes verwendet werden, für die bestimmt wurde, dass sie keinen Konflikt mit dem Teilsatz von Werten aus dem ersten Satz von Indizes aufweisen.

Das Verfahren 950 beinhaltet bei Block B910 das Schreiben der Vielzahl von Werten in den Speicher. Beispielsweise können die Werte aus dem LUT-Stream 918 in den Speicher 904 im Ausgabe-Stream 920 geschrieben werden. Vor dem Ausschreiben kann die DCU 932 die Daten reorganisieren, sodass die Daten in einer Eins-zu-Eins-Reihenfolge mit den aus dem Eingabepuffer im Index-Stream 916 ausgelesenen Indizes vorliegen. In einigen Ausführungsformen kann die PPU 930 eine oder mehrere Operationen, wie etwa Interpolation, an den abgerufenen Werten durchführen, bevor ein Endwert in den Speicher 904 im OUT-Stream 920 geschrieben wird.

HARDWARE-SEQUENZER FÜR EIN DIREKTSPEICHERZUGRIFFSSYSTEM

Ein System mit Direktspeicherzugriff (DMA) kann verwendet werden, um Daten von unterschiedlichen Speicherstellen zu bewegen, ohne dass eine zentrale Verarbeitungseinheit (CPU) erforderlich ist. Beispielsweise kann der DMA als Datenbewegungs-Engine arbeiten, um Daten von einer Quelle zu einem Ziel zu bewegen - z. B. von einer Quelle wie einem externen Speicher (z. B. DRAM) oder einem internen Speicher wie einem L2-Puffer oder Vektorspeicher (VMEM) einer Vektorverarbeitungseinheit (VPU) zu einem Ziel, wie etwa einer VPU. Das DMA-System kann in der Praxis zusätzliche Operationen durchführen, wie etwa ohne Einschränkung das Auffüllen von Frame-Daten, das Manipulieren von Adressen, das Verwalten überlappender Daten, das Verwalten unterschiedlicher Durchquerungsreihenfolgen und das Berücksichtigen unterschiedlicher Frame-Größen.

Bei der digitalen Signalverarbeitung können mehrere DMA-Ressourcen verwendet werden, um strukturierte Kacheldatenbewegungen zwischen einem externen Speicher und einem Prozessor - wie beispielsweise einer VPU - zu beschreiben. Beispielsweise können diese DMA-Ressourcen Deskriptoren, Kanäle, Auslöser und/oder Register beinhalten. Deskriptoren können beispielsweise eine Kachelbewegung beschreiben, wie etwa eine Stelle der Quelle, eine Zielstelle, einen Zeilenabstand, eine Kachelbreite, eine Kachelhöhe, eine kreisförmige Pufferanordnung und/oder dergleichen. Die Kacheldatenbewegung für Bildoberflächen mit räumlichen und zeitlichen Abhängigkeiten verursacht jedoch zusätzliche Programmiermodellherausforderungen für einen Benutzer und erfordert unterschiedliche und viele DMA-Konfigurationsressourcen. Diese Kacheldatenabhängigkeiten können auch den Steuercode und eine Steuersequenz im Prozessorcode (z. B. VPU) verkomplizieren. Beispielsweise kann eine typische Verarbeitungsoperation eine Filterung umfassen, wie etwa eine 3x3-Filterung. Diese Art von Operation führt räumliche Abhängigkeiten ein, da jedes Ausgabepixel von den entsprechenden Werten von 3x3 Pixeln um das Ausgabepixel herum abhängt. Bei einer solchen Operation kann eine 3×3-Matrix von Werten verwendet werden, um eine Filterung durchzuführen, und diese Operation kann als räumlich abhängige Operation bezeichnet werden. In der Praxis kann jede Kachel eines Frames dieselbe Größe aufweisen - z. B. 64×64 - um Programmierherausforderungen zu reduzieren. Wenn jedoch ein 3×3-Filter an einer 64×64-Kachel verwendet wird, wird ein zusätzliches Pixel nach oben und unten von benachbarten Kacheln benötigt - wie z. B. in den schattierten Bereichen der 10C veranschaulicht. Daher müssen diese Informationen in den DMA-Ressourcen codiert werden, um ein ordnungsgemäßes Abrufen der Daten über Kacheln hinweg zu ermöglichen -was zu einem zusätzlichen Programmieraufwand führt.

Unter Bezugnahme auf die 10A-10G veranschaulichen die 10A-10G verschiedene Herausforderungen für Datenbewegungen, wenn ein DMA-System verwendet wird. Die Visualisierung 1000 der 10A kann zum Beispiel dem Auffüllen von Frame-Daten entsprechen. In der Visualisierung 1000 kann es neun Abschnitte geben, einen oberen linken Abschnitt, einen oberen Abschnitt, einen oberen rechten Abschnitt, einen linken Abschnitt, einen mittleren Abschnitt, einen rechten Abschnitt, einen unteren linken Abschnitt, einen unteren Abschnitt und einen unteren rechten Abschnitt. In einem solchen Beispiel kann jeder Abschnitt eine oder mehrere Kacheln beinhalten - z. B. kann der obere linke Abschnitt eine Kachel beinhalten, während der obere Abschnitt z. B. vier Kacheln beinhalten kann. Um diese Unterteilung genau zu definieren, kann dieser Frame in bestehenden Ansätzen somit unter Verwendung von neun Deskriptoren (z. B. einen für jeden Abschnitt), drei Kanälen (z. B. einen für eine linke Spalte, einen für eine mittlere Spalte und einen für eine rechte Spalte) und drei Auslösern (z. B. einen für jeden Kanal) beschrieben werden.

In Bezug auf das Auffüllen beispielsweise aufgrund räumlicher Abhängigkeiten kann das DMA-System beim Durchführen von Operationen an Daten nahe einer Grenze einer Kachel oder eines Abschnitts eines Frames Werte auffüllen oder Werte für Pixel erzeugen, die außerhalb einer Bildgrenze liegen. Dies kann daran liegen, dass bei gewissen Implementierungen das Anfordern von Daten außerhalb eines Speicherbereichs für ein Bild einen Fehler auslösen kann. Somit kann der DMA verwendet werden, um Werte aufzufüllen oder herzustellen, nachdem die Bilddaten aus dem entsprechenden Speicherbereich abgerufen wurden, um das Auslösen des Fehlers zu vermeiden. Ohne Auffüllen stimmt die Struktur der Daten möglicherweise nicht mit einer Kernelgröße überein, wenn beispielsweise eine Filteroperation durchgeführt wird. Die abgerufenen Daten mit den zusätzlichen aufgefüllten Werten können dann an das Ziel - z. B. eine VPU - gesendet werden, sodass die VPU die Daten gemäß ihrer Konfiguration verarbeiten kann und Daten über einen gesamten (aufgefüllten) Frame auf die gleiche Weise verarbeiten kann. Beim Auffüllen kann ein Auffüllen mit Nullen verwendet werden (z. B. wenn jeder neue Datenpunkt einen Nullwert beinhaltet), können duplizierte Werte verwendet werden (z. B. Duplizieren des Pixelwerts eines benachbarten Pixels aus den abgerufenen Daten) und/oder kann ein anderer Auffüllmechanismus verwendet werden. Außerdem kann eine Auffüllung zu allen Seiten eines Frames hinzugefügt werden und kann für unterschiedliche Seiten unterschiedlich hinzugefügt werden. Beispielsweise kann in 10A ein aufgefüllter Bereich 1002 auf einer rechten Seite größer sein als auf einer linken, oberen oder unteren Seite des Frames. Das Auffüllen erhöht die Komplexität der DMA-Programmierung, wenn Daten von einer Quelle zu einem Ziel verschoben werden - beispielsweise vom Speicher in den VMEM - und erhöht auch die Komplexität der VPU-Programmierung, wenn ein größerer, aufgefüllter Frame verarbeitet wird.

Nun Bezug nehmend auf 10B entspricht die Visualisierung 1010 in 10B einer Adressenmanipulation durch ein DMA-System. Beispielsweise können unterschiedliche Deskriptoradressen manipuliert und programmiert werden, um zusammenhängende Frame-Daten abzurufen. Damit der DMA effektiv durchgeführt wird, kann die Adressenbeschreibung der Datenverschiebung zusammenhängend sein. Somit kann die Adresse jedes Deskriptors manipuliert werden, und diese Manipulation muss von einem Deskriptor auf einen anderen übertragen werden. Wenn beispielsweise Werte wie veranschaulicht aufgefüllt werden, kann die Startadresse für jeden Deskriptor manipuliert werden, um zu bewirken, dass die abgerufenen Daten die aufgefüllten Werte beinhalten. Dazu verwendet ein Programmierer eine Startadresse und eine Kachelbreite sowie eine Anzahl von Kacheln in jedem Abschnitt und verwendet diese Informationen, um eine nächste Deskriptoradresse zu generieren. Beispielsweise kann ein erster Deskriptor das Abrufen von Daten beginnend oben links, dann oben, dann oben rechts, dann links, dann in der Mitte und so weiter veranlassen, wie durch die Pfeile in 10B angegeben. Startdeskriptoradressen erhöhen jedoch die Komplexität der DMA-Programmierung, wenn Daten an ein Ziel verschoben werden - wie etwa den VMEM.

Als weiteres Beispiel und in Bezug auf 10C kann es erforderlich sein, dass das DMA-System vertikal und horizontal überlappende Daten von benachbarten Kacheln liest, um eine zusammenhängende Datenverarbeitung sicherzustellen. Wie beispielsweise durch die schattierten Bereiche von 10C veranschaulicht, kann es erforderlich sein, dass überlappende Daten von einer Kachel eines oberen linken Abschnitts und einer benachbarten Kachel in einem oberen Abschnitt in derselben Operation gelesen werden. In ähnlicher Weise kann es erforderlich sein, dass überlappende Daten von einer Kachel eines oberen linken Abschnitts und einer benachbarten Kachel in einem linken Abschnitt in derselben Operation gelesen werden. Um dies zu erreichen, muss der Deskriptor aktualisiert oder bewegt werden, um den überlappenden Teil einzuschließen. Beispielsweise kann der Basisdeskriptor eine Adresse am Anfang des oberen Abschnitts beinhalten, aber um Daten von der angrenzenden Kachel im oberen linken Abschnitt zu erfassen, muss der Deskriptor für den oberen Abschnitt aktualisiert (z. B. nach links bewegt) werden, um die Daten von der Kachel oben links zu erfassen. Diese Aktualisierung erfordert zusätzlichen Programmieraufwand, insbesondere wenn die Anzahl der Deskriptoren erhöht wird.

Außerdem muss das DMA-System in Bezug auf die 10D-10F möglicherweise unterschiedliche Durchquerungsreihenfolgen unterstützen, um die Daten auf zusammenhängende Weise aus dem Speicher auszulesen. Unabhängig davon, ob Filterung, Faltung, Matrixmultiplikation und/oder eine andere Operation durchgeführt wird, kann die zugeordnete Durchquerungsreihenfolge beispielsweise unterschiedlich sein. Um dies zu berücksichtigen, können verschiedene Durchquerungsreihenfolgen unterstützt werden, wie etwa die 10D veranschaulichten, die eine Rasterdurchquerungsreihenfolge beginnend oben links (Visulisierung 1030), eine Rasterdurchquerungsreihenfolge beginnend rechts oben (Visualisierung 1032), eine Rasterdurchquerungsreihenfolge beginnend links unten (Visualisierung 1034) und/oder eine Rasterdurchquerungsreihenfolge beginnend rechts unten (Visualisierung 1036) beinhalten. In ähnlicher Weise können in Bezug auf die Visualisierung 1038 der 10E verschiedene kubische Durchquerungsreihenfolgen durch das DMA-System für ein kubisches Bild unterstützt werden. 10F veranschaulicht verschiedene Durchquerungsreihenfolgen für vertikales Mining, die durch das DMA-System unterstützt werden können, wie etwa eine vertikale Mining-Durchquerungsreihenfolge, die oben links beginnt (Visualisierung 1040), eine vertikale Mining-Durchquerungsreihenfolge, die oben rechts beginnt (Visualisierung 1042), eine vertikale Mining-Durchquerungsreihenfolge beginnend unten links (Visualisierung 1046) und/oder eine vertikale Mining-Durchquerungsreihenfolge beginnend rechts unten (Visualisierung 1048). Um jede dieser unterschiedlichen Durchquerungsreihenfolgen zum Bewegen von Daten in den Speicher (wie etwa VMEM) zu unterstützen, wird die Komplexität der DMA-Programmierung erhöht.

Bezugnehmend auf 10G kann es auch erforderlich sein, dass das DMA-System unterschiedliche Frame-Größen unterstützt, wie etwa das Bewegen mehrerer Frames mit unterschiedlichen Größen (z. B. Luma/Chroma-Komposit oder unterschiedliche Pyramidenebenen). Beispielsweise kann ein Prozessor - wie etwa eine VPU - Frames unterschiedlicher Größe verarbeiten, um eine endgültige gewünschte Ausgabe zu generieren. 10A veranschaulicht eine beispielhafte Visualisierung 1048, die einer Pyramidenverarbeitung von Frames für eine Schätzungsoperation des optischen Flusses entspricht. In solchen Beispielen kann die Bewegung von Pixeln zuerst an einer kleineren Frame-Größe berechnet werden, dann an einer größeren Frame-Größe unter Verwendung eines Hinweises von der Ausgabe der kleineren Frame-Größe, dann an einer noch größeren Frame-Größe unter Verwendung eines Hinweises von der größeren Frame-Größe und so weiter an. Somit kann das DMA-System das Abrufen von Frame-Daten für verschiedene Frame-Größen unterstützen, aber diese Fähigkeit erfordert zusätzliche Programmierkomplexität für das DMA-System. Beispielsweise müssen die Deskriptoren für jede unterschiedliche Frame-Größe programmiert oder aktualisiert werden.

Um die Programmierung für diese verschiedenen Operationen zu vereinfachen, die ein DMA-System unterstützt, können die DMA-Systeme und - Verfahren der vorliegenden Offenbarung einen Hardware-Sequenzer in Kombination mit einer DMA-Engine verwenden, um die Datenbewegung zu berücksichtigen. Beispielsweise kann die Datenbewegung für ein vollständiges Bild explizit und vollständig in einem Hardware-Sequenzierungsmodus mit einem vereinfachten Programmiermodell (z. B. einer Bildstruktur eines Frames, wie in 10I veranschaulicht) beschrieben werden, das die Kachelsequenzierung (Auslösung) Auffüllung, Überlappung (Offset), Durchquerungsreihenfolge und unterschiedliche Frame-Größen handhabt. Der Hardware-Sequenzer kann die DMA-Ressourcennutzung reduzieren (z. B. eine Anzahl von erforderlichen Deskriptoren, Auslösern, Kanälen usw. reduzieren), die Steuerung von der VPU für die VPU-Steuerungsverarbeitung auslagern und die Komplexität der DMA-Programmierung reduzieren. Dies kann durch Laden einer Bild- oder Frame-Deskriptoransicht (z. B. wie in 10I veranschaulicht) in Form einer Folge von Befehlen aus einem lokalen programmierbaren Speicher erreicht werden. Diese Hardwaresequenzbefehle können jede der Operationen enthalten, die zu einer Erhöhung der Programmierkomplexität führen, wie hierin beschrieben - einschließlich Bildauffüllen, Kachelüberlappung oder -offset, Frame-Offset, Bilddurchlaufreihenfolgen und Bildgröße in Kachelgranularität. Der Hardware-Sequenzer kann die Bildbefehle zusätzlich zu den Deskriptorinformationen aus dem Speicher lesen (z. B. aus den Bildbefehlen oder aus einem separaten Deskriptorspeicher oder SRAM) und die Kachelbewegungen sequenzieren, um das Vollbild zu durchlaufen und auszumalen.

Bezugnehmend nun auf 10H veranschaulicht 10H ein DMA-System 1050 mit einem Hardware-Sequenzer gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Es versteht sich, dass diese und andere hierin beschrieben Anordnungen nur als Beispiele aufgeführt werden. Andere Anordnungen und Elemente (z. B. Maschinen, Schnittstellen, Funktionen, Befehle, Gruppierungen von Funktionen usw.) können zusätzlich oder anstelle der gezeigten verwendet werden, und einige Elemente können ganz weggelassen werden. Ferner sind viele der hierin beschriebenen Elemente funktionale Einheiten, die als diskrete oder verteilte Komponenten oder in Verbindung mit anderen Komponenten und in jeder geeigneten Kombination und Position implementiert werden können. Verschiedene hierin als von Einheiten ausgeführt beschriebene Funktionen können durch Hardware, Firmware und/oder Software ausgeführt werden. Beispielsweise können verschiedene Funktionen durch einen Prozessor ausgeführt werden, der im Speicher gespeicherte Anweisungen ausführt. In einigen Ausführungsformen kann das System 1050 in ähnlichen Komponenten, Merkmalen und/oder Funktionen wie die des beispielhaften autonomen Fahrzeugs 1300 der 13A-13D, der beispielhaften Rechenvorrichtung 1400 der 14 und/oder des beispielhaften Rechenzentrums 1500 der 15 beinhaltet sein und/oder kann diese beinhalten.

Das System 1050 kann eine DMA-Engine 1056, eine Registersteuerung 1058, eine Hardware(HW)-Sequenzer-Steuerung 1060, einen Deskriptor-SRAM 1052 und/oder einen Hardware (HW)-Sequenzerbefehls-SRAM 1054 beinhalten. Ein bestehendes System kann nur die DMA-Engine 1056 und den Deskriptor-SRAM 1052 beinhalten, der die Deskriptoren für den Frame speichert. Somit musste die DMA-Engine 1056, wie hierin beschrieben, zuvor alle Operationen des Auffüllens, der Adressmanipulation usw. durchführen, wenn Daten von einer Quelle zu einem Ziel gesendet wurden, und die VPU oder eine andere Quelle musste die Sequenzierung durch Handshaking mit dem DMA-System durchführen (z. B. mit der VPU als primärem Knoten und dem DMA als sekundärem Knoten). In solchen Beispielen würde die DMA-Engine 1056 auf Kachelebene verarbeiten, wobei Deskriptoren für verschiedene Abschnitte des Frames verwendet werden, die jeweils eine oder mehrere Kacheln beinhalten, um Kacheln einzeln abzurufen, um sie an ein Ziel zu senden, und nachfolgende Kacheln würden gemäß den Deskriptoren basierend auf einer Angabe von der VPU, eine nächste Kachel abzurufen, abgerufen.

Unter Verwendung des Systems 1050 der 10H können Frames jedoch auf Frame-Ebene verarbeitet werden - z. B. kann ein einzelner Deskriptor für den in 10C veranschaulichten Frame verwendet werden, für die zuvor neun Deskriptoren erforderlich waren. Wenn die DMA-Engine 1056 in der Praxis versucht, Deskriptoren aus dem Deskriptor-SRAM 1052 (oder allgemeiner dem Deskriptorspeicher 1052) zu laden, kann die HW-Sequenzer-Steuerung 1060 somit das Laden der Deskriptoren unterbrechen und eine Befehlssequenz-Verarbeitungsstruktur verwenden, um mehrere Frames, Kachelzeilen/-spalten und mehrere Deskriptoren zu handhaben. Dazu kann ein Frame-Format 1070 (10I) verwendet werden, das Frames auf einer höheren Ebene beschreibt, indem Kachelreihen/-spalten (in Abhängigkeit von der Durchquerungsreihenfolge) in Hardware statt auf Kachelebene verarbeitet werden. Beispielsweise kann anstelle des Auffüllens von Kacheln ein ganzer Frame unter Verwendung des Frame-Formats 1070 aufgefüllt werden, wodurch viele Frames mit einem einzigen Auffüllbefehl aufgefüllt werden. Somit kann ein ganzer Frame verstanden werden, wie etwa wo aufzufüllen ist, wo zu überlappen ist, wie Adressen automatisch manipuliert werden sollen und so weiter. Außerdem kann das Legacy-Format für Operationen unterstützt bleiben, die möglicherweise nicht von der HW-Sequenzer-Steuerung 1060 profitieren, da die DMA-Engine 1056 Deskriptoren direkt aus dem Deskriptor-SRAM 1052 entnehmen kann, ohne Eingriff durch die HW-Sequenzer-Steuerung 1060.

Die HW-Sequenzer-Steuerung 1060 kann z. B. als Zustandsmaschine arbeiten, die den HW-Sequenzerbefehls-SRAM 1054 (oder allgemeiner den HW-Sequenzerbefehlsspeicher 1054) liest, wobei das Frame-Format 1070 einschließlich der Sequenzierungsbefehle gespeichert wird. Eine Verarbeitungssteuerung - wie etwa ein R5-Prozessor, eine CPU, ein ARM-Prozessor usw. - kann programmierten Code und/oder Einstellungen von einer übergeordneten Engine verwenden, um den HW-Sequenzerbefehls-SRAM 1054 und den Deskriptor-SRAM 1052 zu programmieren oder zu konfigurieren.

Der Deskriptor-SRAM 1054 kann einen oder mehrere Deskriptoren beinhalten, die Kacheldimensionen (z. B. eine Kachelbreite dx und eine Kachelhöhe dy), einen Startpunkt für das Bild oder den Frame (z. B. oben links, unten rechts usw.), ein Auslösertyp und/oder andere Mikroinformationen über den Abtasttyp des Deskriptors definieren.

Das HW-Sequenzerbefehls-SRAM 1054 kann das Frame-Format 1070, das den Frame als Ganzes definiert, die Größe des Frames, die Frame-Auffüllung usw. speichern. Zum Beispiel kann das Frame-Format 1070 Frame-Header für die Header-Steuerung, Offset-Steuerung und Auffüllungssteuerung beinhalten und kann Spalten-Header und/oder Reihen-Header für Spalten oder Reihen des Frames beinhalten (z. B. Spalten-Header für vertikale Abtastmuster und Reihen-Header für Rasterabtastmuster). Die Frame-Header-Steuerung kann einen Frame-Wiederholungsfaktor beinhalten, um zu identifizieren, wie oft der konkrete Frame wiederholt werden soll, sowie eine Anzahl von Deskriptorreihen und/oder Deskriptorspalten. Die Frame-Header-Offset-Steuerung kann einen Frame-Kachel-Offset (z. B. einen Offset von Kachel zu Kachel) und einen Frame-Offset (z. B. einen Offset zwischen zwei oder mehr Frames, die unter Verwendung eines einzelnen Kanals ausgelesen werden können, wie etwa wenn ein YUV-Frame verarbeitet werden kann, der drei separate Ebenen beinhaltet) beinhalten. Der Frame-Auffüllungs-Header kann angeben, wie viele Füllzeilen oder -pixel auf einer Frame-Ebene hinzuzufügen sind (im Gegensatz zu einer Ebene pro Kachel bei früheren Ansätzen), wie etwa das Auffüllen einer linken Seite eines Frames, einer Oberseite eines Frames, einer rechten Seite eines Frames und/oder einer Unterseite eines Frames, sodass der gesamte Frame aufgefüllt wird, anstatt jede Kachel innerhalb jedes Abschnitts eines Frames auf einer Kachelebene aufzufüllen.

Die Spalten-Header können verwendet werden, wenn die Durchquerungsreihenfolge vertikal ist, und die Reihen-Header können verwendet werden, wenn die Durchquerungsreihenfolge gerastert oder horizontal ist. Die Spalte-Header und/oder Reihen-Header können einen Spalten- oder Reihen-Offset (z. B. wie groß der Offset zwischen jeder Spalte oder jeder Reihe ist), einen Spalten- oder Reihenwiederholungsfaktor (z. B. wie oft derselbe Spalten- oder Reihenverarbeitungstyp über den Frame wiederholt werden soll, wie etwa N-1 Mal, wobei N die Anzahl der Verarbeitungen der Spalte oder Reihe ist), und eine Anzahl von Deskriptoren, die für jede Spalte oder Reihe verwendet werden, beinhalten (z. B. kann ein einzelner Deskriptor verwendet werden, um eine gleiche Kachel über eine Reihe oder Spalte zu wiederholen, oder ein erster Deskriptor kann verwendet werden, um einen Teil einer Reihe zu durchlaufen, und ein zweiter Deskriptor kann verwendet werden, um einen anderen Teil der Reihe zu durchlaufen, und so weiter). Die Deskriptor-IDs können so beschrieben werden, dass ein Deskriptor - z. B. im Deskriptor-SRAM 1052 gespeichert - entnommen und verwendet werden kann, um die Reihe oder Spalte zu beschreiben. Beispielsweise kann die Deskriptor-ID angeben, welcher Deskriptor für (eine) konkrete Spalte(n) und/oder Reihe(n) zu verwenden ist und wie oft der Deskriptor wiederholt wird (z. B. N-1 Mal, wobei N die Anzahl von Malen ist, wie oft der Deskriptor insgesamt verwendet wird). In Ausführungsformen kann es eine festgelegte Anzahl von Deskriptoren (z. B. 64) geben, und die Deskriptor-ID kann verwendet werden, um zu bestimmen, welcher Deskriptor für eine konkrete Spalte und/oder Reihe verwendet werden soll. Auf diese Weise betrachtet die Hardware-Sequenzer-Steuerung 1060 eine Superstruktur eines Frames, der sich über Basisdeskriptoren aus dem Deskriptor-SRAM 1052 befindet, was eine Vereinfachung der Ressourcen ermöglicht, die von der DMA-Engine 1056 benötigt werden, um eine gleiche Datenübertragung zu implementieren. Außerdem kann die HW-Sequenzer-Steuerung 1060 Kacheln - z. B. unter Verwendung der Registersteuerung 1058 - im Voraus abrufen, um die Latenz zu reduzieren, und die Kacheldaten können auf Anforderung durch die DMA-Engine 1056 sofort verfügbar sein.

Im Betrieb kann die HW-Sequenzer-Steuerung 1060 die Bildstruktur (z. B. das Frame-Format 1070 ) aus dem HW-Sequenzerbefehls-SRAM 1054 zusammen mit den Deskriptorinformationen aus dem Deskriptor-SRAM 1052 lesen und kann die Informationen kombinieren, um durch einen Rahmen für die DMA-Engine 1056 zu sequenzieren. Anstatt eine separate Codierung der DMA-Engine 1056 für jeden Deskriptor, Auslöser, Kanal usw. zu erfordern, kann die HW-Sequenzer-Steuerung 1060 somit die Bildstruktur lesen, die Deskriptoren entnehmen und durch den Frame für die DMA-Engine 1056 mit dem richtigen Deskriptorformat sequenzieren. Die Registersteuerung 1058 kann in Ausführungsformen bei der Steuerung einer Durchquerungsreihenfolge, eines Vorabrufs und/oder anderer Rahmenadressierungssteuerungen helfen. Die HW-Sequenzer-Steuerung 1060 vereinfacht den Code für die VPU weiter, sodass die VPU nicht mehrere Kanäle berücksichtigen muss. Stattdessen kann die VPU eine Kachel anfordern, dann eine nächste Kachel, dann eine nächste Kachel und so weiter. Die HW-Sequenzer-Steuerung 1060 versteht eine aktuelle Position in dem Frame und versteht somit eine nächste Kachel, die für die DMA-Engine 1056 abgerufen werden soll, und die DMA-Engine 1056 muss diese Informationen nicht intern verfolgen.

Das System 1050 kann somit rückwärtskompatibel mit früheren Ansätzen sein, da das System immer noch die Verwendung verschiedener Deskriptoren, Auslöser, Kanäle usw. unterstützen kann, aber auch auf einer Frame-Ebene verstehen kann, um die Komplexität zu verringern. Das System 1050 kann Bildauffüllung an allen Ecken eines Frames mit unterschiedlichen Pixelauffüllungsgrößen, Überlappen von Kacheln vertikal und/oder horizontal, um angrenzenden Kachelzugriff durch die VPU zu ermöglichen, um entlang Kachelgrenzen zu verarbeiten, und Durchlaufen eines Frames in unterschiedlichen Durchquerungsreihenfolgen unterstützen. Zusätzlich kann das System 1050 eine automatische Kachel-Offset-Anpassung durch die HW-Sequenzer-Steuerung 1060 am VMEM-Ziel unterstützen. Da Deskriptoren in dem Frame über Hardware verknüpft sind, muss ein Benutzer Deskriptoren nicht verknüpfen oder zusammenfügen. Die HW-Sequenzer-Steuerung 1060 kann die Adressensequenzierung über Deskriptoren/Kacheln hinweg über einen Frame hinweg ohne zusätzliche Programmierkomplexität verwalten, und die HW-Sequenzer-Steuerung 1060 kann Kacheln für eine verbesserte Leistung vorab abrufen.

In einigen Ausführungsformen können die Deskriptoren in der Bild- oder Frame-Struktur beinhaltet sein, anstatt separat im Deskriptor-SRAM 1052 gespeichert zu werden. Wenn beispielsweise keine Legacy-Kompatibilität implementiert ist, kann die Gesamtheit der Sequenzierungsstruktur und Kachelstruktur in der Frame-Struktur beschrieben werden. In einem solchen Beispiel kann das Frame-Format in 10I zusätzliche Informationen für die Deskriptoren beinhalten, wie etwa Kachelbreite, Auslösertyp usw., um zu erreichen, dass dieselben Informationen für die HW-Sequenzer-Steuerung 1060 verfügbar sind, als wenn der Deskriptor bzw. die Deskriptoren separat im Deskriptor-SRAM 1052 gespeichert sind.

Unter Bezugnahme auf 10J ist 10J ist ein Beispiel des Frame-Formats 1070 der 10I bei Implementierung für eine Rasterabtastsequenz gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Beispielsweise ist das Frame-Format 1070A ein Beispiel eines Frame-Formats in einem Rastermodus mit Frame-Adressenverarbeitung unter Verwendung eines einzelnen Kanals, eines einzelnen Auslösers und eines einzelnen Deskriptors. In diesem Beispiel kann die Kachelstruktur 16x8 sein. 10K ist ein Beispiel dieser Kachelstruktur mit Hardware-Sequenzierung in der Rasterabtastsequenz mit Frame-Adressenverarbeitung unter Verwendung des beispielhaften Frame-Formats 1070A gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Zum Beispiel kann für jede Kachelreihe derselbe Deskriptor (z. B. Kacheldimension) verwendet werden (wie durch „D1“ in der Visualisierung 1072 angegeben), sodass dieselbe Kachel 16 Mal entlang jeder Reihe (von C1 bis C16) angewendet wird und für 8 Reihen (von R1 bis R8) von oben nach unten wiederholt wird. Die Sequenz kann 20 Bytes beinhalten, wie in dem Frame-Format 1070A veranschaulicht, und jede Reihe kann N*2 + Bytes aufweisen, wobei N die Anzahl von Einträgen pro Reihe darstellt (wie in 10J veranschaulicht). Um den Frame wie in Visualisierung 1072 veranschaulicht zu sequenzieren, kann das Frame-Format 1070A somit keine Frame-Wiederholung beinhalten, kann die Anzahl der Deskriptorreihen null sein, kein Kachel-Offset, kein Frame-Offset, Frame-Auffüllung von 3 Pixelzeilen links (PL), rechts (PR), oben (PT) und unten (PB), kann die Reihe kann 7 Mal wiederholt werden (für insgesamt 8 Reihen), kann der Offset jeder Reihe die Kachelhöhe (Ty) sein (sodass jede Reihe um die Kachelhöhe versetzt ist), kann ein Deskriptor mit der Deskriptor-ID D1 verwendet werden und kann der Deskriptor 15 Mal (insgesamt 16 Mal) in jeder Reihe wiederholt werden. Somit kann die HW-Sequenzer-Steuerung in der Praxis den D1 entsprechenden Deskriptor aus dem Deskriptor-SRAM 1052 (der die Kachelhöhe und Kachelbreite beinhaltet) verwenden und kann die Bildstruktur aus dem Frame-Format 1072 verwenden, das in dem HW-Sequenzersteuerungs-SRAM 1054 gespeichert ist, um das Bild Kachel für Kachel (16 Kacheln pro Reihe), Reihe für Reihe (von R1 bis R8) für den Zielprozessor (z. B. eine VPU) zu sequenzieren. Auf diese Weise können ein einzelner Deskriptor, ein einzelner Auslöser und ein einzelner Kanal verwendet werden, wodurch die Programmierkomplexität reduziert wird, während es auch ermöglicht wird, dass das DMA-System 1050 die primäre oder steuernde Komponente in den Interaktionen des DMA-Systems 1050 und der VPU ist.

In einigen Ausführungsformen kann als eine Erweiterung der HW-Sequenzer-Steuerung 1060 ein DMA-Auslösemodus verwendet werden, um einen Softwareeingriff beim Programmieren der VPU zu reduzieren, indem das DMA-System 1050 die Sequenz von Deskriptoren befiehlt. Beispielsweise kann das DMA-System 1050 ein Bild aus einem externen Speicher lesen, das Bild kacheln und die Kacheln für die VPU sequenziell verarbeiten. Um dies zu erleichtern, kann die VPU Start- und Erledigt-Signale bereitstellen. Der VPU-Start kann durch das DMA-System 1050 angesteuert werden, und wenn die VPU die Verarbeitung eines Anweisungsblocks beendet hat, kann die VPU ein Erledigt-Signal an das DMA-System 1050 senden. Somit können das DMA-System 1050 (z. B. die HW-Sequenzer-Steuerung 1060) und die VPU an einem Handshake-Mechanismus teilnehmen, bei dem das DMA-System 1050 der primäre Knoten und die VPU der sekundäre Knoten ist. Dieser DMA-Auslösemodus kann den Aufwand der VPU-Kachelsteuerung minimieren und das Programmiermodell für die DMA-Engine 1056 vereinfachen. Beispielsweise ist ein spezifischer Code zum doppelten Puffern der DMA-Datenbewegung möglicherweise nicht erforderlich, und der DMA-Kernelcode kann unabhängig vom VPU-Kernelcode sein. Somit vereinfacht der DMA-Auslösemodus den VPU-Code, da die Kachelsequenzierung durch das DMA-System unter Verwendung der HW-Sequenzer-Steuerung 1060 gehandhabt wird. Der nachstehende Beispielcode veranschaulicht den VPU-Code vor und nach der DMA-Auslöser-Hinzufügung.

Vor:

Nach:

Wenn die VPU zuvor eine Kachel zum Verschieben nach VMEM angefordert hatte, kann das DMA-System 1050 im Ergebnis nun, da die HW-Sequenzer-Steuerung 1060 die Sequenzierung steuert, das Verschieben der Kachel in den VMEM mit der VPU als Ziel auslösen. Auf diese Weise kann das DMA-System 1050 durch die VPU zu verarbeitende Daten vorab abrufen, und wenn die VPU angibt, dass die Verarbeitung abgeschlossen ist, kann das DMA-System 1050 die nächsten zu verarbeitenden Daten sofort verfügbar haben (z. B. im VMEM) und kann dies der VPU angeben.

Beim Durchführen der Verarbeitung eines oder mehrerer Frame(s) kann die HW-Sequenzer-Steuerung 1060 den/die Deskriptor(en) aus dem Deskriptor-SRAM 1052 abrufen (der die Kacheldimensionen, den Auslösertyp usw. angeben kann) und kann die Bildstruktur aus dem HW-Sequenzerbefehls-SRAM 1054 abrufen. Der HW-Sequenzer-Befehl 1060 - in Kombination mit der Registersteuerung 1058 - kann dann damit beginnen, eine erste Reihe oder Spalte gemäß der Durchquerungsreihenfolge zu durchlaufen und einen ersten (und in Ausführungsformen einzigen) Deskriptor zu verwenden, und kann sich dann auf Grundlage einer Anzahl (z. B. 1-N) von Wiederholungen, die erfüllt werden, wenn zwei oder mehr Deskriptoren verwendet werden, zu einem zweiten Deskriptor bewegen und so weiter. Wenn jede Kachel bestimmt ist, kann die DMA-Engine 1056 die Kacheldaten aus den Quelldaten abrufen und die Kacheldaten in die Zieldaten (z. B. im VMEM) schreiben. Sobald die Daten in das Datenziel geschrieben sind, kann der Prozessor (z. B. eine VPU) durch die HW-Sequenzer-Steuerung 1060 benachrichtigt werden, dass die Daten für den Prozessor verfügbar sind, um mit der Verarbeitung zu beginnen. Dann kann das DMA-System 1050 während der Verarbeitung eine nächste Kachel von Daten basierend auf der Sequenz von der HW-Sequenzer-Steuerung 1060 abrufen und die Daten in das Datenziel schreiben, sodass, wenn der Prozessor angibt, dass die Verarbeitung abgeschlossen ist, die HW-Sequenzer-Steuerung 1060 der VPU (über einen Handshake-Mechanismus) angeben kann, dass die nächsten zu verarbeitenden Daten verfügbar sind, und so weiter, bis die Verarbeitung abgeschlossen ist.

Unter nunmehriger Bezugnahme auf 10L umfasst jeder Block des hierin beschriebenen Verfahrens 1080 einen Rechenprozess, der unter Verwendung einer beliebigen Kombination von Hardware, Firmware und/oder Software ausgeführt werden kann. Beispielsweise können verschiedene Funktionen durch einen Prozessor ausgeführt werden, der im Speicher gespeicherte Anweisungen ausführt. Das Verfahren 1080 kann auch als computerverwendbare Anweisungen dargestellt werden, die auf Computerspeichermedien gespeichert sind. Die Verfahren 1080 kann durch eine eigenständige Anwendung, einen Dienst oder einen gehosteten Dienst (eigenständig oder in Kombination mit einem anderen gehosteten Dienst) oder ein Plug-in zu einem anderen Produkt bereitgestellt werden, um nur einige zu nennen. Desweiteren wird das Verfahren 1080 in Bezug auf das System der 10H beschrieben, aber das Verfahren 1080 kann durch ein beliebiges System, eine beliebige Struktur oder Komponente oder eine beliebige Kombination von Systemen, Strukturen oder Komponenten ausgeführt werden, einschließlich, jedoch nicht beschränkt auf die hierin beschriebenen.

10L ist ein Flussdiagramm für ein Verfahren 1080 für ein DMA-System, das einen Hardware-Sequenzer beinhaltet, gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Das Verfahren 1080 beinhaltet bei Block B1002 das Abrufen einer Kachelstruktur aus einem Deskriptorspeicher und einer Frame-Struktur entsprechend einem Frame aus einem HW-Sequenzer-Befehlsspeicher. Beispielsweise kann die HW-Sequenzer-Steuerung 1060 den/die Deskriptor(en) aus dem Deskriptor-SRAM 1052 abrufen.

Das Verfahren 1080 beinhaltet bei Block B1004 das sequentielle Abrufen von Kacheln des Frames aus dem Quellspeicher. Zum Beispiel kann die Hardware-Sequenzer-Steuerung 1060- in Ausführungsformen in Kombination mit der Registersteuerung 1058 - den Abruf von Kacheln durch die DMA-Engine 1056 aus dem Quellspeicher gemäß der Frame-(oder Bild)-Struktur und der Kachelbeschreibung von dem/den Deskriptor(en) sequenzieren.

Das Verfahren 1080 beinhaltet bei Block B1006 das Schreiben abgerufener Daten, die den Kacheln entsprechen, in einen Zielspeicher. Beispielsweise kann die DMA-Engine 1056 die abgerufenen Daten, die den Kacheln entsprechen, in den Zielspeicher (z. B. VMEM) zur Verarbeitung durch den Zielprozessor (z. B. eine VPU) schreiben.

Das Verfahren 1080 beinhaltet bei Block B1008 das Bereitstellen einer Angabe an einen Prozessor, der dem Zielspeicher zugeordnet ist, dass die abgerufenen Daten im Zielspeicher gespeichert sind. Beispielsweise kann die HW-Sequenzer-Steuerung 1060 dem Prozessor angeben, dass die Daten für eine nächste Kachel zur Verarbeitung vorbereitet sind.

Das Verfahren 1080 beinhaltet bei Block B1010 das Empfangen einer Angabe, dass die Verarbeitung der abgerufenen Daten abgeschlossen ist. Beispielsweise kann der Prozessor nach Abschluss der Verarbeitung dem DMA-System 1050 angeben, dass die Verarbeitung abgeschlossen ist, zu welchem Zeitpunkt eine nächste Datenkachel in den Zielspeicher geladen werden kann (oder vorab geladen worden sein kann), und das DMA-System 1050 kann dasselbe dem Prozessor angeben.

VERWENDUNG EINER VPU ZUM KONFIGURIEREN EINES DMA-SYSTEMS FÜR BEREICHSABHÄNGIGE DATENBEWEGUNG

Beim Abrufen bekannter Datenmuster kann eine Verarbeitungssteuerung ein System mit Direktspeicherzugriff (DMA) konfigurieren und ein Prozessor (z. B. eine Vektorverarbeitungseinheit (VPU)) kann den DMA auslösen und sequenzieren. Wenn jedoch unterschiedliche Datenpunkte oder Merkmale für unregelmäßige oder unbekannte Datenmuster verarbeitet werden, können Herausforderungen bei der Neukonfiguration der Datenbewegung eingeführt werden, da die Merkmals- oder Objektstellen dynamisch berechnet werden. Beispielsweise erfordern Objektnachverfolgungsalgorithmen, Merkmalsnachverfolgungsalgorithmen, Objekterkennungsalgorithmen, Deep-Learning-Algorithmen, die interessierende Bereiche (Regions of Interest - ROI) variabler Größe verwenden, und/oder andere bereichsabhängige Datenbewegungsalgorithmen eine dynamische Anpassung an Adress- und Datenpaare, sodass ein DMA-System die richtigen Informationen abrufen kann, damit sie ein Prozessor - beispielsweise eine VPU - verarbeitet. In herkömmlichen Systemen kann beim Abrufen unbekannter Datenmuster - wie etwa bei der Objektnachverfolgung - eine Verarbeitungssteuerung (z. B. ein R5-Prozessorkern zum Steuern eines programmierbaren Visionsbeschleunigers (PVA)) eine Unterbrechung erfordern, um in den Verarbeitungszyklus einzugreifen, um aktualisierte Informationen zu bestimmen, die durch den Prozessor (z. B. eine VPU) berechnet werden, und den DMA und für eine nächste Iteration neu zu konfigurieren. Somit führt die Verarbeitungssteuerung zusätzliche Latenzen in z. B. einen Nachverfolgungsalgorithmus ein, der eine kurze Reaktionszeit erfordert.

Um die Nachteile herkömmlicher Systeme zu berücksichtigen, die einen Eingriff durch eine Verarbeitungssteuerung erfordern, können die Systeme und Verfahren der vorliegenden Offenbarung den DMA und den Prozessor (z. B. VPU) verwenden, um eine eng gekoppelte Verarbeitungsschleife zu konfigurieren, die es dem DMA ermöglicht, seine Deskriptoren basierend auf Ausgaben des Prozessors neu zu konfigurieren. Somit kann der DMA zur Laufzeit dynamisch umprogrammiert werden, um gewisse Algorithmen zu handhaben, die eine bereichsabhängige Datenbewegung erfordern. Dieser VPU-Konfigurationsmodus kann verwendet werden, um Deskriptoren eines DMA zu aktualisieren, um Merkmalsdaten - einschließlich Stellen - basierend auf Laufzeit-VPU-Berechnungen nachzuverfolgen. Somit kann die VPU eine Liste von Adressen- und Datenpaaren in einem Speicher - wie etwa einem VMEM - festlegen und dann den DMA auslösen, damit er seine eigenen Deskriptoren aktualisiert, um Daten von Bereichen zu sammeln, die neu berechnete Adressen aufweisen. Indem auf eine Schnittstelle zwischen der VPU und dem DMA zurückgegriffen wird, muss die Verarbeitungssteuerung (z. B. ein R5- oder ARM-Verarbeitungskern) möglicherweise nicht eingreifen, sobald die Verarbeitungssteuerung die VPU und den DMA anfänglich konfiguriert, um mit der Verarbeitung zu beginnen. Dieser massenhafte, schnelle und synchrone MMIO-Zugriff zum Aktualisieren von Funktionsdeskriptoren reduziert somit die Latenz bei der Objektnachverfolgung, Merkmalsnachverfolgung, Objekterkennung, Deep Learning und/oder anderen Algorithmen mit bereichsabhängiger Datenbewegung.

Bezugnehmend nun auf 11A veranschaulicht 11A ein Datenflussdiagramm 1100 für einen Prozess zum Konfigurieren eines Systems mit Direktspeicherzugriff (DMA) unter Verwendung einer Vektorverarbeitungseinheit (VPU) gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Es versteht sich, dass diese und andere hierin beschrieben Anordnungen nur als Beispiele aufgeführt werden. Andere Anordnungen und Elemente (z. B. Maschinen, Schnittstellen, Funktionen, Befehle, Gruppierungen von Funktionen usw.) können zusätzlich oder anstelle der gezeigten verwendet werden, und einige Elemente können ganz weggelassen werden. Ferner sind viele der hierin beschriebenen Elemente funktionale Einheiten, die als diskrete oder verteilte Komponenten oder in Verbindung mit anderen Komponenten und in jeder geeigneten Kombination und Position implementiert werden können. Verschiedene hierin als von Einheiten ausgeführt beschriebene Funktionen können durch Hardware, Firmware und/oder Software ausgeführt werden. Beispielsweise können verschiedene Funktionen durch einen Prozessor ausgeführt werden, der im Speicher gespeicherte Anweisungen ausführt. In einigen Ausführungsformen kann der Prozess 1100 durch ein System ausgeführt werden, das ähnlichen Komponenten, Merkmale und/oder Funktionen wie die des beispielhaften autonomen Fahrzeugs 1300 der 13A-13D, der beispielhaften Rechenvorrichtung 1400 der 14 und/oder des beispielhaften Rechenzentrums 1500 der 15 beinhaltet.

Das System, das den Prozess 1100 durchführt, kann eine Verarbeitungssteuerung 1102 (z. B. einen R5-Prozessor, einen ARM-Verarbeitungskern, eine Anweisungssatzarchitektur (ISA), eine X86-Architektur usw.), ein System 1104 mit Direktspeicherzugriff (DMA), eine Vektorverarbeitungseinheit (VPU) 1108 (oder einen anderen Prozessortyp), einen Vektorspeicher (VMEM) 1110 (oder einen anderen Speichertyp) und einen Deskriptor-RAM 1106 beinhalten. In der Praxis kann der VPU-Konfigurationsmodus die DMA-Deskriptoren konfigurieren, indem eine Sequenz nicht zusammenhängender Adressen/Daten-Paare in den DMA-Deskriptor-SRAM geschrieben wird. Der Prozess 1100 kann in Bezug auf einen beispielhaften Merkmals- oder Objektnachverfolgungsalgorithmus beschrieben werden. Dies soll jedoch nicht einschränkend sein, und der Prozess 1100 und das zugrunde liegende System können verwendet werden, um jede Art von Algorithmus auszuführen, wie etwa solche mit bereichsabhängiger Datenbewegung.

Beispielsweise kann eine erste Operation beinhalten, dass die Verarbeitungssteuerung 1102 den DMA 1104 und die VPU 1108 konfiguriert, um eine Verarbeitung einiger Daten durchzuführen, und dann sowohl den DMA 1104 als auch die VPU 1108 zur Verarbeitung auslöst. Beispielsweise kann die Verarbeitungssteuerung 1102 den Deskriptor-RAM 1106 mit einem Startpunkt im Speicher für die Verarbeitung laden und kann die Register der VPU 1108 für die konkrete Art von Operation konfigurieren, die die VPU 1108 an den Daten durchführen wird.

Für eine zweite Operation kann die VPU 1108 den DMA 1104 auslösen, um anfängliche Merkmalsdatenpunkte in dem VMEM 1110 zu lesen. Um beispielsweise mit der Arbeit zu beginnen, benötigt die VPU 1108 Daten vom DMA 1104, daher konfiguriert die VPU 1108 den DMA 1104 zum Laden von Datenpunkten in den VMEM 1110 an einer Stelle, von der die VPU 1108 weiß, dass sie die Daten zur Verarbeitung abrufen kann.

Bei einer dritten Operation kann die VPU 1108 den aktuellen Merkmalsdatensatz verarbeiten und eine nächste nachverfolgte Objekt- oder Merkmalsstelle berechnen. Als Ergebnis kann die VPU 1108 nun eine neue oder aktualisierte Stelle für das nachverfolgte Merkmal oder Objekt berechnet haben.

Bei einer vierten Operation kann die VPU 1108 den VMEM 1110 mit den aktualisierten Stellen unter Verwendung eines VPU-Konfigurationsformats (beschrieben in Bezug auf 11B) aktualisieren und kann dann den DMA 1104 auslösen, damit er seine Deskriptoren in dem Deskriptor-RAM 1106 aktualisiert. Zum Beispiel ist in 11B eine Tabelle 1120, die ein VPU-Konfigurationsformat veranschaulicht, das durch eine VPU in einen Vektorspeicher (VMEM) geschrieben und durch ein DMA-System gelesen wird, gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Beispielsweise kann das Format für jedes Adressen/Daten-Paar vier Bytes für die Adresse und vier Bytes für die Daten beinhalten.

Bei einer fünften Operation kann der DMA 1104 die Deskriptoren im Deskriptor-RAM 1106 aktualisieren, um die richtigen Daten für eine nächste Iteration der Verarbeitung durch die VPU 1108 abzurufen. Beispielsweise kann der DMA 1104 die Adressen/Daten-Paare aus dem VPU-Konfigurationsformat lesen, um Betriebsdeskriptoren mit der aktualisierten Stelle zu patchen. In Ausführungsformen kann es eine Eins-zu-Eins-Entsprechung zwischen Merkmalspunkten und Deskriptoren geben, sodass jedes nachverfolgte Merkmal, Objekt oder jeder nachverfolgte Punkt einen zugeordneten Deskriptor beinhalten kann. Auf diese Weise kann ein Adressen/Daten-Paar für jedes nachverfolgte Merkmal, Objekt oder jeden nachverfolgten Punkt im Laufe der Zeit unter Verwendung eines individuellen Deskriptors aktualisiert werden.

Bei einer sechsten Operation kann der DMA 1104 die neu aktualisierten Deskriptoren im Deskriptor-RAM 1106 verwenden, um neue Merkmalsdaten für die Stelle abzurufen. Beispielsweise kann der DMA 1104 der VPU 1108 angeben, dass die Deskriptoren aktualisiert wurden, und die VPU 1108 kann den DMA 1104 auslösen, damit er die neuen Daten in den VMEM 1110 liest, und so weiter.

Infolgedessen können nach der ersten Konfigurationsoperation durch die Verarbeitungssteuerung die Operationen zwei bis sechs wiederholt werden, um eine eng synchrone VPU-Konfigurationsschleife zu bilden, die einen Eingriff der Verarbeitungssteuerung erfordert - wodurch die Latenz verringert wird, um die kurze Reaktionszeit zu berücksichtigen, die für die Nachverfolgungs- oder Erkennungsalgorithmen erforderlich ist. Da der DMA 1104 außerdem Adressen im Speicher mit neuen aktualisierten Adressen überschreibt, aktualisiert der DMA 1104 Code, den der DMA 1104 betrachten muss, um herauszufinden, was als nächstes abzurufen ist. Dadurch wird der Durchsatz im Gegensatz zu herkömmlichen Systemen erhöht, die sich auf Steuerbusse stützten, um Register mit Adressen und Daten zu aktualisieren. Somit wird der Vorteil des Definierens eines Adress/Daten-Protokolls verwirklicht, bei dem eine variable Menge von Adressstellen mit einer variablen Datenmenge zusammen mit der Art und Weise, wie die Adressen/Daten-Paare aktualisiert werden, aktualisiert werden kann. Dies ermöglicht, dass der DMA 1104 - der eine Breite aufweisen kann, die größer ist als die Breite eines Steuerbusses (z. B. 512 Bits gegenüber 32 Bits) - auf bis zu (zum Beispiel und ohne Einschränkung) 8 Adressen/Daten-Paare gleichzeitig aktualisiert werden kann (wobei jedes Adressen/Daten-Paar wie in 11 B unter Verwendung von 8 Bytes definiert ist).

Obwohl der DMA als unter Verwendung des VPU-Konfigurationsmodus des Prozesses 1100 aktualisiert dargestellt ist, können ferner zusätzliche oder alternative Elemente oder Komponenten des Systems aktualisiert werden. Beispielsweise kann ein Anweisungs-Cache der VPU 1108 unter Verwendung der VPU unter Verwendung eines ähnlichen Ansatzes aktualisiert werden. Als weiteres Beispiel kann ein aktualisiertes Hardware-Sequenzer-Programm geschrieben werden, um den Hardware-Sequenzer-Speicher zu aktualisieren, indem Adressdaten angegeben werden. Dies würde im Wesentlichen das Beschreiben eines Hardware-Sequenzer-RAM mit einem neuen Programm beinhalten - wie etwa des Hardware-Sequenzer-RAM 1054 für die Hardware-Sequenz-Steuerung 1060 der 10H.

Unter nunmehriger Bezugnahme auf 11C umfasst jeder Block des hierin beschriebenen Verfahrens 1150 einen Rechenprozess, der unter Verwendung einer beliebigen Kombination von Hardware, Firmware und/oder Software durchgeführt werden kann. Beispielsweise können verschiedene Funktionen durch einen Prozessor ausgeführt werden, der im Speicher gespeicherte Anweisungen ausführt. Das Verfahren 1150 kann auch als computerverwendbare Anweisungen dargestellt werden, die auf Computerspeichermedien gespeichert sind. Die Verfahren 1150 kann durch eine eigenständige Anwendung, einen Dienst oder einen gehosteten Dienst (eigenständig oder in Kombination mit einem anderen gehosteten Dienst) oder ein Plug-in zu einem anderen Produkt bereitgestellt werden, um nur einige zu nennen. Desweiteren wird das Verfahren 1150 in Bezug auf das System der 11A beschrieben, aber das Verfahren 1150 kann durch ein beliebiges System, eine beliebige Struktur oder Komponente oder eine beliebige Kombination von Systemen, Strukturen oder Komponenten ausgeführt werden, einschließlich, jedoch nicht beschränkt auf die hierin beschriebenen.

11C ist ein Flussdiagramm für ein Verfahren 1150 zum Konfigurieren eines DMA-Systems unter Verwendung einer VPU gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Das Verfahren 1150 beinhaltet bei Block B1102 das Berechnen einer ersten Ausgabe, die einer oder mehreren ersten aktualisierten Stellen eines nachverfolgten Merkmals entspricht, unter Verwendung eines Prozessors und zumindest teilweise basierend auf ersten Daten, die unter Verwendung eines DMA-Systems in den Speicher geschrieben wurden. Beispielsweise kann die VPU 1108 auf Daten aus dem VMEM 1110 zugreifen, die unter Verwendung des DMA 1104 in den VMEM 1110 geschrieben wurden, und kann die Daten verarbeiten, um eine oder mehrere Objektstellen zu berechnen, die einem nachverfolgten Merkmal, Objekt, Punkt usw. entsprechen.

Das Verfahren 1150 beinhaltet bei Block B1104 das Aktualisieren des Speichers unter Verwendung des Prozessors, um zweite Daten zu beinhalten, die für ein oder mehrere Adressen/Daten-Paare repräsentativ sind, die der einen oder den mehreren ersten aktualisierten Stellen entsprechen. Zum Beispiel kann die VPU 1108 nach dem Berechnen der einen oder der mehreren Stellen den VMEM 1110 mit Adressen/Daten-Paaren in einem Format aktualisieren, wie etwa dem Format, das in Bezug auf 11 B beschrieben wurde.

Das Verfahren 1150 beinhaltet bei Block B1106 das Aktualisieren eines oder mehrerer Deskriptoren, die dem nachverfolgten Merkmal entsprechen, unter Verwendung des DMA-Systems und zumindest teilweise basierend auf dem einen oder den mehreren Adressen/Daten-Paaren. Beispielsweise kann der DMA 1104 auf die Adressen/Daten-Paare aus dem VMEM 1110 zugreifen und die Adressen/DatenPaare verwenden, um Deskriptoren in dem Deskriptor-RAM 1106 für eine nächste Leseoperation zu aktualisieren.

Das Verfahren 1150 beinhaltet bei Block B1108 das Schreiben dritter Daten in den Speicher unter Verwendung des DMA-Systems und zumindest teilweise basierend auf dem einen oder den mehreren Deskriptoren. Beispielsweise kann der DMA 1104 die aktualisierten Daten entsprechend den Adressen/Daten-Paaren, wie sie unter Verwendung der Deskriptoren identifiziert wurden, in den VMEM 1110 schreiben.

Das Verfahren 1150 beinhaltet bei Block B1110 das Berechnen einer zweiten Ausgabe, die einer oder mehreren zweiten aktualisierten Stellen des nachverfolgten Merkmals entspricht, unter Verwendung des Prozessors und zumindest teilweise basierend auf den dritten Daten. Sobald sich beispielsweise die aktualisierten Daten in VMEM 1110 befinden, kann die VPU 1108 einen nächsten Satz aktualisierter Adressen/Daten-Paare berechnen, die dem verfolgten Merkmal, Objekt, Punkt usw. entsprechen, und dieser Prozess kann sich wiederholen, bis die Verarbeitung abgeschlossen ist.

PERMANENTE FEHLERERKENNUNG IN EINEM PROGRAMMIERBAREN VISIONSBESCHLEUNIGER (PVA)

In sicherheitskritischen Anwendungen wie autonomen und halbautonomen Maschinenanwendungen gibt strenge Anforderungen an die permanente Fehlererkennung und -isolierung. Wenn beispielsweise Deep Learning, Computer Vision, Sensorverarbeitung und/oder andere Anwendungen in einer Maschine ausgeführt werden, muss die permanente Fehlererkennung regelmäßig und innerhalb eines zugewiesenen Zeitbudgets ausgeführt werden, um genaue Tests zu ermöglichen, aber auch der Anwendung zu ermöglichen, richtig zu funktionieren - z. B. mit geringer Latenz. In Bezug auf Automotive Safety Integrity Level (ASIL) D können Anwendungen, die in der autonomen oder halbautonomen Maschine ausgeführt werden, eine Abdeckung von 90 % oder mehr der permanenten Fehler erfordern. Dazu kann eine Ende-zu-Ende-Abdeckung mit geringer Latenz erforderlich sein, während das Laufzeitbudget jeder konkreten Anwendung eingehalten wird. Herkömmliche Ansätze verwenden einen integrierten Selbsttest (BIST) zum Identifizieren von Fehlern, aber diese BIST-Techniken beinhalten entweder keine angemessene Abdeckung, führen zu viel Latenz in das System ein und/oder erfüllen nicht die Laufzeitbudgets für gewisse Anwendungen.

Die vorliegenden Systeme und Verfahren können, um den Mängeln dieser herkömmlichen Ansätze Rechnung zu tragen, einen Mehrfacheingangs-Signaturregister (MISR)-BIST ausführen - z. B. um eine Fehlererkennung eines programmierbaren Visionsbeschleunigers (PVA) eines Systems auf einem Chip (SoC) durchzuführen. Beispielsweise kann ein PVA in verschiedenen Ausführungsformen der vorliegenden Offenbarung ein oder mehrere DMA-Systeme und eine oder mehrere VPUs beinhalten, die unter Verwendung einer oder mehrerer Verarbeitungssteuerungen (oder Steuerprozessoren), wie etwa einem R5-Prozessor und einem ARM-Prozessor, einer CPU und/oder dergleichen, gesteuert werden. Daher kann jede Komponente des PVA ein Testen erfordern, und die vorliegenden Systeme und Verfahren führen den MISR-BIST aus, um dauerhafte Fehler in einer Ende-zu-Ende-Weise zu erkennen. Auf diese Weise kann die permanente Fehlererkennung ausgeführt werden, um Ende-zu-Ende-Blöcke sowohl für die Steuerals auch für die Datenlogik abzudecken, mit direkter Fehlermeldung an einen Sicherheitsprozessor, um die Latenz zu reduzieren, und mit Anpassung für konkrete Anwendungen, um die damit verbundenen Laufzeitbudgets zu erfüllen.

In verschiedenen Ausführungsformen kann das MISR in dem PVA verwendet werden, um einen Softwarelogik-BIST zur permanenten Fehlererkennung zu implementieren. Die MISR-Hardware - hierin mit Bezug auf 12A und/oder 12B beschrieben - kann eine Hardware für die zyklische Redundanzprüfung (CRC) beinhalten, die - z. B. mit einem bekannten Ausgangswert - unter Verwendung einer Verarbeitungssteuerung initialisiert wird. Beim Ausführen von PVA-Anwendungen kann die Verarbeitungssteuerung einen Teil des Zeitbudgets - z. B. -10 % oder weniger des Zeitbudgets - zuweisen, um einen bekannten Software-MISR-Test mit einer bekannten Eingabe auszuführen, der eine deterministische vorberechnete Ausgabe mit der richtigen Signatur oder einen goldenen Wert aufweist. Wenn beispielsweise ein Zeitbudget 30 Frames pro Sekunde entspricht, kann das Zeitbudget, das 3 oder weniger der Frames entspricht, dem MISR-Testen zugewiesen werden. Zu der/den zugewiesenen Zeit(en) kann die Verarbeitungssteuerung den MISR-Test starten und auf den Abschluss des Tests warten, um die MISR-CRC-Berechnung zu beenden. Sobald das Testen abgeschlossen ist, kann die MISR-Hardware den endgültigen CRC-Wert zurücklesen und den endgültigen CRC-Wert mit einem vorberechneten goldenen Wert vergleichen. Im Falle einer Nichtübereinstimmung kann die MISR-Hardware den Fehler direkt an einen Sicherheitsprozessor eines SoC melden, um weitere Maßnahmen zur Behandlung des Sicherheitsfehlers zu ergreifen - z. B. zu veranlassen, dass Ausgaben der Anwendung ignoriert werden, um den permanenten Fehler zu beheben oder zu umgehen usw.

Somit kann die MISR-Hardware im DMA-Block eine oder mehrere (z. B. alle in Ausführungsformen) der Transaktionen an einem oder mehreren (z. B. allen in Ausführungsformen) der Masterports der fortschrittlichen erweiterten Schnittstelle (AXI) des PVA überwachen. Durch Untersuchen aller Ausgabestufen von dem PVA kann in Ausführungsformen die Sicherheitsintegrität des PVA auf permanente Defekte geprüft werden, die die Ausgabestufe - z. B. die Ausgabeinformationen - beschädigen können, die möglicherweise durch den PVA und/oder eine andere Engine verbraucht werden, wenn sie eine Anwendung ausführen. Die MISR-Hardware kann somit Fehler über unterschiedliche Blöcke des PVA (z. B. die Verarbeitungssteuerung(en), die VPU(s) und das DMA-System(e)) erkennen, da diese Komponenten alle bei der Erzeugung der Ausgabestufe zusammenarbeiten und interagieren. Die berechnete Signatur in der MISR-Hardware kann den Zustand dieser verschiedenen Blöcke des PVA während der Dauer des MISR-Tests darstellen.

In Ausführungsformen kann das MISR-Schema eine CRC-Prüfung sowohl für Schreibadressen (z. B. 40-Bit-Steuerung) als auch für Schreibdaten (z. B. 512-Bit-Daten) beinhalten, die die AXI-Masterports verlassen. Dieses Merkmal kann eine Isolierung der Steuerpfadfehler (z. B. Fehler bei der Adressierung) von den Datenpfadfehlern (z. B. Fehler bei Berechnungen) ermöglichen. Aufgrund der Konfiguration der MISR-Hardware - wie hierin beschrieben - kann jeder DMA-AXI-Port in der Lage sein, überprüft zu werden. In Ausführungsformen kann ein Steuerbit verwendet werden, um das Schreiben der Adress- und Datenausgaben für alle Kanäle zu deaktivieren, die an der MISR-Berechnung teilnehmen, um Bandbreitenverbrauch im Speicherteilsystem und während der Speicherzuweisung zu sparen. Ferner kann das MISR-Schema ein Steuerregisterbit pro Kanal beinhalten, um spezifische Kanäle von der MISR-Berechnung auszuschließen oder zu maskieren - z. B. um Nicht-Sicherheitskanäle zu isolieren. Der DMA kann in Ausführungsformen IEEE 802- und MPEG-CRC-32-Primitive-Polynome verwenden, um den MISR-CRC zu berechnen: X³² + X²⁶ + X²³ + X²² + X¹⁶ + X¹² + X¹¹ + X¹⁰ + X⁸ + X⁷ + X⁵ + X⁴ + X² + X + 1. MISR-SET-Register können verwendet werden, um die Anfangs-CRC-Werte (z. B. Ausgangswerte) sowohl für Adressen- als auch für Daten-CRC-Berechnungen einzustellen. MISR-REF-Register können verwendet werden, um den CRC-Wert sowohl für Adressen- als auch für Daten-CRC-Berechnungen zu vergleichen.

Um MISR an 512-Bit-Daten zu unterstützen, kann eine 8:1-Bit-Datenkomprimierung angewendet werden - z. B. kann jedes Datenbyte über eine 8 > 1-Exklusiv-ODER-Operation (XOR) in 1 Datenbit komprimiert werden, um 2×32-Bit-Nachrichtendaten zu bilden. Um MISR-40-Bit-Adressen zu unterstützen, können 9 höchstwertige Bits komprimiert werden - z. B. können 9 höchstwertige Adressbits über eine 9 > 1 XOR-Operation komprimiert werden, um 32-Bit-Nachrichtenadressen zu bilden. Variationen von Testmustern und Anweisungen können verwendet werden, um ein Aliasing bezüglich der Komprimierung abzudecken. Die Wahrscheinlichkeit, dass Aliasing auftritt, kann gering sein, da bei einer geraden Anzahl von Fehlern in einem Byte im Ausgabebild des Fehlerausfalls keinen Adressen-CRC-Fehler erzeugt. Außerdem kann Aliasing unwahrscheinlich sein, da die Referenz-CRC an einem Ausgabebild berechnet werden kann, das über die gesamte Dauer des MISR-Tests dasselbe Muster an denselben geradzahligen Fehlerbitpositionen aufweist. Bei Versuchen wurde gezeigt, dass Aliasing einen Abdeckungsverlust von durchschnittlich 0,25 % verursacht. Datenkomprimierung mit solch geringem Aliasing ist aufgrund der Breite des Busses - z. B. 512 Bit - in Ausführungsformen sinnvoll, und ohne die Komprimierung kann der MISR-Test die Latenz- oder Laufzeitbudgets des Systems nicht erfüllen.

Ein MISR-Zeitgeberregister kann verwendet werden, um die MISR-Berechnung zeitlich abzugrenzen, und das MISR-Zeitgeberregister kann bei jedem AXI-Takt dekrementiert werden. Das Zeitüberschreitungsmerkmal kann bei Fehlern hilfreich sein, die dazu führen, dass der MISR-Test hängen bleibt, wodurch die MISR-Hardware möglicherweise den Fehler nicht meldet. Ein Softwareereignis kann von der Verarbeitungssteuerung verwendet werden, um die MISR-Berechnung zu stoppen, wenn der MISR-Test endet. Das DMA-System kann den MISR-REF-Wert mit einem MISR-VAL-Wert sowohl für Daten- als auch Adressenausgaben des MISR-Tests vergleichen, und die DMA-Hardware kann MISR-Statusregister basierend auf dem Ergebnis des Vergleichs aktualisieren. Beispielsweise können die MISR-Statusregister einen der folgenden Werte beinhalten: 0: inaktiv; 1: erledigt: Daten fehlgeschlagen; 3: beschäftigt; 4: erledigt: sowohl Adresse als auch Daten fehlgeschlagen; 5: erledigt: Zeitüberschreitung fehlgeschlagen; 6: RSVD; und 7: erledigt: bestanden. Im Fall eines MISR-Zeitüberschreitungsfehlers kann der DMA ein Zeitüberschreitungssignal für den Sicherheitsprozessor generieren, und im Fall eines CRC-Prüffehlers in den Daten und/oder den Adressen kann der DMA dem Sicherheitsprozessor einen Sicherheitsfehler mitteilen.

Unter Bezugnahme auf 12A ist 12A ein Diagramm eines Systems eines integrierten Selbsttests (BIST) zum Durchführen von Berechnungen zur zyklischen Redundanzprüfung (CRC) eines programmierbaren Visionsbeschleunigers (PVA) gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Es versteht sich, dass diese und andere hierin beschrieben Anordnungen nur als Beispiele aufgeführt werden. Andere Anordnungen und Elemente (z. B. Maschinen, Schnittstellen, Funktionen, Befehle, Gruppierungen von Funktionen usw.) können zusätzlich oder anstelle der gezeigten verwendet werden, und einige Elemente können ganz weggelassen werden. Ferner sind viele der hierin beschriebenen Elemente funktionale Einheiten, die als diskrete oder verteilte Komponenten oder in Verbindung mit anderen Komponenten und in jeder geeigneten Kombination und Position implementiert werden können. Verschiedene hierin als von Einheiten ausgeführt beschriebene Funktionen können durch Hardware, Firmware und/oder Software ausgeführt werden. Beispielsweise können verschiedene Funktionen durch einen Prozessor ausgeführt werden, der im Speicher gespeicherte Anweisungen ausführt. In einigen Ausführungsformen kann die MISR-Hardware 1250 ähnliche Komponenten, Merkmale und/oder Funktionen wie die des DMA-Systems 1050 der 10H, des beispielhaften utonomen Fahrzeugs 1300 der 13A-13D, der beispielhaften Rechenvorrichtung 1400 der 14 und/oder des beispielhaften Rechenzentrums 1500 der 15 beinhalten. Beispielsweise kann die MISR-Hardware 1200 in einem DMA-Block eines PVA beinhaltet sein, wie etwa in 10H veranschaulicht. Somit kann die MISR-Hardware 1200 an den Ausgangsstufen der Datenbewegung arbeiten und die Adressierung (oder Steuerung) kann die Ausgaben der DMA-Engine 1056 abgreifen. Im Beispiel der 12A können 16 AXI-Datenkanäle und 16 AXI-Adressenkanäle (oder Steuerkanäle) vorhanden sein. Dies soll jedoch nicht einschränkend sein, und je nach Ausführungsform kann eine beliebige Anzahl (und/oder Art) von Daten- und/oder Adressenkanälen verwendet werden.

Im Betrieb kann eine Verarbeitungssteuerung das DMA-System 1050 und die MISR-Hardware 1200 steuern - ebenso wie eine oder mehrere Verarbeitungskomponenten des Systems, wie etwa eine VPU. Beim Durchführen von MISR-Tests für das DMA-System 1050 kann der Testcode in Ausführungsformen alle Nullen, alle Einsen, abwechselnde Nullen und Einsen und/oder Zufallscodesequenzen beinhalten. Auf diese Weise kann eine hohe Abdeckung für das DMA-System 1050 erreicht werden. Beim Testen der VPU kann der Testcode beispielsweise anwendungsspezifischen oder kundenspezifischen Code beinhalten. Zum Beispiel können während des Testens der Abdeckung für eine konkrete Anwendung die verwendeten Komponenten oder Teile der VPU (z. B. Register, Logik usw.) bestimmt werden, und der Testcode kann so generiert werden, dass diese spezifischen Komponenten oder Teile der VPU in die Ausführung des Testcodes einbezogen sind. Beispielsweise können diese Zufallsdaten mit unterschiedlichen Anweisungen in den Testcode einbezogen werden, sodass der Test durch unterschiedliche Anweisungen sequenziert wird, um unterschiedliche Bereiche der VPU-Logik zu verwenden. Auf diese Weise wird die Abdeckung für die VPU im Allgemeinen und speziell für die konkrete Anwendung, die auf der VPU ausgeführt wird, erhöht. Indem DMA- und VPU-Tests auf diese Weise durchgeführt werden und weil die Verarbeitungssteuerung an der Steuerung und Interaktion zwischen den verschiedenen Komponenten (z. B. DMA-System 1050 und VPU) beteiligt ist, kann die Verarbeitungssteuerung eine hohe Abdeckung aufweisen, das die Ausgaben der Datenbewegungen und -adressierung durch die Interaktionen der Verarbeitungssteuerung beeinflusst wurden.

Wenn während des Testens unterschiedliche Codemuster verwendet werden, können die Codemuster in einem alternierenden Muster verwendet werden, oder ein Code kann für einen ersten Zeitrahmen (z. B. Zeitäquivalent von 30 fps), ein anderer Code für einen zweiten Zeitrahmen (z. B. Zeitäquivalent von 30 fps), ein anderer Code für einen dritten Zeitrahmen (z. B. Zeitäquivalent von 30 fps) und so weiter verwendet werden. Beispielsweise kann in dem DMA-Codebeispiel der Code aus Nullen für einen ersten Zeitrahmen, dann der Code aus Einsen für einen zweiten Zeitrahmen, dann der Code aus abwechselnden Nullen und Einsen (z. B. 0101010101 ...) für einen dritten Zeitrahmen und dann ein Zufallscode (z. B. 011100100010...) für einen vierten Zeitrahmen verwendet werden, und dann können diese vier Codes wiederholt werden, und so weiter.

In der Praxis kann die Verarbeitungssteuerung beispielsweise beim Testen des DMA mit einer MISR-Steuerung 1206 interagieren, um einen festgelegten Referenzwert in das MISR-Datensatzregister 1210 und das MISR-Adressensatzregister 1216 zu schreiben. Diese Werte können für Daten und Adresse unterschiedlich sein und können als Ausgangswerte für die CRC-Berechnungen bezeichnet werden. Die Verarbeitungssteuerung kann dann Kanäle initialisieren, die eine Datenbewegung in der DMA-Engine 1056 durchführen, und da die Stelle des Testcodes im Speicher der Verarbeitungssteuerung bekannt ist, kann der Deskriptor (z. B. wie durch die Verarbeitungssteuerung im Deskriptor-SRAM 1052 konfiguriert) verwendet werden, um die DMA-Engine 1056 durch die Daten für den MISR-Test zu sequenzieren. Die Verarbeitungssteuerung kann einen Zeitgeber 1226 an der MISR-Hardware 1200 setzen, um den MISR-Test zu aktivieren, und kann dann den/die Kanal(e) der DMA-Engine 1056 auslösen, damit sie mit dem Lesen der Testdaten vom Quellziel beginnen und die Daten an die MISR-Hardware 1200 für den MISR-Test ausgeben. Somit wird beim Testen des DMA die Datenbewegung getestet (z. B. richtige Adressierung und richtige Daten in den Adressierungsstellen), sodass die MISR-Hardware 1200 die Ausgaben der DMA-Engine 1056 abgreifen kann, wenn sie die Datenbewegung des Testcodes durchführt. Dieser Abgriff in die Ausgangsstufe kann in 12A als externer Speicher angegeben sein, der kanalisiert werden kann - ein Datenkanal nach dem anderen und ein Adresskanal nach dem anderen - wie durch die Verarbeitungssteuerung sequenziert. Zum Beispiel kann die Verarbeitungssteuerung für die Datenkanäle durch jeden der z. B. 16 Datenkanäle sequenzieren, und die entsprechenden AXI-Schreibdaten (wdata) für jeden Kanal können durch die CH0-CH16-Daten-CRC-Berechnung 1202 - z. B. in Reihe - eingespeist werden. Beispielsweise kann die Verarbeitungssteuerung ein Kanalausgangsregister 1220 so konfigurieren, dass es die Kanäle einzeln gemäß der konfigurierten Sequenz von der Verarbeitungssteuerung sequenziert. In Ausführungsformen kann ein Kanalmaskenregister 1208 (z. B. durch die MISR-Steuerung 1206 basierend auf einer Interaktion mit der Verarbeitungssteuerung programmiert) durch die Verarbeitungssteuerung konfiguriert werden, um verschiedene Kanäle - z. B. nicht getestete Kanäle - aus der CRC-Berechnung zu maskieren oder zu entfernen. Diese Maskierung kann in Ausführungsformen unter Verwendung eines UND-Gatters durchgeführt werden. Wenn ein oder mehrere Kanäle maskiert sind, kann der goldene Wert im MISR-Datenreferenzregister 1222 (der durch die Verarbeitungssteuerung an die MISR-Steuerung 1206 geliefert werden kann) nur den CRC-Berechnungen für die unmaskierten Kanäle entsprechen. Für jeden unmaskierten Kanal können die Daten auf dem Kanal - generiert unter Verwendung des aus dem Speicher gelesenen Testcodes - auf das Polynom der CRC-Datenberechnung 1202 angewendet werden (z. B. mit oder ohne Komprimierung), um einen MISR-Datenwert 1214 für diesen Kanal zu generieren. Sobald ein Kanal mit der Berechnung fertig ist, kann die Verarbeitungssteuerung eine Angabe empfangen und kann veranlassen, dass ein nächster Datenkanal an die CRC-Berechnung 1202 gesendet wird, um einen nächsten MISR-Datenwert 1214 zu berechnen, und so weiter, bis jeder der unmaskierten Kanäle einen entsprechenden MISR-Datenwert 1214 aufweist. Sobald jeder der MISR-Datenwerte 1214 für die konkrete Iteration berechnet wurde, können diese Werte 1214 kombiniert werden, um einen endgültigen MISR-Datenwert zu generieren, der mit einem goldenen Wert im MISR-Datenreferenzregister 1222 verglichen werden kann, um eine MISR-Datenstatusbestimmung zu generieren (die z. B. Statusse beinhalten kann, die den Werten von 0-7 oben entsprechen).

Als weiteres Beispiel kann die Verarbeitungssteuerung für die Adressenkanäle durch jeden der z. B. 16 Adressen- oder Steuerkanäle sequenzieren, und die entsprechende AXI-Schreibadresse (waddress) für jeden Kanal kann durch die CH0-CH16-Adressen-CRC-Berechnung 1204 - z. B. in Reihe - eingespeist werden. In Ausführungsformen kann das Kanalmaskenregister 1208 durch die Verarbeitungssteuerung konfiguriert werden, um verschiedene Kanäle - z. B. nicht getestete Kanäle - aus der CRC-Berechnung zu maskieren oder zu entfernen. Diese Maskierung kann in Ausführungsformen unter Verwendung eines UND-Gatters durchgeführt werden. Wenn ein oder mehrere Kanäle maskiert sind, kann der goldene Wert im MISR-Datenreferenzregister 1224 nur den CRC-Berechnungen für die unmaskierten Kanäle entsprechen. Für jeden unmaskierten Kanal kann die Adresse auf dem Kanal - generiert unter Verwendung des aus dem Speicher gelesenen Testcodes - auf das Polynom der CRC-Adressenberechnung 1204 angewendet werden (z. B. mit oder ohne Komprimierung), um einen MISR-Adressenwert 1218 für diesen Kanal zu generieren. Sobald ein Kanal mit der Berechnung fertig ist, kann die Verarbeitungssteuerung eine Angabe empfangen und kann veranlassen, dass ein nächster Adressenkanal an die CRC-Berechnung 1204 gesendet wird, um einen nächsten MISR-Adressenwert 1218 zu berechnen, und so weiter, bis jeder der unmaskierten Kanäle einen entsprechenden MISR-Adressenwert 1218 aufweist. Sobald jeder der MISR-Adressenwerte 1218 für die konkrete Iteration berechnet wurde, können diese Werte 1218 kombiniert werden, um einen endgültigen MISR-Adressenwert zu generieren, der mit einem goldenen Wert im MISR-Adressenreferenzregister 1224 verglichen werden kann, um eine MISR-Adressenstatusbestimmung zu generieren (die z. B. Statusse beinhalten kann, die den Werten von 0-7 oben entsprechen).

In einigen Ausführungsformen kann der MISR-Test iterativ sein, sodass der erste Code verarbeitet, die Ausgabe getestet und die Ausgabe dann für eine nächste Iteration verwendet werden kann, die getestet werden kann, und so weiter. In solchen Ausführungsformen kann der MISR-Test eine Vielzahl von Stufen beinhalten, und der abgeschlossene MISR-Test kann das Durchführen jeder Stufe beinhalten.

Wenn die MISR-Hardware 1200 verwendet wird, um beispielsweise die VPU speziell zu testen, kann das DMA-System 1050 den Testcode in den VMEM verschieben, die VPU kann den Testcode verarbeiten und die Ergebnisse zurück in den VMEM schreiben, und die DMA-Engine 1056 kann die Ergebnisse aus dem VMEM zurück zu einer Zielstelle lesen. Beim Zurückschreiben der Ergebnisse in die Zielstelle kann die MISR-Hardware 1200 die DMA-Ausgabe abgreifen und das MISR an den Daten (z. B. einschließlich Daten und Adressen) durchführen und das MISR ähnlich wie hierin beschrieben durchführen. Auf diese Weise kann die Interaktion der VPU mit dem Testcode unter Verwendung der MISR-Hardware 1200 getestet werden.

Nach Abschluss des MISR-Tests kann die Verarbeitungssteuerung eine Unterbrechung empfangen. Zum Beispiel kann die Verarbeitungssteuerung eine Erledigt-Unterbrechung empfangen und dort, wo kein Fehler auftritt, auf einen nächsten MISR-Testzyklus warten. Wenn die Unterbrechung eine Fehlerunterbrechung ist, kann die Art des Fehlers bestimmt werden - z. B. Fehler Daten, Fehler Adresse, beide Fehler usw. - und ein Sicherheitsfehler kann dem Sicherheitsprozessor mitgeteilt werden. In einigen Ausführungsformen kann der DMA, wenn sich die MISR-Hardware 1200 aufhängt oder inaktiv ist (z. B. einen Zeitüberschreitungsfehler aufweist), beispielsweise ein Zeitüberschreitungssignal für den Sicherheitsprozessor des SoC generieren.

In einigen Ausführungsformen können die Kanäle, um die MISR-Berechnung zum Berechnen von CRC auf einem oder mehreren (z. B. in Ausführungsformen allen, wie etwa 16) Kanälen zu beschleunigen, ohne die Kanal-MISR-Berechnung zu serialisieren oder einzustufen, basierend auf einer in einem AXI-ID-Feld vorhandenen Kanal-ID demultiplext werden, um die Kanalberechnung zu parallelisieren. Da beispielsweise die CRC-Berechnungen mit unterschiedlichen Raten abgeschlossen werden, beinhaltet der Ansatz von 12A eine serielle Verarbeitung der Kanäle nacheinander. Unter Verwendung des Systems der 12B, die nachstehend beschrieben wird, können diese Berechnungen jedoch parallel abgeschlossen werden. Wenn die Verarbeitungssteuerung beispielsweise die MISR-Berechnung beendet, kann die MISR-Steuerung alle Kanalausgaben sequenzieren, um eine endgültige Signatur zu berechnen, die mit einer Referenz oder einem goldenen Wert sowohl für Adressen- als auch für Datenausgaben verglichen werden kann. Dieses Merkmal kann die permanente Fehlererkennung beschleunigen, ohne dass eine zusätzliche Programmierregisterschnittstelle erforderlich ist - z. B. weil dieselben Steuerregister für alle Kanäle verwendet werden können.

Somit und unter Bezugnahme auf 12B ist 12B ein Diagramm eines Systems eines integrierten Selbsttests (BIST) für parallele Berechnungen zur zyklischen Redundanzprüfung (CRC) eines programmierbaren Visionsbeschleunigers (PVA) gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Es versteht sich, dass diese und andere hierin beschrieben Anordnungen nur als Beispiele aufgeführt werden. Andere Anordnungen und Elemente (z. B. Maschinen, Schnittstellen, Funktionen, Befehle, Gruppierungen von Funktionen usw.) können zusätzlich oder anstelle der gezeigten verwendet werden, und einige Elemente können ganz weggelassen werden. Ferner sind viele der hierin beschriebenen Elemente funktionale Einheiten, die als diskrete oder verteilte Komponenten oder in Verbindung mit anderen Komponenten und in jeder geeigneten Kombination und Position implementiert werden können. Verschiedene hierin als von Einheiten ausgeführt beschriebene Funktionen können durch Hardware, Firmware und/oder Software ausgeführt werden. Beispielsweise können verschiedene Funktionen durch einen Prozessor ausgeführt werden, der im Speicher gespeicherte Anweisungen ausführt. In einigen Ausführungsformen kann die MISR-Hardware 1250 ähnliche Komponenten, Merkmale und/oder Funktionen wie die des DMA-Systems 1050 der 10H, des beispielhaften autonomen Fahrzeugs 1300 der 13A-13D, der beispielhaften Rechenvorrichtung 1400 der 14 und/oder des beispielhaften Rechenzentrums 1500 der 15 beinhalten. Beispielsweise kann die MISR-Hardware 1250 in einem DMA-Block eines PVA beinhaltet sein, wie etwa in 10H veranschaulicht. Somit kann die MISR-Hardware 1250 an den Ausgangsstufen der Datenbewegung arbeiten und die Adressierung (oder Steuerung) kann die Ausgaben der DMA-Engine 1056 abgreifen. Im Beispiel der 12A können 16 AXI-Datenkanäle und 16 AXI-Adressenkanäle (oder Steuerkanäle) vorhanden sein. Dies soll jedoch nicht einschränkend sein, und je nach Ausführungsform kann eine beliebige Anzahl (und/oder Art) von Daten- und/oder Adressenkanälen verwendet werden.

Die MISR-Hardware 1250 kann ähnlich wie die MISR-Hardware 1200 der 12A arbeiten, außer dass die MISR-Hardware 1250 für parallele Datenkanal- und parallele Adressenkanal-CRC-Berechnungen konfiguriert sein kann. Beispielsweise kann die Verarbeitungssteuerung das MISR-Datensatzregister 1256 zum Setzen von Ausgangs- oder Referenzwerten für jede Daten-CRC-Berechnung 1260A-1260N (jeweils entsprechend den AXI-Datenkanälen 0-15) konfigurieren und kann das MISR-Adressensatzregister 1258 zum Setzen von Ausgangs- oder Referenzwerten für jede Adressen-CRC-Berechnung 1262A-1262N (jeweils entsprechend den AXI-Adresskanälen 0-15) konfigurieren. Die Verarbeitungssteuerung kann dann, ähnlich dem in Bezug auf 12A beschriebenen, die Datenbewegung (z. B. für DMA-Testen) und/oder die VPU-Verarbeitung (z. B. für VPU-spezifisches Testen) des DMA-Systems 1050 auslösen, um Daten zu verschieben, und die MISR-Hardware 1250 kann die zu testende(n) Ausgangsstufe(n) abgreifen.

Somit kann die Verarbeitungssteuerung bewirken, dass die 16 Datenkanäle an den Multiplexer (mux) 1252 gesendet werden und die 16 Adressendatenkanäle an den Multiplexer (mux) 1254 gesendet werden. Der Multiplexer 1252 kann dann den entsprechenden Datenkanal an die entsprechende CRC-Berechnung 1260A-1260N liefern (z. B. AXI-Daten von Kanal 0 an die CRC-Berechnung 1260 von Kanal 0, Daten von Kanal 1 an die CRC-Berechnung 1260B von Kanal 1 und so weiter) und jede CRC-Berechnung 1260 kann die Daten und das CRC-Polynom mit dem Referenzwert verwenden, um einen MISR-Datenwert 1284A-1284N zu berechnen (z. B. kann die Kanal-0-CRC-Berechnung 1260A den MISR-Daten0-Wert 1284A berechnen, kann die Kanal-1-CRC-Berechnung 1260B den MISR-Daten1-Wert 1284B berechnen und so weiter). Die MISR-Datenwerte 1284A-1284N können dann aus dem Multiplexer (mux) 1264 gemäß der MISR-Sequenz von der MISR-Steuerung 1270 sequenziert werden, wie durch die Verarbeitungssteuerung konfiguriert. In Ausführungsformen, wie etwa in Bezug auf 12A beschrieben, können ein oder mehrere Kanäle nicht in dem konkreten MISR-Test beinhaltet sein, sodass ein Kanalmaskenregister 1268 durch die Verarbeitungssteuerung konfiguriert werden kann, um die MISR-Sequenz so zu aktualisieren, dass die MISR-Datenwerte 1284, die dem einen oder den mehreren maskierten Kanälen entsprechen, für die Daten-CRC-Berechnung 1274 der Kanäle 0-16 zum Berechnen eines endgültigen CRC-Werts nicht bereitgestellt werden. Für die unmaskierten Kanäle können die MISR-Datenwerte 1284 durch den Multiplexer 1264 gemäß der MISR-Sequenz ausgegeben werden. Auf diese Weise werden die unterschiedlichen Berechnungszeiten für unterschiedliche Kanäle und CRC-Berechnungen 1260 berücksichtigt, da die MISR-Datenwerte 1284 dazu gezwungen werden, gemäß der MISR-Sequenz ausgegeben zu werden, anstatt gemäß dem Timing der abgeschlossenen CRC-Berechnung an die CRC-Berechnung 1274 gesendet zu werden. Sobald die MISR-Sequenz von MISR-Datenwerten 1284 durch den Multiplexer 1264 an die CRC-Berechnung 1274 ausgegeben ist, kann die CRC-Berechnung 1274 einen endgültigen CRC-Wert berechnen und den endgültigen CRC-Wert im VAL-Register 1276 speichern. Der endgültige CRC-Wert im VAL-Register 1276 kann dann mit einem goldenen Wert im MISR-Datenreferenzregister 1272 (wie durch die MISR-Steuerung 1270 von der Verarbeitungssteuerung konfiguriert) verglichen werden, um den MISR-Datenstatus zu bestimmen.

In ähnlicher Weise kann die Verarbeitungssteuerung veranlassen, dass die 16 Adressenkanäle an den Multiplexer (mux) 1254 gesendet werden, und der Multiplexer 1254 kann dann den entsprechenden Adressenkanal an die entsprechende CRC-Berechnung 1262A-1262N liefern (z. B. AXI-Adresse von Kanal 0 an CRC-Berechnung 1262 von Kanal 0, Adresse von Kanal 1 an CRC-Berechnung 1262B von Kanal 1 und so weiter), und jede CRC-Berechnung 1262 kann die Adresse und das CRC-Polynom mit dem Referenzwert verwenden, um einen MISR-Adresswert 1286A-1286N zu berechnen (z. B. kann die Kanal-0-CRC-Berechnung 1262A den MISR-Adresse0-Wert 1286A berechnen, kann die Kanal-1-CRC-Berechnung 1262B den MISR-Adresse1-Wert 1286B berechnen und so weiter). Die MISR-Adressenwerte 1286A-1286N können dann aus dem Multiplexer (mux) 1266 gemäß der MISR-Sequenz von der MISR-Steuerung 1270 sequenziert werden, wie durch die Verarbeitungssteuerung konfiguriert. In Ausführungsformen, wie etwa in Bezug auf 12A beschrieben, können ein oder mehrere Kanäle nicht in dem konkreten MISR-Test beinhaltet sein, sodass ein Kanalmaskenregister 1268 durch die Verarbeitungssteuerung konfiguriert werden kann, um die MISR-Sequenz so zu aktualisieren, dass die MISR-Adressenwerte 1286, die dem einen oder den mehreren maskierten Kanälen entsprechen, für die Adressen-CRC-Berechnung 1280 der Kanäle 0-16 zum Berechnen eines endgültigen CRC-Werts nicht bereitgestellt werden. Für die unmaskierten Kanäle können die MISR-Adressenwerte 1286 durch den Multiplexer 1266 gemäß der MISR-Sequenz ausgegeben werden. Auf diese Weise werden die unterschiedlichen Berechnungszeiten für unterschiedliche Kanäle und CRC-Berechnungen 1262 berücksichtigt, da die MISR-Adressenwerte 1286 dazu gezwungen werden, gemäß der MISR-Sequenz ausgegeben zu werden, anstatt gemäß dem Timing der abgeschlossenen CRC-Berechnung an die CRC-Berechnung 1280 gesendet zu werden. Sobald die MISR-Sequenz von MISR-Adressenwerten 1286 durch den Multiplexer 1266 an die CRC-Berechnung 1280 ausgegeben ist, kann die CRC-Berechnung 1280 einen endgültigen CRC-Wert berechnen und den endgültigen CRC-Wert im VAL-Register 1282 speichern. Der endgültige CRC-Wert im VAL-Register 1282 kann dann mit einem goldenen Wert im MISR-Adressenreferenzregister 1278 (wie durch die MISR-Steuerung 1270 von der Verarbeitungssteuerung konfiguriert) verglichen werden, um den MISR-Adressenstatus zu bestimmen.

Der MISR-Datenstatus und der MISR-Adressenstatus können ähnlich wie in der obigen Beschreibung in Bezug auf 12A überprüft und verwendet werden.

Bezugnehmend nun auf 12C umfasst jeder Block des hierin beschriebenen Verfahrens 1290 einen Rechenprozess, der unter Verwendung einer beliebigen Kombination von Hardware, Firmware und/oder Software durchgeführt werden kann. Beispielsweise können verschiedene Funktionen durch einen Prozessor ausgeführt werden, der im Speicher gespeicherte Anweisungen ausführt. Das Verfahren 1290 kann auch als computerverwendbare Anweisungen dargestellt werden, die auf Computerspeichermedien gespeichert sind. Die Verfahren 1290 kann durch eine eigenständige Anwendung, einen Dienst oder einen gehosteten Dienst (eigenständig oder in Kombination mit einem anderen gehosteten Dienst) oder ein Plug-in zu einem anderen Produkt bereitgestellt werden, um nur einige zu nennen. Desweiteren wird das Verfahren 1290 in Bezug auf das System der 12A beschrieben, aber das Verfahren 1290 kann durch ein beliebiges System, eine beliebige Struktur oder Komponente oder eine beliebige Kombination von Systemen, Strukturen oder Komponenten ausgeführt werden, einschließlich, jedoch nicht beschränkt auf die hierin beschriebenen.

12C ist ein Flussdiagramm für ein Verfahren 1290 zum Ausführen (BIST) für die permanente Fehlererkennung in einem PVA gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Das Verfahren 1290 beinhaltet bei Block B1202 das Empfangen einer Vielzahl von Datenkanälen von einem DMA-System, jeweils einen Kanal nach dem anderen und basierend auf einer Sequenzierung der Verarbeitungssteuerung. Beispielsweise kann die MISR-Hardware 1200 einen Datenkanal (oder einen Kanal von Adressendaten) zu einem Zeitpunkt gemäß einer durch die Verarbeitungssteuerung bestimmten Sequenz empfangen.

Das Verfahren 1290 beinhaltet bei Block B1204 das Berechnen einer Vielzahl von MISR-Werten durch Durchführen einer CRC-Berechnung für jeden Kanal unter Verwendung eines Polynoms der CRC-Berechnung und jeweiliger Daten, die dem Kanal entsprechen, um einen MISR-Wert zu berechnen. Beispielsweise kann die CRC-Berechnung 1202 (oder 1204 für Adressen) für jeden Kanal einen MISR-Datenwert 1214 (oder einen MISR-Adressenwert 1216 für Adressen) unter Verwendung der Daten (oder Adresse) von dem Kanal und eines Polynoms der CRC-Berechnung 1202 (beginnend mit einem Ausgangswert aus dem CRC-MISR-Datensatzregister 1210 oder dem MISR-Adressensatzregister 1216) berechnen.

Das Verfahren 1290 beinhaltet bei Block B1206 das Berechnen eines endgültigen MISR-Werts unter Verwendung der Vielzahl von MISR-Werten. Beispielsweise können die MISR-Datenwerte 1214 von jedem Kanal (oder die MISR-Adressenwerte von jedem Kanal) kombiniert werden, um einen endgültigen MISR-Wert zu generieren.

Das Verfahren 1290 beinhaltet bei Block B1208 das Vergleichen des endgültigen MISR-Werts mit einem Signaturwert. Beispielsweise kann der aus den einzelnen MISR-Werten 1214 (oder Adresswerten 1216) generierte endgültige MISR-Wert mit einer Signatur oder einem goldenen Wert des MISR-Datenreferenzregisters 1222 (oder des MISR-Adressreferenzregisters 1224 für Adressen) verglichen werden.

Das Verfahren 1290 beinhaltet bei Block B1210 das Ausgeben eines MISR-Status zumindest teilweise basierend auf dem Vergleich. Zum Beispiel kann basierend auf dem Vergleich bei Block B1208 ein Status - z. B. Fehler Daten, Fehler Adresse, beide Fehler, erledigt usw. - bestimmt werden, und dieser Status kann verwendet werden, um den Sicherheitsprozessor des SoC zu benachrichtigen, wenn ein Fehlerstatus generiert ist.

BEISPIELHAFTES AUTONOMES FAHRZEUG

13A ist eine Veranschaulichung eines Beispiels für ein autonomes Fahrzeug 1300 gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Das autonome Fahrzeug 1300 (hier alternativ als „Fahrzeug 1300“ bezeichnet) kann ohne Einschränkung ein Personenfahrzeug beinhalten, wie etwa ein Auto, einen Lastwagen, einen Bus, ein Rettungsfahrzeug, ein Shuttle, ein elektrisches oder motorisiertes Fahrrad, ein Motorrad, ein Feuerwehrauto, ein Polizeifahrzeug, einen Krankenwagen, ein Boot, ein Baufahrzeug, ein Unterwasserfahrzeug, eine Drohne, ein an einen Anhänger gekoppeltes Fahrzeug und/oder eine andere Art von Fahrzeug (das z. B. unbemannt ist und/oder einen oder mehrere Passagiere beherbergt). Autonome Fahrzeuge werden im Allgemeinen im Hinblick auf Automatisierungslevels beschrieben, die von der National Highway Traffic Safety Administration (NHTSA), einer Abteilung des US-Verkehrsministeriums, und der Society of Automotive Engineers (SAE) „Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road Motor Vehicles“ (z. B. Standard Nr. J3016-201806, veröffentlicht am 15. Juni 2018, Standard Nr. J3016-201609, veröffentlicht am 30. September 2016, sowie frühere und zukünftige Versionen dieses Standards) definiert sind. Das Fahrzeug 1300 kann zu einer Funktionalität gemäß einem oder mehreren von Level 3 - Level 5 der Levels für autonomes Fahren in der Lage sein. Zum Beispiel kann das Fahrzeug 1300 in Abhängigkeit von der Ausführungsform zu einer bedingten Automatisierung (Level 3), einer hohen Automatisierung (Level 4) und/oder einer vollständigen Automatisierung (Level 5) in der Lage sein.

Das Fahrzeug 1300 kann Komponenten wie etwa ein Fahrgestell, eine Fahrzeugkarosserie, Räder (z. B. 2, 4, 6, 8, 18 usw.), Reifen, Achsen und andere Komponenten eines Fahrzeugs beinhalten. Das Fahrzeug 1300 kann ein Antriebssystem 1350 beinhalten, wie etwa eine Brennkraftmaschine, ein Hybridelektrotriebwerk, einen vollelektrischen Motor und/oder einen anderen Typ von Antriebssystem. Das Antriebssystem 1350 kann mit einem Antriebsstrang des Fahrzeugs 1300 verbunden sein, der ein Getriebe beinhalten kann, um den Antrieb des Fahrzeugs 1300 zu ermöglichen. Das Antriebssystem 1350 kann als Reaktion auf das Empfangen von Signalen von der Drossel/dem Fahrpedal 1352 gesteuert werden.

Ein Lenksystem 1354, das ein Lenkrad beinhalten kann, kann verwendet werden, um das Fahrzeug 1300 zu lenken (z. B. entlang eines gewünschten Pfads oder einer gewünschten Route), wenn das Antriebssystem 1350 in Betrieb ist (z. B., wenn das Fahrzeug in Bewegung ist). Das Lenksystem 1354 kann Signale von einem Lenkaktor 1356 empfangen. Für die vollständige Automatisierungsfunktionalität (Level 5) kann das Lenkrad optional sein.

Das Bremssensorsystem 1346 kann verwendet werden, um die Fahrzeugbremsen als Reaktion auf das Empfangen von Signalen von den Bremsaktoren 1348 und/oder Bremssensoren zu betreiben.

Die Steuerung(en) 1336, die ein oder mehrere Systeme on Chips (SoCs) 1304 (13C) und/oder GPU(s) beinhalten kann/können, kann/können Signale (z. B. stellvertretend für Befehle) für eine oder mehrere Komponenten und/oder Systeme des Fahrzeugs 1300 bereitstellen. Die Steuerung(en) kann/können z. B. Signale zur Betätigung der Fahrzeugbremsen über einen oder mehrere Bremsaktoren 1348, zur Betätigung des Lenksystems 1354 über einen oder mehrere Lenkaktoren 1356, um das Antriebssystem 1350 über einen oder mehrere Drossel-/Fahrpedalaktoren 1352 zu betreiben, senden. Die Steuerung(en) 1336 kann/können eine oder mehrere bordeigene (z. B. integrierte) Rechenvorrichtungen (z. B. Supercomputer) beinhalten, die Sensorsignale verarbeiten und Betriebsbefehle ausgeben (z. B. Signale, die Befehle darstellen), um autonomes Fahren zu ermöglichen und/oder einen menschlichen Fahrer beim Führen des Fahrzeugs 1300 zu unterstützen. Die Steuerung(en) 1336 kann/können eine ersten Steuerung 1336 für Funktionen des autonomen Fahrens, eine zweiten Steuerung 1336 für funktionelle Sicherheitsfunktionen, eine dritte Steuerung 1336 für eine Funktionalität der künstlichen Intelligenz (z. B. maschinelles Sehen), eine vierte Steuerung 1336 für eine Infotainment-Funktionalität, eine fünfte Steuerung 1336 für Redundanz in Notfällen und/oder andere Steuerungen beinhalten. In einigen Beispielen kann ein einzelner Steuerungen 1336 zwei oder mehr der vorstehenden Funktionalitäten handhaben, können zwei oder mehr Steuerungen 1336 eine einzelne Funktionalität handhaben und/oder eine beliebige Kombination davon.

Die Steuerung(en) 1336 stellt/stellen Signale zum Steuern einer/eines oder mehrerer Komponenten und/oder Systeme des Fahrzeugs 1300 als Reaktion auf Sensordaten bereit, die von einem oder mehreren Sensoren empfangen werden (z. B. Sensoreingaben). Die Sensordaten können zum Beispiel und ohne Einschränkung empfangen werden von Sensor(en) 1358 von globalen Navigationssatellitensystemen (z. B. Sensor(en) des globalen Positionsbestimmungssystems), RADAR-Sensor(en) 1360, Schwingungssensor(en) 1362, LIDAR-Sensor(en) 1364, Sensor(en) 1366 einer Trägheitsmesseinheit (inertial measurement unit - IMU) (z. B. Beschleunigungsmesser(n), Gyroskop(en), Magnetkompass(en), Magnetometer(n) usw.), Mikrofon(en) 1396, Stereokamera(s) 1368, Weitsichtkamera(s) 1370 (z. B. Fischaugenkameras), Infrarotkamera(s) 1372, Rundumkamera(s) 1374 (z. B. 360-Grad-Kameras), Langstrecken- und/oder Mittelstreckenkamera(s) 1398, Geschwindigkeitssensor(en) 1344 (z. B. zum Messen der Geschwindigkeit des Fahrzeugs 1300), Schwingungssensor(en) 1342, Lenksensor(en) 1340, Bremssensor(en) (z. B. als Teil des Bremssensorsystems 1346) und/oder anderen Sensortypen.

Eine oder mehrere der Steuerung(en) 1336 kann/können Eingaben (z. B. durch Eingabedaten dargestellt) von einem Kombiinstrument 1332 des Fahrzeugs 1300 empfangen und Ausgaben (z. B. durch Ausgabedaten, Anzeigedaten usw. dargestellt) über eine Anzeige 1334 einer Mensch-Maschine-Schnittstelle (human-machine interface - HMI), einen akustischen Melder, einen Lautsprecher und/oder über andere Komponenten des Fahrzeugs 1300 bereitstellen. Die Ausgaben können Informationen wie etwa Fahrzeuggeschwindigkeit, Drehzahl, Zeit, Abbildungsdaten (z. B. die HD-Karte 1322 aus 13C), Standortdaten (z. B. den Standort des Fahrzeugs 1300, wie etwa auf einer Karte), Richtung, Standort von anderen Fahrzeugen (z. B. ein Belegungsraster), Informationen über Objekte und Status von Objekten, wie sie durch die Steuerung(en) 1336 wahrgenommen werden, usw. beinhalten. Zum Beispiel kann die HMI-Anzeige 1334 Informationen über das Vorhandensein eines oder mehrerer Objekte (z. B. eines Straßenschilds, eines Warnschilds, einer umschaltenden Ampel usw.) und/oder Informationen über Fahrmanöver, die das Fahrzeug vorgenommen hat, vornimmt oder vornehmen wird (z. B. dass es jetzt die Spur wechselt, in zwei Meilen Ausfahrt 34B nimmt usw.), anzeigen.

Das Fahrzeug 1300 beinhaltet ferner eine Netzwerkschnittstelle 1324, die drahtlose Antenne(n) 1326 und/oder Modem(s) zum Kommunizieren über ein oder mehrere Netzwerke verwenden kann. Zum Beispiel kann die Netzwerkschnittstelle 1324 zur Kommunikation über LTE, WCDMA, UMTS, GSM, CDMA2000 usw. fähig sein. Die drahtlose(n) Antenne(n) 1326 kann bzw. können zudem die Kommunikation zwischen Objekten in der Umgebung (z. B. Fahrzeugen, mobilen Vorrichtungen usw.) unter Verwendung von (einem) lokalen Netz(en) wie etwa Bluetooth, Bluetooth LE, Z-Wave, ZigBee usw. und/oder Weitverkehrsnetz(en) mit geringem Stromverbrauch (low power wide-area networks - LPWANs) wie etwa LoRaWAN, SigFox usw. ermöglichen.

13B ist ein Beispiel für die Positionen und Sichtfelder der Kameras für das autonome Fahrzeug 1300 von 13A, gemäß einiger Ausführungsformen der vorliegenden Offenbarung. Die Kameras und die entsprechenden Sichtfelder stellen eine beispielhafte Ausführungsform dar und sind nicht als einschränkend aufzufassen. Zum Beispiel können zusätzliche und/oder alternative Kameras enthalten sein und/oder die Kameras können sich an unterschiedlichen Stellen an dem Fahrzeug 1300 befinden.

Die Kameratypen für Kameras können Digitalkameras beinhalten, ohne darauf beschränkt zu sein, die zur Verwendung mit den Komponenten und/oder Systemen des Fahrzeugs 1300 ausgelegt sind. Die Kamera(s) können mit dem Automobilsicherheitsintegritätslevel (automotive safety integrity level - ASIL) B und/oder mit einem anderen ASIL betrieben werden. Die Kameraarten können in Abhängigkeit von der Ausführungsform zu einer beliebigen Bildaufnahmerate in der Lage sein, wie etwa 60 Bilder pro Sekunde (frames per second -fps), 120 fps, 240 fps usw. Die Kameras können dazu in der Lage sein, Rollblendenverschlüsse, globale Blendenverschlüsse, einen anderen Typ von Blendenverschluss oder eine Kombination davon zu verwenden. In einigen Beispielen kann eine Farbfilteranordnung eine Rot-Klar-Klar-Klar(red clear clear clear - RCCC)-Farbfilteranordnung, eine Rot-Klar-Klar-Blau(red clear clear blue - RCCB)-Farbfilteranordnung, eine Rot-Blau-Grün-Klar(red blue green clear - RBGC)-Farbfilteranordnung, eine Foveon-X3-Farbfilteranordnung, ein Bayer-Sensoren(RGGB)-Farbfilteranordnung, eine Monochrom-Sensor-Farbfilteranordnung und/oder eine andere Art von Farbfilteranordnung beinhalten. In einigen Ausführungsformen können Klarpixelkameras, wie zum Beispiel Kameras mit einer RCCC-, einer RCCB- und/oder einer RBGC-Farbfilteranordnung, in einem Bestreben zur Erhöhung der Lichtempfindlichkeit verwendet werden.

In einigen Beispielen können eine oder mehrere der Kamera(s) verwendet werden, um Funktionen der weiterentwickelten Fahrerassistenzsysteme (advanced driver assistance systems - ADAS) durchzuführen (z. B. als Teil einer redundanten oder ausfallsicheren Ausgestaltung). Zum Beispiel kann eine Multifunktions-Monokamera installiert sein, die Funktionen wie Spurverlassenswarnung, Verkehrszeichenassistent und intelligente Scheinwerfersteuerung bereitstellt. Eine oder mehrere der Kamera(s) (z. B. alle von den Kameras) können simultan Bilddaten (z. B. ein Video) aufnehmen und bereitstellen.

Eine oder mehrere der Kameras können in einer Montagebaugruppe, z. B. einer kundenspezifisch entworfenen (3D-gedruckten) Baugruppe, montiert sein, um Streulicht und Reflexionen aus dem Inneren des Autos (z. B. Reflexionen vom Armaturenbrett, die sich in den Windschutzscheibenspiegeln spiegeln) auszuschließen, welche die Bilddatenerfassungsfähigkeiten der Kamera beeinträchtigen können. Unter Bezugnahme auf Außenspiegel-Montagebaugruppen können die Außenspiegelbaugruppen kundenspezifisch in 3D gedruckt werden, sodass die Kameramontageplatte der Form des Außenspiegels entspricht. In einigen Beispielen kann die Kamera(s) in den Außenspiegel integriert sein. Bei Seitensichtkameras können die Kamera(s) auch in vier Säulen an jeder Ecke des Fahrerhauses integriert sein.

Kameras mit einem Sichtfeld, die Abschnitte der Umgebung vor dem Fahrzeug 1300 beinhalten (z. B. nach vorn gerichtete Kameras), können für die Rundumsicht verwendet werden, um dabei zu helfen, nach vorn gerichtete Pfade und Hindernisse zu identifizieren, sowie mit Hilfe einer oder mehrerer Steuerungen 1336 und/oder Steuer-SoCs beim Bereitstellen von Informationen zu helfen, die für die Erzeugung eines Belegungsgitters und/oder die Bestimmung bevorzugter Fahrzeugpfade entscheidend sind. Nach vorn gerichtete Kameras können verwendet werden, um viele der gleichen ADAS-Funktionen wie LIDAR auszuführen, einschließlich Notbremsung, Fußgängererkennung und Kollisionsvermeidung. Nach vorn gerichtete Kameras können auch für ADAS-Funktionen und -Systeme verwendet werden, einschließlich Spurverlassenswarnungen (Lane Departure Warning - LDW), autonome Geschwindigkeitssteuerung (Autonomous Cruise Control - ACC) und/oder andere Funktionen wie Verkehrszeichenerkennung.

Eine Vielfalt an Kameras kann in einer nach vorn gerichteten Konfiguration verwendet werden, einschließlich zum Beispiel einer monokularen Kameraplattform, die einen Farbbildsensor mit CMOS (complementary metal oxide semiconductor - komplementärer Metalloxid-Halbleiter) beinhaltet. Ein weiteres Beispiel kann eine Weitsichtkamera(s) 1370 sein, die verwendet werden kann, um Objekte wahrzunehmen, die aus der Peripherie ins Blickfeld kommen (z. B. Fußgänger, kreuzender Verkehr oder Fahrräder). Obwohl in 13B nur eine Weitsichtkamera 1370 veranschaulicht ist, kann eine beliebige Anzahl von Weitsichtkameras an dem Fahrzeug 1300 vorhanden sein. Zusätzlich kann eine Langstreckenkamera(s) 1398 (z. B. ein Weitsichtstereokamerapaar) zur tiefenbasierten Objektdetektion verwendet werden, insbesondere für Objekte, für die ein neuronales Netz noch nicht trainiert worden ist. Die Langstreckenkamera(s) 1398 können auch zur Objektdetektion und -klassifizierung sowie zur grundlegenden Objektverfolgung verwendet werden.

Eine oder mehrere Stereokameras 1368 können auch in einer nach vorne gerichteten Konfiguration beinhalten. Die Stereokamera(s) 1368 können eine integrierte Steuereinheit beinhalten, die eine skalierbare Verarbeitungseinheit umfasst, die eine programmierbare Logik (FPGA) und einen Mehrkern-Mikroprozessor mit einer integrierten Schnittstelle für ein CAN oder Ethernet auf einem einzelnen Chip bereitstellen kann. Eine solche Einheit kann verwendet werden, um eine 3D-Karte der Umgebung des Fahrzeugs zu erzeugen, die eine Abstandsschätzung für alle Punkte im Bild beinhaltet. Eine alternative Stereokamera(s) 1368 können (einen) kompakte(n) Stereosichtsensor(en) beinhalten, die zwei Kameraobjektive (je eines links und rechts) und einen Bildverarbeitungschip beinhalten können, die den Abstand von dem Fahrzeug zu dem Zielobjekt messen und die erzeugten Informationen (z. B. Metadaten) verwenden können, um die autonome Notbrems- und Spurverlassenswarnfunktionen zu aktivieren. Andere Typen von Stereokamera(s) 1368 können zusätzlich oder alternativ zu den hierin beschriebenen verwendet werden.

Kameras mit einem Sichtfeld, das Abschnitte der Umgebung seitlich des Fahrzeugs 1300 einschließt (z. B. Seitensichtkameras), können für die Rundumsicht verwendet werden, wodurch Informationen bereitgestellt werden, die zur Erstellung und Aktualisierung des Belegungsgitters sowie zur Erzeugung von Seitenaufprallkollisionswarnungen verwendet werden. Zum Beispiel könnten die Rundumkamera(s) 1374 (z. B. vier Rundumkameras 1374, wie in 13B veranschaulicht) an dem Fahrzeug 1300 positioniert sein. Die Rundumkamera(s) 1374 können Weitsichtkamera(s) 1370, Fischaugenkamera(s), 360-Grad-Kamera(s) und/oder ähnliches beinhalten. Zum Beispiel können vier Fischaugenkameras vorne, hinten und an den Seiten des Fahrzeugs angebracht werden. In einer alternativen Anordnung kann das Fahrzeug drei Rundumkamera(s) 1374 (z. B. links, rechts und hinten) verwenden und kann eine oder mehrere andere Kamera(s) (z. B. eine nach vorn gerichtete Kamera) als eine vierte Rundumsichtkamera nutzen.

Kameras mit einem Sichtfeld, das Abschnitte der Umgebung hinter dem Fahrzeug 1300 einschließt (z. B. Rückfahrkameras), können als Einparkhilfe, für die Rundumsicht, Heckkollisionswarnungen und das Erstellen und Aktualisieren des Belegungsgitters verwendet werden. Es kann eine große Vielfalt an Kameras verwendet werden, einschließlich unter anderem Kameras, die auch als nach vorne gerichtete Kamera(s) (z. B. Kamera(s) 1398 mit langer und/oder mittlerer Reichweite, Stereokamera(s) 1368, Infrarotkamera(s) 1372 usw.) geeignet sind, wie hier beschrieben.

13C ist ein Blockdiagramm einer beispielhaften Systemarchitektur für das beispielhafte autonome Fahrzeug 1300 von 13A, gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Es versteht sich, dass diese und andere hierin beschriebene Anordnungen nur als Beispiele aufgeführt werden. Andere Anordnungen und Elemente (z. B. Maschinen, Schnittstellen, Funktionen, Befehle, Gruppierungen von Funktionen usw.) können zusätzlich oder anstelle der gezeigten verwendet werden, und einige Elemente können ganz weggelassen werden. Ferner sind viele der hierin beschriebenen Elemente funktionale Einheiten, die als diskrete oder verteilte Komponenten oder in Verbindung mit anderen Komponenten und in jeder geeigneten Kombination und Position implementiert werden können. Verschiedene hierin als von Einheiten ausgeführt beschriebene Funktionen können durch Hardware, Firmware und/oder Software ausgeführt werden. Beispielsweise können verschiedene Funktionen durch einen Prozessor ausgeführt werden, der im Speicher gespeicherte Anweisungen ausführt.

Jede(s) der Komponenten, Merkmale und Systeme des Fahrzeugs 1300 in 13C sind als über den Bus 1302 verbunden veranschaulicht. Der Bus 1302 kann eine Controller Area Network (CAN)-Datenschnittstelle beinhalten (hier alternativ als „CAN-Bus“ bezeichnet). Ein CAN kann ein Netz innerhalb des Fahrzeugs 1300 sein, das verwendet wird, um die Steuerung verschiedener Merkmale und Funktionen des Fahrzeugs 1300 zu unterstützen, wie etwa Betätigung von Bremsen, Beschleunigung, Bremsung, Lenkung, Windschutzscheibenwischer usw. Ein CAN-Bus kann so konfiguriert sein, dass er dutzende oder sogar hunderte von Knoten aufweist, von denen jeder eine eigene eindeutige Kennung (z. B. eine CAN-ID) aufweist. Der CAN-Bus kann ausgelesen werden, um Lenkradwinkel, Geschwindigkeit über Grund, Motorumdrehungen pro Minute (revolutions per minute - RPMs), Tastenpositionen und/oder andere Fahrzeugstatusindikatoren zu ermitteln. Der CAN-Bus kann ASIL B-konform sein.

Obwohl der Bus 1302 hier als CAN-Bus beschrieben wird, ist dies nicht als Einschränkung zu verstehen. Zum Beispiel können zusätzlich zu oder alternativ zum CAN- Bus auch FlexRay und/oder Ethernet eingesetzt werden. Obwohl der Bus 1302 mit einer einzigen Linie dargestellt wird, ist dies nicht als Einschränkung zu verstehen. Zum Beispiel kann eine beliebige Anzahl von Bussen 1302 vorhanden sein, die einen oder mehr CAN-Busse, einen oder mehr FlexRay-Busse, einen oder mehr Ethernet-Busse und/oder einen oder mehr andere Arten von Bussen mit einem anderen Protokoll beinhalten können. In einigen Beispiel können zwei oder mehr Busse 1302 verwendet werden, um unterschiedliche Funktionen durchzuführen, und/oder können sie zur Redundanz verwendet werden. Zum Beispiel kann ein erster Bus 1302 für die Funktionalität der Kollisionsvermeidung verwendet werden und ein zweiter Bus 1302 für die Betätigungssteuerung verwendet werden. In jedem Beispiel kann jeder Bus 1302 mit beliebigen Komponenten des Fahrzeugs 1300 kommunizieren und können zwei oder mehr Busse 1302 mit denselben Komponenten kommunizieren. In einigen Beispielen können jedes SOC 1304, jede Steuerung 1336 und/oder jeder Computer im Fahrzeug Zugriff auf dieselben Eingabedaten (z. B. Eingaben von Sensoren des Fahrzeugs 1300) haben und mit einem gemeinsamen Bus, wie etwa dem CAN-Bus, verbunden sein.

Das Fahrzeug 1300 kann eine oder mehrere Steuerungen 1336 beinhalten, wie etwa diejenigen, die hierin in Bezug auf 13A beschrieben sind. Die Steuerung(en) 1336 können für eine Vielfalt von Funktionen verwendet werden. Die Steuerungen 1336 können mit beliebigen von verschiedenen anderen Komponenten und Systemen des Fahrzeugs 1300 gekoppelt sein und können zur Steuerung des Fahrzeugs 1300, der künstlichen Intelligenz des Fahrzeugs 1300, des Infotainment für das Fahrzeug 1300 und/oder dergleichen verwendet werden.

Das Fahrzeug 1300 kann ein System (oder mehrere Systeme) auf einem Chip (SoC) 1304 beinhalten. Das SoC 1304 kann CPU(s) 1306, GPU(s) 1308, Prozessor(en) 1310, Cache(s) 1312, Fahrpedal(e) 1314, Datenspeicher 1316 und/oder andere nicht abgebildete Komponenten und Funktionen beinhalten. Die SoC(s) 1304 können zum Steuern des Fahrzeugs 1300 in einer Vielfalt an Plattformen und Systemen verwendet werden. Die SoC(s) 1304 können beispielsweise in einem System (z. B. dem System des Fahrzeugs 1300) mit einer HD-Karte 1322 kombiniert werden, die über eine Netzwerkschnittstelle 1324 Aktualisierungen der Karte und/oder Updates von einem oder mehreren Servern (z. B. Server 1378 der 13D) erhalten kann.

Die CPU(s) 1306 können einen CPU-Cluster oder CPU-Komplex (hierin alternativ als „CCPLEX“ bezeichnet) beinhalten. Die CPU(s) 1306 können mehrere Kerne und/oder L2-Caches beinhalten. Zum Beispiel können in einigen Ausführungsformen die CPU(s) 1306 acht Kerne in einer kohärenten Mehrprozessorkonfiguration beinhalten. In einigen Ausführungsformen können die CPU(s) 1306 vier Doppelkerncluster beinhalten, wobei jeder Cluster über einen dedizierten L2-Cache verfügt (z. B. einen L2-Cache mit 2 MB). Die CPU(s) 1306 (z. B. CCPLEX) können so konfiguriert sein, dass sie simultane Clusteroperationen unterstützen, sodass eine beliebige Kombination von Clustern der CPU(s) 1306 zu einem beliebigen gegebenen Zeitpunkt aktiv sein kann.

Die CPU(s) 1306 können Leistungsverwaltungsfähigkeiten implementieren, die eines oder mehrere der folgenden Merkmale beinhalten: einzelne Hardwareblöcke können automatisch taktgesteuert werden, wenn sie inaktiv sind, um dynamische Leistung zu sparen; jeder Kerntakt kann gesteuert werden, wenn der Kern aufgrund der Ausführung von WFI-/WFE-Anweisungen keine Anweisungen aktiv ausführt; jeder Kern kann unabhängig leistungsgesteuert sein; jeder Kerncluster kann unabhängig taktgesteuert sein, wenn alle Kerne taktgesteuert oder leistungsgesteuert sind; und/oder jeder Kerncluster kann unabhängig leistungsgesteuert sein, wenn alle Kerne leistungsgesteuert sind. Die CPU(s) 1306 können ferner einen erweiterten Algorithmus zur Verwaltung von Leistungsstatus implementieren, bei dem zulässige Leistungsstatus und erwartete Aufwachzeiten spezifiziert werden und die Hardware/der Mikrocode den besten Leistungsstatus bestimmt, in den für den Kern, Cluster und CCPLEX einzutreten ist. Die Verarbeitungskerne können vereinfachte Leistungsstatus-Eintragssequenzen in der Software unterstützen, wobei die Arbeit in den Mikrocode ausgelagert wird.

Die GPU(s) 1308 können eine integrierte GPU (hierin alternativ als „iGPU“ bezeichnet) beinhalten. Die GPU(s) 1308 können programmierbar sein und für parallele Arbeitslasten effizient sein. Die GPU(s) 1308 können in einigen Beispielen einen erweiterten Tensor-Anweisungssatz verwenden. Die GPU(s) 1308 können einen oder mehrere Streaming-Mikroprozessoren beinhalten, wobei jeder Streaming-Mikroprozessor einen Level-Eins-(„L1“-)Cache beinhalten kann (z. B. einen L1-Cache mit einer Speicherkapazität von mindestens 96 KB), und zwei oder mehr Streaming-Mikroprozessoren können einen L2-Cache gemeinsam nutzen (z. B. einen L2-Cache mit einer Speicherkapazität von 512 KB). In einigen Ausführungsformen können die GPU(s) 1308 mindestens acht Streaming-Mikroprozessoren beinhalten. Die GPU(s) 1308 können (eine) Berechnungs-Anwendungsprogrammierschnittstelle(n) (API(s)) verwenden. Zusätzlich können die GPU(s) 1308 eine oder mehrere Parallelrechenplattformen und/oder Programmiermodelle (z. B. CUDA von NVIDIA) verwenden.

Die GPU(s) 1308 können für die beste Rechenleistung in Automobil- und eingebetteten Anwendungsfällen leistungsoptimiert sein. Die GPU(s) 1308 können zum Beispiel auf einem Fin-Feldeffekttransistor (FinFET) gefertigt sein. Dies ist jedoch nicht als Einschränkung zu verstehen, und die GPU(s) 1308 können auch mit anderen Halbleiterfertigungsverfahren hergestellt werden. Jeder Streaming-Mikroprozessor kann eine Anzahl von Verarbeitungskernen mit gemischter Genauigkeit beinhalten, die in mehrere Blöcke partitioniert sind. Zum Beispiel, und ohne Einschränkung, könnten 64 PF32-Kerne und 32 PF64-Kerne in vier Verarbeitungsblöcke partitioniert sein. In solch einem Beispiel könnten jedem Verarbeitungsblock 16 FP32-Kerne, 8 FP64-Kerne, 16 INT32-Kerne, zwei NVIDIA TENSOR COREs mit gemischter Genauigkeit für Deep-Learning-Matrixarithmetik, ein L0" Anweisungs-Cache, ein Warp-Planer, eine Verteilungseinheit und/oder eine Registerdatei mit 64 KB zugewiesen sein. Zusätzlich können Streaming-Mikroprozessoren unabhängige parallele Integer- und Fließkomma-Datenpfade beinhalten, um eine effiziente Ausführung von Arbeitslasten mit einer Mischung aus Berechnung und Adressierungsberechnungen zu ermöglichen. Die Streaming-Mikroprozessoren können eine unabhängige Thread-Planungsfunktion beinhalten, um eine feinkörnigere Synchronisation und Kooperation zwischen parallelen Threads zu ermöglichen. Die Streaming-Mikroprozessoren können eine Einheit aus kombiniertem L1-Daten-Cache und gemeinsam genutztem Speicher beinhalten, um die Performance zu verbessern, während die Programmierung vereinfacht wird.

Die GPU(s) 1308 können einen Speicher mit hoher Bandbreite (high bandwidth memory - HBM) und/oder ein 16-GB-HBM2-Speicherteilsystem beinhalten, um in einigen Beispielen eine Spitzenspeicherbandbreite von etwa 900 GB/Sekunde bereitzustellen. In einigen Beispielen kann zusätzlich oder alternativ zu dem HBM-Speicher ein synchroner Grafik-Direktzugriffsspeicher (synchronous graphics random-access memory - SGRAM) verwendet werden, wie etwa ein synchroner Direktzugriffsspeicher vom Graphics-Double-Data-Rate-Typ fünf (graphics double data rate type five - GDDR5).

Die GPU(s) 1308 kann/können eine einheitliche Speichertechnologie mit Zugriffszählern beinhalten, die eine genauere Zuweisung von Speicherseiten an den Prozessor ermöglicht, der am häufigsten darauf zugreift, und so die Effizienz von Speicherbereichen verbessert, die von mehreren Prozessoren gemeinsam genutzt werden. In einigen Beispielen kann die Unterstützung von Adressübersetzungsdiensten (ATS) verwendet werden, damit die GPU(s) 1308 direkt auf die Seitentabellen der CPU(s) 1306 zugreifen können. In solchen Beispielen kann, wenn die GPU(s) 1308 Speicherverwaltungseinheit (memory management unit - MMU) einen Fehlschlag erleidet, eine Adressübersetzungsanfrage an die CPU(s) 1306 gesendet werden. Als Reaktion darauf können die CPU(s) 1306 in ihren Seitentabellen nach einer Virtuell-zu-Physisch-Zuordnung für die Adresse suchen und die Übersetzung zurück an die GPU(s) 1308 übertragen. Als solche kann die einheitliche Speichertechnologie einen einzelnen einheitlichen virtuellen Adressraum für Speicher sowohl der CPU(s) 1306 als auch der GPU(s) 1308 ermöglichen, wodurch die Programmierung der GPU(s) 1308 und die Portierung von Anwendungen auf die GPU(s) 1308 vereinfacht werden.

Darüber hinaus kann die GPU(s) 1308 einen Zugriffszähler beinhalten, der die Häufigkeit des Zugriffs der GPU(s) 1308 auf den Speicher anderer Prozessoren verfolgt. Der Zugriffszähler kann dazu beitragen, dass Speicherseiten in den physischen Speicher desjenigen Prozessors verschoben werden, der am häufigsten auf die Seiten zugreift.

Die SoC(s) 1304 können eine beliebige Anzahl von Cache(s) 1312 beinhalten, einschließlich der hierin beschriebenen. Der/die Cache(s) 1312 kann/können beispielsweise einen L3-Cache beinhalten, der sowohl der/den CPU(s) 1306 als auch der/den GPU(s) 1308 zur Verfügung steht (z. B. der sowohl mit der/den CPU(s) 1306 als auch der/den GPU(s) 1308 verbunden ist). Der/die Cache(s) 1312 können einen Rückschreib-Cache beinhalten, der die Status von Zeilen verfolgen kann, wie z. B. durch die Verwendung eines Cache-Kohärenzprotokolls (z. B. MEI, MESI, MSI usw.). Der L3-Cache kann in Abhängigkeit von der Ausführungsform 4 MB oder mehr beinhalten, obwohl auch kleinere Cache-Größen verwendet werden können.

Der/die SoC(s) 1304 kann/können eine arithmetische Logikeinheit(en) (ALU(s)) beinhalten, die beim Durchführen von Verfahren in Bezug auf eine der vielen Aufgaben oder Operationen des Fahrzeugs 1300, wie etwa der Verarbeitung von DNNs, genutzt werden kann. Darüber hinaus können die SoC(s) 1304 eine oder mehrere Gleitkommaeinheiten (floating point units - FPU(s)) - oder andere mathematische Coprozessoren oder numerische Coprozessoren - zur Durchführung mathematischer Operationen innerhalb des Systems beinhalten. Zum Beispiel kann der SoC(s) 104 eine oder mehrere FPUs beinhalten, die als Ausführungseinheiten in einer CPU(s) 1306 und/oder GPU(s) 1308 integriert sind.

Das/die SoC(s) 1304 können einen oder mehrere Beschleuniger 1314 beinhalten (z. B. Hardware-Beschleuniger, Software-Beschleuniger oder eine Kombination davon). Zum Beispiel können das/die SoC(s) 1304 einen Hardware-Beschleunigungscluster beinhalten, der optimierte Hardware-Beschleuniger und/oder einen großen chipinternen Speicher beinhalten kann. Der großer chipinterne Speicher (z. B. 4 MB SRAM) kann einen Hardware-Beschleunigungscluster zur Beschleunigung neuronaler Netze und anderer Berechnungen ermöglichen. Der Hardware-Beschleunigungscluster kann verwendet werden, um die GPU(s) 1308 zu ergänzen und eingige Tasks der GPU(s) 1308 auszulagern (z. B. mehr Zyklen der GPU(s) 1308 zum Durchführen anderer Tasks freizumachen). Als Beispiel können der/die Beschleuniger 1314 für zielgerichtete Arbeitslasten (z. B. Wahrnehmung, neuronale Faltungsnetze (CNNs usw.) verwendet werden, die stabil genug sind, um für eine Beschleunigung geeignet zu sein. Der Begriff „CNN“, wie er hier verwendet wird, kann alle Arten von CNNs beinhalten, einschließlich regionenbasierter oder regionaler neuronaler Faltungsnetze (RCNNs) und Fast RCNNs (z. B. für die Objekterkennung).

Der/die Beschleuniger 1314 können (z. B. Hardware-Beschleunigungscluster) (einen) Deep-Learning-Beschleuniger (deep learning accelerator(s) - DLA(s)) beinhalten. Die DLA(s) können eine oder mehrere Tensor-Verarbeitungseinheiten (TPU(s)) beinhalten, die so konfiguriert sein können, dass sie zusätzliche zehn Billionen Vorgänge pro Sekunde für Deep-Learning-Anwendungen und -Ableitung bereitstellen. Die TPUs können Beschleuniger sein, die zum Durchführen von Bildverarbeitungsfunktionen (z. B. für CNNs, RCNNs usw.) konfiguriert und optimiert sind. Die DLA(s) können ferner für einen spezifischen Satz von Arten von neuronalen Netzen und Fließkommavorgängen sowie für die Ableitung optimiert sein. Das Design der DLA(s) kann mehr Performance pro Millimeter bereitstellen als eine Allgemeinzweck-GPU und übertrifft typischerweise die Performance einer CPU bei weitem. Die TPU(s) können mehrere Funktionen durchführen, einschließlich einer Einzelinstanz-Faltungsfunktion, die z. B. INT8-, INT16- und FP16-Datenarten sowohl für Merkmale als auch für Gewichtungen unterstützt, sowie Postprozessorfunktionen.

Die DLA(s) können neuronale Netze, insbesondere CNNs, an verarbeiteten oder unverarbeiteten Daten für beliebige einer Vielfalt von Funktionen schnell und effizient ausführen, darunter zum Beispiel und ohne Einschränkung: ein CNN für die Identifizierung und Detektion von Objekten unter Verwendung von Daten von Kamerasensoren; ein CNN für die Abstandsschätzung unter Verwendung von Daten von Kamerasensoren; ein CNN für die Detektion und Identifizierung und Detektion von Einsatzfahrzeugen unter Verwendung von Daten von Mikrofonen; ein CNN für die Gesichtserkennung und Identifizierung von Fahrzeugbesitzern unter Verwendung von Daten von Kamerasensoren; und/oder ein CNN für sicherheits- und/oder sicherungsbezogene Ereignisse.

Die DLA(s) können eine beliebige Funktion der GPU(s) 1308 durchführen und durch Verwenden eines Inferenzbeschleunigers kann ein Gestalter zum Beispiel entweder DLA(s) oder GPU(s) 1308 für eine beliebige Funktion anvisieren. Zum Beispiel kann der Designer die Verarbeitung von CNNs und Fließkommavorgängen auf DLA(s) konzentrieren und andere Funktionen der/den GPU(s) 1308 und/oder anderen Beschleuniger(n) 1314 überlassen.

Der/die Beschleuniger 1314 (z. B. der Hardware-Beschleunigungscluster) können (einen) programmierbare(n) Sichtbeschleuniger (programmable vision accelerator - „PVA“) beinhalten, der hierin alternativ als ein Beschleuniger für maschinelles Sehen bezeichnet werden kann. Die PVA(s) können zur Beschleunigung von Algorithmen des maschinellen Sehens für weiterentwickelte Fahrerassistenzsysteme (ADAS), autonomes Fahren, Augmented-Reality(AR)- und/oder Virtual-Reality(VR)-Anwendungen konstruiert und konfiguriert sein. Die PVA(s) können ein Gleichgewicht zwischen Performance und Flexibilität bereitstellen. Zum Beispiel können alle PVA(s) ohne Einschränkung eine beliebige Anzahl von Reduced-Instruction-Set-Computer(RISC)-Kerne, direkten Speicherzugriff (direct memory access - DMA) und/oder eine beliebige Anzahl von Vektorprozessoren beinhalten.

Die RISC-Kerne können mit Bildsensoren (z. B. Bildsensoren einer beliebigen der hierin beschriebenen Kameras), Bildsignalprozessor(en) und/oder dergleichen interagieren. Jeder der RISC-Kerne kann eine beliebige Menge an Speicher beinhalten. Die RISC-Kerne können in Abhängigkeit von der Ausführungsform ein beliebiges von einer Anzahl von Protokollen verwenden. In einigen Beispieln können die RISC-Kerne ein Echtzeitbetriebssystem (real-time operating system - RTOS) ausführen. Die RISC-Kerne können unter Verwendung einer oder mehrerer Vorrichtungen für integrierte Schaltungen, anwendungsspezifischer integrierter Schaltungen („ASICs“) und/oder Speichervorrichtungen implementiert sein. Die RISC-Kerne können beispielsweise einen Anweisungs-Cache und/oder einen eng gekoppelten RAM beinhalten.

Der DMA kann es den Komponenten des/der PVA(s) ermöglichen, unabhängig von der/den CPU(s) 1306 auf den Systemspeicher zuzugreifen. Der DMA kann eine beliebige Anzahl von Merkmalen unterstützen, die zum Bereitstellen der Optimierung des PVA verwendet werden, einschließlich der Unterstützung von mehrdimensionaler Adressierung und/oder zirkulärer Adressierung, ohne darauf beschränkt zu sein. In einigen Beispielen kann der DMA bis zu sechs oder mehr Dimensionen der Adressierung unterstützen, die Blockbreite, Blockhöhe, Blocktiefe, horizontale Blockabstufung, vertikale Blockabstufung und/oder Tiefenabstufung beinhalten können.

Die Vektorprozessoren können programmierbare Prozessoren sein, die so ausgestaltet sein können, dass sie die Programmierung für Algorithmen des maschinellen Sehens effizient und flexibel ausführen und Signalverarbeitungsfähigkeiten bereitstellen. In einigen Beispielen kann der PVA einen PVA-Kern und zwei Vektorverarbeitungsteilsystempartitionen beinhalten. Der PVA-Kern kann ein Prozessorteilsystem, DMA-Engine(s) (z. B. zwei DMA-Engines) und/oder andere Peripheriegeräte beinhalten. Das Vektorverarbeitungsteilsystem kann als primäre Verarbeitungs-Engine des PVA arbeiten und kann eine Vektorverarbeitungseinheit (vector processing unit - VPU), einen Anweisungs-Cache und/oder einen Vektorspeicher (z. B. VMEM) beinhalten. Ein VPU-Kern kann einen digitalen Signalprozessor beinhalten, wie zum Beispiel einen digitalen Single-Instruction-Multiple-Data-(SIMD-)Very-Long-Instruction-Word-(VLIW-)Signalprozessor. Die Kombination aus SIMD und VLIW kann den Durchsatz und die Geschwindigkeit erhöhen.

Jeder der Vektorprozessoren kann einen Anweisungs-Cache beinhalten und an dedizierten Speicher gekoppelt sein. Daher kann in einigen Beispielen jeder der Vektorprozessoren so konfiguriert sein, dass er unabhängig von anderen Vektorprozessoren ausgeführt wird. In anderen Beispielen können die Vektorprozessoren, die in einem konkreten PVA enthalten sind, so konfiguriert sein, dass sie Datenparallelität einsetzen. Zum Beispiel kann in einigen Ausführungsformen eine Vielzahl von Vektorprozessoren, die in einem einzelnen PVA enthalten ist, denselben Algorithmus des maschinellen Sehens ausführen, jedoch an unterschiedlichen Regionen eines Bildes. In anderen Beispielen können die in einem konkreten PVA enthaltenen Vektorprozessoren simultan unterschiedliche Algorithmen des maschinellen Sehens an demselben Bild ausführen oder sogar unterschiedliche Algorithmen an sequentiellen Bildern oder Abschnitten eines Bildes ausführen. Unter anderem kann eine beliebige Anzahl von PVAs in einem Hardware-Beschleunigungscluster enthalten sein und kann eine beliebige Anzahl von Vektorprozessoren in jedem der PVAs enthalten sein. Zusätzlich können der/die PVA(s) einen zusätzlichen Fehlerkorrekturcode(ECC)-Speicher beinhalten, um die Gesamtsystemsicherheit zu erhöhen.

Der/die Beschleuniger 1314 (z. B. ein Hardware-Beschleunigungscluster) können ein Netzwerk auf dem Chip für maschinelles Sehen und SRAM beinhalten, um einen SRAM mit hoher Bandbreite und niedriger Latenz für den/die Beschleuniger 1314 bereitzustellen. In einigen Beispielen kann der chipinterne Speicher mindestens 4 MB SRAM beinhalten, der z. B. und ohne Einschränkung aus acht feldkonfigurierbaren Speicherblöcken besteht, auf die sowohl der PVA als auch der DLA zugreifen können. Jedes Paar von Speicherblöcken kann eine weiterentwickelte Peripheriebus (advanced peripheral bus - APB)-Schnittstelle, eine Konfigurationsschaltung, eine Steuerung und einen Multiplexer beinhalten. Jede Art von Speicher kann verwendet werden. Der PVA und DLA können auf den Speicher über einen Backbone zugreifen, der dem PVA und DLA einen Hochgeschwindigkeitszugriff auf den Speicher bereitstellt. Der Backbone kann ein Netzwerk auf dem Chip für maschinelles Sehen beinhalten, das den PVA und DLA mit dem Speicher verbindet (z. B. unter Verwendung von APB).

Das Netzwerk auf dem Chip für maschinelles Sehen kann eine Schnittstelle beinhalten, die vor der Übertragung eines beliebigen Steuersignals/einer beliebigen Adresse/ beliebiger Daten bestimmt, dass sowohl der PVA als auch der DLA einsatzbereite und gültige Signale bereitstellen. Eine derartige Schnittstelle kann separate Phasen und separate Kanäle für die Übertragung von Steuersignalen/Adressen/Daten sowie eine Burst-artige Kommunikation für eine kontinuierliche Datenübertragung bereitstellen. Diese Art von Schnittstelle kann den Normen ISO 26262 oder IEC 61508 entsprechen, obwohl auch andere Normen und Protokolle verwendet werden können.

In einigen Beispielen kann das/die SoC(s) 1304 einen Echtzeit-Raytracing-Hardwarebeschleuniger beinhalten, wie er in der US-Patentanwendung Nr. 16/101,232, eingereicht am 10. August 2018, beschrieben ist. Der Echtzeitstrahlverfolgungs-Hardware-Beschleuniger kann verwendet werden, um schnell und effizient Positionen und Ausdehnungen von Objekten (z. B. innerhalb eines Weltmodells) zu bestimmen, um Echtzeitvisualisierungssimulationen zu erzeugen, für die RADAR-Signalinterpretation, für die Schallausbreitungssynthese und/oder -analyse, für die Simulation von SONAR-Systemen, für die allgemeine Wellenausbreitungssimulation, für den Vergleich mit LIDAR-Daten zum Zwecke der Lokalisierung und/oder für andere Funktionen und/oder für andere Anwendungen. In einigen Ausführungsformen können eine oder mehrere Tree Traversal Units (TTUs) verwendet werden, um eine oder mehrere Raytracing-bezogene Operationen auszuführen.

Der/die Beschleuniger 1314 (z. B. der Hardware-Beschleunigercluster) weisen ein breites Spektrum von Verwendungen für das autonome Fahren auf. Der PVA kann ein programmierbarer Sichtbeschleuniger sein, der für wichtige Verarbeitungsstufen im ADAS und in autonomen Fahrzeugen verwendet werden kann. Die Fähigkeiten eines PVA passen gut zu algorithmischen Domänen, die eine vorhersagbare Verarbeitung bei niedriger Leistung und niedriger Latenz benötigen. Anders ausgedrückt zeigt der PVA eine gute Performance für halbdichte oder dichte reguläre Berechnungen, auch an kleinen Datensätzen, die vorhersagbare Laufzeiten mit niedriger Latenz und niedriger Leistung benötigen. Im Zusammenhang mit Plattformen für autonome Fahrzeuge sind die PVAs also dafür ausgelegt, klassische Computer-Vision-Algorithmen auszuführen, da sie effizient bei der Objekterkennung sind und mit ganzzahligen mathematischen Verfahren arbeiten.

Zum Beispiel, gemäß einer Ausführungsform der Technologie, wird der PVA verwendet, um maschinelles Stereo-Sehen durchzuführen. Ein auf semiglobalem Abgleich basierender Algorithmus kann verwendet werden, obwohl dies nicht als Einschränkung auszulegen ist. Viele Anwendungen für das autonome Fahren auf Level 3-5 erfordern Bewegungsschätzung/Stereo-Abgleich spontan (z. B. Struktur aus Bewegung, Fußgängererkennung, Fahrspurerkennung usw.). Der PVA kann eine Funktion des maschinellen Stereo-Sehens an Eingaben von zwei monokularen Kameras durchführen.

In einigen Beispielen kann der PVA verwendet werden, um einen dichten optischen Fluss durchzuführen. Gemäß der Verarbeitung von RADAR-Rohdaten (z. B. mit einer 4D-Fast-Fourier-Transformation) zur Bereitstellung von verarbeitetem RADAR. In anderen Beispielen wird der PVA für die Laufzeit-Tiefenverarbeitung verwendet, indem z. B. Laufzeit-Rohdaten verarbeitet werden, um verarbeitete Laufzeitdaten bereitzustellen.

Der DLA kann verwendet werden, um eine beliebige Art von Netzwerk auszuführen, um die Steuerung und Fahrsicherheit zu verbessern, einschließlich zum Beispiel ein neuronales Netz, das ein Maß an Konfidenz für jede Objekterkennung ausgibt. Ein derartiger Konfidenzwert kann als eine Wahrscheinlichkeit interpretiert werden oder als Bereitstellung einer relativen „Gewichtung“ jeder Erkennung im Vergleich zu anderen Erkennungen. Anhand dieses Konfidenzwerts kann das System ferner entscheiden, welche Erkennungen als echte positive Erkennungen und welche als falsch positive Erkennungen betrachtet werden sollten. Das System kann zum Beispiel einen Schwellenwert für die Konfidenz festlegen und nur die Erkennungen, die den Schwellenwert überschreiten, als echte positive Erkennungen betrachten. In einem automatischen Notbrems(automatic emergency braking - AEB)-System würden falsch positive Erkennungen dazu führen, dass das Fahrzeug automatisch eine Notbremsung durchführt, was natürlich unerwünscht ist. Daher sollten nur die sichersten Entdeckungen als Auslöser für AEB in Betracht gezogen werden. Der DLA kann ein neuronales Netz zur Regression des Konfidenzwerts ausführen. Das neuronale Netz kann als Eingabe zumindest eine Teilmenge von Parametern nutzen, wie etwa die Abmessungen des Begrenzungsrahmens, die (z. B. von einem anderen Teilsystem) erhaltene Schätzung der Bodenebene, die Ausgabe des IMU-Sensors 1366, die mit der Ausrichtung des Fahrzeugs 1300 korreliert, die Entfernung, die Schätzung der 3D-Position der Aufgabe, die vom neuronalen Netz und/oder anderen Sensoren (z. B. LIDAR-Sensor(en) 1364 oder RADAR-Sensor(en) 1360) erhalten wird, und andere.

Das/die SoC(s) 1304 können Datenspeicher 1316 (z. B. Speicher) beinhalten. Der bzw. die Datenspeicher 1316 kann bzw. können On-Chip-Speicher des bzw. der SoC(s) 1304 sein, der neuronale Netze speichern kann, die auf der GPU und/oder dem DLA ausgeführt werden sollen. In einigen Beispiel kann die Kapazität des/der Datenspeicher(s) 1316 groß genug sein, um mehrere Instanzen von neuronalen Netzen zur Redundanz und Sicherheit zu speichern. Der/die Datenspeicher 1312 können L2 oder L3 Cache(s) 1312 umfassen. Der Verweis auf den/die Datenspeicher 1316 kann einen Verweis auf den Speicher beinhalten, der dem PVA, DLA und/oder anderen Beschleunigern 1314 zugeordnet ist, wie hier beschrieben.

Das/die SoC(s) 1304 kann/können einen oder mehrere Prozessor(en) 1310 (z. B. eingebettete Prozessoren) beinhalten. Der/die Prozessor(en) 1310 können einen Booting- und Leistungsverwaltungsprozessor beinhalten, der ein dedizierter Prozessor und ein Teilsystem sein kann, um die Booting-Leistungs- und - verwaltungsfunktionen und die damit verbundene Sicherheitsdurchsetzung zu handhaben. Der Booting- und Leistungsverwaltungsprozessor kann ein Teil der Booting-Sequenz des/der SoC(s) 1304 sein und Laufzeit-Leistungsverwaltungsdienste bereitstellen. Der Booting-Leistungs- und Verwaltungsprozessor kann Takt- und Spannungsprogrammierung, Unterstützung bei Übergängen des Systems in einen Zustand mit niedriger Leistung, Verwaltung von Thermo- und Temperatursensoren der SoC(s) 1304 und/oder Verwaltung von Leistungszuständen der SoC(s) 1304 bereitstellen. Jeder Temperatursensor kann als Ringoszillator implementiert sein, dessen Ausgangsfrequenz proportional zur Temperatur ist, und die SoC(s) 1304 können Ringoszillatoren verwenden, um Temperaturen von CPU(s) 1306, GPU(s) 1308 und/oder Beschleuniger(n) 1314 zu detektieren. Falls bestimmt wird, dass Temperaturen einen Schwellenwert überschreiten, kann der Booting- und Leistungsverwaltungsprozessor dann in eine Temperaturfehlerroutine eintreten und die SoC(s) 1304 in einen Zustand mit niedrigerer Leistung versetzen und/oder das Fahrzeug 1300 in einen Modus des Fahrens zu einem sicheren Halt versetzen (z. B. das Fahrzeug 1300 zu einem sicheren Halt bringen).

Der/die Prozessor(en) 1310 können ferner einen Satz von eingebetteten Prozessoren beinhalten, die als eine Audioverarbeitungs-Engine dienen können. Die Audioverarbeitungs-Engine kann ein Audioteilsystem sein, das eine vollständige Hardware-Unterstützung für Mehrkanal-Audio über mehrere Schnittstellen sowie eine breite und flexible Palette von Audio-E/A-Schnittstellen ermöglicht. In einigen Beispielen ist die Audioverarbeitungs-Engine ein dedizierter Prozessorkern mit einem digitalen Signalprozessor mit dediziertem RAM.

Der/die Prozessor(en) 1310 können ferner eine stets eingeschaltete Prozessor-Engine beinhalten, welche die notwendigen Hardware-Merkmale zur Unterstützung der Sensorverwaltung mit niedriger Leistung und der Aufwach-Anwendungsfälle bereitstellen kann. Die stets eingeschaltete Prozessor-Engine kann einen Prozessorkern, einen eng gekoppelten RAM, unterstützende Peripheriegeräte (z. B. Timer und Unterbrechungssteuerungen), verschiedene E/A-Steuerungsperipheriegeräte und Routing-Logik beinhalten.

Die Prozessor(en) 1310 können ferner eine Sicherheitscluster-Engine beinhalten, die ein dediziertes Prozessorteilsystem zum Handhaben der Sicherheitsverwaltung für Automobilanwendungen beinhaltet. Die Sicherheitscluster-Engine kann zwei oder mehr Prozessorkerne, einen eng gekoppelten RAM, unterstützende Peripheriegeräte (z. B. Zeitgeber, eine Unterbrechungssteuerung usw.) und/oder Routing-Logik beinhalten. In einem Sicherheitsmodus können die zwei oder mehr Kerne in einem Gleichschrittmodus arbeiten und als ein einzelner Kern mit einer Vergleichslogik funktionieren, um beliebige Unterschiede zwischen ihren Vorgängen zu erkennen.

Der/die Prozessor(en) 1310 können ferner eine Echtzeitkamera-Engine beinhalten, die ein dediziertes Prozessorteilsystem zur Handhabung der Echtzeitkameraverwaltung beinhalten kann.

Der/die Prozessor(en) 1310 können ferner einen Signalprozessor mit hohem Dynamikbereich beinhalten, der einen Bildsignalprozessor beinhalten kann, der eine Hardware-Engine ist, die Teil einer Kameraverarbeitungspipeline ist.

Die Prozessor(en) 1310 können einen Videobildkompositor beinhalten, der ein Verarbeitungsblock sein kann (z. B. auf einem Mikroprozessor implementiert), der Videonachverarbeitungsfunktionen implementiert, die durch eine Videowiedergabeanwendung benötigt werden, um das endgültige Bild für das Fenster des Wiedergabeprogramms zu erzeugen. Der Videobildkompositor kann eine Objektivverzeichnungskorrektur an den Weitsichtkamera(s) 1370, Rundumkamera(s) 1374 und/oder kabineninternen Überwachungskamerasensoren durchführen. Der kabineninterne Überwachungskamerasensor wird vorzugsweise von einem neuronalen Netz überwacht, das auf einer anderen Instanz des Advanced SoC läuft und so konfiguriert ist, dass es Ereignisse in der Kabine erkennt und entsprechend reagiert. Ein kabineninternes System kann Lippenlesen durchführen, um den Mobilfunkdienst zu aktivieren und einen Anruf zu tätigen, E-Mails zu diktieren, ein Ziel des Fahrzeugs zu ändern, ein Infotainmentsystem des Fahrzeugs und dessen Einstellungen zu aktivieren oder zu ändern oder sprachaktiviertes Surfen im Internet bereitzustellen. Dem Fahrer stehen bestimmte Funktionen zur Verfügung, wenn das Fahrzeug in einem autonomen Modus betrieben wird, und sind ansonsten deaktiviert.

Der Videobildkompositor kann eine erweiterte zeitliche Rauschunterdrückung sowohl für die räumliche als auch für die zeitliche Rauschunterdrückung beinhalten. Zum Beispiel wo Bewegung in einem Video vorkommt, gewichtet die Rauschunterdrückung die räumlichen Informationen entsprechend, indem sie die Gewichtung der Informationen, die von benachbarten Frames bereitgestellt werden, verringert. Wo ein Bild oder ein Abschnitt eines Bildes keine Bewegung enthält, kann die vom Videobildkompositor durchgeführte zeitliche Rauschunterdrückung Informationen aus dem vorherigen Bild verwenden, um das Rauschen im aktuellen Bild zu unterdrücken.

Der Videobildkompositor kann auch so konfiguriert sein, dass er eine Stereoentzerrung an den eingegebenen Stereolinsen-Frames durchführt. Der Videobildkompositor kann ferner für die Benutzerschnittstellenzusammensetzung verwendet werden, wenn der Desktop des Betriebssystems in Gebrauch ist und die GPU(s) 1308 nicht zum kontinuierlichen Rendern neuer Oberflächen benötigt werden. Sogar wenn die GPU(s) 1308 eingeschaltet sind und aktiv 3D-Rendering durchführen, kann der Videobildkompositor eingesetzt werden, um die GPU(s) 1308 zu entlasten, um die Performance und Reaktionsfähigkeit zu verbessern.

Das/die SoC(s) 1304 können ferner eine serielle Mobile-Industry-Processor-Interface (MIPI)-Kameraschnittstelle zum Empfangen von Videos und Eingaben von Kameras, eine Hochgeschwindigkeitsschnittstelle und/oder einen Videoeingabeblock beinhalten, der für Kamera- und zugehörige Pixeleingabefunktionen verwendet werden kann. Das/die SoC(s) 1304 können ferner (eine) Eingabe/Ausgabe-Steuerung(en) beinhalten, die durch Software gesteuert werden können und für den Empfang von E/A-Signalen verwendet werden können, die keiner bestimmten Rolle zugewiesen sind.

Das/die SoC(s) 1304 können ferner eine breite Palette von Peripherieschnittstellen beinhalten, um die Kommunikation mit Peripheriegeräten, Audio-Codecs, Leistungsverwaltungs- und/oder anderen Vorrichtungen zu ermöglichen. Das/die SoC(s) 1304 kann/können verwendet werden, um Daten von Kameras (z. B. verbunden über Gigabit Multimedia Serial Link und Ethernet), Sensoren (z. B. LIDAR-Sensor(en) 1364, RADAR-Sensor(en) 1360 usw., die über Ethernet verbunden sein können), Daten vom Bus 1302 (z. B. Geschwindigkeit des Fahrzeugs 1300, Lenkradposition usw.), Daten von GNSS-Sensor(en) 1358 (z. B. verbunden über Ethernet oder CAN-Bus) zu verarbeiten. Das/die SoC(s) 1304 kann/können ferner dedizierte Hochleistungssteuerungen für die Massenspeicherung beinhalten, die ihre eigenen DMA-Engines enthalten können und die verwendet werden können, um die CPU(s) 1306 von Routineaufgaben der Datenverwaltung zu befreien.

Die SoC(s) 1304 können eine Ende-zu-Ende-Plattform mit einer flexiblen Architektur sein, die die Automatisierungslevels 3-5 überspannt und dadurch eine umfassende funktionelle Sicherheitsarchitektur bereitstellt, die Techniken des maschinellen Sehens und des ADAS für Diversität und Redundanz ausnutzt und effizient einsetzt und eine Plattform für einen flexiblen, zuverlässigen Fahrsoftwarestapel zusammen mit Deep-Learning-Werkzeugen bereitstellt. Das/die SoC(s) 1304 können schneller, zuverlässiger und sogar energieeffizienter und raumeffizienter sein als herkömmliche Systeme. Zum Beispiel können der/die Beschleuniger 1314, wenn sie mit den CPU(s) 1306, GPU(s) 1308 und Datenspeicher(n) 1316 kombiniert sind, eine schnelle, effiziente Plattform für autonome Fahrzeuge der Levels 3-5 bereitstellen.

Die Technologie stellt somit Möglichkeiten und Funktionen bereit, die mit herkömmlichen Systemen nicht erreicht werden können. Zum Beispiel können Algorithmen des maschinellen Sehens auf CPUs ausgeführt werden, die unter Verwendung einer Programmiersprache auf hohem Level, wie etwa der Programmiersprache C, konfiguriert werden können, um eine große Vielfalt von Verarbeitungsalgorithmen über eine große Vielfalt von visuellen Daten auszuführen. Die CPUs sind jedoch oft nicht in der Lage, die Performance-Anforderungen vieler Anwendungen des maschinellen Sehens zu erfüllen, wie z. B. in Bezug auf die Ausführungszeit und den Leistungsverbrauch. Insbesondere sind viele CPUs nicht in der Lage, komplexe Objekterkennungsalgorithmen in Echtzeit auszuführen, die in fahrzeuginternen ADAS-Anwendungen und in praktischen autonomen Fahrzeugen der Levels 3-5 erforderlich sind.

Im Gegensatz zu herkömmlichen Systemen ermöglicht die hier beschriebene Technologie durch die Bereitstellung eines CPU-Komplexes, eines GPU-Komplexes und eines Hardware-Beschleunigungclusters die gleichzeitige und/oder sequentielle Ausführung mehrerer neuronaler Netze und die Kombination der Ergebnisse, um autonome Fahrfunktionen der Level 3-5 zu ermöglichen. Zum Beispiel kann ein CNN, das auf dem DLA oder dGPU (z. B. GPU(s) 1320) ausgeführt wird, eine Text- und Worterkennung beinhalten, die es dem Supercomputer ermöglicht, Verkehrsschilder zu lesen und zu verstehen, einschließlich Schildern, für die das neuronale Netz nicht speziell trainiert wurde. Der DLA kann ferner ein neuronales Netz enthalten, das in der Lage ist, Zeichen zu identifizieren, zu interpretieren und ein semantisches Verständnis davon bereitzustellen und dieses semantische Verständnis an den Pfadplanungsmodule weiterzugeben, die auf dem CPU-Komplex laufen.

Als weiteres Beispiel können mehrere neuronale Netze simultan ausgeführt werden, wie für das Fahren bei Level 3, 4 oder 5 erforderlich ist. Zum Beispiel kann ein Warnschild mit der Aufschrift „Vorsicht: Blinkende Lichter weisen auf Vereisung hin“ zusammen mit einem elektrischen Licht von mehreren neuronalen Netzen unabhängig oder gemeinsam interpretiert werden. Das Schild selbst kann von einem ersten eingesetzten neuronalen Netz (z. B. einem trainierten neuronalen Netz) als Verkehrsschild identifiziert werden und kann der Text „Blinkende Lichter weisen auf Verweisung hin“ von einem zweiten eingesetzten neuronalen Netz interpretiert werden, das die Wegplanungssoftware des Fahrzeugs (die vorzugsweise auf dem CPU-Komplex ausgeführt wird) darüber informiert, dass, wenn blinkende Lichter erkannt werden, Vereisungen vorliegen. Das blinkende Licht kann identifiziert werden, indem ein drittes eingesetztes neuronales Netz über mehrere Frames hinweg betrieben wird und die Wegplanungssoftware des Fahrzeugs über das Vorhandensein (oder Nichtvorhandensein) von blinkenden Lichtern informiert. Alle drei neuronalen Netze können simultan laufen, wie etwa innerhalb des DLA und/oder auf den GPU(s) 1308.

In einigen Beispielen kann ein CNN zur Gesichtserkennung und Fahrzeugbesitzeridentifizierung Daten von Kamerasensoren verwenden, um das Vorhandensein eines autorisierten Fahrers und/oder Besitzers des Fahrzeugs 1300 zu identifizieren. Die stets eingeschaltete Sensorverarbeitungs-Engine kann verwendet werden, um das Fahrzeug zu entriegeln, wenn sich der Besitzer der Fahrertür nähert und Lichter einschaltet, und um in dem Sicherheitsmodus das Fahrzeug zu deaktivieren, wenn der Besitzer das Fahrzeug verlässt. Auf diese Weise stellen das/die SoC(s) 1304 Sicherheit gegen Diebstahl und/oder Carjacking bereit.

In einem anderen Beispiel kann ein CNN zur Erkennung und Identifizierung von Rettungsfahrzeugen Daten von Mikrofonen 1396 verwenden, um Sirenen von Notfahrzeugen zu erkennen und zu identifizieren. Im Gegensatz zu herkömmlichen Systemen, die allgemeine Klassifikatoren zur Erkennung von Sirenen und zur manuellen Extraktion von Merkmalen verwenden, nutzen die SoC(s) 1304 das CNN zur Klassifizierung von Umwelt- und Stadtgeräuschen sowie zur Klassifizierung von visuellen Daten. In einer bevorzugten Ausführungsform wird das CNN, das auf dem DLA läuft, dafür trainiert, die relative Annäherungsgeschwindigkeit des Einsatzfahrzeugs zu identifizieren (z. B. durch Verwendung des Dopplereffekts). Das CNN kann auch geschult werden, um Einsatzfahrzeuge zu identifizieren, die für den lokalen Einsatzbereich des Fahrzeugs spezifisch sind, wie durch GNSS-Sensor(en) 1358 identifiziert. Folglich versucht das CNN zum Beispiel, wenn es in Europa betrieben wird, europäische Sirenen zu erkennen, und in den Vereinigten Staaten versucht das CNN, nur nordamerikanische Sirenen zu identifizieren. Sobald ein Rettungsfahrzeug erkannt wird, kann ein Steuerprogramm verwendet werden, um eine Sicherheitsroutine für Rettungsfahrzeuge auszuführen, das Fahrzeug zu verlangsamen, zur Seite der Straße zu fahren, das Fahrzeug abzustellen und/oder das Fahrzeug mit Hilfe der Ultraschallsensoren 1362 im Leerlauf laufen zu lassen, bis das Rettungsfahrzeug vorbeifährt.

Das Fahrzeug kann CPU(s) 1318 (z. B. diskrete CPU(s) oder dCPU(s)) beinhalten, die über eine Hochgeschwindigkeitszusammenschaltung (z. B. PCIe) an die SoC(s) 1304 gekoppelt sein können. Die CPU(s) 1318 können zum Beispiel einen X86-Prozessor beinhalten. Die CPU(s) 1318 können dazu verwendet werden, eine beliebige einer Vielfalt von Funktionen durchzuführen, einschließlich zum Beispiel des Vermittelns potenziell inkonsistenter Ergebnisse zwischen ADAS-Sensoren und den SoC(s) 1304 und/oder des Überwachens des Status und Zustands der Steuerung/en) 1336 und/oder eines Infotainment-SoC 1330.

Das Fahrzeug 1300 kann GPU(s) 1320 (z. B. diskrete GPU(s) oder dGPU(s)) beinhalten, die über eine Hochgeschwindigkeitszusammenschaltung (z. B. NVLINK von NVIDIA) an die SoC(s) 1304 gekoppelt sein können. Die GPU(s) 1320 können eine zusätzliche Funktionalität für künstliche Intelligenz bereitstellen, wie etwa durch Ausführen redundanter und/oder unterschiedlicher neuronaler Netze, und sie können zum Trainieren und/oder Aktualisieren neuronaler Netze auf Grundlage von Eingaben (z. B. Sensordaten) von Sensoren des Fahrzeugs 1300 verwendet werden.

Das Fahrzeug 1300 kann ferner die Netzwerkschnittstelle 1324 beinhalten, die drahtlose Antenne(n) 1326 beinhalten kann (z. B. eine oder mehrere drahtlose Antennen für unterschiedliche Kommunikationsprotokolle, wie etwa eine Mobilfunkantenne, eine Bluetooth-Antenne usw.). Die Netzwerkschnittstelle 1324 kann verwendet werden, um eine drahtlose Verbindung über das Internet mit der Cloud (z. B. mit (einem) Server(n) 1378 und/oder anderen Netzwerkvorrichtungen), mit anderen Fahrzeugen und/oder mit Rechenvorrichtungen (z. B. Client-Vorrichtungen von Fahrgästen) zu ermöglichen. Zum Kommunizieren mit anderen Fahrzeugen kann eine direkte Verknüpfung zwischen den zwei Fahrzeugen hergestellt werden und/oder eine indirekte Verknüpfung (z. B. über Netzwerke und über das Internet) hergestellt werden. Direkte Verknüpfungen können unter Verwendung einer Fahrzeug-zu-Fahrzeug-Kommunikationsverknüpfung hergestellt werden. Eine Fahrzeug-zu-Fahrzeug-Kommunikationsverknüpfung kann dem Fahrzeug 1300 Informationen über Fahrzeuge in der Nähe des Fahrzeugs 1300 bereitstellen (z. B. Fahrzeuge vor, neben und/oder hinter dem Fahrzeug 1300). Die vorgenannte Funktionalität kann Teil einer kooperativen adaptiven Geschwindigkeitssteuerungsfunktionalität des Fahrzeugs 1300 sein.

Die Netzwerkschnittstelle 1324 kann ein SoC beinhalten, das eine Modulations- und Demodulationsfunktionalität bereitstellt und es den Steuerungen 1336 ermöglicht, über drahtlose Netzwerke zu kommunizieren. Die Netzwerkschnittstelle 1324 kann ein Hochfrequenz-Frontend für die Aufwärtskonvertierung vom Basisband auf die Hochfrequenz und die Abwärtskonvertierung von der Hochfrequenz auf das Basisband beinhalten. Die Frequenzkonvertierungen können durch hinreichend bekannte Prozesse und/oder unter Verwendung von Überlagerungsverfahren durchgeführt werden. In einigen Beispielen kann die Radiofrequenz-Front-End-Funktionalität von einem separaten Chip bereitgestellt werden. Die Netzwerkschnittstelle kann eine drahtlose Funktionalität für die Kommunikation über LTE, WCDMA, UMTS, GSM, CDMA2000, Bluetooth, Bluetooth LE, Wi-Fi, Z-Wave, ZigBee, LoRaWAN und/oder andere drahtlose Protokolle beinhalten.

Das Fahrzeug 1300 kann ferner einen oder mehrere Datenspeicher 1328 beinhalten, die eine Speicherung außerhalb des Chips (z. B. außerhalb der SoC(s) 1304) beinhalten können. Der/die Datenspeicher 1328 können ein oder mehrere Speicherelemente umfassen, darunter RAM, SRAM, DRAM, VRAM, Flash, Festplatten und/oder andere Komponenten und/oder Vorrichtungen, die mindestens ein Datenbit speichern können.

Das Fahrzeug 1300 kann ferner einen oder mehrere GNSS-Sensoren 1358 beinhalten. Der/die GNSS-Sensor(en) 1358 (z. B. GPS, unterstützte GPS-Sensoren, Differential-GPS (DGPS)-Sensoren usw.), um bei der Kartierung, der Wahrnehmung, der Erstellung von Belegungsrastern und/oder der Pfadplanung zu helfen. Eine beliebige Anzahl von GNSS-Sensor(en) 1358 kann verwendet werden, einschließlich zum Beispiel und ohne Einschränkung eines GPS unter Verwendung eines USB-Steckers mit einer Ethernet-zu-Seriell-Brücke (z. B. RS-232-Brücke).

Das Fahrzeug 1300 kann ferner einen oder mehrere RADAR-Sensoren 1360 beinhalten. Der/die RADAR-Sensor(en) 1360 können vom Fahrzeug 1300 zur Fahrzeugerkennung mit großer Reichweite verwendet werden, auch bei Dunkelheit und/oder schlechten Wetterbedingungen. Die RADAR-Funktionssicherheitslevel können ASIL B sein. Der/die RADAR-Sensor(en) 1360 können CAN und/oder den Bus 1302 (z. B. zur Übertragung der von dem/den RADAR-Sensor(en) 1360 erzeugten Daten) zur Steuerung von und zum Zugriff auf Objektverfolgungsdaten verwenden, wobei in einigen Beispielen der Zugriff auf Rohdaten über Ethernet erfolgt. Eine große Vielfalt von RADAR-Sensortypen kann verwendet werden. Zum Beispiel und ohne Einschränkung können die RADAR-Sensor(en) 1360 für die Verwendung als Front-, Heck- und Seiten-RADAR geeignet sein. In einigen Beispielen werden Puls-Doppler-RADAR-Sensoren verwendet.

Der bzw. die RADAR-Sensor(en) 1360 kann bzw. können unterschiedliche Konfigurationen beinhalten, wie etwa lange Reichweite mit schmalem Sichtfeld, kurze Reichweite mit breitem Sichtfeld, Seitenabdeckung mit kurzer Reichweite usw. In einigen Beispielen kann RADAR mit langer Reichweite zur Funktionalität der adaptiven Geschwindigkeitsregelung verwendet werden. Die RADAR-Systeme können mit großer Reichweite ein breites Sichtfeld bereitstellen, das durch zwei oder mehr unabhängige Scans realisiert wird, z. B. innerhalb einer Reichweite von 250 m. Die RADAR-Sensoren 1360 können bei der Unterscheidung zwischen statischen und sich bewegenden Objekten helfen und von ADAS-Systemen zur Notbremsunterstützung und Kollisionswarnung verwendet werden. RADAR-Systeme mit großer Reichweite können ein monostatisches multimodales RADAR mit mehreren (z. B. sechs oder mehr) festen RADAR-Antennen und einer Hochgeschwindigkeits-CAN- und FlexRay-schnittstelle beinhalten. In einem Beispiel mit sechs Antennen können die vier zentrale Antennen ein fokussiertes Strahlenmuster erzeugen, das dazu ausgestaltet ist, die Umgebung des Fahrzeugs 1300 bei höheren Geschwindigkeiten mit minimalen Störungen durch den Verkehr auf den benachbarten Fahrspuren aufzuzeichnen. Die beiden anderen Antennen können das Sichtfeld erweitern, wodurch es möglich ist, Fahrzeuge, die in die Fahrspur des Fahrzeugs 1300 einfahren oder diese verlassen, schnell zu erkennen.

RADAR-Systeme mit mittlerer Reichweite können beispielsweise eine Reichweite von bis zu 1360 m (vorne) oder 80 m (hinten) und ein Sichtfeld von bis zu 42 Grad (vorne) oder 1350 Grad (hinten) beinhalten. RADAR-Systeme mit kurzer Reichweite können ohne Einschränkung RADAR-Sensoren beinhalten, die für die Installation an beiden Enden des hinteren Stoßfängers konstruiert sind. Wenn das RADAR-Sensorsystem an beiden Enden des hinteren Stoßfängers installiert ist, kann ein derartiges RADAR-Sensorsystem zwei Strahlen erzeugen, die den toten Winkel hinter und neben dem Fahrzeug konstant überwachen.

RADAR-Systeme mit kurzer Reichweite können in einem ADAS-System zur Detektion des toten Winkels und/oder zur Spurwechselassistenz verwendet werden.

Das Fahrzeug 1300 kann ferner einen oder mehrere UltraschallSensoren 1362 beinhalten. Der/die Ultraschallsensor(en) 1362, die vorne, hinten und/oder an den Seiten des Fahrzeugs 1300 positioniert sein können, können als Einparkhilfe und/oder zur Erstellung und Aktualisierung eines Belegungsgitters verwendet werden. Eine große Vielfalt von Ultraschallsensor(en) 1362 kann verwendet werden und können unterschiedliche Ultraschallsensor(en) 1362 können für unterschiedliche Erkennungsreichweiten (z. B. 2,5 m, 4 m) verwendet werden. Der/die Ultraschallsensor(en) 1362 können bei funktionellen Sicherheitslevels von ASIL B arbeiten.

Das Fahrzeug 1300 kann einen oder mehrere LIDAR-Sensoren 1364 beinhalten. Der/die LIDAR-Sensor(en) 1364 können zur Objekt- und Fußgängererkennung, Notbremsung, Kollisionsvermeidung und/oder andere Funktionen verwendet werden. Der/die LIDAR-Sensor(en) 1364 können dem funktionellen Sicherheitslevel ASIL B entsprechen. In einigen Beispielen kann das Fahrzeug 1300 mehrere LIDAR-Sensoren 1364 (z. B. zwei, vier, sechs usw.) beinhalten, die Ethernet verwenden können (um z. B. Daten für einen Gigabit-Ethernet-Switch bereitzustellen).

In einigen Beispielen können die LIDAR-Sensor(en) 1364 dazu in der Lage sein, eine Liste von Objekten und deren Abstände für ein 360-Grad-Sichtfeld bereitzustellen. Handelsübliche LIDAR-Sensor(en) 1364 können zum Beispiel eine beworbene Reichweite von ungefähr 1300 m aufweisen, mit einer Genauigkeit von 2 cm-3 cm und mit Unterstützung für eine 1300 Mbps-Ethernet-Verbindung. In einigen Beispielen können ein oder mehrere nicht vorstehende LIDAR-Sensoren 1364 verwendet werden. In solchen Beispielen können der/die LIDAR-Sensor(en) 1364 als eine kleine Vorrichtung implementiert werden, das in die Front, das Heck, die Seiten und/oder die Ecken des Fahrzeugs 1300 eingebettet werden kann. Der/die LIDAR-Sensor(en) 1364 können in solchen Beispielen ein horizontales Sichtfeld von bis zu 120 Grad und ein vertikales Sichtfeld von bis zu 35 Grad mit einer Reichweite von 200 m selbst bei Objekten mit niedrigem Reflexionsvermögen bereitstellen. Die an der Front montierte(n) LIDAR-Sensor(en) 1364 können für ein horizontales Sichtfeld zwischen 45 Grad und 135 Grad konfiguriert sein.

In einigen Beispielen können auch LIDAR-Technologien, wie etwa 3D-Flash-LIDAR, verwendet werden. 3D-Flash-LIDAR verwendet einen Laserblitz als Sendequelle, um die Umgebung des Fahrzeugs bis zu einer Entfernung von ca. 200 m zu beleuchten. Eine Flash-LIDAR-Einheit beinhaltet einen Rezeptor, der die Laserpuls-Laufzeit und das reflektierte Licht an jedem Pixel aufzeichnet, was wiederum der Reichweite vom Fahrzeug zu den Objekten entspricht. Flash-LIDAR kann ermöglichen, dass mit jedem Laserblitz hochgenaue und verzerrungsfreie Bilder der Umgebung erzeugt werden. In einigen Beispielen können vier Flash-LIDAR-Sensoren eingesetzt werden, einer an jeder Seite des Fahrzeugs 1300. Verfügbare 3D-Flash-LIDAR-Systeme beinhalten eine Festkörper-3D-Staring-Array-LIDAR-Kamera ohne bewegliche Teile außer einem Lüfter (z. B. eine nicht scannende LIDAR-Vorrichtung). Die Flash-LIDAR-Vorrichtung kann einen 5-Nanosekunden-Laserpuls der Klasse I (augensicher) pro Bild verwenden und kann das reflektierte Laserlicht in Form von den 3D-Reichweitenpunktwolken und gemeinsam registrierten Intensitätsdaten erfassen. Durch die Verwendung von Flash-LIDAR und weil Flash-LIDAR eine Festkörpervorrichtung ohne bewegliche Teile ist, ist der/die LIDAR-Sensor(en) 1364 weniger anfällig für Bewegungsunschärfe, Vibrationen und/oder Stöße.

Das Fahrzeug kann ferner IMU-Sensor(en) 1366 beinhalten. Der/die IMU-Sensor(en) 1366 kann/können sich in einigen Beispielen in der Mitte der Hinterachse des Fahrzeugs 1300 befinden. Der/die IMU-Sensor(en) 1366 können zum Beispiel und ohne Einschränkung (einen) Beschleunigungsmesser, (ein) Magnetometer, (ein) Gyroskop(e), (einen) Magnetkompass(e) und/oder andere Sensorarten beinhalten. In einigen Beispielen, wie etwa in sechsachsigen Anwendungen, kann der/die IMU-Sensor(en) 1366 Beschleunigungsmesser und Gyroskope beinhalten, während in neunachsigen Anwendungen der/die IMU-Sensor(en) 1366 Beschleunigungsmesser, Gyroskope und Magnetometer beinhalten können.

In einigen Ausführungsformen können die IMU-Sensor(en) 1366 als miniaturisiertes GPS-gestütztes Trägheitsnavigationssystem (GPS-Aided Inertial Navigation System - GPS/INS) mit hoher Rechenleistung implementiert sein, das Trägheitssensoren von mikroelektromechanischen Systemen (micro-electromechanical systems - MEMS), einen hochempfindlichen GPS-Empfänger und weiterentwickelte Kalman-Filteralgorithmen kombiniert, um Schätzungen von Position, Geschwindigkeit und Lage bereitzustellen. Wie in solchen Beispielen können der/die IMU-Sensor(en) 1366 es dem Fahrzeug 1300 ermöglichen, den Kurs zu schätzen, ohne dass Eingaben von einem Magnetsensor erforderlich sind, indem vom GPS an den/die IMU-Sensor(en) 1366 Änderungen der Geschwindigkeit direkt beobachtet und korreliert werden. In einigen Beispielen können die IMU-Sensor(en) 1366 und GNSS-Sensor(en) 1358 in einer einzelnen integrierten Einheit kombiniert sein.

Das Fahrzeug kann ein oder mehrere Mikrofone 1396 beinhalten, die in und/oder um das Fahrzeug 1300 herum angebracht sind. Die Mikrofone 1396 können unter anderem zur Erkennung und Identifizierung von Rettungsfahrzeugen verwendet werden.

Das Fahrzeug kann ferner eine beliebige Anzahl von Kameratypen beinhalten, darunter Stereokamera(s) 1368, Weitsichtkamera(s) 1370, Infrarotkamera(s) 1372, Rundumkamera(s) 1374, Langstrecken- und/oder Mittelstreckenkamera(s) 1398 und/oder andere Kameratypen. Die Kameras können verwendet werden, um Bilddaten um die gesamte Peripherie des Fahrzeugs 1300 herum zu erfassen. Die Art der verwendeten Kameras hängt von den Ausführungsformen und Anforderungen für das Fahrzeug 1300 ab, und es kann eine beliebige Kombination von Kameratypen verwendet werden, um die erforderliche Abdeckung rund um das Fahrzeug 1300 bereitzustellen. Zusätzlich kann die Anzahl der Kameras in Abhängigkeit von der Ausführungsform unterschiedlich sein. Zum Beispiel kann das Fahrzeug sechs Kameras, sieben Kameras, zehn Kameras, zwölf Kameras und/oder eine andere Anzahl von Kameras beinhalten. Die Kameras können zum Beispiel und ohne Einschränkung Gigabit Multimedia Serial Link (GMSL) und/oder Gigabit Ethernet unterstützen. Jede der Kameras wird hier mit Bezug auf 13A und 13B näher beschrieben.

Das Fahrzeug 1300 kann ferner einen oder mehrere Schwingungssensor(en) 1342 beinhalten. Der/die Vibrationssensor(en) 1342 können Vibrationen von Komponenten des Fahrzeugs, wie z. B. der der Achse(n), messen. Zum Beispiel können Änderungen der Vibrationen eine Änderung des Straßenbelags angeben. In einem weiteren Beispiel, wenn zwei oder mehr Vibrationssensoren 1342 verwendet werden, können die Unterschiede zwischen den Vibrationen verwendet werden, um die Reibung oder den Schlupf des Straßenbelags zu bestimmen (z. B., wenn der Unterschied der Vibration zwischen einer leistungsbetriebenen Achse und einer sich frei drehenden Achse besteht).

Das Fahrzeug 1300 kann ein ADAS-System 1338 beinhalten. Das ADAS-System 1338 kann in einigen Beispielen ein SoC beinhalten. Das ADAS-System 1338 kann autonome/adaptive/automatische Geschwindigkeitssteuerung (autonomous/adaptive/automatic cruise control - ACC), kooperative adaptive Geschwindigkeitssteuerung (cooperative adaptive cruise control - CACC), Vorwärtszusammenstoßwarnungen (forward crash warning - FCW), automatisches Notbremsen (AEB), Spurverlassenswarnungen (lane departure warning - LDW), Spurhalteassistenz (lane keep assist - LKA), Totwinkelwarnung (blind spot warning - BSW), Querverkehrswarnung (rear cross-traffic warning - RCTW), Kollisionswarn (collision warning - CWS)-Systeme, Spurzentrierung (lane centering - LC) und/oder andere Systeme, Merkmale und/oder Funktionen beinhalten.

Die ACC-Systeme können RADAR-Sensor(en) 1360, LIDAR-Sensor(en) 1364 und/oder eine Kamera(s) verwenden. Die ACC-Systeme können eine ACC in Längsrichtung und/oder eine ACC in Querrichtung beinhalten. Die Längs-ACC steuert den Abstand zum Fahrzeug, das sich unmittelbar vor dem Fahrzeug 1300 befindet, und passt die Fahrzeuggeschwindigkeit automatisch an, um einen sicheren Abstand zu vorausfahrenden Fahrzeugen einzuhalten. Die Quer-ACC führt eine Abstandshaltung durch und rät dem Fahrzeug 1300, die Fahrspuren zu wechseln, wenn dies erforderlich ist. Die Quer-ACC ist mit anderen ADAS-Anwendungen, wie zum Beispiel LCA und CWS, verbunden.

Die CACC verwendet Informationen von anderen Fahrzeugen, die über die Netzwerkschnittstelle 1324 und/oder die drahtlose(n) Antenne(n) 1326 von anderen Fahrzeugen über eine drahtlose Verknüpfung oder indirekt über eine Netzwerkverbindung (z. B. über das Internet) empfangen werden können. Direkte Verknüpfungen können durch eine Fahrzeug-zu-Fahrzeug (V2V)-Kommunikationsverknüpfung bereitgestellt werden, während indirekte Verknüpfungen durch eine Infrastruktur-zu-Fahrzeug (12V)-Kommunikationsverknüpfung bereitgestellt werden können. Im Allgemeinen stellt das V2V-Kommunikationskonzept Informationen über unmittelbar vorausfahrende Fahrzeuge (z. B. Fahrzeuge, die sich unmittelbar vor dem und auf derselben Spur wie das Fahrzeug 1300 befinden) bereit, während das 12V-Kommunikationskonzept Informationen über den weiter entfernt vorausfahrenden Verkehr bereitstellt. CACC-Systeme können entweder eines oder beides von 12V- und V2V-Informationsquellen beinhalten. Angesichts der Informationen über die Fahrzeuge vor dem dem Fahrzeug 1300 kann die CACC zuverlässiger sein und hat das Potenzial, den Gleichmäßigkeit des Verkehrsfluss zu verbessern und Staus auf der Straße zu reduzieren.

FCW-Systeme sind so ausgelegt, dass sie den Fahrer vor einer Gefahr warnen, sodass er entsprechende Maßnahmen ergreifen kann. FCW-Systeme verwenden eine nach vorn gerichtete Kamera und/oder RADAR-Sensor(en) 1360, die mit einem dedizierten Prozessor, DSP, FPGA und/oder ASIC gekoppelt sind, die elektrisch mit einer Rückmeldung des Fahrers gekoppelt sind, wie z. B. einer Anzeige, einem Lautsprecher und/oder einer vibrierenden Komponente. FCW-Systeme können eine Warnung bereitstellen, z. B. in Form eines Tons, einer optischen Warnung, einer Vibration und/oder eines schnellen Bremsimpulses.

AEB-Systeme erkennen eine drohende Vorwärtskollision mit einem anderen Fahrzeug oder einem anderen Objekt und kann automatisch die Bremsen betätigen, wenn der Fahrer nicht innerhalb eines spezifizierten Zeit- oder Abstandsparameters eine korrigierende Handlung durchführt. AEB-Systeme können nach vorn gerichtete Kamera(s) und/oder RADAR-Sensor(en) 1360 verwenden, die mit einem dedizierten Prozessor, DSP, FPGA und/oder ASIC gekoppelt sind. Wenn das AEB-System eine Gefahr erkennt, warnt es typischerweise zuerst den Fahrer, um eine korrigierende Handlung durchzuführen, um eine Kollision zu vermeiden, und, wenn der Fahrer keine korrigierenden Handlung durchführt, kann das AEB-System automatisch die Bremsen in dem Bestreben betätigen, die Auswirkungen der vorhergesagten Kollision zu verhindern oder mindestens abzuschwächen. AEB-Systeme können Techniken, wie zum Beispiel dynamische Bremsunterstützung und/oder Bremsung aufgrund eines bevorstehenden Zusammenstoßes, beinhalten.

LDW-Systeme stellen visuelle, akustische und/oder taktile Warnungen wie etwa Lenkrad- oder Sitzschwingungen bereit, um den Fahrer darauf aufmerksam zu machen, wenn das Fahrzeug 1300 Spurmarkierungen überquert. Ein LDW-System wird nicht aktiviert, wenn der Fahrer ein absichtliches Verlassen der Fahrspur anzeigt, indem er den Blinker betätigt. LDW-Systeme können nach vorne gerichtete Kameras verwenden, die mit einem dedizierten Prozessor, DSP, FPGA und/oder ASIC gekoppelt sind, die elektrisch mit einer Rückmeldung des Fahrers gekoppelt sind, wie z. B. einer Anzeige, einem Lautsprecher und/oder einer vibrierenden Komponente.

LKA-Systeme sind eine Variante der LDW-Systeme. LKA-Systeme stellen eine Lenkeingabe oder eine Bremsung bereit, um das Fahrzeug 1300 zu korrigieren, wenn das Fahrzeug 1300 beginnt, die Fahrspur zu verlassen.

BSW-Systeme erkennen und warnen den Fahrer vor Fahrzeugen in einem toten Winkel eines Automobils. BSW-Systeme können einen optischen, akustischen und/oder taktilen Alarm bereitstellen, um anzugeben, dass Einfädeln in oder Wechseln der Fahrspuren unsicher ist. Das System kann eine zusätzliche Warnung bereitstellen, wenn der Fahrer einen Blinker setzt. BSW-Systeme können (eine) nach hinten und zur Seite gerichtete Kamera(s) und/oder RADAR-Sensor(en) 1360 verwenden, die an einen dedizierten Prozessor, DSP, FPGA und/oder ASIC gekoppelt sind, das heißt elektrisch an eine Rückführung des Fahrers gekoppelt, wie etwa eine Anzeige, einen Lautsprecher und/oder eine schwingende Komponente.

RCTW-Systeme können eine optische, akustische und/oder taktile Benachrichtigung bereitstellen, wenn ein Objekt außerhalb der Reichweite der Heckkamera erkannt wird, wenn das Fahrzeug 1300 rückwärts fährt. Einige RCTW-Systeme beinhalten das AEB-System, um sicherzustellen, dass die Fahrzeugbremsen betätigt werden, um einen Zusammenstoß zu vermeiden. Die RCTW-Systeme können einen oder mehrere nach hinten gerichtete RADAR-Sensor(en) 1360 verwenden, die mit einem dedizierten Prozessor, DSP, FPGA und/oder ASIC gekoppelt sind, die elektrisch mit einer Rückmeldung des Fahrers gekoppelt sind, wie z. B. einer Anzeige, einem Lautsprecher und/oder einer vibrierenden Komponente.

Herkömmliche ADAS-Systeme können anfällig für falsch positive Ergebnisse sein, die für den Fahrer ärgerlich und ablenkend sein können, aber typischerweise nicht katastrophal sind, da die ADAS-Systeme den Fahrer warnen und es dem Fahrer ermöglichen, zu entscheiden, ob wirklich eine Sicherheitsbedingung vorliegt, und entsprechend zu handeln. In einem autonomen Fahrzeug 1300 muss das Fahrzeug 1300 jedoch bei widersprüchlichen Ergebnissen selbst entscheiden, ob es das Ergebnis eines primären Computers oder eines sekundären Computers (z. B. einer ersten Steuerung 1336 oder einer zweiten Steuerung 1336) beachtet. In einigen Ausführungsformen kann das ADAS-System 1338 beispielsweise ein Backup- und/oder sekundärer Computer sein, der Wahrnehmungsinformationen für ein Rationalitätsmodul eines Backup-Computers bereitstellt. Der Rationalitätsmonitor des Backup-Computers kann eine redundante, diverse Software auf HardwareKomponenten ausführen, um Fehler in der Wahrnehmung und bei dynamischen Fahraufgaben zu erkennen. Die Ausgaben des ADAS-Systems 1338 können für eine Überwachungs-MCU bereitgestellt werden. Wenn die Ausgaben des primären und des sekundären Computers miteinander in Konflikt geraten, muss die Kontroll-MCU bestimmen, wie der Konflikt beigelegt werden kann, um einen sicheren Betrieb zu gewährleisten.

In einigen Beispielen kann der primäre Computer so konfiguriert sein, dass er der Kontroll-MCU eine Konfidenzbewertung bereitstellt, welche die Konfidenz des primären Computers in das gewählte Ergebnis angibt. Wenn die Konfidenzbewertung einen Schwellenwert überschreitet, kann die Kontroll-MCU der Führung des primären Computers folgen, unabhängig davon, ob der sekundäre Computer ein widersprüchliches oder inkonsistentes Ergebnis bereitstellt. Wo die Konfidenzbewertung den Schwellenwert nicht erreicht und der primäre und der sekundäre Computer unterschiedliche Ergebnisse angeben (z. B. einen Widerspruch), kann die Kontroll-MCU zwischen den Computern vermitteln, um ein geeignetes Resultat zu bestimmen.

Die Überwachungs-MCU kann so konfiguriert sein, dass sie neuronale(s) Netz(e) ausführt, die dafür trainiert und konfiguriert sind, mindestens auf Grundlage von Ausgaben aus dem primären Computer und dem sekundären Computer die Bedingungen zu bestimmen, unter denen der sekundäre Computer Fehlalarme bereitstellt. Folglich können das/die neuronale Netz(e) in der Überwachungs-MCU lernen, wann der Ausgabe eines sekundären Computers vertraut werden kann und wann nicht. Zum Beispiel können, wenn der sekundäre Computer ein RADAR-basiertes FCW-System ist, neuronale Netz(e) in der Überwachungs-MCU lernen, wann das FCW-System metallische Objekte identifiziert, die tatsächlich keine Gefahren sind, wie etwa ein Abflussgitter oder ein Gullydeckel, das/der einen Alarm auslöst. Ähnlich, wenn der sekundäre Computer ein kamerabasiertes LDW-System ist, kann ein neuronales Netz in der Kontroll-MCU lernen, die LDW zu überschreiben, wenn Fahrradfahrer oder Fußgänger vorhanden sind und ein Verlassen der Fahrspur tatsächlich das sicherste Manöver ist. In Ausführungsformen, die ein oder mehrere neuronale Netzwerke beinhalten, die auf der Kontroll-MCU laufen, kann die Kontroll-MCU mindestens eine DLA oder GPU beinhalten, die für die Ausführung des oder der neuronalen Netze mit zugewiesenem Speicher geeignet ist. In bevorzugten Ausführungsformen kann die Überwachungs-MCU eine Komponente eines oder mehrerer der SoC(s) 1304 umfassen und/oder als solche enthalten sein.

In anderen Beispielen kann das ADAS-System 1338 einen sekundären Computer beinhalten, der die ADAS-Funktionalität unter Verwendung der herkömmlichen Regeln des maschinellen Sehens durchführt. Als solcher kann der sekundäre Computer klassische Regeln des maschinellen Sehens (wenn-dann) verwenden und kann das Vorhandensein eines neuronalen Netzes/von neuronalen Netzen in der Kontroll-MCU die Zuverlässigkeit, Sicherheit und Performance verbessern. Zum Beispiel macht die vielfältige Implementation und absichtliche Nicht-Identität das Gesamtsystem fehlertoleranter, insbesondere gegenüber Fehlern, die durch Software(oder Software-Hardware-Schnittstellen)-Funktionalität verursacht werden. Wenn zum Beispiel ein Software-Bug oder -Fehler in der auf dem primären Computer laufenden Software vorliegt und der nicht identische Software-Code, der auf dem sekundären Computer läuft, dasselbe Gesamtergebnis bereitstellt, kann die Überwachungs-MCU eine größere Konfidenz darin haben, dass das Gesamtergebnis korrekt ist und der Bug in der Software oder Hardware auf dem primären Computer keinen wesentlichen Fehler verursacht.

In einigen Beispielen kann die Ausgabe des ADAS-Systems 1338 in einen Wahrnehmungsblock des primären Computers und/oder in einen Block für dynamische Fahr-Tasks des primären Computers eingespeist werden. Wenn das ADAS-System 1338 z. B. eine Vorwärtszusammenstoßwarnung aufgrund eines unmittelbar vorausliegenden Objekts angibt, kann der Wahrnehmungsblock diese Information bei der Identifizierung von Objekten verwenden. In anderen Beispielen kann der sekundäre Computer über sein eigenes neuronales Netz verfügen, das trainiert ist und somit das Risiko von falsch positiven Ergebnissen reduziert, wie hierin beschrieben.

Das Fahrzeug 1300 kann ferner das Infotainment-SoC 1330 (z. B. ein fahrzeuginternes Infotainment-System (in-vehicle infotainment system - IVI-System)) beinhalten. Obwohl als ein SoC veranschaulicht und beschrieben, kann das Infotainment-System kein SoC sein und kann zwei oder mehr diskrete Komponenten beinhalten. Das Infotainment-SoC 1330 kann eine Kombination aus Hardware und Software beinhalten, die verwendet werden kann, um dem Fahrzeug 1300 Audio (z. B. Musik, einen persönlichen digitalen Assistenten, Navigationsanweisungen, Nachrichten, Radio usw.), Video (z. B. TV, Filme, Streaming usw.), Telefon (z. B. Freisprechen), Netzverbindungsfähigkeit (z. B. LTE, Wi-Fi usw.) und/oder Informationsdienste (z. B. Navigationssysteme, Rückwärtseinparkhilfe, ein Radiodatensystem, fahrzeugbezogene Informationen wie etwa Kraftstofffüllstand, insgesamt zurückgelegte Strecke, Bremskraftstofffüllstand, Ölfüllstand, Tür öffnen/schließen, Luftfilterinformationen usw.) bereitzustellen. Das Infotainment-SoC 1330 kann zum Beispiel Radios, Plattenspieler, Navigationssysteme, Videowiedergabevorrichtungen, USB- und Bluetooth-Verbindungsfähigkeit, Carputer, In-Car-Entertainment, Wi-Fi, Audiosteuerelemente am Lenkrad, ein Freisprech-Sprachsteuerelement, eine Heads-up-Anzeige (heads-up display - HUD), eine HMI-Anzeige 1334, eine Telematikvorrichtung, ein Steuerfeld (z. B. zum Steuern von und/oder Interagieren mit verschiedenen Komponenten, Merkmalen und/oder Systemen) und/oder andere Komponenten beinhalten. Das Infotainment-SoC 1330 kann ferner dazu verwendet werden, um einem Benutzer(n) des Fahrzeugs Informationen (z. B. optisch und/oder akustisch) bereitzustellen, wie z. B. Informationen vom ADAS-System 1338, Informationen zum autonomen Fahren, wie z. B. geplante Fahrzeugmanöver, Trajektorien, Umgebungsinformationen (z. B. Kreuzungsinformationen, Fahrzeuginformationen, Straßeninformationen usw.) und/oder andere Informationen.

Das Infotainment-SoC 1330 kann GPU-Funktionen beinhalten. Der Infotainment-SoC 1330 kann über den Bus 1302 (z. B. CAN-Bus, Ethernet usw.) mit anderen Vorrichtungen, Systemen und/oder Komponenten des Fahrzeugs 1300 kommunizieren. In einigen Beispielen kann das Infotainment-SoC 1330 an eine Überwachungs-MCU gekoppelt sein, sodass die GPU des Infotainment-Systems einige Selbstfahrfunktionen ausführen kann, falls die primäre(n) Steuerung(en) 1336 (z. B. primäre und/oder Reserve-Computer des Fahrzeugs 1300) ausfallen. In einem solchen Beispiel kann der Infotainment-SoC 1330 das Fahrzeug 1300 in einen Chauffeur-zu-Safe-Stop-Modus versetzen, wie hier beschrieben.

Das Fahrzeug 1300 kann ferner ein Kombiinstrument 1332 (z. B. ein digitales Armaturenbrett, ein elektronisches Kombiinstrument, eine digitale Instrumententafel usw.) beinhalten. Das Kombiinstrument 1332 kann eine Steuerung und/oder einen Supercomputer (z. B. eine diskrete Steuerung oder einen diskreten Supercomputer) beinhalten. Das Kombiinstrument 1332 kann einen Satz von Instrumenten wie etwa einen Geschwindigkeitsmesser, Kraftstofffüllstand, Öldruck, Tachometer, Wegstreckenzähler, Blinker, Schaltpositionsanzeige, Sicherheitsgurtwarnleuchte(n), Parkbremswarnleuchte(n), Motorfehlfunktionsleuchte(n), Airbag- (SRS-) Systeminformationen, Beleuchtungssteuerelemente, Sicherheitssystemsteuerelemente, Navigationsinformationen usw. beinhalten. In einigen Beispielen können Informationen angezeigt und/oder zwischen dem Infotainment-SoC 1330 und dem Kombiinstrument 1332 geteilt werden. In anderen Worten kann das Kombiinstrument 1332 als Teil des Infotainment-SoC 1330 enthalten sein oder umgekehrt.

13D ist ein Systemdiagramm für die Kommunikation zwischen dem/den cloudbasierten Server(n) und dem beispielhaften autonomen Fahrzeug 1300 von 13A, gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Der System 1376 kann den Server 1378, die Netzwerk(e) 1390 und Fahrzeuge, einschließlich des Fahrzeugs 1300 beinhalten. Der/die Server 1378 kann/können eine Vielzahl von GPUs 1384(A)-1384(H) (hierin zusammenfassend als GPUs 1384 bezeichnet), PCIe-Switches 1382(A)-1382(H) (hierin zusammenfassend als PCIe-Switches 1382 bezeichnet) und/oder CPUs 1380(A)-1380(B) (hierin zusammenfassend als CPUs 1380 bezeichnet) beinhalten. Die GPUs 1384, CPUs 1380 und PCIe-Switches können mit Hochgeschwindigkeitszusammenschaltungen miteinander verbunden sein, wie etwa und ohne Einschränkung den von NVIDIA entwickelten NVLink-Schnittstellen 1388 und/oder PCIe-Verbindungen 1386. In einigen Beispielen sind die GPUs 1384 über ein NVLink- und/oder NVSwitch-SoC verbunden und die GPUs 1384 und die PCIe-Switches 1382 über PCIe-Zusammenschaltungen verbunden. Obwohl acht GPUs 1384, zwei CPUs 1380 und zwei PCIe-Switches veranschaulicht sind, soll dies nicht einschränkend sein. Je nach Ausführungsform kann jeder der Server 1378 eine beliebige Anzahl von GPUs 1384, CPUs 1380 und/oder PCIe-Switches beinhalten. Zum Beispiel können der/die Server 1378 jeweils acht, sechzehn, zweiunddreißig und/oder mehr GPUs 1384 beinhalten.

Der/die Server 1378 können über die Netzwerk(e) 1390 und von Fahrzeugen Bilddaten empfangen, die für Bilder repräsentativ sind, die unerwartete oder veränderte Straßenbedingungen zeigen, wie etwa kürzlich begonnene Straßenarbeiten. Der/die Server 1378 können über die Netzwerk(e) 1390 und an die Fahrzeuge neuronale Netze 1392, aktualisierte neuronale Netze 1392 und/oder Karteninformationen 1394 übertragen, einschließlich Informationen über Verkehrs- und Straßenbedingungen. Die Aktualisierungen der Karteninformationen 1394 können Aktualisierungen für die HD-Karte 1322 beinhalten, wie etwa Informationen bezüglich Baustellen, Schlaglöchern, Umleitungen, Überschwemmungen und/oder anderer Hindernisse. In einigen Beispielen können die neuronalen Netze 1392, aktualisierten neuronalen Netze 1392 und/oder Karteninformationen 1394 aus einem neuen Training und/oder Erfahrungen resultieren, das/die in Daten dargestellt wird/werden, die von einer beliebigen Anzahl von Fahrzeugen in der Umgebung empfangen wurden, und/oder basierend auf Training, das in einem Rechenzentrum (z. B. unter Verwendung von dem/den Server(n) 1378 und/oder anderen Servern) durchgeführt wurde.

Der/die Server 1378 können verwendet werden, um Modelle des maschinellen Lernens (z. B. neuronale Netze) basierend auf Trainingsdaten zu trainieren. Die Trainingsdaten von Fahrzeugen können erzeugt werden und/oder können sie in einer Simulation (z. B. unter Verwendung einer Spiele-Engine) erzeugt werden. In einigen Beispielen werden die Trainingsdaten mit Tags versehen (z. B. wenn das neuronale Netz von überwachtem Lernen profitiert) und/oder einer anderen Vorverarbeitung unterzogen, während in anderen Beispielen die Trainingsdaten nicht mit Tags versehen und/oder vorverarbeitet werden (z. B. wenn das neuronale Netz kein überwachtes Lernen benötigt). Das Training kann nach einer oder mehreren Klassen von maschinellen Lerntechniken erfolgen, einschließlich, aber nicht beschränkt auf Klassen wie: überwachtes Training, halbüberwachtes Training, unüberwachtes Training, Selbstlernen, Verstärkungslernen, föderiertes Lernen, Transferlernen, Merkmalslernen (einschließlich Hauptkomponenten- und Clusteranalysen), multilineares Unterraum lernen, vielfältiges Lernen, Repräsentationslernen (einschließlich Ersatzwörterbuchlernen), regelbasiertes maschinelles Lernen, Anomalieerkennung und alle Varianten oder Kombinationen davon. Sobald die Modelle des maschinellen Lernens trainiert sind, können die Modelle des maschinellen Lernens durch Fahrzeuge verwendet werden (z. B. über die Netzwerke 1390 an Fahrzeuge übertragen werden) und/oder die Modelle des maschinellen Lernens können durch den/die Server 1378 verwendet werden, um Fahrzeuge aus der Ferne zu überwachen.

In einigen Beispielen kann der/können die Server 1378 Daten von den Fahrzeugen empfangen und die Daten auf aktuelle neuronale Echtzeit-Netze zum intelligenten Echtzeit-Inferenzieren anwenden. Der/die Server 1378 können Deep-Learning-Supercomputer und/oder dedizierte KI-Computer beinhalten, die durch die GPU(s) 1384 angetrieben werden, wie etwa die von NVIDIA entwickelten DGX- und DGX-Station-Maschinen. In einigen Beispielen können der/die Server 1378 jedoch eine Deep-Learning-Infrastruktur beinhalten, die nur CPU-angetriebene Rechenzentren verwendet.

Die Deep-Learning-Infrastruktur des/der Server(s) 1378 kann zum schnellen Echtzeit-Inferenzieren in der Lage sein und diese Fähigkeit verwenden, um den Zustand von Prozessoren, Software und/oder assoziierter Hardware in dem Fahrzeug 1300 zu bewerten und zu verifizieren. Zum Beispiel kann die Deep-Learning-Infrastruktur periodische Aktualisierungen von dem Fahrzeug 1300 empfangen, wie etwa eine Sequenz von Bildern und/oder Objekten, die das Fahrzeug 1300 in dieser Sequenz von Bildern lokalisiert hat (z. B. über maschinelles Sehen und/oder andere Techniken des maschinellen Lernens zur Objektklassifizierung). Die Deep-Learning-Infrastruktur kann ihr eigenes neuronales Netz ausführen, um Objekte zu identifizieren und sie mit Objekten zu vergleichen, die durch das Fahrzeug 1300 identifiziert wurden, und falls die Ergebnisse nicht übereinstimmen und die Deep-Learning-Infrastruktur zu dem Schluss kommt, dass die KI in dem Fahrzeug 1300 eine Fehlfunktion aufweist, dann kann der/können die Server 1378 ein Signal an das Fahrzeug 1300 übertragen, das einen ausfallsicheren Computer des Fahrzeugs 1300 anweist, die Steuerung zu übernehmen, die Fahrgäste zu benachrichtigen und ein sicheres Parkmanöver durchzuführen.

Die Server 1378 können die GPU(s) 1384 und einen oder mehrere programmierbare Inferenzbeschleuniger (z. B. NVIDIAs TensorRT) beinhalten. Die Kombination von GPU-angetriebenen Servern und Ableitungsbeschleunigung kann eine Reaktionsfähigkeit in Echtzeit ermöglichen. In anderen Beispielen, wenn z. B. die Performance weniger kritisch ist, können von CPUs, FPGAs und anderen Prozessoren angetriebene Server für die Ableitung verwendet werden.

BEISPIELHAFTE RECHENVORRICHTUNG

14 ist ein Blockdiagramm einer beispielhaften Rechenvorrichtung(en) 1400, die zur Verwendung bei der Implementierung einiger Ausführungsformen der vorliegenden Offenbarung geeignet ist. Die Rechenvorrichtung 1400 kann ein Verschaltungssystem 1402 beinhalten, das die folgenden Vorrichtungen direkt oder indirekt koppelt: Speicher 1404, eine oder mehrere Zentraleinheiten (CPUs) 1406, eine oder mehrere Grafikverarbeitungseinheiten (GPUs) 1408, eine Kommunikationsschnittstelle 1410, Eingabe/Ausgabe(E/A)-Ports 1412, Eingabe-/Ausgabekomponenten 1414, eine Stromversorgung 1416, eine oder mehrere Präsentationskomponenten 1418 (z. B. Anzeige(n)) und eine oder mehrere Logikeinheiten 1420. In mindestens einer Ausführungsform kann/können die Rechenvorrichtung(en) 1400 eine oder mehrere virtuelle Maschinen (VM) umfassen und/oder jede ihrer Komponenten kann aus virtuellen Komponenten bestehen (z. B. virtuelle Hardwarekomponenten). Nicht einschränkende Beispiele können eine oder mehrere GPUs 1408 eine oder mehrere vGPUs umfassen, eine oder mehrere CPUs 1406 können eine oder mehrere vCPUs umfassen und/oder eine oder mehrere Logikeinheiten 1420 können eine oder mehrere virtuelle Logikeinheiten umfassen. Die Rechenvorrichtung(en) 1400 kann (können) somit diskrete Komponenten (z. B. eine vollständigen, der Rechenvorrichtung 1400 zugeordneten GPU), virtuelle Komponenten (z. B. einen Teil einer der Rechenvorrichtung 1400 zugeordneten GPU) oder eine Kombination davon beinhalten.

Auch wenn die verschiedenen Blöcke von 14 als über das Verschaltungssystem 1402 mit Leitungen verbunden gezeigt sind, soll dies nicht einschränkend sein und dient nur der Klarheit. Zum Beispiel kann in einigen Ausführungsformen eine Präsentationskomponente 1418, wie etwa Anzeigevorrichtung, als E/A-Komponente 1414 betrachtet werden (z. B. wenn die Anzeige ein Touchscreen ist). Als weiteres Beispiel können die CPUs 1406 und/oder GPUs 1408 Speicher beinhalten (z. B. kann der Speicher 1404 repräsentativ für eine Speichervorrichtung zusätzlich zum Speicher der GPUs 1408, der CPUs 1406 und/oder anderen Komponenten sein). Mit anderen Worten dient die Rechenvorrichtung aus 14 lediglich der Veranschaulichung. Es wird nicht zwischen Kategorien wie „Workstation“, „Server“, „Laptop“, „Desktop“, „Tablet“, „Client-Vorrichtung“, „mobile Vorrichtung“, „Handheld-Vorrichtung“, „Spielekonsole“, „elektronische Steuereinheit (electronic control unit - ECU),“ „Virtual-Reality-System“ und/oder andere Vorrichtungs- oder Systemtypen unterschieden, da alle im Umfang der Rechenvorrichtung der 14 betrachtet werden.

Das Verschaltungssystem 1402 kann eine oder mehrere Verbindungen oder Busse darstellen, wie beispielsweise einen Adressbus, einen Datenbus, einen Steuerbus oder eine Kombination davon. Das Verschaltungssystem 1402 kann einen oder mehrere Bus- oder Verbindungstypen beinhalten, wie beispielsweise einen Bus mit Industriestandardarchitektur (industry standard architecture - ISA), einen Bus mit erweiterter Industriestandardarchitektur (extended industry standard architecture - EISA), einen Bus der Video Electronic Standards Association (VESA), einen Bus für Verschaltung einer Periphärkomponente (PCI), ein Bus für Expressverschaltung einer Periphärkomponente (PCIe) und/oder eine andere Art von Bus oder Verbindung. In einigen Ausführungsformen gibt es direkte Verbindungen zwischen Komponenten. Als ein Beispiel kann die CPU 1406 direkt mit dem Speicher 1404 verbunden sein. Ferner kann die CPU 1406 direkt mit der GPU 1408 verbunden sein. Wo eine direkte oder Punkt-zu-Punkt-Verbindung zwischen Komponenten besteht, kann das Verschaltungssystem 1402 eine PCIe-Verbindung beinhalten, um die Verbindung auszuführen. In diesen Beispielen muss kein PCI-Bus in der Rechenvorrichtung 1400 beinhaltet sein.

Der Speicher 1404 kann eine beliebige Vielfalt computerlesbarer Medien beinhalten. Die computerlesbaren Medien können beliebige verfügbare Medien sein, auf welche die Rechenvorrichtung 1400 zugreifen kann. Die computerlesbaren Medien können sowohl flüchtige als auch nichtflüchtige Medien sowie entfernbare und nicht entfernbare Medien beinhalten. Beispielhaft und nicht einschränkend können die computerlesbaren Medien Computerspeichermedien und Kommunikationsmedien umfassen.

Die Computerspeichermedien können sowohl flüchtige als auch nichtflüchtige und/oder entfernbare und nicht entfernbare Medien beinhalten, die in jedem beliebigen Verfahren oder jeder beliebigen Technologie zum Speichern von Informationen wie etwa computerlesbare Anweisungen, Datenstrukturen, Programmmodule und/oder anderen Daten implementiert werden. Zum Beispiel kann der Speicher 1404 computerlesbare Anweisungen speichern (die z. B. ein Programm oder Programme und/oder ein oder mehrere Programmelemente darstellen, wie etwa ein Betriebssystem). Computerspeichermedien können RAM, ROM, EEPROM, Flash-Speicher oder andere Speichertechnologie, CD-ROM, Digital Versatile Disks (DVD) oder andere optische Plattenspeicher, Magnetkassetten, Magnetbänder, Magnetplattenspeicher oder andere magnetische Speichervorrichtungen oder jedes andere Medium beinhalten, das verwendet werden kann, um die gewünschten Informationen zu speichern und auf das die Rechenvorrichtung 1400 zugreifen kann, sind aber nicht darauf beschränkt. Im hierin verwendeten Sinne umfassen Computerspeichermedien keine Signale an sich.

Die Computerspeichermedien können computerlesbare Anweisungen, Datenstrukturen, Programmmodule und/oder andere Datentypen in einem modulierten Datensignal wie etwa einer Trägerwelle oder einem anderen Transportmechanismus verkörpern und beinhalten beliebige Informationsliefermedien. Der Begriff „moduliertes Datensignal“ kann sich auf ein Signal beziehen, bei dem eine oder mehrere seiner Eigenschaften so eingestellt oder geändert wurden, dass Informationen in dem Signal codiert sind. Als Beispiel und nicht einschränkend können die Computerspeichermedien drahtgebundene Medien beinhalten, wie etwa ein drahtgebundenes Netzwerk oder eine direkte drahtgebundene Verbindung, und drahtlose Medien, wie beispielsweise akustische, Funk-, Infrarot- und andere drahtlose Medien. Kombinationen aller Vorstehenden sollen ebenfalls im Umfang computerlesbarer Medien eingeschlossen sein.

Die CPU(s) 1406 können konfiguriert sein, um mindestens einige der computerlesbaren Anweisungen auszuführen, um eine oder mehrere Komponenten der Rechenvorrichtung 1400 zu steuern, um eines/einen oder mehrere der Verfahren und/oder Prozesse, die hierin beschrieben sind, auszuführen. Die CPU(s) 1406 können jeweils einen oder mehrere Kerne (z. B. einen, zwei, vier, acht, achtundzwanzig, zweiundsiebzig usw.) beinhalten, die in der Lage sind, eine Vielzahl von Software-Threads gleichzeitig zu handhaben. Die CPU(s) 1406 können eine beliebige Art von Prozessor beinhalten und können unterschiedliche Arten von Prozessoren beinhalten, abhängig von der Art der Rechenvorrichtung 1400 (z. B. Prozessoren mit weniger Kernen für mobile Vorrichtungen und Prozessoren mit mehr Kernen für Server). Zum Beispiel kann der Prozessor in Abhängigkeit von der Art der Rechenvorrichtung 1400 ein Advanced-RISC-Machines(ARM)-Prozessor sein, der unter Verwendung von Reduced Instruction Set Computing (RISC) implementiert ist, oder ein x86-Prozessor, der unter Verwendung von Complex Instruction Set Computing (CISC) implementiert ist. Die Rechenvorrichtung 1400 kann eine oder mehrere CPUs 1406 zusätzlich zu einem oder mehreren Mikroprozessoren oder zusätzlichen Coprozessoren, wie etwa mathematischen Coprozessoren, beinhalten.

Zusätzlich oder alternativ zu den CPU(s) 1406 können die GPU(s) 1408 dazu konfiguriert sein, mindestens einige der computerlesbaren Anweisungen auszuführen, um eine oder mehrere Komponenten der Rechenvorrichtung 1400 zu steuern, um eines/einen oder mehrere der Verfahren und/oder Prozesse, die hierin beschrieben sind, auszuführen. Eine oder mehrere der GPU(s) 1408 können eine integrierte GPU sein (z. B. mit einer oder mehreren der CPU(s) 1406) und/oder eine oder mehrere der GPU(s) 1408 können eine diskrete GPU sein. In Ausführungsformen können eine oder mehrere der GPU(s) 1408 ein Coprozessor einer oder mehrerer der CPU(s) 1406 sein. Die GPU(s) 1408 können durch die Computervorrichtung 1400 verwendet werden, um Grafiken (z. B. 3D-Grafiken) zu rendern oder Universalberechnungen durchzuführen. Zum Beispiel können die GPU(s) 1408 für Universalberechnungen auf GPUs (GPGPU) verwendet werden. Die GPU(s) 1408 können Hunderte oder Tausende von Kernen beinhalten, die Hunderte oder Tausende von Softwarethreads gleichzeitig handhaben können. Die GPU(s) 1408 können Pixeldaten für Ausgabebilder als Reaktion auf das Rendern von Befehlen erzeugen (z. B. Rendern von Befehlen aus der/den CPU(s) 1406, die über eine Hostschnittstelle empfangen werden). Die GPU(s) 1408 können Grafikspeicher beinhalten, wie etwa Anzeigespeicher, um Pixeldaten oder andere geeignete Daten zu speichern, wie etwa GPGPU-Daten. Der Anzeigespeicher kann als Teil des Speichers 1404 beinhaltet sein. Der/die GPU(s) 1408 können zwei oder mehrere GPUs beinhalten, die parallel arbeiten (z. B. über einen Link). Der Link kann die GPUs direkt verbinden (z. B. unter Verwendung von NVLINK) oder kann die GPUs über ein Switch verbinden (z. B. unter Verwendung von NVSwitch). Wenn sie miteinander kombiniert werden, kann jede GPU 1408 Pixeldaten oder GPGPU-Daten für verschiedene Abschnitte einer Ausgabe oder für verschiedene Ausgaben (z. B. eine erste GPU für ein erstes Bild und eine zweite GPU für ein zweites Bild) erzeugen. Jede GPU kann ihren eigenen Speicher beinhalten oder kann Speicher mit anderen GPUs teilen.

Zusätzlich oder alternativ zu den CPU(s) 1406 und/oder den GPU(s) 1408 kann/können die Logikeinheit(en) 1420 dazu konfiguriert sein, mindestens einige der computerlesbaren Anweisungen auszuführen, um eine oder mehrere Komponenten der Rechenvorrichtung 1400 zu steuern, um eines/einen oder mehrere der Verfahren und/oder Prozesse, die hierin beschrieben sind, auszuführen. In Ausführungsformen können die CPU(s) 1406, die GPU(s) 1408 und/oder die Logikeinheit(en) 1420 einzeln oder gemeinsam eine beliebige Kombination der Verfahren, Prozesse und/oder Teile davon ausführen. Eine oder mehrere der Logikeinheiten 1420 kann/können Teil von und/oder integriert in eine oder mehrere der CPU(s) 1406 und/oder der GPU(s) 1408 sein und/oder eine oder mehrere der Logikeinheiten 1420 kann/können diskrete Komponenten oder anderweitig extern zu der/den CPU(s) 1406 und/oder der/den GPU(s) 1408 sein. In Ausführungsformen können eine oder mehrere der Logikeinheiten 1420 ein Coprozessor einer oder mehrerer der CPU(s) 1406 und/oder einer oder mehrerer der GPU(s) 1408 sein.

Beispiele der Logikeinheit(en) 1420 beinhalten einen oder mehrere Verarbeitungskerne und/oder Komponenten davon, wie etwa Datenverarbeitungseinheiten (Data Processing Units - DPUs), Tensorkerne (Tensor Cores - TC), Tensor-Verarbeitungseinheiten (Tensor Processing Unit - TPU), visuelle Pixelkerne (Pixel Visual Cores - PVC), Bildverarbeitungseinheiten (Vision Processing Unit - VPU), Grafikverarbeitungscluster (Graphics Processing Cluster - GPC), Texturverarbeitungscluster (Texture Processing Cluster - TPC), Streaming-Multiprozessoren (SM), Baumdurchquerungseinheiten (Tree Traversal Unit - TTU), Beschleuniger für künstliche Intelligenz (Artificial Intelligence Accelerator - AIA), Deep-Learning-Beschleuniger (Deep Learning Accelerator - DLA), arithmetische Logikeinheiten (ALU), anwendungsspezifische integrierte Schaltungen (ASIC), Gleitkommaeinheiten (Floating Point Unit - FPU), Eingabe/Ausgabe(E/A)-Elemente, Elemente für Verschaltung von Periphärkomponenten (PCI) oder Expressverschaltung von Periphärkomponenten (peripheral component interconnect express - PCIe) und/oder dergleichen.

Die Kommunikationsschnittstelle 1410 kann einen oder mehrere Empfänger, Sender und/oder Transceiver beinhalten, die es der Rechenvorrichtung 1400 ermöglichen, mit anderen Rechenvorrichtungen über ein elektronisches Kommunikationsnetz, einschließlich drahtgebundener und/oder drahtloser Kommunikation, zu kommunizieren. Die Kommunikationsschnittstelle 1410 kann Komponenten und Funktionalität beinhalten, um eine Kommunikation über eine Anzahl unterschiedlicher Netzwerke zu ermöglichen, wie etwa drahtlose Netzwerke (z. B. Wi-Fi, Z-Wave, Bluetooth, Bluetooth LE, ZigBee usw.), drahtgebundene Netzwerke (z. B. Kommunikation über Ethernet oder InfiniBand), Weiterverkehrsnetzwerke mit geringer Leistung (z. B. LoRaWAN, SigFox usw.) und/oder das Internet. In einer oder mehreren Ausführungsformen können die Logikeinheit(en) 1420 und/oder die Kommunikationsschnittstelle 1410 eine oder mehrere Datenverarbeitungseinheiten (DPUs) beinhalten, um über ein Netzwerk und/oder durch das Verschaltungssystem 1402 empfangene Daten direkt an eine oder mehrere GPU(s) 1408 (z. B. einen Speicher davon) zu übertragen.

Die E/A-Ports 1412 können die Rechenvorrichtung 1400 dazu befähigen, logisch an andere Vorrichtungen gekoppelt zu werden, einschließlich der E/A-Komponenten 1414, der Präsentationskomponente(n) 1418 und/oder anderer Komponenten, von denen einige in die Rechenvorrichtung 1400 eingebaut (z. B. darin integriert) sein können. Veranschaulichende E/A-Komponenten 1414 beinhalten ein Mikrofon, eine Maus, eine Tastatur, einen Joystick, ein Gamepad, einen Gamecontroller, eine Satellitenschüssel, einen Scanner, einen Drucker, eine drahtlose Vorrichtung usw. Die E/A-Komponenten 1414 können eine natürliche Benutzerschnittstelle (natural user interface - NUI) bereitstellen, die Luftgesten, Spracheingabe oder andere durch einen Benutzer erzeugte physiologische Eingaben verarbeitet. In einigen Fällen können Eingaben zur weiteren Verarbeitung an ein geeignetes Netzwerkelement übertragen werden. Eine NUI kann eine beliebige Kombination aus Spracherkennung, Stifterkennung, Gesichtserkennung, biometrischer Erkennung, Gestenerkennung sowohl auf dem Bildschirm als auch neben dem Bildschirm, Luftgesten, Kopf- und Augenverfolgung und Berührungserkennung (wie unten genauer beschrieben) implementieren, die einer Anzeige der Rechenvorrichtung 1400 zugeordnet sind. Die Rechenvorrichtung 1400 kann Tiefenkameras, wie etwa stereoskopische Kamerasysteme, Infrarotkamerasysteme, RGB-Kamerasysteme, Touchscreen-Technologie und Kombinationen davon, zur Gestendetektion und -erkennung beinhalten. Zusätzlich kann die Rechenvorrichtung 1400 Beschleunigungsmesser oder Gyroskope (z. B. als Teil einer Trägheitsmesseinheit (intertia measurement unit - IMU)) beinhalten, die eine Bewegungsdetektion ermöglichen. In einigen Beispielen kann die Ausgabe der Beschleunigungsmesser oder Gyroskope durch die Rechenvorrichtung 1400 verwendet werden, um immersive augmentierte Realität oder virtuelle Realität zu rendern.

Die Stromversorgung 1416 kann auch eine fest verdrahtete Stromversorgung, eine Batteriestromversorgung oder eine Kombination davon beinhalten. Die Stromversorgung 1416 kann der Rechenvorrichtung 1400 Strom bereitstellen, um den Komponenten der Rechenvorrichtung 1400 den Betrieb zu ermöglichen.

Die Präsentationskomponent(en) 1418 können eine Anzeige (z. B. einen Monitor, einen Touchscreen, einen Fernsehbildschirm, ein Heads-up-Display (HUD), andere Anzeigearten oder eine Kombination davon), Lautsprecher und/oder andere Präsentationskomponenten beinhalten. Die Präsentationskomponent(en) 1418 können Daten von anderen Komponenten (z. B. den GPU(s) 1408, den CPU(s) 1406 usw.) empfangen und die Daten ausgeben (z. B. als Bild, Video, Ton usw.).

BEISPIELHAFTES RECHENZENTRUM

15 zeigt ein Beispiel für ein Rechenzentrum 1500, das in mindestens einer Ausführungsform der vorliegenden Offenbarung eingesetzt werden kann. Das Rechenzentrum 1500 kann eine Rechenzentrums-Infrastrukturschicht 1510, eine Framework-Schicht 1520, eine Softwareschicht 1530 und/oder eine Anwendungsschicht 1540 beinhalten.

Wie in 15 gezeigt, kann die Rechenzentrums-Infrastrukturschicht 1510 einen Ressourcen-Orchestrator 1512, gruppierte Rechenressourcen 1514 und Knoten-Rechenressourcen („Knoten-RRs“) 1516(1)-1516(N) beinhalten, wobei „N“ eine beliebige positive ganze Zahl darstellt. In mindestens einer Ausführungsform können die Knoten-RRs 1516(1)-1516(N) eine beliebige Anzahl von Zentraleinheiten (CPUs) oder andere Prozessoren (einschließlich DPUs, Beschleuniger, feldprogrammierbare Gate-Arrays (FPGAs), Grafikprozessoren oder Grafikverarbeitungseinheiten (GPUs) usw.), Speichervorrichtungen (z. B. dynamischer Nur-Lese-Speicher), Datenspeichervorrichtungen (z. B. Festkörper- oder Festplattenlaufwerke), Netzwerk-Ein-/Ausgabevorrichtungen (NW E/A), Netzwerk-Switches, virtuellen Maschinen (VMs), Leistungsmodule und/oder Kühlmodule usw. beinhalten, ohne darauf beschränkt zu sein. In mindestens einer Ausführungsform können ein oder mehrere Knoten-RRs unter den Knoten-RRs 1516(1)-1516(N) ein Server sein, der eine oder mehrere der vorstehend erwähnten Rechenressourcen aufweist. Darüber hinaus können die Knoten-RRs 1516(1)-1516(N) in einigen Ausführungsformen eine oder mehrere virtuelle Komponenten beinhalten, wie z. B. vGPUs, vCPUs und/oder dergleichen, und/oder einer oder mehrere der Knoten-RRs 1516(1)-1516(N) können einer virtuellen Maschine (VM) entsprechen.

In mindestens einer Ausführungsform können die gruppierten Rechenressourcen 1514 separate Gruppierungen von Knoten-RRs 1516 beinhalten, die innerhalb eines oder mehrerer Racks (nicht gezeigt) oder vieler Racks untergebracht sind, die in Rechenzentren an verschiedenen geografischen Standorten untergebracht sind (ebenfalls nicht gezeigt). Separate Gruppierungen von Knoten-RRs 1516 innerhalb der gruppierten Rechenressourcen 1514 können gruppierte Rechen-, Netzwerk-, Arbeitsspeicher- oder Datenspeicherressourcen beinhalten, die zur Unterstützung einer oder mehrerer Arbeitslasten konfiguriert oder zugewiesen sein können. In mindestens einer Ausführungsform können mehrere Knoten-RRs 1516, die CPUs, GPUs, DPUs und/oder Prozessoren beinhalten, in einem oder mehreren Racks gruppiert sein, um Rechenressourcen bereitzustellen, um eine oder mehrere Rechenlasten zu unterstützen. Das eine oder mehrere Racks können auch eine beliebige Anzahl von Leistungsmodulen, Kühlmodulen und/oder Netz-Switches in beliebiger Kombination beinhalten.

In mindestens einer Ausführungsform kann der Ressourcen-Orchestrator 1512 einen oder mehrere Knoten-RRs 1516(1)-1516(N) und/oder gruppierte Rechenressourcen 1514 konfigurieren oder anderweitig steuern. In mindestens einer Ausführungsform kann der Ressourcen-Orchestrator 1512 eine Verwaltungsentität für Softwaregestaltungsinfrastruktur (software design infrastructure - SDI) für das Rechenzentrum 1500 beinhalten. Der Ressourcen-Orchestrator 1512 kann aus Hardware, Software oder einer Kombination davon bestehen.

In mindestens einer Ausführungsform, wie in 15 gezeigt, kann die Framework-Schicht 1520 einen Aufgabenplaner 1532, einen Konfigurationsmanager 1534, einen Ressourcenmanager 1536 und/oder ein verteiltes Dateisystem 1538 beinhalten. Die Framework-Schicht 1520 kann ein Framework zum Unterstützen von Software 1532 der Softwareschicht 1530 und/oder einer oder mehreren Anwendung(en) 1542 der Anwendungsschicht 1540 beinhalten. Die Software 1532 oder die Anwendung(en) 1542 können jeweils webbasierte Dienstsoftware oder - anwendungen beinhalten, wie etwa diejenigen, die von Amazon Web Services, Google Cloud und Microsoft Azure bereitgestellt sind. Die Framework-Schicht 1520 kann eine Art von freiem und Open-Source-Software-Webanwendungs-Framework sein, ohne darauf beschränkt zu sein, wie etwa Apache Spark™ (im Folgenden „Spark“), welches das verteilte Dateisystem 1538 für umfangreiche Datenverarbeitungen (z. B. „Big Data“) nutzen kann. In mindestens einer Ausführungsform kann der Aufgabenplaner 1532 einen Spark-Treiber beinhalten, um die Planung von Arbeitslasten zu erleichtern, die durch verschiedene Schichten des Rechenzentrums 1500 unterstützt werden. Der Konfigurationsmanager 1534 kann in der Lage sein, unterschiedliche Schichten zu konfigurieren, wie etwa die Softwareschicht 1530 und die Framework-Schicht 1520, was Spark und das verteilte Dateisystem 1538 zum Unterstützen einer umfangreicher Datenverarbeitung beinhaltet. Der Ressourcenmanager 1536 kann in der Lage sein, geclusterte oder gruppierte Computerressourcen zu verwalten, die zur Unterstützung des verteilten Dateisystems 1538 und des Aufgabenplaners 1532 zugeordnet oder zugewiesen sind. In mindestens einer Ausführungsform können geclusterte oder gruppierte Rechenressourcen die gruppierte Rechenressource 1514 auf der Rechenzentrums-Infrastrukturschicht 1510 beinhalten. Der Ressourcenmanager 1536 und der Ressourcen-Orchestrator 1512 können sich aufeinander abstimmen, um diese zugeordneten oder zugewiesenen Rechenressourcen zu verwalten.

In mindestens einer Ausführungsform kann die in der Softwareschicht 1530 enthaltene Software 1532 Software beinhalten, die mindestens durch Abschnitte der Knoten-RRs 1516(1)-1516(N), der gruppierten Rechenressourcen 1514 und/oder des verteilten Dateisystems 1538 der Framework-Schicht 1520 verwendet wird. Zu einem oder mehreren Typen von Software können Software zum Durchsuchen von Internet-Webseiten, Software zum Scannen von E-Mails auf Viren, Datenbank-Software und Software für Streaming-Videoinhalte gehören, ohne darauf beschränkt zu sein.

In mindestens einer Ausführungsform können die in der Anwendungsschicht 1540 enthaltenen Anwendung(en) 1542 eine oder mehrere Arten von Anwendungen beinhalten, die zumindest von Abschnitten der Knoten-RRs 1516(1)-1516(N), den gruppierten Rechenressourcen 1514 und/oder dem verteilten Dateisystem 1538 der Framework-Schicht 1520 verwendet werden. Eine oder mehrere Arten von Anwendungen können eine beliebige Anzahl einer Genomikanwendung, einer kognitiven Rechenanwendung und einer maschinellen Lernanwendung umfassen, die Trainings- oder Ableitungssoftware beinhaltet, Framework-Software des maschinellen Lernens (z. B. PyTorch, TensorFlow, Caffe usw.) und/oder andere maschinelle Lernanwendungen beinhalten, ohne darauf beschränkt zu sein, die in Verbindung mit einer oder mehreren Ausführungsformen verwendet werden.

In mindestens einer Ausführungsform kann ein beliebiger des Konfigurationsmanagers 1534, des Ressourcenmanagers 1536 und des Ressourcen-Orchestrators 1512 auf Grundlage einer beliebigen Menge und Art von Daten, die auf eine beliebige technisch machbare Weise erfasst wurden, eine beliebige Anzahl und Art von selbstmodifizierenden Aktionen implementieren. Selbstmodifizierende Handlungen können einen Rechenzentrumsbetreiber des Rechenzentrums 1500 dahingehend entlasten, möglicherweise schlechte Konfigurationsentscheidungen zu treffen und möglicherweise nicht ausgelastete und/oder schlecht funktionierende Abschnitte eines Rechenzentrums zu vermeiden.

Das Rechenzentrum 1500 kann Werkzeuge, Dienste, Software oder andere Ressourcen beinhalten, um ein oder mehrere Modelle des maschinellen Lernens zu trainieren oder Informationen unter Verwendung eines oder mehrerer Modelle des maschinellen Lernens gemäß einer oder mehreren in dieser Schrift beschriebenen Ausführungsformen vorherzusagen oder abzuleiten. Zum Beispiel kann/können ein Modell(e) für maschinelles Lernen trainiert werden, indem Gewichtungsparameter gemäß einer Architektur eines neuronalen Netzes unter Verwendung von Software und/oder Rechenressourcen berechnet werden, die vorstehend in Bezug auf das Rechenzentrum 1500 beschrieben sind. In mindestens einer Ausführungsform können trainierte oder eingesetzte Modelle für maschinelles Lernen, die einem oder mehreren neuronalen Netzen entsprechen, verwendet werden, um Informationen unter Verwendung der vorstehend in Bezug auf das Rechenzentrum 1500 beschriebenen Ressourcen zu inferenzieren oder vorherzusagen, indem Gewichtungsparameter verwendet werden, die durch eine oder mehrere hierin beschriebene Trainingstechniken berechnet werden, sind aber nicht darauf beschränkt.

In mindestens einer Ausführungsform kann das Rechenzentrum 1500 CPUs, anwendungsspezifische integrierte Schaltungen (ASICs), GPUs, FPGAs und/oder andere Hardware (oder entsprechende virtuelle Rechenressourcen) verwenden, um das Training und/oder die Inferenzierung mit den oben beschriebenen Ressourcen durchzuführen. Darüber hinaus können eine oder mehrere der vorstehend beschriebenen Software- und/oder Hardware-Ressourcen als Dienst konfiguriert sein, um Benutzern das Trainieren oder Durchführen des Inferenzierens von Informationen zu ermöglichen, wie etwa Bilderkennung, Spracherkennung oder andere Dienste der künstlichen Intelligenz.

BEISPIELHAFTE NETZWERKUMGEBUNGEN

Netzwerkumgebungen, die für die Verwendung beim Implementieren von Ausführungsformen der Offenbarung geeignet sind, können ein oder mehrere Client-Vorrichtungen, Server, netzwerkverbundenen Speicher (network attached storage - NAS), andere Backend-Vorrichtungen und/oder andere Vorrichtungstypen beinhalten. Die Client-Vorrichtungen, Server und/oder andere Vorrichtungstypen (z. B. jede Vorrichtung) können auf einer oder mehreren Instanzen der Rechenvorrichtung(en) 1400 aus 14 implementiert sein - z. B. kann jede Vorrichtung ähnliche Komponenten, Merkmale und/oder Funktionalität der Rechenvorrichtung(en) 1400 beinhalten. Zusätzlich, wenn Backend-Vorrichtungen (z. B. Server, NAS usw.) implementiert werden, können die Backend-Vorrichtungen auch Teil eines Rechenzentrums 1500 sein, dessen Beispiel in 15 näher beschrieben wird.

Komponenten einer Netzwerkumgebung können miteinander über ein oder mehrere Netzwerke kommunizieren, die drahtgebunden, drahtlos oder beides sein können. Das Netzwerk kann mehrere Netzwerke oder ein Netzwerk von Netzwerken beinhalten. Beispielsweise kann das Netzwerk ein oder mehrere Weitverkehrsnetzwerke (WAN), ein oder mehrere lokale Netzwerke (LANs), ein oder mehrere öffentliche Netzwerke wie das Internet und/oder ein öffentliches Telefonvermittlungsnetz (publich switched telephone network - PSTN) und/oder ein oder mehrere private Netzwerke beinhalten. Wenn das Netzwerk ein drahtloses Telekommunikationsnetz beinhaltet, können Komponenten wie eine Basisstation, ein Kommunikationsturm oder sogar Zugangspunkte (sowie andere Komponenten) eine drahtlose Konnektivität bereitstellen.

Kompatible Netzwerkumgebungen können eine oder mehrere Peer-to-Peer-Netzwerkumgebungen beinhalten - in diesem Fall kann ein Server nicht in einer Netzwerkumgebung beinhaltet sein - und eine oder mehrere Client-Server-Netzwerkumgebungen - in diesem Fall können ein oder mehrere Server in einer Netzwerkumgebung beinhaltet sein. In Peer-to-Peer-Netzwerkumgebungen kann die hierin in Bezug auf einen oder mehrere Server beschriebene Funktionalität auf einer beliebigen Anzahl von Client-Vorrichtungen implementiert sein.

In mindestens einer Ausführungsform kann eine Netzwerkumgebung eine oder mehrere Cloud-basierte Netzwerkumgebungen, eine verteilte Rechenumgebung, eine Kombination davon usw. beinhalten. Eine Cloud-basierte Netzwerkumgebung kann eine Framework-Schicht, einen Job-Scheduler, einen Ressourcenmanager und ein verteiltes Dateisystem beinhalten, die auf einem oder mehreren Servern implementiert sind, die einen oder mehrere Kernnetzwerkserver und/oder Edge-Server beinhalten können. Eine Framework-Schicht kann ein Framework zur Unterstützung von Software einer Software-Schicht und/oder einer oder mehrerer Anwendungen einer Anwendungsschicht beinhalten. Die Software oder Anwendung(en) können jeweils Web-basierte Dienstsoftware oder Anwendungen beinhalten. In Ausführungsformen können eine oder mehrere der Client-Vorrichtungen die Web-basierte Dienstsoftware oder Anwendungen verwenden (z. B. durch Zugreifen auf die Dienstsoftware und/oder Anwendungen über eine oder mehrere Anwendungsprogrammierschnittstellen (API)). Bei der Framework-Schicht kann es sich um eine Art freies und quelloffenes Software-Webanwendungs-Framework handeln, das etwa ein verteiltes Dateisystem für die Verarbeitung großer Datenmengen (z. B. „Big Data“) verwenden kann, ist aber nicht darauf beschränkt.

Eine Cloud-basierte Netzwerkumgebung kann Cloud-Computing und/oder Cloud-Speicher bereitstellen, die eine beliebige Kombination von hierin beschriebenen Rechen- und/oder Datenspeicherfunktionen (oder einen oder mehrere Teile davon) ausführen. Jede dieser verschiedenen Funktionen kann über mehrere Standorte von zentralen oder Kernservern (z. B. von einem oder mehreren Rechenzentren, die über einen Staat, eine Region, ein Land, den Globus usw. verteilt sein können) verteilt sein. Wenn eine Verbindung zu einem Benutzer (z. B. einer Client-Vorrichtung) relativ nahe bei einem oder mehreren Edge-Servern ist, können ein oder mehrere Core-Server dem oder den Edge-Servern mindestens einen Teil der Funktionalität zuweisen. Eine Cloud-basierte Netzwerkumgebung kann privat sein (z. B. auf eine einzelne Organisation beschränkt), kann öffentlich sein (z. B. für viele Organisationen verfügbar) und/oder eine Kombination davon sein (z. B. eine Hybrid-Cloud-Umgebung).

Die Client-Vorrichtungen können mindestens einige der Komponenten, Merkmale und Funktionalitäten der hier beschriebenen Beispielcomputer 1400 in Bezug auf 14 beinhalten. Beispielhaft und nicht einschränkend kann eine Client-Vorrichtung als Personal Computer (PC), Laptop-Computer, mobiles Gerät, Smartphone, Tablet-Computer, Smartwatch, tragbarer Computer, persönlicher digitaler Assistent (PDA), MP3-Player, Virtual-Reality-Headset, Global Positioning System (GPS) oder -Gerät, Videoplayer, Videokamera, Überwachungsgerät oder - system, Fahrzeug, Boot, Fischereifahrzeug, virtuelle Maschine, Drohne, Roboter, tragbares Kommunikationsgerät, Krankenhausgerät, Spielgerät oder -system, Unterhaltungssystem, Fahrzeugcomputersystem, eingebettetes Systemsteuerung, Fernbedienung, Anwendung, Unterhaltungselektronikgerät, Workstation, Edge-Gerät, beliebige Kombination dieser abgegrenzten Geräte oder beliebiges anderes geeignetes Gerät verkörpert sein.

Die Offenbarung kann im allgemeinen Kontext von Computercode- oder maschinenverwendbaren Anweisungen, einschließlich computerausführbarer Anweisungen wie Programmmodulen, die von einem Computer oder einem anderen Computer, wie einem Personal Data Assistent oder einem anderen Handheld-Gerät, ausgeführt werden, beschrieben werden. Im Allgemeinen beziehen sich Programmmodule einschließlich Routinen, Programme, Objekte, Komponenten, Datenstrukturen usw. auf Code, der bestimmte Aufgaben ausführt oder bestimmte abstrakte Datentypen implementiert. Die Offenbarung kann in einer Vielzahl von Systemkonfigurationen praktiziert werden, einschließlich Handheld-Vorrichtungen, Unterhaltungselektronik, Allzweckcomputern, spezielleren Rechenvorrichtungen usw. Die Offenbarung kann auch in verteilten Rechenumgebungen praktiziert werden, in denen Aufgaben von entfernten Verarbeitungsvorrichtungen, die über ein Kommunikationsnetz verbunden sind, durchgeführt werden.

Wie hier verwendet, sollte eine Nennung von „und/oder“ in Bezug auf zwei oder mehr Elemente so interpretiert werden, dass nur ein Element oder eine Kombination von Elementen gemeint ist. Zum Beispiel kann „Element A, Element B und/oder Element C“ nur Element A, nur Element B, nur Element C, Element A und Element B, Element A und Element C, Element B und Element C oder Elemente enthalten A, B und C. Außerdem kann „mindestens eines von Element A oder Element B“ mindestens eines von Element A, mindestens eines von Element B oder mindestens eines von Element A und mindestens eines von Element umfassen B. Ferner kann „mindestens eines von Element A und Element B“ mindestens eines von Element A, mindestens eines von Element B oder mindestens eines von Element A und mindestens eines von Element B beinhalten.

Der Gegenstand der vorliegenden Offenbarung wird hierin spezifisch beschrieben, um gesetzliche Anforderungen zu erfüllen. Die Beschreibung selbst soll jedoch den Umfang dieser Offenbarung nicht einschränken. Vielmehr haben die Erfinder in Erwägung gezogen, dass der beanspruchte Gegenstand auch auf andere Weise verkörpert werden könnte, um andere Schritte oder Kombinationen von Schritten ähnlich den in diesem Dokument beschriebenen in Verbindung mit anderen gegenwärtigen oder zukünftigen Technologien einzuschließen. Obwohl die Begriffe „Schritt“ und/oder „Block“ hierin verwendet werden können, um verschiedene Elemente der verwendeten Verfahren zu bezeichnen, sollten die Begriffe darüber hinaus nicht so ausgelegt werden, dass sie eine bestimmte Reihenfolge zwischen oder zwischen verschiedenen hierin offenbarten Schritten implizieren, es sei denn, die Reihenfolge ist der einzelnen Schritte ist explizit beschrieben.

ZITATE ENTHALTEN IN DER BESCHREIBUNG

Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.

Zitierte Patentliteratur

US 15141703 [0019]

Claims

System, das Folgendes umfasst: einen Speicher; ein System mit Direktspeicherzugriff (DMA), das an den Speicher gekoppelt ist; und einen an den Speicher gekoppelten Prozessor, wobei das System Operationen ausführt, die Folgendes umfassen: Berechnen einer ersten Ausgabe, die einer oder mehreren ersten aktualisierten Stellen eines nachverfolgten Merkmals entspricht, unter Verwendung des Prozessors und zumindest teilweise basierend auf ersten Daten, die unter Verwendung des DMA-Systems in den Speicher geschrieben wurden; Aktualisieren des Speichers unter Verwendung des Prozessors, um zweite Daten zu beinhalten, die für ein oder mehrere Adressen/Daten-Paare repräsentativ sind, die der einen oder den mehreren ersten aktualisierten Stellen entsprechen; Aktualisieren eines oder mehrerer Deskriptoren, die dem nachverfolgten Merkmal entsprechen, unter Verwendung des DMA-Systems und zumindest teilweise basierend auf dem einen oder den mehreren Adressen/Daten-Paaren; Schreiben von dritten Daten in den Speicher unter Verwendung des DMA-Systems und zumindest teilweise basierend auf dem einen oder den mehreren Deskriptoren; und Berechnen einer zweiten Ausgabe, die einer oder mehreren zweiten aktualisierten Stellen des nachverfolgten Merkmals entspricht, unter Verwendung des Prozessors und zumindest teilweise basierend auf den dritten Daten.
System nach Anspruch 1, ferner umfassend eine Verarbeitungssteuerung, wobei das System ferner Operationen ausführt, die Konfigurieren des DMA-Systems und des Prozessors unter Verwendung der Verarbeitungssteuerung umfassen.
System nach Anspruch 1 oder 2, ferner umfassend eine Verarbeitungssteuerung, wobei das System ferner Operationen ausführt, die Auslösen des DMA-Systems und des Prozessors unter Verwendung der Verarbeitungssteuerung umfassen.
System nach einem der vorstehenden Ansprüche, ferner umfassend einen Deskriptorspeicher, wobei der eine oder die mehreren Deskriptoren in dem Deskriptorspeicher aktualisiert werden.
System nach einem der vorstehenden Ansprüche, wobei die Operationen in einer Schleife bei jeder Iteration einer Vielzahl von Iterationen durchgeführt werden.
System nach einem der vorstehenden Ansprüche, wobei die zweiten Daten einem Datenformat entsprechen, das ein oder mehrere Bytes, die eine Adresse des einen oder der mehreren Adressen/Daten-Paare darstellen, und ein oder mehrere Bytes, die Daten des einen oder der mehreren Adressen/Daten-Paare darstellen, beinhaltet.
System nach einem der vorstehenden Ansprüche, wobei das System in mindestens einem von Folgendem umfasst ist: einem Steuersystem für eine autonome oder halbautonome Maschine; einem Wahrnehmungssystem für eine autonome oder halbautonome Maschine; einem System zum Durchführen von Simulationsoperationen; einem System zum Durchführen von Deep-Learning-Operationen; einem System auf einem Chip (SoC); einem System mit einem programmierbaren Visionsbeschleuniger (PVA); einem System mit einer Visionsverarbeitungseinheit; einem System, das unter Verwendung eines Edge-Geräts implementiert ist; einem System, das unter Verwendung eines Roboters implementiert ist; einem System, das eine oder mehrere virtuelle Maschinen (VMs) enthält; einem System, das zumindest teilweise in einem Rechenzentrum implementiert ist; oder einem System, das zumindest teilweise unter Verwendung von Cloud-Computing-Ressourcen implementiert ist.
System, das Folgendes umfasst: einen Vektorspeicher (VMEM); ein System mit Direktspeicherzugriff (DMA), das an den VMEM gekoppelt ist; und eine an den VMEM gekoppelte Vektorverarbeitungseinheit (VPU), wobei das System Operationen ausführt, die Folgendes umfassen: Berechnen einer ersten Ausgabe, die einer oder mehreren ersten aktualisierten Stellen eines nachverfolgten Merkmals entspricht, unter Verwendung der VPU und zumindest teilweise basierend auf ersten Daten, die unter Verwendung des DMA-Systems in den VMEM geschrieben wurden; Aktualisieren des VMEM unter Verwendung der VPU, um zweite Daten zu beinhalten, die für ein oder mehrere Adressen/Daten-Paare repräsentativ sind, die der einen oder den mehreren ersten aktualisierten Stellen entsprechen; Aktualisieren eines oder mehrerer Deskriptoren, die dem nachverfolgten Merkmal entsprechen, unter Verwendung des DMA-Systems und zumindest teilweise basierend auf dem einen oder den mehreren Adressen/Daten-Paaren; Schreiben von dritten Daten in den VMEM unter Verwendung des DMA-Systems und zumindest teilweise basierend auf dem einen oder den mehreren Deskriptoren; und Berechnen einer zweiten Ausgabe, die einer oder mehreren zweiten aktualisierten Stellen des nachverfolgten Merkmals entspricht, unter Verwendung der VPU und zumindest teilweise basierend auf den dritten Daten.
System nach Anspruch 8, ferner umfassend eine Verarbeitungssteuerung, wobei das System ferner Operationen ausführt, die Konfigurieren des DMA-Systems und der VPU unter Verwendung der Verarbeitungssteuerung umfassen.
System nach Anspruch 8 oder 9, ferner umfassend eine Verarbeitungssteuerung, wobei das System ferner Operationen ausführt, die Auslösen des DMA-Systems und der VPU unter Verwendung der Verarbeitungssteuerung umfassen.
System nach einem der Ansprüche 8 bis 10, ferner umfassend einen Deskriptorspeicher, wobei der eine oder die mehreren Deskriptoren in dem Deskriptorspeicher aktualisiert werden.
System nach einem der Ansprüche 8 bis 11, wobei die Operationen in einer Schleife bei jeder Iteration einer Vielzahl von Iterationen durchgeführt werden.
System nach einem der Ansprüche 8 bis 12, wobei die zweiten Daten einem Datenformat entsprechen, das ein oder mehrere Bytes, die eine Adresse des einen oder der mehreren Adressen/Daten-Paare darstellen, und ein oder mehrere Bytes, die Daten des einen oder der mehreren Adressen/Daten-Paare darstellen, beinhaltet.
System nach einem der Ansprüche 8 bis 13, wobei das System in mindestens einem von Folgendem umfasst ist: einem Steuersystem für eine autonome oder halbautonome Maschine; einem Wahrnehmungssystem für eine autonome oder halbautonome Maschine; einem System zum Durchführen von Simulationsoperationen; einem System zum Durchführen von Deep-Learning-Operationen; einem System auf einem Chip (SoC); einem System mit einem programmierbaren Visionsbeschleuniger (PVA); einem System mit einer Visionsverarbeitungseinheit; einem System, das unter Verwendung eines Edge-Geräts implementiert ist; einem System, das unter Verwendung eines Roboters implementiert ist; einem System, das eine oder mehrere virtuelle Maschinen (VMs) enthält; einem System, das zumindest teilweise in einem Rechenzentrum implementiert ist; oder einem System, das zumindest teilweise unter Verwendung von Cloud-Computing-Ressourcen implementiert ist.
Verfahren, das Folgendes umfasst: Berechnen einer ersten Ausgabe, die einer oder mehreren ersten aktualisierten Stellen eines nachverfolgten Merkmals entspricht, unter Verwendung einer Vektorverarbeitungseinheit (VPU) und zumindest teilweise basierend auf ersten Daten, die unter Verwendung eines Systems mit Direktspeicherzugriff (DMA) in einen Vektorspeicher (VMEM) geschrieben wurden; Aktualisieren des VMEM unter Verwendung der VPU, um zweite Daten zu beinhalten, die für ein oder mehrere Adressen/Daten-Paare repräsentativ sind, die der einen oder den mehreren ersten aktualisierten Stellen entsprechen; Aktualisieren eines oder mehrerer Deskriptoren, die dem nachverfolgten Merkmal entsprechen, unter Verwendung des DMA-Systems und zumindest teilweise basierend auf dem einen oder den mehreren Adressen/Daten-Paaren; Schreiben von dritten Daten in den VMEM unter Verwendung des DMA-Systems und zumindest teilweise basierend auf dem einen oder den mehreren Deskriptoren; und Berechnen einer zweiten Ausgabe, die einer oder mehreren zweiten aktualisierten Stellen des nachverfolgten Merkmals entspricht, unter Verwendung der VPU und zumindest teilweise basierend auf den dritten Daten.
Verfahren nach Anspruch 15, ferner umfassend Konfigurieren des DMA-Systems und der VPU unter Verwendung einer Verarbeitungssteuerung.
Verfahren nach Anspruch 15 oder 16, ferner umfassend Auslösen des DMA-Systems und der VPU unter Verwendung einer Verarbeitungssteuerung.
Verfahren nach einem der Ansprüche 15 bis 17, ferner umfassend Aktualisieren des einen oder der mehreren Deskriptoren in einem Deskriptorspeicher.
Verfahren nach einem der Ansprüche 15 bis 18, wobei das Verfahren in einer Schleife bei jeder Iteration einer Vielzahl von Iterationen durchgeführt wird.
Verfahren nach einem der Ansprüche 15 bis 19, wobei die zweiten Daten einem Datenformat entsprechen, das ein oder mehrere Bytes, die eine Adresse des einen oder der mehreren Adressen/Daten-Paare darstellen, und ein oder mehrere Bytes, die Daten des einen oder der mehreren Adressen/Daten-Paare darstellen, beinhaltet.