DE19949377A1 - Automatische Speicherung einer Trigger-Definition in einem Signalmeßsystem - Google Patents

Abstract

Ein System und Verfahren zum automatischen Speichern und Abrufen zur Verwendung in einem Signalmeßsystem, das Signaldaten gemäß einer Triggerspezifikation erfaßt und speichert, wobei eine Triggerspezifikation allgemein eine Triggerdefinition und Triggersteuerparameter umfaßt, liefern eine automatische Speicherung von Trigger-bezogenen Daten in einem Speicher, die beispielsweise eine gegenwärtige Triggerdefinition und andere spezifizierte Abschnitte einer Triggerdefinition umfassen, ohne daß eine explizite Anforderung eines Betreibers stattfindet. Eine Mehrzahl von solchen gespeicherten Triggerspezifikationen wird später verfügbar, um von dem Speicher wiedergewonnen zu werden. Dies versetzt einen Betreiber in die Lage, ohne weiteres zu einer früheren Version einer Triggerdefinition zurückzukehren, falls der Betreiber bestimmt, daß eine gegenwärtige Triggerdefinition unerwünscht ist. Das automatische Speichern von Triggerspezifikationen kann ansprechend auf eines oder auf mehrere vorbestimmte Ereignisse auftreten. Bei einem Aspekt der Erfindung umfassen vorbestimmte Ereignisse den Versuch des Benutzers, Daten zu erfassen. Es sei angemerkt, daß dieser Aspekt der vorliegenden Erfindung die Bedürfnisse des Betreibers vorweg nimmt, eine Triggerdefinition zu speichern, da Triggerdefinitionen, die verwendet werden, um Daten zu erfassen, für den Betreiber möglicherweise wichtig sind. Das heißt, daß dieser Aspekt der vorliegenden Erfindung die inhärente Korrelation zwischen einer ...

Description

Die vorliegende Erfindung bezieht sich allgemein auf Signal­ meßsysteme und insbesondere auf das Speichern von Trigger- Spezifikationen in einem Signalmeßsystem.

Analysatoren und Tester sind üblicherweise dazu da, bei der Entwicklung, Herstellung und Fehlerbehebung von komplexen digitalen Elektronik/Software-Geräten und integrierten Schaltungen zu helfen, die Mikroprozessoren, Direktzugriffs­ speicher (RAM; RAM = Random Access Memory), Nur-Lese-Spei­ cher (ROM; ROM Read-Only-Memory) und andere Schaltungen um­ fassen. Solche Analysatoren und Tester, die in dieser Anmel­ dung als Signalmeßsysteme bezeichnet werden, umfassen Logik­ analysatoren, Digitaloszilloskope, Protokollanalysatoren, Mikroprozessoremulatoren, Bitfehlerratentester, Netzwerkana­ lysatoren und andere Geräte. Logikanalysatoren werden immer mehr für diesen Zweck eingesetzt und sind von einer Anzahl von Herstellern, wie z. B. der Hewlett-Packard Company, Tektronix Inc. und anderen kommerziell erhältlich.

Logikanalysatoren sind digitale Datenerfassungsgeräte, die es einem Betreiber ermöglichen, digitale Signaldaten von ei­ ner großen Anzahl von Logiksignalen ("Signalen") zu erfassen und anzuzeigen, wie z. B. solche Signale, die über Adres­ sen-, Daten- und Steuerleitungen eines zu testenden Elements (DUT; DUT = Device Under Test) laufen. Ein zu testendes Ele­ ment kann eines oder mehrere getrennt gehäuste Bauelemente, wie sie beispielsweise oben angeführt wurden, sowie andere Schaltungen und Geräte umfassen.

Die Signale werden auf fest verdrahteten Leitungen, die als Kanäle bezeichnet werden, von dem zu testenden Element er­ faßt. Die Kanäle können physisch in Gruppen angeordnet sein, die allgemein als Baugruppen oder Pods bezeichnet werden. Die empfangenen Signale werden abgetastet und digitalisiert, um Signaldaten zu bilden. Das Digitalisieren umfaßt typi­ scherweise das Vergleichen eines Spannungsbetrags jedes Lo­ giksignalabtastwerts mit einer Referenzspannungsquelle, um den logischen Zustand des Signals zu bestimmen. Das Abtasten kann bei einer Anzahl von auswählbaren Raten abhängig von der Frequenz, mit der die abgetasteten Signale ihre logi­ schen Zustände ändern, stattfinden. Die resultierenden Si­ gnaldaten werden unter der Steuerung eines Abtasttakts in einem Signaldatenspeicher gespeichert, der allgemein eine feste Größe hat. Die Daten werden typischerweise sequentiell gespeichert, so daß aufeinanderfolgende Signalabtastwerte in aufeinanderfolgenden Speicherpositionen gespeichert werden. Aufgrund der Menge von Signaldaten ist der Signaldatenspei­ cher typischerweise als Umbruchpuffer oder "Wrap-Around"- Puffer implementiert.

Die Auswahl des Abschnitts der Signaldaten, die getrennt ge­ speichert und anschließend auf der Anzeige dargestellt wer­ den, wird durch eine Benutzerdefinierte Trigger-Spezifika­ tion bestimmt. Die Trigger-Spezifikation, die auch als Trig­ gereinstellung oder Trigger-Set-Up bezeichnet wird, wird allgemein durch eine Triggerdefinition und eine Anzahl von Parametern spezifiziert, die hier zusammen als Triggersteu­ erparameter oder einfacher ausgedrückt als Triggersteuerun­ gen bezeichnet werden. Die Triggerdefinition identifiziert, wann Signaldaten zu speichern sind. Die Triggersteuerungen identifizieren die Charakteristika der erfaßten Signaldaten, die beispielsweise die relative Position des Auftretens, die durch die Triggerdefinition definiert ist, und die zu spei­ chernden Signaldaten umfassen. Eine vorbestimmte Menge an Signaldaten, die vor und nach dem spezifizierten Auftreten vorhanden sind, wird dann im Speicher gespeichert, um eine anschließende Analyse durchzuführen.

Eine Triggerdefinition, die auch als Triggersequenz bezeich­ net wird, umfaßt einen oder mehrere Triggersequenzpegel.

Jeder Sequenzpegel kann irgendeine Anzahl von Triggerver­ zweigungen umfassen, von denen jede eine Verzweigungsbedin­ gung umfaßt, die bewirkt, daß der Logikanalysator die Hand­ lung ausführt, die in dieser Triggerverzweigung definiert sind. Eine solche Ausführung resultiert im Speichern von Si­ gnaldaten oder in einer Weiterverarbeitung eines folgenden Sequenzpegels. Die schließliche Verzweigungsbedingung, die die Erfassung von Signaldaten bewirkt, wird allgemein auch als Triggerbedingung bezeichnet.

Verzweigungsbedingungen werden durch das Auftreten von einem oder mehreren Ereignissen spezifiziert. Ein Ereignis wird als ein Auftreten von bestimmten Charakteristika oder Eigen­ schaften eines Signals definiert, wie z. B. einer ansteigen­ den oder einer abfallenden Kante, einem logisch hohen oder logisch niedrigen Signalzustand, usw. Die Ereignisse können ebenfalls basierend auf internen Betriebsmitteln, wie z. B. internen Zeitsteuerungen, Zählern, usw., definiert sein. Ty­ pischerweise spezifiziert eine Verzweigungsbedingung eine Anzahl von Ereignissen, die gleichzeitig oder in einer rela­ tiven Zeitsequenz auftreten.

Nachdem die Triggerspezifikation spezifiziert ist, kann der Betreiber eine Messung durchführen, d. h. die Erfassung von Signalabtastwerten initiieren. Wenn eine Signaldatenerfas­ sung initiiert wird, werden die Signaldaten mit der spezifi­ zierten Triggerdefinition verglichen. Wenn die Triggerdefi­ nition erfüllt ist, werden die Signaldaten gemäß den spezi­ fizierten Triggersteuerungen erfaßt. Anschließend kann der Signaldatenspeicher sequentiell ausgelesen werden, um die Signaldaten anzuzeigen.

Das Aufbauen einer korrekten Triggerdefinition kann sehr kompliziert und zeitaufwendig sein. Ein allgemeiner Lösungs­ ansatz zum Entwickeln einer Triggerdefinition besteht darin, einzelne Abschnitte einer Triggerdefinition zu einen gegebe­ nen Zeitpunkt aufzubauen und zu testen. Wenn jeder Abschnitt verifiziert ist, werden zusätzlichen Komplexitätsschichten zu der vorher verifizierten Triggerdefinition hinzugefügt. Beispielsweise beginnen Betreiber eine Triggerspezifika­ tionsentwicklung oft mit einer einfachen Triggerdefinition, führen ein Erfassen durch und untersuchen die erfaßten Da­ ten. Wenn die Ergebnisse so sind, wie es erwartet wird, dann fügt der Betreiber einen anderen Abschnitt, d. h. eine Ver­ zweigung oder ein Ereignis, zu der Triggerdefinition hinzu, um die Triggerdefinition weiter zu definieren, um die er­ wünschten Informationen zu erfassen. Wenn die Verzweigungs­ bedingung nicht so arbeitet, wie es erwünscht wird, wird der Betreiber einen oder mehrere der zuletzt hinzu gefügten Ab­ schnitte der Triggerdefinition eliminieren, um zu versuchen zu einer Triggerdefinition zurückzukehren, von der bekannt ist, daß sie so arbeitet, wie es erwünscht ist. Der Betrei­ ber kann dann einen weiteren Versuch durchführen, um die nächste Verzweigungsbedingung zu entwickeln. Dieses Verfah­ ren wird wiederholt, bis der gegenwärtige Abschnitt der Triggerdefinition so arbeitet, wie es erwartet wird, bevor zusätzliche Komplexitätsschichten hinzugefügt werden.

Es ist jedoch oft schwierig, sich daran zu erinnern, welche Aspekte einer Triggerdefinition während einer Anzahl von vergangenen Erfassungen verändert wurden, welche Verzwei­ gungsbedingungen zu einer erfolgreichen Datenerfassung führ­ ten, usw. Oftmals wurde eine Anzahl von Ereignissen hinzu­ gefügt, oder es wurden frühere Ereignisse und Bedingungen modifiziert. Als Ergebnis verbringen Betreiber oft sehr viel Zeit damit, vergangene Erfassungen zu bewerten, wodurch un­ vermeidbar frühere Arbeit noch einmal durchgeführt wird, um Abschnitte einer Triggerdefinition zu entwickeln, die be­ reits früher verifiziert worden ist. Solche Aktivitäten sind nicht nur zeitaufwendig sondern führen oft dazu, daß neue Betreiber, die mit dem Triggerprozeß nicht vertraut sind, keine nützlichen Erfassungen aufrufen können, ohne daß sie weiter von einem erfahrenen Betreiber unterstützt oder ge­ führt werden. Dies ist darin problematisch, da ein erfahre­ ner Betreiber nicht verfügbar sein könnte und die Laborko­ sten, die der Messung zugeordnet sind, stark ansteigen.

Eine Lösung bestand darin, die Hilfe eines üblichen Merkmals in herkömmlichen Logikanalysatoren zu verwenden, die dem Be­ treiber die Möglichkeit liefert, eine vorbestimmte Anzahl von ausgewählten Triggerspezifikationen zu speichern und an­ schließend von einem Speicher wiederzugewinnen. Allgemein erfordern solche Funktionen, daß der Betreiber eine Anzahl von expliziten Handlungen durchführt, um eine Triggerspezi­ fikation zu speichern. Beispielsweise ist es nicht unüblich, daß ein Betreiber eine Triggerspezifikationsspeicherfunktion über die Implementation eines getrennten dafür vorgesehenen Knopfes, von Softkeys, eines GUI-Knopfes (GUI = Graphical User Interface = graphische Benutzerschnittstelle) oder eines Menügegenstands usw., aufrufen muß. Oftmals muß der Betreiber zuerst durch eine Serie von Soft-Key-Menüs oder GUI-Fenstern laufen, um an der geeigneten logischen Position anzukommen, die diese Funktionsspeicherungsschnittstelle enthält. Sobald sie ausgewählt ist, muß der Betreiber einen Namen oder einen anderen Identifizierer der Triggerspezifi­ kation zuweisen, die gespeichert werden soll. Nachdem die Triggerspezifikation gespeichert ist, muß der Betreiber wie­ der mittels des Soft-Key-Menüs oder des GUI-Fensters navi­ gieren, um die zusätzliche Triggerdefinitionsentwicklung durchzuführen.

Dieser Prozeß ist für einen neuen Betreiber schwierig in seiner Verwendung, unzweckmäßig und für einen erfahrenen Be­ treiber ablenkend. Insbesondere realisiert ein neuer Betrei­ ber oft nicht, daß eine spezielle Verzweigungsbedingung nicht so wie erwartet arbeiten wird, oder er erinnert sich nicht an die Verfügbarkeit der Triggerdefinitionsspeiche­ rungsfunktionalität. Als Ergebnis erzeugen neue Betreiber oft unbeabsichtigterweise eine Triggerspezifikation, die nicht die erwünschten Daten umfaßt, und von denen der Be­ treiber oft nicht ohne weiteres wieder zurückkommt. Somit verbraucht ein typischer neuer Betreiber oft eine beträcht­ liche Zeit und beträchtliche Anstrengungen, um die gegen­ wärtige, nicht-funktionsfähige Triggerdefinition zu editie­ ren, um die problematische Verzweigungsbedingungen zu eli­ minieren, um dann wieder eine weitere Hinzufügung zu der Triggerspezifikation zu entwickeln, deren Erfolg wiederum unsicher ist.

