DE19815534A1 - Verfahren und System zum Entwurf und zur Simulation digitaler Rechner-Hardware - Google Patents

Description

HINTERGRUND DER ERFINDUNG Gebiet der Erfindung

Die vorliegende Erfindung betrifft generell die Entwicklung des Entwurfs von Rechner-Hardware und die Simulation des elektrischen und logischen Verhaltens digitaler Hardware, beispielsweise elektronischer Schaltkreise. Im einzelnen stellt die Erfindung ein Verfahren und eine Vorrichtung be­ reit, die eine Umwandlung einer funktionellen Beschreibung digitaler Hardware in eine komplette Netzliste ermöglichen.

Stand der Technik

Die bisherigen Ansätze für die Entwurfsspezifikation von Rechner-Hardware haben entweder eine Beschreibung auf der Re­ gistertransferebene (RTL) der Netzliste oder eine funktio­ nelle Beschreibung der Hardware als Grundlage. Eine funktio­ nelle Beschreibung ist keine Darstellung des Hardware-Layouts mit allen Einzelheiten, das heißt mit allen Zwischenverbin­ dungen und funktionellen Elementen, sondern wird vorwiegend verwendet, um schnellstmöglich eine Hardware-Spezifikation zu erstellen, die bereits auf der frühesten Entwicklungsstufe ausführungsfähig ist und überprüft werden kann. Hiermit wer­ den die für die Hardware geplanten funktionellen Eigenschaf­ ten in die Funktionsmerkmale umgewandelt, die dann miteinan­ der verknüpft werden.

Eine funktionelle Beschreibung kann in jeder beliebigen Pro­ grammiersprache erstellt werden, beispielsweise in "C" oder "C++", erfolgt oft jedoch in speziell modifizierten Sprachen wie "BEHAVIOUR", um spezielle Hardware-Eigenschaften be­ schreiben zu können. Nachdem sie für das Zielrechnersystem kompiliert wurde, kann die funktionelle Beschreibung zur Hardware-Simulation auf einem Standardrechner eingesetzt wer­ den, unter Anwendung von Betriebssystemen wie "UNIX" (ein von Bell Laboratories entwickeltes Betriebssystem, eingetragenes Warenzeichen der UNIX Systemlaboratorien). Der funktionelle Beschreibungsansatz ermöglicht daher die Darstellung komple­ xer Hardware-Strukturen in einer Form, die es möglich macht, Hardware-Fehler zu einem frühestmöglichen Zeitpunkt während der Entwurfsphase ausfindig zu machen.

Im Gegensatz zu dem oben genannten funktionellen Ansatz ist eine Netzlistenbeschreibung in jedem Fall notwendig, um zu einem Hardware-Erzeugnis für den Entwurf zu gelangen. Die Netzlisten können mit speziellen Hardware-Beschreibungsspra­ chen beschrieben werden, beispielsweise in "DSL" (Hardware Design Language, entwickelt im IBM Entwicklungslabor in Böblingen, Deutschland), die dadurch gekennzeichnet ist, daß sie nur eine Datenstruktur verwendet, nämlich Leiterbündel. Daher erfordert "DSL" nur Attributvereinbarungen für Ein­ gangs/Ausgangs-Merkmale oder Taktsignale. Speicherelemente wie Register und Arrays werden als Blöcke betrachtet. Das Vo­ kabular dieser Sprache umfaßt nur Operatoren mit einer nied­ rigen Hardware-Komplexität, z. B. die logischen Operatoren "compare", "if-then", "add" und "substract".

Eine andere Möglichkeit zur Netzlisten-Beschreibung ist "VHDL", eine Programmiersprache wie "ADA", die durch spezi­ elle Hardware-Operationen erweitert ist. Diese Sprache umfaßt dementsprechend eine Reihe von Datenstrukturen und alle An­ weisungen einer normalen Programmiersprache, wie z. B. "Schleifen"-Anweisungen. Durch bestimmte Anweisungen für die Takt- und Signalgabe wird "VHDL" zu einer echten Hardware-Be­ schreibungssprache. Ein Nachteil von "VHDL" ist, daß die Si­ mulation aufgrund der erforderlichen Signaldefinitionen er­ eignisgesteuert ist.

Die vorerwähnten Beschreibungssprachen unterscheiden sich we­ sentlich von dem vorher beschriebenen funktionellen Ansatz, und zwar im Hinblick auf die jeweils zugrunde liegende Metho­ dologie. Eine auf einem funktionellen Ansatz basierende Simu­ lationsprozedur führt nacheinander sämtliche Funktionen der kompletten Hardware aus. Es müssen jedoch nicht alle Funktio­ nen bei jedem Zustandsübergang ausgeführt werden, da sich die meisten von ihnen gegenseitig ausschließen.

Im Gegensatz dazu wird bei dem Netzlistenansatz die Hardware parallel beschrieben, wodurch funktionelle Beziehungen nicht evident werden. Zur Simulierung einer Netzliste muß daher die Netzlistenbeschreibung analysiert, sortiert und als Entwurfs­ modell in einer bestimmten Datenstruktur gespeichert werden. Dieses Entwurfsmodell kann dann anschließend von einem Simu­ lator ausgeführt werden. Die funktionellen Eigenschaften der simulierten Hardware gehen jedoch vollständig verloren. Daher ist dieser Ansatz ziemlich zeitaufwendig. Bis heute gibt es jedoch kein Verfahren, das eine einfache oder sogar automati­ sche Umwandlung von einer funktionellen Beschreibung der Hardware in eine korrekte und vollständige Netzliste ermög­ licht. Daher müssen für alle Entwürfe aufwendige Netzlisten­ spezifikationen generiert und manuell überprüft werden.

Außerdem verwendet man beim Entwurf der heutigen komplizier­ ten digitalen Signalverarbeitungssysteme in zunehmendem Maße hochentwickelte Entwurfswerkzeuge für eine Funktionsanalyse und Simulation. In letzter Zeit befaßte man sich mit der In­ tegration derartiger Simulationswerkzeuge, wobei sich daten­ flußorientierte Ansätze wegen der besonderen Eigenschaften der meisten digitalen Signalverarbeitungsanwendungen als sehr gut geeignet erwiesen haben. Desweiteren ist die Integration des Steuerungsflusses in die datenflußorientierte Simulation und Synthese bekannt.

In der Technik sind verschiedene Entwicklungswerkzeuge in Form von Zustandsmaschinen für Entwurfseingaben und Simula­ tionen auf höherer Ebene bekannt, mit denen die Entwurfszeit verkürzt und die Korrektheit der Simulationsergebnisse ge­ währleistet werden können. Für die Analyse eines typischen Rechnerentwurfs ist die Folgesteuerungslogik des Hardware-Sy­ stems, die in Form von Maschinen mit finitem Zustand reali­ siert wird, eine der wichtigsten Entwurfsbemühungen.

