Entwicklung einer Systemumgebung für System Level Design in SpecC

Transkript

1 Entwicklung einer Systemumgebung für System Level Design in SpecC Dipl.-Ing. (FH) David Berner, ASIC Design Center Fachhchschule Offenburg, Badstrasse 24, Offenburg Tel. 0781/ , Fax 0781/ Um bei ständig verkürzten Entwicklungszyklen immer kmplexere Designs bearbeiten zu können, muss auf immer höhere Abstraktinsebenen gewechselt werden. SpecC ist eine Methdik und eine Sprache zur Entwicklung auf Systemebene. Um Akzeptanz auf industrieller Ebene zu erhalten, müssen Tls vrhanden sein, die einen anschaulichen und interaktiven Gang durch den Design-Flw ermöglichen. Dies war bis jetzt ein Schwachpunkt vn SpecC, sll sich jedch mit der Entwicklung vn RESpecCT ändern. 1. Einführung Möglichkeiten die Prduktivität derart entscheidend zu steigern sehen wir heute in der knsequenten Wiederverwertung vn Intellectual Prperty (IP reuse) und in dem Wechsel zu höheren Abstraktinsebenen - besser nch: in der Kmbinatin vn beidem. 2. System Level Design Histrisch gesehen ging die Entwicklung immer vn niederen Ebenen zu höheren Ebenen. Als Parallele kann man das Prgrammieren betrachten: Ausgehend vn dem Stanzen vn Lchkarten in Maschinencde über Assembler-Prgrammierung und der Prgrammierung in strukturierten Im Jahr 1965 hat Grdn Mre, Mitgründer vn Intel, vrausgesagt, dass sich die Transistrdichte vn Halbleiterchips ungefähr alle 18 Mnate verdppeln werde. Im Februar 2001 kündigte Pat Gelsinger (Intels Technlgie-Kpf) auf der Internatinal Slid State Circuit Cnference (ISSCC) den 1 TIPS-Przessr mit 10 Milliarden Transistren und 30 GHz für das Jahr 2010 an. Ein aktueller P4 Przessr besteht aus 42 Millinen Transistren. Da die Prduktivität der Entwickler in der Vergangenheit nur um ca. 20% pr Jahr gestiegen ist, wird klar, dass ein slches Ziel mit herkömmlichen Mitteln nicht erreichbar ist. Ein weiteres Phänmen heutzutage ist, dass Prduktentwicklungszyklen immer kürzer werden. Der Markt entwickelt sich derart schnell, dass das, was heute sehr gefragt ist in einem Jahr schn keiner mehr haben will. Die "time t market" entscheidet über den Erflg der Misserflg eines Prdukts. Wie ist jedch eine Verkürzung der Entwicklungszeiten bei immer kmplexeren Systemen möglich? Maske Mdul-Flrplan Przessr-Flrplan System-Flrplan Physikalische ALU Zelle Transistr Abbildung 1: Gajski Y mit System Level Design Verhaltens- System- FSM Mdul Lgik Struktur- Przessr MPC-Wrkshp, Juli, 2001