Erfahrenere Betreiber haben ebenfalls Probleme, wenn sie versuchen, eine komplexe Triggerdefinition zu entwickeln. Erfahrene Betreiber stehen oft vor der Situation, daß sie deutlich über eine nicht-gespeicherte Triggerdefinition hin­ ausgegangen sind und wieder zu derselben zurückkehren wol­ len, daß sie jedoch aufgrund der Komplexität der Triggerde­ finition, aufgrund der Zeit, die ausgehend von der früheren Version der Triggerdefinition, die von dem Betreiber gespei­ chert wurde, oder, falls keine gespeichert wurde, seit der Erzeugung der Definition verstrichen ist, und aufgrund der Anzahl von Aspekten der Triggerdefinition, die hinzugefügt oder modifiziert worden sind, dazu nicht mehr in der Lage sind. Somit sehen sich Betreiber herkömmlicher Signalmeßsy­ steme allgemein und insbesondere von Logikanalysatoren durchgehend vor der Aufgabe, daß sie sich erinnern müssen, um wichtige Triggerdefinitionen zu identifizieren, die sie vielleicht wieder während eines Triggerdefinitionsentwick­ lungsprozesses verwenden wollen. Betreiber müssen ebenfalls durchgehend den Vorausblick haben, daß sie wichtige Trigger­ definitionen speichern, oder sie müssen in der Lage sein, zu einem bestimmten späteren Zeitpunkt zwischen den Aspekten einer Triggerdefinition, die zu einer Datenerfassung wie erwartet führten, und denen, die dies nicht erreichten, zu unterscheiden. Wie es bereits ausgeführt worden ist, führt eine solche Bürde dazu, daß der Wirkungsgrad ungünstig be­ einträchtigt wird, mit dem der Logikanalysator verwendet wird.

Die Aufgabe der vorliegenden Erfindung besteht darin, ein effizientes Konzept zur Verwendung eines Signalmeßsystems zu schaffen.

Diese Aufgabe wird durch ein System zur Verwendung in einem Signalmeßsystem nach Patentanspruch 1, durch ein System zum automatischen Speichern und Abrufen nach Patentanspruch 3, durch ein System zum automatischen Speichern nach Patentan­ spruch 4, durch ein Verfahren zum automatischen Speichern und anschließenden Abrufen nach Patentanspruch 20, durch ein Verfahren zum automatischen Speichern und Abrufen nach Patentanspruch 29, durch ein Verfahren zum automatischen Speichern und Abrufen nach Patentanspruch 33 und durch ein System zum automatischen Speichern nach Patentanspruch 35 gelöst.

Die vorliegende Erfindung betrifft ein System und ein Ver­ fahren zur Verwendung in Signalmeßsystemen, die Signaldaten erfassen und speichern gemäß einer Triggerspezifikation, die allgemein eine Triggerdefinition und Triggersteuerparameter ("Triggersteuerungen") umfaßt. Die vorliegende Erfindung speichert in einem Speicher automatisch Trigger-bezogene Da­ ten, die beispielsweise eine gegenwärtige Triggerdefinition und andere spezifizierte Abschnitte einer Triggerspezifi­ kation ("gespeicherte Triggerspezifikationen") umfassen, oh­ ne eine explizite Anforderung durch einen Betreiber. Eine Mehrzahl solcher gespeicherter Triggerspezifikationen werden für eine Wiedergewinnung vom Speicher ("für eine Erinnerung bzw. einen Abruf") später verfügbar. Dies versetzt einen Betreiber in die Lage, ohne weiteres zu einer früheren Version einer Triggerdefinition zurückzukehren, falls er zu dem Schluß kommen sollte, daß eine gegenwärtige Triggerdefi­ nition unerwünscht ist. Das automatische Speichern von Triggerspezifikationen (oder Abschnitten derselben) kann ansprechend auf eines oder mehrere vorbestimmte Ereignisse stattfinden. Bei einem Aspekt der vorliegenden Erfindung umfassen solche vordefinierten Ereignisse bzw. ein solches vordefiniertes Ereignis den Versuch des Betreibers, Daten zu erfassen, woraufhin Triggerdefinitionen gespeichert werden. Es sei darauf hingewiesen, daß dieser Aspekt der vorliegen­ den Erfindung die Bedürfnisse des Betreibers, eine Trigger­ definition zu speichern, vorweg nimmt, da Triggerdefini­ tionen, die verwendet werden, um Daten zu erfassen, für den Betreiber potentiell wichtig sind. Das heißt, daß dieser Aspekt der vorliegenden Erfindung die inhärente Korrelation zwischen einer Triggerdefinition, die aufgerufen wird, und der Wichtigkeit einer solchen Triggerdefinition bei der Entwicklung einer erwünschten Triggerspezifikation vorteil­ haft ausnutzt.

Eine Anzahl von Aspekten der vorliegenden Erfindung werden nachfolgend zusammengefaßt, wobei ferner auf unterschied­ liche Ausführungsbeispiele von jedem der zusammengefaßten Aspekte eingegangen wird.

Ein Aspekt der vorliegenden Erfindung betrifft ein System zur Verwendung in einem Signalmeßsystem, das Signaldaten gemäß einer gegenwärtigen Triggerspezifikation erfaßt und speichert. Das System ist aufgebaut und angeordnet, um einen spezifizierten Abschnitt der gegenwärtigen Triggerspezifi­ kation ansprechend auf ein Auftreten einer vorbestimmten Speicherungsbedingung automatisch zu speichern. Die vorbe­ stimmte Speicherungsbedingung umfaßt nicht Anforderungen von einem Betreiber, um die gegenwärtige Triggerspezifikation zu speichern. Das System liefert ferner einen anschließenden Zugriff auf eine vorbestimmte Anzahl der spezifizierten Triggerspezifikationsabschnitte für eine nachfolgende Erin­ nerung. Vorzugsweise ist die vorbestimmte Speicherungsbe­ dingung der Versuch eines Betreibers, Daten zu erfassen.

Ein weiterer Aspekt der vorliegenden Erfindung betrifft ein System zum automatischen Speichern und Abrufen zur Verwen­ dung in einem Signalmeßsystem, das Digitaldaten gemäß einer Triggerspezifikation erfaßt und speichert. Das System ist aufgebaut und angeordnet, um einen vordefinierten Abschnitt einer gegenwärtigen Triggerspezifikation automatisch und an­ sprechend auf Anforderungen, die von einem Betreiber aufge­ rufen worden sind, zu speichern, und um dem Betreiber einen Zugriff auf eine vorbestimmte Anzahl der gespeicherten vor­ definierten Triggerspezifikationsabschnitte für einen nach­ folgenden Abruf und Verwendung durch den Betreiber zu lie­ fern.

Ein weiterer Aspekt der vorliegenden Erfindung betrifft ein System zum automatischen Speichern zur Verwendung in einem Signalmeßsystem, wie z. B. einem Logikanalysator oder einem Digitaloszilloskop, das Signaldaten gemäß einer Triggerspe­ zifikation erfaßt und speichert, wobei das Signalmeßsystem eine Benutzerschnittstelle und ein Speicherelement hat. Das System speichert automatisch gegenwärtige Trigger-bezogene Daten in einem Speicher, der mit dem System wirksam gekop­ pelt ist. Eine vorbestimmte Anzahl solcher Trigger-bezogener Daten wird für einen nachfolgenden Abruf von dem Speicher gespeichert.

Das System zum automatischen Speichern speichert die Trig­ ger-bezogenen Daten ansprechend auf ein Auftreten einer vor­ bestimmten Speicherungsbedingung, die ausdrücklich keine Ak­ tionen eines Betreibers umfaßt, um die Trigger-bezogenen Da­ ten zu speichern, sondern beispielsweise eine Anforderung eines Betreibers, Signaldaten zu erfassen, oder das Ver­ streichen eines vorbestimmten Zeitintervalls. Die Trigger­ bezogenen Daten können einen Abschnitt einer gegenwärtigen Triggerspezifikation, wie z. B. eine gegenwärtige Trigger­ definition, die eine Triggersequenz definiert, die gegenwär­ tig auf der Benutzerschnittstelle angezeigt wird, umfassen, wenn der Betreiber gerade eine Messung durchführt. Die Trig­ ger-bezogenen Daten können ebenfalls einen oder mehrere ge­ genwärtige Triggersteuerparameter umfassen, die die Art und Weise definieren, auf die Signaldaten gespeichert werden. Triggersteuerparameter können beispielsweise eine Triggerpo­ sition, die eine relative Position der Triggerbedingung und der Signaldaten, die gespeichert werden, definiert, eine Speichertiefe, die eine Menge von Signaldaten identifiziert, die in dem Speicherelement beim Auftreten der Speicherbedin­ gung gespeichert werden sollen, oder eine Abtastrate, die eine Frequenz definiert, mit der die Signaldaten beim Auf­ treten der Speicherungsbedingung abgetastet und gespeichert werden sollen, etc. umfassen.

Bei einem Ausführungsbeispiel umfaßt das System eine Auto­ speicherungssteuerung, die angeordnet und aufgebaut ist, um einen oder mehrere Eingangssignale zu empfangen, die Ereig­ nisse identifizieren, die die vorbestimmte Speicherungsbe­ dingung definieren. Die Autospeicherungssteuerung ist eben­ falls aufgebaut und angeordnet, um die Trigger-bezogenen Da­ ten in einer Region des Speicherelements zu speichern, wenn eines oder mehrere empfangene Ereignisse ein Auftreten der vorbestimmten Speicherungsbedingung anzeigen. Das System um­ faßt ferner eine Abrufsteuerung, die aufgebaut und an­ geordnet ist, um von einer einer Mehrzahl von Speicherele­ mentregionen Betreiber-spezifizierte Trigger-bezogene Daten wiederzugewinnen, die einem früheren Auftreten der Speiche­ rungsbedingung zugeordnet sind, und um die wiedergewonnenen Trigger-bezogenen Daten zu der Benutzerschnittstelle zu lie­ fern.

Bestimmte Ausführungsbeispiele umfassen ferner ein Zeiger­ array, auf das durch die Autospeicherungssteuerung und die Abrufsteuerung zugegriffen werden kann. Das Zeigerarray umfaßt Zeiger, von denen jeder eine der Mehrzahl von Speicherelementregionen identifiziert. Das Zeigerarray um­ faßt ferner Triggernamen, von denen jeder einem der Zeiger zugeordnet ist, und die eine Beschreibung der Trigger-bezo­ genen Daten liefern, die in der Speicherelementregion ge­ speichert sind, die durch den zugeordneten Zeiger identifi­ ziert wird. Die Triggernamen zeigen vorzugsweise eine Rela­ tivsequenz an, in der die entsprechenden Trigger-bezogenen Daten gespeichert worden sind. Bei solchen Ausführungsbei­ spielen kann ferner eine Zeigerpuffersteuerung, die aufge­ baut und angeordnet ist, um eine Zuordnung zwischen den Triggernamen und den Zeigern zu halten, in dem Zeigerarray vorhanden sein, so daß die Triggernamen die Relativsequenz, in der die entsprechenden Trigger-bezogenen Daten gespei­ chert worden sind, wiedergeben.

Ein anderer Aspekt der Erfindung betrifft ein Verfahren zum automatischen Speichern und anschließenden Abrufen einer Triggerdefinition in einem Signalmeßsystem, das Signaldaten gemäß einer Triggerspezifikation umfaßt, die eine Trigger­ definition und einen oder mehrere Triggersteuerungsparameter umfaßt. Das Verfahren umfaßt folgende Schritte: 1) automati­ sches Speichern einen gegenwärtigen Triggerdefinition an­ sprechend auf eine vorbestimmte Anzahl von jüngsten Signal­ erfassungsanforderungen; und 2) Liefern eines Zugriffs durch den Betreiber auf die vorbestimmte Anzahl von vorher gespei­ cherten Triggerdefinitionen. Vorzugsweise umfaßt das Verfah­ ren ferner folgende Schritte: a) Speichern der Triggerdefi­ nitionen in einer Region eines Speicherelements; und b) Ak­ tualisieren eines Zeigerarrays, um die Speicherung der ge­ genwärtigen Triggerdefinition wiederzugeben, wobei das Zei­ gerarray Zeiger auf Speicherregionen, in denen Triggerde­ finitionen gespeichert sind, und Namen gespeichert hat, von denen jeder einer entsprechenden Triggerdefinition zugeord­ net ist und diese entsprechende Triggerdefinition identifi­ ziert.

Bei bestimmten Ausführungsbeispielen umfaßt der Schritt 1) folgende Schritte: a) Identifizieren einer Autospeicherbe­ dingung, wobei die Autospeicherbedingung explizit das Aufru­ fen durch einen Betreiber oder eine andere Betreiberhand­ lung, die dem Speichern einer Triggerdefinition zugeordnet ist, ausschließt; b) Zuordnen einer Region eines Systemspei­ chers mit ausreichender Größe, um die Triggerdefinition zu speichern; c) Speichern der Triggerdefinition in der zuge­ ordneten Speicherregion; und e) Einstellen eines Zeigers in dem Zeigerarray, um auf die zugeordneten Speicherregion zu zeigen. Bei anderen Ausführungsbeispielen umfaßt der Schritt 2) folgende Schritte: a) Empfangen einer Anforderung eines Betreibers, eine spezifische Triggerdefinition abzurufen; und b) Gleichmachen einer gegenwärtigen Triggerdefinition zu der ausgewählten gespeicherten Triggerdefinition. Vorzugs­ weise wird vor dem Schritt b) ein Schritt c) durchgeführt, der eine Aktualisierung des Bildschirms einer Benutzer­ schnittstelle verhindert. Vorzugsweise wird ferner nach dem Schritt b) ein Schritt d) durchgeführt, der es erlaubt, daß Bildschirmaktualisierungen durchgeführt werden können.

Ein weiterer Aspekt der vorliegenden Erfindung betrifft ein Verfahren zum automatischen Speichern und Abrufen von Trig­ ger-bezogenen Daten in einem Signalmeßsystem, das Signalda­ ten gemäß einer Triggerspezifikation erfaßt und speichert. Das Verfahren umfaßt folgende Schritte: 1) automatisches Speichern von Trigger-bezogenen Daten, die zumindest eine Triggerdefinition umfaßt, in einem Speicherelement anspre­ chend auf das Auftreten einer vorbestimmten Speicherungsbe­ dingung, die explizit das Aufrufen eines Betreibers oder eine andere Handlung, die dem Speichern einer Triggerdefi­ nition zugeordnet ist, ausschließt; 2) Liefern einer Anzeige einer vorbestimmten Anzahl von vorher gespeicherten Trig­ ger-bezogenen Daten auf einer Benutzerschnittstelle, wobei sämtliche vorher gespeicherten Trigger-bezogenen Daten an­ sprechend auf ein früheres Auftreten der vorbestimmten Spei­ cherdefinition gespeichert sind; 3) Wiedergewinnen von dem Speicher von bestimmten Trigger-bezogenen Daten der vorbe­ stimmten Anzahl von vorher gespeicherten Trigger-bezogenen Daten, die durch den Betreiber identifiziert sind; und 4) Aktualisieren einer gegenwärtigen Triggerspezifikation, da­ mit sie die wiedergewonnenen Trigger-bezogenen Daten umfaßt.

