DE69817581T2

DE69817581T2 - System und verfahren zum umwandeln von graphischen programmen in hardware-implementierungen

Info

Publication number: DE69817581T2
Application number: DE69817581T
Authority: DE
Inventors: L. Jeffrey KODOSKY; Hugo Andrade; K. Brian ODOM; P. Cary BUTLER
Original assignee: National Instruments Corp
Current assignee: National Instruments Corp
Priority date: 1997-08-18
Filing date: 1998-06-22
Publication date: 2004-06-24
Anticipated expiration: 2018-06-23
Also published as: US7010470B2; US20030195729A1; US6954724B2; EP1004085B1; EP1004085A1; US7177786B2; WO1999009498A1; US7650264B2; US6993466B2; US20030195732A1; US7558711B2; US20060004553A1; US20030200076A1; US6983228B2; US20070225954A1; US6219628B1; ATE248403T1; US7707014B2; US20030195731A1; US20070198236A1

Description

Die vorliegende Erfindung betrifft die graphische Programmierung und insbesondere ein System und ein Verfahren zum Umwandeln eines graphischen Programms in eine programmierbare Hardwareimplementierung.
Traditionell wurden von Programmierern beim Schreiben von Anwendungsprogrammen textbasierte höhere bzw. problemorientierte Programmiersprachen verwendet. Es existieren viele verschiedene höhere Programmiersprachen, wie BASIC, C, FORTRAN, Pascal, COBOL, ADA, APL usw. In diesen höheren Sprachen geschriebene Programme werden von als Compiler bekannten Übersetzungseinrichtungen auf die Maschinenspracheebene übersetzt. Die höheren Programmiersprachen auf dieser Ebene sowie auf der Assembler-Sprachenebene werden als textbasierte Programmierumgebungen bezeichnet.
Computer müssen in zunehmendem Maße von Personen verwendet und programmiert werden, die in Computerprogrammiertechniken nicht sehr gut ausgebildet sind. Wenn traditionelle textbasierte Programmierumgebungen verwendet werden, werden die Programmierkenntnisse des Benutzers und seine Fähigkeit, sich mit dem Computersystem auszutauschen, häufig zu einem begrenzenden Faktor beim Erreichen einer optimalen Ausnutzung des Computersystems.
Es gibt zahlreiche feine Komplexitäten, die ein Benutzer beherrschen muß, bevor er ein Computersystem in einer textbasierten Umgebung wirksam programmieren kann. Die Aufgabe des Programmierens eines Computersystems zum Modellieren eines Prozesses wird häufig dadurch weiter kompliziert, daß eine Folge mathematischer Formeln, mathematischer Schritte oder anderer Prozeduren, die üblicherweise zum konzeptionellen Modellieren eines Prozesses verwendet werden, häufig nicht in engem Sinne den traditionellen textbasierten Programmiertechniken entsprechen, die zum Programmieren eines zum Modellieren eines solchen Prozesses verwendeten Computersystems eingesetzt werden. Mit anderen Worten erzeugt die Anforderung, daß ein Benutzer in einer textbasierten Programmierumgebung programmiert, ein Abstraktionsniveau zwischen der Konzeptionalisierung der Lösung durch den Benutzer und der Implementierung eines Verfahrens, das diese Lösung in einem Computerprogramm erreicht. Demgemäß muß ein Benutzer häufig in erheblichem Maße verschiedene Fähigkeiten aufweisen, um ein System konzeptionell zu modellieren und dann einen Computer so zu programmieren, daß er dieses System modelliert. Weil einem Benutzer die Techniken zum Programmieren eines Computersystems in einer textbasierten Umgebung zum Implementieren seines Modells häufig nicht völlig geläufig sind, wird die Wirksamkeit, mit der das Computersystem verwendet werden kann, um diese Modellierung auszuführen, häufig verringert.
Beispiele von Gebieten, auf denen Computersysteme verwendet werden, um physikalische Systeme zu modellieren und/oder zu steuern, sind die Gebiete der Instrumentation, der Prozeßsteuerung und der industriellen Automatisierung. Die Computermodellierung oder -steuerung von Vorrichtungen, wie Instrumenten oder industrieller Automatisierungshardware, ist angesichts der zunehmenden Komplexität und der Vielfalt der Instrumente und Vorrichtungen, die zum Gebrauch verfügbar sind, zunehmend wünschenswert geworden. Infolge der großen Vielfalt möglicher Test- und Steuersituationen und Umgebungen und auch infolge der großen Vielfalt der verfügbaren Instrumente oder Vorrichtungen muß ein Benutzer häufig ein Programm zum Steuern eines gewünschten Systems entwickeln. Wie vorstehend erwähnt wurde, mußten zum Steuern solcher Systeme verwendete Computerprogramme in herkömmlichen textbasierten Programmiersprachen, wie beispielsweise Assembler, C, FORTRAN, BASIC oder Pascal, geschrieben werden. Traditionelle Benutzer dieser Systeme sind jedoch häufig in Programmiertechniken nicht sehr gut ausgebildet, und traditionelle textbasierte Programmiersprachen waren zusätzlich nicht intuitiv genug, um es Benutzern zu ermöglichen, diese Sprachen ohne Training zu verwenden. Daher war es für ein Implementieren solcher Systeme häufig erforderlich, einen Programmierer heranzuziehen, um Software zum Steuern und zur Analyse von Instrumenten oder industriellen Automatisierungsdaten zu schreiben. Demgemäß erwiesen sich das Entwickeln und Verwalten der Softwareelemente in diesen Systemen häufig als schwierig.
In dem Kodosky u. a. erteilten US-Patent US-A-4 901 221 sind ein graphisches System und ein Verfahren zum Modellieren eines Prozesses, also eine graphische Programmierumgebung, beschrieben, wodurch es einem Benutzer ermöglicht wird, einen Prozeß leicht und intuitiv zu modellieren. Die bei Kodosky u. a. beschriebene graphische Programmierumgebung kann als die höchste und intuitivste Art angesehen werden, in der mit einem Computer kommuniziert werden kann. Eine graphische Programmierumgebung kann in einer Ebene oberhalb textbasierter Programmiersprachen hoher Ebene, wie C, Pascal usw., dargestellt werden. Das bei Kodosky u. a. beschriebene Verfahren ermöglicht es einem Benutzer, ein Diagramm unter Verwendung eines Blockdiagrammeditors einzurichten, so daß das erzeugte Diagramm eine Prozedur oder ein Verfahren zum Erreichen eines bestimmten Ergebnisses, wie ein Manipulieren von einer oder mehreren Eingangsvariablen zum Erzeugen von einer oder mehreren Ausgangsvariablen, graphisch darstellt. Ansprechend darauf, daß der Benutzer ein Datenflußdiagramm oder ein graphisches Programm unter Verwendung des Blockdiagrammeditors einrichtet, werden automatisch Maschinenspracheanweisungen erzeugt, die eine der angezeigten Prozedur entsprechende Ausführungsprozedur charakterisieren. Daher kann ein Benutzer ein Computerprogramm ausschließlich unter Verwendung einer graphischen Programmierumgebung erzeugen. Diese graphische Programmierumgebung kann zum Erzeugen virtueller Instrumentensysteme, industrieller Automatisierungssysteme und zum Modellieren von Prozessen sowie für jeden beliebigen Typ einer allgemeinen Programmierung verwendet werden.
Daher lehren Kodosky u. a. eine graphische Programmierumgebung, bei der ein Benutzer Bildzeichen in einem Blockdiagramm unter Verwendung eines Blockdiagrammeditors anordnet und manipuliert, um ein Datenfluß-"Programm" zu erzeugen. Ein graphisches Programm zum Steuern oder Modellieren von Vorrichtungen, wie Instrumenten, Prozessen oder industrieller Automatisierungshardware, wird als ein virtuelles Instrument (VI) bezeichnet. Beim Erzeugen eines virtuellen Instruments erzeugt ein Benutzer vorzugsweise eine Frontplatte oder eine Benutzerschnittstellenplatte. Die Frontplatte enthält verschiedene Frontplattenobjekte, wie Steuerungen oder Indikatoren, welche die jeweilige Ein- und Ausgabe darstellen, die von dem graphischen Programm oder VI verwendet werden, und sie kann andere Bildzeichen enthalten, welche gesteuerte Vorrichtungen darstellen. Wenn die Steuerungen und Indikatoren auf der Frontplatte erzeugt werden, werden entsprechende Bildzeichen oder Terminals in dem Blockdiagramm automatisch von dem Blockdiagrammeditor erzeugt. Alternativ kann der Benutzer zuerst Terminal-Bildzeichen in dem Blockdiagramm anordnen, wodurch die Anzeige entsprechender Frontplattenobjekte auf der Frontplatte hervorgerufen wird. Der Benutzer wählt dann verschiedene Funktionen, die sein gewünschtes Ergebnis erzielen, wobei er die entsprechenden Funktionsbildzeichen zwischen den Terminals der entsprechenden Steuerungen und Indikatoren verbindet. Mit anderen Worten erzeugt der Benutzer ein als Blockdiagramm bezeichnetes Datenflußprogramm, das den graphischen Datenfluß darstellt, der seine gewünschte Funktion erreicht. Dies erfolgt durch Verdrahten der verschiedenen Funktionsbildzeichen zwischen den Steuerbildzeichen und Indikatorbildzeichen. Die Manipulation und Organisation von Bildzeichen erzeugt wiederum eine Maschinensprache, wodurch das gewünschte Verfahren oder der gewünschte Prozeß erreicht wird, wie in dem Blockdiagramm dargestellt ist.
Ein Benutzer gibt Daten unter Verwendung von Frontplattensteuerungen in ein virtuelles Instrument ein. Diese eingegebenen Daten laufen durch das Datenfluß-Blockdiagramm oder graphische Programm und erscheinen als Änderungen an den ausgegebenen Indikatoren. Bei einer Instrumentenanwendung kann die Frontplatte in Analogie mit der Frontplatte eines Instruments gebracht werden. Bei einer industriellen Automatisierungsanwendung kann die Frontplatte in Analogie mit der MMI (Mensch-Maschine-Schnittstelle) einer Vorrichtung gebracht werden. Der Benutzer stellt die Steuerungen an der Frontplatte ein, um die Eingabe zu beeinflussen, und er betrachtet die Ausgabe an den jeweiligen Indikatoren.
Demgemäß ist die graphische Programmierung zu einem Programmierern zur Verfügung stehenden mächtigen Werkzeug geworden. Graphische Programmierumgebungen, wie das LabVIEW-Produkt von National Instruments, sind sehr beliebt geworden. Werkzeuge wie LabVIEW haben die Produktivität von Programmierern stark erhöht, und zunehmende Anzahlen von Programmierern verwenden graphische Programmierumgebungen zum Entwickeln ihrer Softwareanwendungen. Insbesondere werden graphische Programmierwerkzeuge unter anderem für Tests und Messungen, zur Datenerfassung, Prozeßsteuerung, für Mensch-Maschine-Schnittstellen (MMI) und für Überwachungssteuerungs- und Datenerfassungsanwendungen (SCADA-Anwendungen) verwendet.
Ein Hauptzweck virtueller Instrumentensysteme besteht darin, dem Benutzer die maximale Flexibilität zum Erzeugen seiner eigenen Anwendungen und/oder zum Definieren seiner eigenen Instrumentenfunktionen zu geben. Es ist in dieser Hinsicht wünschenswert, die Ebene zu erweitern, bis zu der der Benutzer von Instrumenten oder industrieller Automatisierungshardware in der Lage ist, Instrumente zu programmieren. Die Entwicklung dieser Ebenen, auf denen der Benutzer ein Instrument programmieren konnte, läßt sich im wesentlichen folgendermaßen darstellen:

1. Software auf der Benutzerebene (LabVIEW, LabWindows CVI, Visual Basic usw.)
2. Software auf der Kern-Ebene
3. Software auf einer Hilfs-Kern-Ebene (ein zweiter Kern, der neben dem Haupt-Betriebssystem läuft, beispielsweise InTime, VentureCom usw.)
4. Eingebettete Software auf der Kern-Ebene
5. Software auf der Hardware-Ebene (FPGA – die vorliegende Patentanmeldung).