2 Hchsprachen ging man über zur bjektrientierten Prgrammierung. Dabei wird die innere Struktur vn Prblemen direkt mdelliert hne auf die letztendliche Realisierung in Maschinensprache Rücksicht zu nehmen. Sicher werden alle anderen Arten vn Prgrammierung heute immer nch verwendet, dch sbald Prbleme eine gewisse Kmplexität erreichen führt heute kein Weg mehr an der bjektrientierten Prgrammierung vrbei. In der Schaltungsentwicklung begann es mit dem Designen der eigentlichen Schaltung mit allen Bauteilen auf Silizium. Der Weg führte über Transistr-Lgik und Gatter-Lgik zu High-Level- Design mit Sprachen wie VHDL und Verilg, w aus einem lösungsrientierten Sprachknstrukt die niederen Ebenen autmatisch erzeugt werden. Um nch kmplexere Systeme schnell zu realisieren, ging man dazu über, die funktinale Spezifikatin in einer Hchsprache wie C zu schreiben, zu testen und zu verifizieren. Dann wurde diese (vn Hand) überführt in eine VHDL-. Auf diese Weise kann die Funktinalität des Systems zu einem sehr frühen Zeitpunkt überprüft werden. Es können Mdifikatinen vrgenmmen werden bevr schn zu viel Entwicklungsarbeit investiert wurde. Diese Art vn Design-Vrgehen wird "System Level Design" genannt (Abbildung 1). Ein grsses Prblem dabei ist die Überführung des C-Mdells auf die VHDL-Ebene. Da sich diese beiden Ebenen in einigen Punkten grundsätzlich unterscheiden, ist eine Umsetzung mit erheblichem Aufwand verbunden und fehlerbehaftet. Man ist deshalb bestrebt diese Lücke zu schliessen und einen Design-Fluss zu bekmmen, der vn der Systemspezifikatin bis zur Transistrebene knsistent ist. 3. SpecC Wer sich mit System Level Design beschäftigt, wird zwangsläufig auf den Begriff SpecC stssen. Der Begriff SpecC taucht jedch auch im Zusammenhang mit vielen anderen Stichwrten auf wie z.b.: Hardware Sftware C-Design SOC, Embedded System Unterschiedliche Abstraktinsebenen Benutzer geführte Verfeinerung Simulatin auf verschiedenen Ebenen Trennung vn Funktin und Kmmunikatin Vllständige und rthgnale Sprache Dch was ist denn nun SpecC genau? 3.1. Methdik Zuerst ist SpecC eine Methdik die einen Synthesefluss beschreibt (Abbildung 2). Dabei werden vn der System-Spezifikatin bis zur Implementierung vier verschiedene Abstraktinseneben definiert: Spezifikatinsebene Architekturebene Kmmunikatinsebene Implementierungsebene Der Übergang zwischen diesen Ebenen erflgt weitgehend autmatisiert, es müssen nur wenige Design-Entscheidungen getrffen werden wie: Aufteilung Hardware / Sftware Auswahl vn Przessren Festlegung vn Ausführungsreihenflgen Auswahl vn Prtkllen Dieser Vrgang wird auch "Benutzer geführte Verfeinerung" genannt. Der knsistente Synthese-Fluss wird ergänzt durch einen Validierungs-Fluss (Abbildung 2). Der Validierungs-Fluss besteht darin, dass das System auf jedem Abstraktinslevel simulierbar und verifizierbar sein sll. Auf dem Spezifikatinslevel wird die Funktin des Gesamtsystems nachgewiesen. Durch den knsistenten Synthese- Fluss reicht es aus in den unteren Ebenen nur nch die sgenannten Ht-Spts zu verifizieren, die Gesamtfunktinalität ist nach wie vr gegeben. Da in niedrigeren Ebenen die Simulatinsperfrmance durch mehr Detailinfrmatinen drastisch zurück geht und eine Simulatin des Gesamtsystems praktisch unmöglich wird, ist dies ein entscheidender Vrteil. SpecC war als erst nur eine Methdik, was fehlte war eine Implementierung davn. MPC-Wrkshp, Juli 2001

3 Abbildung 2: SpecC Sythese- und Validierungs-Fluss MPC-Wrkshp, Juli, 2001

