DE69631278T2

DE69631278T2 - Entwurfssystem und -verfahren zum kombinierten Entwurf von Hardware und Software

Info

Publication number: DE69631278T2
Application number: DE1996631278
Authority: DE
Inventors: Karl Van Rompaey; Diederik Verkest; Jan Vanhoof; Bill Lin; Ivo Bolsens; Hugo De Man
Original assignee: Interuniversitair Microelektronica Centrum vzw IMEC
Current assignee: Interuniversitair Microelektronica Centrum vzw IMEC
Priority date: 1995-10-23
Filing date: 1996-10-03
Publication date: 2004-11-18
Anticipated expiration: 2016-10-04
Also published as: DE69631278D1; EP0772140A1; EP0772140B1; ATE257611T1

Description

Gebiet der Erfindung
Die vorliegende Erfindung betrifft eine Entwurfsumgebung und ein Entwurfsverfahren für den gleichzeitigen Entwurf bzw. das Codesign einer Hardware/Software. Noch spezifischer gesehen umfasst das Codesign von Hardware/Software gemäß dieser Erfindung die Spezifikation, die Synthese und die Simulation von heterogenen Systemen.
Hintergrund der Erfindung
Digitale Kommunikationstechniken bilden die Grundlage des schnellen Durchbruches der modernen Unterhaltungselektronik, der kabellosen und der kabelgebundenen Sprach- und Datennetzwerkprodukte, der Breitbandnetzwerke und der multimedialen Anwendungen. Solche Produkte beruhen auf digitalen Kommunikationssystemen, welche möglich gemacht werden durch die Kombination der VLSI Technologie und der Digitalen Signal Verarbeitung.
Digitale Systeme führen Echtzeit-Transformationen auf zeitdiskreten, digitalisierten Abtastwerten von analogen Mengen mit einer endlichen Bandbreite und mit einem endlichen Signal zu Rausch Verhältnis durch. Diese Transformationen können in Programmiersprachen spezifiziert werden und sie können ausgeführt werden auf einem programmierbaren Prozessor oder direkt auf einer anwendungsspezifischen Hardware. Die Wahl bestimmt sich nach den Kompromissen zwischen Kosten, Performance, Leistung und Flexibilität.
Daher sind digitale Systeme ein Kandidat par excellence für den gleichzeitigen Entwurf d. h. das Codesign von Hardware/Software.
Im Gegensatz zur analogen Verarbeitung garantiert die digitale Verarbeitung eine perfekte Reproduzierbarkeit, Speicherung und Testfähigkeit. Die Signalqualität ist eine Sache von exakten mathematischen Operationen. Der zu zahlende Preis besteht in den Kosten für die Hardware und in der Performance, welche man benötigt, um der harten Echtzeiteigenschaft zu genügen. Dieses Problem ist jetzt gelöst durch den Überfluss an digitaler VLSI (Very Large Scale Integration = Sehr große Skalen Integration) Technologie, welche preiswerten Speicherplatz und Rechenauswertungen von hoher Geschwindigkeit liefert. Daher hat die Verbindung der VLSI Technologie mit der digitalen Verarbeitung den Durchbruch möglich gemacht für die moderne Unterhaltungselektronik, die tragbare und persönliche Kommunikation, die Breitbandnetzwerke, die multimedialen Anwendungen und die Anwendungen im Automobilbereich.
Das Verfahren zum Entwurf der Produkte für diese Anwendungen ist Gegenstand einer Anzahl von Abhängigkeiten. Ein erster Zwang besteht darin, dass sie aus Gründen der Leistung, der Performance und der Kosten aus Silizium oder aus einer anderen Hardwareplattform implementiert werden müssen. Ein zweiter Zwang besteht darin, dass diese Systeme zum Implementieren der Produkte von einem hoch spezialisierten Systemteam in Begriffen von ausführbaren, gleichzeitig ablaufenden Programmierparadigmen ersonnen werden, welche heute von den Hardwaredesignern noch nicht richtig verstanden werden. Daher werden die meisten Spezifikationen zuerst ins Englische übersetzt und dann neu entworfen (redesigned) in einer spezifischen Beschreibungssprache für die Hardware, wie etwa VHDL oder VERILOG für die Komponenten der Hardware, und in einer Beschreibungssprache für die Software, wie etwa C oder Assembler für die Softwarekomponenten. Obwohl die Hardware und die Software eine sehr enge gegenseitige Verflechtung bzw. Interaktion aufweisen, werden beide, sowohl die Hardware als auch die Software, getrennt entworfen und ausgelegt. Erst nach dem Zusammenbau des Systems werden die Software und die Hardware zusammen betrieben. Als eine Konsequenz hieraus kann der Entwurf weit von dem Optimum entfernt sein oder er kann sogar falsch sein und Irrtümer enthalten, was eine erneute Entwurfsrunde zur Pflicht macht. Diese Lücke zwischen dem Systemdesign und der Umsetzung bzw. Implementierung wird schnell zu dem wichtigsten Flaschenhals beim Verfahren zum Entwerfen der genannten Produkte oder der genannten Systeme. Eine andere Abhängigkeit besteht darin, dass aus Gründen der Kosteneffizienz und der zeitgerechten Marktplazierung eine Notwendigkeit besteht, die Designproduktivität um mindestens eine Größenordnung zu steigern. Noch eine andere Abhängigkeit besteht darin, dass sowohl eine Wiederverwendung von Designs als auch ein Design für eine Methodologie der Wiederverwendung angenommen werden müssen. Diese Methodologie impliziert ein Codesign von Hardware/Software auf mehreren Ebenen der Implementierung.
J. Buck et al. fokussieren in „PTOLEMY: A framework for simulating and prototyping heterogeneous Systems (– Ein Rahmenwerk für das Simulieren und Prototypieren von heterogenen Systemen –)" (International Journal on Computer Simulation, January 1994) die Aufmerksamkeit auf eine Umgebung für das gleichzeitige Simulieren von Hardware/Software. Die vorgeschlagene Methodologie erlaubt nur ein Codesign von Hardware/Software von Systemen, die auf einem Datenflussalgorithmus beruhen. Weiterhin wird die Synthese einer Hardware/Software Schnittstelle (interface Synthesis) nicht unterstützt.
Das Patent No. 5,197,016 der Vereinigten Staaten offenbart ein computergestütztes System und ein computergestütztes Verfahren für das Entwerfen eines anwendungsspezifischen integrierten Schaltkreises, dessen beabsichtigte Funktion sowohl durch die Untersysteme der Hardware als auch in die Untersysteme der Software implementiert wird. Die vorgeschlagene Methodologie erlaubt nur ein Design für einen einzelnen Prozessor und sie ist nur gültig für Spezifikationen, welche auf einem Zustandsdiagramm beruhen. Ein Codesign von Hardware/Software für Systeme, die auf einer heterogenen Spezifikation beruhen, wird nicht unterstützt.
S. Narayan, F. Vahid und D. Gajski offenbaren in „System specification with the SpecCharts language (– Systemspezifikation mit der SpecCharts Sprache –)" (IEEE Design & Test of Computers, Seiten 6–13, Dezember 1992) eine Methodologie, welche auf VHDL aufbaut. Die Methodologie unterstützt das Codesign von Hardware/Software für Systeme, die auf einer heterogenen Spezifikation beruhen aber nicht.
P. Chou, R. Ortega und G. Borriello zeigen in „Synthesis of the hardware/software Interface in microcontroller-based systems (– Synthese von Hardware/Software Schnittstellen bei Systemen auf der Basis von Mikrokontrollern –)" (Proceedings of the IEEE International Conference on Computer-Aided Design, ICCAD 92, Seiten 488–495, November 1992) eine Methode für das Erzeugen von Hardware/Software Schnittstellen für Systeme, welche auf einem Mikrocontroller beruhen. Die genannte Methode geht davon aus, dass der Nutzer die Softwareschnittstelle bestimmt, wie etwa die Kommunikation mit den Treibern vor dem Start der Systemsyntheseaufgabe.
Die Referenzen nach dem Stand der Technik, wie diejenige von Ismail und Jerraya: „Synthesis Steps and Design Models for Codesign (– Synthesestufen und Entwurfsmodelle für das Codesign –)", veröffentlicht in Computer, Februar 1995 und die von Valderrama et al: „A Unified Model for Co-Simulation and Co-Synthesis of Mixed Hardware/Software Systems (– Vereinheitlichtes Modell für die gleichzeitige Simulation und Synthese von gemischten Systemen Hardware/Software –)", Proceedings of the European Design and Test Conference, Paris, March 1995, beschreiben eine Umfeld für den gleichzeitigen Entwurf von Hardware/Software. Eine vereinheitlichte Methodologie für die Cosynthese (gleichzeitige Synthese) und die Cosimulation (gleichzeitige Simulation) wird hierin beschrieben. Das Umfeld erlaubt es auch, mehrere architektonische Modelle anzupassen durch die Verwendung einer Bibliothek von Kommunikationsmodellen, welche die Abstrahierung von bestehenden Kommunikationsschemata ermöglichen. Dieselben Modulbeschreibungen sind mit verschiedenen Umgebungsarchitekturen hinsichtlich ihrer zugrunde liegenden Kommunikationsprotokolle verwendbar.
Ein Problem bei dem Designumfeld für ein Hardware/Software Codesign, wie dasselbe in den Referenzen nach dem Stand der Technik beschrieben wird, liegt in der Tatsache, dass das SOLAR/COSMOS Verfahren nur mit festgelegten Hardware/Software Zielarchitekturen umgehen kann. Es kann mit verschiedenen Typen von Hardware/Software Zielarchitekturen solange umgehen, wie diese im voraus in Bezug auf das Designverfahren bekannt sind, wie folgt. Irgendeine Hardware/Software Zielarchitektur, welche als ein Ziel für die SOLAR/COSMOS Methode dient, muss im voraus bekannt sein (Blöcke, Verbindungen, Treiber, ...).
Insbesondere nimmt die Designmethodologie, wie sie in der SOLAR/COSMOS Umgebung implementiert wird, eine Bibliothek von Kommunikationsmodellen in Anspruch. Eine entsprechende Bibliothek von Kommunikationseinheiten ist auch mit enthalten.
Beim SOLAR/COSMOS ist auf einer hohen Stufe der Abstraktion die Kommunikation zwischen den verschiedenen Systemkomponenten als ein logisches Kommunikationsnetzwerk modelliert welches einen Satz von Diensten liefert. Spezifischer gesehen findet die Kommunikation über logische Kanaleinheiten (die Kommunikationsmodelle) statt. Das Problem der Kommunikationssynthese (Design) wird dann wie folgt formuliert:

1. Festsetzen der Anzahl von Kommunikationseinheiten (aus einer Bibliothek ausgewählt), welche die Funktionalität des Kommunikationsnetzwerkes implementieren werden.
2. Zuweisung von logischen Kanaleinheiten zu den zuerteilten Kommunikationseinheiten.

Als eine Konsequenz muss eine Kommunikationseinheit in der Bibliothek für jede mögliche Kommunikation zwischen den Systemkomponenten der endgültigen Designimplementierung vorhanden sein (d. h. für jede Kombination von Prozessoren).
Eine Kommunikationseinheit ist nämlich ein Objekt, welches eine oder mehrere Prozeduren ausführen kann, welche eine bzw. einige gemeinsame Ressourcen miteinander teilen können (siehe D2, S. 181). Das Teilen der einen bzw. der einigen gemeinsamen Ressourcen wird von einem Kommunikationscontroller gesteuert. Eine Kommunikationseinheit kann entweder einer bestehenden Kommunikationsplattform oder einem Untersystem entsprechen, welches sich aus einer früheren Designsitzung ergeben hat (D2, S. 181). In beiden Fällen ist die Hardware/Software Zielarchitektur der endgültigen Designimplementierung schon am Platz vorhanden, sie braucht nur verwendet zu werden. Die verfügbaren Kommunikationseinheiten werden in eine Bibliothek von Komponenten eingeordnet, und sie werden nicht für jede Designsitzung synthetisiert (S. 181).
Diese Kommunikationseinheiten sind in der Tat wirkliche E/A Prozessoren. Sie liefern eine Menge an Funktionalität, welche verwendet werden kann, um die Kommunikation zu implementieren, welche von den logischen Kanaleinheiten, die denselben zugewiesen sind, erfordert werden, aber sie werden immer als ein Ganzes instantiiert (zuerteilt), was zu einer Suboptimalität führt und es kann keine maßgeschneiderte, flexible Designlösung erzeugt werden.
Somit kann die SOLAR/COSMOS Umgebung nur eine gewisse Anzahl von vorher definierten Hardware/Software Zielarchitekturen unterstützen. Welcher Teil der Hardware/Software Zielarchitektur tatsächlich während der Kommunikation in einer spezifischen Anwendung verwendet werden wird, dies wird von Anwendung zu Anwendung unterschiedlich sein. Die meisten Anwendungen werden jedoch nicht alle verfügbaren E/A Mechanismen in solch einer vorher definierten Architektur benutzen, und es werden sich daher suboptimale Designimplementierungen ergeben.
Keine der Lösungen nach dem Stand der Technik liefert eine Designumgebung, die auf einem Datenmodell beruht, welches es erlaubt Implementierungen für heterogene Hardware/Software, die von einer heterogenen Systemspezifikation aus starten, zu spezifizieren, zu simulieren und zu implementieren oder zu synthetisieren. In den folgenden Abschnitten dieses Teiles wird eine Analyse über die Eigenschaften von Spezifikationen von solchen heterogenen Systemen erstellt.
Definition des Problems
In dem striktesten Sinne bestehen die digitalen Systeme aus Algorithmen, welche digitale Signale in digitale Signale in Echtzeit abbilden. Die Echtzeitbeschränkung wird bestimmt durch die Wiederholungsperiode des Algorithmus für das Aufbrauchen eines Eingangsrahmens und für das Erzeugen eines neuen Ausgangsrahmens.
Die Periodizität dieser Beschränkung und die Natur der Signale führt zu der Tatsache, dass der elementare Algorithmus eine Datenflussfunktion darstellt.
Ein Synchroner Daten-Fluss (SDF) Algorithmus kann modelliert werden als ein azyklischer Graph, bei dem Knoten Operatoren sind und Kanten die Datenreihenfolgen repräsentieren. Dieser Graph wird als Datenflussgraph bezeichnet. Ein Operator kann ausgeführt werden, wenn eine vorher bestimmte, feste Anzahl von Daten (Tokens d. h. Kennzeichen) an seinem Eingang vorhanden ist, und dann erzeugt er eine oder mehrere Ausgangsdaten (Tokens).
Eine bedingte Auswahl von zwei Operationen an einem einzelnen Ausgang ist erlaubt. Operatoren haben keinen Stand, sondern Felder (Arrays), welche sich aus der Ausführung eines Algorithmus ergeben, und für eine Wiederverwendung bei zukünftigen Ausführungen (Verzögerungsoperator) gespeichert werden können. Viele digitale Verarbeitungsalgorithmen sind von diesem Typ. Sie können sehr wirkungsvoll durch so genannte Anwendungsprogrammiersprachen beschrieben werden, etwa durch SILAGE.
Im Gegensatz dazu enthalten Algorithmen für den Dynamischen Daten-Fluss (DDF) eine datenabhängige Erzeugung und einen datenabhängigen Verbrauch von Tokens. Sie lassen ,while' und ,if-then-else' Anweisungen zu.
Computer-Aided-Design (CAD = computergestütztes Design) Umgebungen für digitale Systeme, wie DSP-Station von Mentor Graphics, PTOLEMY, GRAPE-II von COSSAP, erlauben alle die Spezifikation von SDF und DDF und gebrauchen soviel wie möglich eine statische Ablaufplanung, um Simulationsgeschwindigkeiten zu liefern, welche um bis zu zwei Größenordnungen schneller sind als ereignisgesteuerte Simulatoren, wie sie für VHDL im Gebrauch sind. Dies rechtfertigt die Verwendung von diesen Simulationsparadigmen für eine digitale Systemspezifikation und Validation.
Wenn wir jedoch digitale Verarbeitungssysteme im weiteren Sinne betrachten, dann ist ein breiterer Umfang notwendig, wie dies in der 1 dargestellt ist, welcher eine Abstraktion von vielen praktischen Implementierungen von digitalen Verarbeitungssystemen ist. Ein sorgfältiger Blick auf die 1 erlaubt uns, fünf (in der Folge 1) 2) 3) 4) 5)) gemeinsame Eigenschaften der Spezifikationen von digitalen Verarbeitungssystemen zu identifizieren:

1) Digitale Systeme umfassen in typischer Weise sowohl einen (oder mehrere) Signalweg 1 als auch langsame Regelschleifen 2 und ein reaktives Steuersystem 3, welches die Ereignisse 4 aus einem langsamen Umfeld wie etwa von einer Benutzerschnittstelle (User Interface = UI) 5 und eine langsame Zustandsinformation 6 aus den Signalwegen als Eingangssignale aufnimmt, um den Modus oder die Parameter der Signalwege zu steuern.
2) Ein Signalweg 1 besteht gewöhnlich aus einer Verkettung von Datenflussfunktionsblöcken (DFB) 7, wie h1, h2,..., L2, welche des Öfteren bei bereits ausgesprochen verschiedenen Daten- und Ausführungsgeschwindigkeiten arbeiten und welche das Format der Daten umwandeln. Die Unterschiede der Geschwindigkeit und des Formats resultieren naturgemäß aus den Operationen wie: Frequenzumwandlung nach oben und unten, eine Modulation Bit zu Symbol, eine Datenkompression und eine Fehlerkorrekturcodierung. Wenn diese DFBs auf nicht fragmentierten Signalwörtern arbeiten, dann können sie am besten als Datenflussalgorithmus spezifiziert werden (z. B. in SILAGE; DFL oder C). Andere, welche einzelne Bits der Signale manipulieren, können direkt als finite Statusmaschinen mit Datenwegen (FSMD = Finite State Machines with Data paths) beim Registertransfer oder bei der Verhaltensstufe mit VHDL spezifiziert werden. Folglich hängt das Spezifikationsformat von dem Typ des Datenflussfunktionsblocks ab.
3) DFBs in dem Signalweg sind intern stark miteinander verbundene Datenflussgraphen mit einer spärlichen externen Kommunikation. Daher werden sie, vom Standpunkt der Implementierung aus gesehen, selten über mehrere Komponenten von Hardware oder Software hinweg partitioniert (unterteilt). Eher werden sie auf derselben Komponente zusammengeführt, wenn die Bedingungen des Durchsatzes und der Geschwindigkeit es zulassen, es so zu tun. Ein Zusammenführen impliziert ein Sequentialisieren der verzahnt ablaufenden Prozesse auf einer einzelnen Komponente, während dabei die Zeitbeschränkungen immer noch erfüllt werden. Dies erfordert Softwaresynthese: Verkapselungstechniken von einzeln geketteten Compilern, um eine Zeitplanung von verzahnt verlaufenden Prozessen in Echtzeit zu erlauben.
4) Regelschleifen und eine Moduskontrolle durch eine Einstellung von Parametern sind geläufig bei fast allen digitalen Verarbeitungssystemen. Zum Beispiel haben alle digitalen Kommunikationssysteme Nachführungsschleifen und Erfassungsschleifen zum Synchronisieren der Frequenz und der Phase des Signalweges des Empfängers mit den Eigenschaften des ankommenden Signals. Das Design dieser Schleifen ist eine der schwierigsten Aufgaben, weil deren Eigenschaften stark von den Rausch- und Störungseigenschaften des Kommunikationskanals abhängig sind. Dieses impliziert das Design von phasenverriegelten Regelschleifen, von Verzögerungsregelschleifen und von schnellen Fouriertransformationen, welche von „Ereignissen" (events) gesteuert werden, welche die Regelmäßigkeit der Signalströme stören.

Die Häufigkeit des Auftretens dieser Ereignisse ist um Größenordnungen langsamer als die Datengeschwindigkeit in dem Signalweg. Ähnlich zu dem UI (User Interface) haben daher die Verfahren, welche diese langsamen Steuerungsschleifen und die Moduseinstellung modellieren, keinen Datenfluss, sondern reaktive Semantiken.
Sie laufen gleichzeitig mit dem Datenfluss und oft bestehen sie selbst aus verzahnten Prozessen. Solch ein steuerungsdominiertes System kann beschrieben werden als eine Program State Machine (PSM) (Programm Zustandsmaschine), welche eine Hierarchie von Programmzuständen ist, in denen jeder Programmzustand einen unterschiedlichen Berechungsmodus darstellt. Formalismen wie StateCharts oder SpecCharts, welche eine Verhaltenshierarchie, eine Handhabung von Ausnahmen und ein Modellieren einer Inter-Prozesskommunikation mit einbeziehen, sind notwendig, um solche Systeme zu beschreiben. In der Praxis wird sehr oft eine Synchronisation in einem oder in mehreren verzahnt verlaufenden C Programmen spezifiziert.

5) Digitale Systeme enthalten beides, Blöcke sowohl mit einer hohen als auch mit einer niedrigen Datenübertragungsgeschwindigkeit, in dem Signalweg. Blöcke mit einer hohen Datenübertragungsgeschwindigkeit werden direkt in der Hardware synthetisiert. Blöcke mit einer niedrigen Datenübertragungsgeschwindigkeit sind Kandidaten für die Implementierung auf programmierbaren Prozessoren. Daher sind digitale Systeme natürliche Kandidaten für ein Codesign von Hardware/Software.

Aus den obigen Ausführungen folgt, dass digitale Systeme eine Kombination von Datenmodellen für ihre Spezifikation erfordern. Spezifikationssprachen sind eng gekoppelt an diese Datenmodelle, Paradigmen, Simulatoren und Synthesewerkzeuge.
Gegenwärtig ist die vorherrschende Spezifikationssprache des digitalen Systemdesigners die Sprache C oder eine DFL für den Hauptsignalweg, während FSMDs und PSMs gewöhnlich in einer HDL beschrieben werden. Für die Beschreibung von Kommunikationskanälen und Kommunikationsprotokollen müssen andere Formalismen wie Zeitdiagramme, ausgedehnte Graphen der Signalübertragung (Extended Signal Transition Graphs) und kommunizierende sequentielle Prozesse (Communicating Sequential Processes) in Betracht gezogen werden. Ein CAD System für digitale Systeme muss in der Lage sein, alle diese Paradigmen und die damit verbundenen Sprachen und Designumgebungen mit einzukapseln.
Das Design digitaler Systeme erfordert daher die Fähigkeit, den Datenfluss und reaktive Paradigmen mit weit unterschiedlichen Zeitkonstanten zu mischen. Der Unterschied in den Zeitkonstanten zwischen dem Steuer- und dem Datenfluss wirft bei der Simulation besondere Probleme auf. Es ist erfordert, dass alle Prozesse auf dem höchst möglichen Abstraktionsniveau simulierbar sind.
Nicht nur die Spezifikation eines digitalen Systems ist von Natur aus heterogen. Auch die Implementierungsarchitektur eines digitalen Systems ist heterogen. Ein Beispiel einer Implementierungsarchitektur umfasst die folgenden Typen von Komponenten und die Kommunikation zwischen diesen Komponenten:

– programmierbare Prozessoren.
– anwendungsspezifische Prozessoren mit einer fest verdrahteten Steuereinheit.
– anwendungsspezifische Prozessoren mit einem spezialisierten Befehlsliste.
– Hardwarebeschleuniger.
– Mikrocontroller
– Kommunikationsblöcke und Speicher
– Peripherieeinrichtungen (DMA, UART, ...)

Daher muss eine Designmethode für ein digitales System die Lücke zwischen der heterogenen Spezifikation des Systems und seiner heterogenen Implementierung überbrücken. Die heutigen Synthesewerkzeuge und Kompilierer erlauben es uns, all die Prozessor-Beschleuniger-Speicherplatzkomponenten zu synthetisieren oder zu programmieren, wenn die globale Systemarchitektur erst einmal definiert worden ist. Jedoch ist die Verfügbarkeit dieser Komponentenkompilierer notwendig, aber sie ist nicht ausreichend. Was gebraucht wird, sind Modelle und Werkzeuge, um die funktionale Spezifikation eines Systems in die detaillierte Architektur zu verfeinern: die Definition und die Zuteilung der Komponenten und ihre Kommunikation und Synchronisation. Der wesentlichste Schritt besteht darin, die notwendige Software und Hardware zu erzeugen, um die Prozessoren, Beschleuniger und die Umgebung miteinander in Kommunikation zu bringen.
Einer der Schlüsselansätze zur Meisterung der Komplexität des digitalen Systemdesigns liegt in der Wiederverwendung von Komponenten. Der Designprozess für ein digitales System muss das Modellieren von wiederverwendbaren Komponenten und die Unterstützung eines Designs für die Wiederverwendungsmethodologie erlauben, welche es erlaubt Komponenten zu entwerfen, welche leicht wiederverwendet werden können. Das Problem des Wiederverwendens von vorher entworfenen Komponenten liegt in den festen Kommunikationsprotokollen, welche sie verwenden, was Protokollumwandlungen notwendig macht, wenn Prozessoren mit verschiedenen Protokollen über eine Schnittstelle miteinander verbunden werden müssen. Gegenwärtig wird die Auswahl eines Protokolls vorgenommen, während die Komponente entworfen wird: das Funktions- und Kommunikationsverhalten werden intrinsisch miteinander vermischt. Eine gute Auswahl des Protokolls ist jedoch nur möglich, wenn alle Komponenten, welche in der Kommunikation mit einbezogen sind, bekannt sind. Daher muss ein Designumfeld für digitale Systeme es erlauben, dass eine Komponente anfänglich rein funktional beschrieben wird. Später, wenn die Komponente in einem System (wieder) verwendet wird, dann muss es das Designumfeld erlauben, in das am besten geeignete Kommunikationsverhalten umzuschalten. Dieser Ansatz steht im Gegensatz zu den laufenden Hardwaredesignpraktiken (VHDL), bei denen das Kommunikationsverhalten und das funktionale Verhalten vermischt sind.
Ein anderer Schlüsselansatz zur Meisterung der Komplexität des digitalen Systemdesigns liegt in den Mitteln der Modularität. In modularen Entwürfen wird die vollständige Funktionalität des Systems in Kommunikationskomponenten aufgespalten, welche eine Komplexität aufweisen, mit der man umgehen und die man managen kann. Der Vorteil dieses Ansatzes besteht darin, dass die Komponenten wiederverwendet werden können und dass das System leichter anzupassen und zu handhaben ist.
Der Nachteil liegt in dem Overhead wegen der Kommunikation zwischen den Komponenten oder weil der Kompilierer nicht über die Grenzen der Komponenten hinaus optimiert. Daher sollte die Kommunikation zwischen den Komponenten so gestaltet sein, dass die Modularität leicht entfernt werden kann, wenn zwei Komponenten in eine einzige Komponente zusammengeführt werden.
In der Vergangenheit hat man ein großes Ausmaß an Anstrengungen in den Entwurf von Umfeldern hineingesteckt, welche es erlauben, die Komponenten eines digitalen Systems zu implementieren.
Sprachen mit den dazugehörigen Simulatoren, fein abgestimmt in Richtung von spezifischen Anwendungsbereichen, erlauben es, Komponenten auf einem hohen Abstraktionsniveau zu spezifizieren und zu simulieren. Hardwarekompilierer können die Komponentenbeschreibung in Prozessoren mit hoch spezialisierten Architekturen hinein implementieren. Softwarekompilierer erlauben die Erzeugung von Maschinencode für programmierbare Standardprozessoren. Simulatoren von Befehlslisten erlauben eine Fehlerbeseitigung der Maschinencode auf verschiedenen Niveaus der Abstraktion (C, asm). Beispiele solcher Designumgebungen sind Cathedral-1/2/3, das ARM Prozessorwerkzeugpaket (der C-Kompilierer und der ARMulator) und die Synopsis Synthesewerkzeuge. Aus den obigen Ausführungen kann geschlossen werden, dass die Komponenten digitaler Systeme mit Standarddesignumgebungen implementiert werden können. Das, was fehlt, ist der Leim, welcher diese Designumgebungen miteinander verbindet und automatisch die Schnittstellen der erzeugten oder der Standardprozessoren gemäß der Systemspezifikation erstellt. Daher sollte eine Systemdesignumgebung es erlauben, bestehende Designumgebungen leicht mit einzuschließen. Sie sollte Synthesewerkzeuge bereitstellen für die Schnittstellenbildung zwischen Hardware/Hardware und Hardware/Software, welche unabhängig von dem Prozessor und von der Designumgebung sind. Um dieses zu erreichen, muss die Spezifikationsmethode es erlauben, Standardkomponenten auf einer Basis, wie sie gegeben ist, zu modellieren.
Zusammenfassend können die folgenden Anforderungen für eine Designumgebung eines Hardware/Software Systems definiert werden:

– Modularität ist wesentlich, um die Komplexität zu meistern, aber das Overhead sollte minimal sein und entfernt werden können.
– Verschiedene Beschreibungssprachen sind notwendig, um jeder Systemkomponente zu erlauben, mit dem am meisten geeigneten Paradigma beschrieben zu werden.
– Die Designumgebung muss in der Lage sein, die heterogene, konzeptuelle Spezifikation, die sich daraus ergebende heterogene Architektur und alle Verfeinerungsschritte dazwischen zu modellieren.
– Die Standardkomponenten und die dazugehörigen Designumgebungen müssen modelliert werden können.
– Eine klare Trennung zwischen dem funktionalen Verhalten und dem Kommunikationsverhalten ist erforderlich, um eine Wiederverwendung von Designs zu erlauben.
– Eine vom Prozessor unabhängige Schnittstellensynthese ist wesentlich.

