-
Das
Entwerfen, Testen und Verifizieren eines Prozessors, wie z. B. eines
Mikroprozessors, ist ein schwieriges Vorhaben. Prozessorsimulationen
unter Verwendung von Prozessorsimulatoren und/oder einer Vielzahl
von Tools bzw. Werkzeugen wie Registerübertragungssprachen-Modellen
(RTL-Modellen; RTL register transfer language) wurden immer wichtiger
für Prozessor-Entwurf,
-Testen und -Verifikation. In einer Prozessorverifikationsumgebung
kann ein Prozessorsimulationsinitialisierer einen Satz von Testvektoren
eingeben und einen Satz von Daten und/oder Anweisungen ausgeben,
die das Erzeugen anfänglicher
Bedingungen für
Verifikationstools ermöglichen,
wie z. B. einem Simulator, ein RTL-Modell, einen Prüfer usw.
-
Ein
Testfall, der durch eine Prozessorverifikationsarchitektur ausgeführt wird,
kann als Teil seiner Ausgabe einen Satz von Dateien erzeugen, die Erfassungsinformationen
enthalten. Erfassungsinformationen betreffen die Vielzahl und die
Häufigkeit von
bestimmten definierten Ereignissen, die während eines Satzes von Prozessorsimulationen
auftreten. Definierte Ereignisse können z. B. umfassen, ob eine Anweisung
ausgeführt
wurde, ob ein Interrupt aufgetreten ist, ob in einen Prozessormodus
eingetreten wurde, usw. Die Erfassung ist das primäre Wertmaß bei einer
Testfallregression.
-
Ein
Prozessor kann unterschiedliche Typen von Registern umfassen. Zum
Beispiel kann eine Prozessorfamilie bekannte vom Benutzer zugreifbare Register
umfassen, wie z. B. AX und SI oder D0–D7 und A0–A7. Ein Prozessor kann jedoch
ferner andere, weniger bekannte und weniger zugreifbare Register
umfassen. Diese Register können
ein modellspezifisches Register (MSR) und ein Prozessorstatusregister
(PSR) umfassen. MSRs und PSRs können während der
Prozessorentwicklung hinzugefügt,
entfernt und neu konfiguriert werden und können in einem vollständigen Prozessorentwurf
verbleiben oder nicht.
-
Ein
modellspezifisches Register kann eingestellt sein, um das Steuern
von Prozessor-Verhalten und/oder -Modi zu ermöglichen. Somit kann ein modellspezifisches
Register verwendet werden, um einen Prozessormodus zu „hacken". Dies kann der Prozessor-Entwicklung
und -Verifikation nutzen, durch Vereinfachen des Konfigurierens
eines Prozessors in einen gewünschten
deterministischen Zustand zum Testen. In einer Umgebung, die eine
Prozessorsimulation umfasst, kann ein Prozessorsimulator MSRs simulieren.
Somit kann der Prozessorsimulator konfiguriert sein, um einen anfänglich erwünschten
Prozessorzustand aus einem simulierten MSR zu lesen. In der Simulationsumgebung
werden MSRs üblicherweise
während
einer Simulationskonfiguration und nicht während eines Simulationsdurchlaufs
geschrieben.
-
Ein
PSR kann Statusbits umfassen, die durch einen Prozessor oder einen
Prozessorsimulator gesetzt werden, um Ereignisse zu berichten, wie z.
B. Prozessorstatusübergänge, Prozessorereignisse
(z. B. Fehler), Prozessormodusübergänge usw.
In einer Umgebung, die eine Prozessorsimulation umfasst, kann ein
Prozessorsimulator PSRs simulieren. Somit kann der Prozessorsimulator
konfiguriert sein, um Prozessorstatusänderungen zu erkennen, durch Manipulieren
von Bits in einem simulierten PSR.
-
Ein
Prozessor kann unterschiedliche funktionale Bereiche aufweisen,
kann in unterschiedlichen Phasen durch unterschiedliche Personen
zu unterschiedlichen Zeiten entworfen werden, kann durch verschiedene
Prüfungen
gehen usw. Ein Bereich, eine Phase oder eine Revision kann auf bestimmten MSRs
während
Entwurf und während
Verifikation basieren. Ein anderer Bereich, eine Phase oder eine Überprüfung kann
auf anderen MSRs basieren. Es ist unwahrscheinlich, dass ein modellspezifisches
Register, das einem Bereich, einer Phase oder Überprüfung gut bekannt ist, einem
einen anderen Bereich, einer Phase oder Überprüfung gleichermaßen bekannt
ist. Somit ermöglichen
die modellspezifische Registerlogik und der Signifikanzvektordatenspeicher
das Aufbauen von Verifikationstools, die Kenntnisse von MSRs erfassen
und memorieren.
-
Es
ist die Aufgabe der vorliegenden Erfindung, ein System, ein Verfahren,
ein computerlesbares Medium und einen Satz von Anwendungsprogrammierungsschnittstellen
mit verbesserten Charakteristika zu schaffen.
-
Diese
Aufgabe wird durch ein System gemäß Anspruch 9, 12 und 28, ein
Verfahren gemäß Anspruch
20 und 30, ein computerlesbares Medium gemäß Anspruch 27 und einen Satz
von Anwendungsprogrammierungsschnittstellen gemäß Anspruch 29 gelöst.
-
Die
beiliegenden Zeichnungen, die umfasst sind und einen Teil der Spezifikation
bilden, stellen verschiedene Beispiel-Systeme, -Verfahren usw. dar, die
verschiedene beispielhafte Ausführungsbeispiele von
Aspekten der Erfindung darstellen. Die dargestellten Elementgrenzen
(z. B. Kästen,
Kästengruppen
oder andere Formen) in den Figuren stellen ein Beispiel der Grenzen
dar. Ein Durchschnittsfachmann auf dem Gebiet wird erkennen, dass
ein Element als mehrere Elemente entworfen sein kann, oder dass
mehrere Elemente als ein Element entworfen sein können. Ein
Element, das als eine interne Komponente eines anderen Elements
gezeigt ist, kann als eine externe Komponente implementiert sein
und umgekehrt. Elemente sind möglicherweise nicht
maßstabsgetreu
gezeichnet.
-
Bevorzugte
Ausführungsbeispiele
der vorliegenden Erfindung werden nachfolgend Bezug nehmend auf
die beiliegenden Zeichnungen näher
erläutert.
Es zeigen:
-
1 ein
Beispielsystem zum Manipulieren von modellspezifischen Registern;
-
2 ein
anderes Beispielsystem zum Manipulieren von modellspezifischen Registern;
-
3 ein
Beispielsystem zum Erwerben von Prozessorstatusregister-Bitübergangsdaten;
-
4 ein
anderes Beispielsystem zum Erwerben von Prozessorstatusregister-Bitübergangsdaten;
-
5 ein
Beispielsystem zum Manipulieren von modellspezifischen Registern
und Erwerben von Prozessorstatusregister-Bitübergangsdaten;
-
6 ein
Beispielsystem zum Korrelieren von Prozessorstatusregister-Bitübergangsdaten
mit modellspezifischen Registermanipulationen;
-
7 ein
Beispielsystem zum Bewerten einer Prozessormodusabdeckung;
-
8 ein
Beispielverfahren zum Verhindern, dass irrelevante modellspezifische
Registerbits bei einer Prozessorsimulation gesetzt werden und Prozessorstatusregister-Bitübergangsdaten
von einer Prozessorsimulation erworben werden;
-
9 eine
Beispielrechenumgebung, in der Beispiel-Systeme und -Verfahren, die hierin dargestellt
sind, wirken können;
-
10 eine
beispielhafte Anwendungsprogrammierungsschnittstelle (API); und
-
11 ein
Beispielverfahren zum Wählen
im Hinblick auf modellspezifische Registermanipulationen.
-
Beispiel-Systeme
und -Verfahren, die hierin beschrieben sind, beziehen sich auf das
Verwenden von modellspezifischen Registern und Signifikanzvektoren,
um das Einrichten bekannter gültiger
Zustände
für Prozessorsimulationen
zu ermöglichen. Beispiel-Systeme
und -Verfahren beziehen sich ebenfalls auf das Erwerben von Prozessorstatusregister-Bitübergangsdaten,
die während
Prozessorsimulationen erzeugt werden. Somit ermöglichen einige Beispiel-Systeme
und -Verfahren das Bewerten einer Prozessormoduserfassung. Beziehungen
zwischen Modellstatusregister-Initialisierungen und Prozessorstatusregister-Bitübergängen können das
Bereitstellen eines Abdeckungsanalysekontexts ermöglichen.
Zum Beispiel können
gezielte Testfälle
geschrieben werden, um das Platzieren einer Prozessorsimulation
in bestimmte Modi zu versuchen und dann bestimmte Aktionen auftreten
zu lassen, während
diese Modi vorhanden sind. Das Einrichten der Modi wird ermöglicht durch
Manipulieren der modellspezifischen Register und das Beobachten
der Aktionen, die auftreten, wenn die Modi vorhanden sind, wird
durch Zugreifen auf die Prozessorstatusregister ermöglicht.
-
Einige
modellspezifische Registerbits können
nicht bedeutungsvoll in einer Verifikationsumgebung gesetzt werden.
Zum Beispiel kann ein bestimmtes Merkmal möglicherweise nicht implementiert
werden und somit ist das modellspezifische Registerbit, das einen
Modus für
dieses Merkmal steuert, irrelevant. Ein Techniker, der das modellspezifische
Registerbit in einem Testfall setzt, kann glauben, dass das Setzen
des Bits in dem Testfall eine Wirkung hat. Um zu verhindern, dass
der Techniker den fehlerhaften Gedanken beibehält, kann eine modellspezifische
Registerlogik modellspezifische Register neu konfigurieren, die
durch einen Prozessorsimulationsinitialisierer konfiguriert wurden,
und über die
Neukonfiguration berichten. Die modellspezifische Registerlogik
kann auf einen Signifikanzvektor zugreifen, um das modellspezifische
Register zu konfigurieren. Bei einem Beispiel kann die modellspezifische
Registerlogik eine logische UND-Operation zwischen den Inhalten
des modellspezifischen Registers und dem Signifikanzvektor durchführen. Um „Unrat
rein, Unrat raus" zu
verhindern, können die
Signifikanzvektoren an die modellspezifischen Register angewendet
werden. Somit ermöglichen
Signifikanzvektoren das Eingeben von nachweisbar bedeutungsvollen
oder relevanten Nullen und Einsen in modellspezifische Register
und nicht nur das Eingeben davon in modellspezifische Register,
was ein Techniker als bedeutungsvolle oder relevante Nullen und
Einsen betrachtet.
-
Das
Nachfolgende umfasst Definitionen und ausgewählte Ausdrücke, die hierin verwendet werden.
Die Definitionen können
verschiedene Beispiele umfassen, die in den Schutzbereich eines
Ausdrucks fallen. Die Beispiele sollen nicht einschränkend sein. Sowohl
Singular- als auch Plural-Formen von Ausdrücken können innerhalb der Definitionen
liegen.
-
„Computerkomponente", wie hierin verwendet,
bezieht sich auf eine computerverwandte Entität, wie z. B. Hardware, Firmware,
Software oder eine Kombination derselben. Computerkomponenten können z.
B. Folgendes umfassen: einen Prozess, der auf einem Prozessor läuft, einen
Prozessor, ein Objekt, ein Ausführelement,
einen Teilprozess einer Ausführung,
ein Programm, einen Computer, usw. Computerkomponenten können auf
einem Computer angeordnet sein und/oder zwischen zwei oder mehr Computern
verteilt sein.
-
„Computerlesbares
Medium", wie es
hierin verwendet wird, bezieht sich auf ein Medium, das am direkten
oder indirekten Liefern von Signalen, Anweisungen und/oder Daten
zu einer Computerkomponente teilnimmt. Ein computerlesbares Medium
kann Formen annehmen, wie z. B. ein nichtflüchtiges Medium (z. B. optische
Platte, magnetische Platte), flüchtige
Medien (z. B. Magnetplatte, dynamischer Speicher), Übertragungsmedien
(z. B. Koaxialkabel, Kupferdraht, Faser optikkabel) und ähnliches. Übertragungsmedien
können
die Form elektromagnetischer Strahlung annehmen, wie z. B. der,
die während
Radiowellen- und Infrarotdaten-Kommunikationen erzeugt wird, oder
kann die Form von einer oder mehreren Gruppen von Signalen annehmen.
Allgemeine Formen eines computerlesbaren Mediums umfassen Disketten,
Festplatten, Magnetbänder, CD-ROMs,
RAMs, ROMs, EPROMs, andere Speicher-Chips oder -Karten, Speicherstäbe, Träger-Wellen/-Pulse
und andere Medien aus denen ein Computer, ein Prozessor oder eine
andere elektronische Vorrichtung lesen kann. Signale, die zum Verbreiten von
Anweisungen oder anderer Software über ein Netzwerk verwendet
werden, wie z. B. das Internet, können als ein „computerlesbares
Medium" betrachtet
werden.
-
„Datenspeicher", wie er hierin verwendet wird,
bezieht sich auf eine physische und/oder logische Entität, die Daten,
die durch elektrische und/oder magnetische Signale dargestellt werden, speichern
kann. Ein Datenspeicher kann z. B. eine Datenbank, eine Tabelle,
eine Datei, eine Liste, eine Warteschlange, ein Freispeicher, ein
Speicher, ein Register usw. sein. Ein Datenspeicher kann in einer logischen
und/oder physischen Entität
vorliegen und/oder kann zwischen zwei oder mehr logischen und/oder
physischen Entitäten
verteilt sein.
-
„Logik", wie es hierin verwendet
wird, kann Hardware, Firmware, Software und/oder Kombinationen derselben
umfassen, die eine oder mehrere Funktionen oder Aktionen durchführen und/oder
die eine Funktion oder Aktion aus einer anderen Logik, einem Verfahren
und/oder einem System verursachen. Zum Beispiel kann eine Logik
einen softwaregesteuerten Mikroprozessor, eine diskrete Logik, wie z.
B. eine anwendungsspezifische integrierte Schaltung (ASIC), eine
programmierte Logikvorrichtung, eine Speichervorrichtung, die Anweisungen
enthält, usw.
umfassen. Eine Logik kann eines oder mehrere Gatter, Kombinationen
aus Gattern oder andere Schaltungskomponenten umfassen. Eine Logik
kann ferner vollständig
als Software verkörpert
sein. Wo mehrere logi sche Logiken beschrieben sind kann es möglich sein,
die mehreren logischen Logiken in eine physische Logik zu integrieren.
Auf ähnliche
Weise, wo eine einzelne logische Logik beschrieben ist, kann es
möglich
sein, diese einzelne logische Logik zwischen mehreren physischen
Logiken zu verteilen.
-
Eine „wirksame
Verbindung" oder
eine Verbindung, durch die Entitäten „wirksam
verbunden" oder „wirksam
verbindbar" sind,
ist eine, bei der Signale, physische Kommunikationen und/oder logische Kommunikationen
gesendet und/oder empfangen werden können. Üblicherweise umfasst eine wirksame
Verbindung eine physische Schnittstelle, eine elektrische Schnittstelle
und/oder eine Datenschnittstelle, aber eine wirksame Verbindung
kann unterschiedliche Kombinationen dieser oder anderer Typen von
Verbindungen umfassen, die ausreichend sind, um eine wirksame Steuerung
zu ermöglichen. Zum
Beispiel können
zwei Entitäten
wirksam dadurch verbunden sein, dass sie in der Lage sind, Signale
zueinander direkt oder durch Zwischencomputerkomponenten, Logiken
usw. zu kommunizieren. Logische und/oder physische Kommunikationskanäle können eine
wirksame Verbindung erzeugen.
-
„Signal", wie es hierin verwendet
wird, umfasst, ist jedoch nicht beschränkt auf eines oder mehrere
elektrische, magnetische oder optische Signale, analoge oder digitale
Signale, Daten, Computer- oder Prozessor-Anweisungen, Nachrichten,
Bit oder Bitstrom oder andere Einrichtungen, die empfangen, übertragen
und/oder durch eine Computerkomponente und/oder Logik erfasst werden
können.
-
„Software", wie hierin verwendet,
bezieht sich auf Computer- oder Prozessor-Anweisungen, die gelesen,
interpretiert, kompiliert und/oder ausgeführt werden können, um
zu verursachen, dass ein Computer, eine Computerkomponente, ein
Prozessor oder eine andere elektronische Vorrichtung eine oder mehrere
Aktionen ausführt
und/oder sich auf eine gewünschte
Weise verhält.
Die Anweisungen können
in ver schiedenen Formen verkörpert
sein, wie z. B. Routinen, Algorithmen, Modulen, Verfahren, Teilprozessen
und/oder Programmen, die separate Anwendungen oder Anweisungen aus
dynamisch verknüpften
Bibliotheken umfassen. Software kann in einer Vielzahl von ausführbaren
und/oder ladbaren Formen implementiert sein, einschließlich aber
nicht beschränkt
auf ein allein stehendes Programm, einen Funktionsruf (lokal und/oder
entfernt), ein Servelet, ein Applet, Anweisungen die in einem Speicher
gespeichert sind, Teil eines Betriebssystems oder andere Typen von
ausführbaren
Anweisungen. Software kann in einer Logik angeordnet sein und/oder
zwischen zwei oder mehr kommunizierenden, kooperierenden und/oder
parallelen Verarbeitungslogiken verteilt sein und kann somit auf
serielle, parallele, massiv parallele und andere Weisen geladen und/oder
ausgeführt
werden.
-
Eine
geeignete Software zum Implementieren verschiedener Komponenten
der Beispielsysteme und Verfahren umfasst Programmiersprachen und
Tools wie Java, Pascal, C#, C++, C, CGI, Perl, SQL, APIs, SDKs,
Anordnung, Firmware, Mikrocode, usw. Software, egal ob ein gesamtes
System oder eine Systemkomponente, kann als ein Herstellungsartikel
verkörpert
sein und als Teil eines computerlesbaren Mediums beibehalten oder
geliefert werden, wie vorangehend definiert wurde. Software kann
als Signale über
ein Netzwerk oder ein anderes Kommunikationsmedium übertragen
werden. Somit, bei einem Beispiel, nimmt ein computerlesbares Medium die
Form von Signalen an, die Software darstellen, wie sie von einem
Webserver zu einem Benutzer heruntergeladen wird. Bei einem anderen
Beispiel nimmt das computerlesbare Medium die Form von Software
an, wie sie auf dem Webserver beibehalten wird.
-
Einige
Abschnitte der nachfolgenden detaillierten Beschreibung werden im
Hinblick auf Algorithmen und symbolische Darstellung von Operationen an
Datenbits in einem Speicher präsentiert.
Diese algorithmischen Beschreibungen und symbolischen Darstellungen
sind Mittel, die durch Fachleute auf dem Gebiet verwendet werden,
um die Substanz ihrer Arbeit anderen zu übermitteln. Ein Algorithmus hier
und allgemein eine Sequenz von Operationen, die ein greifbares,
konkretes echtes Ergebnis erzeugen. Die Operationen können physische
Manipulationen physischer Elemente umfassen. Die physischen Elemente
können
die Form von elektrischen oder magnetischen Signalen annehmen, die
in der Lage sind, gespeichert, übertragen,
kombiniert, verglichen und anderweitig in einer Logik, einem Computerspeicher
und ähnlichem
manipuliert zu werden.
-
Es
hat sich zeitweilig als vorteilhaft herausgestellt, im Wesentlichen
aus Gründen
der allgemeinen Verwendung, diese Signale als Bits, Werte, Elemente,
Symbole, Zeichen, Ausdrücke,
Zahlen oder ähnliches
zu bezeichnen. Diese und ähnliche
Ausdrücke
sollen geeigneten physischen Artikeln zugeordnet werden und sind
nur bequeme Etiketten, die für
diese Artikel angewendet werden. In der Beschreibung beziehen sich
Ausdrücke
wie Verarbeiten, Rechnen, Berechnen, Bestimmen, Anzeigen oder ähnliches,
außer
anderweitig erwähnt,
auf Aktionen und Prozesse einer Computerkomponente, eines Prozessors
oder einer ähnlichen
elektronischen Vorrichtung, die Daten manipuliert und transformiert, die
als physische (elektronische) Quantitäten dargestellt sind.
-
1 stellt
ein Beispielsystem 100 zum Manipulieren von modellspezifischen
Registern dar. Das System 100 kann einen Datenspeicher 110 umfassen,
der konfiguriert ist, um einen Satz von Signifikanzvektoren zu speichern.
Ein Signifikanzvektor kann Informationen codieren, die sich darauf
beziehen, welche Bits in einem modellspezifischen Register, das
sich auf den Signifikanzvektor bezieht, bei einer Prozessorsimulation
relevant sind. Zum Beispiel kann ein modellspezifisches Register
ein erstes Bit aufweisen, das steuert, ob ein Prozessor in einen ersten
Modus eintritt, und ein zweites Bit, das steuert, ob der Prozessor
in einen zweiten Modus eintritt. Wenn zu einem bestimmten Zeitpunkt
bei der Prozessorentwicklung der erste Modus implementiert wurde,
dann kann das erste Bit relevant für einen Simulationsdurchlauf
sein, und ein Signifikanzvektor, der an ein modellspezifisches Register
angewendet wird, würde
dieses Bit nicht ausblenden. Wenn jedoch, zu diesem Zeitpunkt bei
der Prozessorentwicklung, der zweite Modus nicht implementiert wurde, dann
ist das zweite Bit möglicherweise
nicht relevant und ein Signifikanzvektor könnte dieses Bit ausblenden.
-
Das
System 100 kann ferner eine modellspezifische Registerlogik 120 umfassen,
die wirksam mit dem Datenspeicher 110 verbunden ist. Die
modellspezifische Registerlogik 120 kann konfiguriert sein, um
das Initialisieren eines modellspezifischen Registers zu ermöglichen,
das einem Prozessorsimulator zugeordnet ist, auf einen anfänglichen
Wert, der relevant für
eine Prozessorsimulation ist. Die modellspezifische Registerlogik 120 kann
ein Teil des Satzes von Signifikanzvektoren anwenden, um die Konfiguration
zu erreichen. Wann und wie der Signifikanzvektor angewendet werden
kann, kann von der Konfiguration einer Verifikationsumgebung abhängen.
-
Somit
stellt 2 ein Beispielsystem 200 zum Manipulieren
von modellspezifischen Registern dar, das verschiedene Verfahren
zum Anwenden eines Signifikanzvektors darstellt. Das System 200 kann
einen Datenspeicher 210 umfassen, in dem die Signifikanzvektoren
gespeichert sind, und eine modellspezifische Registerlogik 220,
die konfiguriert ist, um diese Signifikanzvektoren anzuwenden. Die
Signifikanzvektoren können
angewendet werden, um das Konfigurieren eines modellspezifischen
Registers in einem Prozessorsimulator auf einen bekannten gültigen anfänglichen
Wert zu ermöglichen.
Bei einem Beispiel kann die modellspezifische Registerlogik 220 konfiguriert
sein, um einen oder mehrere Signifikanzvektoren an Testfalldaten
anzuwenden, die in einem Testfalldatenspeicher 230 gespeichert
sind. Die Testfalldaten können
für einen
Prozessorsimulationsinitialisierer 240 verfügbar sein.
Bei einem anderen Beispiel kann die modell spezifische Registerlogik 220 konfiguriert
sein, um einen Signifikanzvektor an Simulationsdaten anzuwenden,
die in einem Simulationsdatenspeicher 250 gespeichert sind.
Die Simulationsdaten können
für einen
Prozessorsimulator 260 verfügbar sein und können Daten
und/oder Anweisungen umfassen, die durch den Prozessorsimulationsinitialisierer 240 erzeugt
werden. Bei einem wiederum anderen Beispiel kann die modellspezifische
Registerlogik 220 konfiguriert sein, um einen Signifikanzvektor
an ein maschinenspezifisches Register anzuwenden, das dem Simulator 260 zugeordnet ist.
Das maschinenspezifische Register kann vorangehend durch den Prozessorsimulationsinitialisierer 240 initialisiert
worden sein. Bei diesem Beispiel, bei dem die modellspezifische
Registerlogik 220 eine Signifikanzvektor an ein modellspezifisches
Register in dem Simulator 260 anwendet, kann die modellspezifische
Registerlogik 220 eine logische UND-Operation zwischen
den Inhalten des modellspezifischen Registers und des Signifikanzvektors
durchführen.
-
Die
modellspezifische Registerlogik 220 kann ferner konfiguriert
sein, um verschiedene Aktionen zu unternehmen, basierend auf dem
Erfassen, dass ein Signifikanzvektor einen modellspezifischen Registerinhalt
geändert
hat. Die Aktionen können
z. B. vom Benutzer konfigurierbar und/oder vorbestimmbar sein. Somit
kann die modellspezifische Registerlogik 220 bei einem
Beispiel konfiguriert sein, um zu verhindern, dass ein Prozessorsimulationsinitialisierer 240 einen
Prozessorsimulator 260 initialisiert. Bei einem anderen
Beispiel kann die modellspezifische Registerlogik 220 konfiguriert
sein, um zu verhindern, dass ein Prozessorsimulator 260 eine Fehlermeldung
abspielt und/oder erzeugt, die ein irrelevantes modellspezifisches
Registerbit betrifft, das gesetzt wird. Zusätzlich dazu kann die modellspezifische
Registerlogik 220 ferner konfiguriert sein, um einem Benutzer
eine Wahlmöglichkeit
zu präsentieren,
im Hinblick darauf ob eine Prozessorsimulation durchgeführt werden
soll, wenn die modellspezifische Registerlogik 220 bestimmt,
dass ein irrelevantes modellspezifisches Regis terbit gesetzt ist.
Zum Beispiel kann eine Warnmeldung präsentiert werden, die einen
Tester warnt, dass ein modellspezifisches Registerbit geändert wurde
und dass der Test, der abgespielt wird, möglicherweise nicht genau ihr
Denken im Hinblick auf anfängliche
Register- und/oder Prozessor-Zustände reflektiert.
-
3 stellt
ein Beispielsystem 300 zum Erwerben von Prozessorstatusregister-Bitübergangsdaten
dar. Das System 300 kann einen Datenspeicher 310 umfassen,
der konfiguriert ist, um Prozessorstatusbitübergangsdaten zu speichern.
Die Prozessorstatusbitübergangsdaten
können
Informationen codieren, die Prozessorstatusbitübergänge betreffen, die während einer
Prozessorsimulation auftreten. Zum Beispiel kann ein erstes Prozessorstatusbit
gesetzt werden, wenn ein Prozessor von einem ersten Prozessormodus
in einen zweiten Prozessormodus schaltet.
-
Das
System 300 kann ferner eine Prozessorstatusregisterlogik 320 umfassen,
die wirksam mit dem Datenspeicher 310 verbunden ist. Die
Prozessorstatusregisterlogik 320 kann konfiguriert sein,
um einen Prozessorstatusbitübergang
zu erfassen, der während
einer Prozessorsimulation auftritt. Auf ähnliche Weise kann die Prozessorstatusregisterlogik 320 konfiguriert
sein, um die Prozessorstatusbitübergangsdaten
in dem Datenspeicher 310 zu speichern. Bei einem Beispiel
kann die Prozessorstatusregisterlogik 320 konfiguriert
sein, um Prozessorstatusbitübergänge zu erfassen,
während
eine Prozessorsimulation läuft.
Bei einem anderen Beispiel kann die Prozessorstatusregisterlogik 320 konfiguriert
sein, um Prozessorstatusbitübergänge zu erfassen,
nachdem eine Prozessorsimulation abgeschlossen ist.
-
Somit
stellt 4 ein Beispielsystem 400 zum Erwerben
von Prozessorstatusregisterbitübergangsdaten
dar. Das System 400 kann einen Datenspeicher 410 zum
Speichern von Prozessorstatusbitübergangsdaten
und eine Prozessorstatusregisterlogik umfassen, die konfiguriert
ist, um Prozessorregis terstatusbitübergänge zu erfassen und die Prozessorstatusregisterbitübergangsdaten
zu speichern. Eine Verifikationsumgebung, mit der das System 400 interagiert,
kann einen Testfalldatenspeicher 430 umfassen, der Testfalldaten
speichert, wie z. B. Testvektoren, und liefert diese Testfalldaten
zu einem Prozessorsimulationsinitialisierer 440. Der Initialisierer 440 kann
Simulationsdaten erzeugen, die in einem Simulationsdatenspeicher 450 gespeichert
werden können.
Die Simulationsdaten können
das Erzeugen von anfänglichen
Bedingungen, Zuständen, Modi
usw. in einem Simulator 460 ermöglichen. Der Simulator 460 kann
eine Prozessorsimulation betreiben und Abdeckungsinformationen,
Bitübergangsinformationen
und ähnliches
in Simulationsergebnisdaten speichern, die in einem Simulationsergebnisdatenspeicher 470 gespeichert
sind.
-
Bei
einem Beispiel kann die PSR-Logik 420 konfiguriert sein,
um Prozessorstatusregisterbitübergänge zu erfassen,
während
der Simulator 460 eine Prozessorsimulation betreibt. Bei
einem anderen Beispiel kann die Prozessorstatusregisterlogik 420 konfiguriert
sein, um Prozessorstatusregisterbitübergänge zu erfassen, durch Untersuchen
der Simulationsdaten, die in dem Simulationsergebnisdatenspeicher 470 gespeichert
sind. Zusätzlich
und/oder alternativ kann die Prozessorstatusregisterlogik 420 einige
Prozessorstatusregisterbitübergänge von
dem Simulator 460 und anderen erfassen, durch Untersuchen
des Simulationsergebnisdatenspeichers 470.
-
5 stellt
ein Beispielsystem 500 dar, zum Manipulieren von modellspezifischen
Registern und Erwerben von Prozessorstatusregisterbitübergangsdaten.
Das System 500 kombiniert Elemente des Systems 100 (1)
und des Systems 300 (3) und interagiert
mit einer Verifikationsumgebung. Die Verifikationsumgebung, mit
der das System 500 interagiert, kann einen Testfalldatenspeicher 550 umfassen,
der Testfalldaten speichert, wie z. B. Testvektoren, und diese Testfalldaten
zu einem Prozessorsimulationsinitialisierer 560 liefert.
Der Initialisierer 560 kann Simulationsdaten erzeugen,
die in einem Simulationsdatenspeicher 570 gespeichert werden
können.
Die Simulationsdaten können
das Erzeugen von anfänglichen
Bedingungen, Zuständen,
Modi usw. in einem Simulator 580 ermöglichen. Der Simulator 580 kann
eine Prozessorsimulation betreiben und Abdeckungsinformationen,
Bitübergangsinformationen und ähnliches
in Simulationsergebnisdaten speichern, die in einem Simulationsergebnisdatenspeicher 590 gespeichert
sind.
-
Das
System 500 kann einen ersten Datenspeicher 510 umfassen,
der konfiguriert ist, um einen Satz von Signifikanzvektoren zu speichern,
die Informationen codieren, die sich darauf beziehen, welche Bits
in einem modellspezifischen Register, die sich auf den Signifikanzvektor
beziehen, bei einer Prozessorsimulation relevant sind. Das System 500 kann ferner
eine modellspezifische Registerlogik 520 umfassen, die
wirksam mit dem ersten Datenspeicher 510 verbunden ist.
Die modellspezifische Registerlogik 520 kann konfiguriert
sein, um das Initialisieren eines modellspezifischen Registers zu
ermöglichen, das
dem Prozessorsimulator 580 zugeordnet ist, auf einen anfänglichen
Wert, der für
die Prozessorsimulation relevant ist.
-
Das
System 500 kann ferner einen zweiten Datenspeicher 530 umfassen,
der konfiguriert ist, um Prozessorstatusbitübergangsdaten zu speichern,
die Informationen betreffend Prozessorstatusbitübergänge codieren, die während des
Prozessorsimulationsbetriebs durch den Simulator 580 auftreten.
Das System 500 kann ferner eine Prozessorstatusregisterlogik 540 umfassen,
die wirksam mit dem zweiten Datenspeicher 530 verbunden
ist. Die Prozessorstatusregisterlogik 540 kann konfiguriert
sein, um einen Prozessorstatusregisterbitübergang zu erfassen, der während eines
Prozessorsimulationsbetriebs durch den Simulator 580 auftritt.
Nach dem Erfassen, dass ein Prozessorstatusregister-Bitübergang
aufgetreten ist, kann die Prozessorstatusregisterlogik 540 Prozessorstatusbitübergangsdaten
in dem zweiten Datenspeicher 530 speichern.
-
Wie
oben beschrieben wurde, kann eine modellspezifische Registerlogik
konfiguriert sein, um Signifikanzvektoren zu verschiedenen Zeitpunkten
an verschiedene Daten und/oder Register anzuwenden. Somit kann die
modellspezifische Registerlogik 520 konfiguriert sein,
um einen Signifikanzvektor an Testfalldaten, die für den Prozessorsimulationsinitialisierer 560 verfügbar sind,
an Simulationsdaten, die für einen
Prozessorsimulator 580 durch den Prozessorsimulationsinitialisierer 560 verfügbar sind,
an ein maschinenspezifisches Register, das dem Prozessorsimulator 580 zugeordnet
ist, usw., anzuwenden.
-
Bei
einer Konfiguration kann das System 500 vom Benutzer konfigurierbare
und/oder dynamisch aktualisierbare Aktionen basierend auf der modellspezifischen
Registerlogik 520 unternehmen, die erfasst, dass das Anwenden
eines Signifikanzvektors einen modellspezifischen Registerlogikinhalt
geändert
hat. Somit kann die modellspezifische Registerlogik 520 konfiguriert
sein, um Aktionen durchzuführen,
wie z. B. den Prozessorsimulationsinitialisierer 560 daran
zu hindern, den Prozessorsimulator 580 zu initialisieren,
den Prozessorsimulator 580 daran zu hindern, eine Fehlermeldung
betreffend ein irrelevantes modellspezifisches Registerbit zu betreiben oder
zu erzeugen, das gesetzt wird, dem Benutzer eine Auswahlmöglichkeit
zu präsentieren,
ob eine Prozessorsimulation betrieben werden soll, usw.
-
Bei
einem Beispiel kann die Prozessorstatusregisterlogik 540 konfiguriert
sein, um Prozessorstatusbitübergänge zu erfassen,
während
eine Prozessorsimulation betrieben wird, nachdem eine Prozessorsimulation
abgeschlossen wurde, Kombinationen derselben, usw.
-
6 stellt
ein Beispielsystem zum 600 Korrelieren von Prozessorstatusregisterbitübergangsdaten
mit modellspezifi schen Registermanipulationen dar. Das System 600 kann
einen ersten Datenspeicher 610 und eine modellspezifische
Registerlogik 620 ähnlich
zu jenen umfassen, die oben beschrieben wurden. Auf ähnliche
Weise kann das System 600 einen zweiten Datenspeicher 630 und
eine Prozessorstatusregisterlogik 640 ähnlich zu jenen umfassen, die
oben beschrieben wurden. Zusätzlich dazu
kann das System 600 eine Verhältnislogik 650 umfassen,
die konfiguriert ist, um eine Beziehung zwischen Prozessorstatusbitübergangsdaten,
die in einem Datenspeicher 630 gespeichert sind, und dem relevanten
Anfangswert zu bestimmen, zu dem die modellspezifische Registerlogik 620 ein
modellspezifisches Register konfiguriert hat, basierend auf einem Signifikanzvektor,
der in dem Datenspeicher 610 gespeichert ist. Die Beziehung
kann z. B. Folgendes umfassen: Bestimmen, ob Prozessorstatusregisterbitübergänge aufgetreten
sind und/oder unterschiedlich waren, basierend auf denen, falls
vorhanden, Signifikanzvektoren durch die modellspezifische Registerlogik
angewendet wurden. Zusätzlich
und/oder alternativ kann die Beziehung z. B. das Bestimmen umfassen,
ob bestimmte Prozessormodi während
einer Simulation abgedeckt wurden, bei der ein bestimmter Signifikanzvektor
durch das modellspezifische Register 620 angewendet wurde.
Während
zwei Beziehungen beschrieben wurden, wird darauf hingewiesen, dass
auch andere Beziehungen untersucht werden können.
-
7 stellt
ein Beispielsystem 700 zum Bewerten der Prozessormodusabdeckung
dar. Das System 700 kann einen ersten Datenspeicher 710 und
eine modellspezifische Registerlogik 720 ähnlich zu
jenen umfassen, die oben beschrieben wurden. Auf ähnliche
Weise kann das System 700 einen zweiten Datenspeicher 730 und
eine Prozessorstatusregisterlogik 740 ähnlich zu jenen umfassen, die
oben beschrieben wurden. Auf ähnliche
Weise kann das System 700 eine Verhältnislogik 750 ähnlich zu
der umfassen, die oben beschrieben wurde. Zusätzlich dazu kann das System 700 eine
Abdeckungslogik 760 umfassen, die konfiguriert ist, um
zu bestimmen, ob eine gewünschte
Prozessormodusabdeckung durch eine Prozessorsi mulation erreicht
wurde. Bei einem Beispiel bestimmt die Abdeckungslogik 760, ob
die gewünschte
Prozessormodusabdeckung erreicht wurde, durch Identifizieren, ob
eine erforderliche Anzahl und Vielzahl von definierten Ereignissen während der
Prozessorsimulation aufgetreten ist. Definierte Ereignisse können z.
B. eine Anweisung umfassen, die ausgeführt wird, eine L1-Cacheoperation,
die auftritt, eine L2-Cacheoperation,
die auftritt, ein auftretendes Interrupt, eine auftretende Registerübertragungssprachenaktion,
eine auftretende Cache-Spülung
und einen auftretenden Speicherabruf. Die Abdeckungslogik 760 kann
Abdeckungsinformationen in einem Abdeckungsdatenspeicher 770 speichern,
was z. B. das Erzeugen von formatierten Berichten im Hinblick auf
Abdeckung ermöglichen
kann.
-
Beispielverfahren
sind besser verständlich Bezug
nehmend auf die Flussdiagramme aus 8 und 11.
Während
zu Zwecken der Einfachheit der Erklärung die Beispielmethoden als
eine Reihe von Aktionen beschrieben sind, wird darauf hingewiesen,
dass die Methoden nicht durch die Reihenfolge der Aktionen eingeschränkt sind,
da einige in unterschiedlichen Reihenfolgen und/oder gleichzeitig mit
anderen auftreten können.
Ferner können
weniger als die dargestellten Aktionen erforderlich sein, um eine
Beispielmethode zu implementieren. Ferner können zusätzliche und/oder alternative
Methoden zusätzliche,
nicht dargestellte Aktionen verwenden.
-
In
Flussdiagrammen bezeichnen Blöcke
Aktionen, die mit einer Logik implementiert werden können. Ein
Flussdiagramm zeigt keine Syntax für eine bestimmte Programmiersprache,
eine Methode oder einen Stil (z. B. verfahrensorientiert, objektorientiert). Statt
dessen stellt ein Flussdiagramm Funktionsinformationen dar, die
ein Durchschnittsfachmann auf dem Gebiet verwenden kann, um eine
Logik zu entwickeln, um die dargestellte Verarbeitung auszuführen. Es
wird darauf hingewiesen, dass bei einigen Beispielen Programmelemente
wie temporäre
Variablen, Routineschleifen usw. nicht gezeigt sind. Es wird darauf
hingewiesen, dass die Aktionen unter Verwendung verschiedener Programmierlösungsansätze implementiert
werden können,
wie z. B. einer Maschinensprache, verfahrensorientiert, objektorientiert
und/oder mit Künstliche-Intelligenz-Techniken.
-
8 stellt
ein Beispielverfahren 800 zum Verhindern dar, das irrelevante
modellspezifische Registerbits bei einer Prozessorsimulation gesetzt werden,
und zum Erwerben von Prozessorstatusregisterbitübergangsdaten von einer Prozessorsimulation.
Das Erwerben der Prozessorstatusregisterbitübergangsdaten kann das Bestimmen
der Prozessormodusabdeckung erleichtern, die während einer Simulation erreicht
wird.
-
Das
Verfahren 800 kann bei 810 das Konfigurieren eines
modellspezifischen Registers umfassen, das einem Prozessorsimulator
zugeordnet ist, mit einem Anfangswert, der bekannterweise relevant für eine Prozessorsimulation
ist. Bei einem Beispiel umfasst das Konfigurieren eines modellspezifischen Registers,
das einem Prozessorsimulator zugeordnet ist, das Durchführen einer
logischen UND-Verknüpfung
der Inhalte eines modellspezifischen Registers, das durch einen
Prozessorsimulationsinitialisierer und einen Signifikanzvektor initialisiert
wird, der dem modellspezifischen Register zugeordnet ist. Der Anfangswert
für das
modellspezifische Register kann das Steuern von Angelegenheiten
ermöglichen,
ob ein Kern bei der Prozessorsimulation betriebsfähig ist,
ob ein Satz von Kernen bei einem Verriegelungsschrittmodus bei der
Prozessorsimulation wirksam ist, welcher Typ eines Cachekohärenzprotokolls
bei der Prozessorsimulation verwendet wird, ob ein geschütztes Speichermodell
bei der Prozessorsimulation verwendet wird, und ähnliches.
-
Das
Verfahren 800 kann ferner bei 820 das Erfassen
eines Bitübergangs
umfassen, der in einem Prozessorstatusregister während der Prozessorsimulation
auftritt. Der Bitübergang
kann zu Zeiten erfasst werden, wie z. B. während eine Pro zessorsimulation
läuft,
nachdem die Prozessorsimulation gelaufen ist, usw.
-
Das
Verfahren 800 kann ferner bei 830 das Bestimmen
umfassen, ob eine gewünschte
Prozessormodusabdeckung durch eine Prozessorsimulation erreicht
wurde. Bei einem Beispiel kann das Bestimmen, ob die gewünschte Abdeckung
erreicht wurde, das Analysieren einer Beziehung zwischen dem erfassten
Bitübergang
in dem Prozessorstatusregister und dem Anfangswert umfassen, auf
den das modellspezifische Register konfiguriert wurde. Bei einem
anderen Beispiel umfasst das Bestimmen, ob eine gewünschte Prozessormodusabdeckung
erreicht wurde, das Identifizieren des Typs und der Anzahl von definierten
Ereignissen, die während
der Prozessorsimulation aufgetreten sind. Das Auftreten eines definierten
Ereignisses kann identifiziert werden durch Analysieren eines Bitübergangs
in einem Prozessorstatusregister. Definierte Ereignisse können z.
B. eine Anweisung umfassen, die ausgeführt wird, eine auftretende
L1-Cacheoperation, eine auftretende L2-Cacheoperation, ein auftretendes
Interrupt, eine auftretende Registerübertragungssprachenaktion,
eine auftretende Cache-Ausströmung, einen
auftretenden Speicherabruf, usw.
-
Während 8 verschiedene
Aktionen darstellt, die in Reihe auftreten, wird darauf hingewiesen, dass
verschiedene Aktionen, die in 8 dargestellt sind,
im Wesentlichen parallel auftreten könnten. Auf darstellende Weise
könnte
ein erster Prozess ein modellspezifisches Register auf einen Anfangswert
konfigurieren, der Bekannterweise relevant für eine Prozessorsimulation
ist, ein zweiter Prozess könnte
Bitübergänge erfassen,
die in dem Prozessorstatusregister während der Prozessorsimulation
auftreten, und ein dritter Prozess könnte bestimmen, ob eine gewünschte Prozessormodusabdeckung
durch die Prozessorsimulation erreicht wurde. Während drei Prozesse beschrieben
sind, wird darauf hingewiesen, dass eine größere und/oder geringere Anzahl
von Prozessen verwendet werden könnte,
und dass leichte Prozesse, reguläre
Prozesse, Teilprozesse und andere Lösungsansätze verwendet werden könnten.
-
Bei
einem Beispiel werden Methoden als prozessorausführbare Anweisungen und/oder
Operationen implementiert, die auf einem computerlesbaren Medien
gespeichert sind. Somit kann bei einem Beispiel ein computerlesbares
Medium prozessorausführbare
Anweisungen speichern, die wirksam sind, um ein Verfahren auszuführen, das
das Konfigurieren eines modellspezifischen Registers umfasst, das
einer Prozessorsimulation zugeordnet ist, mit einem Anfangswert,
der bekanntlicherweise relevant für die Prozessorsimulation ist.
Der Anfangswert kann z. B. das Steuern ermöglichen, ob ein Kern bei der
Prozessorsimulation betriebsfähig
ist, ob ein Satz von Kernen in einem Verriegelungsschrittmodus bei der
Prozessorsimulation wirkt, welcher Typ eines Cachekohärenzprotokolls
bei der Prozessorsimulation verwendet wird und ob ein geschütztes Speichermodell
bei der Prozessorsimulation verwendet wird. Das Verfahren kann ferner
das Erfassen eines Bitübergangs
umfassen, der in einem Prozessorstatusregister während der Prozessorsimulation
auftritt, und das Bestimmen, ob eine gewünschte Prozessormodusabdeckung
durch die Prozessorsimulation erreicht wurde, durch Analysieren
einer Beziehung zwischen dem erfassten Bitübergang in dem Prozessorstatusregister,
dem Anfangswert, auf den das modellspezifische Register konfiguriert
wurde und dem Typ und der Anzahl von definierten Ereignissen, die
während
der Prozessorsimulation aufgetreten sind. Das Auftreten eines definierten
Ereignisse kann z. B. identifiziert werden durch Analysieren eines
Bitübergangs
in einem Prozessorstatusregister. Ein definiertes Ereignis kann
z. B. eine Anweisung umfassen, die ausgeführt wird, eine auftretende
L1-Cacheoperation,
eine auftretende L2-Cacheoperation, ein auftretendes Interrupt,
eine auftretende Registerübertragungssprachenaktion,
eine auftretende Cachespülung
und einen auftretenden Speicherabruf.
-
Während das
obige Verfahren derart beschrieben ist, dass es auf einem computerlesbaren Medium
gespeichert ist, wird darauf hingewiesen, dass andere hierin beschriebene
Beispielverfahren ebenfalls auf einem computerlesbaren Medium gespeichert
sein können.
-
9 stellt
einen Computer 900 dar, der einen Prozessor 902,
einen Speicher 904, und Eingangs-/Ausgangs-Tore 910 erfasst,
die wirksam durch einen Bus 908 verbunden sind. Bei einem
Beispiel kann der Computer 900 ein MSR/PSR-System 930 umfassen,
das konfiguriert ist, um das Bewerten der Prozessormodusabdeckung
bei einer Prozessorsimulation zu ermöglichen. Egal ob es als Hardware, Firmware,
Software und/oder Kombinationen derselben implementiert ist, schafft
das MSR/PSR-System 930 eine Einrichtung zum Einrichten
eines gewünschten
Zustands in einem modellspezifischen Register, auf das durch einen
Prozessorsimulator zugegriffen werden soll, eine Einrichtung zum
Erfassen eines Bitzustandübergangs
in einem Prozessorstatusregister, das durch den Prozessorsimulator
beschreibbar ist, und eine Einrichtung zum Bestimmen, ob eine gewünschte Prozessormodusabdeckung durch
den Prozessorsimulator erreicht wurde, durch Vergleichen des erfassten
Bitzustandsübergangs
mit dem gewünschten
Zustand in dem modellspezifischen Register.
-
Der
Prozessor 902 kann eine Vielzahl von Prozessoren sein,
einschließlich
einem Dualmikroprozessor und anderer Mehrfachprozessorarchitekturen.
Der Speicher 904 kann einen flüchtigen Speicher (z. B. RAM,
Synchron-RAM (SRAM), dynamischen RAM (DRAM), synchronen DRAM (SDRAM), Doppeldatenraten-SDRAM
(DDSDRAM), Direkt-RAM-Bus-RAM (DRRAM)), einen nichtflüchtigen Speicher
(z. B. ROM, PROM, EPROM, EEPROM) und ähnliches umfassen.
-
Eine
Platte 906 kann wirksam mit dem Computer 900 z.
B. über
eine Eingangs-/Ausgangs-Schnittstelle (z. B. Karte, Vorrichtung) 918 und ein
Eingangs-/Ausgangs-Tor 910 verbunden sein. Die Platte 906 kann
formen annehmen, wie z. B. ein Magnetplattenlaufwerk, ein Festkörperzustand-Plattenlaufwerk,
ein Diskettenlaufwerk, ein Bandlaufwerk, ein Zip-Laufwerk, eine Flashspeicherkarte, einen
Speicherstab und ähnliches.
Ferner kann die Platte 906 Formen annehmen wie optische
Laufwerke, wie z. B. eine CD-ROM, ein CD-bespielbares Laufwerk (CD-R-Laufwerk),
ein CD-wiederbeschreibbares Laufwerk (CD-RW-Laufwerk) und/oder ein
digitales Video-ROM-Laufwerk
(DVD ROM). Der Speicher 904 kann z. B. Prozesse 914 und/oder
Daten 916 speichern. Die Platte 906 und/oder der
Speicher 904 können
ein Betriebssystem speichern, das konfiguriert ist, um Ressourcen
des Computers 900 zu steuern und zuzuweisen.
-
Der
Bus 908 kann eine einzelne interne Busverbindungsarchitektur
und/oder eine andere Bus- oder Netz-Architektur sein. Während ein
einzelner Bus dargestellt ist, wird darauf hingewiesen, dass der Computer 900 mit
verschiedenen Vorrichtungen, Logiken und Peripheriegeräten unter
Verwendung anderer Busse kommunizieren kann, die nicht dargestellt
sind (z. B. PCIE, SATA, Infiniband, 1394, USB, Ethernet). Der Bus 908 kann
Formen annehmen, wie ein Speicherbus oder eine Speichersteuerung,
ein Peripheriegerätebus
oder ein externer Bus, ein Crossbar-Schalter, ein lokaler Bus, usw.
Der lokale Bus kann Formen annehmen, wie z. B. ein Bus einer industriellen
Standardarchitektur (ISA), ein Bus einer Mikrokanalarchitektur (MSA),
ein Bus einer erweiterten ISA (EISA), ein Bus einer Peripheriekomponentenverbindung
(PCI), ein universeller serieller Bus (USB), ein Kleincomputer-Schnittstellenbus
(SCSI-Bus), usw.
-
Der
Computer 900 kann mit Eingabe-/Ausgabe-Vorrichtungen über I/O-Schnittstellen 918 und Eingangs-/Ausgangs-Tore
interagieren. Die Eingabe-/Ausgabe-Vorrichtungen können z.
B. eine Tastatur, ein Mikrofon, eine Zeige- und Auswahl-Vorrichtung, Kameras,
Videokarten, Anzeigen, eine Platte 906, Netzwerkvorrichtungen 920 und ähnliches
umfassen. Die Eingangs-/Ausgangs-Tore 910 können z. B.
serielle Tore, parallele Tore, USB-Tore usw. umfassen.
-
Der
Computer 900 kann in einer Netzwerkumgebung arbeiten und
kann somit mit Netzwerkvorrichtungen 920 über die
I/O-Vorrichtungen 918 und/oder
die I/O-Tore 910 verbunden sein. Durch die Netzwerkvorrichtungen 920 kann
der Computer 900 mit einem Netzwerk interagieren. Durch
das Netzwerk kann der Computer 900 logisch mit entfernten Computern
verbunden sein. Netzwerke, mit denen der Computer 900 interagieren
kann, können
z. B. ein lokales Netz (LAN), ein weites Netz (WAN), usw. umfassen.
Die Netzwerkvorrichtungen 920 können mit LAN-Techniken verbunden
sein, wie z. B. faserverteilte Datenschnittstelle (FDDI), kupferverteilte
Datenschnittstelle (CDDI), Ethernet (IEEE 902.3), Token-Ring (IEEE
902.5), drahtlose Computerkommunikation (IEEE 902.11), Bluetooth
(IEEE 902.15.1), Zigbee (IEEE 802.15.4) und ähnliches. Auf ähnliche Weise
können
die Netzwerkvorrichtungen 920 mit WAN-Techniken verbunden
sein, wie z. B. Punkt-zu-Punkt-Verknüpfungen,
Schaltungs-Schaltnetzwerken, wie z. B. integrierten digitalen Dienstnetzwerken
(ISDN), Paketschaltnetzwerken, digitalen Teilnehmeranschlussleitungen
(DSL), usw.
-
Bezug
nehmend nun auf 10 ist eine Anwendungsprogrammierungsschnittstelle
(API) 1000 dargestellt, die Zugriff auf ein MSR/PSR-System 1010 liefert.
Die API 1000 kann verwendet werden, z. B. durch einen Programmierer 1020 und/oder einen
Prozess 1030, um Zugriff auf die Verarbeitung zu gewinnen,
die durch das MSR/PSR-System 1010 durchgeführt wird.
Zum Beispiel kann ein Programmierer 1020 ein Programm schreiben,
um auf das MSR/PSR-System 1010 zuzugreifen (z. B. seine Operation
aufzurufen, seine Operation zu überwachen,
seine Operation zu steuern), wobei das Schreiben des Programms durch
das Vorhandensein der API 1000 ermöglicht wird. Der Programmierer 1020 muss
die internen Vorgänge
des MSR/PSR-Systems 1010 nicht verstehen, sondern der Programmierer 1020 muss
nur die Schnittstelle zu dem MSR/PSR-System 1010 kennen.
Dies ermöglicht das
Einkapseln der Funktionalität
des MSR/PSR-Systems 1010, wäh rend diese Funktionalität freigelegt
wird. Auf ähnliche
Weise kann die API 1000 verwendet werden, um Datenwerte
zu dem MSR/PSR-System 1010 zu liefern und/oder Datenwerte
von dem MSR/PSR-System 1010 wiederzugewinnen. Zum Beispiel
kann ein Prozess 1030 Signifikanzvektoren zu dem MSR/PSR-System 1010 über die
API 1000 unter Verwendung eines Rufs liefern, der in der
API 1000 geliefert wird.
-
Somit
kann bei einem Beispiel der API 1000 ein Satz von Anwendungsprogrammierungsschnittstellen
auf einem computerlesbaren Medium gespeichert werden. Die Schnittstellen
können
durch einen Programmierer 1020, eine Computerkomponente, eine
Logik, einen Prozess 1030 usw. verwendet werden, um Zugriff
auf ein MSR/PSR-System 1010 zu gewinnen. Die Schnittstellen
können
Folgendes umfassen, sind jedoch nicht darauf beschränkt: eine
erste Schnittstelle 1040, die einen modellspezifischen Registersignifikanzvektor
kommuniziert, eine zweite Schnittstelle 1050, die PSR-Bitfeld-Übergangsdaten kommuniziert
und eine dritte Schnittstelle 1060, die Abdeckungsdaten
kommuniziert, die aus dem modellspezifischen Registersignifikanzvektor,
und dem Prozessorstatusregister-Bitfeldübergang hergeleitet werden,
interpretiert im Hinblick auf einen Prozessorsimulationslauf.
-
11 stellt
ein Beispielverfahren 1100 zum Durchführen von Auswahlen dar, die
modellspezifische Registermanipulationen betreffen. Das Verfahren 1100 kann
z. B. in einem Computersystem verwendet werden, das eine grafische
Benutzerschnittstellenvorrichtung umfasst. Das Verfahren 1100 kann ein
Verfahren unterstützen
zum Liefern und Auswählen
aus einem Satz von Dateneinträgen
auf der Anzeige. Das Verfahren 1100 kann bei 1110 das
Wiedergewinnen eines Satzes von Dateneinträgen umfassen. Ein Dateneintrag
kann z. B. eine modellspezifische Registerkonfigurationsoperation
darstellen. Das Verfahren 1100 kann ferner bei 1120 das
Anzeigen des Satzes aus Dateneinträgen auf der Anzeige und bei 1130 das
Empfangen eines Dateneintrags-Auswahlsignals um fassen, das die Auswahlvorrichtung
anzeigt, die einen ausgewählten
Dateneintrag auswählt.
-
Nach
dem Empfangen eines Dateneintrags-Auswahlsignals kann das Verfahren 1100 bei 1140 fortschreiten,
um eine modellspezifische Registerkonfigurationsoperation zu initiieren,
die dem ausgewählten
Dateneintrag zugeordnet ist. Bei 1150 kann eine Bestimmung
dahingehend gemacht werden, ob ein anderes Dateneintragsauswahlsignal verarbeitet
werden soll. Wenn die Bestimmung Ja lautet, dann kann die Verarbeitung
zu 1130 zurückkehren,
ansonsten kann die Verarbeitung abgeschlossen werden.
-
Während Beispiel-Systeme,
-Verfahren usw. relativ detailliert durch Beschreiben von Beispielen dargestellt
und beschrieben wurden, sollen die Beispiele den Schutzbereich der
beiliegenden Ansprüche
nicht einengen oder einschränken.
Es ist natürlich
nicht möglich,
jede denkbare Kombination von Komponenten oder Methoden zu Zwecken
des Beschreibens der Systeme, Verfahren usw. zu beschreiben, die
hierin beschrieben sind. Zusätzliche
Vorteile und Modifikationen sind für Fachleute auf dem Gebiet offensichtlich.
Daher ist die Erfindung nicht auf die spezifischen Details, die
darstellende Vorrichtung und die darstellenden Beispiele eingeschränkt, die gezeigt
und beschrieben sind. Diese Anmeldung soll Änderungen, Modifikationen und
Abweichungen umfassen, die in den Schutzbereich der beiliegenden Ansprüche fallen,
und somit soll der Schutzbereich der Erfindung durch die beiliegenden
Ansprüche
und ihre Entsprechungen bestimmt sein.
-
Zu
dem Ausmaß,
dass der Ausdruck „umfasst" oder „umfassen" in der detaillierten
Beschreibung oder den Ansprüchen
verwendet wird, soll derselbe auf eine Weise ähnlich zu dem Ausdruck „aufweisen" umfassend sein,
wie dieser Ausdruck interpretiert wird, wenn er als Überleitungswort
in einem Anspruch verwendet wird. Ferner, zu dem Ausmaß dass der
Ausdruck „oder" in der detaillierten
Beschreibung oder den Ansprüchen
verwendet wird (z. B. A oder B), ist es beabsichtigt, dass dies „A oder
B oder beide" bedeutet.
Wenn die Anmelder „nur
A oder B aber nicht beide" andeuten
wollen, dann wird der Ausdruck „nur A oder B aber nicht beide" verwendet. Siehe
Bryan A. Garner, A Dictionary of Modern Legal Usage 624 (2. Auflage
1995).