Ein weiterer Aspekt der vorliegenden Erfindung betrifft ein Verfahren zum automatischen Speichern und Abrufen von Trig­ ger-bezogenen Daten in einem Signalmeßsystem, das Signalda­ ten gemäß einer Triggerspezifikation erfaßt und speichert, wobei das Signalmeßsystem eine graphische Benutzerschnitt­ stelle hat. Das Verfahren umfaßt folgende Schritte: 1) An­ zeigen, auf der graphischen Benutzerschnittstelle, einer Be­ nutzerinteraktiven Triggerdefinitionseditierungsregion; 2) Empfangen von Eingaben des Betreibers für eine gegenwärtige Triggerspezifikation mit einer Triggerdefinition, die in der Triggerdefinitionseditierregion angezeigt ist; 3) Speichern der gegenwärtigen Triggerdefinition, die die Triggerdefini­ tion umfaßt, die in der Triggerdefinitionseditierungsregion angezeigt ist, um bei einem Auftreten einer Signalerfas­ sungsanforderung eine Speicherung durchzuführen; und 4) An­ zeigen einer Anzeige für vorher gespeicherte Triggerspezi­ fikationen auf der graphischen Benutzerschnittstelle. Bei bestimmten Ausführungsbeispielen umfaßt das Verfahren ferner folgende Schritte: 5) Empfangen einer Graphikauswahleingabe, die spezifische Trigger-bezogene Daten identifiziert; 6) Wiedergewinnen der ausgewählten Trigger-bezogenen Daten; und 7) Anzeigen der Triggerdefinition, die in den wiedergewonne­ nen Trigger-bezogenen Daten enthalten ist, in der Triggerde­ finitionseditierregion einer gegenwärtigen Triggerdefini­ tion.

Ein weiterer Aspekt der vorliegenden Erfindung betrifft ein Autospeicherungssystem zur Verwendung in einem Signalmeßsy­ stem, das Signaldaten gemäß einer Triggerspezifikation er­ faßt und speichert, wobei das Signalmeßsystem eine Benutzer­ schnittstelle und ein Speicherelement aufweist. Das System ist aufgebaut und angeordnet, um als Reaktion auf ein Auf­ treten einer Benutzeranforderung, um Signaldaten zu erfas­ sen, eine gewärtige Triggerspezifikation in einem Speicher, der mit dem System wirksam gekoppelt ist, automatisch zu speichern, und um eine vorbestimmte Anzahl der Triggerspe­ zifikationen für ein späteres Abrufen von dem Speicher zu speichern. Das System umfaßt eine Autospeichersteuerung, die aufgebaut und angeordnet ist, um eine oder mehrere Eingaben zu empfangen, die Ereignisse identifizieren, die die vorbe­ stimmte Speicherbedingung definieren, und um in einer Region des Speicherelements die Trigger-bezogenen Daten zu spei­ chern, wenn das eine oder die mehreren empfangenen Ereignis­ se ein Auftreten der vorbestimmten Speicherbedingung anzei­ gen. Das System umfaßt ferner eine Abrufsteuerung, die aufgebaut und angeordnet ist, um von der Speicherelementre­ gion Benutzerspezifizierte Trigger-bezogene Daten wieder­ zugewinnen, und um die wiedergewonnenen Trigger-bezogenen Daten zu der Benutzerschnittstelle zu liefern.

Bei bestimmten Ausführungsbeispielen dieses Aspekts der Er­ findung umfaßt das System ferner ein Zeigerarray, das mit der Autospeichersteuerung und der Abrufsteuerung wirksam gekoppelt ist. Das Zeigerarray umfaßt Zeiger auf Spei­ cherelementregionen, in denen gespeicherte Triggerspezifi­ kationen sind, die ansprechend auf eine vorbestimmte Anzahl von früheren Signalerfassungsanforderungen gespeichert wur­ den. Das Zeigerarray umfaßt ferner Triggernamen, von denen jeder eine relative Sequenz identifiziert, in der Trigger­ spezifikationen, die einem zugeordneten Zeiger entsprechen, gespeichert wurden. Bestimmte Implementationen dieses Aus­ führungsbeispiels umfassen eine Zeigerpuffersteuerung, die aufgebaut und angeordnet ist, um eine Zuordnung zwischen dem Triggernamen und den Zeigern in dem Zeigerarray zu halten, so daß die Triggernamen die relative Sequenz wiedergeben, in der die entsprechenden Trigger-bezogenen Daten gespeichert worden sind.

Verschiedene Ausführungsbeispiele der vorliegenden Erfindung liefern bestimmte Vorteile und überwinden bestimmte Nachtei­ le konventioneller Techniken. Nicht alle Ausführungsbei­ spiele der Erfindung liefern die gleichen Vorteile, und die, die alle Vorteile liefern, haben dieselben nicht unter allen Umständen. Unter dieser Voraussetzung liefert die vorliegen­ de Erfindung viele Vorteile einschließlich des bereits aus­ geführten Vorteils des automatischen Speichern einer Trig­ gerdefinition, eines größeren Abschnitts einer Triggerspezi­ fikation oder von anderen Trigger-bezogenen Daten, wenn ein vorbestimmtes Ereignis auftritt, wie z. B. Ereignisse, die möglicherweise wichtige Triggerdefinitionen anzeigen, und dies alles vollständig ohne Intervention oder ohne einen Aufruf durch den Betreiber. Dies erhöht den Wirkungsgrad deutlich, mit dem neue und erfahrene Betreiber Triggerspezi­ fikationen erzeugen können.

Weitere Merkmale und Vorteile der vorliegenden Erfindung so­ wie die Struktur und der Betrieb verschiedener Ausführungs­ beispiele der vorliegenden Erfindung werden nachfolgend be­ zugnehmend auf die beigefügten Zeichnungen beschrieben. In den Zeichnungen bezeichnen gleiche Bezugszeichen identische oder funktionsmäßige ähnliche Elemente. Zusätzlich identi­ fiziert die ganz linke bzw. identifizieren die zwei ganz links stehenden Ziffern eines Bezugszeichen die Zeichnung, in der das Bezugszeichen zuerst auftritt.

Fig. 1 ist ein Funktionsblockdiagramm eines beispielhaften Logikanalysators, in dem Ausführungsbeispiele der vorliegenden Erfindung implementiert werden können.

Fig. 2 ist ein Funktionsblockdiagramm eines Triggerver­ walters, in dem Aspekte der vorliegenden Erfindung implementiert werden können.

Fig. 3 ist ein Funktionsblockdiagramm eines Teilsystems zum automatischen Speichern und Abrufen gemäß einem Ausführungsbeispiel der vorliegenden Erfindung.

Fig. 4 ist ein schematisches Diagramm einer Triggerspe­ zifikation die in einem Speicher gespeichert ist, gemäß einem Ausführungsbeispiel der vorliegenden Erfindung.

Fig. 5 ist ein schematisches Diagramm eines Zeigerarrays, das bei bestimmten Aspekten der vorliegenden Erfin­ dung gehalten wird.

Fig. 6A ist eine Darstellung einer graphischen Benutzer­ schnittstellenanzeige gemäß einem Ausführungsbei­ spiel der vorliegenden Erfindung, bei dem ein Be­ treiber Triggerspezifikationen automatisch und ma­ nuell speichern kann.

Fig. 6B ist eine Darstellung einer graphischen Benutzer­ schnittstellenanzeige gemäß einem Ausführungsbei­ spiel der vorliegenden Erfindung, wobei ein pop­ up-Menü dargestellt ist, das ansprechend auf den Aufruf eines Benutzers, eine Triggerspezifikation manuell zu speichern, angezeigt wird.

Fig. 7 ist ein Flußdiagramm auf hoher Ebene der Verfahren zum Speichern und Abrufen, die gemäß einem Ausfüh­ rungsbeispiel der vorliegenden Erfindung durchge­ führt werden.

Fig. 8 ist ein Flußdiagramm auf hoher Ebene eines alterna­ tiven Ausführungsbeispiels für Verfahren, die durchgeführt werden, um vorbestimmte Abschnitte ei­ ner Triggerspezifikation automatisch zu speichern und abzurufen.

Fig. 9 ist ein Flußdiagramm auf hoher Ebene der Verfahren, die gemäß einem Ausführungsbeispiel der vorliegen­ den Erfindung durchgeführt werden, um eine Trigger­ spezifikation automatisch zu speichern.

Fig. 10 ist ein detailliertes Flußdiagramm der Verfahren, die gemäß einem Ausführungsbeispiel der vorliegen­ den Erfindung durchgeführt werden, um eine Trigger­ spezifikation automatisch zu speichern.

Fig. 11 ist ein Flußdiagramm auf hoher Ebene der Verfahren, die von der vorliegenden Erfindung durchgeführt werden, um eine früher gespeicherte Triggerspezi­ fikation abzurufen.

Fig. 12 ist ein detailliertes Flußdiagramm der Verfahren, die von der vorliegenden Erfindung durchgeführt werden, um eine vorher gespeicherte Triggerspezifi­ kation abzurufen.

Fig. 13 ist ein Flußdiagramm einer beispielhaften Implemen­ tation von Verfahren, die an einer Benutzerschnitt­ stelle gemäß einem Ausführungsbeispiel der vorlie­ genden Erfindung durchgeführt werden.

Die vorliegende Erfindung betrifft ein System und ein Ver­ fahren zur Verwendung in einem Signalmeßsystem, das Signal­ daten gemäß einer Triggerspezifikation, die eine Triggerde­ finition und einen oder mehrere Triggerparameter ("Trigger­ steuerungen") umfaßt, erfaßt und speichert. Die vorliegende Erfindung speichert auf automatische Art und Weise in einem Speicher Trigger-bezogene Daten, die Triggerdefinitionen und weitere spezifizierte Abschnitte einer gegenwärtigen Trig­ gerspezifikation umfassen ("gespeicherte Triggerspezifika­ tionen"), ohne daß ein Aufruf des Benutzers oder eine andere Einmischung des Benutzers stattgefunden hat. Eine Mehrzahl solcher gespeicherter Triggerspezifikationen wird an­ schließend für eine Wiedergewinnung von dem Speicher ver­ fügbar gemacht ("erinnert"). Dies versetzt einen Betreiber in die Lage, ohne weiteres zu einer früheren Version einer Triggerdefinition zurückzukehren, falls der Betreiber be­ stimmen sollte, daß eine gegenwärtige Triggerdefinition un­ erwünscht ist. Das automatische Speichern von Triggerspezi­ fikationen (oder Abschnitten derselben) kann ansprechend auf eines oder mehrere vorbestimmte Ereignisse stattfinden. Bei einem Aspekt der vorliegenden Erfindung umfassen solche vor­ bestimmten Ereignisse den Versuch des Benutzers, Daten zu erfassen. Es sei darauf hingewiesen, daß dieser Aspekt der vorliegenden Erfindung die Bedürfnisse des Betreibers nach einer Speicherung einer Triggerdefinition vorwegnimmt, da Triggerdefinitionen, die verwendet werden, um Daten zu er­ fassen, für den Betreiber möglicherweise wichtig sind. Das heißt, daß dieser Aspekt der vorliegenden Erfindung die in­ härente Korrelation zwischen einer aufgerufenen Triggerdefi­ nition und der Wichtigkeit der Triggerdefinition bei der Entwicklung einer erwünschten Triggerspezifikation vorteil­ haft ausnutzt.

Wie es bereits angemerkt wurde, kann die vorliegende Erfin­ dung in jedem Signalmeßsystem implementiert werden, das Si­ gnaldaten gemäß einer Triggerspezifikation erfaßt. Aspekte der vorliegenden Erfindung werden bezugnehmend auf ein bei­ spielhaftes Signalmeßsystem, d. h. bezugnehmend auf einen Logikanalysator, beschrieben. Fig. 1 ist ein Funktionsblock­ diagramm einer solchen Logikanalysators.

Der Logikanalysator 100 erfaßt, analysiert und zeigt eine breite Vielzahl von Signalen allgemein bezüglich des Logik­ pegels der Signale als Funktion der Zeit an. Bei dem in Fig. 1 dargestellten beispielhaften Ausführungsbeispiel um­ faßt der Logikanalysator 100 ein Allzweckcomputersystem, das unter Verwendung einer hohen Computerprogrammiersprache pro­ grammierbar ist, und eine speziell programmierte Spezial­ zweckhardware zum Durchführen der Signalerfassungs-, der Ana­ lyse- und der Anzeigefunktion. Aus der folgenden Beschrei­ bung sollte klar werden, daß die vorliegende Erfindung auch in anderen Umgebungen betrieben werden kann, wie beispiels­ weise auf Programm-betriebenen On-Board-Prozessoren, ASICs, einer Firmware, einer Hardware oder einer Kombination der­ selben.

Der Logikanalysator 100 umfaßt einen Prozessor 102, einen Systemspeicher 104, Eingabe/Ausgabe-(I/O-)Karten 106 und Speichereinheiten 105, wie z. B. ein Festplattenlaufwerk, ein Diskettenlaufwerk, usw. Der Analysator 100 kann eben­ falls eines oder mehrere Eingabe/Ausgabe-Geräte umfassen, wie z. B. eine Tastatur 108, Zeigegeräte 110 und eine Anzei­ ge 112. Der Systemspeicher 104 wird zum Speichern von Pro­ grammbefehlen zusätzlich zu anderen Computerlesbaren Pro­ grammen und Daten verwendet. Bei einem bevorzugten Ausfüh­ rungsbeispiel umfaßt der Systemspeicher 104 einen Direktzu­ griffsspeicher (RAM). Die Anzeige 112 ist vorzugsweise eine Kathodenstrahlanzeige und ist logisch und physikalisch in ein Array von Bildelementen (Pixeln) geteilt. Die Einga­ be/Ausgabe-(I/O-)Schnittstellenkarten 106 können Modemkar­ ten, Netzschnittstellenkarten, Sound-Karten und dergleichen sein.