Ein anderes wichtiges Problem, das zum Beispiel in einem Ar­ tikel von A. Aziz et al. angesprochen wird, der in IEEE Com­ puter Society Press, Los Alamitos, USA, unter dem Titel "Minimizing Interacting Finite State Machines: A Compositional Approach to Language Containment" veröffent­ licht wurde, ist die kompositionale Minimierung mehrerer mit­ einander in Wechselbeziehung stehender Maschinen mit finitem Zustand, die sich in Zusammenhang mit der formellen Überprü­ fung der Hardware-Entwürfe ergeben. Von den Autoren wird an­ erkannt, daß vieles im Verhalten eines entworfenen Systems, bezogen auf eine zu überprüfende gegebene Eigenschaft, redun­ dant ist, so daß das System durch wesentlich einfachere Dar­ stellungen ersetzt werden kann. Die Autoren zeigen, daß diese Redundanzen durch Berechnung von Zuständen erfaßt werden kön­ nen, die bei gleichzeitiger Fairneß Eingangs-/Ausgangs-äqui­ valent sind. Da die Berechnung vollständiger Äquivalenzen rechnerisch aufwendig ist, schlagen sie weiter ein Spektrum von Annäherungen vor, die effizient berechenbar sind. So wer­ den zum Beispiel Prozeduren beschrieben, die das System im Hinblick auf explizite Darstellungen hierarchisch minimieren.

Hierauf basieren eine Reihe von bekannten Lösungsansätzen im Bereich der Übersetzung von Datenflußinformationen in eine Hardware-Beschreibungssprache. In einem Artikel von W.H. Chou und S.Y. Kung mit dem Titel "Register Transfer Modelling and Simulation for Array Processors", veröffentlicht in IEEE Computer Society Press, Los Alamitos, USA, wird ein Modellie­ rungsschema für einen Registertransfer beschrieben, in dem eine graphische Darstellung des entworfenen Datenflusses in eine Registertransfersprache übersetzt wird, die weiter mit einem Hardware-Beschreibungsmodul kombiniert wird. Hierdurch wird ein interaktiver Simulator implementiert, der das Ver­ halten eines solchen Systems simuliert.

In einem Artikel von A.D. Gordon mit dem Titel "The Formal Definition of a Synchronous Hardware Description", veröffent­ licht in IEEE Computer Society Press, Los Alamitos, USA, wird eine Hardware-Überprüfungsmethode beschrieben, die Verbindun­ gen herstellt zwischen einer Sprache, die in der Praxis zum Entwurf eines Schaltkreises verwendet wird, und einer anderen Sprache, die zu Forschungszwecken in Zusammenhang mit der Hardware-Überprüfung verwendet wird. Hier wird eine einfache Datenflußsprache zur Beschreibung digitaler Signalverarbei­ tungs-Schaltkreise verwendet, bei der eine Logik höherer Ord­ nung ausgiebig für Untersuchungen der Hardware-Überprüfung eingesetzt wird. Im einzelnen wird eine Kombination aus einer Betriebs- und einer Vorhersagesemantik zur formellen Defini­ tion einer wesentlichen Teilgruppe der Datenflußsprache ver­ wendet, indem die Definitionen dieser Sprache in den Vorher­ sagen der Logik höherer Ordnung abgebildet werden.

Eine andere Hardware-Entwurfsumgebung der höheren Stufe wird beschrieben in einem Artikel von F. Rocheteau und N. Halbwachs mit dem Titel "POLLUX: LUSTRE BASED HARDWARE DESIGNED ENVIRONMENT", veröffentlicht bei Elsevier, Amster­ dam, Niederlande, 1992. Hier wurde eine Entwurfsbeschreibung in einer Datenflußsprache geschrieben und von einem anderen Werkzeug verwendet, um den entsprechenden synchronen Schalt­ kreis oder ein Simulationsprogramm zu erzeugen, das auf einer sequentiellen Maschine kompiliert und ausgeführt werden kann.

Neben den obigen Ansätzen sind auch objektorientierte Kon­ zepte für Hardware-Beschreibungssprachen bereits bekannt, beispielsweise aus einem Artikel von A.J. Van der Hoeven et al. mit dem Titel "A Hardware Designed System Based on Object-Oriented Principles", veröffentlicht in IEEE Computer Society Press, Los Alamitos, USA. Die meisten Hardware-Be­ schreibungssprachen und ihre Umgebungen basieren entweder auf imperativen Sprachkonzepten oder auf funktionellen Sprachkon­ zepten. Die in diesem Artikel beschriebene Hardware-Spezifi­ kations- und Simulationsumgebung basiert auf objektorientier­ ten Konzepten wie Klassen, Objekten, Vererbung und Abstrak­ tion. Das zugrunde liegende Hardware-Entwurfsmodell verwendet außerdem applikative Zustandsübergänge zur Beschreibung der Funktionalität und des Datenflusses in einem VLSI-Netz.

Ein weiterer objektorientierter Ansatz wird beschrieben in IBM TDB Nr. 12, 5/91, Seite 435-436, unter dem Titel "State Machine Verification Expert". Dieses Expertensystem wurde er­ dacht zur Erzeugung aller möglichen Szenarien für eine Zu­ standsmaschine. Bei der Zustandsmaschine handelt es sich in der Beschreibung um Entitäten, die sich auf bestimmte Kennt­ nisse stützen, in denen Zustandsübergangsregeln als Vorwärts­ verkettungsregeln dargestellt sind. Mit dem System wird ins­ besondere eine natürliche Darstellung der Zustandsmaschine erreicht; es verwendet heuristische und kausale Kenntnisse, um den Stoßraum der Eingänge und den Zustand von allem Über­ flüssigen zu befreien. Das Expertensystem kann also wirksam alle Kombinationen der Eingangssignale und der möglichen Zu­ stände der Zustandsmaschine in angemessener Zeit testen. Das beschriebene, sich auf Kenntnisse stützende Konzept hat den Vorteil, daß es Vereinbarungen für das Verhalten der Maschine im zeitlichen Ablauf generieren kann, und es kann die Einzel­ heiten auf einer niedrigen Betriebsebene der Maschine aus­ blenden, um einen Ausgang nur auf einer höheren Ebene zu er­ zeugen. Mit dem objektorientierten Ansatz erreicht man eine Klassifizierung der Datenstrukturen in Einheiten-Hierarchien, die in der Zustandsmaschine eine Entität darstellen. Das Ex­ pertensystem erzeugt eine Funktion, die die möglichen Werte der Steuereingänge betrachtet und alle möglichen Kombinatio­ nen für die Regeln ausprobiert, um bestimmte Szenarien auszu­ filtern und zu erzeugen.

