Upload
others
View
3
Download
0
Embed Size (px)
Citation preview
A. Steininger / TU Wien1
Asynchrone Designmethoden
wissenschaftliche Spielerei oder echte Alternative ?
A. Steininger / TU Wien2
Huffman CircuitsDelay ModelsBounded Delay Methoden
Bundled Data & Micropipelines
Delay Insensitive MethodenTransition SignalingNull Convention LogicCode Alternation Logic
Überblick
A. Steininger / TU Wien3
Ein kurzes Resumee ...Boole‘sche Logik beschreibt das Input/ Output-Mappingzeitfrei. Es wird also von kontinuierlich gültigenEingängen ausgegangen
Skew verursacht aber inkonsistente Eingänge und daher ungültige Zwischenzustände
FCBA
11110011110100011110101001000000
A. Steininger / TU Wien4
Idee: Vermeiden von SkewWenn wir stets nur je einSignal (Bit) ändern, dannkann sich auch der Skewnicht auswirken
Daten sind jederzeitkonsistent
A
Skew
ODER?
A. Steininger / TU Wien5
&
>=1
XYZ
W A&
&
K
L
M
Beispiel für Glitches
AMLKZYXW1110
1
010
1111 100
100
000
0000101111
00
11
11111
0
0
01
00
1
1
statisch !
A
∆ = 4
∆ = 3
∆ = 6
∆ = 2
A. Steininger / TU Wien6
Huffman Circuits
„Glitchfreie“ Auslegung der Logik Einfügen redundanter Zusatzterme in derNormalform-DarstellungProbleme:
nicht alle Glitches sind vermeidbarRestriktionen für Inputs erforderlichZusatzterme = redundante Logik
A. Steininger / TU Wien7
F = (X ∧ ¬Y ∧ ¬Z) ∨(¬W ∧ Z) ∨ (W ∧ Y)
1 11 11 1 1 1
1 1
00 01 11 10
00
0111
10
W
Z
Y
X
YZ
WX
1
W
1 11 1 1
1 1
00 01 11 1000
0111
10
ZY
X
YZWX
(¬W ∧ Z)F = (X ∧ ¬Y ∧ ¬Z) ∨(¬W ∧ Z) ∨ (W ∧ Y)
1 1
Optimierung im KV-Diagramm
(W ∧ Y)∨ (Y ∧ Z) ∨ (¬W ∧ X ∧ ¬Y)∨ (W ∧ X ∧ ¬Z)
A
A. Steininger / TU Wien8
Restriktionen für Inputs
Fundamental Mode („Grey-Codierung“)es ändert sich immer nur ein Input-Bit
Delay in der Rückkopplung nötigZustandscodierung schwierigfür Datenpfadelemente ungeeignet
Burst ModeInputs dürfen sich gruppenweise ändern
Burst-Mode erfordert lokalen Takt
A. Steininger / TU Wien9
DelayElements
Combinationallogic
Outputs
NextState
CurrentState
Inputs Z1
Zm
x1
xn
y1
yk
Delay in der Rückkopplung
A. Steininger / TU Wien10
Probleme bei Huffman Circuits
Delay im Feedbackimpliziert Timing-Annahmen („Bounded Delay“)verlangsamt Funktion erheblich
Kompliziertes Designbei Zustandscodierung & Datenpfadelementendurch lokalen Takt im Burst-Modewegen redundanter Terme Test ?
Keine Strukturierung
keine brauchbare Gesamtlösung
A
A. Steininger / TU Wien11
Es darf nur mit konsistenten, eingeschwungenen Zuständen operiert werden
? Wie unterscheidet man konsistente Zustände von Übergangszuständen oder Glitches ?
Zeitbedingungen für Konsistenzsynchrones Designasynchrone „bounded delay“ Verfahren (Timer)
Hinzufügen von „Meta-Information“asynchrone „delay-insensitive“ Verfahren (Codierung)
Grundproblem beim Design
A
A. Steininger / TU Wien12
Die wichtigsten Delay ModelsSynchroner Fall
begrenzte Delays, a priori bekannt (min, max)
fundamental (bounded delay)Grenze für (absolute) Delays für Gatter & Leitungen angenommen
scalable-delay-insensitiveGrenze für relative Abweichung zwischen Delaysangenommen
quasi-delay-insensitiveeinzige Annahme: alle Zweige einer „Gabel“ haben gleichen Delay
delay insensitivekeine Restriktionen für Delays (nur „endlich“)
A. Steininger / TU Wien13
Bounded Delay Methoden
Philosophie: Wir suchen weiterhin eineLösung im Zeitbereich, allerdings wollenwir kein globales Steuersignal sondernlokale Lösungen
Erspart Probleme mit TaktverteilungErlaubt detailliertere Optimierungen
Dazu sind Annahmen / Kenntnisse überdas Zeitverhalten nötig
A. Steininger / TU Wien14
Synchron versus Asynchron
Synchrones Designein globales Steuersignal
(ohne Feedback !)globale Timinganalyse
Asynchrones Designviele lokale Handshakes (= Feedback)lokale Timinganalysen
comb comb
comb comb
req
ack
A. Steininger / TU Wien15
Was benötigen wir?
HandshakeTransportmedium für Handshake-Information
SpeicherHalten der Ausgängevgl. Pipelineregister
Completion detectionSteuerung von req & ack
comb comb
req
ack
A. Steininger / TU Wien16
Bundled Data: Prinzip
Sender (REQ):"Daten gültig und dürfenverwendet werden„
Empfänger: (ACK)"Daten verarbeitet,dürfen entfernt werden"
REQ
ACK
DatenSender Emp-fänger
„explizites Handshaking“
A
A. Steininger / TU Wien17
Beispiel: Centronix-Protokoll
[Centronix Spec zu ETRAX100LX, „Fastbyte Mode“]
Daten
„REQ“
„ACK“
A. Steininger / TU Wien18
Bundled Data: Problem
Wie bestimmt man die Zeitpunkte „Daten gültig“ und „Daten verarbeitet“ ?
(=> Timing der Steuersignale )Lösungen:
Steuerpfad muss langsamer sein als Datenpfad:bounded Delay model (absolut)scalable delay insensitive (relativ)
kann nie delay-insensitive sein !Current Sensing
A. Steininger / TU Wien19
Codierung der Steuersignale
Information wird nicht über den Zustand eines Signals
dargestellt, sondern über Signalflanken („Events“)
Es gibt keine statischen DatenFlanke liefert implizit den Zeitpunkt der Gültigkeit mit, unabhängig vom Delay (!)
Zur logischen Verknüpfung Event-Logic
A. Steininger / TU Wien20
Implementierungsvarianten
Two-Phase HandshakeFlanke auf REQ, danach Flanke auf ACK
optimale Nutzung der Bandbreite des KanalsHW-Implementierung oft aufwendig
Four-Phase HandshakeAkt. Flanke auf REQ, dann akt. Flanke auf ACK,danach durch passive Flanken zum Ausgangszust.
Verschwendung von BandbreiteHW-Implementierung viel einfacher
A. Steininger / TU Wien21
Event Logic
ODER-Verknüpfung für Events:„Flanke Y“ = „Flanke A“ ODER „Flanke B“
XOR-Gate
UND-Verknüpfung für Events:„Flanke Y“ = Flanke A“ UND „Flanke B“
Muller-C-Gate
A. Steininger / TU Wien22
Muller-C-Gate
RS
reset
set
a
b
y
IF a = = bTHEN y = aELSE hold y
Ca b
y
A. Steininger / TU Wien23
„FIFO-für Steuersignale“
C
C C
ROUT
AOUTRIN
Elastische Pipeline
A. Steininger / TU Wien24
Micropipeline mit Datenpfad
com
b
com
b
com
b
A
A. Steininger / TU Wien25
Bundled Data: Bilanz
Steuersignale kennzeichnen Gültigkeit der Daten, Übergabe mittels asynchronem HandshakeMit Event-Logik lässt sich eine „elastische“Pipeline für Steuersignale aufbauen
Probleme bleibenTiming/Routing der SteuersignaleFeststellung der Gültigkeit der Daten
A. Steininger / TU Wien26
Timing der Steuersignale
bisher:ein Steuersignal (REQ) beschreibt die Gültigkeit der gesamten Daten („bundled data“)dies impliziert die Forderung, dass REQ längere Laufzeit hat als die Daten (=> Delay-Elemente)ein solches Design ist nie Delay-insensitive
besser:jede Datenleitung beschreibt ihre Gültigkeit selbst
A. Steininger / TU Wien27
Gültigkeit der Daten
Feststellung der Gültigkeit / Konsistenzder Daten erfolgt mittels Delay/Timer
Mit einfachen Delay-Elementen erzielt man wie im synchronen System keine konzeptionell saubere Lösung(worst-case,…)Delay-Faults sind extrem kritisch.
A. Steininger / TU Wien28
Die Zeit als Maß aller Dinge ?
TreppenhauslichtAnwesenheit auf der Treppe
MikrowelleTemperatur/Garzustand der Speise
3-Minuten-EiKonsistenz des Dotters
AmpelAnzahl wartender Autos
IntervallschalterSicht durch die verregnete Scheibe
A. Steininger / TU Wien29
Konsistenz aus Zeitbedingung?
Taktperiode (synchrones Design)Delay (bounded Delay)
… sind ein indirektes und daher aus konzeptioneller Sicht problematisches/ungeeignetes Maß für die Gültigkeit und Konsistenz der Daten
Können wir Datenkonsistenz nicht direkt feststellen??
A
A. Steininger / TU Wien30
Es darf nur mit konsistenten, eingeschwungenen Zuständen operiert werden
? Wie unterscheidet man konsistente Zustände von Übergangszuständen oder Glitches ?
Zeitbedingungen für Konsistenzsynchrones Designasynchrone „bounded delay“ Verfahren (Timer)
Hinzufügen von „Meta-Information“asynchrone „delay-insensitive“ Verfahren (Codierung)
Grundproblem beim Design
A
A. Steininger / TU Wien31
Wie codiere ich „ungültig“ ?
Transition Signaling für die Daten selbstHI und LO nur als „Events“ darstellbarje eine Leitung für HI und LOEvent auf einer Leitung setzt entspr. Zustand
„Mehrwertige“ statische Logikim Pegelbereich nicht etabliertDarstellung eines Bits auf 2 digitalenLeitungen erlaubt 4 Zustände
A
A. Steininger / TU Wien32
Transition Signaling - BeispielA0
A1
B0
B1
Y = A or B
A=0 A=1
B=1B=0
Y0
Y1 Y=1 Y=1
A. Steininger / TU Wien33
Transition Signaling – GrenzenDelay insensitive circuits können nur unter folgenden Einschränkungen entworfen werdenBuffer, Inverter, Wires und C-Elements sind die einzig zulässigen single-output GatesAND, OR, XOR, etc. sind daher nicht zulässigMulti-Output Gates (intern bounded delay) günstig
Scott Hauck, „Asynchronous Design Methodologies – An Overview“Proceedings of the IEEE, vol 83, no 1, pp 69-93, Jan. 1995
A. Steininger / TU Wien34
Wie codiere ich „ungültig“ ?
Transition Signaling für die Daten selbstHI und LO nur als „Events“ darstellbarje eine Leitung für HI und LOEvent auf einer Leitung setzt entspr. Zustand
„Mehrwertige“ statische Logikim Pegelbereich nicht etabliertDarstellung eines Bits auf 2 digitalenLeitungen erlaubt 4 Zustände
A. Steininger / TU Wien35
Mehrwertige Logik
Die in der NULL-Convention Logic ver-wendete 3-wertige Logik umfasst dieZustände:
True (T) False (F) NULL (N)Das ermöglicht es, gemeinsam mit denNutzdaten auch Steuerinformation zuübermitteln.
„implizites Handshaking“
A
A. Steininger / TU Wien36
Logische Funktionen für NCL
NNNNNFFFNFTTNFTAND
NNNNNFTFNTTTNFTOR
NNTFFT
NOT
A. Steininger / TU Wien37
Completeness of Input–CriteriaDer Ausgang bleibt immer solange auf NULL, bisauch der letzte Eingang gültig (= ungleich NULL) ist.In einer mit NULL initialisierten Schaltung läuft eine „wavefront“ mit gültigen Werten von den Eingängen zu den AusgängenDie Synchronisation läuft selbständig und völlig unabhängig von Verzögerungen abDieses Prinzip lässt sich ohne weitere Maßnahmen vom einzelnen Gatter auf ein komplettes System erweitern.
A. Steininger / TU Wien38
Completen. of Input – Beispiel
&
>=1
XYZ
W A&
&
K
L
M
AMLKZYXWNNNN
N
NNN
11N0 01N
0NN0NN
NNNNNNNNN0
NN
NN
N NNN
0
N
1
NN
N1
N
0
N1N0
N1N011N0
1110
1110
1110
01N
010010
N
N
1
11
1
0
A
∆ = 4
∆ = 3
∆ = 6
∆ = 2
A. Steininger / TU Wien39
Bereitschaft für neue Daten...
...besteht erst, wenn auch der letzteInput wieder NULL ist.Der Output geht aber mit dem erstenNULL-Input wieder auf NULLEs sollen aber immer abwechselnd DATA-wellen und NULL-Wellen durch die Schaltung laufen Wie erkennen wir die „completeness of input“ für die NULL-Wellen ??
A. Steininger / TU Wien40
Completen of NULL – Problem
&
>=1
XYZ
W A&
&
K
L
M
AMLKZYXW1110
N
010
1111 NN0
NN0NN0
0N0010111N
N1
11
1 111
N
0
N
01
0N
1
N
111N
111N111N
1111
1111
1111
N00
100100
N
N
1
1
1
Waren die anderen Ein-gänge wirklich konstant oder nur langsamer ??
0
A
∆ = 4
∆ = 3
∆ = 6
∆ = 2
A. Steininger / TU Wien41
Rückkopplung vom Ausgang
„Feedback-Gate“mit Hysterese-Verhalten
AB
R
TF
TT
TTTTTTNFFFFFFFFNFFNFTNNNNNFTNFTNFTNFTNFTNFTNFTNFTN
FTNFTNFTNTFN
R
RABR
Timing!!
TF
FNN
N
FN
A
A. Steininger / TU Wien42
Completen. of NULL – Lösung
&
>=1
XYZ
W A&
&
K
L
M
AMLKZYXW1110
1
010
NN1N NN0
N10N10
010010111N
11
11
1 111
N
0
N
01
0N
1
N
1N1N
1N1NNN1N
NNNN
NNNN
NNNN
NN0
NNNNNN
1
1
N
NN
N
N
A
∆ = 4
∆ = 3
∆ = 6
∆ = 2
A. Steininger / TU Wien43
Datenkonsistenz in NCLDurch das Alternieren von NULL- und DATA-Wellen ist jede konsistente DATA-Welle durchzwei NULL Wellen ( = vorne und hinten)eingerahmt.
NULL
NULL
NULL
TRUE
TRUE
FALSE
TRUE
NULL
NULL
NULL
NULL
TRUE
FALSE
TRUE
FALSENULLt
Konsistent DATAKonsistent NULLA
A. Steininger / TU Wien44
Codierung des Alphabets
im Pegelbereich nicht etabliertDarstellung eines Bits auf 2 Leitungen:
grundsätzl. beliebig(1 aus n , 2-rail, etc.) kosteneffizient sind 2 SignalleitungenBeispiel: 2-rail-coding
verboten11FALSE01TRUE10NULL00BedeutungX1X0
Signal X
A. Steininger / TU Wien45
Bedingungen an die Codierung
Vertauschbarkeit der Reihenfolgebeim Übergang von einem gültigen Codewort auf das nächste darf kein Zwischenzustand ein gültiges Codewort darstellen
Ist noch eine Flanke ausständig ?
Garantiertes Auftreten eines EventsBeim Übergang von einem Codewort auf das nächste muss zumindest eine Flanke auftreten
Neues oder altes Codewort ?
A. Steininger / TU Wien46
Bedingungen an die Codierung
Vertauschbarkeit der Reihenfolgebeim Übergang von einem gültigen Codewort auf das nächste darf kein Zwischenzustand ein gültiges Codewort darstellenNCL: Nur 1 Bit Änderung von N auf T / F
Garantiertes Auftreten eines EventsBeim Übergang von einem Codewort auf das nächste muss zumindest eine Flanke auftretenNCL: Rückkehr zu NULL vorgeschrieben (!)
A. Steininger / TU Wien47
Gatter in NCL
Mem
E1.a
E1.b
E1
E2.a
E2.b
E2
Y.a
Y.b
Y
Mem
A. Steininger / TU Wien48
NULL Convention Logic: Bilanz
NCL ist eine elegante, durchgängige,delay-insensitive Design-Methode(Direkte) Completion detection ist möglichStrukturierung ist möglich durch RegisterHW-Aufwand: zwei Leitungen je BitEffizienz: Die NULL-Wellen halbieren denproduktiven DurchsatzPatentiert und industriell verwendet
A. Steininger / TU Wien49
Code Alternation Logic
Grundidee: Anstelle der unproduktiven NULL-Wellen produktive Daten in anderer Codierung („Phase“) übertragen:
H
L
H
h
l
l
h
L
L
H
H
l
l
h
hHt
konsistent Phase Φ0konsistent Phase Φ1
NULL
NULL
NULL
TRUE
TRUE
FALSE
TRUE
NULL
NULL
NULL
NULL
TRUE
FALSE
TRUE
FALSENULL
A
NCLCAL
A. Steininger / TU Wien50
Zustandscodierung in CAL
(1,0)(0,1)Φ1(1,1)(0,0)Φ0HILO
Phase
Zustand
Darstellung eines Signals auf 2 Leitungen (a,b) („two-rail coding“)
A. Steininger / TU Wien51
Bedingungen an die Codierung
Vertauschbarkeit der Reihenfolgebeim Übergang von einem gültigen Codewort auf das nächste darf kein Zwischenzustand ein gültiges Codewort darstellenBei jedem Übergang ändert sich genau ein Bit
Garantiertes Auftreten eines EventsBeim Übergang von einem Codewort auf das nächste muss zumindest eine Flanke auftretenBei jedem Übergang ändert sich genau ein Bit
A
A. Steininger / TU Wien52
Gatter in CAL
Mem
E1.a
E1.b
E1
E2.a
E2.b
E2
Y.a
Y.b
Y
Mem
A. Steininger / TU Wien53
Wahrheitstabelle CAL-AND
HL**HLL**L**hlh**lllHLhlY
E1
E2
L, H, l, h für E1, E2 und Y laut CAL Tabelle* … Halten des letzten gültigen Wertes an Y
A. Steininger / TU Wien54
Completion Detection in CALEin konsistentes Datenwort in CAL ist vonDatenworten in anderer Phase eingerahmt.
H
L
H
h
l
l
h
L
L
H
H
l
l
h
hH
A
A. Steininger / TU Wien55
Completion Detection in CALEin konsistentes Datenwort in CAL ist vonDatenworten in anderer Phase eingerahmt.Zur Feststellung der Konsistenz muss für jedesBit die Phase ermittelt werden. Dies kann beiCAL sehr einfach durch ein XOR erfolgen.
(1,0)(0,1)Φ1(1,1)(0,0)Φ0HILO
a = ba ≠ b
A. Steininger / TU Wien56
Completion Detection in CALEin konsistentes Datenwort in CAL ist vonDatenworten in anderer Phase eingerahmt.Zur Feststellung der Konsistenz muss für jedesBit die Phase ermittelt werden. Dies kann beiCAL sehr einfach durch ein XOR erfolgen.Bits mit gleicher Phase gehören zum gleichenDatenwortDiese Konsistenzprüfung ist direkt undkonzeptionell sauber.
A. Steininger / TU Wien57
Code Alternation Logic: Bilanz
CAL ist eine elegante, durchgängige,delay-insensitive Design-Methode(Direkte) Completion detection ist möglichStrukturierung ist möglich durch RegisterHW-Aufwand: zwei Leitungen je BitEffizienz: Im Vergleich zu NCL doppelter produktiver DurchsatzPatentiert
A
A. Steininger / TU Wien58
Zusammenfassung (1)
Asynchrones Design verwendet lokalenHandshake (Feedback) anstelle einesglobalen TaktesDie Bundled-Data Methode
verwendet Steuersignale (expliziter Handshake)ist sehr effizient, leitet die Konsistenz aus einer Zeitbedingung abist bestenfalls scalable delay insensitive
A. Steininger / TU Wien59
Zusammenfassung (2)
MicropipelinesSind eine effiziente Methode zur Strukturierung asynchroner Designsbieten eine elastische Pipeline für Steuersignalebieten per se keine Completion Detection
Transition Signaling für Datenist konzeptionell geeignet für delay insensitivebietet nur eingeschränkte Funktionalitätist extrem schwierig zu designen
A. Steininger / TU Wien60
Zusammenfassung (3)
Null Convention Logic (NCL)verwendet dreiwertige Logikbenötigt daher zwei Leitungen je Signalist konzeptionell elegantBeruht auf einem Alternieren von DATA-Wellen und NULL-Wellenist daher nur beschränkt effizient
A. Steininger / TU Wien61
Zusamenfassung (4)
Code Alternation Logic (CAL)verwendet je zwei unterschiedliche Codierungen für HI und LObenötigt daher 2 Leitungen je Signalberuht auf einem Alternieren der Phasenist geeignet für delay insensitiveist doppelt so effizient wie NCL
A. Steininger / TU Wien62
Die Methode Zukunft ?Asynchrones Design bietet große Vorteile, aber
keine Vereinfachungen wie im synchronen Falldie Design-Methoden sind weniger ausgereiftdie bestehenden Design-Tools sind ungeeignetdie bestehende Technologie ist schlecht geeignetes gibt wenig Erfahrung (Robustheit, Test)Ingenieure sind in synchronem Design ausgebildet
Evolution statt Revolution:
GALS-Architekturen (Globally Asynchronous / Locally Synchronous): Räumlich kleine synchrone Funktionsblöcke kommunizieren asynchron