DE69729057T2 - Verfahren zum Anwenden eines Mehrwort-Befehlsregisters während der Fehlersuche eines Datenverarbeitungssystems - Google Patents

Verfahren zum Anwenden eines Mehrwort-Befehlsregisters während der Fehlersuche eines Datenverarbeitungssystems Download PDF

Info

Publication number
DE69729057T2
DE69729057T2 DE69729057T DE69729057T DE69729057T2 DE 69729057 T2 DE69729057 T2 DE 69729057T2 DE 69729057 T DE69729057 T DE 69729057T DE 69729057 T DE69729057 T DE 69729057T DE 69729057 T2 DE69729057 T2 DE 69729057T2
Authority
DE
Germany
Prior art keywords
register
code
instruction
data
execution
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE69729057T
Other languages
English (en)
Other versions
DE69729057D1 (de
Inventor
Douglas E. Deao
Natarajan Seshan
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Texas Instruments Inc
Original Assignee
Texas Instruments Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Texas Instruments Inc filed Critical Texas Instruments Inc
Publication of DE69729057D1 publication Critical patent/DE69729057D1/de
Application granted granted Critical
Publication of DE69729057T2 publication Critical patent/DE69729057T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/34—Addressing or accessing the instruction operand or the result ; Formation of operand address; Addressing modes
    • G06F9/355—Indexed addressing
    • G06F9/3552—Indexed addressing using wraparound, e.g. modulo or circular addressing
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
    • G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
    • G01R31/28—Testing of electronic circuits, e.g. by signal tracer
    • G01R31/317—Testing of digital circuits
    • G01R31/31705—Debugging aspects, e.g. using test circuits for debugging, using dedicated debugging test circuits
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01R—MEASURING ELECTRIC VARIABLES; MEASURING MAGNETIC VARIABLES
    • G01R31/00—Arrangements for testing electric properties; Arrangements for locating electric faults; Arrangements for electrical testing characterised by what is being tested not provided for elsewhere
    • G01R31/28—Testing of electronic circuits, e.g. by signal tracer
    • G01R31/317—Testing of digital circuits
    • G01R31/3181—Functional testing
    • G01R31/3185—Reconfiguring for testing, e.g. LSSD, partitioning
    • G01R31/318533—Reconfiguring for testing, e.g. LSSD, partitioning using scanning techniques, e.g. LSSD, Boundary Scan, JTAG
    • G01R31/318566—Comparators; Diagnosing the device under test
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/362—Software debugging
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/362—Software debugging
    • G06F11/3648—Software debugging using additional hardware
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30003—Arrangements for executing specific machine instructions
    • G06F9/3005—Arrangements for executing specific machine instructions to perform operations for flow control
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30098—Register arrangements
    • G06F9/30101—Special purpose registers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30098—Register arrangements
    • G06F9/30105—Register structure
    • G06F9/30112—Register structure comprising data of variable length
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30098—Register arrangements
    • G06F9/30105—Register structure
    • G06F9/30116—Shadow registers, e.g. coupled registers, not forming part of the register space
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30098—Register arrangements
    • G06F9/3012—Organisation of register space, e.g. banked or distributed register file
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30098—Register arrangements
    • G06F9/3012—Organisation of register space, e.g. banked or distributed register file
    • G06F9/30134—Register stacks; shift registers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3836—Instruction issuing, e.g. dynamic instruction scheduling or out of order instruction execution
    • G06F9/3842—Speculative instruction execution
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3836—Instruction issuing, e.g. dynamic instruction scheduling or out of order instruction execution
    • G06F9/3853—Instruction issuing, e.g. dynamic instruction scheduling or out of order instruction execution of compound instructions

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Test And Diagnosis Of Digital Computers (AREA)
  • Debugging And Monitoring (AREA)
  • Advance Control (AREA)

Description

  • TECHNISCHES GEBIET DER ERFINDUNG
  • Diese Erfindung bezieht sich 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 konstruierte 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-/Herstellungszykluszeit 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ührungspipeline 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.
  • 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.
  • US-A-5479652 beschreibt einen Mikroprozessor mit einer Betriebsart für externe Anweisungen für den direkten Zugriff auf die Ausführungseinheit in Reaktion auf von außen erzeugte Anweisungen und Befehle. Es sind ein Pfad für externe Befehle sowie ein herkömmlicher prozessorgetriebener Pfad vorgesehen. Vor der Ausführung eines Austestbefehls von dem externen Befehlspfad wird die Ausführung von Befehlen in dem herkömmlichen vom Prozessor angesteuerten Pfad vollständig abgeschlossen. Da ein direkter Zugriff über den externen Befehlspfad vorgesehen ist, gibt es keine implizite Aktualisierung, die erfordert, dass der Zustand in einem alternativen Speicher gesichert wird.
  • Zusammenfassung der Erfindung
  • In Übereinstimmung mit der vorliegenden Erfindung ist es vorteilhaft, während des Austestprozesses eines Datenverarbeitungssystems schnelle Downloads des Programmspeichers und schnelle Uploads und Downloads des Datenspeichers zu schaffen. Der Daten-Streaming-Prozess gemäß der vorliegenden Erfindung beseitigt den Kommunikationsorganisationsaufwand, der zuvor mit einem seriellen Scan-Testzugriffsport verknüpft war, indem er an dem Scan-Kanal des Testzugriffsports einen dauernden Datenstrom schafft.
  • Gemäß einem ersten Aspekt der Erfindung wird ein Verfahren zum Austesten eines Prozessors in einem Datenverarbeitungssystem geschaffen, wobei der Prozessor ein Mehrwort-Befehlsregister besitzt, wobei das Verfahren die folgenden Schritte umfasst: Ausführen von Systemcode aus dem Mehrwort-Befehlsregister in einer Befehlsausführungspipeline in einer normalen Betriebsweise; Anhalten des normalen Betriebs des Prozessors durch Sichern wenigstens eines ersten teilweise ausgeführten Befehls in einem externen Testsystem; Verhindern des Holens von Befehlen in das Mehrwort-Befehlsregister; Übertragen einer ersten Folge von Austestcode-Befehlen von dem externen Testsystem in das Mehrwort-Befehlsregister; Ausführen der Folge von Austestcode-Befehlen in dem Mehrwort-Befehlsregister des Prozessors, um eine Austestoperation an dem Prozessor auszuführen; und Wiederaufnehmen des Ausführens des Systemcodes in dem Mehrwort-Befehlsregister durch Wiedergewinnen des wenigstens ersten teilweise ausgeführten Befehls in dem Mehrwort-Befehlsregister von dem externen Testsystem; Freigeben des Holens von Befehlen und Starten des normalen Betriebs des Prozessors.
  • Gemäß einem zweiten Aspekt der Erfindung wird ein Datenverarbeitungssystem geschaffen; das einen Mikroprozessor umfasst, der ein Mehrwort-Befehlsregister besitzt, wobei der Mikroprozessor ferner umfasst: eine Befehlsausführungspipeline, die mit dem Mehrwort-Befehlsregister verbunden ist, um Systemcode von dem Mehrwort-Befehlsregister in einer normalen Betriebsweise auszuführen; eine Emulationsschaltungsanordnung, die mit der Befehlsausführungspipeline und mit dem Mehrwort-Befehlsregister verbunden ist, um den normalen Betrieb des Mikroprozessors anzuhalten, indem wenigstens ein erster teilweise ausgeführter Befehl in einem externen Testsystem gesichert wird, wobei die Emulationsschaltungsanordnung so betreibbar ist, dass sie das Holen von Befehlen in das Mehrwort-Befehlsregister verhindert und eine erste Folge von Austestcode von dem externen Testsystem in das Mehrwort-Befehlsregister überträgt, und ferner so betreibbar ist, dass sie den wenigstens ersten teilweise ausgeführten Befehl in dem Mehrwort-Befehlsregister von dem externen Testsystem wiedergewinnt und das Holen von Befehlen ermöglicht; und wobei die Befehlspipeline ferner so betreibbar ist, dass sie die erste Folge von Austestcode in dem Mehrwort-Befehlsregister des Mikroprozessors ausführt, um eine Austestoperation an dem Mikroprozessor auszuführen und um daraufhin die Ausführung des wiedergewonnenen wenigstens ersten teilweise ausgeführten Befehls in dem Mehrwort-Befehlsregister wieder aufzunehmen.
  • 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 Anweisungen, 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 Daten-Streaming-Register 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., ausführlich einen DSP. Das US-Patent 5.329.471, erteilt an Gary Swoboda u. a., beschreibt ausführlich, wie ein DSP zu testen und zu emulieren ist. Um zu ermöglichen, dass ein Durchschnittsfachmann auf dem Gebiet der Mikroprozessoren die Erfindung herstellt und nutzt, werden im Folgenden Einzelheiten von Abschnitten des Mikroprozessors 1, die für eine Ausführungsform der vorliegenden Erfindung relevant sind, ausreichend ausführlich erläutert.
  • 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. Ferner 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.
  • Tabelle 2. Steuerregister
    Figure 00190001
  • Figure 00200001
  • 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
    Figure 00200002
  • 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
    Figure 00210001
  • 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
    Figure 00220001
  • 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 6. Schreibweisen für die Befehlsoperationen und -ausführungen
    Figure 00230001
  • Figure 00240001
  • Tabelle 7 und Tabelle 8 definieren die Abbildung zwischen Befehlen und Funktionseinheiten.
  • Tabelle 7. Abbildung von Befehlen auf Funktionseinheiten
    Figure 00250001
  • Figure 00260001
  • Tabelle 8. Abbildung von Funktionseinheiten auf Befehle
    Figure 00270001
  • Figure 00280001
  • Figure 00290001
  • 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
    Figure 00290002
  • 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
    Figure 00310001
  • 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.
  • Figure 00310002
  • 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
    Figure 00320001
  • 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:
  • Figure 00340001
  • Die acht Befehle werden sequentiell ausgeführt.
  • Das in 10B gezeigte vollständig parallele p-Bitmuster führt zu dieser Ausführungsfolge:
  • Figure 00340002
  • Alle acht Befehle werden parallel ausgeführt.
  • Das in 10C gezeigte teilweise serielle p-Bitmuster führt zu dieser Ausführungsfolge:
  • Figure 00340003
  • 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:
  • Figure 00350001
  • 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:
  • Figure 00360001
  • Das folgende Ausführungspaket ist gültig:
  • Figure 00360002
  • 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:
  • Figure 00360003
  • Das folgende Ausführungspaket ist gültig:
  • Figure 00360004
  • Falls 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:
  • Figure 00370001
  • Das folgende Ausführungspaket ist gültig:
  • Figure 00370002
  • 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:
  • Figure 00370003
  • Das folgende Ausführungspaket ist gültig:
  • Figure 00370004
  • 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:
  • Figure 00380001
  • Das folgende Ausführungspaket ist gültig:
  • Figure 00380002
  • 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:
  • Figure 00380003
  • Das folgende Ausführungspaket ist gültig:
  • Figure 00380004
  • 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:
    Figure 00390001
    während diese Codefolge gültig ist:
  • Figure 00390002
  • 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:
  • Figure 00390003
  • 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
    Figure 00400001
  • 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
    Figure 00410001
  • Figure 00420001
  • 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
    Figure 00420002
  • Figure 00430001
  • 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:
  • Figure 00430002
  • So sieht die Syntax für den ADD-Befehl aus:
    Figure 00430003
    src und dst geben die Quelle bzw. das Ziel an. Das (.unit) schreibt vor, auf welche Funktionseinheit (.L1, .L2, .S1, .S2, .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 Speicherteilsystemen 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.
  • Tabelle 15. Beschreibung der Pipelinephasen
    Figure 00460001
  • Figure 00470001
  • 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
    Figure 00480001
  • 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.
  • Einzyklusbefehle 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.
  • Multiplikationsbefehle 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 E1 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.
      i LDW
      i + 1 STW
    • 2) Wenn vor einem Ladevorgang ein Speichervorgang ausgeführt wird, wird der neue Wert gespeichert und der neue Wert geladen.
      i STW
      i + 1 LDW
    • 3) Wenn die Befehle parallel sind, wird der alte Wert geladen und der neue Wert gespeichert.
      i STW
      i + 1|| LDW
  • 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öglicht, 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 die Zählung ≥ 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
    Figure 00530001
  • 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-Programmadressenunterbrechungspunkt (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 ein Daten-Streaming 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 Anweisungen 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 unentschiedenen 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
    Figure 00570001
  • 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
    Figure 00580001
  • 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
    Figure 00590001
  • 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
    Figure 00600001
  • 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
    Figure 00610001
  • 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 unentschiedene Unterbrechungen kein CPU-Steuerregister bilden, halten sie den unentschiedenen 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 diesem 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 EMUOIN 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 EMUOIN 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
    Figure 00670001
  • Tabelle 24. Verzweigung zum Analyserücksprungzeiger
    Figure 00670002
  • Tabelle 25. Codefolge für den Rücksprung von der AINT
    Figure 00670003
  • 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. Testportsignalbeschreibungen4
    Figure 00690001
  • Tabelle 27. Beschreibungen der Testportbus-Signale
    Figure 00700001
  • 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
    Figure 00720001
  • Figure 00730001
  • Figure 00740001
  • Tabelle 29. Megamodulbegrenzungssignale
    Figure 00750001
  • Figure 00760001
  • Tabelle 30. Beschreibungen der MTAP-CPU- und der MTAP-Megamodul-Begrenzungssignale
    Figure 00760002
  • Tabelle 31. Beschreibungen der Signale der MTAP-CPU-Schnittstelle
    Figure 00770001
  • Figure 00780001
  • Tabelle 32. Beschreibungen der Signale der MTAP-Megamoduldomänen-Schnittstelle
    Figure 00780002
  • 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.
  • Figure 00800001
  • 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/UT)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
    Figure 00850001
  • 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-RDY-basierten 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
    Figure 00870001
  • 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_DONE erkennt 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 unentschiedenen 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 unentschiedene 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.
  • Emulationspipeline-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. Unentschiedene 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 unentschiedene 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 hält 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 Sicherns 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 Off-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 unwesentlichen 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.
    • 8. 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 unwesentlichen 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_DONE) 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 Daten-Streaming-Register (STREAM) 393. Diese verschiedenen Re gister 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 unentschiedene 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 36. ACR-Bitfelder
    Figure 00980001
  • Figure 00990001
  • Figure 01000001
  • Tabelle 37. Beschreibungen der Ereignisfreigabe- und Statusfelder (EES-Felder)
    Figure 01000002
  • 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.
  • Speicherzugriffsunterstü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 PDATA_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 unwesentlichen 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 "Daten-Streaming" 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 Daten-Streaming-Register 393, das zur Unterstützung des Daten-Streaming verwendet wird. Dieses CPU-Steuerregister verbindet die CPU-Registerdatei mit dem Daten-Streaming-Bus von dem MTAP (STRM_U/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 Daten-Streaming-Prozess 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 Daten-Streaming-Bussen (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 Streaming-Fehler erfassen, der bei Abschluss des Streaming-Prozesses 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 Streaming-Prozesses vorteilhaft dasselbe Holpaket ausgeführt.
  • Die Tabellen 38 und 39 zeigen das Holpaket zur Steuerung von Daten-Streaming-Daten-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 Streaming-Daten 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 Daten-Streaming-Daten-Download (Datenport 2)
    Figure 01030001
  • Tabelle 39. Holpaket für den Daten-Streaming-Daten-Download (Datenport 1)
    Figure 01040001
  • Die Tabelle 40 und die Tabelle 41 zeigen Holpakete zur Steuerung von Daten-Streaming-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 Streaming-Daten 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 Daten-Streaming-Daten-Uploads (Datenport 2)
    Figure 01050001
  • Tabelle 41. Holpaket für Daten-Streaming-Daten-Uploads (Datenport 1)
    Figure 01050002
  • Tabelle 42 zeigt das Holpaket zum Steuern von Daten-Streaming-Programm-Downloads. Wie bei Daten-Downloads muss das XDS den ersten zu speichernden Wert in die Registerdatei (in B0) laden. Allerdings ist anders als beim Daten-Streaming 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 Daten-Streaming-Programm-Downloads
    Figure 01060001
  • 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.
  • Echtzeit-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 Anwendereneichbarkeit 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 unentschiedene 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 des Testzugriffsports und der Boundary-Scan-Architektur der Norm IEEE 1149.1-1990. 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 Port-Scan-Entwurfs (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 EMU0/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 0x00-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-JTAG-konform 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
    Figure 01180001
  • Figure 01190001
  • 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, CAP-TURE_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 CAP-TURE_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
    Figure 01220001
  • 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. MTAP-Status
    Figure 01250001
  • Figure 01260001
  • Figure 01270001
  • 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. Der Befehlsbeginn 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 der Beginn einer privaten Anweisung 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
    Figure 01290001
  • Figure 01300001
  • ANMERKUNG: Der MTAP 305 stellt zusätzliche Beschränkungen an die durch die Opcodes 0x20–0x23, 0x30, 0x32 und 0x24 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-Teilsystem, 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 Befehle vom Befehlssteuerblock 560 beginnen 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
    Figure 01340001
  • Figure 01350001
  • Tabelle 48. Vorrichtungsbetriebsartfeld
    Figure 01360001
  • Tabelle 49 definiert anhand des MCS-Bits und der Vorrichtungsbetriebsartfeldbits die Taktauswahltabelle
  • Tabelle 49. Taktauswahltabelle
    Figure 01370001
  • Tabelle 50. MPSD-EXE-Code
    Figure 01370002
  • Tabelle 51. Fernereignisfeld
    Figure 01380001
  • Tabelle 52. DTP-Verriegelungsfeld
    Figure 01380002
  • Tabelle 53. Statusauswahlfeld
    Figure 01380003
  • Tabelle 54. Emulationskonfigurationscodes
    Figure 01390001
    • hochimpedant HI-Z
    • offener Kollektor OC
    • Totempfahl TP
  • Figure 01400001
  • Figure 01410001
  • ANMERKUNG: Sämtliche Signale, die EMU0OUT und EMU1OUT ansteuern, sind tief 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 Synchronisation 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 Synchronisationsproblem 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 Ox20–Ox2F enthält und der TAP entweder von UPDATE_IR oder von UPDATE_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
    Figure 01440001
  • Immer noch anhand von 36 verhindert das Signal SWINPROG die Erzeugung von START, falls der JTAG-Opcode 0x20–0x23, 0x30, 0x32 oder 0x24 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
    Figure 01450001
  • 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 gescannt 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. Befehlssteueranweisungen
    Figure 01470001
  • 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-Synchronisationstaktumschalter 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 unentschieden. 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 0x20–0x23, 0x30, 0x32 oder 0x24 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
    Figure 01520001
  • Tabelle 59. PAUS-HALT-Codeübergang
    Figure 01520002
  • 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
    Figure 01530001
  • 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, CO 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 CO 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 (0x20–0x23, 0x30 und 0x32) erzeugt, während C0 als SHIFT_DR AND JTAG der Opcodes (0x22–0x23 und 0x32) 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 0x20–0x23 und 0x30 und 0x32 (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 0x22–0x23, 0x30 und 0x32), 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_C0 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
    Figure 01560001
  • Tabelle 62. Beiträge des ODER-Terms zur Emulationsbetriebsart
    Figure 01570001
  • ANMERKUNG: Die GSM 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
    Figure 01580001
  • 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
    Figure 01590001
  • 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 (0x20–0x23, 0x30 und 0x32). CO wird auf eine Eins angesteuert, falls die Pfade SCTL_HALT oder SCTL_CNTL (0x22–0x23 und 0x32) ausgewählt sind, oder wird auf null angesteuert, falls die Pfade SDAT_HALT oder SDAT_CNTL (0x20–0x21 und 0x30) 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 0x20 oder 0x21 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_C0 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
    Figure 01610001
  • 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 Synchronisationsverzö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 abgeschlossen 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 Synchronisation 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
    Figure 01640001
  • 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 Daten-Streaming) 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 Daten-Streaming-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 67. Definition des CM-Bitfelds
    Figure 01660001
  • Tabelle 68. CES-Bitfelddefinitionen
    Figure 01670001
  • 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 CPU-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 E1) 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
    Figure 01690001
  • 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 Streaming-Register 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) Daten-Streaming-Register 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_ATA 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
    Figure 01720001
  • Tabelle 71. Echtzeitbetriebsartemulationsstatussignale
    Figure 01730001
  • Tabelle 72. CPU-Emulationsstatussignale
    Figure 01730002
  • Tabelle 73. CPU-Emulationsereignissignale
    Figure 01740001
  • 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.

