DE60212455T2 - System und verfahren zum takten eines ip-core während einer fehlersuchoperation - Google Patents

Description

• Die vorliegende Erfindung betrifft ein System und ein Verfahren zum Takten eines IP-Kerns während einer Fehlersuchoperation.
• Im Design von integrierten Schaltungen gibt es eine zunehmende Nachfrage nach Emulations- und Prüfwerkzeugen. Auf Hardware beruhende Prüflösungen gibt es seit Jahren in zwei unterschiedlichen Ausführungsformen: Beschleuniger und Emulatoren. Nützliche Werkzeuge in Emulationssystemen sind sogenannte IP-Xpress-Sätze, die emulationsbereite Sätze zur gleichzeitigen Hardware- und Softwareprüfung von auf Prozessoren beruhenden Systemen sind. Solche IP-Xpress-Sätze verwenden Mikroprozessor- oder DSP-Chips, die auf einer gedruckten Schaltung angebracht sind, um die Funktionalität der Vorrichtung bereitzustellen, die mit einem Design verbunden werden soll, das im Emulator abgebildet wird, und die Sätze bestehen aus einer Schaltkarte und HDL-Hülldateien.
• Alle Prozessor-IP-Kerne benötigen eine gewisse äußere Taktquelle. Folglich werden ein oder mehrere Taktsignale für die IP-Xpress-Karten (d.h. Prozessorkarten oder Prozessorzielkarten) bereitgestellt. Die Takte werden entweder direkt von den inneren Taktgeneratoren des Emulators geliefert, oder sie können vom Design geliefert werden, das auf den Emulator geladen wird.
• Eine andere Art der Bereitstellung eines Takts für einen IP-Kern ist die Verwendung eines Taktoszillators, der auf der IP-Xpress-Karte angebracht ist. In diesem Fall kann jede Frequenz angelegt werden, d.h. es gibt keine Einschränkungen der maximalen Taktfrequenz infolge des Emulationssystems.
• Ein Hauptvorteil eines IP-Xpress-Satzes ist es, eine schnell laufende Prüfumgebung bereitzustellen, in der eine Anwendungssoftware auf dem IP-Kern läuft und das Design stimuliert, das auf den Emulator abgebildet ist. Im Fall eines fehlerhaften Systemverhaltens könnte der Grund dafür entweder in der Anwendungssoftware oder im Design liegen (vorausgesetzt der IP-Kern funktioniert korrekt). Um die fehlerhafte Komponente des Systems zu identifizieren, müssen sowohl die Anwendungssoftware als auch das Design ausgetestet werden. Dies kann am günstigsten durchgeführt werden, wenn die Hardware und Software synchron gestoppt werden. Einerseits ergibt dies eine gute Korrelation zwischen dem Status des Designs und der tatsächlichen Softwareausführung, und ermöglicht es andererseits, alle Ressourcen des Designs abzufragen, die auf das Emulatorsystem abgebildet werden. Dies kann jedoch bedeuten, daß die Emulatortakte gestoppt werden. Falls der IP-Kern durch einen Takt getaktet wird, der durch das Emulatorsystem erzeugt wird, würde dies bedeuten, daß der IP-Kern nicht mehr getaktet wird. Folglich würde die Softwarefehlersucheinrichtung nicht unbedingt arbeiten, und als Ergebnis wären die Ressourcen der Softwareausführung nicht sichtbar, und eine vollständige Fehlersuche im System wäre nicht möglich.
• Der Artikel „Co-Emulation and Debugging of HW/SW-Systems" von G. Koch u.a. beschäftigt sich allgemein mit den Eigenschaften von Systemen, die ausgetestet werden, und welche dieser Eigenschaften zur Problemen führen könnten, wenn die Ausführung einer Systemkomponente infolge eines Haltepunkts gestoppt wird. Das Hauptproblem, das auftreten würde, ist ein Datenverlust, da einer der beiden Prozesse (entweder in Hardware oder Software) infolge eines Haltepunkts gestoppt wird, wohingegen der andere Prozeß weiter Daten an den gestoppten Prozeß sendet, die nicht richtig aufgenommen werden können. Der Ansatz, den die Autoren dieses Artikels vorschlagen, ist, daß es für einen gegebenen Prozeß nicht nur das ursprüngliche Modell geben würde, das die beabsichtigte Funktionalität abdeckt, sondern es auch ein zweites, alternatives Fehlersuchmodell dieses Prozesses geben wür de, das zusätzlich zur ursprünglichen Funktionalität bestimmte interne Zustände und eine bestimmte externe Signalisierung ermöglicht, um anzuzeigen, daß ein gestoppter Prozeß keine Daten aufnehmen kann und der andere Prozeß es später erneut versuchen soll. Dies setzt im Grunde voraus, daß die Kommunikation zwischen den beiden Prozessen auf einer Quittierungsüberwachung beruht und imstande ist, Daten erneut zu senden.
• Es ist die Aufgabe der vorliegenden Erfindung, ein System und ein Verfahren zum Takten eines IP-Kerns während einer Fehlersuchoperation bereitzustellen. Diese Aufgabe wird durch die Merkmale der Ansprüche gelöst.
• Um diese Aufgabe zu lösen, ist erfindungsgemäß die Takterzeugung für den IP-Kern, wenn er in die Systemfehlersuchbetriebsart eintritt, auf der IP-Xpress-Karte selbst ausgeführt. Es sich ein Taktoszillator und eine Schalteinrichtung vorgesehen, und die Schalteinrichtung schaltet auf den Taktoszillator, der auf der IP-Xpress-Karte vorgesehen ist, sobald in die Systemfehlersuchbetriebsart eingetreten wird. Um die Schaltoperation einzuleiten, überwacht die Schalteinrichtung Signale, die für den IP-Kern spezifisch sind, die einen Haltepunkt anzeigen, z.B. EMU0/1 im Fall von TI C6x DSPs, und wenn diese anzeigen, daß ein Haltepunkt erfaßt worden ist, wird die Taktausgabe der Schalteinrichtung vom Taktoszillator betrieben. Folglich wird er IP-Kern selbst dann kontinuierlich getaktet, wenn die Takte des Emulatorsystems gestoppt werden. Ferner ist die Softwarefehlersucheinrichtung immer noch in ihrer Systemfehlersuchbetriebsart funktionsfähig, und alle internen IP-Kern-Ressourcen und der Softwareausführungsstatus können untersucht werden.
• Beim Verlassen der Systemfehlersuchbetriebsart wird der Schalteinrichtung signalisiert, auf die Takte des Emulatorsystems zurückzuschalten, und die Systemausführung kann in ihrer normalen Betriebsart weitergehen.
• Die vorliegende Erfindung wird nun unter Bezugnahme auf die Figur beschrieben. Die Figur zeigt eine bevorzugte Ausführungsform der vorliegenden Erfindung, die eine Schalteinrichtung 1 aufweist. Mit der Schalteinrichtung ist ein Taktoszillator 2 verbunden. Auf der linken Seite der Figur werden zwei mögliche Taktquellen für den Normalbetrieb des Emulatorsystems gezeigt. Diese Taktsignale werden durch die Rückwandplatine des Emulatorsystems auf der IP-Xpress-Karte betrieben. Das Signal gpc2i_clkin ist ein Treibertakt vom Design, und gpc2i_j17_clkin ist ein Takt direkt aus dem Generator des Emulators. Abhängig vom Auswahlsignal, das an den Multiplexer 3 geliefert wird, wird einer dieser Takte an den IP-Kern geliefert. Zum Beispiel ist der IP-Kern ein DSP. Der Taktoszillator 2, die Schalteinrichtung 1 und die Signale, die einen Haltepunkt anzeigen, bilden den Taktgenerator, wenn in die Haltepunktbetriebsart eingetreten wird. Die Ausgabe der Schalteinrichtung ist ein Taktsignal, das den IP-Kern taktet.
• Während des Normalbetriebs des Emulatorsystems führt die Schalteinrichtung einen „regulären" Takt durch ihren Ausgang zu. Wenn in die Systemfehlersuchbetriebsart eingetreten wird, schaltet die Schalteinrichtung von diesem „regulären" Takt auf den Taktoszillator, der auf der IP-Xpress-Karte vorgesehen ist.
• Die folgenden Codebruchteile zeigen, wie das Umschalten auf den Taktoszillator in der Schalteinrichtung implementiert werden kann.
• 
• 
• 

