DE112010006087T5

DE112010006087T5 - Architektur zum Testen, zur Validierung und zur Fehlerbereinigung

Info

Publication number: DE112010006087T5
Application number: DE112010006087.8T
Authority: DE
Inventors: Kreshavan Tiruvallur; Christian Lovin; David Grawrock; Evan J. Halprin; Jiun Long Foo; Wee Hoo Cheah; Vui Yong; Yen Tat Lee; Kip Killpack; Niel Dobler; Nagib Z. Hakim; Michael T. White; Brian Meyer; Russ Wunderlich; Anthony Kozaczuk; Kyle Markley; Loren McConnell; Lyle Cool; Rahima Mohammed; Tieyu Zheng
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2010-12-23
Filing date: 2010-12-23
Publication date: 2014-06-26
Also published as: WO2012087330A2; GB2493793B; JP2013529321A; CN103748562B; US20150127983A1; JP5548966B2; US10198333B2; KR20130128424A; KR101581702B1; GB2493793A; CN103748562A; GB201122290D0; WO2012087330A3

Abstract

Eine Vorrichtung und ein Verfahren zum Bereitstellen einer Architektur zum Testen, zur Validierung und zur Fehlerbereinigung werden hierin beschrieben. Auf einer Ziel- oder Basisebene werden Hardwarehaken (Design-For-Test oder DFx) in Siliziumbauteilen angeordnet und in diese integriert. Ein Controller kann einen abstrahierten Zugriff auf solche Haken beispielsweise über eine Abstraktionsschicht, welche Details der Hardware-DFx auf niedriger Ebene abstrahiert, bereitstellen. Zusätzlich stellt die Abstraktionsschicht durch eine Schnittstelle, wie beispielsweise APIs, Dienste, Routinen und Datenstrukturen für Software-/Präsentationsschichten auf höheren Ebenen bereit, welche dazu in der Lage sind, Testdaten für eine Validierung und eine Fehlerbereinigung einer Einheit/Plattform im Test zu sammeln. Ferner stellt die Architektur der Testarchitektur potentiell einen abgestuften sicheren (mehrere Ebenen von sicherem) Zugriff bereit. Zusätzlich kann ein physikalischer Zugriff auf die Testarchitektur für eine Plattform durch das Verwenden eines vereinheitlichten, bi-direktionalen Testzugriffanschlusses vereinfacht werden, wobei auch potentiell ein Fernzugriff erlaubt wird, um ein Testen und eine Fehlerbereinigung eines Bauteils/einer Plattform im Test aus der Ferne zu ermöglichen. Im Wesentlichen wird hierin ein vollständiger Testarchitekturstapel zum Testen, zur Validierung und zur Fehlerbereinigung elektronischer Bauteile, Einrichtungen und Plattformen beschrieben.

Description

