DE69327389T2

DE69327389T2 - Verfahren zum Prüfen von Entwürfen für programmierbare Logikschaltungen

Info

Publication number: DE69327389T2
Application number: DE69327389T
Authority: DE
Inventors: Brent Alan Fairbanks
Original assignee: Altera Corp
Current assignee: Altera Corp
Priority date: 1992-10-29
Filing date: 1993-10-29
Publication date: 2000-06-15
Anticipated expiration: 2013-10-30
Also published as: EP0600608B1; US6182020B1; US7398483B2; US6601221B1; EP0600608A1; US20030182645A1; DE69327389D1

Description

HINTERGRUND DER ERFINDUNG

Die vorliegende Erfindung bezieht sich allgemein auf Werkzeuge für das computerunterstützte Software-Engineering. Genauer: Die vorliegende Erfindung bezieht sich auf ein Softwareimplementiertes Werkzeug für die Unterstützung beim Entwurf von logischen Schaltungen, die miteinander verbundene Schaltungselemente aufweisen, wobei die Erfindung eine Technik zur Überprüfung des Entwurfs eines Benutzers gegen einen Satz von Entwurfsregeln bereitstellt.
Es sind Computerentwurfswerkzeuge bekannt für die Unterstützung eines Schaltungsdesigners beim Strukturentwurf und zum Simulationstesten von logischen Schaltungsanordnungen. Ein derartiges Software-basiertes System ist das unter der Handelsmarke MAX-PLUS verkaufte System, das von der Altera Corporation, San Jose, Kalifornien erhältlich ist. Typischerweise verwendet der Designer ein derartiges System zum anfänglichen Entwerfen und nachfolgenden Testen der Funktionsweise des Entwurfs unter Verwendung von Computersimulationstechniken. Es wird auf Fig. 1 Bezug genommen. Eine typische Computerlogiksimulationstechnik verfährt derart, daß anfänglich ein Logikentwurf in der Form eines Schemas oder einer Netzliste in einer Datei 10 gespeichert wird und die Netzliste mittels eines Logikcompilers 12 in eine Simulator-Logik-Netzliste 14 gewandelt wird, die durch den Logiksimulator 15 verwendet wird. Im Gebrauch wird ferner ein Satz von Simulations-Eingabevektoren 16 dem Logiksimulator bereitgestellt, der die Simulator-Logik-Netzliste zusammen mit den Simulator-Eingabevektoren liest und die Funktionsweise des Logikentwurfs "simuliert", indem Logikpegel durch die Logik-Grundelemente fortgepflanzt werden, um einen Satz von Ausgabevektoren 18 zu erzeugen, die die simulierten Ausgaben des Logikentwurfs sind. Es wurde gefunden, daß dieser Prozeß im Bereich des Logikentwurfs außerordentlich nützlich ist, insbesondere für komplexe Schaltungen, die für die körperliche Implementierung in löschbaren programmierbaren Logikbausteinen (EPLDs) und maskenprogrammierbaren Logikbausteinen (MPLDs) bestimmt sind. Mit der umfangreichen Anwendung von Schaltungen bestand in jüngerer Zeit der Trend, entweder die Logikschaltungsanordnung im Hinblick auf die MPLD- Implementation zu entwerfen oder einen für die Implementation in EPLD- Form bestimmten ursprünglichen Entwurf zu einem funktionell identischen Entwurf umzuwandeln, der für die Implementation in einer MPLD-Form bestimmt ist. Typischerweise muß ein gegebener Entwurf eines Benutzers einem Satz von Entwurfsregeln genügen, die zulässige und unzulässige strukturelle und funktionelle Konfigurationen regeln, damit der Entwurf nützlich und zuverlässig ist. Ein Versäumnis, einer oder einigen der Entwurfsregeln zu genügen, kann - obwohl nicht zwingenden tödlich für die Funktionsweise einer Schaltung - funktionsmäßige Unsicherheiten unter speziellen Bedingungen einführen, manchmal mit einem kumulativen Effekt, der zu einem teilweise nicht funktionsfähigen oder - in Extremfällen - vollkommen unfunktionsfähigen Schaltungsentwurf führt. Wenn auch der Logiksimulationsprozeß dafür bestimmt ist, fehlerhafte oder nicht konsistente Reaktionen auf eine Stimulation durch die Test-Eingabevektoren offenzulegen, wird ein derartiges Ergebnis nur nach einer häufig länglichen und Zeit verbrauchenden Simulation des ursprünglichen Entwurfs erhalten.
Die 1988-IEEE International Conference on Computer Design: VLSI in Computers and Processors (1988), Seiten 324-327, Spickelmier et al. offenbart ein Verfahren zum kritischen Untersuchen von Schaltungsentwürfen unter Verwendung eines wissenbasierten Programms, das Fehler oder einen schlechten Entwurfsstil in Schaltungsentwürfen sucht. Die Wissenbasis besteht aus Prozeß- und Entwurfsstilkonstanten, einem Satz von unzulässigen Beschreibungen, einem Satz von strukturellen Beschreibungen und Fehlerüberprüfungsregeln. Information in der Wissenbasis wird dazu verwendet, Strukturen und Fehler in der Schaltung zu finden. Zum Finden von Schaltungsstrukturen verwendet das Programm ein regelbasiertes Muster- oder prozedurales Abgleichsystem. Jene Strukturen, die in der Datenbasis gefunden wurden, werden dann auf Fehler überprüft.

ÜBERSICHT DER ERFINDUNG