Im allgemeinen kann der Benutzer, die vorstehende Liste nach unten durchlaufend, Softwareanwendungen erzeugen, die eine deterministischere Echtzeitantwort bereitstellen. Gegenwärtig stellen die meisten Programmentwicklungswerkzeuge für Instrumentensysteme oder die industrielle Automatisierung eine Schnittstelle auf der vorstehenden Ebene 1 kereit. Im allgemeinen sind die meisten Benutzer nicht in der Lage, auf der Kern-Ebene oder der Hilfs-Kern-Ebene zu programmieren, und/oder dies ist ihnen nicht erlaubt. Die Software auf der Benutzerebene nimmt typischerweise die Form von Softwarewerkzeugen an, die zum Erzeugen von Software verwendet werden können, die auf den Ebenen 1 und/oder 4 arbeitet.
Gegenwärtige Instrumentenlösungen auf der Ebene 5 existieren. in erster Linie als von dem Anbieter definierte Lösungen, also als von dem Anbieter erzeugte Module. Es ist jedoch sehr wünschenswert, dem Benutzer die Fähigkeit zu geben, Software auf der Benutzerebene zu entwickeln, die auf der Hardwareebene arbeitet. Es ist insbesondere wünschenswert, dem Benutzer die Fähigkeit zu geben, Software hoher Ebene, wie Graphikprogramme, zu entwickeln, die leicht in die Instrumentenfunktionalität auf der Hardwareebene umgewandelt werden kann. Hierdurch würde dem Benutzer der doppelte Vorteil gegeben, daß er Instrumentenfunktionalitäten auf der höchstmöglichen Ebene (textbasierte oder graphische Programme) programmieren kann, während ihm auch die Fähigkeit gegeben wird, das erzeugte Programm direkt in Hardware ablaufen zu lassen, um eine höhere Geschwindigkeit und Effizienz zu erzielen.
In dem Dokument von Chen "Software Environment for WASMII: a Data Driven Machine With a Virtual Hardware", veröffentlicht 1994, ist die Verwendung dynamisch umkonfigurierbarer FPGAs auf der Grundlage einer virtuellen Hardware beschrieben. In diesem Dokument ist auch ein System beschrieben, wodurch ein Anwendungsprogramm als ein Datenflußdiagramm editiert wird und dann in einen Satz von Unterdiagrammen unterteilt wird, die jeweils den Konfigurationsdaten von n in WASMII-System verwendeten FPGA-Chips entsprechen. Es erzeugt eine Hardwarebeschreibung von wenigstens einem Abschnitt des graphischen Programms und konfiguriert ein programmierbares Hardwareelement unter Verwendung der Hardwarebeschreibung, um ein konfiguriertes Hardwareelement zu erzeugen, wobei das konfigurierte Hardwareelement eine Hardwareimplementierung von wenigstens einem Abschnitt des graphischen Programms implementiert.
Gemäß einem Aspekt ist das Verfahren gemäß der vorliegenden Erfindung durch Anspruch 1 definiert.
Gemäß einem Aspekt ist das Meßsystem gemäß Anspruch 22 definiert.
Gemäß einem weiteren Aspekt ist das Meßsystem gemäß Anspruch 42 definiert.
Die vorliegende Erfindung sieht ein computerimplementiertes System und Verfahren zum automatischen Erzeugen von Funktionalitäten auf der Hardwareebene, beispielsweise programmierbarer Hardware oder FPGAs, ansprechend auf ein von einem Benutzer erzeugtes graphisches Programm vor. Hierdurch wird dem Benutzer die Fähigkeit gegeben, Instrumentenfunktionalitäten unter Verwendung graphischer Programmiertechniken zu entwickeln oder zu definieren, während ermöglicht wird, daß das sich ergebende Programm direkt in Hardware ausgeführt wird.
Der Benutzer erzeugt zuerst ein graphisches Programm, das die gewünschte Funktionalität ausführt oder darstellt. Das graphische Programm weist typischerweise ein oder mehrere Module oder eine Hierarchie von Unter-VIs auf. Bei der bevorzugten Ausführungsform ordnet der Benutzer verschiedene Konstruktionselemente in Abschnitten des graphischen Programms an, um das Umwandeln dieser Abschnitte in Hardwareform zu unterstützen.
Der Benutzer wählt dann eine Option zum Umwandeln des graphischen Programms in ausführbare Form aus, wobei wenigstens ein Abschnitt des graphischen Programms in eine Hardwareimplementierung umgewandelt wird. Gemäß einer Ausführungsform der vorliegenden Erfindung kann der Benutzer, entweder während der Erzeugung des graphischen Programms oder beim Auswählen der Option zum Umwandeln des graphischen Programms in ausführbare Form auswählen, welche Abschnitte von Modulen in die Hardwareform zu übersetzen sind. Demgemäß kann der Benutzer einen ersten Abschnitt des graphischen Programms auswählen, der vorzugsweise den Überwachungssteuerungs- und Anzeigeabschnitt des Programms enthält, der zur Ausführung auf einer CPU in Maschinensprache zu übersetzen ist. Gemäß der vorliegenden Erfindung kann der Benutzer einen zweiten Abschnitt des graphischen Programms auswählen, der für die Hardwareimplementierung erwünscht ist.
Der für die Hardwareimplementierung ausgewählte Abschnitt des graphischen Programms wird zuerst in eine Hardwarebeschreibung, wie eine VHDL-Beschreibung, exportiert. Die Hardwarebeschreibung wird dann in eine Netzliste, vorzugsweise eine FPGA-spezifische Netzliste, umgewandelt. Die Hardwarebeschreibung wird durch ein Synthesewerkzeug in eine Netzliste umgewandelt. Die Netzliste wird dann in eine auch als Software-Bitstrom bekannte FPGA-Programmdatei übersetzt. Bei der bevorzugten Ausführungsform wird die Hardwarebeschreibung direkt in eine FPGA-Programmdatei umgewandelt.
Der Schritt des Übersetzens der sich ergebenden Netzliste in eine FPGA-Programmdatei verwendet vorzugsweise eine Bibliothek vorübersetzter Funktionsblöcke, um beim Übersetzen zu helfen, sowie Hardware-zielspezifische Informationen. Die Bibliothek vorübersetzter Funktionsblöcke enthält Netzlistenbibliotheken für Strukturknoten, wie For/Next-Schleifen, While/Do-Schleifen, Fallstrukturen und Sequenzstrukturen und andere. Dies ermöglicht es dem Benutzer, mit höheren Programmier-Konstruktionselementen, wie Iterationen, Schleifen und Fallstrukturen, zu programmieren, während ermöglicht wird, daß das resultierende Programm direkt in Hardware ausgeführt wird.
Der sich ergebende Bitstrom wird dann in eine FPGA übertragen, um eine programmierte FPGA zu erzeugen, die dem graphischen Programm oder Blockdiagramm entspricht.
Die bevorzugte Ausführungsform der Erfindung umfaßt ein Computersystem für allgemeine Zwecke, das eine CPU und einen Speicher enthält, sowie eine mit dem Computersystem gekoppelte Schnittstellenkarte oder Vorrichtung, die programmierbare Hardware oder Logik, wie eine FPGA, enthält. Das Computersystem weist auf diese Weise ein graphisches Programmiersystem auf, das zum Entwickeln des graphischen Programms verwendet wird. Das Computersystem weist auch Software gemäß der bevorzugten Ausführungsform auf, die in der Lage ist, das graphische Programm in eine Hardwarebeschreibung umzuwandeln. Das Computersystem umfaßt weiterhin ein Synthesewerkzeug, das zum Übersetzen der Hardwarebeschreibung in eine FPGA-spezifische Netzliste verwendet wird, sowie andere Werkzeuge zum Umwandeln der Netzliste in eine FPGA-Programmdatei zum Herunterladen in die FPGA. Das Computersystem umfaßt weiterhin eine Bibliothek vorübersetzter Funktionsblöcke gemäß der vorliegenden Erfindung, die von dem Synthesewerkzeug verwendet werden, um beim Übersetzen der Netzliste in den Software-Bitstrom zu helfen.
Bei einer Ausführungsform umfaßt die Zielvorrichtung mit der umkonfigurierbaren Hardware oder FPGA, die programmiert wird, eine Schnittstellenkarte in dem Computersystem, wie eine Datenerfassungskarte, eine IEC-Bus-Schnittstellenkarte oder eine VXI-Schnittstellenkarte. Bei einer alternativen Ausführungsform weist die programmierte Zielvorrichtung ein Instrument oder eine Vorrichtung auf, das oder die, beispielsweise über eine serielle Verbindung, mit dem Computer verbunden ist. Es sei bemerkt, daß das programmierte Zielinstrument oder die programmierte Zielvorrichtung mit einer FPGA oder einem anderen konfigurierbaren Hardwareelement nach Wunsch eine beliebige von verschiedenen Formen annehmen kann.
Verschiedene Ausführungsformen der vorliegenden Erfindung werden nun nur als Beispiel mit Bezug auf die anliegende Zeichnung beschrieben.
1 zeigt ein Instrumentensteuersystem.
1A zeigt ein industrielles Automatisierungssystem.
2 zeigt ein Blockdiagramm des Instrumentensteuersystems aus 1.
3, 3A und 3B zeigen Blockdiagramme, in denen eine mit programmierbarer Hardware gemäß verschiedenen Ausführungsformen der vorliegenden Erfindung konfigurierte Schnittstellenkarte dargestellt ist.
4 zeigt ein Flußdiagramm, in dem die Funktionsweise einer bevorzugten Ausführungsform dargestellt ist.
4A zeigt ein detaillierteres Flußdiagramm, in dem die Funktionsweise der bevorzugten Ausführungsform der Erfin-dung dargestellt ist, wobei ein erster Abschnitt des graphischen Programms in Maschinensprache übersetzt wird und ein zweiter Abschnitt des graphischen Programms in eine Hardwareimplementation umgewandelt wird.
5 zeigt ein detaillierteres Flußdiagramm, in dem eine Erzeugung eines graphischen Programms gemäß der bevorzugten Ausführungsform dargestellt ist.
6 zeigt ein detaillierteres Flußdiagramm, in dem der Vorgang des Exportierens wenigstens eines Abschnitts eines graphischen Programms in eine Hardwarebeschreibung dargestellt ist.
7 zeigt ein Flußdiagramm, in dem der Vorgang dargestellt ist, bei dem das Verfahren ein Eingabeterminal in eine Hardwarebeschreibung exportiert.
8 zeigt ein Flußdiagramm, in dem der Vorgang dargestellt ist, bei dem das Verfahren einen Funktionsknoten in eine Hardwarebeschreibung exportiert.
9 zeigt ein Flußdiagramm, in dem der Vorgang dargestellt ist, bei dem das Verfahren ein Ausgabeterminal in eine Hardwarebeschreibung exportiert.
10 zeigt ein Flußdiagramm, in dem der Vorgang dargestellt ist, bei dem das Verfahren einen Strukturknoten in eine Hardwarebeschreibung exportiert.
11 zeigt eine Umwandlung einer Knoten-Hardwarebeschreibung in eine Netzliste.
12 zeigt eine Umwandlung einer Strukturknoten-Hardwarebeschreibung in eine Netzliste.
13 zeigt den Funktionsblock für einen Strukturknoten.
14 zeigt ein Zustandsdiagramm, in dem die Funktionsweise des Strukturknoten-Funktionsblocks aus 13 dargestellt ist.
15 und 16 zeigen ein einfaches Beispiel einer Funktionsweise einer bevorzugten Ausführungsform, wobei 15 ein einfaches graphisches Programm und 16 ein Konzeptdiagramm der Hardwarebeschreibung des graphischen Programms aus 15 zeigt.
17–19 zeigen ein weiteres Beispiel einer Funktionsweise einer bevorzugten Ausführungsform, wobei 17 ein graphisches Programm, 18 einen Baum ansprechend auf das graphische Programm aus 17 erzeugter Datenstrukturen und 18 ein Konzeptdiagramm der Hardwarebeschreibung des graphischen Programms aus 17 zeigt.
20–21 zeigen ein als examplel.vi bezeichnetes graphisches Programm.
Wenngleich an der Erfindung verschiedene Modifikationen vorgenommen werden können und alternative Formen davon möglich sind, sind in der Zeichnung spezifische Ausführungsformen beispielhaft dargestellt und werden hier detailliert beschrieben. Es ist jedoch zu verstehen, daß die Zeichnung und die detaillierte Beschreibung die Erfindung nicht auf die offenbarte spezielle Form beschränken sollen. Vielmehr soll die Erfindung alle Modifikationen, gleichwertige Formen und Alternativen abdecken, die innerhalb des durch die anliegenden Ansprüche definierten Schutzumfangs der vorliegenden Erfindung liegen.
1 und 1A – Instrumente und industrielle Automatisierungssysteme
In 1 ist ein Instrumentensteuersystem 100 dargestellt. Das System 100 weist einen Computer 102 auf, der mit einem oder mehreren Instrumenten verbunden ist. Der Computer 102 weist eine CPU, einen Anzeigebildschirm, einen Speicher und eine oder mehrere Eingabevorrichtungen, wie bspw. eine Maus oder eine Tastatur, auf, wie dargestellt ist. Der Computer 102 ist über das eine oder die mehreren Instrumente verbunden, um eine Testeinheit (UUT) oder einen Prozeß 130 zu analysieren, zu messen oder zu steuern.
Das eine oder die mehreren Instrumente können ein IEC-Bus-Instrument 112, eine Datenerfassungsplatine 114 und/oder ein VXI-Instrument 116 einschließen. Das IEC-Bus-Instrument 112 ist über eine von dem Computer 102 bereitgestellte IEC-Bus-Schnittstellenkarte 122 mit dem Computer 102 gekoppelt. Die Datenerfassungsplatine 114 ist mit dem Computer 102 gekoppelt und vorzugsweise über eine Signalaufbereitungs-Schaltungsanordnung 124 mit der UUT verbunden. Die Signalaufbereitungs-Schaltungsanordnung 124 weist vorzugsweise ein SCXI-(Signal Conditioning eXtensions for Instrumentation)-Gehäuse mit einem oder mehreren SCXI-Modulen 126 auf. Sowohl die IEC-Bus-Karte 122 als auch die DAQ-Karte 114 sind typischerweise in einen E/A-Schlitz in dem Computer 102, wie einen PCI-Bus-Schlitz, einen PC-Karten-Schlitz oder einen ISA-, EISA- oder Mikrokanal-Bus-Schlitz eingesteckt, der von dem Computer 102 bereitgestellt wird. Diese Karten 122 und 114 sind jedoch zu Erläuterungszwecken außerhalb des Computers 102 dargestellt. Das VXI-Instrument 116 ist über einen VXI-Bus, MXI-Bus oder einen anderen seriellen oder parallelen Bus, der von dem Computer 102 bereitgestellt wird, mit dem Computer 102 gekoppelt. Der Computer 102 weist vorzugsweise eine VXI-Schnittstellenlogik, wie bspw. eine VXI-, MXIoder IEC-Bus-Schnittstellenkarte (nicht dargestellt), auf, die in dem Computer enthalten ist. Ein (nicht dargestelltes) serielles Instrument kann auch über einen seriellen Port, wie bspw. eine RS-232-Ports, ein USB-(Universal Serial Bus)- oder IEEE-1394- oder 1394.2-Busses, der von dem Computer 102 bereitgestellt wird, mit dem Computer 102 gekoppelt sein. Bei typischen Instrumentensteuersystemen sind nicht Instrumente jedes Schnittstellentyps vorhanden, und viele Systeme können tatsächlich nur ein oder mehrere Instrumente eines einzigen Schnittstellentyps, beispielsweise nur IEC-Bus-Instrumente, aufweisen.
Bei der Ausführungsform aus 1 weisen eine oder mehrere mit dem Computer 102 verbundene Vorrichtungen gemäß der bevorzugten Ausführungsform eine programmierbare oder umkonfigurierbare Hardware auf. Beispielsweise weisen gemäß einer bevorzugten Ausführungsform eine oder mehrere von der IEC-Bus-Karte 122, der DAQ-Karte 114 und der VXI-Karte eine programmierbare Hardware auf. Alternativ oder zusätzlich umfassen eines oder mehrere von dem IEC-Bus-Instrument 112, dem VXI-Instrument 116 oder dem seriellen Instrument gemäß einer bevorzugten Ausführungsform programmierbare Hardware. Bei der bevorzugten Ausführungsform umfaßt die programmierbare Hardware eine FPGA (feldprogrammierbare Gatteranordnung).
Die Instrumente sind mit der Testeinheit (UUT) oder dem Prozeß 130 gekoppelt oder sie sind gekoppelt, um typischerweise von Gebern erzeugte Feldsignale zu empfangen. Das System 100 kann bei einer Datenerfassungs- oder Steueranwendung, bei einer Test- und Meßanwendung, bei einer Prozeßsteueranwendung oder bei einer Mensch-Maschine-Kommunikations-Anwendung eingesetzt werden.
In 1A ist ein industrielles Automatisierungssystem 140 dargestellt. Das industrielle Automatisierungssystem 140 ähnelt dem in 1 dargestellten Instrumenten- oder Test- und Meßsystem 100. Elemente, die Elementen in 1 ähneln oder mit diesen identisch sind, haben zweckmäßigerweise die gleichen Bezugszahlen. Das System 140 umfaßt einen Computer 102, der mit einer oder mehreren Vorrichtungen oder Instrumenten verbunden ist. Der Computer 102 weist eine CPU, einen Anzeigebildschirm, einen Speicher und eine oder mehrere Eingabevorrichtungen, wie bspw. eine Maus oder eine Tastatur, auf, wie dargestellt ist. Der Computer 102 ist über die eine oder die mehreren Vorrichtungen mit einem Prozeß oder einer Vorrichtung 160 verbunden, um eine Automatisierungsfunktion, wie bspw. eine MMI (Mensch-Maschine-Schnittstelle), SCADA (Supervisory Control and Data Acquisition – Überwachungssteuerung und Datenerfassung), eine tragbare oder verteilte Erfassung, eine fortschrittliche Analyse oder eine Steuerung, durchzuführen.
Die eine oder die mehreren Vorrichtungen können eine Datenerfassungsplatine 114, ein serielles Instrument 142, eine PLC (eine programmierbare Logiksteuereinrichtung) 144 oder eine Feldbus-Netzwerkkarte 156 umfassen. Die Datenerfassungsplatine 114 ist mit dem Computer 102 gekoppelt oder in diesem enthalten und vorzugsweise über die Signalaufbereitungs-Schaltungsanordnung 124 mit dem Prozeß 160 verbunden. Die Signalaufbereitungs-Schaltungsanordnung 124 weist vorzugsweise ein SCXI-(Signal Conditioning eXtensions for Instrumentation)-Gehäuse auf, das ein oder mehrere SCXI-Module 126 enthält. Das serielle Instrument 142 ist über eine serielle Schnittstellenkarte 152 oder über einen seriellen Port, wie bspw. ein RS-232-Port, der von dem Computer 102 bereitgestellt wird, mit dem Computer 102 gekoppelt. Die PLC 144 ist über einen seriellen Port, einen Ethernet-Port oder eine firmeneigene Schnittstelle mit dem Computer 102 gekoppelt. Die Feldbus-Schnittstellenkarte 156 ist vorzugsweise in dem Computer 102 enthalten und über ein Feldbusnetzwerk mit einer oder mehreren Feldbusvorrichtungen, wie bspw. ein Ventil 146, verbunden. Jede von der DAQ-Karte 114, der seriellen Karte 152 und der Feldbuskarte 156 sind typischerweise in einen E/A-Schlitz in dem Computer 102 eingesteckt, wie vorstehend beschrieben wurde. Diese Karten 114, 12 und 156 sind jedoch zu Darstellungszwecken außerhalb des Computers 102 dargestellt. Bei typischen industriellen Automatisierungssystemen sind nicht Vorrichtungen von jedem Schnittstellentyp vorhanden, und viele Systeme können tatsächlich nur eine oder mehrere Vorrichtungen eines einzigen Schnittstellentyps, beispielsweise nur PLCs, aufweisen. Die Vorrichtungen sind mit der Vorrichtung oder dem Prozeß 160 gekoppelt.
Bei der Ausführungsform aus 1A umfassen eine oder mehrere der mit dem Computer 102 verbundenen Vorrichtungen eine programmierbare Hardware gemäß der vorliegenden Erfindung. Beispielsweise enthalten eine oder mehrere von der Datenerfassungsplatine 114, dem seriellen Instrument 142, der seriellen Schnittstellenkarte 152, der PLC 144 oder der Feldbus-Netzwerkkarte 156 programmierbare Hardware gemäß der vorliegenden Erfindung. Bei der bevorzugten Ausführungsform weist die programmierbare Hardware eine FPGA (feldprogrammierbare Gatteranordnung) auf.
Wiederum mit Bezug auf die 1 und 1A sei bemerkt, daß der Computer 102 vorzugsweise ein Speichermedium, wie bspw. ein nichtflüchtiges Medium, z. B. ein magnetisches Medium, eine CDROM, Disketten 104 oder ein flüchtiges Medium, wie bspw. ein Computersystemspeicher, z. B. einen Direktzugriffsspeicher (RAM), aufweist. Das Speichermedium speichert vorzugsweise ein graphisches Programmierentwicklungssystem zum Entwickeln graphischer Programme. Das Speichermedium speichert auch Computerprogramme gemäß der vorliegenden Erfindung, die ausführbar sind, um wenigstens einen Abschnitt eines graphischen Programms in eine Form zum Konfigurieren oder Programmieren der programmierbaren Hardware oder der FPGA umzuwandeln. Die bevorzugte Ausführungsform umfaßt ein in einem Speicher und/oder einer Festplatte des Computers 102 gespeichertes und von einer CPU des Computers 102 ausgeführtes Softwareprogramm. Die Code und Daten aus dem Speicher ausführende CPU umfaßt demgemäß eine Einrichtung zum Umwandeln graphischen Codes in eine Hardwareimplementation gemäß den nachstehend beschriebenen Schritten.
Die Instrumente oder Vorrichtungen in den 1 und 1A werden durch graphische Softwareprogramme gesteuert, wobei wahlweise ein Abschnitt von diesen in der CPU des Computers 102 ausgeführt wird und wobei wenigstens ein Abschnitt von diesen zur Hardwareausführung in die programmierbare Hardware heruntergeladen wird. Die graphischen Softwareprogramme, die eine Datenerfassung, eine Datenanalyse und/oder eine Präsentation, beispielsweise für Instrumentensteuerungen oder eine industrielle Automatisierung, ausführen, werden als virtuelle Instrumente bezeichnet.
Die bevorzugte Ausführungsform besteht aus dem graphischen Programmiersystem LabVIEW oder BridgeVIEW von National Instruments, die nachstehend zusammenfassend als LabVIEW bezeichnet werden. Bei der bevorzugten Ausführungsform soll der Begriff "LabVIEW" auch graphische Programmiersysteme einschließen, die eine G-Programmierfunktionalität enthalten, die also wenigstens einen Abschnitt der graphischen Programmierfunktionalität von LabVIEW enthalten, wobei dies das graphische Programmiersystem BridgeVIEW einschließt.
Der Begriff "graphisches Programmiersystem" soll weiterhin beliebige der verschiedenen Systemtypen einschließen, die zum Entwickeln oder Erzeugen graphischen Codes oder graphischer Programme verwendet werden, wobei diese LabVIEW und BridgeVIEW von National Instruments, Visual Designer von Intelligent Instrumentation, VEE (Visual Engineering Environment) von Hewlett-Packard, Snap-Master von HEM Data Corporation, DASYLab von DasyTec, GFS DiaDem und ObjectBench von SES (Scientific and Engineering Software) und andere einschließen.
Wenngleich bei der bevorzugten Ausführungsform die graphischen Programme und die programmierbare Hardware an der Datenerfassung bzw. Datenerzeugung, Datenanalyse und/oder Datenanzeige beteiligt sind und zum Steuern oder Modellieren von Instrumenten oder industrieller Automatisierungshardware verwendet werden, ist zu verstehen, daß die vorliegende Erfindung zum Erzeugen von Hardwareimplementationen graphischer Programme für eine Vielzahl von Anwendungen verwendet werden kann und nicht auf Instrumentenanwendungen oder industrielle Automatisierungsanwendungen beschränkt ist. Mit anderen Worten dienen die 1 und 1A nur als Beispiel, und die bevorzugten Ausführungsformen können in beliebigen von verschiedenen Typen von Systemen verwendet werden. Demgemäß sind das System und die Verfahren gemäß den bevorzugten Ausführungsformen verwendbar, automatisch Hardwareimplementierungen von graphischen Programmen oder graphischen Code für beliebige von verschiedenen Anwendungstypen zu erzeugen, die Softwareanwendungen für allgemeine Zwecke, wie Textbearbeitung, Tabellenkalkulation, Netzwerksteuerung, Spiele usw. einschließen.
Computerblockdiagramm
In 2 ist ein Blockdiagramm des Computers 102 (aus 1) dargestellt. Die Elemente eines Computers, die nicht erforderlich sind, um die Funktionsweise der bevorzugten Ausführungsformen zu verstehen, wurden der Einfachheit halber fortgelassen. Der Computer 102 umfaßt wenigstens eine Zentralverarbeitungseinheit oder CPU 160, die mit einem Prozessor oder Hauptbus 162 gekoppelt ist. Die CPU 160 kann eine beliebige von verschiedenen Typen, einschließlich eines x86-Prozessors, eines PowerPC-Prozessors, einer CPU aus der Motorola-Prozessorfamilie, eine CPU aus der SPARC-RISC-Prozessorfamilie oder eines anderen Typs sein. Der Hauptspeicher 166 ist durch eine Speichersteuereinrichtung 164 mit dem Hauptbus 162 gekoppelt. Der Hauptspeicher 166 speichert ein graphisches Programmiersystem und auch Software zum Umwandeln wenigstens eines Abschnitts eines graphischen Programms in einer Hardwareimplementierung. Diese Software wird nachstehend in näheren Einzelheiten erörtert. Der Hauptspeicher 166 speichert auch Betriebssystemsoftware sowie die Software zum Betrieb des Computersystems, wie Fachleuten wohlbekannt ist.
Der Hauptbus 162 ist durch eine Bussteuereinrichtung 168 oder eine Busbrückenlogik mit einem Erweiterungs- oder Ein-/Ausgabebus 170 gekoppelt. Der Erweiterungsbus 170 ist vorzugsweise der PCI-(Peripheral Component Interconnect – Peripheriekomponenten)-Erweiterungsbus, wenngleich auch andere Bustypen verwendet werden können. Der Erweiterungsbus 170 weist Schlitze für verschiedene Vorrichtungen, wie bspw. die Datenerfassungsplatine 114 (aus 1), eine IEC-Bus-Schnittstellenkarte 122, die das IEC-Bus-Instrument 112 (aus 1) mit einer IEC-Bus-Schnittstelle versieht, und eine VXI- oder MXI-Buskarte 230, auf, die mit dem VXI-Gehäuse 116 gekoppelt ist, um VXI-Instrumente zu empfangen. Der Computer 102 weist weiterhin ein Videoanzeige-Untersystem 180 und ein Festplattenlaufwerk 182 auf, die mit dem Erweiterungsbus 170 gekoppelt sind.
Eine oder mehrere Schnittstellenkarten oder Vorrichtungen, die mit dem Erweiterungsbus gekoppelt sind, wie die DAQ-Karte 114, die IEC-Bus-Schnittstellenkarte 122, das IEC-Bus-Instrument 112 oder die VXI- oder MXI-Buskarte 230, weisen ein eingebettetes System mit einer eingebetteten CPU und einem eingebetteten Speicher auf.
Programmierbares Hardwarediagramm
In 3 ist ein Blockdiagramm dargestellt, das eine Schnittstellenkarte zeigt, die mit einer programmierbaren Hardware gemäß der vorliegenden Erfindung konfiguriert ist. Es sei bemerkt, daß 3 nur als Beispiel dient und daß eine Schnittstellenkarte oder Vorrichtung, die mit der programmierbaren Hardware gemäß der bevorzugten Ausführungsform konfiguriert ist, nach Wunsch verschiedene Architekturen und Formen aufweisen kann. Die in 3 dargestellte Schnittstellenkarte ist die in 1 oder die in 1A dargestellte DAQ-Schnittstellenkarte 114. Wie vorstehend erwähnt wurde, kann die programmierbare Hardware jedoch nach Wunsch auf beliebigen der verschiedenen in den 1 und 1A dargestellten Vorrichtungen oder auf anderen Vorrichtungen hinzugefügt werden.
Wie dargestellt ist, weist die Schnittstellenkarte 114 einen E/A-Anschluß 202 auf, der zum Empfang von Signalen gekoppelt ist. In den Ausführungsformen aus den 1 und 1A liefert der E/A-Anschluß 202 analoge und/oder digitale Verbindungen zum Empfangen bzw. Bereitstellen analoger oder digitaler Signale. Der E/A-Anschluß 202 ist dafür ausgelegt, mit der SCXI-Aufbereitungslogik 124 und 126 gekoppelt zu werden, oder er ist dafür ausgelegt, direkt mit einer Testeinheit 130 oder einem Prozeß 160 gekoppelt zu werden.
Die Schnittstellenkarte 114 weist auch eine Datenerfassungslogik (DAQ-Logik) 204 auf. Wie dargestellt ist, weist die Datenerfassungslogik 204 Analog-Digital-Wandler (A/D-Wandler), Digital-Analog-Wandler (D/A-Wandler), eine Zeitgeber/Zähler-Logik (TC-Logik) und eine Signalaufbereitungslogik (SC-Logik) auf. Die DAQ-Logik 204 liefert die Datenerfassungsfunktionalität der DAQ-Karte 114.
Gemäß der bevorzugten Ausführungsform der Erfindung weist die Schnittstellenkarte 114 ein programmierbares Hardwareelement oder einen programmierbaren Prozessor 206 auf. Bei der bevorzugten Ausführungsform weist die programmierbare Hardware 206 eine feldprogrammierbare Gatteranordnung (FPGA), wie bspw. diejenigen auf, die von Xilinx, Altera usw. erhältlich sind. Das programmierbare Hardwareelement 206 ist mit der DAQ-Logik 204 gekoppelt, und es ist auch mit der lokalen Busschnittstelle 208 gekoppelt. Demgemäß kann ein graphisches Programm auf dem Computer 102 oder einem weiteren Computer in einem vernetzten System erzeugt werden, und wenigstens ein Abschnitt des graphischen Programms kann zur Ausführung in der FPGA 206 in eine Hardwareimplementationsform umgewandelt werden. Der in eine Hardwareimplementationsform umgewandelte Abschnitt des graphischen Programms ist vorzugsweise ein Abschnitt, der eine schnelle Ausführung und/oder eine Echtzeitausführung benötigt.
Bei der Ausführungsform aus 3 weist die Schnittstellenkarte 114 weiterhin einen zweckgebundenen Mikroprozessor 212 und einen Speicher 214 auf, die auf der Platine vorhanden sind. Dies ermöglicht es, daß ein Abschnitt des graphischen Programms zum Speichern im Speicher 214 und zur Ausführung durch den Mikroprozessor 212 in die Maschinensprache übersetzt wird. Dies kommt zu einem Abschnitt des graphischen Programms hinzu, der in eine Hardwareimplementationsform in der FPGA 206 umgewandelt wird. Demgemäß wird bei einer Ausführungsform, nachdem ein graphisches Programm erzeugt worden ist, ein Abschnitt des graphischen Programms zur Ausführung in der eingebetteten CPU 212 übersetzt und über die CPU 212 und den Speicher 214 lokal auf der Schnittstellenkarte 114 ausgeführt, und ein zweiter Abschnitt des graphischen Programms wird in ein hardwareausführbares Format umgewandelt oder konvertiert und zur Hardwareimplementation in das FPGA 206 heruntergeladen.
Wie dargestellt ist, weist die Schnittstellenkarte 114 weiter eine Busschnittstellenlogik 216 und einen Steuer-/Datenbus 218 auf. Bei der bevorzugten Ausführungsform ist die Schnittstellenkarte 114 eine mit dem PCI-Bus kompatible Schnittstellenkarte, die zur Kopplung mit dem PCI-Bus des Hauptcomputers 102 oder zur Kopplung mit einem PXI-(PCI eXtensions for Instrumentation)-Bus ausgelegt ist. Die Busschnittstellenlogik 216 und der Steuer-/Datenbus 218 stellen demgemäß eine PCI- oder PXI-Schnittstelle bereit.
Die Schnittstellenkarte 114 weist auch eine lokale Busschnittstellenlogik 208 auf. Bei der bevorzugten Ausführungsform weist die lokale Busschnittstellenlogik 208 einen RTSI-(Real Time System Integration – Echtzeit-Systemintegration)-Bus zum Vermitteln von Zeit- und Auslösesignalen zwischen der Schnittstellenkarte 114 und einer oder mehreren anderen Vorrichtungen oder Karten auf.
Bei einer Ausführungsform weist die Schnittstellenkarte 114 auch einen nichtflüchtigen Speicher 215 auf, der mit dem programmierbaren Hardwareelement 206 gekoppelt ist. Der nichtflüchtige Speicher ist in der Lage, die von dem Hauptcomputersystem empfangene Hardwarebeschreibung zu speichern, um die Ausführung der Hardwarebeschreibung in dem programmierbaren Hardwareelement 206 vor dem Booten des Computersystems 102 oder während des Bootens von diesem zu ermöglichen.
Bei der Ausführungsform aus 3A sind die CPU 212 und der Speicher 214 nicht auf der Schnittstellenkarte 114 vorhanden, und es wird demgemäß nur der Abschnitt des graphischen Programms, der in die Hardwareimplementationsform umgewandelt wird, in das FPGA 206 heruntergeladen. Daher wird bei der Ausführungsform aus 3A jeder Überwachungssteuerabschnitt des graphischen Programms, der erforderlich oder erwünscht ist, um in Maschinensprache auf einer programmierbaren CPU ausgeführt zu werden, von der Haupt-CPU in dem Computersystem 102 ausgeführt und nicht lokal von einer CPU auf der Schnittstellenkarte 114 ausgeführt.
Bei der Ausführungsform aus 3B ist die CPU 212 nicht auf der Schnittstellenkarte 114 vorhanden, so daß die Schnittstellenkarte 114 die FPGA 206 und den Speicher 214 enthält. Bei dieser Ausführungsform wird der Speicher 214 zum Speichern von FPGA-Zustandsinformationen verwendet. 3B zeigt die gegenwärtig bevorzugte Ausführungsform.
4 – Umwandeln graphischen Codes in eine Hardwareimplementierung
In 4 ist ein Flußdiagramm dargestellt, in dem die Funktionsweise der bevorzugten Ausführungsform dargestellt ist. Die bevorzugte Ausführungsform umfaßt ein computerimplementiertes Verfahren zum Erzeugen von Hardwareimplementierungen graphischer Programme oder graphischen Codes. Es ist zu verstehen, daß verschiedene der Schritte in den nachstehenden Flußdiagrammen gleichzeitig oder in anderen Reihenfolgen auftreten können.
In dem nachstehenden Verfahren wird vorausgesetzt, daß ein graphisches Programmierentwicklungssystem zur Erzeugung graphischer Programme in dem Speicher des Computersystems gespeichert ist. Bei der bevorzugten Ausführungsform ist das graphische Programmiersystem das von National Instruments erhältliche graphische Programmiersystem LabVIEW. Bei diesem System erzeugt der Benutzer das graphische Programm in einer graphischen Programmplatte, die als ein Blockdiagrammfenster bezeichnet wird, und er erzeugt auch eine Benutzerschnittstelle in einer graphischen Frontplatte. Das graphische Programm wird manchmal als ein virtuelles Instrument (VI) bezeichnet. Das graphische Programm oder VI hat typischerweise eine Hierarchie von Unter-Graphikprogrammen und Unter-VIs.
Wie dargestellt ist, erzeugt der Benutzer in Schritt 302 ein graphisches Programm, das manchmal auch als ein Blockdiagramm bezeichnet wird. Bei der bevorzugten Ausführungsform enthält das graphische Programm ein graphisches Datenflußdiagramm, das die Funktionalität des auszuführenden Programms spezifiziert. Dieses graphische Datenflußdiagramm ist vorzugsweise direkt in Maschinensprachencode übersetzbar, der auf einem Computersystem ausführbar ist.
In Schritt 304 exportiert das Verfahren wenigstens einen Abschnitt des graphischen Programms in eine Hardwarebeschreibung. Nachdem der Benutzer in Schritt 302 demgemäß ein graphisches Programm erzeugt hat, wählt er eine Option aus, um einen Abschnitt des graphischen Programms in eine Hardwarebeschreibung zu exportieren. Die Hardwarebeschreibung ist vorzugsweise eine VHDL-Beschreibung, beispielsweise eine VHDL-Quellendatei oder alternativ eine Netzlistenbeschreibung hoher Ebene. Die Hardwarebeschreibung umfaßt eine Hardwarebeschreibung hoher Ebene von Funktionsblöcken, Logik, Eingängen und Ausgängen, welche die von dem graphischen Programm angegebene Operation ausführen. Der Vorgang des Exportierens wenigstens eines Abschnitts des graphischen Programms in eine Hardwarebeschreibung wird in näheren Einzelheiten zusammen mit dem Flußdiagramm aus 6 erörtert.
Bei einer Ausführungsform spezifiziert der Benutzer während der Erzeugung des graphischen Programms in Schritt 302 Abschnitte, beispielsweise Unter-VIs, welche zur Umwandlung in eine Hardwareimplementation in das Hardwarebeschreibungsformat zu exportieren sind. Wenn der Benutzer bei einer weiteren Ausführungsform die Option zum Exportieren eines Abschnitts des graphischen Programms in das Hardwarebeschreibungsformat auswählt, wählt er aus, welche Module oder Unter-VIs zu dieser Zeit in die Hardwarebeschreibung zu exportieren sind.
In Schritt 306 wandelt das Verfahren die Hardwarebeschreibung in eine FPGA-spezifische Netzliste um. Die Netzliste beschreibt die Komponenten, die in der Hardware vorhanden sein müssen, sowie ihre Verbindungen. Eine Umwandlung der Hardwarebeschreibung in die FPGA-spezifische Netzliste wird vorzugsweise von beliebigen der verschiedenen Typen im Handel erhältlicher Synthesewerkzeuge, wie bspw. diejenigen, die von Xilinx, Altera usw. erhältlich sind, ausgeführt.
Bei der bevorzugten Ausführungsform kann der Umwandlungsschritt 306 einen oder mehrere vorübersetzte Funktionsblöcke aus einer Bibliothek vorübersetzter Funktionsblöcke 208 verwenden. Demgemäß enthält die in Schritt 304 erzeugte Hardwarebeschreibung für bestimmte Funktionsblöcke, die schwierig oder weniger wirksam von einer Hardwarebeschreibung in ein Netzlistenformat zu übersetzen sind, einen Bezug auf einen vorübersetzten Funktionsblock aus der Bibliothek 308. Alternativ sind Hardwareimplementationen für alle Funktionsblöcke in der Funktionsbibliothek enthalten. Die jeweiligen vorübersetzten Funktionsblöcke werden einfach an Stelle dieser Referenzen in Schritt 306 in die Netzliste eingefügt. Die bevorzugte Ausführungsform enthält demgemäß die Bibliothek 308 vorübersetzter Funktionsblöcke, die auch als die Komponentenbibliothek bezeichnet wird, wobei die vorübersetzten Funktionsblöcke beim Erzeugen der Netzliste verwendet werden. Die bevorzugte Ausführungsform enthält auch hardwarezielspezifische Informationen 310, die in Schritt 306 beim Umwandeln der Hardwarebeschreibung in eine Netzliste, die für einen bestimmten Typ oder eine bestimmte Klasse von FPGAs spezifisch ist, verwendet werden.
In Schritt 312 übersetzt das Verfahren die Netzliste in eine FPGA-Programmdatei, die auch als Software-Bitstrom bezeichnet wird. Die FPGA-Programmdatei ist eine Datei, die leicht zum Programmieren einer FPGA heruntergeladen werden kann.
Nachdem die Netzliste in Schritt 312 zu einer FPGA-Programmdatei kompiliert worden ist, überträgt das Verfahren in Schritt 314 die FPGR-Programmdatei in die programmierbare Hardware, beispielsweise die FPGA, um eine mit dem graphischen Programm äquivalente programmierte Hardware zu erzeugen. Demgemäß wird nach Abschluß des Schritts 314 der Abschnitt eines in Schritt 304 referenzierten graphischen Programms als eine Hardwareimplementierung in ein FPGA oder ein anderes programmierbares Hardwareelement aufgenommen.
Es sei bemerkt, daß verschiedene der vorstehenden Schritte kombiniert werden können und/oder für den Benutzer unsichtbar gemacht werden können. Beispielsweise können die Schritte 306 und 312 ebenso wie die Schritte 304 und 306 zu einem einzigen Schritt kombiniert werden. Bei der bevorzugten Ausführungsform kann der Benutzer, nachdem er das graphische Programm in Schritt 302 erzeugt hat, einfach eine Hardwareexportoption auswählen und das Hardwareziel oder den Hardware-Bestimmungsort angeben, wodurch bewirkt wird, daß die Schritte 304–314 automatisch ausgeführt werden.
4A – Umwandlung eines graphischen Programms in Maschinensprache- und Hardwareimplementierung
4A zeigt ein detaillierteres Flußdiagramm, in dem die Funktionsweise der bevorzugten Ausführungsform der Erfindung, einschließlich des Übersetzens eines ersten Abschnitts des graphischen Programms in Maschinensprache und des Umwandelns eines zweiten Abschnitts des graphischen Programms in eine Hardwareimplementierung, dargestellt ist.
Wie in 4A dargestellt ist, kann der Benutzer, nachdem er in Schritt 302 ein graphisches Programm erzeugt hat, wahlweise einen ersten Abschnitt auswählen, der für die CPU-Ausführung in den Maschinencode zu übersetzen ist, wie es normalerweise erfolgt. Bei der bevorzugten Ausführungsform wählt der Benutzer vorzugsweise einen Überwachungssteuerungs- und Anzeigeabschnitt des für eine CPU-Ausführung in Maschinencode zu übersetzenden graphischen Programms aus. Der erste Abschnitt, der Überwachungssteuerungs- und Anzeigeabschnitte aufweist, wird zur Ausführung in einer CPU, wie bspw. die Haupt-CPU in dem Computer 102 oder die auf der Schnittstellenkarte 114 vorhandene CPU 212, übersetzt. Dies ermöglicht es, daß die Überwachungssteuerungs- und Anzeigeabschnitte in der Haupt-CPU ausgeführt werden, was für diese Elemente des Programms optimal ist.
Der Benutzer wählt einen zweiten Abschnitt zur Umwandlung in die Hardwareimplementation aus, die wie vorstehend in den Schritten 304–314 aus 4 beschrieben ausgeführt wird. Der Abschnitt des graphischen Programms, der für die Hardwareimplementierung erwünscht ist, weist vorzugsweise Module oder VIs aus, die eine schnelle oder deterministische Implementierung erfordern und/oder die in einer autonomen Hardwareeinheit ausgeführt werden sollen. Im allgemeinen werden Abschnitte des graphischen Programms, die eine schnellere oder deterministischere Ausführung haben sollen, in die Hardwareimplementierung umgewandelt. Bei einer Ausführungsform wird das gesamte graphische Programm für die Umwandlung in eine Hardwareimplementierung ausgewählt, so daß Schritt 322 nicht ausgeführt wird.
5 – Erzeugung eines graphischen Programms
5 zeigt ist ein detaillierteres Flußdiagramm des Schritts 302 aus den 4 und 4A, worin eine Erzeugung eines graphischen Programms gemäß der bevorzugten Ausführungsform der Erfindung dargestellt ist. Wie dargestellt ist, ordnet der Benutzer in Schritt 342 auf dem Bildschirm ein graphisches Programm oder ein Blockdiagramm an. Dies schließt ein, daß der Benutzer verschiedene Bildzeichen oder Knoten auf dem Rnzeigebildschirm, beispielsweise durch Verdrahten, anordnet und verbindet, um ein graphisches Programm zu konfigurieren. Insbesondere wählt der Benutzer verschiedene Funktionsbildzeichen oder andere Bildzeichen aus und ordnet die Bildzeichen in einem Blockdiagrammfeld an oder legt sie in diesem ab und verbindet die Bildzeichen dann oder "verdrahtet" sie, um das graphische Programm zusammenzustellen. Der Benutzer stellt vorzugsweise auch eine Benutzerschnittstelle zusammen, die als eine Frontplatte bezeichnet wird, die Steuerungen und Indikatoren aufweist, welche die Eingabe in das graphische Programm bzw. die Ausgabe aus dem graphischen Programm angeben oder darstellen. Für weitere Informationen zum Erzeugen eines graphischen Programms im graphischen Programmiersystem LabVIEW sei auf das von National Instruments erhältliche LabVIEW-System sowie auf die vorstehend erwähnten Patentanmeldungen verwiesen.
Ansprechend darauf, daß der Benutzer auf dem Bildschirm ein graphisches Programm anordnet, entwickelt und speichert das Verfahren einen Baum von Datenstrukturen, die das graphische Programm darstellen. Wenn der Benutzer demgemäß auf dem Bildschirm Funktionsknoten, Strukturknoten, Ein-/Ausgabeterminals und Verbindungen von Drähten usw. anordnet und einrichtet, entwickelt und speichert das graphische Programmiersystem einen Baum von Datenstrukturen, die das graphische Programm darstellen. Wenn der Benutzer insbesondere jeden einzelnen Knoten und Draht zusammenstellt, entwickelt und speichert das graphische Programmiersystem eine entsprechende Datenstruktur in dem Baum von Datenstrukturen, die den einzelnen Abschnitt des graphischen Programms darstellt, der zusammengestellt wurde. Demgemäß sind die Schritte 342 und 344 ein iterativer Prozeß, welcher wiederholt ausgeführt wird, wenn der Benutzer das graphische Programm erzeugt.
6 – Exportieren eines Abschnitts des graphischen Programms in eine Hardwarebeschreibung
6 zeigt ein Flußdiagramm des Schritts 304 aus den 4 und 4A, worin die Funktionsweise dargestellt ist, wenn das Verfahren einen Abschnitt des graphischen Programms in eine Hardwarebeschreibung exportiert. Der Baum der in Schritt 344 erzeugten und gespeicherten Datenstrukturen enthält vorzugsweise einen hierarchischen Baum von Datenstrukturen auf der Grundlage der Hierarchie und der Verbindbarkeit des graphischen Programms. Wie dargestellt ist, durchläuft das Verfahren in Schritt 362 den Baum von Datenstrukturen, und das Verfahren übersetzt in Schritt 364 jede Datenstruktur in ein Hardwarebeschreibungsformat. Bei einer Ausführungsform flacht das Verfahren den Baum der Datenstrukturen vor dem Durchlaufen des Schritts in Schritt 362 zuerst ab.
Bei der vorliegenden Ausführungsform kann eine Anzahl verschiedener Funktionsbildzeichen und/oder Grundelemente für eine Umwandlung in eine Hardwareimplementierung in einem Diagramm oder graphischen Programm angeordnet werden. Diese Grundelemente umfassen Funktionsknoten, Konstanten, globale Variablen, Steuer- und Indikatorterminals, Strukturknoten und Unter-VIs usw., sind jedoch nicht auf diese beschränkt. Funktionsbildzeichen oder Grundelemente können von einem beliebigen Datentyp sein, sie sind jedoch gemäß der vorliegenden Ausführungsform auf ganzzahlige oder Boolesche Datentypen beschränkt. Weiterhin werden globale Variablen vorzugsweise im Interesse der Bequemlichkeit auf einem einzigen globalen Feld zusammengestellt. Falls ein VI mehrere Male auftritt, ist das VI vorzugsweise ablaufinvariant und kann Zustandsinformationen aufweisen. Falls ein VI nicht ablaufinvariant ist, werden vorzugsweise mehrere Kopien des VI in Hardware erzeugt, falls das VI keine Zustandsinformationen aufweist, und es tritt andernfalls ein Fehler auf.
Bei der bevorzugten Ausführungsform weist jeder Knoten, der in eine Hardwarebeschreibung umgewandelt wird, eine Freigabeeingabe, eine Freigabelöschsignal-Eingabe, eine Haupttaktsignal-Eingabe und ein Ausgangsfreigabe- oder Abschlußsignal auf. Die Freigabeeingabe garantiert, daß der Knoten zur richtigen Zeit ausführt, nämlich wenn alle seine Eingaben empfangen worden sind. Die Freigabelöschsignal-Eingabe wird verwendet, um den Knoten zurückzusetzen, falls Zustandsinformationen daran erinnern, daß der Knoten abgeschlossen wurde. Das Ausgangsfreigabesignal oder Abschlußsignal wird erzeugt, wenn der Knoten abgeschlossen wird, und es wird verwendet, um den Betrieb des nachfolgenden Knotens, der eine Ausgabe vom Knoten empfängt, freizugeben. Jeder Knoten, der in eine Hardwarebeschreibung umgewandelt wird, enthält auch die in dem graphischen Programm dargestellten Datenwege.
Für While-Schleifenstrukturen, Iterationsstrukturen, Sequenzstrukturen und Fallstrukturen wird die jeweilige Struktur im wesentlichen zu einer Steuerschaltung oder einem Steuerblock abstrahiert. Der Steuerblock weist einen Diagrammfreigabeausgang für jedes Unterdiagramm und einen Diagrammabschlußeingang für jedes Unterdiagramm auf.
Zusätzlich zu den vorstehenden Signalen, beispielsweise der Freigabeeingabe, der Freigabelöschsignal-Eingabe, der Haupttaktsignal-Eingabe und dem Ausgangsfreigabe- oder Abschlußsignal weisen alle globalen Variablen zahlreiche zusätzliche Signale, einschließlich CPU-Schnittstellensignale, die für den Typ der CPU und des Busses spezifisch sind, auf, sie weisen jedoch typischerweise Datenleitungen, Adreßleitungen, Takt-, Rücksetz- und Vorrichtungsauswahlsignale auf. Alle VIs und Unter-VIs weisen auch CPU-Schnittstellensignale auf, falls sie eine globale Variable enthalten.
Wenn ein Bildzeichen für ein VI definiert wird, das ausschließlich zum Darstellen eines mit der FPGA ver bundenen Hardwarebetriebsmittels, beispielsweise eines A/D-Wandlers, mit einer Anzahl von Eingängen und Ausgängen verwendet wird, wird bei der bevorzugten Ausführungsform auf der mit VHDL bezeichneten Frontplatte vorzugsweise eine Zeichenkettensteuerung angeordnet. In diesem Fall wird der Standardtext der Zeichenkettensteuerung in der für die VHDL-Beschreibung des VIs erzeugten Textdatei angeordnet. Daher wird bei einer Ausführungsform eine Bibliothek von VIs bereitgestellt, die jeweils eine physikalische Komponente oder ein physikalisches Betriebsmittel darstellen, das in oder für die FPGA verfügbar ist. Wenn diese VHDL-Dateien, die diese VIs darstellen, verwendet werden, überwacht das Verfahren der vorliegenden Erfindung ihre Verwendung, um zu gewährleisten, daß jedes Hardwarebetriebsmittel nur einmal in der Hierarchie der zur FPGA exportierten VIs verwendet wird. Wenn die VHDL-Datei geschrieben wird, werden die Inhalte der Zeichenkettensteuerung zum Definieren des Zugriffsverfahrens für dieses Hardwarebetriebsmittel verwendet.
Nachfolgend wird der Pseudocode angegeben, der die im Flußdiagramm aus 6 ausgeführten Operationen beschreibt:
GenCircuit(vi)

