DE60118089T2

DE60118089T2 - Abtastschnittstelle mit Zeitmultiplexmerkmal zur Signalüberlagerung

Info

Publication number: DE60118089T2
Application number: DE60118089T
Authority: DE
Inventors: Gary L. Swoboda
Original assignee: Texas Instruments Inc
Current assignee: Texas Instruments Inc
Priority date: 2000-03-02
Filing date: 2001-03-02
Publication date: 2006-10-05
Anticipated expiration: 2021-03-03
Also published as: DE60139219D1; EP1130501A1; EP1139220A2; EP1132816B1; EP1132816A2; DE60118089D1; EP1139220B1; EP1139108A2; EP1130501B1; EP1132816A3; EP1139108B1; EP1139108A3; EP1139220A3

Description

GEBIET DER ERFINDUNG
Die Erfindung betrifft allgemein die elektronische Datenverarbeitung und insbesondere Emulations-, Simulations- und Testfähigkeiten elektronischer Datenverarbeitungsvorrichtungen und -systeme.
HINTERGRUND DER ERFINDUNG
Die hoch entwickelte Waferlithographie- und Oberflächenmontagetechnologie integrieren zunehmend komplexere Funktionen sowohl auf der Siliciumebene als auch auf der Ebene gedruckter Leiterplatten beim elektronischen Entwurf. Ein verminderter physikalischer Zugang ist eine ungünstige Folge dichterer Entwürfe und abnehmender Verbindungsabstände. Es ist eine in den Entwurf aufgenommene Testbarkeit erforderlich, so dass das Endprodukt während des Testens und der Fehlersuche noch kontrollierbar und beobachtbar ist. Jegliche Herstellungsfehler sind vorzugsweise während des abschließenden Tests, bevor ein Produkt versandt wird, erkennbar. Diese Grundnotwendigkeit lässt sich bei komplexen Entwürfen nur schwer erreichen, ohne die Testbarkeit in der Logikentwurfsphase zu berücksichtigen, so dass automatische Testgeräte das Produkt testen können.
Zusätzlich zum Testen auf Funktionalität und auf Herstellungsfehler erfordert die Anwendungssoftwareentwicklung ein ähnliches Maß an Simulation, Beobachtbarkeit und Kontrollierbarkeit in der System- oder Untersystem-Entwurfsphase. Die Emulationsphase des Entwurfs sollte gewährleisten, dass ein IC (integrierter Schaltkreis) oder ein Satz von ICs im Endgerät oder in der Endanwendung richtig funktioniert, wenn er mit den Softwareprogrammen zusammenarbeitet.
Mit der zunehmenden Verwendung von ICs in der Autoindustrie, in der Telekommunikation, in Verteidigungssystemen und in Lebenserhaltungssystemen werden das gründliche Testen und die umfangreiche Echtzeit-Fehlersuche zu einer kritischen Anforderung.
Das funktionelle Testen, bei dem ein Entwickler für das Erzeugen von Testvektoren verantwortlich ist, welche die Übereinstimmung mit Spezifikationen gewährleisten sollen, ist noch immer ein weit verbreitet verwendetes Testverfahren. Für sehr große Systeme erweist sich dieses Verfahren als unzureichend, um ein hohes Maß an Abdeckung für erkennbare Fehler bereitzustellen. Automatisch erzeugte Testmuster wären für eine vollständige Testbarkeit wünschenswert, und die Kontrollierbarkeit und Beobachtbarkeit sind Schlüsselziele, welche die gesamte Testhierarchie betreffen (von der Systemebene bis zur Transistorebene).
Ein weiteres Problem bei umfangreichen Entwürfen sind die lange Zeit und die erheblichen Kosten, die dabei auftreten. Es wäre wünschenswert, Testbarkeitsschaltungsanordnungen, Systeme und Verfahren zur Verfügung stehen zu haben, welche mit dem Konzept des Entwurfs zur Wiederverwendbarkeit konsistent sind. Auf diese Weise können nachfolgende Vorrichtungen und Systeme geringe Entwurfskosten für die Testbarkeit, Simulation und Emulation haben, indem die Testbarkeits-, Simulations- und Emulationsschaltungsanordnungen, -systeme und -verfahren wieder verwendet werden, die in einer ursprünglichen Vorrichtung implementiert wurden. Ohne einen proaktiven Testbarkeits-, Simulations- und Emulationsansatz wird viel spätere Entwicklungszeit für die Erzeugung und Aktualisierung von Testmustern aufgewendet.
Selbst wenn eine erhebliche Investition getätigt wurde, um ein Modul so zu entwickeln, dass es wieder verwendbar ist, und um seine Testmuster vollständig zu erzeugen und zu klassifizieren, kann die spätere Verwendung des Moduls es in anwendungsspezifischer Logik begraben und seinen Zugang schwierig oder unmöglich machen. Folglich ist es erwünscht, diese Falle zu vermeiden.
Die Fortschritte des IC-Entwurfs sind beispielsweise von einer verringerten internen Sichtbarkeit und Kontrolle, einer verringerten Fehlerabdeckung und einer verringerten Fähigkeit, Zustände zu wechseln, größeren Testentwicklungs- und Prüfungsproblemen, einer erhöhten Komplexität der Entwurfssimulation und stetig zunehmenden Kosten für CAD-(computerunterstützter Entwurf)-Werkzeuge begleitet. Beim Platinenentwurf treten die Nebenwirkungen einer verringerten Registersichtbarkeit und -kontrolle, einer komplizierten Fehlersuche und Simulation bei der Entwurfsprüfung, eines Verlusts an einer herkömmlichen Emulation infolge des Verlusts an physikalischem Zugang durch Packen vieler Schaltungen in ein einziges Gehäuse, einer erhöhten Komplexität der Leitungsführung auf der Platine, erhöhter Kosten für Entwurfswerkzeuge, von Gehäusen mit gemischten Modi und des Entwurfs für die Herstellbarkeit auf. Bei der Anwendungsentwicklung sind einige Nebenwirkungen eine verringerte Sichtbarkeit von Zuständen, Schwierigkeiten einer schnellen Emulation, eine skalierte zeitliche Simulation, eine erhöhte Komplexität bei der Fehlersuche und erhöhte Kosten von Emulatoren. Produktionsnebenwirkungen umfassen eine verringerte Sichtbarkeit und Kontrolle, Komplikationen bei Testvektoren und -modellen, eine erhöhte Testkomplexität, Gehäuse mit gemischten Modi, eine fortlaufende Kostenerhöhung von automatischen Testgeräten bis in den siebenstelligen Bereich und engere Toleranzen.
Die Emulationstechnologie, bei der eine Scan-basierte Emulation und eine Mehrfachverarbeitungs-Fehlersuche verwendet werden, wurde vor mehr als 10 Jahren eingeführt. 1988 war der Wechsel von der herkömmlichen Emulation innerhalb der Schaltung zur Scan-basierten Emulation durch Entwurfszyklus-Zeitdruck und neu verfügbaren Raum zur Emulation auf dem Chip motiviert. Entwurfszyklus-Zeitdruck wurde durch drei Faktoren erzeugt, nämlich höhere Integrationsniveaus, wie auf dem Chip vorhandenen Speicher, vergrößerte Taktfrequenzen, welche elektrische Störungen durch Emulationsunterstützungslogik hervorriefen, und höher entwickelte Packungstechniken, welche Emulatorverbindungsprobleme erzeugten.
Heute fordern dieselben Faktoren, mit neuen Einzelheiten, die Fähigkeit eines Scan-basierten Emulators heraus, die Einrichtungen zur Systemfehlersuche bereitzustellen, die heutige komplexe, hochintegrierte Entwürfe mit hoher Taktfrequenz benötigen. Die sich ergebenden Systeme sind kleiner, schneller und kostengünstiger. Sie weisen eine höhere Leistungsfähigkeit auf und haben zunehmend höhere Dichten. Jeder dieser positiven Systemtrends beeinträchtigt die Beobachtung der Systemaktivität, wobei es sich um den Schlüsselfaktor zum Ermöglichen einer schnellen Systementwicklung handelt. Dieser Effekt wird als "verschwindende Sichtbarkeit" bezeichnet.
Anwendungsentwickler bevorzugen die Sichtbarkeit und Kontrolle aller relevanten Systemaktivitäten. Der stetige Fortschritt der Integrationsniveaus und Erhöhungen der Taktfrequenzen verringern im Laufe der Zeit stetig die verfügbare Sichtbarkeit und Kontrolle. Diese Kräfte erzeugen eine Sichtbarkeits- und Kontrolllücke, wobei es sich um die Differenz zwischen dem gewünschten Sichtbarkeits- und Kontrollniveau und dem tatsächlich verfügbaren Niveau handelt. Im Laufe der Zeit wird sich diese Lücke sicher vergrößern. Verkäufer von Anwendungsentwicklungswerkzeugen bemühen sich, die Wachstumsrate dieser Lücke zu minimieren. Software- und zugeordnete Hardwarekomponenten von Entwicklungswerkzeugen müssen mehr mit weniger und auf verschiedene Arten erreichen, wobei die Herausforderung, eine einfache Verwendbarkeit bereitzustellen, durch diese Kräfte vergrößert wird.
Bei der heutigen hochintegrierten System-auf-einem-Chip-("System-On-a-Chip"-SOC)-Technologie hat sich die Sichtbarkeits- und Kontrolllücke drastisch vergrößert. Traditionelle Fehlersuchoptionen, wie Logikanalysatoren und aufgeteilte Prototypsysteme, sind nicht in der Lage, mit den Integrationsniveaus und weiter ansteigenden Taktfrequenzen heutiger Systeme Schritt zu halten.
Mit zunehmenden Integrationsniveaus wechseln Systembusse, welche zahlreiche Systemkomponenten verbinden, auf den Chip, wodurch der Zugang zu diesen Bussen für traditionelle Logikanalysatoren verwehrt wird. Bei einer begrenzten oder nicht signifikanten Bussichtbarkeit können Werkzeuge in der Art von Logikanalysatoren nicht verwendet werden, um die Systemaktivität zu betrachten oder die Auslösemechanismen bereitzustellen, die zur Kontrolle des entwickelten Systems erforderlich sind. Ein Kontrollverlust geht mit diesem Sichtbarkeitsverlust einher, weil es schwierig ist, Gegebenheiten zu kontrollieren, die nicht zugänglich sind.
Um diesem Trend entgegenzuwirken, haben Systementwickler daran gearbeitet, diese Busse freistehend zu halten, indem sie Systemkomponenten auf eine Weise gebaut haben, die die Konstruktion von Prototypensystemen mit freistehenden Bussen ermöglicht hat. Dieser Ansatz steht wegen der zunehmenden Erhöhung von Systemtaktfrequenzen auch in Frage. Die Schnittstellengeschwindigkeiten von Chip zu Chip halten nicht mit der Erhöhung der Taktfrequenzen der CPUs mit. Entwickler finden heraus, dass die Leistungsfähigkeit eines unterteilten Systems infolge von Schnittstellen-Wartezuständen, die hinzugefügt werden, um verzögerte Kommunikationsraten von Chip zu Chip zu kompensieren, nicht mit derjenigen seines integrierten Gegenstücks Schritt hält. An irgendeinem Punkt erreicht diese Beeinträchtigung der Leistungsfähigkeit nicht tolerierbare Niveaus, und das unterteilte Prototypensystem ist keine einsetzbare Fehlersuchoption mehr. Wir sind in eine Ära eingetreten, in der Produktionsvorrichtungen als die Plattform zur Anwendungsentwicklung dienen müssen.
Zunehmende CPU-Taktfrequenzen beschleunigen auch das Verschwinden anderer einfacher Sichtbarkeitsmechanismen. Weil die CPU-Taktfrequenzen die maximalen E/A-Zustandsfrequenzen übersteigen können, können Sichtbarkeitsports, die Informationen in nativer Form exportieren, nicht mehr mit der CPU Schritt halten. Untersysteme auf dem Chip werden auch mit Taktfrequenzen betrieben, die langsamer sind als die CPU-Taktfrequenz. Dieser Ansatz kann verwendet werden, um den Systementwurf zu vereinfachen und den Leistungsverbrauch zu reduzieren. Diese Entwicklungen bedeuten, dass sich nicht mehr auf einfache Sichtbarkeitsports verlassen werden kann, um eine klare Sicht der CPU-Aktivität zu erhalten.
Mit der Abnahme der Sichtbarkeit und der Kontrolle werden die Entwicklungswerkzeuge, die zum Entwickeln der Anwendung verwendet werden, weniger produktiv. Die Werkzeuge scheinen auch infolge der zunehmenden Werkzeugkomplexität, die erforderlich ist, um die Sichtbarkeit und die Kontrolle aufrechtzuerhalten, schwerer verwendbar. Probleme hinsichtlich der Sichtbarkeit, der Kontrolle und der einfachen Verwendung, die durch Systeme auf einem Chip hervorgerufen werden, neigen dazu, die Produktentwicklungszyklen zu verlängern.
Wenngleich die Integrationstrends Entwickler mit schwierigen Fehlersuchumgebungen konfrontieren, wecken sich auch Hoffnung, dass neue Ansätze für Fehlersuchprobleme auftauchen werden. Die erhöhten Dichten und Taktfrequenzen, die zu Entwicklungszyklus-Zeitdruck führen, erzeugen auch Gelegenheiten zu ihrer Lösung.
Auf dem Chip vorhandene Fehlersucheinrichtungen sind kostengünstiger als je zuvor. Weil Hochleistungschips hoher Geschwindigkeit zunehmend durch sehr große Speicherstrukturen beherrscht werden, fallen die Systemkosten, die mit der wahlfreien Logik verbunden sind, welche die CPU und die Speicheruntersysteme begleitet, als Prozentsatz der Gesamtsystemkosten. Die Kosten mehrerer tausend Gatter liegt auf einem Allzeitminimum, und sie können in manchen Fällen in einer Ecke heutiger Chipentwürfe untergebracht werden. Die Kosten je Anschlussstift bei heutigen Gehäusen hoher Dichte sind auch abgefallen, wodurch es leichter ist, mehr Anschlussstifte zur Fehlersuche zuzuordnen. Die Kombination kostengünstiger Gatter und Stifte ermöglicht die Anordnung neuer Emulationseinrichtungen auf dem Chip, die erforderlich sind, um die Herausforderungen anzugehen, die durch Systeme auf einem Chip hervorgerufen werden.
Wenn Produktionsvorrichtungen auch als die Anwendungs-Fehlersuchplattform dienen, müssen sie ausreichend Fehlersuchmöglichkeiten bereitstellen, um Ziele in Bezug auf die Zeit bis zur Markteinführung zu unterstützen. Weil die Fehlersuchanforderungen bei verschiedenen Anwendungen variieren, ist es sehr wünschenswert, die auf dem Chip vorhandenen Fehlersucheinrichtungen anpassen zu können, um Anforderungen in Bezug auf die Zeit bis zur Markteinführung und Kostenanforderungen in Einklang zu bringen.
Weil diese auf dem Chip vorhandenen Fähigkeiten die wiederkehrenden Kosten des Chips beeinflussen, ist die Skalierbarkeit jeder Lösung von primärer Wichtigkeit. "Zahlen Sie nur für das, was Sie brauchen" sollte das Leitprinzip für die Entwicklung von auf dem Chip vorhandenen Werkzeugen sein. Bei diesem neuen Paradigma kann der Systemarchitekt auch die Fehlersuchfähigkeiten auf dem Chip zusammen mit der restlichen Funktionalität spezifizieren, wobei er die Anforderungen an die Chipkosten und den Fehlersuchbedarf des Produktentwicklungsteams in Einklang bringt.
In der US-Patentanmeldung 5 347 523 ist ein Datenverarbeitungssystem mit einer seriellen Scan-Schaltung beschrieben, die einen Adressdetektor zum Erfassen und Decodieren seriell bereitgestellter Adressbits aufweist. Die Oberfläche der integrierten Schaltung ist durch Vermeiden großer Adress- und Datenbusse und durch die Buswegleitung reduziert.
Die Emulationstechnologie gemäß der vorliegenden Erfindung verwendet die vorstehend erwähnten Fehlersuchmöglichkeiten, um Entwicklern ein Arsenal von Fehlersuchfähigkeiten mit dem Ziel bereitzustellen, die Kontroll- und Sichtbarkeitslücke zu verschmälern.
Diese Emulationstechnologie bietet Lösungen für die komplexen Fehlersuchprobleme heutiger hochintegrierter eingebetteter Echtzeitsysteme. Diese Technologie richtet sich auf die Probleme des Verlusts an Sichtbarkeit, des Verlusts an Kontrolle und der einfachen Verwendung, die im vorstehenden Abschnitt beschrieben wurden, während der Merkmalssatz gegenwärtiger Emulatoren erweitert wird.
Die auf dem Chip vorhandene Fehlersuchkomponente gemäß der vorliegenden Erfindung bietet ein Mittel zum Optimieren der Kosten und der Fehlersuchmöglichkeiten. Die Architektur ermöglicht flexible Kombinationen von Emulationskomponenten oder Peripherieeinrichtungen, welche ausgelegt sind, um Bedingungen hinsichtlich der Systemkosten und der Zeit bis zur Markteinführung zu erfüllen. Der Skalierbarkeitsaspekt macht es möglich, sie bei vertreibbaren Kosten und begrenzten zusätzlichen Leistungsanforderungen in Produktionsvorrichtungen aufzunehmen.
KURZBESCHREIBUNG DER ZEICHNUNG
Die vorliegende Erfindung wird nun anhand eines Beispiels mit Bezug auf die bevorzugten und als Beispiel dienenden Ausführungsformen, die in den Figuren der anliegenden Zeichnung dargestellt sind, weiter beschrieben, wobei:
1 schematisch als Beispiel dienende Ausführungsformen eines Emulationssystems gemäß der Erfindung zeigt,
2 schematisch relevante Abschnitte als Beispiel dienender Ausführungsformen des Systems aus 1 gemäß der Erfindung zeigt,
3 in Tabellenform eine Definition mehrerer Scan-Schnittstellen zwischen dem Emulator und der Zielvorrichtung aus den 1 und 2 gemäß der Erfindung zeigt,
4 schematisch eine als Beispiel dienende Äusführungsform einer Scan-Schnittstelle zwischen dem Emulator und der Zielvorrichtung aus den 1 und 2 gemäß der Erfindung zeigt,
5 schematisch eine weitere als Beispiel dienende Ausführungsform einer Scan-Schnittstelle zwischen dem Emulator und der Zielvorrichtung aus den 1 und 2 gemäß der Erfindung zeigt,
6 in Tabellenform als Beispiel dienende Operationen zeigt, die von der Scan-Schnittstelle aus 4 ausgeführt werden können,
7 ein Zeitablaufdiagramm ist, das den in 6 dargestellten Operationen entspricht,
8 in Tabellenform als Beispiel dienende Operationen zeigt, die von der Scan-Schnittstelle aus 5 ausgeführt werden können,
9 ein Zeitablaufdiagramm ist, das den Operationen aus 8 entspricht,
10 in Tabellenform als Beispiel dienende Modusbits zeigt, die in die Zielvorrichtung aus den 2, 4 und 5 gescannt werden können, um in 2 dargestellte entsprechende Scan-Schnittstellenmodi auszuwählen,
11 schematisch eine als Beispiel dienende Ausführungsform einer Übertragungssteuereinrichtung für die Modusbits aus 10 zeigt,
12 schematisch relevante Abschnitte der in den 1, 2, 4 und 5 dargestellten als Beispiel dienenden Ausführungsformen des Emulators zeigt,
13 schematisch relevante Abschnitte der in den 1, 2, 4 und 5 dargestellten als Beispiel dienenden Ausführungsformen der Zielvorrichtung zeigt, und
die 14–25 Zeitablaufdiagramme sind, welche als Beispiel dienende Operationen zeigen, die dem Schalten von jedem der in 2 dargestellten Scan-Schnittstellenmodi zu jedem der in 2 dargestellten anderen Scan-Schnittstellenmodi zugeordnet sind.
DETAILLIERTE BESCHREIBUNG
Emulations-, Fehlersuch- und Simulationswerkzeuge gemäß der vorliegenden Erfindung werden hier beschrieben. Die hier beschriebenen Emulations- und Fehlersuchlösungen beruhen auf der Voraussetzung, dass im Laufe der Zeit einige, wenn nicht die meisten traditionell außerhalb des Chips ausgeführten Fehlersuchfunktionen in die Produktionsvorrichtung integriert werden müssen, falls sie im Fehlersucharsenal des Entwicklers bleiben sollen. Zum Unterstützen der Migration von Fehlersuchfunktionen auf den Chip stellt die vorliegende Erfindung ein mächtiges und skalierbares Portfolio von Fehlersuchmöglichkeiten zur Anordnung auf dem Chip bereit. Diese Technologie bewahrt alle Vorteile der anfänglichen JTAG-Technologie, während sie zusätzliche Möglichkeiten hinzufügt, die sich direkt auf die Probleme in Bezug auf die Sichtbarkeit, die Kontrolle und die einfache Verwendung richten, welche durch den Trend der verschwindenden Sichtbarkeit hervorgerufen werden.
Vier wesentliche Architektur-Infrastrukturkomponenten sind die wesentlichen Bestandteile, die sich gegen die hier zuvor beschriebene Kontroll- und Sichtbarkeitslücke richten:

