-
TECHNISCHES
GEBIET DER ERFINDUNG
-
Diese
Erfindung bezieht sich allgemein auf Mikroprozessoren und insbesondere
auf Architekturen von Prozessoren mit sehr langen Befehlswörtern.
-
HINTERGRUND
DER ERFINDUNG
-
Während die
Technologie zur Herstellung integrierter Schaltungen fortschreitet,
können
in einer einzelnen integrierten Schaltungsvorrichtung immer mehr
Logikfunktionen enthalten sein. Moderne integrierte Schaltungsvorrichtungen
(IC-Vorrichtungen)
enthalten große
Anzahlen von Gattern auf einen einzelnen Halbleiterchip, wobei diese
Gatter in der Weise verdrahtet sind, dass sie mehrere und komplexe
Funktionen wie etwa beispielsweise jene in einem Universalmikroprozessor
ausführen.
Die Herstellung solcher Schaltungen, die diese Höchstintegration (VLSI) enthalten,
erfordert, dass die Fertigung der Schaltung fehlerfrei ist, da einige
Herstellungsmängel
verhindern können,
dass sie alle Funktionen ausführt,
für deren
Ausführung
sie entworfen worden ist. Dies erfordert die Prüfung der Konstruktion der Schaltung
und außerdem
verschiedene Typen elektrischer Tests nach der Herstellung.
-
Während die
Komplexität
der Schaltung zunimmt, nehmen allerdings die Kosten und die Schwierigkeit beim
Prüfen
und bei elektrischen Tests jeder der Vorrichtungen in der Schaltung
ebenfalls zu. Vom Standpunkt eines elektrischen Tests muss es Idealerweise
möglich
sein, jedes der Gatter nicht nur einzeln (im digitalen Sinn, um
zu bestimmen, dass es weder offen noch geschlossen klemmt), sondern
auch in Verbindung mit den anderen Gattern in der Schaltung in allen
möglichen
Operationskombinationen zu betätigen,
um vollständig
zu prüfen,
dass jedes Gatter in einer VLSI-Schaltung richtig funktioniert.
Normalerweise wird dies durch eine automatische Testausrüstung (ATE)
erreicht, die Testvektoren zum Ausführen der gewünschten
Tests verwendet. Ein Testvektor beschreibt, häu fig in einem Versuch, ein
besonderes Gatter (oder Makro) zu "testen", für
jeden Gehäuseanschlussstift
während
einer Zeitdauer die gewünschte
Testeingabe (oder die gewünschten
Testeingangssignale), die dem Taktimpuls (oder den Taktimpulsen)
zugeordnet sind, und die erwartete Testausgabe (oder die erwarteten
Testausgangssignale). Bei einer komplexen Schaltungsanordnung kann
dies eine große Anzahl
von Testvektoren und dementsprechend eine lange Testdauer umfassen.
Makro und Zelle werden hier in der Weise verwendet, dass sie das
Gleiche bedeuten und austauschbar verwendet werden können.
-
Schaltungskonstrukteure
haben bei der Verbesserung der Effizienz der Tests dieser VLSI-Schaltungen Klemmfehler-Modelliertechniken
verwendet. Die Klemmfehler-Modellierung ist nicht auf Offen- oder
Geschlossenklemmdefekte in einzelnen Gattern, sondern auf die Wirkung
dieser defekten Gatter (und defekter Verdrahtungen) gerichtet, die
zu hoch und tief klemmenden Knoten der Logikschaltung führen. Daraufhin
werden minimale Muster von Testvektoren für das Betätigen der Logikschaltung abgeleitet.
Das Anlegen dieser Testvektoren an die Schaltung erfasst hoch und
tief klemmende Knoten, falls Defekte vorhanden sind. Diese Techniken verbessern
erfolgreich die Testeffizienz von VLSI-Schaltungen der gegenwärtigen Generation.
-
Außerdem können einige
Gatter spezifischer Schaltungskonfigurationen in der VLSI-Schaltung
für alle Signale
bis auf eine spezielle Kombination von Signalen unzugänglich sein,
wodurch ein Fehler verborgen wird, bis ein sehr spezifisches Muster
von Signalen übergeben
wird. Allerdings sind die Kosten der Ausführung dieser Tests an 100 %
der hergestellten Schaltungen in Anbetracht der hohen Kosten der
Testausrüstung,
die zum Betätigen
jeder Schaltung erforderlich ist, in Verbindung mit der langen Dauer,
die erforderlich ist, um jede mögliche
Kombination an jedes Gatter zu übergeben,
erstaunlich. In der Vergangenheit hat dies die Hersteller integrierter
Schaltungen gezwungen, weniger als alle aktiven Vorrichtungen in
einem Chip zu testen, wobei die damit verbundenen Qualitätsniveaus
des Produkts suboptimal waren. Somit ist eines der Hauptprobleme
bei der Konstruktion integrierter Schaltungen die Fähigkeit,
den endgültigen
IC-Entwurf an gemessen zu testen, wobei dieses Problem mit zunehmender
Komplexität
der integrierten Schaltung zunimmt.
-
Eine
Möglichkeit,
dieses Problem zu behandeln, ist über das Design for Test (DFT).
Die Hauptkonzepte beim DFT sind die Steuerbarkeit und die Beobachtbarkeit.
Die Steuerbarkeit ist die Fähigkeit,
den Zustand jedes Knotens in der Schaltung zu setzen und zurückzusetzen,
während
die Beobachtbarkeit die Fähigkeit
ist, den Zustand irgendeines Knotens in der Schaltung entweder direkt
oder indirekt zu beobachten. Der Zweck des DFT ist die Erhöhung der
Fähigkeit
zum Steuern und Beobachten interner und externer Knoten von externen
Eingaben/Ausgaben. Das heißt,
DFT-Techniken können
zur Logikprüfung
und für
Gleichstromparametertests verwendet werden.
-
Das
Entwerfen der Testfähigkeit
für irgendeine
Schaltung beeinflusst in gewissem Grad die Schaltungsanordnung.
Wahrscheinlich ist eine zusätzliche
Logik hinzuzufügen.
Diese zusätzliche
Logik erhöht
die Menge an Silicium, das zur Implementierung des Entwurfs erforderlich
ist. Üblicherweise
sind die Einsparungen aus der erhöhten Testfähigkeit erst zu erkennen, wenn
die Entwicklungszeit und die Testkosten der Schaltung und ihres
Endsystems analysiert werden.
-
In
Verbindung mit der Klemmfehlermodellierung und der Erzeugung zugeordneter
Tests kann in die VLSI-Schaltung eine weitere Schaltungsanordnung
aufgenommen werden, die speziell für die Verbesserung ihrer Testfähigkeit
entworfen ist. Ein Typ einer Testschaltungsanordnung ist ein Scan-Pfad
in der Logikschaltung. Ein Scan-Pfad enthält eine Kette synchron getakteter
Master/Slave-Zwischenspeicher
(oder Register), von denen jeder mit einem besonderen Knoten in
der Logikschaltung verbunden ist. Diese Zwischenspeicher können mit
einem seriellen Datenstrom ("Scan-in") geladen werden,
der die Logikschaltungsknoten auf einen vorgegebenen Zustand voreinstellt.
Daraufhin kann die Logikschaltung auf normale Weise betätigt werden, wobei
das Ergebnis der Operation (an jedem der Knoten, der einen Scan-Zwischenspeicher
besitzt) in seinem jeweiligen Zwischenspeicher gespeichert wird.
Durch serielles Entladen der Inhalte der Zwischenspeicher ("Scan-out") wird das Ergebnis
der besonderen Testoperation an den zugeordneten Knoten ausgelesen,
wobei es auf eine falsche Operation des Knotens analysiert werden
kann. Die Wiederholung dieser Operation mit einer Anzahl verschiedener
Datenmuster testet effektiv alle erforderlichen Kombinationen der
Logikschaltung, im Vergleich zu getrennten Tests jeder aktiven Komponente
oder Zelle und aller ihrer möglichen
Wechselwirkungen jedoch mit einer verringerten Testdauer und mit
verringerten Kosten. Die Scan-Pfade ermöglichen die Schaltungsinitialisierung
durch direktes Schreiben in die Zwischenspeicher (oder Register)
und durch direktes Beobachten der Inhalte der Zwischenspeicher (oder
Register). Die Verwendung von Scan-Pfaden hilft, die Menge der Testvektoren
im Vergleich zu herkömmlichen "Funktionsbetriebsart"-Zugängen zu
verringern. Techniken zum Scannen dieser Daten sind diskutiert von
E. J. McCluskey in: A Survey of Design for Testability Scan Techniques,
VLSI Design (Bd. 5, Nr. 12, S. 38–61, Dezember 1984).
-
Außerdem wünschen die
Anwender integrierter Schaltungen, während die VLSI-Technologie
fortschreitet, speziell entworfene und kons truierte integrierte
Schaltung zur Ausführung
von Funktionen, die an die Anwendung des Anwenders angepasst sind.
Diese integrierten Schaltungen werden anwendungsspezifische integrierte
Schaltungen (ASICs) genannt. Damit eine ASIC-Vorrichtung von den
Kosten her konkurrenzfähig
mit Universalmikrocomputern ist, in denen Spezialfunktionen in programmierbarer
Firmware implementiert werden kann, und von den Kosten konkurrenzfähig mit
einem Platinenentwurf ist, der aus niedriger integrierten Schaltungen
aufgebaut ist, muss die Entwurfsdauer der ASIC-Schaltung kurz sein
und die ASIC-Schaltung mit niedrigen Kosten herstellbar und testbar
sein. Dementsprechend ist es nützlich,
wenn diese Schaltungen einen modularen Entwurf besitzen, wobei jedes
der Module eine bestimmte Funktion ausführt, so dass eine neue ASIC-Schaltung
durch Kombination zuvor entworfener Schaltungsmodule konstruiert
werden kann. Ein solcher Zugang kann ebenfalls für Nicht-ASIC-Mikrocomputer
und -Mikroprozessoren verwendet werden. Unabhängig von dem Endprodukt ermöglicht die
Verwendung eines modularen Zugangs, dass der Konstrukteur eine Logik
verwendet, die zuvor geprüft
worden ist und sich als herstellbar erwiesen hat. Falls in einer
neuen Schaltungsanordnung Logikmodule angeordnet werden, die vorhandene
Scan-Pfade enthalten, sind allerdings für die neue Vorrichtung im allgemeinen
neue Testmuster erforderlich, was die Entwurfs-/Herstellungszyklusz
eit verlängert.
-
Um
auf effiziente Weise eine gründliche
Erfassung sämtlicher
möglicher
Fehler zu schaffen, wird ein modularer Zugang zur Verwendung von
Scan-Pfaden und anderen Testfähigkeitsschaltungen
verwendet. Allerdings nutzt dieser Zugang Systembusse zum Einrichten
und Betreiben des Scan-Tests, so dass das für ein gegebenes Modul entworfene
Testmuster, obgleich jedes Modul unabhängig getestet wird, vom Betrieb
anderer Module in der Logikschaltung zur Bussteuerung und Modulauswahl
abhängt.
Dies führt
dazu, dass die Testfähigkeit
eines besonderen Moduls vom fehlerfreien Betrieb der anderen Module
abhängt.
Außerdem
hängt das
automatische Testprogrammgenerator-Programm (ATPG-Programm), das
die Bedingungen für
den Test eines gegebenen Moduls einstellt, von der Position des
Moduls in Bezug auf andere Module und von den Betriebsmerkmalen
dieser anderen Module ab. Obgleich durch diese Modularität somit
verringerte Testdauern und Kosten erzielt werden, kann die Verwendung
von Systembussen zum Laden und Entladen der Scan-Pfade in den einzelnen
Modulen nicht nur den Betrieb des besonderen Moduls beeinflussen,
sondern schließt
auch das "Portieren" des Testprogramms
für ein
gegebenes Modul von einer Logikschaltung zu einer anderen aus.
-
In
letzter Zeit werden beim Entwurf von ASICs MegaModules verwendet.
(MegaModule ist ein Warenzeichen der Texas Instruments Incorporated.)
Die Typen der MegaModules umfassen SRAMs, FIFOs, Registerdateien,
RAMs, ROMs, universelle asynchrone Empfänger/Sender (UARTs), programmierbare
Logikanordnungen und weitere solche Logikschaltungen. MegaModules
sind üblicherweise
als integrierte Schaltungsmodule mit einer Komplexität von wenigstens
500 Gattern und einer komplexen ASIC-Makrofunktion definiert. Diese
MegaModules können
zuvor entworfen und in einer ASIC-Entwurfsbibliothek gespeichert
werden. Daraufhin können
die MegaModules von dem Konstrukteur ausgewählt und in einem bestimmten
Bereich auf dem gewünschten
IC-Chip an geordnet werden. Dies ermöglicht, dass ASIC-Konstrukteure
MegaModules so leicht wie einfache Makros in ihre Logik integrieren.
-
Eine
weitere Lösung
für dieses
Testproblem einer ASIC ist die Verwendung eines so genannten Parallelmodultests
(PMT), der häufig
als ein "Direktverbindungs"-Schema bezeichnet
wird. (Parallelmodultest ist ein Warenzeichen von Texas Instruments
Incorporated.) Der PMT ist ein Direktverbindungs-Schema, da er externe
Anschlussstifte mit einem MegaModule verbindet, wobei sämtliche
weitere Logik, Puffer usw. umgangen werden. Er ist primär als ein
Logikprüfungs-Testfähigkeits-Schema
gedacht und kürzlich
verbessert worden, um beschränkte
VIH/VIL- und ICCQ-Testfähigkeitsschemata
zu behandeln. Allerdings kann sogar der PMT Probleme haben, da die
Logikzustände
der ASIC-Schaltungsanordnung als Teil des Testprozesses während der
Testauswahl und -freigabe gestört
werden können.
-
Eine
weitere Lösung
ist die durch die Norm IEEE 1149.1 definierte Testzugriffsport-
und Boundary-Scan-Architektur, ein so genannter JTAG-Testport. Die
IEEE 1149.1 ist hauptsächlich
als eine Systemtestlösung
gedacht. Die Norm IEEE 1149.1 erfordert, dass wenigstens vier Gehäuseanschlussstifte
für die
Testfunktion vorgesehen sind. Die Norm IEEE 1149.1 erfordert für jeden
E/A-Puffer Boundary-Scan-Zellen, was eine Datenverzögerung für sämtliche
Normaloperationsfunktions-Anschlussstifte sowie einen Silicium-Overhead
hinzufügt.
Obgleich sie "Programmeinstiegsmöglichkeiten" zur Steuerung einiger
interner Testfähigkeitsschemata
besitzt, ist sie nicht für
Tests auf der Chipebene optimiert. Die IEEE 1149.1 unterstützt Tests
interner Gleichstromparameter nicht explizit.
-
Softwareunterbrechungspunkte
(SWBP) schaffen einen weiteren Mechanismus, der das Austesten von
Mikroprozessorcode und das Bewerten der Leistung ermöglicht.
Sofern das Programm in einem beschreibbaren Speichermodul liegt,
das es ermöglicht,
den Opcode an dem Haltepunkt im Speicher durch den Softwareunterbrechungspunkt-Opcode
zu ersetzen, wird ein SWBP typischerweise durch Opcode-Ersatz ausgeführt. Wenn
ein SWBP-Opcode die erste Ausführungsstufe
einer Befehlsausführuspipeline
erreicht, bewirkt er in den meisten Maschinen, dass die Pipeline
das Fortschreiten anhält
oder einen nicht programmierten Sprung zu einer Unterbrechungsdienstroutine
ausführt
und ein Austeststatusbit setzt, das angibt, dass die Pipeline angehalten
wurde oder einen nicht programmierten Sprung ausgeführt hat.
In Prozessoren, die als geschützte
Pipelines spezifiziert sind, werden Befehle, die nach dem SWBP in
die Pipeline geholt werden, nicht ausgeführt. Es wird zugelassen, dass
Befehle, die bereits in der Pipeline sind, abgeschlossen werden. Um
die Ausführung
neu zu starten, kann die Pipeline durch einfaches Vorauslesen des
Opcodes an der SWBP-Speicheradresse gelöscht und daraufhin neu gestartet
werden, nachdem der Opcode im Speicher durch den ursprünglichen
Opcode ersetzt worden ist.
-
D1
(WO-A-96 38787) schafft einen Computer mit einem Pipelineprozessor
und Code-Unterbrechungspunkten zum Ausführen von Software-Austestoperationen.
Die Code-Unterbrechungspunkte werden dadurch implementiert, dass
die Adressen der im Voraus ausgewählten Befehle im Voraus in
Austestadressenregistern gespeichert werden. Während der Befehlsvorausholphase
werden die 29 höchstwertigen
Bits der 32-Bit-Befehlsadresse mit den in den Austestadressenregistern
gespeicherten Code-Unterbrechungspunkten verglichen, wobei ein 1-Bit-Signal erzeugt wird,
das angibt, ob es eine positive Übereinstimmung
gibt. Während
der Decodierungsphase der Befehlausführung werden die drei niedrigstwertigen
Bits der 32-Bit-Befehlsadresse verglichen, wobei ein 1-Bit-Signal
erzeugt wird, das angibt, ob es eine positive Übereinstimmung gibt. Daraufhin
werden die beiden 1-Bit-Signale logisch UND-verknüpft und
mit dem Bit 3 der 32-Bit-Befehlsadresse synchronisiert, um sicherzustellen,
dass die Signale auf den entsprechenden Vergleichen derselben Befehlsadresse
beruhen. D1 implementiert eine Art eines Hardware-Unterbrechungspunkts,
in dem die Anzahl der Code-Unterbrechungspunkte durch die Anzahl
der vorgesehenen Austestadressenregister beschränkt ist.
-
Die
Mikroprozessorkonstrukteure sind zunehmend bemüht, zur Verbesserung der Leistung
die Parallelität
zu verwenden. Eine parallele Architektur, die in einigen modernen
Mikroprozessoren Anwendung gefunden hat, ist die Architektur mit
sehr langem Befehlswort oder VLIW-Architektur. Mikroprozessoren
mit der VLIW-Architektur werden so genannt, da sie Befehle im VLIW-Format
behandeln.
-
Ein
Befehl im VLIW-Format ist ein Befehl mit langer fester Breite, der
mehrere gleichzeitige Operationen codiert. VLIW-Systeme verwenden
mehrere unabhängige
Funktionseinheiten. Anstatt mehrere unabhängige Befehle an die Einheiten
auszugeben, kombiniert ein VLIW-System die mehreren Befehle zu einem
sehr langen Befehl. In einem VLIW-System können Computerbefehle für mehrere
Ganzzahloperationen, Gleitkommaoperationen und Speicherbezugnahmen
zu einem einzigen breiten VLIW-Befehl kombiniert werden.
-
Das
Testen und Austesten einer so komplizierten Pipeline ist selbst
dann, wenn die in den vorangehenden Absätzen beschriebenen Techniken
verwendet werden, schwierig. Dagegen werden diese und weitere Nachteile
des Standes der Technik durch die vorliegende Erfindung überwunden,
wobei verbesserte Verfahren und Vorrichtungen für Tests auf der Chipebene sowie
für das
Austesten auf der Systemebene geschaffen werden.
-
ZUSAMMENFASSUNG
DER ERFINDUNG
-
Die
vorliegende Erfindung schafft ein Verfahren zum Austesten eines
Prozessors, einen Mikroprozessor und ein Datenverarbeitungssystem,
wie sie in den beigefügten
unabhängigen
Ansprüchen
definiert sind.
-
Gemäß der vorliegenden
Erfindung kann ein Softwareunterbrechungspunkt-Befehl (SWBP-Befehl), der in einem Mikroprozessor
ausgeführt
wird, der eine ungeschützte
Befehlsausführungspipeline
besitzt, keine Techniken des Standes der Technik nutzen, falls die
Befehlsausführungslatenzzeit
aufrechterhalten werden soll. Um die Latenzzeit aufrechtzuerhalten,
müssen
alle Phasen einer ungeschützten
Pipeline gleichzeitig angehalten werden. Um dies mit einem Softwareunterbrechungspunkt
gemäß der vorliegenden
Erfindung auszuführen,
wird der SWBP-Befehl decodiert und an die erste Ausführungsstufe
der Ausführungspipe line übergeben,
wo er genutzt wird, um die gesamte Pipeline an der nächsten Pipelinephasengrenze
anzuhalten.
-
Außerdem ist
der SWBP gemäß der vorliegenden
Erfindung nicht als ein Opcode implementiert, sondern lediglich
ein einzelnen Bit oder Bitfeld in dem Opcode. Dies beseitigt vorteilhaft
die Notwendigkeit, den Opcode im Speicher zu ersetzen und ihn vorauszuholen,
um die Ausführung
wieder aufzunehmen, was nicht erfolgen kann, falls die Befehlslatenzzeit
aufrechterhalten werden soll. Die Austestsoftware braucht vorteilhaft lediglich
ein einzelnes Bit oder Bitfeld in der ersten Ausführungsstufe
der Befehlsausführungspipeline
zu ersetzen. Außerdem
besitzt dies den zusätzlichen
Vorteil, dass der ursprüngliche
Opcode decodiert und an die Ausführungseinheit übergeben
wird. Beispielsweise kann in einer Ausführungsform, die das Feld für die bedingte Ausführung des
Opcodes bis zur Ausführungsstufe
der Befehlspipeline nicht decodiert, dieses Feld verwendet werden.
-
Im
Fall einer Architektur, die mehrere Ausführungseinheiten in der Pipeline
oder andere Formen der parallelen Befehlsausführung unterstützt, ist
ein weiterer Aspekt der vorliegenden Erfindung, dass eine Einschränkungsvorschrift
erzwungen werden kann, in der vorschriftsmäßig lediglich ein SWBP-Befehl
pro Ausführungspaket
zulässig
ist. Diese Vorschrift ist optional und braucht nicht in jeder Ausführungsform
der vorliegenden Erfindung enthalten zu sein. Daraufhin kann das
SWBP-Bit oder -Bitfeld jeder Ausführungseinheit nach einer wahren
Bedingung durchsucht werden. Da lediglich ein SWBP zulässig ist,
wird lediglich einer gefunden, was eine leichte Identifizierung
der Ausführungseinheit
ermöglicht,
deren SWBP-Bit gelöscht
werden muss oder deren SWBP-Bitfeld durch den ursprünglichen
Wert ersetzt werden muss.
-
In
einer weiteren Ausführungsform
der vorliegenden Erfindung kann ein SWBP-Befehl als ein vollständiger Befehls-Opcode
codiert werden. Um die Befehlslatenzzeit aufrecht zu erhalten, erfordert
in dieser Ausführungsform
ein Neustartprozess, nachdem ein SWBP behandelt worden ist, dass
die Austestsoftware die Zwischenspeicher der Ausführungseinheit
mit dem decodierten Zustand des ursprünglichen Opcodes, der durch
den SWBP-Opcode ersetzt worden ist, ersetzt.
-
Ein
Verfahren zum Austesten eines Prozessors, der eine Befehlsausführungspipeline
mit wenigstens einer ersten -Ausführungsphase, der eine zweite
Ausführungsphase
folgt, besitzt, mit einem SWBP-Befehl umfasst gemäß der vorliegenden
Erfindung die folgenden Schritte:
- Bilden eines Software-Unterbrechungsbefehls
in einer Befehlsfolge durch Ersetzen eines Feldes in einem Operationsbefehl
durch einen vorgegebenen Unterbrechungspunkt-Code;
- Holen und Ausführen
eines Abschnitts der Befehlsfolge in der Prozessor-Befehlsausführungspipeline
in einer normalen Operation, um mehrere überlappende Operationen in
der Befehlspipeline zu initiieren;
- Holen und teilweises Ausführen
des Software-Unterbrechungsbefehls in der ersten Ausführungsphase
der Befehlspipeline;
- Anhalten der normalen Operation der Befehlspipeline in Reaktion
auf die Decodierung des Unterbrechungspunkt-Codes in der zweiten
Phase der Befehlspipeline;
- Ausführen
einer Austestfunktion in Reaktion auf das Decodieren des Unterbrechungspunkt-Codes;
und erneutes Beginnen der normalen Operation in der Befehlspipeline
nach dem Schritt des Ausführens
einer Austestfunktion ohne Vorausholen des Operationsbefehls, der
durch den Software-Unterbrechungsbefehl ersetzt wurde.
-
KURZBESCHREIBUNG
DER ZEICHNUNG
-
Weitere
Merkmale und Vorteile der vorliegenden Erfindung werden mit Bezug
auf die folgende ausführliche
Beschreibung in Verbindung mit der beigefügten Zeichnung klar, in der:
-
1 ein Blockschaltplan eines
digitalen Signalprozessors (DSP) ist, der seine Komponenten zeigt, die
sich auf eine Ausführungsform
der vorliegenden Erfindung beziehen;
-
2 ein Blockschaltplan der
Funktionseinheiten, Datenpfade und Registerdateien aus 1 ist;
-
3 das Adressierungsbetriebsartregister
(AMR) des DSP aus 1 zeigt;
-
4 das Steuerstatusregister
(CSR) zeigt, das Steuer- und Statusbits des DSP aus 1 enthält;
-
5 ein Universaleingangsregister
(IN) zeigt, das 32 Universaleingangssignale des DSP aus 1 unterstützt;
-
6 ein Universalausgangsregister
(OUT) zeigt, das 32 Universalausgangssignale des DSP aus 1 unterstützt;
-
7 das Registerspeicherschema
für 40-Bit-Daten
des DSP aus 1 veranschaulicht;
-
8A–8J ein
Opcode-Abbild für
den DSP aus 1 zeigt;
-
9 das Grundformat eines
Holpakets des DSP aus 1 zeigt;
-
10A ein Holpaket aus 9 mit vollständig seriellen
p-Bits zeigt;
-
10B ein Holpaket aus 9 mit vollständig parallelen
p-Bits zeigt;
-
10C ein Holpaket aus 9 mit teilweise seriellen
p-Bits zeigt;
-
11 die Pipelinephasen des
DSP aus 1 zeigt;
-
12 die Verzweigungsbefehlsphasen
zeigt;
-
13 anhand von Taktzyklen
und Holpaketen den Betrieb der Pipeline des DSP aus 1 zeigt;
-
14 das Holpaket n zeigt,
das drei Ausführungspakete
enthält,
die gefolgt von sechs Holpaketen (n + 1 bis n + 6), jeweils mit
einem Ausführungspaket
(das 8 parallele Befehle enthält),
gezeigt sind;
-
15 ein Blockschaltplan
eines MTAP für
die Testportschnittstelle für
den Prozessor aus 1 zeigt;
-
16 ein Zeitablaufplan einer
MegaModule-Rücksetzfolge
für den
Prozessor aus 1 ist;
-
17A das Unterbrechungsmerkerregister
(IFR) zeigt, das den Status von INT4-INT15 und NMI enthält;
-
17B das Unterbrechungsfreigaberegister
(IER) des DSP aus 1 zeigt;
-
17C das Unterbrechungssetzregister
(ISR) zeigt, das das manuelle Setzen oder Löschen von Unterbrechungen in
dem IFR ermöglicht;
-
17D das Unterbrechungssetzregister
(ICR) zeigt, das das manuelle Setzen oder Löschen von Unterbrechungen in
dem IFR ermöglicht;
-
18 ein Zeitablaufplan der
Erfassung von Analyseunterbrechungen für den Prozessor aus 1 ist;
-
19A und 19B zwei analyseunterbrechungsbezogene
Befehle, SWI und B ARP, veranschaulichen;
-
20 ein Blockschaltplan
ist, der die Signale der MTAP-CPU-Schnittstelle für den MTAP
aus 15 beschreibt;
-
21 ein Blockschaltplan
einer MTAP-MegaModule-Domänen-Schnittstelle
für den
Prozessor aus 1 ist;
-
22 ein Zustandsdiagramm
der Testportzustände
für den
Prozessor aus 1 ist;
-
23A ein Zeitablaufplan
einer Taktumschaltung vom Funktionslauf zum Scan an UCLK für den Prozessor
aus 1 ist;
-
23B ein Zeitablaufplan
einer Taktumschaltung vom Funktionslauf an TCLK für den Prozessor
aus 1 ist;
-
23C ein Zeitablaufplan
einer Taktumschaltung vom Funktionslauf an UCLK für den Funktionslauf an
TCLK für
den Prozessor aus 1 ist;
-
24 eine Tabelle einer Scan-Kette
für einen
Daten-Scan auf der Grundlage der MSEND-Bits für den Prozessor aus 1 ist;
-
25 ein Zeitablaufplan ist,
der verschiedene Fälle
des Anhaltens für
den Prozessor aus 1 zeigt;
-
26 ein Stromlaufplan der
Schaltungsanordnung zum Bilden des Signals ERDY ist;
-
27A ein Zeitablaufplan
eines vom CPU-Testport angeforderten Halts während der Unterbrechungsverarbeitung
für den
Prozessor aus 1 ist;
-
27B ein Zeitablaufplan
ist, der einen vom Testport angeforderten Testhalt veranschaulicht;
-
28 ein Zeitablaufplan eines
Pipeline-Halts ist, der einen Pipeline-Managementprozess zur Emulation
für den
Prozessor aus 1 zeigt;
-
29 ein Zeitablaufplan ist,
der einen Pipeline-Wiedergewinnungsprozess nach der Emulation für den Prozessor
aus 1 zeigt;
-
30A ein Analysesteuerregister
für den
Prozessor aus 1 veranschaulicht;
-
30B ein Analysedatenregister
für den
Prozessor aus 1 veranschaulicht;
-
30C ein Analysedatenunterbrechungs-Rücksprungzeigerregister
für den
Prozessor aus 1 veranschaulicht;
-
30D ein Datenstromregister
für den
Prozessor aus 1 veranschaulicht;
-
31 ein Zeitablaufplan für die Befehlsausführungspipeline
für den
Prozessor aus 1 ist,
der verschiedene Pipelinephasen zeigt;
-
32 ein Blockschaltplan
ist, der die Anschlussstiftverbindungen zu einem Megamodul in dem
Prozessor aus 1 veranschaulicht;
-
33 ein Blockschaltplan
ist, der einen JTAG-Befehl und Datenregisterpfade für den Prozessor
aus 1 veranschaulicht;
-
34A JTAG-Befehlsregisterinhalte
veranschaulicht, wenn in den Registern aus 33 der Strap-Status ausgewählt ist;
-
34B JTAG-Befehlsregisterinhalte
veranschaulicht, wenn in den Registern aus 33 der Emulationshaltstatus ausgewählt ist;
-
34C JTAG-Befehlsregisterinhalte
veranschaulicht, wenn in den Registern aus 33 der Echtzeitemulationsstatus ausgewählt ist;
-
34D JTAG-Befehlsregisterinhalte
veranschaulicht, wenn in den Registern aus 33 der Emulationsfehlerstatus ausgewählt ist;
-
35 ein Blockschaltplan
einer JTAG-MPSD-Schnittstelle für
den Prozessor aus 1 ist;
-
36 das Emulationssteuerregister
aus 33 veranschaulicht;
-
37 ein Blockschaltplan
einer Codezustandsmaschine (CSM) für den MTAP des Prozessors aus 1 ist;
-
38 ein Prinzipschaltbild
eines Taktquellenumschalters für
die CSM aus 37 ist;
-
39 ein Prinzipschaltbild
der Schaltungsanordnung zum Erzeugen einer EVTA-Unterbrechung für den Prozessor
aus 1 ist;
-
40 das Zählerregister
aus 33 veranschaulicht;
-
41 ein Blockschaltplan
von Domänenverdrahtungen
für den
Prozessor aus 1 ist;
-
42 ein Blockschaltplan
ist, der ein Stream-Scan-Register in dem MTAP aus 41 veranschaulicht;
-
43 ein Blockschaltplan
einer EMU-Anschlussstiftverbindung für den Prozessor aus 1 ist; und
-
44 ein Blockschaltplan
einer JTAG-TAP-Konfiguration für
den Prozessor aus 1 ist.
-
AUSFÜHRLICHE
BESCHREIBUNG VON AUSFÜHRUNGSFORMEN
DER ERFINDUNG
-
1 ist ein Blockschaltplan
eines Mikroprozessors 1, der eine Ausführungsform der vorliegenden
Erfindung aufweist. Der Mikroprozessor 1 ist ein digitaler
VLIW-Signalprozessor ("DSP"). Im Interesse der
Klarheit zeigt 1 lediglich
jene Abschnitte des Mikroprozessors 1, die für das Verständnis einer
Ausführungsform
vorliegenden Erfindung relevant sind. Einzelheiten der allgemeinen
Konstruktion für
DSPs sind wohlbekannt und leicht anderswo zu finden. Beispielsweise
beschreibt das US-Patent 5.072.418, erteilt an Frederick Boutaud
u. a., einen DSP. Das US-Patent 5.329.471, erteilt an Gary Swoboda
u. a., beschreibt, wie ein DSP zu testen und zu emulieren ist. Im
Folgenden werden Einzelheiten von Abschnitten des Mikroprozessors 1 erläutert, die
für eine
Ausführungsform
der vorliegenden Erfindung relevant sind.
-
Im
Mikroprozessor 1 sind eine Zentraleinheit (CPU) 10,
ein Datenspeicher 22, ein Programmspeicher 23,
Peripherieeinrichtungen 60 und eine externe Speicherschnittstelle
(EMIF) mit einem direkten Speicherzugriff (DMA) 61 gezeigt.
Fer ner weist die CPU 10 eine Befehls-Hol/Decodierungs-Einheit 10a–c,
mehrere Ausführungseinheiten
einschließlich
einer Arithmetik- und Lade/Speicher-Einheit D1, einen Multiplizierer
M1, eine ALU/Schiebeeinheit S1, eine Arithmetik-Logik-Einheit ("ALU") L1, eine gemeinsam
genutzte Mehrport-Registerdatei 20a, von der Daten gelesen
und in die Daten geschrieben werden, auf. Die decodierten Befehle
werden über
verschiedene Mengen von Steuerleitungen, die nicht gezeigt sind,
von der Befehls-Hol/Decodier-Einheit 10a-c an die Funktionseinheiten
D1, M1, S1 und L1 geliefert. Die Daten werden über eine erste Menge von Bussen 32a von
den/zu den Lade/Speicher-Einheiten D1 zu der/von der Registerdatei 20a, über eine
zweite Menge von Bussen 34a zum Multiplizierer M1, über eine
dritte Menge von Bussen 36a zu der ALU/Schiebe-Einheit
S1 und über
eine vierte Menge von Bussen 38a zu der ALU L1 geliefert.
Die Daten werden über eine
fünfte
Menge von Bussen 40a von den/zu den Lade/Speicher-Einheiten
D1 zum/vom Speicher 22 geliefert. Es wird angemerkt, dass
der gesamte oben beschriebene Datenpfad mit der Registerdatei 20b und
den Ausführungseinheiten
D2, M2, S2 und L2 verdoppelt ist. Die Befehle werden über eine
Menge von Bussen 41 durch die Holeinheit 10a aus
dem Befehlsspeicher 23 geholt. Die Emulationsschaltungsanordnung 50 schafft einen
Zugriff auf den internen Betrieb der integrierten Schaltung 1,
die durch ein externes Test/Entwicklungs-System (XDS) 51 gesteuert
werden kann.
-
Das
externe Testsystem 51 ist repräsentativ für eine Vielzahl bekannter Testsysteme
zum Austesten und Emulieren integrierter Schaltungen. Ein solches
System ist beschrieben im US-Patent 5.535.331. Die Testschaltungsanordnung 52 enthält Steuerregister
und eine parallele Signaturanalyseschaltungsanordnung für Tests
der integrierten Schaltung 1.
-
Es
wird angemerkt, dass der Speicher 22 und der Speicher 23 in 1 als ein Teil einer integrierten Schaltung
des Mikroprozessors 1 gezeigt sind, deren Umfang durch
den Kasten 42 dargestellt ist. Die Speicher 22–23 könnten ebenso
gut extern gegenüber
der integrierten Schaltung 42 des Mikroprozessors 1 sein
oder es könnte
ein Teil von ihnen in der integrierten Schaltung 42 liegen
und ein Teil von ihnen extern gegenüber der integrierten Schaltung 42 sein.
Dies sind Fragen der Entwurfswahl. Außerdem sind die besondere Auswahl und
Anzahl der Ausführungseinheiten
eine Frage der Entwurfswahl und nicht entscheidend für die Erfindung.
-
Wie
in 1 gezeigt ist, kann
ein zusätzlicher
Speicher oder können
zusätzliche
Peripherieeinrichtungen mit dem Mikroprozessor 1 verbunden
sein, wenn der Mikroprozessor 1 in einem Datenverarbeitungssystem
enthalten ist. Beispielsweise sind ein Schreib-Lese-Speicher (RAM) 70,
ein Nur-Lese-Speicher (ROM) 71 und eine Platte 72 gezeigt,
die über
einen externen Bus 73 verbunden sind. Der Bus 73 ist
mit der externen Speicherschnittstelle (EMIF) verbunden, die Teil
des Funktionsblocks 61 in dem Mikroprozessor 42 ist.
Außerdem
ist in dem Block 61 ein Controller für den direkten Speicherzugriff
(DMA) enthalten. Der DMA-Controller wird allgemein dazu verwendet,
Daten zwischen dem Speicher und den Peripherieeinrichtungen im Prozessor 1 und
zwischen dem Speicher und gegenüber
dem Mikroprozessor 1 externen Peripherieeinrichtungen zu
verschieben.
-
2 ist ein Blockschaltplan
der Ausführungseinheiten
und der Registerdateien des Mikroprozessors aus 1, der eine genauere Ansicht der Busse
zeigt, die die verschiedenen Funktionsblöcke verbinden. So weit nichts
anderes angemerkt ist, sind sämtliche
Datenbusse in dieser 32 Bits
breit. Der Bus 40a besitzt einen Adressenbus DA1, der durch
den Mux 200a angesteuert wird. Dies ermöglicht, entweder durch die
Lade/Speicher-Einheit D1 oder durch die Lade/Speicher-Einheit D2
eine Adresse zu erzeugen, um eine Adresse für Lade- oder Speichervorgänge für die Registerdatei 20a zu
liefern. Der Datenbus LD1 lädt
die Daten von einer durch den Adressenbus DA1 spezifizierten Adresse
im Speicher 22 in ein Register in der Ladeeinheit D1. Die
Einheit D1 kann die früher
gelieferten Daten manipulieren und in der Registerdatei 20a speichern.
Gleichfalls speichert der Datenbus ST1 Daten von der Registerdatei 20a im
Speicher 22. Die Lade/Speicher-Einheit D1 führt die
folgenden Operationen aus: 32-Bit-Addition, 32-Bit-Subtraktion,
lineare und zirkuläre
32-Bit-Adressenberechnungen. Die Lade/Speicher-Einheit D2 arbeitet ähnlich wie
die Einheit D1 mit Hilfe des Mux 200b zur Auswahl einer
Adresse.
-
Die
ALU-Einheit L1 führt
die folgenden Typen von Operationen aus: 32/40-Bit-Arithmetik- und -Vergleichsoperationen;
Zählung
der höchstwertigen
1-, 0-Bits für 32 Bits;
Normierungszählung
für 32
und 40 Bits; und Logikoperationen. Die ALU L1 besitzt den Eingang
src1 für
einen 32-Bit-Quelloperanden und den Eingang src2 für einen
zweiten 32-Bit-Quelloperanden. Der Eingang msb_src ist ein 8-Bit-Wert,
der zum Bilden von 40-bit-Quelloperanden verwendet wird. Die ALU
L1 besitzt einen Ausgang dst für
32-Bit-Zieloperanden. Der Ausgang msb_dst ist ein 8-Bit-Wert, der
zum Bilden von 40-Bit-Zieloperanden verwendet wird. Zwei 32-Bit-Register
in der Registerdatei 20a sind verkettet, um einen 40-Bit-Operanden zu
halten. Der Mux 211 ist mit dem Eingang src1 verbunden
und ermöglicht, über den
Bus 38a einen 32-Bit-Operanden von der Registerdatei 20a oder über den
Bus 210 einen 32-Bit-Operanden von der Registerdatei 20b zu
erhalten. Der Mux 212 ist mit dem Eingang src2 verbunden
und ermöglicht, über den
Bus 38a einen 32-Bit-Operanden von der Registerdatei 20a oder über den
Bus 210 einen 32-Bit-Operanden von der Registerdatei 20b zu
erhalten. Die ALU-Einheit L2
arbeitet ähnlich
wie die Einheit L1.
-
Die
ALU/Schiebe-Einheit S1 führt
die folgenden Typen von Operationen aus: 32-Bit-Arithmetikoperationen;
32/40-Bit-Verschiebungen und 32-Bit-Bitfeldoperationen; 32-Bit-Logikoperationen;
Verzweigung; und Konstantenerzeugung. Die ALU S1 besitzt einen Eingang
src1 für
einen 32-Bit-Quelloperanden und einen Eingang src2 für einen
zweiten 32-Bit-Quelloperanden. Der Eingang msb_src ist ein 8-Bit-Wert,
der zum Bilden von 40-Bit-Quelloperanden verwendet wird. Die ALU
S1 besitzt einen Ausgang dst für
32-Bit-Zieloperanden. Der Ausgang msb_dst ist ein 8-bit-Wert, der
zum Bilden von 40-Bit-Zieloperationen verwendet wird. Der Mux 213 ist
mit dem Eingang src2 verbunden und ermöglicht, über den Bus 36a einen
32-Bit-Operanden von der Registerdatei 20a oder über den
Bus 210 einen 32-Bit-Operanden von der Registerdatei 20b zu
erhalten. Die ALU-Einheit S2 arbeitet ähnlich wie die Einheit S1,
wobei sie aber zusätzlich
Registerübertragungen
zu der/von der Steuerregisterdatei 102 ausführen kann.
-
Der
Multiplizierer M1 führt
16 × 16-Multiplikationen
aus. Der Multiplizierer M1 besitzt einen Eingang src1 für einen
32-Bit-Quelloperanden und einen Eingang src2 für einen 32-Bit-Quelloperanden.
Die ALU S1 besitzt einen Ausgang dst für 32-Bit-Zieloperanden. Der
Mux 214 ist mit dem Eingang src2 verbunden und ermöglicht, über den
Bus 34a einen 32-Bit-Operanden von der Registerdatei 20a oder über den
Bus 210 einen 32-Bit-Operanden von der Registerdatei 20b zu
erhalten. Der Multiplizierer M2 arbeitet ähnlich wie der Multiplizierer
M1.
-
Wie
in 2 gezeigt ist, kann
eine Einheit (.S2) unter Verwendung der Busse 220 und 221 von
der Steuerregisterdatei 102 lesen und in sie schreiben.
Die Tabelle 2 führt
die in der Steuerregisterdatei enthaltenen Steuerregister auf und
beschreibt jedes kurz. Im Folgenden werden die Steuerregister ausführlicher
beschrieben. Auf jedes Steuerregister wird durch den MVC-Befehl
zugegriffen; siehe die Beschreibung der MVC-Befehle weiter unten.
-
-
-
3 zeigt das Adressierungsbetriebsartregister
(AMR). Acht Register (A4-A7,
B4–B7)
können
eine zirkuläre
Adressierung ausführen.
Das AMR spezifiziert für
jedes dieser Register die Adressierungsbetriebsart. Für jedes
Register wird ein 2-Bit-Feld zur Auswahl der Adressenänderungsbetriebsart
verwendet: lineare Betriebsart (die Standardbetriebsart) oder zirkuläre Betriebsart.
Bei der zirkulären
Adressierung spezifiziert das Feld außerdem, welches BK-Feld (Blockgrößenfeld)
für einen
Ringpuffer zu verwenden ist. Außerdem
muss der Puffer auf eine Byte-Begrenzung
gleich der Blockgröße ausgerichtet
sein. Die Codierung des Betriebsartauswahlfelds ist in Tabelle 3
gezeigt.
-
Tabelle
3. Codierung des Adressierungsbetriebsartfelds
-
Die
Blockgrößenfelder
BK0 und BK1 spezifizieren die Blockgrößen für die zirkuläre Adressierung.
Die fünf
Bits in BK0 und in BK1 spezifizieren die Breite. Die Formel zur
Berechnung der Blockgrößenbreite
ist:
- Blockgröße (in Bytes)
= 2(N + 1)
- wobei N der Wert in BK1 oder in BK0 ist
-
Tabelle
4 zeigt die Blockgrößenberechnungen
für sämtliche
32 Möglichkeiten.
-
Tabelle
4. Blockgrößenberechnungen
-
Das
in 4 gezeigte Steuerstatusregister
(CSR) enthält
Steuer- und Statusbits. Die Funktionen der Bitfelder in dem CSR
sind in Tabelle 5 gezeigt.
-
Tabelle
5. Steuerstatusregister: Bitfelder, Lese/Schreib-Status und Funktion
-
Ein
in 5 gezeigtes Universaleingangsregister
(IN) unterstützt
32 Universaleingangssignale, während
ein in 6 gezeigtes
Universalausgangsregister (OUT) 32 Universalausgangssignale unterstützt. Die Funktion
dieser Signale wird weiter unten beschrieben.
-
Die
unten stehende Tabelle 6 erläutert
verschiedene hier verwendete Symbole.
-
-
-
Tabelle
7 und Tabelle 8 definieren die Abbildung zwischen Befehlen und Funktionseinheiten.
-
-
-
-
-
-
Die
Universalregisterdatei unterstützt
32- und 40-Bit-Daten. 32-Bit-Daten sind in Einzelregistern enthalten.
40-Bit-Daten sind über
zwei Register enthalten; die 32 LSBs der Daten sind in einem geraden
Register gespeichert, während
die 8 MSBs in den 8 LSBs des nächsten
Registers (das immer ein ungerades Register ist) gespeichert sind.
Wie in Tabelle 9 gezeigt ist, gibt es für 40-Bit-Daten 16 gültige Registerpaare.
In der Syntax der Assembler-Sprache werden die Registerpaare durch
einen Doppelpunkt zwischen den Registernamen bezeichnet. Die ungeraden
Register werden zuerst spezifiziert.
-
Tabelle
9. Lange Registerpaare
-
7 veranschaulicht das Registerspeicherschema
für 40-Bit-Daten.
Operationen, die eine lange Eingabe erfordern, ignorieren die 24
MSBs des ungeraden Registers. Operationen, die ein langes Ergebnis
erzeugen, füllen
die 24 MSBs des ungeraden Registers mit Nullen auf. Das gerade Register
ist in dem Opcode codiert.
-
In
den 8A–8J ist das Opcode-Abbild
des DSP gezeigt. Wegen Erläuterungen
der Feldsyntaxen und -werte wird auf Tabelle 6 und auf die weiter
unten beschriebenen Befehlsbeschreibungen verwiesen.
-
Sämtliche
Befehle können
bedingt sein. Die Bedingung wird durch ein 3-Bit-Feld (creg), das das getestete Register
spezifiziert, und durch ein 1-Bit-Feld (z), das einen Test auf null
oder nicht null spezifiziert, gesteuert. Die vier MSBs jedes Opcodes
sind creg und z. Zu Beginn der Pipelinestufe E1 wird für alle Befehle das
Register getestet. Die Pipeline wird weiter unten beschrieben. Falls
z = 1 ist, erfolgt der Test auf Gleichheit mit null. Falls z = 0
ist, erfolgt der Test auf Verschiedenheit von null. Damit Befehle
unbedingt ausgeführt
werden können,
wird der Fall des Bedingungsregisterfelds (creg) = 0 und z = 0 immer
als wahr behandelt. Das Registerfeld creg ist wie in Tabelle 10
gezeigt codiert.
-
Tabelle
10. Register, die durch bedingte Operationen getestet werden können
-
Anmerkung:
x ist für
die reservierten Fälle
unbedeutend.
-
Bedingte
Befehle werden durch "[
]" dargestellt,
das das Bedingungsregister umgibt. Das folgende Ausführungspaket
enthält
zwei parallele ADD-Befehle. Das erste ADD hängt davon ab, dass B0 nicht
null ist. Das zweite ADD hängt
davon ab, dass B0 null ist. '!' gibt das 'nicht' der Bedingung an.
-
-
Die
obigen Befehle schließen
sich gegenseitig aus. Das heißt,
dass nur einer ausgeführt
wird.
-
Falls
sich gegenseitig ausschließende
Befehle parallel geplant werden, müssen sie weiter sämtliche weiter
unten erwähnten
Betriebsmittelbeschränkungen
befolgen.
-
Falls
sich gegenseitig ausschließende
Befehle wie weiter unten beschrieben irgendwelche Betriebsmittel
gemeinsam nutzen, können
sie nicht parallel geplant werden (in das gleiche Ausführungspaket
gegeben werden), selbst wenn schließlich nur einer ausgeführt wird.
-
Die
Ausführung
von Befehlen kann hinsichtlich Verzögerungsschlitzen definiert
werden. Tabelle 11 zeigt die Typen von Befehlen, wie viele Verzögerungsschlitze
jeder Typbefehl besitzt und die Ausführungsphasen, die er verwendet.
Die Verzögerungsschlitze
sind die Anzahl der Zusatzzyklen, die es dauert, bevor ein Ergebnis
zum Lesen verfügbar
ist, nachdem die Quelloperanden gelesen worden sind. Falls die Quelloperanden
bei einem Einzyklusbefehl (wie etwa ADD) im Zyklus i gelesen werden,
kann das Ergebnis im Zyklus i + 1 gelesen werden. Falls die Quelloperanden
bei einem Multiplikationsbefehl (MPY) im Zyklus i gelesen werden, kann
das Ergebnis in Zyklus I + 2 gelesen werden.
-
Tabelle
11. Zusammenfassung zu Verzögerungsschlitzen
-
Die
Befehle werden immer zu jeweils acht geholt. Dies bildet ein Holpaket.
Das Grundformat eines Holpakets ist in 9 gezeigt. Die Ausführungsgruppie rung des Holpakets
ist durch das p-Bit, das Bit null jedes Befehls, spezifiziert. Die
Holpakete sind 8-Wort-ausgerichtet.
-
Das
p-Bit steuert die parallele Ausführung
der Befehle. Die p-Bits werden von links nach rechts (von niedrigerer
zu höherer
Adresse) abgetastet. Falls das p-Bit des Befehls i gleich 1 ist,
ist der Befehl i + 1 parallel zu dem (im gleichen Zyklus wie der)
Befehl i auszuführen.
Falls das p-Bit des Befehls i gleich 0 ist, wird der Befehl i +
1 in dem Zyklus nach dem Befehl i ausgeführt. Sämtliche Befehle, die parallel
ausgeführt
werden, bilden ein Ausführungspaket.
Ein Ausführungspaket
kann bis zu acht Befehle enthalten. Sämtliche Befehle in einem Ausführungspaket
müssen
eine eindeutige Funktionseinheit verwenden.
-
Ein
Ausführungspaket
kann keine 8-Wort-Begrenzung überschreiten.
Somit wird das letzte p-Bit in einem Holpaket stets auf 0 gesetzt,
wobei jedes Holpaket ein neues Ausführungspaket beginnt. Die folgenden Beispiele
veranschaulichen die Umsetzung einer p-Bitfolge in einen zyklusweisen
Ausführungsbefehlsstrom. Für die Holpakete
gibt es drei Typen von p-Bitmustern. Diese drei p-Bitmuster führen zu
den folgenden Ausführungsfolgen
für die
acht Befehle: vollständig
seriell; vollständig
parallel; oder teilweise seriell. Diese drei Ausführungsfolgen
werden weiter unten umfassend erläutert.
-
Das
in
10A gezeigte vollständig serielle
p-Bitmuster führt
zu dieser Ausführungsfolge:
Die acht
Befehle werden sequentiell ausgeführt.
-
Das
in
10B gezeigte vollständig parallele
p-Bitmuster führt
zu dieser Ausführungsfolge:
Alle acht
Befehle werden parallel ausgeführt.
-
Das
in
10C gezeigte teilweise
serielle p-Bitmuster führt
zu dieser Ausführungsfolge:
Es wird
angemerkt, dass die Befehle C, D und E keine der gleichen Funktionseinheiten,
Querpfade oder anderen Datenpfadbetriebsmittel verwenden. Dies trifft
auch auf die Befehle F, G und H zu.
-
Die
Zeichen || bedeuten, dass ein Befehl parallel zu dem vorausgehenden
Befehl auszuführen
ist. In dem vorausgehenden, teilweise seriellen Beispiel wird der
Code wie folgt dargestellt:
-
-
Falls
eine Verzweigung zur Mitte eines Ausführungspakets auftritt, werden
sämtliche
Befehle bei niedrigeren Adressen ignoriert. Falls in dem teilweise
seriellen Beispiel eine Verzweigung zu der Adresse auftritt, die
den Befehl D enthält,
werden lediglich D und E ausgeführt.
Obgleich der Befehl C in demselben Ausführungspaket ist, wird er ignoriert.
Da die Befehle A und B in früheren
Ausführungspaketen
sind, werden sie ebenfalls ignoriert.
-
Keine
zwei Befehle in demselben Ausführungspaket
können
die gleichen Betriebsmittel verwenden. Außerdem können keine zwei Befehle während desselben
Zyklus in dasselbe Register schreiben. Im Folgenden wird jedes der
Betriebsmittel beschrieben, das ein Befehl verwenden kann.
-
Zwei
Befehle, die dieselbe Funktionseinheit verwenden, können in
demselben Ausführungspaket
ausgegeben werden.
-
Das
folgende Ausführungspaket
ist ungültig:
-
-
Das
folgende Ausführungspaket
ist gültig:
-
-
Querpfade
(1X und 2X): Eine Einheit (entweder ein .S, ein .L, oder ein .M)
kann pro Datenpfad und pro Ausführungspaket über die
Querpfade (1X und 2X) einen Quelloperanden von ihrer entgegengesetzten
Registerdatei lesen. Beispielsweise kann .S1 unter Verwendung des
Querpfads 1X beide Operanden aus der Registerdatei A oder einen
Operanden aus der Registerdatei B lesen. Dies wird durch ein X nach
dem Einheitsnamen bezeichnet.
-
Da
es nur einen Pfad von A zu B und nur einen Pfad von B zu A gibt,
können
zwei Befehle, die den gleichen Querpfad X zwischen den Registerdateien
verwenden, nicht in demselben Ausführungspaket ausgegeben werden.
-
Das
folgende Ausführungspaket
ist ungültig:
-
-
Das
folgende Ausführungspaket
ist gültig:
-
-
sFalls
das x-Bit in dem Befehlsfeld (wie in dem Opcode-Abbild gezeigt)
gesetzt ist, kommt der Operand aus einer Registerdatei, die zu dem
Ziel entgegengesetzt ist.
-
Lade-
und Speichervorgänge
können
beim Laden in oder beim Speichern aus der anderen Registerdatei
einen Adressenzeiger von einer Registerdatei verwenden. Zwei Lade-
und/oder Speichervorgänge,
die einen Adressenzeiger aus derselben Registerdatei verwenden,
können
nicht in demselben Ausführungspaket ausgegeben
werden.
-
Das
folgende Ausführungspaket
ist ungültig:
-
-
Das
folgende Ausführungspaket
ist gültig:
-
-
Zwei
Lade- und/oder Speichervorgänge,
die in dieselbe Registerdatei laden und/oder aus ihr speichern,
können
nicht in demselben Ausführungspaket
ausgegeben werden.
-
Das
folgende Ausführungspaket
ist ungültig:
-
-
Das
folgende Ausführungspaket
ist gültig:
-
-
Pro
Zyklus kann lediglich ein langes Ergebnis auf jede Seite der Registerdatei
geschrieben werden. Da die Einheiten .S und .L einen Leseregisterport
für lange
Quelloperanden und einen Schreibregisterport für lange Ergebnisse gemeinsam
nutzen, kann in einem Ausführungspaket
lediglich eines pro Seite ausgegeben werden.
-
Das
folgende Ausführungspaket
ist ungültig:
-
-
Das
folgende Ausführungspaket
ist gültig:
-
-
Da
die Einheiten .L und .S ihren langen Leseport mit dem Speicherport
gemeinsam nutzen, können Operationen,
die einen langen Wert lesen, nicht in demselben Ausführungspaket
wie ein Speichervorgang in die Einheiten .L und/oder .S ausgegeben
werden.
-
Das
folgende Ausführungspaket
ist ungültig:
-
-
Das
folgende Ausführungspaket
ist gültig:
-
-
Mehr
als vier Lesevorgänge
des gleichen Registers in demselben Zyklus können nicht auftreten. Bedingte
Register sind in dieser Zählung
nicht enthalten.
-
Die
folgende Codefolge ist ungültig:
während diese
Codefolge gültig
ist:
-
-
Mehrfachschreibvorgänge in dasselbe
Register in demselben Zyklus können
stattfinden, falls Befehle mit verschiedenen Latenzzeiten, die in
dasselbe Register schreiben, in verschiedenen Zyklen ausgegeben werden.
Beispielsweise kann ein MPY, das im Zyklus i ausgegeben wird und
auf das ein ADD im Zyklus i + 1 folgt, nicht in dasselbe Register
schreiben, da beide Befehle im Zyklus i + 1 ein Ergebnis schreiben.
Somit ist die folgende Codefolge ungültig:
-
-
Tabelle
12 zeigt verschiedene Mehrfachschreibkonflikte. Beispielsweise schreiben
das ADD und das SUB im Ausführungspaket
L1 in dasselbe Register. Dieser Konflikt ist leicht erfassbar.
-
Das
MPY im Paket L2 und das ADD im Paket L3 könnten beide gleichzeitig in
B2 schreiben; allerdings wäre
dies kein Konflikt, wenn ein Verzweigungsbefehl bewirken würde, dass
das Ausführungspaket
nach L2 verschieden von L3 ist. Somit könnte der potentielle Konflikt
in L2 und L3 von einem Assembler nicht erfasst werden. Da sich die
Befehle in L4 gegenseitig ausschließen, bilden sie keinen Schreibkonflikt.
Da nicht offensichtlich ist, dass sich die Befehle im L5 gegenseitig
ausschließen,
kann der Assembler demgegenüber
keinen Konflikt bestimmen. Falls die Pipeline Befehle zum Ausführen von
Mehrfachschreibvorgängen
in dasselbe Register empfängt,
ist das Ergebnis unbestimmt.
-
Tabelle
12. Beispiele der Erfassbarkeit von Schreibkonflikten durch den
Assembler
-
Die
Adressierungsbetriebsarten sind linear, zirkulär unter Verwendung von BK0
und zirkulär
unter Verwendung von BK1. Die Betriebsart wird durch das Adressierungsbetriebsartregister
(AMR) spezifiziert.
-
Acht
Register können
eine zirkuläre
Adressierung ausführen.
A4–A7
werden von der Einheit .D1 verwendet, während B4–B7 von der Einheit .D2 verwendet
werden. Keine anderen Einheiten können zirkuläre Adressierungsbetriebsarten
ausführen.
Das AMR spezifiziert für
jedes dieser Register die Adressierungsbetriebsart.
-
Die
folgenden Befehle verwenden sämtlich
das AMR, um zu bestimmen, welche Typen von Adressenberechnungen
für diese
Register ausgeführt
werden: LD(B)(H)(W), ST(B)(H)(W), ADDA(B)(H)(W) und SUBA(B)(H)(W).
Alle Register können
die Adressierung der linearen Betriebsart ausführen.
-
Die
Adressierung der linearen Betriebsart arbeitet wie folgt mit den
Befehlen LD/ST: Die lineare Betriebsart verschiebt einfach den Operanden
offsetR/cst für
einen Wort-, Halbwort oder Bytezugriff jeweils um 2, 1 bzw. 0 nach
links und führt
daraufhin (je nach der spezifizierten Operation) eine Addition oder
Subtraktion von baseR aus.
-
Die
Adressierung der linearen Betriebsart arbeitet wie folgt mit den
Befehlen ADDA/SUBA: Die lineare Betriebsart verschiebt einfach den
Operanden src1/cst für
einen Wort-, Halbwort- oder Bytezugriff jeweils um 2, 1 bzw. 0 nach
links und führt
daraufhin (je nach der spezifizierten Operation) eine Addition oder
Subtraktion aus.
-
Die
Adressierung der zirkulären
Betriebsart verwendet die Felder BK0 und BK1 in dem AMR, um die Blockgrößen für die zirkuläre Adressierung
zu spezifizieren. Die Adressierung der zirkulären Betriebsart arbeitet wie
folgt mit den Befehlen LD/ST: Nach dem Verschieben von offsetR/cst
für LDW,
LDH oder LDB jeweils um 2, 1 oder 0 nach links wird eine Addition
oder Subtraktion ausgeführt,
wobei der Übertrag/das
Borgen zwischen den Bits N und N + 1 verhindert ist. Die Bits N
+ 1 bis 31 von baseR bleiben ungeändert. Sämtliche anderen Überträge/Borgungen
pflanzen sich wie üblich
fort. Somit liegt die Adresse außerhalb des Ringpuffers, wenn
ein offsetR/cst größer als
die Ringpuffergröße 2(N + 1) spezifiziert ist. Die Ringpuffergröße in dem
AMR wird nicht skaliert; z. B.: eine Größe von 4 ist 4 Bytes, nicht
4 · Größe von (Typ).
Somit sollte eine Größe von 32 oder
N = 4 spezifiziert werden, um an dem Datenfeld von 8 Wörtern eine
zirkuläre
Adressierung auszuführen. Tabelle
12 zeigt ein mit dem Register A4 in der zirkulären Betriebsart mit BK0 = 4
ausgeführtes
LDW, so dass die Puffergröße 32 Bytes,
16 Halbwörter
oder 8 Wörter
ist. Der in das AMR gegebene Wert ist für dieses Beispiel 0004 0001h.
-
Tabelle
13. LDW in der zirkulären
Betriebsart
-
-
Anmerkung:
9h Wörter
sind 24h Bytes. 24h Bytes sind 4 Bytes über die 32-Byte-Begrenzung (20h-Byte-Begrenzung)
100h–11Fh
hinaus, so dass es auf 104h zurückgesetzt
wird.
-
Die
Adressierung der zirkulären
Betriebsart arbeitet wie folgt mit den Befehlen ADDA/SUBA: Nach dem
Verschieben von src1/cst für
ADDAW, ADDAH oder ADDAB jeweils um 2, 1 oder 0 nach links wird eine Addition
oder Subtraktion ausgeführt,
wobei der Übertrag/das
Borgen zwischen den Bits N und N + 1 verhindert ist. Die Bits N
+ 1 bis 31 einschließlich
src2 bleiben ungeändert.
Sämtliche
weiteren Überträge/Borgungen pflanzen
sich wie üblich
fort. Somit liegt die Adresse außerhalb des Ringpuffers, wenn
src1 größer als
die Ringpuffergröße 2(N+ 1) spezifiziert ist. Die Ringpuffergröße in dem
AMR wird nicht skaliert, z. B.: eine Größe von 4 ist 4 Bytes, nicht
4 · Größe von (Typ).
Somit sollte eine Größe von 32
oder N = 4 spezifiziert werden, um an einem Datenfeld von 8 Wörtern eine
zirkuläre
Adressierung auszuführen.
Tabelle 14 zeigt ein mit dem Register A4 in der zirkulären Betriebsart
mit BK0 = 4 ausgeführtes
ADDAH, so dass die Puffergröße 32 Bytes,
16 Halbwörter
oder 8 Wörter
ist. Der in das AMR gegebene Wert ist für dieses Beispiel 0004 0001h.
-
Tabelle
14. ADDAH in der zirkulären
Betriebsart
-
-
Anmerkung:
13h Halbwörter
sind 26h Bytes. 26h Bytes sind 6 Bytes über die 32-Byte-Begrenzung (20h-Byte-Begrenzung)
100h–11Fh
hinaus, so dass es auf 106h zurückgesetzt
wird.
-
Zur
Beschreibung jedes Befehls wird eine Befehlssyntax verwendet. Die
Opcode-Abbildung zerlegt die verschiedenen Bitfelder, die jeden
Befehl ergeben. Wie in Tabelle 8 gezeigt wurde, gibt es bestimmte
Befehle, die in mehr als einer Funktionseinheit ausgeführt werden
können.
Die Syntax spezifiziert die Funktionseinheit und die verschiedenen
von einem Befehl verwendeten Betriebsmittel typischerweise wie folgt:
EXAMPLE
(.unit) src, dst
-
So
sieht die Syntax für
den ADD-Befehl aus:
-
- ADD (.unit) src1, src2, dst
- ODER
- ADDU (.unit) src1, src2, dst
- ODER
- ADD (.unit) src2, src1, dst
- unit = .L1,.L2,.51,.52,.D1,.D2.
-
src
und dst geben die Quelle bzw. das Ziel an. Das (.unit) schreibt
vor, auf welche Funktionseinheit (.L1,.L2,.S1,.52,.M1,.M2,.D1 oder
.D2) der Befehl abgebildet wird. Dieser Befehl besitzt drei Opcode-Abbildungsfelder:
src1, src2 und dst.
-
Pipelinebetrieb
-
Die
DSP-Pipeline besitzt mehrere Hauptmerkmale, die die Leistung verbessern,
die Kosten senken und die Programmierung vereinfachen. Sie sind:
die erhöhte
Pipeline-Verarbeitung beseitigt Engpässe herkömmlicher Architekturen bei
Programmhol-, Datenzugriffs- und Multiplikationsoperationen; durch
die Beseitigung von Pipeline-Verriegelungen wird die Steuerung der
Pipeline vereinfacht; die Pipeline kann in jedem Zyklus acht parallele
Befehle absenden; parallele Befehle schreiten gleichzeitig durch
die gleichen Pipelinephasen fort; aufeinander folgende Befehle schreiten
mit der gleichen relativen Pipelinephasen-Differenz fort; und Lade-
und Speicheradressen erscheinen während derselben Pipelinephase
an der CPU-Begrenzung, was Lesen-nach-Schreiben-Speicherkonflikte
beseitigt.
-
Sowohl
für Datenzugriffe
als auch für
Programmholvorgänge
ist eine mehrstufige Speicherpipeline vorhanden. Dies ermöglicht sowohl
die Verwendung schneller synchroner On-Chip- als auch Off-Chip-Speicher
und ermöglicht
unendlich verschachtelbare Schleifen ohne Organisationsaufwand mit
Verzweigungen parallel zu anderen Befehlen.
-
Es
gibt keine internen Verriegelungen in den Ausführungszyklen der Pipeline,
so dass in jedem CPU-Zyklus ein neues Ausführungspaket in die Ausführung eintritt.
Somit ist die Anzahl der CPU-Zyklen für einen besonderen Algorithmus
mit besonderen Eingangsdaten festgesetzt. Falls es während der
Programmausführung
keine Speicherblockierungen gibt, ist die Anzahl der CPU-Zyklen
für ein
auszuführendes
Programm gleich der Anzahl der Taktzyklen.
-
Die
Ausführung
kann lediglich durch Blockierungen von den Speicheruntersystemen
oder durch Unterbrechungen verhindert werden. Die Gründe für Speicherblockierungen
sind durch die Speicherarchitektur bestimmt. Um umfassend zu verstehen,
wie ein Programm auf Geschwindigkeit zu optimieren ist, sollte die
Folge von Programmhol-, Datenspeicher- und Datenladeanforderungen,
die das Programm erzeugt, verstanden werden und sollte verstanden
werden, wie sie die CPU blockieren könnten.
-
Von
einem funktionellen Gesichtspunkt aus beruht der Pipelinebetrieb
auf CPU-Zyklen. Ein CPU-Zyklus ist die Zeitdauer, während der
ein besonderes Ausführungspaket
in einer besonderen Pipelinestufe ist. Die CPU-Zyklusbegrenzungen
treten immer an Taktzyklusbegrenzungen auf; allerdings können Speicherblockierungen
bewirken, dass sich CPU-Zyklen über
mehrere Taktzyklen erstrecken. Um den Maschinenzustand an den CPU-Zyklusbegrenzungen
zu verstehen, brauchen lediglich die Ausführungspipelinephasen (E1–E5) betrachtet
zu werden. Die Pipelinephasen sind in 11 gezeigt und in Tabelle 15 beschrieben.
-
-
-
Der
Pipelinebetrieb der Befehle kann in sieben in Tabelle 16 gezeigte
Typen klassifiziert werden. Die Verzögerungsschlitze für jeden
Befehlstyp sind in der zweiten Spalte aufgeführt.
-
Tabelle
16. Zusammenfassung der Verzögerungsschlitze
-
Die
Ausführung
der Befehle kann hinsichtlich der Verzögerungsschlitze (Tabelle 16)
definiert werden. Ein Verzögerungsschlitz
ist ein CPU-Zyklus, der nach der ersten Ausführungsphase (E1) eines Befehls,
in der die Ergebnisse von der Ausführung nicht verfügbar sind,
stattfindet. Beispielsweise besitzt ein Multiplikationsbefehl 1
Verzögerungsschlitz,
d. h. es gibt 1 CPU-Zyklus, bevor ein weiterer Befehl die Ergebnisse
von dem Multiplikationsbefehl verwenden kann.
-
Einszyklusbefehle
werden während
der Pipelinephase E1 ausgeführt.
Sämtlich
während
E1 wird ein Operand gelesen, wird eine Operation ausgeführt und
werden die Ergebnisse in ein Register geschrieben. Diese Befehle
besitzen keine Verzögerungsschlitze.
-
Muatiplikationsbefehle
schließen
ihre Operationen während
der Pipelinephase E2 ab. In der Phase E1 wird der Operand gelesen
und beginnt die Multiplikation. In der Phase E2 wird die Multiplikation
abgeschlossen und das Ergebnis in das Zielregister (dst) geschrieben.
Multiplikationsbefehle besitzen 1 Verzögerungsschlitz.
-
Ladebefehle
besitzen zwei Ergebnisse: Die aus dem Speicher geladenen Daten und
die Adressenzeigeränderung.
-
Die
Operationen von Datenladevorgängen
werden während
der Pipelinephase E5 abgeschlossen. In der Phase E1 wird die Adresse
der Daten berechnet. In der Phase E2 wird die Datenadresse an den
Datenspeicher gesendet. In der Phase E3 wird ein Speicherlesen ausgeführt. In
der Phase E4 werden die Daten an der Begrenzung des CPU-Kerns empfangen.
Schließlich
werden die Daten in der Phase E5 in ein Register geladen. Da die
Daten bis E5 nicht in das Register geschrieben werden, besitzen
diese Befehle 4 Verzögerungsschlitze.
Da die Zeigerergebnisse in E 1 in das Register geschrieben werden,
gibt es im Zusammenhang mit der Adressenänderung keine Verzögerungsschlitze.
-
Die
Operationen von Speicherbefehlen werden während der Pipelinephase E3
abgeschlossen. In der Phase E1 wird die Adresse der Daten berechnet.
In der Phase E2 wird die Datenadresse an den Datenspeicher gesendet.
In der Phase E3 wird ein Speicherschreiben ausgeführt. In
der Pipelinephase E1 wird die Adressenänderung ausgeführt. Obgleich
die Ausführung
von Speichervorgängen
in der Pipelinephase E3 abgeschlossen wird, besitzen sie keine Verzögerungsschlitze
und folgen den folgenden Vorschriften (i = Zyklus):
- 1) Wenn vor einem Speichervorgang ein Ladevorgang ausgeführt wird,
wird der alte Wert geladen und der neue Wert gespeichert.
- 2) Wenn vor einem Ladevorgang ein Speichervorgang ausgeführt wird,
wird der neue Wert gespeichert und der neue Wert geladen.
- 3) Wenn die Befehle parallel sind, wird der alte Wert geladen
und der neue Wert gespeichert.
-
Verzweigungsbefehle
werden während
der Pipelinephase E1, fünf
Verzögerungsschlitze/CPU-Zyklen, nachdem
der Verzweigungsbefehl in eine Anfangspipelinephase E1 eingetreten
ist, ausgeführt. 12 zeigt die Verzweigungsbefehlsphasen. 13 zeigt anhand der Taktzyklen
und der Holpakete den Betrieb der Pipeline. Falls in 13 eine Verzweigung im
Holpaket n ist, ist die Verzweigungsphase E1 die Phase PG von n
+ 6. Im Zyklus 7 ist n in der Phase E1 und n + 6 in der Phase PG.
Da das Verzweigungsziel im Zyklus 7 in PG ist, erreicht es bis zum
Zyklus 13 nicht E1. Somit erscheint es, als ob die Ausführung der
Verzweigung sechs Zyklen dauert oder fünf Verzögerungsschlitze besitzt.
-
In 14 ist das Holpaket n,
das drei Ausführungspakete
enthält,
gezeigt, worauf sechs Holpakete (n + 1 bis n + 6), jedes mit einem
Ausführungspaket
(das 8 parallele Befehle enthält),
folgen. Das erste Holpaket (n) durchläuft während der Zyklen 1–4 die Programmholphasen.
Während
dieser Zyklen wird für
jedes der folgenden Holpakete eine Programmholphase gestartet.
-
In
Zyklus 5, der Programmabsendephase (DP-Phase) tastet die CPU die
p-Bits ab, wobei sie erfasst, dass es in dem Holpaket n drei Ausführungspakete
(k bis k + 2) gibt. Dies zwingt die Pipeline zu blockieren, was
ermöglicht,
dass die Phase DP in den Zyklen 6 und 7 mit der Ausführung der
Pakete k + 1 und k + 2 beginnt. Wenn das Ausführungspaket k + 2 bereit ist,
zur Phase DC weiterzugehen (Zyklus 8), wird die Pipelineblockierung
freigegeben.
-
Die
Holpakete n + 1 bis n + 4 wurden sämtlich blockiert, so dass die
CPU Zeit hätte,
die Phase DP für jedes
der drei Ausführungspakete
(k bis k + 2) im Holpaket n auszuführen. Das Holpaket n + 5 wurde
in den Zyklen 6 und 7 ebenfalls blockiert; es wurde erst ermöglich, dass
es in die Phase PG eintritt, nachdem in Zyk lus 8 die Pipelineblockierung
freigegeben wurde. Die Pipeline fährt wie gezeigt mit den Holpaketen
n + 5 und n + 6 fort, bis ein weiteres Holpaket, das mehrere Ausführungspakete
enthält,
in die Phase DP eintritt oder bis eine Unterbrechung auftritt.
-
Durch
Speicherblockierungen, Mehrzyklen-NOPs und den STP-Befehl werden
Pipeline-Unstetigkeiten verursacht. Während einer Speicherblockierung
tritt der CPU-Zyklus (der normalerweise während eines Taktzyklus auftritt)
in zwei oder mehr Zyklen auf. Während
dieser Zusatztaktzyklen sind sämtliche
Pipelinephasen blockiert. Die Ergebnisse der Programmausführung mit
oder ohne die Blockierung sind völlig
gleich. Bei einer Speicherblockierung dauert es mehr Taktzyklen,
bis die Ausführung
abgeschlossen ist.
-
Der
NOP-Zählbefehl
liefert die Zählzyklen
von NOPs. Falls der Zählstand
2 ist, ist das NOP ein Mehrzyklen-NOP. Beispielsweise füllt ein
NOP 2 die Zusatzverzögerungsschlitze
für die
Befehle in dem Ausführungspaket,
in dem es enthalten ist, und für
alle früheren
Ausführungspakete
aus. Somit sind die Ergebnisse von MPY zur Verwendung durch Befehle
in dem nächsten
Ausführungspaket
verfügbar,
falls ein NOP 2 parallel zu einem MPY-Befehl ist. Falls die Verzögerungsschlitze
einer Verzweigung abgeschlossen werden, während ein Mehrzyklen-NOP weiter
NOPs in die Pipeline absendet, überschreibt
die Verzweigung das Mehrzyklen-NOP, wobei das Verzweigungsziel nach
5 Verzögerungsschlitzen
mit der Ausführung
beginnt.
-
STP
ist ein fortgeschrittener Befehl, der nur dann verwendet werden
kann, wenn diese beiden Bedingungen erfüllt sind: 1) Er kann keinen
parallelen Verzweigungsbefehl enthalten, der ein Programmholen erzwingen
würde und
2) es findet kein Programmholen statt, da entweder sein zweiter
Verzögerungsschlitz
ein Mehrzyklen-NOP enthält
oder die Ausführungspakete
seines dritten und vierten Verzögerungsschlitzes
im selben Holpaket sind.
-
Speichersystem
-
Das
DSP-Programmspeichersystem 23 enthält 64 KBytes Speicher sowie
einen Speicher/Cache-Controller. Der Programmspeicher kann entweder
als ein interner 64 KByte-Programmspeicher oder als ein direkt abgebildeter
Programm-Cache arbeiten.
Es gibt vier Betriebsarten, gemäß denen
das Programmspeichersystem arbeitet: Programmspeicherbetriebsart;
Cache-Freigabebetriebsart; Cache-Einfrierbetriebsart;
und Cache-Umgehungsbetriebsart. Diejenige Betriebsart, gemäß der der
Programmspeicher arbeitet, wird durch das Programm-Cache-Steuerfeld
(PCC-Feld) (Bits 5–7)
in dem CSR (4) bestimmt.
Tabelle 17 zeigt verschiedene PCC-Werte zur Konfigurierung des Programmspeichersystems 23.
-
Tabelle
17. Programm- und Daten-Cache-Felder
-
Wenn
das Feld PCC des CSR den Wert 000b enthält, wird der Programmspeicher
als gültiger
Programmspeicherraum abgebildet. Die Adressen, die das Programmspeicherabbild
ergeben, hängen
von dem Wert an dem Anschlussstift MAP_BOOT an der Vorrichtung ab.
-
Emulationsmerkmale
-
Ein
Aspekt der vorliegenden Erfindung umfasst neue und verbesserte Techniken
zur Emulation des Betriebs des DSP 1, um Softwareprogramme zu entwickeln
oder um den DSP 1 auf richtigen Betrieb zu testen. Es werden
nun diejenigen Abschnitte des DSP 1 ausführlicher
beschrieben, die sich auf die Emulation beziehen.
-
Wieder
anhand von 1 besitzt
die CPU 10 eine Emulationsschaltungsanordnung 50 und
eine Unterbrechungsschaltungsanordnung 90, die die folgenden
Emulationsfunktionen, die ausführlicher
beschrieben werden, unterstützen:
Ausführungs-
und Scan-Steuerung über
die Testports; Analyseunterstützung;
und Echtzeitemulationsunterstützung.
-
Die
Ausführungs-
und Scan-Steuerung über
die Testports umfasst das Anhalten der CPU 10. Die Unterstützung von
CPU-Halts ist auf folgende Weise vorgesehen: ein RDY-basierter CPU-Halt,
der auf einem Softwareunterbrechungspunkt (SWBP) oder auf einem
Analyseereignis beruht.
-
Die
Analyseunterstützung
umfasst das Folgende: einen einzelnen Hardware-Progranunadressenunterbrechungspunkt
(Hardware-PABP) mit genauer Anpassung; Analyseereignisse, die durch
die Eingangssignale EMUOIN oder EMU1IN von dem Megamodul-Testzugriffsport
(MTAP) oder durch einen Programmadressenunterbrechungspunkt ausgelöst werden
können;
und ein Spezialemulationsereignis-Eingangssignal (SEE), das ein
Analyseereignis auslösen
kann.
-
Die
Echtzeitemulationsunterstützung
umfasst eine Nachrichtenübergabe
und eine CPU-Analyseunterbrechung (AINT), die auf einer Softwareunterbrechung,
auf einem Analyseereignis oder auf der nächsten Zyklusbegrenzung beruhen.
-
Nunmehr
anhand von 15 ist die
Emulationsschaltungsanordnung 50 ausführlicher gezeigt. Der Megamodul-Testzugriffsport
(MTAP) 305 ist mit dem CPU-Testport (CPUTP) 310,
mit dem Analysetestport (ATP) 320 und mit dem Megamodultestport
(ATP) 330 verbunden. Mit den Testports sind drei Domänen, die CPU-Domäne 10,
die Analysedomäne 321 und
die Megamoduldomäne 331,
verbunden. Der MTAP 305 stellt die Scan- und Ausführungssteuerung
für die
verschiedenen Domänen
in dem Megamodul bereit. Die Testports stellen für jede Domäne eine Schnittstelle zu dem
MTAP bereit. Außerdem
erzeugen und verteilen die Testports die Taktumschaltfunktionen
für die
Funktions- und Scan-Takte an dem Megamodul und führen sie aus. Der MTAP 305 stellt
eine Schnittstelle zwischen dem XDS 51 und den Echtzeitanalyse-
und Nachrichtenübergabe-Merkmalen der CPU
bereit. Gemäß einem
Aspekt der vorliegenden Erfindung schafft der MTAP 305 einen
Datenstrom für
den schnellen Speicher-Download/Upload. Außerdem unterstützt der
MTAP 305 über
einen Ereigniszähler
und über
die Testportsteuerung der Ausführung
und Taktung sowohl für
die Emulation als auch für
den Test die Leistungsanalyse. Der Betrieb und der Entwurf der Emulationsschaltungsanordnung 50 einschließlich des
MTAP 305 und der Testports 310, 320 und 330 werden
auf den folgenden Seiten ausführlich beschrieben.
-
Eine
Spezialemulationsvorrichtung (SE-Vorrichtung) schafft eine Schnittstelle
zum MTAP 305 und zum Megamodul 300 als Ganzes,
um eine erhöhte
Austest-, Ablaufverfolgungs- und Unterbrechungspunktfähigkeit zu
schaffen. Eine Spezialemulationsvorrichtung (SE) besitzt eine vierte
Domäne
für die
SE-Analysedomänenschaltungsanordnung
(SEA-Domänenschaltungsanordnung),
die außerhalb
des Megamoduls liegt. Die SEA-Domänenschnittstelle zu dem Megamodul über den
MTAP wird auf den folgenden Seiten ebenfalls ausführlich beschrieben.
Die SEA-Domäne
enthält:
Hardwaredatenunterbrechungspunkte bei Daten und bei der Adresse;
Hardwareprogramm-Unterbrechungspunkte bei Adressen der Ausführungspakete,
die zur Ausführung
abgesendet werden; Ablaufverfolgung der ausgeführten Programmadressen und
der Programm- und Datenspeicherzugriffe; genommene Unterbrechungen,
die Funktionseinheitsnutzung und Verzweigungen; und Ereigniszähler und
Ablaufsteuerungen.
-
16 ist ein Zeitablaufplan,
der eine Megamodul-Rücksetzoperation
und verwandte Signale zeigt. Es wird angemerkt, dass während dieses
gesamten Prozesses ein inaktives RDY die CPU weiter blockieren kann,
mit anderen Worten, CPU-Zyklen über
mehrere Taktzyklen erweitern kann. Die Folge der auftretenden Ereignisse
ist wie folgt:
- 1. Takt n + 2: Dies ist der erste
Taktzyklus, nachdem NRESET tief wird. Die folgenden Aktionen finden
statt, falls der CPU-Testport in dem Zustand FUNC ist:
- A) Sämtliche
internen Tristate-Busse sind hochimpedant. Sie bleiben bis zum Zyklus
6 hochimpedant.
- B) LOGXOFFD ist aktiviert, was angibt, dass sämtliche
Nicht-Programmspeichersystem-Vorrichtungen Megamodulübernahmen
(DBS, PWRDN, JACK) ignorieren.
- C) LOGXOFFP ist aktiviert, was angibt, dass der Programmspeicher
Programmspeicherübernahmen
ignorieren sollte: PAS, PDS, PWS.
- 2. Zyklus n + 2: Falls der CPU-Testport in dem Zustand FUNC
ist, werden sämtliche
Befehle in den Pipelinephasen DP und E1 annulliert.
- 3. Zyklus 1: Eine unbestimmte Anzahl von Taktzyklen später findet
bei der steigenden Flanke von NRESET die Rücksetzunterbrechungsverarbeitung
statt.
- 4. Zyklus 6: Wenn JACK aktiv wird, werden sämtliche Register und Begrenzungssignale
mit Ausnahme von PWS, PAS, PDS auf ihre Rücksetzwerte gesetzt. LOGXOFFD
wird deaktiviert.
- 5. Zyklus 7: Da das erste PAS aktiv ist, wird LOGXOFFP deaktiviert.
-
Unterbrechungsoperation
-
Die
CPU besitzt 14 Unterbrechungen, die für den normalen DSP-Betrieb
verfügbar
sind. Diese sind Rücksetzen,
die nicht maskierbare Unterbrechung (NMI) und die Unterbrechungen
4–15.
Diese Unterbrechungen entsprechen den Signalen RESET, NMI und INT4-INT15
an der CPU-Begrenzung. Bei einigen Ausführungsformen können diese
Signale direkt an Anschlussstifte an der Vorrichtung gebunden sein,
können
sie an On-Chip-Peripherieeinrichtungen angeschlossen sein oder können sie
gesperrt sein, indem sie dauerhaft on-Chip inaktiv gebunden sind.
RESET und NMI sind allgemein direkt mit Anschlussstiften an der
Vorrichtung verbunden.
-
Die
Prioritäten
dieser Unterbrechungen sind in Tabelle 18 aufgeführt. Ein Tief-Hoch-Übergang
an einem Unterbrechungsanschlussstift setzt den anstehenden Status
der Unterbrechung innerhalb des Unterbrechungsmerkerregisters (IFR).
Falls die Unterbrechung richtig freigegeben ist, beginnt die CPU
mit der Verarbeitung der Unterbrechung und mit dem Umleiten des
Programmablaufs zu der Unterbrechungsdienstroutine.
-
Tabelle
18: Unterbrechungsprioritäten
-
Es
kann nicht verhindert werden, dass die CPU ein Rücksetzen verarbeitet. Die Verarbeitung
eines Rücksetzens
beginnt, wenn das RESET einen Tief-Hoch-Übergang
erfährt.
Anders als die anderen Unterbrechungen ist das Signal RESET als
aktiv-tief gekennzeichnet. Ein tiefer Wert an RESET besitzt die
Wirkung, die gesamte CPU-Verarbeitung anzuhalten und sämtliche
Register auf ihre Rücksetzwerte
zurückzustellen.
-
Die
nichtmaskierbare Unterbrechung (NMI) ist die Unterbrechung mit der
zweithöchsten
Priorität.
Zwei Bedingungen verhindern, dass die NMI eine Unterbrechungsverarbeitung
bewirkt: Die CPU ist in den Verzögerungsschlitzen
einer Verzweigung, gleich, ob die Verzweigung genommen wird oder
nicht; und das NMI-Freigabebit (NMIE) in dem Unterbrechungsfreigaberegister
(IER) ist 0. Die NMIE wird beim Rücksetzen gelöscht, um
eine Unterbrechung der Prozessorinitialisierung zu verhindern, während es
bei der NMI-Verarbeitung gelöscht
wird, um eine erneute Unterbrechung einer NMI durch eine weitere
NMI zu verhindern. Die NMI wird wieder freigegeben, indem die NMIE
gesetzt wird oder indem die Ausführung
eines B NRP-Befehls abgeschlossen wird.
-
Falls
die NMIE 0 ist, werden die INT4–INT15
gesperrt. Während
der NMI-Verarbeitung
wird der Rücksprungzeiger,
der die frühere
Programmausführung
fortsetzt, in dem NMI-Rücksprungzeigerregister
(NRP) gespeichert. Somit kehrt der Befehl B NRP nach Bedienung des
NMI zu dem früheren
Programmablauf zurück. Tabelle
19 zeigt, wie von einem NMI zurückzukehren
ist.
-
Tabelle
19: Rückkehr
von einem NMI
-
Die
folgenden Bedingungen können
verhindern, dass die INT4–INT15
eine Unterbrechungsverarbeitung verursachen: Die CPU verarbeitet
Code, der in den Verzögerungsschlitzen
einer Verzweigung liegt, und dieser enthält bedingte Verzweigungen,
die die Ausführung
wegen einer Falsch-Bedingung nicht abschlie ßen; das NMIE-Bit in dem Unterbrechungsfreigaberegister
(IER) ist 0; das entsprechende Unterbrechungsfreigabebit (IE-Bit)
in dem IER ist 0; oder das globale Unterbrechungsfreigabebit (GIE-Bit)
in dem Steuerstatusregister (CSR) ist 0.
-
Während der
Unterbrechungsverarbeitung wird der Rücksprungzeiger, der die frühere Programmausführung fortsetzt,
in dem Unterbrechungs-Rücksprungzeigerregister
(IRP) gespeichert. Somit kehrt der Befehl B IRP nach Bedienung der
Unterbrechung zu dem Programmablauf zurück. Tabelle 20 zeigt, wie von
einer maskierbaren Unterbrechung zurückzukehren ist.
-
Tabelle
20. Rückkehr
von einer maskierbaren Unterbrechung
-
Die
Signale IACK und INUM warnen die gegenüber der Vorrichtung 11 externe
Hardware, wenn Unterbrechungen stattgefunden haben. Das Signal IACK
gibt an, dass die CPU mit der Verarbeitung einer Unterbrechung begonnen
hat. Die Signale INUMx (INUM0–INUM3)
geben die Nummer der Unterbrechung (die Bitstelle in dem IFR) an,
die verarbeitet wird.
-
Tabelle
21 führt
die sieben Unterbrechungssteuerregister in der Vorrichtung auf.
-
Tabelle
21. Unterbrechungssteuerregister
-
Das
IFR und das ISR nutzen eine Registeradresse gemeinsam. Aus dem IFR
kann gelesen werden und in das ISR kann geschrieben werden. Die
anderen Register besitzen eindeutige Adressen.
-
Eine
Unterbrechung kann nur dann eine Unterbrechungsverarbeitung auslösen, wenn
das entsprechende Bit in dem Unterbrechungsfreigaberegister (IER)
gesetzt ist. Das Bit 0, das dem Rücksetzen entspricht, ist nicht
schreibbar und wird immer als 1 gelesen. Die RESET-Unterbrechung
ist immer freigegeben. RESET kann nicht gesperrt werden. Die Bits
IE4–IE15
können
als 1 oder 0 geschrieben werden, wobei die zugeordnete Unterbrechung
freigegeben bzw. gesperrt wird. Das IER ist in 17B gezeigt.
-
Wenn
die NMIE gelöscht
ist, sperrt es sämtliche
Nichtrücksetzunterbrechungen,
was eine Unterbrechung des NMI verhindert. Die NMI-Freigabe (NMIE) wird
vom Schreiben von 0 nicht beeinflusst, aber durch ein Schreiben
einer 1 gesetzt. Um irgendeine Unterbrechung der Prozessorinitialisierung
zu verhindern, bis sie vom Anwender freigegeben wird, wird die NMIE
beim Rücksetzen
auf 0 initialisiert. Nach dem Rücksetzen muss
der Anwender die NMIE setzen, um den NMI freizugeben und um zu ermöglichen,
dass die INT15–INT4 durch
die GIE und das richtige IE-Bit freigegeben werden. Der Anwender
kann die NMIE nicht manuell löschen. Die
NMIE wird durch das Auftreten eines NMI gelöscht. Falls die NMIE gelöscht ist,
wird sie lediglich durch den Abschluss eines Befehls B NRP oder
durch ein Schreiben von 1 in die NMIE gesetzt.
-
Das
Unterbrechungsmerkerregister (IFR) (siehe 17A) enthält den Status von INT4–INT15 und
des NMI. Tabelle 22 führt
die Unterbrechungsmerker und die Unterbrechungen, denen sie entsprechen,
auf. Falls der Status der Unterbrechungen geprüft werden soll, kann der MVC-Befehl
zum Lesen des IFR verwendet werden.
-
Tabelle
22. Unterbrechungsmerkerbits
-
Das
Unterbrechungssetzregister (ISR) und das Unterbrechungslöschregister
(ICR) (siehe 17C und 17D) ermöglichen,
Unterbrechungen in dem IFR manuell zu setzen oder zu löschen. Das
Schreiben einer 1 in IS4–IS15
des ISR bewirkt, dass der entsprechende Unterbrechungsmerker gesetzt
wird. Ähnlich
bewirkt das Schreiben einer 1 in ein Bit des ICR, dass der entsprechende
Unterbrechungsmerker gelöscht
wird. Das Schreiben einer 0 in irgendein Bit entweder des ISR oder
des ICR hat keine Wirkung. Ankommende Unterbrechungen haben Priorität und überschreiben
irgendeinen Schreibvorgang in das ICR. Das Rücksetzen oder die NMI können nicht
gesetzt oder gelöscht
werden. Irgendein Schreiben in das ISR oder in das ICR (durch den
MVC-Befehl) besitzt effektiv einen Verzö gerungsschlitz, da die Ergebnisse
erst 2 Zyklen nach dem Schreibvorgang in das ISR oder ICR (durch
den MVC-Befehl) in das IFR gelesen werden können.
-
Obgleich
die Bits für
anstehende Unterbrechungen kein CPU-Steuerregister bilden, halten
sie den anstehenden Zustand sämtlicher
CPU-Unterbrechungen. RESET, NMI, AINT, MSGINT und INT4–INT15 entsprechen
jeweils RSTP, NMIP, AIP, MSGIP und IP4–IP15. Die IP-Bits werden bei
Erkennung einer Unterbrechung gesetzt. Diese Bits, die für den Anwender
nicht direkt sichtbar sind, liegen in der Megamoduldomäne 331 und werden
in jedem Takt aktualisiert (d. h. durch ein inaktives RDY nicht
blockiert). Der Anwender kann den Status der IP-Bits über das IFR beobachten, das
in jedem Zyklus auf den Wert der IP-Bits aktualisiert wird. Der
Anwender kann den Status der IP-Bits über Schreibvorgänge des
Unterbrechungssetzregisters (ISR) und des Unterbrechungslöschregisters
(ICR) beeinflussen. Diese Änderungen
finden bei der nächsten
Aktualisierung der IP-Bits für
das IFR statt. Beim RESET werden die IP-Bits sämtlich gelöscht. Die in diese in Abschnitt
beschriebenen CPU-Register liegen alle in der CPU-Domäne und werden
in jedem Zyklus aktualisiert (d. h. durch ein inaktives RDY blockiert).
-
Die
folgenden Bits sind in dem Sinn "reserviert", dass sie zur Verwendung
durch ein Softwareprogramm während
des normalen Betriebs der CPU 10 nicht verfügbar sind,
zur Verwendung während
der Emulation und der Tests dagegen verfügbar sind.
-
IFR:
Die Bits 2 und 3 des IFR sind für
die Analyseunterbrechung (AINT) bzw. für die Nachrichtenunterbrechung
(MSGINT) reserviert.
-
IER:
Die Bits 2 und 3 des IER sind für
die Analyseunterbrechungsfreigabe (AIE) bzw. für die Nachrichtenunterbrechungsfreigabe
(MSGIE) reserviert.
-
ISR:
Die Bits 2 und 3 des ISR sind für
das Analyseunterbrechungssetzen (AIS) bzw. für das Nachrichtenunterbrechungssetzen
(MSGIS) reserviert. Diese Bits können
nur dann zum Setzen ihrer zugeordneten IP-Bits verwendet werden,
falls das EMU_MVCEN über
den Scan gesetzt ist.
-
ICR:
Die Bits 2 und 3 des ICR sind für
das Analyseunterbrechungslöschen
(AIC) bzw. für
das Nachrichtenunterbrechungslöschen
(MSGIC) reserviert. Diese Bits können
nur dann zum Löschen
ihrer zugeordneten IP-Bits verwendet werden, wenn das EMU_MVCEN über den
Scan gesetzt ist.
-
Eine
Analyseunterbrechung kann durch bestimmte Ereignistypen ausgelöst werden.
Bestimmte Ereignisse lösen
einen Halt aus. Damit ein Halt auftritt, muss der CPU-Testport in
dem Zustand CNTL sein. Eine Ausnahme ist, dass eine externe Haltanforderung
von dem CPU-Testport unabhängig
von dem Ausführungszustand
auftritt.
-
Bestimmte
Ereignisse können
wie folgt entweder eine Halt- oder eine Analyseunterbrechung auslösen:
- 1) Ein in einem aktiven Zustand eingegebenes
Spezialemulationsereignis (SEE).
- 2) Ein On-Chip-Programmadressenunterbrechungspunkt (PABP).
- 3) Die Eingaben EMU0IN und EMU1IN gehen von inaktiv auf aktiv über.
- 4) Ein Gleitkommabetriebsmittelkonflikt (FPX-Ereignis). Bestimmte
weitere Ereignisse können
wie folgt lediglich eine Analyseunterbrechung auslösen:
- 5) Ein Softwareunterbrechungs-SWI-Befehl.
- 6) Die nächste
Zyklusbegrenzung (CYC-Ereignis).
- 7) Das Signal XAINT von dem MTAP. Bestimmte weitere Ereignisse
wie folgt können
lediglich einen Halt auslösen:
- 8) SWBP decodiert. Dies gibt an, dass das Feld creg des ersten
Befehls in dem Ausführungspaket
den SWBP-Code (0001) enthält.
- 9) Eine externe Haltanforderung von dem CPU-Testport.
-
Die
Ereignisse müssen
lange genug aktiv sein, damit sie, wenn sie freigegeben sind, unabhängig von dem
blockierten Zustand des Prozessors erkannt werden. Allerdings können sie
nicht so lange aktiv sein, dass sie mehrere Ereignisse bewirken.
Um Zeitbeschränkungen
an die Ereignislänge
zu beseitigen, wird eine flankensensible Schaltungsanordnung verwendet.
-
Viele
der oben beschriebenen Ereignisse sind als Analyseereignisse klassifiziert
und werden ignoriert, wenn das Signal SUSPEND (Tabelle 29) in der
CPU aktiv ist. Allerdings sind die folgenden Ereignisse nicht als Analyseereignisse
klassifiziert und werden von SUSPEND nicht beeinflusst: SWBP, SWI
und ein von dem Testport angeforderter externer Halt.
-
Das
Signal SUSPEND wird durch das ODER von vier Termen angesteuert:
- 1. CPU_DONE aktiv,
- 2. das ECTL-Bit ist aktiv (Tabelle 28),
- 3. der CPU-Testport ist in den Zuständen PAUS, SDAT oder SCTL (Tabelle
33),
- 4. das Signal AINTSUSP in dem Analysesteuerregister (Tabelle
34).
-
Es
wird nun auf 18 verwiesen,
d. h. auf einen Zeitablaufplan, der die Erfassung der Analyseunterbrechungen
veranschaulicht. Eine Analyseunterbrechung (AINT) kann durch eine
von 7 Quellen verursacht werden:
- 1. Ein MTAP-Signal
EMU0IN zur CPU.
- 2. Ein MTAP-Signal EMU1IN zur CPU.
- 3. Ein Signal XAINT von dem MTAP. Eine Unterbrechung wird nur
dann erzeugt, wenn der CPU-Testport in CTRL ist.
- 4. Spezialemulationsereignis-Megamoduleingabe (SEE-Megamoduleingabe).
- 5. On-Megamodul-Programmadressenunterbrechungspunkt (On-Megamodul-PABP).
- 6. Softwareunterbrechungsbefehl (SWI). Anders als ein SWBP erfordert
eine SWI nicht, dass der CPU-Testport in dem Zustand CNTL ist. Der
STP-Befehl ist verfügbar,
um in den Programmspeicher zu schreiben, um SWI zu setzen.
- 7. Überschreiten
der nächsten
Zyklusbegrenzung bei der Ausführung
(CYC). Falls freigegeben, löst
die erste Zyklusbegrenzung, nachdem das Ausführungspaket eines B ARP-Ziels
E1 abschließt,
ein CYC-Ereignis aus, wobei AIP gesetzt wird. Dies wird für ein unterbrechungsbasiertes
Einzelweiterschalten mit einer Überwachungseinrichtung
verwendet.
-
Einige
dieser Ereignisse erfordern die Freigabe durch das Analysesteuerregister
(30A). Das AIP (und
somit das AIF-Bit in dem IFR (17A))
wird nur durch die Verarbeitung der Unterbrechung oder durch das
Schreiben einer 1 in das Bit 2 des ICR (17D) gelöscht. Wie alle anderen Unterbrechungen
können diese
während
der Verzögerungsschlitze
einer Verzweigung nicht auftreten. Die Erkennung wird verschoben, bis
die Verzweigungsverarbeitung abgeschlossen ist. 18 zeigt die Erfassung dieser Ereignisse.
AIP wird nur dann gesetzt, wenn die angegebene Unterbrechung, falls
erforderlich, durch AIE und durch PRI (und GIE, IE, NMIE) freigegeben
wird.
-
Ein
Bit in dem Analysesteuerregister (30A)
kann die Maskierbarkeit und die Priorität der Unterbrechungen ändern. Dadurch,
dass PRI, AINT gesetzt werden, kann entweder eine zweite nichtmaskierbare
Unterbrechung (PRI = 1), die die höchste Priorität besitzt,
oder die maskierbare Unterbrechung mit der zweitniedrigsten Priorität (PRI =
0) behandelt werden. In einigen Systemen muss die Analyse so schnell
wie möglich
auf Ereignisse reagieren. In diesen sollte die nicht maskierbare
Betriebsart verwendet werden. In anderen Systemen darf der Programmablauf
so wenig wie möglich
unterbrochen werden. In diesem Fall sollte der maskierbare Modus
niedriger Priorität
verwendet werden.
-
Falls
PRI = 1 ist, sperrt AIE sämtliche
Nicht-RESET-Unterbrechungen. Außerdem
wird AINT von GIE oder NMIE nicht beeinflusst. NMIE sperrt sämtliche
Nicht-RESET/Nicht-AINT-Unterbrechungen, was die Unterbrechung eines
NMI mit Ausnahme durch RESET oder AINT verhindert. Es wird angemerkt,
dass eine Unterbrechung, damit sie sich in HPIENT widerspiegelt,
nicht durch AIE freigegeben zu werden braucht, wenn PRI = 1 ist
(es sei denn, es ist AINT).
-
Wenn
PRI = 1 ist, werden die folgenden verschiedenen Bedingungen an die
Erfassung einer Unterbrechung, die eine Verarbeitung benötigt, gestellt:
- 1. Weder GIE noch NMIE brauchen gesetzt zu
sein, damit ein AINT genommen wird.
- 2. Für
sämtliche
Unterbrechungen mit Ausnahme von RESET muss AIE gesetzt sein (AIE
= 1).
-
Wenn
PRI = 1 ist, finden während
der Unterbrechungsverarbeitung die folgenden verschiedenen Aktionen
statt:
- 1. Während
eines AINT wird PGIE nicht auf GIE gesetzt und GIE nicht gelöscht.
- 2. AIE wird gelöscht.
-
Unabhängig von
dem Wert von PRI wird die Rücksprungadresse
für ein
AINT immer in dem in 30C veranschaulichten
Analyseunterbrechungs-Rücksprungzeigerregister
(ARP) gesichert. Da, falls in dem ACR PRI = 1 ist, eine AINT eine
NMI oder eine andere Unterbrechung unterbrechen und den Wert in
dem IRP überschreiben
kann, ist ein von NRP und IRP (siehe Tabelle 20) verschiedenes ARP
erforderlich.
-
19A und 19B veranschaulichen zwei analyseunterbrechungsbezogene
Befehle, SWI bzw. BARP. Die Tabellen 23 und 24 beschreiben diese
zwei Befehle. Tabelle 25 zeigt einen Rücksprung von der AINT-Codefolge.
-
Tabelle
23. Softwareunterbrechungsbefehl
-
Tabelle
24. Verzweigung zum Analyserücksprungzeiger
-
Tabelle
25. Codefolge für
den Rücksprung
von der AINT
-
Wenn
die Verarbeitung einer Analyseunterbrechung beginnt, wird das AINT-SUSP-Bit in dem Signal ACR
gesetzt, um die Erkennung irgendwelcher zukünftiger Analyseereignisunterbrechungen
oder Halte zu sperren (d. h. AIP wird nicht gesetzt). AINTSUSP wird
lediglich durch einen Anwenderschreibvorgang gelöscht.
-
Wieder
anhand von 18 wird
nun der Betrieb der Analyseunterbrechungen in Anwesenheit weiterer Unterbrechungen
diskutiert. Falls in der DP-Phase des vorausgehenden Ausführungspakets
n + 4 eine (auf alle möglichen
Arten freigegebene) Unterbrechung stattfand, wird diese Unterbrechung
verschoben und die AINT genommen. Somit werden n + 4 und n + 5 annulliert.
Bei der Rückkehr
zu n + 5 treten irgendwelche Bedingungen, die ein programmadressenbasiertes
AIP bewirkten, erneut auf.
-
Falls
in der DP-Phase des nächsten
Ausführungspakets
n + 6 eine (auf alle mögliche
Arten freigegebene) Unterbrechung auftrat, erhält die AINT Vorrang, da sie
vor der nächsten
Unterbrechung aufgetreten ist. Somit braucht es für die programmadressenbasierten
Analyseunterbrechungen: SWI, PABP, SEE und CYC-basierte AINTs, keine Spezialbehandlung
zu geben.
-
Testports
-
Wieder
anhand von 15 besitzt
jede Domäne
10, 321 und 331 jeweils über die Testports 310, 320 und 330 eine
Schnittstelle zum MTAP 305. Der MTAP unterstützt bis
zu vier Testports, einen für
jede Domäne. Allerdings
ist der Testport für
die SEA-Domäne
nicht in dem Megamodul enthalten. Testports sind allgemeine Test/Emulations-Schnittstellen,
die eine Domänentakterzeugung
sowie eine Ausführungs-
und Scan-Steuerung schaffen. Die Ausführungssteuerung ermöglicht eine
direkte taktweise Steuerung der Domäne durch die Emulations- oder Testsoftware.
Es ist die MTAP-Testport-Schnittstelle gezeigt, die ausführlicher
in Tabelle 26 und 27 beschrieben ist. Die Schnittstelle zwischen
der SEA-Domäne und dem
MTAP ist ähnlich
und wird ausführlich
anhand der 32 und 41 beschrieben.
-
Tabelle
26. Testportsignalbeschreibungen
4
-
Tabelle
27. Beschreibungen der Testportbus-Signale
-
Die
Tabellen 28, 29, 30, 31 und 32 beschreiben
und definieren zusammen mit den 20 und 21 verschiedene Signale
und Steuerbits, die sich auf die Emula tion und auf Tests des später ausführlicher
beschriebenen Megamoduls 300 beziehen. Tabelle 28 definiert
CPU-Domänenbits,
die für
die Emulationssteuerung und zum Liefern von Statusinformationen,
die unter Verwendung der Scan-Kette 301a–d übertragen werden, verwendet
werden. Tabelle 29 definiert Signale, die über die Megamodulbegrenzung 301 gesendet
werden. 20 veranschaulicht
die Verdrahtungen zwischen dem MTAP 305 und der CPU-Domäne 10.
Tabelle 30 definiert die von 20 veranschaulichten
Signale, die ebenfalls die Megamodulbegrenzung 301 ansteuern.
Tabelle 31 definiert die verbleibenden durch 20 veranschaulichten Signale. 21 veranschaulicht die
Verdrahtungen zwischen dem MTAP 305 und der Megamoduldomäne 331.
Tabelle 32 definiert die in 21 veranschaulichten
Signale.
-
Verschiedene
in den Tabellen 28-32 verwendete Begriffe sind wie folgt
definiert:
- Annul: Falls ein Ausführungspaket während einer
besonderen Pipelinestufe annulliert wird, setzt es keine Megamodulbegrenzungsübernahmen
oder keinen Megamodulbegrenzungsstatus aktiv, schreibt es keine
Werte in einen für
den Anwender oder für
die Emulation sichtbaren Zustand. Adressen und Daten können ebenso
wie Statussignale, die durch eine Übernahme unterschieden werden
müssen,
ihren Zustand ändern,
während
sie durch Übernahmen
unterschieden werden. Ein ungeeigneter Status muss inaktiv gesetzt
werden. Das Annullieren erzwingt außerdem, dass ein Befehl in
künftigen
Pipelinestufen annulliert wird.
- Analysesteuerregister (ACR): In 30A gezeigt
- Analysedatenregister (ADR): In 30B gezeigt
- PRI-Unterbrechungsprioritätssteuerbit
in dem ACR: in Tabelle 34 beschrieben.
-
Tabelle
28. CPU-Domänenbits
für die
Emulationssteuerung und Statusbits während des Scans
-
-
-
Tabelle
29. Megamodulbegrenzungssignale
-
-
Tabelle
30. Beschreibungen der MTAP-CPU- und der MTAP-Megamodul-Begrenzungssignale
-
Tabelle
31. Beschreibungen der Signale der MTAP-CPU-Schnittstelle
-
-
Tabelle
32. Beschreibungen der Signale der MTAP-Megamoduldomänen-Schnittstelle
-
22 ist ein Zustandsdiagramm
verschiedener Zustände,
in denen sich ein Testport befinden kann. Eine Menge von MTAP-Signalen
C0, C1 und Ce (Tabelle 27) und das Signal LOCK (Tabelle 26) bestimmen den
Zustand des Testports, wie er in Tabelle 33 beschrieben und in 22 veranschaulicht ist.
Jeder Testport 310, 320 und 330 besitzt
ein unabhängiges
Verriegelungssignal von dem MTAP (15).
Ein aktives Verriegelungssignal bewirkt, dass der momentane Zustand
in dem Testport zwischengespeichert wird, bis das Verriegelungssignal
inaktiv ist. Wenn ein Testport nicht verriegelt ist, bestimmt der
Testportbus den Zustand des Testports. Wenn der Testport verriegelt
ist, werden Signaländerungen
an dem Testportbus und an der Taktumschaltung ignoriert. Wenn eine
Domäne
verriegelt ist, werden ihre Scan-Module nicht zu der Kette hinzugefügt und über die
gemeinsam genutzten Schieberegisterbits (SSR-Bits) des Testports
umgangen. Das Signal LOCK verriegelt außerdem die momentane Takterzeugungsbetriebsart
der Vorrichtung.
-
Die
im XDS 51 arbeitende Software stellt sicher, dass ein Testport richtig übergeht,
wenn der Testport mit einem an den Testport angelegten MTAP-Code
entriegelt wird, der von dem Code, in dem er verriegelt wurde, verschieden
ist. Wie in 22 gezeigt
ist, wird beim Schalten von FUNC, CNTL oder HALT in einen Scan-Zustand
(SCTL oder SDAT) PAUS durchlaufen. Wie später beschrieben wird, lässt der
MTAP nicht zu, dass der Zustand PAUS verlassen wird, bis eine Taktumschaltung
abgeschlossen ist.
-
Falls
der Testport in PAUS verriegelt ist, muss die Emulationssoftware
den Testport in PAUS entriegeln. Wenn er in irgendwelchen anderen
Zuständen
entriegelt würde,
würden
die resultierenden Taktumschaltungen Störungen enthalten.
-
Wieder
anhand von 15 liefert
jeder Testport ein Domänenbusfreigabesignal
(ein Signal DBENB) an seine Domänen-Scan-Pfade.
Wenn die DBENB inaktiv ist, zwingt sie sämtliche Domänenbegrenzungssignale inaktiv
und setzt sie alle Domänen-Tristates
auf den HI-Z- Zustand. In der Emulationsbetriebsart wird DBENB aktiv
angesteuert, falls der Testport in FUNC, CNTL oder HALT ist. In
der Testbetriebsart (ATPG_DEVM = 1) wirkt das erste SSR-Bit des
Testports als die DBENB. Dieses Bit wird als Teil einer Daten-Scan-Operation
(SDAT-Operation) gescannt. Das Signal DBENB ist in allen Betriebsarten
inaktiv, wenn der Testport in SCTL, SDAT oder PAUS ist. Beim Schalten
von PAUS auf FUNC oder CNTL zwingt der MTAP den Testport, wenigstens
während
eines Takts in HALT einzutreten, um sicherzustellen, dass das DBENB
vor dem Neustart der Ausführung
aktiv ist.
-
-
Anhand
der 23A, 23B und 23C, d. h. von Zeitablaufplänen, wird
nun die Operation einer Taktumschaltung beschrieben. Für die Taktumschaltung,
wie sie durch UCLK_SEL, TCLK_SEL, MTAP-Codes, LOCK und SHIFT_DR
gesteuert wird, wird der Zustand PAUS verwendet. LM wird ausgeschaltet,
wenn der Testport in PAUS, SDAT oder SCTL ist. Falls ATPG_DEVM =
1 ist, wird in HALT ebenfalls LM ausgeschaltet. Es sind drei Taktumschaltungsarten
möglich:
- 1. Umschalten vom Funktionslauf an UCLK auf
Scan (an TCLK) (23A)
zur Emulationssteuerung der Vorrichtung.
- 2. Umschalten vom Funktionslauf an TCLK zum Scan (an TCLK) (23B) für den Test. Da sichergestellt werden
kann, dass TCLK direkt von Vorrichtungsanschlussstiften kommt, während UCLK
durch die cDSP-Entwurfslogik gesteuert werden kann, wird während des
Tests der Lauf an TCLK verwendet.
- 3. Umschalten vom Funktionslauf an UCLK auf den Funktionslauf
an TCLK (23C) für den Test
aus den gleichen Gründen
wie oben.
-
Die
Folge der Änderungen,
die in den Eingaben in den Testport gezeigt sind, ist konsistent
mit dem Übergang
der MTAP-Ausgaben. Eine Ausnahme ist, dass SHIFT_DR gleichzeitig
mit dem Übergang
in die Zustände
und aus den Zuständen
SDAT oder SCTL übergehen
könnte.
-
Es
werden die folgenden Vorschriften befolgt:
- 1.
Taktungsänderungen
beruhen auf zwischengespeicherten Codes in dem Testport.
- 2. Die Taktung und der Testportzustand ändern sich nicht, falls das
LOCK-Bit aktiv ist.
- 3. LS ist immer um 180 Grad phasenverschoben gegenüber dem
Takt, welcher angesteuert wird (SCLK oder LM) und überschneidet
sich nicht mit ihm.
- 4. (T/U)CLK steuert LM/LS nur an, falls (T/U)CLK_SEL freigegeben
und der Testport entweder, falls ATPG_DEVM = 0 ist, in HALT oder
in FUNC oder CNTL ist.
- 5. TCLK steuert SCLK/LS nur an, falls TCLK_SEL, SHIFT_DR und
SDAT_SEL freigegeben und LOCK gesperrt ist. Es wird angemerkt, dass
SCTL_SEL SCLK nicht freigibt, da lediglich die SSR-SRLs (d. h. keine Domänen-SRLs)
gescannt werden.
- 6. Schließlich
steuert TCLK LM/LS immer an, wenn der Testport in FUNC oder CNTL
ist, falls die Vorrichtung in der ATPG-Betriebsart (ATPG_DEVM =
1) ist. Dabei ist angenommen, dass UCLK tief angesteuert wird.
-
Die
Scan-Operation wird durch den Pfad des internen gemeinsam genutzten
Schieberegisters (SSR) des Testports geliefert. Dieser Pfad enthält für jede verschiedene
Scan-Kette in dieser Domäne
einen SRL. Die SSR-Bits werden zum Aktualisieren des Scan-Steuerpfads
(SCTL-Pfads) oder als Umgehungsbits für Domänendaten-Scan-Pfade (SDAT-Scan-Pfade)
verwendet. Da der Testport auch dann scannbar bleiben muss, während die
Domäne
im Funktionstakt läuft,
wird der SSR-Pfad mit dem Scan-Takt getaktet. Die Takte in der Domäne müssen für SDAT und
SCTL von dem Funktionstakt auf den Scan-Takt umschalten (22). Einzelheiten der Scan-Pfade
werden später
anhand von 33 beschrieben.
-
Eine
Steuer-Scan-Operation (SCTL) greift über den SSR-Scan-Pfad auf die
Modul-Scan-Freigabebits (MSENB-Bits) zu. Wie in 24 veranschaulicht ist, wählen die
MSENBs diejenigen Domänen-Scan-Pfade, die
freigegeben sind, aus, um den Daten-Scan-Pfad (SDAT-Pfad) zu bilden.
Jeder Testport enthält
wenigstens ein MSENB-Bit. Für
jeden Scan-Pfad in der Domäne
wird ein MSENB-Bit benötigt.
Sämtliche
Testports in dem Megamodul sind Ein-Schnitt-Ports: Sie besitzen
einen einzigen Scan-Pfad und ein einziges MSENB-Bit. Alternative
Ein-Schnitt-Ausführungsformen
könnten
den SCTL-Scan und die MSENB-Bits der Einfachheit halber durch das
Signal LOCK oder äquivalent
ersetzen. Die MSENB-Daten werden in den SSR-Pfad gescannt, während der
MTAP das durch das aktive Signal SCTL_SEL geeignete SHIFT_DR aktiviert.
Wenn der MTAP das durch ein aktives Signal SCTL_SEL geeignete UPDATE
DR aktiviert, wird das SSR in die MSENBs geladen. Wenn der MTAP
das durch ein aktives SCTL_SEL geeignete CAPTURE_DR aktiviert, werden
die MSENBs in das SSR geladen. Ein umgangener Steuer-Scan während des
Funktionslaufs kann dadurch ausgeführt werden, dass der Testport
in FUNC oder in CNTL verriegelt und daraufhin der Scan ausgeführt wird.
In diesem Fall sind die SSR-Bits die einzigen, die zu der Scan-Kette
hinzugefügt
werden. Außerdem
reagiert der Testport nicht auf die Signale UPDATE_DR und CAPTURE_DR.
-
Eine
Daten-Scan-Operation (SDAT) schafft über den SSR-Scan-Pfad einen
Zugriff auf die Domänen-Scan-Pfade.
Während
eines Daten-Scans werden die Domänen-Daten über die
SSR-Pfade gescannt. Die SSR-Bits wirken als Umgehungsbits für die Domänen-Scan-Pfade,
die wie durch die MSENB-Bits gesteuert umgangen werden. Der SSR-Pfad
wird durch den Zustand SDAT ausgewählt. Während der MTAP das SHIFT_DR
aktiviert und der Testport in dem Zustand SDAT ist, werden die Daten
in den SSR-Pfad gescannt. Wenn das dem SSR zugeordnete MSENB freigegeben
ist, werden die Daten von dem SSR-Bit über diesen Domänen-Scan-Pfad
gescannt. Wenn das MSENB-Bit gesperrt ist, werden die Daten in das
nächste
SSR-Bit gescannt. Jede Domäne
enthält
wenigstens einen SDAT-Pfad. Der SDAT-Pfad schafft einen Zugriff
auf die für den
Test und für
die Emulation erforderlichen SRLs. Die Signale UPDATE_DR und CAPTURE_DR
werden von der Daten-Scan-Operation nicht verwendet.
-
Abschalten
-
In
der integrierten Schaltung 1 sind wie folgt drei Verfahren zum Abschalten
verfügbar:
- 1. Der IDLE-Befehl. Das IDLE pflanzt ständig NOPs
in die Pipeline fort, bis es durch eine Unterbrechung annulliert
wird. Die Taktungsoperation und die RDY-Operation werden wie normal
fortgesetzt. Somit kann die CPU weiter auf einen Testporthalt reagieren.
- 2. Abschluss des PDREQ/PDACK-Quittungsaustauschs, um LM/LS in
der Analysedomäne
und in der CPU-Domäne
abzuschalten. Der Entwurf des Mikroprozessors 1 kann die
Signale EIP SET und IP SET von dem Megamodul verwenden, um auf der
Grundlage geänderter
Unterbrechungsbedingungen Takte wieder freizugeben.
- 3. Ändern
oder Abschalten von UCLK für
die CPU. Allerdings kann das XDS durch den Lauf des Megamoduls an
TCLK lediglich eine beschränkte
Sichtbarkeit schaffen, falls UCLK abgeschaltet ist.
-
15 und Tabelle 34 schildern
ausführlich
die Abschaltschnittstelle zwischen den Testports, der Abschaltlogik
und der Megamodulbegrenzung. Falls ein Testport ein inaktives FCLK_REQ
und eine aktive Takte-aus-Anforderung (OFFREQ empfängt, schaltet
er die Takte ab (LM tief und LS hoch), wobei er die Anforderung
durch Aktivieren von OFFACK quittiert. Falls OFFREQ deaktiviert
oder FCLK_REQ aktiviert ist, werden die Takte wieder freigegeben
und wird OFFACK deaktiviert. Die Abschaltlogik verleiht dem Mikroprozessor 1 die
Fähigkeit,
die Analysedomäne
und die CPU-Domäne
abzuschalten. Im zweiten Fall können
die Eingaben EiP_SET oder IP_SET dazu verwendet werden, Unterbrechungsbedingungen
zu signalisieren, die der Mikroprozessor 1 eventuell verwenden
möchte,
um die Takte wieder zu aktivieren. Der Entwurf des Mikroprozessors 1 ist
dafür verantwortlich,
dass alle anderen Komponenten, falls erforderlich, blockiert werden,
während
die CPU abgeschaltet wird.
-
Tabelle
34. Abschaltungsbezogene Signale
-
Sämtliche
SRLs in dem Megamodul sind scannbar und gehören zu einer der drei Testportdomänen oder
zu dem MTAP. Eine vierte Off-Megamodul-Domäne, die SE-Analysedomäne, wird
durch den MTAP unterstützt,
ist aber nicht als Teil des Megamoduls enthalten. Jede Domäne besitzt
einen ihr zugeordneten Testport. Die Testports werden in Situationen
verwendet, in denen die Takte in einer besonderen Domäne eventuell umgeschaltet
werden müssen.
Die vier Domänen
sind wie folgt:
- Analysedomäne: Das Analysedatenregister
(ADR)
- Megamoduldomäne:
Diese Domäne
enthält
einen einzigen Scan-Pfad, der enthält:
- 1. IP-Bits, die dem IFR und den zugeordneten Erfassungszwischenspeichern
zugeführt
werden,
- 2. die SRLs, die RDY an der Begrenzung zwischenspeichern und
Blockierungen steuern,
- 3. die Parallelsignaturanalysatoren (PSAs) für den Test,
- 4. die Schaltungsanordnung, die die Signale EMU (0/1)IN von
dem MTAP erfasst,
- 5. die Zwischenspeicher für
die Abschaltsteuerbits, 6. die Schaltungsanordnung, die CPU-fertig
erzeugt,
- 7. die Schaltungsanordnung, die den Ein-Takt-MSGSW-Impuls erzeugt.
- CPU-Domäne:
Die CPU-Domäne
enthält
einen einzigen Scan-Pfad, der sämtliche
CPU-SRLs enthält,
die durch das RDY blockiert sind.
- SE-Analyse-Domäne
(SEA-Domäne):
eine Spezialemulationsvorrichtung (SE) besitzt eine vierte Domäne für die SE-Logik,
die außerhalb
des Megamoduls liegt.
-
CPU-Testporthaltsteuerung
-
Dieser
Abschnitt beschreibt einen CPU-Domänenhalt für die Emulation. In der Emulationsbetriebsart (EMU_DEVM
= 1) hält
die CPU die Ausführung
an einer Zyklusbegrenzung an. In der Testbetriebsart (ATPG_DEVM
= 1) hält
die CPU die Ausführung
an einer Taktbegrenzung an. Die Figuren in diesem Abschnitt zeigen
für Veranschaulichungszwecke
einen Zwei-Zyklus-Off-Megamodul-RDYbasierten Halt. Tabelle 35 definiert
die Signale zwischen der CPU-Domäne
und dem CPU-Testport, die das Anhalten unterstützen.
-
Tabelle
35. CPU-Domäne-CPU-Testport-Schnittstelle
-
25 ist ein Zeitablaufplan,
der die wie früher
diskutierten verschiedenen Fälle
eines Halts für
die Emulation veranschaulicht. Obgleich die Beschreibungen hier
angeben, dass der Testport in den Haltzustand übergeht, wären die Ergebnisse für eine andere
Ausführungsform
dieselben, wenn der Testport stattdessen in den Zustand PAUS überginge.
PAUS beeinflusst die Signale ERDY_DC, ERDY_E1 und CPU_DONE auf die gleiche
Weise wie HAL. Emulationshalte treten in Reaktion auf das Folgende
auf:
- Fall 1. der Aktiv-Übergang
der Eingaben EMU(0/1). Es wird angemerkt, dass die Signale EMU(0/1)IN
einen Takt lang Impulse erzeugen. Somit werden diese Signale in
der Megamoduldomäne
(möglicherweise
in der Mitte eines Zyklus) erfasst, wobei ihre Breite wie gezeigt
bis zum Ende des Zyklus gedehnt wird. Somit erreicht die Logik in
der Megamoduldomäne
dies, da sie während
des inaktiven RDY reagieren muss.
- Fall 2. ein während
der Phase DP erfasster Programmadressenunterbrechungspunkt.
- Fall 3. ein während
der Phase DP decodierter SWBP. Es wird angemerkt, dass die Pipeline,
nachdem sie während
der Befehlsphase E1 angehalten worden ist, erst fortschreitet, wenn
das Feld SWBP_DEC während
des Scan gelöscht
worden ist.
- Fall 4. ein Spezialemulationsereignis (SEE), das auf einer Programmadressenunterbrechungspunkt-Übereinstimmung
des externen PCDP beruht. Dieses wird während der DP-Phase intern gesehen.
Es wird angemerkt, dass je nach der implementierten Spezialemulationslogik
andere Bedingungen einen SEE-basierten Halt erzeugen könnten. Allerdings
ist ein Programmadressenunterbrechungspunkt gezeigt, da er die strengsten
Zeitgebungsanforderungen besitzt.
- Fall 5. ein Gleitkommabetriebsmittelkonflikt.
- Fall 6. der Testport geht während
der Phase DP von CNTL auf HALT über.
Wie EMU(0/1)IN-Ereignisse kann dies ebenfalls während der Mitte eines Zyklus
DP auftreten. Wie in 25 gezeigt
ist, finden anhand eines dieser Ereignisse die folgenden Aktionen
statt:
- Das Signal ERDY_DC wird während
der gesamten Phase DC von außen
tief gesetzt.
- Das Signal ERDY_E1 wird zu Beginn der Phase E1 von außen tief
gesetzt.
- Das EMURDY wird zu Beginn der zugeordneten E1 gesetzt. Dieses
wird dem Signal CPU_RDY zugeführt,
das die CPU blockiert.
- Nachdem sämtliche
RDY (die Eingaben RDY1-RDY4) intern aktiv sind, wird CPU_DONE aktiviert.
- Nachdem das CPU_DONS erkannt worden ist, stellt der MTAP den
CPU-Testport von
CNTL auf HALT um.
- Das XDS führt über den
MTAP sämtliche
erforderlichen Scans aus.
- Der MTAP stellt den Testport zurück auf CNTL, um zu ermöglichen,
dass die CPU die Pipelinephase abschließt. CPU_DONE und ERDY_E1 werden
inaktiv.
- EMURDY wird inaktiv.
-
Es
wird angemerkt, dass der MTAP das Megamodul um eine einzelne Pipelinephase
weiterschalten kann, wenn er das CNTL lediglich für einen
Takt anlegt.
-
26 ist ein Prinzipschaltbild,
das eine Schaltung zum Bilden eines externen Speicherbereitschaftssignals
ERDY veranschaulicht. Die externen Speichersysteme müssen ihre
gegenseitigen RDYs verfolgen, um ihre gegenseitigen Blockierungen
zu bemerken. Ähnlich
können
die Signale ERDY_DC und ERDY_E1 von den externen Speichersystemen
verwendet werden, damit sie einen Emulationshalt bemerken. Da die
CPU intern eine Zwei-Zyklen-Warnung (wenigstens zwei Takte) vor
einem anstehenden Emulationshalt besitzt, kann sie die Signale ERDY_DC
und ERDY_E1 erzeugen.
-
27A ist ein Zeitablaufplan,
der die Wechselwirkungen der Halte, der Unterbrechungen und des Rücksetzens
veranschaulicht. In 27 ist
angenommen, dass ein Ausführungspaket
n + 5 in seiner Stufe DC eine freigegebene anstehende Unterbrechung
besitzt. Falls n + 5 in der DP einen Halt erfasst hat, erhält der Halt
Priorität,
wobei die Unterbrechung nicht auftritt. Auf diese Weise können Halte
Unterbrechungen (einschließlich
des Rücksetzens)
blockieren. Allerdings werden die Unterbrechungsmerker weiter gesetzt.
Da das EMURDY die Unterbrechungsreaktion durch Blockieren der Pipeline
aufschiebt, werden Unterbrechungen und Rücksetzungen während des
Scan ebenfalls aufgeschoben.
-
Die
Nebenwirkungen eines Halts hängen
vom Fortschritt des zugeordneten Ausführungspakets über die
Pipeline ab. Falls ein Ausführungspaket
nach einem Mehrzyklen-NOP oder -IDLE in seiner DP eine Haltbedingung
feststellt, reagieren somit ERDY_DC und EMURDY erst auf den Halt,
wenn das Ausführungspaket in
DC eintritt. Ähnlich
reagieren ERDY_E1 und CPU_DONE erst, wenn das Ausführungspaket
in E1 eintritt.
-
Falls
der CPU-Testport in Reaktion auf einen vom ihm angeforderten Emulationshalt
während
der Unterbrechungsverarbeitung von CNTL auf HALT übergeht,
wird CPU_DONE erst aktiv, wenn das Unterbrechungsbedienungsholpaket
(ISFP) E1 erreicht (27A).
-
27B ist ein Zeitablaufplan,
der einen Testhalt veranschaulicht, der von einem Testport angefordert wird.
Wenn die CPU in der Testbetriebsart ist (ATPG_DEVM = 1), hält sie sofort
an, wenn der Testport in Reaktion auf einen vom CPU-Port angeforderten
Testhalt von CNTL auf HALT übergeht.
Dies wirkt unabhängig von
der Anwesenheit der Unterbrechungsverarbeitung auf die gleiche Weise.
-
Emulationspineline-Steuerung
-
Wieder
anhand von Tabelle 28, die verschiedene Emulationssteuer- und Statusbits
zusammenfasst, werden nun die folgenden Emulationssteuerbits ausführlicher
beschrieben: EPDN, EPUP, ECTL und EUPL. Das Emulation-Pipe-down-Bit
(EPDN-Bit) führt
für einen
Emulationshalt eine Annullierung aus, was zu Folgendem führt:
- Weiteres
Holen gesperrt: PAS wird gesperrt. Somit werden keine weiteren Programmholvorgänge begonnen. Allerdings
wird zugelassen, dass vorher angeforderte Holvorgänge abgeschlossen
und in einen Programmdateneingangspuffer PDATA_I geladen werden,
der sich in der Programmholschaltungsanordnung 10a befindet.
- Ausführungspakete,
die noch nicht in E1 sind, werden annulliert: Bevor ein Ausführungspaket
in E1 eintritt, wird es annulliert. Irgendwelche Ausführungspakete,
die in E2 und danach eintreten, können bis zum Abschluss durch
das XDS umlaufen. Anmerkung: Die Bits ANNUL und ANNUL_ASU müssen beide
auf 0 gescannt werden, damit die Annullierung funktioniert.
- Unterbrechungen gesperrt: Das Nehmen sämtlicher Unterbrechungen einschließlich RESET
wird gesperrt. Anstehende Bits werden weiter gesetzt.
-
Das
Emulation-Pipe-up-Bit (EPUP-Bit) führt die Annullierung für einen
Emulationsneustart aus. Unterbrechungen werden gesperrt, so dass
das Nehmen sämtlicher
Unterbrechungen einschließlich
RESET gesperrt ist; allerdings werden anstehende Unterbrechungsbits
weiter gesetzt.
-
Das
Emulationssteuerbit (ECTL-Bit) ermöglicht, dass die Emulationssteuerung
der CPU durch die folgenden Schritte ausgeführt wird:
- 1)
Hält Analyseereignisse
an: ECTL halt irgendeine zukünftige
Erkennung von Analyseereignissen an.
- 2) Unterbrechungen gesperrt: ECTL sperrt sämtliche Unterbrechungen einschließlich RESET.
IP-Bits werden weiter gesetzt, Unterbrechungen aber nicht genommen.
Wegen des Anhaltens von Analyseereignissen kann AIP lediglich durch
einen SWI gesetzt werden.
- 3) Sperrt Holvorgänge:
ECTL sperrt (wie EPDN) ebenfalls Programmholvorgänge, indem es PRS inaktiv zwingt.
Somit kann das XDS Befehle in PDATA_I scannen, wenn die CPU im Halt
ist. Falls PDATA_I mehrere Ausführungspakete
(ein teilweise serielles Holpaket) enthält, sollte die CPU diese wie üblich verarbeiten
und auf das erste Ausführungspaket
zurücksetzen,
wenn sie fertig ist. Allerdings können Ausführungspakete nicht die Holpaketbegrenzung überschreiten
und zurücksetzen.
Das XDS kann ein weiteres Emulationsereignis auslösen, indem
es einen SWBP als einen der 8 Befehle anordnet.
-
Das
Emulationsprogramm-Upload-Unterstützungs-Bit (EUPL-Bit) unterstützt einen
Programm-Upload. Das EUPL gibt Programmholvorgänge wieder frei und setzt den
PFC, um zu dem nächsten
Holpaket (d. h. keine Verzweigung, PFC += 8) zu inkrementieren.
Allerdings werden sämtliche
Stufen DP und danach annulliert. Selbst wenn ECTL gesetzt ist, werden
Holvorgänge
wieder freigegeben. Allerdings werden Unterbrechungen weiter nicht
genommen und Analyseereignisse weiter angehalten, falls ECTL gesetzt
ist. Dies wird für
den Programm-Upload
verwendet. PDATA_I kann in jedem Zyklus gescannt werden, um die
Holpaketinhalte zu entnehmen. Anmerkung: Die Bits ANNUL und ANNUL_ASU
müssen
beide zu 0 gescannt werden, damit die Annullierung funktioniert.
-
28 ist ein Zeitablaufplan,
der eine als eine "Pipe-down"-Prozedur bezeichnete
Folge von Halts in einer Prozedur zum Anhalten der Pipeline und
Si chern der Inhalte verschiedener Register in der Pipeline als einen
Zustand veranschaulicht. Es wird zugelassen, dass Befehle in den
Ausführungspaketen,
die E1 (a–d) abgeschlossen
haben, bis zum Abschluss fortfahren. Im Folgenden wird die Folge
von Operationen XDS 51 beschrieben, die beim Steuern eines
Pipeline-Halts ausgeführt werden.
Es wird angemerkt, dass sich irgendwelche Anwenderänderungen
der Datenquellen von Ladevorgängen,
die abgeschlossen worden sind, in diesem Verfahren des Sicheres
des Zustands beim Neustart nicht widerspiegeln. Nach Beginn eines
Halts werden wie anhand von 25 beschrieben
die folgenden Schritte ausgeführt:
- 1. Zyklus 2 zum Zeitpunkt 350: Ausscannen
und Sichern des gesamten CPU-Domänenzustands.
Einscannen mit EPDN = 1, EPUP = 0, ECTL = 0, EUPL = 0, ANNUL = 0
und ANNUL_ASU = 0. Dies hält
neue Holvorgänge
an, sperrt Unterbrechungen und annulliert Ausführungspakete, die E1 nicht
abgeschlossen haben.
- 2. Anlegen von CNTL 351 für einen Taktzyklus.
- 3. Zyklus 3 zum Zeitpunkt 352: Ausscannen und Sichern
von DDATA_I. Einscannen des Zustands ohne irgendwelche Änderungen.
- 4. Anlegen von CNTL 353 für einen Taktzyklus.
- 5. Zyklus 4 zum Zeitpunkt 354: Ausscannen und Sichern
von DDATA_I. Einscannen des Zustands ohne irgendwelche Änderungen.
- 6. Anlegen von CNTL 355 für einen Taktzyklus.
- 7. Zyklus 5 zum Zeitpunkt 356: Ausscannen und Sichern
von DDATA_I. Einscannen des Zustands, der die Phase DP mit NOPs
und EPDN = 1, EPUP = 0, ECTL = 1, EUPL = 0, ANNUL = 0 und ANNUL_ASU
= 0 füllt.
Das Setzen von ECTL setzt SUSPEND, um die On-Chip- und die 0ff-Chip-Analyse
zu sperren.
- 8. Anlegen von CNTL 357 für einen Taktzyklus.
- 9. Zyklus 6 zum Zeitpunkt 358: kein Scannen. Zulassen,
dass NOPs in die Pipeline fortgepflanzt werden.
- 10. Anlegen von CNTL 359 für einen Taktzyklus.
- 11. Zyklus 7 zum Zeitpunkt 360: Ausscannen mit keinem
zu sichernden Zustand. Einscannen mit EPDN = 0, EPUP = 0, ECTL =
1, EUPL = 0, ANNUL = 1 und ANNUL_ASU = 1. Löschen von EPDN ermöglicht,
dass die Inhalte der Phase DP (IR) dem Rest der Pipeline zugeführt werden.
Holvorgänge
und Unterbrechungen bleiben über
ECTL gesperrt.
-
29 ist ein Zeitablaufplan,
der zeigt, wie der gesamte Pipeline-Zustand in einer "Pipe-up"-Prozedur durch Wiedergewinnen
jedes der verschiedenen Zustände,
die während
der oben beschriebenen Pipe-down-Prozedur gesichert werden, wiederhergestellt
wird. In dieser Figur ist angenommen, dass die Pipeline von allen
Ausführungspaketen,
die durch das XDS zur Steuerung eingefügt wurden, geleert worden ist
und in allen Pipelinephasen NOPs enthält. Dieser Zustand wird manuell
dadurch erzielt, dass das XDS das Befehlsregister mit NOPs füllt und
dass ermöglicht
wird, dass andere Befehle bis zum Abschluss in der Pipeline umlaufen.
Nach dem Neu-Scan wird ermöglicht,
dass annullierte Phasen aus dem gesicherten Zustand abgeschlossen
werden. Der gesamte weitere Zustand folgt aus dem vorigen Zyklus.
Da im Zyklus 2 Datenspeicherübernahmen
gesperrt sind, werden Datenspeicheroperationen vorteilhaft nicht
nochmals ausgeführt.
Ankommende Ladedaten, die zu Beginn von E5 (am Ende von E4) zwischengespeichert
wurden, müssen
durch das XDS eingescannt werden. Somit bewirkt die gesamte Folge
von Pipe-down, Emulation und Pipe-up in dem Datenverarbeitungssystem
aus 1 vorteilhaft keine
fremden Speicher- oder E/A-Zyklen. Im Folgenden wird die Operationsfolge
beschrieben, die das XDS beim Steuern eines Pipeline-Neustarts ausführt:
- 1. Zyklus 0 zum Zeitpunkt 370: Wiedereinscannen
der Adresse des Holpakets, das für
das Holpaket h geholt worden ist. Diese Informationen sind beim
Scan des Zyklus 2 während
des Emulationshalts verfügbar. Es
ist EPDN = 0, EPUP = 0, ECTL = 0, EUPL = 1, ANNUL = 1 und ANNUL_ASU
= 1 zu setzen. Dies gibt das Holen wieder frei, während Unterbrechungen
gesperrt werden.
- 2. Anlegen von CNTL 371 für einen Taktzyklus.
- 3. Zyklus 1 zum Zeitpunkt 372: Wiedereinscannen der
Adresse des Holpakets, das für
das Holpaket i geholt worden ist. Diese Informationen sind beim
Scan des Zyklus 2 während
des Emulationshalts verfügbar.
- 4. Anlegen von CNTL 373 für einen Taktzyklus.
- 5. Zyklus 2 zum Zeitpunkt 374: Wiedergewinnen des gesamten
CPU-Domänenzustands
aus dem Zyklus mit dem gesperrten DBS (0 setzen). Es ist EPDN =
0, EPUP = 1, ECTL = 0, EUPL = 1, ANNUL = 1 und ANNUL_ASU = 1 zu
setzen. Dies gibt Holvorgänge
wieder frei, während
Unterbrechungen gesperrt werden.
- 6. Anlegen von CNTL 375 während eines Taktzyklus.
- 7. Zyklus 3 zum Zeitpunkt 376: Ausscannen und Wiedereinscannen
von DDATA_I vom Zyklus 3 des Pipeline-Halts.
- B. Anlegen von CNTL 377 für einen Taktzyklus.
- 9. Zyklus 4 zum Zeitpunkt 387: Ausscannen und Wiedereinscannen
von DDATA_I vom Zyklus 4 des Pipeline-Halts.
- 10. Anlegen von CNTL 398 für einen Taktzyklus.
- 11. Zyklus 5 zum Zeitpunkt 380: Ausscannen und Wiedereinscannen
mit DDATA_I aus dem Zyklus 5 des Pipeline-Halts. Es ist EPDN = 0,
EPUP = 0, ECTL = 0 und EUPL = 0, ANNUL = 1, ANNUL_ASU = 1 zu setzen.
Dies gibt Unterbrechungen, Analyse und Holen wieder frei.
-
Wie
in Tabelle 10 gezeigt ist; wird ein Softwareunterbrechungspunkt
(SWBP) dadurch gesetzt, dass das Feld creg/z in einem Ziel-Befehl
durch einen Code "0001 ", der einen SWBP
angibt, ersetzt und gesichert wird. Dieses Feld wird unter Verwendung
der Pipelinephase DC decodiert. Das Decodieren eines "0001" löst eine
Unterbrechungspunktoperation aus und ruft das XDS 51 auf,
um durch Ausführen
der wie die oben beschriebenen Pipe-down- und Pipe-up-Unterbrechungspunkt-Prozeduren
eine Austest- oder Emulationsoperation auszuführen. Beim Abschluss der Austest-
oder Emulationsoperation ersetzt das XDS während E1 den SWBP-Befehl in
der Pipeline, indem es das zugeordnete Feld creg des Felds auf seinen
ursprünglichen
Wert zurücksetzt.
Außerdem
wird dadurch, dass ein SWBP decodiert wird, ein SWBP_DEC-SRL gesetzt.
Das XDS verwendet SWBP_DEC (20)
als Status. Beim Ersetzen von SWBP in der Pipeline durch das richtige
Feld creg, sollte das XDS das SWBP_DEC löschen, so dass ein weiterer
SWBP decodiert werden kann. Gemäß einem
Aspekt der vorliegenden Erfindung wird in Reaktion auf einen Software-Unterbrechungs-Befehl
eine Austestfunktion ausgeführt,
wobei der normale Pipelinebetrieb wieder aufgenommen wird, ohne
den Befehl, der in einen SWBP umgesetzt wurde, vorauszuholen. Vorteilhaft
werden in dem Datenverarbeitungssystem aus 1 keine fremden Speicherzyklen ausgeführt.
-
Wieder
anhand von 29 wird
angenommen, dass die CPU über
eine Emulationshaltfolge angehalten worden ist und dass das XDS
den gesamten erforderlichen Zustand, der von dem Diagnoseprogramm
anzuzeigen ist, entnommen hat. Das XDS kann ein Einzelweiterschalten
des Mikroprozessors 1 ausführen, indem es die ersten 6
Schritte der Neustartfolge ausführt
und daraufhin die gesamte Emulationshaltfolge erneut ausführt. Es
wird angemerkt, dass der Analysetestport in CNTL oder FUNC verriegelt
sein muss, während
das Einzelweiterschalten für
Analyseereignisse stattfindet. Ähnlich
muss der Megamodultestport in CNTL oder FUNC verriegelt sein, damit
Unterbrechungen erfasst werden. Mit anderen Worten, damit Unterbrechungen
erfasst werden, muss dieser Abschnitt des Megamoduls weiter laufen.
Außerdem
führt die
CPU kein Einzelweiterschalten in Unterbrechungsdienst-Holpakete
aus. Es muss ermöglicht
werden, dass die CPU während
einer minimalen Anzahl von Zyklen läuft, bevor eine Unterbrechung
bedient wird.
-
Ereignisse
können
aus verschiedenen Gründen
in Reaktion auf den Zustand der verschiedenen Testports 310, 320 und 330 aufgeschoben
werden. Drei Bedingungen schieben Analyseereignisse während eines Halts
auf:
- 1. Während
eines Halts zwingen die Zustände
PAUS/SDAT/SCTL des CPU-Testports
und das Signal CPU_DONE das Signal SUSPEND aktiv, wobei zukünftige Analyseereignisse
gesperrt werden. Wenn der CPU-Testport zu CNTL oder zu FUNC zurückkehrt,
kehrt das Signal SUSPEND in den inaktiven Zustand zurück.
- 2. Außerdem
wird verhindert, dass Analyseereignisse Halts bewirken, wenn der
CPU-Testport in dem Zustand FUNC ist.
- 3. Das XDS kann das ECTL-Bit über den Scan setzen, um Analyseereignisse
während
der Emulationssteuerung zu sperren.
-
Ein
Halt wird durch ein IDLE oder durch einen Mehrzyklen-NOP-Befehl
in der Pipeline nicht beeinflusst. Bei einem Pipeline-Neustart wird
der vorausgehende Zustand des IDLE oder des Mehrzyklen-NOP in der
Pipeline wiederhergestellt.
-
In
normalen Austest- und Emulationsoperationen werden weder die Analysedomäne noch
die Megamoduldomänen
blockiert; somit ist für
den MTAP kein Quittungsaustauschsignal (wie etwa über CPU_DONS) zum
Anhalten des Testports 320 oder 330 vorgesehen.
Der MTAP führt
einfach die Taktumschaltung aus, wobei er bei den richtigen Taktbegrenzungen über die
Zustände
verschiebt. Falls diese Domänen
aus irgendeinem Grund angehalten werden müssen, dürfen sie erst angehalten werden,
nachdem die CPU-Domäne
angehalten worden ist.
-
Die 30A, 30B, 30C und 30D veranschaulichen verschiedene
Register, die wie oben beschrieben während der Emulation und während des
Austestens verwendet werden. Diese umfassen: das Analysesteuerregister
(ACR) 390, das Analysedatenregister (ADR) 391,
den Analyseunterbrechungsrücksprungzeiger (ARP) 392 und
das Datenstromregister (STREAM) 393. Diese verschiedenen
Register sind in den vorherigen Abschnitten diskutiert worden und
werden nun ausführlicher
beschrieben. In diesen Figuren bezieht sich der Begriff "MVC-lesbar" und "MVC-schreibbar" darauf, ob besondere
Bits in einem CPU-Steuerregister durch einen MVC-Befehl gelesen
oder geschrieben werden können.
Sämtliche
reservierten oder Nur-Schreiben-Bits werden als "0" gelesen.
-
30A beschreibt das ACR 390,
das die Steuer- und Statusbits für
die Emulation und Analyse enthält.
Die Statusbits bewirken keine Halt- oder Analyseunterbrechung, sondern
widerspiegeln einfach die Tatsache, dass das Ereignis aufgetreten
ist, während
die Ereignisse nicht aufgeschoben wurden. Wenn sie auftreten, lösen die
tatsächlichen
Ereignisse selbst (falls sie freigegeben sind) einen Halt aus oder
setzen sie das AIP in der Weise, dass es eine anstehende Unterbrechung
zeigt. Außerdem
setzt das Rücksetzen
das ACR nur dann auf seine Rücksetzwerte,
wenn der CPU-Testport in dem Zustand FUNC ist. Die Ausnahme ist RSTOCC,
das unabhängig
vom Zustand des CPU-Testports immer rückgesetzt wird. Tabelle 36
beschreibt die Funktion jedes ACR-Bitfelds.
-
-
-
-
Tabelle
37. Beschreibungen der Ereignisfreigabe- und Statusfelder (EES-Felder)
-
30B beschreibt das Analysedatenregister
(ADR) 391. Die oberen 30 Bits des ADR werden in der Pipelinephase
DC zum Vergleichen mit der Programmadresse verwendet, um einen Programmadressenunterbrechungspunkt
zu erzeugen. Dieses Register ist in der Analysedomäne und wird
zur Nachrichtenübergabe verwendet.
Ein Lesevorgang dieses Registers während eines Analyse-Scan gibt
0 zurück
und setzt das Bit MSGERR in dem ACR. Ein Schreibvorgang während des
Analyse-Scan hat keine Wirkung und setzt das Bit MSGERR. Irgendein
anderer Lese- oder Schreibvorgang löscht das Bit MSGERR.
-
30C beschreibt den Analyseunterbrechungsrücksprungzeiger
(ARP) 392, der zuvor anhand der Analyseunterbrechungen
ausführlich
beschrieben wurde.
-
Seicherzugriffsunterstützung
-
Die
Architektur des Mikroprozessors 1 nimmt an, dass sämtliche
Speicherplätze,
ob im Programmspeicher oder im Datenspeicher, beschreibbar sind
(falls RAM oder FLASH verwendet wird). Der Entwurf des Mikroprozessors 1 befolgt
diese Übereinkunft,
um XDS-basierte Daten-Uploads und -Downloads und Programm-Uploads
und -Downloads sowie den Ersatz eines SWI zu überwachen. Außerdem belegen
verschiedene Programm- und Datenspeicher möglicherweise nicht den gleichen
Adressenraum. Caches sind für
den SWI- und SWBP-Ersatz beschreibbar.
-
Für Daten-Downloads
und -Uploads sowie für
Programm-Downloads erledigt das XDS nach einer Emulationshaltfolge
das Folgende:
- 1. Setzen von ECTL. Scannen eines
Holpakets in das DDATA_I 10a (1). Für Datenzugriffe enthalten diese
7 serielle Lade- oder Speichervorgänge. Für Programm-Downloads enthalten
diese 3 MVC/STP-Paare, auf die ein SWBP folgt. Die richtigen Daten
und Adressen werden in die Registerdateien gescannt.
- 2. Die CPU wird frei laufen gelassen. Schließlich löst der SWBP einen Halt und
einen nachfolgenden Neu-Scan aus.
-
Auf
diese Weise kann das XDS 224 Bits/Scan (7 × 32-Bit-Speichervorgänge) Daten
herunter-/heraufladen oder 96 Bits/Scan (3 × 32-Bits-Speichervorgänge) Programm
herunterladen. Gemäß einem
Aspekt der vorliegenden Erfindung werden diese Austestcode-Befehlsfolgen
in das Mehrwort-Befehlsregister geladen und ausgeführt, um
an dem Prozessor 1 eine Austestoperation auszuführen. Vorteilhaft
treten bei dem Datenverarbeitungssystem aus 1 keine fremden Speicheroperationen
auf.
-
Die
Programm-Uploads des Emulators führen
die folgende Emulationspipeline-Haltfolge aus:
- 1.
Es werden ECTL und EUPL gesetzt. Es wird ein Wert in den PFC und
in das PADDR gescannt.
- 2. Es wird dreimal HALT/CNTL angelegt, um über die Phasen PS, PW und PR
zu verschieben.
- 3. Es wird das PDATA_I für
das heraufgeladene Programm gescannt.
- 4. Danach kann das XDS in jedem Zyklus ein einzelnes CNTL/HALT
anlegen. Somit kann der Emulator 256 Bits/Scan ausführen.
-
Während die
voraus gehende Prozedur für
das Herauf- oder Herunterladen kleiner Datenmengen, ohne die Datenverarbeitungssystemumgebung
zu stören,
wirksam ist, gibt es wegen der Menge des erforderlichen Scannens
eine bedeutende Organisationsablaufzeit. Eine als "Datenstrom" bezeichnete Prozedur schafft
die folgenden Datenübertragungen
mit der vollen Scan-Rate: Programmspeicher-Download (von dem XDS),
Datenspeicher-Download (von dem XDS) und Datenspeicher-Upload (in
das XDS).
-
30D veranschaulicht das
Datenstromregister 393, das zur Unterstützung des Datenstroms verwendet
wird. Dieses CPU-Steuerregister verbindet die CPU-Registerdatei mit
dem Datenstrombus von dem MTAP (STRM_I/O). Dieses Register kann
nicht zur Speicherung verwendet werden, da das, was geschrieben wird,
nicht ausgelesen wird. Anhand der Tabellen 38–42 wird nun der Datenstromprozess
ausführlicher
beschrieben.
-
Um
Holvorgänge
zu verhindern, setzt das XDS das ECTL-Bit, um das Holen zu sperren.
Das XDS lädt das
richtige Holpaket in das PDATA_I. Dieses Holpaket führt die
erforderliche Datenverschiebung zwischen den Datenstrombussen (STRM_ST
und STRM_LD) aus, wie auf sie über
das Steuerregister STREAM-CPU zugegriffen
wird. Die CPU schreitet beim Scannen eines neuen Datenworts (jedes
32-te Bit) um einen Zyklus fort. Falls vor dem nächsten Zyklusschritt kein CPU_DONE
empfangen wird, zwischenspeichert der MTAP diesen Fehlerzustand.
Daraufhin kann das XDS einen Datenstromfehler erfassen, der bei
Ab schluss des Datenstromprozesses aufgetreten ist. Einzelheiten
des Managements der Datenverschiebung und der Fehlererfassung in
dem MTAP werden später
diskutiert. Da das Befehlsholen verhindert ist, wird für die Dauer
des Datenstromprozesses vorteilhaft dasselbe Holpaket ausgeführt.
-
Die
Tabellen 38 und 39 zeigen das Holpaket zur Steuerung von Datenstromdaten-Downloads
an dem Datenport 2 bzw. 1. Da der Mikroprozessor 10 die
zwei Ports in physikalisch getrennte Speicherräume schreiben lassen kann,
sind Beispiele für
beide Datenports gezeigt. In beiden Fällen wird ein MVC-Befehl mit
dem STREAM-Register als ein Operand verwendet, um die Datenstromdaten
in die Registerdateien B und A zu verschieben. Für den Datenport 2 muss das
XDS den Anfangsdatenwert für
das erste STW in die Registerdatei (in B1) scannen. Für Downloads
des Datenports 1 muss STREAM zunächst
in ein B-Register und daraufhin in ein A-Register verschoben werden,
da der MVC nicht direkt ein A-Register laden kann. In diesem Fall
muss das XDS die beiden Anfangswerte (A1 und B1) beide in die Registerdatei
einscannen. Es wird angemerkt, dass der Mikroprozessor 10 vorteilhaft
verschiedene Kombinationen von Befehlen wie etwa MVC und STW in
Tabelle 38 und in Tabelle 39 parallel ausführen kann, um die Organisationsablaufzeit
zu minimieren.
-
Tabelle
38. Holpaket für
einen Datenstromdaten-Download (Datenport 2)
-
Tabelle
39. Holpaket für
den Datenstromdaten-Download (Datenport 1)
-
Die
Tabelle 40 und die Tabelle 41 zeigen Holpakete zur Steuerung von
Datenstrom-Uploads an den Datenport 2 bzw. 1. Da der Mikroprozessor 1 die
beiden Ports in physikalisch getrennte Speicherräume schreiben lassen kann,
sind Beispiele für
beide Datenports gezeigt. In beiden Fällen wird ein MVC-Befehl mit
dem STREAM-Register als ein Operand verwendet, um die Datenstromdaten
aus den Registerdateien B und A zu verschieben. Außerdem muss
das XDS den letzten Datenwert aus dem letzten LDW von der Registerdatei (von
B1) scannen, nachdem es ermöglicht,
das Takten der letzten Ladevorgänge
nach dem Füllen
von PDATA_I mit NOPs manuell abzuschließen.
-
Tabelle
40. Holpaket für
Datenstromdaten-Uploads (Datenport 2)
-
Tabelle
41. Holpaket für
Datenstromdaten-Uploads (Datenport 1)
-
Tabelle
42 zeigt das Holpaket zum Steuern von Datenstromprogramm-Downloads.
Wie bei Daten-Downloads muss das XDS den ersten zu speichernden
Wert in die Registerdatei (in B0) laden. Allerdings ist anders als
beim Datenstrom für
Programmzugriffe kein Befehl verfügbar, um den STREAM direkt
in das Register, d. h. in ein Programmdaten-Ausgangsregister (PDATA_O),
das sich in der Programmholschaltungsanordnung 10a befindet,
zu verschieben, um ihn zu speichern. Somit muss das Signal STRM_SEL
verwendet werden, um PDATA_O in jedem Zyklus (über den STRM-E/A-Bus) auf den
Wert von STREAM zu aktualisieren.
-
Tabelle
42. Holpaket für
Datenstromprogramm-Downloads
-
Caching-Unterstützung
-
In
dem Steuerstatusregister (CSR) gibt es unabhängige Steuerungen für Daten- und Programm-Caches,
die Folgendes ermöglichen:
- 1. Caches einfrieren: die gecacheden Werte
werden gelesen. Lesevorgänge
aktualisieren den Cache nicht.
- 2. Caches leeren: Alle gecacheden Daten werden ungültig gemacht.
Es finden keine Aktualisierungen statt.
- 3. Cache umgehen: Die Werte werden aus dem Speicher gelesen.
Lesevorgänge
aktualisieren den Cache nicht.
-
Die
folgenden Vorschriften werden auf die XDS-Steuerung von Speicherzugriffen
in Bezug auf Caches angewendet.
- 1. Bei Daten-
oder Programm-COFF-Downloads werden die Caches geleert und daraufhin
in ihre früheren Steuerzustände wieder
aufgenommen.
- 2. Für
Daten- oder Programm-COFF-Uploads werden die Caches eingefroren
und auf ihre früheren
Steuerzustände
zurückgesetzt.
- 3. Für
Daten- oder Programmspeicher-Lesevorgänge in einer CPU-Speicheransicht werden
die Caches eingefroren und daraufhin in ihre früheren Steuerzustände wieder
aufgenommen.
- 4. Für
Daten- oder Programmspeicher-Lesevorgänge in einer physikalischen
Speicheransicht werden die Caches umgangen und in ihre früheren Steuerzustände zurückgesetzt.
- 5. Für
Daten-Schreibvorgänge
wird an den Cache-Steuerbits keine Änderung vorgenommen.
- 6. Für
Programm-Schreibvorgänge
wird der Cache geleert und daraufhin in seine früheren Steuerzustände zurückgesetzt.
-
Anmerkungen
zu Entwicklungshilfsmitteln
-
Das
Programmierermodell zum Austesten in dem XDS und in dem Simulator
ist wie folgt:
- 1. Sämtliche Informationen werden
auf zyklusweiser Grundlage (im Gegensatz zu taktweiser Grundlage) angezeigt.
Somit sind Speicherblockierungen für den Anwender nicht sichtbar.
- 2. Das Diagnoseprogramm hebt das nächste beim Disassemblieren
auszuführende
Ausführungspaket
hervor.
- 3. Es werden sämtliche
Registerergebnisse angezeigt, die bis zum Ende des letzten Zyklus
geschrieben werden:
- A) Die Ergebnisse des Ausführungspakets
in E1 (Ein-Zyklus-Ganzzahlbefehle, Adressenänderung) in dem vorausgehenden
Zyklus.
- B) Ähnlich
die Ergebnisse des Befehls in E2 von zwei Zyklen zuvor (Ganzzahlmultiplikationen).
- C) Die Ergebnisse des Befehls in E4 (Gleitkommabefehle) von
vier Zyklen zuvor.
- D) Die Ergebnisse des Befehls in E5 (Ladeoperationen) von fünf Zyklen
zuvor.
-
In überwachungsbasierten
Diagnoseprogrammen muss der Programmierer eine Einzelzuweisung verwenden.
Außerdem
erscheinen sämtliche
Befehle zur Ausführung
in der Reihenfolge.
-
Falls
beispielsweise in 31 das
Ausführungspaket
(f) hervorgehoben ist, wird der gesamte in der oder vor der Doppellinie 400 geschriebene
CPU-Zustand angezeigt. Somit werden z. B. die Ergebnisse des Ausführungspakets
(e) nicht angezeigt, wenn es eine Multiplikation ausgeführt hat.
Stattdessen enthält
das Zielregister der Multiplikation seine früheren Inhalte aus Zyklus 11.
-
Anders
als beim CPU-Zustand wird zugelassen, dass der Speicherzustand zum
Abschluss von Speichervorgängen
fortschreitet. In 31 werden
die Speichervorgänge
in den Ausführungspaketen
c-e abgeschlossen. Somit scheint die Speicheranzeige (die aktualisiert
wird, nachdem sämtliche
Scans abgeschlossen sind) der CPU 3 Zyklen voraus zu sein. Obgleich
dies mit Ladevorgängen
mit 4 Verzögerungsschlitzen
inkonsistent zu sein scheinen könnte,
muss der Programmierer betrachten, dass der Wert des Ladewerts derjenige ist,
der unmittelbar vor dem Weiterschalten über einen Ladebefehl in der
Anzeige angezeigt wird. Da sämtliche Zugriffe
an der CPU-Begrenzung in der Reihenfolge auftreten, ist die Speicheranzeige
selbstkonsistent.
-
Fchtzeit-Austesten
-
Überwachungsbetriebsart:
Die Echtzeitaustestung schafft Anwendersichtbarkeit – während im
Mikroprozessor 1 Anwendercode läuft. Die Variablen können sowohl
vom Standpunkt der Assemblersprache als auch einer höheren Sprache
(HLL) angezeigt und geändert
werden. Dieses Echtzeitaustesten ist an sich unabhängig von
der Emulationslogik. Normalerweise ist die Austestüberwachungseinrichtung
entweder die Hintergrundaufgabe oder eine Unterbrechungsdienstroutine
auf sehr niedriger Ebene, die in Anwesenheit von Echtzeitaufgaben
läuft,
die durch Unterbrechungen mit höherer
Priorität
angesteuert werden. Die Überwachungseinrichtung
kommuniziert mit einem Host, bei dem sich ein Diagnoseprogramm befindet.
Das Diagnoseprogramm kann auf der untersten Ebene Speicher- und
Registerlesevorgänge
und Speicher- und Registeränderungen
anfordern. Die Kommunikation kann über Peripherieeinrichtungen
wie etwa serielle Ports, über gemeinsam
genutzten Speicher oder über
hierfür
vorgesehene Nachrichtenübergabehardware
(wie etwa das ADR) stattfinden. Betrachtungen zur Entwicklung von Überwachungscode
sind: Codegröße: Die Überwachungscodegröße muss
minimiert werden.
-
Leistung:
Der Überwachungscode
muss schnell genug laufen, um eine angemessene Anwendererreichbarkeit
zu schaffen.
-
Einzelweiterschalten
-
Das
Diagnoseprogramm führt
zwei Typen des Weiterschaltens aus:
- 1. Weiterschaltanweisungen
in einer höheren
Sprache.
- 2. Weiterschaltausführungspakete
auf zyklusweiser Basis.
-
Da
die Pipelinesichtbarkeit entscheidend für die Programmierung der CPU
ist, braucht das Diagnoseprogramm das Befehlsweiterschalten (das
Weiterschalten eines Befehls über
die gesamte Strecke von E1 bis E5) nicht zu unterstützen. Stattdessen
ermöglicht
der Schrittmechanismus lediglich, dass der Zustand um eine einzige
Pipelinephase fortschreitet.
-
Nach
einem Emulationshalt wird durch eine Pipeline-Halt-Scan-Folge (28), auf die ein Teilneustart folgt
(29), ein Ausführungspaketweiterschalten
ausgeführt.
Genauer wird ermöglicht,
dass der Neustart einen Zyklus fortschreitet. Daraufhin tritt die
Emulationshaltfolge in ihrer Gesamtheit erneut auf.
-
Im
Allgemeinen entsprechen Ausführungspakete
oder Gruppen von Ausführungspaketen
nicht auf eineindeutiger Basis Anweisungen in höheren Sprachen (HLL-Anweisungen).
Um eine HLL-anwendungsweise Sichtbarkeit zu schaffen, sind die folgenden
Zugänge
verfügbar:
- 1) Der HLL-Compiler kann Code erzeugen, der
Nebenwirkungen erzeugt, die in der Reihenfolge abgeschlossen werden.
Allerdings verhindert dies drastisch, dass Hochleistungscode erzielt
wird. Außerdem maskiert
diese Einschränkung
Probleme, die nur dann auftreten, wenn eine Ausführung außer der Reihe zulässig ist.
- 2) Das XDS kann mehrere Halte und Scans ausführen, so dass die Ergebnisse
einer besonderen HLL-Anweisung isoliert werden können. Um diese Methodik zu
ermöglichen,
müssen
neue Verfahren zum Einbetten von Austestinformationen in das Objekt
entwickelt werden. Außerdem
muss in einer Anzeige in einer gemischten Betriebsart (sowohl Assembler
als auch HLL) ein Verfahren entwickelt werden, das zeigt, welche
Assembleranweisungen welche Pipelinephase, wie sie in der Anzeige
zu sehen ist, abgeschlossen haben. Ein Nachteil dieses Verfahrens
ist, dass der Anwender möglicherweise
keine neuen Speicherplätze oder
symbolischen Werte für
die Anzeige anfordern kann. Diese Informationen können bereits
verloren gegangen sein, da der Teil darüber hinaus gelaufen sein kann,
wenn ihre Werte gültig
sind. Ausgehend von der momentanen Emulationsbeschreibung in diesem
Kapitel sind beide Lösungen
praktizierbar.
-
Der
Softwareersatz eines SWI-Befehls im Programmspeicher durch den richtigen
Befehl erfolgt durch das Anwenderüberwachungsprogramm. Falls
Unterbrechungen freigegeben sind und die SWI die anstehende Unterbrechung
mit der höchsten
Priorität
ist, wird sie genommen, wenn die SWI in DC ist. Falls es Unterbrechungen
mit höherer
Priorität
gibt, wird die SWI beim Rücksprung
von der Unterbrechung erneut geholt und somit erneut festgestellt.
Die SWI-Erkennung wird dadurch verschoben, dass sie in den Verzögerungsschlitzen einer
genommenen Verzweigung ist, oder wird verschoben, falls AINT nicht
freigegeben ist.
-
Megamodul-Testzugriffsport
(MTAP)
-
Es
wird nun ausführlich
der MTPA beschrieben. Aspekte der vorliegenden Erfindung beziehen
sich auf Verbesserungen an der Struktur der IEEE 1149.1–1990, Standard
Test Access Port and Boundary Scan Architecture. Die Begriffe und
Konzepte in Bezug auf die IEEE 1149.1, die hier verwendet werden,
sind in dieser IEEE-Norm ausführlich
erläutert.
Gleichfalls beziehen sich Aspekte der vorliegenden Erfindung außerdem auf Verbesserungen
an der Struktur des modularen Pon-Scan-Entwurfs (Modular Pon Scan
Design, MPSD) von Texas Instruments, wie er im US-Pat. Nr. 4.860.290
offenbart ist. Insbesondere ist der Betrieb der Schieberegisterzwischenspeicher
(SRLs), die jeweils für
jedes Modul wie eine Perlenschnur auf einem seriellen Scan-Pfad über den
gesamten Mikroprozessor 1 verteilt sind und einen Zugriff
auf alle "wichtigen" Register schaffen,
im US-Pat. Nr. 4.860.290 beschrieben.
-
Wieder
anhand von 15 unterstützt der
Megamodul-Testzugriffsport (MTAP) 305 eine Teilmenge der
Merkmale des Testzugriffsports der Norm IEEE 1149.1. Da der MTAP
des Megamoduls 300 die Anschlussstifte des Mikroprozessors 1 nicht
direkt ansteuert, gibt es keine Anforderung zur Unterstützung eines
Boundary-Scan. Der MTAP 305 schafft eine 1149.1-konforme
JTAG-Zustandsmaschine sowie serielle Scan-Kommunikationen zwischen
dem Scan-Controller eines fernen Hosts 51 und den Domänentestports
(DTPs) 310, 320 und 330 des Megamoduls.
Wie in den vorangehenden Abschnitten diskutiert wurde, schafft der
MTAP 305 außer
der JTAG-Schnittstelle eine Testunterstützung, eine automatische Ausführungssteuerung
der DTPs, einen Datenstrom-Steuermechanismus, der einen beträchtlichen
Leistungsvorteil schafft, eine Unterstützung der Multiprozessor-Emulation
und eine Leistungsanalyse. Die Testmerkmalsmenge des MTAP 305 unterstützt die Anwendung
der Erzeugung automatischer Testmustererzeugungsmuster (Automatic
Test Pattern Generation-Muster, ATPG-Muster). Unter Verwendung der Emulationsfähigkeiten
können
Funktionstestmuster geladen, ausgeführt und ausgetestet werden.
-
32 ist ein Blockschaltplan,
der die Signalverbindungen vom Megamodul 300 zu den Anschlussstiften
410–416
am Mikroprozessor 1 veranschaulicht. Außerdem ist die Architektur
des Megamoduls 300, wie früher diskutiert wurde und hier
zusammengefasst wird, anhand von 15 zwischen
dem MTAP 305 und vier Domänen: dem CPU-Kern 10,
der CPU-Analyse 321, dem Megamodul 331 (enthält sämtliche
Megamodulmerkmale außerhalb
des CPU-Kerns) und der Spezialemulation (SE) 400, aufgeteilt.
Das SE-Modul 400 ist extern gegenüber dem Megamodul 300.
Jede Domäne
schafft eine Ausführungssteuerung
und über
einen Domänentestport
(DTP) einen Zugriff auf die Domänen-Scan-Pfade.
Der DTP 310 der CPU schafft eine Haltebetriebsart und Echtzeitemulationsmerkmale,
die die Programmausführung
(Start, Stopp, Softwareunterbrechungspunkt) und die Sichtbarkeit
für das
Programmierermodell (Register und Speicher) steuern. Die CPU-Analysedomäne 321 schafft
Kernanalysemerkmale, die im Fall des Mikroprozessors 1 einen
Hardwareunterbrechungspunkt und eine Echtzeitemulations-Scan-Kommunikationsunterstützung umfassen.
Die SE-Analysedomäne 400 schafft
fortgeschrittene Emulationsanalysemerkmale. Diese Merkmale umfassen Größenkomparatoren
für Hardwareunterbrechungspunkte,
Programmbusadressen-Unterbrechungspunkte, Datenbusadressen-
und Datenunterbrechungspunkte, Ereigniszähler, Programmunstetigkeitsablaufverfolgung
und Analysezustandsablaufsteuerung. Die Megamoduldomäne 331 schafft
lediglich eine Ausführungssteuerung
und einen Scan-Zugriff derjenigen Merkmale innerhalb des Megamoduls,
die wie etwa die Test-PSA-Register in der Test-Schaltungsanordnung 52 außerhalb
der CPU liegen.
-
Die
Echtzeitemulationsunterstützung
schafft eine Ausführungssteuerung
und Sichtbarkeit des Programmierermodells, während der Prozessor die Bedienung
von Unterbrechungen und Multiplexaufgaben fortsetzt. Außerdem kann
auf die Echtzeitunterbrechung über
ein anwendungsbasiertes Diagnoseprogramm zugegriffen werden, wobei
sie die Verwendung der eingebetteten Analysefähigkeit ohne Verbinden mit
einem fernen Test/Emulations-Controller enthält.
-
Immer
noch anhand von 32 ist
der Megamodul-Testzugriffsport (MTAP) 305 insofern IEEE-1149.1-konform,
als er die Standard-JTAG-Schnittstelle und die Standard-JTAG-Zustandsmaschinenmerkmalsmenge
unterstützt.
Der MTAP 305 ist insofern nicht 1149.1-konform, als er
den Boundary-Scan oder irgendwelche öffentlichen STAG-Befehle außer BYPASS
nicht unterstützt.
JTAG-basierte Emulations- und Testanforderungen für den Mikroprozessor 1 werden
unter Verwendung von Einrichtungen in der IEEE 1149.1 geschaffen,
die anwendungsspezifische JTAG-Anweisungen und Datenpfaderweiterungen
zulassen. Bezugnahmen auf die geforderte JTAG-Fähigkeit werden hier als "öffentliche Fähigkeit" bezeichnet, während Erweiterungen
als "private" Fähigkeit
bezeichnet werden.
-
Die
Unterstützung
der Emulations- und Testmerkmale in dem Megamodul (MTAP) 300 erfordert
die Verbindung mit der Standard-JTAG-Fünf-Anschlussstift-Schnittstelle
(TMS 410, TRST 411, TDI 412, TDO 413, TCLK 414),
ergänzt
durch zwei zusätzliche
doppelt gerichtete Emulationsunterbrechungsanschlussstifte (EMU1 415,
EMUO 416) des Mikroprozessors 1. Es gibt mehrere
JTAG/MTAP-Konfigurationen, die in den folgenden Abschnitten diskutiert
werden. Die Anschlussstifte EMUO und EMU1 können so konfiguriert werden, dass
Multiprozessor-Haltereignisse und Leistungsanalysemerkmale erleichtert
werden. Die Anschlussstifte EMUO/1 sind Funktionsanschlussstifte
und an sich konform zu sämtlichen
Megamodulbegrenzungs-Zellenvorschriften.
-
Um
die Kommunikation und Steuerung zwischen den JTAG-Anschlussstiften
der Vorrichtung, dem MTAP 305 und mehreren Domänentestports
zu unterstützen,
wurden innerhalb des JTAG-Systems die folgenden Konstrukte hinzugefügt.
-
Datenpfaderweiterungen – erweiterte
private JTAG-IR-Anweisungen schaffen eine MTAP-Daten-Scan-Auswahl
des Domänenstatus,
der EMU1- und EMUO-Konfigurationen. Emulationssteuerung. Domänen-Scan-Pfadauswahl
und Domänen-Verriegelungsinformationen.
-
Befehlserzeugung – erweiterte
private JTAG-IR-Anweisungen schaffen Test- und Emulationsanweisungen,
die durch den JTAG-Zustand IDLE begonnen werden.
-
Befehlsregistererfassung – es wurde
eine JTAG-Befehlsregistererfassung verschiedener Emulationszustands-,
Domänenstatus-
und Testinformationen hinzugefügt,
um den Emulationssoftwarebetrieb und die MTAP-Testfähigkeit
zu erleichtern.
-
Die
JTAG-Signale des MTAP 305 sind wie folgt:
- TMS: Testbetriebsartauswahl.
Dieses Signal steuert den Übergang
des JTAG-Zustandsdiagramms. Die verschiedenen durchlaufenen Zustände bewirken,
dass die Befehls- und Datenpfade gescannt und die JTAG-Befehle ausgeführt werden.
- TCK: Testtakt. Dieses Signal schafft einen Takt für die JTAG-Logik
und -Zustandsmaschinen. Die JTAG-Schnittstelle wird mit einer dem
Megamodul von außen
zugeführten
Frequenz getaktet und ermöglicht, dass
das Megamodul mit anderen JTAG-Vorrichtungen, mit anderen JTAG-Controllern
und mit anderer JTAG-Testausrüstung,
die für
andere Taktraten entworfen worden ist, verträglich ist. In dieser Beschreibung
ist dieser Takteingang als TCLK bezeichnet. Die normale Systemtakteingabe
wird als UCLK (Funktionstakt) bezeichnet.
- TDI: Testdateneingabe: Dieses Signal schafft Eingangsdaten für alle JTAG-Befehls-Scans
und JTAG-Daten-Scans des Megamoduls.
- TDO: Testdatenausgabe. Dieses Signal schafft Ausgangsdaten von
allen JTAG-Befehls-Scans und JTAG-Daten-Scans des Megamoduls.
- TRST: Testrücksetzen.
Dieses Signal setzt das JTAG-Modul zurück und wird geschaffen, um
sicherzustellen, dass der Testzugriffsport (TAP) beim Einschalten
schnell initialisiert wird.
-
Die
Beziehungen zwischen diesen Signalen sind in der Spezifikation IEEE
1149.1 definiert.
-
Die
EMU-Signale des MTAP 305 sind wie folgt:
- EMUI [1:0]:
EMU-Eingang. Da EMUI asynchron sein kann und irgendeine Impulsbreite
aufweisen kann, ermöglicht
die Analysedomäne,
die Erfassung einer logischen Null an EMUIn als ein Ereignis zu
verwenden. Um sicherzustellen, dass ein einzelnes taktsynchrones
Ereignis zur Ereignisverarbeitung an die CPU-Domäne (EMUI-Signale) gesendet
wird, muss EMUI an einen Impulsfänger
und Synchronisator übergeben
werden. Der Impulsfänger
ist selbstlöschend
durch den synchronisierten Ereignisimpuls.
- EMUO[1:0]: EMU-Ausgang. Dieses Signal wird genutzt, um Ereignisse
auszugeben, die (in den Emulations- und Testbetriebsarten) über die
EMUC-Bits des ECR oder (in der Strap-Betriebsart) über die
CPU_EMUC-Bits des ACR ausgewählt
wurden. Die Signale EMUO[1:0] vom MTAP 305 müssen wenigstens
5 ns aktiv sein (Testbus-Controller-Anforderung).
- EMUOEN[1:0]: EMU-Ausgangsfreigabe. Dieses Signal schafft eine
Freigabe für
den externen Tristate-Puffer des Signals EMUO, der zum Ansteuern
der EMU-Anschlussstift-Anschlussfläche verwendet wird. Die Betriebsart
dieses Signals, gemeinsam genutzt oder dediziert, wird (in der Emulations-
und Testbetriebsart) über die
EMUC-Bits des ECR oder (in der Strap-Betriebsart) über die
CPU_EMUC-Bits des ACR ausgewählt.
In der gemeinsam genutzten Betriebsart wird dieses Signal nur dann
freigegeben, wenn das Ereignis aktiv ist, was den Ausgangspuffer
in der Tristate-Betriebsart lässt,
wenn ein Ereignis nicht freigegeben ist. Wenn es in der gemeinsam
genutzten Betriebsart gesperrt wird, kann der Zustand der EMU-Anschlussstift-Anschlussflächen von
einem externen Ereignis in den EMUI-Treiber angesteuert werden.
In der dedizierten Betriebsart ist dieses Signal immer aktiv, was
die EMU-Anschlussstift-Anschlussfläche auf den EMUO-Signalpegel
zwingt. Beispiele der Verwendung dieses gegenüber dem Megamodul externen
Signals werden später
diskutiert.
-
JTAG-Opcode-Nutzung
-
Der
JTAG-Opcode-Raum Ox00–0x1F
ist für
den JTAG-spezifischen Gebrauch reserviert. Die diesen Opcodes zugeordneten
Scan-Pfade und -Befehle
sind in der Spezifikation IEEE 1149.1 definiert. Dieser Opcode-Raum
ist momentan lediglich teilweise definiert, wobei alle nicht definierten
Opcodes in dieser Gruppe zur zukünftigen
Verwendung reserviert sind. Bezugnahmen auf irgendeinen Opcode in
dieser Gruppe erfolgen hier als auf einen öffentlichen Opcode.
-
Gemäß einem
Aspekt der vorliegenden Erfindung ist ein Abschnitt des nicht definierten
JTAG-Opcode-Raums von 0x20–0x2F
für die
emulationsspezifische Verwendung reserviert. Auf diese Opcodes wird
als private Opcodes Bezug genommen. Alle nicht definierten Opcodes
in dieser Gruppe sind zur zukünftigen
Verwendung bei der Emulation reserviert.
-
Die
Opcodes innerhalb des Bereichs 0x20–0x2F sind zum Auswählen von
Daten-Scan-Pfaden und als Emulations- und Testanweisungen definiert.
Wenn die JTAG-Zustandsmaschine in dem JTAG-Zustand SHIFT_DR (Verschiebung
des ausgewählten
Datenregisters) ist, wird ein Opcode als eine Daten-Scan-Pfadauswahl
genutzt. Der gleiche Opcode wird als Anweisung genutzt, wenn die
JTAG-Zustandsmaschine
in dem JTAG-Zustand IDLE ist. Außerdem werden die JTAG-Opcodes genutzt,
um in einer Testbetriebsart, die die JTAG-Zustände auf DTP-Steuerzustände abbildet, Steuercodes direkt
an einen DTP anzulegen. Jede dieser drei Verwendungen der Opcodes
ist von den anderen entkoppelt. Dieses Dokument diskutiert sie unabhängig.
-
33 ist ein Blockschaltplan
der Organisation des MTAP-Scan-Pfads. Außer den IR- und Umgehungspfaden,
die von der JTAG-Spezifikation beauftragt sind, sind Emulations/Test-Scan-Pfade
vorgesehen. Es wird angemerkt, dass der MTAP 305 keinen
Boundary-Scan-Pfad unterstützt
(was den MTAP 305 nicht-JTAGkonform macht). Die Emulations/Test-Pfade
werden dadurch gescannt, dass die JTAG-Zustandsmaschine bis zu dem
Zustand SHIFT-DA durchlaufen wird, dem ein SHIFT-IR-Scan zur Auswahl
des Scan-Pfads vorangestellt ist. Mehr als ein Opcode kann die gleichen öffentlichen
oder privaten Scan-Pfade adressieren.
-
Die öffentlichen
und privaten Scan-Pfade sind in Tabelle 43 kurz beschrieben.
-
Tabelle
43. Öffentliche
und private Scan-Pfade
-
-
JTAG-Datenpfadsteuerung
-
Weiter
anhand von 33 werden
die Scan-Daten während
des JTAG-Zustands SHIFT_DR über
ein ausgewähltes
Datenschieberegister verschoben. Das Datenschieberegister verschiebt
von MSB auf LSB, wobei das LSB des Schieberegisters während des
ersten Zustands SHIFT_DR in TDO ausgegeben wird. Falls ein statischer
Wert des übertragenen
Datenbits benötigt
wird, können
die vom TDI in das Datenschieberegister verschobenen Daten am Ende
der Schiebefolge in ein paralleles Halteregister übertragen
werden. Das parallele Halteregister wird ein Schattenregister oder,
für ein
Halteregister der Länge
eins, ein Schattenbit genannt. Die Implementierung des MTAP 305 verwendet
eine Mischung aus Schattenbits und Schieberegisterbits als Schnittstelle
für Prozessoremulationsfunktionen.
Wenn die Schieberegisterbits direkt verwendet werden, ist die Verschiebung
des Datenschieberegisters in der Endanwendung des Bits unbedeutend
gemacht worden.
-
In
die Datenregistergruppe von JTAG-Zuständen wird eingetreten, wenn
der Zustand SELECT_DR in CAPTURE_DR übergeht, während sie endet, wenn die Ausführung des
Zustands UPDATE_DR abgeschlossen ist. Diese Gruppe von Zuständen wird
einem spezifischen Datenpfad zugewiesen, der durch den Opcode ausgewählt wird,
der in dem JTAG-Befehlsregister gehalten wird, während die Datenregister-Scan-Zustandsgruppe
durchlaufen wird. Diese Zustandsgruppe enthält drei Zustände mit
pfadspezifischer Wichtigkeit. Diese Zustände, CAPTURE_DR, SHIFT_DR und
UPDATE_DR können
mit dem in dem JTAG-Befehlsregister enthaltenen Opcode kombiniert
werden, so dass sich pfadspezifische Richtlinien für das Management
der Scan-Daten ergeben.
-
Der
Zustand CAPTURE_DR kann zu Beginn der Schiebefolge wahlweise Informationen
in das Datenschieberegister laden. Diese Informationen sind daraufhin
an dem TDO-Anschlussstift des Chips sichtbar, während ein pfadspezifisches
Datenschieberegister über
den Zustand SHIFT_DR vorgerückt
wird. Der Zustand UPDATE_DR wird verwendet, um Daten, die in das
Datenschieberegister verschoben werden, an das richtige parallele
Datenregister zu übertragen,
das durch den JTAG-IR-Opcode bezeichnet wird.
-
Die
meisten privaten MTAP-Datenpfade erfordern nicht, dass die CAPTURE_DR-Funktion
für jede
Datenpfadbitstelle implementiert ist. In einigen Fällen erfordert
ein gesamter Datenpfad nicht, dass die CAPTURE_DR-Funktion implementiert
ist. Dies ist insbesondere wahr für DTP-Daten-Scan-Pfade. Einige
privaten MTAP-Datenpfade nutzen ein Datenschieberegister gemeinsam.
Diese Implementierung führt
zu einem einzelnen Datenschieberegister, dessen Daten durch ein
geeignetes Signal UPDATE_DR wahlweise in verschiedene Schattenregister
oder -bits übertragen
werden. Dieser Zugang wird innerhalb der DTPs genutzt, um ein einzelnes
physikalisches Schieberegister zu nutzen, das sowohl die DTP_SCTL-
als auch die DTP_SDAT-Scan-Pfade unterstützt. Dieser gemeinsam genutzte
Zugang ermöglicht
außerdem,
dass die CAPTURE_DR-Zustandsfunktion für die Pfade gemischt wird.
Sämtliche
oben diskutierten Optionen für
die physikalische Implementierung ändern die Datenpfadkonfiguration
oder den Datenpfadbetrieb, wie sie bzw. er durch die Softwaresteuerung
der Pfade betrachtet wird, NICHT.
-
Wenn
der JTAG-TAP über
den Zustand SELECT_DR übergeht,
hängen
der ausgewählte
Daten-Scan-Pfad und die erfassten und aktualisierten Register von
dem Befehl in dem JTAG-IR ab. IR-Anweisungen, die andere Daten als
die DTP-Daten-Scan-Anweisungen
an die DTPs richten, erfordern ein Aktualisierungs- und in einigen
Fällen
ein Erfassungssignal (die auf den JTAG-TAP-Zuständen CAPTURE_DR und UPDATE_DR
beruhen). Die DTP_SDAT- und DTP-SCTL-Scan-Pfade nutzen über die DTPs ein gemeinsames Datenschieberegister
gemeinsam. Im Fall des DTP-SCTL-Pfads bewirkt das Pfadauswahlsignal
zusammen mit dem Zustand CAPTURE_DR, dass das gemeinsame Schieberegister
aus den MSENB-Schattenbits geladen wird. Nachdem ein Scan abgeschlossen
ist (SHIFT-DR),
bewirkt der Zustand UPDATE_DR, dass der neue Wert in dem gemeinsamen
Schieberegister an die eindeutigen MSENB-Schattenregister übertragen
wird. Im Fall des DTP_SDAT-Pfads wird das gemeinsame DTP-Schieberegister
als ein Umgehungsbit genutzt. Alle anderen Scan-Pfade werden direkt
gescannt (nicht über
die DTPs gescannt). Tabelle 44 zeigt ausführlich die Anforderungen an
jeden Scan-Pfad.
-
Tabelle
44. Einzelheiten des JTAG-DATA-PATH
-
Die
Auswahlsignale SCTL_SEL, SECR_SEL, SCTR_SEL, STRM_SEL und SECT_SEL
schließen sich
gegenseitig aus und werden durch den TAP-Zustand UPDATE_IR inaktiv
angesteuert.
-
Weiter
anhand von 33 besitzt
das JTAG-Befehlsregister (JTAG-IR) 450 des MTAP 305 eine
Länge von
acht Bits, wobei alle Bits bei der Befehlsdecodie rung verwendet
werden. Die decodierten Befehle werden genutzt, um Scan-Pfade auszuwählen oder
Anweisungen auszuführen.
Der Zugriff auf das IR wird durch eine Gruppe von JTAG-Zuständen geschaffen.
In diese Zustände
wird eingetreten, wenn der Zustand SELECT_IR in CAPTURE_IR übergeht,
während
sie verlassen werden, wenn der Zustand UPDATE_IR verlassen wird. Wenn
die JTAG-TAP-Zustandsmaschine über den
Zustand SELECT_IR geht, wird das IR-Register mit dem JTAG-Daten-Scan-Pfad
verbunden. Der Zustand CAPTURE_IR lädt die Informationen zu Beginn
der Verschiebungsfolge in das Befehlsschieberegister. Die erfassten
Daten hängen
vom Zustand der Statusauswahlbits (STSL-Bits) in dem Emulationssteuerregister
(Emulation Control Register ECR) (siehe 36) ab. Diese Informationen sind daraufhin
an dem TDO-Anschlussstift des Chips sichtbar, während das Befehlsschieberegister über den
Zustand SHIFT_IR fortschreitet. Wenn in den Zustand SHIFT_IR eingetreten
wird, gibt der DPC (Datenpfad-Controller)
den Scan-Pfad frei, um bei jedem TCLK zu verschieben. Das Befehlsschieberegister wird
vom MSB zum LSB verschoben, wobei das LSB-Erfassungs-Informationsregister
beim ersten Zustand SHIFT_IR an TDO ausgegeben wird. Dieser Mechanismus
wird verwendet, um den Emulations- und Teststatus zu laden und zu
exportieren. Der Zustand UPDATE_IR wird verwendet, um in den Chip
verschobene Daten (die Inhalte des Befehlsschieberegisters) zu den
Schattenbits des IR zu übertragen.
-
34A veranschaulicht das
JTAG-IR bei ausgewähltem
Strap-Status. Der Strap-Status ist der Standardstatuszustand, der
durch TRST- oder durch den JTAG-Zustand TLR ausgewählt wird.
Die zwei LSBs werden mit einem festen Muster (0, 1) pro Abschnitt
6.1.1 der Spezifikation IEEE 1149.1 geladen. Dieses feste Muster
wird von MTAP-Zustandsmerkern abgeleitet, die während der Strap-Betriebsart in das
richtige Muster gezwungen werden.
-
34B veranschaulicht das
JTAG-IR bei ausgewähltem
Haltstatus. Die hier veranschaulichten Statusbits werden während der
Haltebetriebsartemulation allgemein genutzt. Sämtliche Statusbits mit Ausnahme von
ABP_DET und SWBP_DEC (CPU-Domäne)
werden vom MTAP geliefert. Die Statusbits des MTAP 305 sind
in Tabelle 45 definiert. Die Haltebetriebsartemulationsstatusbits
sind in Tabelle 68 definiert.
-
34C veranschaulicht das
JTAG-IR bei ausgewähltem
Echtzeitstatus. Die hier veranschaulichten Statusbits werden allgemein
während
der Echtzeitbetriebsartemulation genutzt. Sämtliche Statusbits mit Ausnahme
von MSGFLG und MSGSW (CPU-Domäne)
werden vom MTAP 305 geliefert. Die Statusbits des MTAP 305 sind
in Tabelle 44 definiert. Die Echtzeitbetriebsart-CPU-Domänen-Emulationsstatusbits
sind in Tabelle 69 definiert.
-
34D veranschaulicht das
JTAG-IR bei ausgewähltem
Emulationsfehlerstatus. Die hier veranschaulichten Statusbits werden
allgemein während
der Emulationsfehlerverarbeitung sowohl für Halt- als auch für Echtzeitbetriebsarten
genutzt. Sämtliche
Statusbits mit Ausnahme von MINT_EN und AINT_EN (CPU-Domäne) werden
vom MTAP 305 geliefert. Die Statusbits des MTAP 305 sind
in Tabelle 44 definiert. Die MINT_EN- und AINT_EN-CPU-Domänen-Emulationsfehlerstatusbits
sind in Tabelle 69 definiert.
-
Tabelle
45 definiert die Statusbits, die innerhalb des MTAP-Moduls 305 erzeugt
werden. Wegen der Definition der von dem MTAP 305 nach
außen
gelieferten Statusbits siehe die Tabellen 68–71.
-
-
-
-
Tabelle
45 definiert einen Satz von JTAG-Befehlen, die von dem MTAP 305 unterstützt werden.
Die JTAG-Befehle in dem MTAP 305 können in die Standard-JTAG-Befehle,
die von der Spezifikation IEEE 1149.1 gefordert werden (öffentliche
Befehle), und in private Befehle, die für die Emulation und für den Test
hinzugefügt
worden sind, aufgeteilt werden. Private JTAG-Opcodes besitzen drei
Gundfunktionen:
- 1) Auswahl des Scan-Pfads für den JTAG-Zustand
SHIFT_DR und für
die Steuerlogik, die in Verbindung mit den JTAG-Zuständen CAPTURE_DR
und UPDATE DR verwendet werden.
- 2) Bestimmung der Anordnung privater Anweisungen, die erzeugt
werden, wenn private Opcodes in dem JTAG-IR sind und die JTAG-Zustandsmaschine
in dem JTAG-Zustand IDLE übergeht.
- 3) Unterstützung
von ATPG-Tests mit Opcodes durch eine direkte Abbildung der JTAG-Zustände auf MPSD-Codes,
wenn die Vorrichtungsbetriebsart Test ist.
-
Private
Anweisungen sind Aktionen, die in der JTAG-Umgebung dadurch begonnen
werden, dass entweder von UPDATE_IR oder von UPDATE_DR in den JTAG-Zustand
IDLE eingetreten wird. Die Anweisungsinitiierung ist mit dem Funktionstakt
(UCLK) synchronisiert und führt
zu einen Funktionstakt breiten Befehlen für die Funktionslogik im MTAP 305 und
in den DTPs. Ferner verhindert die Initiierung einer privaten Anweisung
weitere Aktualisierungen des JTAG-IR, bis der Befehl ausgegeben worden
ist. Der Abschluss einer privaten Anweisung kann durch Erfassung
des IRBUSY (Befehlsregister-belegt-Merker) in dem JTAG-Zustand CAPTURE_IR
bestimmt werden.
-
Von
dem MTAP 305 werden die in Tabelle 46 beschriebenen JTAG-Befehle
unterstützt.
Sie sind in öffentliche
und private Gruppen aufgeteilt. Die benötigten Opcodes (öffentlich)
sind wie in der Diskussion bezeichnet. Irgendein nicht als benötigt bezeichneter
Opcode ist ein privater Opcode. Außer einer kurzen Beschreibung
der Anweisung, die mit diesem Opcode begonnen werden kann, enthält die Beschreibung
der privaten Gruppe das von dem Opcode ausgewählte Datenregister. Die Testbetriebsartverwendung
der Opcodes wird später,
insbesondere anhand der Tabelle 63 und 65, diskutiert.
-
Tabelle
46. CODEBESCHREIBUNG
-
-
ANMERKUNG:
Der MTAP 305 stellt zusätzliche
Beschränkungen
an die durch die Opcodes 0×20–0×23, 0×30, 0×32 und
0×24 ausgewählten Scan-Pfade
(siehe die späteren
Abschnitte hinsichtlich "MTAP-Codezustandsmaschine" und "MTAP-MPSD-Codegenerator"). Scan-Pfade, die
nicht explizit identifiziert sind, wählen den Umgehungspfad aus
und sind zur zukünftigen
Verwendung reserviert.
-
Wieder
anhand von 33 ist der
Umgehungspfad 451 ein Ein-Bit-Datenpfad, der ausgewählt wird, wenn
kein anderer Datenpfad über
das JTAG-Befehlsregister spezifisch ausgewählt ist. Der Umgehungspfad erfasst
immer eine logische Eins in dem Zustand CAPTURE_DR.
-
MTAP-Unterstützung von
JTAG-MPSD-DTPs.
-
35 ist ein Blockschaltplan
des MTAP 305, der eine JTAG-MPSD-Schnittstelle besitzt.
Der MTAP 305 schafft einen externen Zugriff auf und eine
Steuerung der Domänentestports
(DTPs). Der MTAP 305 wird als eine Schnittstelle zwischen
der JTAG- und der MPSD-Scan-Technologie genutzt. Er profitiert von
der Nutzung des JTAG-Protokolls als ein Kommunikationsmedium zusätzlich zu
seiner Verwendung bei der Boundary-Scan-Kontrolle. Der MTAP 305 ermöglicht einen
Zugriff auf Test- und Emulationssystembetriebsmittel. Der MTAP-Block 305 führt die
folgenden Funktionen aus: Testunterstützung, Scan-Unterstützung und
Ausführungsunterstützung.
-
Die
Testunterstützung
ermöglicht
eine Platinenanwendung von ATPG-Testmustern über die direkte Umsetzung des
JTAG-TAP-Zustands in DTP-MPSD-Codes
und die Ersetzung von TCLK für
UCLK. Außerdem wird über eine
direkte MPSD-Betriebsart das Chiptesteranlegen von ATPG-Testmustern
unterstützt.
Die Scan-Unterstützung
umfasst das Management des Umschaltens und des Anlegens der an jede
Domäne
gelieferten Takte, um sicherzustellen, dass in den Scan-Betriebsarten
Testtakte geliefert werden, und die Erzeugung von DTP-MPSD-Scan-Code vom JTAG-Schiebedatenzustand
(SHIFT_DR) und die Pfadauswahl in dem JTAG-Befehlsregister. Die
Ausführungsunterstützung umfasst
das Management des Umschaltens und Anlegens der Takte, die an jede
Domäne
geliefert werden, um sicherzustellen, dass in den Ausführungsbetriebsarten
Funktionstakte zugeführt
werden, und die Erzeugung von MPSD-Codefolgen, die über die
DTPs die Ausführungsbetriebsarten
der Domänen
steuern.
-
Die
Folgen der gescannten Informationen, gekoppelt mit den JTAG-Zustandsdiagrammübergängen, lenken
die von dem MTAP 305 geschaffene Funktionalität. Ein MTAP-Untersystem,
das die Codezustandsmaschine (CSM) genannt wird, erzeugt die MPSD-Ausführungscodefolgen,
die zum Steuern der einzelnen Domänen verwendet werden. Da die
JTAG-Logik durch den Testtakt (TCLK) angesteuert wird, während die
Funktionslogik durch den Universaltakt (UCLK) angesteuert wird,
kann der MTAP 305 die Taktung jeder Domäne steuern.
-
Weiter
anhand von 35 enthält der Megamodul-Testzugriffsport
(MTAP) 305 einen JTAG-TAP 500 (der in der JTAG-Spezifikation
1149.1 spezifiziert ist), eine JTAG-Datenpfad-Steuerlogik 510,
das Emulationssteuerregister (ECR) 520, die Codezustandsmaschine
(CSM) 530, die Startsteuerung 540, eine Befehlsdecodierung 550,
eine Befehlssteuerung 560 und den MPSD-Codegenerator 570.
-
Weiter
anhand von 35 kann
der MTAP 305 zwischen den JTAG- und DTP-Steuerblöcken verteilt sein.
Der JTAG-Block enthält
den JTAG-TAP 500, das JTAG-IR 580 und die Datenpfadsteuerung 510.
Dieser Block decodiert die JTAG-Aktivität an den Vorrichtungsanschlussstiften,
empfängt
Befehle und ordnet sie als Scan-Pfad-Steuerunterscheidung an oder
liefert sie als Befehlsunterscheidungen an den DTP-Block. Anweisungsanforderungen
werden von dem JTAG-Block an den DTP-Block übergeben, wo sie verarbeitet
und in dem richtigen Funktionslogikblock angeordnet werden. Der
DTP-Steuerblock enthält
eine Startsteuerung 540, eine Befehlssteuerung 560,
ein Emulationssteuerregister 520, eine MPSD-Codezustandsmaschine 530 und MPSD-Codegeneratorabschnitte 570.
-
Der
JTAG-TAP 500 enthält
eine Zustandsmaschine, die die durch die Anschlussstifte TCLK, TRST- und
TMS gerichtete JTAG-Zustandsaktivität verfolgt. Diese Zustandsmaschine
erzeugt sämtliche
Steuersignale, die zum Erfassen, Verschieben und Aktualisieren sowohl
der Befehlsregister- als auch der Datenregister-Scan-Pfade verwendet
werden. Daraufhin verwendet der Datensteuerpfad 510 den
TAP und die Informationen des Befehlsregisters 580, um
die Scan-Steuerung für
die JTAG-Scan-Pfade zu erzeugen.
-
Weiter
anhand von 35 werden
die MPSD-Codezustandsmaschine (MPSD-CSM) 530 und das Emulationssteuerregister
(ECR) 520 zusammen verwendet, um von dem MPSD-Codegenerator 570 und
von den DTP-Steuertakten MPSD-Ausführungscodefolgen zu erzeugen.
Die Anweisungen vom Anweisungssteuerblock 560 initiieren
die Operationen der CSM 530. Wenn die CSM 530 durch
eine Anweisung angewiesen wird, wählt sie einen der zwei programmierbaren
Werte CO und Ce von dem ECR 520 aus und legt ihn an. Die Anlegefolge
der zwei vorgeladenen Codewerte wird außerdem durch Bits in dem ECR 520 spezifiziert.
Diese Anlegefolge ist programmierbar und kann von Prozessoraktionen
abhängig
gemacht werden. Der Betrieb der CSM 530 wird ausführlicher
in einem folgenden Abschnitt behandelt. Außerdem unterstützt das
ECR 520 die Vorrichtungsbetriebsartauswahl und verschiedene
Testfunktionen, die in dem nächsten
Abschnitt behandelt werden.
-
Der
Codegenerator 570 nimmt Eingaben von den ECR-Betriebsartbits,
von den TAP-Zuständen,
von der Decodierung des DTP-JTAG-IR-Steuer-Opcodes und von der MPSD-Codezustandsmaschine
und bildet die an die DTPs gelieferten MPSD-Codes.
-
36 veranschaulicht das
MTAP-Emulationssteuerregister 520. Das Emulationssteuerregister (ECR) 520 ist
ein privater Scan-Pfad 452 (33)
in dem MTAP 305. Es wird durch einen in dem JTAG-Befehlsregister
angeordneten SECR-Opcode spezifiziert. Das ECR ist als ein Schieberegister
und, obgleich nicht alle Bits Schattenbits sind, als ein Schattenregister
implementiert. Die Emulationssteuerregisterfelder sind in Tabelle
47 beschrieben.
-
Tabelle
47. Vorrichtungsbetriebsartfeld
-
-
Tabelle
48. Vorrichtungsbetriebsartfeld
-
Tabelle
49 definiert anhand des MCS-Bits und der Vorrichtungsbetriebsartfeldbits
die Taktauswahltabelle.
-
Tabelle
49. Taktauswahltabelle
-
Tabelle
50. MPSD-EXE-Code
-
Tabelle
51. Fernereignisfeld
-
Tabelle
52. DTP-Verriegelungsfeld
-
Tabelle
53. Statusauswahlfeld
-
Tabelle
54. Emulationskonfigurationscodes
-
- hochimpedant HI-Z
- offener Kollektor OC
- Totempfahl TP
-
-
-
ANMERKUNG:
Sämtliche
Signale, die EMU0OUT und EMU1OUT ansteuern, sindtief aktive Versionen der
spezifizierten Signale. Das Signal MTAP_BORROW ist ein einen Takt
breiter Impuls und wird in einem späteren Abschnitt definiert.
-
Falls
der EMUC-Code anhand von Tabelle 54 für eines oder für beide
EMUOE-Signale den HI-Z-Zustand auswählt, werden die richtigen EMUOE-Signale
dauerhaft tief angesteuert, was den EMUO-Treiber in dem HI-Z-Zustand
hält. Falls
der Code für
einen oder für
beide Anschlussstifte einen Zustand mit offenem Kollektor auswählt, steuert
das zum Ansteuern von EMUO ausgewählte Signal ebenfalls den Zustand
von EMUOE. Falls an EMUO ein Falsch-Zustand auftritt, wird EMUOE
auf tief umgeschaltet, was den EMUO-Ausgangstreiber auf seinen HI-Z-Zustand
zwingt. Falls an EMUO eine Wahr-Bedingung auftritt, wird EMUOE auf hoch
umgeschaltet, was bewirkt, dass der EMUn-Anschlussstifttreiber von
einer HI-Z-Ausgabe in den Ansteuerzustand übergeht. Die Ausführung der
JTAG-Befehle IF_CLRO oder IF_CLR1 verhindert die Signale, die EMUO0
und EMUO1 ansteuern, bis die Signale in ihren inaktiven Zustand
zurückkehren.
TRST- bewirkt, dass die EMUC-Bits mit Nullen geladen werden.
-
Die
EMUC-Konfigurationscodebits sind als Schattenbits des ECR implementiert.
Die Konfigurationsbits werden aktualisiert, wenn der JTAG-TAP über dem
Zustand IDLE übergeht.
Dies ermöglicht,
dass die neue Ereignisauswahl mit UCLK synchronisiert wird und beseitigt
somit die Möglichkeit
einer Störung
der Signale EMUO.
-
Falls
die Vorrichtungsbetriebsartbits auf STRAP gesetzt sind, werden die
EMU-Konfigurationscodes durch die CPU EMUC-Bits des ACR wie in einem
früheren
Abschnitt definiert ausgewählt.
Das Feld EMUC wird durch TRST- und durch den JTAG-Zustand TLR auf
0000 initialisiert.
-
Die
Vorrichtungsbetriebsartfelder und das MCS-Bit sind mit Schattenbits
implementiert, die während des
JTAG-Zustands UPDATE-DR geladen werden, während die MPSD-Code- und Fernereignisfelder
keine Schattenfelder sind und physikalisch innerhalb der Emulationssteuerschieberegisterbits
liegen. Bezugnahmen auf das ECR beziehen sich auf die Schatten-
und Nicht-Schattenbits, die die Funktionsinformationen einer anderen
Logik zuführen.
-
Da
es beim Ändern
der Vorrichtungsbetriebsarten oder des MCS-Bits keine Synchronisierung
gibt, muss die Software sicherstellen, dass sämtliche Testports beim Umschalten
der Betriebsarten oder des MCS-Bits entriegelt sind und PAUS angelegt
ist oder der momentan ausgewählte
Takt gesperrt (abgeschaltet) ist, um zu vermeiden, dass durch Störungen ein
ungültiger
Zustand verursacht wird.
-
Die
Mischung der Schatten- und Nicht-Schattenbits im ECR 520 ergibt
sich aus der Verwendung der MPSD-Code und -Fernereignisfelder mit
einer Logik, die an dem Funktionstakt (UCLK) läuft. Diese Felder werden direkt
an die Logik oder Register angelegt, die mit UCLK bewertet werden.
Die in Bezug auf den Testtakt (TCLK) aktualisierten Schieberegisterbits ändern sich
asynchron in Bezug auf UCLK, wobei sie in der von UCLK gesteuerten
Logik fehlerhafte Ergebnisse erzeugen. Das Synchronisierungsproblem
wird dadurch behandelt, dass die Verwendung der ECR-Daten durch
die von UCLK gesteuerte Logik verhindert wird, während das ECR-Schieberegister
gescannt wird. Die Verhinderung besitzt die Wirkung, dass unter
Verwendung der Nicht-Schattenschieberegisterbits der Zustand der
Funktionslogik eingefroren oder verriegelt wird, wobei sie durch
die Verwendung einer Funktionsanweisung durch Emulationssoftware
erzeugt wird. Dieser Verhinderungsprozess ist eine alternative Form
der synchronisierten Schattierung, die sicherstellt, dass die Funktionslogik
unter Verwendung von durch den Testtakt (TCLK) gescannten Informationen
die Erscheinung gibt, zu allen Zeiten statisch zu sein. Der Verriegelungsprozess
ist Teil der MPSD-Codezustandsmaschine und wird in einem späteren Abschnitt
diskutiert, der die MTAP-Codezustandsmaschine beschreibt.
-
Selbst
dann, wenn die Host-Software lediglich den ECR-Zustand prüft, kann
das ECR 520 nicht gescannt werden, ohne dass die Software
zunächst
die CSM verriegelt.
-
MTAP-Startsteuerung
und -Befehlssteuerung
-
Wieder
anhand von 35 nimmt
die MTAP-Startsteuerlogik 540 Befehlsrichtlinien von dem JTAG-Abschnitt
des MTAP 305 an, synchronisiert sie die Richtlinie und
ordnet sie den Befehl daraufhin mit Hilfe der MTAP-Befehlssteuerung 560 für die MPSD-Codezustandsmaschine 530 und
für die
gegenüber
dem MTAP 305 externen Logikblöcke an. Ein Domänenbefehl
wird nur dann in dem JTAG-Abschnitt begonnen, wenn das JTAG-IR 580 einen
Opcode im Bereich von 0×20-0×2F enthält und der
TAP entweder von UPDATE_IR oder von UP-DATE_DR in den Zustand IDLE übergeht.
-
Die
Domänenanweisungsanforderung
wird an die MTAP-Startsteuerlogik 540 übertragen, wo eine Zustandsmaschine
ein zu TCLK synchrones Signal IRBUSY erzeugt, das weitere JTAG-Befehlsregisteraktualisierungen
verhindert. Tabelle 55 ist eine Folge von Ereignissen, die die Erzeugung
eines Startimpulses für
die zu erzeugende Anweisung ermöglichen.
START_REQT und IRBUSY werden durch den TAP-Testlogikrücksetzzustand
(TAP-Zustand TLR) zurückgesetzt,
während
START_REQ1 und START_REQ2 durch IRBUSY tief zurückgesetzt werden.
-
Tabelle
55. Startimpulserzeugung
-
Immer
noch anhand von 36 verhindert
das Signal SWINPROG die Erzeugung von START, falls der JTAG-Opcode
0×20–0×23, 0×30, 0×32 oder
0×24 ist
(wobei sämtliche
Anweisungen auf die Auswahl eines Domänen-Scan-Pfads oder des ECR
gerichtet sind).
-
Tabelle
56 zeigt eine Wahrheitstabelle für
die START-Erzeugungszustandsmaschine.
-
Tabelle
56. Starterzeugungszustandsmaschine
-
Der
Anweisungserzeugungsprozess erfordert, dass die Emulationssoftware
dafür verantwortlich
ist, dass eine zweite Anweisung erst ausgegeben wird, wenn die erste
abgeschlossen ist. Das über
die JTAG-IR-Erfassungsinformationen sichtbare IRBUSY-SRL ermöglicht,
dass der Belegt-Anzeiger durch Emulationssoftware in demselben Befehlsregister-Scan
untersucht wird, der die nächste
Anweisung lädt.
Da der Erfassungszustand vor dem Aktualisierungszustand auftritt,
stellt die Erfassung einer logischen Null des IRBUSY-Merkers in
einem Anweisungsladevorgang für
die Emulationssoftware sicher, dass die Befehlsregisteraktualisierung
bestimmt stattfindet. Anweisungen, die in das Befehlsregister ge scannt
werden, sollten in dem Zustand PAUSE IR enden, was ermöglicht,
dass die Emulationssoftware entscheidet, ob die Fortpflanzung in den
JTAG-Zustand IDLE gewährleistet
ist. Bestimmte Ereignisse, die sich aus der Erzeugung der Startimpulse ergeben,
können
in der Weise programmiert werden, dass sie an den Emulationsanschlussstiften
als Unterbrechungen gesehen werden. Diese Unterbrechungen können in
einigen Fällen
von der Emulationssoftware anstelle des Abfragens des Befehlsregisters
verwendet werden. Die Bestimmung der Anwendbarkeit der Unterbrechung
ist dem Ermessen des Programmierers überlassen.
-
Falls
die JTAG-Zustandsmaschine mit der in das JTAG-IR 520 geladenen
SGABORT-Anweisung in den Zustand IDLE angesteuert wird oder wenn
die JTAG-Zustandsmaschine in den Zustand TEST-LOGIC_RESET angesteuert
wird, ist der Startgenerator auf seinen Löschzustand gerichtet. Die SGABORT-Anweisung überschreibt
das IRBUSY und ermöglicht,
dass die Anweisung in das JTAG-IR geladen wird.
-
Weiter
anhand von 35 erzeugt
der Anweisungs-Controller 560 sämtliche Befehlsübernahmen
für die
CSM 530 und die Domänen.
Der Zustand des Verriegelungsbits kann beeinflussen, welche Domänen eine Anweisung
wie etwa SDAT_HALT empfangen. START ist ein einen Takt breiter Impuls,
der durch die JTAG-START-Steuerlogik erzeugt wird, wenn ein Befehl
von der JTAG-Schnittstelle begonnen worden ist. START wird an die
Befehlssteuerung gesendet, um an sein Ziel gelenkt zu werden. Die
Befehlssteuerlogik kombiniert den START-Impuls mit dem JTAG-IR-Wert,
um eine spezifische Anweisung zu bilden. Diese spezifischen Anweisungen
werden entweder an die MPSD-Codezustandsmaschine 530 in
dem MTAP 305 oder an eine Domäne außerhalb des MTAP 305 gesendet.
Die Anweisungen sind in Tabelle 57 aufgeführt.
-
Tabelle
57. Anweisungssteueranweisungen
-
MTAP-Codezustandsmaschine
-
Weiter
anhand von 35 steuert
die MPSD-Codezustandsmaschine (MPSD-CSM) 530 das Anlegen der MPSD-Codes
von den EXE- und TERM-Registerfeldern des ECR 520 an den
MPSD-Codegenerator 570 (der den MPSD-Bus ansteuert). Außerdem führt sie
das Management der Taktumschaltungen aus, die erforderlich sind,
um in der Emulationsbetriebsart zu scannen (TCLK) und auszuführen (UCLK).
-
Die
CSM 530 ist in allen Betriebsarten mit Ausnahme der ATPG-Betriebsart
betriebsbereit. In der Emulationsbetriebsart wird die CSM verwendet,
um programmierbare MPSD-Ausführungscodefolgen
für den MPSD-Codegenerator
zu erzeugen. Die Ausführungscodefolgen
sind als FUNC, CNTL, HALT und PAUS definiert. Die Emulationssoftware
muss die CSM anweisen, dass sie an den Codegenerator einen PAUS-Code anlegt,
bevor ein Scan der DIP-Daten oder der Steuerpfade versucht wird.
Die CSM verwendet den Ausführungscode,
um die Domänentaktauswahl
zu bestimmen. Das Anlegen des Codes FUNC, CNTL oder HALT erfordert,
dass UCLK an die Domänen
angelegt ist, während
der Code PAUS angelegt werden kann, wenn entweder UCLK oder TCLK
angelegt ist. Der Übergang
von einem FUNC-, CNTL- oder HALT-Code zu einem PAUS bewirkt ein
Taktumschalten von UCLK zu TCLK, während eine Anforderung zum Übergang
von PAUS zu FUNC, CNTL oder HALT ein Taktumschalten von TCLK zu
UCLK bewirkt. Alle Taktumschaltungen finden statt, während ein
PAUS-Code an entriegelte Domänen
angelegt ist.
-
37 ist ein Blockschaltplan
der CSM 530. Die Codezustandsmaschine kann in einen MPSD-Code-Controller-Abschnitt 600,
einen Code-Registerabschnitt 610 und einen Taktumschalterabschnitt 620 zerlegt werden.
Der Code-Registerabschnitt enthält
ein Zwei-Bit-Code-Register, ein Taktauswahlbit und einen Codemultiplexer.
Der Taktumschalter enthält
einen Öffnen-vor-Schließen-Synchronisierungstaktumschalter
mit einem Schalten-im-Gang-Indikator. Der Code-Controller enthält zwei
Zustandsmaschinen-SRLs und die gesamte kombinatorische Logik zur
Anpassung an MTAP-Anweisungen und REVT-Betriebsarten, die in dem
ECR spezifiziert werden. Außerdem
erzeugt die Zustandsmaschine Multiplexersteuerungen zur Auswahl
des EXE-Codes 611 und des TERM-Codes 612 in das
Code-Register und zum Laden des Taktauswahlbits (TCLKON 613).
-
Die
Codequelle für
das Code-Register 610 wird durch den Code-Controller 600 bestimmt.
Normalerweise ist das Code-Register in Abwesenheit einer anderen
Richtlinie zu sich selbst zurückgekoppelt.
Dies ermöglicht,
dass der Code-Controller während
einer Zeitdauer eines Takts das EXE- oder das TERM-Code-Feld von
dem ECR auswählt.
Das einen Takt breite Auswahlfenster ermöglicht, dass ein neuer Code
in das Code-Register eingegeben wird, wonach der Code umläuft. Dieses
Schema ermöglicht,
dass der Code-Controller Anweisungen direkt von der MTAP-Anweisungssteuerung 560 an
die Multiplexersteuerung in dem Code-Registerblock übergibt.
Die Signale CSEL(3:0) 614 steuern die Muxe an dem Code-Register.
-
Falls
der nächste
durch die CSM an den Codegenerator anzulegende Code ein Laufcode
(CNTL oder FUNC) ist und der aktuelle Code PAUS ist, erzwingt die
CSM für
einen Taktzyklus den HALT-Code, bevor der Laufcode angewendet wird.
Der Grund dafür
ist zu ermöglichen,
dass die Domänen
ihre Busse einen Takt vorzeitig freigeben, da die Busse für den HALT-Code
freigegeben werden (DBENB).
-
Nach
dem Auflösen
der Priorität
aller Anforderungen leitet der Code-Controller 600 die
Multiplexerauswahlen ab. Die Priorität ist zunächst Taktumschaltanforderungen,
zweitens MTAP-Anweisungen und drittens Fernereignisanforderungen.
Taktumschaltanforderungen haben gegenüber MTAP-Anweisungen Priorität, indem
die MTAP-START-Steuerung verhindert wird, während das Taktumschalten im
Gang ist (SWINPROG wahr ist), und indem in dem JTAG-IR ein CSM-Befehl
spezifiziert wird. Falls gleichzeitig mit einer Fernereignisanweisung
eine MTAP-Anweisung auftritt, wird die Ereignisanweisung ignoriert.
Irgendeine MTAP-Anweisung oder ein fernes Ereignis können ein
Taktumschalten in einer von beiden Richtungen anfordern. Die erforderliche
Taktpolarität
ist in den MPSD-Code eingebettet, wobei PAUS das Anlegen von TCLK
an alle entriegelte Domänen
anfordert, während
HALT, CNTL und FUNC das Anlegen von UCLK anfordern.
-
Wenn
eine Codeladeanforderung erfasst wird, bestimmt der Code-Controller,
welcher von drei Typen von Ladevorgängen stattfindet. Sie sind
ein Codeladevorgang ohne Taktumschalten, ein Umschalten von UCLK
auf TCLK oder ein Umschalten von TCLK auf UCLK. Der Code-Controller
behandelt jeden dieser Fälle anders.
Kein Schalten wird erfasst, wenn eines der folgenden beiden Dinge
auftritt:
- 1) Der momentane Code ist PAUS und
der zu ladende Code ist PAUS oder
- 2) der momentane Code ist nicht PAUS und der angeforderte Code
ist nicht PAUS.
-
Falls
der momentane Code HALT, CNTL oder FUNC ist und der angeforderte
Code PAUS ist, wird ein UCLK-TCLK-Umschalten erfasst. Falls der
momentane Code PAUS und der angeforderte Code HALT, CNTL oder FUNC
ist, wird ein TCLK-UCLK-Taktumschalten erfasst. Die unterschiedliche
Verarbeitung der Typen stellt sicher, dass alle Taktumschaltungen
stattfinden, während
der MPSD-PAUS-Code
an die Domänen
angelegt wird.
-
Wenn
kein Taktumschalten erforderlich ist, wählt der Code-Controller 600 das
zu ladende ECR-Feld aus und bestimmt er den nächsten CSM-Zustand. Das Code-Register 610 wird
zusammen mit dem Taktauswahlbit und dem CSM-Zustand im nächsten Takt
geladen.
-
Wenn
angefordert wird, einen Code PAUS in das Code-Register zu laden,
während
der momentane Wert ein HALT, CNTL oder FUNC ist, wählt der
Code-Controller
das zu ladende ECR-Feld aus und bestimmt er den nächsten CSM-Zustand.
Im nächsten
Zustand wird in das Code-Register PAUS geladen und wird in das TCLKON-Bit
eine Eins geladen. Der Taktumschalter, der TCLKON mit TCLK_SEL (Testtaktauswahl)
vergleicht, bestimmt, dass eine Taktumschaltung angefordert ist,
wobei SWINPROG (Umschalten im Gang) aktiv wird. Nachdem das Taktumschalten
abgeschlossen ist, wird SWINPROG wieder inaktiv, wobei der Code-Controller
und die MTAP-START-Steuerung fortfahren können.
-
Eine
Anforderung, die ein Umschalten von TCLK auf UCLK erfordert, erfährt eine
Spezialverarbeitung durch den Code-Controller 600, da er
den momentanen PAUS-Code halten muss, während die Takte umgeschaltet
werden, woraufhin der Code installiert wird, der bewirkte, dass
das Umschalten auftritt. In diesem Fall lädt der Code-Controller den
angeforderten Taktzustand bei TCLKON, aktualisiert er den CSM-Zustand
und verhindert er das Laden des Code-Registers 610.
-
Das
TCLKON 613 fordert an, dass der Taktumschalter 620 das
Taktumschalten auf funktionsfähig
erzeugt. Der aktualisierte Zustand der CSM 530 zeigt auf
den Code, der geladen werden muss, wenn die Taktumschaltung abgeschlossen
ist. Da TCLKON einen PAUS-Code darstellt, kann es mit den Inhalten
des Code-Registers 610 verglichen
werden, um zu sehen, ob die Taktauswahl und der Codewert übereinstimmen. Wenn
TCLKON eine Null ist und das Code-Register ein PAUS enthält, ist
ein verzögerter
Code-Register-Ladevorgang anstehend. Das TCLKON 613 wird
immer direkt zum Taktumschalter 620 gesendet, wobei, falls
erforderlich, eine Taktumschaltfolge begonnen wird. Dies stellt
sicher, dass der Takt umgeschaltet wird, während an die Domänen ein
PAUS-Code angelegt wird. Falls TCLKON nicht mit dem Ausgang des
Taktumschalters oder mit PAUS_NOW 615, der Decodierung
des Pause-Codes in dem Code-Register, übereinstimmt, wird von dem
Taktumschalter ein Umschalten-im-Gang (SWINPROG) 621 erzeugt.
Wenn ein Taktumschalten von TCLK auf UCLK abgeschlossen ist, erzeugt
der Umschalter ein Signal LD_CODE für den Code-Controller. Der Code-Controller
kombiniert das Signal LD_CODE mit dem momentanen CSM-Zustand, um
anzufordern, dass entweder das EXE- oder das TERM-Code-Feld in das
Code-Register geladen wird. Wenn das JTAG-IR 0×20–0×23, 0×30, 0×32 oder 0×24 enthält, verhindert das SWINPROG
in der START-Steuerung des MTAP 305 die START-Erzeugung.
-
38 ist ein Prinzipschaltbild
der MTAP-CSM-Taktumschaltschaltung 620, d. h. einer Öffnen-vor-Schließen-Umschaltschaltung.
In Tabelle 58 ist eine HALT-PAUS-Wahrheitstabelle veranschaulicht, während in
Tabelle 59 eine PAUS-HALT-Wahrheitstabelle gezeigt ist.
-
Tabelle
58. HALT-PAUS-Codeübergang
-
Tabelle
59. PAUS-HALT-Codeübergang
-
Es
werden nun Spezial-CSM-Betrachtungen bei ECR-Scans angemerkt. Da
die CSM 530 die Felder ECR 520 als statische Eingaben
verwendet, kann das ECR nur verwendet werden, während das CSM in dem Zustand
LOCKED ist. Der Code-Controller 600 codiert die drei jeweils
durch das Signal 601, 602 und 603 angegebenen
Codemanagementzustände
EXECUTE, TERMINATE und LO CKED in die zwei Zustandsregisterbits.
Die Zustände
EXECUTE und TERMINATE widerspiegeln die Quelle des momentanen Codes
in dem Code-Register. Diese zwei Zustände können jederzeit über MTAP-Anweisungen
angewiesen werden. Das Fernereignisfeld kann einen dieser beiden
Zustände
anweisen, wenn der CSM-Zustand nicht in dem Zustand LOCKED ist.
Der Zustand LOCKED wird durch die MTAP-Anweisung angewiesen und
kann nicht durch das Fernereignisfeld des ECR angewiesen werden.
Wegen Anweisungsinformationen siehe Tabelle 57. Die Zustandscodierung
ist in Tabelle 60 gezeigt.
-
Tabelle
60. CSM-Codierung
-
ANMERKUNG:
Es wird angemerkt, dass der oben gezeigte Zustand, bei dem sowohl
CSM_LOCK als auch CSM_EXE gesetzt sind, möglicherweise nie existiert,
wenn er aber existiert, das CSM_LOCK das CSM_EXE überschreibt.
In den verriegelten Zustand sollte eingetreten werden, bevor ein
Scan-ECR versucht wird, betreffs des SECR-Befehls siehe Tabelle
46.
-
MTAP-MPSD-Codegenerator
-
Wieder
anhand von 35 sind
die den Domänen
zugeführten
MPSD-Codes in den MPSD-Codegenerator 570 integriert. Der
Codegenerator 570 steuert den MPSD-Bus entweder von einem
der DTP-Daten- und DTP-Steuer-Scan-Zustände oder von den Ausgaben der
MPSD-Codezustandsmaschine (MPSD-CSM) an, indem er den JTAG-TAP-Controller-Zustand
direkt auf die MPSD-Codes abbildet oder indem er den MPSD-Strap-Zustand
(normale Betriebsart) auf den Bus zwingt.
-
Die
Erzeugung der Codes durch den Codegenerator 570 besitzt
eine Hierarchie, die sicherstellt, dass die Vorrichtung in dem JTAG-Testlogik-Rücksetzzustand
(TLR) funktionsfähig
ist. Diese Hierarchie ermöglicht auch,
dass der MTAP 305 mit Emulationssoftware initialisiert
wird, während
sämtliche
Domänen
einen MPSD-Funktionslaufcode (FUNC) zusammen mit einer Funktionstaktauswahl
empfangen. Der von dem MPSD-Codegenerator entwickelte Codewert ist
das logische ODER der Eingaben von mehreren Quellen. Es liegt in
der Verantwortung der Emulationssoftware, kompatible Codequellen
anzulegen, um die gewünschte Codeausgabe
zu erzielen.
-
Der
MPSD-Codegenerator 570 führt ein logisches ODER der
Codeeingaben von der Codezustandsmaschine 530, von der
Strap-Betriebsart, von den Scan-DTP-Daten,
von der Scan-DTP-Steuerung und von der ATPG-Betriebsart aus. Wenn
beide Vorrichtungsbetriebsartbits in dem ECR 520 gesetzt
sind, ist STRAP aktiv. Das STRAP ist mit C1, C0 und Ce ODER-verknüpft, wobei
es sie in den Logikzustand eins zwingt und den MPSD-Code von FUNC
erzeugt. Dies ermöglicht,
dass weitere Codequellen mit Emulationssoftware initialisiert werden,
bevor das Signal STRAP mit Software zurückgesetzt wird. STRAP maskiert
sämtliche
anderen Eingaben in die Codeerzeugungslogik. Die Vorrichtungsbetriebsartbits
werden durch eine logische Null an TRST-, durch den JTAG-TAP-Übergang
in den Testlogikrücksetz-Zustand
(Zustand TLR) oder durch Programmieren der ECR-Betriebsartbits durch
einen ECR-Scan auf logische Einsen gesetzt.
-
Die
Quellen der Code-Erzeugung des DTP-Pfad-Scans, der MPSD-Codezustandsmaschine
und der ATPG-Betriebsartabbildung werden durch die Emulationssoftware
und durch die MPSD-Codeerzeugungshardware gegenseitig ausschließend gemacht.
Die MPSD-Ausführungscodes
von FUNC, CNTL und HALT können
nur durch die MPSD-Codezustandsmaschine oder durch die ATPG-Betriebsartabbildungslogik,
die JTAG-TAP-Zustände
direkt in MPSD-Codes umsetzt, erzeugt werden. Es ist jederzeit lediglich
eine Quelle für die
Ausführungscodes
aktiv, wobei die inaktive Quelle der Codebildungsfunktion im MPSD-Codegenerator 570 logische
Nullen zuführt.
-
Bevor
irgendwelche DTP-Datensteuer-Scans versucht werden, müssen beide
MPSD-Ausführungscodequellen
in ihre inaktiven Zustände
gebracht werden (indem dem MPSD-Codegenerator logische Nullen zugeführt werden).
Die Zustandsabbildung für
die ATPG-Betriebsart wird in der Weise gewählt, dass die Konformität mit dieser
Vorschrift sichergestellt ist. Die Emulationssoftware ist dafür verantwortlich
sicherzustellen, dass die MPSD-Codezustandsmaschinenausgaben in
den inaktiven Zustand gebracht werden (PAUS, CSM_C0 und CSM_Ce logische
Nullen), bevor MPSD-Scans versucht werden. Da bei sämtlichen Nicht-Scan-MPSD-Codes (FUNC,
CNTL, HALT und PAUS) C1 eine logische 1 ist, wird C1 als NOT SHIFT_DR OR
NOT der JTAG-Opcodes (0×20–0×23, 0×30 und
0×32)
erzeugt, während
CO als SHIFT_DR AND JTAG der Opcodes (0×22–0×23 und 0×32) erzeugt wird. Dies liefert
nur dann eine Null in C1, wenn tatsächlich die MPSD-Daten- oder
MPSD-Steuerpfade gescannt werden und befreit beide Ausführungs-Codegeneratoren
davon, C1 zu entwickeln.
-
Der
Codegenerator 570 nimmt Eingaben von den ECR-Betriebsartbits,
von den TAP-Zuständen,
von den Decodierungen der MPSD-Daten und der MPSD-Steuer-Opcodes und
von der MPSD-Codezustandsmaschine und bildet die MPSD-Codes, die
den Domänen
zugeführt
werden. Wenn die Einrichtung nicht in STRAP ist, wird C1 das Inverse
des Zustands SHIFT_DR, UND-verknüpft
mit einem JTAG-Opcode von 0×20–0×23 und
0×30 und
0×32 (Scan
der MPSD-Daten- oder
MPSD-Steuerpfade), zugewiesen. Dies macht die Erzeugung der MPSD-Scan-Codes von SDAT
und SCTL unmöglich,
wenn nicht der richtige Scan-Pfad ausgewählt ist und der Datenregister-Scan-Zustand
auftritt. Falls der MPSD-Steuerpfad ausgewählt ist (ein JTAG-Opcode von
0×20–0×23 0×30 und
0×32),
wird CO in dem JTAG-Zustand SHIFT_DR auf eins gesetzt.
-
An
das Scannen des DTP-Datenpfads wird eine zusätzliche Bedingung gestellt.
Der Zustand CAPTURE_DR tastet TCLK_SEL ab, wobei während der
Zustände
SHIFT_DR der MPSD PAUS-Code an die DTPs angelegt wird, wenn es falsch
ist. Zusätzlich
wird die Ausgabe des DTP-Daten-Scan-Pfads auf eine Null gezwungen.
Wenn TCLK_SEL falsch ist, ist der erfasste Wert von TCLK_SEL an das
erste Bit des DTP-Daten-Scan-Pfads auszugeben. Scan-Codes können nur
dann erzeugt werden, wenn die Emulationssoftware sicherstellt, dass
die Ausgaben CSM_CO und CSM_Ce der CSM eine logische Null sind.
-
Die
Tabellen 61, 62 und 63 zeigen den Beitrag
der verschiedenen Codegeneratorquellen. Tabelle 61 zeigt eine Wahrheitstabelle
für den
STRAP-Code, Tabelle 62 zeigt eine Wahrheitstabelle für den Emulationscode
und Tabelle 63 zeigt eine Wahrheitstabelle für den ATPG-Code.
-
Tabelle
61. Beiträge
des ODER-Terms zur STRAP-Codeerzeugung
-
Tabelle
62. Beiträge
des ODER-Terms zur Emulationsbetriebsart
-
ANMERKUNG:
Die CSM 530 muss in der Weise programmiert werden, dass
vor dem Scannen der MPSD-Daten oder der MPSD-Steuerung ein PAUS-Code
aktiviert wird. Für
MPSD-DATA- und Steuer-Scans, die ohne einen PAUS-Code in der CSM
auftreten, werden die Beiträge
C1 und C0 von dem JTAG-Zustandsdiagramm verhindert.
-
Tabelle
63. Beiträge
des ODER-Terms zur ATPG-Betriebsart
-
ANMERKUNG:
Der "-" in den vorausgehenden
Tabellen bezeichnet Zustände,
in denen eine Codequelle nicht zu dem Ausgangszustand der Codegeneratoren
beiträgt.
Die Behandlung von C1, C0 und Ce für die verschiedenen Betriebsarten
ist in Tabelle 64 gezeigt.
-
Tabelle
64. Behandlungen von C1, C0 und Ce
-
In
der Emulationsbetriebsart steuert der MPSD-Codegenerator (MCG) 570 das
Bit C1 des MPSD-Codes, das an den MPSD-Testportbus 306 (15) angelegt wird. Der
MCG zwingt C1 hoch, sofern nicht ein JTAG-MPSD-Daten-Scan im Gang
ist (C1 = 0). Wenn die CSM einen MPSD-Zustand PAUS ausgibt, bildet
der MCG die JTAG-TAP-Zustände
auf MPSD-Scan-Codes ab. Der JTAG-Daten-Scan-Pfad ist direkt an den MPSD-Busdaten-Scan-Pfad
gekoppelt. Daraufhin werden sämtliche
entriegelten MPSD-Testports an TCLK mit Daten gescannt, wenn der
JTAG-TAP-Zustand in den Zustand SHIFT_DR übergegangen ist. Der MPSD-Daten-
oder -Steuerpfad wird über
die JTAG-IR-Pfadauswahlen ausgewählt.
Während
des JTAG-Zustands SHIFT_DR wird der Zyklus C1 tief angesteuert,
wenn einer der Opcodes SDAT_HALT, SDAT_CNTL, SCTL_HALT oder SCTL_CNTL
vorhanden ist (0×20–0×23, 0×30 und
0×32).
CO wird auf eine Eins angesteuert, falls die Pfade SCTL_HALT oder
SCTL_CNTL (0×20–0×23 und
0×32)
ausgewählt
sind, oder wird auf null angesteuert, falls die Pfade SDAT_HALT
oder SDAT_CNTL (0×20–0×23 und
0×30)
ausgewählt
sind.
-
In
der ATPG-Betriebsart werden alle DTP-MPSD-Codes von dem JTAG-TAP-Zustandscontroller
mit Ausnahme des Lauftest/Leerlauf-Zustands direkt abgebildet. Im
Lauftest/Leerlauf wird die CSM genutzt, um MPSD-Ausführungscodezustände (CNTL
oder HALT) anzusteuern. Die CSM wird entriegelt, wobei der Zustand
EXE oder TRM (ausgewählt
durch die JTAG-IR-Anweisung) den MPSD-Bus ansteuert. Falls das JTAG-IR
im Lauftest/Leerlauf einen anderen Code als 0×20 oder 0×21 enthält, wird der vorausgehende
abgebildete Zustand (HALT oder PAUS) weiter an den MPSD-Bus angelegt.
Der vorausgehende abgebildete Zustand wird ebenfalls weiter angelegt,
falls die CSM verriegelt ist (oder entriegelt ist, aber der neue
MPSD-Code nicht an den MPSD-Bus angelegt worden ist). Wenn der Lauftest/Leerlauf-Zustand
verlassen wird, wird die CSM verriegelt, wobei der MPSD-Codegenerator
die JTAG-Zustandsabbildung nutzt, um den MPSD-Bus anzusteuern. Die
DTP-Scan-Pfade werden wie in der Emulationsbetriebsart über einen
in das IR geladenen DTP-Scan-Opcode ausgewählt. Die Abbildung der Daten-Scan-Registergruppe
der Scan-Zustände
zwingt MAP_CO und MAP_Ce in der ATPG-Betriebsart mit Ausnahme des
Zustands SHIFT_DR, bei dem die normale JTAG-MPSD-Schiebecodeumsetzung
stattfindet, auf Nullen. Falls von der ATPG-Betriebsart (von einem ECR-Scan)
in die Emulationsbetriebsart umgeschaltet wird, steuert die CSM
weiter das PAUS (den abgebildeten SHIFT_DR-Zustand) an, bis die
CSM entriegelt ist.
-
Tabelle
65 zeigt die Zustandsdecodierung sowohl für die Emulations- als auch
für die
ATPG-Betriebsart.
-
Tabelle
65. MPSD-Codegenerator – JTAG-Zustands-Abbildung
-
In
der STRAP-Betriebsart werden alle ECR-Verriegelungsbits inaktiv
angesteuert, was die Domänen zwingt,
die momentanen MPSD-Codes zu verwenden. Außerdem zwingt die MPSD-Strap-Betriebsart
den MPSD-FUNC-Code auf den MPSD-Bus 306.
-
MTAP-Domänentaktmanagement
-
Das
Domänentaktmanagement
wird durch die Vorrichtungsbetriebsart gesteuert. Die Signale UCLK_SEL
und TCLK_SEL werden durch die Betriebsartbits in den MCG 570 durchgeschaltet.
In der MPSD-Strap-Betriebsart überschreibt
der MCG den Taktumschalter, um UCLK_SEL zu erzeugen. Die ATPG-Betriebsart überschreibt
den Taktumschalter, um TCLK auszuwählen. In der Emulationsbetriebsart
werden an den Ausgängen
des Taktumschalters 620 das UCLK_SEL und das TCLK_SEL geliefert.
-
Wenn
UCLK_SEL und TCLK_SEL inaktiv sind, tasten sie die von dem DTP an
die Domäne
gelieferten Funktions- und Scan-Takte aus. Wenn der Taktumschalter 620 in
der CSM einen Zustand erfasst, der erfordert, dass der Domänentakt
von UCLK auf TCLK umgeschaltet wird, wird UCLK_SEL inaktiv angesteuert,
wobei der Master-Takt abgeschaltet wird, während die Slave-Phase hoch
ist und die Master-Phase tief ist. Der Takt-Mux des DTP stellt sicher,
dass die Slave-Phase
am Ausgang des Takt-Mux hoch bleibt, während die Auswahl beider Takte
aufgehoben wird. Wenn UCLK_SEL inaktiv ist, wird nach einer Synchronisierungsverzögerung TCLK_SEL
aktiv angesteuert, wobei TCLK (während
der Slave hoch und der Master tief ist) für den Testport freigegeben
wird. Dieser Mechanismus führt
ein Öffnen-vor-Schließen-Schalten
des Funktionstakts aus. Das Umschalten von TCLK zurück auf UCLK
funktioniert völlig
gleich. Die CSM legt den PAUS-Code an den MPSD-Bus an, bis das Taktumschalten
abgeschlos sen ist. Außerdem
wird nur der Takt von Testports umgeschaltet, die entriegelt sind.
-
Wenn
eine Domäne
in dem Prozess ist, in dem sie entriegelt wird, muss der Zustand
der Taktumschaltsignale so beschaffen sein, dass sie an den Zustand
der Takte in der Domäne,
die entriegelt wird, angepasst sind. Falls die Zustände nicht
angepasst sind, findet ein Taktumschalten ohne Synchronisierung
statt. Diese Situation wird von der Software vermieden.
-
39 ist ein Prinzipschaltbild
für die
MTAP-Ereigniserzeugungsschaltung (EVTA) 590. Die EVTA ist ein
Ereignis, das durch entriegelte Domänen freigegeben wird. Zwei
Typen von Ereignissen, d. h. MSGSW und CPU_DONE, können EVTA
erzeugen.
-
Aus 39 ist zu sehen, dass je
nach dem Zustand von CPULOCK entweder ein MSGSW oder ein CPU_DONE
das EVTA erzeugen kann, d. h., falls die CPU entriegelt ist, ist
das einzige Ereignis, das EVTA erzeugen kann, DONE. Das DONE ist
ebenfalls durch ANYSTOP geeignet, so dass kein EVTA erzeugt wird, falls
das DONE von ANYSTOP erzeugt wurde, d. h. lediglich von MPSD erzeugte
DONEs können
ein EVTA erzeugen. Der Grund dafür
ist, dass es keinen Grund gibt, EVTA zu erzeugen und somit den von
der CSM ausgegebenen Zustand und somit den Zustand des MPSD-Busses
zu ändern,
falls ANYSTOP aktiv war.
-
MTAP-Abschaltunterstützung
-
In
der Emulationsbetriebsart werden MTAP-Befehle und Scan-Taktumschaltungen
in einem aktiven Funktionstakt weitergegeben. Es ist möglich, dass
dies in der Abschaltbetriebsart nicht wahr ist. Somit wird vom MTAP 305 ein
Funktionstaktanforderungs-Signal (Signal FCLK_REQ) für das Megamodul
erzeugt, das anfordert, dass Funktionstakte freigegeben werden.
Das FCLK_REQ wird wie in Tabelle 66 definiert erzeugt.
-
Tabelle
66. FCLK_REQ-Erzeugung
-
Außerdem wird
angemerkt, dass CPU_DONE inaktiv angesteuert werden muss, wenn die CSM_CNTL
oder FUNC anlegt, falls das Megamodul in einem Abschaltzustand ist.
CPU_DONE muss aktiv angesteuert werden, wenn die CSM HALT anlegt.
-
40 veranschaulicht die
MTAP Zählerschaltungsanordnung 630,
die sich in der CSM 530 befindet. Der Zähler 631 ist ein 10-Bit-Rückwärtszähler, der
für verschiedene
Funktionen (Leistungsanalyse, Ausführungssteuerung oder Datenstrom)
konfigurierbar ist. Der Zähler 631 und
seine Steuerbits sind Schattenbits für den Scan. Der Zähler läuft an UCLK,
während
die Schattenbits an TCLK laufen. Wenn der Scan-Pfad des Zählers ausgewählt ist
(LEVT_CNTR-Anweisung), werden die Schattenbits während des JTAG-Zustands CAPTURE_DR
(nicht in der Datenstrom-Betriebsart) mit dem Wert des Zählers geladen,
während
der Zähler während des
JTAG-Zustands IDLE von den Schattenbits geladen wird. Die Verwendung
des Zustands IDLE zum Ausführen
der Zählerladens
ermöglicht,
ein synchrones Laden auszuführen.
Die Signale MTAP_BORROW und XFER_DATA sind einen einzelnen Taktzyklus
breit.
-
Das
AUX-Bit ist nur im Schiebepfad des Zählers und wird während eines
SMM_ID-Scan als das 16-te Bit für
den ID-Buswert genutzt. Während
einer SMM_ID-Scan-Operation werden die 16 Bits des Schieberegisters
des Zählers
durch den Zustand CAPTURE_DR mit dem 16-Bit-ID-Buswert geladen.
-
Das
Zählerbetriebsartfeld
(CM[1:0]) wird genutzt, um den Zähler 631 für die ausgewählte Funktion
zu konfigurieren. Tabelle 67 definiert das CM-Bitfeld des Zählers 630 und
Tabelle 68 das CES-Bitfeld.
-
-
Tabelle
68. CES-Bitfelddefinitione
-
Spezialemulationsvorrichtungsunterstützung(SE-Vorrichtungsunterstützung)
-
Wieder
anhand von 15 enthält die Megamodulbegrenzung 301 Signale
zur Unterstützung
einer Spezialemulationsvorrichtung. Eine SE-Vorrichtung enthält das Megamodul 300 und
zusätzliche
Steuerregister in einer vierten SE-Analysedomäne (SEA-Domäne). Die Steuerregister für eine SE-Vorrichtung
sind speicheradressiert.
-
Wieder
anhand von 11 wird
der Programmzählerwert
des Ausführungspakets
in der Phase DP in einem als PCDP bezeichneten Register zwischengespeichert.
Das PCDP kann mit Werten, die in der Emulationslogik gehalten werden,
auf exakte Anpassungen, Bereichsvergleich, oder Bitfeldmaskierungsvergleich verglichen
werden. Falls das PCDP an einen besonderen Adressensatz für einen
Hardwareprogramm-Unterbrechungspunkt angepasst ist, setzt die SE-Emulationslogik
während
dieses Zyklus SEE.
-
DADDR,
DDATA_I, DDATA_O, DRNW und DBS sind an der GPU-Begrenzung verfügbar, um
Unterbrechungspunkte an Datenadressen zu erfassen. Für Vergleiche
der genauen Anpassung, des Bereichs oder der Maske der Unterbrechungspunktwerte
können
sowohl Adressen als auch (durch die richtigen Übernahmen geeignete) Daten
verwendet werden. Datenunterbrechungspunkte unterscheiden sich von
Programmunterbrechungspunkten dadurch, dass die Datenadressen während der
Phase E2 an der CPU-Begrenzung vorhanden sind. Das Ausführungspaket,
das den Unterbrechungspunkt verursacht, kann nicht vor dem Eintritt
in die Ausführung
angehalten werden. Allerdings kann die Emulationslogik aus dem PCDP-Strom
den Befehl rekonstruieren, der den Unterbrechungspunkt verursacht
hat. Für
dieses Merkmal ist eine gewisse Pufferung des PCDP erforderlich.
-
Ablaufverfolgungs- und
Leistungsanalyse
-
Für die Ablaufverfolgung
sind auf dem Bus Speichersteuerungs- und Unterbrechungsquittierungssignale
verfügbar.
Ein Signal BRTK gibt an, dass die durch PCDP dargestellte Adresse
ein Verzweigungsziel war. Acht Signale (FU_L1, FU_M1, FU_D1, FU_S1,
FU_L2, FU_M2, FU_D2, FU_S2) geben an, ob das Ausführungspaket
in E2 (während
des vorangehenden Zyklus in E 1) einen Befehl an den Einheiten L-,
M-, D- oder S- bzw. auf Seite A- oder B- ausgeführt hat. Die Einheitszuweisung
bezieht sich auf den für
die Decodierung verwendeten Decodierungsblock. Dies kann verwendet
werden, um die Parallelität
zu bewerten und um zu bewerten, ob Bedingungen für einen besonderen Befehl als
wahr bewertet werden. Schließlich
gibt eine 3-Bit-Ausgabe EPSIZE die Größe des Ausführungspakets (in Wörtern) in
DC an. Diese sollte während
der Unterbrechungsverarbeitung und während aller Zusatzzyklen, die
durch IDLEs und Mehrzyklen-NOPs eingeführt werden, null sein.
-
41 ist ein Verdrahtungsdiagramm,
das ausführlicher
die Verdrahtung zwischen dem MTAP 305 und den Domänen und
DTPs des Megamoduls 300 zeigt. Wie in 33 angegeben ist, nutzt die SE-Analyse einen
unabhängigen
Scan-Pfad 457 und 458,
während
sie den MTAP-MPSD-Steuerbus (C0, C1, Ce) mit den Megamodul-DTPs
gemeinsam nutzt. Die in Tabelle 69 beschriebenen Signale bilden
eine Schnittstelle des MTAP 305 zu dem SE-Analysemodul.
-
Tabelle
69. MTAP-Sea-Modulverdrahtung
-
Das
SE nutzt einen DTP, der völlig
gleich den DTPs des Megamoduls ist. Die SE-Analysebits C0, C1 und
Ce werden in der Weise zeitlich gesteuert, dass sie parallel zu
den DTP-Bits C0, C1 und Ce des Megamoduls an den SE-DTP übergeben
werden.
-
Weiter
anhand von 41 schafft
das Modul MTAP 305 die Schnittauffächerung zwischen der JTAG-Umgebung
und jedem DTP. Die Auffächerung
zu jedem DTP enthält
einen MPSD-Codebus (C0, C1, Ce), die Signale, die die Domänentaktschaltung
zwischen TCLK und UCLK steuern, die Aktualisierungssignale, die das
Laden der Steuer-SRLs in dem Testport steuern, den Emulationsstatus
und die MTAP-Anweisungen, die nicht auf dem MPSD-BUS rundgesendet
werden.
-
Weiter
anhand von 41 enthält die Datenstrom-Scan-Pfad-Schaltungsanordnung 700 eine
Schaltungsanordnung zum Übertragen
von Stromdaten an das Datenstromregister 393 (30D). Ein STRM_I/O-Bus 701 überträgt Stromdaten
an die CPU-Domäne 10.
Diese Schaltungsanordnung wird anhand von 42 ausführlicher beschrieben.
-
42 ist ein Prinzipschaltbild,
das Einzelheiten der Daten-Scan-Pfad-Schaltungsanordnung 700 zeigt.
Das Scan-Register 710 bildet einen Abschnitt des DATA_STRM-Scan-Pfads 456 (33). Der STRM_I/O-Bus 701 überträgt Stromdaten
an das (zuvor anhand von 30D beschriebene)
Datenstromregister STREAM 393, das in der CPU-Domäne 10 ist.
Wie zuvor anhand der Tabellen 37–41 beschrieben worden ist,
können
die Stromdaten zu und von verschiedenen Speicherplätzen in
der CPU-Domäne 10 übertragen werden.
Der Fünf-Bit-Zähler 632 ist
ein Abschnitt des Zählers 631,
der anhand von 40 beschrieben
wurde. Der Komparator 635 überwacht das JTAG-IR 580,
um zu bestimmen, wann in dem JTAG-IR 580 ein JTAG-Befehl
SDAT_STRM vorhanden ist. Das Gatter 636 dekrementiert in
Reaktion auf jeden durch das Signal 637 angegebenen JTAG-Schiebezustand den
Zähler 632.
Der Komparator 712 erfasst, wann der Zähler 632 die 00 erreicht
hat und aktiviert das Signal XFER_DATA 702.
-
Wie
anhand von Tabelle 64 beschrieben wurde, werden Stromdaten aus dem
Scan-Register 710 übertragen,
wenn in dem Befehlsregister der CPU 10 ein Ladebefehl vorhanden
ist. In diesem Fall wird das STREAM-Register 393 in Reaktion
auf das Signal 702 geladen. Wenn im Befehlsregister der
CPU 10 ein Speicherbefehl vorhanden ist, werden Daten aus
dem STREAM-Register 393 an das Scan-Register 710 übertragen.
In diesem Fall wird in Reaktion auf den Speicherbefehl das Schreibfreigabesignal
aktiviert, wobei das Gatter 713 das Signal 717 aktiviert,
um in Reaktion auf das Signal XFER_DATA 702 das Scan-Register 710 zu
laden.
-
Weiter
anhand von 42 bildet
die Statusschaltung 730, wie anhand von Tabelle 44 beschrieben wurde,
in Reaktion auf das Signal XFER_DATA 702 die MTAP-Statusbits
STRY_TGLE und STSW_TGLE. Die Quittungsaustauschsignale 731 umfassen
CPU_DONE und TERM (0, 1) vom ECT 520.
-
43 ist ein Prinzipschaltbild,
das die EMU-Anschlussstiftverbindungen zeigt. EMU[1:0) sind EMU-Eingangs/Ausgangs-Anschlussstifte.
Diese Anschlussstifte schaffen einen Emulationsereigniseingang für die Multiprozessorunterstützung und
einen Emulationsereignisausgang für die Erfassung externer Ereignisse.
In einem Endsystem können
sämtliche
JTAG- und Emulationsanschlussstifte ohne Verbindungen gelassen werden.
Um dies zu ermöglichen,
befinden sich an den Anschlussstiften TMS, TCLK, TDI, EMU1 und EMU0, wie
durch den Pull-Up 900 angegeben ist, kleine Pull-Up-Widerstände. TRST-
besitzt einen kleinen internen Pull-down-Widerstand, der sicherstellt,
dass der JTAG-TAP und die Begrenzungslogik zurückgesetzt bleiben, wenn sie
ohne Verbindung gelassen werden.
-
44 ist ein Blockschaltplan
einer alternativen Ausführungsform
einer Vorrichtung 1000, die einen Aspekt der vorliegenden
Erfindung verwendet. Es gibt mehrere Konfigurationen, die durch
die JTAG-Schnittstelle des MTAP 305 unterstützt werden
können. 44 ist ein Beispiel, das
ein Megamodul 1010 und ein kundenangepasstes Logikmodul 1020 besitzt.
Es ist wichtig anzumerken, dass alle Signale des JTAG-Moduls TDO/TDI
in Serie geschaltet sind, während
alle Signale TMS und TRST parallel geschaltet sind. Die Reihenfolge
der Module ist unwichtig. Die Modulreihenfolge muss für die Konfigurationsdatei
der Zielsystem-JTAG-Vorrichtung
geliefert werden. Diese Datei wird von der Emulationssoftware genutzt,
um das Management mehrerer JTAG-Vorrichtungen und JTAG-Module in der gleichen
Scan-Kette auszuführen.
-
EMU-Status
-
Wieder
anhand von 41 werden
in der CPU oder in dem On-Chip-Speichersystem des Mikroprozessors 1 verschiedene
Emulationsstatusbits erzeugt.
-
Diese
Signale werden als Pegel in den MTAP 305 gebracht. Sie
werden während
des Zustands CAPTURE-IR im Schieberegister des JTAG-IR 580 zwischengespeichert.
Tabelle 70 beschreibt die Haltebetriebsartemulationsstatussignale.
Tabelle 71 beschreibt die Echtzeitbetriebsartemulationsstatussignale.
Tabelle 72 beschreibt die CPU-Emulationsstatussignale. Tabelle 73
beschreibt die CPU-Emulationsereignissignale.
-
Tabelle
70. Haltebetriebsartemulationsstatussignale
-
Tabelle
71. Echtzeitbetriebsartemulationsstatussignale
-
Tabelle
72. CPU-Emulationsstatussignale
-
Tabelle
73. CPU-Emulationsereignissignale
-
Die
Begriffe "angelegt", "verbunden" und "Verbindung" bedeuten, wie sie
hier verwendet werden, elektrisch verbunden, einschließlich dort,
wo zusätzliche
Elemente in dem elektrischen Verbindungspfad sein können.
-
Obgleich
die Erfindung mit Bezug auf veranschaulichende Ausführungsformen
beschrieben wurde, soll diese Beschreibung nicht in beschränkendem
Sinn verstanden werden. Für
den Fachmann auf dem Gebiet sind mit Bezug auf diese Beschreibung
verschiedene weitere Ausführungsformen
der Erfindung offensichtlich. Somit sollen die beigefügten Ansprüche irgendwelche
solche Änderungen
der Ausführungsformen,
die in den Gültigkeitsbereich
der Erfindung fallen, umfassen.