GEBIET
Diese Erfindung betrifft das Gebiet von Computersystemen und insbesondere das Bereitstellen einer Test- und Fehlerbereinigungs-Infrastruktur für Computersysteme.
HINTERGRUND
Fortschritte in der Halbleiter-Verarbeitung und im Logik-Design haben eine Zunahme in der Menge an Logik, die auf integrierten Schaltkreisvorrichtungen vorhanden sein kann, ermöglicht. Als logische Folge haben sich Computersystemkonfigurationen von einer einzelnen oder mehreren integrierten Schaltungen in einem System zu mehreren Kernen, mehreren Hardware-Threads und mehreren logischen Prozessoren, die auf einem einzelnen integrierten Schaltkreis vorliegen, sowie zu anderen Schnittstellen, die innerhalb solcher Prozessoren integriert sind, entwickelt. Ein Prozessor oder eine integrierte Schaltung umfasst typischerweise einen einzigen physikalischen Prozessorchip, wobei der Prozessorchip eine beliebige Anzahl von Kernen, Hardware-Threads, logischen Prozessoren, Schnittstellen, Speicher, Controller-Hubs, etc. aufweisen kann. Und da sowohl Prozessoren als auch Computer-Systeme an Komplexität zunehmen, nimmt auch die Art von Test und Fehlerbereinigung dieser Systeme an Komplexität zu.
Die hohen Geschwindigkeiten, die massive Menge an Logik und die kleine Ausführung von Prozessoren führen zu einer Unfähigkeit, Produkte zeitgerecht oder auf kostengünstige Weise von Fehlern zu bereinigen, zu validieren und auf den Markt zu bringen. Derzeit hat sich die Welt von Test und Fehlerbereinigung zwischen Herstellern und Kunden/Anbietern zweigeteilt entwickelt, wobei die Hersteller dazu neigen, sich auf die Silizium-Einrichtungen, die sie anbieten, zu konzentrieren, und sich die Anbieter auf andere Teile, die mit den Silizium-Einrichtungen integriert werden, konzentrieren. Um ihr Silizium sowohl vor bösartigen als auch zufälligen Beschädigungen zu schützen, legen die Hersteller ihre Hardware-Fehlerbereinigung-Haken Anbietern oft auf keiner Ebene offen, denn es gibt keine sichere Methode, einen solchen Zugriff bereitzustellen. Und da die Komplexität des Testens weiter fortgeschrittener Computer-Systeme immer aufwendiger wird, verwenden Hersteller eine enorme Menge an Geld und Aufwand, um bei der Validierung zu unterstützen, auch wenn die entdeckten Probleme nicht direkt mit ihren Einrichtungen zusammenhängen. Darüber hinaus kann jede andere Einrichtung (Prozessor, Controller-Hub, Grafikkarte, Mainboard, etc.) in einem System einen eigenen Zugriff für ein Testen und für eine Fehlerbereinigung aufweisen. Dieser disjunkte Ansatz beim Testen/bei der Fehlerbereinigung führt nur zu mehr Verwirrung und Verzögerung beim Validieren von Produkten. Darüber hinaus wurden traditionelle Sondierungstestmethoden aufgrund der physikalischen Größenbegrenzungen neuer integrierter Schaltungen untragbar.
Darüber hinaus kosten die Werkzeuge, um eine Validierung zu versuchen, wie z. B. externe Logikanalysatoren und Oszilloskope, unabhängig davon, ob für einen Hersteller oder einen Anbieter, eine beträchtliche Menge an Geld, ebenso wie eine erhebliche Menge an Zeit geschulter Mitarbeiter, um diese zu verbinden und korrekt zur Validierung zu verwenden. Darüber hinaus sind diese externen Validierungs-Werkzeuge nur dazu in der Lage, Protokollaustauschvorgänge über Verbindungen zu erfassen, und haben Schwierigkeiten, die Zustände und Wechselwirkungen von Einrichtungen vollständig zu ermitteln.
Als spezifische Beispiele stellen aktuelle Computersysteme keine Möglichkeiten bereit, um verschiedene Systemereignisse unter bestimmten Bedingungen ohne erheblichen Aufwand und Zeit zu validieren, wie z. B. geräteinterne Signale, Spuren oder Zustände nachzuverfolgen; Signale früh in einem Boot-Vorgang nachzuverfolgen; bestimmte Ereignisse, wie Aufhängereignisse, die als In-Band-Nachrichten integriert wurden, zu bestimmen und neuen hochschnellen, internen, speicherbezogenen und Input/Output(I/O)-bezogenen Datenverkehr und/oder Protokolle zu erschließen. Im Wesentlichen gibt es derzeit keine vereinheitlichte und effektive Art, über mehrere Vektoren (Prozessor-Test/Validierung, Plattformfehlerbereinigung, elektrisches Margining, Motherboard-Diagnose, etc.) zu validieren.
KURZBESCHREIBUNG DER ZEICHNUNGEN
Die vorliegende Erfindung ist beispielhaft durch die Abbildungen der beigefügten Zeichnungen illustriert und nicht dazu gedacht, durch diese beschränkt zu werden.
1 zeigt eine Ausführungsform einer logischen Darstellung eines mehrfachverarbeitenden Elementprozessors.
2 zeigt eine weitere Ausführungsform einer logischen Darstellung eines mehrfachverarbeitenden Elementprozessors.
3 zeigt eine Ausführungsform einer logischen Darstellung einer geschichteten Testarchitektur.
4 zeigt eine Ausführungsform eines Computersystems mit mehreren Prozessoren mit beispielhaften Ausführungsformen von DFx-Merkmalen.
5 zeigt eine Ausführungsform eines Blockschaltbildes für eine bidirektionale Verbindungsarchitektur, welche einen geschichteten Verbindung-Stapel verwendet.
6 zeigt eine Ausführungsform eines Blockschaltbildes zum Erfassen von Signalinformationen beim frühen Einschalten.
7 zeigt eine Ausführungsform eines High-Level-Blockdiagramms einer Erfassungslogik zum Erfassen früher Signale während des Bootens eines elektronischen Systems.
8 zeigt eine Ausführungsform eines Flussdiagramms für ein Verfahren zum frühen Erfassen von Signalinformationen in einer Leistungssequenz.
9 zeigt ein Ausführungsbeispiel einer veranschaulichenden Logik zum Erfassen von Signalen von Interesse in Niedrigleistungszuständen.
10 zeigt eine Ausführungsform einer veranschaulichenden Plattform mit einem oder mehreren VCUs.
11 zeigt eine Ausführungsform eines Flussdiagramms für ein Verfahren zum Bedienen einer DFx-Anforderung von Software unter Verwendung einer VCU.
12 zeigt eine Ausführungsform eines Aktualisierens einer Testarchitektur zum Berücksichtigen einer Änderung darin.
13 zeigt eine Ausführungsform eines geschichteten Stapels für eine Testarchitektur.
14 zeigt eine Ausführungsform eines Flussdiagramms für ein Verfahren zum Zugreifen auf DFx-Merkmale durch einen geschichteten Architekturstapel.
15 zeigt eine Ausführungsform einer Logik zum Bereitstellen eines sicheren Zugriffs auf eine Testarchitektur.
16 zeigt eine Ausführungsform eines Flussdiagramms zum Bereitstellen eines sicheren Zugriffs in einer Testarchitektur.
17 zeigt eine Ausführungsform eines universellen Testzugriffsanschlusses (Universal Test Access Port – UTAP) für eine Testarchitektur in einer Plattform.
18 zeigt eine Ausführungsform einer Einheit mit integrierter Schaltung in einem beispielhaften Verbindungsmechanismus zur Großserienfertigung.
19 zeigt eine Ausführungsform eines Wärmeverteilers mit einem diskreten Lastmerkmal, um Oberseiten-Testpins und ein Sondieren zu unterstützen.
20 zeigt eine Ausführungsform einer Explosionsdarstellung eines Designs eines thermischen Werkzeugs mit kleinem Formfaktor (SFFTT) zum Bereistellen eines thermischen Marginings.
21 zeigt eine Ausführungsform eines Fernzugriffs auf eine Einheit im Test.
22 zeigt eine Ausführungsform einer anderen Ausführungsform des Fernzugriffs auf eine Einheit im Test.
23 zeigt eine Ausführungsform einer Logik, um eine intern beobachtete Spurinformation über einen Seitenband-Bus bereitzustellen.
24 zeigt eine Ausführungsform eines Flussdiagramms für ein Verfahren zum Verwalten von Daten einer internen Beobachtungsspur (internal observation trace – IOT).
25 zeigt eine Ausführungsform eines Flussdiagramms zum Rekonstruieren von Spuren aus IOT-Daten.
26 zeigt eine Ausführungsform eines Flussdiagramms für ein Verfahren zum Durchführen einer Divergenzdetektion nach einer Verarbeitung.
27 zeigt eine Ausführungsform eines Flussdiagramms zum Ermöglichen eines Zugriffs auf RTL-Datenstrukturen durch eine höhere Programmiersprache.
28 zeigt eine Ausführungsform einer Infrastruktur zum Ermöglichen einer räumlichen und zeitlichen Charakterisierung sowie einer Fehlerbereinigung eines Stromnetzes relativ zu On-Die-Ereignissen, einschließlich der Fähigkeit, Test- und Systemereignisse mit einer Stromnetz-Leistung zu korrelieren.
DETAILLIERTE BESCHREIBUNG
In der folgenden Beschreibung werden zahlreiche spezifische Details dargelegt, wie Beispiele für spezifische Typen von spezifischen Prozessor-Konfigurationen, Controller, Validierungs-/Test-/Fehlerbereinigungs-Haken, Orten von Komponenten, Sicherheitsprotokollen, Abstraktionsverfahren, einer Informationsformatierung und -anordnung, von physikalischen Zugriffsanschlusskonfigurationen und -orten, Leistungskonfigurationen, etc., um ein gründliches Verständnis der vorliegenden Erfindung bereitzustellen. Es wird jedoch für einen Fachmann erkennbar sein, dass diese spezifischen Details nicht eingesetzt werden müssen, um die vorliegende Erfindung auszuführen. In anderen Fällen sind wohlbekannte Komponenten oder Verfahren, wie z. B. eine spezifische und alternative Prozessorarchitektur, spezifische Logikschaltungen/spezifischer Code für beschriebene Funktionen und Algorithmen, spezifische Implementierungsdetails der Validierungssteuerung, andere bekannte Entwurfsvalidierungshaken, bekannte Sicherheits- und Zugriffsverfahren und andere spezifische operative Einzelheiten nicht im Detail beschrieben worden, um eine unnötige Verschleierung der vorliegenden Erfindung zu vermeiden.
Das Verfahren und die Vorrichtung, welche hierin beschrieben sind, dienen dem Bereitstellen einer Test-Infrastruktur für Computersysteme. Insbesondere ist ein Schwerpunkt der Diskussion auf eine Validierung innerhalb traditioneller Computersysteme, welche Prozessoren, wie beispielsweise einen Prozessor 100, aufweisen, gerichtet. Dennoch sind die hierin beschriebenen Vorrichtungen und Verfahren nicht darauf beschränkt, da sie in Verbindung mit einer alternativen Computerarchitektur, sowie jeder anderen elektronischen Einrichtung, die getestet, von Fehlern bereinigt, validiert, etc. werden soll, implementiert werden können. Beispielsweise kann die hierin beschriebene Test-Infrastruktur in einer Kommunikationseinrichtung oder einer anderen integrierten Schaltungsumgebung implementiert werden. Oder die Test-Infrastruktur kann in eingebetteten Einrichtungen mit kleinem Formfaktor, wie z. B. PDAs und Handys genutzt werden.
Ausführungsformen von Prozessor-Architekturen
Unter Bezugnahme auf 1 ist eine Ausführungsform eines Prozessors mit mehreren Kernen dargestellt. Der Prozessor 100 umfasst jeden beliebigen Prozessor, wie z. B. einen Mikroprozessor, einen eingebetteten Prozessor, einen Digitalsignalprozessor (DSP), einen Netzwerk-Prozessor oder eine andere Einrichtung, um Code auszuführen. Der Prozessor 100 weist in einer Ausführungsform mindestens zwei Kerne – Kerne 101 und 102 – auf, die asymmetrische oder symmetrische Kerne (dargestellte Ausführungsform) aufweisen können. Allerdings kann der Prozessor 100 jede beliebige Anzahl von Verarbeitungselementen aufweisen, die symmetrisch oder asymmetrisch sein können.
In einer Ausführungsform bezieht sich ein Verarbeitungselement auf eine Thread-Einheit, einen Thread-Slot, eine Prozesseinheit, einen Kontext, einen logischen Prozessor, einen Hardware-Thread, einen Kern und/oder jedes beliebige andere Element, das in dazu der Lage ist, einen Zustand für einen Prozessor, wie z. B. einen Ausführungszustand oder einen architektonischen Zustand, zu halten. Mit anderen Worten bezieht sich ein Verarbeitungselement in einer Ausführungsform auf eine beliebige Hardware, die dazu in der Lage ist, unabhängig einem Code, wie beispielsweise einem Software-Thread, einem Betriebssystem, einer Applikation oder einem anderen Code zugeordnet zu sein. Ein physischer Prozessor bezieht sich typischerweise auf eine integrierten Schaltung, die potentiell eine beliebige Anzahl von anderen Verarbeitungselementen, wie z. B. Kerne oder Hardware-Threads, aufweist.
Ein Kern bezieht sich oft auf eine Logik, die sich auf einem integrierten Schaltkreis befindet und dazu in der Lage ist, einen unabhängigen Architekturzustand aufrechtzuerhalten, wobei jeder unabhängig aufrechterhaltene Architekturzustand mit mindestens einigen dedizierten Ausführungsressourcen verknüpft ist. Im Gegensatz zu Kernen bezieht sich ein Hardware-Thread typischerweise auf jede beliebige Logik, die sich auf einem integrierten Schaltkreis befindet, und welche dazu in der Lage ist, einen unabhängigen Architekturzustand aufrechtzuerhalten, wobei sich die unabhängig aufrechterhaltenen architektonischen Zustände einen Zugriff auf Ausführungsressourcen teilen. Wie man sieht, überschneidet sich die Linie zwischen der Systematik eines Hardware-Threads und eines Kerns, wenn bestimmte Ressourcen gemeinsam genutzt werden und andere einem architektonischen Zustand dediziert sind. Doch oft werden ein Kern und ein Hardware-Thread von einem Betriebssystem als einzelne logische Prozessoren angesehen, wobei das Betriebssystem dazu in der Lage ist, individuell Operationen auf jedem logischen Prozessor zu planen.
Der physikalische Prozessor 100, wie er in dargestellt ist, umfasst zwei Kerne, Kern 101 und 102. Hier werden die Kerne 101 und 102 als symmetrische Kerne, d. h. Kerne mit den gleichen Konfigurationen, funktionalen Einheiten und/oder Logik betrachtet. In einer anderen Ausführungsform umfasst der Kern 101 einen Out-of-Order-Prozessorkern, während der Kern 102 einen In-Order-Prozessorkern umfasst. Jedoch können die Kerne 101 und 102 einzeln aus jeder beliebigen Art von Kern, wie einem nativen Kern, einem durch Software verwalteten Kern, einem Kern, der zum Ausführen einer nativen Instruction Set Architecture (ISA) angepasst ist, einem Kern, der zum Ausführen einer translatierten Instruction Set Architecture (ISA) angepasst ist, einem co-gestalteten Kern oder einem anderen bekannten Kern ausgewählt sein. Um die Diskussion jedoch weiter voranzubringen, sind die in Kern 101 veranschaulichten Funktionseinheiten in weiteren Einzelheiten unten beschrieben, da die Einheiten in dem Kern 102 auf eine ähnliche Weise arbeiten.
Wie dargestellt ist, umfasst der Kern 101 zwei Hardware-Threads 101a und 101b, die auch als Hardware-Thread-Slots 101a und 101b bezeichnet werden können. Daher betrachten Software-Entitäten, wie beispielsweise ein Betriebssystem, in einer Ausführungsform den Prozessor 100 potentiell als vier separate Prozessoren, d. h. als vier logische Prozessoren oder Verarbeitungselemente, welche dazu in der Lage sind, vier Software-Threads gleichzeitig auszuführen. Wie oben dargestellt, ist ein erster Thread mit Architekturzustandsregistern 101a verknüpft, ein zweiter Thread ist mit Architekturzustandsregistern 101b verknüpft, kann ein dritter Thread mit Architekturzustandsregistern 102a verknüpft sein und kann ein vierter Thread mit Architekturzustandsregistern 102b verknüpft sein. Wie dargestellt sind die Architekturzustandsregister 101a in den Architekturzustandsregistern 101b repliziert, so dass einzelne Architekturzustände/-kontexte für den logischen Prozessor 101a und den logischen Prozessor 101b gespeichert werden können. In dem Kern 101 können andere kleinere Ressourcen wie ein Befehlszeiger und eine Umbenennungslogik in einer Umbenennungsallokierlogik 130 auch für die Threads 101a und 101b repliziert sein. Einige Ressourcen, wie z. B. Re-Order-Puffer in einer Reorganisations-/Retirement-Einheit 135, ILTB 120, Lade-/Speicher-Puffer, und Warteschlangen können durch Partitionierung geteilt werden. Andere Ressourcen wie interne Allzweckregister, seitentabellenbasierte Register, Low-Level-Daten-Cache und Daten-TLB 115, Ausführungseinheit(en) 140 und Teile einer Out-of-Order-Einheit 135 werden potenziell vollständig geteilt.
Der Prozessor 100 weist oft andere Ressourcen auf, die vollständig geteilt, durch Partitionierung geteilt oder von/für Verarbeitungselemente(n) dediziert sein können. In 1 ist eine Ausführungsform eines rein beispielhaften Prozessors mit veranschaulichenden logischen Einheiten/Ressourcen eines Prozessors dargestellt. Man beachte, dass ein Prozessor jede beliebige dieser Funktionseinheiten aufweisen oder nicht aufweisen, sowie jede beliebige andere bekannte nicht dargestellte Funktionseinheit, Logik oder Firmware aufweisen kann, die nicht gezeigt ist. Wie dargestellt ist, umfasst der Kern 101 einen vereinfachten, repräsentativen Out-of-Order-(OOO)-Prozessorkern. Der OOO-Kern weist einen Sprungzielpuffer 120, um Sprungziele vorherzusagen, die ausgeführt/genommen werden sollen, und einen Anweisungsübersetzungspuffer (I-TLB) 120 zum Speichern von Adressübersetzungseinträgen für Befehle auf.
Der Kern 101 umfasst ferner ein Dekodiermodul 125, welches an eine Abrufeinheit (fetch unit) 120 zum Dekodieren abgerufener Elemente gekoppelt ist. Die Abruflogik umfasst in einer Ausführungsform einzelne Sequenzer, die mit Thead-Slots 101a bzw. 101b verknüpft sind. Üblicherweise ist der Kern 101 mit einer ersten Instruktion Set Architecture (ISA) verknüpft, die auf dem Prozessor 100 ausführbare Anweisungen definiert/angibt. Hierbei umfassen Maschinencodebefehle, die Teil der ersten ISA sind, oft einen Teil der Instruktion (als Opcode bezeichnet), der eine durchzuführende Anweisung oder Operation referenziert/angibt. Die Dekodierlogik 125 enthält Schaltungen, die diese Anweisungen an ihren Opcodes erkennt und die dekodierten Instruktionen auf der Pipeline zum wie durch die erste ISA definierten Verarbeiten weiterleitet. Zum Beispiel weisen die Dekoder 125, wie unten näher erläutert ist, in einer Ausführungsform eine Logik auf, welche konstruiert oder eingerichtet ist, um spezifische neue Instruktionen, wie z. B. eine bedingte Commit-Instruktion und/oder eine spekulative Prüfpunktinstruktion zu erkennen. Als Ergebnis der Erkennung durch die Dekoder 125 nimmt die Architektur oder der Kern 101 spezifische vordefinierte Aktionen vor, um mit der entsprechenden Instruktion verknüpfte Aufgaben durchzuführen.
In einem Beispiel umfasst ein Allozierer- und Umbenenner-Block 130 einen Allozierer zum Reservieren von Ressourcen, wie beispielsweise Registerdateien zum Speichern von Ergebnissen eines Abarbeitens einer Instruktion. Allerdings sind die Threads 101a und 101b potentiell zu einer Out-of-Order-Ausführung in der Lage, wobei der Allozierer- und Umbenenner-Block 130 auch andere Ressourcen, wie einen Reorder-Puffer zum Nachverfolgen von Instruktionsergebnissen reserviert. Die Einheit 130 kann auch einen Registerumbenenner aufweisen, um Programm-/Befehlsreferenzregister in andere bezüglich des Prozessors 100 interne Register umzubenennen. Eine Reorder-/Retirement-Einheit 135 umfasst Komponenten, wie beispielsweise die oben erwähnten Reorder-Puffer, Ladepuffer und Speicherpuffer, um eine Out-of-Order-Ausführung und später ein In-Order-Retirement von Out-of-order ausgeführten Instruktionen zu unterstützen.
Ein Scheduler- und Ausführungseinheit(en)-Block 140 umfasst in einer Ausführungsform eine Schedulereinheit zum Planen von Instruktionen/Operationen auf Ausführungseinheiten. Zum Beispiel wird eine Gleitkommainstruktion auf einem Anschluss einer Ausführungseinheit, die eine verfügbare Gleitkomma-Ausführungseinheit besitzt, geplant. Registerdateien, welche mit den Ausführungseinheiten verknüpft sind, sind ebenfalls mit einbezogen, um Verarbeitungsergebnisse von Informationsinstruktionen zu speichern. Beispielhafte Ausführungseinheiten umfassen eine Gleitkomma-Ausführungseinheit, eine Ganzzahl-Ausführungseinheit, eine Sprungausführungseinheit, eine Ladeausführungseinheit, eine Speicherausführungseinheit und andere bekannte Ausführungseinheiten.
Ein niederrangiger Datencache und ein Datenübersetzungspuffer (D-TLB) 150 sind an die Ausführungseinheiten) 140 gekoppelt. Der Datencache dient dem Speichern zuletzt verwendeter/bearbeiteter Elemente wie Datenoperanden, die potentiell in Speicherkohärenzzuständen gehalten werden. Der D-TLB dient dem Speichern zurückliegender Übersetzungen von virtuellen/linearen auf physische Adressen. Als ein spezifisches Beispiel kann ein Prozessor eine Seitentabellen-Struktur zum Aufbrechen eines physischen Speicher in eine Mehrzahl von virtuellen Seiten aufweisen.
Dabei teilen die Threads 101 und 102 einen Zugriff auf einen höherrangigen oder weiter entfernten Cache 110, welcher dem Zwischenspeichern kürzlich abgerufener Elemente dient. Es ist zu beachten, dass sich höherrangig oder weiter entfernt auf Cache-Ebenen bezieht, welche zunehmen oder sich von der/den Ausführungseinheit(en) entfernen. In einer Ausführungsform ist der höherrangige Cache 110 ein Last-Level-Daten-Cache – ein letzter Cache in der Speicherhierarchie auf dem Prozessor 100 – wie beispielsweise ein zweit- oder drittrangiger Datencache. Allerdings ist der höherrangige Cache 110 nicht darauf beschränkt, da er mit einem Instruktionscache verknüpft sein kann oder einen solchen aufweisen kann. Ein Spur-Cache – eine Art von Instruktionscache – kann statt dessen nach dem Dekoder 125 gekoppelt sein, um kürzlich dekodierte Spuren zu speichern.
In der dargestellten Konfiguration umfasst der Prozessor 100 auch ein Busschnittstellemnodul 105 zum Kommunizieren mit Einrichtungen außerhalb des Prozessors 100, wie einem Systemspeicher 175, einem Chipsatz, einer Northbridge oder einer anderen integrierten Schaltung. Der Speicher 175 kann dem Prozessor 100 dediziert sein oder mit anderen Einrichtungen in einen System geteilt werden. Übliche Beispiele von Typen von Speicher 175 umfassen dynamische Speicher mit wahlfreiem Zugriff (DRAM), statischen RAM (SRAM), nichtflüchtigen Speicher (NV-Speicher) und andere bekannte Speichereinrichtungen.
Es sei angemerkt, dass 1 eine abstrahierte, logische Ansicht eines beispielhaften Prozessors mit einer Darstellung verschiedener Module, Einheiten und/oder Logik illustriert. Allerdings muss beachten werden, dass ein Prozessor, der die hierin beschriebenen Verfahren und Vorrichtungen benutzt, nicht die dargestellten Einheiten aufweisen muss. Ferner kann der Prozessor einige oder alle der gezeigten Einheiten entbehren. Darüber hinaus zeigt 1 nur zwei Kerne; dennoch kann ein Prozessor eine beliebige Anzahl von Kernen, wie z. B. mehrere Kerne des gleichen Typs, sowie mehr als zwei Kerne, die sich in ihrem Typ unterscheiden, aufweisen.
1 zeigt auch eine Ausführungsform eines Prozessors, der in einer Punkt-zu-Punkt-Anordnung mit einer Schnittstelle zu einem externen Speicher-Controller (Controller-Hub 170) gekoppelt ist. Allerdings weisen bereits viele aktuelle Prozessoren ein On-Processor-Speicherschnittstellenmodul – ein On-Chip-Modul – mit unterschiedlichen Verschaltungsarchitekturen, wie z. B. eine Ring-Konfiguration zum Verbinden mehrerer Kerne, sowie geteilte Caches und andere Schnittstellen auf.
Eine Ausführungsform einer solchen Verschaltungsarchitektur ist in 2 dargestellt. Ein Prozessor 200 ist als einen verteilten Cache, eine Ringverbindung sowie einen Kern, einen Cache und Speicher-Controller-Komponenten aufweisend dargestellt. Allerdings ist diese Darstellung rein illustrativ, da ein Prozessor, der die beschriebenen Verfahren und Vorrichtungen implementiert, beliebige Verarbeitungselemente, Arten oder Ebenen von Cache und/oder Speicher, einen Front-Side-Bus oder eine andere Schnittstelle zum Kommunizieren mit externen Geräten aufweisen kann.
In einer Ausführungsform dienen Caching-Agenten 221–224 jeweils dazu, einen verknüpften verteilten Cache zu verwalten. Es ist zu beachten, dass die Caching-Agenten 221–224 dazu dienen, Scheiben eines logisch geteilten Caches oder eines einzelnen privaten Caches auf der gleichen Speicherebene zu verwalten. Als ein Beispiel dient jede Cache-Komponente, wie z. B. die Komponente 221, dazu, eine Scheibe eines Caches für einen damit zusammengesetzten Kern – einen Kern, mit dem der Cache-Agent für den Zweck der Verwaltung der verteilten Scheibe verknüpft ist, zu verwalten. Wie dargestellt ist, werden die Cache-Agenten 221–224 als Cachescheibenschnittstellenlogiken (CSIL) bezeichnet; sie können auch als Cache-Komponenten, Agenten oder andere bekannte Logik, Einheiten oder Module zum Anbinden an einen Cache oder eine Scheibe davon bezeichnet werden. Es ist zu beachten, dass der Cache jede beliebige Ebene von Cache sein kann; dennoch konzentriert sich die Diskussion für diese beispielhafte Ausführungsform auf einen Last-Level-Cache (LLC), der von den Kernen 201–204 geteilt wird.
Sehr ähnlich wie die Cache-Agenten Verkehr auf der Ringverbindung 250 handhaben und a die Cache-Scheiben angebunden sind, dienen Kern-Agenten/-Komponenten 211–214 dazu, jeweils Verkehr mit den Kernen 201–204 handzuhaben bzw. an diese angebunden zu sein. Darüber hinaus ist der Ring 250 auch als einen Speicher-Peripherie-Hub (IMPH) 230 und einen Grafik-Hub (GFX) 240 aufweisend dargestellt, um an andere Module wie z. B. einen Speicher-Controller (IMC) 231 und einen Grafik-Prozessor (nicht dargestellt) angebunden zu sein. Jedoch kann der Ring 250 jedes beliebige der oben genannten Module aufweisen oder entbehren, sowie andere bekannte Prozessor-Module, die nicht dargestellt sind, aufweisen. Zusätzlich können ähnliche Module durch andere bekannte Verbindungen verbunden sein, wie eine Punkt-zu-Punkt-Verbindung oder eine Multi-Drop-Verbindung.
Ausführungsformen einer Test-Infrastruktur
In einer Ausführungsform weist ein Computersystem, das einen Prozessor, wie die in 1 und 2 Dargestellten oder eine andere bekannte Verarbeitungsvorrichtung umfasst, eine Test-Infrastruktur auf, welche dazu eingerichtet ist, (sowohl kosten- als auch komplexitäts-) effizient einen Test, eine Validierung und eine Fehlerbereinigung unterschiedlicher Aspekte in dem Computersystem zu unterstützen. Um solch eine effiziente Umgebung bereitzustellen, muss oft eine Anzahl von Schichten (z. B. physikalische, Kommunikations- und Software-Schichten) implementiert werden, wie etwa die in 3 dargestellten Schichten.
Zum Beispiel umfasst eine physikalische Schicht 305 Testhaken (in einem System bereitgestellte Hardware oder Firmware zum Bereitstellen von Test-, Validierungs- und/oder Fehlerbereinigungfunktionalität), die in den Einrichtungen (Prozessor, Verbindungen, Controller-Hubs, etc.) eines Computersystems enthalten sein können. In einer Ausführungsform sammeln diese Testhaken Fehlerbereinigungs-/Validierungsinformationen entweder durch Design, auf Anweisung anderer Hardware/Firmware, wie beispielsweise eines Microcontrollers oder auf Anweisung von Software, wie z. B. Benutzer-/Anbieter-Fehlerbereinigungsprogrammen oder eines in die Computerplattform integrierten Codes. Spezielle veranschaulichende Beispiele von einigen Haken umfassen: Architektur- und Mikroarchitekturtest-/spurmessmerkmale in einer Einrichtung, elektrische Validierungswerkzeuge, In-Computer-System-/On-Device-Logikanalysatoren, Verbindungsprotokoll-/Spurmessmerkmale, Plattformebenentestmerkmale, Leistungstestmerkmale (unten näher in den Ausführungsformen zur Leistungsvalidierung beschrieben), Einschalt-/Boot-Spurmessmerkmale, Validierungsschaltungen, Großserienfertigungstestmerkmale und andere bekannte Hardware-basierte Mess- und Testmerkmale.
Zusätzlich zum Bereitstellen der für einen Test entworfenen Haken ist in einer Ausführungsform eine Kommunikationsschicht 310 dazu eingerichtet, eine Kommunikation zwischen den Testhaken und einer Test-/Fehlerbereinigung-Software bereitzustellen. Die Kommunikationsschicht 310 kann so einfach sein wie es z. B. einer Software zu ermöglichen, direkt auf die Testhaken (entweder zum Definieren von Testszenarien oder zum Abrufen von Testergebnissen) zuzugreifen. Jedoch kann es, wie oben erwähnt, ein Designer einer Einrichtung wünschen, Silizium-Testmerkmale vor dem Zugriff durch Anbieter oder Benutzer zu verschleiern. Also stellt in diesem Szenario die Kommunikationsschicht 310 Software eine abstrahierte Darstellung von Hardware-Testmerkmalen bereit, so dass eine Anbieter- oder eine Benutzer-Software mit der Kommunikationsschicht 310 interagiert. Und die Kommunikationsschicht 310 interagiert mit Hardware innerhalb der physikalischen Schicht 305 in einer Weise, die der Sicht eines Kunden entzogen ist. In einer Ausführungsform dient ein Microcontroller, der als Validierungs-Steuereinheit (VCU) bezeichnet werden kann, dazu, einen Zugriff auf die verschiedenen Testhaken zu steuern. Hierbei ist Anbietersoftware dazu in der Lage, die VCU aufzufordern, verschiedene Validierungsaufgaben wie das Programmieren verschiedener Haltepunkte, Mikrohaltepunkt-Triggerereignisse, ein Extrahieren gespeicherter Spuren, ein Liefern einer Validierungsinformation und ein Bereitstellen unterschiedlicher Zugriffsniveaus zu koordinieren.
Wie in dem letzten veranschaulichenden Beispiel impliziert ist, können unterschiedliche Abstraktions- und Sicherheitsniveaus in Bezug auf die Test-Infrastruktur bereitgestellt werden. Hierbei kann ein Silizium-Designer für sich selbst einen ungehinderten Zugriff auf alle enthaltenen Testmerkmale wollen, während ein gleitendes Zugriffsmaß für verschiedene Anbieter, Kunden und Nutzer bereitgestellt wird. Folglich umfasst ein erster Schritt das Bereitstellen einer Abstraktionsschicht, die zur Abstrahierung der Haken in der physikalischen Schicht 305 in der Lage ist. Und der zweite Schritt umfasst das Bereitstellen einer sicheren Zugriffsmethodik, die in einer Ausführungsform dazu in der Lage ist, zwischen den verschiedenen Zugriffsniveaus abzugrenzen.
Darüber hinaus dient die Kommunikationsschicht 310 auch dazu, der Softwareschicht 315 einen Bericht über Validierungsinformationen bereitszustellen. Zum Beispiel sammelt ein On-Die-Logikanalysator eine Spurinformation von einem Prozessor. Und die Kommunikations-Schicht 310 umfasst eine Logik, welche dazu ausgelegt ist, die Spurinformation einer Speicherstruktur, wie einem Cache oder ein Speicher-System, in einem definierten Format bereitzustellen, so dass die Software-Schicht 315 auf die Daten zugreifen, sie erkennen und manipulieren kann. Als eine logische Folge stellt die Software-Schicht 315, die auch als eine Zugriffsschicht bezeichnet werden kann, Programme/Werkzeuge bereit, welche auf die Kommunikationsschicht 310 zugreifen und einen Testdateninhalt verarbeiten. In Fortsetzung des Beispiels von oben können Validierungs- und Fehlerbereinigungs-Programme die Spurinformation zur Interpretation (Validierung und Fehlerbereinigung) verarbeiten, wenn die Spurinformation in eine Speicherstruktur gebracht wurde.
Bisher betraf die primäre Diskussion des Zugriffs den logischen oder abstrahierten Zugriff auf Daten aus der physikalischen Schicht 305. Aber der Zugriff auf die physikalische Schicht 305 muss noch erörtert werden. In einem Beispiel verläuft ein solcher Zugriff über einen physikalischen Zugriff. Hier wird ein dedizierter oder universeller Fehlerbereinigungs-/Validierungsanschluss bereitgestellt, um eine bidirektionale Kommunikation (Aufwärtskommunikation von extrahierten Fehlerbereinigungsinformationen und Abwärtskommunikation von Fehlerbereinigungsanforderungen etc., wie beispielsweise mit einer VCU für einen abstrahierten Zugriff auf physikalische Haken) zu unterstützen. Dieser Anschluss kann irgendwo in einem Computersystem (Prozessoreinheit, Chipsatz, Mainboard oder durch eine vorhandene I/O-Schnittstelle, wie z. B. ein Universal Serial Bus Interface) angeordnet oder repliziert sein.
In einer weiteren Ausführungsform dient die Test-Infrastruktur auch dazu, einen Fernzugriff bereitzustellen. Es sei zum Beispiel angenommen, dass ein Anbieter versucht, einen Prozessor in einem Computersystem zu validieren, aber aufgrund der Komplexität aktueller Computer-Plattformen Probleme hat. Und dem Anbieter wird nur ein hohes Niveau von abstrahiertem Zugriff auf Prozessorfehlerbereinigung-Werkzeuge zur Verfügung gestellt. Anstelle dessen, dass der Prozessorhersteller physisch einen Validierungsingenieur senden muss, um bei dem Fehlerbereinigungsprozess zu unterstützen, ermöglicht die Infrastruktur potentiell einen Fernzugriff zur Validierung und zur Fehlerbereinigung. Darüber hinaus kann der entfernte Hersteller aufgrund der Sicherheitsprotokolle möglicherweise Zugriff auf einen größeren Teil einer Hardware-Infrastruktur haben, um das Fehlerbereinigungsproblem zu lösen, während die Verschleierung der Siliziumtestmerkmale vor dem Anbieter aufrechterhalten bleibt. Neben der Fehlerbereinigung aus der Ferne können die Schichten der 3 auch lokal oder aus der Ferne aktualisiert werden, wie beispielsweise durch das Bereitstellen von Patches, um Code innerhalb einer Firmware oder der VCU zu aktualisieren, um eine flexible und anpassungsfähige zukünftige Validierung bereitzustellen.
Es ist zu beachten, dass die 3 die Schichten einer Testarchitektur in drei Hauptkategorien verallgemeinert (physikalische, Kommunikation und Software). Allerdings kann der Testarchitekturstapel auf jede beliebige Art und Weise organisiert sein, wie z. B. auch andere Schichten, die die gleiche Testschnittstelle bereitstellen, aufweisen. Zum Beispiel umfasst der Validierungsarchitekturstapel in einer Ausführungsform eine Zielschicht (physikalische Einheit im DFx-Test), eine Transportschicht (Schicht, um den übergeordneten transportunabhängigen Stapel einzurichten, so dass er auf der Ziel-DFx-Einheit im Test läuft), eine Abstraktionsschicht (Schicht, um eine abstrahierte Kommunikation zwischen Applikationen und DFx-Schnittstellen niedriger Ebene bereitzustellen), eine Applikationsschicht (Schicht, welche Applikationen, Dienste, Werkzeuge und andere Software zum Kommunizieren mit der Abstraktionsschicht zum Ankoppeln an DFx-Dienste aufweist) und eine Präsentationsschicht (Schicht zum Korrelieren, Visualisieren und/oder Präsentieren zugrunde liegender Daten, Protokolle und Informationen).
Ausführungsformen von Validierungs-, Test- und Fehlerbereinigungshaken
In einer Ausführungsform werden Validierungs-, Test- und Fehlerbereinigungshaken in dem Silizium eines Prozessors und/oder eines Computer-Systems/einer Compter-Plattform zum Unterstützen effizienter Tests, Validierungen und/oder Fehlerbereinigungen integriert. Oft werden in Endprodukte integrierte Validierungshaken als Design zur Fehlerbereinigung, Validierung und/oder zum Test (hier DFx genannt) bezeichnet. DFx umfasst jeden beliebigen bekannten Haken in einem Produkt zum Unterstützen eines Tests, einer Fehlerbereinigung und/oder einer Validierung des betreffenden Produkts (Selbstvalidierungs-Werkzeuge). Im Folgenden sind zahlreiche anschauliche Beispiele für solche Haken enthalten; es ist jedoch wichtig anzumerken, dass die Liste nicht erschöpfend ist. Darüber hinaus können einige beliebige oder alle der unten beschriebenen DFx-Merkmale weggelassen oder mit anderen bekannten integrierten Test-/Fehlerbereinigungsmerkmalen kombiniert werden. Darüber hinaus bezieht sich die primäre Erörterung von DFx auf Prozessoren; dennoch können ähnliche Haken bei anderen Siliziumeinrichtungen wie beispielsweise Motherboards, Controller-Hubs, eingebetteten Prozessoren, Grafikprozessoren, Eingabe/Ausgabe(I/O)-Einrichtungen usw. vorgesehen sein.
Mit Bezug auf 4 ist eine Ausführungsform eines Computersystems mit mehreren Prozessoren dargestellt, um Ausführungsbeispiele von DFx-Merkmalen zu beschreiben. Es ist zu beachten, dass die Darstellung rein illustrativ ist, um die Beschreibung zu unterstützen. Und jede beliebige bekannte Computersystemkonfiguration, wie z. B. eine traditionellere Legacy-Konfiguration, wie sie in 1 dargestellt ist, kann verwendet werden. Ferner ist jeder der vier Prozessoren (410a, b, c und d) als die gleichen Komponenten aufweisend dargestellt. Und obwohl jeder Prozessor verschiedene asymmetrische Konfigurationen aufweisen kann, werden hauptsächlich die Merkmale des Prozessors 410a diskutiert, um die Beschreibung zu vereinfachen.
In einer Ausführungsform umfasst das Computersystem 400 eine oder mehrere Validierungssteuerungseinheit(en) (VCU), um einen Zugriff auf Silizium-DFx bereitzustellen und diesen zu steuern. Wie dargestellt umfasst jede Komponente (die Prozessoren 410a–d und der periphere Controller-Hub 470) jeweils ihre eigene VCU, doch kann jede beliebige Anzahl oder Layouts von VCUs vorgesehen sein, um einen Zugriff auf einen Prozessor oder ein Computersystem zu steuern. Ausführungsformen einer VCU und Merkmale im Hinblick darauf werden näher in dem Abschnitt zu den Ausführungsformen eines Validierungs-Controllers weiter unten diskutiert. Daher stellt die VCU 412a für den Zweck der Beschreibung der Ausführungsformen von DFx-Merkmalen in diesem Szenario einen Zugriff auf DFx-Funktionen des Prozessors 410a bereit.
Als ein erstes Beispiel eines DFx-Merkmals umfasst ein Prozessor 410a einen integrierten (auch als On-Die- oder On-Chip- bezeichneten) Logikanalysator (ODLA oder OCLA) 413a. Bisher enthalten Logikanalysatoren separate physische Einrichtungen, welche über externe Anschlüsse oder durch eine große Anzahl von Sonden an Bauteile gekoppelt sind, um digitale Signale der Einrichtung zu erfassen/anzuzeigen. Aber die externen Einrichtungen sind extrem teuer. Und während die Komplexität von Computern zunimmt, hat die Verspätung/Verzögerung zwischen dem Herstellen eines Produkts bis zur Entwicklung eines Logikanalysators, der zur Anbindung an das Produkt in der Lage ist, drastisch zugenommen. Folglich verliert die Technologiebranche die Fähigkeit, Produkte auf eine zeitgerechte und kostengünstige Weise von Fehlern zu bereinigen, zu validieren und auf den Markt zu bringen.
Daher umfasst der Prozessor 410a in einer Ausführungsform einen ODLA 413a (umfassend Hardware, Firmware, Mikrocode oder eine Kombination davon), der dazu eingerichtet ist, eine On-Die-Funktionalität eines Logikanalysators zu unterstützen. Mit anderen Worten umfasst der Prozessor 410a den ODLA 413a, um digitale Signale, Zustände, Spuren, etc. zu erfassen. Als ein spezifisches anschauliches Beispiel umfasst der Prozessor 410a Logik, welche dazu eingerichtet ist, Haltepunkte (oder Mikrohaltepunkte) zu setzen, um einen Erfassungspunkt auszulösen. Hierbei wird ein Ereignisspeicher, wie z. B. Steuerregister, mit einem oder einer Kombination von Ereignissen, die ein Auslöseszenario definieren, gesetzt. Und wenn dieses Szenario eintritt (jedes der Ereignisse geschieht in der im Szenario angegebenen Weise), werden die Zustände, Signale, Spuren, etc. von Interesse in dem Prozessor erfasst. Eine Auslösebedingung oder ein Auslöseszenario kann so einfach sein wie das Feststellen eines Vorliegens oder Fehlens eines Testsignals oder so komplex wie eine Kombination aus mikroarchitekturellen Ereignissen, wie z. B. ein Erreichen einer Anzahl von Anweisungs-Retirements-Pushouts über einer Schwelle, welche nur mit Anweisungen, die Ebene-Zwei-Cachefehltreffern ausgesetzt waren, verknüpft ist.
Es ist zu beachten, dass der ODLA 413a nicht physisch zusammengruppiert sein muss, wie in dem logischen Block in 4 gezeigt ist. Statt dessen kann der ODLA 413a eine über den Prozessor 410a verteilte Logik aufweisen, um ein oder mehrere beliebige interne oder abgehende Signale innerhalb des Prozessors 410a zu erfassen. In einem Szenario umfasst der ODLA 413a Folgendes: eine Logik, die mit architektonischen oder mikroarchitektonischen Abschnitten des Prozessors 410a verknüpft ist, um Spuren oder Schaltungslogikpegel zu erfassen; eine Logik, die mit internen Verbindungen verknüpft ist, um einen internen Datenverkehr zu erfassen; eine Logik, die mit Speicher-Schnittstellen, wie beispielsweise der Schnittstelle 460a zum Erfassen von Speicherverkehr verknüpft ist; eine Logik, die mit Eingabe/Ausgabe-Schnittstellen, wie z. B. den Schnittstellen 450, 465, einer Grafik-Schnittstelle (nicht dargestellt), einer Legacy- oder Seitenband-Schnittstelle (nicht dargestellt) oder einer anderen mit einem Prozessor verknüpften bekannten Schnittstelle verknüpft ist.
Bei früheren externen Logikanalysatoren wurden die Ergebnisse durch die externe Einrichtung erfasst. Doch in dem obigen Szenario wird der Prozessor 410a als sein eigener Logikanalysator betrieben. Daher dient der ODLA 413a in einer Ausführungsform dazu, einen zur Verfügung stehenden Computerspeicher zu verwenden, um die Erfassungsinformationen zu halten. Beispielsweise verwendet der ODLA 413a einen Cache-Speicher oder einen Teil des Speichers 420a als Spur-Puffer, um die erfasste Information zu halten. In einer Ausführungsform wird ein Teil des Speichers 420a aus der Sicht der Software abgesondert. Und die erfasste Information wird in den abgesonderten Teil des Speichers platziert.
Dabei kann die erfasste Information in ihrer Rohform mit einem vordefinierten, festgelegten Format platziert werden, so dass Validierungs-Software (entweder von einem Hersteller oder einem Kunden auf einer Applikationsschicht) mit dem entsprechenden Zugangsniveau auf die Daten zugreifen und diese manipulieren kann, wie beispielsweise Transformieren der Rohdaten in Zeitdiagramme, Protokolldekodierungen, Darstellung von Spuren oder eine andere bekannte Manipulation von Logikanalysatordaten. In einer anderen Ausführungsform formatiert der ODLA 413a (entweder mit enthaltener programmierbarer Logik, Code oder Microcode) die Rohdaten in eine andere Form und legt sie im Speicher zur Interpretation durch übergeordnete Software ab.
Als ein spezifisches Ausführungsbeispiel fordert eine Software ein bestimmtes Haltepunktszenario für den Prozessor 410a über eine Applikationsprogrammierschnittstelle (API), welche von einer durch die VCU 412a bereitgestellten Kommunikationsschicht, wie durch eine Abstraktionsschicht, bereitgestellt wird, an. Die VCU 412a empfängt die Anforderung und wenn die Anforderung über das erforderliche Zugriffssicherheitsniveau verfügt, setzt die VCU 412a das Trigger-Szenario in Steuerregistern des Prozessors 410a auf. Wenn das in den Steuerregistern definierte Haltepunktszenario angetroffen wird, wird der Haltepunkt dann entweder im Normal- oder in einem Testmodus der Ausführung ausgelöst. Und die erfasste Information wird in den Speicher 420a in einem von dem Einblick eines Betriebssystems verdeckten Bereich gespeichert. Über eine Schnittstellen-API kann eine Software auf die Information zugreifen, sie manipulieren und interpretieren; hierdurch wird im Wesentlichen die Notwendigkeit der Verwendung eines externen Logikanalysators oder Oszilloskops ersetzt, während potenziell ein vollständigerer und detaillierterer Blick auf die interne und externe Kommunikation von Siliziumeinrichtungen zur Verfügung gestellt wird.
Zusätzlich zum Festlegen von Trigger-Szenarien kann auch jede beliebige andere bekannte Technik zur Validierung in den ODLA 413a integriert sein und/oder mit diesem kombiniert werden. Beispielsweise kann der ODLA 413a in Kombination mit einer anderen Logik Testfälle setzen und eine ähnliche Spurinformation erfassen. In der Tat ist es durchaus üblich, dass Designer für Worst-Case-Szenarien entwerfen, die während der normalen Ausführung nicht leicht wiederholt werden. Als Ergebnis kann es während der Validierung vorteilhaft sein, den Prozessor 410a mit spezifischen Worst-Case-Stimuli anzuregen, um sowohl die tatsächliche Antwort als auch die Korrelation zwischen der tatsächlichen Antwort und vorhergehenden Simulationen zu ermitteln. Also ist hier die Logik dazu eingerichtet, spezifische logische Zustände zu setzen oder bestimmte Eingaben zum Generieren von Szenarien, von welchen der ODLA 413a Daten erfasst, zur Verfügung zu stellen.
Bisher hat sich die Diskussion von DFx hauptsächlich auf den ODLA 410a konzentriert, der einen internen Zustand des Prozessors 410a erfasst. Doch wie oben angedeutet, ist der ODLA 413a und/oder eine andere Logik in einer Ausführungsform auch dazu eingerichtet, externe Schnittstellen und Verbindungen zu validieren. Hier ist anstelle des Anordnens von Picosonden an den elektrischen Spuren zum Beobachten einer Kommunikation zwischen Einrichtungen wie mit externen Logikanalysatoren, der in das Silizium integrierte ODLA 413a dazu in der Lage, die gleiche Funktion an der eigentlichen Schnittstelle innerhalb der Einrichtung auszuführen.
Es ist zu beachten, dass ähnliche Verbindungshaken an On-Processor-Schnittstellen angeordnet sein können. Als ein Beispiel, wieder kurzzeitig zu 2 zurückkehrend, können DFx-Haken um den Ring 250 verteilt sein, um Folgendes zu validieren: die elektrischen Eigenschaften (Timing-Margen, Bitraten, Fehler-Tests, Kreuzkopplung, Ringing, Unterschreitung, Überschreitung, etc.) des Rings 250, den Verkehr auf dem Ring 250, das Kommunikationsprotokoll (d. h. Cache-Kohärenz-Protokoll) des Rings 250, den Verkehr/die Protokolle auf der Controller-Schnittstelle 230/231, den Verkehr auf der Grafikschnittstelle 240, etc.
Als Ergebnis kann die Validierung einer komplexen Schnittstelle in Silizium integrierte Haken umfassen, um mehrere Schichten eines Verbindungsarchitekturstapels zu validieren, wie z. B. die physikalischen, elektrischen Eigenschaften, Zustande/Spuren von Logik und übergeordnete Protokolle. In der 4 sind einige Beispiele solcher Schnittstellen (QPI Schnittstelle 450 zum Verbinden von Prozessoren 410a–d; Speicherschnittstellen 460a–d zum Verbinden der Prozessoren 410a–d mit Speichervorrichtungen 420a–d und ein PCI-E oder eine andere Schnittstelle zum Verbinden des Legacy-Prozessors 410c mit einem peripheren Controller-Hub 470) dargestellt, die DFx-Haken für die Validierung aufweisen. Zusätzlich können auch andere Schnittstellen, wie z. B. eine Grafikschnittstelle oder eine Seitenbandverbindung ähnliche DFx-Haken nutzen, wie sie hierin beschrieben sind. Dennoch ist es wichtig anzumerken, dass die dargestellten Schnittstellen auf einen Prozessor zentriert sind. Und andere Einrichtungen, wie der PCH 470 können auch ähnliche DFx-Haken zum Validieren anderer Schnittstellen, wie Peripherieschnittstellen (PCI-E, Universal Serial Bus (USB), Serial Advanced Technology Attachment (SATA), Direct Media Interface (DMI) und andere bekannte Computerverbindungen) aufweisen.
Um ein bestimmtes Darstellungsbeispiel zu geben, zeigt 5 ein Ausführungsbeispiel eines Blockschaltbildes für eine bidirektionale Verbindungsarchitektur unter Verwendung eines geschichteten Verbindungsstapels; illustrative Beispiele davon umfassen eine PCI-Express-(PCI-E)- und eine Quick-Path-Verbindung (QPI). Die dargestellte geschichtete Architektur wird hauptsächlich in Bezug auf eine QPI-Architektur erörtert, kann aber auf ähnliche Weise bei jeder Verbindung verwendet werden, wie z. B. bei einer PCI-, PCI-E-, Grafik-, Speicher-, Peripherie- oder anderen bekannten Verbindung. Die Bezugnahme auf Schichten der 5, wie beispielsweise eine physikalische Schicht 502, umfasst eine Diskussion einer generischen Schicht, die in unterschiedlichen Mitteln realisiert werden kann, wie beispielsweise der physikalischen Schicht 502a und der physikalischen Schicht 502b. Wie dargestellt ist der Verbindungsstapel in fünf Schichten unterteilt, wovon eine oder mehrere potentiell optional auf einer Design-Implementierung beruhen. Zum Beispiel ist die Routing-Schicht 504 in einer Ausführungsform in die Funktionalität der Verbindungsschicht 503 eingebettet; daher ist die Routing-Schicht in einer Ausführungsform keine separate und unterschiedliche Schicht.
In einer Ausführungsform ist die physikalische Schicht 502 für die elektrische Übertragung der Information auf einem physikalischen Medium verantwortlich. Zum Beispiel wird eine physikalische Punkt-zu-Punkt-Verbindung zwischen Verbindungsschichteinheiten 503a und 503b eingesetzt. Als ein veranschaulichendes Beispiel weist die physikalische Verbindung ein Differentialsignalisierungsschema auf, das ein bidirektionales Differentialsignalübertragungspaar 551 und 552 umfasst. Hierbei wird die physikalische Schicht potentiell logisch in einen elektrischen Unterblock und einen logischen Unterblock aufgeteilt, so dass die physikalische Schicht dazu dient, den Rest des Stapels von der elektrischen Übertragung von Informationen zu isolieren und dazu dient, mit der Verbindungsschicht 503 zu kommunizieren.
In einer Ausführungsform abstrahiert die Verbindungsschicht 503 die physikalische Schicht 502 von oberen Schichten des Stapels und bietet verbindungsbezogene Dienste, wie eine zuverlässige Datenübertragung und Flusskontrolle zwischen den angeschlossenen Agenten/Einheiten und eine Virtualisierung eines physikalischen Kanals/einer physikalischen Schnittstelle in mehrere virtuelle Kanäle und Nachrichtenklassen. Hierbei können virtuelle Kanäle als mehrere virtuelle Netzwerke zum Verwenden durch obere Schichten des Stapels betrachtet werden. Beispielsweise verlässt sich die Protokollschicht 506 potentiell auf die durch die Verbindungsschicht 503 zur Verfügung gestellte Abstraktion, um eine Protokollmitteilung auf eine Nachrichtenklasse und damit auf einen oder mehrere virtuelle Kanäle abzubilden.
Die Routing-Schicht 504 stellt in einer Ausführungsform ein flexibles Verfahren zum Leiten von Paketen von einer Quelle zu einem Ziel bereit. Wie oben angegeben ist, kann die Routing-Schicht 504 in extrem einfachen Topologien nicht explizit sein, sondern in die Funktionalität der Linkschicht 503 integriert sein. Zum Beispiel kann die Routing-Schicht 504 auf der Abstraktion der Verbindungsschicht 503 aufbauen, um ein <Anschluss, virtuelles Netzwerk>-Paar anzugeben, um ein Paket zu routen. Hierbei werden Routingtabelleninformationen vorgehalten, um Routing-Informationen für Pakete zur Verfügung zu stellen.
In einer Ausführungsform stellt die Transportschicht 505 zuverlässige Ende-zu-Ende-Übertragungsdienste bereit. Ähnlich wie die Routing-Schicht 504 beruht die Transportschicht 505 ebenfalls optional auf einer Design-Implementierung. Als Beispiel baut die Transportschicht 505 auf der Routing-Schicht 504 auf, um eine zuverlässige Übertragungsdienstunterstützung für die Protokollschicht 506 bereitzustellen. Innerhalb einer Verbindungsarchitektur weist in einer Ausführungsform eine Untergruppe von Komponenten eine Transportschicht 505 auf. Infolgedessen definiert diese Untergruppe von Komponenten Teilfelder von Paketen, welche sich auf die Transportschicht 505 beziehen, während andere Komponenten diese Teilfelder potentiell nicht definieren.
Die Protokollschicht 506 dient in einer Ausführungsform dazu, ein übergeordnetes Kommunikationsprotokoll zwischen Knoten/Agenten, wie z. B. eine Cachekohärenz-, Ordnungs-, Peer-to-Peer-Kommunikation, Interrupt-Lieferung, etc. zu implementieren. Mit anderen Worten definiert die Protokollschicht 506 entsprechend zulässige Nachrichten, Anforderungen, Antworten, Phasen, Kohärenzzustände usw. für Knoten oder Agenten, wie Home-Knoten, Peer-Knoten, Caching-Knoten und Nicht-Caching-Knoten. Beispiele von Nachrichten, wie beispielsweise Home-Knoten-Nachrichten, Snoop-Nachrichten, Antwortnachrichten usw. werden nachfolgend diskutiert.
Man beachte, dass die Diskussion von Schichten und diesen zugeordneter Logik auf jede beliebige Weise gekoppelt sein kann. Zum Beispiel kann gesagt werden, dass eine Protokolllogik an eine physikalische Schicht gekoppelt ist, d. h. Übertragungs- oder Empfangslogik. Hierbei kann, wie aus 5 ersichtlich ist, in einer Ausführungsform die Protokolllogik nicht direkt mit der Logik der physikalischen Schicht gekoppelt sein, sondern durch eine andere Schichtlogik gekoppelt sein. Weiterhin ist der Verbindungsstapel in einer Ausführungsform an eine innere Komponentenlogik, wie beispielsweise eine Cache-Steuerung oder eine Cache-Speicher-Logik gekoppelt, um geeignete Cachekohärenzaktionen zu initiieren.
In einer Ausführungsform umfasst eine QPI-basierte Verbindung ein Modified Exclusive Shared Invalid Forward(MESIF)-Protokoll, das ein Protokoll ähnlich einem Snoop-Protokoll liefert, ohne die potentiellen Beschränkungen eines einzigen, serialisierenden Busses. Wie ein Snooping-Cache-Protokoll basiert MESIF auf Knoten mit zwischengespeicherten Kopien von Daten, um die Kohärenz aufrecht zu erhalten. Die Verwendung von Punkt-zu-Punkt-Verbindungen anstelle einer synchronen, zentralisierten Verbreitung bringt das Problem der zeitlichen Verzerrung mit sich, d. h. die Tatsache, dass Ereignisse vom Standpunkt der unterschiedlichen Knoten in einer unterschiedlichen Reihenfolge zu erfolgen scheinen. Beispielsweise handhabt das MESIF-Protokoll eine zeitliche Verzerrung durch das Erkennen von möglichen Fehler aufgrund von zeitlicher Verzerrung und stellt eine Protokoll- oder Software-Lösung hierfür zur Verfügung.
Ein Home-Knoten ist oft mit einer nicht zwischengespeicherten Kopie von Daten verknüpft. Als Ergebnis kann ein Home-Knoten an einer Transaktion in Bezug auf mit dem Home-Knoten verknüpften Daten teilnehmen. Allerdings muss der Home-Knoten nicht in einen mit einer Transaktion verknüpften ”kritischen Pfad” aufgenommen werden, sondern vielmehr kann ein Home-Knoten in die Transaktion einwerfen, um Konflikte und Probleme zeitlicher Verzerrungen zu beheben. Wegen des Charakters gleichzeitiger Verbreitung des Schemas erreicht MESIF in einer Ausführungsform die niedrige, mit Snooping-Protokollen verknüpfte Latenz, während es eine cachefähigen Kopie der Daten in bestimmten Fällen mit der minimal möglichen Latenz beschafft: einem einzigen Rundlauf von Anforderung-Antwort.
In einer Ausführungsform umfasst eine grundlegende, auf ein MESIF-Protokoll bezogene Transaktion ein Verbreiten einer ersten Anforderung an alle Peer-Knoten sowie einen Home-Knoten. Wenn eine Kopie in dem E-, F- oder M-Kohärenzzustand zwischengespeichert ist, wird sie in die Antwort aufgenommen. Eine zweite Nachricht wird dann an den Home-Knoten gesendet, wodurch er informiert wird, dass die Anforderung erfüllt worden ist. Wenn die angeforderte Zeile nicht zwischengespeichert ist oder wenn nur Kopien in einem S-Zustand existieren, wird die zweite an den Home-Knoten versendete Anforderung verwendet, um die vorherige Anforderung zu bestätigen, welche der Home-Knoten mittlerweile aus seinem Speicher geholt haben kann. In jedem Fall reagiert der Home-Knoten auf die zweite Anforderung (und potenziell die erste, obwohl sie manchmal kombiniert sein können) zum Zwecke der Synchronisation und Konfliktlösung. Es ist zu beachten, dass der Home-Knoten einen oder mehrere Caches haben kann, so dass er auf die anfängliche Anforderung wie jeder andere Knoten reagieren kann.
In einer Ausführungsform werden Konflikte auf eine verteilte Weise behandelt. Das Zeitverzerrungsproblem macht es schwierig, Konflikte zu erfassen, weil die einzelnen Anforderungen um eine beliebig lange Zeit verzögert sein können. Ein Konflikt wird jedoch erkannt werden, wenn jeder Knoten auf Konflikte nach einer Anforderung achtet. Mehrere Knoten können potenziell einen Konflikt erkennen, aber als ein Beispiel wird mindestens einer der Knoten einen Konflikt erkennen. Als Ergebnis wird eine Antwort von einem Knoten in einer Ausführungsform potentiell Konfliktinformationen enthalten.
In einer Ausführungsform ist es einem Knoten, der eine Kopie der Daten aus einer Antwort erhält, erlaubt, die Daten intern sofort bei Empfang zu verwenden, werden jedoch nicht die Auswirkungen der Verwendung der Daten für den Rest des Systems sichtbar gemacht, d. h. global sichtbar, bevor der Knoten eine Bestätigung erhalten hat. Die Bestätigung kann auch Anweisungen dahingehend, dass der anfragende Knoten seine Kopie an einen anderen Knoten weiterleiten und vielleicht den Knoten aus seinem eigenen Cache herauswerfen soll, umfassen. Schließlich verschiebt ein Knoten, wenn der Knoten auf eine Anforderung von einem anderen Knoten antwortet, indem er zwischengespeicherte Daten bereitstellt, in einer Ausführungsform andere Anforderungen, die er für die gleichen Cache-Zeile empfängt, bis der Knoten eine Antwort von dem Home-Knoten empfängt, in der anerkannt wird, dass der Knoten die Daten weitergeleitet hat, wodurch sichergestellt wird, dass alle Knoten die gleiche Reihenfolge der Übertragung der (möglicherweise schreibbaren) Cache-Zeile beachten.
Wie oben angegeben ist der Home-Knoten ein Aufbewahrungsort für nicht zwischengespeicherte Daten, aber der Home-Knoten kann auch einen Prozessor und einen Cache umfassen. Wenn dem Home-Knoten der Cache fehlt, sendet der Home-Knoten Verbreitungsanforderungen an alle anderen (Peer-)Knoten und der Home-Knoten handhabt die Anforderung intern wie jede beliebige andere Anforderung, die für den Home-Knoten ankommt. Es ist zu beachten, dass dies ein Sonderfall ist, da der Home-Knoten nicht explizit Nachrichten an sich selbst (den Home-Knoten) sendet. Darüber hinaus antwortet der Home-Knoten entsprechend, wenn eine externe Anforderung nach Daten, die lokal zwischengespeichert sind, ankommt.
Das offenbarte Nachrichtenprotokoll definiert eine Menge von erlaubten Nachrichten zwischen Kohärenz-(Cache- und Home-)-Agenten, Nicht-Caching-Agenten, sowie anderen Agenten (Speicher-Controller, Prozessoren, etc.). Ein Kohärenzprotokoll verwendet die Nachrichten als Worte und Grammatik in einem Algorithmus, um einen kohärenten Gedanken auszudrücken. Dieser Algorithmus ordnet Anforderungen sinnvoll, löst Konflikte und beschreibt Interaktionen zwischen Caching-Agenten. Obwohl oben ein MESIF-Protokoll beschrieben ist, wird nicht notwendigerweise das MESIF-Cache-Kohärenzprotokoll verwendet. Zum Beispiel kann der Forward-Zustand nicht genutzt werden, was zur Folge hat; dass das bekannte MESI-Protokoll verwendet wird. Außerdem ist zu beachten, dass die obige Diskussion einen beispielhaften Überblick über eine Ausführungsform für ein MESIF-Protokoll enthält. Folglich können sich verschiedene, oben beschriebene Komponenten in verschiedenen Ausführungsformen unterscheiden.
Es ist verständlich, dass die Validierung und Fehlerbereinigung von etwas (sowohl aus elektrischer Sicht als auch aus Protokollsicht) so Komplexem extrem umständlich werden kann. Daher umfasst der Prozessor 410a aus 4 in einer Ausführungsform DFx, um bei der Validierung in einem geschichteten Verbindungsstapel zu unterstützen. Beispielsweise ist der ODLA 413a in Antwort auf ein Trigger-Szenario oder ein anderes Ereignis dazu in der Lage, einen Verkehr, Spuren oder Zustände der geschichteten Verbindungsarchitektur zu erfassen. In einer Ausführungsform bezieht sich ein Zustand auf eine Momentaufnahme von Zuständen von Parameter, Einrichtungen, Agenten und/oder anderen Komponenten eines Validierungsobjekts. Ein Zustand kann auch als Architekturzustand einer Architektur oder eines Validierungsobjekts bezeichnet werden. Als weiteres Beispiel ist ein Zustand durch die Kombination der Werte von Parameter bei der Momentaufnahme des Zustands definiert. Wenn man einhundert Parameter für eine Verbindungsarchitektur identifiziert, dann führt jede Kombination verschiedener Werte für diese einhundert Parameter folglich potentiell zu verschiedenen Zuständen.
Da sich ein Zustand auf eine große Anzahl von Parameter für ein komplexes Protokoll bezieht, umfasst ein übervereinfachtes veranschaulichendes Beispiel eines Zustand für ein Cache-Kohärenz-Protokoll einen Prozessor, der eine Cache-Zeile in einem geteilten Kohärenzzustand hält, zwei Prozessoren, welche die Cache-Zeile in einem ungültigen Zustand halten, und ein Snoop wird bei einem der Prozessoren empfangen. Hierbei gibt es mehrere Protokoll-Agenten, mehrere Cache-Zeilen, die in mehreren Zustande gehalten werden, und eine Anforderung/Meldung, die an einem bestimmten Ziel empfangen wird. Daher sind in diesem einfachen Beispiel allein durchaus einige Parameter vorhanden. Als ein weiteres erläuterndes Beispiel führt eine Schreibtransaktion, die eine Datennutzlast trägt, potentiell zu mehreren Zuständen, da andere Parameter, wie zum Beispiel das Ziel des Schreibbefehls, der Zustand der mit der zu schreibenden Datennutzlast verknüpften Cache-Zeilen, Verbindungsverkehr, Schreibantworten von anderen Agenten, usw. variieren können.
Daher bezieht sich ein Parameter in einer Ausführungsform auf jedes beliebige Element innerhalb eines Protokolls, einer physikalischen Logik, einer Einrichtung, eines Agenten oder eines globalen Zustands/einer globalen Variable, das variiert werden kann oder in unterschiedliche Zustände gebracht werden kann. Als ein spezifisches Beispiel umfasst ein Parameter für einen Caching-Agenten, wie z. B. den Prozessor 410a, beim Validieren eines cachekohärenten Verbindungsprotokolls eine Cache-Antwort auf einen Snoop. Hierbei umfasst ein Wert eines Cache-Antwortparameters ein Weiterleiten der gesnoopten Cachezeile an die anfordernde Einrichtung und ein zweiter Wert des Cache-Antwortparameters umfasst ein Schreiben der Cache-Zeile in einen Home-Knoten. Andere übliche Kohärenz-Protokoll-Parameter umfassen verschiedene Arten von Agenten, Agentenantworten, Einrichtungsantworten, Verbindungsantworten, Nachrichtenantworten, Arten von Antworten, andere Antworten auf konkrete Aktionen, Antwortziele, Nachrichten, Arten von Nachrichten, Nachrichtenziele, Anforderungen, Arten von Anforderungen, Anforderungsziele, Arten von Caches, Cache-Zustande, Cache-Orte, Registerzustände, etc.
Da jedoch jede beliebige Architektur, wie z. B. ein physikalisches Verbindungs-Kommunikationsprotokoll, oder ein anderes Protokoll ein Objekt einer Validierung sein kann, kann ein Parameter eine große Auswahl von Variablen umfassen. Eine nicht erschöpfende illustrative Liste von potentiellen, protokollbezogenen Parametern umfasst eine Anzahl von Protokoll-Agenten, einen Typ eines Protokoll-Agent, einen Typ einer Cache-Umsetzung für einen Agenten, Anzahlen von Protokoll-Agenten unterschiedlicher Arten, einen Stil eines Protokoll-Agenten, einen Zustand eines Protokoll-Agenten, einen Zustand der Schaltung oder eine Zustandsmaschine in einem Protokoll-Agenten oder auf einem Bus, eine Agentenkennung, eine Anzahl von Protokollanforderungen, einen Anforderungstyp, eine Anforderungsquelle, ein Anforderungsziel, einen Zustand einer Anforderung, eine referenzierte Operation, eine Quelle einer Operation, eine referenzierte Adresse, eine Adresse, auf die zugegriffen wird, einen Zustand eines Adressortes, eine Datennutzlast, einen Zustand eines Protokoll-Agenten, einen Zustand eines Cache, einen Zustand einer Cache-Zeile und einen physikalischen Protokollzustandsparameter, wie z. B. eine Spannung, eine Frequenz, einen Leistungszustand oder ein anderes physikalisches Protokollattribut.
In Bezug auf die physikalischen Schichten 502a, b umfassen einige Beispiele von physikalischen Parametern einer Verbindung eine Spannung, ein Unterschwingen, ein Überschwingen, eine Frequenz, eine Periode, ein Spreizspektrum, einen Jitter, eine Taktbegrenzung, ein Rauschen, etc., während andere Parameter den Zustand von verbindungsbezogenen Zustandsmaschinen, Typen von Agenten, Zustände von Agenten, Zustande von I/O-Schaltungen in Agenten usw. aufweisen. Es kann jedoch jedes beliebige variable Element innerhalb einer Architektur als ein Parameter verwendet werden.
Daher ist der ODLA 413a in einer Ausführungsform dazu eingerichtet, Zustande oder Spuren, die die gesamte oder Teile der Zielschnittstelle umfassen können, zu erfassen. Zusätzlich zu einer bestimmten Momentaufnahme zu einem Zeitpunkt in Antwort auf ein definiertes Ereignis, wie etwa ein Trigger-Szenario, ist der ODLA 413a dazu eingerichtet, einen Verkehr (mehrere Zustande der Kommunikation an einer Schnittstelle) zu erfassen. In diesem Szenario wird ein Protokollaustausch zwischen den Einrichtungen erfasst. Und nachdem die Daten verarbeitet wurden, ist übergeordnete Software dazu in der Lage, Protokolldiagramme zu erstellen, um zu validieren, dass der richtige Protokollaustausch an der Schnittstelle erfolgt. In Fortsetzung des obigen Beispiels kann DFx-Silizium entweder ein bestimmtes Trigger-Szenario, welches damit verknüpft ist, dass der Prozessor 410a eine spezifische Snoop-Nachricht für eine Cache-Zeile in einem exklusiven Kohärenzstatus empfängt, erzeugen oder damit geladen werden. Und der ODLA 413a erfasst Informationen, wie beispielsweise die Antwort des Prozessors 410a auf etwas wie eine Snoop-Nachricht, in einem Bereich des Speichers 420a. Über eine von der VCU 412a bereitgestellte API kann eine Drittanbieter-(TPV)-Applikation mit dem entsprechenden Zugang ein auf den in dem zweiten Speicher 420a gehaltenen Informationen basierendes Protokoll aufbauen, um zu validieren, dass die richtige Antwort auf die spezifische Snoop-Nachricht unter den Umständen des definierten Zustands gegeben wurde.
Wie aus diesem Beispiel ersichtlich ist, können ähnliche Verfahren und Vorrichtungen verwendet werden, um sowohl die elektrischen Eigenschaften als auch die Protokolle, wie die oben eingeführten MESIF cachekohärenten Protokolle, der QPI-Verbindung 450 zu validieren. Und das illustrative Beispiel des Validieren der QPI-Verbindung 450 kann extrapoliert werden, um zu zeigen, wie auf Silizium befindliche Haken eine Validierung für jede beliebige Schnittstelle, wie z. B. eine geschichtete Verbindungsarchitektur, bereitstellen können.
Über den ODLA 413a und Validierungshaken für interne und externe Schnittstellen des Prozessors 410a hinaus können auch andere Silizium-Haken in den Prozessor 410a integriert sein. Beispielsweise können spezifische mikroarchitektonische Haken in einer Ausführungsform von dem Prozessor 410a umfasst sein. Zum Beispiel beschreibt eine gleichzeitig anhängige Anmeldung mit der Seriennummer 11/143,425 und dem Titel ”ENHANCEMENTS TO PERFORMANCE MONITORING ARCHITECTURE FOR CRITICAL PATH-BASED ANALYSIS” eine Vorrichtung und ein Verfahren zur Überwachung der Leistung einer Mikroarchitektur. Die Leistung wird durch Simulation, analytische Überlegungen, Retirement-Pushout-Messungen, die gesamte Ausführungszeit und andere Verfahren zum Bestimmen von Ereigniskosten pro Fall überwacht. Als Ergebnis können ähnliche Vorrichtungen in Silizium enthalten sein, um Anweisungen basierend auf mikroarchitektonische Ereignissen mit einer Markierung zu versehen/zu zählen, Retirement-Pushouts zu messen, eine gesamte Ausführungszeit von Anweisungen/Programmen zu bestimmen und ein beliebiges anderes bekanntes Merkmal eines Prozessors zu validieren/von Fehlern zu bereinigen.
Als weiteres Beispiel illustriert der Prozessor 410a eine Power Control Unit (PCU) 414a, um Leistung, wie z. B. Leistungszustände von Verarbeitungselementen in dem Prozessor 410a, zu koordinieren und zu steuern. Darüber hinaus können DFx-Haken von der PCU 414a umfasst sein, um verschiedene Leistungsvalidierungsmetriken, wie z. B. Stromverbrauchsniveaus, eine in verschiedenen Leistungszuständen verbrachte Zeit, die Frequenz von Leistungszustandsübergängen, das Protokoll von Leistungszustandsübergängen und jede beliebige andere bekannte leistungsbezogene Metrik zu erfassen. Ähnlich dem Betrieb des ODLA 413a können Leistungsinformationen im normalen Betrieb, während eines Testmodus mit spezifischen Worst-Case-Leistungssenarien (d. h. Worst-Case-Leistungsresonanzfrequenzen, wie sie von Worst-Case-Mustern erzeugt werden, die über Schnittstellen übertragen werden) als vorgesehene Stimuli oder als Antwort auf das Antreffen von Trigger-Szenarien gesammelt werden. Leistungs-DFx und der Betrieb werden in größerem Detail unten in Bezug auf 28 diskutiert.
Wieder weg von den illustrativen, prozessorzentrischen DFx, die in ähnlicher Weise in jeder beliebigen Einrichtung in einem elektronischen System enthalten sein können, können andere Plattformebenen-DFx enthalten sein. Man beachte, dass die DFx-(Fehlerbereinigungs-)Merkmale, die oben und unten beschrieben sind, einzeln ohne andere Teile der hierin beschriebenen Testarchitektur implementiert sein können. Zum Beispiel kann das Erfassen von Signalinformationen früh in einem Boot-Vorgang, wie detaillierter unter Bezugnahme auf die 6 bis 8 beschrieben ist, auf einem Legacy-System ohne eine Validierungsteuereinheit oder geschichteten, abstrahierten Zugriff implementiert sein.
Mit Hinblick auf 6 ist eine Ausführungsform eines Blockschaltbildes für das Erfassen früher Einschaltsignalinformationen dargestellt. Hier ist der PCH 605 über ein Direct Media Interface (DMI) 635 an den Prozessor 640 gekoppelt. Normalerweise wird beim Einschalten zuerst der PCH 605 hochgefahren. Und wie die meisten Silizium-Einrichtungen wird der PCH 605 in Etappen hochgefahren. Beispielsweise werden bestimmte Quellen in einer bestimmten Reihenfolge hochgefahren. Als rein illustratives Beispiel werden die Takte 610 zuerst eingeschaltet; diesen folgen die Quellen 615 und 620, wie z. B. eine ausgesetzte Quelle, eine aktive Quelle, eine Echtzeittaktquelle, etc. Schließlich wird eine Testlogik 625, wie beispielsweise ein Manageability-Engine und/oder ein Testzugriffsanschluss (TAP) aktiviert.
Unter bestimmten Umständen sind bestimmte Einschalt- oder frühe Signale, welche übergehen, bevor die Testlogik 625 aktiviert ist, nicht sichtbar (es gibt keinen Einblick in ein Problem mit diesen Signalen), weil die mit diesen Signalen verknüpften Übergangsinformationen zu der Zeit, zu der die Testlogik 625 im Boot-Vorgang aktiviert wird, oft verloren sind. Dennoch kann es während der Validierung und Fehlerbereinigung vorteilhaft sein, Informationen über solche Signale sehen und erfassen zu können. Ein veranschaulichendes Beispiel eines solchen Signals umfasst ein Rücksetzsignal eines Power-Management-Controllers. Hierbei weist ein Übergang dieses Signals den Power-Management-Controller an, das Abholen und Ausführen zu starten. Also kann das Bestimmen: (1) ob das Signal nicht übergegangen ist; (2) ob das Signal übergegangen ist und/oder (3) wann das Signal übergegangen ist, bei der Fehlerbereinigung eines Szenarios, in dem der Power-Management-Controller hängt, (ein ”Hängenbleiber”-Szenario) helfen.
Daher dient in einer Ausführungsform eine Logik zum Erfassen früher Einschaltsignale (die auch als Frühboottestlogik bezeichnet werden kann) dazu, frühe Signalinformationen zu erfassen, bevor eine Einrichtung vollständig eingeschaltet ist. Jedes bekannte Verfahren oder jede bekannte Vorrichtung zum Erfassen von Signalinformationen, wie z. B. Spuren, kann verwendet werden. Dabei weist die Erfassungslogik 630 eine Logik auf, welche dazu eingerichtet ist, spezifische Signalinformationen nach einem anfänglichen Einschalten zu erfassen und solche Signalinformationen zu speichern. Und danach, wenn die Testlogik 625 aktiviert wird, können die Informationen ausgelesen werden, um angemessene Fehlerbereinigungsoperationen durchzuführen.
Mit Bezug auf 7 ist eine Ausführungsform eines übergeordneten Blockdiagramms einer Erfassungslogik zum Erfassen früher Signale während eines Bootens eines elektronischen Systems dargestellt. Wie dargestellt ist, weist die Erfassungslogik 700 Speicherelemente 720, wie beispielsweise Register, auf, welche dazu eingerichtet sind, Informationen über Signale von Interesse (d. h. die Signale, welche während des Bootens überwacht werden sollen, wie beispielsweise sig 1, 2, 3...11) zu erfassen/zu halten. In einer Ausführungsform beginnt die Erfassungslogik 700 in einer standardmäßigen, vorkonfigurierten Einstellung beim Einbringen von Leistung damit, Signalinformationen zu erfassen (ohne die Notwendigkeit eines Auslesens durch einen Benutzer oder einen Zugriff/eine Programmierung Dritter). Als ein anderes Beispiel beginnt das Erfassen beim Auftreten einer spezifischen Bedingung, wie beispielsweise einem Übergang eines spezifischen Signals/Taktes oder daraufhin, dass eine spezifische Quelle aktiviert wird. In ähnlicher Weise kann die Signalerfassung beim Auftreten einer Bedingung angehalten werden, wie beispielsweise nach einer Zeitspanne/einer Anzahl von Zyklen, einer Zeitspanne, ohne dass ein Übergang eines oder mehrerer Signale von Interesse detektiert wird, wenn ein letztes Signal von Interesse übergeht, wenn ein letztes Signal von Interesse nicht nach einer Zeitspanne übergeht, wenn eine spezifische Quelle aktiviert wird, wenn eine Testlogik aktiviert wird, wenn ein Programm anzeigt, dass das Erfassen aufhören soll oder bei jedem beliebigen anderen bekannten Ereignis.
Obwohl jede beliebige bekannte Vorrichtung oder jedes beliebige bekannte Verfahren zum Erfassen von Signalinformationen (einer Übergangszeit, einer Anzahl von Übergängen, einer Richtung eines Übergangs, einer Spur, etc.) verwendet werden kann, wird eine spezifische illustrative Ausführungsform mit Bezug auf 7 beschrieben. In diesem Szenario zeichnen die Register 720 eine Zeit auf, wann ein Signal von Interesse (oder wann jedes Signal von Interesse) übergeht. Zum Beispiel weisen die Register 720 ein Signalnamensfeld und ein Zeitstempelfeld auf. Das Signalnamensfeld ist dazu eingerichtet, eine Bitdarstellung zu halten, welche ein Signal von Interesse identifiziert (d. h. ein Bitmuster, welches als einem spezifischen Signal von Interesse entsprechend erkannt wird). Und das Zeitstempelfeld ist dazu eigerichtet, eine Bitdarstellung einer Zeit zu halten, welche einem Übergang des in dem Signalnamensfeld identifizierten Signals entspricht. Es ist zu beachten, dass der Zeitstempelwert in einem Szenario über eine Siliziumversetzung einer Einrichtung, wie beispielsweise des PCH 605 aus 6, deterministisch ist. Dabei sind die Zeitstempel über Siliziumversetzungen, welche zur Fehlerbereinigung verwendet werden sollen, deterministisch.
Zusätzlich können die Register 720 ein Statusfeld halten, welches dazu eingerichtet ist, einen gültigen Wert zu halten, um anzuzeigen, dass das Signalnamensfeld und das Zeitstempelfeld gültige Informationen halten. Umgekehrt zeigt ein ungültiger Wert an, dass Zustande der entsprechenden Felder in dem gleichen Register ungültig sind. In einer Ausführungsform weisen die Register 720 eine Registeranordnung auf, um Informationen bezüglich aller Signale von Interesse zu halten, wie es von einem Entwerfer entschieden wurde oder später durch einen Hersteller aktualisiert wurde. Ferner können die Register 720 als Ringpuffer mit einer Tiefe von N (wobei N eine positive Ganzzahl ist) implementiert sein, so dass eine letzte Menge von N Einträgen erfasst werden wird, um eine Identifizierung von Problemen in letzten N Leistungszustandsübergängen zu ermöglichen.
Um ein noch spezifischeres illustratives Beispiel bereitzustellen, wird im Folgenden angenommen, dass das Rücksetzsignal der Leistungssteuerungseinheit (sig. 11) erfasst/überwacht werden soll. Dabei startet ein Einschaltsignal den Bootprozess. Und eine Einrichtung, wie beispielsweise der PCH 605, beginnt einzuschalten. Es ist zu beachten, dass die Register 720 auf einen Standardwert initialisiert werden können. In Antwort auf das Einschaltsignal oder einen anderen Übergang eines frühen Startsignals beginnt der Zähler 725 zu zählen. Wenn sig. 11 übergeht, wird die Pulserzeugungslogik 710, welche auch eine Kantendetektionslogik (nicht gezeigt) für sig. 11 aufweisen kann, dazu veranlasst, einen Puls zu erzeugen. Im Ergebnis wird ein Bitmuster, welches sig. 11 (das Rücksetzsignal der Leistungssteuerungseinheit) identifiziert, in das Signalnamensfeld 735 gespeichert. Es ist zu beachten, dass auch andere Informationen gespeichert werden können, wie beispielsweise ein Bit, welches die Richtung des Übergangs anzeigt. Zusätzlich zum Aktualisieren des Signalnamensfeldes wird der Wert des Zählers 725 (ein Zeitstempel) in das Zeitstempelfeld 730 gespeichert. Und das Statusfeld 740 wird auf einen gültigen Wert gesetzt, wie beispielsweise einen logisch hohen Wert, um anzuzeigen, dass die in dem Signalnamensfeld 735 und dem Zeitstempelfeld 730 gehaltenen Werte gültig sind.
Der Prozess kann dabei für Übergänge weiterer Signale wiederholt werden. Und wie oben angegeben wurde, kann eine Ringpufferorganisation verwendet werden, um Informationen für so viele Leistungszustandsübergänge wie die Tiefe des Ringpuffers vorzuhalten. Darüber hinaus fährt der Zähler 725, wenn ein Signalübergang erfasst wird, in einem Beispiel fort, zu zählen (ein absoluter Zeitstempel vom Zählbeginn). Und in einem anderen Beispiel wird der Zähler 725 zurückgesetzt (ein relativer Zeitstempel von einem vorangehenden Signalübergang). Ferner hält die Erfassungslogik 700 wie oben erwähnt das Erfassen von Signalinformuationen bei einem vorbestimmten Ereignis an, wie beispielsweise einem letzten Signalübergang oder einem Fehlen eines letzten Signalübergangs nach einer Zeitspanne (ein potentielles Aufhängen oder „Hängenbleiber”-Szenario).
Nachdem die Erfassung vollständig ist, können die Register 720 in einer Ausführungsform ausgelesen werden (d. h. die Signalinformationen sind sichtbar, um jede beliebige notwendige Fehlerbereinigung auf deren Signalübergangen oder deren Fehlen auszuführen). In einer Ausführungsform wird in einem Legacy-System ein Legacy-Testzugriffsanschluss zum physikalischen Verbinden und Auslesen der Registerinformationen verwendet. In einem illustrativen Beispiel ist ein solches Auslesen nicht maskiert oder durch Absicherungen ausgeschlossen und kann jederzeit durchgeführt werden, nachdem ein Manageability-Engine oder ein Testanschluss aktiviert wurde. In einer anderen Ausführungsform wird durch eine Validierungsarchitektur (wie sie hierin beschrieben ist) ein Zugriff auf die Register 720 bereitgestellt und gesteuert. Zum Beispiel stellt eine Validierungssteuereinheit (VCU) potentiell einen abstrahierten und sicheren Zugriff auf die Register bereit. Software ist dabei dazu in der Lage, die Informationen anzufordern, indem eine API verwendet wird. Und die VCU ist dazu in der Lage, die Informationen aus den Registern 720 auszulesen und sie der anfordernden Software zur Verfügung zu stellen. Es ist zu beachten, dass – wie hierin beschrieben ist – entweder anstelle der Register 720 oder in Kombination damit erfasste Informationen in einem Systemspeicher untergebracht werden können, wie oben in Bezug auf das Verwenden von Systemspeicher als Spurpuffer für ein ODLA beschrieben wurde.
Es ist wichtig anzumerken, dass sich die obige Diskussion primär auf das Erfassen von Spuren für Signale innerhalb eines Controller-Hubs während eines Einschaltens konzentriert hat. Die hierin beschriebene Vorrichtung und das hierin beschriebene Verfahren zum Erfassen von frühen Signalspuren sind jedoch in dieser Hinsicht nicht eingeschränkt. Tatsächlich können sie auf ähnliche Weise für jede Siliziumeinrichtung verwendet werden, bevor ein Testmodul für die Einrichtung aktiviert/bereit ist. Zum Beispiel kann eine ähnliche Vorrichtung in einem Prozessor 640 oder einem eingebetteten Prozessor in einer Einrichtung mit kleinem Formfaktor implementiert sein, um Signalinformationen zu erfassen, bevor eine damit verknüpfte Test-/Fehlerbereinigungs-Einheit aktiviert wird.
Unter Bezugnahme auf 8 ist eine Ausführungsform eines Flussdiagramms für ein Verfahren zum frühzeitigen Erfassen von Signalinformationen in einer Einschaltsequenz dargestellt. In dem Fluss 805 tritt ein Einschaltereignis auf. Ein Einschaltereignis kann so einfach sein wie ein Feststellen des Vorliegen (oder Nichtvorliegens) eines Leistungssignals. Doch in einem anderen Beispiel geschieht die Erfassung in Antwort auf das Einschaltsignal, aber stützt sich auf einen eingreifenden Signalübergang, um tatsächlich mit dem Erfassen von Informationen zu beginnen. Zum Beispiel kann ein internes Signal für einen Controller-Hub in Antwort auf das Einschaltsignal übergehen. Und das Erfassen von Signalinformationen beginnt in direkter Antwort auf das eingreifende interne Signal. Das Einschaltereignis kann dabei das Leistungssignal, den Übergang des internen Signals oder beide umfassen.
In dem Fluss 810 werden frühe Einschaltsignalinformationen (Informationen bezüglich Signalen, welche übergehen, bevor eine Testeinheit aktiviert wird) erfasst. Wie oben angegeben ist, kann jede beliebige bekannte Vorrichtung oder jedes beliebige bekannte Verfahren verwendet werden, um solche Informationen zu erfassen. Zum Beispiel kann ein vereinfachter ODLA verwendet werden, welcher voreingestellt ist, um Informationen bei einem Leistungsereignis zu erfassen. Als ein anderes Beispiel kann eine Erfassungslogik, wie sie oben beschrieben ist, verwendet werden. Unabhängig von der Vorrichtung und dem Verfahren wird die Erfassung in dem Fluss 815 beim Auftreten einer vorbestimmten Bedingung, wie beispielsweise nach einer Zeitspanne/einer Anzahl Zyklen, einer Zeitspanne ohne das Detektieren eines Übergangs eines oder mehrerer Signale von Interesse, wenn ein letztes Signal von Interesse übergeht, wenn ein letztes Signal von Interesse nicht nach einer Zeitspanne übergeht, wenn eine spezifische Quelle aktiviert wird, wenn eine Testlogik aktiviert wird, wenn ein Programm anzeigt, dass das Erfassen stoppen soll, oder bei jedem beliebigen anderen bekannten vorbestimmten Boot-up-Ereignis angehalten/gestoppt werden.
In dem Fluss 820 wird ein Testanschluss verfügbar. Zum Beispiel wird ein Testzugriffsanschluss eines Manageability-Engines während des Boot-Prozesses aktiviert. Als ein anderes illustratives Beispiel wird eine VCU gemeinsam mit einem Universalzugriffsanschluss aktiviert, wie es unten beschrieben ist. Wenn der Testanschluss aktiviert ist, können die in dem Fluss 810 erfassten Signalinformationen ausgelesen werden, was auf sichere Weise mittels einer Abstraktionsschicht oder direkt an eine Testeinrichtung geschehen kann. Und Software oder ein Fehlerbereiniger sind dazu in der Lage, festzustellen, ob Probleme oder Problematiken aufgetreten sind. In der Folge können Signale, welche früh in einem Boot-Prozess übergehen, wie beispielsweise bevor eine Logik, welche normalerweise eine Sichtbarkeit für interne Signale ermöglicht, aktiviert wird, überwacht und effizient von Fehlern bereinigt werden, ohne dass große Kosten oder Aufwand im Vergleich zu vorhergehenden Fehlerbereinigungsversuchen ohne solche integrierten Hardwarehaken hinzugefügt werden.
Zusätzlich zu DFx-Merkmalen zum Erfassen von frühen Einschaltsignalen wie oben beschrieben, sind in einer Ausführungsform Haken umfasst, um Signalspuren in einer Ultra-Niedrigleistungsdomäne zu erfassen. In Bezug auf 9 ist eine Ausführungsform einer illustrativen Logik zum Erfassen von Signalen von Interesse in Niedrigleistungszuständen illustriert.
Leistungszustände werden oft produktspezifisch definiert; dennoch bezeichnet ein Leistungszustand in einer Ausführungsform jeden beliebigen Zustand mit verschiedenen Leistungsspezifikationen wie beispielsweise eine Spezifikation von Leistungszuständen eines Advanced Configuration and Power Interface (ACPI). Für Prozessoren definiert die ACPI-Spezifikation drei Basiszustände: C0 (ein arbeitender/aktiver Zustand); C1 (bekannt als Halt, wobei Instruktionen nicht ausgeführt werden, aber zu einem ausführenden Zustand zurückkehren können); C2 (bekannt als Takt-Stop, wobei ein für Software sichtbarer Zustand aufrechterhalten wird, aber ein Aufwachen länger dauern kann) und C3 (bekannt als Schlaf, wobei der Prozessor seinen Cache nicht kohärent hält, aber einen anderen Zustand aufrechterhalten kann). Zusätzlich wurden Variationen an diesen Zuständen durchgeführt. Zum Beispiel kann ein verbesserter C1-Zustand für einen niedrigeren Leistungsverbrauch verwendet werden. Und Variationen von C3/Schlaf können Zustände eines tieferen Schlafes aufweisen (d. h. C6 kann ein tieferer oder tiefster Schlafzustand sein), welche eine längere Zeit zum Aufwecken eines Verarbeitungselements erfordern. Es ist zu beachten, dass diese Leistungszustände rein illustrativ sind und primär in Bezug auf einen Prozessor verwendet werden. Ähnliche Zustände werden von der ACPI-Spezifikation jedoch für andere Einrichtungen, wie beispielsweise einen Controller-Hub definiert.
Wie dargestellt ist, weist die Einrichtung 900, welche einen Prozessor, einen Controller-Hub, eine Grafik-Einrichtung oder eine andere computerbezogene Einrichtung aufweisen kann, eine Logik zum Erfassen von Signalen von Interesse 901–906 während eines Niedrigleistungszustandes (d. h. jedem beliebigen Zustand, welcher in dem Beispiel oben ein nichtarbeitender C0-Zustand ist) auf. Die erste Stufe der Logik (Live-Erfassung 920) erfasst Spuren/Werte der Signale 901–906 live. Zum Beispiel illustriert das Zeitdiagramm 970 die Erfassung des Signals 906 basierend auf dem Taktsignal 910. Es ist zu beachten, dass ein Aktivierungssignal, wie beispielsweise eine Fehlerbereinigungsaktivierung, auch verwendet werden kann, um den Takt 910 (d. h. den Gate-Takt 910 für die Flop-Stufen 920, 930) zu behindern, wenn kein Fehlerbereinigungsmodus vorliegt. Und wie gesehen werden kann, erfasst die zweite Stufe (gespeicherte Werte 930) den Live-Status der Signale 901–906, wenn ein Schaltzyklus initiiert wird, wie es durch das Leistungszyklussignal 925 angezeigt wird. Zum Beispiel kann in einem PCH ein Leistungszyklussignal in Antwort auf das Feststellen des Vorliegens (oder Nichtvorliegens) eines spezifischen vordefinierten Pins generiert werden. In einer Nicht-Boot-Situation schaltet ein Validierungsingenieur dabei den Pin, um das System neu zu booten. Daher wird in diesem Szenario eine jüngste Version/der jüngste Status der Signale 901–906 erfasst und gespeichert. Es ist zu beachten, dass die gespeicherten Werte 930 in dem gezeigten Beispiel bei einem erfolgreichen Boot einen Status 950 der Signale 901–906 während einer jüngsten Fehl-Boot-Bedingung halten, wie in dem Zeitdiagramm 970 dargestellt ist.
Um ein spezifisches Beispiel zum Illustrieren des Betriebs der Logik 900 bereitzustellen, wird angenommen, dass fünf Boot-Vorgänge einer Einrichtung/eines Systems 900 versucht werden. Bei dem ersten Boot-Vorgang wird ein Aktivierungsbit gesetzt, um die Logik scharf zu schalten. Ein Legacy-JTAG oder andere Testschnittstellen können dabei verwendet werden, um das Aktivierungsbit zu setzen. In einer anderen Ausführungsform setzt eine VCU das Aktivierungsbit. Unter der Annahme, dass der erste Boot-Vorgang erfolgreich ist, wird das Leistungszyklussignal 925 auf Niedrig gefahren, so dass der Status der Signale 901–906 erfasst wird. Bei einem zweiten erfolgreichen Boot-Vorgang zeigt ein Status nur einen logischen Wert an (ein vorhergehender erfolgreicher Boot-Vorgang und das Aktivierungsbit bleibt scharf geschaltet). Bei einem dritten Boot-Vorgang, welcher nicht erfolgreich ist, wird das System dennoch neu gestartet. Das Leistungszyklussignal wird dabei geschaltet, wie beispielsweise von Hoch auf Niedrig auf Hoch geschaltet, und der Status der Signale 901–906 wird erfasst, wenn das Leistungszyklussignal 925 auf Niedrig gefahren wird. Unter der Annahme eines vierten Boot-Vorgangs, welcher auch nicht erfolgreich ist, wird das System auf die gleiche Weise neu gestartet. Und bei einem nachfolgenden fünften, erfolgreichen Boot-Vorgang berichtet der Status 950 die Spur/den Status der Signale 901–906 für den jüngsten nicht erfolgreichen Boot-Versuch (Boot-Versuch vier). Wie oben beschrieben ist, kann der Status 950 durch eine Legacy-Testausrüstung ausgelesen werden. Oder in einer anderen Ausführungsform wird eine VCU, welche eine geschichtete Testarchitektur implementiert, verwendet, um einen Zugriff auf die Logik 900 bereitzustellen und zu kontrollieren.
Ein großer Teil der obigen Beschreibung bezog sich auf das Erfassen von Validierungsinformationen für Prozessoren; Einiges davon konzentrierte sich auf das Erfassen von Zuständen von Signalen für einen Controller-Hub, wie beispielsweise einen PCH. DFx-Haken sind in dieser Beziehung jedoch nicht eingeschränkt, da sie auf anderen Gebieten und überall auf der Plattform implementiert sein können. Ein anderes Gebiet, welches oben kurz erwähnt wurde, ist das Bereitstellen von Hardware-Haken zum Testen, zur Validierung und zum Fehlerbereinigen von mit Leistung verknüpfter Hardware und Leistungsstromversorgungsnetzwerken. Zum Beispiel kann eine Frequenzschrittlogik oder eine Logik zum Messen einer Spannung über die Zeit dazu in der Lage sein, ein Stromversorgungsnetz zu charakterisieren (ein Impedanzprofil zu definieren und/oder eine Resonanzfrequenz zu bestimmen). Oder eine Messlogik kann durch einen Spannungsregler (VR) auf einem Motherboard eingefügt werden, um ein Maß von Strombedarf, Leistungsverbrauch, Rauschen, etc. zu messen.
Zusätzlich ist die DFx- und Validierungsarchitektur, welche hierin beschrieben ist, nicht auf eine Laborvalidierung beschränkt. DFx-Merkmale können dabei in Prozessoren, Controller-Hubs, Motherboards oder andere Einrichtungen zum Ankoppeln an eine Serienfertigungs-(HVM)-Testausrüstung integriert sein. Im Ergebnis kann jeder bekannte HVM-Test über den Universalzugangsanschluss, wie unten beschrieben, geleitet werden. Und als Hersteller gibt jede beliebige sichere, geschichtete Validierungsarchitektur in einer Ausführungsform den Herstellungstestern den größten Sicherheitsabstand (d. h. Zugriff auf die meisten oder alle der eingeschlossenen DFx-Merkmale auf niedriger Ebene).
Als eine Folge des Bereitstellens einer Testarchitektur über Produkte hinweg können Herstellungsfehler über die Produkte (cross-product validation) wie beispielsweise Prozessoren, Motherboards, etc. hinweg diagnostiziert werden. Fehler und Versetzungen können durch das Bereitstellen von Testergebnissen durch die geschichtete Testarchitektur nach oben zur Erfassung durch Software über mehrere Produkte leicht bestimmbar sein. Zum Beispiel können tausende von Prozessoren durch ein HVM mit Zugriff auf DFx durch die VCU und eine geschichtete Testarchitektur getestet werden. Und weil die Ergebnisse in der Software-/Präsentationsschicht gesammelt werden, ist die Software dazu in der Lage, die Informationen als präsentierbare Informationen, wie beispielsweise Versetzungen, Fehler usw. zu formulieren.
Als ein anderes Beispiel basieren vorhergehende Motherboard-Diagnoseverfahren auf Tests einer Schaltkarte, welche an mehreren auf der Schaltkarte befindlichen Testpunkten mit dedizierten, externen Testern in einer Schaltung abgegriffen werden (in-circuit probed test – ICT). Da die Formfaktoren geschrumpft sind und die Kosten für Testpunkte stark angestiegen sind, ist es schwierig geworden, ICT weiterhin zu unterstützen. Als ein Ergebnis wird die hierin beschriebene Testarchitektur in einer Ausführungsform, wie beispielsweise eine VCU und bereitgestellte APIs für Software auf höherer Ebene, dazu verwendet, eine verständliche Diagnose über mehrere Einrichtungen hinweg bereitzustellen.
Als ein Ergebnis können vorhergehende Rückläufe von Einrichtungen, wie beispielsweise Prozessoren und Chipsätzen, welche keine Fehler aufweisen, aber aufgrund von Motherboard-Fehlern zurückkommen („kein-Fehler-gefunden”-Rückläufer) vermieden werden, indem diese elegante, einfache Lösung ohne ICT-Notwendigkeit bereitgestellt wird. Zum Beispiel können soviel wie 30% der Testkosten reduziert werden, indem DFx integriert wird und eine Unterstützung (Zugriff und Steuerung) der DFx durch eine VCU und APIs bereitgestellt wird, anstatt dass externe ICT-Vorrichtungen benutzt werden müssen.
Ausführungsformen eines Validierungscontrollers
In einer Ausführungsform ist eine Validierungssteuereinheit (VCU) vorgesehen, um eine Steuerung von DFx-Merkmalen, wie z. B. die hierin beschriebenen Hardware-Test-, Validierungs- und Fehlerbereinigungshaken, und einen Zugriff hierauf zur Verfügung zu stellen. Eine VCU kann jede beliebige Hardware, Firmware, Software, jeden beliebigen Code, Mikrocode oder eine Kombination davon aufweisen, um eine solche Steuerung und/oder einen solchen Zugriff zu implementieren. Mit Bezug auf 10 ist eine Ausführungsform einer illustrativen Plattform mit einer oder mehreren VCUs dargestellt. Wie dargestellt umfasst die Plattform 1000 mehrere VCUs; eine in dem Prozessor 1010 und eine in dem Prozessor 1075. In diesem Szenario können VCUs in mehreren Einrichtungen (Prozessoren, Controller-Hubs, Grafikeinrichtungen, einem Motherboard oder einer anderen bekannten Computereinrichtung) enthalten sein. Als Ergebnis kann jede für einen Zugriff auf ihre jeweiligen Silizium-DFx-Merkmale und die Steuerung davon verantwortlich sein. Eine VCU, wie beispielsweise die VCU 1012, ist dabei in jedem Prozessor enthalten, so dass sie dazu in der Lage ist, einen Zugriff auf und eine Steuerung für die DFx-Merkmale (architekturelle und mikroarchitekturelle DFx 1015, ODLA 103 und PCU 1014) des Prozessors 1010 zur Verfügung zu stellen. Es ist zu beachten, dass diese Verteilung auf mehrere Siliziumeinrichtungen innerhalb der Plattform 1000 möglicherweise einen Zugriff auf DFx-Merkmale und eine Steuerung davon während eines Testens einzelner Bauteile (z. B. einem HVM-Testen einzelner Bauteile) und während eines Plattformtestens/einer Plattformfehlerbereinigung (z. B. mehrerer Bauteile, welche in eine Plattform integriert sind, wobei eine Analyse des gesamten Systems sowie einer Leistung einzelner Bauteile in dem System nützlich sein können) ermöglicht.
In einem Beispiel sind die VCUs bei einer solch verteilten VCU-Implementierung dazu in der Lage, miteinander zu kommunizieren. Eine solche Kommunikation kann direkt erfolgen, wie z. B. über eine VCU-Verbindung (nicht gezeigt), welche die VCUs 1012 und 1080 in der Plattform 1000 miteinander koppelt. Alternativ können die VCUs, wie beispielsweise die VCU 1012 und die VCU 1080 über existierende Verbindungen (Verbindung 1065, welche ein direct media interface (DMI), eine Quickpath-Schnittstelle, eine PCI-E-Schnittstelle, oder eine andere bekannte Verbindung aufweisen kann), welche ihre entsprechenden Einrichtungen (Prozessor 1010 und PCH 1075) miteinander koppelt, kommunizieren. Als eine andere Alternative können die VCUs miteinander über einen geteilten Speicherraum kommunizieren. Zum Beispiel schreibt die VCU 1012 auf einen Speicherbereich 1021, welcher für ein Betriebssystem verdeckt ist, aber für andere Systemeinrichtungen sichtbar ist, beispielsweise für die PCH 1075/VCU 1080. Als Ergebnis ist die VCU 1080 dazu in der Lage, die durch die VCU 1012 geschriebenen Informationen zu lesen und umgekehrt.
Als ein spezifisches illustratives Beispiel wird eine Verbindung/Kommunikation zwischen VCUs verwendet, um einen Softwarezugriff auf DFx-Merkmale überall in der Plattform zu koordinieren, wenn ein vereinheitlichter Anschluss für den Zugriff auf die Validierungsarchitektur, wie in größerem Detail unten beschrieben ist, zur Verfügung gestellt wird. Zusätzlich können andere Probleme durch eine Kommunikation zwischen VCUs und/oder Manageability-Engines detektiert und angegangen werden, wie beispielsweise Livelock, Deadlock, Patch Load Synchronisierung, Leistungs-/Leistungsfähigkeitszustandsübergangssynchronisierung, Survivability, Auslöse- und Spurkonfigurierung, Speicherung von Daten nach dem Sammeln, Sicherheit und Erfassungs-/Berichtabdeckung.
Obwohl sich die obige Diskussion primär auf eine Verteilung einer VCU in jedem Bauteil, wie beispielsweise einem Prozessor, einem Controller-Hub und einem Motherboard konzentriert hat, ist eine solche Verteilung nicht erforderlich. Alternativ ist eine einzelne VCU in einer Einrichtung, wie beispielsweise dem Prozessor 1010 oder dem PCH 1075, enthalten. Und sie steuert einen Zugriff auf ihre DFx-Haken sowie auf die DFx-Haken der Plattform. Darüber hinaus müssen die VCUs nicht symmetrisch sein, wenn eine verteilte VCU-Implementierung verwendet wird. In diesem Fall können sich Siliziumbauteile unterscheiden, und ebenso die VCUs. Zusätzlich können eine oder mehrere VCUs eine höhere Priorität (z. B. ein Head-Home oder eine Master-VCU zum Koordinieren eines Zugriffs und einer Steuerung durch andere VCUs in dem System) aufweisen. Alternativ kann jede VCU als ein Kommunikations-Master betrachtet werden.
In einer Ausführungsform weist die VCU 1012 einen programmierbaren Engine oder eine programmierbare Einheit zum Steuern des Zugriffs auf DFx-Merkmale des Prozessors 1010 auf. Zum Beispiel weist die VCU 1012 einen Microcontroller auf. Ein Microcontroller umfasst oft eine Einrichtung, welche ihr eigenes Verarbeitungselement, ihren eigenen Speicher (Flash, programmierbarer ROM, SRAM oder andere bekannte Speichereinrichtungen) und ihre eigene Kommunikationsschnittstelle aufweist. Im Wesentlichen kann er als ein kleiner, eingebetteter oder selbstständiger Computer innerhalb des Prozessors 1000 betrachtet werden. Er kann daher seinen eigenen Code/Mikrocode halten, um seine Schnittstelle nach oben zu Software einer höheren Ebene und nach unten zu DFx-Merkmalen zu implementieren, wenn er durch sein Verarbeitungselement ausgeführt wird. Darüber hinaus kann der Microcontroller, wie in größerem Detail unten beschrieben ist, aktualisiert werden (sein Steuer- oder Betriebscode, welcher in seinem Speicher gehalten wird, kann mit einem Patch, wie beispielsweise einem authentifizierten Patch versehen oder aktualisiert werden), um eine neue Funktionalität zum Anpassen an Änderungen in anderen Schichten (Software oder DFx-Merkmale) einer Test-Validierungsarchitektur zur Verfügung zu stellen. Folgerichtig können Veränderungen an den DFx-Merkmalen der Plattform oder einer Software einer höheren Ebene durchgeführt werden, und die VCU ist dazu in der Lage, sich ohne ein Austauschen von Hardware (oder eines ganzen Bauteils) anzupassen.
Es ist zu beachten, dass die Beschreibung einer VCU, welche einen Microcontroller aufweist, rein illustrativ ist. Stattdessen können ähnliche Einrichtungen eine ähnliche Steuerung eines Zugriffs auf DFx-Merkmale durchführen und eine ähnliche Schnittstelle zu Schichten einer höheren Ebene zur Verfügung stellen. Zum Beispiel können programmierbare Logikeinrichtungen, wie beispielsweise programmierbare Array-Logikeinrichtungen, generische Array-Logikeinrichtungen, komplexe programmierbare Logikeinrichtungen, Feld-programmierbare Gate-Array-Einrichtungen usw. verwendet werden. Zusätzlich ist die VCU 1012 als einzelner logischer Block in dem Prozessor 1010 dargestellt. Dennoch können, so wie auch ein ODLA über dem Prozessor 1010 verteilt sein kann, Bauteile der VCU 1012 über verschiedene Abschnitte eines Chips oder Packages des Prozessors 1010 verteilt sein.
Ein illustratives Beispiel für eine Interaktion der VCU 1012 mit einigen DFx-Merkmalen ist unmittelbar hierunter enthalten, um die Diskussion voranzubringen. Dabei hat die VCU 1012 Zugriff auf Kanäle in einer auf dem Kern befindlichen Schnittstelle 1011, wie beispielsweise einen Nachrichtenkanal, welcher an Steuerregister des Prozessors 1010 gekoppelt ist. Zusätzlich hat die VCU 1012 Zugriff auf Scan-Signale, wie beispielsweise Scan-Out-Signale und Absicherungen. Im Ergebnis ist die VCU 1012 dazu in der Lage, verschiedene Mikrohaltepunkt-Triggerereignisse (ein Szenario) zu programmieren, den ODLA 1013 anzuweisen, Spuren in dem Speicher 1020 (oder einen Bereich des Speichers 1021, welcher von dem Betriebssystem abgesondert ist) zu speichern, Spuren, welche in dem Speicher 1020 gespeichert sind, zu extrahieren und Spuren an Software einer höheren Ebene (z. B. ein Fehlerbereinigungs-Tool) zu liefern. Zusätzlich ist die VCU 1010 dazu in der Lage, zu steuern, auf welche DFx-Merkmale basierend auf einem aktuellen Sicherheits-(Entsperr)-Niveau zugegriffen werden kann. Und in einer Ausführungsform zeigt die VCU 1010 einer API an, dass Merkmale dazu in der Lage sind, für einen Zugriff auf die DFx-Merkmale des Prozessors 1010 programmiert zu werden.
In einer Ausführungsform ist die VCU 1012 dafür verantwortlich, eine oder mehrere Schichten der geschichteten Validierungsarchitektur, wie sie unten beschrieben ist, zu implementieren, wie beispielsweise eine Abstraktionsschicht, um Hardwaredetails von DFx-Merkmalen vor Software einer höheren Ebene zu abstrahieren oder zu verdecken. Ferner ist die VCU 1012 in einer Ausführungsform, unabhängig davon, ob eine Abstraktionsschicht verwendet wird oder nicht, für einen abgesicherten Zugriff auf DFx-Merkmale verantwortlich, wie unten in dem Abschnitt zu Ausführungsformen einer Validierungsinfrastruktursicherheit beschrieben ist.
Mit Bezug auf 11 ist eine Ausführungsform eines Flussdiagramms für ein Verfahren zum Bedienen einer DFx-Anforderung von einer Software unter Verwendung einer VCU illustriert. In dem Fluss 1105 wird eine DFx-Anforderung gemäß einer Applikationsprogrammierschnittstelle (API) in Antwort auf das Ausführen eines Softwareprogramms, wie beispielsweise eines Test- und Fehlerbereinigungsprogramms von einem Drittanbieter generiert. Dabei kann die DFx-Anforderung mit der Spezifikation der API und Regeln, welche zum Interagieren mit den von einer VCU bereitgestellten Diensten und Routinen bereitgestellt sind, übereinstimmen. Mit anderen Worten kann das Software-Programm geschrieben sein, um mit dem durch die API spezifizierten „Vokabular” übereinzustimmen, wie beispielsweise Benennungskonventionen, welche von der API erkannt werden.
In dem Fluss 1110 wird die DFx-Anforderung mit der API, welche durch die VCU implementiert ist, interpretiert. Dabei arbeitet die API als eine Schnittstelle oder ein Moderator zwischen Software und Dfx-Hardware. Als ein Beispiel wird in der VCU gespeicherter Code, wie beispielsweise in einem Speicher eines VCU-Microcontrollers gespeicherter Code, in Antwort auf die DFx-Anforderung ausgeführt. In diesem Szenario kann der in der VCU gespeicherte Code Bibliotheken, Routinen, Datenstrukturen, Objektklassen, Protokolle usw. aufweisen. Dabei wird angenommen, dass die DFx-Anforderung einen Aufruf an eine Routine in der VCU enthält, welcher dazu dient, eine Ausführung der Routine auf der VCU zu bewirken, um eine Funktion/einen Betrieb, welcher mit der DFx-Hardware verknüpft ist, durchzuführen.
In einer Ausführungsform dient eine VCU dazu, auf DFx-Hardware (Sicherheit) zuzugreifen, wie unten in größerem Detail beschrieben ist. Daher wird in dem Fluss 1115 bestimmt, ob die DFx-Anforderung basierend auf einem Sicherheitsniveau erlaubt ist. Obwohl die Sicherheit in größerem Detail unten beschrieben ist, wird an dieser Stelle ein vereinfachtes Beispiel zur Verfügung gestellt, um mit dem illustrativen Betrieb eine VCU fortzusetzen. Als ein Beispiel kann eine VCU eine Anzahl von Niveaus von sicherem Zugriff aufweisen; jede davon erlaubt verschiedene Niveaus von Zugriff auf Hardware-DFx. Zum Beispiel kann jedes Niveau mit einem verschlüsselten Passcode verknüpft sein. Wenn das Softwareprogramm mit der Ausführung beginnt, kann es also einen sicheren Passcode zur Verfügung stellen, um sein Sicherheitsniveau, welches angibt, auf welche Merkmale das Softwareprogramm zugreifen kann, zu entsperren. Daher wird in dem Fluss 1115 gemäß dem durch die VCU vordefinierten Zugriffsniveau bestimmt, ob die DFx-Anforderung innerhalb des mit dem Softwareprogramm verknüpften Sicherheitsniveaus gewährbar ist. Falls die DFx-Anforderung nicht erlaubt wird, kann sie in dem Fluss 1120 entsprechend gehandhabt (verweigert, nicht ausgeführt, eine Ausnahme ausgebend, usw.) werden.
Wenn die DFx-Anforderung andernfalls erlaubt wird, wird die DFx-Anforderung dann in dem Fluss 1125 bedient. Unter Fortsetzung des obigen Beispiels, in welchem die DFx-Anforderung einen Aufruf einer durch die API definierten Dienstroutine aufweist, führt die VCU dann die Dienstroutine aus. Dabei kann die Dienstroutine eine beliebige Routine zum Einstellen, Initiieren oder Interagieren mit Hardware-DFx-Merkmalen, wie oben beschrieben, aufweisen. Zum Beispiel kann die VCU Mikrohaltepunkt-Triggerereignisse einstellen, welche bewirken, dass ein Prozessor auf die Triggerereignisse trifft, und dass ein ODLA Spuren an dem Haltepunkt erfasst. Die Ergebnisse (Spuren) können dann in dem Fluss 1130 extrahiert werden, wie beispielsweise nach außen in einen Speicher geschrieben werden, welcher von dem ODLA als ein Spurpuffer verwendet wird. Und die Ergebnisse werden in dem Fluss 1135 dem Softwareprogramm zur Verfügung gestellt. In diesem Szenario ist das Softwareprogramm dazu in der Lage, den Speicher auszulesen, um die Spurinformationen für eine spätere Interpretation/Fehlerbereinigung zu erhalten.
Unter Bezug auf 12 wird eine Veränderung an einer Testarchitektur in dem Fluss 1205 festgestellt. Eine Veränderung kann jede beliebige Veränderung innerhalb jeder beliebigen Schicht der Architektur, wie beispielsweise eine Veränderung an einer DFx-Hardware, eine durchzuführende Veränderung daran, wie eine VCU mit einer anderen VCU interagiert, eine Veränderung daran, wie eine VCU mit DFx-Hardware interagiert, eine Veränderung in einem durch eine VCU bereitgestellten Dienst, eine Veränderung in Sicherheitsniveaus (worauf sie jeweils einen Zugriff erlauben), eine Veränderung in der API-Spezifikation, etc. umfassen. Und in dem Fluss 1210 wird die VCU aktualisiert, um die Veränderung an der Testarchitektur zu berücksichtigen. Hierbei kann ein Patch, ein authentifizierter Patch oder eine Aktualisierung entweder lokal oder aus der Ferne angewandt werden, um einen VCU-Code zu aktualisieren, um die Veränderung zu berücksichtigen. Im Ergebnis muss ein Hersteller, wenn sich etwas auf der VCU-Ebene oder in dem geschichteten Stapel darunter verändert, nur eine Aktualisierung an der VCU-Software bereitstellen. Und da in diesem Beispiel nur die API für eine Software höherer Ebene freigelegt ist, müssen Drittanbieter ihre Softwareprogramme oder Werkzeuge nicht aktualisieren. Stattdessen bleibt die API dieselbe, aber die Wirkung der VCU wird basierend auf der Aktualisierung modifiziert, um die Veränderung an der Testarchitektur zu berücksichtigen. In der Folge werden potentiell sowohl Ausgaben (Kosten für ein Neuentwerfen oder Ersetzen von Hardware) und Zeit gespart, indem nicht alle Ebenen eines Stapels modifiziert werden müssen, wenn eine kleine Veränderung an dem Testarchitekturstapel vorliegt.
Ausführungsformen einer geschichteten Validierungsarchitektur
Wie oben erwähnt, ist die Test-, Validierungs- und Fehlerbereinigungsarchitektur in einer Ausführungsform in einem geschichteten Stapel implementiert. Eine Ausführungsform eines geschichteten Stapels für eine Testarchitektur ist in 13 dargestellt. Es ist zu beachten, dass die dargestellten Schichten rein illustrativ sind. Und andere Schichten können miteinbezogen sein, während jede beliebige der dargestellten Schichten ausgelassen sein kann. Darüber hinaus sind auch Beispiele von Logik, wie beispielsweise eine VCU, zum Implementieren einer oder mehrerer der dargestellten Schichten, wie beispielsweise der Abstraktionsschicht 1315 auch illustrativ, da die Schichten in Logik, Hardware, Firmware, Code, Mikrocode, Software oder einer Kombination davon implementiert sein können.
In einer Ausführungsform dient der Stapel 1300 dazu, Implementierungsdetails der Hardware-DFx zu verdecken. Dabei wird eine Abstraktionsschicht 1315 (eine Dienstschicht) bereitgestellt, um solche Hardware-DFx-Details zu abstrahieren, während eine Schnittstelle für eine Client-Schicht (Applikationsschicht 1320 und Präsentationsschicht 1325) zur Verfügung gestellt wird. Wie dargestellt ist, umfasst die für die Applikationsschicht 1320 zur Verfügung gestellte Schnittstelle mehrere APIs (API 1316, 1317 und 1318).
Eine API bezeichnet typischerweise eine bestimmte Menge von Regeln und Spezifikationen, welche eine Softwareschicht, wie beispielsweise die Applikationsschicht 1320, befolgen muss, um auf dadurch zur Verfügung gestellte Dienste zuzugreifen und diese zu verwenden. Im Wesentlichen stellt sie eine Schnittstelle zwischen verschiedenen Schichten (von Software, Firmware oder Hardware) zur Verfügung und ermöglicht ihre Interaktion. Auf eine API kann durch die Schichten 1320 und 1325 zugegriffen werden, welche Konsolen, Werkzeuge, Software, Betriebssysteme, Bibliotheken, Applikationen oder eine andere bekannte Struktur, welche zum Ankoppeln an oder zum Programmieren mit einer API in der Lage ist, umfassen können. Als ein spezifisches illustratives Beispiel weist eine API Spezifikationen für Dienste, Routinen, Funktionen, Datenstrukturen, eine Objektklasse, Protokolle oder andere bekannte API-bezogene Konstrukte auf.
Obwohl eine API verwendet werden kann, werden in der dargestellten Ausführungsform verschiedene APIs zum Zugriff auf verschiedene durch die Abstraktionsschicht 1315 bereitgestellte Dienste, Routinen und Datenstrukturen zur Verfügung gestellt. Zum Beispiel kann/können die API(s) 1316 Kerndienste und Datenstrukturen zur Verfügung stellen, welche dem Verwenden durch die Applikationsschicht 1320 zur Sicherheit (wie in größerem Detail unten beschrieben ist) und zur Abstraktion von Details niedrigerer Ebene verwendet werden, was möglicherweise einen verringerten Generationswerkzeugumsatz bewirkt (Verwendung der gleichen Werkzeuge zum Ankoppeln an die gleichen APIs auf einem Prozessor einer nächsten Generation mit anderen Diensten der Abstraktionsschicht 1315 und/oder anderen DFx-Merkmalen.
Zusätzlich können andere APIs, wie beispielsweise APIs 1317 und 1318, andere Dienste, Datenstrukturen und Abstraktionen zur Verfügung stellen. Als ein Beispiel ist Hardware-DFx nicht die einzige Abstraktion, welche durch die Schicht 1315 zur Verfügung gestellt wird. Dabei stellen die APIs 1317 und 1318 Dienste und Datenstrukturen, welche mit elektrischer Validierung (EV), Stromversorgung, Manageability, Sicherheit, Zugriff oder anderen bekannten Test-, Validierungs- oder Fehlerbereinigungs-bezogenen Säulen verknüpft sind, zur Verfügung. Zuvor waren Hersteller abwehrend in Bezug auf gewisse Algorithmen, wie beispielsweise Algorithmen zur elektrischen Validierung (EV), welche dazu dienen, von Werkzeugen, die in der Clientschicht residieren, verwendet zu werden. Also werden die Algorithmen aktuell nicht zur Verfügung gestellt oder nur eine Teilmenge davon wird zur Verfügung gestellt, wodurch es oft zu minderwertigen Anbieterwerkzeugen zur EV kommt.
In der Folge weist die API 1317 in einer Ausführungsform eine oder mehrere EV-Säulen-APIs auf, um eine Abstraktion einer vollständigen Menge solcher Algorithmen zum Verwenden durch Werkzeuge/Software auf Schichten 1320, 1325 höherer Ebene bereitzustellen. Die Algorithmen können daher auf eine sichere Weise zur Verfügung gestellt werden (nicht sichtbar für TPV-Werkzeuge), woraus sich bessere TPV-Test-Werkzeuge ergeben, während beliebige geheime Algorithmen geheim und abstrahiert bleiben. Es ist zu beachten, dass das Beispiel einer EV-spezifischen API-Säule auf jede beliebige einzelne Test-, Validierungs- und/oder Fehlerbereinigungs-bezogene API-Säule extrapoliert werden kann, welche dazu dient, Hardware, Firmware, Software, Code, Algorithmen, Protokolle usw. zu abstrahieren. Darüber hinaus erlaubt das Bereitstellen von säulenspezifischen API-Dienstmodulen, wie sie dargestellt sind, potentiell einfachere, modulare Aktualisierungen. Zum Beispiel wird, wenn etwas, das mit EV verknüpft ist, modifiziert werden soll, eine Aktualisierung, wie beispielsweise ein Patch von in einem VCU-Microcontroller gespeichertem EV-Code, welcher eine EV-API 1317 implementiert, potentiell durchgeführt, ohne dass Kerndienste oder andere API-Module aktualisiert werden müssen.
In den obigen Beispielen wurde ein Bezug auf eine Schnittstelle zwischen der Abstraktionsschicht 1315 und der Client-Schicht (Applikationsschicht 1320 und Präsentationsschicht 1325) primär in Bezug auf APIs beschrieben. Es kann jedoch jede beliebige andere bekannte Vorrichtung oder jedes beliebige andere bekannte Verfahren zum Bereitstellen einer Schnittstelle verwendet werden, welche bzw. welches Details einer niedrigen Ebene von einer niedrigeren Ebene verdeckt, abstrahiert oder verschleiert, wie beispielsweise Hardware oder in Software/Hardware implementierte Algorithmen. Zusätzlich ist ein Beispiel einer Abstraktionsschicht 1315 durch einen VCU-Microcontroller implementiert, wie oben erwähnt. Dabei sind Logik und/oder Code, um die APIs 1316–1318 zu implementierten, in einer VCU enthalten, wie beispielsweise ein in einer Speichereinrichtung des VCU-Microcontrollers gespeicherter Code. In einer anderen Ausführungsform werden der Code, die Dienste und die Datenstrukturen, um die APIs für die Abstraktionsschicht 1315 zu implementieren, in einem Speicher gehalten und durch die Einrichtung im Test, wie beispielsweise einen Prozessor im Test, ausgeführt.
Wie gezeigt ist, umfasst die unterste Ebene in dem Stapel die Ziel-DFx-Schicht 1305, welche jedes beliebige bekannte DFx-Merkmal aufweisen kann, wie beispielsweise die oben beschriebenen Hardware-Merkmale/-Haken. Zusätzlich kann die DFx-Schicht 1305 auch Legacy-Test/-Validierungsmerkmale aufweisen. Und im Ergebnis kann der direkte Zugriff 1350 in einigen Ausführungsformen einen direkte Zugriff auf einige der Hardware-DFx-Merkmale in der Schicht 1305 gestatten. Als weiteres Beispiel weist die Ziel-DFX-Schicht 1305 eine Einheit im Test auf, welche einen Prozessor, einen PCH, eine Grafikvorrichtung, ein Motherboard oder eine andere elektronische Vorrichtung umfassen kann.
Die Transportschicht 1310 dient dazu, eine Kommunikation, wie beispielsweise Aufgaben von den durch die Abstraktionsschicht 1315 bereitgestellten Diensten und Routinen, welche transportunabhängig (d. h. ohne Kenntnis dessen, wie die Dienste/Routinen zu der DFX-Schicht 1305 transportiert werden) sind, anzupassen, so dass sie auf einem spezifischen Transportvehikel laufen. Zum Beispiel weist die Transportschicht 1310 eine Transporthardware und verknüpfte Treiber auf, um eine Kommunikation von der Abstraktionsschicht 1315 zu nehmen und in angemessene Pakete/Informationen für einen Transport zu der Schicht 1305 anzupassen. Dabei kann das Transportmedium eine Zwischenverbindung innerhalb einer Plattform, eine Zwischenverbindung, welche eine Konsole/einen Tester mit einer Plattform oder einer Einrichtung durch einen Anschluss koppelt, ein Netzwerk für einen Fernzugriff zwischen der Schicht 1315 auf einer Host-Maschine und der Schicht 1305 auf einer entfernten Einheit im Test oder eine andere bekannte testbezogene Einrichtung, wie z. B. eine In-Target-Probe(ITP)-Einrichtung, einen definierten Fehlerbereinigungsanschluss, eine Drittanbieter-(TPV)-Transporteinrichtung umfassen.
Wie aus dem Netzwerkbeispiel abgeleitet werden kann, können eine oder mehrere Schichten des Stapels 1300 auf verschiedenen Maschinen und/oder Komponenten implementiert sein. Zum Beispiel kann die Zielschicht 1305 eine Plattform im Test aufweisen, welche mit einer Hostplattform fernverbunden ist, die eine oder mehrere Schichten des Restes des Stapels implementiert. Als ein weiteres Beispiel ist eine Client-Schicht auf einem Hostsystem implementiert, welches aus der Ferne auf ein Bauteil oder eine Plattform im Test zugreift, welche die Dienstschicht und die Zielschicht 1305 implementiert. Der Fernzugriff wird im größeren Detail unten bei den Ausführungsformen eines Validierungsarchitekturzugriffs beschrieben.
Eine Client-Schicht kann ein beliebiges Werkzeug, eine beliebige Konsole, Applikation oder andere Größe zum Ankoppeln an DFx-Merkmale in der Zielschicht 1305 und/oder der Abstraktionsschicht 1315, welche dem Abstrahieren von Details einer niedrigen Ebene der DFx-Schicht 1305 dient, umfassen. Wenn die Schnittstelle mit der Abstraktionsschicht 1315 durch eine oder mehrere APIs, wie beispielsweise die APIs 1316–1318 verläuft, ist die Applikations-Schicht 1320 dazu ausgelegt, eine Schnittstelle mit den APIs gemäß deren Spezifikationen und Regeln inklusive der Regel und Spezifikationen säulenspezifischer API-Module zu bilden/zu programmieren. Ferner müssen die Clientschicht-Werkzeuge, wie oben angegeben ist, selbst wenn Produkte einer neuen Generation zur Verfügung gestellt werden, nicht durch neuere Versionen ausgetauscht werden, solange die API-Kommunikationsspezifikation zwischen Client-Schichten und der Abstraktionsschicht 1315 gleich bleibt. Statt dessen wird die Abstraktionsschicht aktualisiert, um die gleichen Dienste auf eine neue Weise mit Bezug auf das neue Produkt (Ziel-DFx-Schicht 1305) zur Verfügung zu stellen. Ferner können Drittanbieter-Legacy- und Nicht-Dienst-Applikationen mit Herstellersicherheiten in eine oder mehrere Werkzeuglösungen innerhalb der Client-Schicht integriert werden.
Die Präsentationsschicht kann mit einem Werkzeug oder einer separaten Funktionseinheit integriert sein, welche dazu dient, zugrundeliegende Daten und Protokolle zu korrelieren, zu visualisieren und/oder zu präsentieren. Im Ergebnis können diese Werkzeuge durch und mit der Präferenz von Drittanbietern ausgelegt sein, um Endergebnisse des DFx-Testens auf jede beliebige von ihnen gewählte Weise zu formulieren. In diesem Beispiel dient die Applikationsschicht 1320 dazu, die Abstraktionsschicht 1315 unter Verwendung von darin zur Verfügung gestellten Diensten und Routinen zu programmieren. Ergebnisse dieser Dienste und Routinen, wie beispielsweise Ergebnisse eines Testens in der Schicht 1305 oder eine Ausgabe von Algorithmen, welche in der Schicht 1315 beheimatet sind, werden nach oben an die Applikationsschicht 1325 gegeben. Die Applikationsschicht gibt diese Daten an die Präsentationsschicht weiter, welche die Daten interpretiert (von Fehlern bereinigt) und für eine Interpretation durch einen Menschen oder ein weiteres Werkzeug präsentiert.
Mit Bezug auf 14 ist eine Ausführungsform eines Flussdiagramms für ein Verfahren zum Zugreifen auf DFx-Merkmale durch einen geschichteten Architekturstapel illustriert. In dem Fluss 1405 programmiert eine Applikation, wie beispielsweise ein Drittanbieter-Werkzeug eine Abstraktionsschicht. Hierbei verlangt/verwendet ein Werkzeug oder eine andere Funktionseinheit Dienste einer Abstraktionsschicht, wie es durch eine mit der Abstraktionsschicht verknüpfte API definiert ist. Und solche Dienste werden in dem Fluss 1410 zur Verfügung gestellt. Wenn der Dienst einen lokalen Algorithmus innerhalb einer Applikationsschicht umfasst, ist zu beachten, dass die Information/Datenstruktur zurück an die Applikationsschicht geliefert werden kann.
Wenn auf der anderen Seite der Dienst eine Abwärtskommunikation mit DFx-Merkmalen oder einer Zieleinrichtung im Test umfasst, dann wird die Kommunikation von dem transportunabhängigen Stapel höherer Ebene (die Abstraktionsschicht und die Applikationsschicht) in dem Fluss 1415 angepasst, um transportiert zu werden. Zum Beispiel kann die Anpassung ein Formatieren von Informationen von der Abstraktionsschicht in ein Transportprotokoll wie beispielsweise ein Testanschlussprotokoll, ein Zwischenverbindungsprotokoll, ein Netzwerkprotokoll oder ein Internetprotokoll umfassen. In dem Fluss 1420 wird die angepasste Form von Kommunikation an eine DFx-Einheit im Test transportiert, welche die durch die Abstraktionsschicht angeforderten Operationen durchführt. Es ist zu beachten, dass jede beliebige bekannte DFx-Operation, wie z. B. die oben Beschriebene, durchgeführt werden kann. Die Ergebnisse können dann, in dem Fluss 1425 zurück, der Applikation bereitgestellt werden und durch eine Präsentationsschicht in dem Fluss 1430 interpretiert werden.
Ein übliches Beispiel von oben fortsetzend, um den Fluss zu illustrieren, wird angenommen, dass ein Test- und Fehlerbereinigungswerkzeug verlangt, dass ein Mikrohaltepunkt in eine Einheit im Test, wie beispielsweise einen Prozessor, programmiert wird, und dass Spuren bis zu dem, bei dem oder nach dem Mikrohaltepunkt erfasst werden. In diesem Beispiel kann die Applikation einen durch die Applikationsschicht bereitgestellten Dienst aufrufen (Fluss 1405). Die Abstraktionsschicht führt die aufgerufene Dienstroutine aus, welche das Übertragen einer Mikrohaltepunktdefinition und von Spurerfassungsanweisungen in dem Stapel nach unten umfasst (Fluss 1410). Die Transportschicht passt die Mikrohaltepunktdefinition und Spurerfassung aus dem Transport an, so dass sie in Pakete, welche dem Transport durch einen Testanschluss dienen, geformt werden (Fluss 1415). Die formulierten Pakete werden dann an den Prozessor übertragen (Fluss 1420). Als Antwort wird der Mikrohaltepunkt in Steuerregistern des Prozessors gesetzt und die Spurinformationen werden wie verlangt erfasst. Dabei kann das Zurückgeben von Daten einen Rücklauf nach oben in dem Stapel zurück an die Applikation umfassen, wie beispielsweise durch eine Abstraktionsschicht (Fluss 1425). Als weiteres Beispiel können die Spurinformationen in einem Speicher gespeichert werden, welcher als ein Spurpuffer verwendet wird. Und die Applikation ist dazu in der Lage, die Spurinformationen aus dem Speicher zurückzulesen (Fluss 1425). Mit den Spurinformationen ist ein Präsentationswerkzeug dazu in der Lage, die Prozessorspuren in einer Simulation wieder zu erzeugen, um die Daten zu interpretieren (Fluss 1430). Es ist zu beachten, dass die Zugänglichkeit von Merkmalen unterhalb der Abstraktionsschicht gesichert sein kann, d. h., dass Zugriffsanforderungen von der Applikation auf Merkmale, welche nicht entsperrt sind oder jenseits des Sicherheits-/Privilegniveaus der Applikation sind, verweigert werden können. Solche potentiellen Sicherheitsverbesserungen werden direkt im Anschluss diskutiert.
Sicherheitsausführungsformen für eine Validierungsarchitektur
Wie oben erwähnt ist, umfasst ein potentielles Ziel einer Test-, Validierungs- und Fehlerbereinigungsarchitektur ein Abstrahieren von Details niedriger Ebene, welche ein Designer oder Hersteller nicht freilegen möchte. Eine reine Abstraktion oder Verdeckung solcher Details kann in einer Ausführungsform jedoch nicht genügend „Sicherheit” darstellen. Wenn nur eine Abstraktionsschicht verwendet wurde, könnte jeder, einschließlich eines Endnutzers, dazu in der Lage sein, auf die Testarchitektur zuzugreifen, wenn sie feststellten, wie mit den APIs der Abstraktionsschicht kommuniziert werden kann. Im Ergebnis wird der Zugriff auf die Testarchitektur in einer Ausführungsform gesichert, d. h. Anforderungen von Schichten höherer Ebenen, welche nicht autorisiert sind, werden nicht erlaubt.
15 illustriert eine Ausführungsform von Logik, um einen sicheren Zugriff auf eine Testarchitektur zur Verfügung zu stellen. Dabei umfasst eine Applikation oder Konsole 1515, welche jede beliebige der oben bezüglich einer Applikations- oder Präsentationsschicht beschriebenen Funktionseinheiten umfassen kann, einen Passcode 1520. Der Passcode 1520, welcher auch als Schlüssel bezeichnet werden kann, umfasst ein beliebiges bekanntes Format von Wert, welches dazu dient, einen sicheren oder sperrenden Zugriff auf ein Merkmal oder ein Zugriffsniveau zur Verfügung zu stellen. Entweder bei einer anfänglichen Interaktion oder anschließend bei einer Anforderung stellt die Applikation 1515 ihren Passcode 1520 einer Abstraktionsschicht über eine Schnittstelle 1530, wie beispielsweise eine durch VCU 1507 implementierte API-Schnittstelle, zur Verfügung. Es ist zu beachten, dass die Topologie der Applikation 1515 als logisch von der UUT 1505 getrennt nur illustrativ ist. Statt dessen kann die UUT 1505 die Applikation ausführen. Oder die VCU 1507 kann in der Einrichtung 1515 implementiert sein, welche in diesem Szenario als Hostsystem/-konsole aufgefasst wird, welche(s) auf die UUT 1505 zugreift.
Wenn die Abstraktionsschicht den Passcode 1520 empfängt, stellt sie unabhängig von der physikalischen Implementierung der Anwendung 1515 basierend auf dem Applikationspasscode im Vergleich mit einem in dem Speicherelement 1510, wie beispielsweise einem allgemeinen Register, einem Steuerregister oder einem modellspezifischen Register (MSR) der UUT 1505, gespeicherten Passcode ein Maß an Zugriff zur Verfügung. Als ein Beispiel ist nur ein Zugriffsniveau vorhanden (vollständiger Zugriff oder kein Zugriff). Wenn der Applikationspasscode 1520 mit einem in dem Speicherelement 1510 gespeicherten Passcode übereinstimmt, kann die Applikation 1520 alle zur Verfügung gestellten Dienste (Zugriff auf verknüpfte DFx-Merkmale) einer durch die VCU 1507 implementierten Abstraktionsschicht verwenden. Alternativ werden, wenn kein Passcode bereitgestellt wird oder falls er nicht passt, Anforderungen von der Applikation 1515 an die Abstraktionsschicht nicht bedient/erlaubt.
Allerdings werden in einer Ausführungsform mehrere Niveaus von Sicherheit zur Verfügung gestellt. Zum Beispiel kann es ein Designer wünschen, dass verschiedene Kunden oder Anbieter verschiedene Zugriffsniveaus auf Algorithmen, Protokolle, Datenstrukturen, DFx-Merkmale, etc. haben. Tatsächlich kann ein Designer/Hersteller für sich selbst einen ungehinderten Zugriff auf die Details einer niedrigen Ebene von DFx-Merkmalen bereitstellen, welche eine Abstraktionsschicht für sowohl Test, Validierung und Fehlerbereinigung der DFx-Merkmale als auch die verknüpfte UUT verdecken soll. Auf ähnliche Weise kann ein Designer/Hersteller für sich selbst einen vollständigen Zugriff innerhalb der Abstraktionsschicht vorsehen.
In der gezeigten Ausführungsform dienen das/die Speicherelement(e) 15c dazu, drei Niveaus von Passcodes zu halten. Ein Passcode (Passcode 1511) ist ein Herstellerpasscode, welcher einen Zugriff des Niveaus 0 (ungestörter oder nicht sehr eingeschränkter) Zugriff auf DFx-Merkmale zur Verfügung stellt. Ein zweites Niveau (Niveau 1), welches durch den Passcode 1512 dargestellt ist, das einen selektiven/eingeschränkten Zugriff auf die Testarchitektur zur Verfügung stellt. Und ein N-tes Niveau, das durch den Passcode 1513 dargestellt ist, das einen noch selektiver eingeschränkten Zugriff auf die Testarchitektur bereitstellt. Dabei kann jeder der Passcodes sicher zur Verfügung gestellt werden, so wie beispielsweise der Passcode 1512 an einen Drittanbieter (TBV). Im Ergebnis können sie, wenn sie ein TPV-Werkzeug entwerfen, den Passcode 1512 als Passcode 1520 integrieren oder verwenden. Wenn die Applikation 1515 durch einen Authentifizierungsprozess geht (den Passcode 1520 einer Abstraktions- oder Sicherheitsschicht, welche durch die VTU 1507 implementiert ist, zur Verfügung stellt), wird ihr daher ein Zugriff des Niveaus 1 auf die Testarchitektur zur Verfügung gestellt. In diesem Fall ist der Zugriff des Niveaus 1 beschränkt. Also wird ein Zugriff von der Applikation 1515, der nicht innerhalb ihres Sicherheitsniveaus liegt (ein Zugriff auf ein DFx-Merkmal oder ein Implementierungsdetail, welches eingeschränkt ist), von der VCU 1507 verweigert (nicht erlaubt).
Unter Bezugnahme auf 16 ist eine Ausführungsform eines Flussdiagramms zum Bereitstellen eines sicheren Zugriffs in einer Testarchitektur illustriert. In dem Fluss 1605 wird ein Zugriffsniveau einer Applikation bestimmt. In einer Ausführungsform wird ein beliebiger bekannter Authentifizierungsprozess verwendet, um die Applikation mit einem Zugriffsniveau für eine Testarchitektur zu verknüpfen. In einem anderen Beispiel wird ein Passcode-Verifizierungsprozess, wie er oben beschrieben ist, verwendet, um das Zugriffsniveau der Applikation festzustellen. Es ist zu beachten, dass das Feststellen am Anfang des Ausführens der Applikation (eine allgemeine Authentifizierung für das Programm an seinem Beginn) durchgeführt werden kann oder auf eine spezifische Anforderung hin durchgeführt werden kann.
In dem Fluss 1610 wird eine Dienstanforderung durch die Applikation an eine API der Abstraktionsschicht geliefert. Dabei ist die Dienstanforderung an die API rein illustrativ, da die Anforderung eine beliebige Dienstanforderung oder einen beliebigen versuchten Zugriff auf DFx-Merkmale umfassen kann. Unabhängig von dem Typ oder Format der Anforderung wird in dem Fluss 1615 bestimmt, ob der angeforderte Dienst basierend auf dem festgestellten Zugriffsniveau erlaubt ist. In diesem Szenario sind bestimmte Dienste, Algorithmen, Protokolle, DFx-Merkmale, etc. als erlaubbar oder gemäß definierten Sicherheitszugriffsniveaus eingeschränkt vordefiniert. Wenn die Anforderung mit einem Zugriffsniveau der Applikation (oder einem Niveau mit mehr Zugriff) assoziiert ist, wird daher die Anforderung in dem Fluss 1625 erlaubt und (wenn Teil des Dienstes) an eine DFx-Einheit im Test in dem Fluss 1630 transportiert. Wenn im Gegenteil die Anforderung nicht innerhalb des Zugriffsniveaus der Applikation liegt, wird sie in dem Fluss 1620 nicht erlaubt.
Ausführungsformen von physikalischem Zugriff auf eine Validierungsarchitektur
Zuvor war ein Zugriff auf Hardware-Testmerkmale über mehrere disjunkte, unverbundene Anschlüsse, welche über eine Computerplattform verstreut waren, verteilt. Dies machte die Verbindungen zum Testen einer Plattform sowohl mühsam als auch aufwendig (verschiedene Anschlüsse und Werkzeuge zum Verbinden mit diesen Anschlüssen). Daher wird in einer Ausführungsform ein universeller Testzugriffsanschluss (UTAP) zum Ersetzen mehrerer Plattform-Testschnittstellen zur Verfügung gestellt. Mit Bezug auf 17 ist eine Ausführungsform für einen UTAP für eine Testarchitektur in einer Plattform dargestellt.
Die Prozessoren 170a–d umfassen einen beliebigen bekannten Prozessor und sind über Zwischenverbindungen 1750, wie beispielsweise eine Quickpath-Verbindung, verbunden, während der PCH 1770 an den Prozessor 1710c über eine Zwischenverbindung 1765, wie beispielsweise ein Direct Media Interface (DMI), gekoppelt ist. Wie dargestellt ist, sind die VCUs 1712a–e dazu in der Lage, auf der Zwischenverbindung 1790, wie beispielsweise einer Testzwischenverbindung oder einer anderen bekannten Schnittstelle, zu kommunizieren. Aber wie oben angegeben wurde, sind die VCUs in einer anderen Ausführungsform dazu in der Lage, über die Zwischenverbindung 1750, 1765 zu kommunizieren. Folgerichtig sind die VCUs 1712a–e in diesem Szenario dazu eingerichtet, miteinander zu kommunizieren, wodurch ein Zugriff auf VCU-Testmerkmale der Plattform 1700 über einen einzigen, vereinheitlichten Anschluss, wie beispielsweise den UTAP 1785 ermöglicht wird. Dabei sind die VCUs 1712a–e dazu in der Lage, kooperativ miteinander zu interagieren. Oder sie sind zumindest dazu in der Lage, Nachrichten von dem UTAP 1785 an die passende, beabsichtigte VCU zu leiten.
In einer Ausführungsform umfasst der UTAP 1785 einen bidirektionalen Anschluss, um Fehlerbereinigungsinformationen (von mit dem Prozessor verknüpftem Speicher oder zurück von den VCUs) zu extrahieren und mit den VCUs 1712a–e zu kommunizieren. Als ein Beispiel umfasst die UTAP 1785 einen dedizierten Testanschluss. In einer anderen Ausfülvungsform ist die UTAP 1785 huckepack auf einer anderen Schnittstelle, wie beispielsweise einer vorhandenen Schnittstelle (z. B. einer Universal Serial Bus(USB)-Schnittstelle, einer Serial Advanced Technology Attachment(SATA)-Schnittstelle oder einer anderen bekannten Schnittstelle) oder einer zukünftigen Schnittstelle, welche doppelt verwendet wird, angeordnet.
Es ist zu beachten, dass die dargestellte Topologie rein illustrativ ist. Jede beliebige Anzahl von Prozessoren kann umfasst sein. Und ein PCH muss nicht umfasst sein. Zusätzlich kann der UTAP 1785 einen physikalischen Anschluss umfassen, welcher dazu dient, an eine externe Einrichtung gekoppelt zu werden, wie beispielsweise eine Konsole, einen Computer oder einen Tester. Als ein weiteres Beispiel stellt der UTAP eine Netzwerkschnittstelleneinrichtung (z. B. ein NIC) oder einen Controller zum Kommunizieren mit einem Host oder einem entfernten System (Fernzugriff ist unten in größeren Detail beschrieben) dar. Dabei kann der Controller einen Baseboardmanagementcontroller (einen eingebetteten Microcontroller, welcher auf einem Motherboard eingebettet ist, welcher Systemparameter (z. B. Temperatur, Gebläsegeschwindigkeit, Leistungsstatus, etc.) berichten kann) umfassen und kann auch eine Fernkommunikation mit der Plattform 1700 ermöglichen.
Das Bereitstellen eines universellen Testanschlusses vereinfacht möglicherweise (sowohl in Bezug auf Aufwand als auch Komplexität) ein Testen einer Plattform. Dennoch können aktuelle Testorte für einzelne Bauteile, wie beispielsweise Prozessoren, Ineffizienzen umfassen. Zum Beispiel weisen Prozessoren typischerweise Test- und Validierungspins auf ihrer „Unterseite” auf, welche in Bezug auf Pins oft limitiert ist, wodurch sich ein größeres Package-Substrat und größere Kosten ergeben. Um solche Kosten zu verringern, lassen Kunden zunehmend Test- und Fehlerbereinigungshaken weg. Wenn ein Kunde nicht dazu in der Lage ist, ein Bauteil von Fehlern zu bereinigen, kann es im Ergebnis ein irrtümlicher Rückläufer an den Hersteller werden.
Daher werden in einer Ausführungsform unbestückte Flächen auf einer Oberfläche eines Package-Substrats einer integrierten Schaltung (IC) (z. B. Prozessoren, Controllerhubs etc.), wie z. B. auf dem Umfang des Substrats dazu verwendet, einige oder alle zur Verwendung beim Testen und bei der Validierung vorgesehene Pins zu platzieren. Zum Beispiel werden diese Pins in die äußere Metallschicht des Package-Substrats geätzt und durch das Lötabdeckmittel exponiert.
Bezugnehmend auf 18 ist eine Ausführungsform eines Packages einer integrierten Schaltung in einem beispielhaften Großserienfertigungsverbindungsmechanismus dargestellt. In diesem Beispiel umfasst der IC ein CPU-Package 1860, welches auf der Oberseite Test- und Fehlerbereinigungspins 1865 umfasst. Diese Pins sind dazu in der Lage, abhängig von dem in Verbindung stehenden Verwendungsfall auf eine Vielzahl von Weisen verbunden zu werden. In einem Validierungs- oder Fehlerbehebungsverwendungsfall kann auf sie u. a. unter Verwendung eines kompressionsartigen Verbindermechanismus zugegriffen werden, welcher Ausrichtungsmerkmale umfassen kann, welche den Verbinder direkt mit dem Package-Substrat ausrichten, wodurch die bestmöglichen Toleranzen erreicht werden können und die Pin-Merkmalgrößen und das Verbindungssystem so klein wie möglich gemacht werden können. Es ist zu beachten, dass diese Merkmale oft kompatible, reziproke Merkmale in dem Sockel 1850 umfassen, um einen Oberseitenverbinder dazu in die Lage zu versetzen, einen Kontakt mit einem Substrat des IC 1860 herzustellen.
Das dargestellte Verbindungsszenario, wie beispielsweise ein HVM-Verbindungsszenario, umfasst eine Greifgelenkbefestigung 1820, um IC-Verrichtungssonden 1835, wie beispielsweise POGO-Pin-artige Verbindungen mit Oberseiten-Pins 1865 zu verbinden. Und die IC-Vorrichtungssondendrähte 1810 verbinden die Vorrichtungssonden 1835 mit einer Konsole/einem Tester 1805. Im Ergebnis erlaubt es das Greifgelenk 1820, dass der Verbindungsmechanismus geöffnet werden kann, ein neues Bauteil eingeführt werden kann und durch das Schließen des Gelenks 1820 wird die Verbindung zwischen dem Tester 1805 und Oberseitentest-/Fehlerbereinigungspins 1865 hergestellt. In verschiedenen Testverwendungsfällen in der Großserienfertigung, in welchen erwartet wird, dass die Rate für die Kopplung an diese Gehäuseoberseitenpins minimal akzeptable „Schlagfrequenzen” einhält, würde das Verbindungsverfahren dazu tendieren, eine Art von automatisierten und/oder hocheffizienten Mechanismen zu verwenden, wie in 18 dargestellt ist.
Ebenfalls dargestellt ist eine ähnliche Verbindung mit einem Motherboard 1840, wobei Motherboard-Vorrichtungsdrähte 1823 einen Tester 1805 mit MB-Vorrichtungssonden 1825 verbinden. Zusätzlich ist auch eine Basissonde 1830 dargestellt, um eine Basis des Motherboards 1840 zu berühren. Es ist zu beachten, dass das Beispiel eines Greifgelenks 1820 rein illustrativ ist und dass jedes beliebige bekannte Verbindungsszenario für Sonden, Tester, Sockel, HVM-Werkzeuge, etc. verwendet werden kann. Darüber hinaus können ähnliche Mechanismen für andere ICs, wie beispielsweise einen Controller-Hub oder ein Peripheriegerät verwendet werden.
18 zeigt auch einen integrierten Wärmespreizer, auch Integrated Heat Spreader (IHS) 1870 genannt, welcher in einer Ausführungsform dazu ausgelegt ist, einen Raum für Oberseitenpins 1865 und eine Verbindung dazu mittels Vorrichtungssonden 1835 zu erlauben. Bezugnehmend auf 19 ist eine Ausführungsform eines Wärmespreizers mit einem diskreten Lademerkmal zum Unterstützen von Oberseitentestpins und einem Sondieren dargestellt. Dabei ist eine integrierte Schaltung 1905 auf einem Gehäuse 1907 mit einem IHS 1910 verknüpft. In einer Ausführungsform umfasst der IHS 1910 vorstehende „Lastohren” 1911. In der Darstellung stellen die Lastohren 1911 Sockelaktuierungslastpunkte für aktivierte Sockellastmechanismen, wie beispielsweise einen Direct-Socket-Loading-(DSL)-Mechanismus 1920 bereit. Das Verwenden eines derartigen Designs ergibt möglicherweise ein weniger besetztes Oberseitenareal, wodurch mehr Raum für Signalpin-Pads zur Validierung, wie oben beschrieben, ermöglicht wird.
Außerhalb der Lastohren 1911 kann der Umfang des IHS 1910 eine kleinere kontinuierliche oder diskontinuierliche Stufe entlang der Kante des IHS 1910 aufweisen. Als weitere Alternative kann die Kante keine Stufe aufweisen. Wenn die Ohren 1911 beladen sind, wird das Gehäuse 1907 wie gezeigt auf den Sockel gedrückt, wodurch der Sockel betätigt wird und eine elektrische Verbindung zwischen dem Sockel und dem Einrichtungsgehäuse forciert wird. Es ist zu beachten, dass die Anzahl von Ohren (dargestellt als zwei, aber nicht darauf beschränkt) auf einer Anzahl von Belastungspunkten für eine bestimmte Applikation abhängt. Darüber hinaus befinden sich die Ohren 1911 unter (z. B. unmittelbar unter) den Belastungspunkten einer gegebenen Applikation und müssen sich nicht in der Mitte des IHS 1910 befinden. Dennoch wird der Ort der Ohren 1911 oft typischerweise (nicht immer) derart sein, dass die von dem Belastungsmechanismus auf den IHS 1910 ausgeübten Kräfte in einer Betätigungskraft resultieren, welche hinreichend ist, um den IHS 1910/das Zentrum des Gehäuses 1907 zu schließen. In einer Ausführungsform haben die Lastohren 1910 eine gewisse Länge, um eine vollständige Belastungszone eines Belastungsmechanismus abzudecken. Zum Beispiel befinden sich die vorgeschlagenen IHS-Ohren in einem Längenbereich von 1 mm bis 50 mm, um die Lastlänge einer DSL-Lastplatte 1920 abzudecken. Es ist zu beachten, dass ein IHS-Abdichtungsmittel während der Montage des IHS 1910 unter die Ohren 1911 gebracht werden kann, um die Belastungskraft auf das Gehäuse 1907 zu übertragen, ohne die Ohren 1911 zu verbiegen.
Im Ergebnis hat ein vorheriger typischer IHS eine Laststufe um etwa 90% eines Umfangs, um zu gewährleisten, dass eine hinreichend verteilte Last den Sockel betätigt, um eine elektrische Verbindung zu forcieren. Durch das Bereitstellen von Lastohren wie oben beschrieben kann der gleiche Belastungsprozess jedoch mit einem reduzierten Kantenstufenschritt erreicht werden, wodurch mehr Raum auf einer Oberseite eines ICs für Test-/Fehlerbereinigungs-Pinout und -sondierung ermöglicht wird. Zusätzlich kann der IHS 1910, um mehr Raum zu ermöglichen, eine selektiv gebildete Lage mit diskreten Lastohren 1911 aufweisen, welche sich dort befinden, wo die Last hauptsächlich auf den IHS 1910 aufgebracht wird. Zum Beispiel kontaktiert die DSL-Lastplatte 1920 einen kleinen Bereich der Stufe des IHS 1910. Die Ohren 1911 sind daher strategisch dort platziert, wo die DSL-Platte 1920 die Last platziert. Folgerichtig können die neuen Oberseitentestpins durch den nunmehr freigemachten Raum einbezogen werden, ohne eine Gehäusegröße zu erhöhen oder ein Gebiet des IHS 1910 zur thermischen Ableitung zu verringern.
In einer mit Wärmeableitung im Zusammenhang stehenden Materie sind aktuelle thermische Margining-Werkzeuge extrem groß, wodurch eine größere Flächennutzung und reduzierte Signalintegritätsmargins hervorgerufen werden. Daher ist mit Bezug auf 20 eine Ausführungsform einer Explosionsdarstellung eines Designs eines thermischen Werkzeugs mit kleinem Formfaktor (Small Form Factor Thermal Tool – SFFTT) zum thermischen Margining dargestellt. Es ist zu beachten, dass ein solches Margining in einigen Ausführungsformen als ein DFx-Merkmal betrachtet werden kann. Dabei weist das SFFTT 2000 ein oder mehrere der folgenden Merkmale auf: eine maßgefertigte Coldplate 2010, welche an den Boden des Mini-Bulk-Thermoelektrischen-Cooler-(TEC)-Arrays 2025 gelötet ist; einen Wasserkühler 2040 mit Mikrokanal-Kühltechnologie, welcher über ein Flüssigmetallthermoschnittstellenmaterial (z. B. ein Ga-Sn-Flüssigmetallmaterial) an der Oberseite des Mini-Bulk-TEC-Arrays 2025 angebracht ist; ein einzigartiges Kanaldesign der Abdeckung des Wasserkühlers 2040, um eine gleichförmige Verteilung des Wasserflusses bereit zu stellen; Schlauchmaterial zum Einlassen und Auslassen (Einlass 2050 und Auslass 2060) von Wasser in der Mitte der Einrichtung; eine Drahtzeuganordnung für einen Controller; eine T-artige Thermokopplung, welche in einer Mitte der Coldplate 2010 integriert ist, um eine Temperaturrückkopplung für einen Controller bereitzustellen; Abstandshalter 2020 zwischen dem Wasserkühler 2040 und der Coldplate 2010, um TEC-Rissbildungsprobleme zu adressieren; ein Kabelmanagement des TEC 2025 unter Verwendung eines Breadboards 2035, um eine Drahtspannung zu mindern; und einen Temperaturschalter.
Derartige Merkmale stellen mögliche Vorteile für einen SFFTT dar. Zum Beispiel ist ein Wasserkühler 2040 mit einer Mikrokanalkühltechnologie potentiell effizienter als ein Diamantfinnentechnologiedesign. Und eine Platzierung des Einlasses und des Auslasses (250, 260) bei der Mitte des SFFTT 2000 zusammen mit einem einzigartigen Kanaldesign der Wasserkühlerabdeckung erlauben es dem Kaltfluss, aus der Mitte in den Wasserblock einzutreten, während das erhitzte Wasser zu den Seiten des Kühlers bewegt wird; diese Distanz ist nur die Hälfte der Kanallänge im Vergleich zu anderen diamantfeinen Stildesigns. Im Ergebnis befindet sich die kälteste Region in der Mitte, wo die Wärmekonzentration typischerweise aufgrund von durch den TEC 2025 und das Silizium-im-Test erzeugte Hitze am größten ist. Schließlich wird die Temperaturdifferenz über dem Wasserkühler potentiell um so viel wie 3°C reduziert und die Temperatur ist gleichmäßiger verteilt, so dass der Kühler eine verbesserte Zuverlässigkeit der TECs 2025 ergibt. Als weiteres Beispiel reduziert eine Anbringung der Coldplate 2010 an dem Mini-Bulk-TEC-Array 2025 potentiell eine oder mehrere Lagen von thermischem Widerstand. Darüber hinaus stellen die Abstandshalter 2020 zwischen dem Wasserkühler 2040 und der Coldplate 2010 einen Abfederungsmechanismus bereit, um Rissbildungsproblemen des TECs 2025, welche im Falle eines Bulk-TEC auftreten, vorzubeugen. Und ein Kabelmanagement unter Verwendung des Breadboards 2035 reduziert potentiell eine Drahtspannung sowie einen TEC-Leitfehler.

Um eine weitere Beschreibung bereitzustellen, werden einige illustrative Spezifikationen von oben beschriebenen Merkmalen hier diskutiert. Als ein erstes Beispiel umfasst das Mini-Bulk-TEC 2025 eine Fläche von bis zu 39 mm mal 39 mm bei einer maximal dissipierten Temperatur von 75° und einem Fußabdruck von bis zu 15 cm². Zusätzlich kann jede beliebige Anzahl von TECs in dem Array 2025 verbunden sein. Als ein illustratives Beispiel sind zwei Gruppen von 11 TECs in Reihe verbunden und zwei Gruppen von 11 TECs sind parallel verbunden. Zusätzlich stellt ein Mikrokanal-Finnendesign für den Wasserkühler 2040 vertikale (oder horizontale) Kühlkanäle bereit, anstelle eines zirkularen Kühlmusters einer Diamantenfinne. Und die Kanäle/Finnen können jede beliebige Größe aufweisen. Zum Beispiel können die Firmen eine Höhe von 2 mm und eine Breite von 0,3 mm aufweisen und um 0,3 mm voneinander beabstandet sein. Eine beispielhafte Simulation verschiedener Designs für den Wasserkühler 2040 ist unten in der Tabelle A bereitgestellt.

SFF LCTT mit neuem Wasserkühlerdesign (Vista Ridge)	Finnendicke/Kanalbreite (mm)	TDP (W)	Gehäusematerial	Kühlergröße (in mm × mm)	Kühlerhöhe (in mm)	niedrigstes Tcp (C) der Simulation
Mikrofannen (hohes Profil)	0,25/0,3	50	Blech	32 × 32	10	–12,3
Mikrofannen (hohes Profil)	0,25/0,3	50	Akryl	32 × 32	10	–11,2
Mikrofannen (niedriges Profil)	0,25/0,3	50	Blech	32 × 32	7	–10,4
Mikrofannen (niedriges Profil)	0,25/0,3	50	Akryl	32 × 32	7	–9,5

Tabelle A: Zusammenfassung der simulierten Leistung eines Wasserkühlers

Eine ähnliche Simulation zeigt eine stark verbesserte Geschwindigkeitsverteilung und Temperaturverteilung bei einer Mikrokanalwasserkühlertechnologie. Als Ergebnis dieser Fortschritte wird der SFFTT potentiell in der Größe um so viel wie 40%–50% im Vergleich zu vorherigen thermischen Margining-Einrichtungen reduziert, während immer noch ein vergleichbares Temperatur-Margining (z. B. 5°C–100°C) bereitgestellt wird. Darüber hinaus spart die Reduktion in dem Formfaktor auch möglicherweise Fläche auf einen Board und erhöht die Signalintegritäts-(SI)-Margins, indem es einem Chip ermöglicht wird, näher an einem nächsten Chip platziert zu sein. Eine Verbesserung bei den SI-Margins treibt auch einen Trend aller Marktsegmente in Richtung einer Miniaturisierung von Produkten. Ein einzigartiges Kanaldesign auf einer Wasserkühlerabdeckung stellt auch potentiell eine gleichförmige Wasserflussverteilung bereit, wodurch sich eine verbesserte TEC-Zuverlässigkeit ergibt. Darüber hinaus kann eine Fehlererkennung durch ein Isolieren von Fehlern und ein Verringern von Entkommensfällen als Teil von Nachsiliziumfehlerbereinigungs-/-validierungsaktivitäten von Herstellern und Anbietern beschleunigt werden. Und durch das Ermöglichen einer Temperatur-Margining-Fähigkeit für Anbieter kann eine Herstellung mit einem Wettbewerbsvorteil in der Leistung bereitgestellt werden. Es ist auch wert, bemerkt zu werden, dass Validierungsergebnisse von Anbietern auch Herstellern dabei helfen können, effizienter bei der elektrischen Validierung zu werden, wodurch möglicherweise eine Lieferung von endnutzerfreundlicheren Produkten ermöglicht wird.
Ausführungsformen eines Fernzugriffs auf eine Validierungsarchitektur
Zuvor verbrauchten Hersteller große Mengen von Ressourcen (Zeit, Personal und Geld), um Anbieter bei ihren Fehlerbereinigungsanstrengungen zu unterstützen. Tatsächlich sendeten Hersteller/Designer oft Validierungsingenieure zu Anbieterstandorten, wenn die Anbieter nicht dazu in der Lage waren, ihren eigenen Test und ihre eigene Fehlerbereinigung durchzuführen oder dabei auf Probleme stießen. Leider wird dieser Prozess, wenn die Komplexität von Bauteilen und Plattformen zunimmt, schwieriger für Anbieter und beschwerlicher für Hersteller. Folgerichtig ermöglicht eine Validierungsarchitektur in einer Ausführungsform einen Fernzugriff, um bei einem Test-, Validierungs- und/oder Fehlerbereinigungsprozess zu unterstützen.
Bezugnehmend auf 21 ist eine Ausführungsform eines Fernzugriffs auf eine Einheit im Test dargestellt. Wie oben ausgeführt ist, können Schichten eines Testarchitekturstapels über Maschinen (und Netzwerke) hinweg implementiert sein. Hier umfasst/implementiert ein entfernter Host 2105 Werkzeuge 2106 (eine Applikationsschicht mit Test-, Validierungs- und/oder Fehlerbereinigungswerkzeugen) und eine Abstraktionsschicht 2107, wie oben beschrieben ist. Eine Kommunikation von den Schichten 2106, 2017 wird über eine Schnittstelle 2130 bereitgestellt, welche jede beliebige bekannte Schnittstelle aufweisen kann, wie beispielsweise eine Fernschnittstelle, eine Netzwerkschnittstelle, eine Peripherieschnittstelle, etc.
In einer Ausführungsform wird eine solche Kommunikation gemäß einem beliebigen bekannten Verschlüsselungsalgorithmus 2150 verschlüsselt. Zusätzlich kann in einer anderen Ausführungsform eine VPN-Verschlüsselung 2110 bei dem Transport verwendet werden. In diesem Szenario ist der lokale Host 2115 (d. h. der auf eine beliebige Weise mit dem entfernten Host 2105 gekoppelte Host) dazu ausersehen, eine Transportschicht 2116 zum Anpassen von transportunabhängigen Schichten 2106, 2107 zum Transport zu einer Einheit im Test (UUT) 2120 zu implementieren. Daher können beliebige der oben beschriebenen Test-, Fehlerbereinigungs-, Validierungs- und Sicherheitsoperationen von einem entfernten Host zum Ankoppeln an eine Einheit im Test implementiert sein.
Kurz bezugnehmend auf 22 ist eine andere Ausführungsform eines Fernzugriffs auf eine Einheit im Test dargestellt. Dabei umfasst der entfernte Host 2205 drei Schichten (2206, 2207 und 2208) und verfügt über eine direkte Kommunikation mit der Einheit im Test (UUT) 2220 über einen verschlüsselten Kanal. Wie der Layout-Unterschied darstellt, kann jede beliebige Kopplung oder jedes beliebige Layout implementiert sein, um an eine Einheit im Test aus der Ferne anzukoppeln. Ebenfalls kann jeder beliebige Authentifizierungsprozess verwendet werden, um den Kanal einzurichten. Und ein Sicherheitsprotokoll (ähnlich zu den oben Beschriebenen) könnte verwendet werden, um verschiedene Zugriffsniveaus zu verifizieren. Im Ergebnis kann ein Anbieter oder Hersteller dazu in der Lage sein, eine Einrichtung aus der Ferne zu testen, zu validieren oder von Fehlern zu bereinigen, ohne physisch an die Einheit anzukoppeln. Dem obigen kann entnommen werden, dass mit dem Testen und der Fehlerbereinigung verbundene Zeit und Kosten potentiell drastisch reduziert werden, indem es Validierungsingenieuren ermöglicht wird, Produkte von ihren Ursprungsorten aus der Ferne zu validieren, anstatt physisch an den Anbieterstandorten präsent sein zu müssen.
Ausführungsformen eines Spurerfassungsinformationsmanagements
Wie oben beschrieben ist, wie beispielsweise in dem Abschnitt über Ausführungsformen von Test-, Validierungs- und Fehlerbereinigungshaken, ist ein ODLA auf einem Prozessor, einem Controllerhub oder einer anderen Einrichtung in einigen Ausführungsformen dazu in der Lage, On-Die- und/oder Schnittstelleninformationen, wie beispielsweise eine Spurinformation, zu erfassen. Und sie kann auf jede beliebige Anzahl von Arten, wie beispielsweise unter Verwendung eines Speichers als Spurpuffer, bereitgestellt werden. Oder wie in größerem Detail unten beschrieben ist, kann eine Logik derartige Daten über eine Schnittestelle, wie beispielsweise einen Seitenbandkommunikationsbus bereitstellen. Dann können die Informationen an Werkzeuge für ein Management (Formatieren, Manipulation, Interpretation, Fehlerbereinigung etc.) bereitgestellt werden.
Oben sind ebenfalls die Komplexität und Kosten des Verwendens externer Analysatoren zum Erfassen und Analysieren von Bauteilen erwähnt. Z. B. kann ein Protokoll-Analysator für eine komplexe Schnittstelle, wie beispielsweise eine PCIe-Schnittstelle, 50.000 Dollar oder mehr kosten. Und da Legacy-Signale mehr und mehr integriert werden, wie beispielsweise als Teil eines In-Band-Messaging über eine serielle Hochgeschwindigkeitsschnittstelle, ist die Information nicht einfach auf einem Motherboard verfügbar. Im Ergebnis zeigt die 23 eine Ausführungsform einer Logik zum Liefern von Spurinformationen über einen Seitenbandbus, wie beispielsweise JTAG oder SMBus, an ein Hostsystem. Beispiele von Legacy-In-Band-Signalen zum Erfassen umfassen: TRDY 2321, INTR 2322, SMI 2323 und STPCLK 2324. Dabei erfasst der ODLA 2330 in dem PCH 2320 Spuren der zuvor erwähnten Signale; es ist zu beachten, dass dies in Antwort auf ein beliebiges Ereignis, wie beispielsweise das Ansteuern eines Pins, das Setzen eines Haltepunktereignisses, auf Anweisung eines Hostsystems 2360 oder eines eingebetteten Controllers 2340 (z. B. einer VCU, welche eine Abstraktionsschicht implementiert) erfolgen kann. Der Controller 2340 sammelt Daten für die Signale und stellt sie dem Hostsystem 2360 über einen Seitenbandbus 2350 bereit. Als ein Beispiel weist das Format dieser Daten Folgendes auf: Eine Anzeige, ob ein entsprechendes Signal auf Hoch festsitzt, auf Niedrig festsitzt, ein Umschalten, eine Richtung des Umschaltens oder eine Umschaltfrequenz. Dabei kann die Fehlerbereinigungsfähigkeit mit dem eingebetteten Controller 2340 zum Verarbeiten der Daten und die Fähigkeit des ODLA 2340 zum Auswählen verschiedener interner Signalmengen zum Überwachen ohne eine Veränderung bei der Hardware aktualisiert werden.
Bezugnehmend auf 24 ist eine Ausführungsform eines Flussdiagramms für ein Verfahren zum Verwalten von internen Observationsspur(Internal Observation Trace – IOT)-Daten dargestellt. In dem Fluss 2405 wird ein Test auf einem System ausgefüht. Zum Beispiel wird ein wie oben beschriebener Test auf einer Einheit im Test ausgeführt. Und IOT-Daten werden von einer Logik, wie beispielsweise einem ODLA (auch als On-Chip-Logikanalysator OCLA bezeichnet) erhalten. Es ist zu beachten, dass die IOT-Daten mehrere Ströme/Quellen (z. B. Speicher, I/O, On-Core-Schnittstellen, etc.) aufweisen können.
Im Fluss 2410 werden IOT-Daten gespeichert. Zum Beispiel wird ein mit der Einheit im Test verknüpfter Speicher als Spurpuffer für die IOT-Daten verwendet. Dennoch kann jede beliebige bekannte Schnittstelle verwendet werden, um Daten zu speichern/einem System bereit zu stellen, wie beispielsweise eine Konsole oder ein Host-System, welches dazu dient, die IOT-Daten zu handhaben/zu interpretieren.
In dem Fluss 2415 werden die Spurdaten aus den IOT-Daten rekonstruiert, um eine Wiedergabe zu ermöglichen. Ein beliebiges bekanntes Verfahren zum Rekonstruieren von Spuren und/oder zum Formatieren von Spurdaten kann verwendet werden. Zum Bereitstellen eines illustrativen Beispiels wird kurz auf die 25 Bezug genommen. Dort wird das Format von IOT-Daten dekodiert. In einem Szenario umfassen die IOT-Daten mehrere Ströme/Quellen mit einem spezifischen, vordefinierten Format. So werden die IOT-Daten im Fluss 2505 gemäß solch einem Format dekodiert. Als ein Beispiel werden die Quellen für die IOT-Daten identifiziert. Und in dem Fluss 1510 werden die IOT-Daten separiert, gruppiert und/oder gemäß ihren Quellen sortiert.
Ein Modul (Dienst) für jede Quelle, wie beispielsweise ein Speichermodul für Speicherquellen-IOT-Daten; ein internes Prozessormodul für Prozessorspurquell-IOT-Daten; ein Quickpath-Modul für Quickpath-Schnittstellen-IOT-Daten; ein On-Core-Modul für den Ringverkehr einer On-Core-Verbindung, etc., rekonstruiert Transaktionen für jede entsprechende Quelle in den Flüssen 2515, 2520. Darüber hinaus formatieren die Module in einer Ausführungsform die rekonstruierten Spurdaten spezifisch für eine Wiedergabe in dem Fluss 2525 um. Zurückkehrend zur 24 wird eine Wiedergabe der formatierten, rekonstruierten Spurdaten wiedergegeben. Im Ergebnis kann die Wiedergabe Einblick in den Betrieb einer Einheit im Test zur Validierung und Fehlerbereinigung ermöglichen.
Folgerichtig werden die Fehlerbereinigungszeit und -kosten potentiell verringert, wodurch der Produktentwicklungszyklus erhöht wird. Und die Wiedergabe ermöglicht es Softwaremechanismen, die Reproduktion von Fehlern in einer Emulationsumgebung für Produkte einschließlich der gleichen oder ähnlichen DFx-Methoden, wie beispielsweise der hierin beschriebenen Testarchitektur, zu gestatten. Ein Reproduzieren derartiger Fehler in einer Emulationsumgebung stellt eine volle Sichtbarkeit für das gesamte Systemverhalten innerhalb des Systems im Test bereit, wodurch eine schnelle Fehlerbereinigung ermöglicht wird. Dies unterstützt potentiell das Lösen sowohl von Logik- als auch von Schaltungsgrenzlagenfehlern.
Zusätzlich können ähnliche Vorrichtungen und Verfahren beim Entwickeln von Testinhalten für eine Großserienfertigung verwendet werden; dies stellt potentiell einen schnellen und effizienten Testinhalt für eine Großserienfertigung bereit, wodurch Kosten eingespart werden, indem ein Vertrauen in die Produktstabilität verbessert wird und beim Sortieren von Bauteilen unterstützt wird.
Bezugnehmend auf 26 ist eine Ausführungsform eines Flussdiagramms für ein Verfahren zum Durchführen einer Nachverarbeitungsdivergenzerkennung dargestellt. Wie oben angegeben ist, können, wenn ein Test auf einem System im Test (Fluss 2605) ausgeführt wird, Daten gesammelt und verwendet werden, um exakt die gleichen Testbedingungen in einer Emulations-/Simulationsumgebung wiederzugeben (Flüsse 2610–2625, welche gemäß einem ähnlichen Verfahren arbeiten, wie oben bei den 24–25 beschrieben wurde). Ausgehend von diesem Prozess ist die Validierung dazu in der Lage, Differenzen zwischen dem auf der Hardware durchgeführten Test und dem Softwaremodell zu erkennen; diese Differenzen werden als Divergenzen bezeichnet. Eine Nachverarbeitungsdivergenzerkennung nutzt die Vorteile von DFx-Hardwaremerkmalen, wie beispielsweise eine IOT-Erfassung mit einem OCLA, um einen Systemzustand zu speichern. Wenn ein Test wiedergegeben wird, können die in dem IOT in der Emulation (Wiedergabe der IOT-Daten 2635) gespeicherten Daten, nachdem die Wiedergabe ausgeführt wurde, verarbeitet und mit den in den IOT gespeicherten Daten, welche von dem System im Test gesammelt wurden (gesammelte IOT-Daten 2615), verglichen werden, um Nachverarbeitungsdivergenzerkennungsergebnisse 2640 zu erhalten (d. h. die Differenzen zwischen den Daten 2615 und den Wiedergabedaten 2635). Eine Ausführungszeit während der Wiedergabe ist kostenaufwändig, da sie eine teuere Spezialzweckhardware erfordert. Ein Berechnen der Divergenz während einer derartigen Wiedergabe verschwendet daher möglicherweise teuere Ausführungszeit. Also ermöglicht das Speichern des Systemzustands an einem internen Ort, wie beispielsweise einem Systemspeicher, die Fähigkeit, die Daten separat auf weniger teuerer Hardware zu verarbeiten, nachdem die Wiedergabestufe abgeschlossen wurde.
Als nächstes ist bezugnehmend auf 27 eine Ausführungsform eines Flussdiagramms zum Zugänglichmachen von RTL-Datenstrukturen für eine Hochsprache dargestellt. Wenn Spurdaten von einem System im Test gesammelt werden, werden gewisse gesammelte Datenfelder üblicherweise analysiert, was Modifikationen aus der Spur umfassen kann. Leider verändert sich RTL ständig, wodurch Software, welche um RTL herum gestaltet wurde, beständig aktualisiert werden muss. Wenn Software freigegeben wird (Fluss 2705), werden daher in einer Ausführungsform RTL-Modelle zu dem Zeitpunkt einer Softwarefreigabe gescannt (z. B. wird eine Momentaufnahme von RTL-Daten in dem Fluss 2710 aufgenommen). Aus der Momentaufnahme werden RTL-Datentypen in einem allgemeineren Format, wie beispielsweise in XML, aufgezeichnet. Dabei wird eine RTL-Datenbank von Datenstrukturmomentaufnahmen aus den RTL-Momentaufnahmendaten in dem Fluss 2715 erzeugt.
Sobald die RTL-Daten gespeichert sind (d. h. die Datenbank erzeugt wurde), werden Softwaremechanismen/Dienste zum Lesen, Maskieren und Modifizieren von Spurdatenpaketen, welche auf den aufgenommenen RTL-Datentypendefinitionen beruhen, bereitgestellt. Durch ein einfaches Auswählen, welche Monentaufnahme geladen werden soll, basierend darauf, von. welchem RTL-Modell die Spur stammte, wird eine andere Software potentiell von inkonsequenten RTL-Veränderungen isoliert. Als ein Beispiel fragt eine Software, wenn sie dazu bestimmt ist, Spurdaten von einem Test unter Verwendung dieses RTL-Modells zu interpretieren oder zu modifizieren (Fluss 2720), die Datenbank nach RTL-Datenstrukturen (Fluss 2725) ab und verwendet die Information, um Spurdaten zu dekodieren (Fluss 2730). Im Ergebnis wird eine flexible und adaptierbare Infrastruktur (Modelle von Paket- und Signalformaten) für RTL-Datenstrukturen bereitgestellt, anstatt sich auf konstante RTL-Modelle und eine sich verändernde Software zu verlassen.
Ausführungsformen der Leistungsvalidierung
Da die Logik zunimmt und Schaltkreise kleiner werden, nehmen schaltungsbezogene Probleme stark zu. Und Schaltungsfehler entgehen der Erkennung. Zusätzlich gibt es keine aktuellen guten Charakterisierungsverfahren, um Schaltungsfehler für Nichtgeschwindigkeitspfadprobleme reproduzierbarer zu machen. Im Ergebnis wird in einer Ausführungsform eine Schaltungsgrenzlagenvalidierungs-(CMV)-Methode verwendet, um Probleme für Nichtgeschwindigkeitspfade sowie möglicherweise für Geschwindigkeitspfade bereitzustellen. Hauptursachen von Schaltungsmarginalität umfassen: On-Die-Signalintegrität (durch Kreuzkopplung induziertes Rauschen, durch Netzstatik induziertes Rauschen); Leistungsbereitstellungsintegrität (hochdynamische Stromereignisse gehen oft auf Taktung zurück); Taktdomänenkreuzung und Prozess-, Spannungs- und Temperaturänderungen (Leistungszustandsübergänge, Siliziumprozessvariation).
Beruhend auf Analysen von Plattform-Validierungs-Management-Produkten über die letzten Generationen zeigen Indikatoren, dass das Leistungs-(Power-PWR)-Netz der Hauptverursacher von Schaltungsgrenzlagen ist. In einer Ausführungsform wird daher eine Infrastruktur zum Ermöglichen einer räumlichen und zeitlichen Charakterisierung sowie einer Fehlerbereinigung eines Leistungsnetzes relativ zu On-Die-Ereignissen, einschließlich einer Fähigkeit zum Korrelieren von Test- und Systemereignissen mit Leistungsnetz-Performance, bereitgestellt.
Bezugnehmend auf 28 wird eine Ausführungsform einer solchen Infrastruktur bereitgestellt. Dabei wird eine übergreifende, integrierte (On-Die-)Architektur bereitgestellt, welche eine zeitbasierte und räumliche Steuerung sowie eine Beobachtung von On-Die-Spannungsregelungsereignissen mit einer Fähigkeit zum deterministischen Korrelieren solcher Ereignisse mit Testinhalten sowie Systemereignissen bereitgestellt. Wie dargestellt ist, dient die Architektur 2810 dazu, von einem Host 2800 durch eine Abstraktionsschicht 2805 (wie oben beschrieben), welche durch die VCU 2815 implementiert sein kann, angekoppelt zu werden.
Die Komponenten der Architektur 2800 umfassen: Eine On-Die-Spannungsnetzstatikbeobachtungsfähigkeit mit hoher Bandbreite (VDM 2830) und einen Netzstatikinjektionsmechanismus (ODI 2835) (welche in einer Ausführungsform beide dazu eingerichtet sind, zeitlich und räumlich konfiguriert zu werden); eine taktzyklusspezifische Testinhaltssynchronisationsinfrastruktur, eine Infrastruktur zum deterministischen Triggern von Ereignissen und zur taktzyklusgenauen Zeitüberwachung (DSC 2840), welche in einer Ausführungsform eine Zeitstempelung und Wiedergabe erlaubt; eine dynamische On-Die-Spannungsregelungszustandserfassungsfähigkeit, wie beispielsweise einen ODLA für eine VR-Zustandserfassung, mit einer Ereigniskorrelation; einen auf einer konfigurierbaren Hardware basierenden Nutzlastmodifizierungsmechanismus (Mikrohaltepunktlogik 2830), welcher auf Systemereignisse, Testereignisse und/oder Leistungszustandsübergänge in jeder beliebigen gegebenen Leistungsdomäne oder -domänen je nach Ermessen des Anwenders/Hosts 2800 hin initiiert werden kann.
Eine nicht abschließende Liste von Beispielen bzgl. der Fähigkeiten der Architektur umfassen: Eine Fähigkeit zum Korrelieren von ODI/VDM-System/(I/O oder Kern-)-Ereignissen mit einer Beobachtung von On-Die-Spannungsregulierungsintema, wie beispielsweise Momentaufnahmen von analogen Beobachtungspunkten über A/D-Samples und dynamischen Momentaufnahmen von Zustandsmaschinenabzügen; deterministisches Initiieren von Hardwarebasierenden Nutzlaständerungen; Synchronisieren von ODI- und/oder VDM-Triggerereignissen mit internen VR-Ereignissen; Anhalten auf interne VR-Ereignisse hin; Erfassen von Zeitstempeln von internen VR-Ereignissen; Überwachen einer Verzögerung zwischen einer Ausgabe eines Leistungsmanagementkommandos und einer tatsächlichen VR-Veränderung; Beobachtung von VDM/ODI-Veränderungen; Korrelieren von aktuellem eingehenden Verhalten mit internen Ereignissen, Beobachten einer Gangverhältnisänderung und von Leistungsverteilungseffekten und Bereitstellen einer Tastverhältniserkennungsintervallberechnung.
Einige nicht-abschließende Beispiele von Applikationen und Modi der Architektur umfassen: Leistungsnetzcharakterisierung; systemereignisbasierende Korrelation und leistungsereignisbasierende Korrelation; all diese sind unten veranschaulichend beschrieben. Für ein Leistungsnetz kann eine Charakterisierung auf jede beliebige Anzahl von Wegen ausgeführt werden, wodurch dem Anwender eine vollständige Flexibilität gegeben wird. Im Wesentlichen sind die Spannungsüberwachungsschaltungen in diesem Betriebsmodus vorkonfiguriert, um Spannungen über der Zeit zu erfassen. Die Spannungen werden gemessen, indem die Oszillationen eines Ringoszillators während kurzer Zeitdauern gezählt werden. Während des Verlaufs eines Tests oder einer anderen Systemaktivität werden die höchsten Peaks und die tiefsten Täler innerhalb einer gegebenen Leistungsdomänengegend durch ein Vergleichen von Samples über den Verlauf des Charakterisierungszyklus hinweg erfasst. Dabei kann die Charakterisierung ausgeführt werden, während das System in Ruhe oder in einem Boot-Zyklus ist, während eines Tests oder während jeder beliebigen Anzahl von Systemereignissen. Und die Charakterisierung kann auch auf jeder beliebigen/allen Domänen gleichzeitig ausgeführt werden.
Für eine systemereignisbasierende Korrelation unter Verwendung einer Mikrohaltepunktinfrastruktur, welche zum Synchronisieren des Starts einer Testsequenz (oder eines Systemereignisse von Interesse) mit der Initiierung des Leistungsnetz-Samplings konfiguriert ist, wird die abgelaufene Zeit bis zu dem Fehlerpunkt oder bei dem Auftreten eines bestimmten Systemereignisses wie beispielsweise eines Cyclic Redundancy Check(CRC)-Fehlers (als ein veranschaulichendes Beispiel) erfasst. Die Testsequenz kann dann deterministisch wiedergegeben werden, um die On-Die-Spannungsregelungsperformance auf eine konfigurierbare Art zu evaluieren; mit der Fähigkeit, sich jeden beliebigen Taktzyklus vor, während oder nach einem gegebenen Triggerereignis anzuschauen. Eine Datensammlung von analogen Punkten und Zustandsdaten kann zu einem gegebenen Zeitpunkt oder in einer gegebenen Gegend basierend auf einem Triggerereignis von Interesse dynamisch erfasst werden. Daher wohnt der Architektur eine vielseitige Flexibilität inne, so dass Triggerereignisse und Aktionen durch die Leistungsregelungsblöcke, das Powermanagement oder test-/systemspezifische Ereignisse bereitgestellt werden können.
Für eine leistungsereignisbasierende Korrelation ist die Operation ähnlich zu einer systemereignisbasierenden Korrelation. Eine Mikrohaltepunkt-„artige” Infrastruktur ist in die Spannungsregelungsschaltung integriert, wodurch die Initiierung einer Anzahl von Systemereignissen mit dem Sampling des Leistungsnetzes über VDM 2830 und/oder die Injektion eines Netzstatikereignisses über ODI 2835 erlaubt wird. Triggerereignisse in diesem Modus werden in einer Ausführungsform am typischsten auf spezifische Leistungsereignisse oder auf Zustände hin initiiert.
Ein Modul bezieht sich wie hierin verwendet auf eine beliebige Hardware, Software, Firmware oder eine Kombination davon. Modulgrenzen, welche als separat dargestellt sind, variieren üblicherweise oft und können sich möglicherweise überlappen. Zum Beispiel können sich ein erstes und ein zweites Modul Hardware, Software, Firmware oder eine Kombination davon teilen, während sie potentiell eine unabhängige Hardware, Software oder Firmware zurückbehalten. In einer Ausführungsform umfasst der Begriff Logik Hardware, wie beispielsweise Transistoren, Register etc., welche kombiniert und/oder konfiguriert sind, um Aufgaben auszuführen. In einer anderen Ausführungsform bezieht sich Logik auf andere Einrichtungen, wie beispielsweise programmierbare Logikeinrichtungen oder programmierbare Logikanordnungen. In noch einer anderen Ausführungsform umfasst die Logik auch Software oder Code, welche(r) in Hardware integriert ist, wie beispielsweise Firmware oder Mikrocode.
Ein Wert, wie er hierin verwendet wird, umfasst eine beliebige Darstellung einer Zahl, eines Zustandes, eines logischen Zustandes oder eines binären logischen Zustandes. Die Verwendung von Logikpegeln, Logikwerten oder logischen Werten wird oft auch als Einsen oder Nullen bezeichnet, welche einfach binäre Logikzustände darstellen. Zum Beispiel bezeichnet eine 1 einen hohen Logikpegel und 0 bezeichnet einen niedrigen Logikpegel. In einer Ausführungsform kann eine Speicherzelle, wie beispielsweise ein Transistor oder eine Flashzelle, dazu in der Lage sein, einen einzigen logischen Wert oder mehrere logische Werte zu halten. Allerdings wurden andere Darstellungen von Werten in Computersystemen verwendet. Zum Beispiel kann die Dezimalzahl zehn auch als ein binärer Wert 1010 und als ein hexadezimaler Buchstabe A dargestellt werden. Daher umfasst ein Wert jede beliebige Darstellung von Information, welche dazu in der Lage ist, in einem Computersystem gehalten zu werden.
Darüber hinaus können Zustände durch Werte oder Teile von Werten dargestellt werden. Beispielsweise kann ein erster Wert, wie beispielsweise eine logische 1, einen Voreinstell- oder Initialzustand darstellen, während ein zweiter Wert, wie beispielsweise eine logische 0, einen Nicht-Voreinstellzustand darstellen kann. Zusätzlich beziehen sich die Begriffe Reset und Set in einer Ausführungsform auf einen voreingestellten bzw. einen aktualisierten Wert oder Zustand. Zum Beispiel kann ein voreingestellter Wert potentiell einen hohen logischen Wert, d. h. Reset, umfassen, während ein aktualisierter Wert potentiell einen niedrigen logischen Wert, d. h. Set umfasst. Es ist zu beachten, dass eine beliebige Kombination von Werten verwendet werden kann, um eine beliebige Anzahl von Zuständen darzustellen.
Die Ausführungsformen von Verfahren, Hardware, Software, Firmware oder Code, welche oben beschrieben wurden, können mittels Instruktionen oder Code implementiert sein, welche auf einem maschinenzugänglichen oder einem maschinenlesbaren Medium gespeichert sind und welche durch ein Verarbeitungselement ausführbar sind. Ein maschinenzugängliches/lesbares Medium umfasst einen beliebigen Mechanismus, welcher Informationen in einer Form bereitstellt (d. h. speichert und/oder überträgt), welche von einer Maschine, wie beispielsweise einem Computer oder einem elektronischen System, lesbar ist. Zum Beispiel umfasst ein materielles maschinenzugängliches Medium einen Speicher mit wahlfreiem Zugriff (RAM), wie beispielsweise einen statischen RAM (SRAM) oder einen dynamischen RAM (DRAM); ROM; ein magnetisches oder optisches Speichermedium; Flash-Speichereinrichtungen; elektrische Speichereinrichtungen; optische Speichereinrichtungen; akustische Speichereinrichtungen; eine andere Form von materiellen Speichereinrichtungen zum Halten nicht-materieller, verbreiteter Signale (z. B. Trägerwellen, Infrarotsignalen, Digitalsignalen); etc.
Zusätzlich können die Ausführungsformen von Verfahren, Hardware, Software, Firmware oder Code, welche oben beschrieben wurden, durch eine Ausführung eines Compilers, welcher auf einem maschinenlesbaren Medium gespeichert ist, oder als Teil eines ausführenden Codes, welcher auf einem maschinenlesbaren Medium gespeichert ist und durch einen Compiler kompiliert wurde, implementiert sein. Ein Compiler umfasst oft ein Programm oder eine Menge von Programmen, um einen Source-Text/-Code in einen Ziel-Text/-Code zu übersetzen. Üblicherweise wird die Kompilierung eines Programm-/Applikation-Codes mit einem Compiler in mehreren Phasen und Durchgängen ausgeführt, um einen Programmcode in einer Hochsprache in einen Maschinen- oder Assembly-Sprachcode auf niedriger Ebene zu transformieren. Dennoch können Einzeldurchgangscompiler für eine einfache Kompilierung verwendet werden. Ein Compiler kann alle bekannten Kompilierungstechniken verwenden und alle bekannten Compileroperationen ausführen, wie beispielsweise eine lexikalische Analyse, ein Vorverarbeiten, ein Analysieren, ein grammatisches Analysieren, ein semantisches Analysieren, eine Code-Generation, eine Code-Transformation und eine Code-Optimierung. Ein Compiler dient in einer Ausführungsform dazu, einen Code zu kompilieren und/oder zu optimieren, um Operationen, Aufrufe, Funktionen, Instruktionen, etc. einzufügen, um die hier beschriebenen Verfahren auszuführen.
Größere Compiler umfassen oft mehrere Phasen, aber die meisten dieser Phasen sind innerhalb von zwei allgemeinen Phasen umfasst: (1) ein Front-End, d. h. allgemein, wo ein syntaktisches Verarbeiten, ein semantisches Verarbeiten und einige Transformationen/Optimierungen stattfinden, und (2) ein Back-End, d. h. allgemein, wo eine Analyse, Transformationen, Optimierungen und eine Code-Erzeugung stattfinden. Einige Compiler beziehen sich auf ein Middle-End, war das Verschwimmen der Abgrenzung zwischen einem Front-End und einem Back-End eines Compilers illustriert. Im Ergebnis kann eine Bezugnahme auf eine Einfügung, eine Assoziation, eine Erzeugung oder eine andere Operation eines Compilers in einer bzw. einem beliebigen der zuvor erwähnten Phasen oder Durchgänge sowie beliebigen anderen bekannten Phasen oder Durchgangen eines Compilers stattfinden. Derartige Einfügungen erfolgen in einer Ausführungsform während einer statischen und/oder Gesamtprogrammkompilierung. In einer anderen Ausführungsform kann ein Compilercode oder ein dynamischer Optimierungscode während einer dynamischen Kompilierung derartige Operationen/Aufrufe einfügen sowie den Code für eine Ausführung während der Laufzeit optimieren. In einem Szenario kann entweder Hardware oder Software, wie beispielsweise ein Compilerprogramm, eine dynamische Profilierung einer Programmausführung ausführen.
In dieser Beschreibung bedeutet eine Bezugnahme auf „eine Ausführungsform”, dass ein bestimmtes Merkmal oder eine bestimmte Struktur oder Charakteristik, welche(s) im Zusammenhang mit der Ausführungsform beschrieben ist, in einer Ausführungsform vorhanden ist. Das Auftreten des Ausdrucks „in einer Ausführungsform” an verschiedenen Stellen in dieser Beschreibung bezieht sich daher nicht notwendigerweise überall auf die gleiche Ausführungsform. Darüber hinaus können die bestimmten Merkmale, Strukturen oder Charakteristiken auf jede beliebige geeignete Weise in einer oder mehreren Ausführungsformen kombiniert werden.
In der vorhergehenden Beschreibung wurde eine detaillierte Beschreibung mit Bezugnahme auf spezifische beispielhafte Ausführungsformen gegeben. Es wird jedoch erkennbar sein, dass verschiedene Modifikationen und Veränderungen darin ausgeführt werden können, ohne von dem breiteren Geist und Umfang der Erfindung, wie sie in den beigefügten Ansprüchen beschrieben ist, abzuweichen. Die Beschreibung und die Zeichnungen sollen demgemäß in einem veranschaulichenden Sinne und nicht in einem einschränkenden Sinne verstanden werden. Darüber hinaus bezieht sich die vorhergehende Verwendung einer Ausführungsform und eine andere beispielhafte Sprache nicht notwendigerweise auf die gleiche Ausführungsform oder das gleiche Beispiel, sondern kann sich auf verschiedene und getrennte Ausführungsformen sowie möglicherweise die gleiche Ausführungsform beziehen.

Claims

Vorrichtung, welche Folgendes umfasst: einen oder mehrere Hardwaretesthaken, welche zum Bereitstellen einer Testinformation eingerichtet sind, und eine Abstraktionslogik, welche zum Abstrahieren des einen oder der mehreren Hardwaretesthaken von der Softwareschicht und zum Bereitstellen einer Schnittstelle für eine Softwareschicht eingerichtet ist, wobei die Schnittstelle dazu eingerichtet ist, mit dem einen oder den mehreren Hardwaretesthaken in Verbindung stehende Dienste bereitzustellen.
Vorrichtung, welche Folgendes umfasst: eine integrierte Schaltung, welche einen On-Die-Logikanalysator (ODLA) aufweist, welcher dazu eingerichtet ist, eine Spurinformation, welche mit der integrierten Schaltung verknüpft ist, zu erfassen, einen an die integrierte Schaltung gekoppelten Speicher, wobei der Speicher dazu eingerichtet ist, als ein Spurpuffer zum Halten der mit der integrierten Schaltung verknüpften Spurinformation, welche von dem ODLA erfasst wurde, verwendet zu werden.
Vorrichtung, welche Folgendes umfasst: eine integrierte Schaltung, welche einen On-Die-Logikanalysator (ODLA) aufweist, welcher dazu eingerichtet ist, eine Spurinformation einer Schnittstelle für die integrierte Schaltung zu erfassen, und einen mit der integrierten Schaltung gekoppelten Speicher, wobei der Speicher dazu eingerichtet ist, als ein Spurpuffer zum Halten der Spurinformation der Schnittstelle für die integrierte Schaltung, welche von dem ODLA erfasst wurde, verwendet zu werden.
Vorrichtung, welche Folgendes umfasst: einen Prozessor, welcher Folgendes aufweist: einen Validierungscontroller, welcher an ein oder mehrere Kontrollregister in dem Prozessor gekoppelt ist, wobei der Validierungscontroller dazu eingerichtet ist, das eine oder die mehreren Kontrollregister zu konfigurieren, um einen Haltepunkt zu definieren, einen On-Die-Logikanalysator (ODLA), welcher dazu eingerichtet ist, eine mit dem Prozessor verknüpfte Spurinformation in Antwort darauf zu erfassen, dass der Prozessor auf den Haltepunkt trifft, wenn das eine oder die mehreren Kontrollregister dazu konfiguriert sind, den Haltepunkt zu definieren.
Vorrichtung, umfassend eine integrierte Schaltung, welche Folgendes aufweist: einen Testanschluss, welcher dazu eingerichtet ist, einen Zugriff auf eine mit der integrierten Schaltung verknüpfte Testinformation zu erlauben, eine Frühanschaltsignallogik, welche dazu eingerichtet ist, eine Signalzustandsinformation von Signalen, welche übergehen sollen, bevor der Testanschluss während einer Anschaltsequenz der integrierten Schaltung aktiviert wird, zu erfassen.
Vorrichtung, umfassend eine integrierte Schaltung, welche Folgendes aufweist: ein Einschaltsignal, welches dazu eingerichtet ist, überzugehen, um ein Einschalten der integrierten Schaltung anzuzeigen, eine Zähllogik, welche dazu eingerichtet ist, eine Zählung in Antwort auf das Übergehen des Einschaltsignals zu starten, eine Kantendetektierungslogik, um einen Kantenübergang eines Signals von Interesse zu detektieren, ein Speicherelement, welches dazu eingerichtet ist, eine Signalidentifizierung für das Signal von Interesse und einen Zeitstempelwert basierend auf der Zählung der Zähllogik, wenn die Kantendetektierungslogik den Kantenübergang des Signals von Interesse detektiert, zu halten.
Vorrichtung, welche Folgendes umfasst: eine integrierte Schaltung, welche dazu eingerichtet ist, sich in einem aktiven Leistungszustand und in mehreren Niedrigleistungszuständen zu befinden, wobei die integrierte Schaltung Folgendes aufweist: eine Niedrigleistungssignallogik, welche dazu eingerichtet ist, eine Signalzustandsinformation von Signalen in Antwort auf ein mit einem Niedrigleistungszustand der mehreren Niedrigleistungszuständen verknüpftes Leistungszyklusereignis zu erfassen.
Vorrichtung, umfassend eine integrierte Schaltung, welche Folgendes aufweist: mehrere Hardware-Design-For-Test-(DFx)-Merkmale, und einen Mikrocontroller, welcher dazu eingerichtet ist, einen Zugriff auf die mehreren Hardware-DFx-Merkmale bereitzustellen, wobei der Mikrocontroller einen Code aufweist, welcher, wenn er ausgeführt wird, den Mikrocontroller dazu veranlasst, eine Software oder mehrere Applikationsprogrammierschnittstellen (APIs) für mit den mehreren DFx-Merkmalen verknüpfte Dienste bereitzustellen.
Materielles maschinenlesbares Medium, welches einen Code aufweist, welcher, wenn er ausgeführt wird, eine Maschine dazu veranlasst, die folgende Operation auszuführen: Interpretieren einer Anforderung von einer anfordernden Software nach einem Dienst, welcher mit einem Hardwaretesthaken in der Maschine verknüpft ist, gemäß einer Spezifikation für eine Applikationsprogrammierschnittstelle (API), Bedienen der Anforderung in Antwort auf das Interpretieren der Anforderung, wobei das Bedienen der Anforderung ein Initiieren eines mit dem Hardwaretesthaken in verknüpften Tests umfasst, und Bereitstellen von Testergebnissen des Tests an die anfordernde Software.
Materielles maschinenlesbares Medium, welches einen Code aufweist, welcher, wenn er ausgeführt wird, eine Maschine dazu veranlasst, die folgende Operation auszuführen: Feststellen einer Veränderung an Hardwaretesthaken der Maschine, Aktualisieren von Code, welcher in einem Mikrocontroller gespeichert ist, um die Veränderung an der Hardware der Maschine zu berücksichtigen, wobei das Aktualisieren des Codes auch eine gleiche Schnittstelle zu einer Softwareschicht zum Zugreifen auf mit Hardwaretesthaken der Maschine verknüpfte Dienste aufrecht erhält.
System, welches Folgendes umfasst: eine physikalische Zielschicht, welche dazu eingerichtet ist, Hardwaretestmerkmale innerhalb einer integrierten Schaltung zu implementieren, eine Transportschicht, welche dazu eingerichtet ist, eine transportunabhängige Kommunikation von einer Abstraktionsschicht zu der physikalischen Zielschicht zu transportieren, die Abstraktionsschicht, welche dazu eingerichtet ist, die physikalische Zielschicht zu abstrahieren und einer Applikationsschicht eine oder mehrere Applikationsprogrammierschnittstellen (APIs) bereitzustellen, die Applikationsschicht, welche dazu eingerichtet ist, mit der physikalischen Zielschicht verknüpfte Dienste von der Abstraktionsschicht gemäß Spezifikationen der einen oder der mehreren APIs anzufordern.
Materielles maschinenlesbares Medium, welches einen Code aufweist, welcher, wenn er ausgeführt ist, eine Maschine dazu veranlasst, die folgende Operation auszuführen: Programmieren einer Applikationsprogrammierschnittstelle (API) für einen oder mehrere mit Hardwaretestmerkmalen einer integrierten Schaltung verknüpfte Dienste, Empfangen von Daten von dem einen oder den mehreren Diensten und Interpretieren der Daten in Antwort auf das Empfangen der Daten.
Vorrichtung, welche Folgendes umfasst: einen Controller, welcher dazu eingerichtet ist, eine Anforderung von einer Applikation zu empfangen, wobei die Anforderung dazu dient, mit dem Zugreifen auf ein Hardwaretestmerkmal in einer integrierten Schaltung verknüpft zu sein, Sicherheitslogik, welche dazu eingerichtet ist, ein Zugriffsniveau der Applikation aus mehreren Zugriffsniveaus zu bestimmen, um die Anforderung von der Applikation in Antwort darauf zu erlauben, dass das Zugriffsniveau der Applikation Zugriff auf das Hardwaretestmerkmal hat, und die Anforderung von der Applikation in Antwort darauf nicht zu erlauben, dass das Zugriffsniveau der Applikation keinen Zugriff auf das Hardwaretestmerkmal hat.
Verfahren, welches Folgendes umfasst: Bestimmen eines Zugriffsniveaus einer Applikation, Bereitstellen einer Dienstanforderung für eine Abstraktionsschnittstelle von der Applikation, wobei die Abstraktionsschnittstelle dazu dient, einen Zugriff auf Hardwaretestmerkmale einer integrierten Schaltung zu steuern, Feststellen, ob die Dienstanforderung von der Applikation an die Abstraktionsschnittstelle zulässig ist, basierend auf einem Typ der Dienstanforderung und dem Zugriffsniveau der Applikation, und Nichterlauben der Dienstanforderung in Antwort auf ein Feststellen, dass die Dienstanforderung von der Applikation an die Abstraktionsschnittstelle basierend auf dem Typ der Dienstanforderung und dem Zugriffsniveau der Applikation nicht zulässig ist.
System, welches Folgendes umfasst: mehrere integrierte Schaltungen, wobei jede der mehreren integrierten Schaltungen einen Validierungscontroller aufweist, welcher dazu eingerichtet ist, einen Zugriff auf Hardwaretestmerkmale jeder der mehreren integrierten Schaltungen zu steuern, und einen universellen Testzugriffsanschluss, welcher dazu eingerichtet ist, einen Zugriff auf jeden der Validierungscontroller in jeder der mehreren integrierten Schaltungen bereitzustellen.
Vorrichtung, welche Folgendes umfasst: eine Einheit mit einer integrierten Schaltung (IC), welche Signalpins auf einer Unterseite der IC-Einheit und Testpins auf der Oberseite der IC-Einheit, welche zum elektrischen Koppeln mit Testsonden eingerichtet sind, aufweist.
System, welches Folgendes umfasst: eine Einheit mit einer integrierten Schaltung (IC), welche Signalpins auf einer Unterseite der IC-Einheit und Testpins auf der Oberseite der IC-Einheit aufweist, und einen Großserienfertigungs-(HVM)-Verbindungsmechanismus, welcher Vorrichtungssonden aufweist, welche elektrisch an einen Tester und die Testpins auf der Oberseite der IC-Einheit gekoppelt sind.
Vorrichtung, welche Folgendes umfasst: eine Einheit mit einer integrierten Schaltung, und einen integrierten Wärmeverteiler (IHS), welcher thermisch an die Einheit mit der integrierten Schaltung gekoppelt ist, wobei der IHS diskret vorstehende Lastlaschen aufweist.
Vorrichtung, welche ein thermisches Werkzeug mit kleinem Formfaktor umfasst, welches Folgendes aufweist: eine Coldplate, welche zum thermischen Koppeln an eine integrierte Schaltung eingerichtet ist, eine Anordnung eines thermoelektrischen Kühlers, einen Wasserkühler mit Mikrokanalkühlrippen, und einen Einlass und einen Auslass bei einer Mitte des Wasserkühlers.
Vorrichtung, welche ein thermisches Werkzeug mit kleinem Formfaktor umfasst, welches Folgendes aufweist: eine Coldplate, welche zum thermischen Koppeln an eine integrierte Schaltung eingerichtet ist, eine Anordnung eines thermoelektrischen Kühlers, einen Wasserkühler mit Mikrokanalkühlrippen, und einen Einlass und einen Auslass bei einer Mitte des Wasserkühlers.
Materielles maschinenlesbares Medium, welches einen Code aufweist, welcher, wenn er ausgeführt wird, eine Maschine dazu veranlasst, die folgende Operation auszuführen: Durchführen eines Tests auf einem Computersystem, Abspeichern einer Spurinformation in einer Speichervorrichtung in dem Computersystem, Rekonstruieren von Spurdaten aus der Spurinformation in der Speichervorrichtung, Ausführen einer Wiedergabe der Spurdaten in einer Simulationsumgebung.
Materielles maschinenlesbares Medium, welches einen Code aufweist, welcher, wenn er ausgeführt wird, eine Maschine dazu veranlasst, die folgende Operation durchzuführen: in Reaktion auf eine Softwarefreigabe: Aufnehmen einer Momentaufnahme einer Widerstandslogik-(RTL)-Struktur und Aufbauen einer RTL-Struktur-Momentaufnahmendatenbank basierend auf der Momentaufnahme der RTL-Struktur, und