Gemäß der vorliegenden Erfindung wird bereitgestellt ein Verfahren des Verifizierens, ob ein anfänglicher Logikentwurf einem Benutzer gewählten Satz von Entwurfsregeln aus einem vorexistierenden Satz von Entwurfsregeln genügt, der erlaubte und verbotene strukturelle und funktionale Logikvorrichtungsbeziehungen ausdrückt, in einem Computer-unterstützten Logikentwurfssystem zum Entwerfen und Testen logischer Schaltungen vor einer körperlichen Implementation, wobei das Verfahren die Schritte umfasst: (a) Unterbreiten von Wahlmöglichkeiten einem Benutzer, die den gesamten vorexistierenden Satz von Entwurfsregeln, einen vorbestimmten Untersatz des vorexistierenden Satzes von Entwurfsregeln und einen individuell anpassbaren Untersatz des vorexistierenden Satzes von Entwurfsregeln, der durch den Benutzer anzupassen ist, enthalten, wobei der vorbestimmte Untersatz von Entwurfsregeln auf programmierbare Logikvorrichtungen anwendbar ist; (b) Akzeptieren einer Wahl des Benutzers aus den unterbreiteten Wahlmöglichkeiten, die hierdurch den Benutzergewählten Satz von Entwurfsregeln etabliert; (c) Bereitstellen einer Logikentwurfsdatei, die den anfänglichen Logikentwurf in Computer-lesbarer Form enthält; (d) Ausführen des Benutzer gewählten Satzes von Entwurfsregeln, um wenigstens Teile des anfänglichen Logikentwurfs zu überprüfen; und (e) Bereitstellen einer vom Benutzer wahrnehmbaren Anzeige jeglicher Verletzung des Benutzer gewählten Satzes von Entwurfsregeln durch den anfänglichen Logikentwurf.
Die vorliegende Erfindung stellt somit eine Technik zur Überprüfung des anfänglichen Entwurfs eines Benutzers gegen einen benutzergewählten Satz von Entwurfsregeln bereit, um mögliche Probleme bei einem ursprünglichen Entwurf aufzudecken, die eine unzuverlässige Schaltung ergeben könnten, sei sie in EPLD- oder MPLD-Form implementiert.
Das bevorzugte Verfahren enthält den Schritt, daß einem Benutzer ermöglicht wird, den Grad der Entwurfsregelbefolgung aus einer Hierarchie derartiger Grade zu wählen. Ferner enthält das Verfahren den Schritt des Bereitstellens einer benutzerwählbaren Liste von optionalen Regel-Wahlmöglichkeiten. Es werden somit alle Regeln im Satz oder nur ausgewählte der Regeln im Satz dazu verwendet, den anfänglichen Logikentwurf auf Entwurfsregelbefolgung zu überprüfen, wobei der Grad der Befolgung ebenfalls durch den Benutzer wählbar ist.
Sowohl die Hierarchie von Graden der Entwurfsregelbefolgung als auch die benutzerwählbare Liste von optionalen Regel-Wahlmöglichkeiten werden dem Benutzer bevorzugt sichtbar angezeigt, um bei der Auswahl von Wahlmöglichkeiten zu helfen.
Das bevorzugte Verfahren sorgt ferner für einen zusätzlichen Vergleich wenigstens einiger der Entwurfsregeln mit einer synthetisierten Version des anfänglichen Logikentwurfs in jenen Fällen, in denen der anfängliche Entwurf einer Logiksynthese unterworfen wird. Diese Fähigkeit ist vor gesehen, um auf Entwurfsregelverletzungen zu überprüfen, die möglicherweise durch den Prozeß der Logiksynthese eingeführt werden.
Die Erfindung stellt eine zweckdienliche und effektive Technik bereit zum Verifizieren, ob ein anfänglicher Logikentwurf den Satz von Entwurfsregeln befolgt, der auf den Typ von programmierbarem Baustein anwendbar ist, der zur Implementierung des Entwurfs dient. Ausführungsformen der Erfindung können somit in Verbindung mit ELPD- und MLPD-Implementationen verwendet werden. Ferner können Ausführungsformen der Erfindung leicht erweitert werden, um Änderungen an einem existierenden Satz von Entwurfsregeln einzubeziehen oder neue Entwurfsregeln zu implementieren, die im computerunterstützten Logikentwurfsprozeß als nötig oder wünschenswert gefunden werden.
Es werden nun Beispiele von Ausführungsformen der vorliegenden Erfindung mit Bezugnahme auf die Zeichnungen beschrieben, in denen:
Fig. 1 ein schematisches Diagramm ist, das ein Computer-Logik- Simulationssystem des Stands der Technik veranschaulicht;
Fig. 2 eine Veranschaulichung von Computerhardware ist, die für die Implementierung der vorliegenden Erfindung geeignet ist;
Fig. 3 ein Blockdiagramm eines Systems für die Implementierung der vorliegenden Erfindung unter Verwendung der in Fig. 2 gezeigten Computerhardware ist;
Fig. 4 eine Erst-Benutzerschnittstelle in der bevorzugten Ausführungsform der Erfindung veranschaulicht; und
Fig. 5 eine Zweit-Benutzerschnittstelle in der bevorzugten Ausführungsform der Erfindung veranschaulicht;
Fig. 6 ein schematisches Diagramm ist, das das Verfahren der vorliegenden Erfindung veranschaulicht.

BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORM

Fig. 2 ist eine Darstellung von Computerhardware, die für die Implementierung der vorliegenden Erfindung geeignet ist. Wie in dieser Figur zu sehen, umfaßt ein Computersystem 31 einen Monitor 33, einen Anzeigeschirm 35, ein Gehäuse 37, eine Tastatur 39 und eine Maus 41. Die Maus 41 kann einen oder mehrere Mausknöpfe, wie etwa Knöpfe 43, aufweisen. Das Gehäuse 37 umschließt typische Computerkomponenten, wie etwa ein Prozessor, Speicher, Plattenlaufwerke und Peripherieschnittstellenadapter (nicht gezeigt). Fig. 2 ist eine Repräsentation nur eines von vielen Typen von Computersystemen, die für die Ausführung der vorliegenden Erfindung geeignet sind. Andere für den Gebrauch bei der vorliegenden Erfindung geeignete Typen von Computersystemen umfassen sogenannte "Notebook"-, "Palmtop"- oder "Hand-Held"-, "Pentop"- usw. Computer. Ferner wird die Verwendung des Begriffes "Maus" oder "Benutzereingabevorrichtung" so verstanden, daß dieser Begriff andere Mittel für die Eingabe von Information in einen Computer umfaßt, wie etwa ein Berührungsschirm, ein Trackball, eine MIDI-Tastatur, einen Lichtstift, einen Datenhandschuh usw. Wie Fachleuten im Fachgebiet sofort ersichtlich sein wird, sind viele Typen von Computerhardware und Hardwarekonfigurationen für die Verwendung im Zusammenhang mit der vorliegenden Erfindung geeignet.
Fig. 3 veranschaulicht ein System 50 zum Implementieren der Erfindung unter Verwendung der in Fig. 2 gezeigten Computerhardware. Wie in dieser Figur zu sehen, enthält das System 50 ein Computersystem 51, das mit einer relativen Zeigevorrichtung (RPD) 53 gekoppelt ist, beispielsweise ein Trackball oder eine Maus. Das Computersystem 50 enthält einen Zentralprozessor 55, einen Systemspeicher 56, eine Eingabevorrichtung, wie etwa eine Tastatur 39, eine Festplatte 58, einen Monitor 33, eine externe Schnittstelle 51, einen Drucker 62, einen Eingabe/Ausgabe-(I/O)- Controller 53, einen Kommunikationsport 64 und einen Anzeigeadapter 65. Ein Systembus 67 verbindet die Komponenten des Computersystems 50 miteinander, wodurch eine Verbindung zwischen diesen bereitgestellt wird. Die Tastatur 57 und die RPD 53 sind individuell oder gemeinsam Dateneingabevorrichtungen, mit denen ein Benutzer des Computersystems 51 mit dem Entwurfsüberprüfungssystem interagieren kann.
Eine bevorzugte Ausführungsform verwendet einen angemessen programmierten IBM-kompatiblen Personalcomputer (PC), der unter dem MS-DOS- Betriebssystem unter Verwendung von Windows 3.x als eine Benutzeroberfläche läuft. Es versteht sich, daß andere Plattformen zur Verfügung stehen und die Erfindung in anderen Formen ausführen können. Die Erfindung ist nicht auf Ausführungsformen beschränkt, die Computer vom PC-Typ enthalten, sondern kann andere Plattformen enthalten, wie etwa Apple- Macintosh®-Computer (Apple Computer, Cupertino, Kalifornien) oder Sun- SparcStations, als Beispiel. Die Entwurfsüberprüfungserfindung wird durch den Zentralprozessor 55 unter angemessener Prozeßsteuerung und Instruierung durch Prozeduren implementiert, die im Systemspeicher 56 gespeichert sind und als Teil des Systems 50 bereitgestellt sind.
Nachdem ein Benutzer den Ursprungsentwurf erzeugt und ihn in eine geeignete Form für die Logikentwurfsdatei (wie etwa eine Netzliste) gebracht hat, wird dieser Entwurf gegen einen vorgewählten Satz von Entwurfsregeln überprüft.
Die Erfindung überprüft somit Benutzerentwürfe auf Fehler, die Zuverlässigkeitsprobleme verursachen können, wenn die Schaltungsanordnung in Silizium implementiert wird. Dieses Werkzeug wendet einen Satz von Regeln an, wie unten spezifiziert, um im Entwurf des Benutzers nach verschiedenen Strukturen zu suchen, die dahingehend bestimmt wurden, daß sie Probleme verursachen. Wenn eine bestimmte Struktur gefunden wird, wird der Benutzer alarmiert und kann die Struktur in den Entwurfsdateien finden. Eine Ausführungsform der Erfindung kann als Teil des MAX+plus-II-Compilers ablaufen und wird durch eine Optionen-Dialogbox gesteuert. Es sind verschiedene vordefinierte Sätze von Entwurfsregeln zusammen mit einem benutzerspezifizierten Regelsatz wählbar.
Die Hauptmotivation für die Befolgung von Regeln ist eine funktionelle MPLD-Implementation des Entwurfs eines Benutzers. Allerdings kann angenommen werden, daß dann, wenn ein Entwurf die durch die MPLD- Konversion motivierten Regeln befolgt, eine EPLD-Implementation ebenfalls zuverlässig sein wird. Die Erfindung ist somit nützlich für die Überprüfung von sowohl EPLD-implementierbaren Entwürfen als auch von MPLD-implementierbaren Entwürfen.