Neben diesen bisher genannten Lösungsansätzen ist aus der U.S. Patentschrift Nr. 5,369,594 ein verbessertes Entwurfssy­ stem und Verfahren für Schaltkreise bekannt. Der simulierte Schaltkreis, der sowohl passive als auch aktive lineare und nichtlineare Elemente aufweisen kann, wird in Teilschalt­ kreise unterteilt, so daß einige Teilschaltkreise nur lineare Elemente enthalten. Mit dieser Technik, Simulation großer Schaltkreise mit großen Bereichen passiver Komponenten, wird die Gesamtzeit für die Simulation wesentlich verkürzt.

Ein anderes Entwurfsverfahren für die Implementierung von Da­ tenflußpartitionen in einem Chipentwurf auf höherer Ebene, in dem eine wachsende logische Bibliothek mit Makrofunktionen eingesetzt wird, um den Datenfluß und die Partitionierungen der Steuerlogik zu beschreiben, wird in der EP-Anmeldung Nr. 91.480.167.5 beschrieben. Dieses Entwurfsverfahren umfaßt ei­ nen logischen Eingabeschritt, um mit einer Sprache höherer Ebene den Chipentwurf zu erfassen, unter Anwendung der logi­ schen Makrofunktionsbibliothek zur Beschreibung von Partitio­ nen der Datenfluß-Steuerlogik, einen logischen Simulations­ schritt auf höherer Ebene, in dem Wortmodelldaten verwendet werden, die das logische Verhalten der Makrofunktionen dar­ stellen, um auf einer höheren Ebene das Verhalten der Logik der höheren Ebene zu simulieren, einen Strukturextraktions­ schritt zur Extrahierung der zugehörigen physikalischen Daten aus der Logik der höheren Ebene unter Anwendung einer Wortab­ bildung, die die physische Plazierung von Büchern in den Ma­ krofunktionen und die logischen Modelle der Bücher be­ schreibt, einen Buchebenenlogik-Überprüfungsschritt, mit dem sichergestellt wird, daß die Buchebenenlogik mit der Logik der höheren Ebene konsistent ist, und, neben anderen Schrit­ ten, einen Leistungszuweisungsschritt, in dem die Buchebenen­ logik zur Erstellung des korrekten Leistungspegels der in der Buchebenenlogik enthaltenen Bücher verwendet wird.

In einem im IBM Technical Disclosure Bulletin (TDB), Band 38, Nr. 7, 1995, auf den Seiten 253-254 beschriebenen Artikel mit dem Titel "Method to Analyze Global Transient Phenomena Induced by Changes in the State of Very Large Simulation Models", wird ein Lösungsansatz für eine globale Analyse ei­ ner zentralen Verarbeitungseinheit (CPU) mit Ereignissimula­ tor beschrieben. Die dort angesprochenen speziellen Probleme sind lange CPU-Laufzeiten und die Analyse von Übergangsvaria­ blen wie Strom, lokale Erwärmung, Veränderungen der Versor­ gungsströme, Spannungsverschiebungen auf Stromversorgungsbus­ sen, logische Veränderungen durch Rauschen und durch Rauschen verursachte Fehler in den Analog-Schaltkreisen. Das Grundkon­ zept dieses Lösungsansatzes ist eine Abstraktion dessen, was beim Entwurf bei jeder Zustandsänderung geschieht.

Ein verbesserter Funktionssimulator zur Überprüfung einer von der Technologie unabhängigen Logik wird beschrieben in IBM TDB Nr. 2, 7/91, Seite 252-253, unter dem Titel "Hardware Cycle Simulation Coverage Measurement Tool". Die Analyse der Logik basiert auf einer Datenflußanalyse, in der überprüft wird, wie sich die logischen BOOLESCHEN Werte fortpflanzen, und in der geprüft wird, ob die Latches und Busse zu einem bestimmten Zeitpunkt die richtigen Werte aufweisen. Weiter wird anhand einer Steuerflußanalyse die Ablauffolge der Schalter und Entscheidungselemente geprüft, die zu einer Ver­ änderung des logischen Zustandes führen. Sie überprüft, ob diese während der Simulation aktiviert wurden oder nicht. Im einzelnen wird ein Programm beschrieben, das die Aktivierung des logischen Steuerflusses während der Simulationsphase quantifiziert und dadurch eine Bewertung des Deckungsbereichs des Testfalles zuläßt.

Ein logischer Entwurf anhand einer statischen Flußanalyse wird beschrieben in IBM TDB Nr. 8, 1/91, Seite 437-441. Mit einer logischen Synthese wird eine Umwandlung einer Hardware- Spezifikation auf funktioneller Ebene in eine logische Reali­ sation auf Gate-Ebene durchgeführt. Das logische Synthesesy­ stem dient zur Umwandlung des Modells in eine Grundentwurfs­ sprache zur Darstellung der Struktursprache. Diese Darstel­ lung auf Gate-Ebene ermöglicht die Durchführung einer Taktanalyse mit der jeweiligen Funktion. Der zur Herstellung der Chips verwendete Hardware-Entwurfszyklus beginnt mit ei­ ner funktionellen Beschreibung auf höherer Ebene, mit den An­ forderungen für die zeitlichen Abläufe und mit den Datenfluß­ bildern. Nachdem diese komplett sind, wird unter Verwendung der Grundentwurfssprache ein Software-Modell der Funktionen erzeugt. Man läßt dieses durch verschiedene Taktanalysepro­ gramme laufen, um zu prüfen, ob die Taktgabe für den Hard­ ware-Entwurf korrekt ist. Nachdem sowohl die Funktion als auch der zeitliche Ablauf überprüft sind, ist der logische Entwurf komplett. In einem daran anschließenden Schritt wird der physikalische Entwurf des Chips, das heißt, die Plazie­ rung und die Verdrahtung, angesprochen. Schließlich wird der Chip hergestellt, geprüft und den Logikentwicklern zurückge­ geben.