Claims (16)

  1. Verfahren zum Austesten eines Prozessors (1) in einem Datenverarbeitungssystem, wobei der Prozessor (1) ein Mehrwort-Befehlsregister besitzt, wobei das Verfahren die folgenden Schritte umfasst: Ausführen von Systemcode aus dem Mehrwort-Befehlsregister in einer Befehlsausführungspipeline in einer normalen Betriebsweise; Anhalten des normalen Betriebs des Prozessors (1) durch Sichern wenigstens eines ersten teilweise ausgeführten Befehls in einem externen Testsystem (51); Verhindern des Holens von Befehlen in das Mehrwort-Befehlsregister; Übertragen einer ersten Folge von Austestcode-Befehlen von dem externen Testsystem (51) in das Mehrwort-Befehlsregister; Ausführen der Folge von Austestcode-Befehlen in dem Mehrwort-Befehlsregister des Prozessors, um eine Austestoperation an dem Prozessor (1) auszuführen; und Wiederaufnehmen des Ausführens des Systemcodes in dem Mehrwort-Befehlsregister durch Wiedergewinnen des wenigstens ersten teilweise ausgeführten Befehls in dem Mehrwort-Befehlsregister von dem externen Testsystem (51), Freigeben des Holens von Befehlen und Starten des normalen Betriebs des Prozessors (1).
  2. Verfahren nach Anspruch 1, bei dem der Schritt des Ausführens von Austestcode ferner umfasst: Ausführen der Folge von Austestcode in einer normalen Betriebsweise, um auf erste Daten in einer ersten Speicherschaltung innerhalb des Prozessors (1) zuzugreifen und um die ersten Daten in wenigstens einem ersten Speicherelement des Prozessors (1) zu speichern; und Übertragen der ersten Daten von dem ersten Speicherelement an einen Testport am Prozessor.
  3. Verfahren nach Anspruch 2, bei dem der Schritt des Anhaltens des normalen Betriebs ferner das Empfangen eines Austestbefehls von dem externen Testsystem (51) über den Testport umfasst.
  4. Verfahren nach Anspruch 3, bei dem der Schritt des Ausführens der Folge von Austestcode in einer normalen Betriebsweise ferner das Senden einer Meldung über den Testport an das externe Testsystem (51) in Reaktion auf die Ausführung eines Befehls der Folge von Austestcode umfasst.
  5. Verfahren nach Anspruch 4, bei dem die Schritte des Anhaltens, des Ausführens von Austestcode und des Wiederaufnehmens des Ausführens von Systemcode nicht bewirkt, dass ein vorher geholter Befehl erneut aus dem Programmspeicher (23) geholt wird.
  6. Verfahren nach Anspruch 5, bei dem der Schritt des Übertragens der ersten Daten ferner das Übertragen der ersten Daten von dem ersten Speicherelement über einen seriellen Scan-Pfad zu dem Testport am Prozessor umfasst.
  7. Verfahren nach einem der Ansprüche 1 bis 6, bei dem der Schritt des Anhaltens umfasst: Sichern eines ersten Zustands der Inhalte in der Befehlsausführungspipeline.
  8. Verfahren nach Anspruch 7, bei dem der Schritt des Anhaltens ferner umfasst: Weiterschalten der Befehlsausführungspipeline um eine Pipelinephase und Sichern eines zweiten Zustands der Inhalte der Befehlsausführungspipeline; und Wiederholen des Schrittes des Weiterschaltens um eine Pipelinephase und des Sicherns eines weiteren Zustands von Inhalten der Befehlsausführungspipeline, bis die Systemcode-Befehle aus der Befehlsausführungspipeline geleert sind.
  9. Verfahren nach einem der Ansprüche 1 bis 8, bei dem der Schritt des Wiederaufnehmens der Ausführung umfasst: Wiedergewinnen des ersten Zustands der Inhalte der Befehlspipeline in der Befehlspipeline, bevor der normale Betrieb des Prozessors (1) gestartet wird.
  10. Verfahren nach einem der Ansprüche 4 bis 9, bei dem der Schritt des Sendens einer ersten Meldung in Reaktion auf die Ausführung eines Softwareunterbrechungspunkt-Befehls in der Folge von Austestcode erfolgt.
  11. Verfahren nach Anspruch 10, das ferner die folgenden Schritte umfasst: Übertragen einer zweiten Folge von Austestcode-Befehlen in das Mehrwort-Befehlsregister von dem externen Testsystem (51) in Reaktion auf die erste Meldung; und Ausführen der zweiten Folge von Austestcode, während das Holen von Befehlen weiterhin verhindert wird.
  12. Datenverarbeitungssystem, das einen Mikroprozessor (1) umfasst, der ein Mehrwort-Befehlsregister besitzt, wobei der Mikroprozessor (1) ferner umfasst: eine Befehlsausführungspipeline, die mit dem Mehrwort-Befehlsregister verbunden ist, um Systemcode von dem Mehrwort-Befehlsregister in einer normalen Betriebsweise auszuführen; eine Emulationsschaltungsanordnung (50), die mit der Befehlsausführungspipeline und mit dem Mehrwort-Befehlsregister verbunden ist, um den normalen Betrieb des Mikroprozessors (1) anzuhalten, indem wenigstens ein erster teilweise ausgeführter Befehl in einem externen Testsystem (51) gesichert wird, wobei die Emulationsschaltungsanordnung (50) so betreibbar ist, dass sie das Holen von Befehlen in das Mehrwort-Befehlsregister verhindert und eine erste Folge von Austestcode von dem externen Testsystem (51) in das Mehrwort-Befehlsregister überträgt, und ferner so betreibbar ist, dass sie den wenigstens ersten teilweise ausgeführten Befehl in dem Mehrwort-Befehlsregister von dem externen Testsystem (51) wiedergewinnt und das Holen von Befehlen ermöglicht; und wobei die Befehlspipeline ferner so betreibbar ist, dass sie die erste Folge von Austestcode in dem Mehrwort-Befehlsregister des Mikroprozessors ausführt, um eine Austestoperation an dem Mikroprozessor (1) auszuführen und um dann die Ausführung des wiedergewonnenen wenigstens ersten teilweise ausgeführten Befehls in dem Mehrwort-Befehlsregister wieder aufzunehmen.
  13. Datenverarbeitungssystem nach Anspruch 12, bei dem die Emulationsschaltungsanordnung (50) ferner so betreibbar ist, dass sie einen ersten Zustand der Inhalte der Befehlsausführungspipeline sichert, nachdem der normale Betrieb des Prozessors (1) angehalten worden ist.
  14. Datenverarbeitungssystem nach Anspruch 12 oder 13, bei dem die Emulationsschaltungsanordnung (50) ferner so betreibbar ist, dass sie den ersten Zustand der Inhalte der Befehlspipeline in der Befehlspipeline wiedergewinnt, bevor der normale Betrieb des Prozessors (1) wieder aufgenommen wird.
  15. Datenverarbeitungssystem nach einem der Ansprüche 12 bis 14, bei dem die Befehlsausführungspipeline-Schaltungsanordnung ferner so betreibbar ist, dass sie einen Softwareunterbrechungspunkt-Befehl in der Folge von Austestcode ausführt und in Reaktion auf die Ausführung des Softwareunterbrechungspunkt-Befehls eine zweite Folge von Austestcode von dem externen Testsystem (51) in das Mehrwort-Befehlsregister überträgt.
  16. Datenverarbeitungssystem nach einem der Ansprüche 12 bis 15, bei dem die Befehlsausführungspipeline ferner so betreibbar ist, dass sie die Ausführung von Systemcode in einer normalen Betriebsweise wieder aufnimmt, nachdem die erste Folge von Austestcode wieder aufgenommen worden ist, ohne dass erneut ein Befehl aus dem Programmspeicher (23) geholt wird.
