Hardwaresynthese

Hardware/Software-Codesign
Kapitel 5: Hardwaresynthese
M. Schölzel
Zur Erinnerung…
Prozessoren, ASICs, ASIPs, Busse, Speicher,…
System
Hardware
Programmiersprachen,
Hardwarebeschreibungssprachen,
DAGs, …
Logik
Boolesche Funktionen,
Zustandsautomaten,…
Architektur
Block
Modul
Software
ALUs, Register,
Multiplexer,…
Gatter, Flip-Flops, …
 Hardwaresynthese
Abstraktionen / Ebenen nach J. Teich
− High-Level-Synthese: Überführt Verhaltensbeschreibung auf
Architekturebene in Strukturbeschreibung auf Architekturebene
− Logiksynthese: Überführt Verhaltensbeschreibung auf Logikebene in
Strukturbeschreibung
Hardware/Software-Codesign
High-Level-Synthese
Ziel der High-Level-Synthese
Eingabe:
 Spezifikation einer Funktion durch verhaltensorientierte
Beschreibung
 Zeitbeschränkung
Ausgabe:
 Datenpfad und Steuerpfad, zur Berechnung der spezifizierten
Funktion
− bei Einhaltung der Zeitbeschränkung
− mit minimalen Ressourcen
Erzeugte Architektur
Strukturelle Beschreibung einer Architektur besteht aus:
 Datenpfad
− Funktionale Ressourcen (Addierer, ALUs, …)
− Kommunikationsressourcen (Leitungen, Busse)
− Speicherressourcen (Register, FIFOs, RAM, …)
 Kontrollpfad
Klassifikation Datenpfad:
 Multiplexer-basiert
 Bus-basiert
Klassifikation Kontrollpfad:
 Direktimplementierung
 Mikroprogrammiert
Multiplexer-basierte Architektur
in
Steuerwerk
(Automat)
Reg.
Reg.
Mux
Mux
F. U.
F. U.
Mux
Reg.
Datenpfad
out
Bus-basierte Architektur
Ergebnisbus
R1
R2
R3
R4
Operandenbus
Multiplizierer
ALU
R5
Ablauf High-Level-Synthese
 Eingabe:
− Spezifikation der Funktion (z.B. als VHDL-Programm, Hardware-C, C-Code, …)
 Übersetzung der Eingabe in Zwischencode + Optimierungen
(Eliminierung toten Codes, redundanter Berechnungen, …)
 Erstellung einer internen Beschreibung (z. B. Steuerflussgraph, DAG)
 High-Level-Synthese:
− Datenpfadsynthese
• Scheduling (Erstellen eines Ablaufplans)
• Allocation (Auswahl der Ressourcen)
• Binding (Zuordnung der Operationen zu Ressourcen)
− Kontrollpfadsynthese
Datenpfad-Synthese
Scheduling und Allocation sind eng verknüpft
Bei Optimierung der Ablaufzeit:
 In der Regel viele Ressourcen erforderlich
Bei Optimierung der Ressourcen:
 Hohe Ablaufzeiten
DAG
1
2
3
4
5
Zeitoptimiert
Ressourcenoptimiert
1
3
1
2
4
5
2
3
4
5
Problem-Graph
Takt 0
1
2
6
8
10
Takt 1
3
7
9
11
Takt 2
4
Takt 3
5
Takt 4
Ein Problemgraph ist ein gerichteter azyklischer Graph (DAG) mit
Knotenmenge V und Kantenmenge E Í V´V. Knoten sind Aufgaben, Kanten
beschreiben Abhängigkeiten zwischen den Aufgaben.
Ressource-Graph
Ein Ressourcengraph ist ein bibartiter Graph
(VR,K), wobei VR = V È VT und K Í V´ VT. VT
ist die Menge der Ressourcentypen. Eine
Kante (m,n) repräsentiert die Ausführbarkeit
der Aufgabe m auf dem Ressourcentyp n.
Weiterhin ist gegeben:
• Kostenfunktion c: VT ® , die jedem
Ressourcentyp Kosten zuordnet.
• Gewichtsfunktion w: K ® , die jeder
Kante (m,n) die Berechnungszeit der
Aufgabe m auf Ressource n zuordnet.
Ein Synthesemodell ist ein Paar aus
Problemgraph und Ressourcengraph: ((V,E),
(VR,K)).
Zu lösende Syntheseprobleme:
• Scheduling (Finden eines Ablaufplans s
zum Problemgraphen)
• Allokation
• Bindung
Multiplizierer
1
1
r1
3
2
α (r 1) = 1
1
1
1
6
1
1
7
8
ALU
α (r 2) = 1
1
r2
4
9
1
1
11
5
1
1
10
Allokation und Bindung
 Zu gegebenem Synthesemodell ((V,E), (VR,K)) legt eine