Benutzerschnittstelle

Die vorliegende Ausführungsform tritt als benutzerwählbare Compileroption auf. Insbesondere wird, wenn aus dem Menü ausgewählt, ein einem Doktor ähnelndes Icon unterhalb des Logiksynthesemoduls angezeigt. Während der Kompilierung wird diese Ausführungsform an drei Stellen ausgeführt: nach einer Netzliste-Extraktion, nach einer Logiksynthese und nach einer simulierten Netzliste-(SNF)-Extraktion. An jedem Punkt wird eine andere Teilmenge von Regeln ausgeführt. Beispielsweise werden illegale Taktstrukturen nach der Netzliste-Extraktion erfaßt, während statische Gefahren sowohl in den Vor- und Nach-Synthese-Netzlisten nach Durchführung der Logiksynthese erfaßt werden.
Eine Ausführungsform der Erfindung wird durch einen Optionen-Menüpunkt gesteuert. Dieser Punkt öffnet eine in Fig. 4 gezeigte Dialogbox, die den Typ von anzuwendenden Entwurfsregeln steuert und die Benutzereinstellung des Regelsatzes ermöglicht.
Wenn diese Ausführungsform durch die Benutzer auf den "MPLD-Regeln"- Grad (siehe Fig. 4) gesetzt wird, werden alle Regeln ausgeführt, wie unten beschrieben. Dieser Grad ist der am meisten zeitverbrauchende und kann eine Anzahl von falschen Warnungen erzeugen. Eine Überprüfung auf diesem Grad ist für jeden Entwurf erforderlich, der einer MPLD-Umwandlung zugeführt wird. Um die Anzahl von Warnungen zu reduzieren und für die Geschwindigkeit der Verarbeitung eines Entwurfs sind drei andere Optionen vorgesehen. Der "FLEX"- und "EPLD"-Grad hindern diverse Regeln an einer Ausführung oder beschränken die Strukturen, vor denen eine Regel warnen wird. Schließlich ist ein vollständig benutzerwählbarer Warnsatz vorgesehen, der durch eine Dialogbox gesteuert wird, die durch Wählen des Fortgeschrittene Optionen -Knopfes verfügbar ist (siehe Fig. 5).
Mit der Fortgeschrittene Optionen -Dialogbox kann der Benutzer wahlweise jede Regel freigeben oder sperren, die diese Ausführungsform der Erfindung ausführt. Das Setzen jeder der Regeln in der Benutzerkonfiguration und der gegenwärtige Regelgrad wird in der Projektinitialisierungsdatei gesichert. Die Vorgabe für ein neues Projekt ist der "FLEX"-Warngrad, wobei die Regeln, die diesen Grad bilden, in der Fortgeschrittene Optionen -Dialogbox gewählt sind.

Entwurfsregeln

Eine bevorzugte Ausführungsform testet den folgenden Satz von Entwurfsregeln. Jede dieser Regeln wird durch eine Kontrollbox in der Benutzerauswahl-Dialogbox gesteuert (siehe Fig. 5). Wenn eine aggressive ("MPLD") Überprüfung gewählt ist, wird jede Regel angewendet, und es werden dann, wenn niedrigere oder benutzergewählte Grade verwendet werden, diverse Regeln angewendet, wie unten vermerkt. Wenn eine Entwurfsregelverletzung erfaßt wird, wird dem Benutzer über die Anzeige eine Warnung ausgegeben. In der bevorzugten Ausführungsform ist jede Warnung von der Form: "Entwurfsdoktorwarnung:" gefolgt durch eine Beschreibung der Verletzung. Falls gewünscht, kann der Benutzer zur Anzeige jene Abschnitte der Logikschaltungsanordnung des ursprünglichen Entwurfes zur Anzeige aufrufen, die für die Warnung einschlägig sind.

Taktschemata

Das wichtigste System in einem synchronen Entwurf ist das Takten von Registern. Die bevorzugte Taktkonstruktion für eine MPLD-Implementation ist ein globales Takten, bei dem ein einziger Stift als Taktquelle für alle Register in einer Konstruktion dient. Dieser Ansatz wie auch durch einen einzigen Stift getriebene Taktgeber werden durch die bevorzugte Ausführungsform akzeptiert. Alle anderen Ansätze werden eine Warnung erzeugen.
Diese Regeln werden in allen Warngraden vor der Logiksynthese ausgeführt.

Rippletakte

Ein Rippletakt existiert, wenn die Ausgabe eines Registers den Takt eines anderen Registers speist. Dies ist für sich selbst nicht wirklich gefährlich, wird aber in allen Graden eine Warnung erzeugen. Wenn allerdings die Ausgabe eines oder mehrerer Flip-Flops in einer Kette in eine kombinatorische Logik gespeist wird (beispielsweise ein Dekodierer), wird eine Warnung ausgegeben, daß eine Störimpulssituation vorliegen könnte.

Verknüpfte Takte

Falls der Takt eines Flip-Flops durch eine kombinatorische Logik gespeist wird, müssen maximal zwei Gatter zwischen dem Taktgeber und jedem der den Taktgeber speisenden Eingangsstifte existieren. In jedem Pfad dürfen nur UND-, ODER-, NAND-, NOR- und NICHT-Gatter vorliegen, Ferner sollten nur insgesamt zwei UND/ODER- (NAND/NOR-)Gatter vorliegen. Jede Abweichung von diesem Muster wird eine Warnung erzeugen. Ferner, wenn zwei oder mehr Register einen Taktgeber durch Logik speisen, dann wird eine Warnung ausgegeben, da nicht gewährleistet werden kann, daß die Register zum gleichen Zeitpunkt sich ändern werden und daß die Verzögerungspfade zum Taktgeber die gleiche Länge aufweisen werden.

Mehrfachniveau-Takte

Alle anderen Taktschemata werden unter die allgemeine Überschrift von Mehrfachniveau-Takten fallen. Wenn ein derartiges Taktschema erfaßt wird, wird dem Benutzer eine beratende Warnung ausgegeben, in der Art einer Anweisung, detaillierte Referenzquellen betreffend mehr Information zu konsultieren.

Mehrfachtaktnetze

Diese Regel testet, um zu bestimmen, ob ein synchrones Gerät, das auf einen Takt synchronisiert ist, Daten empfängt, die auf einen anderen Takt synchronisiert sind. Sofern nicht das Gerät ein Synchronisierregister ist, das eine einzige Eingabe von der anderen Taktgruppe aufweist, wird eine Warnung ausgegeben, daß dies eine Entwurfsverletzung ist.

Vorgabe- und Lösch-Konfigurationen

Die in den vorangehenden Abschnitten aufgeführten Regeln werden ferner auf die Vorgabe- und Löschsignale eines Flip-Flops angewendet. Diese Signale sollten idealerweise durch Eingangsstifte angesteuert werden. Hiervon abgesehen, sollten sie aber nicht durch mehr als zwei Logikniveaus angesteuert werden. Jegliche Kombination von Mehrfach-Flip-Flops oder Flip-Flops mit Eingabestiften werden eine Warnung erzeugen.

Statische und Dynamische Gefahren