Ein Hardware-Entwurfsentwicklungssystem, bei dem die zu simu­ lierende Logik in mehrere funktionelle Inseln unterteilt wird, die parallel entwickelt werden, wird beschrieben in IBM TDB Nr. 7, 12/90, Seite 247-251, unter dem Titel "Multi-Clock Rate Device for Hardware Simulation Efficiency Improvement". Die Simulation beginnt auf voneinander getrennten Inseln und wird dann fortgesetzt mit immer größer werdenden Strukturen, um schließlich Funktionen zu erreichen, in denen verschiedene Karten einer späteren Maschine zu Gruppen zusammengefaßt wer­ den. Es können nicht alle Inseln gleichzeitig miteinander verbunden werden, da viele Probleme an den Schnittstellen zwischen den einzelnen Inseln auftreten. Am Beginn eines Si­ mulationsprojektes werden also Simulationselemente definiert, die Teilgruppen von Funktionen verschiedener Schnittstellen darstellen, so daß die Entwickler ihre Logik simulieren kön­ nen, bevor tatsächlich Schnittstellen verfügbar sind.

Ein verbesserter funktioneller Simulator, der eine parallele Hardware-Beschreibung wirksam in eine serielle Beschreibung zur logischen Simulation umwandelt, wird beschrieben in IBM TDB Nr. 11, 4/90, Seite 354-361, unter dem Titel "Model Ordering for Compiled Enhanced Functional Simulator". Hard­ ware-Modelle, die von einem Logiksimulator simuliert werden sollen, werden in Taktabschnitte segmentiert. Jeder Taktab­ schnitt wird weiter in einen Signalblockabschnitt und einen Latchblockabschnitt aufgeteilt. Registertransfer-Sprachanwei­ sungen werden dem langsamsten Taktabschnitt, bei dem sich im­ mer noch ein korrektes Verhalten ergibt, zugewiesen.

Ein Simulationsprogramm, das die dynamische Leistung einer großen Gruppe von miteinander verbundenen Schaltkreisen simu­ liert, wird beschrieben in IBM TDB 2/73, Seite 2973-2975. Eine Entwurfsbeschreibung ist in einem Block enthalten, der Simulationsbibliotheksinformationen verwendet, um eine Simu­ lationsdatenbank zu entwickeln. Der Block verwendet bekannte Analysetechniken mit kleinen Signalschaltkreisen, um äquiva­ lente Schaltkreise und Netzlisten zu entwickeln, welche die zu simulierende Schaltkreislogik beschreiben. Der Ausgang des Blocks ergibt die Simulationsdatenbank, die zur effizienten Verarbeitung von einem Simulationsalgorithmus formatiert wird. Im einzelnen wird die Simulationszeit in einzelne Schritte unterteilt. Der Simulationsalgorithmus behandelt einzelne logische Schaltkreise während eines Zeitschrittes voneinander unabhängig, weil der Zeitschritt im Vergleich zu den Übergangszeiten im Schaltkreis klein ist. Während eines jeden Zeitschritts werden nur diejenigen Schaltkreise simu­ liert, bei denen es zu einer Veränderung in der Zustandsva­ riablen kommen könnte. Eindeutig im Nullzustand befindliche Schaltkreise werden nicht simuliert. Die Berechnung der Schaltkreisrückmeldungen für die einzelnen logischen Schalt­ kreise wird seriell nach Schaltkreis für jeweils einen ein­ zelnen Zeitschritt ausgeführt. Die Eingänge für alle Schalt­ kreise verwenden die soeben berechneten Ergebnisse und alle externen Signalveränderungen während dieses Zeitschritts. Nachdem alle Schaltkreise analysiert wurden, werden die Er­ gebnisse in einer Ereignisdatei plaziert und die Zeit wird inkrementiert.

ZUSAMMENFASSUNG DER ERFINDUNG

Es ist eine Aufgabe der vorliegenden Erfindung, ein Verfahren und ein System bereitzustellen, mit denen eine Beschreibung eines digitalen Hardware-Entwurfs auf funktioneller Ebene in eine korrekte und vollständige Netzliste umgewandelt werden kann. Inbesondere wird dieses Verfahren automatisch ausge­ führt.

Eine weitere Aufgabe ist die Bereitstellung eines Hardware- Entwurfsverfahrens und eines Systems, mit denen eine notwen­ dige Simulation des Entwurfs auf niedriger Netzlistenstufe vermieden wird.

Eine andere Aufgabe ist die Bereitstellung eines Hardware-Si­ mulators zur Berechnung eines Hardware-Entwurfs innerhalb ei­ ner Mindestzeit, auch für die Simulation sehr komplexer Ent­ würfe.

Gemäß der Erfindung wird, als ein erster Schritt zur Generie­ rung einer Netzliste, eine lokale Netzliste bereitgestellt, auf der Grundlage fester Regeln, die später noch ausführli­ cher beschrieben werden. Außerdem wird parallel eine globale Variablentabelle aufgestellt. In einem zweiten Schritt wird für jede Variable die funktionelle Hardware-Beschreibung im Hinblick auf die in der globalen Tabelle enthaltene jeweilige Information umgewandelt und alle funktionellen Elemente des Entwurfs werden über ihre jeweiligen Verbindungen miteinander verbunden. In einem letzten Schritt wird die benötigte Ein­ gangs- und Ausgangsinformation zu der Netzliste hinzugefügt. Es wird betont, daß lokale Veränderungen in der funktionellen Spezifikation auch als lokale Veränderungen in der Netzliste dargestellt werden.

Die Erfindung erlaubt eine schnelle Simulation selbst kompli­ zierter Entwürfe, wie sie zum Beispiel im Bereich der inte­ grierten CMOS-Chiptechnologie verwendet werden. Natürlich kann die Erfindung auch für weniger komplizierte Hardware- Entwürfe in allen technischen Bereichen verwendet werden, beispielsweise für Chips für spezielle Zwecke oder für Steu­ erchips. Jede abstrakte Beschreibung eines Hardware-Entwurfs auf der Basis einer Steuerlogik und einer Datenflußlogik kann ohne besondere Entwicklungsbemühungen in eine Listenbeschrei­ bung der Hardware umgewandelt werden, was sogar automatisch ausgeführt werden kann. Daher ist eine manuelle Erzeugung ei­ ner Netzlistenspezifikation und eine langsame Simulation der Spezifikation nicht länger erforderlich. Darüber hinaus ist keine besondere Hardware für die Beschleunigung der Simula­ tion erforderlich.

Lokale Veränderungen eines zugrunde liegenden Entwurfs ent­ sprechen lokalen Veränderungen in der lokalen Netzliste. Die globale Netzliste selbst bleibt jedoch unverändert, da alle globalen Einträge durch feste Bezugspunkte in der lokalen Netzliste verankert sind.