Allokation a : VT ®  die Anzahl der vorhandenen Instanzen
eines jeden Ressourcentyps fest.
 Zu gegebenem Synthesemodell ((V,E), (VR,K)) ist eine Bindung
gegeben durch:
− b: V ® VT mit (v, b(v))  K ist (Zuordnung zu einem Ressourcentyp)
− g: V ®  mit g(v) < a(b(v)) (Zuordnung zu einer Instanz eines
Ressourcentyps)
Implementierung
 Synthesemodell ((V,E), (VR,K)) ist gegeben.
 Eine obere Zeitschranke S
 Eine Implementierung ist eine Ablaufplanung, Allokation und
Bindung (s,b,g,a) mit folgenden Eigenschaften:
− Zeitschranke wird eingehalten:
• Für alle v  V: s(v) + w(v, b(v))  S
− In jedem Zeitschritt i werden die vorhandenen
Ressourcenbeschränkungen eingehalten:
• "i"r  VT:|{v |
s(v)  i < s(v) + w(v, b(v)) und
b(v)=r}|  a(r)
Ablaufplan und Bindung des
Problemgraphen
Ablaufplan des Problemgraphen bei
beschränkten Ressourcen
Takt 0
1
10
Takt 1
2
11
Takt 2
3
Takt 3
6
4
Takt 4
7
Takt 5
8
5
Takt 6
Takt 7
9
Ablaufplan des Problemgraphen bei
beschränkten Ressourcen mit Bindung
Takt 0
1
10
Takt 1
2
11
Takt 2
3
Takt 3
6
4
Takt 4
7
Takt 5
8
5
Takt 6
Takt 7
9
Datenpfad aus der Implementierung
ableiten
 Operationen mit gleicher Bindung werden
durch dieselbe Ressource implementiert
 Kanten werden Register
 Überlappende Kanten müssen auf
verschiedene Register abgebildet werden.
 Register, die von unterschiedlichen
Ressourcen beschrieben werden, erhalten
Multiplexer am Eingang
 Ressourcen, die Werte von verschiedenen
Registern nutzen, erhalten Multiplexer am
Eingang
Beispiel
Mux
R1
Mux
Ext
Mux
MUL
R2
Mux
Ext
Mux
Add, Cmp
Sub
Ablaufplanung (Scheduling)
Zeitpunkt der Ablaufplanung:
 statisch (zur Übersetzungszeit)
 dynamisch (zur Abarbeitungszeit der Aufgabe)
Zeitpunkt der Unterbrechnung
 Aufgabe darf unterbrochen werden (präemptive Ablaufplanung)
 Aufgabe darf nicht unterbrochen werden (nicht-präemptive Ablaufplanung)
Art der Beschränkung
 ressourcenbeschränkt
 zeitbeschränkt
Periodizität
 periodisch (Planung für iterative Ausführung)
 aperiodisch
Zeitbeschränkte Planung - As Soon
As Possible (ASAP)
Takt 0
1
2
6
8
10
Takt 1
3
7
9
11
Takt 2
4
Takt 3
5
Takt 4


0, falls v keinen Vorgänger hat
asap (v )  


max{asap (u )  delay(u ) | u ist Vorgänger von v}  1, sonst


Zeitbeschränkte Planung – As Late
As Possible (ALAP)
ALAP-Ablaufplan für L = 5
Takt 0
1
2
Takt 1
6
3
Takt 2
4
7
8
10
Takt 3
5
9
11
Takt 4


L  delay(v ), falls v keine Nachfolger hat
alap (L, v )  


min{alap (L, u ) | u ist Nachfolger von v}  delay(v ), sonst