1. Echtzeitemulation (RTE),
2. Echtzeit-Datenaustausch (RTDX),
3. Überwachung und
4. fortschrittliche Analyse.

Diese Komponenten richten sich auf die in Tabelle 1 dargestellten Sichtbarkeits- und Kontrollanforderungen.
Tabelle 1. Emulationssystemarchitektur und -verwendung
Die Echtzeitemulation ("Real-Time Emulation" – RTE) stellt einen Basissatz fester Fähigkeiten zur Echtzeit-Ausführungssteuerung (run, step, halt usw.) und Register-/Speichersichtbarkeit bereit. Diese Komponente ermöglicht es dem Benutzer, eine Fehlersuche in Anwendungscode vorzunehmen, während Echtzeitunterbrechungen weiter abgearbeitet werden. Auf Register und Speicher kann in Echtzeit zugegriffen werden, ohne die Unterbrechungsverarbeitung zu beeinflussen. Benutzer können zwischen Echtzeit- und Nicht-Echtzeitunterbrechungen unterscheiden und Code markieren, der durch Echtzeit-Fehlersuch-Speicherzugriffe nicht gestört werden darf. Diese grundlegende Emulationsfähigkeit enthält Hardware, die als zwei Einzelpunkt-Hardwareunterbrechungspunkte, ein einziger Datenüberwachungspunkt, ein Ereigniszähler oder ein Datenprotokollmechanismus konfiguriert werden kann. Die EMU-Anschlussstiftfähigkeit beinhaltet das Auslösen von Ein-/Ausgaben zur Mehrprozessor-Ereignisverarbeitung und einen unidirektionalen (Ziel-zu-Host-) Datenprotokollmechanismus.
RTDX^TM stellt Echtzeit-Datenübertragungen zwischen einem Emulatorhost und einer Zielanwendung bereit. Diese Komponente bietet sowohl bidirektionale als auch unidirektionale DSP-Ziel/Host-Datenübertragungen, die durch den Emulator erleichtert werden. Die DSP-Anwendung (oder Zielanwendung) kann Zieldaten sammeln, die zum Host zu übertragen sind, oder Daten vom Host empfangen, während die Emulationshardware (innerhalb des DSPs und des Emulators) die eigentliche Übertragung ausführt. Mehrere RTDX-Übertragungsmechanismen werden unterstützt, welche jeweils unterschiedliche Niveaus der Bandbreite- und Anschlussstiftverwendung bereitstellen, wodurch der Ausgleich zwischen der Verfügbarkeit von Gattern und Anschlussstiften und Bandbreiteanforderungen ermöglicht wird.
Die Überwachung ist ein nicht störender Mechanismus zum Bereitstellen einer Sichtbarkeit der Anwendungsaktivität. Die Überwachung wird verwendet, um die sich auf die CPU beziehende Aktivität, wie den Programmablauf und Speicherzugriffe, die Systemaktivität, wie ASIC-Zustandsmaschinen, Datenströme und von der CPU gesammelte Daten zu überprüfen. Bei der in der Vergangenheit verwendeten Überwachungstechnologie wurden auch Logikanalysator-artige Erfassungsvorrichtungen und spezielle Emulationsvorrichtungen (SE-Vorrichtungen) verwendet, die mehr Anschlussstifte als eine Produktionsvorrichtung aufwiesen. Der Logikanalysator oder eine ähnliche Vorrichtung verarbeitete native Darstellungen der Daten unter Verwendung einer Zustandsmaschinen-artigen Programmierschnittstelle (Filtermechanismus). Dieses Überwachungsmodell beruhte darauf, dass die gesamte Aktivität exportiert wurde, wobei die externe Auslösung die Daten auswählte, die gespeichert, betrachtet und analysiert werden mussten.
Die existierende Logikanalysator-artige Technologie bietet jedoch keine Lösung für die sich verringernde Sichtbarkeit infolge höherer Integrationsniveaus, zunehmender Taktfrequenzen und komplizierterer Gehäuseanordnungen. In diesem Modell muss die Produktionsvorrichtung eine Sichtbarkeit durch eine begrenzte Anzahl von Anschlussstiften bereitstellen. Die exportierten Daten werden codiert oder komprimiert, um die erforderliche Exportbandbreite zu verringern. Der Aufzeichnungsmechanismus wird zu einer reinen Aufzeichnungsvorrichtung, welche die exportierten Daten in einen tiefen Überwachungsspeicher packt. Überwachungssoftware wird verwendet, um die aufgezeichneten Daten in eine Aufzeichnung der Systemaktivität zu konvertieren.
Auf dem Chip vorhandene Überwachung mit einem schnellen seriellen Datenexport bietet in Kombination mit einer fortschrittlichen Analyse eine Lösung für SOC-Entwürfe. Die Überwachung wird verwendet, um die sich auf die CPU beziehende Aktivität, wie den Programmablauf und Speicherzugriffe, die Systemaktivität, wie ASIC-Zustandsmaschinen, Datenströme usw. und von der CPU gesammelte Daten zu überprüfen. Hierdurch werden vier verschiedene Klassen von Überwachungsdaten erzeugt:

• der vom DSP-Kern bereitgestellte Programmablauf und die davon bereitgestellte Zeitsteuerung (PC-Überwachung),
• vom DSP-Kern oder von Peripherieeinrichtungen auf der Chipebene vorgenommene Speicherdatenreferenzen (Daten-Lese- und Schreibvorgänge),
• anwendungsspezifische Signale und Daten (ASIC-Aktivität) und
• von der CPU erfasste Daten.

Erfassungsmechanismen für die vier Klassen von Überwachungsdaten sind modular, wodurch der Ausgleich der Funktionalität und Gattern und Anschlussstiften, die erforderlich sind, um gewünschte Bandbreiteanforderungen zu erfüllen, ermöglicht wird.
Die RTDX- und die Überwachungsfunktion liefern ähnliche, jedoch verschiedene Formen der Sichtbarkeit. Sie unterscheiden sich in Bezug darauf, wie Daten erfasst werden, und die Umstände, unter denen sie am wirksamsten wären. Eine kurze Erklärung ist nachstehend aus Klarheitsgründen aufgenommen:
RTDX^TM ("Real Time Data eXchange" – Echtzeit-Datenaustausch) ist eine von der CPU unterstützte Lösung zum Austausch von Informationen, wobei die auszutauschenden Daten ein wohldefiniertes Verhalten in Bezug auf den Programmablauf haben. Beispielsweise kann RTDX verwendet werden, um die Ein- oder Ausgabepuffer von einem DSP-Algorithmus aufzuzeichnen. RTDX benötigt eine CPU-Unterstützung bei der Datenerfassung, weshalb eine bestimmte, jedoch kleine, CPU-Bandbreite erforderlich ist, um dies zu erreichen.
Demgemäß ist RTDX ein in die Anwendung eingreifender bzw. diese störender Mechanismus zum Bereitstellen von Sichtbarkeit bei geringen wiederkehrenden Zusatzkosten.
Die Überwachung ist ein nicht störender bzw. nicht eingreifender, hardwareunterstützter Erfassungsmechanismus (in der Art von Busschnüfflern) mit einem Datenexport sehr hoher Bandbreite (BW). Die Überwachung wird verwendet, wenn es notwendig ist, Daten mit sehr hoher Datenrate zu exportieren oder wenn das Verhalten der zu überwachenden Informationen nicht bekannt ist oder zufälliger Natur ist oder mit einer Adresse verbunden ist. Der Programmablauf ist ein typisches Beispiel, bei dem es nicht möglich ist, das Verhalten vorab zu kennen. Die zum Exportieren dieser Informationsklasse erforderliche Bandbreite ist hoch. Die Datenüberwachung spezifizierter Adressen ist ein anderes Beispiel. Die zum Exportieren einer Datenüberwachung erforderliche Bandbreite ist sehr hoch.
Überwachungsdaten sind unidirektional, und sie gehen nur vom Ziel zum Host. RTDX kann Daten in beiden Richtungen austauschen, wenngleich unidirektionale Formen von RTDX unterstützt werden (Datenprotokollierung). Der Überwachungsdatenweg kann auch verwendet werden, um unidirektionalen RTDX mit sehr hoher Geschwindigkeit bereitzustellen (von der CPU erfasste Überwachungsdaten).
Die Merkmale hoher Ebene der Überwachung und von RTDX sind in Tabelle 2 angegeben.
Tabelle 2. Merkmale von RTDX und von der Überwachung
Die fortschrittliche Analyse stellt einen nicht eingreifenden, auf dem Chip vorhandenen Ereigniserfassungs- und Auslösererzeugungsmechanismus bereit. Die von der fortschrittlichen Analyse erzeugten Auslöserausgaben steuern andere Infrastrukturkomponenten, wie die Überwachung und RTDX. Bei früheren Überwachungstechniken wurde die zu einem Logikanalysator exportierte Busaktivität verwendet, um Auslöser zu erzeugen, welche die Überwachung innerhalb der Logikanalysatoreinheit steuerten oder Auslöser erzeugten, welche der Vorrichtung zugeführt wurden, um die Ausführung zu unterbrechen. Hieran war gewöhnlich ein Chip beteiligt, der mehr Anschlussstifte als die Produktionsvorrichtung aufwies (eine SE- oder spezielle Emulationsvorrichtung). Dieses Analysemodell funktioniert in der System-auf-einem-Chip-(SOC)-Ära nicht gut, weil die Integrationsniveaus und Taktfrequenzen heutiger Vorrichtungen einen Busexport mit vollständiger Sichtbarkeit ausschließen.
Die fortschrittliche Analyse bietet bezahlbare auf dem Chip vorhandene Befehls- und Datenbusvergleicher, Ablaufssteuereinrichtungen und Zustandsmaschinen sowie Ereigniszähler, um die wichtigsten Abschnitte der Auslösefunktionen nachzubilden, die in der Vergangenheit außerhalb des Chips vorhanden waren. Die fortschrittliche Analyse bietet den Steueraspekt des Fehlersuch-Auslösemechanismus zur Überwachungs-, RTDX- und Echtzeitemulation. Diese Architekturkomponente identifiziert Ereignisse, überwacht Ereignissequenzen und weist Aktionen auf der Grundlage ihres Auftretens zu (Unterbrechen der Ausführung, Aktivieren/Deaktivieren der Überwachung, Zählen, Aktivieren/Deaktivieren von RTDX usw.). Die modularen Bausteine für diese Fähigkeit umfassen Busvergleicher, externe Ereignisgeneratoren, Zustandsmaschinen oder Zustands-Ablaufssteuereinrichtungen und Auslösergeneratoren. Die Modularität des fortschrittlichen Analysesystems ermöglicht den Ausgleich der Funktionalität und der Gatter.
Die Emulatorfähigkeit wird durch die Wechselwirkung von vier Emulatorkomponenten erzeugt:

1. Fehlersuch-Anwendungsprogramm,
2. Hostcomputer,
3. Emulationssteuereinrichtung und
4. auf dem Chip vorhandene Fehlersucheinrichtungen.

Diese Komponenten sind wie in 1 dargestellt verbunden. Der Hostcomputer 10 ist mit einer Emulationssteuereinrichtung 12 (außerhalb des Hosts) verbunden, wobei die Emulationssteuereinrichtung (hier auch als Emulator oder Steuereinrichtung bezeichnet) auch mit dem Zielsystem 16 verbunden ist. Der Benutzer steuert vorzugsweise die Zielanwendung durch ein Fehlersuch-Anwendungsprogramm, das auf dem Hostcomputer läuft, beispielsweise das "Code Composer Studio"-Programm von Texas Instruments.
Ein typisches Fehlersuchsystem ist in 1 dargestellt. Dieses System verwendet einen Hostcomputer 10 (im Allgemeinen einen PC), um durch einen Emulator 12 auf die Fehlersuchfähigkeiten zuzugreifen. Das Fehlersuch-Anwendungsprogramm präsentiert die Fehlersuchfähigkeiten durch den Hostcomputer in einer benutzerfreundlichen Form. Die Fehlersuchressourcen werden nach Bedarf von der Fehlersuchsoftware zugewiesen, so dass dem Benutzer diese Last abgenommen wird. Die Fehlersuche auf der Quellenebene verwendet die Fehlersuchressourcen, wobei sie ihre Komplexität vor dem Benutzer verbirgt. Die Fehlersucheinrichtung bietet zusammen mit den auf dem Chip vorhandenen Überwachungs- und Auslöseeinrichtungen ein Mittel zum Auswählen, Aufzeichnen und Anzeigen der interessierenden Chipaktivität. Überwachungsanzeigen werden automatisch mit dem Quellencode korreliert, der das Überwachungsprotokoll erzeugt hat. Der Emulator liefert sowohl die Fehlersuchsteuerungs- als auch die Überwachungsaufzeichnungsfunktion.
Die Fehlersucheinrichtungen werden unter Verwendung von Standard-Emulatorfehlersuchzugriffen durch die JTAG-Schnittstelle des Zielchips oder eine ähnliche serielle Fehlersuchschnittstelle programmiert. Weil Anschlussstifte kostbar sind, ermöglicht die Technologie das gemeinsame Verwenden des Anschlussstiftsatzes für die Fehlersuche durch Überwachungs-, Auslöse- und andere Fehlersuchfunktionen bei einer kleinen Erhöhung der Siliciumkosten. Feste Anschlussstiftformate werden auch unterstützt. Wenn die Option des gemeinsamen Verwendens von Anschlussstiften eingesetzt wird, wird die Verwendung der Anschlussstifte für die Fehlersuche zu Beginn jeder Fehlersuchsitzung (bevor der Chip angewiesen wird, das Anwendungsprogramm ablaufen zu lassen) bestimmt, wodurch die Überwachungsexportbandbreite maximiert wird. Die Überwachungsbandbreite wird durch Zuordnen der Maximalzahl von Anschlussstiften für die Überwachung maximiert.
Die Fehlersuchfähigkeiten und Bausteine innerhalb eines Systems können variieren. Die Emulatorsoftware legt die Konfiguration daher bei der Laufzeit fest. Dieser Ansatz macht es notwendig, dass die Hardwareblöcke einen Satz von Randbedingungen erfüllen, welche die Konfiguration und die Registerorganisation betreffen. Andere Komponenten stellen eine Hardwaresuchfähigkeit bereit, die dafür ausgelegt ist, die Blöcke und andere Peripherieeinrichtungen in der Systemspeicherkarte zu lokalisieren. Die Emulatorsoftware verwendet eine Sucheinrichtung zum Lokalisieren der Ressourcen. Die Adresse, an der sich die Module befinden, und eine Typkennung identifizieren eindeutig jeden gefundenen Block. Sobald die Kennungen gefunden wurden, kann eine Entwurfsdatenbank verwendet werden, um die genaue Konfiguration und alle Systemeingaben und Systemausgaben festzustellen.
Der Hostcomputer ist im Allgemeinen ein PC mit einem Speicher von mindestens 64 Megabytes, der zumindest Windows95, SR-2, Windows NT oder spätere Versionen von Windows ausführen kann. Der PC muss eine der vom Emulator benötigten Kommunikationsschnittstellen unterstützen, beispielsweise:

• Ethernet 10T und 100T, TCP/IP-Protokoll,
• den universellen seriellen Bus (USB), Version 1.x,
• Firewire, IEEE 1394 und/oder
• Parallelport (SPP, EPP und ECP).

Die Emulationssteuereinrichtung 12 stellt eine Brücke zwischen dem Hostcomputer 10 und dem Zielsystem 16 bereit und behandelt alle Fehlersuchinformationen, die zwischen der auf dem Hostcomputer laufenden Fehlersuchanwendung und einer auf einem DSP (oder einem anderen Zielprozessor) 14 ausgeführten Zielanwendung ausgetauscht werden.
Eine als Beispiel dienende Emulatorkonfiguration unterstützt alle folgenden Fähigkeiten:

• Echtzeitemulation,
• RTDX,
• Überwachung und
• fortschrittliche Analyse.

Zusätzlich unterstützt die Emulator-Ziel-Schnittstelle:

• Eingabe- und Ausgabeauslöser,
• Bit-Ein-/Ausgabe und
• die Überwachung spezieller erweiterter Betriebsmodi.

Die Emulationssteuereinrichtung 12 greift über eine Scan-basierte Schnittstelle mit 3, 4 oder 5 Bits auf Echtzeit-Emulationsfähigkeiten (Ausführungssteuerung, Speicher und Registerzugriff) zu. Auf RTDX-Fähigkeiten kann durch einen Scan oder durch die Verwendung von drei RTDX-Formaten höherer Bandbreite zugegriffen werden, bei denen direkte Ziel-Emulator-Verbindungen außer den Scan-Verbindungen verwendet werden. Die Ein- und Ausgabeauslöser ermöglichen es, dass andere Systemkomponenten dem Chip Fehlersuchereignisse signalisieren und umgekehrt.
Der Emulator 12 ist in einen Kommunikations- und einen Emulationsabschnitt unterteilt. Der Kommunikationsabschnitt unterstützt die Kommunikation mit dem Host 10 über Hostkommunikationsverbindungen, während der Emulationsabschnitt mit dem Ziel kommuniziert, wobei er Ziel-Fehlersuchfunktionen und den Fehlersuchport der Vorrichtung verwaltet. Der Emulator 12 kommuniziert beispielsweise unter Verwendung einer der vorstehend erwähnten Industriestandard-Kommunikationsverbindungen bei 15 mit dem Hostcomputer 10. Die Host-Emulator-Verbindung kann mit Standard-Verkabelungstechnologie eingerichtet werden. Die Host-Emulator-Trennung wird durch die Standards bestimmt, die auf die verwendete Schnittstelle angewendet werden.
Die Emulationssteuereinrichtung 12 kommuniziert mit dem Zielsystem 16 bei 17 über ein oder mehrere Zielkabel. Fehlersuch-, Überwachungs-, Auslöse- und RTDX-Fähigkeiten verwenden das Zielkabel und in manchen Fällen dieselben Anschlussstifte der Vorrichtung gemeinsam. Es kann mehr als ein Zielkabel erforderlich sein, wenn das Zielsystem eine Überwachungsbreite verwendet, die nicht in einem einzigen Kabel untergebracht werden kann. Die gesamte Überwachungs-, RTDX- und Fehlersuchkommunikation geschieht über diese Verbindung.
2 zeigt schematisch relevante Abschnitte als Beispiel dienender Ausführungsformen des Emulationssystems aus 1. 2 weist eine Scan-Schnittstelle auf, die in dem Kabel 17 zwischen dem Emulator 12 und dem Zielchip 14 bereitgestellt ist. Wie in 2 dargestellt ist, kann der Emulator 12 beliebige von mehreren Betriebsmodi für die Scan-Schnittstelle auswählen. Bei den hier offenbarten Beispielen ist die Scan-Schnittstelle eine Standard-JTAG-Scan-Schnittstelle, die Erfindung ist jedoch auch auf andere Typen von Scan-Schnittstellen anwendbar. Hier stellt der Modus J_5 das Standard-JTAG-Format dar, bei dem fünf Anschlussstifte des Zielchips verwendet werden. Die Modi J_4 und J_3 bezeichnen Modi der Scan-Operation, bei denen eine Zeitmultiplexierung verwendet wird, um zwei oder mehr der fünf JTAG-Signale an einem einzigen Anschlussstift der Scan-Schnittstelle zu kombinieren und dadurch einen oder mehrere der fünf Anschlussstifte freizugeben, die normalerweise der Standard-J_5-Operation zugeordnet sind. Der Modus J_4 multiplexiert zwei JTAG-Signale auf einen einzigen Anschlussstift und benötigt demgemäß vier Anschlussstifte für die Scan-Operation, wodurch ein Anschlussstift für andere Zwecke, wie andere Fehlersuchfunktionen, freigegeben wird. Der Modus J_3 multiplexiert drei JTAG-Signale auf einen einzigen Anschlussstift und benötigt daher nur drei Anschlussstifte für die Scan-Operation, wodurch zwei Anschlussstifte für andere Zwecke, wie andere Fehlersuchoperationen, freigegeben werden. Im Modus J_1 wird keine Multiplexierung verwendet, sondern es bleibt nur das TRST-(Testlogikrücksetz)-Signal der Scan-Schnittstelle zugewiesen, wodurch vier Anschlussstifte für andere Zwecke, wie die Fehlersuchoperation, freigegeben werden.
3 bietet eine Beschreibung von jedem der vorstehend beschriebenen Modi der Scan-Operation. Es sei bemerkt, dass der J_1-, der J_4- und der J_3-Modus auf Punkt-zu-Punkt-Verbindungen zwischen dem Emulator und einer einzigen Zielvorrichtung beschränkt sind, während J_5 natürlich auf jede beliebige Anzahl Scan-verketteter Zielvorrichtungen anwendbar ist.
Unter erneutem Bezug auf 2 sei bemerkt, dass der Zielchip einen Scan-Schnittstellenadapter 21 aufweist, der für die Umwandlung der nach einem der Modi J_5, J_4 und J_3 vom Emulator empfangenen Signale in eine Fünf-Signal-Schnittstelle, die mit dem J_5-Format identisch ist, in diesem Beispiel die JTAG- Schnittstelle mit fünf Anschlussstiften, verantwortlich ist. Mit anderen Worten entspricht das Signal MSCAN IN dem TDI der J_5-Schnittstelle. Das Signal MTRST entspricht dem Signal TRST der J_5-Schnittstelle. Das Signal MTCK entspricht dem Signal TCK der J_5-Schnittstelle. Das Signal MTMS entspricht dem Signal TMS der J_5-Schnittstelle, und das Signal MSCAN OUT entspricht dem Signal TDO der J_5-Schnittstelle. Demgemäß übersetzt der Scan-Schnittstellenadapter 21 diese Schnittstelle, unabhängig von dem vom Emulator 12 verwendeten Schnittstellenmodus J_5, J_4 oder J_3, in diesem Beispiel in eine Fünf-Signal-JTAG-Schnittstelle zur Teststeuerung mehrerer in den Zielchip eingebetteter Kerne. Umgekehrt wandelt der Scan-Schnittstellenadapter 21 die innerhalb des Chips verwendete Fünf-Signal-Schnitstelle in das Signalformat um, das vom Scan-Schnittstellenmodus benötigt wird, der auf der Emulatorseite ausgewählt worden ist.
4 zeigt schematisch die Scan-Schnittstellen-Signalverbindungen zwischen dem Emulator und dem Zielchip während der J_4-Operation. In der J_4-Konfiguration wird die Emulator-TDO-zu-Chip-TDI-Verbindung zum Multiplexieren sowohl des TMS-Signals vom Emulator als auch des TDO-Signals vom Emulator verwendet. Diese zeitmultiplexierten Signale (TDM-Signale) werden am TDI-Anschlussstift der Zielvorrichtung empfangen. Der Scan-Schnittstellenadapter innerhalb der Zielvorrichtung wandelt dann von der Schnittstelle mit vier Anschlussstiften in das Standard-Fünf-Signal-JTAG-Format um, wie vorstehend mit Bezug auf 2 beschrieben wurde. Wie in 4 angegeben ist, ist der TMS-Signalweg zwischen der Zielvorrichtung und dem Emulator für andere Zwecke, wie Fehlersuchfunktionen, frei.
5 zeigt die Scan-Schnittstellenverbindungen zwischen dem Emulator und einem Zielchip, wenn das J_3-Scan-Format verwendet wird. In der J_3-Konfiguration wird die Emulator-TDI-zu-Chip-TDO-Verbindung als ein bidirektionales Signal verwendet, auf dem das TMS-Signal vom Emulator, das TDO-Signal vom Emulator und das TDI-Signal vom Zielchip zeitmultiplexiert werden. Wie in 5 dargestellt ist, gibt diese Konfiguration zwei Verbindungen zwischen dem Emulator und dem Zielchip (TMS- und Ziel-TDI-zu-Emulator-TDO) für andere Zwecke, wie Fehlersuchfunktionen, frei.
Die erwähnte J_1-Konfiguration ermöglicht, dass vier der fünf Scan-Schnittstellenverbindungen für andere Zwecke, wie Fehlersuchfunktionen, verwendet werden und dass die Scan-Schnittstelle die Kontrolle nur der TRST-Verbindung behält, so dass der Emulator den Scan-Schnittstellenadapter 21 noch selektiv für Scan-Operationen konfigurieren kann (was natürlich in der J_1-Konfiguration nicht möglich ist). Insbesondere bewirkt das Aktivieren von TRST durch den Emulator, dass der Scan-Schnittstellenadapter 21 die Scan-Schnittstelle auf eine Standard-Scan-Schnittstelleneinstellung, beispielsweise J_3, J_4 oder J_5, legt. Die Standardeinstellung kann vom Chiparchitekten spezifiziert werden, und die Emulatorsoftware kann leicht mit einer beliebigen ausgewählten Standardoperation kompatibel gemacht werden.
6 zeigt als Beispiel dienende Operationen, die vom Scan-Schnittstellenadapter und vom Emulator im J_4-Modus ausgeführt werden können. Wie in 6 dargestellt ist, steuert eine Zustandsmaschine innerhalb des Emulators die Ein- und Ausgabesequenz für die J_4-Schnittstellenkonfiguration. Die Zustandsmaschine weist neun Zustände zum Steuern der J_4-Ein- und -Ausgabe auf. Die Zustandssequenz beginnt mit einem Anfangsbit, gefolgt von vier TMS-Werten, gefolgt von vier TDI-Werten. Der Scan-Schnittstellenadapter in der Zielvorrichtung weist auch eine Zustandsmaschine auf, die verwendbar ist, um von der J_4-Schnittstelle in die J_5-Schnittstelle zu konvertieren, was das Aktivieren des Signals MTCK aus 2 nur während vier Zuständen (0 × 4, 0 × 5, 0 × 6 und 0 × 7) der Neun-Zustands-Sequenz einschließt, wobei diese vier Zustände für die TDO-Ausgabe vom Ziel zum Emulator und für die parallele TMS/TDI-Ausgabe vom Scan-Schnittstellenadapter zu den Kernen verwendet werden.
Gemäß einer Ausführungsform wird die Zustandsmaschine innerhalb des Scan-Schnittstellenadapters des Chips in einen Anfangszustand (0 × F) gezwungen, wenn eine 0 an den TRST-Anschlussstift des Zielchips aus 4 angelegt wird. Die Zustandsmaschine kann gemäß manchen Ausführungsformen auch in den Anfangszustand gezwungen werden, falls das TDO-Signal des Emulators während mindestens 9 aufeinander folgender Zyklen von TCK eine logische 1 ist, wenn TCK kontinuierlich läuft. Während sich der Scan-Schnittstellenadapter im Anfangszustand befindet, aktiviert er eine Testrücksetzung (MTRST in 2) an den Kernen des Zielchips und bleibt im Anfangszustand, falls er eine logische 1 am TDI-Eingang erfasst. Wenn der Scan-Schnittstellenadapter eine 0 an seinem TDI-Eingang erfasst, während er sich im Anfangszustand befindet, beginnt die Zustandsmaschine mit der in 6 dargestellten Zustandsprogression, wobei der Reihe nach vom Zustand 0 × 0 zum Zustand 0 × 7 übergegangen wird und dann zum Anfangszustand 0 × F übergegangen wird, wo wiederum die Prüfung auf eine logische 0 am TDI-Eingang vorgenommen wird.
7 ist ein Zeitablaufdiagramm, das den in 6 dargestellten J_4-Operationen entspricht.
8 zeigt als Beispiel dienende Operationen, die vom Emulator und vom Scan-Schnittstellenadapter im J_3-Scan-Modus ausgeführt werden können. In diesem Modus initialisiert der Scan-Schnittstellenadapter seine Zustandsmaschine auf den Rücksetzzustand, wenn der Emulator mindestens sechzehn Takte (TCK) zuführt, während eine logische 1 vom Emulator dem TDO-Anschlussstift der Zielvorrichtung zugeführt wird. Die Zustandsmaschine innerhalb des Emulators wirkt mit der Zustandsmaschine des Adapters unter Verwendung von sechzehn Zuständen zusammen, um die J_3-Scan-Operation auszuführen. Die Zustandssequenz beginnt damit, dass der Emulator von seinem TDI-Anschlussstift zum TDO-Anschlussstift der Zielvorrichtung ein Anfangsbit (0), gefolgt von vier TMS-Werten, gefolgt von vier TDI-Werten, sendet. Beim nächsten TCK-Impuls beendet der Emulator das Ansteuern des TDO-Anschlussstifts der Zielvorrichtung. An diesem in 8 mit 81 bezeichneten Punkt steuert weder der Emulator noch die Zielvorrichtung den TDO-Anschlussstift der Zielvorrichtung an.
Beim nächsten TCK-Impuls bei 82 steuert die Zielvorrichtung ihren TDO-Anschlussstift für den ersten von fünf TCK-Zyklen an. Während der ersten vier dieser TCK-Zyklen treibt die Zielvorrichtung Zielvorrichtungs-Scan-Daten TDO_0 – TDO_3 aus. Das Signal MTCK aus 2 wird nur während dieser vier Zustände aktiviert, um eine parallele TMS/TDI-Ausgabe vom Scan-Schnittstellenadapter zu den Kernen zu ermöglichen. Während des fünften TCK-Zyklus treibt die Zielvorrichtung den Wert ihres TDO-Anschlussstifts auf eine logische 1, wie bei 83 dargestellt ist.
Nach dem nächsten TCK-Impuls bei 84 übergibt die Zielvorrichtung die Steuerung ihres TDO-Anschlussstifts an den Emulator, und der Emulator treibt die logische 1. Weil sowohl der Emulator als auch die Zielvorrichtung eine logische 1 treiben, wenn die Steuerung bei 84 gewechselt wird, tritt während dieses Steuerungsaustausches kein Buskonflikt auf. Während des nächsten TCK-Zyklus wendet der Emulator das Anfangsbit an, um die Sequenz aus 8 wieder einzuleiten.
Falls der Standardmodus für den Scan-Schnittstellenadapter J_3 ist, wird die Zustandsmaschine der Zielvorrichtung in den Zustand 0 × F gezwungen, wenn der TRST-Anschlussstift auf 0 getrieben wird. Wenn sich die Zustandsmaschine der Zielvorrichtung, ob durch die Operation von TRST oder durch sequenzielles Durchlaufen der in 8 dargestellten Zustände, im Zustand 0 × F befindet, erwartet die Zustandsmaschine der Zielvorrichtung, dass der Emulator das Anfangsbit der logischen 0 zuführt. Wenn das Anfangsbit nicht erfasst wird, bedeutet dies, dass der Emulator und das Ziel die Synchronisation verloren haben, der Emulator nicht vorhanden ist oder der Emulator und das Ziel in verschiedenen Scan-Schnittstellenmodi arbeiten. Falls die Zustandsmaschine der Zielvorrichtung während des 0 × F-Zustands eine logische 1 erfasst, setzt die Zustandsmaschine der Zielvorrichtung MTRST auf die inneren Kerne der Zielvorrichtung und bleibt im Zustand 0 × F. Wenn eine 0 am TDO-Eingang der Zielvorrichtung erfasst wird, während sich die Zustandsmaschine der Zielvorrichtung im Zustand 0 × F befindet, beginnt die Zustandsmaschine der Zielvorrichtung mit ihrer Zustandsprogression, wobei sie sequenziell vom Zustand 0 × 0 bis zum Zustand 0 × E und dann zum Zustand 0 × F fortschreitet, wo sie wieder die vorstehend erwähnte Prüfung auf ein Anfangsbit der logischen 0 an ihrem TDO-Anschlussstift ausführt. Wenn der Emulator einen kontinuierlich laufenden TCK anwendet und der TDO-Anschlussstift der Zielvorrichtung auf eine logische 1 hochgezogen wird, initialisiert die Zustandsmaschine innerhalb des Scan-Schnittstellenadapters der Zielvorrichtung innerhalb von sechzehn TCK-Zyklen auf die Testrücksetzbedingung, wenn TRST während des Zeitraums nicht aktiviert wird, in dem TDO bei einem kontinuierlich laufenden TCK auf die logische 1 hochgezogen wird.
9 ist ein Zeitablaufdiagramm, das den J_3-Operationen aus 8 entspricht.
Der ausgewählte Scan-Schnittstellenmodus, d.h. J_5, J_4, J_3 oder J_1, kann als TDI-Informationen, beispielsweise als ein Bitpaar mit LSB, gefolgt von MSB, im TDI-Datenstrom vom Emulator zur Zielvorrichtung übertragen werden. Bei manchen Ausführungsformen wird das MSB der Modusinformationen, sobald das LSB der Modusinformationen übertragen worden ist, stets im nächsten TDI-Informationsschlitz übertragen. Anhand einer JTAG-Ausführungsform als Beispiel sei bemerkt, dass die Übertragung von Modusbitpaaren beispielsweise durch die folgenden Bedingungen eingeleitet werden kann:
IDLE-Zustand nach einem TRST-, IR_UPDATE- oder DR_UPDATE-Zustand,
IDLE-Zustand nach einem IDLE-Zustand, während dessen das LSB des Modus übertragen worden ist,
IR_EXIT-Zustand nach einem IR_SCAN-Zustand,
DR_EXIT-Zustand nach einem DR_SCAN-Zustand,
DR_PAUSE-Zustand nach einem DR_CAPTURE-Zustand,
IR_PAUSE-Zustand nach einem IR_CAPTURE-Zustand,
DR_PAUSE-Zustand nach einem DR_PAUSE-Zustand, während dessen das LSB des Modus übertragen worden ist, oder
IR_PAUSE-Zustand nach einem IR_PAUSE-Zustand, während dessen das LSB des Modus übertragen worden ist.
10 zeigt eine als Beispiel dienende Zuordnung von Modusbits zu dem gewünschten Scan-Schnittstellenprotokoll.
11 zeigt schematisch eine als Beispiel dienende Ausführungsform einer Übertragungssteuereinrichtung für die Modusbits aus 10. Das Modus-LSB wird übertragen, wenn das Signal 111 aktiv ist, und das Modus-MSB wird übertragen, wenn das Signal 112 aktiv ist.
Die 14–16 sind Zeitablaufdiagramme, welche als Beispiel dienende Moduswechsel vom J_5-Modus zu den anderen Modi zeigen. Die 17–19 sind Zeitablaufdiagramme, welche als Beispiel dienende Moduswechsel vom J_4-Modus zu den anderen Modi zeigen. Die 20–22 sind Zeitablaufdiagramme, welche als Beispiel dienende Moduswechsel vom J_3-Modus zu den anderen Modi zeigen, und die 23–25 sind Zeitablaufdiagramme, welche als Beispiel dienende Moduswechsel vom J_1-Modus zu den anderen Modi zeigen. In diesen Beispielen sind JM(0) und JM(1) die Modusbits LSB bzw. MSB.
12 zeigt relevante Abschnitte als Beispiel dienender Ausführungsformen des Emulators aus 2, einschließlich der Zustandsmaschine, welche die vorstehend mit Bezug auf die 6–11 beschriebenen Operationen ausführen kann. Wie in 12 dargestellt ist, können die TCK-, TDI-, TDO- und TMS-Verbindungen zur Übermittlung von Nicht-Scan-Informationen zwischen dem Emulator und dem Zielchip verwendet werden, und die Zustandsmaschine kann den TMS-, TDO- und TCK-Leitungen geeigneterweise drei Zustände zuordnen, wenn sie für Nicht-Scan-Zwecke verwendet werden.
13 zeigt schematisch relevante Abschnitte als Beispiel dienender Ausführungsformen der Zielvorrichtung aus den 2, 4 und 5. Wie in 13 dargestellt ist, weist der Scan-Schnittstellenadapter des Zielchips eine Zustandsmaschine 132 auf, welche die vorstehend in Bezug auf die 6–11 beschriebenen Operationen zusammen mit einer Verzögerungsstrecke ausführen kann, die die vom Emulator empfangenen zeitmultiplexierten Informationen geeignet verzögert, um die zeitmultiplexierten Signale zu demultiplexieren. Diese demultiplexierten Signale können dann auf ihren jeweiligen Signalleitungen an die Kerne der Zielvorrichtung ausgegeben werden, wie in 2 dargestellt ist. Weiterhin kann, wie in 13 dargestellt ist, die Zustandsmaschine 132 die TDO-Ausgabe der Zielvorrichtung drei Zuständen zuordnen, wenn diese Verbindung für Nicht-Scan-Zwecke verwendet wird.
13 zeigt auch Konfigurationsschalter bei 135, welche es dem Emulator ermöglichen, auf gewünschte Zielknoten innerhalb der Zielvorrichtung zuzugreifen, um beispielsweise Fehlersuchinformationen zu erhalten. Abhängig von dem ausgewählten Scan-Schnittstellenmodus können die Signalverbindungen für TCK, TDO, TDI und TMS für Nicht-Scan-Zwecke, wie eine Fehlersuchoperation, verwendet werden. Ein Konfigurationsregister 137 ist im Daten-Scan-Pfad der Zielvorrichtung bereitgestellt, um es dem Emulator zu ermöglichen, darin Konfigurationsinformationen zu scannen, welche die Konfiguration der Schalter 135 steuern, so dass auf die gewünschten Knoten innerhalb der Zielvorrichtung zugegriffen werden kann. Die Zustandsmaschine enthält auch eine Dreizustands-Steuerleitung 131, welche den Ausgaben des Konfigurationsschaltabschnitts 135 nach Bedarf drei Zustände zuordnen kann, wenn die zugeordneten Emulatorverbindungen für Scan-Zwecke verwendet werden.
Wiederum mit Bezug auf die 10, 11 und 14–25 sei bemerkt, dass, wenn die Emulator-Zustandsmaschine in einen Nicht-Scan-Zustand eintritt, neue Modusinformationen, entweder auf dem TDI-Anschlussstift der Zielvorrichtung (für die J_5- oder die J_4-Operation) oder auf dem TDO-Anschlussstift der Zielvorrichtung (für die J_3-Operation), zur Zielvorrichtung gesendet werden können. Wie vorstehend erwähnt wurde, wird bei manchen Ausführungsformen, sobald das LSB übertragen worden ist, stets das MSB im nächsten verfügbaren Emulator-zu-Zielvorrichtung-Scan-Informationsschlitz, ob vom TDI-Anschlussstift des Emulators in den TDO-Anschlussstift der Zielvorrichtung gescannt (für die Modi J_4 und J_5) oder vom TDI-Anschlussstift des Emulators in den TDO-Anschlussstift der Zielvorrichtung gescannt (für die J_3-Operation), übertragen.
Weiterhin sei bemerkt, dass in den Zeitablaufdiagrammen aus den 14–25 das DLY1-Signal die Ausgabe der Verzögerungsstrecke aus 13, beispielsweise einer Vier-Bit-Verzögerungsstrecke, die zum Verzögern der TMS-Werte in den Modi J_3 und J_4 erforderlich ist, ist (siehe auch die 6 und 8). Das Signal GTCK ist eine von der Zustandsmaschine 132 erzeugte geschaltete Version von TCK zum Treiben des Signals MTCK aus 2 während der J_4-Operationen aus den 6 und 7 und während der J_3-Operationen aus den 8 und 9.
Ein Scan-Schnittstellenadapter gemäß anderen Ausführungsformen der Erfindung kann nur zwischen J_3 und J_5 oder zwischen J_4 und J_5 konvertieren. Bei diesen als Beispiel dienenden Ausführungsformen kann der Emulator automatisch feststellen, welche Konvertierung (falls überhaupt) unterstützt wird, indem er versucht, zuerst nach dem J_3-Protokoll, dann nach dem J_4-Protokoll und dann nach dem J_5-Protokoll mit der Zielvorrichtung zu kommunizieren. Die Zielvorrichtung antwortet nur dann richtig, wenn das richtige Protokoll vom Emulator verwendet wird.
In Bezug auf den J_1-Scan-Schnittstellenmodus sei bemerkt, dass die Scan-Schnittstelle in diesem Modus tatsächlich deaktiviert ist. Der Emulator erwartet, dass die normalerweise TCK-, TMS-, TDI- und TDO-Funktionen zugewiesenen Anschlussstifte anderen Funktionen, wie Fehlersuchfunktionen, zugewiesen werden. Die Zustandsmaschine im Scan-Schnittstellenadapter wird in den Zustand 0 × F gezwungen (siehe auch die 6 und 8), während der Modus J_1 ist.
Das Setzen von TRST durch den Emulator bewirkt, dass der Modus asynchron von J_1 in den Standardmodus wechselt (entweder J_3, J_4 oder J_5), wie in den 23–25 dargestellt ist.
Wie vorstehend gezeigt wurde, ermöglicht die vorliegende Erfindung durch die Verwendung der Zeitmultiplexierung innerhalb einer Scan-Schnittstelle und weiter durch Ermöglichen des Deaktivierens der Scan-Schnittstelle, dass Emulator-zu-Zielvorrichtung-Verbindungen, die normalerweise der Scan-Schnittstelle zugewiesen sind, selektiv anderen gewünschten Funktionen, beispielsweise Fehlersuchfunktionen, zugewiesen werden, welche auf diese Weise den gewöhnlichen Funktionen der Scan-Schnittstelle überlagert werden. Hierdurch werden vorteilhafterweise mehr Anschlussstifte der Zielvorrichtung für eine gewünschte Nicht-Scan-Kommunikation mit dem Emulator bereitgestellt.
Wenngleich als Beispiel dienende Ausführungsformen der Erfindung vorstehend detailliert beschrieben wurden, wird der Schutzumfang der Erfindung, welche in einer Vielzahl von Ausführungsformen verwirklicht werden kann, hierdurch nicht eingeschränkt.