Eine statische Gefahr tritt dann auf, wenn eine Eingabe Logikpegel ändert und verursacht, daß eine Ausgabe momentan den Pegel ändert oder einen Störimpuls verursacht. Dies tritt deswegen auf, weil der neue Satz von Eingabevektoren auf eine andere Hülle auf dem Karnaugh-Plan der Funktion abgebildet wird als der ursprüngliche Satz. Wenn beide Sätze von Eingabevektoren auf die gleiche Hülle auf dem Karnaugh-Plan abgebildet werden, existiert dann keine statische Gefahr. Eine dynamische Gefahr tritt auf, wenn eine Ausgabe den Zustand ändern sollte, tatsächlich aber sich dreimal ändert anstelle von nur einmal. Dies impliziert, daß wenigstens drei Pfade durch die interessierende Funktion vorliegen.
Es gibt zwei mögliche Quellen von Gefahren in einem für eine EPLD kompilierten Entwurf. Im ersten Fall kann der Entwurf des Benutzers vielfältige Gefahren enthalten. Im anderen Fall, kann die Logiksynthese Gefahren in den Entwurf einführen. Um auf beide mögliche Quellen von Gefahren zu testen, führt die Erfindung diese Regel sowohl vor als auch nach dem Logiksynthesemodul aus. Falls der Benutzer nur nach Fehlern in seinem Ursprungsentwurf sucht, wird diese Regel vor der Logiksynthese laufen. Falls der Benutzer nach Fehlern in beiden Fällen sucht, wird diese Regel nach der Logiksynthese laufen, wo sie den Vor-Synthese-Entwurf und den Nach-Synthese-Entwurf beide untersuchen kann. Falls der Benutzer nur nach Fehlern aus der Synthese sucht, werden beide Entwürfe nach der Ausführung der Logiksynthese analysiert, und Fehler aus dem ursprünglichen Entwurf werden nicht berichtet.
Da Fehler nicht wirklich wichtig sind, wenn sie nur die Dateneingabe eines Flip-Flops betreffen, überprüft die bevorzugte Ausführungsform derartige Logik nicht. Sie überprüft Logik, die alle Steuerstifte eines Flip-Flops speist, sowie auch jegliche rein kombinatorischen Netze. Diese Regel wird im "FLEX"- und "MLPD"-Grad für das Nach-Synthese-Netz und in allen Graden für das Vor-Synthese-Netz ausgeführt.

Latchen Asynchroner Eingaben

Um Initialisierungs- und Halteprobleme bei asynchronen Eingaben zu vermeiden, überprüft die Regel alle Eingabestifte, um zu sehen, ob diese mit dem Takt jeglichen synchronen Geräts, das sie speisen, gelatcht sind oder nicht. Die Theorie hierzu ist, daß eine asynchrone Eingabe maximal zu einem synchronen Gerät verzweigen sollte, das als das Synchronisierlatch betrachtet werden würde. Eine Eingabe, die nur ein rein kombinatorisches Netz speist, wird dieser Regel nicht unterworfen, sofern nicht das Netz die Datenleitung eines Flip-Flops speist.

Wettlaufsituationen

Die Erfindung sucht nach gewissen Typen von kritischen Wettläufen, wenn diese Regel gewählt ist. Sie wird nicht die Fähigkeit haben, nach einem Wettlauf des üblichen zwei- oder mehr-Eingaben-Schalten-auf einmal-Typs zu suchen, da die Anzahl von zwei- oder mehr-Eingaben-Netzen in einem großen Entwurf riesengroß ist. Die bevorzugte Ausführungsform erfaßt die Verwendung eines Flip-Flops, das hinsichtlich seiner Aufgabe von gewisser anderer Steuerlogik abhängt. Ein gutes Beispiel hierfür ist ein Pulsgenerator, in dem ein Signal VCC in einen DFF taktet, und Q durch ein NICHT- Gatter den CLRN speist. Diese Konfiguration würde einen Puls ungewisser Breite erzeugen. Diese Regel sucht deshalb nach Flip-Flops, die für eines ihrer Steuersignale, nämlich CLK, CLRN, PRN oder ENA, von ihrer Ausgabe abhängen.

Verzögerungsketten und Asynchrone Pulsgeneratoren

Diese Regel überprüft den Ursprungsentwurf nach Ketten aus dem Benutzer zur Verfügung stehenden Grundelementen, wie etwa Expander, MCELLs oder SOFTs im Altera-System. Sie sucht nach Fällen, in denen eines der gegebenen Grundelemente eine einzige Ausgangsfächerung zu einem anderen der Grundelemente aufweist, mit einiger hinzugefügter Vorausschau. Beispielsweise wird b = mcell(mcell(a)) gefunden, während b = soft(exp(a)) nicht gefunden wird. Die Vorausschau wird verwendet, um auf Strukturen der Form b = mcell(exp(mcell(exp(a)))) zu testen. Diese Strukturen erzeugen in allen Graden eine Warnung, da sie ein Vertrauen auf eine feste Verzögerung anzeigen, und diese kann über Gerätegeschwindigkeit, Gatter, Fabrikationsunterschiede, Temperatur usw. nicht garantiert werden.

Kreuzgekoppelte Expander

Als im Grunde zu vermeidende Strukturen werden kreuzgekoppelte Expander stets die Erzeugung einer Warnung verursachen, wenn diese gefunden werden. Der Typ der Warnung wird durch Lesen des Entwurfs des Benutzers bestimmt und durch Suchen nach einem EXPDFF-, EXPLATCH-, NORLATCH- oder NANDLATCH-Grundelement. Falls eine dieser Makrofunktionen gefunden wird, wird dann im "FLEX"- und "MPLD"-Grad eine milde Warnung ausgegeben. Falls Benutzer-erzeugte kreuzgekoppelte Expander gefunden werden, wird in allen Graden eine strenge Warnung ausgegeben.

Verwendung einer Haupt-Rücksetzung

Wenn ein Entwurf von einem EPLD zu einem MPLD umgewandelt wird, verlieren Zustandsmaschinen und andere Registerlogik die Voraussetzung der Anschalt-Rücksetzung. Ein zu wandelnder Entwurf muß deshalb einen Hauptrücksetzungsstift aufweisen, der alle Flip-Flops löscht und durch ein Signal auf Platinenniveau ansteuert werden würde. Die Regel versucht, aus allen Registern einen gemeinsamen Rücksetzstift zu isolieren, selbst wenn kombinatorische Logik auf einigen der Leitungen vorgesehen ist (beispielsweise aktiv-low LLW LLCLR = /Rücksetzen &...).
Diese Regel wird nur im "MPLD"-Grad aktiv sein, da sie nur für die Überprüfung einer Umwandlung zu einer MPLD nützlich ist. Sie wird entweder aus dem Ursprungsentwurf des Benutzers oder aus dem SNF ausgeführt.

Steckengebliebene Zustände

Ein Entwurf kann einen Satz von Flip-Flops enthalten, die effektiv als eine Zustandsmaschine wirken, die steckengebliebene Zustände enthalten kann. Die bevorzugte Ausführungsform wird versuchen, Gruppen von Flip-Flops zu isolieren, die als Zustandsmaschine wirken, selbst wenn sie nicht explizit als eine Zustandsmaschine deklariert sind. Falls sie derartige Gruppen findet, analsiert sie die Zustandsübergänge der Maschine und sucht nach sich gegenseitig ausschließenden Gruppen von Zuständen. Mit anderen Worten sollte eine Zustandsmaschine keine Zustände aufweisen, die nicht zum Grundzustand zurückkehren können. (Beispielsweise indizieren A-B-'C-'A und D-E-F-D, daß eine der beiden Gruppen steckengeblieben ist.) Da diese Regel sehr viel Zeit brauchen könnte, wird sie nur im "MPLD"-Grad ausgeführt.

Verschiedene Ausgabeverzögerungen innerhalb einer Gruppe

Wenn die bevorzugte Ausführungsform eine Ausgabegruppe findet, überprüft diese Regel den Takt auf Ausgabeverzögerungen jedes Mitglieds der Gruppe. Falls die Verzögerungen nicht identisch sind, weist dies auf mögliche Außer-Chip-Störimpulse hin. Diese aus dem SNF arbeitende Regel ist sowohl im "FLEX"- als auch im "MPLD"-Grad aktiviert.

Detaillierte Diskussion

Das folgende ist eine detaillierte Diskussion der zur Überprüfung eines Entwurfs eines Benutzers verwendeten Algorithmen. Jeder der verschiedenen Algorithmen wird zuerst diskutiert und dann aufgeführt. Falls ein Algorithmus von der Ausgabe oder von Datenstruktur eines anderen Algorithmus abhängt, wird dies in der Diskussion vermerkt. Der Beschreibung der Algorithmen folgt eine Diskussion der Datenstrukturen, die in der Erfindung verwendet werden. Jeder Definition folgt eine kurze Beschreibung jeder Datenstruktur. Schließlich wird der Eingangspunkt vom Compiler beschrieben. Dieser dient als die letzte Authorität darüber, wann eine bestimmte Entwurfsregel ausgeführt wird.