Keine der Methodologien gemäß dem Stand der Technik erlaubt es, dass die Typen der Hardware/Software Architekturen vorher nicht bekannt sind, d. h. nur eine begrenzte Anzahl von vorher definierten Hardware/Software Architekturen sind verfügbar.
Zusammenfassung der Erfindung
Eine Designmethodologie und eine Designmaschine für eine Codesignumgebung eines Hardware/Software Systems wird in der vorliegenden Erfindung offenbart. Gemäß einem ersten Ziel der vorliegenden Erfindung wird ein Verfahren zur Erzeugung einer heterogenen Spezifikation einer heterogenen Implementierung eines Systems offenbart, wobei dieses System mindestens einen digitalen Systemteil umfasst und wobei die heterogene Spezifikation eine gewisse Anzahl von Datenmodellen und Paradigmen mit assoziierten Verhaltens- und Struktursprachen umfasst, wobei die heterogene Implementierung Hardwareteile und Softwareteile umfasst und die Implementierung Softwareuntersysteme von jenem System umfasst, wobei das Verfahren die folgenden Schritte umfasst:
ein Definieren eines ersten Satzes von primitiven Objekten in einer Datenbank, welche auf mindestens einem Computer kompiliert wird, welcher die besagte Spezifikation jenes Systems darstellt, wobei dasselbe die folgenden Unterschritte umfasst:
Unterschritt 1: ein Beschreiben der Spezifikation jenes Systems in einem oder in mehreren Verfahren, wobei ein jedes Verfahren einen funktionalen Aspekt jenes Systems darstellt, wobei jene Verfahren primitive Objekte sind;
Unterschritt 2: ein Definieren von Eingängen und ein Verbinden dieser Eingänge mit Kanälen, wobei diese Eingänge die Kommunikation zwischen jenen Verfahren strukturieren, und wobei jene Eingänge und jene Kanäle primitive Objekte sind, wobei ein Verfahren einen oder mehrere Eingänge hat;
Unterschritt 3: ein Definieren der Kommunikationssemantik jener Eingänge durch ein Protokoll, wobei dieses Protokoll ein primitives Objekt ist;
und danach
ein Erzeugen hierarchischer Objekte in jener Datenbank, während eine Implementierung jenes Systems durch eine Verfeinerung jener Spezifikation des Systems durch eine Verfeinerung jener primitiven Objekte erzeugt wird, wobei jene hierarchischen Objekte Verfeinerungen der primitiven Objekte sind und einen größeren Grad an Detaillierung aufweisen, während jene Kommunikationssemantik im wesentlichen bewahrt bleibt;
ein Auswählen von einer oder von mehreren Hardwarekomponenten, wobei diese Komponenten programmierbare Prozessoren umfassen;
ein Zuweisen von jenen verfeinerten Verfahren der besagten verfeinerten Spezifikation des Systems zu den Hardwarekomponenten, wobei diese verfeinerten Verfahren einem programmierbaren Prozessor zugewiesen werden, welcher ein Softwareuntersystem ist;
ein Auswählen von E/A Szenariomodellen für Eingänge von jenen verfeinerten Verfahren eines Softwareuntersystems, wodurch jene Eingänge von jenen verfeinerten Verfahren eines Softwareuntersystems mit der Schnittstelle jenes programmierbaren Prozessors verbunden werden, und wobei die Schnittstelle des programmierbaren Prozessors mit zweiten Eingängen verbunden wird, wobei diese zweiten Eingänge die Kommunikationssemantik jener Eingänge im wesentlichen aufrechterhalten.
Das Verfahren der vorliegenden Erfindung kann ferner den Schritt der Simulation jenes Systems umfassen.
Vorzugsweise umfasst das Verfahren der vorliegenden Erfindung ferner den Schritt der Verfeinerung des Kanals zwischen einem ersten und einem zweiten Eingang von jeweils einer ersten und einer zweiten Hardwarekomponente, wobei der erste und der zweite Eingang ein inkompatibles erstes und zweites Protokoll haben, wodurch ein hierarchischer Kanal geschaffen wird, und dieser hierarchische Kanal wandelt das erste Protokoll in das zweite Protokoll um.
In einer vorteilhaften Ausführung enthält das Verfahren der vorliegenden Erfindung ferner den Schritt der Erzeugung einer Netzwerkliste, welche die Layoutinformation jener Implementierung enthält.
In einem zweiten Aspekt der vorliegenden Erfindung wird eine Designmaschine geliefert zur Erzeugung einer heterogenen Implementierung eines Systems aus einer heterogenen Spezifikation, wobei dieses System mindestens einen digitalen Systemteil umfasst und wobei die heterogene Spezifikation eine gewisse Anzahl von Paradigmen umfasst mit assoziierten Verhaltens- und Struktursprachen, wobei die heterogene Implementierung Hardwareteile und Softwareteile umfasst, dadurch gekennzeichnet, dass jene Maschine so angeordnet ist, dass sie alle Schritte des Verfahrens gemäß der vorliegenden Erfindung ausführt.
Eine Designmaschine gemäß der vorliegenden Erfindung kann ferner Mittel zur Simulation jenes Systems umfassen, welches eine große Anzahl von Simulatoren für jene Verhaltens- und Struktursprachen umfasst.
Kurze Beschreibung der Zeichnungen
1 ist eine schematische Darstellung eines heterogenen digitalen Systems, welches verschiedene Spezifikationsparadigmen umfasst.
2 ist ein Ablaufdiagramm, welches das Verfahren des Hardware/Software Codesigns gemäß der vorliegenden Erfindung darstellt.
3 ist eine Darstellung der primitiven Objekte in der Datenbank und der Beziehungen zwischen den besagten primitiven Objekten.
4 ist eine Darstellung der hierarchischen Objekte in der Datenbank und der Beziehungen zwischen diesen hierarchischen Objekten und zwischen den primitiven Objekten und den hierarchischen Objekten.
5 ist eine Darstellung der Transformation des Prozessmischens.
6 ist ein Flowchart einer spezifischen Ausführung des Verfahrens der Implementierung für das Hardware/Software Codesign.
7 ist eine schematische Darstellung der Funktionalität der Erzeugung der Hardware/Software Schnittstelle.
8 ist eine schematische Darstellung eines besonderen E/A Szenarios, welches in der Datenbank modelliert wird.
9 ist ein Flowchart einer spezifischen Ausführung der Bauweise einer Hardware/Software Cosimulation.
10 ist ein Blockdiagramm eines typischen, heterogenen digitalen Systems: die Pager- bzw. Speicherseitenanwendung.
11 ist eine schematische Darstellung der Pageranwendung, wie sie in der vorliegenden Erfindung beschrieben wird.
12 ist ein Blockdiagramm des Pagers nach der Anwendung der Transformation des Prozessmischers.
13 ist ein Blockdiagramm des Pagers, nachdem die Kommunikationskanäle mit einem spezifischen Kommunikationsverhalten markiert worden sind.
14 ist eine Darstellung der Einführung des spezifischen Kommunikationsverhaltens in die Pageranwendung durch eine Verfeinerung eines primitiven Kanals in einen hierarchischen Kanal.
15 ist eine Darstellung der Implementierung eines Verfahrens in die Hardware, wobei die sich daraus sich ergebenden Untersysteme der Hardware eingekapselt werden, damit sie in Verbindung zueinander stehen können.
16 zeigt die Details der Einkapselung der Untersysteme der Hardware in dieser besonderen Anwendung.
17 ist eine Darstellung der Erzeugung einer Hardware/Software Schnittstelle zwischen einem Untersystem der Software, welches auf einem ARM Prozessor kompiliert worden ist, und einem Untersystem der Hardware.
Detaillierte Beschreibung der Erfindung
In dem Folgenden werden ein Designumfeld und eine Designmethodologie offenbart, welche den Anforderungen gerecht werden, welche da sind die Modularität, die Einkapselung von verschiedenen Beschreibungssprachen, die Modellierung von einer heterogenen, konzeptuellen Spezifikation zu einer sich daraus ergebenden heterogenen Architektur und alle dazwischen liegenden Schritte der Verfeinerung, die Fähigkeiten zur Modellierung von Standardkomponenten und den dazugehörigen Designumgebungen, die Trennung zwischen funktionalem und Kommunikationsverhalten und die Synthese einer vom Prozessor unabhängigen Schnittstelle. Diese Designumgebung wird im Folgenden CoWare genannt.
In dem Folgenden versteht es sich, dass die Konzeptverfeinerung eine Umwandlung oder eine Übersetzung oder eine Transformation einer Spezifikation eines elektronischen Systems in eine Implementierung bedeutet.
Diese Implementierung kann eine Architektur von Komponenten sein, welche dasselbe Verhalten zeigt wie jene Spezifikation oder welche jene Spezifikation ausführt. Diese Implementierung kann auch eine hinzugefügte Entwicklung in der Kette sein, welche zu der endgültigen Implementierung führt. Einzelheiten hinzuzufügen bedeutet, dass eine Implementierung spezifischer oder konkreter gestaltet wird als ein Ergebnis einer Implementierungsentscheidung auf einer früheren Stufe in der Kette, welche zu der endgültigen Implementierung führt. In die Einzelheiten zu gehen kann auch bedeuten, dass man ein materielles Objekt wie eine spezifische Komponente oder eine spezifische Kommunikation zwischen den Komponenten einfügt, im Gegensatz zu einem abstrakten Aspekt auf einer früheren Stufe in der Kette, welche zu einer endgültigen Implementierung führt. Andere Beispiele der Konzeptverfeinerung und der Konzepteinzelheiten können im Folgenden gefunden werden.
2 zeigt die Architektur des CoWaresystems. Das CoWaresystem unterstützt vier größere Designaktivitäten: die Cospezifikation 8, die Cosimulation 9, die Cosynthese 10 und die Interface- bzw. Schnittstellensynthese 11. Der Eingang ist eine heterogene Spezifikation eines elektronischen Systems, der Ausgang 12 ist eine Netzwerkliste der kommerziellen Werkzeuge nach dem Stand der Technik für die Erzeugung des Layouts der Implementierung. Dieser Ausgang umfasst vorzugsweise die strukturellen VHDL oder Verflog und Maschinencode für die programmierbaren Prozessoren.
Die Designumgebung der CoWare wird oben auf der Spitze eines Datenmodells implementiert, in welchem die Modularität mit Hilfe von Verfahren bereitgestellt wird. Verfahren enthalten Einkapselungen von Hostsprachen, welche verwendet werden, um die Systemkomponenten zu beschreiben. Eine Kommunikation zwischen Verfahren findet statt durch eine Verhaltensschnittstelle, welche Eingänge umfasst. Damit zwei Verfahren in der Lage sind, miteinander zu kommunizieren, müssen ihre Eingänge mit einem Kanal verbunden sein. Die Semantik der Kommunikation zwischen Prozessen beruht auf dem Konzept des Remote Procedure Call (RPC = Entfernter Prozeduraufruf). Das Datenmodell ist hierarchisch strukturiert und es ergibt die Möglichkeit Kanäle, Eingänge und Protokolle in Objekte einer niedrigeren Stufe zu verfeinern und Einzelheiten hinzuzufügen. Wir beziehen uns auf das abstrakteste Objekt als ein primitives Objekt. Ein Objekt, welches mehr Implementierungseinzelheiten enthält, wird als ein hierarchisches Objekt bezeichnet.
Wir erörtern zuerst die primitiven Objekte. Die hierarchischen Objekte werden verwendet, um das Kommunikationsverhalten des Systems zu verfeinern, und sie werden nachher diskutiert.
Ein Verfahren ist ein Behälter für eine gewisse Anzahl von Einkapselungen einer Hostsprache einer Komponente. Ein einzelnes Verfahren kann vielfache Einkapselungen von Hostsprachen aufweisen, welche verschiedene Implementierungen für dieselbe Komponente beschreiben, oder für dieselbe Komponente, die auf verschiedenen Abstraktionsniveaus dargestellt ist.
Eine Einkapselung einer Hostsprache beschreibt eine Komponente in einer spezifischen Hostsprache. Vorzugsweise C, C++, DFL, VHDL und Verflog werden von Hostsprachen unterstützt. Eine Einkapselung einer CoWaresprache wird verwendet, um die Struktur des Systems zu beschreiben. In einer Einkapselung einer CoWaresprache kann man Verfahren instantiieren und ihre Eingänge mit Kanälen verbinden.
Andere Einkapselungen einer Hostsprache umfassen den Zusammenhang und eine Anzahl von Ausführungseinheiten. Der Zusammenhang und die Ausführungseinheiten enthalten einen Code, der in der Hostsprache der Einkapselung geschrieben ist. Der Zusammenhang enthält einen Code, der allen Ausführungseinheiten in der Einkapselung gemeinsam ist, d. h. Variable/Signale und Funktionen, wie sie von der Semantik der Hostsprache zugelassen sind. Der Zusammenhang als solcher liefert die Kommunikation zwischen den Ausführungseinheiten (Intra-Prozesskommunikation).
Jedes primitive CoWareverfahren (symbolisiert durch eine Ellipse 13 in 2) kapselt verzahnt verlaufende Programme von Ausführungseinheiten in einer Hostsprache der Wahl ein. Verzahnte Ausführungseinheiten kommunizieren über einen gemeinsam geteilten Speicherplatz innerhalb eines Prozesses miteinander. Eine Inter-Prozesskommunikation erfolgt über unidrektionale Kanäle unter Verwendung eines Remote Procedure Call (RPC) Protokolls (= entfernter Prozeduraufruf). Die Gründe dieser Wahl sollen unten erklärt werden.
Man beachte, dass auf diesem Wege eine heterogene Spezifikation unterstützt wird: beides, sowohl Hardware- und Softwareaspekte, Struktur- und Verhaltensaspekte sowie verschiedene Spezifikationen von Paradigmen (Datenfluss, Steuerfluss, ...) können verbunden werden.
Eine Cospezifikation erlaubt es, eine funktionale Spezifikation zu beschreiben, welche auf dem Konzept miteinander kommunizierender CoWareverfahren beruht.
Ein wichtiges Konzept von CoWare besteht darin, dass grundsätzlich keine Unterscheidung gemacht wird zwischen einer Cosimulation und einer Cosynthese. Beide beruhen auf dem Konzept der Verfeinerung der Spezifikation für die Implementierung, der Wiederverwendung bestehender Kompilierer, Emulatoren und Simulationsverfahren.
In der Verfeinerung für die Cosynthese führt der Designer eine interaktive Grobunterteilung der Spezifikationen über die einem Nutzer zugeteilte Architektur durch. Dies führt zu einer Vereinigung von mit dem Komponentenkompilierer konsistenten Verfahren, welche dazu bestimmt sind auf derselben Komponente abgebildet zu werden. Mit dem Komponentenkompilierer konsistente Verfahren haben eine Einkapselung in derselben Hostsprache. Das Vereinigen bzw. Zusammenführen besteht in einer mitlaufenden Verarbeitung der RPC Aufrufe zwischen jenen Verfahren und es führt zu zwei Unterproblemen: die Abbildung der verzahnten Ausführungseinheiten in den Verfahren auf einem Prozessor unter Wiederverwendung der bestehenden Komponentenkompilierer 14, 15, 16, 17, 18, 19 und die Verfeinerung der Kommunikation zwischen den Verfahren in den Hardware- und in den Softwarekommunikationsprotokollen, welche dieselben implementieren. Auf die Implementierung von verzahnten Ausführungseinheiten und auf die Intra-Prozesskommunikation muss sorgfältig geachtet werden unter Verwendung von Echtzeitbetriebssystemen (RTOS = Real-Time Operating Systems), Mikrokernen oder einer Softwaresynthese im Falle von programmierbaren Prozessoren oder durch Bereitstellung einer auf einer Bibliothek beruhenden Schale eines Kommunikationsprotokolls um die bestehenden Hardwaresynthesewerkzeuge herum. Eine Verfeinerung der Inter-Prozesskommunikation bedeutet wieder eine Verfeinerung der primitiven RPC Kommunikation durch eine Ausweitung der Kommunikationseingänge in implementierbare Protokolle, welche in einer Protokollbibliothek 20 verfügbar sind. Es ist auch möglich, Kanalverfahren abstrakten Kanälen zuzuweisen.
Im Prinzip ist alles dieses offen für den Nutzer, welcher seine eigene Bibliothek für Kommunikationsprotokolle hinzufügen kann. Andererseits liefert CoWare in dem SYMPHONY Werkzeugkasten 21 eine Methodologie für die Schnittstellensynthese, wobei jeder Kommunikationskanal durch die Auswahl eines Kommunikationsszenarios verfeinert wird. Auf diesem Wege ist eine automatische Synthese von Hardware/Hardware und Hardware/Software Schnittstellen möglich, einschließlich der Erzeugung von Softwaretreibern in programmierbaren Prozessoren. Dies ist ein wesentlicher Teil des Hardware/Software Codesigns.
Nach der Kompilierung aller Komponenten ist alle Hardware verfügbar als eine strukturierte VHDL und alle Software für die Prozessoren liegt in C vor, welche auf dem Hostkompilierer der programmierbaren Komponenten kompiliert werden kann. Der abschließende Schritt besteht darin, all diese Synthese- und Hardwarebeschreibungen zu verbinden, um kommerzielle Back-End Werkzeuge anzutreiben und ein Layout zu erzeugen.
In 3 enthalten das Verfahrenssystem 22 und das Untersystem 23 eine Einkapselung einer CoWaresprache. Die Einkapselung der CoWaresprache des Systems 22 beschreibt, wie sie von einem Fall eines Untersystems 23 und von einem Fall von P4 (24) aufgebaut wird. Ein jedes der Verfahren P1 (25), P23 (26) und P4 (24) enthält eine Einkapselung einer C Sprache.
Eingänge sind Objekte, durch welche Verfahren kommunizieren. Ein primitiver Eingang ist durch ein Protokoll und durch einen Parameter eines Datentyps gekennzeichnet.
Es gibt einen impliziten Eingang, den Aufbaueingang, an dem ein RPC genau einmal beim Systemstart durchgeführt wird.
In 3 hat das Verfahren P23 (26) zwei primitive Eingänge p2 (27) und p3 (28), nahe bei dem impliziten Aufbaueingang gelegen.
Protokolle definieren die Kommunikationssemantik eines Einganges. Ein primitives Protokoll ist das eines Masters, eines Inmasters, eines Outmasters, eines Inoutmasters, eines Slaves, eines Inslaves, eines Outslaves, eines Inoutslaves. Jedes primitive Protokoll weist auf einen anderen Weg des Datentransports hin. Das Präfix in, out und inout weist auf die Richtung der Daten hin. Das Postfix master, slave weist auf die Richtung der Steuerung hin: ob das Protokoll einen RPC aktiviert (Master) oder einem RPC dient (Slave). In dem übrigen Teil dieses Textes werden Eingänge mit einem Slave/Master Protokoll gewöhnlich als Slave/Master Eingänge bezeichnet.
In 3 werden die Master Eingänge (29, 30) durch die kleinen schattierten Rechtecke auf einem Perimeter des Verfahrens dargestellt. Slave Eingänge (27, 28) werden durch kleine offene Rechtecke auf dem Perimeter dargestellt. Die Richtung der Daten eines Einganges wird dargestellt durch einen Pfeil, welcher mit einem Eingang verbunden ist. In 3 ist der Eingang p1 (29) ein Outmaster Eingang und der Eingang p2 (27) ist ein Inslave Eingang.
Ein Protokoll kann weiterhin einen Indexsatz aufweisen. Die Indices in diesem Indexsatz werden dazu verwendet, um eine Zusatzinformation über die Daten, welche transportiert werden, zu überwachen. Zum Beispiel wird das primitive Protokoll, welches verwendet wird, um den Speichereingang eines Prozessors zu modellieren, einen Index haben, um die Adresse der Daten zu modellieren, welche auf den Speichereingang gelegt werden.
Eine Ausführungseinheit ist ein einzelner Steuerfluss innerhalb eines Verfahrens. Eine Ausführungseinheit enthält einen Code in der Hostsprache der Einkapselung, von welcher die Ausführungseinheit ein Teil ist. Der Code in einer Ausführungseinheit wird ausgeführt gemäß der Semantik der Hostsprache. Wir unterscheiden zwischen Slave Ausführungseinheiten und autonomen Ausführungseinheiten.
Slave Ausführungseinheiten sind eindeutig den Slave Eingängen zugeordnet und ihr Code wird ausgeführt, wenn der Slave Eingang aktiviert wird (d. h. wenn ein RPC an dem Slave Eingang durchgeführt wird). Es gibt eine besondere Slave Ausführungseinheit, welche dem impliziten Aufbaueingang zugeordnet ist und welche verwendet werden kann, um das Verfahren in Gang zu setzen.
In 3 enthält das Verfahren P23 (26) zwei reguläre Slave Ausführungseinheiten (31, 32), welche jeweils den Slave Eingängen p2 (27) und p3 (28) zugeordnet sind, nahe gelegen bei der speziellen Aufbau Slave Ausführungseinheit (33).
Autonome Ausführungseinheiten werden nicht irgendeinem Eingang zugeordnet und ihr Code wird nach der Systeminitialisierung in einer unendlichen Schleife ausgeführt.
In 3 enthält ein jedes der Verfahren P1 (25) und P4 (24) eine autonome Ausführungseinheit (34).
Eine Einkapselung einer Sprache kann mehrfache Slave und autonome Ausführungseinheiten enthalten, welche im Prinzip alle gleichzeitig zur Ausführung ablaufen.
Ein Kanal ist eine Punkt-zu-Punkt Verbindung eines Master Einganges und eines Slave Einganges. Zwei Eingänge, welche durch einen Kanal miteinander verbunden sind, können Daten miteinander austauschen. Kanäle können uni- oder bidirektional sein. Ein primitiver Kanal liefert eine ungepufferte Kommunikation. Er hat kein Verhalten: er ist ein Medium für den Datentransport. In der Hardware ist er mit Drähten implementiert. In der Software ist er mit einem (möglicherweise mitlaufenden) Funktionsaufruf implementiert. Auf diesem Wege modellieren primitive Kanäle die grundlegenden Grundroutinen der Kommunikation, welche man zurück bis in die Software- und Hardware Beschreibungssprachen findet.
Im einem engen Sinne sind nur Punkt-zu-Punkt Kanäle erlaubt, welche einen Master Eingang mit einem Slave Eingang verbinden. Ein Experte auf diesem Gebiet kann jedoch leicht diese Beschränkung entfernen, um Kanäle zu erlauben, welche zwei Master Eingänge oder zwei Slave Eingänge miteinander verbinden, oder um zu erlauben, dass Kanäle mehrfache Slave Eingänge und mehrfache Master Eingänge verbinden können.
Solch eine erweiterte Beschreibung kann auf das Basismodell übertragen werden unter Verwendung eines Vorgabe (Default) oder vom Benutzer definierten Übersetzungsschemas.
In der 3 gibt es einen primitiven Kanal (35), welcher den Eingang p1 (29) des Verfahrens P1 (25) mit dem Eingang p2 (27) des Verfahrens P23 (26) verbindet.
Kommunikation findet immer zwischen zwei Ausführungseinheiten statt. Kommunikation zwischen Ausführungseinheiten, welche Teile desselben Verfahrens sind, wird als Intra-Prozesskommunikation bezeichnet. Kommunikation zwischen Ausführungseinheiten in verschiedenen Verfahren sind, wird als Inter-Prozesskommunikation bezeichnet.
Intra-Prozess (Inter-Ausführungseinheits)kommunikation wird durchgeführt, indem man die Verwendung von gemeinsam geteilten Variablen/Signalen in Anspruch nimmt, welche in dem Zusammenhang des Verfahrens deklariert werden. Um zu vermeiden, dass zwei Ausführungseinheiten auf dieselbe Variable zur gleichen Zeit zugreifen, ist die Hostsprache abhängig. Es liegt in der Verantwortung des Benutzers, kritische Abschnitte durch Verwendung der Mechanismen, welche in der Hostsprache bereitgestellt werden, zu schützen.
In der 3 tritt die Intra-Prozesskommunikation in dem Verfahren P23 (26) auf.
Die Variable tmp (36), welche in dem Zusammenhang (37) deklariert worden ist, wird von der Slave Ausführungseinheit p2 (31) und von der Slave Ausführungseinheit p3 (32) gemeinsam geteilt.
Inter-Prozess (Inter-Ausführungseinheits)kommunikation mit einem primitiven Protokoll beruht auf RPC. An einem Master Eingang kann die RPC Funktion verwendet werden, um eine Ausführungseinheit in einem entfernten Verfahren zu starten. Auf einen Master Eingang kann von irgendwoher in der Einkapselung der Hostsprache (Zusammenhang, autonome Ausführungseinheiten, Slave Ausführungseinheiten) zugegriffen werden mit Ausnahme von der Ausführungseinheit der Aufbaueinheit.
Die RPC Funktion kehrt zurück, wenn die Slave Ausführungseinheit vollendet ist, d. h. wenn alle die Anweisungen in dem Code der Slave Ausführungseinheit ausgeführt sind. In der Slave Ausführungseinheit (eindeutig einem Slave Eingang zugeordnet) können die Lese- und Schreibfunktionen verwendet werden, um auf die Daten des Slave Einganges zuzugreifen.
Die Indexfunktion wird verwendet, um auf die Indices des Protokolls des Einganges zuzugreifen. Die RWbar Funktion wird an einem Inoutslave Eingang verwendet, um die tatsächliche Richtung des Datentransportes zu bestimmen. Auf einen Slave Eingang kann nur von innerhalb seiner mit ihm verbundenen Ausführungseinheit zugegriffen werden.
Ein bidirektionaler Eingang kann verwendet werden, um beides zu tun, sowohl um Daten zu senden als auch um Daten zu empfangen.
Gemäß der strikten RPC Semantik kann dies jedoch nicht von demselben RPC Aufruf getan werden. In einem einzelnen RPC Aufruf verwendet man den bidirektionalen Eingang entweder in der Eingabe- oder in der Ausgaberichtung, aber nicht in beiden Richtungen. Für einen Experten auf diesem Gebiet ist es leicht, die strikte RPC Semantik auf eine volle mit Pfeilen versehene Funktionsaufrufsemantik auszudehnen, bei der Argumente an ein entferntes Verfahren übergeben und die Ergebnisse zurückerhalten werden.
In der 3 tritt die Inter-Prozesskommunikation zwischen den Verfahren P1 (25) und P23 (26) über den Kanal (35) auf. Wenn die RPC Anweisung (38) in der autonomen Ausführungseinheit (34) erreicht wird, dann wird der Wert der lokalen Variablendaten (39) auf den Kanal (35) gegeben und die Steuerung wird an die Slave Ausführungseinheit p2 (31) übergeben. Die autonome Ausführungseinheit (34) wird angehalten, bis die letzte Anweisung der Slave Ausführungseinheit (31) ausgeführt ist. Danach nimmt der autonome Ausführungseinheit (34) ihre Ausführung wieder auf durch Ausführung der Anweisung (40) nach der RPC Anweisung (38).
Durch die Verwendung primitiver Kanäle, Eingänge und Protokolle konzentriert sich der Designer erstens auf die Funktionalität des Systems, während er von den Terminals, Signalen und Handshakes absieht. Wenn sich der Designer erst einmal davon überzeugt hat, dass die Verfahren des Systems funktional korrekt sind, dann kann das Kommunikationsverhalten des Systems verfeinert werden. Die Verfeinerung der Kommunikation in CoWare wird ausgeführt, indem man die in der Kommunikation mit einbezogenen Objekte (Kanäle, Eingänge und Protokolle) hierarchisch macht.
Hierarchische Kanäle sind Verfahren, welche einem primitiven Kanal ein gegebenes Kommunikationsverhalten zuordnen. Die Verhaltensschnittstelle eines hierarchischen Kanals ist festgelegt durch die Eingänge, welche durch den primitiven Kanal verbunden sind. Einen Kanal hierarchisch zu machen, kann das Kommunikationsverhalten zweier verbundener Verfahren drastisch ändern. Es kann zum Beispiel die Verfahren durch Hinzufügung von Puffern parallelisieren (Pipeline). Die eine Eigenschaft, welche erhalten bleibt, indem man einen Kanal hierarchisch macht, ist die Richtung des Datentransportes.
In 4 wird der primitive Kanal (41) zwischen den Verfahren P1 (42) und P23 (43) verfeinert in einen hierarchischen Kanal (44) mit FIFO Verhalten. Der FIFO hierarchische Kanal (44) entkoppelt die autonome Ausführungseinheit des Verfahrens P1 (42) und die Slave Ausführungseinheit, welche zu dem Eingang p2 (45) des Verfahrens P23 (43) gehört. Die Wirkung besteht darin, dass die Geschwindigkeit, mit welcher das Verfahren P1 (42) RPCs ausgeben kann, nicht länger bestimmt wird von der Geschwindigkeit, mit welcher das Verfahren P23 (43) den RPCs dienen kann. Der FIFO hierarchische Kanal (44) berücksichtigt das notwendige Puffern der Daten.
Hierarchische Kanäle sind Verfahren, welche ein gegebenes Kommunikationsverhalten einem primitiven Eingang zuordnen. Die Verhaltensschnittstelle des hierarchischen Eingangs ist teilweise festgelegt durch den primitiven Eingang, den dieselbe verfeinert. Das hierarchische Eingangsverfahren sollte einen Eingang haben, welchen wir den Rückkehreingang nennen, welcher kompatibel mit dem primitiven Eingang ist. Einen primitiven Eingang hierarchisch zu machen, erhält die Richtung der Daten (in/out). Zwei Eingänge sind kompatibel, wenn ihre primitiven Protokolle kompatibel sind, wenn sie denselben Datentyp haben und wenn sie gleiche Protokollindices haben. Die folgenden primitiven Protokolle sind kompatibel: (master, slave); (inslave, outmaster); (inslave, inoutmaster); (outslave, inmaster); (outslave, inoutmaster); (inoutslave, inmaster); (inoutslave, outmaster); (inoutslave, inoutmaster). Zwei hierarchische Protokolle sind kompatibel, wenn ihre primitiven Protokolle kompatibel sind und wenn sie denselben Namen haben.
In der 4 wird eine bestimmte Datenformatierung für die Daten festgelegt, welche über den Kanal (41) zwischen dem Verfahren P1 (42) und dem FIFO hierarchischen Kanal (44) transportiert werden. Dies wird erreicht, indem man die primitiven Eingänge p1 (46) und links (47) hierarchisch macht. Das Formatierungsverfahren (48), welches den Eingang p1 (46) verfeinert, könnte zum Beispiel einen zyklischen Redundanzcheck zu den Daten hinzufügen, welche transportiert werden. Das Nichtformatverfahren (49), welches den Eingang links (47) des FIFO hierarchischen Kanals (44) verfeinert, nutzt dann diesen zyklischen Redundanzcheck, um zu bestimmen, ob die erhaltenen Daten gültig sind. Die tatsächlichen Daten und der zyklische Redundanzcheck werden sequentiell über denselben primitiven Kanal zwischen den Eingängen op (50) und ip (51) gesandt. Als eine Konsequenz ist die Geschwindigkeit zwischen dem Formatierungsverfahren (48) und dem Nichtformatverfahren (49) das Zweifache der Geschwindigkeit des Verfahrens P1 (42).
Primitive Protokolle liefern eine Klassifikation von allen hierarchischen Protokollen. Ein primitives Protokoll bestimmt die Kommunikationssemantik, aber nicht die Kommunikationsimplementierung: es setzt nicht das Zeitdiagramm fest, welches in der Kommunikation verwendet wird. Hierarchische Protokolle verfeinern primitive Protokolle mit einem Zeitdiagramm und den dazugehörigen E/A Terminals. Hierarchische Protokolle sind Modelle einer hohen Stufe für alternative Implementierungen eines primitiven Protokolls: sie bewahren beides, sowohl die Richtung der Daten als auch die Steuerung der Richtung des primitiven Protokolls.
Um auf die Terminals des hierarchischen Protokolls zuzugreifen, wird zur gleichen Zeit ein hierarchischer Eingang eingeführt. Auf die Terminals kann von dem Code aus dem Inneren der Ausführungseinheit zugegriffen werden, indem man die Funktionen Put, Sample und Wait verwendet.
In der 4 werden das primitive Protokoll des Einganges (50) und der ip Eingang (51) des Formatierungsverfahrens (48) und des Nichtformatverfahrens (49) in das RS232 Protokoll (52) verfeinert. In dem hierarchischen Eingang (53) RS232 wird ein in dem Formatierungsverfahren (48) auf dem op Eingang (50) ausgegebener RPC (54) in Handhabungen und Beeinflussungen der Terminals (55) umgewandelt gemäß einem Zeitdiagramm (56).
Das CoWaremodell ist auf einem Computer oder auf einer großen Anzahl von Computern implementiert und ein Satz von Schnittstellen (API) Funktionen von Anwendungsprogrammierern ist verfügbar.
Wenn eine Beschreibung eines CoWaresystems geparst (syntaktisch analysiert) wird, wird eine Darstellung des Systems im Speicher hergestellt, in dem die Objekte der Beschreibung aufeinander bezogen sind. Alle Werkzeuge der CoWareumgebung verwenden diese API Funktionen, um die Systembeschreibung zu analysieren, zu beeinflussen und zu verfeinern.
Auf Grund der Auswahl der RPC als eine Inter-Prozess Kommunikation, der Klassifikation der Protokolle und des Strukturierens eines Verfahrens in Einkapselungen mit dem Zusammenhang und mit den Ausführungseinheiten kann eine Transformation einer Verfahrenszusammenführung implementiert werden.
Das Ziel dieser Transformation besteht darin, eine Anzahl von Verfahrensexemplaren, welche in derselben Hostsprache beschrieben sind, in einer Einkapselung einer einzelnen Hostsprache zu verbinden, welche dann durch einen Kompilierer der Hostsprache auf einen einzelnen Prozessor abgebildet werden kann.
In dem Verfahren der Zusammenführung werden alle entfernten Verfahrensaufrufe mitlaufen: jede Slave Ausführungseinheit ist mit einbezogen in den Code der Ausführungseinheit, welcher dieselbe durch eine RPC Anweisung aufruft. Wegen der Semantik der RPC Kommunikation ändert diese Transformation nicht das Verhalten des ursprünglichen Systems, vorausgesetzt, dass man darauf achtet, ein Zusammentreffen von Namen zu vermeiden. Das Ergebnis der Zusammenführung ist eine Einkapselung einer einzelnen Hostsprache, welche einen einzelnen Zusammenhang enthält, eine einzelne Aufbauausführungseinheit, eine oder mehrere autonome Ausführungseinheiten, möglicherweise mehrfache Slave Ausführungseinheiten, um RPC Anfragen von externen Verfahren (nicht in die Transformation der Verfahrenszusammenführung mit einbezogen), möglicherweise mehrfache RPCs zu Slave Ausführungseinheiten in externen Verfahren (nicht in die Transformation der Verfahrenszusammenführung mit einbezogen) zu bedienen.
Die 5 zeigt die Wirkung der Zusammenführung der Verfahrensexemplare (25, 26) in das Verfahrensuntersystem (23) der 3. Das Verfahrensuntersystem (57) hat eine CoWare Spracheneinkapselung. Nach der Zusammenführung der Exemplare (58, 59) erhalten wir eine C Spracheneinkapselung (60), welche zu dem Verfahrensuntersystem hinzugefügt wird.
Der Vorteil der Verfahrenszusammenführung besteht darin, dass die mitlaufende Transformation den Overhead, welcher die Ausführung der (entfernten) Verfhrensaufrufe begleitet, entfernt. Sie vermindert weiterhin. die Anzahl verzahnter Ausführungseinheiten und daher den Overhead, welcher das Umschalten zwischen den Ausführungseinheiten begleitet. Schließlich erlaubt sie den Kompilierern der Hostsprache, eine Optimierung über die Grenzen der ursprünglichen Verfahren hinaus durchzuführen.
Die Eingangs- und Protokollhierarchie liefert eine klare Trennung zwischen dem funktionalen Verhalten und dem Kommunikationsverhalten. Normalerweise gemäß der Tradition enthält die Beschreibung einer Komponente beides, sowohl das funktionale Verhalten als auch das Kommunikationsverhalten in einer verschachtelten Art und Weise. Wenn solch eine Komponente wieder verwendet werden soll in einer anderen Umgebung als in der, für die sie ursprünglich vorgesehen war, dann muss der Designer diese Teile der Beschreibung der Komponente, welche mit der Kommunikation zu tun hat, ändern. In CoWare wird ein Verhalten einer Komponente durch ein Verfahren beschrieben, welches Gebrauch von RPC macht, um mit der Welt außerhalb zu kommunizieren. Solche Verfahren können miteinander verbunden werden, ohne dass ihre Beschreibung (Modularität) verändert wird. Indem man primitive Eingänge und primitive Protokolle verwendet, konzentriert sich der Designer auf die Funktionalität des Systems, während er von den Terminals, Signalen und Handshakes abstrahiert.
Später, wenn die Komponente in ein System instantiiert ist, dann wird das primitive Protokoll in das am besten geeignete hierarchische Protokoll verfeinert, wobei mit Rücksicht genommen wird auf die anderen mit einbezogenen Komponenten. Dies setzt das Zeitdiagramm und die Terminals fest, welche verwendet werden, um über jenen Eingang zu kommunizieren. Der Eingang, welcher das hierarchische Protokoll enthält, ist hierarchisch gemacht, um das erforderliche Kommunikationsverhalten hinzuzufügen, welches das Zeitdiagramm des ausgewählten hierarchischen Protokolls implementiert. Wieder wird dies erreicht, ohne dass die Beschreibung irgendeines der mit einbezogenen Verfahren verändert wird.
Wegen dieser Eigenschaft ist es machbar, Bibliotheken von Funktionsbausteinen und Bibliotheken von Kommunikationsblöcken aufzubauen, welche wieder verwendbar sind: sie können zusammengesteckt werden, ohne dass man ihre Beschreibung verändert. Nachdem die Blöcke zusammengesteckt worden sind, kann irgendein Kommunikationsoverhead (Ketten von entfernten Verfahrensaufrufen) entfernt werden durch ein Mitlaufen der Slave Ausführungseinheiten, welche den RPCs dienen. Das Ergebnis ist eine Beschreibung der Komponente, in welcher die Funktion und die Kommunikation nahtlos miteinander verschachtelt sind und welche in Software oder Hardware so effizient kompiliert werden kann wie eine Beschreibung in dem traditionellen Designverfahren.
Das obige Verfahren vermindert die Menge an Protokollumwandlungen, welche auf der Systemstufe benötigt werden, und es erlaubt, die Auswahl des Kommunikationsprotokolls und seiner Implementierung bis in die späte Phase des Designverfahrens zu verschieben, und auf diese Weise erreicht man die Anforderungen an ein „Design für die Wiederverwendung". Das Konzept der hierarchischen Protokolle ist auch nützlich, um die Standardkomponenten („Wiederverwendung des Designs") zu modellieren, weil die Zeitdiagramme, gemäß denen ein Prozessor kommuniziert, darin abstrahiert sind.
Die Eingabe zu dem Verfahren der Verfeinerung der Implementierung ist eine funktionale Spezifikation: eine Einkapselung einer CoWaresprache, welche aus einer Anzahl von Verfahrensexemplaren besteht (d. h. Einkapselungen einer Hostsprache), welche beides darstellen, sowohl ein Intra-Prozess- als auch ein Inter-Prozesskommunikationsverhalten. In einem ersten Schritt wird eine Zuordnung durchgeführt. In diesem Schritt werden die Anzahl und der Typ von Prozessoren ausgewählt, welche als das Ziel für das Implementieren der Eingabespezifikation dienen werden. Nach der Zuordnung der notwendigen Prozessorressourcen wird ein Zuweisungsschritt durchgeführt. In diesem Schritt wird jedes Verfahrensexemplar der Eingabespezifikation zu einem der zugeordneten Prozessoren zugewiesen.
Der Rest des Implementierungsweges ist in 6 dargestellt.
Alle Verfahrensexemplare, welche an einen einzelnen Prozessor gebunden sind, werden zusammengeführt. Dies führt zu einem System mit einer eins – zu – eins Abbildung zwischen den (zusammengeführten) Verfahren und den zugeordneten Prozessoren. In der 6 sind alle DFL Verfahren (61) in ein einzelnes DFL Verfahren (63) zusammengeführt (62).
Die Einkapselung der Hostsprache eines jeden (zusammengeführten) Verfahrensexemplars muss jetzt kompiliert werden auf seinem Zielprozessor unter Verwendung eines Kompilierers der Hostsprache. Dies umfasst die folgenden Schritte:

(1) Die CoWare Konzepte einer autonomen Ausführungseinheit, einer Slave Ausführungseinheit und eines gemeinsam geteilten Zusammenhangs werden auf dem Zielprozessor implementiert.
(2) Die Inter-Prozesskommunikation wird implementiert.
(3) Die resultierenden Prozessoren werden so eingekapselt, dass sie mit dem Rest des Systems verbunden werden können.

In dem Schritt (1) werden bestehende (kommerziell verfügbare) Kompilierer von Hostsprachen wieder verwendet. Wenn solch ein Kompilierer einer Hostsprache nicht direkt die CoWare Konzepte einer autonomen Ausführungseinheit, einer Slave Ausführungseinheit und eines gemeinsam geteilten Zusammenhangs unterstützt, dann unterstützt die CoWare Umgebung zwei Alternativen:

– der Kompilierer der Hostsprache wird ausgedehnt auf Bibliotheken, welche solche Konzepte unterstützen (Multi- Ausführungseinheiten-Bibliothek);
– eine Softwaresynthese wird durchgeführt, um die Einkapselung der Hostsprache zu übersetzen in eine Beschreibung, welche von dem Kompilierer der Hostsprache bewerkstelligt werden kann.

In der 6 wird das DFL Verfahren (63) mit dem Cathedral Kompilierer (64) kompiliert. Das Ergebnis ist eine VHDL Netzliste (65) der Implementierung.
In Schritt (2), wenn das Verfahren auf einem nicht programmierbaren Prozessor kompiliert wird, umfasst die Implementierung der Inter-Prozesskommunikation die Schritte der Verfeinerung der primitiven Eingänge/Protokolle in geeignete hierarchische Eingänge/Protokolle und die Zusammenführung der hierarchischen Eingänge mit dem Verfahren.
In 6 werden die hierarchischen Eingänge (66) zu den VHDL Verfahren (67) hinzugefügt. Nach dem Zusammenführen (68) aller Verfahren (67) wird das resultierende VHDL Verfahren (69) kompiliert mit dem Synopsis Kompilierer (70).
In der Stufe (2), wenn das Verfahren auf einem programmierbaren Prozessor kompiliert wird, umfasst die Implementierung der Inter-Prozesskommunikation die Schritte der Erzeugung von Gerätetreibern und der Erzeugung von Hardware Schnittstellen. Ein Softwarewerkzeug wird verwendet, um dies zu erreichen. Im Folgenden wird dieses Werkzeug SYMPHONY genannt. Die 7 verdeutlicht das Werkzeug SYMPHONY.
SYMPHONY macht Gebrauch von einem Softwaremodell (71) und von einem Hardware Modell (72) des Zielprozessors und von einer Bibliothek von E/A Szenarien (73) für diesen Prozessor. Das Hardware Modell (72) des programmierbaren Prozessorkernes besteht aus einer Einkapselung einer HDL Hostsprache, welche die Information formalisiert, welche in dem Hardware Abschnitt des Datenblattes des programmierbaren Prozessorkernes verfügbar ist. Die Einkapselung der HDL Hostsprache des Hardware Modells ist gekennzeichnet durch eine Verhaltensschnittstelle, welche mit der Hardware Schnittstelle des programmierbaren Prozessors konform ist. Alle Eingänge (74) haben hierarchische Protokolle: sie bestehen aus Terminals und aus einem Zeitdiagramm. Das Hardware Modell kann auch eine HDL Beschreibung enthalten, entweder für eine black box, für ein Simulationsmodell oder für die volle Beschreibung des Prozessorkernes.
Das Software Modell (71) des programmierbaren Prozessorkernes besteht aus einer Einkapselung einer Software Hostsprache, welche die Information formalisiert, welche in dem Software Abschnitt des Datenblattes des programmierbaren Prozessors verfügbar ist. Die Einkapselung der Software Hostsprache des Software Modells ist gekennzeichnet durch eine Verhaltensschnittstelle, welche konform mit der Softwareschnittstelle des programmierbaren Prozessorkernes ist. Alle Eingänge (75) haben primitive Protokolle. Das Software Modell identifiziert zum Beispiel, welche Eingänge verwendet werden können, um Daten in den Prozessorkern hinein oder aus dem Prozessorkern heraus zu erhalten (speicheradressiert, Coprozessoreingang, ...), welche Eingänge als Unterbrechungseingänge verwendet werden können und was ihre Eigenschaften sind (Unterbrechungspriorität, maskierbare Unterbrechung, ...). Zusätzlich enthält das Software Modell eine Verhaltensbeschreibung, welche es erlaubt eine Einkapselung einer Software Hostsprache in Maschinencode zu kompilieren. Zum Beispiel: Funktionen zum Managen von prozessorspezifischen Aktionen wie; Installieren eines Interruptvektors (Unterbrechungsvektors), Freigeben/Sperren der Unterbrechungen usw. In 7 ist das Software Modell des ARM-6 RISC Prozessors gezeigt. Eine Anzahl seiner Eingänge (75) ist in 7 gezeigt. Der Speichereingang mem ist als ein (bidirektionaler) Slave Eingang modelliert. Auf diesen Slave Eingang wird über den Gerätetreiber mit Hilfe eines RPC zugegriffen, um Daten zu schreiben/lesen auf/von der externen Hardware. Die Slave Ausführungseinheit, modelliert in dem Software Modell und dem mem Slave Eingang zugeordnet, übersetzt den eingehenden RPC an dem Speicherzugang. SYMPHONY stellt die Verbindung zwischen den Gerätetreibern und dem mem Eingang her. Der fiq Eingang wird als ein master Eingang modelliert. Das Software Modell des ARM Prozessors gewährleistet, dass jedes Mal dann ein RPC an diesem Eingang durchgeführt wird, wenn der Prozessor nachweist, dass eine Unterbrechung aufgetreten ist. SYMPHONY verbindet den fiq Eingang mit einer Slave Ausführungseinheit, welche als die Interruptserviceroutine dient, so dass die Routine automatisch gestartet wird.
In der 7 ist das Hardware Modell des ARM-6 RISC Prozessors gezeigt. Eine Anzahl seiner Eingänge (74) ist in 7 gezeigt. Der Speichereingang mem ist als ein (bidirektionaler) Master Eingang modelliert. Das Hardware Modell des ARM vollzieht einen RPC am Eingang jedes Mal, wenn es wünscht, Daten von dem RAM, ROM oder von der speicheradressierten Hardware zu schreiben/lesen. SYMPHONY verbindet den mem Eingang mit einer Slave Ausführungseinheit in der Hardware Schnittstelle, welche das Decodieren der Adresse durchführt und den RPC weitersendet an den geeigneten Hardwareblock (RAM, ROM, speicheradressierte Hardware).
Der fiq Eingang ist als ein Slave Eingang in dem Hardware Modell modelliert. Der Slave Eingang wird durch einen RPC aktiviert, welcher durchgeführt wird an dem Eingang durch die Hardware Schnittstelle. Die dem fiq Eingang zugeordnete Slave Ausführungseinheit (und in dem Hardware Modell modelliert) setzt das geeignete Kennzeichen (flag) in dem Zustandsregister auf den geeigneten Wert, womit eine Unterbrechungsanforderung signalisiert wird.
Die Verbindung zwischen den Ereignissen (RPC an die Eingänge, Start von Slave Ausführungseinheiten, welche Slave Eingängen zugeordnet sind) in dem Hardware Modell und den Ereignissen in dem Software Modell wird berücksichtigt von der Prozessorhardware oder, im Falle einer Simulation, durch den Simulator einer Befehlsliste für den ARM.
SYMPHONY beruht auf der Beobachtung, dass programmierbare Prozessoren eine Anzahl gemeinsamer Kommunikationsverfahren aufweisen, um Daten in oder aus den Prozessoren zu erhalten. Diese Kommunikationsverfahren werden modelliert durch E/A Szenarien. Ein E/A Szenario beschreibt einen Weg des Verwendens der Eingänge eines spezifischen Prozessorkerns, um einen besonderen Eingang einer Einkapselung einer Softwarehostsprache auf einen äquivalenten Eingang in der Hardware abzubilden, wodurch die Grenze des Prozessorkerns gekreuzt und überquert wird, während die Kommunikationssemantik aufrechterhalten bleibt. 8 zeigt ein Beispiel eines E/A Szenarios. Es besteht aus einer Einkapselung einer Softwarehostsprache und einer Einkapselung einer Hardwarehostsprache, welche jeweils einen Software E/A Treiber und das dazugehörige Gegenstück auf der Hardwareseite beschreibt. Ein E/A Szenario ist auch gekennzeichnet mit einigen Leistungskennzahlen, welche es dem Designer oder SYMPHONY erlauben, eine Entscheidung darüber zu fällen, welches E/A Szenario für welchen Eingang zu verwenden ist.
Das E/A Szenario (78) der 8 zeigt, wie ein outmaster Eingang psw (79) in Software auf einen outmaster Eingang phw (80) in Hardware abgebildet werden kann, wobei der Speichereingang (81) eines ARM-6 RISC Prozessorkerns verwendet wird. Die Einkapselung des Softwareverfahrens P1 (82) stellt den Software E/A Treiber dar und kopiert Daten von dem Eingang psw (79) zu einer spezifischen Speicheradresse 0x08000 über einen RPC Aufruf (84). Die Einkapselung des Hardwareverfahrens P2 (83) stellt das dazugehörige Gegenstück auf der Hardwareseite dar und prüft, ob der Speicheradressbus des ARM (modelliert durch die Protokollindices des Speichereinganges (81)) gleich ist zu 0x08000. Wenn dies der Fall ist, dann werden Daten, welche auf dem Speicherdatenbus des ARM Speicherresident gelagert sind, auf den Eingang phw (80) über einen RPC Aufruf (85) kopiert.
Die Bibliothek der E/A Szenarien umfasst:

– Speicheradressierte E/A Szenarien. Diese liefern einen Mechanismus des Datentransfers, welcher üblich ist, weil er nicht den Gebrauch von speziellen Prozessorbefehlen erfordert und weil er praktisch so viele Eingabe- und Ausgabeeingänge implementierten kann wie gewünscht. In speicheradressierten E/A werden Teile des Adressraumes den Eingabe- und Ausgabeeingängen zugewiesen. Lesen und Schreiben an solchen Adressen werden als Befehle an die E/A Eingänge interpretiert. „Sending (Senden)" an einen speicheradressierten Ort bezieht eine wirksame Ausführung einer „Store (Speichern)" Befehlsanweisung auf einer Pseudospeicherstelle mit ein, welche mit einem Ausgabeeingang verbunden ist, und „Receiving (Empfangen)" von einem speicheradressierten Ort bezieht eine wirksame Ausführung einer „Load (Laden)" Befehlsanweisung auf einer Pseudospeicherstelle mit ein, welche mit einem Eingabeeingang verbunden ist. Wenn diese Speicheroperationen auf den Teilen des Adressraumes, welche dem speicheradressierten E/A zugewiesen sind, ausgeführt werden, dann ignoriert das Speichersystem die Operation. Die E/A Einheit jedoch sieht die Operation und führt die entsprechende Operation an den verbundenen E/A Eingängen durch. Die Anzahl von Speicherstellen, welche für speicheradressierte E/A zugewiesen sind, wird von der Zahl der Eingänge abhängen, welche eine Softwareprozessorkomponente „physikalisch" implementieren muss. SYMPHONY schlägt eine Zuweisung von Adressstellen zu Kanälen vor, welche zu einer einfachen Adressdekodierungslogik führen wird. Der Benutzer kann jedoch immer die vorgeschlagene Zuweisung überschreiben.
– Befehlsprogrammierte E/A Szenarien. Einige Prozessoren liefern auch spezielle Befehle für das Zugreifen auf spezielle E/A Eingänge, die von dem Prozessor selbst bereitgestellt werden. Unter Verwendung dieses Schemas werden diese speziellen Kommunikationseingänge des Prozessors an die äußeren Kanäle über die E/A Einheit verbunden. Zusätzlich zu der Bereitstellung einer Hardware Unterstützung für einen speicheradressierten und befehlsprogrammierten E/A, liefert die E/A Einheit auch Unterstützung für eine Hardware Unterbrechungssteuerung. Unterbrechungen werden für verschiedene Zwecke verwendet, einschließlich der Koordination von unterbrechungsgetriebenen E/A Übertragungen. Verschiedene Prozessoren liefern einen verschiedenen Grad an Hardware Unterbrechungsunterstützung. Einige Prozessoren liefern einen direkten Zugang zu einer Anzahl von speziell angefertigten Unterbrechungssignalen. Unsere Architektur der E/A Einheit macht Gebrauch von diesen Signalen, wenn sie verfügbar sind. Wenn mehr Unterbrechungs „Kanäle" erforderlich sind, wie es zum Beispiel erforderlich ist, um eine Anzahl von unterbrechungsgetriebenen Kommunikationskanälen zu unterstützen, dann verwenden wir die Strategie der Interruptvektoren. Interruptvektoren sind Zeigeradressen, welche dem Prozessorkern sagen, wohin für die Interruptserviceroutine zu springen ist. In der Tat ist dies eine Art von speicheradressierter Unterbrechungshandhabung. Wenn erst einmal das E/A Szenario für jeden Eingang der Einkapselung einer Software Hostsprache ausgewählt ist, erzeugt SYMPHONY die notwendige Kommunikationssoftware und die entsprechende Hardware E/A Einheit durch ein Verbinden der ausgewählten E/A Szenarien. Die erzeugte Kommunikationssoftware, das Softwaremodell des Prozessorkerns und die Einkapselung der Software Hostsprache selbst werden zusammengeführt und mit dem prozessorspezifischen C-Kompilierer kompiliert. Das Ergebnis von SYMPHONY ist eine Verfeinerung der ursprünglichen Einkapselung der Hostsprache in eine CoWare Einkapselung, von welcher die Verhaltensschnittstelle identisch ist zu der der ursprünglichen Einkapselung.