Claims

Verfahren zum Unterstützen der Kommunikation mit einer Scan-Schnittstelle, wobei mehrere Signale verwendet werden, die normalerweise jeweils über jeweilige Signalwege der Scan-Schnittstelle übertragen werden, mit den folgenden Schritten: Bereitstellen eines ersten Signals, das der Scan-Schnittstelle zugeordnet ist, Bereitstellen eines zweiten Signals, das der Scan-Schnittstelle zugeordnet ist, Zeitmultiplexieren des ersten und des zweiten Signals auf einen einzigen Signalweg, dadurch gekennzeichnet, dass das erste und das zweite Signal auf jeweilige entsprechende Signalwege der Scan-Schnittstelle demultiplexiert werden.
Verfahren nach Anspruch 1 mit den folgenden Schritten: Bereitstellen eines weiteren Signals, das der Scan-Schnittstelle zugeordnet ist, und Zeitmultiplexieren des weiteren Signals zusammen mit dem ersten und dem zweiten Signal auf dem einzigen Signalweg.
Verfahren nach Anspruch 2, wobei das erste und das zweite Signal Datensignale sind und das weitere Signal ein Steuersignal ist.
Verfahren nach Anspruch 3, welches weiter die folgenden Schritte aufweist: Empfangen des ersten, des zweiten und des dritten Signals auf dem einzigen Signalweg und Demultiplexieren des ersten, des zweiten und des dritten Signals auf jeweilige entsprechende Signalwege der Scan-Schnittstelle.
Verfahren nach einem der Ansprüche 1 bis 4, wobei die Scan-Schnittstelle eine JTAG-Schnittstelle ist.
Scan-Adaptervorrichtung mit einem ersten Kommunikationsport (17) zur Kommunikation mit einem Emulator (12) über ein erstes und ein zweites Signal, die einer Scan-Schnittstelle zugeordnet sind und auf einen einzigen Signalweg des ersten Kommunikationsports (J_1, J_2, J_4) und eines zweiten Kommunikationsports (MSCAN IN, MTRST, MTCK, MTMS, MASCAN OUT) zur Kopplung mit der Scan-Schnittstelle zeitmultiplexiert sind, dadurch gekennzeichnet, dass sie aufweist: einen Adapter (21), der zwischen den ersten und den zweiten Kommunikationsport geschaltet ist, um die zeitmultiplexierten ersten und zweiten Signale zu empfangen und ansprechend darauf das erste und das zweite Signal auf jeweiligen Signalwegen des zweiten Kommunikationsports bereitzustellen.
Vorrichtung nach Anspruch 6, wobei der Adapter (21) eine Zustandsmaschine (132) zur Verbindung zwischen dem ersten und dem zweiten Kommunikationsport aufweist.
Vorrichtung nach Anspruch 6, wobei der Adapter (21) eine Verzögerungsstrecke (VERZÖGERUNGSSTRECKE, 13) zum Demultiplexieren der zeitmultiplexierten ersten und zweiten Signale aufweist.
Vorrichtung nach Anspruch 6, wobei der erste Kommunikationsport (17) weiter der Kommunikation mit dem Emulator (12) über ein weiteres Signal, das der Scan-Schnittstelle zugeordnet ist und zusammen mit dem ersten und dem zweiten Signal auf den einzigen Signalweg zeitmultiplexiert ist, dient, und der Adapter (21) weiter verwendbar ist, um das erste, das zweite und weitere Signale auf jeweiligen Signalwegen des zweiten Kommunikationsports bereitzustellen.
Vorrichtung nach Anspruch 6, wobei die Scan-Schnittstelle eine JTAG-Schnittstelle ist.
Vorrichtung nach Anspruch 6, welche weiter aufweist: einen Datenverarbeitungskern (KERN, 2), der mit der Scan-Schnittstelle verbunden ist, um dazwischen eine Scan-Kommunikation auszuführen, und eine integrierte Schaltung, in der die Scan-Schnittstelle, der Scan-Schnittstellenadapter und der Datenverarbeitungskern angeordnet sind.