Taktanalyse

Diese Routine versucht, Taktstrukturen zu isolieren und berichtet dem Benutzer, wenn eine Struktur gefunden wird, die die momentan gewählten Entwurfsregeln verletzt. Die Analyse der Taktstrukturen besteht aus zwei Teilen. Als erstes isoliert die Routine drc_mark_clock-groups() Gruppen von synchronen Geräten, die die gleiche Taktlogik teilen, sei es ein Eingabestift, eine Gleichung oder ein anderes synchrones Gerät. Mit den isolierten Taktgruppen kombiniert dann die Routine drc_reduce_ripple_clocks() Taktgruppen, die Teile einer Rippletaktkette sind. Diese sind von der Form C. CLK = B. Q., B. CLK = A. Q. usw. Schließlich werden die Gleichungen oder Stifte analysiert, die eine Taktgruppe ansteuern, und es werden Warnungen auf Grundlage der momentan gewählten Regeln ausgegeben. Die Taktgruppen werden für die Verwendung durch drc_check_asynch signals() gesichert (siehe unten unter der Überschrift Asynchrone Eingabestifte).
Die erste Stufe der Taktanalyse besteht aus dem Zusammenfassen aller synchronen. Geräte in Taktgruppen, die durch die Compilerdatenbasis-ID des Stiftes, Flip-Flops oder Gatters, welcher/welches die Geräte speist, identifiziert werden. Wenn die Gruppen-ID für ein Gerät bestimmt wurde, wird die Gruppe aus der Liste bekannter Gruppen gefunden werden. Falls die Gruppe nicht existiert, wird eine neue Gruppe erzeugt und in die Liste von Gruppen eingefügt. Die Gerät-ID wird dann zu einer verketteten Liste aller synchronen Geräte in der Gruppe hinzugefügt, die zur Überprüfung von asynchronen Signalen und für den Fehlerbericht verwendet wird.
Die zweite und die dritte Stufe der Taktanalyse bringen das Reduzieren von Ripple-getakteten Gruppen und die Analyse der durch drc_mark_clock_groups() bestimmten Taktgruppen mit sich. Da bei einer Ripple-Taktgruppe jedes Element durch ein anderes Signal getrieben wird, nämlich die Ausgabe des vorangehenden Elements, wird jedes Element seine eigene Taktgruppe bilden. Da ferner die Datensätze für die Gruppe in der Datenbasis in beliebiger Reihenfolge auftreten könnten, können die Gruppen während des ersten Durchgangs nicht kombiniert werden. Die Routine drc_reduce_ripple_clocks() sucht deshalb durch die Liste von Taktgruppen und sucht nach Rippleketten. Sie kondensiert diese Ketten in eine einzige Taktgruppe mit der Gruppen-ID von dem ersten Gerät in der Kette.
Nachdem alle der Taktgruppen identifiziert und reduziert wurden, wird die Hauptanalyse gestartet. Diese sieht nach der Logik, die jede Taktgruppe treibt, und vergleicht sie mit bekannten zulässigen und unzulässigen Strukturen. Der Bericht von Warnungen wird variieren in der Abhängigkeit von den durch den Benutzer gewählten Entwurfsregeln. Wenn beispielsweise der Benutzer die Rippletaktentwurfsregel gewählt hat, werden jegliche Ripplegruppen, die im Entwurf gefunden wurden, berichtet werden. Allerdings wird die Ripplegruppe ungeachtet dessen, ob diese Regel gewählt ist, überprüft werden, um zu sehen, ob sie irgendeine Logik speist, wie auch ein Ripplezähler würde. Dies wird stets eine Warnung erzeugen.
Nach dem Rippletakten wird die Taktgruppe überprüft, um zu sehen, ob sie durch einen Eingabestift angesteuert wird. Falls dies nicht der Fall ist, wird die Logik, die diese Gruppe treibt, in eine von drei Kategorien fallen. Die erste ist eine logische Kombination von Registerausgaben und möglichen Eingangsstiften. Für diesen Fall muß wenigstens ein Register und ein Stift existieren, da ein einzelnes Register in eine Ripple-Gruppe fallen würde, oder zwei oder mehr Register mit keinem oder mehreren Stiften. In beiden Fällen wird betreffend Register-Taktleitungen eine Warnung ausgegeben, falls der Benutzer die Gattertaktüberprüfung eingeschaltet hat.
Der zweite Fall tritt auf, wenn der Takt eine logische Funktion von Eingabestiften ist. Alle einzelnen Stifttaktgruppen werden hier verwendet, um zu bestimmen, ob die Gleichung eine andere bekannte Taktleitung einbezieht. Es wird eine Warnung erzeugt, wenn die Logik komplizierter als zwei Gatter in einer UND-UND-, ODER-ODER- oder ähnlichen Konfiguration ist. Ferner sollte, wenn ein einzelner bekannter Stifttakt in der Gleichung verwendet wird, die andere Logik wie ein Freigabesignal aussehen. Falls dies der Fall ist, wird der Erfinder vorschlagen, daß der Benutzer eine freigebene DFF verwendet. Andernfalls wird eine Warnung ausgegeben.
Der letzte Fall involviert Mehrfach-Pegel-Logik und andere Strukturen, die diese Ausführungsform nicht analysieren kann. In einem solchen Fall wird eine Warnung ausgegeben, daß die Taktlogik zu kompliziert ist und nicht analysiert werden kann.

Vorgabe- und Löschkonfigurationen

Die Analyse, die für Taktschemata durchgeführt wird, wird für Vorgabe- und Löschlogik wiederholt. Der Hauptunterschied ist, daß ein Entwurf einen Hauptrücksetzstift aufweisen sollte, falls er dafür bestimmt ist, zu einer MPLD gewandelt zu werden. Der Entwurfsdoktor wird deshalb versuchen, einen Hauptrücksetzstift zu isolieren, wenn er die Liste von Rücksetzgruppen bildet. Falls eine Hauptrücksetzung tatsächlich gefunden wird, werden dann die Logiktests an den Rücksetzleitungen modifiziert, um nach einfachen, diese Hauptrücksetzung einbeziehenden Funktionen zu suchen.

Statische und Dynamische Gefahren