ASAP-Scheduling mit bedingter
Verschiebung (ressourcenbeschränkt)
ASAP-Ablaufplan
ASAP-Ablaufplan mit bedingter Verschiebung
Takt 0
1
2
6
8
10
Takt 1
3
7
9
11
Takt 2
4
Takt 3
5
Takt 4
Ressourcenbeschränkung:
a(MUL) = 2, a(ALU) = 2
Ausgangspunkt ist ASAP-Ablaufplan ohne Ressourcenbeschränkung
Werden in einem Zeitschritt mehr Ressourcen benötigt, also vorhanden, dann
verschieben der nicht ausführbaren Operationen auf späteren Zeitpunkt.
Ressourcenbeschränkte
Ablaufplanung (List-Scheduling)
Bekannt
Zeitbeschränkte Ablaufplanung (ForceDirected-Scheduling)
Ähnlich dem List-Scheduling
Priorität einer Operation wird dynamisch bestimmt
anhand von:
 Mobilitätsintervall: (v) = [sasap(v), salap(v)]
 Ausführungswahrscheinlichkeit p(v,t):


1

, falls asap (v )  t  alap (v )

p(v, t )  
 (v )  1


0, sonst



 Belegung einer Ressource r:
q(r , t ) 

v V und v ist Operation, die
auf Ressource r ausgeführt
werden kann
p(v, t )
Beispiel Belegung einer Ressource
Takt 0
Takt 0
1
2
6
8
10
1
Takt 1
Takt 1
3
7
9
11
Takt 2
4
4
Takt 3
7
8
10
Takt 3
5
5
Takt 4
9
Takt 4
1 0
2 0
Takt 1
3
Takt 2
4
0
6
0
7
2
1
8
5 0
2
10
9
Belegung des Multiplizierers in
Zeitschritt 0:
2
2
1
Takt 3
Takt 4
6
3
Takt 2
Takt 0
2
11
q(MUL,0) =
p(1,0) + p(2,0) + p(6,0) + p(8,0) =
1 + 1 + 1/2 + 1/3 = 17/6 = 2,8333…
11
Belegungsgraph für das Beispiel mit
Multiplizierer und ALU
q k,t Multiplizierer
3
2
1
0
0
q
k,t
1
2
3
t
3
t
ALU
3
2
1
0
1
2
Selbstkraft
Mittlere Auslastung der Ressource r im Mobilitätsintervall der Operation v:

(v )
alap
1
  q(r , t )
qm (r , v ) 
(v )  1 t asap (v )
Selbstkraft der Operation v zum Zeitpunkt t, v benötigt Ressource r:
FvS,t  q(r , t )  qm (r , v )
Beispiel für Multiplikation
Takt 0
Takt 1
Takt 2
Takt 3
q(MUL,0)
qm(MUL,v)
q(MUL,1)
qm(MUL,v)
q(MUL,2)
qm(MUL,v)
q(MUL,3)
Mobilität der Operation v
Vorgänger-/Nachfolgerkräfte
Planung einer Operation v ändert Mobilität der Vor-/Nachfolgeroperation u
Geänderte Mobilität: (u)
Geänderte ASAP/ALAP-Zeit: alap(u), asap(u)
Mittlere Auslastung der Ressource r im neuen Mobilitätsintervall der Operation u:

(u )
alap
1
  q(r , t )
qn (r , u ) 
(u )  1 t asap (u )
Vor/Nachfolgekraftkraft der Operation u zum Zeitpunkt t, u benötigt Ressource r:
FuN,t  qn (r , u )  qm (r , u )
Beispiel für Multiplikation
Takt 0
q(MUL,0)
qm(MUL,u)
qn(MUL,u)
Takt 1
q(MUL,1)
qm(MUL,u)
qn(MUL,u)
q(MUL,2)
Takt 2
Takt 3
Neue Mobilität der Operation u
qm(MUL,u)
q(MUL,3)
Alte Mobilität der Operation u
Gesamtkraft
Fv,t  FvS,t 

u Succ (v )
FuN,t 