Zusätzlich fügt SYMPHONY RAM- und ROM-Blöcke hinzu, um den Programmcode und die Daten zu speichern (In 7 sind RAM und ROM nicht explizit gezeigt: sie sind Teil der HW Schnittstelle). Das Ergebnis von SYMPHONY ist eine Verfeinerung der ursprünglichen Einkapselung der Hostsprache in eine CoWare Einkapselung, von welcher die Verhaltensschnittstelle identisch ist zu der der ursprünglichen Einkeipselung. SYMPHONY ersetzt wirksam eine Software Einkapselung durch eine Hardware Einkapselung, welche eine äquivalente Funktionalität aufweist.
In Stufe (3), wenn zwei Prozessoren nicht protokollkompatibel sind, wird ein Protokollumwandlungsverfahren eingeführt. In 6 haben der mit Cathedral-2/3 kompilierte Prozessor (65) und der Standardprozessor (76) inkompatible Protokolle. Eine Protokollumwandlung (77) ist erforderlich, um sie kompatibel zu machen.
Ein digitales System in der CoWare Designumgebung kann simuliert werden. Die Simulation ist eine Implementierung des digitalen Systems auf einem oder auf mehreren Allzweckcomputern. Dem Verfahren der Implementierung, wie es oben dargelegt worden ist, kann gefolgt werden, um eine Simulation aufzubauen. 9 stellt den Aufbau einer Simulation dar. Für die Simulation sind die Zielprozessoren Simulatoren (86), welche auf den Verfahren (87) der Betriebssysteme (88) laufen, welche auf Allzweckcomputern laufen. Die Zuteilung und Zuweisung bestimmen die Simulationsarchitektur. Willkürliche Simulationsarchitekturen werden von der CoWare Designumgebung unterstützt. Unterstützung wird geleistet, um eine optimale Architektur für eine gegebene Simulationsgeschwindigkeit und für eine Sichtbarkeit der Fehlersuche auszuwählen.
Die in Schritt (1) erwähnten Kompilierer der Hostsprache sind jetzt die Simulationsmaschinen für die Hostsprachen.
In Schritt (2) besteht die Inter-Prozesskommunikation jetzt aus zwei Teilen. In einem ersten Teil wird die Kommunikation von der Simulationsmaschine mit dem OS Verfahren verwirklicht, auf dem die Simulationsmaschine läuft. In einem zweiten Teil wird die Kommunikation zwischen zwei verschiedenen OS Verfahren über die OS und Netzwerkebene verwirklicht. Die Kommunikation zwischen der Simulationsmaschine und dem OS Verfahren wird durchgeführt über die Schnittstelle der Anwendungsprogrammierer der Simulationsmaschine. Die Kommunikation zwischen zwei verschiedenen OS Verfahren wird bewerkstelligt durch die Grundroutinen der OS Inter-Prozesskommunikation (z. B. gemeinsam geteilter Speicherplatz und Semaphors für zwei Verfahren auf einem einzelnen OS oder TCP/IP Anschluss (socket) für zwei Verfahren auf verschiedenen Computern).
Wenn die verwendete Simulationsmaschine eine feste Schnittstelle hat, wie zum Beispiel einen Simulator einer Befehlsliste für einen programmierbaren Prozessor, dann wird die Hardware Software Schnittstelle mit SYMPHONY erzeugt und kann wie irgendein anderes Verfahren simuliert werden.
Die CoWare Designumgebung unterstützt eine Simulation auf einem mehrfachen Abstraktionsniveau, was der Schlüssel für eine wirksame Cosimulation ist. Es erlaubt, die Verfahren unter einer Fehlersuche und Fehlerbeseitigung auf einer geeigneten niedrigen Stufe der Abstraktion für Zwecke der Fehlerbeseitigung zu simulieren, während die anderen Verfahren in dem System auf der höchsten geeigneten Stufe der Abstraktion für maximale Geschwindigkeit simuliert werden. Die zeitaufwendige Simulation auf einer niedrigen Stufe der Abstraktion ist begrenzt auf den kleinsten möglichen Teil des Systems unter einer Simulation, solange sie noch in der Lage ist, diese Teile in dem Systemzusammenhang zu simulieren.
Weil beide, sowohl die Simulation als auch die Implementierung, demselben Designverfahren folgen, ist es möglich, hybride Simulationsarchitekturen aufzubauen, in denen ein Teil des Systems durch Simulatoren implementiert wird, welche auf OS Verfahren laufen, und ein Teil des Systems durch tatsächliche Hardware implementiert wird. Dies ist gerade eine weitere Manifestation der Heterogenität der digitalen Systemarchitekturen.
In einer spezifischen Ausführung der vorliegenden Erfindung wird eine Anwendung offenbart in der Folge für das Hardware/Software Codesign einer Pager Anwendung.
SPEZIFIKATION DES PAGERS
Jeder Block (89) in 10 entspricht einem Verfahren, welches eine spezifische Funktion des Pagers implementiert. Diese funktionale Zerlegung bestimmt die anfängliche Aufteilung. Die Zeiger (90) zwischen den Verfahren stellen primitive Kanäle mit RPC Semantik dar.
Die 11 zeigt die RPC Kommunikation im Einzelnen für einen Teil des Pager Designs. Die Blöcke (91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101) in der 11 entsprechen den Verfahren (89) von 10.
Das Abtastverfahren (94) des Taktgenerators enthält eine autonome Ausführungseinheit (102). Diese Ausführungseinheit läuft kontinuierlich. Er führt einen RPC (103) über seinen Eingabe Eingang ip (104) zu dem Tracking & Acquisition (Nachführung & Erfassung) Verfahren (93), um einen neuen Wert für Delta zu erhalten. Die autonome Ausführungseinheit (102) des Verfahrens (94) fügt den Deltaparameter zu einigen internen Variablen hinzu, so lange bis ein Grenzwert überschritten ist. Auf diesem Wege implementiert er eine Sägezahnfunktion. Wenn der Sägezahn den (festen) Grenzwert überschreitet, dann wird ein RPC Aufruf (105) an das Verfahren der A/D Umwandlung (95) ausgegeben. Die autonome Ausführungseinheit (102) des Abtast-Taktgenerators (94) führt einen RPC Aufruf (105) (er gibt ein Taktzeichen zum Abtasten) bei jeder Grenzwert/Delta-Iteration (wirkliche Taktzyklen) durch.
Der Taktgeber (106) der Slave Ausführungseinheit in dem Verfahren der A/D Umwandlung (95) tastet die analoge Eingabe ab und sendet das Ergebnis zu dem Verfahren der Abwärtswandlung (100) über einen RPC Aufruf (107). Dies seinerseits aktiviert wiederum das Dezimierungsverfahren (99) über einen RPC Aufruf usw.
Das Correlator Noise Estimator Verfahren (98) (Verfahren der Abschätzung des Korrelationsrauschens) enthält eine Slave Ausführungseinheit (108), welche dem Eingang ip (109) zugeordnet ist, um die Korrelationswerte zu berechnen. Diese Ausführungseinheit (108) wird aktiviert, wenn das Verfahren der Phasenkorrektur (97) Daten auf das Correlator Noise Estimator Verfahren (98) schreibt (d. h. wenn das Verfahren der Phasenkorrektur (97) einen RPC (110) auf den ip (109) Eingang des Correlator Noise Estimator Verfahrens (98) durchführt). Die Slave Ausführungseinheit (108) liest die Daten ein und führt dann einen RPC (111) an dem Verfahren (91) der Benutzerschnittstelle aus, um einen neuen Wert für den Parameter par zu erhalten, den sie benötigt für die Berechnung der Korrelationswerte. Schließlich werden die neuen Korrelationsergebnisse an das Tracking Acquisition Verfahren (93) gesandt über einen RPC Aufruf (112) auf seinem op Eingang (113).
Die Slave Ausführungseinheit (114) in dem Trackking Acquisition Verfahren (93) aktualisiert den Deltawert für die Sägezahnfunktion, welche von dem Abtastverfahren (94) des Taktgenerators implementiert worden ist. Sie setzt den aktualisierten Wert in den Zusammenhang (115), wo er von der Slave Ausführungseinheit op (116) wieder gefunden wird, welche RPC Anfragen von dem Abtastverfahren (94) des Taktgenerators bedient. Auf diesem Wege beeinflusst das Tracking Acquisition Verfahren (93) die Frequenz des Taktgebers, welche von dem Abtastverfahren (94) des Taktgenerators erzeugt worden ist. Dieses Beispiel zeigt, wie der Zusammenhang (115) für die Kommunikation zwischen den Ausführungseinheiten innerhalb desselben Verfahrens verwendet wird, wobei der RPC Mechanismus für eine Kommunikation zwischen den Ausführungseinheiten in verschiedenen Verfahren verwendet wird. Das Schließen (117) und Aufschließen (118) des Zusammenhangs (115) ist erforderlich, um gleichzeitige Zugriffe auf die Variable Delta zu vermeiden. Die Sperre (117) in der Slave Ausführungseinheit op (116) verschließt den Zusammenhang (115) zum Lesen: andere Ausführungseinheiten haben noch die Erlaubnis, aus dem Zusammenhang (115) zu lesen, aber keine andere Ausführungseinheit darf in den Zusammenhang (115) schreiben. Die Sperre (119) in der Slave Ausführungseinheit ip (114) verschließt den Zusammenhang (115) zum Schreiben: keine andere Ausführungseinheit darf den Zusammenhang (115) beschreiben oder lesen, bis er wieder entriegelt ist.
Jedes Verfahren ist in der Sprache beschrieben, welche am besten zu den Eigenschaften der Funktion passt, welche sie implementiert. Die Datenflussblöcke (NCO (101), Abwärtsumwandlung (100), Dezimierungsverfahren (99), Chip Angepasste Filter (96), Phasenkorrektur (97), Correlator Noise Estimator Verfahren (98) und das Abtastverfahren (94) des Taktgenerators sind in DFL beschrieben. Die an der Steuerung orientierten Blöcke (Tracking Acquisition (93), Bildextrahierung (92) und die Benutzerschnittstelle (91)) sind in C beschrieben. Der Code in der 11 ist ein Pseudo-Code, welcher für die Darstellung gedacht ist und welcher nicht dem tatsächlichen Code entspricht.
DESIGNVERFAHREN
Nachdem die anfängliche Spezifikation des Systems durch eine Simulation validiert worden ist, fängt der Designer mit der Verfeinerung des Verfahrens an.
Bis zu diesem Moment ist noch nicht entschieden, welches Verfahren auf welcher Art von Zielprozessor implementiert werden wird, noch ist definiert, wie die RPC Kommunikation verfeinert werden wird. Die Wahl der Spezifikationssprache für jedes Verfahren beschränkt jedoch die Wahl des Kompilierers der Komponente und in diesem Sinne bestimmt sie teilweise den Zielprozessor. Daher kann das Studieren möglicher alternativer Zuweisungen eines Verfahrens zu einem Zielprozessor die Verfügbarkeit einer Beschreibung des Verfahrens in mehr als in einer Spezifikationssprache erfordern oder ein eindeutiges Erraten der besten Lösung.
ZUTEILUNG UND ZUWEISUNG
Dieser Schritt bestimmt, welche Verfahren auf welchem Zielprozessor implementiert werden. Die anfängliche Spezifikation zeigt die feinste Unterteilung: ein Verfahren in der anfängliche Spezifikation wird nie aufgespalten werden über mehrere Prozessoren. Es kann jedoch wert sein, eine Anzahl von Verfahren innerhalb eines einzelnen Prozessors zu verbinden. Dies wird erreicht durch eine Zusammenführung dieser Verfahren in ein einzelnes Verfahren, welches dann auf den ausgewählten Zielprozessor durch einen Kompilierer einer Hostsprache abgebildet werden kann. Eine Zusammenführung von Verfahren ist nur erlaubt, wenn die Verfahren in derselben Spezifikationssprache beschrieben sind. Daher kann das Studieren möglicher Verfahren der Zusammenführungen erfordern, dass für eine Anzahl von Verfahren (z. B. Verfahren der Abschätzung des Korrelationsrauschens) eine Beschreibung in mehr als in einer Spezifikationssprache verfügbar ist. Nach der Zuteilung und Zuweisung erhält man eine Beschreibung mit einer eins zu eins Abbildung der zusammengeführten Verfahren auf die Prozessoren.
In dem Pager Beispiel (12) findet die folgende Zuteilung, Zusammenführung und Zuweisung statt.
Die Verfahren NCO (120), Abwärtsumwandlung (121) und das Verfahren der Dezimierung (122) werden zusammengeführt und auf der Hardware abgebildet auf einem anwendungsspezifischen DSP Prozessor (123), weil die Abtastgeschwindigkeit der zusammengeführten Verfahren identisch ist, was impliziert, dass sie mit derselben Frequenz getaktet werden können. Der Vorteil liegt darin, dass nur ein Taktbaum pro zusammengeführtes Verfahren erzeugt zu werden braucht (i. s. o einer pro ursprüngliches Verfahren). Ein zusätzlicher Vorteil liegt darin, dass die Scan-Ketten für die Verfahren, welche zusammengeführt werden, verbunden werden können.
Der auf den Chip abgestimmte Filter (124) und die Verfahren der Phasenkorrektur (125) werden zusammengeführt und auf einen CATHEDRAL-3 Prozessor (126) abgebildet, weil ihre Abtastgeschwindigkeiten identisch sind.
Das Correlator Noise Estimator Verfahren (127) wird auf einen CATHEDRAL-3 Prozessor (128) abgebildet. Es wird nicht mit dem Verfahren der Phasenkorrektur (125) zusammengeführt, weil es bei einer um das Vierfache tieferen Frequenz arbeitet.
Das Abtasttaktgenerator (129) wird auf einen CATHEDRAL-3 Prozessor (130) abgebildet.
Tracking Acquisition Verfahren (131), Bildextrahierung (132) und Benutzerschnittstelle (133) werden zusammengeführt und auf einen programmierbaren Prozessor (134) abgebildet. Für dieses Design wird ein ARME Prozessor gewählt.
Die Hardware/Software tradeoffs beruhen auf den folgenden Beobachtungen. Um ein maximales Maß an Flexibilität zu erreichen, wird so viel von der Funktionalität wie möglich in Software auf dem ARME (134) implementiert. Es besteht jedoch auf Grund der Leistungsbeschränkungen des ARM6 Prozessors (134) eine Grenze, bis zu der etwas in Software implementiert werden kann. Die zwei Hauptfaktoren, welche eine Rolle in diesem Problem spielen, sind das Tracking Acquisition Verfahren (131), welches in Software implementiert werden muss, weil der Algorithmus, welcher verwendet wird, um das Nachführen und Erfassen (tracking and acquisition) durchzuführen, verändert werden kann in Abhängigkeit von dem Anwendungsbereich des Pager Systems.
Das Correlator Noise Estimator Verfahren (127) ist nicht in die Software mit eingeschlossen, weil die Eingabegeschwindigkeit für den Correlator Noise Estimator (127) zu hoch ist, um eine Echtzeitkommunikation zwischen dem ARME und dem Phasenkorrekturverfahren (125) zu verwirklichen. Zusätzlich zeigt eine Abschätzung der Anzahl von Zyklen, welche erforderlich sind, um jede Funktion des ARME auszuführen, dass die Implementierung des Correlator Noise Estimator Verfahrens (127) in Software nicht genügend Zeit übrig lässt, um Tracking und Acquisition zwischen jeden zwei Symbolen durchzuführen.
Nach der Zusammenführung kann jedes der zusammengeführten Verfahren jetzt auf einem getrennten Zielprozessor implementiert werden mit einem geeigneten Kompilierer. Die Kommunikation zwischen den zusammengeführten Verfahren wird noch über primitive Eingänge und primitive Kanäle bewerkstelligt.
Auswahl des Kommunikationsmechanismus
Nachdem die Unterteilung des Systems durch eine Simulation verifiziert worden ist und bevor die wirkliche Implementierung stattfindet, kann der Designer wählen, den Kommunikationsmechanismus zwischen den Verfahren zu verfeinern. Dies kann erreicht werden, indem man das Verhalten der Kanäle zwischen den Prozessoren explizit macht.
In dem laufenden Beispiel können die Prozessoren im Grundsatz gleichzeitig arbeiten, weil jeder Prozessor seine eigene Ausführungseinheit der Steuerung hat. Indem man das auf RPC gestützte Kommunikationsschema verfeinert, können wir die Prozessoren in einer Pipeline anordnen: alle Prozessoren arbeiten gleichzeitig und sie synchronisieren an den E/A Punkten. Dieses verfeinerte Kommunikationsschema wird als Blocked/UnBlocked Read/Write (Gesperrt/Ungesperrt Lesen/Schreiben) Kommunikation bezeichnet. Die 13 zeigt den Pager mit dem verfeinerten Kommunikationsmechanismus. Die Eingänge und Ausgänge der Prozessoren sind mit BW für Blocked Write, BR für Blocked Read und UBR für UnBlocked Read gekennzeichnet worden.
Die BW-BR Kommunikation garantiert, dass keine Daten jemals verloren gehen. Wenn das Schreibverfahren Daten zur Verfügung hat, dann wird es dieses dem Leseverfahren signalisieren. Wenn das Leseverfahren zu diesem Moment nicht bereit ist, Daten zu empfangen (weil es noch die vorhergehenden Daten verarbeitet), dann wird das Schreibverfahren sperren bis das Leseverfahren bereit ist zu kommunizieren. Alternativ wird es, wenn das Leseverfahren neue Daten benötigt, dieses dem Schreibverfahren signalisieren. Wenn das Schreibverfahren zu diesem Moment nicht bereit ist, Daten zu senden (weil es noch die Daten berechnet), dann wird das Leseverfahren sperren bis das Schreibverfahren bereit ist zu kommunizieren. Das BW-BR Schema wird in dem Hauptsignalweg verwendet.
Ein BW-BR Schema wird jedoch nicht für den Parameter und für die Moduseinstellung für den Hauptsignalweg verwendet. Wenn ein Beschleuniger BR verwendet, um einen Parameterwert zu lesen, dann wird er gesperrt, bis der Parameter geliefert wird. Da die Parametereinstellung in der Software getan wird, wird dies die Berechnungen in dem Hauptsignalweg erheblich verzögern. Daher wird die Parametereinstellung über ein BW-BR Schema getan. Dies gewährleistet, dass jede Parameteränderung von den Beschleunigern gelesen wird, aber es überlässt es dem Beschleuniger zu entscheiden, wann es den Parameter liest.
In der CoWare Designumgebung wird die Verfeinerung des Kommunikationsmechanismus durchgeführt, indem man Gebrauch macht von einem hierarchischen Kanal. Ein hierarchischer Kanal ersetzt einen primitiven Kanal durch ein Verfahren, welches beschreibt, wie eine Kommunikation über diesen Kanal ausgeführt wird.
Die Einführung einer BW-BR Kommunikation ist im Detail für das Chip Matched Filter & Phase Correction (135) und Correlator & Noise Estimator Verfahren (136) in 14 gezeigt.
Der BWBR Kanal (137) enthält eine autonome Ausführungseinheit (138) und eine Slave Ausführungseinheit (139), welche gegenseitig miteinander kommunizieren über eine gemeinsam geteilte Variable tmp [0 7] in dem Zusammenhang (140). Die Slave Ausführungseinheit (139) wird aktiviert durch einen RPC (141) von dem CMF & Phase Correction Verfahren (135) und sie versucht, den Zusammenhang (140) mit neuen Werten zu aktualisieren. Die autonome Ausführungseinheit (138) versucht kontinuierlich, die Werte aus dem Zusammenhang (140) zu lesen und sie an den Ausgabeeingang (144) über ein RPC (142) zu senden, wobei auf diesem Wege das Correlator & Noise Estimator Verfahren (136) aktiviert wird, welches dieser Ausgabe (144) zugeordnet ist. Die Sperreigenschaft der Kommunikation wird berücksichtigt durch den Gebrauch einer binären Semaphore rw (143). Dies garantiert, dass die Eingangsausführungseinheit (139) sperren wird, bis die vorhergehenden Daten von der autonomen Ausführungseinheit (138) gelesen worden sind (keine Daten werden überschrieben bevor sie gelesen worden sind), und dass die autonome Ausführungseinheit (138) sperren wird, bis neue Daten verfügbar sind (keine Daten werden zweimal gelesen). Wenn die Eingabe der Slave Ausführungseinheit (139) gesperrt ist, dann ist auch das CMF & Phasenkorrekturverfahren (135), welches dessen Dienst über ein (RPC) anfordert, gesperrt, weil der RPC (141) nur zurückkehren wird, nachdem die Slave Ausführungseinheit (139) abgeschlossen hat. Wenn die autonome Ausführungseinheit (138) gesperrt ist, dann gibt es keine RPC Anfragen an das Correlator Noise Estimator Verfahren (136), so dass das Verfahren (136) automatisch blockiert ist.
In dem Fall einer Blocked-Write, UnBlocked Read Kommunikation wird der Code für die autonomen Ausführungseinheit leicht verändert. Die Ausführungseinheit sendet immer den Wert, welcher in dem Zusammenhang gespeichert ist, ohne dass geprüft wird, ob er aktualisiert wird. Derselbe Wert kann mehr als einmal gesendet werden, aber die Ausführungseinheit wird nie gesperrt sein. Der Eingang der Slave Ausführungseinheit ist identisch mit dem BWBR Fall und wird blockieren, bis die Daten gelesen worden sind.
In beiden Fällen ist eine Sperrung und eine Freigabe des Zusammenhanges erforderlich, um gleichzeitige Zugriffe auf die gemeinsam geteilte Variable in dem Zusammenhang zu vermeiden, und als solches hat es nichts zu tun mit der Sperreigenschaft der Kommunikation.
Implementierung des Pagers
Nachdem der neu eingeführte Kommunikationsmechanismus durch eine Simulation verifiziert worden ist, muss jedes Verfahren auf seinem zugewiesenen Zielprozessor synthetisiert werden.
Implementierung eines Verfahrens in der Hardware
15 verdeutlicht die reine Hardware Implementierung für das Correlator & Noise Estimator Verfahren (145) und das zusammengeführte Phasenkorrektur und Chip Matched Filter Verfahren (146).
Diese Hardware Implementierung für den Pager besteht aus drei unterschiedlichen Schritten:
Die (zusammengeführten) DFL Verfahren werden synthetisiert durch den CATHEDRAL Silizium Kompilierer. Der Kompilierer erzeugt Prozessoren, von denen alle die Eingaben und Ausgaben von dem Master Typ sind. Diese Prozessoren sind in 15 gezeigt als die inneren Rechtecke (147, 148).
Jeder Prozessor ist eingekapselt, um ihn konsistent mit der Spezifikation zu machen, in welcher die DFL Verfahren Slave Eingänge haben. Zusätzlich enthält die Einkapselung eine torgesteuerte Taktschaltung, um die Aktivität des Prozessors zu steuern. Die eingekapselten Prozessoren sind in 15 als die großen Rechtecke (149, 150) gezeigt: sie enthalten den von CATHEDRAL (147, 148) erzeugten Prozessor und etwas eingekapselte Hardware (151, 152, 153). Wie man beobachten kann, sind die Eingabeeingänge (154, 155) der eingekapselten Prozessoren (149, 150) jetzt von dem Slave Typ. Die eingekapselte Hardware (151, 152, 153) ist im Detail in der 16 gezeigt als die folgenden Blöcke (155, 156, 157).
Das BWBR Verfahren ist in der Hardware implementiert. In diesem Fall erhalten wir die Implementierung dieses Verfahrens aus der Bibliothek auf dem Niveau des Gates. Diese Implementierung ist funktional äquivalent zu der ursprünglichen C-ähnlichen Beschreibung (137) dieses Blocks in der 14. Die 16 zeigt die detaillierte Implementierung (158) des BWBR Verfahrens, welches in dem Hauptsignalweg des Pagers verwendet wird.
Implementierung eines Verfahrens in der Software
Um die Diskussion zu vereinfachen, werden wir nur die Übertragung der 14 Korrelationswerte des Tracking Acquisition Verfahrens betrachten und die Festsetzung eines Parameterwertes durch die Benutzerschnittstelle. Wir wissen auch, dass die Übertragung der Korrelationswerte ein BWBR sein muss und dass die Übertragung des Parameterwertes ein BWUBR sein muss.
Die Hardware Schnittstelle und der Software E/A Gerätetreiber werden automatisch mit SYMPHONY erzeugt. Um diese Schnittstellen zu erzeugen, analysiert SYMPHONY die Eingänge des Software Verfahrens. Für jeden dieser Eingänge sucht SYMPHONY die Bibliothek der E/A Szenarien für ein anwendbares Szenario ab. Der Benutzer wird gefragt, das am besten geeignete Szenario unter den anwendbaren Szenarien auszuwählen. SYMPHONY verbindet dann die ausgewählten Szenarien mit einem Software E/A Gerätetreiber und mit einer Hardware Schnittstelle.
In dem Beispiel (17) gibt es zwei Eingänge, welche implementiert werden sollen:

– bool [32][14] corr: inslave (159) wird verwendet, um die Korrelationswerte zu übertragen. Dies ist ein Eingang vom Typ inslave, welcher eine Anordnung von 14 Bitvektoren der Größe 32 transportiert.
– bool par: outmaster (160) wird verwendet, um einen Parameter des Korrelationsblockes einzustellen. Dies ist ein Eingang vom Typ outmaster, welcher einen boolschen Wert transportiert.

Für den corr Eingang (159) schlägt SYMPHONY das in 17 dargestellt Szenario vor. Der Speichereingang des ARM wird verwendet werden, um die Korrelationswerte zu übertragen, und der FIQ Eingang des Prozessors wird verwendet werden, um die Übertragung zu starten. Das E/A Szenario beschreibt, welche Blöcke in die Software und Hardware eingefügt werden müssen, um diese Art der Kommunikation zu verwirklichen. Insgesamt sind drei Hardware- und drei Softwareblöcke erforderlich, um die Kommunikation über den corr Eingang zu implementieren. Unpack (161). Der Speichereingang des ARM ist offensichtlich nicht weit genug, um die 14 Korrelationswerte parallel zu übertragen. Daher wird das Szenario die Übertragung in sequentieller Form nacheinander durchführen. Von den 14 Korrelationswerten werden 13 intern in dem Unpack Block (161) gespeichert werden. Der 14-te Wert wird zu dem Split Block (162) gesendet.
Split (162) speichert den 14-ten Wert intern und aktiviert dann den FIQ Eingang des ARM Prozessors. Das Aktivieren des FIQ Einganges (163) des Hardwaremodells (164) hat als eine Konsequenz zur Folge, dass ein RPC an den Unterbrechungseingang (165) des Softwaremodells (166) ausgegeben wird. Dieser Eingang (165) ist mit dem Join (167) Block verbunden.
Join (167) findet den 14-ten Korrelationswert wieder auf durch Ausgabe eines RPC an den entsprechenden Eingabeeingang (168) des Demux Blockes (169). Demux Block (169). Die Datenübertragung wird implementiert durch einen speicheradressierten E/A. Daher sollte der Benutzer, wenn er dieses E/A Szenario auswählt, sich für die Adresse entscheiden, welche für die Übertragung verwendet werden wird. Wenn einer der Eingabeeingänge des Demux Blockes aktiviert wird, dann wird ein RPC an den Speichereingang (170) durchgeführt werden mit einer Adresse, welche dem aktivierten Eingabeeingang entspricht.
Mux (171). Auf der Hardwareseite gibt der Speichereingang (172) einen RPC an den Mux (171) Block jedes mal dann, wenn er (172) aktiviert ist. In diesem Block (171) wird die Adresse dekodiert werden und der entsprechende Ausgabeeingang wird aktiviert werden, um den Korrelationswert wieder zu finden, welcher lokal in der Hardware gespeichert war (entweder in dem Split (162) oder in dem Unpack Block (161)). Pack (173). Nachdem der 14-te Korrelationswert wieder gefunden worden ist durch den Join Block (167), wird er auf den Pack Block (173) weitergeleitet, welcher dann die 13 anderen Korrelationswerte wieder finden wird durch das Ausgeben aufeinander folgender RPCs an die verschiedenen Eingänge des Mux Blockes (169). Schließlich, wenn der Pack Block (173) alle 14 Werte wieder gefunden hat, dann packt er sie in eine Feldgruppierung und aktiviert den ursprünglichen Softwareanwendungscode in dem Tracking Acquisition Verfahren (174).
Alle diese Blöcke sind in einer generischen Art und Weise in einer Bibliothek beschrieben, wo sie wieder gefunden und maßgeschneidert angepasst werden können durch SYMPHONY.
Die Lösung für den par Eingang (160) ist viel einfacher. Da er ein outmaster Eingang ist, kann er direkt auf den Speichereingang abgebildet werden. Wenn der Speichereingang schon benutzt wird, dann ist ein extra Multiplexer (175) erforderlich. Dies ist in 17 gezeigt. Um die Aufhebung der Sperrung des Einlesens von Zeichen der Übertragung zu implementieren, ist ein zusätzliches Register (176) auf der Hardwareseite erforderlich.
Bevor man mit dem Weg der Implementierung weitergeht, werden alle Verfahren, welche durch SYMPHONY hinzugefügt worden sind, zusammengeführt. Die Hardwareschnittstellen werden in einem Hardwareschnittstellenblock zusammengeführt, welcher dann mit den Synthesewerkzeugen der RT-Stufe implementiert werden kann. Die Verfahren der E/A Gerätetreiber werden mit dem ursprünglichen SW Anwendungscode zusammengeführt. Als eine Konsequenz des Mitlaufens bewegt sich die vollständige Tracking und Acquisition Slave Ausführungseinheit in die Unterbrechungsroutine. Jedes Mal, wenn neue Korrelationswerte bereit stehen, wird die Ausführungseinheit der Hauptsoftware unterbrochen, um den Tracking und Acquisition Algorithmus laufen zu lassen. Nachdem diese Unterbrechung verarbeitet worden ist, nimmt die Hauptausführungseinheit ihre Ausführung wieder auf.
In der obigen Beschreibung sind offenbart worden eine Designumgebung und eine Designmethodologie, welche die Anforderungen der Modularität, der Einkapselung von verschiedenen Beschreibungssprachen erfüllen, des Modellierens aus einer heterogenen konzeptuellen Spezifikation bis zu einer daraus resultierenden heterogenen Architektur und mit allen Schritten der Verfeinerung dazwischen, der Modellierungsfähigkeiten für Standardkomponenten und der dazugehörigen Designumgebungen, der Trennung zwischen dem funktionalen Verhalten und dem Kommunikationsverhalten und welche die Anforderungen der prozessorunabhängigen Schnittstellensynthese erfüllen. Aber es ist einleuchtend, dass andere Ausführungen der vorliegenden Erfindung für einen Experten auf diesem Gebiet offensichtlich sind, der Geist und der Umfang der vorliegenden Erfindung werden nur begrenzt durch die Begriffe der anhängenden Ansprüche.

Claims

Verfahren zur Erzeugung einer heterogenen Systemimplementierung aus einer heterogenen Spezifikation, wobei das besagte System mindestens einen digitalen Systemteil umfasst und wobei die heterogene Spezifikation eine gewisse Anzahl von Datenmodellen und Paradigmen mit assoziierten Verhaltens- und Struktursprachen umfasst, wobei die besagte heterogene Implementierung Hardwareteile und Softwareteile umfasst und die Implementierung Softwareuntersysteme von dem besagten System umfasst, wobei das Verfahren die folgenden Schritte umfasst: ein Definieren eines ersten Satzes von primitiven Objekten in einer Datenbank, welche auf mindestens einem Computer kompiliert wird, welcher die besagte Spezifikation des besagten Systems darstellt, wobei dasselbe die folgenden Unterschritte umfasst: Unterschritt 1: ein Beschreiben der Spezifikation des besagten Systems in einem oder in mehreren Verfahren, wobei ein jedes Verfahren einen funktionalen Aspekt des besagten Systems darstellt, wobei die besagten Verfahren primitive Objekte sind; Unterschritt 2: ein Definieren von Eingängen und ein Verbinden der besagten Eingänge mit Kanälen, wobei die besagten Eingänge die Kommunikation zwischen den besagten Verfahren strukturieren, und wobei die besagten Eingänge und die besagten Kanäle primitive Objekte sind, wobei ein Verfahren einen oder mehrere Eingänge hat; Unterschritt 3: ein Definieren der Kommunikationssemantik der besagten Eingänge durch ein Protokoll, wobei das besagte Protokoll ein primitives Objekt ist; und danach ein Erzeugen hierarchischer Objekte in der besagten Datenbank, während eine Implementierung des besagten Systems durch eine Verfeinerung der besagten Spezifikation des besagten Systems durch eine Verfeinerung der besagten primitiven Objekte erzeugt wird, wobei die besagten hierarchischen Objekte Verfeinerungen der besagten primitiven Objekte sind und einen größeren Grad an Detaillierung aufweisen, während die besagte Kommunikationssemantik im wesentlichen bewahrt bleibt; ein Auswählen von einer oder von mehreren Hardwarekomponenten, wobei diese Komponenten programmierbare Prozessoren umfassen; ein Zuweisen der besagten verfeinerten Verfahren der besagten verfeinerten Spezifikation des besagten Systems zu den besagten Hardwarekomponenten, wobei diese verfeinerten Verfahren einem programmierbaren Prozessor zugewiesen werden, welcher ein Softwareuntersystem ist; ein Auswählen von E/A-Szenariomodellen für Eingänge der besagten verfeinerten Verfahren des Softwareuntersystems, wodurch die besagten Eingänge der besagten verfeinerten Verfahren des Softwareuntersystems mit der Schnittstelle des besagten programmierbaren Prozessors verbunden werden, und wobei die Schnittstelle des besagten programmierbaren Prozessors mit zweiten Eingängen verbunden wird, wobei die besagten zweiten Eingänge die Kommunikationssemantik der besagten Eingänge im wesentlichen aufrechterhalten.
Verfahren gemäß Anspruch 1, welches ferner den Schritt der Simulation des besagten Systems umfasst.
Verfahren gemäß Anspruch 1, welches ferner den Schritt der Verfeinerung des Kanals zwischen einem ersten und einem zweiten Eingang von jeweils einer ersten und einer zweiten Hardwarekomponente umfasst, wobei der besagte erste und der besagte zweite Eingang ein inkompatibles erstes und zweites Protokoll haben, wodurch ein hierarchischer Kanal geschaffen wird, und der besagte hierarchische Kanal wandelt das erste Protokoll in das zweite Protokoll um.
Verfahren gemäß Anspruch 3, welches ferner den Schritt der Erzeugung einer Netzwerkliste umfasst, welche die Layoutinformation der besagten Implementierung enthält.
Designmaschine zur Erzeugung einer heterogenen Systemimplementierung aus einer heterogenen Spezifikation, wobei das besagte System mindestens einen digitalen Systemteil umfasst und wobei die besagte heterogene Spezifikation eine gewisse Anzahl von Paradigmen umfasst mit assoziierten Verhaltens- und Struktursprachen, wobei die besagte heterogene Implementierung Hardwareteile und Softwareteile umfasst, dadurch gekennzeichnet, dass die besagte Maschine so angeordnet ist, dass sie alle Schritte gemäß Anspruch 1 ausführt.
Designmaschine gemäß Anspruch 5, welche ferner Mittel zur Simulation des besagten Systems umfasst, welches eine große Anzahl von Simulatoren für die besagten Verhaltens- und Struktursprachen umfasst.