DE69729057T 1996-12-20 1997-12-18 Verfahren zum Anwenden eines Mehrwort-Befehlsregisters während der Fehlersuche eines Datenverarbeitungssystems Expired - Lifetime DE69729057T2 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US3426196P 1996-12-20 1996-12-20
US34261P 1996-12-20

Publications (2)

Publication Number Publication Date
DE69729057D1 DE69729057D1 (de) 2004-06-17
DE69729057T2 true DE69729057T2 (de) 2005-05-12

Family

ID=21875290

Family Applications (1)

Application Number Title Priority Date Filing Date
DE69729057T Expired - Lifetime DE69729057T2 (de) 1996-12-20 1997-12-18 Verfahren zum Anwenden eines Mehrwort-Befehlsregisters während der Fehlersuche eines Datenverarbeitungssystems

Country Status (4)

Country Link
US (1) US6065106A (de)
EP (1) EP0849671B1 (de)
JP (2) JPH10187491A (de)
DE (1) DE69729057T2 (de)

Families Citing this family (44)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE69433124T2 (de) * 1993-11-05 2004-05-27 Intergraph Corp., Huntsville Befehlsspeicher mit assoziativem Kreuzschienenschalter
US6145027A (en) * 1997-07-09 2000-11-07 Texas Instruments Incorporated DMA controller with split channel transfer capability and FIFO buffering allowing transmit channel to get ahead of corresponding receive channel by preselected number of elements
US6571359B1 (en) * 1999-12-13 2003-05-27 Intel Corporation Systems and methods for testing processors
US6643803B1 (en) * 1999-02-19 2003-11-04 Texas Instruments Incorporated Emulation suspend mode with instruction jamming
US6557116B1 (en) * 1999-02-19 2003-04-29 Texas Instruments Incorporated Emulation suspension mode with frame controlled resource access
US6367071B1 (en) * 1999-03-02 2002-04-02 Lucent Technologies Inc. Compiler optimization techniques for exploiting a zero overhead loop mechanism
US6405300B1 (en) * 1999-03-22 2002-06-11 Sun Microsystems, Inc. Combining results of selectively executed remaining sub-instructions with that of emulated sub-instruction causing exception in VLIW processor
US6311311B1 (en) * 1999-08-19 2001-10-30 International Business Machines Corporation Multiple input shift register (MISR) signatures used on architected registers to detect interim functional errors on instruction stream test
US7100027B1 (en) * 1999-12-13 2006-08-29 Intel Corporation System and method for reproducing system executions using a replay handler
US6754892B1 (en) * 1999-12-15 2004-06-22 Transmeta Corporation Instruction packing for an advanced microprocessor
US6704857B2 (en) * 1999-12-23 2004-03-09 Pts Corporation Methods and apparatus for loading a very long instruction word memory
US6934937B1 (en) * 2000-03-30 2005-08-23 Broadcom Corporation Multi-channel, multi-service debug on a pipelined CPU architecture
US6681321B1 (en) * 2000-04-20 2004-01-20 International Business Machines Corporation Method system and apparatus for instruction execution tracing with out of order processors
US7366876B1 (en) 2000-10-31 2008-04-29 Analog Devices, Inc. Efficient emulation instruction dispatch based on instruction width
US6944848B2 (en) * 2001-05-03 2005-09-13 International Business Machines Corporation Technique using persistent foci for finite state machine based software test generation
US6466048B1 (en) 2001-05-23 2002-10-15 Mosaid Technologies, Inc. Method and apparatus for switchably selecting an integrated circuit operating mode
JP2002358060A (ja) * 2001-06-01 2002-12-13 Seiko Epson Corp 表示制御システム、表示サービス提供システム及び表示制御プログラム、並びに表示制御方法
US7257805B2 (en) 2001-11-09 2007-08-14 International Business Machines Corporation Restoring debugging breakpoints subsequent to program code modifications
JP2004013602A (ja) * 2002-06-07 2004-01-15 Handotai Rikougaku Kenkyu Center:Kk データ駆動プロセッサのエミュレーションシステム
US9003376B2 (en) * 2002-08-09 2015-04-07 Texas Instruments Incorporated Software breakpoints with tailoring for multiple processor shared memory or multiple thread systems
GB2395302B (en) * 2002-11-13 2005-12-28 Advanced Risc Mach Ltd Hardware driven state save/restore in a data processing system
US7698539B1 (en) * 2003-07-16 2010-04-13 Banning John P System and method of instruction modification
US7606997B1 (en) 2003-07-18 2009-10-20 Guillermo Rozas Method and system for using one or more address bits and an instruction to increase an instruction set
JP4409349B2 (ja) * 2004-04-27 2010-02-03 Ｏｋｉセミコンダクタ株式会社 デバッグ回路およびデバッグ制御方法
US7523351B2 (en) * 2004-09-27 2009-04-21 Ceva D.S.P. Ltd System and method for providing mutual breakpoint capabilities in computing device
US20070006042A1 (en) * 2005-06-30 2007-01-04 International Business Machines Corporation Software debug support for cache flush with access to external data location(s) through debug port
US7778806B2 (en) * 2006-03-29 2010-08-17 Hitachi, Ltd Method and apparatus for simulating microcomputer-based systems
US7987075B2 (en) * 2008-06-30 2011-07-26 Hitachi, Ltd Apparatus and method to develop multi-core microcomputer-based systems
FR2996321B1 (fr) * 2012-10-03 2014-10-24 Emulation And Verification Engineering Procede et dispositif de sauvegarde d'un etat d'un circuit sous test emule dans un emulateur et de son environnement de test logiciel, et procede et dispositif de restauration correspondants
US9417988B2 (en) * 2013-02-26 2016-08-16 Red Hat, Inc. Tracking subclasses of and operations performed by generic objects in a computer system
CN103473045A (zh) * 2013-08-27 2013-12-25 广州华多网络科技有限公司 一种生成接口文档的方法及装置
CN103488462B (zh) * 2013-09-06 2016-04-13 暨南大学 一种改进型8051ip核
US9619214B2 (en) 2014-08-13 2017-04-11 International Business Machines Corporation Compiler optimizations for vector instructions
GB2530050B (en) * 2014-09-10 2021-07-21 Advanced Risc Mach Ltd Debugging in a data processing apparatus
US9588746B2 (en) 2014-12-19 2017-03-07 International Business Machines Corporation Compiler method for generating instructions for vector operations on a multi-endian processor
US10169014B2 (en) 2014-12-19 2019-01-01 International Business Machines Corporation Compiler method for generating instructions for vector operations in a multi-endian instruction set
US10481203B2 (en) 2015-04-04 2019-11-19 Nvidia Corporation Granular dynamic test systems and methods
US10545189B2 (en) 2015-10-27 2020-01-28 Nvidia Corporation Granular dynamic test systems and methods
US9880821B2 (en) 2015-08-17 2018-01-30 International Business Machines Corporation Compiler optimizations for vector operations that are reformatting-resistant
US9594668B1 (en) * 2015-09-04 2017-03-14 International Business Machines Corporation Debugger display of vector register contents after compiler optimizations for vector instructions
US10095603B2 (en) * 2017-01-09 2018-10-09 International Business Machines Corporation Pre-fetching disassembly code for remote software debugging
US10754759B1 (en) * 2018-02-05 2020-08-25 Xilinx, Inc. Breakpointing circuitry that evaluates breakpoint conditions while running clock to target circuit
US11152076B2 (en) * 2019-09-23 2021-10-19 Arm Limited Apparatus and method for executing debug instructions
CN110688821B (zh) * 2019-09-27 2023-10-13 北京中电华大电子设计有限责任公司 一种复杂算法的测试激励生成器及其控制方法

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4701921A (en) * 1985-10-23 1987-10-20 Texas Instruments Incorporated Modularized scan path for serially tested logic circuit
US4811345A (en) * 1986-12-16 1989-03-07 Advanced Micro Devices, Inc. Methods and apparatus for providing a user oriented microprocessor test interface for a complex, single chip, general purpose central processing unit
US4860290A (en) * 1987-06-02 1989-08-22 Texas Instruments Incorporated Logic circuit having individually testable logic modules
US5535331A (en) * 1987-09-04 1996-07-09 Texas Instruments Incorporated Processor condition sensing circuits, systems and methods
US5084814A (en) * 1987-10-30 1992-01-28 Motorola, Inc. Data processor with development support features
GB2266606B (en) * 1992-04-27 1996-02-14 Intel Corp A microprocessor with an external command mode
US5537538A (en) * 1993-12-15 1996-07-16 Silicon Graphics, Inc. Debug mode for a superscalar RISC processor
US5564028A (en) * 1994-01-11 1996-10-08 Texas Instruments Incorporated Pipelined data processing including instruction trace
US5530804A (en) * 1994-05-16 1996-06-25 Motorola, Inc. Superscalar processor with plural pipelined execution units each unit selectively having both normal and debug modes
FR2720174B1 (fr) * 1994-05-20 1996-08-14 Sgs Thomson Microelectronics Procédé pour tester le déroulement d'un programme d'instructions exécutées par un circuit intégré spécialisé, et circuit intégré spécialisé s'y rapportant.