Der Prozessor 102 ist typischerweise ein kommerziell ver­ fügbarer Prozessor, wie z. B. der PA-RISC-Prozessor der Hewlett-Packard Company, der Pentium-Mikroprozessor der In­ tel Corporation oder ein PowcerPC-Mikroprozessor oder ein Mikroprozessor der 68000-Serie von Motorola. Viele andere Prozessoren sind ebenfalls verfügbar. Ein solcher Prozessor führt ein Programm aus, das als Betriebssystem 114 bezeich­ net wird, liefert eine graphische Benutzerschnittstelle (GUI; GUI = Graphical User Interface) 116 und ein Fenstersy­ stem, wie z. B. die verschiedenen Versionen der Betriebssy­ steme Windows der Microsoft Corporation, das NetWare-Be­ triebssystem, das von Novell Inc. verfügbar ist oder das Unix-Betriebssystem, das von vielen Herstellern verfügbar ist, wie z. B. von Sun Microsystems Inc., der Hewlett- Packard Company und AT & T. Das Betriebssystem 114 steuert die Ausführung von anderen Computerprogrammen, wie z. B. Soft­ wareausführungen des Logikanalysemoduls 140, und liefert eine Ablaufsteuerung bzw. Disposition, eine Eingabe/Ausga­ be-Steuerung, eine Datei- und Daten-Verwaltung, eine Spei­ cherverwaltung und eine Kommunikationssteuerung sowie andere Dienstleistungen. Der Prozessor 102 und das Betriebssystem 114 definieren allgemein eine Computerplattform, die durch einen gestrichelten Block 101 gezeigt ist, für die Anwen­ dungsprogramme die in hohen Programmiersprachen geschrieben werden können. Die Funktionselemente des Logikanalysators 100 kommunizieren über einen Systembus 120 miteinander.

Das Signalerfassungsmodul 122 umfaßt Schaltungsanordnungen und Software, die Logiksignale 152 von einem zu testenden Element 131 abtasten und digitalisieren. Das Signalerfas­ sungsmodul 122 empfängt Logiksignale 152 von dem zu testen­ den Element 131 über Kanäle 130. Das Signalerfassungsmodul 122 umfaßt einen Datenabtastdetektor 138, der Logiksignale 152 empfängt und digitalisiert. Vorzugsweise werden die Ab­ tastwerte der Logiksignale 152 zu gleichmäßigen Zeitinter­ vallen erhalten. Das Zeitintervall kann Benutzer-spezifi­ ziert sein, oder auch mit einem der Logiksignale 152 syn­ chronisiert sein, die von dem zu testenden Element 131 emp­ fangen werden, wie z. B. einem Tastsignal, das von dem DUT 131 erzeugt wird. Die Signaldaten 154 sind eine abgetastete und digitalisierte Darstellung der Logiksignale 152. Das Si­ gnaldatenerfassungsmodul 122 umfaßt ferner einen Puffer 132, der die Signaldaten von dem Datenabtastdetektor 138 empfängt und vorübergehend speichert.

Ein Triggersequenzer bzw. eine Trigger-Ablaufsteuerung 134 wählt den Abschnitt der Signaldaten 154 für eine nachfolgen­ de Speicherung und Anzeige basierend auf einer Betreiber-de­ finierten Triggerspezifikation 150 aus. Wie es angemerkt wurde, ist die Triggerspezifikation 150 allgemein durch zwei Parameter spezifiziert, nämlich durch eine Triggerdefini­ tion, die Auftrittsereignisse identifiziert, unter denen Si­ gnaldaten gespeichert werden sollen, und durch eine Trigger­ position, die die Relativposition des Auftrittsereignisses bzw. des Auftretens, das durch die Triggerdefinition defi­ niert wird, identifiziert. Der Triggersequenzer 134 spei­ chert eine vorbestimmte Menge von Signaldaten, die vor und nach dem spezifizierten Auftrittsereignis auftreten, in ei­ nem Speicher. Der Triggersequenzer 134 liefert eine Schal­ tersteuerung 159 für den Schalter 136. Der Schalter 136 er­ laubt einen Durchgang von Logiksignalabtastwerten 154 von dem Puffer 132 zu einem Datenspeicher 142.

Der Logikanalysator 100 umfaßt ferner eine Videoanzeigesteu­ erung 126. Die Computerplattform 101 treibt die Videoanzei­ gesteuerung 126 unter Verwendung von üblichen Fensteranwen­ dungsprogrammschnittstellen (API; API = Application Program Interface) und zeigt Daten von dem Logikanalysemodul 140 dem Betreiber auf einer Anzeige 112 unter der Steuerung der Vi­ deoanzeigesteuerung 126.

Das Logikanalysemodul 140 umfaßt einen Triggerverwalter 180, der den Betreiber mit der Fähigkeit versieht, Triggerspe­ zifikationen zu erzeugen und zu modifizieren, um erwünschte Signale und Businformationen zu erfassen, die an den Kanälen 130 auftreten. Der Triggerverwalter 180 versetzt den Betrei­ ber ferner in die Lage, solche Triggerspezifikationen zu speichern und gespeicherte Triggerdefinitionen abzurufen, um sie anschließend zu verwenden und zu modifizieren.

Fig. 2 ist ein Blockdiagramm eines Ausführungsbeispiels ei­ nes Triggerverwalters 180. Der Triggerverwalter 180 ist der­ art gezeigt, daß er hauptsächlich vier Funktionsteilsysteme oder Komponenten umfaßt. Insbesondere umfaßt der Triggerver­ walter 180 ein Triggerentwicklungsteilsystem 204, das den Betreiber mit der Fähigkeit versieht, Triggerspezifikationen über eine Benutzerschnittstelle zu entwickeln, die als gra­ phische Benutzerschnittstelle 116 bei dem dargestellten Aus­ führungsbeispiel implementiert ist. Ein Triggersequenzer­ teilsystem 202 empfängt Triggersequenzen 205 von dem Trig­ gerentwicklungsteilsystem 204 und interpretiert die Trigger­ sequenzen 205 unter Verwendung von Triggersteuerinformatio­ nen 207, die von dem Triggersteuersystem 206 empfangen wer­ den. Der Triggersequenzen 206 erzeugt Triggerdefinitionssi­ gnale 211, die dazu geeignet sind, das Signalerfassungsmodul 122 zu steuern.

Das Triggersteuerungsteilsystem 206 versetzt den Betreiber in die Lage, die Charakteristika der erfaßten Daten zu spe­ zifizieren, und liefert die Triggersteuerung 207 zu dem Si­ gnalerfassungsmodul 122. Die Triggersteuerungen 207 umfassen beispielsweise Zähl- und Speicher-Qualifikationen 227, 228, eine Abtastrate 229, eine Speichertiefe 231 und eine Trig­ gerposition 233. Diese Triggersteuerungen sind in der Tech­ nik bekannt. Das Teilsystem 208 zum automatischen Speichern und Abrufen sorgt für das automatische und für das vom Be­ treiber aufgerufene Speichern von Triggerspezifikationen so­ wie für das Abrufen solcher Triggerspezifikationen für eine anschließende Verwendung und Modifikation. Das Teilsystem 208 zum automatischen Speichern und Abrufen leitet die ge­ speicherte Triggerspezifikation 223 weiter, um das Ent­ wicklungsteilsystem 204 derart zu beeinflussen, daß eine Anzeige auf der graphischen Benutzerschnittstelle 116 auf­ tritt.

Fig. 3 ist ein Funktionsblockdiagramm, das die Primärkompo­ nenten eines Ausführungsbeispiels des Teilsystems 208 zum automatischen Speichern und Abrufen, das oben bezugnehmend auf Fig. 2 eingeführt wurde, anschaulich macht. Wie es ange­ merkt wurde, speichert das Teilsystem 208 zum automatischen Speichern und Abrufen auf automatische Art und Weise eine gegenwärtige Triggerspezifikation (oder einen Abschnitt der­ selben), wenn eine vorbestimmte Bedingung außer der Anforde­ rung eines Betreibers (die vorbestimmte Bedingung wird hier als "vorbestimmte Speicherbedingung" bezeichnet) auftritt. Eine solche vorbestimmte Speicherbedingung kann durch das Auftreten von einem oder mehreren Ereignissen definiert sein. Bei einem bevorzugten Ausführungsbeispiel ist eine solche vorbestimmte Bedingung die Anforderung eines Betrei­ bers, eine Messung durchzuführen, d. h. eine Erfassung lau­ fen zu lassen. Es sei darauf hingewiesen, daß dieser Aspekt der vorliegenden Erfindung die Bedürfnisse des Betreibers vorweg nimmt, eine gegenwärtige Triggerspezifikation zu speichern, indem alle solchen Triggerspezifikationen gespei­ chert werden, die verwendet werden, um Daten zu erfassen. Dieser Aspekt der vorliegenden Erfindung wird nachfolgend detaillierter beschrieben.

Das Teilsystem 208 zum automatischen Speichern und Abrufen umfaßt allgemein eine Autospeichersteuerung 302 und eine Abrufsteuerung 306, die über die Benutzerschnittstellen- Schnittstellensteuerung 304 (UI-Schnittstellensteuerung; UI = User Interface) mit der graphischen Benutzerschnittstelle 116 kommunizieren. Bei diesem Ausführungsbeispiel speichert die Autospeichersteuerung 302 eine gegenwärtige Triggerspe­ zifikation 150 beim Auftreten einer Anforderung 215 eine Erfassung laufen zu lassen. Die Abrufsteuerung 306 gewinnt eine spezifizierte Triggerspezifikation 316, die in dem Speicher 104 gespeichert ist, zurück und liefert sie zu dem Triggerentwicklungsteilsystem 202 über die graphische Benut­ zerschnittstelle 116. Sobald die wiedergewonnene Triggerspe­ zifikation 316 in dem Triggerentwicklungsteilsystem 202 enthalten ist, kann der Betreiber diese editieren oder auf andere Art und Weise modifizieren.

Die Autospeichersteuerung 302 und die Abrufsteuerung 306 greifen auf ein Zeigerarray 310 zu, das Zeiger 314 auf Triggerspezifikationen 316, die in dem Speicher 104 gespei­ chert sind, speichert. Die Triggerspezifikationsnamen ("Na­ men") 312 sind ebenfalls in dem Zeigerarray 310 gespeichert. Jeder Name 312 liefert eine Beschreibung für einen zugeord­ neten Zeiger 314. Bei dem hier gezeigten Ausführungsbeispiel wird eine Mehrzahl von Triggerspezifikationen 316 in dem Speicher 104 gespeichert, wie es durch die drei beispielhaf­ ten Triggerspezifikationen 316A, 316B und 316C, die in Fig. 3 gezeigt sind, demonstriert ist. Solche Triggerspezifika­ tionen 316 werden sequentiell gespeichert. Dies bedeutet, daß sie alle drei eine "gegenwärtige" Triggerspezifikation zu einem bestimmten früheren Zeitpunkt waren, an dem die vorbestimmte Speicherbedingung auftrat. Bei einem solchen Ausführungsbeispiel identifizieren die Namen 312 zugeordnete Triggerspezifikationen 316 durch Identifizieren einer rela­ tiven Sequenz, in der die entsprechenden Triggerspezifika­ tionen 316 gespeichert worden sind.

Eine Zeigerpuffersteuerung 308 ist zwischen einer Autospei­ chersteuerung 302 und einem Zeigerarray 310 wirksam ange­ ordnet. Die Zeigerpuffersteuerung 308 hält eine Zuordnung zwischen Namen 312 und Zeigern 314 in dem Array 310, so daß die Namen 312 die Sequenz korrekt wiedergeben, in der die entsprechenden Triggerspezifikationen 316 und ihre zugeord­ neten Zeiger 314 gespeichert worden sind.

Wieder Bezug nehmend auf Fig. 3 wird nachfolgend eine ge­ nauere Beschreibung einer speziellen Implementation der vor­ liegenden Erfindung gegeben. Es sei darauf hingewiesen, daß die Autospeichersteuerung 302 eine gegenwärtige Triggerspe­ zifikation 150 beim Auftreten einer Anforderung 215, eine Erfassung laufen zu lassen, speichert und mit der graphi­ schen Benutzerschnittstelle 116 über die Benutzerschnitt­ stellensteuerung 304 kommuniziert. Wie es in Fig. 3 gezeigt ist, und wie es bereits oben ausgeführt wurde, umfaßt die Triggerspezifikation 150 Triggersteuerungen 207 und eine Triggerdefinition 209, die, wie es gezeigt ist, beide von der Autospeichersteuerung 302 empfangen werden.

Bei dem hier gezeigten Ausführungsbeispiel speichert die Autospeichersteuerung 302 eine gegenwärtige Triggerspezifi­ kation 150 ansprechend auf eine Anforderung, eine Erfassung laufen zu lassen. Eine solche Anforderung wird, wie es ge­ zeigt ist, durch die graphische Benutzerschnittstelle 116 als Anforderung 215, eine Erfassung laufen zu lassen, er­ zeugt, die oben bezugnehmend auf Fig. 2 durchgeführt wurde. Bei dem hier gezeigten Ausführungsbeispiel werden die UI- Schnittstellenoperationen in der UI-Schnittstellensteuerung 304 zusammengefügt. Zusätzlich zum Durchführen von weiteren Benutzerschnittstellenoperationen, die in dieser Beschrei­ bung an anderer Stelle detailliert beschrieben sind, erzeugt die UI-Steuerung 304 ein Lauferfassungssignal 303 anspre­ chend auf den Empfang eines Lauferfassungssignals 215. Das Lauferfassungssignal 215 wird durch die graphische Benutzer­ schnittstelle 116 ansprechend auf den Betreiber erzeugt, der eine Messung aufruft. Ein solcher Aufruf kann durch graphi­ sches Auswählen eines Menügegenstandes, durch einen speziel­ len Knopf, durch ein Icon oder dergleichen ausgewählt wer­ den. Bei Ausführungsbeispielen, die eine Benutzerschnitt­ stelle umfassen, die keine graphische Benutzerschnittstelle 116 ist, kann ein Betreiber die Durchführung einer Messung über einen Softkey-Auswahlgegenstand, über einen speziellen Knopf oder über eine andere Vorrichtung aufrufen.

Bei einem Aspekt der vorliegenden Erfindung unterstützen die obigen Fähigkeiten zum automatischen Speichern und Abrufen die Fähigkeit zum manuellen Speichern. Beispielsweise spei­ chert die Autospeichersteuerung 302 ebenfalls eine gegenwär­ tige Triggerspezifikation 150 als Reaktion auf ein Spei­ chern-Signal 301, das durch die UI-Schnittstellensteuerung 304 ansprechend auf ein ähnliches Signal 217, das durch die graphische Benutzerschnittstelle 116 erzeugt wird, erzeugt wird. Die graphische Benutzerschnittstelle 116 erzeugt das manuelle Speichern-Signal 217 ansprechend auf einen Betrei­ ber, der explizit anfordert, daß eine gegenwärtige Bedingung gespeichert wird.

