-
HINTERGRUND
-
Industriepraktiken zum Prüfen von Systemen auf Chip (systems-on-chip; SOCs) erfordern aufwändiges Prüfgerät (ATE), dessen Kosten direkt proportional zu der Anzahl von Kanälen, der Geschwindigkeit und dem Betriebsspeicher sind, der pro Prüfung des Eingabe-Ausgabe(EA)-Kanals verfügbar ist. Da Chipgrößen wachsen, steigen Speicheranforderungen pro E/A-Kanal.
-
In vielen Fällen sind weder zusätzliche Prüf-E/A-Kanäle verfügbar noch verbessert sich die Geschwindigkeit von Prüfkanälen. Mit zunehmend vorherrschenden 2.5D- und 3D-Chips, haben sich die zum Prüfen verfügbaren E/A-Kanäle weiter verringert. Scan-Kompressionsschemata von verschiedenen Tool-Lieferanten für elektronische Entwurfsautomatisierung (electronic design automation; EDA) zielen darauf ab, geringere Prüfdatenanforderungen zu erreichen, wobei diese jedoch auf Kosten schwacher Prüfabdeckung oder lieferantenspezifischer Designanpassung gehen.
-
Das Korrelieren der ATE mit Prüfausfällen auf Systemebene ist eine weitere Herausforderung. Das Ausführen von Strukturprüfungen auf Systemebene ist aufwändig, was diesen Prozess häufig unpraktisch macht. Es gab einige Bemühungen, eine Strukturprüfung auf Systemebene zu ermöglichen, wobei diese jedoch Spezialzweckprüfschnittstellen benutzen und nicht breit anwendbar sind. Existierende Lösungen neigen dazu, sich eine hohe Latenz einzuhandeln, was es aufwändig macht, sie mit mehreren Fehlermodellen oder Prüfprogrammen zu verwenden.
-
Anwendungen des Automobil- und Hochleistungsrechnens (high-performance computing; HPC) erfordern Prüfungen, die in der Praxis auszuführen sind, um dabei zu helfen, Sicherheit und Zuverlässigkeit zu gewährleisten. Strukturprüfungen stellen eine hohe Prüfabdeckung verglichen mit Funktionsmustern bereit und sind am geeignetsten, den Anforderungen dieser Anwendungen zu entsprechen. Existierenden Schemata für Strukturprüfung in der Praxis sind durch lange Ausführungszeiten und/oder Datenspeicheranforderungen beschränkt.
-
KURZE ZUSAMMENFASSUNG
-
Ausführungsformen eines Systems werden offenbart, welche die Herausforderungen von früheren Vorgehensweisen mindern. Prüfen mit hohem Durchsatz ist auf existierenden E/A-Kanalschaltungen ermöglicht, welche die E/A-Kanäle in ihrem Funktionsmodus benutzen. Frühere Vorgehensweisen beruhen auf Spezialzweckprüfschaltungen in den E/A-Kanälen, deren Kosten mit den Durchsatzanforderungen der Prüfung ansteigen.
-
Die Rolle des ATE wird vereinfacht, um Leistung und thermischen Steuerung bereitzustellen. Frühere Vorgehensweisen benutzen das ATE, um die Prüfdaten bereitzustellen sowie auch die Prüfergebnisse zu bewerten. Die offenbarten Ausführungsformen ermöglichen kleinere und weniger aufwändige ATEs.
-
Die offenbarten Ausführungsformen sind auf Plattformen anwendbar, die ATE, Systemebenenprüfung (system-level test; SLT), Platinen und Prüfungen in der Praxis umfassen. Diese Portabilität ermöglicht Diagnose- und Debug-Korrelation zwischen Plattformen. Frühere Vorgehensweisen weisen spezifische Design-Merkmale für jede Plattform auf, die eine Korrelation zu einer Herausforderung machen.
-
Die offenbarten Ausführungsformen können benutzt werden, um Automobil-ISO-Spezifikationskonformität auf Fehlertoleranzzeitintervall (FTTI) zu prüfen und die Zuverlässigkeit von HPC-Produkten zu verbessen.
-
Figurenliste
-
Um die Erläuterung über ein bestimmtes Element oder eine bestimmte Aktion leicht zu kennzeichnen, bezieht sich die höchstwertigste Ziffer oder die höchstwertigsten Ziffern eines Bezugszeichens auf die Figur, in der dieses Element erstmalig eingeführt wird.
- 1 veranschaulicht eine Systemarchitektur 100 gemäß einer Ausführungsform.
- 2 veranschaulicht eine ATE-Architektur 200 gemäß einer Ausführungsform.
- 3 veranschaulicht DUT-Logikkomponenten 300 gemäß einer Ausführungsform.
- 4 veranschaulicht ein Prüfsystem 400 gemäß einer Ausführungsform.
- 5 veranschaulicht einen Hardwarecontroller 304 gemäß einer Ausführungsform.
- 6 ist ein Blockdiagramm eines Rechensystems 600, innerhalb desselben die hier eingeführten Techniken verkörpert oder ausgeführt werden können.
-
AUSFÜHRLICHE BESCHREIBUNG
-
„FTTI“ bezieht sich auf Fehlertoleranzzeitintervall (FTTI; Fault Tolerant Time Interval). Der ISO 26262 Standard definiert FTTI als eine Zeitspanne, in der ein Fehler (1.42) oder Fehler in einem System (1.129) vorhanden sein kann/können, bevor ein gefährliches (1.57) Ereignis auftritt.
-
„IEEE 1500“ bezieht sich auf eine skalierbare Standardarchitektur zum Ermöglichen einer Wiederverwendung und einer Integration von Prüfungen für eingebettete Kerne und zugehörige Schaltungen. Sie verzichtet auf die Adressierung von Analogschaltungen und konzentriert sich auf die Erleichterung einer effizienten Prüfung digitaler Aspekte von Systemen auf Chip (SoCs). IEEE Std 1500 weist serielle und parallele Prüfzugriffsmechanismen (test access mechanisms; TAMs) und einen reichhaltigen Satz von Anweisungen auf, die zur Prüfung von Kernen, SoC-Verbindungen und Schaltungen geeignet sind. Außerdem definiert IEEE Std 1500 Merkmale, die eine Kernisolierung und einen Kernschutz ermöglichen.
-
„ISO 26262“ bezieht sich auf einen internationalen Standard zur Funktionssicherheit von elektrischen und/oder elektronischen Systemen in Serienautomobilen, die durch die Internationalen Organisation für Normung (International Organization for Standardization; ISO) festgelegt wird.
-
„MBIST“ bezieht sich auf Memory Built-In Self-Test (eingebaute Speicherselbstprüfung), eine Logik, die einen Satz von March-Algorithmen erzeugt, die angewendet werden können, um Speicherstörungen zu erfassen.
-
„PCIe“ bezieht sich auf Peripheriekomponenten-Interconnect Express, einen seriellen Hochgeschwindigkeit-Computererweiterungsbus-Standard, der ausgestaltet ist, um die älteren PCI-, PCI-X- und AGP-Busstandards zu ersetzen. PCIe weist zahlreiche Verbesserungen gegenüber den älteren Standards auf, einschließlich höheren maximalen Systembusdurchsatz, niedrigere E/A-Pinzahl und kleineren physischen Fußabdruck, bessere Leistungsskalierung für Busvorrichtungen, einen ausführlicheren Fehlererfassungs- und Berichtsmechanismus (Advanced Error Reporting; AER) und native Hot-Plug-Funktionalität. Neuere PCIe-Standardvorrichtungen stellen Hardwareunterstützung für E/A-Virtualisierung bereit.
-
Ausführungsformen eines Systems werden offenbart, die Hochgeschwindigkeit-E/A (z.B., PCIe, USB 2.0 und darüber, IEEE IEEE 1394/1394b, Serial ATA, NVLink™ usw.) basiertes Prüfen von Systems-on-a-chip (SOCs) auf Wafer- und System-Ebenen ermöglichen. Die Anforderung für aufwändige Prüfausrüstung wird durch Verringern des E/A-Kanals und des Speichers pro E/A-Kanalanforderungen von herkömmlichen Vorgehensweisen gemindert. Die ATE-Architektur und der ATE-Design können somit vereinfacht werden, um kleinere Formfaktoren zu ermöglichen und Kapitalkosten der Anschaffung und Unterhaltung zu verringern. Prüfeinfügungskomplexitäten können ebenfalls durch direktes Prüfen der SOCs auf System-Ebenen-Plattformen verringert werden.
-
Das System basiert auf existierenden Hochgeschwindigkeits-Eingabe/Ausgabe (High Speed Serial Input/Output; HSIO) Standards, z.B. PCIe, die es über Plattformen hinweg portierbar machen, die eine ATE- Leiterplatten-Prüfung auf System-Ebene (system-level test; SLT) und Prüfungen in der Praxis umfassen. Der hohe Durchsatz ermöglicht Prüfungen in der Praxis innerhalb eines Fehlertoleranzzeitintervalls (FTTI) für ISO 26262 Einhaltung.
-
1 veranschaulicht eine Systemarchitektur 100 gemäß einer Ausführungsform. Die Systemarchitektur 100 umfasst einen Endpunkt 102, einen Endpunkt 104, einen Endpunkt 106, einen Schalter 108, einen Wurzelkomplex 110, einen DDR SRAM 112, einen Prozessor 114, einen Prozessor 116 und ein Vorderseitenbus 118. Der Wurzelkomplex 110 vermittelt Kommunikation durch periphere Vorrichtungen („Endpunkte“) auf dem Vorderseitenbus 118. Ein wohlbekanntes Beispiel eines Wurzelkomplexes 110 ist eine „Southbridge“.
-
Die Systemarchitektur 100 ist auf unterschiedliche Plattformen skalierbar. Eine zu prüfende Vorrichtung (device-under-test; DUT) wird beispielsweise als ein PCIe-Endpunkt 106 oder zum zweistelligen Prüfen als der Endpunkt 102 und Endpunkt 104, die über den Schalter 108 in diesem Beispiel gekoppelt sind, hinzugefügt. Prüfdaten und Prüfergebnisse werden von dem Systemspeicher (z.B., DDR SRAM 112) gespeichert, der für die CPU zugänglich ist (z.B., Prozessor 114 und Prozessor 116 über Vorderseitenbus 118 zu dem Wurzelkomplex 110). Die CPU führt den Gesamtprüfprozess, lädt Systemspeicher mit Prüfdaten und löst jede DUT zum „Selbstest“ aus. 3 veranschaulicht einen Controller, der innerhalb der DUT implementiert sein kann.
-
Die Systemarchitektur 100 meistert den Vorderseitenbus 118 und führt DMA für Prüfdaten durch, führt Prüfungen aus, speichert Antworten im Systemspeicher und löst die CPU aus, wenn Prüfen erfolgt. Die CPU vergleicht Prüfantworten mit erwarteten Ergebnissen, um einen Bestehen/Versagen-Status zu bestätigen.
-
Mehrere Vorrichtungen können seriell oder nebenläufig durch die Systemarchitektur 100 geprüft werden. Das Austauschen von Vorrichtungen manifestiert sich als ein Hot-Plug-Ereignis und die Vorrichtungen werden einer Aufzählung unterzogen, um der CPU auf dem Bus sichtbar zu werden, wobei der obige Prozess danach ausgeführt werden kann.
-
2 veranschaulicht eine ATE-Architektur 200 gemäß einer Ausführungsform. Die ATE-Architektur 200 umfasst eine automatisierte Prüfausrüstung 202, eine automatisierte Prüfausrüstung 204, eine CPU 206, eine CPU 208, eine CPU 210, eine CPU 212, eine DUT 214, eine DUT 216, eine DUT 218, eine DUT 220, einen DRAM 222, einen DRAM 224, einen DRAM 226 und einen DRAM 228.
-
2 veranschaulicht beispielhafte ATE-Anwendungsfälle für die Systemarchitektur 100. Die automatisierten Prüfausrüstung 204 weist mehrere physikalische oder virtualisierte CPUs mit dediziertem Systemspeicher (z.B., DRAMs) auf, die zusammen die DUTs antreiben. In diesem Schema wird die Rolle der automatisierten Prüfausrüstung 202 vereinfacht, um Leistungs- und Temperatursteuerung bereitzustellen. Prüfung und Ergebnisvergleich werden durch die CPU <-> DUT-Controller (siehe 3) in Verbindung mit auf der CPU ausgeführten Logik ausgeführt.
-
3 veranschaulicht DUT-Logikkomponenten 300 gemäß einer Ausführungsform. Die DUT-Logikkomponenten 300 umfassen einen Buscontroller 302, einen Hardwarecontroller 304, eine IEEE 1500 Komponente 306, eine Abtastkette 308 und eine MBIST-Komponente 310.
-
Der Hardwarecontroller 304 der DUT 312 kommuniziert mit dem Buscontroller 302, um die Prüfdaten abzurufen und die Prüfausführung zu steuern. Der Hardwarecontroller 304 kommuniziert ebenfalls mit der JTAG/IEEE 1500 Komponente 306, um die DUT 312 in verschiedene Prüfkonfigurationen einzustellen und um die Prüfungen auszulösen. Für Prüfungen der Abtastkette 308 stellt der Hardwarecontroller 304 einen direkten Zugriff mit hohem Durchsatz auf die On-Chip-Kompressoren/Dekompressoren bereit, um die Abtastdaten zu laden und die Daten von den Kompressoren zurück zu sammeln.
-
4 veranschaulicht ein Prüfsystem 400 gemäß einer Ausführungsform. Das Prüfsystem 400 umfasst eine CPU 402, ein HDD 404, einen Wurzelkomplex 110, einen DDR SRAM 112 und eine DUT 312. Die DUT 312 umfasst einen Buscontroller 302, einen Hardwarecontroller 304, eine Einheit 1 406 und eine Einheit 2 408. Die Einheit 1 406 umfasst eine JTAG/IEEE 1500 Komponente 410, eine Abtastkettenkomponente 412 und eine Komponente der MBIST-Komponente 414. Die Einheit 2 408 würde typischerweise ähnliche Komponenten umfassen.
-
Abhängig von dem Stillstand der Einheit 1 406 in der DUT 312 kommuniziert die DUT 312 mit der CPU, um die Einheit 1 406 mit anderen Einheiten (z.B., der Einheit 2 408) zu prüfen, um funktional zu bleiben. Der Funktionszustand der Einheit 1 406 kann in einem On-Chip-Speicher oder in dem Systemspeicher (z.B., DDR SRAM 112) gespeichert sein. Die CPU lädt Prüfdaten in den Systemspeicher von dem Festplattenlaufwerk (z.B., HDD 404). Die CPU bereitet die DUT 312 zur Prüfung durch Ausführen der Logik zum Einrichten vor und löst den Hardwarecontroller (z.B., Hardwarecontroller 304) aus, um die spezifische Einheit der DUT 312 zu prüfen. Nach der Prüfausführung stellt die CPU den Funktionszustand der Einheit wieder her, die geprüft wurde, und gibt dies der DUT 312 an, um den Betrieb wiederaufzunehmen.
-
Eine einzige CPU 402 kann somit verwendet werden, um DUTs eines komplexen elektronischen Systems oder einer Leiterplatte zu prüfen. Jede DUT 312 umfasst einen Buscontroller 302, der sich schnittstellenmäßig mit einem externen Busanschluss (bus port) 314 verbindet, und einen internalisierten Hardwarecontroller 304, der mit dem Buscontroller 302 gekoppelt ist. Der Hardwarecontroller 304 steuert und koordiniert eine Abtastkette 308 und eine MBIST-Komponente 310, die in jeder Funktionseinheit in der DUT internalisiert sind. „Internalisiert“ bedeutet, dass die Abtastkette 308 und die MBIST 310 an den Pins auf dem Umfang der enthaltenen Funktionseinheit angeschlossen sind und der Hardwarecontroller 304 ebenfalls intern zu der enthaltenen DUT ist (der Hardwarecontroller 304 wechselwirkt mit externen Vorrichtungen der DUT über den externen Busanschluss 314). Eine DUT 312 kann in einigen Fällen lediglich eine einzige Funktionseinheit umfassen, wobei in diesem Fall die Funktionseinheit und die DUT 312 ein und dieselbe sein können. Typischerweise umfasst jede DUT mehrere Funktionseinheiten, die jeweils eine lokale (internalisiert zu der DUT) Abtastkette, eine lokale IEEE 1500 Komponente und (optional) eine MBIST-Komponente umfassen (wenn die Funktionseinheit eine Speicheranordnung aufweist oder zu der Prüfung einer externen Speicheranordnung beiträgt). Der Betrieb jeder dieser lokalen Vorrichtungen wird durch einen Hardwarecontroller 304 koordiniert, der zu allen Funktionseinheiten in der DUT zentral ist.
-
Der Hardwarecontroller 304 umfasst eine Logik, um den Betrieb der internalisierten Komponenten der Funktionseinheiten unabhängig gemäß einer Prüflogik zu koordinieren, die über den Buscontroller empfangen wird. Die Systemarchitektur 100 ist ausgestaltet, um hinsichtlich dessen flexibel zu sein, wo die Speicheranordnung oder ein Abschnitt davon, die/der durch eine bestimmte MBIST 310 zu prüfen ist, in dem Design implementiert ist. Beispielsweise kann die durch eine bestimmte MBIST 310 geprüfte Speicheranordnung intern zu der Funktionseinheit sein, welche die MBIST 310 umfasst, oder die Speicheranordnung kann intern zu der DUT sein, welche die MBIST 310 umfasst, jedoch von den Funktionseinheiten der DUT gemeinsam genutzt wird, oder der Wurzelkomplex 110 kann eine oder mehrere der DUTs mit einer gemeinsam genutzten Speicheranordnung koppeln. Somit kann die MBIST von einer bestimmten Funktionseinheit oder DUT einen Speicherbus zu einer lokalen Speicheranordnung oder nicht lokalen Speicheranordnung abhängig von der Implementierung benutzen. Eine bestimmte MBIST ist jedoch zu einer bestimmten Funktionseinheit hinsichtlich ihrer Prüfeingaben und Steuerungen und der Rückgabe von Prüfergebnissen internalisiert. Diese Architekturmerkmale können eine große Verringerung in einer Anzahl von E/A-Prüfkanalpins auf komplexen elektronischen Vorrichtungen ermöglichen, einschließlich des Ermöglichens des Prüfens von großen, gemeinsam genutzten Speicheranordnungen auf eine verteilte Art und Weise über viele Funktionseinheiten und DUTs.
-
Der Hardwarecontroller 304 umfasst in einer Ausführungsform einen In-System-Prüfsequenzer 502, einen LBIST-Mastercontroller 504, einen JTAG-Controller 506, einen LBIST-Abtastkettencontroller 508 und einen PCIe-Controller 510. Der PCIe-Controller 510 wird betrieben, um Prüfdaten von dem Systemspeicher abzurufen und Prüfergebnisse in den Systemspeicher zu schreiben. Der LBIST-Mastercontroller 504 kommuniziert mit dem In-System-Prüfsequenzer 502 und dem LBIST-Abtastkettencontroller 508, der die Abtastketten 412 antreibt. Der In-System-Prüfsequenzer 502 kommuniziert Lese/Schreib-Daten, Adresse und Länge von Daten an den LBIST-Mastercontroller 504 und stellt DMA-Lese/Schreib-Anfragen für Daten. Leseabschlussdaten werden empfangen und durch den In-System-Prüfsequenzer 502 decodiert und entweder an den LBIST-Mastercontroller 504 oder den JTAG-Controller 506 gesendet. Der LBIST-Abtastkettencontroller 508 treibt die Dekompression/Kompression-Strukturen der Abtastketten 412, um die Abtastdaten in die Abtastketten zu transferieren und die Daten von dem Prüfergebnis-Schieberegistern zurück zu sammeln. Der JTAG-Controller 506 zapft das Netzwerk der IEEE 1500 Komponente 410 an, um die IEEEE 1500 Register zu programmieren. Dies ist lediglich ein Beispiel, wie der Hardwarecontroller 304 implementiert werden kann.
-
6 ist ein Blockdiagramm einer Ausführungsform eines Rechensystems 600, bei dem ein oder mehrere Aspekte der Offenbarung implementiert werden können. Das Rechensystem 600 umfasst einen Systemdatenbus 632, eine CPU 602, Eingabevorrichtungen 608, einen Systemspeicher 604, ein Graphikverarbeitungssystem 606 und Anzeigevorrichtungen 610. In alternativen Ausführungsformen können die CPU 602, Abschnitte des Graphikverarbeitungssystems 606, der Systemdatenbus 632 oder eine beliebige Kombination davon in einer einzigen Verarbeitungseinheit integriert sein. Darüber hinaus kann die Funktionalität des Graphikverarbeitungssystems 606 in einem Chipsatz oder in einer anderen Art von Spezialzweckverarbeitungseinheit oder Co-Prozessor umfasst sein.
-
Wie gezeigt, verbindet der Systemdatenbus 632 die CPU 602, die Eingabevorrichtungen 608, den Systemspeicher 604 und das Graphikverarbeitungssystem 606. In alternativen Ausführungsformen kann der Systemspeicher 604 direkt mit der CPU 602 verbunden sein. Die CPU 602 empfängt eine Benutzereingabe von den Eingabevorrichtungen 608, führt im Systemspeicher 604 gespeicherte Programmanweisungen aus, arbeitet an Daten, die im Systemspeicher 604 gespeichert sind, um Rechenaufgaben durchzuführen. Der Systemspeicher 604 umfasst typischerweise einen Direktzugriffspeicher (dynamic random access memory; DRAM), der benutzt wird, um Programmanweisungen und Daten zu speichern. Das Graphikverarbeitungssystem 606 empfängt durch die CPU 602 übertragene Anweisungen und verarbeitet die Anweisungen beispielsweise, um Aspekte der offenbarten Ausführungsformen zu implementieren, und/oder Graphiken (z.B., Bilder, Kacheln, Video) zu rendern und auf den Anzeigevorrichtungen 610 anzuzeigen.
-
Wie ebenfalls gezeigt, umfasst der Systemspeicher 604 ein Anwendungsprogramm 612, eine Anwendungsprogrammierschnittstelle 614 (application programming interface; API) und einen Graphikverarbeitungseinheitstreiber 616 (GPU-Treiber). Das Anwendungsprogramm 612 erzeugt Aufrufe an die API 614, um einen gewünschten Satz von Rechenergebnissen zu erzeugen. Beispielsweise kann das Anwendungsprogramm 612 Programme oder Funktionen davon an die API 614 zur Verarbeitung innerhalb des Graphikverarbeitungseinheitstreibers 616 übertragen.
-
Das Graphikverarbeitungssystem 606 umfasst eine GPU 618 (Graphikverarbeitungseinheit), einen On-Chip-GPU-Speicher 622, einen On-Chip-GPU-Datenbus 636, einen lokalen GPU-Speicher 620 und einen GPU-Datenbus 634. Die GPU 618 ist konfiguriert, um mit dem On-Chip-GPU-Speicher 622 über den On-Chip-GPU-Datenbus 636 und mit dem lokalen GPU-Speicher 620 über den GPU-Datenbus 634 zu kommunizieren. Die GPU 618 kann von der CPU 602 übertragene Anweisungen empfangen, die Anweisungen verarbeiten und Ergebnisse im lokalen GPU-Speicher 620 speichern. Anschließend kann die GPU 618 bestimmte Graphiken, die im lokalen GPU-Speicher 620 gespeichert sind, auf den Anzeigevorrichtungen 610 anzeigen. Die hier offenbarten Prüfarchitekturen können innerhalb des Graphikverarbeitungssystems 606 benutzt werden, um die GPU 618, die lokalen GPU-Speicher 620 und die On-Chip-GPU-Speicher 622 zu prüfen, wobei diese Komponenten in gemeinsamen oder unterschiedlichen funktionalen Prüfpartitionen sein können. Die CPU 602 kann für die Prüfmuster benutzt werden und um den Hardwarecontroller 304 jeder funktionalen Partition zu koordinieren und die Prüfergebnisse im Systemspeicher 604 zur Analyse zu speichern.
-
Die GPU 618 umfasst einen oder mehrere Logikblöcke 624. Die Logikblöcke 624 können Ausführungsformen der hier offenbarten Systeme und Techniken, wie beispielsweise Prüflogik von dem Hardwarecontroller 304, implementieren.
-
Die GPU 618 kann mit einer beliebigen Menge von On-Chip-GPU-Speichern 622 und lokalen GPU-Speichern 620, einschließlich keinem, ausgestattet sein, und kann On-Chip-GPU-Speicher 622, lokale GPU-Speicher 620 und Systemspeicher 604 in beliebiger Kombination für Speicheroperationen einsetzen.
-
Der On-Chip-GPU-Speicher 622 ist konfiguriert, um die GPU-Programmierung 628 und den On-Chip-Puffer 630 zu umfassen. Die GPU-Programmierung 628 kann von dem Graphikverarbeitungseinheitstreiber 616 an den On-Chip-GPU-Speicher 622 über den Systemdatenbus 632 übertragen werden. Die GPU-Programmierung 628 kann die Logikblöcke 624 umfassen.
-
Der lokale GPU-Speicher 620 umfasst typischerweise einen kostengünstigeren dynamischen Direktzugriffsspeicher (dynamic random access memory; DRAM) außerhalb des Chips und wird ebenfalls eingesetzt, um von der GPU 618 eingesetzte Daten und Programme zu speichern. Wie gezeigt, umfasst der lokale GPU-Speicher 620 einen Frame-Puffer 626. Der Frame-Puffer 626 kann beispielsweise Daten speichern, zum Beispiel ein Bild, eine Graphikoberfläche, die eingesetzt werden können, um die Anzeigevorrichtungen 610 anzutreiben. Der Frame-Puffer 626 kann mehr als eine Oberfläche umfassen, so dass die GPU 618 eine Oberfläche rendern kann, während eine zweite Oberfläche eingesetzt wird, um die Anzeigevorrichtungen 610 anzutreiben.
-
Die Anzeigevorrichtungen 610 sind eine oder mehrere Ausgabevorrichtungen, die imstande sind, ein visuelles Bild auszugeben, das einem Eingangsdatensignal entspricht. Beispielsweise kann eine Anzeigevorrichtung mit einer Flüssigkristallanzeige oder einem anderen geeigneten Anzeigesystem aufgebaut sein. Die Eingangsdatensignale an die Anzeigevorrichtungen 610 werden typischerweise durch Herausscannen des Inhalts eines oder mehrerer Frames von Bilddaten erzeugt, die im Frame-Puffer 626 gespeichert sind.