4 3.2. SpecC - Yet anther language? Auf der Suche nach einer Implementierung für die SpecC Methdik wurden erst bestehende Sprachen evaluiert ( Abbildung 3). Diese Erweiterungen machen SpecC zu einer vllständigen und rthgnalen Implementierung der SpecC Methdik. Die vn beliebigen Systemen ist auf allen Ebenen möglich. Um die Entwicklungsenergie um SpecC zu bündeln ist ein Standardisierungsgremium gegründet wrden. Das SpecC Technlgy Open Cnsrtium (STOC) hat über 40 Mitglieder aus Industrie und Frschung und berät über Mdifikatinen des ffenen Standards. interface I1 { bit[63:0] Read(vid); vid Write(bit[63:0]); }; channel C1 implements I1; behavir B1(in int, I1, ut int); Abbildung 3: Vergleich bestehender Sprachen Dabei wurde festgestellt, dass es bis jetzt keine Sprache gibt, die die Prblematik vn System Level Design vllständig abdeckt. Es wurde als klar, dass eine eigene Sprache entwickelt werden musste, die der Prblematik gerecht wird. Um den Einarbeitungsaufwand vn Ingenieuren möglichst gering zu halten wurde SpecC auf Basis vn ANSII C entwickelt. Dies macht Sinn, da heute schn herkömmliches "System Level Design" mit C beginnt Sprache Die Sprache SpecC ist als ein echtes Superset vn ANSI-C. Das heisst jedes C Prgramm ist ein gültiges SpecC Prgramm. Es führt nur wenige Syntax-Erweiterungen ein, die der Sprache sieben Knzepte hinzufügen: Verhaltens Hierarchie Strukturelle Hierarchie Parallelismus Synchrnisatin Timing Zustandsübergänge behavir B(in int p1, ut int p2) { int v1; C1 c1; B1 b1(p1, c1, v1), b2(v1, c1, p2); vid main(vid) { par { b1.main(); b2.main(); } } }; Abbildung 4: SpecC Beispielcde 4. RESpecCT 4.1. Idee Um nun SpecC für den Anwender interessant zu machen ist es essentiell Tls zu haben, deren Umgang den Nutzer möglichst intuitiv durch die zu erledigenden Aufgaben führt. Die Idee war nun ein Tl zu entwickeln, das eine grafische Implementierung der SpecC Methdik ist mit der SpecC-Sprache als Basis. Es sllte Mdellierung, Analyse, Verfeinerung und Synthese in sich vereinen. Dieses Tl entstand im Rahmen meiner Diplmarbeit am Center fr Embedded Cmputer Systems der University f Califrnia, Irvine und bekam den Namen RESpecCT (= MPC-Wrkshp, Juli 2001

5 Refinement and Explratin tl fr the SpecC Technlgy). Seine wesentlichen Merkmale sind: Visualisierung vn Designs Anzeige vn Analyse-Ergebnissen Eingabe vn Design-Entscheidungen Leicht zu bedienen Übersichtlich Plattfrm-unabhängig Die Implementierung der Übergänge zwischen den Abstraktinsebenen wurden vn Dktranden gemacht und als shared libraries eingebunden. Die Prgrammierung erflgte mit Pythn, einer sehr flexiblen High-Level Sprache und QT als grafischem Tlkit Designanalyse (Prfiling) Die Designanalyse (Prfiling, Estimatin) dient dazu möglichst viele Infrmatinen über das Design zu sammeln und dem Nutzer zur Verfügung zu stellen, damit er bessere Entscheidungen fällen kann. Er bekmmt dabei z.b. Auskunft über Art und Häufigkeit vn bestimmten Operatinen in beliebigen "Zweigen" des Designs (Abbildung 6). Ausserdem kann die Designanalyse dabei helfen kritische Punkte im Design (sg. ht spts) zu detektieren und durch Änderungen vn Designentscheidungen der Anpassung des Cdes zu entschärfen. Dabei kann auch die Einhaltung vn Designcnstraints überprüft werden IDE Abbildung 5 zeigt die RESpecCT Oberfläche. Grundsätzlich kann links die Behavir-Hierarchie eingesehen werden. Auf der rechten Seite ist ein MDI (Multiple Dcument Interface) in dem Infrmatinen über bestimmte Teile des Designs angezeigt werden können der der SpecC Cde direkt editiert werden kann. Der Benutzer wird nach und nach durch die verschiedenen Designebenen geführt und bekmmt Dialge präsentiert in denen gewisse Designentscheidungen getrffen werden müssen. Abbildung 6: Ergebnisse der Designanalyse 5. Zusammenfassung Abbildung 5: RESpecCT IDE Jedem in der Chipbranche ist längst klar, dass in Zukunft ganz andere Tls zur Entwicklung vn Chips, Embedded Systemen und Systemen allgemein benötigt werden. Welches Tl sich letztendlich auf dem Markt durchsetzen wird wird die Zukunft entscheiden. Im Vergleich mit anderen Ansätzen wie System-C ist SpecC deutlich knsequenter und knsistenter. Alle Ansätze sind immer nch weit vn einer breiten industriellen Nutzung entfernt, jedch kmmt SpecC mit RESpecCT diesem Ziel einen entscheidenden MPC-Wrkshp, Juli, 2001

6 Schritt näher. Auch wenn nch viel Arbeit gemacht werden muss in Bezug auf Biblitheken und im Backend s zeigt sich heute schn, dass die Kmbinatin vn: a) der SpecC Methdik, geschaffen für die Kmplexität zukünftiger Designs, in Verbindung mit b) der SpecC Sprache, die perfekt an die Prblematik vn System Level Design angepasst ist und c) RESpecCT, einer grafischen Erweiterung die intuitive Interaktin mit den Designs ermöglicht, auf dem besten Weg ist ein mächtiges Werkzeug für die effiziente Entwicklung vn kmplexen Systemen der Zukunft zu werden 6. Referenzen [1] David Berner, Develpment f a Visual Refinement and Explratin Tl fr SpecC, Technical Reprt ICS-01-12, Irvine, Februar [2] D.Gajski et al, SpecC: Specificatin Language and Design Methdlgy, Kluwer Academic Publishers, [3] Gerstlauer, Dömer, Peng, Gajski, System Design: A Practical Guide with SpecC, Kluwer Academic Publishers, [3] R.Dömer, J. Zhu, D. Gajski, The SpecC Language Reference Manual, Technical Reprt ICS-98-13, Irvine, Januar Online: SpecC hmepage an der University f Califrnia Irvine SpecC Open Technlgy Cnsrtium (STOC) MPC-Wrkshp, Juli 2001