"Wenn in Antwort auf eine Eingabeänderung und für eine gewisse Kombination von Stufenverzögerungen eine Netzausgabe momentan auf 0 gehen könnte, wenn sie eine konstante 1 bleiben sollte, sagen wir, daß das Netz eine statische-1-Gefahr aufweist. In ähnlicher Weise, wenn die Ausgabe momentan auf 1 gehen könnte, wenn sie 0 bleiben sollte, sagen wir, daß das Netz eine statische-0-Gefahr aufweist. Falls die Ausgabe drei oder mehr Mal sich ändern könnte, wenn die Ausgabe sich von 0 auf 1 (oder von 1 auf 0) ändern sollte, sagen wir, daß das Netz eine dynamische Gefahr aufweist." Charles H. Roth, Jr. Fundamentals of Logic Design, zweite Ausgabe, c. 1979 West Publishing Company.
Die folgenden Routinen isolieren Fälle von statischen Gefahren. Wie oben vermerkt, ermöglicht die Benutzerschnittstelle einem Designer, nach Gefahren im ursprünglichen Entwurf zu suchen, nach durch Logiksynthese eingeführten Gefahren zu suchen oder nach beidem zu suchen. Um dies zu erledigen, ist die Routine unten dafür geschrieben, die Compilerdatenbasis sowohl bevor als auch nach der Logiksynthese zu handhaben. Tatsächlich existieren alle notwendigen Datensätze nach der Logiksynthese, was es ermöglicht, daß diese Routine aufgerufen wird, nachdem dieses Modul gelaufen ist.
Die Routine drc_check_hazards() wird einmal aufgerufen, ungeachtet dessen, was der Benutzer für die Gefahrerfassung angefordert hat. Sie bestimmt dann, welche Teile der Compilerdatenbasis zu prüfen sind und wie mit Warnungen umzugehen ist. Diese Routine verhindert zwei Warnungen betreffend das gleiche Logikstück, da dies nur passieren kann, wenn der Ursprungsentwurf des Benutzers Gefahren enthält. In diesem Fall wird die Warnung betreffend den Ursprungsentwurf ausgegeben, mit einer Anmerkung, daß die Gefahr auch nach der Synthese existiert.
Um diese Verarbeitung durchzuführen, ruft drc_check hazards() eine zweite Routine, drc_check function for hazards(), die das eigentliche Gefahrtesten durchführt. Diese Funktion weist die Fähigkeit auf, von beiden Sätzen von Compilerdatenbasisdatensätzen zu arbeiten, und bestimmt auf Grundlage der Gültigkeit weitergegebener Parameter, welcher Satz zu analysieren ist. Sobald sie die angemessenen Logikbäume konstruiert hat, ruft die Funktion drc_create_sum_of_procuts(), um jeden der Bäume zu Summen von Produktformen zu reduzieren, und gibt dann die reduzierten Bäume zu drc_check_trees() weiter, wo sie auf Gefahren überprüft und miteinander verglichen werden.
Nachdem die Produktsummengleichung behandelt wurde, wird die Ursprungsgleichung invertiert und reduziert, um eine Gleichung zu erzeugen, die die 0-Terme der Funktion aufführt. Diese neue Gleichung wird auf die gleiche Art und Weise wie die Ursprungsgleichung verarbeitet, woraus eine Liste von jeglichen statische-0-Gefahren resultiert.
Die Funktion drc_check_trees() akzeptiert eine oder zwei Logikbäume, die durch drc_check_function_for_hazards() erzeugt sind und analysiert diese auf statische Gefahren. Wenn die Funktion drc_check_trees() Gefahren findet, vergleicht sie die Liste von Gefahren aus dem Vorsynthesebaum mit der Liste von Gefahren aus dem Nachsynthesebaum, wie angemessen, Sie bestimmt dann, welche Fehlermitteilungen anzuzeigen sind, auf Grundlage dessen, ob der Benutzer Vor- oder Nachsynthese-Gefahrerfassung oder beides gewählt hat. Die Prozedur zum Überprüfen einer Funktion auf Gefahren, wie unten gezeigt, arbeitet ausgehend von einer aus der Datenbasis erzeugten Produktsummengleichung. Die Gleichung von der Form F = b+ c+bcd+abc wird in Paaren von Termen analysiert, um benachbarte Abdeckungen zu isolieren. Diese werden gefunden, wenn zwei Terme die gleiche Variable enthalten, dies aber in komplementärem Sinn, beispielsweise äb und abc aus F. Die Routine sammelt dann alle in jenen zwei Termen enthaltenen anderen Variablen, und versucht, einen Term zu finden, der diese Ansammlung abdeckt. In der Funktion F ist keine Abdeckung für den Term bc, so daß in der Funktion eine statische-1-Gefahr existiert. Andererseits produzieren c und b d den Satz von Variablen bd, der durch den Term b abgedeckt ist.
Schließlich ist die Prozedur zum Erzeugen von Produktsummenbäumen wie folgt. Als erstes wird aus der Compilerdatenbasis ein Baum gebaut, indem direkt in der Beschreibung von Logikgattern gelesen wird, und indem diese zu DRCS TREE NODE-Strukturen gewandelt werden. Alle Register und Eingabestifte werden als Quellen behandelt, wie auch jegliche Fälle von kombinatorischer Rückkopplung. Dann wird die Funktion drc_create_sum_of_products() aufgerufen, die den Baum rekursiv zu einer Produktsummenform reduziert.
Die eigentliche Reduktion wird durch die Funktion drc compress tree() durchgeführt. Diese Funktion führt die Boolean'schen Algebra-Funktionen UND und ODER (oder "multiplizier" und "addier") vom tiefsten Verschachtelungsniveau aufwärts durch. Während sie sich ihren Weg im Baum hoch arbeitet (oder, konzeptuell, von der am stärksten verschachtelten Klammer), erzeugt sie Bäume, die höchstens ein einziges Niveau tief sind. Mit anderen Worten, der durch diese Funktion erzeugte Baum wird stets von der Produktsummenform term+term+... sein, wobei term ein einziges Literal oder ein Produkt von Literalen ist (beispielsweise A, AB, ABC, usw.).
Wenn die Funktion einen Baum zu drc_create_sum_of products zurückgibt, ist das Ergebnis per Definition ein Produktsummenausdruck Die Funktion entfernt ferner Bäume, die während der Multiplikation zu VCC oder GND reduziert werden, wie auch duplizierte Terme und Bäume, die durch andere Bäume absorbiert werden (beispielsweise AB absorbierend ABC).

Asynchrone Eingabestifte

Um die Möglichkeit von Initialisierungs- und Halteverletzungen zu reduzieren, sollte ein Entwurf jedes Eingangssignal an den Takt des synchronen Netzes latchen, das das Signal speist. Diese Routine bestimmt, ob ein Eingangssignal mehr als ein Flip-Flop treibt, indem die Datenleitungen jedes synchronen Geräts zurück durch die Logik zu entweder anderen synchronen Geräten oder Eingabestiften zurückverfolgt wird. Jedes Gerät, das direkt von einem Eingangsstift abhängt, wird deshalb den Benutzungszählwert dieses Stifts um eins erhöhen. Am Ende der Rückverfolgung liest die Routine nur diese Benutzungszählwerte, was die Ausgangsverzweigung des Stiftes bestimmt.
Ferner sollte ein Signal, das durch ein auf einen Takt synchronisiertes Register erzeugt wird, auf den Takt jedes anderen Registers gelatcht werden, welches das Signal speist. Wenn deshalb eine Rückverfolgung an einem synchronen Gerät endet, wird die Taktgruppen-ID des Endgeräts gegen die Taktgruppen-ID des ursprünglichen Datenports überprüft. Falls die IDs nicht übereinstimmen, empfängt dann ein Gerät, das auf einen Takt synchronisiert ist, Daten, die auf einen anderen Takt synchronisiert sind. Diese Konfiguration ist eine Entwurfsverletzung, sofern nicht das Register ein Synchronisierregister ist, das eine einzige Eingabe von der anderen Taktgruppe hat (beispielsweise ist reg b ein Synchronisierregister, wenn reg_b.d = reg_a.q, reg_a.clk = clk_a, reg_b.clk = clk_b).
Diese Funktion wird stets ausgeführt, da sie bestimmt, ob irgendwelche Mehrfachtaktsysteme existieren und wo irgendwelche Probleme mit diesen Systemen auftreten.

Wettlaufsituationen

Die bevorzugte Ausführungsform wird kritische Wettläufe finden, die Steuersignale betreffen, die von dem Register abhängen, das sie steuern. Sie wird nicht nach anderen kritischen Wettläufen suchen, die zwei (oder mehr) zum gleichen Zeitpunkt schaltende Eingaben zu einer Funktion betreffen. Diese Routine führt eine einfache Rückverfolgung der jede der Steuerleitungen eines Registers treibenden Logik durch und endet an Stiften und anderen Registern. Es wird eine Warnung ausgegeben, wenn die Ausgabe des Registers in irgendeiner der Gleichungen gefunden wird.

Verzögerungsketten und asynchrone Pulsgeneratoren

Durch diese Funktion wird die Verwendung von Ketten von Expandern oder MCELL-Grundelementen zum Modifizieren des Timings eines Geräts erfaßt. Da die Datenbasis-Datenstrukturen der Elemente einer Kette in beliebiger Reihenfolge kommen können, macht diese Funktion insgesamt drei Durchgänge durch die Compilerdatenbasis. Beim ersten Durchgang macht sie alle Grundelemente ausfindig, die Teil einer Verzögerungskette zu sein scheinen. Wenn sie Verzögerungsketten gefunden hat, reduziert dann ein zweiter Durchgang die Anzahl von markierten Grundelementen auf eines pro Kette, um den Fehlerbericht zu vereinfachen. Schließlich berichtet ein dritter Durchgang alle Fehler, nachdem er verifiziert hat, daß eine Kette gefunden wurde und nicht eine Konfiguration des durch MCELL(NICHT(...)) repräsentierten Typs, wobei die Polarität der Ausgabe gegenüber der Eingabe ebenfalls berichtet wird.