Senden von GenCircuit zu Diagramm höchster Ebene von vi

Diagram (Diagramm): GenCircuit (d)

Senden von GenCircuit zu jeder Konstanten in d
Senden von GenCircuit zu jedem Knoten in d
Senden von GenCircuit zu jedem Signal in d
Signal (Signal): GenCircuit(s)
Erklären des Typs des Signals s

BasicNode (Basisknoten): GenCircuit(n)

Erklären des Typs der für n erforderlichen Komponente
Erklären des UND-Gatters für das Freigeben von n (falls erforderlich)
Auflisten der Verbindungen für alle Knoteneingänge
Auflisten der Verbindungen für alle Eingänge zum Freigeben des UND-Gatters (falls erforderlich)

Constant (Konstante): GenCircuit(c)

Erklären des Typs und des Werts der Konstanten c

WhileLoopNode (While-Schleifenknoten): GenCircuit(n)

Erklären der While-Schleifen-Steuerungskomponente
Erklären des UND-Gatters zum Freigeben von n (falls erforderlich)
Auflisten der Verbindungen für alle Knoteneingänge
Auflisten der Verbindungen für alle Eingänge zum Freigeben des UND-Gatters (falls erforderlich)
Erklären des Typs jeder Schieberegisterkomponente
Auflisten der Verbindungen für alle Eingänge für alle Schieberegister
Erklären des Typs jeder Tunnelkomponente Auflisten der Verbindungen für alle Eingänge zu allen Tunneln