Beim Empfang eines Lauferfassungssignals 303 und, bei dem beispielhaften Ausführungsbeispiel, einer Speichern-Anfor­ derung 301 speichert die Autospeichersteuerung 302 Trigger­ steuerungen 207 und die Triggerdefinition 209 als gegenwär­ tige Triggerspezifikation 316 in dem Speicher 104. Die Auto­ speichersteuerung 302 erzeugt eine Anforderung nach einer ausreichenden Speichermenge vom Betriebssystem 114 über die Erzeugung einer Anforderung 221. Ansprechend auf eine solche Anforderung bringt das Betriebssystem 114 einen Zeiger 223 zu der zugewiesenen Region in dem Speicher 104 zurück.

Wenn die vorbestimmte Speicherbedingung auftritt, leitet die Autospeichersteuerung 302 die gegenwärtige Triggerspezifika­ tion 150 zu dem Speicher 104 zum Speichern in einer Spei­ cherregion, die an einem Zeiger 223 beginnt. Die gesamte oder ein Abschnitt der gegenwärtigen Triggerspezifikation 150 wird als "Triggerspezifikation" 316 in dem Speicher 104 gespeichert. Der Zeiger 223 wird dann zu einer Zeigerpuffer­ steuerung 308 zur Speicherung in dem Zeigerarray 310 weiter­ geleitet. Die Zeigerpuffersteuerung 308 ist nachfolgend de­ tailliert beschrieben.

Bei einem alternativen Ausführungsbeispiel kann die ausge­ wählte vorbestimmte Speicherbedingung Ereignisse umfassen, die andere Ereignisse als die Anforderung nach einem Erfas­ sungslauf sind. Beispielsweise speichert bei einem alterna­ tiven Ausführungsbeispiel der vorliegenden Erfindung die Autospeichersteuerung 302 eine gegenwärtige Triggerdefini­ tion 209 und eine Triggersteuerung 207 periodisch, d. h. im­ mer zu einem vorbestimmten Zeitintervall. Ein solcher Lö­ sungsansatz hat mit dem oben bezeichneten Lösungsansatz ge­ meinsam, daß es nicht erforderlich ist, daß sich der Betrei­ ber daran erinnert, die erforderlichen Handlungen durchzu­ führen, um den erwünschten Abschnitt der Triggerspezifika­ tion zu speichern. Die beiden Lösungsansätze haben ferner gemeinsam, daß sie nicht die Konzentration des Betreibers beim Entwickeln einer erwünschten Triggersequenz stören.

Fig. 4 zeigt eine beispielhafte Triggerspezifikation 316, die in dem Speicher 104 gespeichert ist. Wie es bereits aus­ geführt worden ist, umfaßt eine gegenwärtige Triggerspezi­ fikation 150 eine Triggerdefinition 209 und Triggersteue­ rungen 207. Bei dem dargestellten Ausführungsbeispiel ist beides in der Triggerspezifikation 316 enthalten, die in dem Speicher 104 gemäß Aspekten der vorliegenden Erfindung auto­ matisch gespeichert wird.

Die gegenwärtige Triggerdefinition 209 ist, wie es bereits ausgeführt worden ist, die Triggersequenz, die gerade auf der graphischen Benutzerschnittstelle 116 angezeigt wird, wenn der Betreiber eine Messung durchführt. Zusätzlich sind eine Anzahl von Triggersteuerparametern oder Triggersteue­ rungen 207 als Teil der Triggerspezifikation 316 gespei­ chert. Bei dem dargestellten Ausführungsbeispiel umfassen die Triggersteuerungen 207 eine Triggerposition 233, die eine relative Position der Triggerbedingung und der Signal­ daten, die gespeichert werden, definiert. Zusätzlich ist ein Speichertiefenparameter 231 als Teil der Triggersteuerungen 207 gespeichert. Die Speichertiefe 231 identifiziert die Menge an Signaldaten, die beim Auftreten der Triggerbedin­ gung gespeichert werden soll. Der Abtastratenparameter 229 identifiziert die Frequenz, mit der Signaldaten abgetastet und gespeichert werden. Der Zählqualifikationsparameter 227 liefert Etiketteninformationen, die in den Triggersteuerun­ gen 207 enthalten sein können. Der Speicherqualifikations­ parameter 228 identifiziert Kriterien, die auf die abgeta­ steten Daten angewendet werden, um zu bestimmen, ob die ab­ getasteten Daten gespeichert oder weggeworfen werden sollen.

Es sollte für Fachleute offensichtlich sein, daß unter­ schiedliche oder zusätzliche Triggersteuerungen 207 in die Triggerspezifikation 316 aufgenommen werden können. Ferner sollte darauf hingewiesen werden, daß die Triggerspezifi­ kation 316 einen vorbestimmten Abschnitt der in Fig. 4 ge­ zeigten Daten umfassen kann. Beispielsweise kann die Trig­ gerspezifikation 316 nur die Triggerdefinition 209 umfassen und keine Triggersteuerungen 207. Alternativ können Filter vorhanden sein, um spezifische Abschnitte der Triggerspezi­ fikation 150 selektiv zu speichern, wenn unterschiedliche Speicherbedingungen auftreten. Beispielsweise wird anspre­ chend auf das Auftreten einer ersten Speicherbedingung die Triggerdefinition 209 gespeichert, während ansprechend auf eine zweite Speicherbedingung die gesamte Triggerspezifika­ tion 150 gespeichert wird.

Fig. 5 ist eine Darstellung eines Ausführungsbeispiels eines Zeigerarrays 310. Wie es angemerkt wurde, speichert das Zei­ gerarray 310 Zeiger 314 zu Triggerspezifikationen 316 in dem Speicher 104 sowie entsprechende Namen 312, die bei dem ge­ zeigten Ausführungsbeispiel die chronologische Reihenfolge identifizieren, in der die zugeordneten Triggerspezifika­ tionen 316 gespeichert worden sind. Es sollte für Fachleute klar sein, daß eine beliebige Anzahl von Triggerspezifika­ tionen 316 in dem Speicher 104 gespeichert werden kann, wes­ halb das Zeigerarray 310 eine beliebige Anzahl von Zeigern 314 und entsprechenden Namen 312 umfassen kann.

Bei dem gezeigten Ausführungsbeispiel existieren n Zeiger 314, nämlich der Zeiger 1, der Zeiger 2, der Zeiger 3, . . . und der Zeiger n. Die zuletzt gespeicherte Triggerspezifi­ kation 316 wird an einer Speicherposition gespeichert, die durch den Zeiger 1 identifiziert ist. Wie es in Fig. 5 ge­ zeigt ist, lautet der Name, der diesem Zeiger 1 zugeordnet ist, "letzter Lauf", was bedeutet, daß die zugeordneten Triggerspezifikation 316A (Fig. 3), die an dieser Speicher­ position gespeichert ist, die Triggerspezifikation ist, die zuletzt implementiert wurde, um Daten zu erfassen.

Der Zeiger 2 ist ein Zeiger auf eine Speicherposition, die die Triggerspezifikation 316B (Fig. 3) speichert, die vor der Triggerspezifikation 318A an der durch den Zeiger 1 identifizierten Speicherposition gespeichert wurde. Somit lautet der Name 312, der diesem Zeiger 2 zugeordnet ist "vorletzter Lauf". In anderen Worten ist die Triggerspezi­ fikation 316B, die an der Speicherposition gespeichert ist, die durch den Zeiger 2 identifiziert ist, eine Triggerspe­ zifikation, die implementiert wurde, um Daten vor der jüng­ sten Datenerfassung zu erfassen. Auf ähnliche Art und Weise identifiziert der Zeiger 3 die Speicherposition, an der die Triggerspezifikation 316C (Fig. 3), die den "drittletzten Lauf" betraf, gespeichert ist. Bei einem alternativen Aus­ führungsbeispiel können Namen 312 vorgesehen sein, um nicht die relative Reihenfolge, in der eine Triggerspezifikation 316 gespeichert wird, zu identifizieren, sondern um andere Charakteristika zu identifizieren, beispielsweise die Umstän­ de der Datenerfassung.

Wie es ausgeführt worden ist, hält die Zeigerpuffersteuerung 308 eine Zuordnung zwischen den Namen 312 und dem Zeiger 314 in dem Array 310, so daß die Namen 312 die chronologische Reihenfolge korrekt wiedergeben, in der die Triggerspezi­ fikationen 316 und ihre zugeordneten Zeiger 314 gespeichert worden sind. Bei einem gezeigten Ausführungsbeispiel aktua­ lisiert die Zeigerpuffersteuerung 308 die Zeiger 314, die den Anzeigenamen 312 zugeordnet sind, wenn eine neue gegen­ wärtige Triggerspezifikation 316 durch die Autospeicher­ steuerung 302 gespeichert wird. Bei diesem gezeigten Aus­ führungsbeispiel wird der Zeigerarray 310 durch die Zeiger­ puffersteuerung 308 dynamisch verwaltet, die die Zeiger 314 aktualisiert, die jedem Name 312 zugeordnet sind, um das Auftreten der jüngsten Datenerfassung wiederzugeben.

Insbesondere wird der Zeiger n-1 zu dem Zeiger n kopiert, wodurch der Zeiger n im wesentlichen überschrieben oder weg­ geworfen wird. Beispielsweise würde bezugnehmend auf das Zeigerarray 10, das in Fig. 5 gezeigt ist, der Zeiger 3 auf den Zeiger n kopiert. Genauso wird der Zeiger 2 auf den Zei­ ger 3 kopiert, und der Zeiger 1 auf den Zeiger 2. Der Zeiger 223 wird dann als Zeiger 1 gespeichert. Dies aktualisiert auf schnelle und einfache Art und Weise dynamisch das Zei­ gerarray 310, ohne daß Triggerspezifikationen 316 bewegt werden müssen, oder ohne daß die Namen 312 betroffen sind, die auf der graphischen Benutzerschnittstelle 116 angezeigt werden. In anderen Worten aktualisiert die Zeigerpuffer­ steuerung 308 auf dynamische Art und Weise das Zeigerarray 310 durch Verschieben der Zeiger 314, um einem Name 312 zu­ geordnet zu sein, der die chronologische Sequenz genau wie­ dergibt, mit der die zugeordnete Triggerspezifikation 316 gespeichert wurde.

Aus der vorangegangenen Beschreibung sollte klar werden, daß die Zeigerpuffersteuerung 308 einfach die korrekte Zuordnung zwischen den Namen 312 und den Zeigern 314 sicherstellt, da die Namen 312 eine relative Sequenz betreffen. Wie es ausge­ führt worden ist, sind die Zeiger 314 Namen 312 dynamisch zugeordnet, um die Datenmenge zu reduzieren, die zu verar­ beiten ist, und um eine konsistente Schnittstelle mit der graphischen Benutzerschnittstelle 116 beizubehalten. Bei einem alternativen Ausführungsbeispiel können andere Techni­ ken implementiert werden, um sicherzustellen, daß die gra­ phische Benutzerschnittstelle 116 eine vorbestimmte Anzahl von Anzeigen von früher gespeicherten Triggerspezifikationen 316 präsentiert, und daß eine korrekte Zuordnung zwischen den angezeigten Anzeigen und den Triggersequenzen beibehal­ ten wird. Beispielsweise können bei einem alternativen Aus­ führungsbeispiel die Namen 312 neu angeordnet werden, wenn zusätzliche Triggerspezifikationen 316 durch die Autospei­ chersteuerung 302 gespeichert werden.

Wie es angemerkt worden ist, gewinnt die Abrufsteuerung 306 eine gespeicherte Triggerspezifikation 316, die durch den Betreiber spezifiziert ist, wieder, und leitet dieselbe zu dem Triggerentwicklungssystem 202 über die graphische Benutzerschnittstelle 116. Wie es nachfolgend detaillierter beschrieben wird, wählt der Betreiber auf der graphischen Benutzerschnittstelle 116, daß eine spezielle Triggerspezi­ fikation 316 abgerufen wird, um eine Editierung durchzu­ führen. Diese Auswahl existiert in der Erzeugung einer Ab­ ruftriggerspezifikation 235 durch die graphische Benutzer­ schnittstelle 116, die von der UI-Schnittstellensteuerung 304 empfangen wird. Die UI-Schnittstellensteuerung 304 erzeugt ein Abruf-(Puffer-Nr-)Signal 307 zum Empfang durch die Abrufsteuerung 306. Die Abrufanforderung 307 übersetzt die identifizierte Puffernummer (1., 2., 3., etc.) in einer Triggerspezifikation 316, die in dem Speicher gespeichert ist, durch Zugreifen auf das Zeigerarray 310, um einen Zeiger 314 wiederzugewinnen, der der identifizierten Triggerspezifikation zugeordnet ist. Wenn der Betreiber beispielsweise die dritte Triggerspezifikation auswählt, greift die Abrufsteuerung 306 auf das Zeigerarray 310 zu und gewinnt den Zeiger 303 wieder, der dem Name 312 zugeordnet ist, der die ausgewählte Triggerspezifikation identifiziert, welche beim "drittletzten Lauf" gespeichert wurde. Die Abrufsteuerung 306 greift auf den Speicher 104 an der identifizierten Position zu und gewinnt die Triggerspe­ zifikation 316C an dieser Position wieder und leitet die Triggerspezifikation 316 als gespeicherte Triggerspezi­ fikation 305 zu der UI-Schnittstellensteuerung 304 weiter, die dann die Daten der GUI 116 zur Anzeige präsentiert.

Fig. 6A ist eine Darstellung einer graphischen Benutzer­ schnittstellenanzeige gemäß einem Ausführungsbeispiel der vorliegenden Erfindung, bei dem ein Betreiber Triggerspe­ zifikationen automatisch und manuell speichern kann. Wie es in Fig. 6A gezeigt ist, liefert eine Anzeige 600 tabellenar­ tige Fenster, wobei jedes einer Hauptfunktion des Logikana­ lysators 100 zugeordnet ist. Bei diesem gezeigten Ausfüh­ rungsbeispiel ist ein Primärrang 602 für Tabellen oben an der Anzeige 600 gezeigt. Trigger-bezogene Operationen sind ohne weiteres unter einer "Trigger"-Tabelle 606 zu finden, wobei die graphische Auswahl derselben die Anzeige eines zweiten Rangs 604 von Tabellen bewirkt, die alle auf die Triggerentwicklung im Logikanalysator 100 bezogen sind.