Kreuzgekoppelte Expander

Diese Funktion erfaßt Expander-Latches und andere kreuzgekoppelte Expanderstrukturen. Sie verwendet einige Graphen-Theorie-Algorithmen, um alle Schleifen in einem Graph zu isolieren, der das Netz repräsentiert. Dies wird bewerkstelligt durch Aufbauen eines gerichteten Graphen mit der gesamten Verknüpfbarkeit des Netzes. Dann werden, beginnend an den Registern und Stiften, Vorwärts- und Rückwärtsabhängigkeiten entfernt. Wenn ein Knoten keine Vorwärtsabhängigkeiten mehr aufweist, können alle Knoten, von denen er Rückwärtsabhängigkeiten aufweist, diesen Knoten aus ihrer Vorwärtsabhängigkeitsliste entfernen und der Knoten kann gestrichen werden. Diese Streichung wird rekursiv durch den Graphen durchgeführt. Rückwärtsabhängigkeiten werden in der gleichen Art und Weise behandelt. Am Ende dieses Algorithmus sind die einzigen Knoten mit Abhängigkeiten jene, die Teil einer kombinatorischen Schleife sind oder von einer kombinatorischen Schleife abhängen.
Mit dieser Information wird dann der Graph nach kleinen Schleifen durchsucht, die wie Latchstrukturen aussehen. Diese involvieren typischerweise vier Gatter in der Datenbasis, die aus zwei UND- oder NAND-Gattern und zwei Platzhalter EXPANDER- oder MCELL-Gattern bestehen. Wenn eines dieser gefunden wird, wird der nahe gelegene Bereich auf zwei weitere Latches überprüft. Dies zeigt das Vorhandensein einer bekannten Klasse eines aus Logik gebauten DFF an, wo zwei Latches die Vorsetz- und Löschoperationen durchführen und ein drittes Ausgabelatch speisen.
Wenn eine LATCH- oder DFF-Struktur isoliert ist, sucht die Erfindung in den Vollnamen der Gatter nach den Schlüsselwörtern EXPLATCH, EXPDFF, NANDLTCH und NORLTCH. Diese zeigen an, daß sie von ALTERA bereitgestellte Makrofunktionen sein könnten und bewirken, daß ein anderer Typ von Warnung ausgegeben wird. Der Benutzer wird dann betreffend die Struktur gewarnt, ob sie die LATCH- oder DFF-Kriterien erfüllt oder ob sie eine unbekannte Struktur ist.

Benutzung einer Hauptrücksetzung

Diese Funktion versucht, einen Eingangsstift zu isolieren, der dem Entwurf des Benutzers als ein Hauptrücksetzsignal dient. Sie wird ferner die Rücksetzgruppen in einem Entwurf bestimmen, die Gruppen synchroner Geräte sind, die durch das gleiche Signal rückgesetzt oder initialisiert werden. Diese Gruppen, wie auch die Hauptrücksetzung (falls gefunden), werden durch drc_check_preset_clear() verwendet, um alle Rücksetzkonfigurationen in einem Entwurf zu überprüfen.
Das Finden einer Hauptrücksetzung enthält diese Heuristik: Die Hauptrücksetzung sollte in der Rücksetzgleichung der meisten Register sein. Wenn nach der Hauptrücksetzung gesucht wird, werden einzelne Stifte stärker gewichtet als Gruppen von Stiften. Falls eine aus einem einzigen Stift bestehende Rücksetzgruppe gefunden wird, wird dann die Anzahl von Registern in dieser Gruppe zu dem Benutzungszählwert dieses Stiftes hinzuaddiert. Falls mehrere Stifte in einer logischen Gleichung einbezogen sind, wird dann der Benutzungszählwert für jeden Stift in der Gruppe um eins vergrößert werden anstelle um die Anzahl von Registern in der Gruppe. Nachdem alle Rücksetzgruppen analysiert wurden, wird eine Hauptrücksetzung aus den während der Suche erzeugten Zählwerten identifiziert.
Die folgenden Funktionen können ebenfalls in die bevorzugte Ausführungsform der Erfindung einbezogen werden. Die erste wird auf die Effizienz jeder Makrofunktion in dem Entwurf des Benutzers überprüfen, und zwar gegen eine vorkompilierte Liste von Makrofunktionen und Äquivalenten. Die zweite wird verifizieren, daß die Zeit bis zur Ausgabe für jedes Element einer bekannten Gruppe identisch sind. Die letzte wird versuchen, jegliche unbekannten Zustandsmaschinen zu isolieren und zu testen, um zu sehen, ob sie mögliche steckengebliebene Zustände enthalten. Datenstrukturen
Diese Struktur enthält ein Flag für jede Entwurfsregel innerhalb der bevorzugten Ausführungsform der Erfindung. Diese Struktur wird dazu verwendet, die Entwurfsregelüberprüfung zu steuern und initialisiert die Fortgeschrittene Optionen -Dialogbox. Wenn neue Entwurfsregeln entwickelt werden, werden Flags zu dieser Struktur hinzugefügt. Jedes Element dieser Struktur wird ferner in der Form RULE NAME = 0/1 zur Projektinitialisierungsdatei ausgeschrieben.
Dieser Typ codiert den momentan gewählten Regelsatz, Die EPLD-, Flex- und MPLD-Regelsätze bilden sich auf ein bestimmtes Muster von WAHR- Merkern in der obigen Entwurfsregelstruktur ab, während der benutzergewählte Regelsatz ein beliebiges Muster ermöglicht. Dieses wird dazu verwendet, die Fortgeschrittene Optionen... Dialogbox zu initialisieren und wird als eine Abkürzung für die drei bekannten Regelsätze verwendet. Dies wird in der Projektinitialisierungsdatei als DRC_RULES = Nummer gesichert.
Dieser Typ wird dazu verwendet, den momentanen Zustand des Compilers anzuzeigen und wird zum Compilersteuermodul exportiert.
Diese Struktur hält Daten über eine Gruppe von synchronen Geräten, die einen gemeinsamen Takt teilen und auf die als eine "Taktgruppe" Bezug genommen werden. Für jede Taktgruppe in einem Entwurf hält diese Struktur einen Zeiger zur Liste von Geräten, die durch diesen Stift oder diese Gleichung getaktet werden; die Datenbasis-ID des Taktstifts oder der Gleichung; ob diese Taktgruppe Teil einer Ripple-Taktkette ist oder nicht, die Anzahl von Registern in einer Gruppe, und einen Zeiger zur nächsten Taktgruppe.
Diese Struktur definiert einen Knoten in einer Taktgruppe, was ein Auftreten eines synchronen Geräts darstellt. Die Erfindung erfordert nicht eine Bestimmung des Typs des in einer Taktgruppe repräsentierten synchronen Geräts, ob es ein Latch, ein DFF, ein JKFF oder eine Zustandsmaschine ist. Diese Struktur hält die Datenbasis-ID des synchronen Geräts, die Taktgruppen-ID und den Sinn des Takts, wenn er diesen Knoten erreicht.
Diese Struktur hält einen einzigen Stift in einer Liste von Eingangsstiften in einem Entwurf. Die Benutzungszählwertvariable ist die Anzahl von sychronen Geräten, die durch diesen Stift über beliebige kombinatorische Logik angesteuert werden. Die Struktur zeichnet ferner die Datenbasis-ID des Stifts, den sie repräsentiert, und einen Zeiger zum nächsten Element in der Liste auf. Diese Struktur ist im Gebrauch, wenn der Hauptrücksetzstift für einen Entwurf bestimmt wird.
Dieser Typ definiert die logischen Operatoren, die innerhalb des durch die bevorzugte Ausführungsform aus der Compilerdatenbasis extrahierten Logikbaums existieren können. Anders als beim Compiler existiert ein einziger Typ für jeden Operator anstelle eines Typs mit einer eingebetteten Pinzählung. Diese Information wird im Baumknoten gespeichert, wie unten diskutiert.
Diese Struktur definiert einen Knoten im in der statische-Gefahr-Erfassung verwendeten Logikbaum. Konzeptuell repräsentiert jeder Knoten in diesem Baum ein Gatter im Entwurf, bevor der Baum zur Produktsummenform umgewandelt wird. Die Struktur listet auf die logische Operation, die sie repräsentiert, die Anzahl von anderen Knoten, die Eingaben zu diesem Knoten sind und die Anzahl von festen Datenbasisdatensätzen, die ebenfalls Eingaben zu diesem Knoten sind. Die festen Datenbasisdatensätze repräsentieren Eingangsstifte und synchrone Geräte. Der Knoten hält dann einen Zeiger zu einem Feld von Datenbasisdatensatz-IDs und einen Zeiger zu einem Feld von Zeigern zu anderen Knoten.
Diese Struktur hält eine betreffend eine Logikfunktion erzeugte Warnung. Der Typ zeigt an, ob dies eine Warnung betreffend eine statische-1- oder eine statische-0- Gefahr ist. Name ist der Name des Grundelements, das dem Benutzer berichtet werden wird, und conditions ist eine Liste von Namen von Quellen im Entwurf und der Niveaus, auf den sie sich befinden müssen, damit die Gefahr existiert. Diese Quellen sind Eingangsknoten und synchrone Geräte. Schließlich ist eine Liste von Datenbasis-IDs der Quellen vorgesehen, die dazu verwendet wird, Ortsinformation zu erzeugen, wenn der Fehler berichtet wird.
Diese Struktur definiert einen Knoten im durch die bevorzugte Ausführungsform aus der Datenbasis extrahierten Graph, wenn auf kombinatorische Latches, Flip-Flops und andere Rückkoppelstrukturen überprüft wird. Jeder Datensatz in der Datenbasis hält einen Zeiger zu einer dieser Strukturen. Die Struktur enthält dann eine Liste von Eingaben zu diesem Datenbasisdatensatz, eine Liste von allen Datensätzen, die von diesem einen für die Eingabe abhängen, und die Gesamtanzahl von Elementen in jeder Liste. Sie zeichnet dann die Anzahlen von Eingaben und Ausgaben auf, die noch nicht verarbeitet wurden, wie oben beschrieben.