CaseSelectNode (Fallauswahlknoten): GenCircuit(n)

Erklären der Fallauswahl-Steuerkomponente
Erklären des UND-Gatters zum Freigeben von n (falls erforderlich)
Auflisten der Verbindungen für alle Knoteneingänge
Auflisten der Verbindungen für alle Eingänge zum Freigeben des UND-Gatters (falls erforderlich)
Erklären des Typs jeder Tunnelkomponente
Auflisten der Verbindungen für alle Eingänge zu allen Tunneln

SequenceNode (Sequenzknoten): GenCircuit(n)

Erklären der Sequenzsteuerkomponente
Erklären des UND-Gatters zum Freigeben von n (falls erforderlich)
Auflisten der Verbindungen für alle Knoteneingänge
Auflisten der Verbindungen für alle Eingänge zum Freigeben des UND-Gatters (falls erforderlich)
Erklären des Typs jeder Tunnelkomponente Auflisten der Verbindungen für alle Eingänge zu allen Tunneln

SubVINode (Unter-VI-Knoten): GenCircuit(n)

Senden von GenCircuit zum Unter-VI von n
Zuordnen der Eingänge und Ausgänge des Unter-VIs zu jenen von n
Erklären des UND-Gatters zum Freigeben von n (falls erforderlich)
Auflisten der Verbindungen für alle Knoteneingänge
Auflisten der Verbindungen für alle Eingänge zum Freigeben des UND-Gatters (falls erforderlich)