Weiter muß nur ein Bruchteil aller möglichen logischen Zu­ stände des Entwurfs beschrieben werden, obwohl der Entwurf trotzdem umfassend beschrieben wird. Darüber hinaus hängt die zum Testen eines ganzen Chips benötigte Simulationszeit von den auf einem kompletten Chip gleichzeitig ablaufenden Pro­ zessen ab, und nicht von der Gesamtzahl der Funktionen.

KURZE BESCHREIBUNG DER ZEICHNUNGEN

Fig. 1 ist ein Blockschaubild zum Vergleich bisheriger Lö­ sungsansätze für Netzlisten mit der vorliegenden Erfindung;

Fig. 2 ist ein Blockschaubild zur Darstellung einer allge­ mein üblichen Anwendungsprogrammstruktur nach dem Stand der Technik;

Fig. 3 ist ein Flußbild, das einen Netzlisten-Umwandlungs­ mechanismus und den entsprechenden Informationsfluß gemäß ei­ nem bevorzugten Ausführungsbeispiel der Erfindung zeigt;

Fig. 4 ist ein bevorzugtes Eingangsdatenformat für den Da­ tenfluß und die Steuerlogikinformation, die für eine funktio­ nelle Beschreibung eines Hardware-Entwurfs gemäß der Erfin­ dung verwendet werden;

Fig. 5a zeigt typische Einträge der lokalen Netzliste und der Bezugnahmen auf die globale Tabelle gemäß der Erfindung;

Fig. 5b ist ein bevorzugtes Eintragsformat der globalen Ta­ belle gemäß der Erfindung;

Fig. 5c zeigt exemplarische globale Netzlistenanweisungen nach dem Stand der Technik;

Fig. 6 dient zur Illustration der Umwandlung sequentieller Anweisungen der funktionellen Hardware-Beschreibung in Netz­ listenanweisungen gemäß der Erfindung;

Fig. 7 zeigt, unter Bezugnahme auf die Fig. 5a-c, eine Darstellung von Variablen der funktionellen Beschreibung durch Multiplexer-Mittel; und

Fig. 8 zeigt die Reduzierung des Stromverbrauchs in einer Hardware, die entsprechend einem bevorzugten Ausführungsbei­ spiel der Erfindung entworfen wurde.

AUSFÜHRLICHE BESCHREIBUNG DER ERFINDUNG

Bezugnehmend auf das Blockschaubild in Fig. 1; die Simulation eines Hardware-Entwurfs und die Generierung einer Hardware- Netzliste aus einer funktionellen Hardwarebeschreibung höhe­ rer Ebene nach dem Stand der Technik wird verglichen mit den jeweils der vorliegenden Erfindung zugrunde liegenden Grund­ gedanken. Ausgangspunkt sowohl für die Simulation als auch für die Netzlistengenerierung ist eine funktionelle Beschrei­ bung 10 eines Hardware-Entwurfs auf höherer Ebene, in dem Hardware-Elemente, z. B. Latches oder Register, und funktio­ nelle Merkmale, z. B. Zykluszeiten, unter Anwendung einer im folgenden beschriebenen Technik spezifiziert werden.

Nach dem Stand der Technik wird die funktionelle Beschrei­ bung 10 für eine Simulation 11 der entworfenen Hardware auf höherer Ebene verwendet. Die Simulationsergebnisse können je­ doch nur zum Verständnis der zugrunde liegenden Funktionen und der Leistung der entworfenen Hardware verwendet werden. Die Simulation betrifft beispielsweise die Überprüfung des verwendeten p-Codes, die Leistungsmessung der entworfenen Hardware oder die Überprüfung der entworfenen Anwendungspro­ gramme.

Nach dem Stand der Technik wird daher neben dem Simulations­ schritt ein weiterer Schritt 12 für die Entwicklung der Hard­ ware benötigt, beispielsweise durch Generierung 13 einer Netzliste. Da dieser zweite Schritt 12 unabhängig von dem er­ sten Schritt 11 ist, können die Ergebnisse der Simulation nicht direkt für die Netzlistenerzeugung verwendet werden, sondern nur als Hintergrundinformation für den Hardware-Ent­ wickler. Insbesondere die Netzlisten selbst müssen durch ma­ nuelle Optimierungsschritte erstellt werden.

Im Gegensatz zu den bekannten Lösungsansätzen erlaubt der Netzlisten-Umwandlungsmechanismus gemäß der Erfindung die au­ tomatische Erstellung einer Netzliste, das heißt, ohne daß ein Eingreifen von Seiten des Anwenders erforderlich ist, aus einer funktionellen Beschreibung 10 auf höherer Ebene. Eine langsame Simulation auf der Netzlistenstufe der niedrigeren Ebene ist daher veraltet und die relativ schnelle Simula­ tion 14 der funktionellen Beschreibung ist ausreichend, um die entworfene Hardware zu testen.

Zur Darstellung von "BEHAVIOUR" zeigt das Blockschaubild der Fig. 2 eine gewöhnliche Programmstruktur, mit einem Hauptpro­ gramm 20 und zwei beispielhaften Subroutinen 21, 22, die je­ weils vom Hauptprogramm 20 bei der Programmausführung aufge­ rufen werden. Die Subroutinen 21, 22 selbst rufen weitere Subroutinen 23, 24, etc. auf. Ein Verzweigungsbefehl 25 be­ stimmt, welche der beiden Subroutinen 21, 22 aufgerufen wird, basierend auf dem momentanen Zustand in dem laufenden Haupt­ programm 20. Parallel zum Aufruf der Subroutine 21 werden außerdem feste Werte der Variablen x, y vom Hauptprogramm 20 an die Subroutine 21 übertragen. Ein weiterer Verzweigungsbe­ fehl 26, der in der ersten Subroutine 21 enthalten ist, ruft dann dementsprechend eine andere Subroutine 23 auf, wenn eine zweite bestimmte Voraussetzung erfüllt ist. Entsprechend wird eine letzte Subroutine 27 in der Reihe der Subroutinen aufge­ rufen.

Entsprechend dem dargestellten Programm wird entlang dem zweiten Subroutinenpfad, der mit der Subroutine 22 beginnt, ein zweiter Satz 28 von Werten für die Variablen X und Y übertragen. Eine besondere Konsequenz hiervon ist, daß in der dritten Subroutine 29 eine Bedingung "A1" nie erfüllt wird, das heißt, die Sprungrate in einem weiteren ausgeführten Si­ mulationsprozeß wäre "Null". Die Simulation dieses Zustandes ist somit redundant und verbraucht nur Simulationszeit, hat jedoch keinen positiven Effekt für die eigentlichen Simulati­ onsergebnisse.