Compiler-Schnittstelle

Diese Funktion ist der Haupteingangspunkt vom Compilersteuermodul und umfaßt den Abfertigungspunkt für die Funktionen, die die verschiedenen Entwurfsregeln testen. Wenn neue Entwurfsregeln erzeugt werden, können sie durch diese Funktion zu der angemessenen Stufe des Compilers hinzugefügt werden.
Wie nun ersichtlich sein wird, stellt die Erfindung eine einfache und vorteilhafte Technik bereit zum Validieren eines ursprünglichen Entwurfs sowie einer Logik-synthetisierten Version des ursprünglichen Entwurfes betreffend die Übereinstimmung mit oder Verletzung von vorbestimmten Entwurfs regeln. Bei der bevorzugten Ausführungsform ist die Erfindung als ein zusätzliches Modul im oben erwähnten MAX PLUS-System implementiert und kann in Verbindung mit diesem System für eine anfängliche Entwurfsüberprüfung verwendet werden. Das MAX PLUS-System ist generell in dem "MAX PLUS II programmierbare-Logik-Entwicklungs-System- und Software- Datenblatt" mit Datum September 1992 beschrieben, das von Altera Corporation erhältlich ist.
Die Benutzerwählbarkeit von verschiedenen Graden der Konformitätsüberprüfung (d. h., "EPLD-Regeln", "FLEX-Regeln") und das Benutzer-Regel- Merkmal sorgt für eine große Flexibilität bei der Verwendung der Erfindung, um ursprüngliche Entwürfe eines Benutzers zu überprüfen.
Während das obige eine vollständige und komplette Offenbarung der bevorzugten Ausführungsform der Erfindung bereitstellt, können nach Wunsch vielfältige Modifikationen und Äquivalente verwendet werden. Beispielsweise können bei anderen Ausführungsformen der Erfindung andere Entwurfsregelsätze oder zu dem oben beschriebenen Entwurfsregelsatz zusätzlich vorgesehene Regeln implementiert sein. Deshalb sollten die obige Beschreibung und Darstellungen nicht als den Bereich der Erfindung beschränkend ausgelegt werden, der durch die anhängenden Ansprüche definiert ist.

Claims

1. Verfahren des Verifizierens, ob ein anfänglicher Logikentwurf einem Benutzer gewählten Satz von Entwurfsregeln aus einem vorexistierenden Satz von Entwurfsregeln genügt, der erlaubte und verbotene strukturelle und funktionale Logikvorrichtungsbeziehungen ausdrückt, in einem Computer-unterstützten Logikentwurfssystem zum Entwerfen und Testen logischer Schaltungen vor einer körperlichen Implementation, wobei das Verfahren die Schritte umfasst:

(a) Unterbreiten von Wahlmöglichkeiten einem Benutzer, die den gesamten vorexistierenden Satz von Entwurfsregeln, einen vorbestimmten Untersatz des vorexistierenden Satzes von Entwurfsregeln für programmierbare Logikvorrichtungen und einen individuell anpassbaren Untersatz des vorexistierenden Satzes von Entwurfsregeln, der durch den Benutzer anzupassen ist, enthalten;

(b) Akzeptieren einer Wahl des Benutzers aus den unterbreiteten Wahlmöglichkeiten, die hierdurch den Benutzergewählten Satz von Entwurfsregeln etabliert;

(c) Bereitstellen einer Logikentwurfsdatei, die den anfänglichen Logikentwurf in Computer-lesbarer Form enthält;

(d) Ausführen des Benutzer gewählten Satzes von Entwurfsregeln, um wenigstens Teile des anfänglichen Logikentwurfs zu überprüfen; und

(e) Bereitstellen einer vom Benutzer wahrnehmbaren Anzeige jeglicher Verletzung des Benutzer gewählten Satzes von Entwurfsregeln durch den anfänglichen Logikentwurf.

2. Verfahren nach Anspruch 1, bei dem die dem Benutzer unterbreiteten Wahlmöglichkeiten einen Satz von Entwurfsregeln aus dem vorexistierenden Satz von Entwurfsregeln enthalten, der auf löschbare programmierbare Logikvorrichtungen (EPLDs) anwendbar ist.

3. Verfahren nach Anspruch 1 oder 2, bei dem die dem Benutzer unterbreiteten Wahlmöglichkeiten einen Satz von Entwurfsregeln aus dem vorexistierenden Satz von Entwurfsregeln enthalten, der auf Masken-programmierbare Logikvorrichtungen (MPLDs) anwendbar ist.

4. Verfahren nach Anspruch 3, bei dem der Satz von Entwurfsregeln für MPLDs aus dem gesamten vorexistierenden Satz von Entwurfsregeln besteht.

5. Verfahren nach Anspruch 4, bei dem der Satz von Entwurfsregeln für EPLDs ein Untersatz des Satzes von Entwurfsregeln für MPLDs ist.

6. Verfahren nach einem der vorangehenden Ansprüche, bei dem der Schritt des Unterbreitens von Wahlmöglichkeiten dem Benutzer das sichtbare Anzeigen der Wahlmöglichkeiten umfasst.

7. Verfahren nach einem der vorangehenden Ansprüche, ferner umfassend die Schritte des Durchführens einer Logiksynthese des anfänglichen Logikentwurfs und des Wiederholens des Schritts (d) des Ausführens des Benutzer-gewählten Satzes von Entwurfsregeln und (e) des Bereitstellens einer vom Benutzer wahrnehmbaren Anzeige mit der Logiksyntheseversion des anfänglichen Logikentwurfs, um auf Entwurfsregelverletzungen zu überprüfen, die möglicherweise durch die Logiksynthese eingeführt sind.