Die Auswahl einer "Speichern/Abrufen"-Tabelle 608 in dem Rang 604 bewirkt die Anzeige eines Speichern/Abrufen-Fen­ sters 610. Die Anzeigen, die dem gezeigten Ausführungsbei­ spiel der vorliegenden Erfindung zugeordnet sind, sind in einem Fenster 610 zu finden. Das Speichern/Abrufen-Fenster 610 ist hauptsächlich in zwei Regionen aufgeteilt: in eine Triggerdefinitionsregion 614 und in eine Trigger-Spei­ chern/Abrufen-Steuerregion 626. Die Triggerdefinitionsregion 615 liefert dem Betreiber eine interaktive Umgebung, in der eine Triggerdefinition eingegeben und editiert werden kann. Viele solche interaktiven Triggerdefinitionsentwicklungs­ fenster sind möglich und jeder bekannte Lösungsansatz kann verwendet werden. Bei dem in Fig. 6A dargestellten Aus­ führungsbeispiel wird eine "Bereich speichern, bis das Mu­ ster auftritt"-Triggerfunktion als gegenwärtige Triggerde­ finition angezeigt.

Die Trigger-Speichern/Abrufen-Steuerregion 626 liefert einen Speichern-Knopf 616 und einen Abrufen-Knopf 618 neben einem angezeigten Textfeld, das mit "Triggerdefinition" betitelt ist. Die graphische Auswahl des Speichern-Knopfs 616 durch den Betreiber bewirkt, daß ein Autospeicher- und Abrufen- Untersystem 208 eine gegenwärtige Triggerdefinition spei­ chert, die in der Triggerdefinitionsregion 614 angezeigt ist. Dieses Merkmal des gezeigten Ausführungsbeispiels der vorliegenden Erfindung wird nachfolgend detaillierter bezug­ nehmend auf Fig. 6B beschrieben.

Der Abrufen-Knopf 618 gibt dem Betreiber die Möglichkeit, eine vorher gespeicherte Triggerspezifikation 316 von dem Speicher 104 abzurufen. Die Auswahl eines Abrufen-Knopfes 618 resultiert in der Anzeige eines pop-up-Menüs, das hier als Pop-Up-Menü für die gespeicherte Triggerspezifikation 620 bezeichnet wird.

Das Pop-Up-Menü 620 umfaßt eine Liste 623 der Triggerspezi­ fikationsnamen, die in dem Speicher 104 gespeichert sind oder gespeichert werden können. Bei Aspekten der vorlie­ genden Erfindung, bei denen die Erfindung als Ergänzung zu einem manuellen Speichersystem geliefert wird, besteht ein bevorzugter Lösungsansatz darin, alle gespeicherten Trig­ gerspezifikationen dem Benutzer an einer einzigen Positon zur Durchsicht und Auswahl zur Verfügung zu stellen. Dazu ist die Triggerspezifikationsliste 623 in zwei Unterlisten eingeteilt: eine Liste 622 mit automatische gespeicherten Triggerspezifikationen und eine Unterliste 624 mit manuell gespeicherten Triggerspezifikationen. Wie es in Fig. 6A ge­ zeigt ist, können bei diesem Ausführungsbeispiel der vor­ liegenden Erfindung 5 Triggerspezifikationen automatisch gespeichert werden, während 10 Triggerspezifikationen ma­ nuell gespeichert werden können.

Die Triggerspezifikationsnamen, die in der automatisch ge­ speicherten Triggerspezifikationsliste 622 angezeigt werden, sind die, die oben bezugnehmend auf die Fig. 3 und 5 ausge­ führt wurden. Das heißt, daß die vorgegebenen Namen, die den automatisch gespeicherten Triggerspezifikationen gegeben werden, die relative chronologische Reihenfolge identifizie­ ren, in der die Triggerspezifikationen gespeichert wurden.

Die Namen, die in der manuell gespeicherten Triggerspezifi­ kationsliste 624 dargestellt sind, sind derart gezeigt, daß sie als "MEM-Nr. n - Leer" angegeben sind, wie es nachfol­ gend detaillierter beschrieben wird, wobei dieser Name mo­ difiziert werden kann, wenn ein Betreiber eine Triggerspe­ zifikation manuell speichert. Bei dem in Fig. 6A gezeigten Ausführungsbeispiel wurden jedoch keine derartigen Trigger­ spezifikationen manuell gespeichert. Dementsprechend zeigt die Unterliste 524 10 solcher vorgegebener Namen.

Das Pop-Up-Menü 620 wird angezeigt, um den Betreiber in die Lage zu versetzen, eine erwünschte Triggerspezifikation abzurufen, die in dem Speicher 104 früher gespeichert wurde. Der Mechanismus, der für den Betreiber vorgesehen ist, damit er graphisch eine erwünschte Triggerspezifikation auswählen kann, ist der Hervorhebungsbalken 628. Gemäß bekannter Techniken für graphische Benutzerschnittstellen kann der Betreiber den Hervorhebungsbalken manipulieren, um den Name einer erwünschten Triggerspezifikation hervorzuheben und auszuwählen. Ein solcher Betrieb wird bewirken, daß die Triggerdefinition der ausgewählten Triggerspezifikation in der Triggerdefinitionsregion 614 des Speichern/Abrufen-An­ zeigefensters 610 angezeigt wird. Zusätzlich werden die gegenwärtigen Triggersteuerungen mit denen, die in der ausgewählten Triggerspezifikation gespeichert sind, aktuali­ siert.

Fig. 6B ist eine Darstellung einer graphischen Benutzer­ schnittstellenanzeige gemäß einem Aspekt der vorliegenden Erfindung, wobei ein Pop-Up-Menü dargestellt ist, das an­ sprechend auf den Aufruf eines Benutzers, eine Triggerspe­ zifikation manuell zu speichern, angezeigt wird. Wie es in Fig. 6B gezeigt ist, bewirkt die Auswahl des Speichern- Knopfes 616 die Anzeige eines Pop-Up-Menüs, das hierin als Triggerspezifikationsspeichern-Pop-Up-Menü 650 bezeichnet wird. Das Pop-Up-Menü 650 enthält eine Liste verfügbarer Zeigereinträge in dem Zeigerarray 310, die auf eine Trigger­ spezifikation zeigen können, die manuell gespeichert ist. Die vorgegebenen Namen in der Liste 652 sind wie oben bezug­ nehmend auf Fig. 6A beschrieben ausgeführt. Die dargestellte Auswahl von einem der Anzeigeelemente in der Liste 652 be­ wirkt, daß ein vorbestimmter Abschnitt der gegenwärtigen Triggerspezifikation, einschließlich der Triggerdefinition, die in der Triggerdefinitionsregion 614 angezeigt wird, in dem ausgewählten Puffer gespeichert wird. Zu einem solchen Zeitpunkt werden herkömmliche graphische Techniken implemen­ tiert, um den Betreiber in die Lage zu versetzen, den Name der manuell gespeicherten Triggerspezifikation von dem vor­ gegebenen Name derselben in einen anderen erwünschten Namen zu ändern.

Es sollte darauf hingewiesen werden, daß die graphischen Be­ nutzerschnittstellenanzeigen, die in den Fig. 6A und 6B ge­ zeigt sind, lediglich beispielhaft sind. Beispielsweise sind die Anzeigeelemente bei dem gezeigten Ausführungsbeispiel in der Form von Knöpfen und Fenstertabellen ausgeführt. Es sollte darauf hingewiesen werden, daß die Tabellen 606, 608, die Tabellenränge 602, 604 und die Knöpfe 616 und 618 ledig­ lich einen einer Vielzahl von Lösungsansätzen darstellen, der verwendet werden kann, um Anzeigeelemente zur Auswahl oder zum Dateneintrag durch den Betreiber zu präsentieren. Solche Anzeigeelemente können gemäß Techniken für graphische Benutzerschnittstellenanzeigen geliefert werden, die gegen­ wärtig oder später entwickelt werden. Beispielsweise können Icons, Menülisten, Pop-Up-Menüs, Rollisten und andere der­ artige Graphikanzeigeelemente in einer beliebigen Kombina­ tion verwendet werden, um dieselben oder ähnliche Informa­ tionen einem Betreiber gegenüber zu präsentieren. Alle sol­ chen Implementationen sind in der Technik bekannt und können in Verbindung mit der vorliegenden Erfindung ausgeführt wer­ den.

Es sollte darauf hingewiesen werden, daß Aspekte der vorlie­ genden Erfindung nicht notwendigerweise die Fähigkeit umfas­ sen, Triggerspezifikationen manuell zu speichern. Bei sol­ chen Aspekten werden der Speichern-Knopf 616 und sein zuge­ ordnetes Pop-Up-Menü 650 und die Unterliste 624 auf der graphischen Benutzerschnittstellenanzeige der Fig. 6A und 6B nicht gezeigt. Nur der Speichern-Knopf 618 oder ein Äquiva­ lent zu demselben bei der implementierten Benutzerschnitt­ stelle ist nötig, um zusammen mit einer Anzeige der gespei­ cherten Triggerspezifikationen, aus denen der Betreiber eine erwünschte Triggerspezifikation zum Abruf auswählen kann, dem Betreiber geliefert werden. Ein Modifizieren der graphi­ schen Benutzerschnittstellenanzeigen, um verschiedene Aspek­ te der vorliegenden Erfindung zu implementieren, liegt im Bereich des fachmännischen Könnens.

Das alternative Ausführungsbeispiel, bei dem der Betreiber die Fähigkeit hat, die Triggerspezifikation manuell zu spei­ chern, liefert zusätzliche Vorteile. Ein Vorteil besteht in der Tatsache, zu bestimmen, ob eine Triggerspezifikation ei­ ne ist, auf die zu einem späteren Datum zugegriffen werden wird, wobei der Betreiber in diesem Fall die Triggerspezifi­ kation manuell speichern würde, um den potentiellen Verlust einer automatisch gespeicherten Triggersequenz zu vermeiden, da eine begrenzte Anzahl von automatisch gespeicherten Trig­ gersequenzen vorhanden sein kann, die durch die implemen­ tierte Erfindung unterstützt wird. In anderen Worten werden, wie es oben beschrieben wurde, die automatisch gespeicherten Triggerspezifikationen schließlich mit jüngeren Triggerspe­ zifikationen überschrieben. Andererseits werden manuell gespeicherte Triggerspezifikationen permanent gespeichert, bis sie von dem Betreiber überschrieben werden. Der Be­ treiber kann dann die Triggerspezifikation unbegrenzt halten, und derselben kann, sobald es bestimmt wird, daß sie nicht länger erwünscht ist, dieselbe absichtlich löschen.

Die vorliegende Erfindung ist nicht auf die Implementation mit einer speziellen Benutzerschnittstelle begrenzt. Bei­ spielsweise kann der Logikanalysator 100 oder ein anderes Signalmeßsystem eine Benutzerschnittstelle haben, die mit einer Flach-Bedienfläche und Softkeys ausgestattet ist. Bei einem solchen Ausführungsbeispiel können die Namen für die gespeicherten Triggerspezifikationen neben spezifischen Softkeys präsentiert werden, die es dem Benutzer ermögli­ chen, die erwünschte Triggerspezifikation auszuwählen, um sie durch Drücken des zugeordneten Softkeys abzurufen.

Bei einem anderen Ausführungsbeispiel kann die Benutzer­ schnittstelle spezielle Steuerungen auf einer Frontbedien­ fläche des Signalmeßsystems umfassen. Bei einem solchen Aus­ führungsbeispiel werden Steuerungen, wie z. B. Knöpfe, Ta­ sten oder Drehschalterpositionen für jede der gespeicherten Triggersequenzen vorgesehen. Die Auswahl einer erwünschten Triggersequenz über die Manipulation der speziellen Steue­ rungen würde das Abrufen der erwünschten Triggerspezifi­ kation bewirken.

Es sollte klar sein, daß der Logikanalysator 100 fernge­ steuert sein kann. Bei einem solchen Ausführungsbeispiel ist eine der Eingabe/Ausgabe-Karten 106 eine Netzschnittstel­ lenkarte (NIC). Der Logikanalysator 100 (oder ein anderes Signalmeßsystem, in dem die Erfindung untergebracht ist) liefert dem Betreiber eine Anzeige der gespeicherten Trig­ gersequenzen über das Netz mittels der NIC 106. Jede Tech­ nik, die gegenwärtig oder später entwickelt wird, kann verwendet werden, um Daten und Steuerungen zu einer ent­ fernten Position in einem Netz zu kommunizieren, an der das Signalmeßsystem angeordnet ist, in dem die vorliegende Er­ findung ausgeführt ist.

Fig. 7 ist ein Flußdiagramm auf hoher Ebene von Verfahren zum automatischen Speichern und Abrufen, die gemäß einem Ausführungsbeispiel der vorliegenden Erfindung durchgeführt werden. Das Verfahren 100 beginnt an einem Startblock 702 ansprechend auf das Auftreten einer vorbestimmten Speicher­ bedingung. Wie es ausgeführt wurde, kann diese vorbestimmte Speicherbedingung jede Anzahl von Ereignissen umfassen, wo­ bei explizit ausgeschlossen ist, daß die vorbestimmte Spei­ cherbedingung umfaßt, daß der Betreiber anfordert, daß eine gegenwärtige Triggerspezifikation gespeichert wird. Beim Auftreten einer solchen Speicherbedingung wird die Verarbei­ tung an einem Block 704 fortgesetzt, bei dem die gegenwärti­ ge Triggerspezifikation automatisch gespeichert wird. Be­ züglich seiner Verwendung in dieser Beschreibung kann der Ausdruck "Triggerspezifikation", wie es bereits ausgeführt worden ist, die gesamte oder einen Abschnitt einer gegenwär­ tigen Triggerspezifikation 150 umfassen.

An einem Block 706 liefert die vorliegende Erfindung eine Anzeige für eine vorbestimmte Anzahl von vorher gespeicher­ ten Triggerspezifikationen auf einer Benutzerschnittstelle. Bei dem beispielhaften Ausführungsbeispiel, das oben be­ schrieben wurde, wurde eine graphische Benutzerschnittstelle verwendet, um eine solche Anzeige zu liefern. Ein Fachmann wird jedoch erkennen, daß andere solche Benutzerschnittstel­ len in einem Signalmeßsystem allgemein implementiert werden können, und insbesondere bei einem Logikanalysator 100. So liefert die vorliegende Erfindung in dem Block 706 eine An­ zeige, die für die implementierte Benutzerschnittstelle ge­ eignet ist.