Das Blockschaubild in Fig. 3 zeigt eine bevorzugte Eingangs­ formatstruktur für den Datenfluß und die Steuerlogikinforma­ tionen einer funktionellen Beschreibung eines Hardware-Ent­ wurfs. In einem ersten Schritt wird der Datenfluß 30 des ge­ wünschten Hardware-Entwurfs spezifiziert und in Funkti­ onsstrukturen unterteilt. Dann wird die benötigte Steuerlo­ gik 31, 32 in diese Funktionen eingeführt, um eine Beschrei­ bung des funktionellen Verhaltens der zugrunde liegenden Hardware zu bekommen. Es wird hiermit betont, daß verschie­ dene Zwischenverbindungen oder Beziehungen zwischen dem Da­ tenfluß und der Steuerlogik existieren, zum Beispiel über die zwischen ihnen stattfindenden Aufrufe 33. Die Steuerlogik 31, 32 kann auf verschiedene Funktionen verteilt werden. Es ist auch möglich, daß einige Funktionen überhaupt keinen Daten­ fluß enthalten, zum Beispiel eine Hauptroutine, die grund­ sätzliche Entscheidungen ausführt.

Es wird hiermit festgestellt, daß der dem vorgeschlagenen Konzept zugrunde liegende Gedanke eine Hardware-Beschreibung ist, die zwischen Datenfluß und Steuerfluß unterscheidet. Da­ tenfluß kann beispielsweise die Zuordnung eines Wertes zu ei­ ner Variablen sein, während Steuerfluß zum Beispiel eine an eine Bedingung geknüpfte Programmanweisung bedeutet.

Im folgenden wird ein bevorzugtes Ausführungsbeispiel der vorliegenden Erfindung unter Bezugnahme auf das in Fig. 4 ge­ zeigte Flußschema erläutert. Dieses Schema zeigt die Elemente eines Umwandlungsmittels zur Übertragung einer funktionellen Hardwarebeschreibung 40 der höheren Ebene in eine Netzliste (Beschreibung) 41 der niedrigeren Ebene, wodurch die Umwand­ lung automatisch und unabhängig vom Eingreifen eines Anwen­ ders stattfindet. Das Mittel kann entweder als Hardware oder als ein auf einem Datenträger zur Verfügung stehendes Rech­ nerprogramm zur Ausführung in einem digitalen Rechner reali­ siert werden.

In einem ersten Schritt wird daher jede Anweisung 42 der funktionellen Beschreibung 40 der höheren Ebene, zum Beispiel eine Funktion F(x, y), abhängig von den Variablen x und y, syntaktisch analysiert, 43, um Datenfluß- von Steuerflußan­ weisungen zu unterscheiden, 44. Je nach den Ergebnissen die­ ses Parsingvorgangs, 43, wird die betrachtete Anweisung ent­ weder an eine lokale Netzliste, 45, übertragen, die zum Bei­ spiel Bedingungsklauseln oder Eingangsbedingungen enthält, oder an eine globale Tabelle 46, die Zuweisungen und Funkti­ onsaufrufe enthält.

Weiter wird hier darauf hingewiesen, daß in einer auf einem funktionellen Verhalten basierenden Hardware-Beschreibung der Datenfluß bereits bestimmt ist, die Steuerlogik zur Realisie­ rung dieses Datenflusses jedoch im gesamten Entwurf verteilt ist und nicht in ihrer Gesamtheit überprüft werden kann.

Die lokale Netzliste 45 in Fig. 4 enthält die gesamte kombi­ natorische Logik des Entwurfs, einschließlich aller Decoder und datenabhängigen Schalter. Sie liefert außerdem ein stan­ dardisiertes Format für die Datenflußeingänge, um die Erstel­ lung der globalen Netzliste zu unterstützen. Ein Beispiel für diese Art von Anweisungen ist in Fig. 5a zu finden. Das stan­ dardisierte Format funktioniert wie ein Anker und verbindet die globale Netzliste und die lokale Netzliste.

Fig. 4 zeigt weiter außerdem eine exemplarische globale Ta­ belle 47 gemäß dem bevorzugten Ausführungsbeispiel der Erfin­ dung. Die Einträge der globalen Tabelle sind für jede Varia­ ble die jeweiligen Funktionen sowie die jeweiligen Bezugnah­ men auf die lokale Netzliste. Entsprechende Einträge werden auch für die Funktionen selbst bereitgestellt, die in der zu­ grunde liegenden funktionellen Hardwarebeschreibung definiert sind. Für jede Variable wird ein bestimmter Netzlisteneintrag erstellt. Der Netzlisteneintrag stellt den Multiplexer am Eingang der Variablen dar. Typischerweise handelt es sich hier um eine "UND_ODER"-Schaltung (siehe auch Fig. 7). Der "UND"-Teil ist bereits durch das standardisierte Format in der lokalen Netzliste abgedeckt. Der "ODER"-Teil wird jedoch für die globale Netzliste erzeugt (Fig. 5c). Um diese globale Netzliste gemäß der Erfindung zu erstellen, wird eine globale Tabelle bereitgestellt. Diese Tabelle enthält Einträge, wobei jeder Eintrag aus der folgenden Information besteht (Beispiel siehe Fig. 5b):

• a) die Funktion, die bei Erstellung des Eintrags syntak­ tisch zerlegt wurde, zusammen mit einer Bedingungszahl, die sich auf einen Zustand innerhalb dieser Funktion bezieht (diese wird benötigt, um später einen Bezug zu der lokalen Netzliste herzustellen);
• b) außerdem wird der Variablenname gesichert, um die Mög­ lichkeit zu haben, alle Einträge, die sich auf dieselbe Va­ riable beziehen, zu kombinieren; und
• c) ein Zählwerk, um zwischen Einträgen zu unterscheiden, die ansonsten identisch wären.

Zur Illustration zeigen daher die Fig. 5a-c unterschiedli­ che Datenformate, die zur Namensdefinition verwendet werden, exemplarische Einträge für eine Variable X in der globalen Tabelle und entsprechende Netzlisteneinträge für die Varia­ ble X.

Fig. 6 dient zur Darstellung der Umwandlung sequentieller An­ weisungen 60 der funktionellen Hardwarebeschreibung in die Netzlistenanweisungen durch Neuordnung der Anweisungen unter Anwendung einer globalen Tabelle 61. Die globale Tabelle 61 dient als ein Medium, in dem die Information für eine Varia­ ble während des Entwurfs gesammelt wird. Die gesammelte In­ formation kann dann verwendet werden, um die kompletten Netz­ listenanweisungen 62 für die Variable zu erzeugen.