Mit Bezug auf die vorstehende Pseudocode-Liste sei bemerkt, daß das Verfahren auf der VI-Ebene (der höchsten Ebene) beginnt und mit der Erzeugung von VHDL beginnt, indem es eine Nachricht zu dem Diagramm höchster Ebene sendet. Das Verfahren liefert wiederum im wesentlichen eine Nachricht von dem Diagramm für jede Konstante, jeden Knoten und jedes Signal in dem Diagramm.
Für Signale erklärt das Verfahren dann den Signaltyp.
Für Basisknoten erklärt das Verfahren einen Typ der erforderlichen Komponente und auch ein UND-Gatter mit der zum Freigeben erforderlichen geeigneten Anzahl von Eingängen. Mit anderen Worten erklären die Basisknoten ein UND-Gatter mit einer Anzahl von Eingängen, die der Anzahl der von dem Knoten empfangenen Eingänge entspricht. Hierbei wird bevorzugt eine Optimierung ausgeführt, um die Anzahl der tatsächlich erforderlichen Eingänge zu minimieren. Falls ein Knoten beispielsweise drei Eingänge aufweist, braucht der Knoten nicht unbedingt ein UND-Gatter mit drei Eingängen, falls zwei dieser Eingänge von einem einzigen Knoten kommen. Als ein weiteres Beispiel sei erwähnt, daß falls ein Eingang von einem Knoten A kommt und ein anderer Eingang von einem Knoten B kommt, der Knoten A jedoch auch den Knoten B beliefert, der Eingang vom Knoten A im UND-Gatter nicht erforderlich ist. Demgemäß werden verschiedene Optimierungstypen ausgeführt, um die Anzahl der Eingänge jedes UND-Gatters zu verringern. Für den Grundknoten listet das Verfahren auch die Verbindungen für alle seine Eingänge sowie die Verbindungen für alle Eingänge zum Freigeben des UND-Gatters auf.
Für eine Konstante erklärt das Verfahren einfach den Typ und den Wert der Konstanten.
Für eine While-Schleife erklärt das Verfahren eine While-Schleifensteuerungskomponente. Das Verfahren erklärt auch ein UND-Gatter, listet UND-Gatter-Eingänge auf und listet Knoteneingänge in ähnlicher Weise wie bei dem vorstehend beschriebenen Basisknoten auf. Das Verfahren erklärt dann den Typ für jedes Schieberegister und nimmt eine Komponente für das Schieberegister auf und listet alle Verbindungen für die Schieberegistereingänge auf. Falls in der While-Schleife Tunnel vorhanden sind, erklärt das Verfahren den Typ jeder Tunnelkomponente und listet die Verbindungen für die Eingänge zu den Tunneln auf. Für die meisten Tunnel gleicht das Verfahren einfach die Signale für die Eingangsseite und die Ausgangsseite ab, ohne daß sich eine Auswirkung ergibt.
Das Verfahren läuft für Fall- und Sequenzstrukturen ähnlich ab. Für Fall- und Sequenzstrukturen erklärt das Verfahren eine Fallauswahl-Steuerungskomponente bzw. eine Sequenzsteuerungskomponente. Sowohl für Fall- als auch für Sequenzstrukturen erklärt das Verfahren auch ein UND-Gatter, listet UND-Gatter-Eingänge auf und listet Knoteneingänge auf, wobei dies in ähnlicher Weise wie bei dem vorstehend beschriebenen Basisknoten geschieht. Das Verfahren erklärt dann die für irgendwelche Tunnel erforderliche Komponente und listet die Verbindungen für die Eingänge zu den Tunneln auf.
Für ein Unter-VI sendet das Verfahren eine Nachricht zum Unter-VI und ordnet Ein- und Ausgänge des Unter-VIs denjenigen von n zu. Das Verfahren erklärt dann ein UND-Gatter, listet UND-Gatter-Eingänge auf und listet Knoteneingänge auf, wobei dies in ähnlicher Weise wie bei dem vorstehend beschriebenen Basisknoten geschieht.
7 – Exportieren eines Eingabeterminals in eine Hardwarebeschreibung
7 zeigt ein Flußdiagramm, in dem die Funktionsweise dargestellt ist, wenn das Verfahren ein Eingabeterminal in das Hardwarebeschreibungsformat exportiert. Wie dargestellt ist, bestimmt das Verfahren in Schritt 402, ob die dem Eingabeterminal bereitgestellten Daten von einem Abschnitt des graphischen Programms, der auf der CPU ausgeführt wird, also dem Abschnitt des graphischen Programms, der zur Ausführung auf der CPU in Maschinensprache zu kompilieren ist, eingegeben werden, oder ob die Daten von einem anderen Abschnitt des graphischen Programms eingegeben werden, der auch in eine Hardwareimplementation umgewandelt wird.
Falls in Schritt 402 bestimmt wird, daß die in das Eingabeterminal eingegebenen Daten von einem Abschnitt des graphischen Programms einzugeben sind, der zur Ausführung auf der CPU zu übersetzen ist, erzeugt das Verfahren in Schritt 406, wie dargestellt, eine Hardwarebeschreibung eines Schreibregisters mit einem Dateneingang und Daten-und Steuerausgängen. Das Schreibregister kann von dem Hauptcomputer übertragene Daten, d. h. von dem auf der CPU ausgeführten übersetzten Abschnitt erzeugte Daten, empfangen. In Schritt 408 wird der Datenausgang des Schreibregisters zum Bereitstellen einer Datenausgabe mit anderen Elementen in dem graphischen Programmabschnitt verbunden. In Schritt 408 wird der Steuerausgang des Schreibregisters mit anderen Elementen in dem graphischen Programmabschnitt verbunden, um die Ablaufsteuerung der Ausführung zu steuern und dadurch zu ermöglichen, daß die Hardwarebeschreibung die gleiche oder eine ähnliche Ausführungsreihenfolge aufweist wie das graphische Programm.
Falls in Schritt 402 bestimmt wird, daß die Daten nicht von einem Abschnitt einzugeben sind, der zur Ausführung auf der CPU übersetzt wird, die Daten also von einem anderen Knoten in dem in eine Hardwareimplementation umgewandelten Abschnitt stammen, verknüpft das Verfahren in Schritt 404 den Datenausgang vom vorhergehenden Knoten mit diesem Abschnitt der Hardwarebeschreibung und verknüpft den Datenausgang vom vorhergehenden Knoten beispielsweise mit dem Eingang abhängiger Untermodule sowie einer Steuerweglogik, um die Semantik des ursprünglichen graphischen Programms aufrechtzuerhalten.
8 – Exportieren eines Funktionsknotens in eine Hardwarebeschreibung
8 zeigt ein Flußdiagramm, in dem der Vorgang dargestellt ist, bei dem das Verfahren einen Funktionsknoten in das Hardwarebeschreibungsformat exportiert. Bei der bevorzugten Ausführungsform betrifft der Begriff "Funktionsknoten" beliebige von verschiedenen Typen von Bildzeichen oder Einheiten, die eine ausgeführte Funktion darstellen. Demgemäß stellt das Funktionsknoten-Bildzeichen eine im graphischen Programm ausgeführte Funktion dar. Beispiele von Funktionsknoten umfassen arithmetische Funktionsknoten, beispielsweise Addier-, Subtrahier-, Multiplizier- und Dividierknoten, trigonometrische und logarithmische Funktionsknoten, Vergleichs-Funktionsknoten, Umwandlungs-Funktionsknoten, Zeichenketten-Funktionsknoten, Feld- und Cluster-Funktionsknoten, Datei-Ein-/Ausgabe-Funktionsknoten usw.
Wie in 8 dargestellt ist, bestimmt das Verfahren in Schritt 422 die Eingänge und Ausgänge des Funktionsknotens. In Schritt 424 erzeugt das Verfahren eine Hardwarebeschreibung des dem Funktionsknoten entsprechenden Funktionsblocks mit der geeigneten Anzahl der in Schritt 422 bestimmten Ein- und Ausgänge. Alternativ nimmt das Verfahren in Schritt 424 in der Hardwarebeschreibung eine Referenz auf einen vorübersetzten Funktionsblock aus der Bibliothek 308 auf. In diesem Fall enthält das Verfahren auch die vorbestimmte Anzahl der Eingänge und Ausgänge des Funktionsknotens.
In Schritt 426 durchläuft das Verfahren die Eingabeabhängigkeiten des Knotens, um zu bestimmen, welche anderen Knoten Ausgaben bereitstellen, die dem umgewandelten Funktionsknoten als Eingaben zugeführt werden. In Schritt 428 erzeugt das Verfahren eine Hardwarebeschreibung eines UND-Gatters mit N Eingängen, wobei N die Anzahl der Eingänge für den Knoten sind, wobei jeder der N Eingänge mit Steuerausgängen von Knoten verbunden ist, die dem Funktionsknoten Eingaben bereitstellen. Der Ausgang des UND-Gatters ist mit einem Steuereingang des dem Funktionsknoten entsprechenden Funktionsblocks verbunden.
In dem Datenflußdiagramm-Modell der bevorzugten Ausführungsform kann ein Funktionsknoten nur dann ausführen, wenn alle seine Eingaben empfangen worden sind. Das in Schritt 428 erzeugte UND-Gatter emuliert diese Funktion durch Empfangen aller Steuerausgaben von Knoten, die dem Funktionsknoten Eingaben bereitstellen. Demgemäß empfängt das UND-Gatter im wesentlichen alle abhängigen Eingaben, die dem Funktionsknoten zugeführt werden, und führt eine UND-Verknüpfung an ihnen aus, um ein Ausgangssteuersignal bereitzustellen, das festlegt, ob der Funktionsknoten alle Eingaben empfangen hat. Der Ausgang des UND-Gatters ist mit dem Steuereingang des Funktionsblocks verbunden und steuert die Ausführung des Funktionsblocks. Demgemäß wird der Funktionsblock erst dann ausgeführt, wenn die dem Steuereingang des Funktionsblocks zugeführte Ausgabe des UND-Gatters ein logisches Signal bereitstellt, das angibt, daß alle abhängigen Eingaben, die in den Funktionsknoten eingegeben werden, empfangen worden sind.
9 – Exportieren eines Ausgabeterminals in eine Hardwarebeschreibung
9 zeigt ein Flußdiagramm, in dem der Vorgang dargestellt ist, bei dem das Verfahren ein Ausgabeterminal in die Hardwarebeschreibung exportiert. Wie dargestellt ist, bestimmt das Verfahren in Schritt 440, ob die von dem Ausgabeterminal bereitgestellten Daten an einen Abschnitt des graphischen Programms, der auf der CPU ausgeführt wird, also an den Abschnitt des graphischen Programms, der zur Ausführung auf der CPU in die Maschinensprache zu übersetzen ist, ausgegeben werden, oder ob die Daten an einen anderen Abschnitt des graphischen Programms ausgegeben werden, der auch in eine Hardwareimplementation umgewandelt wird.
Falls in Schritt 440 bestimmt wird, daß die vom Ausgabeterminal ausgegebenen Daten in einen Abschnitt des graphischen Programms auszugeben sind, der zur Ausführung auf der CPU übersetzt wird, erzeugt das Verfahren, wie dargestellt, in Schritt 442 eine Hardwarebeschreibung eines Leseregisters mit einem Dateneingang und Daten- und Steuerausgängen. Das Leseregister kann durch einen vorhergehenden Knoten im graphischen Programm darstellende Logik erzeugte Daten empfangen.
In Schritt 444 verbindet das Verfahren den Datenausgang eines vorhergehenden Knotens mit dem Dateneingang des Leseregisters. In Schritt 444 wird der Steuereingang des Leseregisters auch verbunden, um den Ausführungsablauf zu steuern, also zu garantieren, daß das Leseregister die Daten zur richtigen Zeit empfängt. Dies ermöglicht es, daß die Hardwarebeschreibung die gleiche oder eine ähnliche Ausführungsreihenfolge aufweist wie das graphische Programm.
Falls in Schritt 440 festgestellt wird, daß die Daten nicht an einen zur Ausführung auf der CPU übersetzten Abschnitt auszugeben sind, die Daten also an einen anderen Knoten in dem in eine Hardwareimplementation umgewandelten Abschnitt gerichtet sind, verknüpft das Verfahren in Schritt 446 den Datenausgang vom Ausgabeterminal mit einem nachfolgenden Knoten in diesem Abschnitt der Hardwarebeschreibung und verknüpft beispielsweise den Datenausgang vom Ausgabeterminal mit dem Eingang nachfolgender Untermodule sowie von Wegsteuerlogik, um die Semantik des ursprünglichen graphischen Programms beizubehalten.
10 – Exportieren eines Strukturknotens in eine Hardwarebeschreibung
10 zeigt ist ein Flußdiagramm, in dem ein Vorgang dargestellt ist, bei dem das Verfahren einen Strukturknoten in die Hardwarebeschreibung exportiert. Bei der bevorzugten Ausführungsform betrifft der Begriff "Strukturknoten" einen Knoten, der die Ablaufsteuerung von Daten, einschließlich Iterationen, Schleifen, der Folgesteuerung und bedingter Verzweigungen, darstellt. Beispiele von Strukturknoten umfassen For/Next-Schleifen, While/Do-Schleifen, Fallstrukturen oder bedingte Strukturen und Sequenzstrukturen. Für weitere Informationen zu Strukturknoten sei auf die vorstehend erwähnten LabVIEW-Patente verwiesen.
Das Flußdiagramm aus 10 veranschaulicht das Exportieren eines Schleifenstrukturknotens in eine Hardwarebeschreibung. Wie dargestellt ist, untersucht das Verfahren in Schritt 462 die Strukturknotenparameter, beispielsweise die Iterationsanzahl, die Schleifenbedingung, Perioden, Phasenverzögerungen usw. Wie vorstehend erörtert wurde, ermöglicht es das graphische Programmiersystem dem Benutzer vorzugsweise, bestimmte Parameter in einen Strukturknoten einzufügen, um das Exportieren des Strukturknotens in eine Hardwarebeschreibung zu erleichtern. Iterations- und Schleifenstrukturknoten haben früher eine Iterationsanzahl bzw. eine Schleifenbedingung eingeschlossen. Gemäß der bevorzugten Ausführungsform weisen diese Strukturknoten weiterhin Perioden- und Phasenverzögerungsparameter auf, die in den Strukturknoten eingefügt oder diesem zugewiesen werden. Diese liefern Informationen über die Ausführungsperiode und die Phasenverzögerung des Strukturknotens. Wie nachstehend erörtert wird, werden der Perioden- und der Phasenverzögerungsparameter sowie die Iterationsanzahl oder die Schleifenbedingung verwendet, um das Exportieren des Strukturknotens in eine Hardwarebeschreibung zu erleichtern.
In Schritt 464 fügt das Verfahren die Strukturknotenparameter in die Hardwarebeschreibung ein. In Schritt 466 fügt das Verfahren einen Bezug auf einen vorübersetzten Funktionsblock ein, der dem Typ des Strukturknotens entspricht. Im Fall eines Schleifen-Strukturknotens fügt das Verfahren einen Bezug auf einen vorübersetzten Funktionsblock ein, der die von dem Strukturknoten angegebene Schleifenfunktion implementiert. Das Verfahren verbindet auch Steuerungen mit dem vom Strukturknoten eingeschlossenen Diagramm.
11 – Umwandeln eines Knotens in eine Hardwarebeschreibung
11 zeigt ein Flußdiagramm eines Abschnitts von Schritt 306 aus den 4 und 4A, worin ein Vorgang dargestellt ist, bei dem das Verfahren die Hardwarebeschreibung für einen Knoten in eine Netzliste umwandelt. 11 veranschaulicht einen Vorgang des Umwandelns einer Hardwarebeschreibung eines Knotens, wobei die Hardwarebeschreibung einen Bezug auf einen Funktionsblock enthält und Knotenparameter aufweisen kann. Es sei bemerkt, daß wenn die Hardwarebeschreibung eines Knotens eine Beschreibung der tatsächlichen Register, Gatter usw. enthält, welche die Funktionsweise des Knotens ausführen, die Umwandlung dieser Hardwarebeschreibung in eine Netzliste einfach unter Verwendung beliebiger von verschiedenen Typen von Synthesewerkzeugen ausgeführt wird.
Wie dargestellt ist, untersucht das Verfahren in Schritt 502 den Funktionsblockbezug und jegliche Knotenparameter, die in der Hardwarebeschreibung vorhanden sind. In Schritt 504 wählt das Verfahren den in Bezug genommenen vorübersetzten Funktionsblock aus der Bibliothek 308 aus, die im wesentlichen eine den Funktionsblock beschreibende Netzliste enthält. In Schritt 506 konfiguriert das Verfahren dann die Netzliste des vorübersetzten Funktionsblocks mit allen in Schritt 502 bestimmten Parametern. In Schritt 508 fügt das Verfahren dann den konfigurierten vorübersetzten Funktionsblock in die gerade zusammengestellte Netzliste ein.
12 – Umwandeln eines Strukturknotens in eine Hardwarebeschreibung
12 zeigt ein Flußdiagramm, in dem die Funktionsweise des Flußdiagramms aus 11 dargestellt ist, wobei das Verfahren die Hardwarebeschreibung für einen Strukturknoten in eine Netzliste umwandelt. 12 zeigt einen Vorgang des Umwandelns einer Hardwarebeschreibung eines Strukturknotens, wobei die Hardwarebeschreibung einen Bezug auf einen Funktionsblock des Strukturknotens aufweist und Strukturknotenparameter enthält.
Wie dargestellt ist, untersucht das Verfahren in Schritt 502A den Funktionsblockbezug und die Strukturknotenparameter, die in der Hardwarebeschreibung vorhanden sind. Die Strukturknotenparameter können Parameter, wie die Iterationsanzahl, die Schleifenbedingung, die Periode, die Phasenverzögerung usw., einschließen. In Schritt 504A wählt das Verfahren den in Bezug genommenen vorübersetzten Funktionsblock aus der Bibliothek 308 aus, wobei es sich im wesentlichen um eine Netzliste handelt, die den Funktionsblock des Strukturknotens beschreibt. In Schritt 506A konfiguriert das Verfahren dann die Netzliste des vorübersetzten Funktionsblocks mit den in Schritt 502A bestimmten Strukturknotenparametern. Dies umfaßt das Festlegen der Periode und der Phasenverzögerung der Ausführung des Strukturknotens sowie irgendwelche andere Parameter, wie die Iterationsanzahl, die Schleifenbedingung usw. In Schritt 508A fügt das Verfahren dann den konfigurierten vorübersetzten Funktionsblock in die gerade zusammengestellte Netzliste ein.
13 – Funktionsblock für einen Strukturknoten
13 zeigt ein Blockdiagramm, das einen While-Schleifen-Funktionsblock zeigt. Wie dargestellt ist, weist der While-Schleifen-Funktionsblock Freigabeperioden- und Phaseneingänge sowie einen Schleifensteuereingang auf. Der While-Schleifen-Funktionsblock liefert eine Indexausgabe, die einem Addierer zugeführt wird. Der Addierer wird jedesmal dann inkrementiert, wenn die zum Überwachen der Anzahl der Ausführungen der While-Schleife bereitgestellten Indexsignale auftreten. Die While-Schleife gibt weiterhin Lösch- und Ausgangsfreigabesignale aus, um das Programm innerhalb der While-Schleife zu steuern, und sie empfängt weiterhin eine Schleifenabschlußsignal-Eingabe, die verwendet wird, um anzugeben, ob die Schleife abgeschlossen wurde.
14 – Funktionsweise des Strukturknoten-Funktionsblocks
14 zeigt ein Zustandsdiagramm, in dem die Funktionsweise des in 13 dargestellten While-Schleifen-Funktionsblocks dargestellt ist. Wie ersichtlich ist, geht eine Diagrammstartoperation dem Zustand A vorher. Wenn Phase-Abgeschlossen wahr ist, was darauf hinweist, daß die Phase abgeschlossen wurde, setzt die Zustandsmaschine mit Zustand B fort. Die Zustandsmaschine bleibt in Zustand B, bis das Schleifenfreigabesignal wahr ist, wodurch angegeben wird, daß die Schleife zum Beginnen mit der Ausführung freigegeben wurde. Wenn das Schleifenfreigabesignal aktiviert wird, geht die Zustandsmaschine von Zustand B zu Zustand C. In Schritt C wird das Ausgangslöschsignal aktiviert, wodurch der Schleifenausgang gelöscht wird, bevor die Schleife ausgeführt wird.
Die Zustandsmaschine geht dann von Zustand C zu Zustand D. In Zustand D wird die Berechnung ausgeführt, und es wird das Ausgangsfreigabe-Setzsignal aktiviert. Falls die Periode abgeschlossen ist und die Schleife noch nicht beendet wurde, was durch die Gleichung:
Periode abgeschlossen und/Schleife abgeschlossen
angegeben wird, geht die Zustandsmaschine in einen Fehlerzustand über, und die Operation wird abgeschlossen. Demgemäß war die für die Ausführung der Schleife festgelegte Periode nicht lang genug, um den Abschluß der Schleife zu ermöglichen. Mit anderen Worten benötigte die Schleife zum Abschluß mehr Zeit als die zur Ausführung der Schleife festgelegte Periode.
Die Zustandsmaschine geht von Zustand D zu Zustand E, wenn das Schleifenabschlußsignal vor dem Aktivieren des Periodenabschlußsignals aktiviert wird, wodurch angegeben wird, daß die Schleife vor Ablauf der für die Schleifenausführung zugeordneten Periode abgeschlossen wurde.
Die Zustandsmaschine geht dann, wie dargestellt, von Zustand E in einen Wartezustand über. Falls die Periode abgeschlossen ist und die Schleife nicht erneut freigegeben wird, was durch die Bedingung:
Periode abgeschlossen und/Schleife aktiviert
angegeben wird, geht die Zustandsmaschine vom Wartezustand zum Abschlußzustand. Falls die Periode abgeschlossen wurde und die Schleife noch freigegeben ist, wodurch angegeben wird, daß eine weitere Ausführung der Schleife erforderlich ist, geht die Zustandsmaschine vom Wartezustand zum C-Zustand zurück. Demgemäß schreitet die Zustandsmaschine über die Zustände C, D, E und Warten fort, um Schleifenoperationen auszuführen.
Herunterladen einer Hardwareimplementierung in die programmierbare Logik
Es gibt verschiedene Möglichkeiten oder Verfahren zum Herunterladen einer Hardwareimplementation in die programmierbare Logik. In einem Fall lädt die Haupt-CPU lediglich die Konfiguration in die programmierbare Logik herunter, wie vorstehend beschrieben wurde. Dies könnte durch den Treiber zur Urladezeit geschehen oder dann geschehen, wenn der Benutzer die Ausführungstaste in dem erzeugten graphischen Programm drückt. Alternativ führt die Haupt-CPU die Hardwareimplementierung einem auf der Platine vorhandenen nichtflüchtigen Speicher zu und wird diese Hardwareimplementation während des Urladens der Platine aus dem nichtflüchtigen Speicher auf der Platine in die programmierbare Logik geladen.
Demgemäß kann die umkonfigurierbare Platine so ausgelegt werden, daß das Hardwarediagramm in den nichtflüchtigen Speicher statt direkt in das FPGA geschrieben wird. Dies ermöglicht es, daß eine Hardwareimplementation eines Diagramms die Ausführung beim Einschalten der Leistung beginnt (lange bevor das Urladen des Betriebssystems beendet wurde). In diesem Fall weist das Diagramm vorzugsweise Eingangsfreigabe- und Abbrechsignale der höchsten Ebene auf, die während der Übersetzungszeit so konfiguriert werden können, daß entweder die sofortige Ausführung ermöglicht wird oder daß ein Überwachungsprogramm zum Ermöglichen der Hardwareausführung erforderlich ist.
Standardkonfiguration für die Hardwaresimulation
Wie vorstehend erörtert wurde, weist das System gemäß der bevorzugten Ausführungsform ein Computersystem auf, das eine Zusatzkarte enthält. Die Zusatzkarte führt vorzugsweise eine Datenerfassungs-/Erzeugungsfunktion aus, und sie ist beispielsweise eine Datenerfassungskarte. Die DAQ-Karte weist D/A- und A/D-Wandler sowie verschiedene andere Datenerfassungslogiken auf, und sie weist eine programmierbare Logikvorrichtung, wie bspw. ein FPGA, auf, die eine ansprechend auf ein auf dem Computersystem erzeugtes graphisches Programm erzeugte Hardwareimplementation empfangen kann.
Bei einer Ausführungsform empfängt die programmierbare Logik oder FPGA eine Standardkonfiguration, wobei die Standardkonfiguration die Datenerfassungsplatine mit einer Standardschnittstelle zur Ausführung des graphischen Programms in Software konfiguriert. Demgemäß kann die Haupt-CPU beispielsweise eine Hardwareimplementation in die FPGA herunterladen, wodurch die FPGA mit einer Standardkonfiguration einer Platine programmiert wird, um eine gewünschte Schnittstelle für die Platine bereitzustellen.
Diese Konfiguration bietet dem Hauptcomputer einen direkten Zugriff auf die Ein-/Ausgabe der Platine. Dies ist beispielsweise bei der Hardwaresimulation nützlich, um es der Haupt-CPU zu ermöglichen, das graphische Programm oder Diagramm während der Algorithmusentwicklung in Software auszuführen, um die Machbarkeit zu bestimmen und eine Fehlersuche und dergleichen auszuführen. Das graphische Programm verhält sich ebenso wie dies normalerweise in Hardware der Fall wäre, abgesehen davon, daß das Programm durch die Softwareausführung langsamer läuft. Es sind jedoch im graphischen Programmiersystem Software-Fehlersuchwerkzeuge verfügbar, um die Fehlersuche in dem Programm zu erleichtern. Diese Implementation bietet auch eine kürzere Übersetzungszeit, wodurch eine schnellere Ausführungsform für Benutzerfehlerreparaturen ermöglicht wird. Es wird demgemäß erwartet, daß der Benutzer eine Standardkonfiguration für die programmierbare Logik herunterlädt und das in Software erzeugte graphische Programm ein oder mehrere Male ausführt, um die Fehlersuche zu erleichtern. Sobald das graphische Programm mit einer zufriedenstellenden Funktionsweise konstruiert worden ist, kann der Benutzer die eigentliche Hardwareimplementation des graphischen Programms in die programmierbare Logik herunterladen, wie vorstehend beschrieben wurde.
Wie vorstehend erörtert wurde, gibt es verschiedene Möglichkeiten oder Verfahren für das Herunterladen einer Standardkonfiguration in die programmierbare Logik. In einem Fall lädt die Haupt-CPU lediglich die Konfiguration in die programmierbare Logik herunter, wie vorstehend beschrieben wurde. Dies könnte durch den Treiber zu der Urladezeit geschehen oder dann geschehen, wenn der Benutzer die Ausführungstaste an dem erzeugten graphischen Programm drückt. Alternativ liefert die Haupt-CPU die Standardkonfiguration einem auf der Platine vorhandenen nichtflüchtigen Speicher, und diese Standardkonfiguration wird während des Urladens der Platine vom nichtflüchtigen Speicher auf der Platine in die programmierbare Logik geladen.
Abschätzung der Größe und der Kosten einer Hardwareimplementierung
Bei einer Ausführungsform weist das graphische Programm eine Datenstruktur auf, die eine Liste aller in der Komponentenbibliothek enthaltenen Elemente oder Komponenten sowie die Kosten jeder Komponente in bezug auf die Gatter und die Ausführungszeit aufweist. Wenn daher gemäß dieser Ausführungsform ein graphisches Programm erzeugt wird, referenziert das graphische Programmiersystem die Datenstruktur, um die zugeordneten Gatter- und Zeitkosten zu erhalten, die jeder Komponente zugeordnet sind, die von der Komponentenbibliothek in dem erzeugten graphischen Programm verwendet wird. Beispielsweise gibt das graphische Programmiersystem die Gesamtzahl der in bezug auf jede in dem erzeugten graphischen Programm verwendete Komponente an und stellt dann fest, ob die programmierbare Logik oder FPGA, die verwendet wird, eine ausreichende Kapazität zum Implementieren dieses graphischen Programms aufweist. Weiterhin kann das graphische Programmiersystem diese Datenstruktur verwenden, um während oder vor der Übersetzungszeit zu bestimmen, wie schnell das graphische Programm in der Hardware ausgeführt wird, also wie schnell die Hardwareimplementation in der FPGA ausgeführt werden wird.
Alternativ empfängt das graphische Programmiersystem eine Benutzereingabe in bezug auf die gewünschte Ausführungszeit und verwendet die Ausführungszeiten von jedem der Elemente, um dem Benutzer eine Rückmeldung dazu zu geben, ob das graphische Programm die Benutzeranforderungen in bezug auf die Ausführungszeit erfüllt.
Zusätzlich weist die Komponentenbibliothek gemäß einer Ausführungsform mehrere Versionen jeweiliger Komponenten auf. Beispielsweise weist die Komponentenbibliothek einen schnellen Multiplizierer, der groß ist, und einen kleinen Multiplizierer, der langsam ist, auf. Das graphische Programmiersystem kann so konfiguriert werden, daß es die geeignete Komponentenversion auf der Grundlage davon auswählt, in welchem Maße die FPGA von dem restlichen Diagramm belegt wird, und daß es die geeignete Komponentenversion auf der Grundlage der im Diagramm angegebenen Schleifenzeiten oder einer anderen Eingabe vom Benutzer und/oder Informationen im Diagramm auswählt. Der Benutzer gibt daher bei einer Ausführungsform sowohl die Anzahl der in der verwendeten programmierbaren Logik enthaltenen Gatter als auch die gewünschte Ausführungszeit an, und das graphische Programmiersystem wählt automatisch zwischen verschiedenen Komponentenversionen in der Komponentenbibliothek, beispielsweise zwischen einem langsameren und weniger komplexen Addierer und einem schnelleren, jedoch komplexeren Addierer, aus, um eine Hardwareimplementierung zu entwickeln, die für die Anwendung des Benutzers geeignet ist.
Manipulation nicht wiederverwendbarer Hardwarebetriebsmittel
Wenn ein Benutzer ein graphisches Programm erzeugt, das ein oder mehrere Hardwarebetriebsmittel manipuliert, wobei es sich beispielsweise um ein oder mehrere Hardwarebetriebsmittel handelt, die auf einer Zusatzkarte, beispielsweise einer Datenerfassungskarte, vorhanden sind, weist die Hardwarevorrichtung oder die Platine im allgemeinen eine begrenzte Anzahl von Hardwareelementen auf, die von dem graphischen Programm verwendbar sind. Beispielsweise kann eine gegebene Datenerfassungsplatine nur einen analogen Eingangskanal aufweisen. Zumindest ein Teilsatz dieser Hardwareelemente kann nur einmal verwendet werden, so daß sie nicht wiederverwendbar sind.
Bei einer Ausführungsform der Erfindung erscheinen die in der gesteuerten Hardware vorhandenen nicht wiederverwendbaren Komponenten während der Konfiguration oder Konstruktion des graphischen Programms auf einer Palette. Diese nicht wiederverwendbaren Komponenten verschwinden, wenn sie vom Programm verwendet werden, um dem Benutzer anzugeben, daß diese Komponenten verwendet wurden und demgemäß nicht wiederverwendet werden können. Bei einer Ausführungsform zieht der Benutzer diese nicht wiederverwendbaren Komponenten einfach von der Palette in das graphische Programm. Sobald diese Komponenten von der Palette in das graphische Programm gezogen worden sind, verschwindet die Komponente von der Palette und der Benutzer weiß demgemäß, daß die Komponente in dem graphischen Programm verwendet worden ist und daher nicht zur Wiederverwendung verfügbar ist.
Wenn zwei oder mehr verwendbare Hardwareelemente auf der Platine vorhanden sind, erscheinen in der Palette zwei oder mehr Komponenten. Weil in diesem Fall jede Komponente in dem graphischen Programm verwendet wird, verschwindet das entsprechende Bild in der Palette, um dem Benutzer die Anzahl der verbleibenden Hardwarekomponenten mitzuteilen, die verwendet werden können. Hierdurch wird ein zweckmäßiger Mechanismus bereitgestellt, um dem Benutzer Informationen in bezug auf die verwendeten Hardwarekomponenten bereitzustellen, und es wird dadurch die Wiederverwendung nicht wiederverwendbarer Komponenten verhindert.
Es ist bei manchen graphischen Programmen häufig zweckmäßig, daß ein einziges graphisches Programm auf ein einziges Hardwareelement von mehreren Stellen in dem graphischen Programm oder Diagramm zugreift. Hierdurch wird technisch das vorstehend erörterte Konzept einer einzigen Ausprägung oder einer nicht Wiederverwendbarkeit verletzt, wonach eine nicht wiederverwendbare Komponente nur einmal in einem graphischen Programm verwendet werden kann. Wenn der Benutzer jedoch den Zugriff auf ein einziges nicht wiederverwendbares Hardwareelement an mehreren Stellen in einem einzigen graphischen Programm wünscht, konstruiert der Benutzer vorzugsweise eine Ablaufsteuerung oder implementiert eine Ablaufsteuerung in dem graphischen Programm, wodurch verhindert wird, daß dieses Hardwareelement innerhalb desselben graphischen Programms gleichzeitig verwendet wird. Beim LabVIEW-Programm konstruiert der Benutzer die Ablaufsteuerung beispielsweise unter Verwendung einer Sequenzstruktur. Bei einer Ausführungsform bilden Bezüge auf Hardwareelemente in dem graphischen Programm eine "Handle" für die Hardware, die dem graphischen Programm zugeführt wird und die darin an mehreren Stellen verwendet werden kann. Dieser Bezug oder diese "Handle" für die Hardware kann dann verwendet werden, um gleichzeitige Zugriffe auf eine einzige Vorrichtung in dem graphischen Programm bereitzustellen.
Es gibt im allgemeinen drei verschiedene Arten, in denen ein graphisches Programm oder Diagramm aufgebaut werden kann, um auf eindeutige Hardwarebetriebsmittel zuzugreifen. In einem ersten Fall (a) erscheint ein einziger Bezug auf die Hardware in dem Diagramm, wie vorstehend erörtert wurde. In einem zweiten Fall (b) erscheinen mehrere Bezüge auf die Hardware in dem graphischen Programm, es treten jedoch keine zwei dieser Bezüge gleichzeitig auf. Beispielsweise kann der Benutzer diese mehreren Bezüge in verschiedenen Rahmen einer Sequenzstruktur einrichten. In einem dritten Fall (c) weist das graphische Programm mehrere Bezüge auf die Hardware auf, und die Art, in der das graphische Programm aufgebaut wird, gibt an, daß diese mehreren Bezüge gleichzeitig ausgeführt werden können.
Bei der bevorzugten Ausführungsform erkennt das graphische Programmiersystem vorzugsweise, welcher der erwähnten Fälle auftritt und führt jeden erforderlichen Konfigurationstyp aus, um diesen Situationen Rechnung zu tragen. In dem ersten Fall (a) erscheint eine einzige Referenz auf die Hardware in dem graphischen Programm, so daß das graphische Programmiersystem beim Erzeugen der Hardwareimplementation keine spezielle Verarbeitung ausführen muß. In dem vorstehend erwähnten zweiten Fall (b) verwendet das graphische Programm, wenn die Sequenzstruktur in eine Hardwareimplementation umgewandelt wird, Multiplexer zum Multiplexieren der Steuer- und Dateneingaben in die fragliche Hardware mit denselben Signalen, um zu garantieren, daß gleichzeitige Zugriffe unmöglich sind, wie durch die Sequenzstruktur angegeben wird. In dem vorstehenden Fall (c) erkennt das graphische Programmiersystem vorzugsweise automatisch einen Fall, in dem mehrere Bezüge in der Hardware auftreten, in der sie gleichzeitig ausgeführt werden können, und er konfiguriert die Hardwareimplementation so, daß diese Mehrfachzugriffe verhindert werden und verhindert dadurch einen möglichen fehlerhaften Betrieb. In diesem Fall erkennt das graphische Programmiersystem während des Umwandlungsprozesses in die Hardwareimplementierung die mehreren Bezüge auf die Hardware, die gleichzeitig ausgeführt werden können und instantiiert einen oder mehrere Multiplexer und eine vollständige Entscheidungsschaltung zum Steuern der Multiplexer. Die Multiplexer sind in der Hardwareimplementierung bereitgestellt, um die Möglichkeit einer gleichzeitigen Ausführung dieser mehreren Bezüge auf die nicht wiederverwendbare Hardware auszuschließen.
In den Fällen (b) und (c) verwenden die Hardwareimplementierungen ähnliche Multiplexer. Der Unterschied zwischen den Fällen (b) und (c) besteht darin, daß im Fall (c) die Hardwareimplementation eine Steuerschaltung aufweist. Im Fall (b) sind die Steuersignale die gleichen Steuersignale, die steuern, welcher Rahmen der Sequenz ausgeführt wird, und in (c) kommen die Steuersignale von einer Entscheidungsschaltung. Weiterhin werden in Punkt (b) die Multiplexer, die die Sequenzstruktur konfigurieren und implementieren, zur Übersetzungszeit festgelegt oder definiert. Alternativ wird im Fall (c) die Entscheidungsschaltung zur Übersetzungszeit nicht notwendigerweise bis zur Reihenfolgebildung definiert, sondern die Ausführungsreihenfolge wird tatsächlich zur Ausführungszeit definiert.
Sondeneinführung
Gemäß einer Ausführungsform kann ein Benutzer während der Erzeugung des graphischen Programms eine oder mehrere Sonden in das graphische Programm einfügen, die Daten an dem jeweiligen Draht anzeigen, an dem sich die Sonde während der Ausführung des graphischen Programms befindet. Wenn der Benutzer eine Sonde an einer oder mehreren Stellen in dem graphischen Programm einfügt, weist die entsprechende Hardwareimplementierung die Verwendung einer Zeitmarken-Erzeugungsschaltung an. Die Zeitmarken-Erzeugungsschaltung kann innerhalb der programmierbaren Logik oder FPGA enthalten sein, oder die Zeitmarken-Erzeugungsschaltung ist in einem getrennten Chip oder Logikblock konfiguriert, der auf der Platine vorhanden ist, die mit der FPGA gekoppelt ist. Diese Zeitmarken-Erzeugungsschaltung ermöglicht es dem graphischen Programmiersystem, Sonden in die Hardwareimplementation des graphischen Programms oder Diagramms einzufügen. Die Zeitmarken-Erzeugungsschaltung weist demgemäß eine Hardwareimplementierung der Sonde auf, die in das graphische Softwareprogramm eingefügt wurde. Hierdurch wird ermöglicht, daß die Hardware-Fehlersuchumgebung ebenso aussieht und verwendbar ist wie in dem graphischen Programmiersystem.
Datenwegoptimierung
Bei einer Ausführungsform ist das graphische Programmiersystem in der Lage, graphische Programme oder Diagramme zu erkennen, die dem Hauptcomputer Daten zuführen oder die Daten von dem Hauptcomputer zuführen, und das graphische Programmiersystem fügt spezielle Schaltungen in die Hardwareimplementation ein, um DMA für schnelle Übertragungen zu handhaben, ohne daß spezielle Überlegungen vom Benutzer erforderlich sind. Diese Schaltungen enthalten FIFOs und Schaltungen zum Erzeugen von DMA-Anforderungen (DRQ) oder Entsprechungen.
Dieses Verfahren ermöglicht es, daß das graphische Programmiersystem automatisch eine DMA-Schaltung für das graphische Programm oder Diagramm, das vom Benutzer erzeugt wurde, hervorbringt. Im üblichen Fall läuft die gesamte Kommunikation von der CPU zum graphischen Programm oder Diagramm durch globale Variablen ab. Gemäß dieser Ausführungsform weist das Diagramm ein Bildzeichen auf, das in dem Sinne ähnlich einer "globalen Schreibanweisung" aussieht, daß es sich dabei um eine Datensenke handelt, und wenn das Bildzeichen ausgeführt wird, aktiviert das Bildzeichen eine DMA-Anforderung (DRQ), die zur DMA-Steuerung zurückläuft und eine DMA-Übertragung auslöst. Die FIFO- und DRQ-Erzeugungsschaltungsanordnungen werden innerhalb der FPGA aufgebaut, wenn das DMA-Bildzeichen verwendet wird.
Ereignisse
Das graphische Programmiersystem LabVIEW weist eine Ereignisfähigkeit auf, die es einer ersten Funktion ermöglicht "schlafen zu gehen", während darauf gewartet wird, daß eine zweite Funktion ein Ergebnis erzeugt. Auf diese Weise verbraucht die erste Funktion keine CPU-Zeit, während auf die zweite Funktion gewartet wird. Es sind drei Bildzeichen mit einer zugeordneten Steuersoftware bereitgestellt, die die Ereignisfunktion implementiert. Ein Warten-auf-Ereignis-Funktionsbildzeichen wird der ersten Funktion zugeordnet, die auf das Ergebnis der zweiten Funktion wartet. Ein Festlegen-von-Ereignis-Funktionsbildzeichen wird typischerweise dem zweiten Funktionsbildzeichen zugeordnet, und es löst ein Ereignis aus, wenn die zweite Funktion das gewünschte Ereignis erzeugt. Ein Erzeugen-von-Ereignis-Funktionsbildzeichen wird verwendet, um Bezeichnerwerte zu übergeben, die mehrere Quellen und Ziele mit Festlegen-von-Ereignis-Funktionsbildzeichen bzw. Warten-auf-Ereignis-Funktionsbildzeichen verknüpfen.
Ereignisse weisen in der Hinsicht einige der Eigenschaften globaler Variablen auf, daß ihre Implementation in hohem Maße davon abhängt, ob sie innerhalb einer einzigen Umgebung "geschrieben" und "gelesen" werden (vollständig in Software, vollständig in Hardware oder unter Kreuzen der Grenze zwischen Software und Hardware). Ein Ereignis, das innerhalb der Hardware festgelegt und erkannt wird, betrifft Festlege- und Erkennungs-Ereigniskomponenten aus der Bibliothek. Ein Ereignis, das in der Hardware festgelegt ist und von der Haupt-CPU erkannt wird, kann automatisch einer Unterbrechung zugeordnet werden. Das graphische Programmiersystem, beispielsweise LabVIEW, würde dann den Unterbrechungsbehandlungscode erzeugen, der auf dem Hauptcomputer auszuführen ist.
Automatische Erzeugung der Programmierschnittstelle
Bei einer Ausführungsform kann die von dem graphischen Programmiersystem erzeugte Hardwareimplementation konfiguriert werden, um von anderen Softwareumgebungen oder anderen Protokollen, beispielsweise C, C++, Java, Visual Basic, Visual C++, LabWindows CVI, anderen Typen graphischer Programmiersysteme usw. gesteuert zu werden. Bei dieser Ausführungsform kann das graphische Programmiersystem automatisch eine Beschreibung der erforderlichen Hardware erzeugen, die eine Registerzuordnung, eine Unterbrechungszuordnung, DMA-Fähigkeiten usw. einschließt, um es anderen Softwareumgebungen zu ermöglichen, die Hardwareimplementation zu steuern. Beispielsweise wird bei der bevorzugten Ausführungsform, bei der das graphische Programmiersystem LabVIEW von National Instruments Corporation verwendet wird, das in LabVIEW erzeugte graphische Programm in eine Hardwareimplementation umgewandelt, wobei die Hardwareimplementation auch die vorstehenden Hardwareinformationen einschließt, die erforderlich sind, um es einer anderen Softwareentwicklungsumgebung zu ermöglichen, die Hardwareimplementation zu steuern oder auszuführen.
Kompensieren für schlechte Anordnungs- und Wegleitergebnisse
Wie vorstehend erörtert wurde, verwenden die Ausführungsformen vorzugsweise ein Werkzeug einer dritten Partei, das die von dem graphischen Programm erzeugte Netzliste in eine Hardwareimplementation oder FPGA-Konfiguration umwandelt. Falls bei einer Ausführungsform dieses Werkzeug einer dritten Partei berichtet, daß die maximale Taktgeschwindigkeit geringer als von dem graphischen Programmiersystem erwartet ist, kann das graphische Programmiersystem die Taktgeschwindigkeit wahlweise verringern und einen oder mehrere Zählerwerte und Zeitgeber einstellen, um eine Kompensation für diese neue Taktgeschwindigkeit vorzunehmen. Dies wird vorzugsweise in Fällen ausgeführt, in denen Gesamt-Funktionsweiseziele noch erfüllt sind.
Dies kann beispielsweise in Fällen erforderlich sein, in denen der Benutzer den Zeitablauf innerhalb der graphischen Programmierung unter der Annahme einer bestimmten Taktgeschwindigkeit konfiguriert hat, wobei er beispielsweise eine Zeitsteuerungsschleife einsetzt, bei der ein 20-MHz-Takt angenommen wird, und wobei die Schleife auf der Grundlage dieses 20-MHz-Takts eingerichtet ist, wobei ein Schleifendurchlauf in zwei Millisekunden erfolgt. In Fällen, in denen die Taktgeschwindigkeit geringer als erwartet ist, kann die Hardwareimplementation infolge dieser verschiedenen Taktgeschwindigkeit tatsächlich anders arbeiten als von dem Benutzer erwartet. In diesem Fall kann das graphische Programmiersystem die Taktgeschwindigkeit automatisch verringern und die Zählerwerte und die jeweiligen Zeitgeber einstellen, um diese neue Takageschwindigkeit zu kompensieren und dem Benutzer dadurch die Leistungsfähigkeit bereitzustellen, die er erwartet hat, als er das graphische Programm erzeugt hat. Diese Ausführungsform verwendet einen konfigurierbaren Oszillator auf der Datenerfassungsplatine.
15 – einfaches graphisches Programmbeispiel
15 zeigt ein einfaches Beispiel eines graphischen Programms. In 15 weist das graphische Programm drei Eingabeterminals und ein Ausgabeterminal auf. Das graphische Programm enthält einfach einen ersten Addier-Funktionsknoten mit 2 Eingängen, der eine Eingabe von zwei Eingabeterminals empfängt, und einen zweiten Addier-Funktionsknoten mit 2 Eingängen, der die Ausgabe vom ersten Addier-Funktionsknoten empfängt und eine Ausgabe vom dritten Eingabeterminal empfängt. Der zweite Addier-Funktionsknoten mit 2 Eingängen führt dem Ausgabeterminal wie dargestellt eine Ausgabe zu.
16 – Hardwareergebnis
16 zeigt ein Konzeptdiagramm der Hardware, die sich ergibt, nachdem das graphische Programmbeispiel aus 15 in eine Hardwarebeschreibung umgewandelt wurde. Wie dargestellt ist, enthält das Hardwarediagramm drei Schreibregister 522–526, die jeweils den drei Eingabeterminals entsprechen. Die Datenausgaben der ersten zwei Schreibregister 522 und 524 werden einem ersten Addierer 532 mit zwei Eingängen als Eingaben zugeführt, wobei der Addierer 532 dem ersten Addierer im Blockdiagramm aus 15 entspricht. Die Hardwarebeschreibung beinhaltet auch das Erzeugen eines UND-Gatters 534, das Steuerausgaben von jedem von den ersten zwei Schreibregistern 522 und 524 empfängt und dem Steuereingang des Addierers 532 eine einzige Ausgabe zuführt. Der Zweck des UND-Gatters 534 besteht darin, den Addierer 542 am Ausführen zu hindern, bis beide Eingaben empfangen worden sind.
Der Addierer 532 führt einem zweiten Addierer 542 mit zwei Eingängen eine Datenausgabe zu, wobei der Addierer 542 dem zweiten Addierer im Blockdiagramm aus 15 entspricht. Der erste Addierer 532 erzeugt auch ein Ausgangsfreigabesignal, das einem Eingang eines zweiten UND-Gatters 536 zugeführt wird. Der andere Eingang des UND-Gatters 536 empfängt eine Ausgabe von dem dritten Schreibregister 526, das dem dritten Eingabeterminal entspricht. Das UND-Gatter 536 führt einem Steuereingang des zweiten Addierers 542 eine Ausgabe zu. Demgemäß gewährleistet das UND-Gatter 536, daß der zweite Addierer 542 nicht ausführt, bevor alle Eingaben von dem Addierer 542 empfangen worden sind. Der zweite Addierer 542 führt einem dem Ausgabeterminal zugeordneten Leseregister 546 eine Datenausgabe zu. Der zweite Addierer 542 führt dem Leseregister 546 auch ein Ausgangsfreigabesignal zu, das dem Leseregister 546 mitteilt, wenn gültige Daten bereitgestellt worden sind.
Demgemäß wird, wie dargestellt, zum Erzeugen einer Hardwarebeschreibung für jedes der Eingabeterminals das Flußdiagramm aus 6 ausgeführt, das eine Hardwarebeschreibung der Schreibregister 522, 524 und 526 erzeugt, die jeweils Daten- und Steuerausgänge aufweisen. Für jeden Addierer-Funktionsknoten wird das Flußdiagramm aus 7 ausgeführt, wobei eine Hardwarebeschreibung eines Addierers 532 oder 542 erzeugt wird und weiterhin ein zugeordnetes UND-Gatter 534 oder 536 mit N Eingängen erzeugt wird, dessen Eingänge mit den abhängigen Eingängen des Addierer-Funktionsknotens verbunden sind, um die Ausführung zur richtigen Zeit zu gewährleisten. Schließlich wird das Flußdiagramm aus 8 für das Ausgabeterminal des graphischen Programms ausgeführt, das eine Hardwarebeschreibung eines Leseregisters mit Daten- und Steuereingängen erzeugt.
17–19: Beispiel der Umwandlung eines graphischen Programms in eine Hardwareimplementierung
17–19 betreffen ein detaillierteres Beispiel zur Erläuterung der Funktionsweise der bevorzugten Ausführungsformen.
17 zeigt ein als Beispiel dienendes graphisches Programm (ein LabVIEW-Diagramm), das unter Verwendung der vorliegenden Erfindung in eine FPGA-Implementation umgewandelt wird. Wie dargestellt ist, weist das graphische Programm mehrere in einer While-Schleife enthaltene verbundene Knoten auf. Wie dargestellt ist, weist die While-Schleife Schieberegister-Bildzeichen auf, die durch die abwärts und aufwärts gerichteten Pfeile am linken bzw. am rechten Rand der While-Schleife dargestellt sind. Eine 0-Konstante, die sich außerhalb der While-Schleife befindet, ist mit dem abwärts gerichteten Pfeil des Schieberegisters an dem linken Rand der While-Schleife verbunden.
Die While-Schleife weist ein Zeitgeber-Bildzeichen auf, das die Zeitsteuerung für die While-Schleife darstellt oder bedeutet. Das Zeitgeber-Bildzeichen weist Eingänge für die Periode und die Phase auf. Wie dargestellt ist, empfängt das Zeitgeber-Bildzeichen eine Konstante 1000 für die Periode und eine Konstante 0 für die Phase. Bei einer alternativen Ausführungsform weist die While-Schleife Eingabeterminals auf, die zum Empfangen von Zeitinformationen, wie Periode und Phase, konfiguriert sind.
18 zeigt die ansprechend auf das Diagramm oder graphische Programm aus 17 erzeugten oder diese darstellenden LabVIEW-Datenstrukturen. Das Datenstrukturdiagramm aus 17 enthält eine Hierarchie von Datenstrukturen entsprechend dem Diagramm aus 17. Wie dargestellt, weist die LabVIEW-Datenstrukturdarstellung ein Diagramm höchster Ebene auf, das ein einziges Signal enthält, das die 0-Konstante mit dem linken Schieberegister der While-Schleife verbindet. Demgemäß enthält das Diagramm höchster Ebene nur die Konstante (0) und die While-Schleife.
Die While-Schleife weist ein Unterdiagramm auf, das weiterhin linke und rechte Schieberegisterterme, das Continue-Hinweiszeichen der While-Schleife, eine Anzahl von Konstanten, einen Zeitgeber mit einem Perioden- und einem Phaseneingang, Setzpunkte und Verstärkungen globaler Variablen, Unter-VI-A/D-Lese- und D/A-Schreib-Signale und verschiedene Funktionsbildzeichen, beispielsweise Skalieren, Addieren, Subtrahieren und Multiplizieren, enthält. Weiterhin weist jedes der Objekte in dem Diagramm Terminals auf, und Signale verbinden zwischen diesen Terminals.
19 zeigt einen Schaltplan, der die ansprechend auf die Datenstrukturen aus 18 erzeugte Hardwarebeschreibung darstellt. Der Schaltplan aus 19 implementiert das graphische Programm aus 17. Wie dargestellt ist, sind die CPU-Schnittstellensignale über Busse mit den globalen Variablen verknüpft. Wenngleich dies in 19 nicht dargestellt ist, werden die CPU-Schnittstellensignale auch den Unter-VIs-A/D-Lese- und D/A-Schreibeinheiten zugeführt.
Die While-Schleife ist im wesentlichen zu einer Steuerschaltung abstrahiert, die die Periode und die Phase empfängt, und sie weist eine externe Freigabe auf, welche die Ausführung des Diagramms höchster Ebene vorschreibt, wodurch die Schleife eingeleitet wird. Die Schleife liefert dann ein Diagrammfreigabesignal (diag_enab), um die Schleife einzuleiten und wartet auf ein Diagramm-Abgeschlossen-Signal (diag_done), wodurch der Abschluß der Schleife oder das Verstreichen der Periode angegeben wird. Auf der Grundlage des Werts des Continue-Hinweiszeichens liefert die Schleife ein nachfolgendes diag_enab-Signal oder stellt fest, daß die Schleife beendet wurde und liefert dem Diagramm höchster Ebene ein Abschlußsignal. Wenngleich dies in 19 nicht dargestellt ist, liefert der Schleifensteuerblock auch ein Diagrammlöschfreigabe-Ausgangssignal (diag_clear_enab_out) für jeden Knoten in dem Unterdiagramm der While-Schleife. Demgemäß gibt der Schleifensteuerblock ein Diagrammfreigabesignal (diag_enab) aus, das allen Anfangsknoten in dem Diagramm zugeführt wird, die sich innerhalb der While-Schleife befinden. Die Abschlußsignale (Done-Signale) von diesen Bildzeichen werden einem UND-Gatter zugeführt, dessen Ausgabe bereitgestellt wird, um nachfolgende Knoten freizugeben.
Das Schieberegister weist einen Dateneingang, einen Datenausgang und einen Freigabeeingang, der die Daten getaktet in den Datenausgang (dout) eingibt (din), und einen Ladeeingang, der den Anfangswert getaktet in das Schieberegister eingibt, auf.
Nachstehend wird eine VHDL-Beschreibung gegeben, die dem Beispiel aus den 17–19 entspricht, wobei die VHDL-Beschreibung unter Verwendung der bevorzugten Ausführungsform erzeugt wurde:
Komponentenbibliothek
Die bevorzugte Ausführungsform weist eine Komponentenbibliothek auf, die verwendet wird, um beim Umwandeln verschiedener Grundelemente oder Knoten in einem graphischen Programm in eine Hardwarebeschreibung zu helfen, wobei es sich beispielsweise um eine VHDL-Quellendatei handelt. Nachfolgend werden zwei Beispiele von VHDL-Komponenten in dieser Komponentenbibliothek gegeben, wobei es sich um Komponenten für eine While-Schleife und ein Multiplizierer-Grundelement handelt.
1. While-Schleifenkomponente
Nachstehend wird eine als whileloop.vhd bezeichnete VHDL-Komponente vorgestellt, die die bevorzugte Ausführungsform verwendet, wenn eine While-Schleife in einem graphischen Programm oder Diagramm auftritt. whileloop.vhd zeigt, wie eine While-Schleife in einem graphischen Programm auf eine Zustandsmaschine in der Hardware abgebildet wird. Es sei bemerkt, daß andere Steuerstrukturen, wie eine "For-Schleife", ähnlich sind. whileloop.vhd sieht folgendermaßen aus:
2. Multiplizierer-Grundelementkomponente
Nachstehend wird eine als prim multiply 16.vhd bezeichnete VHDL-Komponente vorgestellt, die die bevorzugte Ausführungsform verwendet, wenn ein Multiplizierer-Grundelement in einem graphischen Programm oder Diagramm auftritt. Wenn dem Weg von enable_in bis zu enable_out gefolgt wird, ist ersichtlich, wie die zeitlich selbst abgestimmte Logik funktioniert, wobei jede Komponente enable_out aktiviert, wenn die Datenausgabe gültig ist.
Andere Grundelemente, wie "Addieren" oder "kleiner als" funktionieren in ähnlicher Weise. prim multiply 16.vhd funktioniert folgendermaßen:
20–21
Die 20 und 21 veranschaulichen den graphischen Quellenknoten eines graphischen Programms oder eines vom VI aufgerufenen examplel.vi.
Nachstehend wird eine von dem in den 20 und 21 dargestellten graphischen Programm examplel.vi erzeugte VHDL-Hardwarebeschreibung gegeben, wobei die nachstehend dargelegte VHDL-Hardwarebeschreibung direkt anhand des LabVIEW-Programms examplel.vi unter Verwendung der bevor zugten Ausführungsform erzeugt wurde.
Wenngleich das System und das Verfahren gemäß der vorliegenden Erfindung in Zusammenhang mit der bevorzugten Ausführungsform beschrieben wurden, soll die vorliegende Erfindung nicht auf die hier dargelegte spezifische Form beschränkt sein, sondern vielmehr solche Alternativen, Modifikationen und gleichwertige Ausgestaltungen einschließen, die vernünftigerweise in den durch die anliegenden Ansprüche definierten Schutzumfang der Erfindung aufgenommen werden können.