Eine gespeicherte Triggerspezifikation, die von dem Betrei­ ber identifiziert worden ist, wird von dem Speicher abgeru­ fen und dem Betreiber als gegenwärtige Triggerspezifikation zum Editieren in einem Block 708 präsentiert. Wieder kann der Betreiber die implementierte Benutzerschnittstelle ver­ wenden, um eine erwünschte gespeicherte Triggerspezifikation auszuwählen, damit sie abgerufen wird. An einem Endblock 710 schließlich wird die Verarbeitung beendet.

Fig. 8 ist ein Flußdiagramm auf hoher Ebene eines alterna­ tiven Ausführungsbeispiels von Verfahren, die durchgeführt werden, um vorbestimmte Abschnitte einer Triggerspezifi­ kation automatisch zu speichern und abzurufen. Bei diesem Ausführungsbeispiel wird das Verfahren 100 zum automatischen Speichern und Abrufen an einem Block 802 aufgerufen, wonach in einem Block 804 eine gegenwärtige Triggerspezifikation (oder ein Abschnitt derselben) automatisch gespeichert wird, wenn eine Signalerfassung aufgerufen wird. Die durch diesen Block dargestellten Verfahren können durchgeführt werden, um eine beliebige erwünschte Anzahl von Triggerdefinitionen zu speichern.

Ein Betreiberzugriff auf eine vorbestimmte Anzahl von vorher gespeicherten Triggerspezifikationen wird in einem Block 806 geliefert. Jegliche Vorrichtung zum Liefern eines solchen Zugriffs für den Betreiber kann verwendet werden. Wenn er einen solchen Zugriff hat, kann ein Betreiber vom Speicher 104 jede beliebige erwünschte Triggerspezifikation wieder­ gewinnen. Die Verarbeitung endet dann an einem Endblock 808.

Fig. 9 ist ein Flußdiagramm auf hoher Ebene der Verfahren, die gemäß einem Ausführungsbeispiel der vorliegenden Erfin­ dung durchgeführt werden, um einen erwünschten Abschnitt ei­ ner Triggerspezifikation automatisch zu speichern. Das Ver­ fahren 900 kann beispielsweise bei dem Block 604 in Fig. 7 oder in dem Block 804 in Fig. 8 durchgeführt werden. Nach einem Anfangsblock 902 werden ausgewählte Triggerspezifika­ tionsdaten von einem Block 904 im Speicher gespeichert. Die­ se Daten können eine Triggerdefinition sowie eine beliebige Anzahl von Triggersteuerparametern umfassen, wie es oben be­ schrieben wurde. Sobald die Daten gespeichert sind, wird die Verarbeitung mit einem Block 906 fortgesetzt, an dem ein Zeigerarray 310 aktualisiert wird, um die Speicherung der gegenwärtigen Triggerspezifikationsdaten in einem Block 904 wiederzugeben. Das Zeigerarray 310 kann unter Verwendung einer beliebigen bekannten Technik aktualisiert werden, um die korrekte Zuordnung zwischen den Zeigern und den entspre­ chenden Triggerspezifikationsdaten und dem entsprechenden Namen sicherzustellen. Das Speicherverfahren wird dann an einem Block 908 beendet.

Fig. 10 ist ein detailliertes Flußdiagramm der Verfahren, die gemäß einem Ausführungsbeispiel der vorliegenden Erfin­ dung durchgeführt werden, um eine Triggerspezifikation auto­ matisch zu speichern. Sobald es bestimmt worden ist, daß ei­ ne gegenwärtige Triggerspezifikation gespeichert wird, wird die Verarbeitung von einem Startblock 1002 zu einem Block 1004 fortgesetzt, an dem die erwünschten gegenwärtigen Trig­ gerspezifikationsdaten wiedergewonnen werden. Ein solches Wiedergewinnen kann es erforderlich machen, daß das automa­ tische Speicher- und Abruf-Untersystem 208 auf verschiedene andere Untersysteme oder Speichergeräte in dem Logikanalysa­ tor 100 zugreift. Wenn solche Daten wiedergewonnen werden, wird eine 06409 00070 552 001000280000000200012000285910629800040 0002019949377 00004 06290 Speicherregion mit ausreichender Größe an einem Block 1006 zugeordnet, um die wiedergewonnenen Daten zu speichern.

An einen Block 1008 werden die gegenwärtigen Triggerspezifi­ kationsdaten, die an dem Block 1004 wiedergewonnen wurden, in der Speicherregion gespeichert, die in dem Block 1006 zu­ gewiesen wurde. Ein Zeiger in dem Zeigerpuffer wird in einem Block 1010 eingestellt, um auf die zugeordnete Speicherre­ gion zu zeigen. Die Verarbeitung wird dann an einem Block 1012 beendet.

Fig. 11 ist ein Flußdiagramm auf hoher Ebene der Verfahren, die von der vorliegenden Erfindung durchgeführt werden, um eine vorher gespeicherte Triggerspezifikation abzurufen. Sobald der Betreiber anfordert, daß eine spezifische Trig­ gerspezifikation 316 abgerufen werden soll, fährt die Verarbeitung vom Startblock 1102 zu einem Block 1104 fort, an dem verhindert wird, daß der graphische Benutzerschnitt­ stellenbildschirm aktualisiert wird. In einem Block 1106 wird die gegenwärtige Triggerspezifikation gleich der ausgewählten gespeicherten Triggerspezifikation gesetzt. Das heißt, daß die ausgewählte gespeicherte Triggerspezifikation vom Speicher wiedergewonnen oder kopiert wird und dem Betreiber als gegenwärtige Triggerspezifikation präsentiert wird. Sobald dies erreicht ist, werden Bildschirmaktualisie­ rungen in einem Block 1108 zugelassen. Die Verarbeitung wird dann an einem Block 1110 beendet.

Fig. 12 ist ein detailliertes Flußdiagramm der Verfahren, die von der vorliegenden Erfindung durchgeführt werden, um eine vorher gespeicherte Triggerspezifikation abzurufen. Bei einem Block 1202 wird in einem Block 1204 verhindert, daß Bildschirmaktualisierungen stattfinden können. Ein Zeiger für die ausgewählte Triggerspezifikation wird an einem Block 1206 wiedergewonnen, der die Region in dem Speicher 104 identifiziert, bei der die ausgewählte Triggerspezifikation positioniert ist. Diese ausgewählte Triggerspezifikation wird dann an einem Block 1208 wiedergewonnen und an einem Block 1210 zu der Benutzerschnittstelle weitergeleitet. Sobald die Benutzerschnittstelle aktualisiert ist, werden Bildschirmaktualisierungen in einem Block 1212 wieder zugelassen. Die Verarbeitung wird dann an einem Block 1214 beendet.

Fig. 13 ist ein Flußdiagramm für eine beispielhafte Imple­ mentation von Verfahren, die bei einer Benutzerschnittstelle gemäß einem Ausführungsbeispiel der vorliegenden Erfindung durchgeführt werden. Nach einem Anfangsblock 1302 werden Triggerspezifikationseingabefelder auf der Benutzerschnitt­ stelle in einem Block 1304 angezeigt. In einem Block 1306 werden Eingaben des Betreibers in die Anzeigetriggerspezifi­ kation empfangen. Wenn solche Eingaben eine Signalerfassung umfassen, wie es in einem Block 1308 bestimmt wird, wird die Verarbeitung an einem Block 1310 fortgesetzt. Andernfalls wird die Verarbeitung an dem Block 1306 fortgesetzt, wo zu­ sätzliche Betreibereingaben empfangen werden können. Dieses Verfahren wird fortgesetzt, bis eine der Betreibereingaben anzeigt, daß eine Signalerfassung erwünscht ist. Wenn dies auftritt, wird die angezeigte Triggerspezifikation an einem Block 1310 als gegenwärtige Triggerspezifikation im Speicher gespeichert. Wie es angemerkt wurde, kann die gesamte oder ein Abschnitt der angezeigten Triggerspezifikation im Spei­ cher gespeichert werden.

An einem Block 1312 bewertet der Betreiber das Verhalten der Erfassung. Wenn sie so ist, wie es erwartet wird, dann kann der Betreiber die Daten in einem Block 1314 analysieren. Wenn dies nicht der Fall ist, wird die Verarbeitung wieder an dem Block 1304 fortgesetzt, an dem die Triggerspezifika­ tionseingabefelder wieder auf der Benutzerschnittstelle an­ gezeigt werden. Das obige Verfahren wird dann fortgesetzt, bis der Betreiber bestimmt, daß die Erfassung so wie erwar­ tet war, was in einem Block 1312 stattfindet. Wenn dies der Fall war, kann der Betreiber die Signaldaten an einem Block 1314 analysieren, wie es oben angemerkt wurde. Die Verarbei­ tung wird dann an einem Block 1316 beendet.

Obwohl verschiedene Ausführungsbeispiele der vorliegenden Erfindung beschrieben worden sind, sei darauf hingewiesen, daß diese lediglich beispielhaft und nicht begrenzend auf­ zufassen sind. Beispielhafte Aspekte der vorliegenden Erfin­ dung wurden beispielsweise bezüglich eines Logikanalysators beschrieben. Für Fachleute sollte es klar sein, daß die vor­ liegende Erfindung in jedem Signalmeßsystem implementiert werden kann, das Signaldaten gemäß einer Triggerspezifika­ tion erfaßt und speichert. Die vorliegende Erfindung kann beispielsweise in einem Digitaloszilloskop, einem Protokoll­ analysator, einem Mikroprozessoremulator, einem Bitfehler­ ratentester, einem Netzwerkanalysator, usw. implementiert werden. Ferner werden Trigger-bezogene Daten, die in dem Speicher 104 gespeichert sind, als gegenwärtige Triggerspe­ zifikation oder ein Abschnitt derselben beschrieben. Bei al­ ternativen Ausführungsbeispielen umfassen Trigger-bezogene Daten, oder, wie es oben beschrieben wurde, umfaßt eine Triggerspezifikation 316 Trigger-bezogene Daten, die tradi­ tionell nicht als Teil einer Triggerspezifikation behandelt werden. Zusätzlich wurde ausgeführt, daß eine Benutzer­ schnittstelle eingesetzt wird, die es einem Betreiber ermög­ licht, eine Anzeige einer ausgewählten Triggerspezifikation in einem einzigen Fenster 610 mit der angezeigten gegenwär­ tigen Triggerdefinition abzurufen. Dies ist optional und wird unter bestimmten Umständen bevorzugt, da der Betreiber eine Triggerspezifikation auswählen kann und unmittelbar damit beginnen kann, dieselbe auf der Anzeige 600 zu editie­ ren oder zu bewerten. Alternative Anzeigelösungsansätze kön­ nen natürlich implementiert werden.

Claims (36)

1. System (204) zur Verwendung in einem Signalmeßsystem (100), das Signaldaten gemäß einer gegenwärtigen Trig­ gerspezifikation erfaßt und speichert,
wobei die gegenwärtige Triggerspezifikation (150) eine Triggerdefinition (209) und Triggersteuerparameter (207) umfaßt,
wobei das System aufgebaut und angeordnet ist, um einen spezifizierten Abschnitt der gegenwärtigen Triggerspe­ zifikation (316) ansprechend auf das Auftreten einer vorbestimmten Speicherbedingung automatisch zu spei­ chern,
wobei die Speicherbedingung keine Anforderungen des Be­ treibers umfaßt, die gegenwärtige Triggerspezifikation zu speichern, und
wobei das System ferner aufgebaut und angeordnet ist, um einen anschließenden Zugriff auf eine vorbestimmte Anzahl der spezifizierten Triggerspezifikationsab­ schnitte (316) für ein anschließendes Abrufen zu schaf­ fen.

2. System nach Anspruch 1, bei dem die vorbestimmte Spei­ cherbedingung der Versuch eines Betreibers ist, Daten zu erfassen (215).

3. System zum automatischen Speichern und Abrufen zur Verwendung in einem Signalmeßsystem (100), das Signal­ daten gemäß einer Triggerspezifikation (150) erfaßt und speichert,
wobei das System aufgebaut und angeordnet ist, um einen vorbestimmten Abschnitt einer gegenwärtigen Triggerspe­ zifikation automatisch und als Reaktion auf von einem Betreiber aufgerufene Anforderungen automatisch zu speichern, und
um dem Betreiber einen Zugriff auf eine vorbestimmte Anzahl der gespeicherten vordefinierten Triggerspezifi­ kationsabschnitte für ein anschließendes Abrufen und eine anschließende Verwendung durch den Betreiber zu liefern.

4. Ein Autospeichersystem (204) zur Verwendung in einem Signalmeßsystem (100), das Signaldaten gemäß einer Triggerspezifikation (150) erfaßt und speichert, wobei das Signalmeßsystem eine Benutzerschnittstelle (116) und ein Speichergerät (104) hat,
wobei das System aufgebaut und angeordnet ist, um ge­ genwärtige Trigger-bezogene Daten in einer Region eines Speichers, der mit dem System wirksam gekoppelt ist, automatisch zu speichern, und
wobei auf eine vorbestimmte Anzahl der Speicherregionen zugegriffen werden kann, um anschließend vorher gespei­ cherte Trigger-bezogenen Daten (316) vom Speicher abzu­ rufen.

5. System nach Anspruch 4, das die Trigger-bezogenen Daten ansprechend auf das Auftreten einer vorbestimmten Spei­ cherbedingung speichert, wobei die vorbestimmte Spei­ cherbedingung Handlungen des Betreibers, um die Trig­ ger-bezogenen Daten zu speichern, ausdrücklich nicht umfaßt.

6. System nach Anspruch 4 oder 5, bei dem die vorbestimmte Speicherbedingung die Anforderung eines Betreibers um­ faßt, Signaldaten zu erfassen.

7. System nach Anspruch 4 oder 5, bei dem die vorbestimmte Speicherregion das Verstreichen eines vorbestimmten Zeitintervalls umfaßt.

8. System nach einem der Ansprüche 4 bis 7, bei dem die Trigger-bezogenen Daten einen Abschnitt einer gegenwär­ tigen Triggerspezifikation umfassen.

9. System nach einem der Ansprüche 5 bis 8, bei dem der Abschnitt der gegenwärtigen Triggerspezifikation eine gegenwärtige Triggerdefinition (208) und einen oder mehrere gegenwärtige Triggersteuerparameter (207) um­ faßt.