u Pred (v )
FuN,t
Eingabe: Problemgraph (V, E), Ressourcegraph, Zeitschranke L
Ausgabe: Ablaufplan s
while noch nicht alle Knoten aus V geplant do
Bestimme Mobilitätsintervalle aller nicht geplanten Operationen
Bestimme Belegungen der Ressourcen und Ausführungswahrscheinlichkeiten
Bestimme Gesamtkräfte aller Operationen
Plane Operation v in Zeitpunkt t für die Fv,t minimal ist
od
Bindung und Allokation
Ausgangspunkt ist eine Spezifikation bestehend aus Problem- und
Ressourcengraphen: ((V,E), (VR,K)) und
Eventuell eine Ablaufplanung s
Lösung durch Betrachtung von Verträglichkeiten/Konflikten:
 Verträgliche Aufgaben können auf derselben Ressource ausgeführt werden
 Aufgaben mit Konflikt müssen auf verschiedenen Ressourcen ausgeführt werden.
Takt 0
1
2
6
8
10
Takt 1
3
7
9
Takt 2
4
Takt 3
5
Takt 4
Problemgraph mit Ablaufplanung
11
Verträglichkeitsgraph
Ablaufplan-Verträglichkeit
Schwache Verträglichkeit
(Best Case)
Multi7
3
plizierer
ALU
Starke Verträglichkeit
(Worst-Case)
7
3
7
6
6
1
6
1
2
8
2
8
3
1
8
2
11
5
11
5
11
5
10
4
10
4
10
4
9
u ~w v, gdw. u und v können
auf derselben Ressource
ausgeführt werden.
9
u ~a v, gdw. u ~w v und u wird im
Ablaufplan erst gestartet,
nachdem die Ausführung von v
beendet wurde.
9
u ~s v, gdw. u ~w v und im
Problemgraphen ex. ein
gerichteter Pfad von u nach v.
Berechnung einer Bindung und
Allokation
Berechnung durch Finden maximaler Cliquen im
Ablaufplanverträglichkeitsgraphen
Im Bsp.: {4,5,10,9}, {11}, {2,7},{3,8},{1},{6}
Es werden damit 2 ALUs und 4 Multiplizierer benötigt.
Ablaufplan-Verträglichkeit
11
5
Takt 0
1
2
6
8
10
Takt 1
10
3
4
9
7
Takt 2
7
3
4
Takt 3
6
5
1
Takt 4
2
8
9
11
Konflikt-Graph
Berechnung der Bindung und Allokation durch Färbung des Konfliktgraphen (analog der Färbung des
Interferenzgraphen)
Im Bsp: {4,5,10,11},{9}, {7,6}{3,1},{2},{8}
Damit wieder 2 ALUs und vier Multiplizierer
Konfliktgraph nach der Ablaufplanung ist ein Intervallgraph
Finden der optimalen Lösung mit Left-Edge-Algorithmus in polynomieller Zeit möglich.
7
3
Konfliktgraph nach
Ablaufplanung (komplementär
6
1
zum Verträglichkeitsgraphen)
2
8
Takt 0
1
11
2
6
8
10
5
Takt 1
3
7
Takt 2
4
10
4
Takt 3
u ~k v, gdw. u sind nicht schwach
verträglich und werden im Ablaufplan Takt 4
zur selben Zeit verarbeitet.
9
5
9
11
Intervall-Graph
2
4
3
5
1
4
2
3
1
0
2
4
5
6
8
10
12
14
16
18 t
Ein ungerichteter Graph (V, E) heißt Intervallgraph, falls man jedem Knoten v 
V einen Intervall [av,ev) mit av, ev   und av  ev zuordnen kann, so dass eine
Kannte (u,v)  E genau dann existiert, falls sich die Intervalle [au, eu) und [av,ev)
überlappen.
Sortierung der Intervalle und
Färbung
Left-Edge-Algorithmus bearbeitet die Knoten in aufsteigender Reihenfolge der linken
Intervallgrenzen au und weist jedem Knoten die kleinste Farbe zu, mit der noch kein
Knoten gefärbt ist, dessen Intervall mit dem Intervall des aktuellen Knotens überlappt.
Kontrollpfadsynthese
Erzeugen eines Moore-Schaltwerkes (direktimplementiert)
Gegeben ist eine Implementierung mit einer Latenz L
Konstruktion eines Zustandsdiagramms mit L vielen Zuständen z0,…zL-1.
Zustand zi repräsentiert Zeitschritt i
Eingangssignal reset
x , falls e  reset
Startzustand x0
f (z , e)  
z , sonst
Zustandsübergangsfunktion:

0
i
2
3
5
4
r2
MUL1
r1
MUL2
ALU1
ALU2
r2
1
r2
r3
6
r3
r1
r1
r2
r3
Kontrollpfad
r1
Steuersignale
i 1
Kontrollpfadsynthese Mikroprogrammgesteuert
Kontrollwort
Nächste Adresse
ROM
Instr. 1: *, *,
+Instr. 2: *, *,
Zustand
Reset
Adresse
<Instr. 3: -, *,
*Instr. 4: -, +
Takt
Steuerwerk
Optimierung der Taktperiode
t(rk) ist die Verzögerungszeit, der Ressource rk
Maximale Operatorverzögerung:
T  max t(rk ) | rk  VT 
Schlupf:
 t(r ) 
s(T , rk )   k   T  t(rk )
 T 
Minimierung des mittleren Schlupfes
bei gegebener Implementierung
h(rk) sei die Anzahl der Operationen, die an die Ressource rk
gebunden sind.
|V |
T
Mittlerer Taktschlupf:
ms(T ) 
 h(r )  s(T , r )
k 1
k
k
|VT |
 h(r )
k 1
k
Minimierung von ms(T) durch Berechnen aller möglichen
mittleren Taktschlupfe für Perioden im Intervall [Tmin,…,Tmax]
Tmin bzw. Tmax sind minimale/maximale Perioden der
Ressourcen
Mit optimalem Topt kann dann die Ausführungszeit
berechnet werden: Tex = L * Topt
Entwurfsraumexploration von
anwendungsspezifischen BefehlssatzProzessoren (ASIPs)
Basiselemente in LISA
RESOURCE
{
}
Beschreibt Architektur der
Speicherelemente im Prozessor:



Arbeitsspeicher
Register
Pipeline
Alle vereinbarten Ressourcen sind
global in der LISA-Beschreibung
gültig
OPERATION
{
CODING { … }
SYNTAX { … }
BEHAVIOR { … }
}
Alle Operationen zusammen
beschreiben den Befehlssatz des
Prozessors



Coding: Binärcodierung
Syntax: Syntax des Assemblerbefehls
Behaviour: Verhalten des Befehls
Beispiel für Ressourcendeklaration
RESOURCE {
PROGRAM_COUNTER uint32 PC;
REGISTER uint32 IR;
REGISTER uint32 GPR[0..31];
}
RAM uint32 prog_mem {
SIZE(0x1000)
BLOCKSIZE(32)
FLAGS(R|X)
};
MEMORY_MAP {
RANGE(0x0000, 0x0FFF) -> prog_mem[(31..0)];
}
PIN bit[1] IRQ, NMI
Mehrere RESOURCEAbschnitte erlaubt
Verfügbare Ressourcen in
LISA:
 REGISTER
 PROGRAM_COUNTER
 RAM
− Size: Anzahl der Elemente im
Speicher
− BLOCKSIZE: Bits in einem
Element
− FLAGS: R=Lesbar, W=Schreibbar,
X=Ausführbar
 MEMORY_MAP
RESOURCE {
uint16 forwarded_address;
}
− RANGE: prog_mem wird auf
Bereich 0x0 … 0xfff abgebildet
 PIN: Pins des Prozessors
 Globale Variablen
Simple Form der Kodierung einer
Operation
ADD r0, r1, r2
OPERATION add {
SYNTAX { „ADD“ „r0“, „r1“, „r2“ }
CODING {0b0[6] 0b00001 0b00010 0b00000 0b0[5] 0b100000 }
BEHAVIOR {GPR[0] = GPR[1] + GPR[2]; }
}
Immer 0
Opcode
Problem: So müsste für jeden Befehl und jede Registerkombination
eine separate OPERATION-Deklaration angegeben erden.
Lösung: Deklaration von Gruppen.
Hierarchie von Operationen
Add-Operation:
Sub-Operation:
instruction behavior: GPR[0] = GPR[1] + GPR[2]
instruction syntax : "ADD r0, r1, r2"
instruction coding : 000000 00001 00010 00000 00000 100000
instruction behavior: GPR[0] = GPR[1] - GPR[2]
instruction syntax : "SUB r0, r1, r2"
instruction coding : 000000 00001 00010 00000 00000 100010
OPERATION add {
SYNTAX { „ADD“ }
CODING {0b100000}
BEHAVIOR {
result = operand1 + operand2
}
}
behaviour call
OPERATION sub {
SYNTAX { „SUB“ }
CODING {0b100010}
BEHAVIOR {
result = operand1 - operand2
}
}
• Ein Bezeichner für
OPERATION alu {
mehrere Gruppen
DECLARE {
• Obergruppe enthält
GROUP opcode = {add || sub}
gemeinsames
}
Verhalten.
SYNTAX { opcode ~ „r0“, „r1“, „r2“ }
• Untergruppen
CODING {0b0[6] 0b00001 0b00010 0b00000 0b0[5] opcode}
modellieren
BEHAVIOR {
alternatives
operand1 = GPR[1];
Verhalten.
operand2 = GPR[2];
• Gruppenname wird
opcode();
als Platzhalter für
GPR[0] = result;
korrespondierende
}
Sektion in der Unter- }
gruppe verwendet
Operationsgraph
alu
add
sub
Kodierung/Dekodierung der
Operationen
Assembler:



Vergleicht die eingegebenen Assembleranweisung mit allen
möglichen Assembleranweisungen, die sich durch den
Operationsbaum ergeben.
Die passende Folge der Knoten wird aktiviert
Die aktivierten Knoten werden zur Kodierung verwendet.
Simulator:



opcode r0,r1,r2
alu
add
opcode = add
sub
opcode = sub
Vergleicht Bitmuster der zu simulierenden Operationen mit
allen möglichen Bitmustern, die sich im Operationsbaum
bilden lassen
000000 00001 00010 00000 00000 opcode
Die passende Folge der Knoten wird aktiviert
Behaviour-Sektion der aktivierten Knoten wird zur
alu
Ausführung der Anweisung verwendet.
Disassembler:


Passende Knoten werden wie im Simulator aktiviert.
Syntax-Sektion dieser Knoten wird genutzt, um den
Assemblerbefehl zu erzeugen.
HDL Code Generator:

Nutzt alle Coding-Sektionen, um daraus den HDL-Code für die
Dekodierlogik der Befehle zu erzeugen.
add
opcode = 100000
sub
opcode = 100010
Generische Operanden
Add-Operation:
Sub-Operation:
Verhalten: GPR[dest] = GPR[src1] + GPR[src2]
Syntax: "ADD r<dest>, r<src1>, r<src2>"
Codierung: 000000 <src1> <src2> <dest> 00000100000
Verhalten: GPR[dest] = GPR[src1] - GPR[src2]
Syntax: "SUB r<dest>, r<src1>, r<src2>"
Codierung: 000000 <src1> <src2> <dest> 00000100010
OPERATION add {
SYNTAX { „ADD“ }
CODING {0b100000}
BEHAVIOR {
result = operand1 + operand2
}
}
• Mehrere Bezeichner
für eine Gruppe.
• Obergruppe
modelliert
gemeinsames
Verhalten.
• Untergruppe
modelliert gleiches
Verhalten an
verschiedenen
Stellen in der
Obergruppe.
OPERATION reg {
DECLARE { LABEL idx; }
SYNTAX { „r“~idx=#U}
CODING {idx=0bx[5]}
EXPRESSION { idx }
}
OPERATION alu {
DECLARE {
GROUP opcode = {add || sub}
GROUP dest, src1, src2, = {reg}
}
SYNTAX { opcode ~ dest „,“ src1 „,“ src2 }
CODING {0b0[6] src1 src2 dest 0b0[5] opcode}
BEHAVIOR {
operand1 = GPR[src1];
operand2 = GPR[src2];
opcode();
GPR[dest] = result;
}
}
OPERATION sub {
SYNTAX { „SUB“ }
CODING {0b100010}
BEHAVIOR {
result = operand1 - operand2
}
}
Label ist ein lokaler
Bezeichner innerhalb einer
Operation mit:
• textueller Repräsentation
in Syntax-Sektion
• Binärrepräsentation in
Coding-Sektion
• Wert in Behavior-Sektion
Anpassung durch Assembler
Eingabe:
ADD r4, r5, r1
OPERATION alu {
…
SYNTAX { opcode ~ dest „,“ src1 „,“ src2 }
…
idx=1
}
idx=4 idx=5
OPERATION add {
SYNTAX { „ADD“ }
…
}
OPERATION sub {
SYNTAX { „SUB“ }
…
}
OPERATION reg {
…
SYNTAX { „r“~idx=#U}
…
}
Codierung durch Assembler
Ausgabe: 000000 00101 00001 00100 00000 100000
OPERATION alu {
…
SYNTAX { opcode ~ dest „,“ src1 „,“ src2 }
CODING {0b0[6] src1 src2 dest 0b0[5] opcode}
idx=4
…
idx=1
idx=5
}
OPERATION add {
SYNTAX { „ADD“ }
CODING {0b100000}
…
}
OPERATION reg {
…
SYNTAX { „r“~idx=#U}
CODING {idx=0bx[5]}
…
}
Matching im Simulator
Eingabe:
000000 00101 00001 00100 00000 100000
OPERATION alu {
…
CODING {0b0[6] src1 src2 dest 0b0[5] opcode}
…
}
idx=4
idx=5
OPERATION reg {
…
CODING {idx=0bx[5]}
…
}
idx=1
OPERATION reg {
…
CODING {idx=0bx[5]}
…
}
OPERATION add {
…
CODING {0b100000}
…
}
OPERATION reg {
…
CODING {idx=0bx[5]}
…
}
OPERATION sub {
…
CODING {0b100010}
…
}
Evaluierung durch Simulator
OPERATION alu {
…
CODING {0b0[6] src1 src2 dest 0b0[5] opcode}
BEHAVIOUR {
operand1 = GPR[src1];
operand2 = GPR[src2];
opcode();
GPR[dest] = result;
}
}
OPERATION add {
…
CODING {0b100000}
BEHAVIOR {
result = operand1 + operand2
}
}
idx=5
OPERATION reg {
…
CODING {idx=0bx[5]}
EXPRESSION { idx }
}
idx=1
OPERATION reg {
…
CODING {idx=0bx[5]}
EXPRESSION { idx }
}
idx=4
OPERATION reg {
…
CODING {idx=0bx[5]}
EXPRESSION { idx }
}
Modellierung gemeinsamen Verhaltens
in verschiedenen Operationen
OPERATION alu {
DECLARE {
GROUP opcode = {add || sub}
GROUP dest, src1, src2, = {reg}
}
SYNTAX { opcode ~ dest „,“ src1 „,“ src2 }
CODING {0b0[6] src1 src2 dest 0b0[5] opcode}
BEHAVIOR {
operand1 = GPR[src1];
operand2 = GPR[src2];
opcode();
GPR[dest] = result;
}
}
OPERATION load {
DECLARE {
GROUP dest = {reg}
LABEL addr
}
SYNTAX { „LOAD“ ~ “ „ dest „,“ „@“~ addr=#X}
CODING {0b1[5] dest addr=0bx[16] 0b111011 }
BEHAVIOR {
result = data_mem[addr];
GPR[dest] = result;
}
}
Zurückschreiben wird in beiden Operationen genutzt.
Instanzen zur Nutzung
gemeinsamer Funktionalität
OPERATION alu {
DECLARE {
GROUP opcode = {add || sub}
GROUP dest, src1, src2, = {reg}
}
SYNTAX { opcode ~ dest „,“ src1 „,“ src2 }
CODING {0b0[6] src1 src2 dest 0b0[5] opcode}
BEHAVIOR {
operand1 = GPR[src1];
operand2 = GPR[src2];
opcode();
writeback();
}
}
OPERATION load {
DECLARE {
GROUP dest = {reg}
LABEL addr
}
SYNTAX { „LOAD“ ~ “ „ dest „,“ „@“~ addr=#X}
CODING {0b1[5] dest addr=0bx[16] 0b111011 }
BEHAVIOR {
result = data_mem[addr];
writeback();
}
}
OPERATION writeback{
BEHAVIOR {
GPR[dest] = result;
}
}
Problem: dest ist nur lokal in den Operationen alu und load gültig.
Lösung des Problems: Referenzen
OPERATION alu {
DECLARE {
GROUP opcode = {add || sub}
GROUP dest, src1, src2, = {reg}
}
SYNTAX { opcode ~ dest „,“ src1 „,“ src2 }
CODING {0b0[6] src1 src2 dest 0b0[5] opcode}
BEHAVIOR {
operand1 = GPR[src1];
operand2 = GPR[src2];
opcode();
writeback();
}
}
OPERATION writeback{
DECLARE {
REFERENCE dest;
}
BEHAVIOR {
GPR[dest] = result;
}
}
OPERATION load {
DECLARE {
GROUP dest = {reg}
LABEL addr
}
SYNTAX { „LOAD“ ~ “ „ dest „,“ „@“~ addr=#X}
CODING {0b1[5] dest addr=0bx[16] 0b111011 }
BEHAVIOR {
result = data_mem[addr];
writeback();
}
}
Eine Referenz ist ein lokaler Bezeichner,
der sich auf eine Gruppe in einer
übergeordneten Operation bezieht.
Zusammenfassen aller Befehle
decode
load
alu
add
nop
sub
OPERATION decode{
DECLARE {
GROUP instruction = { nop || alu || load };
}
CODING AT (PC) { IR == instruction }
SYNTAX { instruction }
BEHAVIOR { instruction(); }
}
Mechanismus Befehlsausführung
OPERATION main {
DECLARE {
INSTANCE fetch;
}
BEHAVIOR {
fetch();
}
}
OPERATION reset {
BEHAVIOR {
int i;
for(i=0; i < 32; i++) {
GPR[i] = 0;
}
IR = 0 ;
PC = LISA_PROGRAM_COUNTER
operand1 = 0;
operand2 = 0;
result = 0;
}
}
OPERATION fetch{
DECLARE {
INSTANCE decode;
}
BEHAVIOR {
IR = prog_mem[PC];
PC = PC + 1;
decode();
}
}
OPERATION decode{
DECLARE {
GROUP instruction = { nop || alu || load };
}
CODING AT (PC) { IR == instruction }
SYNTAX { instruction }
BEHAVIOR { instruction(); }
}
main
fetch
Architekturunabhängig:
Keine Kodierung, keine
Syntax
Schnittstelle zum
Befehlssatz
decode
load
alu
add
nop
sub
Compiler Generierung
Erweiterung der LISA-Schlüsselworte um:
 REGISTER, IMMEDIATE, INSTRUCTION
Dadurch Kennzeichnung von Operationen, die
 eine Instruktion im Befehlssatz des Prozessors repräsentieren
 ein Register / einen Registersatz repräsentieren
 eine Konstante repräsentieren
Einhaltung verschiedener Guidelines erforderlich, insbesondere
zur automatischen Extraktion von Abhängigkeiten zwischen LISAOperationen
Bereitstellung weiterer Informationen:
 Abbildung aller C Datentypen und Operationen auf Assembleranweisungen
 Stackaufbau/Abbau bei Funktionsaufrufen
 Unterstützung für spezielle Operationen, die besonders effizient durch den
Prozessor verarbeitet werden können (z.B. MAC)
Ablauf im Compilerbackend in LISA
Frontend
IR-Code
Code
Selection
Register
Allocation
Scheduling
Assemblercode
 Code Selection: benötigt
Spezifikation aller Muster
 Register Allocation: benötigt
Spezifikation aller nutzbaren
Register (wird teilweise schon
automatisch aus der LISABeschreibung extrahiert).
 Scheduling: benötigt Informationen
über Latenz der einzelnen
Instruktionen und Abhängigkeiten
(Ziel, Quelloperanden werden aus
LISA-Beschreibung extrahiert).
Matcher
Quelle: LISA-Tutorial
Spezifikation eines Musters in LISA
Quelle: LISA-Tutorial
Architekturgetriebene
Entwurfsraumexploration mit LISA
Zielarchitektur
LISA-Beschreibung
Zielarchitektur
Anwen
-dung
Compiler
Linker
Assembler
Simulator
VHDL-Code des
Prozessors
Synthesecompiler
Netzliste
Profiling
(Ausführungszeit)
Profiling
(Taktfrequenz, Fläche,
Stromverbrauch)
Design by Compilation
Compiler übersetzt Anwendung ohne die
Zielarchitektur zu kennen
Überblick
Scheduling
Ziel: Minimierung der verwendeten Ressourcen bei
gegebener Ablaufplanlänge l:
 Minimierung der Slots:
 Minimierung der Operatoren:
Verwendung von zeitbeschränkten
Ablaufplanungsverfahren
Ablaufplanung beachtet folgende
Ressourcenallokationsphase
Ressourcenallokation
Selection: Slot Optimierung
Selection: Typoptimierung
Abschließende Allokation