Also Published As

Publication number Publication date
DE69729057D1 (de) 2004-06-17
EP0849671B1 (de) 2004-05-12
US6065106A (en) 2000-05-16
EP0849671A3 (de) 2000-03-29
EP0849671A2 (de) 1998-06-24
JPH10187491A (ja) 1998-07-21
JP2007004832A (ja) 2007-01-11

Similar Documents

Publication Publication Date Title
DE69729057T2 (de) Verfahren zum Anwenden eines Mehrwort-Befehlsregisters während der Fehlersuche eines Datenverarbeitungssystems
DE69728244T2 (de) Verfahren und Vorrichtung für die Fehlerbeseitigungsunterstützung eines Pipeline-Mikroprozessors
DE69728632T2 (de) Einzelne Schrittausführung von Prozessor- und Teilsystempipelines während der Fehlersuche in einem Datenverarbeitungssystem
US6055649A (en) Processor test port with scan chains and data streaming
US6016555A (en) Non-intrusive software breakpoints in a processor instruction execution pipeline
US7080283B1 (en) Simultaneous real-time trace and debug for multiple processing core systems on a chip
US20070011663A1 (en) Distinguishing Between Two Classes of Trace Information
US6948155B2 (en) Little offset in multicycle event maintaining cycle accurate tracing of stop events
US6996735B2 (en) Apparatus for alignment of data collected from multiple pipe stages with heterogeneous retention policies in an unprotected pipeline
US6889311B2 (en) Pipeline stage single cycle sliding alignment correction of memory read data with integrated data reordering for load and store instructions
DE69728507T2 (de) Nichtintrusive Kodehaltepunkte in einem Prozessorbefehlsausführungspipeline
DE102009012768B4 (de) JTAG Nachrichtenbox
DE69728513T2 (de) Prozessortestanschluss mit Abtastketten und Datenströmung
Chandran et al. Managing trace summaries to minimize stalls during postsilicon validation
DE69728251T2 (de) Erhaltung der Synchronisation zwischen einem Prozessorpipeline und Teilsystempipelines während der Fehlerbeseitigung eines Datenverarbeitungssystems
Li et al. A readback based general debugging framework for soft-core processors
Park et al. On‐Chip Debug Architecture for Multicore Processor
US7502727B2 (en) Tracing user change of program counter during stop event
Park et al. Design methodology for on-chip-based processor debugger
Melear Emulation techniques for microcontrollers with internal caches and multiple execution units
GB2380827A (en) Debugging of processors using two separate event detectors

Legal Events

Date Code Title Description
8364 No opposition during term of opposition