Kriterien zur Hardware/Software-Partitionierung beim Systementwurf
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Kriterien zur Hardware/Software-Partitionierung beim
Systementwurf
Wofram Hardt, Raul Camposano
Universität Gesamthochschule Paderborn, 33095 Paderborn
e-mail: hardt@uni-paderborn.de
Abstrakt. HW/SW-Codesign bietet viele Vorteile (z.B. bzgl. Verifikation und Simula-
tion) im Systementwurf. Der gemeinsame Entwurf macht eine HW/SW-Partitionierung
erforderlich. Hierfür werden Kriterien aufgestellt, basierend auf der Bewertung von
Hardware- und Softawarerealisationen unterschiedlich komplexer Basiselemente.
1.0 Einleitung
In jüngster Zeit wird HW/SW-Codesign von verschiedenen Seiten untersucht. Zum einen extrahiert man Teile
der Software, die einen wesentlichen Teil der Hardware-Resourcen belegen und implementiert sie durch spe-
zielle Hardware [Henk92]. Diese Methode wird besonders durch zeitkritische Anwendungen motiviert. Zum
anderen werden Teile aus einem Hardware-Design identifiziert und in Software realisiert. Kandidaten hierfür
sind z.B. datenabhängige Konstrollstrukturen [Gupt92]. In unserem Ansatz untersuchen wir den Trade-Off
zwischen Hardware- und Softwareimplementationen. Verschiedene Abstraktionsebenen werden von unten
nach oben (Bottom-Up) untersucht. Zu differenzieren sind die Hardware-Ebene (Computer und zusätzliche
Spezialhardware), die Assembler-Ebene (Maschinensprache), die Hochsprachen-Ebene (z.B. C oder C++),
die SW-Modul-Ebene (z.B. Funktionen, Prozeduren) und die Applikations-Ebenen (z.B. Compiler). Charak-
teristische Elemente jeder Ebene werden in Hardware implementiert und mit der jeweiligen Softwarerealisie-
rung verglichen (Bild 1).
SW
SW-Application 4
SW-Module 3
Programming Language 2
Assembler
Assembler 1
HW
Logic
Bild 1. Abstraktionsebenen
Es ist zu Beachten, daß zusätzliche Software wie z.B. das Betriebssystem nicht berücksichtigt wird. Das
würde den Ansatz zu sehr verkomplizieren. Hier werden Kriterien entwickelt zur HW/SW-Partitionierung
basierend auf dem HW/SW-Trade-Off auf den verschiedenen Ebenen. Als HW/SW-Codesign Scenario haben
wir die bekannte Sparc-Architektur [Cyp90] ausgewählt, insbesondere auch deshalb weil die Anbindung spe-
zieller Hardware als Coprocessor vorgesehen ist.
-1-2.0 Vergleich von Hardware- und Softwaredesigns
Prizipiell lassen sich Hadwaredesigns derselben Technologie vergleichen. Wesentliche Bewertungskriterien
sind Größe (Fläche) und Zeit (Verzögerung). Softwareapplikationen dagegen mißt man an der Größe des
Sourcecodes (Lines of Code), der Größe der ausführbaren Dateien (abhängig von Compiler, Maschine und
Operationssystem) und der erforderlichen Datenmenge. Zum Vergleich von Hardware- und Softwaredesigns
beschränken wir uns auf die Kriterien Fläche und Zeit.
2.1 Fläche
Für Hardwaredesigns leiten wir das Flächenmaß aus der aktiven Fläche des Entwurfs ab. Dazu wird die
abstrakte Systembeschreibung synthetisiert und in einer bestimmten Technologie implementiert, z.B. in einer
2 µm CMOS Technologie. Aus den Bibliotheksdaten [Miet04] wird die absolute Fläche ermittelt.
Die Flächenermittlung für Softwareapplikationen beruht auf unser Entscheidung, spezielle Hardware an eine
bestehende Architektur anzubinden. Eine Verschiebung von Hardwaremoduln in Software, läßt sich durch die
Größe des zusätzlich belegten Speichers messen. Tabelle 1 gibt die charakteristischen Daten eines Speicher-
Feature Characteristic
Organization 1M x 4
I/O Interface TTL
Power single 3.3V
Cell size 1.43µm x 3.04 µm
Chip size 6.2 mm x 10.6 mm
Design 0.5 µm
Tabelle 1. Charakteristika eines 4 MB Speicherbausteins
bausteins an [Naka92]. Damit ergibt sich eine Fläche von 139 µm pro 32-Bit Wort. Es ist zu beachten, daß die
verwendete Technologie viel kleiner ist als die, die für die speziellen Hardwaremoduln verwendet wurde. Das
ist übliche Praxis.
2.2 Zeit
Synchrone Systeme werden vielfach durch einen gemeinsamen Takt gesteuert. Dieser ist abhängig von der
eingesetzten Technologie und der Systemkonfiguration. Die ausgewählte Sparc-Architektur wird durch einen
33 MHz Takt gesteuert. Das ist als Einschränkung beim Scheduling zu berücksichtigen. Trade-Offs, die sich
durch eine höhere Taktrate einzelner Moduln ergeben, werden hier nicht untersucht.
Die Ausführungszeit von Software kann durch die Anzahl der abgearbeiteten Befehle approximiert werden.
Da pauschale Durchschnittswerte insbesondere für kleine Moduln zu sehr ungenauen Abschätzungen führen,
untersuchen wir den Assemblercode, der durch den GNU Compiler [Stal92] generiert wird explizit. Jeder
Befehl wird mit der Ausführungsdauer unter Berücksichtigung der ausgewählten Architektur, gewichtet.
Damit werden Pipeline-Effekte und Parallelität von Instruktions- und Floatingpointeinheit berücksichtigt.
Tabelle 2 enthält einen Auszug aus der ermittelten Gewichtungstabelle. Für größere Applikationen müssen
Cache- und Speicherzugriffsfehler einbezogen werden [Smith82], [Smith86], [Good83].
3.0 Trade-Offs
Die Assembler-Ebene wird durch den Befehlssatz des Prozessors definiert. Viele verschiedene Befehlssätze
sind bekannt und man kann sie z.B. in die Gruppen RISC1 und CISC2 einteilen. Zum einen wird die Ausfüh-
-2-Instruktion Zyklen Floating Point Zyklen
Instruktionen
conditional jump 2 FADDs 5
unconditional jmp 3 FCMPs 4
load 2 FDIVs 23
load double floating point 3 FDIVd 37
store 3 FSQRTs 34
arithmetic/logical 1 FSQRTd 63
Tabelle 2. Instruktions-Ausführungszeiten in Zyklen [Cyp90]
rungszeit pro Instruktion und zum anderen die Anzahl der Instruktionen pro beabsichtigter Aktion optimiert
[Patt90]. HW/SW-Codesign auf dieser Ebene würde bedeuten, kurze Sequenzen von Instruktionen in Hard-
ware zu implementieren. Dies kommt einer Erweiterung des Befehlssatzes gleich. Der Entwurf von Befehls-
sätzen ist ein altes Forschungsgebiet [Lund77], [Kemm67]. Die Granularität der betrachteten Elemente ist
Time
Cycle
31
29
27
25
23 Compiler: GNU
21 Machine : Sparc_4
19
17
15
13
11
9
7
5
3
1
Constructs
int a=0 a==0 void f () if-then for of “C”
a=12 a==C void f (int) if-then-else while ... do
a++ a==b int f () if (0) then do ... while
int* f () if (1) then
char f ()
char* f () switch [8]
assign compare call control loop
Bild 2. Ausführungszeit von C-Konstrukten
sehr fein und die erreichten Verbesserungen können durch eine Verlangsamung der Ausführungszeiten insge-
samt kompensiert werden. Daher erwarten wir auf dieser Ebene keine wesentlichen Verbesserungen durch
HW/SW-Codesign.
1. Reduced Instruction Set Computer
2. Complex Instruction Set Computer
-3-Verschiebt man die Betrachtungsebene in Richtung Software, Hochsprachen-Ebene, vergröbert sich die
Granularität der zu betrachtenden Elemente. Die Konstrukte einer Hochsprache werden durch Sequenzen von
Maschineninstruktionen implementiert. Wir haben die bekannte Hochsprache “C” für eine illustrative Ana-
lyse ausgewählt. Die Sprachkonstrukte können in vier Klassen eingeteilt werden: Assignment, Comparison,
Call und Control. Bild 2 veranschaulicht das Ergebnis. Der durchschnittliche Aufwand der Basiselemente
jeder Kategorie wird durch die Schattierung angedeutet. Unsere Schlußfolgerung an diesem Punkt ist, daß
selbst die Konstrukte einer Hochsprache innerhalb von sehr wenigen Zyklen realisiert werden können. Die
einzige Ausnahme ist das switch-Konstrukt, das hier mit 29 Zyklen angegeben ist.
In Bild 3 ist eine standardisierte Version des switch-Konstuktes definiert. Der break-Befehl ist zur Vermei-
dung von Seiteneffekten (z.B. die Ausführung mehrere Fälle bei einem Durchlauf) notwendig.
switch ( int A )
{
case 0: { sequence of C-commands} break;
case 10: { sequence of C-commands} break;
case 20: { sequence of C-commands} break;
.
.
.
case n: { sequence of C-commands}; break;
}
FIGURE 3. Standard Switch-Konstrukt
Die Skizze einer auf acht Fälle beschränkten Hardware-Implementation ist in Bild 4 angegeben. Die Ein-
gangsregister können vom Hauptspeicher mit den relevanten Adressen geladen werden. Diese Beschreibung
wurde synthetisiert und mit der Softwarerealisierung verglichen (Einträge für “case” in Tabelle 3 und
Tabelle 5). Hier sind wesentliche Verbesserungen im Zeitverhalten festzustellen, sofern kein Kommunikati-
onsaufwand berücksichtigt wird, d.h. das Laden der Register wird ignoriert. Das ist sinnvoll für feste Sprung-
Integer
Unit
MUX
D0 D1 D6 D7
...
Data Bus
Bild 4. Hardware-Implementation des Standard Switch-Konstruktes
adressen, z.B. bei Festverdrahtung oder einem einmaligen Ladevorgang in kleinen Applikationen. Im
schlechtesten Fall müssen alle Register geladen werden, während der Prozessor wartet. Dieser Wert ist in
Klammern angegeben.
-4-Die Konstrukte einer Hochsprache werden häufig in Funktionen oder Prozeduren, d.h. Moduln, zusammenge-
faßt. Auf der SW-Modul-Ebene haben wir einige Benchmarks [Ben92] von VHDL1 nach “C” konvertiert
und die Implementationen verglichen. Für die Hardwarerealisierung wurden die Ergebnisse von HIS verwen-
det, die in [Camp91] angegeben sind. Das Modul zur Berechnung des größten gemeinsamen Teilers (gcd)
wurde für vier Bits realisiert, der Diffeq und der Ellipic-Filter für 16 Bits. Tabelle 3 listet die ermittelten Grö-
ßen auf.
Fläche des Fläche der Duchschnittszeit Zeit der
Benchmark HW-Designs SW-Applikation des HW-Designs SW-Applikation
in µm2 *103 in µ m2 *103 in Zyklen in Zyklen
gcd 770 7.3 2.5 84
diffeq 12,960 10.9 5 144
ellipticF 12,000 22.1 13 312
case 6,541 5.9 1 (10) 44
Tabelle 3. Benchmarks implementiert in HW und SW
Im Vergleich dazu ist in Tabelle 4 die Größe bekannter Prozessoren angegeben [Patt90].
Area
Processor
mm2
Sparc 56
Intel 80486 160
MIPS R3000 72
Motorola 88100 81
Tabelle 4. Chipfläche bekannter Prozessoren realisiert in Ceramic-PGA Technologie
Auf dieser Ebene sind erste Verbesserungen durch Implementation in Hardware anstelle von Software fest-
stellbar. Das Zeitverhalten konnte um einen Faktor 4 bis 30 gesteigert werden. Dabei ist zu beachten, daß
diese Zahlen für einen Durchlauf aller Schleifen gelten. Jede weitere Iteration kann das Ergebnis verbessern,
aber die Anzahl der Iterationen kann nicht durch die Untersuchung des Programmcodes ermittelt werden.
Der Vergleich der Flächen muß die unterschiedliche Datenpfadbreite berücksichtigen. Geht man von Bit-
Slice-strukturierten Entwürfen aus, kann die Fläche des n-Bit Datenpfades durch Multiplikation des 1-Bit
Datenpfades mit n approximiert werden. Diese Werte sind auch in Tabelle 5 angegeben. Die Fläche der Hard-
warerealisation ist ungefähr 1000 mal größer als die der Softwarerealisierung. Andererseits ist die zusätzliche
Hardware verglichen mit dem Prozessor klein.
Benchmark Fläche Fläche Zeit Kontroll-
Instruktion
HW/SW HW/SW32 SW/HW (%)
gcd 105 840 33.6 18.8
diffeq 1188 2376 28.8 2.53
Tabelle 5. HW-SW Trade-Off
1. Hardwarebeschreibungssprache
-5-Benchmark Fläche Fläche Zeit Kontroll-
Instruktion
HW/SW HW/SW32 SW/HW
(%)
ellipticF 542 1084 24 1.2
case 1108 1108 (44) 4.4 29
Tabelle 5. HW-SW Trade-Off
Die o.g. Beispiele können in bezug auf die Anzahl der verwendeten Kontrollbefehle klassifiziert werden. Der
prozentuale Anteil der Sprungbefehle ist in Tabelle 5 angegeben. Korreliert man diese mit den vorhergehen-
den Ergebnissen, so stellt sich heraus, daß kontroll-dominierte Moduln bessere Kandidaten für HW/SW/
Codesign sind als z.B. arithmetisch-dominierte.
Auf der Applikations-Ebene werden verschiedene Ansätze verfolgt. Eine softwareorientierte Vorgehens-
weise extrahiert Hardwaremoduln aufgrund von Laufzeitanalysen [Ernst90]. Das ist besonders im Bereich
der Echtzeitanwendungen von Interesse. Ein anderer Ansatz geht von einer vollständigen Hardwarerealisie-
rung aus und transformiert datenabhängige Schleifen in Softwaremoduln [Gupt92]. Für ein Beispiel, einen
Ethernetz-Kontroller, das erfolgreich synthetisiert werden konnte, wurde eine Verkleinerung der Hardware
um etwa 20 Prozent ereicht. Wir legen den Schwerpunkt auf Applikationen, die in Standardsystemen häufig
benutzt werden, z.B. den Blitter [Ben92] ein Coprocessor für spezielle Datenmanipulation. Ein noch komple-
xeres Beispiel wird ein eingeschränkter Compiler sein. Entwicklungen von Hochleistungsarchitekturen zur
effizienten Ausführung von “C”-Programmen wie z.B. die CRISC-Architektur [Ditz87] basieren auf Ent-
wurfstechniken, die auch hier eingesetzt werden können.
4.0 Zusammenfassung und Ausblick
In dieser Arbeit haben wir den HW/SW Trade-Off auf unterschiedlich abstrakten Ebenen untersucht und dar-
aus elementare Partitionierungskriterien ermittelt. Unsere weiteren Forschungen konzentrieren sich auf die
Applikations-Ebene. Die Systembeschreibungen werden in das neu entwickelte ISF-Format [Camp93] trans-
formiert, das eine detailliertere Untersuchung größerer Moduln ermöglicht. Weitere Aspekte, wie z.B. die
Separierung von Kontroll- und Datenteil und die Definition von Modulcharakteristika, die eine vorteilhafte
Implementation in Hardware oder Software erlauben, werden einbezogen.
5.0 Referenzen
[Ben92] “Benchmarks for the 6th International Workshop on High-Level Synthesis.” Available through
electronic mail at ics.uci.edu, 1992.
[Camp91] R.Camposano, R.A.Bergamaschi, C.E. Haynes, M.Payer, S.M.Wu. High-Level VLSI Synthesis,
chapter 4, pages 79–104. Kluwer Academic Publishers, 1991.
[Camp93] Andreas Hoffmann, Heinz Josef Eikerling, Wolfram Hardt, Reiner Geneveriere, Raul
Camposano. “ISF- eine Entwurfsdarstellung für High-Level-Synthese.” Workshop des SFB 358
der TU Dresden und der ITG/GI, 1993.
[Cyp90] Cypress Semiconductor. “Sparc/RISC User’s Guide.” Ross Technology Subsidiary, 3901 North
First Street, San Jose, CA 95134. 1990.
[Ditz87] Daniel R. Ditzel, Hubert R. McLellan. “The Hardware Architecture of the CRISP
Microprocessor” ACM Computer Architecture News, Vol 15 No.2, pages 309-319, 1987.
[Ernst92] Rolf Ernst, Ulrich Holtmann. “Some experiments with low-level speculative computation based
on multiple branch prediction for the synthesis on high-performance, pipelined coprocessors.”
Sixth International Workshop on High Level Synthesis, pages 146–158, 1992.
[Gupt92] Rajesh K. Gupta and G. De Michelli. “System synthesis via hardware- software co-design.” CSL
TR-92-548, 1992.
-6-[Henk92] R.Ernst, J.Henkel “Hardware-Software Co-design of Embedded Controllers based on Hardware
Extraction” Proceedings of the ACM Workshop on Hardware-Software Co-design, 1992.
[Good83] J.R.Goodman J.E.Smith. “A study of instruction cache organizations and replacement policies.”
Proc. Tenth Annual Symposium on Computer Architecture, pages 132–137, January 1983.
[Patt90] D.A.Patterson, J.L.Hennessy. Computer Architecture A Quantitative Approach. MORGAN
KAUFMANN PUBLISHERS, INC., 1990.
[Keem67] W.M. Mc Keeman. “Language directed computer design.” Proc. 1967 Fall Joint Computer
Conf., Washington, D.C., pages 413–417, 1967.
[Lund77] A. Lunde. “Emperial evaluation of some features of instruction set processor architecture.”
Comm. ACM, pages 143–152, March 1977.
[Miet04] Mietec document S2SM 1.0.0. Mietec Standard Cell User Manual 2.4 um CMOS. EUROCHIP
Document MIE/F/04.
[Naka92] K. Nakagawa, N.Akiyama, T. Ohta, T. Someya, A.Tamba, Yuji Yokoyama a.o. “Circuit
Technologies for a 12ns 4Mb TTL BiCMOS DRAM at 3.3V Operation.” Symposium on VLSI
Circuits Digest of Technical Papers, pages 62–63, 1992.
[Smith82] A.J.Smith. “Cache memories.” Computing Surveys, pages 473–530, September 1982.
[Smith86] A.J.Smith. “Bibliography and readings on cpu cache memories and related topics.” Computer
Architecture News, pages 22–42, January 1986.
[Stal92] Richard M. Stallmann. Using and Porting GNU CC. Free Software Foundation Inc., December
1992.
Diese Arbeit wurde teilweise durch den Sonderforschungsbereich SFB 358 der Deutschen Forschungsge-
meinschaft (DFG) gefördert.
-7-Sie können auch lesen