Es wird betont, daß die funktionelle Beschreibung implizit ein oder mehrere Multiplexer enthält, die durch keine Anwei­ sung in der funktionellen Beschreibung wahrnehmbar sind. Dies wird in Fig. 7 dargestellt, die einen Multiplexer 70 mit drei logischen Eingängen 71, 72, 73 und einem logischen Ausgang 74 zeigt. Die entsprechenden Eingänge werden aus der lokalen Netzliste (Tabelle) entnommen und zunächst ge"UND"et. Die be­ treffenden Ergebnisse werden dann ge"ODER"t und diese Ergeb­ nisse werden dann an die globale Netzliste weitergegeben.

Die in Fig. 8 gezeigte funktionelle Situation zeigt weiter, daß niemals alle Funktionen zur gleichen Zeit berechnet wer­ den. Einige Variablen sind "Don't Care"-Variablen und werden somit nicht für eine anstehende Berechnung eingesetzt. Gemäß der Erfindung werden diese Variablen in Halteregister über­ tragen (zum Beispiel die Taktdurchschaltung) und verbrauchen daher keinen Strom, weil die Eingangswerte nicht verändert werden. Mit anderen Worten, die Erfindung ermöglicht den Ent­ wurf der Hardware mit einem Minimum an Verlustleistung.

Im folgenden werden die funktionellen Merkmale eines Umwand­ lungsalgorithmus gemäß der Erfindung gezeigt, geführt durch exemplarische Pseudocodes. Der Entwurf wird damit beschrieben unter Verwendung von Partitionen, die als "BLÖCKE" bezeichnet werden (die Funktionen und Subroutinen entsprechen). Jeder Block ist mit anderen Blöcken entweder durch das Aufrufen von Blöcken oder indem er durch andere Blöcke aufgerufen wird verbunden. Es wird darauf hingewiesen, daß der folgende Ab­ lauf nicht das Mittel zur Umwandlung einer verhaltensbezoge­ nen Sprache in eine Netzliste demonstriert, sondern nur die zugrunde liegenden Konzepte. Es wird auch nicht erklärt, wie Boolesche Ausdrücke umgewandelt werden, da diese Ausdrücke einfach zu übersetzen sind, weil zum Beispiel "UND" und "ODER" in allen Computersprachen dieselben Konstrukte sind.

Für die Übersetzung in eine Netzliste wird zunächst angenom­ men, daß jeder Block einen entsprechenden Eingangszustand hat (M_blockname). Dieser Zustand wird durch den Übersetzungspro­ zeß ohne zusätzliche Information erzeugt. Zum leichteren Ver­ ständnis sind die Namen für dieses Beispiel in einer einfa­ chen Weise zusammengesetzt, nach einer festen Regel, entspre­ chend einem Schema x_y_z:

x = immer ein Schlüsselwort oder Schlüsselzeichen
(E für Ausdruck
C für Zustand (Bedingung)
D für Dateneingang
M für gemultiplexte Daten)

y = Zeilennummer für E- und C-Namen
= relative Position in der globalen Tabelle für D-Namen
= weggelassen für M-Namen

Z = Blockname für E- und C-Namen
= Variable oder Blockname für D- und M-Namen

Übersetzung des Beispiels (Zeile für Zeile)

Initialisiere: (vor dem Start der Blockübersetzung) Erstelle für Netzliste:

C_L0_Block_A = 1

Zeile 1: Übersetze den Booleschen Ausdruck in die Netzliste (Details nicht dargestellt)

E_L1_Block_A = Bool_Expr_1

Generiere Zustand in Netzliste für "if"-Anweisung. Benutze momentan aktiven Zustand vom Stapel (C_L0_Block_A)

C_L1_Block A = C_L0_Block_A and E_L1_Block_A

Neuer aktiver Zustand = C_L1_Block_A
Zeile 2: Boolescher Ausdruck

E_L2_Block_A = Bool_Expr_2

Aktualisiere die globale Tabelle für Variable VAR1 an Position P(X) mit:

VAR1 P(X): Blk = Block_A actState = C1

Generiere Dateneingang für VAR1

D_P(X)_VAR1 = E_L2_Block_A

Zeile 3: "else" setzt den momentanen Aktivzustand zurück nach C_L0_Block_A und verwendet denselben Ausdruck wie "if", jedoch invertiert
C_L3_Block_A = not (Bool_Expr_2)
C_L3_Block_A = C_L0-Block_A and
E_L3_Block_A

Zeile 4: wie Zeile 2
Eingang für Tabelle →
VAR1 P(X+1): Blk = Block_A actState = C3
Eingang für lokale Netzliste →
E_L4_Block A = Bool_Expr_3
D_P(X+1)_VAR1 = E_L4_Block_A

Zeile 5: Ein Funktionsaufruf aktualisiert nur die globale Tabelle, erzeugt aber keine Netzlistenanweisung. Der aktive Zustand am Ende der "if then else"-Klau­ sel ist jetzt C_L0_Block_A

Tabelle →
Block_B P(Y): Blk = Block_A actState = C0
Zeile 6: wie Zeile 1
Netzliste →
E_L6_Block A = Bool_Expr_4
C_L6_Block_A = C_L0_Block_A und E_L6_Block_A

Zeile 7: wie Zeile 5
Eingangstabelle →
Block_C P(Z): Blk = Block_A actState = C6
Zeile 8: wie Zeile 2
Tabelle →
VAR2 P(V): Blk = Block_A actState = C6

Netzliste →
E_L8_Block_A = Bool_Expr_5
D_P(V)_VAR2 = E_L8_Block_A.

Nachdem der Algorithmus für alle Blöcke eines Entwurfs ent­ sprechend verwendet wurde, wurde eine Reihe lokaler Netzli­ stenanweisungen generiert. Die endgültigen Anweisungen werden aus der globalen Tabelle generiert. Die Teilgruppe der globa­ len Tabelle, generiert durch Umwandlung von Block_A für das obige Beispiel, sieht folgendermaßen aus:

Jetzt wird für jedes in Block_A in diesem Beispiel verwendete Element die Netzliste generiert. Jeder Eintrag in der Tabelle ergibt ein Signal für ein Element. Alle Signale werden über eine "ODER"-Anweisung miteinander verknüpft (siehe Fig. 7). Dies stellt den Multiplexer vor den Registern und Netzen dar.

M_VAR1 = (D_P(X)_VAR1 und M_Block_A und C_L1_Block_A) oder (D_P(X+1)_VAR1 und M_Block_A und C_L3_Block_A)

M_VAR2 = (D_P(V)_VAR2 und M_Block_A und C_L6_Block_A)