Claims

Computerimplementiertes Verfahren zum Konfigurieren eines Instruments, um eine Meßfunktion durchzuführen, wobei das Instrument ein programmierbares Hardwareelement aufweist und das Verfahren folgende Schritte umfaßt: Erzeugen eines grafischen Programms, wobei das grafische Programm die Meßfunktion implementiert, wobei das grafische Programm einen Frontplattenabschnitt und einen Blockdiagrammabschnitt aufweist, und wobei der Frontplattenabschnitt als eine Frontplatte für das Instrument funktioniert, Erzeugen einer Hardwarebeschreibung basierend auf dem Blockdiagrammabschnitt des grafischen Programms, wobei die Hardwarebeschreibung eine Hardwareimplementierung des Blockdiagrammabschnitts des grafischen Programms beschreibt, Konfigurieren des programmierbaren Hardwareelements in dem Instrument unter Verwendung der Hardwarebeschreibung, um ein konfiguriertes Hardwareelement zu erzeugen, wobei das konfigurierte Hardwareelement eine Hardwareimplementierung des Blockdiagrammabschnitts des grafischen Programms implementiert, Übersetzen bzw. Compilieren des Frontplattenabschnitts in ausführbaren Code zum Ausführen durch eine Prozessor und Speichern des ausführbaren Codes in einem Speicher, Annehmen eines Signals durch das Instrument von einer externen Quelle nach dem Konfigurieren, Ausführen durch das programmierbare Hardwareelement in dem Instrument, um die Meßfunktion an dem Signal durchzuführen, und Ausführen durch den Prozessor des ausführbaren Codes aus dem Speicher, um den Frontplattenabschnitt auf einer Anzeige darzustellen, während das programmierbare Hardwareelement in dem Instrument ausführt, um die Meßfunktion an dem Signal durchzuführen.
Verfahren nach Anspruch 1, das weiterhin folgenden Schritt umfaßt: Ausführen einer Analog/Digital-Umwandlung des Signals nach der Annahme und vor der Ausführung.
Verfahren nach Anspruch 1, das weiterhin folgenden Schritt umfaßt: Empfangen einer Nutzereingabe zu dem Frontplattenabschnitt auf der Anzeige, um das Instrument zu kontrollieren, während das programmierbare Hardwareelement in dem Instrument ausführt, um die Meßfunktion an dem Signal durchzuführen.
Verfahren nach Anspruch 3, bei dem der Frontplattenabschnitt ein oder mehrere Nutzerschnittstellenobjekte enthält, wobei das Erzeugen den Schritt des Integrieren eines Registers in der Hardwarebeschreibung für zumindest eines der Nutzerschnittstellenobjekte umfaßt, wobei der Schritt des Ausführens des programmierbaren Hardwareelements in dem Instrument, um die Meßfunktion an dem Signal durchzuführen, den Schritt des Zugreifens auf ein Register auf dem programmierbaren Hardwareelement umfaßt, um eines der Nutzerschnittstellenobjekte zu beeinflussen.
Verfahren nach Anspruch 1, bei dem das Instrument den Prozessor und den Speicher aufweist, wobei der Prozessor in dem Instrument den ausführbaren Code aus dem Speicher ausführt, um den Frontplattenabschnitt auf der Anzeige darzustellen, während das programmierbare Hardwareelement in dem Instrument ausführt, um die Meßfunktion an dem Signal durchzuführen.
Verfahren nach Anspruch 1, bei dem das Instrument mit einem Computersystem gekoppelt ist, wobei das Computersystem den Prozessor und den Speicher aufweist, wobei das Computersystem den ausführbaren Code aus dem Speicher ausführt, um die Frontplatte auf der Anzeige darzustellen, während das programmierbare Hardwareelement in dem Instrument ausführt, um die Meßfunktion an dem Signal durchzuführen.
Verfahren nach Anspruch 1, bei dem das Instrument weiterhin eine Zeitgeber/Zähler-Logik enthält und das Verfahren weiterhin den Schritt umfaßt: Durchführen der Zeitgeber/Zähler-Logik einer der Zeitgeber/Zähler-Operationen, während das programmierbare Hard wareelement in dem Instrument ausführt, um die Meßfunktion an dem Signal durchzuführen.
Verfahren nach Anspruch 1, bei dem das programmierbare Hardwareelement in dem Instrument ausführt, um eine Prozeßkontrollfunktion unter Verwendung des Signals durchzuführen.
Verfahren nach Anspruch 1, das weiterhin die Schritte umfaßt: Konvertieren der Hardwarebeschreibung in eine Netzliste, und Übersetzen des Netzlistenformats in eine Hardwareprogrammdatei, wobei das Konfigurieren des programmierbaren Hardwareelements den Schritt des Herunterladens der Hardwareprogrammdatei zu dem programmierbaren Hardwareelement umfaßt, um das programmierbare Hardwareelement zu konfigurieren.
Verfahren nach Anspruch 9, bei dem der Schritt des Konvertierens der Hardwarebeschreibung in eine Netzliste die Schritte umfaßt: Verwenden zumindest eines Funktionsblocks einer Bibliothek von vorübersetzten Funktionsblöcken, und Verwenden von hardwarezielspezifischen Informationen.
Verfahren nach Anspruch 1, bei dem der Schritt des Erzeugens des grafischen Programms die Schritte umfaßt: Anordnen auf dem Bildschirm einer Vielzahl von Knoten, die das grafische Programm umfassen, Erzeugen und Speichern von Datenstrukturen, die das grafische Programm in Reaktion zu dem Anordnen repräsentieren, wobei der Schritt des Erzeugens der Hardwarebeschreibung die Schritte umfaßt: Durchlaufen der Datenstrukturen, Konvertieren der Datenstrukturen in ein Hardwarebeschreibungsformat in Reaktion auf das Durchlaufen.
Verfahren nach Anspruch 1, bei dem das grafische Programm eine Vielzahl von Knoten umfaßt, wobei der Schritt des Erzeugens der Hardwarebeschreibung einen Schritt des Konvertierens jedes der Knoten in ein Hardwarebeschreibungsformat umfaßt.
Verfahren nach Anspruch 12, bei dem jeder der Knoten in ein Hardwarebeschreibungsformat konvertiert ist, mit einer Auslöse- bzw. Freigabeeingabe, einer Taktsignaleingabe und einer Auslöseausgabe, wobei für einen jeweiligen Knoten die Auslöseeingabe ein Auslösesignal empfängt, das von Auslöseaussignalen von einem oder mehr Knoten erzeugt wird, die Eingaben zu den jeweiligen Knoten bereitstellen.
Verfahren nach Anspruch 12, bei dem das grafische Programm ein Eingabeterminal aufweist, wobei der Schritt des Konvertierens für das Eingabeterminal die Schritte umfaßt: Bestimmen, ob eine Dateneingabe zu dem Eingabeterminal von einem Nutzerschnittstellenabschnitt ist, der auf dem Computersystem ausgeführt wird, Erzeugen einer Hardwarebeschreibung eines Schreiberegisters, wobei das Schreiberegister eine oder mehrere Datenausgaben und zumindest eine Kontrollausgabe umfaßt.
Verfahren nach Anspruch 12, bei dem das grafische Programm einen Funktionsknoten umfaßt, wobei der Schritt des Konvertierens für den Funktionsknoten die Schritte umfaßt: Bestimmen von Eingaben und Ausgaben zu/von dem Funktionsknoten, Erzeugen einer Hardwarebeschreibung einer Logik, die die Funktion durchführt, die durch den Funktionsknoten bezeichnet ist, Durchlaufen von Eingabeabhängigkeiten des Knotens, Erzeugen einer Hardwarebeschreibung eines UND-Gatters, mit Protokollverbindungen der Eingabeabhängigkeiten des Knotens zu dem UND-Gatter.
Verfahren nach Anspruch 12, bei dem das grafische Programm einen Strukturknoten umfaßt, wobei der Schritt des Konvertierens für den Strukturknoten die Schritte umfaßt: Bestimmen von Eingaben und Ausgaben zu/von dem Strukturknoten, Erzeugen einer Hardwarebeschreibung eines Kontrollblocks, der die Kontrollfunktion durchführt, die durch den Strukturknoten bezeichnet ist, Durchlaufen von Eingabeabhängigkeiten des Knotens, Erzeugen einer Hardwarebeschreibung eines UND-Gatters mit Protokollverbindungen der Eingabeabhängigkeiten des Knotens zu dem UND-Gatter.
Verfahren nach Anspruch 12, bei dem das grafische Programm ein Ausgabeterminal umfaßt, wobei der Schritt des Konvertierens für das Ausgabeterminal die Schritte umfaßt: Bestimmen, ob eine Datenausgabe von dem Ausgabeterminal für einen Nutzerschnittstellenabschnitt ist, der auf dem Computersystem ausführt, Erzeugen einer Hardwarebeschreibung eines Leseregisters, wobei das Leseregister eine oder mehrere Dateneingaben und zumindest eine Kontrolleingabe umfaßt.
Verfahren nach Anspruch 1, bei dem das grafische Programm ein Datenflußdiagramm umfaßt.
Verfahren nach Anspruch 1, bei dem ein erster Abschnitt des Blockdiagrammabschnitts in eine Hardwarebeschreibung konvertiert ist, wobei das Verfahren weiterhin den Schritt umfaßt: Übersetzen eines zweiten Abschnitts des Blockdiagrammabschnitts in Maschinencode zur Ausführung durch den Prozessor.
Verfahren nach Anspruch 19, das weiterhin die Schritte umfaßt: Ausführen des Maschinencodes, um die Funktionalität durchzuführen, die durch den zweiten Abschnitt des Blockdiagrammabschnitts bezeichnet ist, Durchführen durch das konfigurierte Hardwareelement einer Funktionalität, die durch den ersten Abschnitt des Blockdiagrammabschnitts bezeichnet ist, wobei das Ausführen des Maschinencodes und das Durchführen der Funktionalität durch das konfigurierte Hardwareelement dazu dienen, eine Funktionalität durchzuführen, die durch den Blockdiagrammabschnitt des grafischen Programms bezeichnet ist.
Verfahren nach Anspruch 1, bei dem das Instrument einen nichtflüchtigen Speicher aufweist, der mit dem programmierbaren Hardwareelement gekoppelt ist, und das Verfahren weiterhin den Schritt umfaßt: Speichern der Hardwarebeschreibung in einen nichtflüchtigen Speicher, wobei das Konfigurieren des programmierbaren Hardwareelements den Schritt des Übertragens der Hardwarebeschreibung von dem nichtflüchtigen Speicher zu dem programmierbaren Hardwareelement umfaßt, um das konfigurierte Hardwareelement zu erzeugen.
Meßsystem mit: einem Computersystem mit einer CPU, Speicher und einer Anzeige, wobei der Speicher ein grafisches Programm speichert, wobei das grafische Programm eine Meßfunktion implementiert, wobei das grafische Programm einen Frontplattenabschnitt und einen Blockdiagrammabschnitt umfaßt, wobei der Frontplattenabschnitt als eine Frontplatte für das Instrument funktioniert, wobei der Speicher ebenfalls ein Softwareprogramm speichert, das ausführbar ist, um eine Hardwarebeschreibung basierend auf dem Blockdiagrammabschnitt des grafischen Programms zu erzeugen, wobei die Hardwarebeschreibung eine Hardwareimplementierung des Blockdiagrammabschnitts des grafischen Programms beschreibt, und einem Instrument, das an das Computersystem gekoppelt ist, wobei das Instrument aufweist: eine Eingabe zum Annehmen eines Signals von einer externen Quelle, und ein programmierbares Hardwareelement, wobei das programmierbare Hardwareelement in dem Instrument unter Verwendung der Hardwarebeschreibung konfigurierbar ist, um ein konfiguriertes Hardwareelement zu erzeugen, wobei das konfigurierte Hardwareelement eine Hardwareimplementierung des Blockdiagrammabschnitts des grafischen Programms implementiert, wobei das programmierbare Hardwareelement in dem In strument ausführbar ist, um die Meßfunktion an dem angenommenen Signale durchzuführen, wobei das Computersystem betriebsbereit ist, um den Frontplattenabschnitt des grafischen Programms in ausführbaren Code zu übersetzen und den ausführbaren Code in dem Speicher zu speichern, wobei die CPU in dem Computersystem betriebsbereit ist, den ausführbaren Code auszuführen, um den Frontplattenabschnitt auf der Anzeige darzustellen, während das programmierbare Hardwareelement in dem Instrument ausführt, um die Meßfunktion an dem Signal durchzuführen.
Meßsystem nach Anspruch 22, bei dem das Instrument weiterhin aufweist: eine Analog/Digital-Umwandlungslogik, die mit der Eingabe und dem programmierbaren Hardwareelement gekoppelt ist, um eine Anlaog/Digital-Umwandlungslogik an einem angenommenen analogen Signal durchzuführen, um ein digitales Signal zu erzeugen.
Meßsystem nach Anspruch 22, bei dem der Frontplattenabschnitt betriebsbereit ist, um eine Nutzereingabe aufzunehmen, um das Instrument während der Meßfunktion zu kontrollieren.
Meßsystem nach Anspruch 22, bei dem das Instrument weiterhin eine Zeitgeber/Zähler-Logik aufweist, wobei die Zeitgeber/Zähler-Logik eine der Zeitgeber/Zähler-Operationen durchführt, während das programmierbare Hard wareelement in dem Instrument ausführt, um die Meßfunktion an dem Signal durchzuführen.
Meßsystem nach Anspruch 22, bei dem das programmierbare Hardwareelement in dem Instrument ausführt, um eine Prozeßkontrollfunktion unter Verwendung des Signals durchzuführen.
Meßsystem nach Anspruch 26, bei dem das Softwareprogramm, das in dem Speicher des Computersystems gespeichert ist, weiterhin betriebsbereit ist, um die Hardwarebeschreibung in eine Netzliste umzuwandeln, wobei das Computersystem betriebsbereit ist, daß programmierbare Hardwareelement unter Verwendung der Netzliste zu konfigurieren.
Meßsystem nach Anspruch 22, bei dem das Softwareprogramm, das in dem Speicher des Computersystems gespeichert ist, weiterhin betriebsbereit ist, das Netzlistenformat in eine Hardwareprogrammdatei zu übersetzen, und wobei das Computersystem betriebsbereit ist, die Hardwareprogrammdatei zu dem programmierbaren Hardwareelement herunterzuladen, um das programmierbare Hardwareelement zu konfigurieren.
Meßsystem nach Anspruch 22, bei dem das programmierbare Hardwareelement eine feldprogrammierbare Gatteranordnung (FPGA) aufweist.
Meßsystem nach Anspruch 22, bei dem das Computersystem einen Bus und ebenfalls einen oder mehrere Erweiterungsschlitze aufweist, die mit dem Bus gekoppelt und ausgelegt sind, Erweiterungskarten aufzunehmen, wobei das Instrument eine Erweiterungskarte aufweist, die in einen Erweiterungsschlitz des Busses eingesetzt ist.
Meßsystem nach Anspruch 22, bei dem das Instrument ein externes Instrument ist, das mit dem Computersystem gekoppelt ist.
Meßsystem nach Anspruch 22, bei dem der Speicher des Computersystems ein grafisches Programmiersystem zum Erzeugen des grafischen Programms speichert, wobei das grafische Programmiersystem ausführbar ist, um auf dem Bildschirm eine Vielzahl von Knoten anzuordnen, die das grafische Programm in Reaktion zu der Nutzereingabe umfassen, wobei das grafische Programmsystem weiterhin ausführbar ist, um Datenstrukturen zu erzeugen und zu speichern, die das grafische Programm in Reaktion zu der Anordnung repräsentieren, wobei das Softwareprogramm ausführbar ist, die Datenstrukturen zu durchlaufen und die Datenstrukturen in ein Hardwarebeschreibungsformat in Reaktion zu dem Durchlaufen zu übersetzen.
Meßsystem nach Anspruch 22, bei dem ein erster Abschnitt des Blockdiagrammabschnitts in eine Hardwarebeschreibung übersetzt ist, wobei das Computersystem betriebsbereit ist, einen zweiten Abschnitt des Blockdiagrammabschnitts in einen Maschinencode zur Ausführung durch die CPU zu übersetzen.
Meßsystem nach Anspruch 33, bei dem das konfigurierte Hardwareelement betriebsbereit ist, eine Funktionalität durchzuführen, die durch den ersten Abschnitt des Blockdiagrammabschnitts bezeichnet ist, wobei das Computersystem betriebsbereit ist, den Maschinencode auszuführen, um eine Funktionalität durchzuführen, die durch den zweiten Abschnitt des Blockdiagrammabschnitts bezeichnet ist, wobei die Ausführung des Maschinencodes und die Durchführung der Funktionalität durch das konfigurierte Hardwareelement dazu dient, eine Funktionalität durchzuführen, die durch den Blockdiagrammabschnitt des grafischen Programms bezeichnet ist.
Meßsystem nach Anspruch 22, bei dem das Instrument einen nichtflüchtigen Speicher aufweist, der mit dem programmierbaren Hardwareelement gekoppelt ist, wobei der nichtflüchtige Speicher betriebsbereit ist, die Hardwarebeschreibung zu speichern, wobei der nichtflüchtige Speicher betriebsbereit ist, die Hardwarebeschreibung zu dem programmierbaren Hardwareelement zu übertragen, um das konfigurierte Hardwareelement zu erzeugen.
Meßsystem nach Anspruch 22, bei dem das Instrument Datenakquisitions/Erzeugungsfunktionen durchführt.
Meßsystem nach Anspruch 22, bei dem das Instrument ein IEC-Bus-Instrument ist.
Meßsystem nach Anspruch 22, bei dem das Instrument ein VXI-Bus-Instrument ist.
Meßsystem nach Anspruch 22, bei dem das Instrument ein Instrument mit seriellem Anschluß ist.
Meßsystem nach Anspruch 22, bei dem das Instrument eine speicherprogrammierbare Anpaßsteuerung (PLC) ist.
Meßsystem nach Anspruch 22, bei dem das Instrument eine Feldbus-Vorrichtung ist.
Meßsystem mit: einem Computersystem mit einer CPU, Speicher und einer Anzeige, wobei der Speicher ein grafisches Programm speichert, wobei das grafische Programm eine Meßfunktion implementiert, wobei das grafische Programm einen Frontplattenabschnitt und einen Blockdiagrammabschnitt aufweist, wobei der Frontplattenabschnitt als eine Frontplatte für das Instrument funktioniert, wobei der Speicher ebenfalls ein Softwareprogramm speichert, das ausführbar ist, um eine Hardwarebeschreibung basierend auf dem Blockdiagrammabschnitt des grafischen Programms zu erzeugen, wobei die Hardwarebeschreibung eine Hardwareimplementierung des Blockdiagrammabschnitts des grafischen Programms beschreibt, einem Instrument, das an das Computersystem gekoppelt ist, wobei das Instrument aufweist: eine Eingabe zum Annehmen eines Signals von einer externen Quelle, einen Prozessor, einen Speicher, der mit dem Prozessor gekoppelt ist, und ein programmierbares Hardwareelement, wobei das programmierbare Hardwareelement in dem Instrument unter Verwendung der Hardwarebeschreibung konfigurierbar ist, um ein konfiguriertes Hardwareelement zu erzeugen, wobei das konfigurierte Hardwareelement eine Hardwareimplementierung des Blockdiagrammabschnitts des grafischen Programms implementiert, wobei das programmierbare Hardwareelement in dem Instrument ausführbar ist, um die Meßfunktion an einem angenommenen Signal durchzuführen, wobei der Frontplattenabschnitt des grafischen Programms betriebsbereit ist, in einen ausführbaren Code übersetzt und in dem Speicher des Instruments gespeichert zu werden, wobei der Prozessor in dem Instrument betriebsbereit ist, den ausführbaren Code auszuführen, um den Frontplattenabschnitt auf der Anzeige darzustellen, während das programmierbare Hardwareelement in dem Instrument ausführt, um die Meßfunktion an dem Signal durchzuführen.
Meßsystem nach Anspruch 42, bei dem das Instrument weiter aufweist: eine Analog/Digital-Umwandlungslogik, die mit der Eingabe und dem programmierbaren Hardwareelement gekoppelt ist, um eine Analog/Digital-Umwandlungslogik an einem angenommenen Analogsignal durchzuführen, um ein digitales Signal zu erzeugen.
Meßsystem nach Anspruch 42, bei dem der Frontplattenabschnitt betriebsbereit ist, eine Nutzereingabe aufzunehmen, um das Instrument während der Meßfunktion zu kontrollieren.
Meßsystem nach Anspruch 42, bei dem das Instrument weiterhin eine Zeitgeber/Zähler-Logik aufweist, wobei die Zeitgeber/Zähler-Logik eine der Zeitgeber/Zähler-Operationen durchführt, während das programmierbare Hardwareelement in dem Instrument ausführt, um die Meßfunktion an dem Signal durchzuführen.
Meßsystem nach Anspruch 42, bei dem das programmierbare Hardwareelement in dem Instrument ausführt, um eine Prozeßkontrollfunktion unter Verwendung des Signals durchzuführen.
Meßsystem nach Anspruch 46, bei dem das Softwareprogramm, das in dem Speicher des Computersystems gespeichert ist, weiterhin betriebsbereit ist, die Hardwarebeschreibung in eine Netzliste zu konvertieren bzw. umzuwandeln, wobei das Computersystem betriebsbereit ist, das programmierbare Hardwareelement unter Verwendung der Netzliste zu konfigurieren.
Meßsystem nach Anspruch 42, bei dem das Softwareprogramm, das in dem Speicher des Computersystems gespeichert ist, weiterhin betriebsbereit ist, das Netzlistenformat in eine Hardwareprogrammdatei zu übersetzen, und wobei das Computersystem betriebsbereit ist, die Hardwareprogrammdatei zu dem programmierbaren Hardwareelement herunterzuladen, um das programmierbare Hardwareelement zu konfigurieren.
Meßsystem nach Anspruch 42, bei dem das programmierbare Hardwareelement eine feldprogrammierbare Gatteranordnung (FPGA) aufweist.
Meßsystem nach Anspruch 42, bei dem das Computersystem einen Bus und ebenfalls einen oder mehrere Erweiterungsschlitze aufweist, die mit dem Bus gekoppelt sind und ausgelegt sind, Erweiterungskarten aufzunehmen, wobei das Instrument eine Erweiterungskarte aufweist, die in einen Erweiterungsschlitz des Busses eingesetzt ist.
Meßsystem nach Anspruch 42, bei dem das Instrument ein externes Instrument ist, das mit dem Computersystem gekoppelt ist.
Meßsystem nach Anspruch 42, bei dem der Speicher des Computersystems ein grafisches Programmiersystem zum Erzeugen des grafischen Programms speichert, wobei das grafische Programmiersystem ausführbar ist, um auf dem Bildschirm eine Vielzahl von Knoten anzuordnen, die das grafische Programm in Reaktion auf eine Nutzereingabe umfassen, wobei das grafische Programmiersystem weiterhin ausführbar ist, Datenstrukturen zu erzeugen und zu speichern, die das grafische Programm in Reaktion auf das Anordnen repräsentieren, wobei das Softwareprogramm ausführbar ist, die Datenstrukturen zu durchlaufen und die Datenstrukturen in ein Hardwarebeschreibungsformat in Reaktion auf das Durchlaufen umzuwandeln.
Meßsystem nach Anspruch 42, bei dem ein erster Abschnitt des Blockdiagrammabschnitts in eine Hardwarebeschreibung umgewandelt ist, wobei das Computersystem betriebsbereit ist, einen zweiten Abschnitt des Blockdiagrammabschnitts in einen Maschinencode zur Ausführung durch die CPU zu übersetzen.
Meßsystem nach Anspruch 53, bei dem das konfigurierte Hardwareelement betriebsbereit ist, eine Funktionalität durchzuführen, die durch den ersten Abschnitt des Blockdiagrammabschnitts bezeichnet ist, wobei das Computersystem betriebsbereit ist, den Maschinencode auszuführen, um eine Funktionalität durchzuführen, die durch den zweiten Abschnitt des Blockdiagrammabschnitts bezeichnet ist, wobei das Ausführen des Maschinencodes und die Durchführung der Funktionalität durch das konfigurierte Hardwareelement dazu dienen, eine Funktionalität durchzuführen, die durch den Blockdiagrammabschnitt des grafischen Programms bezeichnet ist.
Meßsystem nach Anspruch 42, bei dem das Instrument einen nichtflüchtigen Speicher aufweist, der mit dem programmierbaren Hardwareelement gekoppelt ist, wobei der nichtflüchtige Speicher betriebsbereit ist, die Hardwarebeschreibung zu speichern, wobei der nichtflüchtige Speicher betriebsbereit ist, die Hardwarebeschreibung zu dem programmierbaren Hardwareelement zu übertragen, um das konfigurierte Hardwareelement zu erzeugen.
Meßsystem nach Anspruch 42, bei dem das Instrument Akquisitions/Erzeugungsfunktionen durchführt.
Meßsystem nach Anspruch 42, bei dem das Instrument entweder ein IEC-Bus-Instrument, ein VXI-Bus-Instrument oder ein Instrument mit seriellem Anschluß ist.
Meßsystem nach Anspruch 42, bei dem das Instrument eine speicherprogrammierbare Anpaßsteuerung (PCL) ist.
Meßsystem nach Anspruch 42, bei dem das Instrument eine Feldbus-Vorrichtung ist.