Claims (7)

1. Verfahren zum Takten eines IP-Kerns während einer Fehlersuchoperation, gekennzeichnet durch Umschalten von dem Takt, der zum Testen eines Designs verwendet wird, das auf einen Emulator abgebildet wird, auf einen Taktoszillator oder jede freischwingende Taktquelle (2).
2. Verfahren nach Anspruch 1, wobei der Taktoszillator auf der IP-Prozessorkarte vorgesehen ist.
3. Verfahren nach Anspruch 1 oder 2, wobei der Takt, der zum Testen des Designs verwendet wird, entweder: a) ein Takt ist, der aus dem Design erhalten wird, das in den Emulator abgebildet wird b) ein Takt ist, der direkt aus den Taktgeneratorschaltungen des Emulators erhalten wird, oder c) ein Taktoszillator ist, der lokal auf der IP-Prozessortochterkarte angebracht ist, oder irgendeine freischwingende Taktquelle.
4. Verfahren nach Anspruch 1, 2 oder 3, das den Schritt der Überwachung von Signalen aufweist, die für den IP-Kern spezifisch sind, die einen Haltepunkt anzeigen, um den Haltepunkt zu detektieren.
5. Verfahren nach einem der Ansprüche 1 bis 4, wobei das Umschalten bei der Detektion durchgeführt wird, daß der Haltepunkt erfaßt worden ist.
6. Verfahren nach einem der Ansprüche 1 bis 5, wobei der IP-Kern ein Mikroprozessor oder ein DSP ist.
7. System zum Takten eines IP-Kerns während einer Fehlersuchoperation, dadurch gekennzeichnet, daß es aufweist: eine Schalteinrichtung (1); einen Taktoszillator oder irgendeine freischwingende Taktquelle (2); und eine Steuereinrichtung zum Senden eines Steuersignals an die Schalteinrichtung (1), wenn die Fehlersuchoperation gestartet wird, um die Schalteinrichtung (1) auf den Taktoszillator oder irgendeine freischwingende Taktquelle (2) umzuschalten.