M_Block_B = (M_Block_A und C_L0_Block_A

M_Block_C = (M_Block_A und C_L6_Block_A).

Die letzten drei Gleichungen enthalten kein "ODER", da sie nur einen Eingang haben.

Claims (13)

1. Ein Verfahren zur funktionellen Beschreibung des Ent­ wurfs digitaler Hardware, gekennzeichnet durch folgende Schritte:
Spezifizieren (10, 40) des Entwurfs nach Funktionen, in Abhängigkeit von den Variablen, wobei die Funktionen Da­ tenfluß- und Steuerflußinformationen enthalten;
syntaktisches Zerlegen (43) der funktionellen Beschrei­ bung, um zwischen Datenfluß- und Steuerflußinformationen zu unterscheiden;
Bereitstellen mindestens einer lokalen Tabelle (45), wo­ bei jeder Eintrag in dieser Tabelle die Steuerflußinfor­ mation enthält;
Bereitstellen einer globalen Tabelle (46), wobei jeder Eintrag in dieser Tabelle die Datenflußinformation und Bezugnahmen auf die lokale(n) Tabelle(n) enthält.

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß der Schritt der Entwurfsspezifikation folgende Schritte umfaßt:
Spezifizieren von Steuerflußobjekten (31, 32) und Daten­ flußobjekten (30) und
Herstellen einer Kommunikation (33) von den Steuerfluß­ objekten zu den Datenflußobjekten.

3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeich­ net, daß der Schritt des Generierens der lokalen Netzli­ ste auf festen Regeln basiert.

4. Verfahren gemäß einem jeden der vorangehenden Ansprüche, dadurch gekennzeichnet, daß die Einträge der globalen Tabelle (46) für jede Variable Funktionen darstellen, sowie entsprechende Bezugnahmen auf die lokale Netzliste (45).

5. Verfahren nach einem jeden der vorangehenden Ansprüche, dadurch gekennzeichnet, daß der Schritt des Spezifizie­ rens des Hardware-Entwurfs weiter folgende Einzel­ schritte umfaßt:
Spezifizieren der Datenflußinformation (30) des Hard­ ware-Entwurfs und Strukturieren dieser Information in Funktionen, und
Einbetten dieser Funktionen in die erforderliche Steuer­ logik (31, 32).

6. Verfahren nach einem jeden der vorangehenden Ansprüche, dadurch gekennzeichnet, daß eine Funktion in Fällen, wo die Funktion mehr als einmal aufgerufen wird, nur einmal ausgeführt wird.

7. Verfahren gemäß einem jeden der vorangehenden Ansprüche, dadurch gekennzeichnet, daß Zustände, die keine erreich­ baren Zustände des Entwurfs sind, in der funktionellen Beschreibung nicht spezifiziert werden.

8. Verfahren nach einem jeden der vorangehenden Ansprüche, dadurch gekennzeichnet, daß nicht relevante Variablen in Halteregister übertragen werden.

9. Ein Verfahren zur Konvertierung einer funktionellen Be­ schreibung eines digitalen Hardware-Entwurfs in eine Netzliste, gekennzeichnet durch das Verfahren zur funk­ tionellen Beschreibung des Entwurfs gemäß einem jeden vorangehenden Anspruch und weiter gekennzeichnet durch folgenden Schritt:
Generieren einer Netzliste (41) aus dem Inhalt der loka­ len Netzliste (45) und der globalen Tabelle (46), wobei jeder Eintrag in dieser Netzliste einer in der globalen Tabelle (46) enthaltenen Variablen entspricht.

10. Verfahren nach einem jeden der vorangehenden Ansprüche, dadurch gekennzeichnet, daß nur Veränderungen des Ent­ wurfs berechnet werden.

11. Verfahren nach einem jeden der vorangehenden Ansprüche, dadurch gekennzeichnet, daß lokale Veränderungen in der funktionellen Spezifikation in entsprechende lokale Ver­ änderungen in der Netzliste umgewandelt werden.

12. Ein Rechnerprogrammprodukt, das auf einem rechnerfähigen Medium gespeichert ist, zur funktionellen Beschreibung des Entwurfs digitaler Hardware, gekennzeichnet durch:
rechnerlesbare Programmittel (10, 40), die bewirken, daß ein Rechner den Entwurf spezifiziert, durch Funktionen, die von Variablen abhängen, wobei die Funktionen Daten­ fluß- und Steuerflußinformationen enthalten;
rechnerlesbares Programmittel (43), das bewirkt, daß der Rechner die funktionelle Beschreibung syntaktisch zer­ legt, um zwischen Datenfluß- und Steuerflußinformationen zu unterscheiden;
rechnerlesbares Programmittel (45), das bewirkt, daß der Rechner mindestens eine lokale Tabelle erzeugt, wobei jeder Eintrag in dieser Tabelle die Steuerflußinforma­ tion enthält;
rechnerlesbares Programmittel (46), das bewirkt, daß der Rechner eine globale Tabelle erzeugt, wobei jeder Ein­ trag in dieser Tabelle die Datenflußinformation und Be­ zugnahmen auf die lokale(n) Tabelle(n) enthält.

13. Ein Rechnerprogrammprodukt, das auf einem rechnerfähigen Medium gespeichert ist, zum Umwandeln einer funktionel­ len Beschreibung eines digitalen Hardware-Entwurfs in eine Netzliste, gekennzeichnet durch:
rechnerlesbare Programmittel (10, 40), die bewirken, daß ein Rechner den Entwurf nach Funktionen spezifiziert, abhängig von Variablen, wobei die Funktionen Datenfluß- und Steuerflußinformationen enthalten;
rechnerlesbares Programmittel (43), das bewirkt, daß der Rechner die funktionelle Beschreibung syntaktisch zer­ legt, um zwischen Datenfluß- und Steuerflußinformationen zu unterscheiden;
rechnerlesbares Programmittel (45), das bewirkt, daß der Rechner mindestens eine lokale Tabelle generiert, wobei jeder Eintrag in dieser Tabelle die Steuerflußinforma­ tion enthält;
rechnerlesbares Programmittel (46), das bewirkt, daß der Rechner eine globale Tabelle erzeugt, wobei jeder Ein­ trag in dieser Tabelle die Datenflußinformation und Be­ zugnahmen auf die lokale(n) Tabelle(n) umfaßt;
rechnerlesbares Programmittel (41), das bewirkt, daß der Rechner eine Netzliste aus dem Inhalt der lokalen Netz­ liste und der globalen Tabelle erzeugt, wobei jeder Ein­ trag in der Netzliste einer Variablen entspricht, die in der globalen Tabelle enthalten ist.