10. System nach Anspruch 9, bei dem die Triggerdefinition eine Triggersequenz definiert, die gegenwärtig auf der Benutzerschnittstelle angezeigt wird, wenn der Betrei­ ber eine Messung laufen läßt.

11. System nach Anspruch 9 oder 10, bei dem der eine oder die mehreren gegenwärtigen Triggersteuerparameter eine Art und Weise definieren, auf die die Signaldaten ge­ speichert werden.

12. System nach einem der Ansprüche 4 bis 11, das ferner folgende Merkmale aufweist:
eine Autospeichersteuerung, die aufgebaut und angeord­ net ist, um eine oder mehrere Eingaben zu empfangen, die Ereignisse identifiziert bzw. identifizieren, die die vorbestimmte Speicherbedingung definiert bzw. de­ finieren, und um in einer Region des Speichergeräts die Trigger-bezogenen Daten (216) zu speichern, wenn die eine oder die mehreren Ereigniseingaben ein Auftreten der vorbestimmten Speicherbedingungen anzeigt bzw. an­ zeigen; und
eine Abrufsteuerung (306) die aufgebaut und angeordnet ist, um von einer einer Mehrzahl von Speichergerätre­ gionen Betreiber-spezifizierte Trigger-bezogene Daten (316), die ansprechend auf ein früheres Auftreten der vorbestimmten Speicherbedingung gespeichert wurden, wiederzugewinnen, und um die wiedergewonnenen Trig­ ger-bezogenen Daten zu der Benutzerschnittstelle (116) zu liefern.

13. System nach Anspruch 12, das ferner folgendes Merkmal aufweist:
ein Zeigerarray (310), auf das von der Autospeicher­ steuerung (302) und der Abrufsteuerung (306) zu­ gegriffen werden kann, das folgende Merkmale aufweist: eine Mehrzahl von Zeigern (314), von denen jeder ei­ ne der Mehrzahl von Speichergerätregionen identifi­ ziert; und
eine Mehrzahl von Triggernamen (312), von denen je­ der einem der Mehrzahl von Zeigern (314) zugeordnet ist und eine Beschreibung von Trigger-bezogenen Da­ ten (316) liefert, die in einer Speichergerätregion gespeichert sind, die durch den zugeordneten Zeiger (314) identifiziert wird.

14. System nach Anspruch 13, bei dem die Triggernamen eine Relativsequenz anzeigen, in der die entsprechenden Trigger-bezogenen Daten gespeichert worden sind.

15. System nach Anspruch 14, das ferner folgende Merkmale aufweist:
eine Zeigerpuffersteuerung (308), die aufgebaut und an­ geordnet ist, um eine Zuordnung zwischen den Triggerna­ men (312) und den Zeigern (314) in dem Zeigerarray zu halten, so daß die Triggernamen die Relativsequenz wie­ dergeben, in der die entsprechenden Trigger-bezogenen Daten gespeichert worden sind.

16. System nach Anspruch 15, bei dem die Abrufsteuerung (306) einen der Zeiger (314) in dem Zeigerarray (310), dem ein Triggername des ausgewählten Triggernamens zugeordnet ist, wiedergewinnt und auf die Speicher­ gerätregion zugreift, die durch den Zeiger identi­ fiziert ist, um die erwünschten Trigger-bezogenen Daten abzurufen.

17. System nach einem der Ansprüche 4 bis 16, bei dem der eine oder die mehreren Triggersteuerparameter folgende Merkmale aufweisen:
eine Triggerposition, die eine Relativposition der Triggerbedingung und der gespeicherten Signaldaten de­ finiert;
eine Speichertiefe, die eine Menge von Signaldaten identifiziert, die in dem Speichergerät beim Auftreten der Speicherbedingung zu speichern sind; und
eine Abtastrate, die eine Frequenz identifiziert, mit der die Signaldaten beim Auftreten der Speicherbedin­ gung abgetastet und gespeichert werden.

18. System nach einem der Ansprüche 4 bis 17, bei dem das Signalmeßsystem als Logikanalysator ausgeführt ist.

19. System nach einem der Ansprüche 4 bis 17, bei dem das Signalmeßsystem als Digitaloszilloskop ausgeführt ist.

20. Verfahren zum automatischen Speichern und späteren Abrufen einer Triggerdefinition in einem Signalmeßsy­ stem (100), das Signaldaten (154) gemäß einer Trigger­ spezifikation (150), die eine Triggerdefinition (209) und einen oder mehrere Triggersteuerparameter (207) umfaßt, erfaßt und speichert, wobei das Verfahren folgende Schritte aufweist:

• 1. automatisches Speichern (704, 804, 900, 1000) ei­ ner gegenwärtigen Triggerdefinition ansprechend auf eine vorbestimmte Anzahl von jüngsten Signal­ erfassungsanforderungen; und
• 2. Liefern (706) eines Betreiberzugriffs auf die vor­ bestimmte Anzahl von vorher gespeicherten Trigger­ definitionen (209).

21. Verfahren nach Anspruch 20, bei dem der Schritt 1) fol­ gende Schritte aufweist:

• a) Speichern (904) der Triggerdefinition in einer Re­ gion eines Speichergeräts; und
• b) Aktualisieren (906) eines Zeigerarrays, um die Speicherung der gegenwärtigen Triggerdefinition wiederzugeben, wobei das Zeigerarray in sich ge­ speicherte Zeiger auf Speicherregionen, in denen Triggerdefinitionen gespeichert sind, und Namen hat, von denen jeder einer entsprechenden Trig­ gerdefinition zugeordnet ist und dieselbe identi­ fiziert.

22. Verfahren nach Anspruch 20, bei dem der Schritt 1) fol­ gende Schritte aufweist:

• a) ansprechend auf eine Autospeicherbedingung, auto­ matisches Speichern, wobei die Autospeicherbedin­ gung explizit einen Aufruf eines Benutzers oder eine andere Handlung eines Benutzers ausschließt, die dem Speichern einer Triggerdefinition zugeord­ net ist;
• b) Zuordnen eines Regionenabschnitts eines System­ speichers mit ausreichender Größe, um die Trigger­ definition zu speichern;
• c) Speichern der Triggerdefinition in der zugeordne­ ten Speicherregion; und
• d) Einstellen eines Zeigers in dem Zeigerarray, um auf die zugeordneten Speicherregion zu zeigen.

23. Verfahren nach einem der Ansprüche 20 bis 22, bei dem der Schritt 2) folgende Schritte aufweist:

• a) Empfangen einer Anforderung eines Betreibers, eine spezifische Triggerdefinition abzurufen; und
• b) Gleichsetzen einer gegenwärtigen Triggerdefinition mit der ausgewählten gespeicherten Triggerdefini­ tion.

24. Verfahren nach Anspruch 23, bei dem der Schritt 2) fer­ ner folgende Schritte aufweist:

• a) vor dem Schritt b), Verhindern einer Bildschirmak­ tualisierung einer Benutzerschnittstelle; und
• b) nach dem Schritt b), Zulassen der Bildschirmaktua­ lisierung.

25. Verfahren nach Anspruch 23 oder 24, bei dem der Schritt 2) b) folgende Schritte aufweist:

• 1. Kopieren der ausgewählten gespeicherten Triggerde­ finition von der zugeordneten Speicherregion; und
• 2. Präsentieren der wiedergewonnenen Triggerdefini­ tion auf der Benutzerschnittstelle als gegenwär­ tige Triggerdefinition.

26. Verfahren nach Anspruch 25, bei dem der Schritt 2) b) (1) folgende Schritte aufweist:

• a) Wiedergewinnen eines Zeigers, der der ausgewählten Triggerspezifikation zugeordnet ist, von dem Zei­ gerarray, wobei der wiedergewonnene Zeiger die Speicherregion identifiziert, an der die ausge­ wählte Triggerspezifikation positioniert ist;
• b) Wiedergewinnen der ausgewählten Triggerdefinition von der Speicherregion; und
• c) Leiten der ausgewählten Triggerdefinition zu der Benutzerschnittstelle.

27. Verfahren nach einem der Ansprüche 20 bis 26, bei dem das Signalmeßsystem ein Logikanalysator ist.

28. Verfahren nach einem der Ansprüche 20 bis 26, bei dem das Signalmeßsystem ein Digitaloszilloskop ist.

29. Verfahren zum automatischen Speichern und Abrufen von Trigger-bezogenen Daten in einem Signalmeßsystem (100), das Daten gemäß einer Triggerspezifikation (150) erfaßt und speichert, mit folgenden Schritten:

• 1. automatisches Speichern von Trigger-bezogenen Da­ ten, die zumindest eine Triggerdefinition (209) umfassen, in einem Speichergerät (142), anspre­ chend auf ein Auftreten einer vorbestimmten Spei­ cherbedingung, die explizit nicht das Aufrufen eines Benutzers oder eine andere Handlung, die dem Speichern einer Triggerdefinition zugeordnet ist, umfaßt;
• 2. Liefern einer Anzeige einer vorbestimmten Anzahl von vorher gespeicherten Trigger-bezogenen Daten auf einer Benutzerschnittstelle (116), wobei alle vorher gespeicherten Trigger-bezogenen Daten an­ sprechend auf ein früheres Auftreten der vorbe­ stimmten Speicherbedingung gespeichert wurden;
• 3. Wiedergewinnen von Daten der vorbestimmten Anzahl von vorher gespeicherten Trigger-bezogenen Daten, die durch den Betreiber identifiziert sind, von dem Speicher; und
• 4. Aktualisieren einer gegenwärtigen Triggerspezifi­ kation, damit sie die wiedergewonnenen Trigger-be­ zogenen Daten umfaßt.

30. Verfahren nach Anspruch 29, bei dem die Trigger-bezoge­ nen Daten ferner einen oder mehrere Triggersteuerpara­ meter umfassen.

31. Verfahren nach Anspruch 30, das ferner folgenden Schritt aufweist:

• 1. Präsentieren der gegenwärtigen Triggerdefinition für eine Modifikation durch den Betreiber auf der Benutzerschnittstelle.

32. Verfahren nach Anspruch 29, bei dem die Benutzer­ schnittstelle eine graphische Benutzerschnittstelle ist.

33. Verfahren zum automatischen Speichern und Abrufen von Trigger-bezogenen Daten in einem Signalmeßsystem (100), das Signaldaten gemäß einer Triggerspezifikation (150) erfaßt und speichert, wobei das Signalmeßsystem eine graphische Benutzerschnittstelle (116) hat, mit folgen­ den Schritten:

• 1. Anzeigen einer Benutzerinteraktiven Triggerdefi­ nitionseditierregion auf der graphischen Benutzer­ schnittstelle (116);
• 2. Empfangen von Eingaben eines Betreibers in eine gegenwärtige Triggerspezifikation mit einer Trig­ gerdefinition, die in der Triggerdefinitionsedi­ tierregion angezeigt ist;
• 3. Speichern der gegenwärtigen Triggerdefinition, die die Triggerdefinition umfaßt, die in der Trigger­ definitionseditierregion angezeigt ist, in einem Speicher beim Auftreten einer Signalerfassungsan­ forderung; und
• 4. Anzeigen einer Anzeige für vorher gespeicherte Triggerspezifikationen auf der graphischen Benut­ zerschnittstelle (116).

34. Verfahren nach Anspruch 33, das ferner folgende Schrit­ te aufweist:

• 1. Empfangen einer Graphikauswahleingabe, die spezi­ fizierte Trigger-bezogene Daten der gespeicherten Triggerspezifikationen identifiziert;
• 2. Wiedergewinnen der ausgewählten Trigger-bezogenen Daten von dem Speicher; und
• 3. Anzeigen der Triggerdefinition, die in den wieder­ gewonnenen Trigger-bezogenen Daten enthalten ist, in einer Triggerdefinitionseditierregion einer ge­ genwärtigen Triggerdefinition.

35. Autospeichersystem (204) zur Verwendung in einem Si­ gnalmeßsystem (100), das Signaldaten gemäß einer Trig­ gerspezifikation (150) erfaßt und speichert, wobei das Signalmeßsystem eine Benutzerschnittstelle (116) und ein Speichergerät (104) hat, wobei das System aufgebaut und angeordnet ist, um ansprechend auf ein Auftreten einer Anforderung eines Betreibers, Signaldaten zu er­ fassen, eine gegenwärtige Triggerspezifikation in einem Speicher automatisch zu speichern, der mit dem System wirksam gekoppelt ist, und um eine vorbestimmte Anzahl der Triggerspezifikationen für ein späteres in Erinne­ rung rufen von dem Speicher zu speichern, mit folgenden Merkmalen:
einer Autospeichersteuerung (302), die aufgebaut und angeordnet ist, um eine oder mehrere Eingaben zu emp­ fangen, die Ereignisse identifizieren, die die vorbe­ stimmte Speicherbedingung definieren, und um in einer Region des Speichergeräts die Trigger-bezogenen Daten zu speichern, wenn die eine oder die mehreren Ereignis­ eingaben ein Auftreten der vorbestimmten Speicherbedin­ gung anzeigen; und
eine Abrufsteuerung (306), die aufgebaut und angeordnet ist, um von der Speichergerätregion Betreiber-spezifi­ zierte Trigger-bezogene Daten wiederzugewinnen, und um die wiedergewonnenen Trigger-bezogenen Daten zu der Benutzerschnittstelle zu liefern.

36. System nach Anspruch 35, das ferner folgendes Merkmal aufweist:
ein Zeigerarray (310), das mit der Autospeichersteue­ rung (302) und der Abrufsteuerung (306) wirksam gekop­ pelt ist, mit folgenden Merkmalen: Zeigern (314) auf die Speichergerätregionen, an denen Triggerspezifikationen gespeichert sind, die ansprechend auf eine vorbestimmte Anzahl von frü­ heren Signalerfassungsanforderungen gespeichert wur­ den; und
Triggernamen (312), von denen jeder eine Relativse­ quenz identifiziert, in der Triggerspezifikationen, die einem zugeordneten Zeiger entsprechen, gespei­ chert worden sind; und
einer Zeigerpuffersteuerung (308), die aufgebaut und angeordnet ist, um eine Zuordnung zwischen den Trigger­ namen (312) und den Zeigern (310) in dem Zeigerarray zu halten, so daß die Triggernamen die Relativsequenz wie­ dergeben, in der die entsprechenden Trigger-bezogenen Daten gespeichert wurden.