Ruprecht-Karls-Universität Heidelberg
Fakultät für Physik und Astronomie
Max - Planck - Institut für Kernphysik
IHEP 98-02
HD-ASIC-39-0298
Datenkompression f
ur die Auslese des
ATLAS Level-1 Triggers
Diplomarb eit
von
Bernhard Niemann
0
0
0
0
1
1
1
1
00000
00000
11111
11111
000000111111
0
0
0
0
1
1
1
1
0
0
0
0
1
1
1
1
0
0
0
0
1
1
1
1
Schröderstraße 90
01
ASIC-Labor http://www.ihep.uni-heidelberg.de/Asic/
D-69120 Heidelberg
Fakult
at f
ur Physik und Astronomie
Ruprecht-Karls-Universit
at Heidelb erg
Diplomarb eit
im Studiengang Physik
vorgelegt von
Bernhard Niemann
aus Karlsruhe
Dezember 1997
Datenkompression f
ur die Auslese des
ATLAS Level-1 Triggers
Die Diplomarb eit wurde von Bernhard Niemann ausgef
uhrt am
Institut f
ur Ho chenergiephysik der Universit
at Heidelb erg
unter der Betreuung von
Herrn Prof. Dr. K. Meier
In dieser Arb eit werden M
oglichkeiten zur Datenkompression f
ur die Aus-
lese des ATLAS Level-1 Kalorimeter-Triggers untersucht. Die Ergebnisse
von Simulationen mit Human Co ding und Run-Length Co ding, sowie f
ur
zwei sp eziell f
ur die Nullunterdr
uckung von verrauschten Daten mit festen
Wortgrenzen entwickelten Algorithmen (Human-Inspired und Dierence
Co ding), werden vorgestellt. Die Parameter der verschiedenen Algorithmen
wurden dab ei an die zu erwartenden Daten angepat. Demnachk
onnen die
Daten um einen Faktor 2-3 komprimiert werden, wenn alle Daten von 0 GeV
bis 255 GeV, inklusive des Rauschuntergrundes von 0.5 GeV, mit 10 bit
Au
osung ausgelesen werden sollen.
Die getesteten Algorithmen wurden auf einem ASIC, dem Readout Merger
ASIC (RemASIC) implementiert. Die Parameter der Verfahren wurden ent-
sprechend den Ergebnissen der Simulation gew
ahlt. Im Human und Run-
Length Mo dus k
onnen sowohl 8 bit, als auch 10 bit Daten verarb eitet werden,
w
ahrend die anderen b eiden Mo di nur mit 10 bit Daten b etrieb en werden
k
onnen. F
ur das Run-Length Enco ding kann ein Energie-Cut gew
ahlt wer-
den, der zu einer drastischen Erh
ohung des Kompressionsfaktors f
uhrt. Die
komprimierten Daten werden in 32 bit Datenworte formatiert. Ein erster
Test des RemASIC wurde erfolgreich durchgef
uhrt.
Data Compression for the ATLAS Level-1 Calorimeter Trigger:
The feasibility of data compression for the readout of the ATLAS level-1
calorimeter trigger has b een investigated. Simulations are presented using
Human and run-length co ding as well as two compression schemes deve-
lop ed for zero suppression of noisy data with co des of xed size (Human-
inspired and dierence co ding). Parameters of these algorithms have b een
tuned to deliver b est results with exp ected data. Compression factors of
2-3 may b e obtained, if all data b etween 0 GeV and 255 GeV including the
noise background of 0.5 GeV are to b e read out with a resolution of 10 bit.
The tested algorithms have b een implemented on an ASIC, the Readout
Merger ASIC (RemASIC). Parameters were chosen according to the results
obtained from the simulation. The Human and run-length co ders are able
to pro cess 8 bit or 10 bit data, the other algorithms exp ect 10 bit data as
input. When compressing in run-length mo de an energy cut may b e applied,
which impressively increases compression factors. Compressed output data
are formatted in 32 bit words. A rst test of the RemASIC has b een carried
out successfully.
Inhaltsverzeichnis
Einleitung 1
1 Physikalischer Hintergrund 2
1.1 ATLAS und LHC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.1 Der LHC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.2 Aufbau des ATLAS Detektors . . . . . . . . . . . . . . . . . . . . . . 3
1.1.3 Trigger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Triggerauslese und Datenkompression . . . . . . . . . . . . . . . . . . . . . 7
1.2.1 Front-End . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2.2 Warum Datenkompression? . . . . . . . . . . . . . . . . . . . . . . . 10
2 Erzeugung von Testdaten 12
2.1 Mo dell der Datenpro duktion . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1.1 Energieverteilung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1.2 Komp onenten der Elektronik . . . . . . . . . . . . . . . . . . . . . . 15
2.2 Das Programm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3 Datenkompression 20
3.1 Eine kurze Einf
uhrung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2 Forderungen an die Verfahren . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3 Universelle Algorithmen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3.1 Human Co ding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3.2 Run-Length Enco ding . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.4 Sp ezielle Algorithmen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.4.1 Human-Inspired Co ding . . . . . . . . . . . . . . . . . . . . . . . . 26
3.4.2 Dierence Co ding . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.5 Software zur Datenkompression . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.5.1 Ein- und Ausgab e . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.5.2 Erzeugung von Co deb
aumen . . . . . . . . . . . . . . . . . . . . . . 31
3.5.3 Abschneiden von Co deb
aumen . . . . . . . . . . . . . . . . . . . . . 32
4 Ergebnisse der Simulationen 34
4.1 Entropie der Daten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.1.1 Die Energieverteilung . . . . . . . . . . . . . . . . . . . . . . . . . . 34
i
ii
INHALTSVERZEICHNIS
4.1.2 Entropie und Pedestal . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.1.3 Entropie und Energieau
osung . . . . . . . . . . . . . . . . . . . . . 38
4.1.4 Anzahl der Samples . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.2 Kompressionsfaktoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.2.1 Human Co ding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2.2 Run-Length Enco ding . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.2.3 Human-Inspired und Dierence Co ding . . . . . . . . . . . . . . . . 43
4.2.4 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5 Die Kompressionseinheit 48
5.1 Der RemASIC - ein
Ub erblick . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.1.1 Die Idee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.1.2 Das Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.1.3 Der Chip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.2 Architektur der Kompressionseinheit . . . . . . . . . . . . . . . . . . . . . . 55
5.2.1 Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.2.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.3 Formatierung der Daten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.4 Die Kompressionsmo dule . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.4.1 Human Co ding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.4.2 Run-Length Enco ding . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.4.3 Human-Inspired und Dierence Co ding . . . . . . . . . . . . . . . . 64
5.5 Betrieb der Kompressionseinheit . . . . . . . . . . . . . . . . . . . . . . . . 66
6 Erster Test des RemASIC 70
6.1 Testaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
6.2 Teststrategie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.3 Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Zusammenfassung 77
A Grundlagen der Informationstheorie 79
A.1 Entropie und Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
A.2 Co dierungstheorie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
A.2.1 Blo ckco des . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
A.2.2 Co des mit variabler L
ange . . . . . . . . . . . . . . . . . . . . . . . . 82
B Op erations- und Testmo di der Kompressionseinheit 84
B.1 Konguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
B.2 Headerwort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
B.3 Beschreib en der Sp eicher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
B.4 Auslese der Sp eicher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
B.5 SpyBus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
C Die Shapingfunktion 88
INHALTSVERZEICHNIS
iii
Literaturverzeichnis 89
Einleitung
Mo derne Ho chenergiephysik-Exp erimente pro duzieren Daten in der Gr
oenordnung von
einigen 10-100 GByte/s. Um solche Datenmengen f
ur eine sp
atere Analyse zu sp eichern
werden immer aufwendigere Daten
ub ertragungssysteme ben
otigt, die in der Lage sind
solche Datenmengen vom Detektor bis zu den Massensp eichern zu b ef
ordern.
Die Entwicklung von Bussystemen mit der entsprechenden Bandbreite ist die eine
M
oglichkeit, eine Reduktion des anfallenden Datenvolumens ohne Informationsverlust die
andere. In dieser Arb eit wird die zweite Metho de, die verlustfreie Datenkompression,
n
aher untersucht. Die mathematisch-theoretische Grundlage der Datenkompression bildet
die Informationstheorie. Sie wurde vor etwa 50 Jahren, mit der Verkn
upfung von Entro-
pie und Kommunikation durch Claude Shannon, Gegenstand der Forschung. Eine kurze
Einf
uhrung der wichtigsten Begrie ndet sich in Anhang A.
Diese Arb eit b esch
aftigt sichinzwei Teilen mit der Datenkompression. Im ersten Teil
(Kapitel 3 und 4) werden verschiedene Verfahren und die Ergebnisse ihrer Simulation mit
Testdaten vorgestellt. Im zweiten Teil (Kapitel 5 und 6) wird die Hardwareimplementa-
tion einer Kompressionseinheit auf einem ASIC (Application Sp ecic Integrated Circuit)
und deren Test b eschrieb en. Die ersten b eiden Kapitel b esch
aftigen sich mit den Ge-
geb enheiten des ATLAS Exp erimentes und dem daraus resultierenden Aussehen der zu
komprimierenden Daten.
1
Kapitel 1
Physikalischer Hintergrund
Im Rahmen der Diplomarb eit wurde eine Datenkompressionseinheit f
ur
die Auslese des ATLAS
1
Level-1 Triggers entwickelt und auf einem ASIC
2
,
dem
Readout Merger ASIC
(RemASIC) implementiert. Dieses Kapitel gibt
zun
achst einen kurzen
Ub erblick
ub er das ATLAS Exp eriment am LHC
3
,um
dann auf die von Physik und Technik gegeb enen Randb edingungen f
ur die
Datenkompression einzugehen.
1.1 ATLAS und LHC
Die Ho chenergiephysik b esch
aftigt sich mit der Suche nach den fundamentalen Bausteinen
der Materie. Hierzu ist es n
otig, immer kleinere Strukturen au
osen zu k
onnen. Dies ge-
schieht mit Hilfe von Streuexp erimenten, die wegen der Heisenb ergschen Unsch
arferelation
bei st
andig wachsenden Energien durchgef
uhrt werden m
ussen. Je kleiner n
amlich die
Strukturen sind, die man au
osen m
ochte, desto gr
oer mu der Impuls
ub ertrag b ei der
Streuung werden. F
ur eine Darstellung der Ho chenergiephysik siehe zum Beispiel [1].
Zur Durchf
uhrung der Streuexp erimente werden Teilchenb eschleuniger mit m
oglichst
hohen Strahlenergien, und Detektoren ben
otigt, die in der Lage sind, die interessanten
Streuereignisse zu registrieren. F
ur das Jahr 2005 wird am europ
aischen Kernforschungs-
zentrum CERN in Genf die Inb etriebnahme eines neuen Beschleunigers, des LHC, geplant.
Mit ihm erhot man sich unter anderem Klarheit
ub er folgende Asp ekte der mo dernen
Teilchenphysik, die mit den bisher existierenden Exp erimenten nicht gekl
art werden konn-
ten:
Existenz des Higgs Bosons
Suche nach sup ersymmetrischen (SUSY) Teilchen
Substruktur der Quarks
1
ATLAS:
A Toroidal LHC Apparatus
2
ASIC:
Application Specic IntegratedCircuit
3
LHC:
Large Hadron Col lider
2
1.1. ATLAS UND LHC
3
Um die bei der Streuung erzeugten Sekund
arteilchen b eobachten zu k
onnen, gibt es am
LHC insgesamt vier Detektoren, einer davon ist ATLAS.
1.1.1 Der LHC
Der LHC ist ein Collider, das heit es werden zwei gegenl
aug b eschleunigte Teilchenstrah-
len an b estimmten Punkten, an denen ein Detektor steht, zur Wechselwirkung gebracht.
Am LHC werden zwei Protonenstrahlen in getrennten R
ohren auf jeweils 7 TeV b eschleu-
nigt, womit im pp-System b ei der Wechselwirkung eine Energie von
p
s
=2
7TeV = 14 TeV (1.1)
zur Verf
ugung steht. Beide Strahlen b estehen aus Teilchenpaketen, den
Bunches
. Alle
25 ns treen in den Wechselwirkungspunkten zwei Bunches aufeinander und erzeugen
Sekund
arteilchen. Dies b ezeichnet man als
Bunch-Crossing
.
1.1.2 Aufbau des ATLAS Detektors
ATLAS ist ein Universaldetektor, mit dem m
oglichst viele verschiedene Pro duktions- und
Zerfallskan
ale b eobachtet werden sollen. Hierzu werden in den einzelnen Detektorkom-
p onenten, die im folgenden kurz b eschrieb en werden, Teilchenbahn, Impuls und Energie
gemessen. In Abbildung 1.1 ist der prinzipielle Aufbau des Detektors zu sehen. Das
Streup otential ist invariant gegen
ub er Drehungen um die Strahlachse und Spiegelungen
am Wechselwirkungspunkt. Deshalb ist der Detektor zylindersymmetrisch um den Wech-
selwirkungspunkt aufgebaut. Zur Beschreibung des Detektors verwendet man ein Ko or-
dinatensystem mit z-Achse in Strahlrichtung. Meistens gibt man den Azimuthwinkel
und anstelle des Polarwinkels
die Pseudorapidit
at
an. Dierenzen in dieser sind f
ur
schnelle Teilchen mit
:=
v
c
!
1 lorentzinvariant. Sie ist deniert durch
=
,
ln tan
2
(1.2)
Innerer Detektor
Der innere Detektor, direkt um den Wechselwirkungspunkt, b esteht aus Siliziumpixelde-
tektoren, Silizumstreifenz
ahlern und Drahtkammern [2]. Sie dienen alle dem Zweck die
Bahnen geladener Teilchen unmittelbar nach der Reaktion m
oglichst genau zu rekonstruie-
ren. Da sich der innere Detektor in einem Magnetfeld parallel zur Strahlachse (solenoidales
Feld) b endet, l
at sich aus der Bahnkr
ummung auch der Teilchenimpuls rekonstruieren.
Kalorimeter
Die Bestimmung der Teilchenenergie erfolgt in den um den inneren Detektor gelegenen
Kalorimetern. Im inneren elektromagnetischen Teil werden die Energien von Elektronen
und Photonen gemessen. Stark wechselwirkende Teilchen (Hadronen) dep onieren hier nur
einen kleinen Teil ihrer Energie. Der Rest wird im
aueren hadronischen Teil nachge-
wiesen. Das Prinzip der Energiemessung ist in b eiden F
allen dasselb e. Ho chenergetische
4
KAPITEL 1. PHYSIKALISCHER HINTERGRUND
ATLAS
S.C. Air Core
Toroids
S.C. Solenoid
Hadron
Calorimeters Calorimeters
Forward
EM Calorimeters
Muon Shieldings
Inner Detector Muon Detectors
Abbildung 1.1: Der ATLAS Detektor [3]
Material
X
0
[
g =cm
2
]
had
[
g =cm
2
]
Ar 18
:
9 119
:
7
Fe 13
:
8 131
:
9
Pb 6
:
3 193
:
7
Tab elle 1.1: Eigenschaften einiger Absorb ermaterialien (nach [4])
Prim
arteilchen erzeugen in einem Absorb ermaterial eine Kaskade von Sekund
arteilchen.
Die Energie der Teilchen in der Kaskade nimmt mit wachsender Eindringtiefe ab bis zum
Stillstand. In einem geeigneten sensitiven Material werden die Sekund
arteilchen nach-
gewiesen. Man erh
alt dann ein elektrisches Signal, das prop ortional zur Energie des
Prim
arteilchens ist.
Im elektromagnetischen Kalorimeter bildet sich
ub er Bremsstrahlung und Paarbildung
die Kaskade von Sekund
arteilchen aus. Die Energie der Teilchen in der Kaskade wird
durch Ionisation im sensitiven Material gemessen. Im hadronischen Teil werden durch
inelastische St
oe mit den Atomkernen des Absorb ermaterials Hadronen gebildet. F
ur die
Absorb er wird man Materialien verwenden, die f
ur die jeweiligen Prozesse einen b esonders
guten Wirkungsquerschnitt b esitzen. F
ur den elektromagnetischen Teil ist dies Blei, f
ur
den hadronischen Eisen, Kupfer o der Wolfram. Da die hadronische Absorptionsl
ange um
einiges gr
oer ist, als die Strahlungsl
ange f
ur elektromagnetische Prozesse (siehe Tab elle
1.1), nehmen hadronische Kalorimeter wesentlich mehr Platz ein als elektromagnetische.
Als sensitive Materialien kommen
ussiges Argon und Plastikszintillatoren zum Ein-
satz. Das Edelgas wird im inneren und in Strahlrichtung gelegenen Bereichverwendet, da
es weniger anf
allig gegen
ub er radioaktiver Strahlung ist. Durch eine r
aumliche Segmen-
tierung der Auslese kann auch der Punkt der Energiedep osition b estimmtwerden. Um im
elektromagnetischen Kalorimeter einzelne Elektronen von Jets
4
unterscheiden zu k
onnen
4
B
undel von Teilchenstrahlen
1.1. ATLAS UND LHC
5
-Bereich Granularit
at (
) Zahl d. Kan
ale
elektromagnetisch 0
::
3
:
2
0
:
05 214000
hadronisch 0
::
4
:
9 0
:
1
::
0
:
2 20100
Tab elle 1.2: Wichtige Kenngr
oen des Kalorimeters (nach[2])
ist dieses feiner segmentiert als das hadronische. Eine
Ub ersicht ist in Tab elle 1.2 gegeb en.
Die Myonkammern
An das Kalorimeter schlieen sich die Myonkammern an. Es sind Driftkammern unter-
schiedlicher Bauart, in denen die Myonen gekr
ummte Spuren hinterlassen, da sie von einem
zylindersymmetrischen (toroidalen) Feld mit Symmetrieachse in Strahlrichtung abgelenkt
werden. Erzeugt wird das Feld von supraleitenden Magneten. Wie schon im inneren
Detektor, wird der Impuls aus der Bahnkr
ummung rekonstruiert.
Myonen werden zweckm
aigerweise weit auen detektiert, da sie das Kalorimeter na-
hezu ungehindert durchdringen, w
ahrend die meisten anderen Teilchen b ereits im Kalo-
rimeter zum Stillstand kommen. Ein Teilchen, das in einer der Myonkammern eine Spur
hinterl
at, ist also mit groer Sicherheit ein Myon.
1.1.3 Trigger
Wollte man alle 25 ns den gesamten Detektor auslesen, so erhielte man eine Datenrate
von etwa 50 TByte/s [2]. Es ist technisch unm
oglich, solch eine Datenmenge zu sp ei-
chern und hinterher sinnvoll zu verarb eiten. Da zudem die interessanten Streuereignisse
extrem selten sind, ist es auch sinnlos, Daten von allen Bunch-Crossings auszulesen. Auf-
gab e des Triggers ist es, in Echtzeit die interessanten Ereignisse zu identizieren, und
nur diese werden dann f
ur die sp
atere
Oine-Analyse
gesp eichert. Die Selektion der Er-
eignisse, und damit die Reduktion der Ereignisrate, erfolgt in drei Schritten (Level 1-3).
Eine Darstellung des Datenusses durch den Trigger ist in Abbildung 1.2 zu sehen. Die
kompletten Datens
atze von der Auslese eines Bunch-Crossings werden zun
achst in einer
Pip eline gesp eichert. Der Level-1 Trigger hat nun solange Zeit f
ur eine Entscheidung, wie
der Datensatz durch die Pip eline wandert. Diese Zeit b ezeichnet man als
Latency
. Wurde
ein Datensatz akzeptiert, so wird er in den
Readout Buer
kopiert und wandert im Falle
einer p ositiven Entscheidung des Level-2 Triggers in den
Event Builder
. Von hier aus wird
er dann, wenn er vom Level-3 Trigger akzeptiert wurde, f
ur die sp
atere Oine-Analyse
gesp eichert.
Level-1 Trigger
Der Level-1 Trigger reduziert die Ereignisrate von 40 MHz auf maximal 100 kHz. Hierf
ur
werden Daten aus dem Kalorimeter und dem Myonsystem getrenntverarb eitet. Der zen-
trale Triggerprozessor f
allt dann aufgrund dieser Daten die Entscheidung, ob ein Ereignis
interessant ist o der nicht (siehe Abbildung 1.3). Akzeptiert die erste Triggerstufe ein Er-
eignis, so pro duziert sie das Startsignal f
ur die zweite Stufe (
Level-1 Accept
). Auerdem
6
KAPITEL 1. PHYSIKALISCHER HINTERGRUND
Level1-
Trigger
Trigger
Level2-
Level3-
Trigger
Auslesedaten des Triggers
<100 Hz
Pipeline-
ATLAS Detektor
Event Builder
<1 kHz
MuonTrack Calo
Speicher
Komplette Events
Massenspeicher
40 MHz
Readout Buffer Regions of Interest
RoI-Koordinaten
Summierte Kanäle
Level2Accept
Level1Accept
< 2ms
Level3Accept
< 2us
<100 kHz
Pipeline-Speicher
Abbildung 1.2: Datenpfad im Trigger und b ei der Auslese (nach[5])
werden die Orte interessanter Energiedep ositionen an den Level-2 Trigger
ub ergeb en. Man
b ezeichnet sie als
Regions of Interest
(RoI).
Der Level-1 Trigger hat eine Latency von maximal 2
s und mu die Ereignisse mit der
vollen Bunch-Crossing-Rate von 40 MHz verarb eiten. Daher verarb eitet er die Kalorime-
terdaten nichtinvoller r
aumlicher Au
osung, sondern er erh
alt sowohl vom elektromagne-
tischen als auchvom hadronischen Kalorimeter 4096 Kan
ale. Sie entstehen durch analoge
Summation der Kalorimetersignale in einem Bereich von 0
:
1
0
:
1 in der
-
-Eb ene. Ein
solcher Kanal wird als
Trigger Tower
b ezeichnet.
Seine Entscheidungen trit der Level-1 Trigger, indem er nach b estimmten physikalisch
interessanten Ob jekten sucht und
ub erpr
uft, ob ihre Energie vorher denierte Schwellen
ub erschreitet. Liegt ihre Energie unterhalb dieser Schwellen, werden die Ob jekte als un-
interessant angesehen. Der Myon-Trigger ist auf die Suche nach Myonen sp ezialisiert,
w
ahrend im Kalorimeter-Trigger nach folgenden Ob jekten gesucht wird:
Elektronen und Photonen
Jets
transversale Energie E
T
fehlende transversale Energie E
miss
T
.
Unter der
transversalen Energie
versteht man
E
T
=
E
sin
:
(1.3)
1.2. TRIGGERAUSLESE UND DATENKOMPRESSION
7
Front End
FADC LUT BCID Auslese
Analoge Summe
Trigger Logik
Photonen Jets versale Energie
Elektronen/
Level1Accept
Fehlende trans-
AusleseRoI-Builder
Zentraler Trigger
Prozessor
Myon-System
Kalorimeter-Signale
RoI-Koordinaten
Level1Accept
Abbildung 1.3: Der Level-1 Trigger (nach[6])
Die fehlende transversale Energie b ezeichnet die Vektorsumme der transversalen Teilchen-
impulse und deutet auf unidentizierte Teilchen, wie Neutrinos, hin.
Der Level-1 Trigger mu eine groe Menge von Daten m
oglichst schnell verarb eiten
und dab ei m
oglichst kompakt bleib en. Deswegen wird dieser Teil des Triggers mit ASICs
aufgebaut. Da diese Chips sp eziell auf eine b estimmte Aufgab e zugeschnitten sind, lassen
sich hohe Verarb eitungsgeschwindigkeiten erreichen.
Level-2 und Level-3 Trigger
In den b eiden nachfolgenden Triggerstufen erfolgt eine weitere Reduktion der Ereignisrate
auf weniger als 100 Hz. Beide Triggerstufen verarb eiten die Kalorimeterdaten in vol-
ler Granularit
at. Der Level-2 Trigger liest allerdings nur die durch die RoI-Ko ordinaten
vorgegeb enen Bereiche aus, w
ahrend der Level-3 Trigger den gesamten Datensatz b ear-
b eitet. Am Ende m
ussen dann nur no ch 10-100 MByte/s f
ur die sp
atere Oine-Analyse
gesp eichert werden.
Die Triggerstufen zwei und drei werden mit kommerziell erh
altlichen Komp onenten
und parallel arb eitenden Prozessoren realisiert. Hierdurch wird die n
otige Flexibilit
at b ei
der Wahl der Triggeralgorithmen erreicht.
1.2 Triggerauslese und Datenkompression
Der Kalorimeter-Trigger b enutzt f
ur seine Entscheidung nicht die volle Granularit
at, son-
dern etwa 8000 Trigger Tower, die b ereits auf dem Detektor gebildet und anschlieend zum
Triggersystem
ub ertragen werden. Die Trigger Tower nden ausschlielichimLevel-1 Trig-
ger Verwendung. Es ist daher notwendig, eine M
oglichkeit zu schaen, den kompletten
Level-1 Trigger auszulesen. Nur so lassen sich die korrekte Funktion der Summation und
Ub ertragung der Trigger Tower, sowie die Entscheidungen der Triggerlogik
ub erpr
ufen.
8
KAPITEL 1. PHYSIKALISCHER HINTERGRUND
Trigger Logik
Readout Buffer
8/10bit
FADC
8/10bit
FeAsic
FeAsic
8/10bit
FADC
8/10bit
FADC
8/10bit
FeAsicFeAsicFeAsic
FeAsicFeAsicFeAsic
FADCFADC
8/10bit
FADC
8/10bit
FADC
8/10bit
FADC
8/10bit
FADC
8/10bit
FeAsic
FeAsic
8/10bit
FADC
8/10bit
FADC
8/10bit
FeAsicFeAsicFeAsic
FeAsicFeAsicFeAsic
FADCFADC
8/10bit
FADC
8/10bit
FADC
8/10bit
FADC
8/10bit
FADC
8/10bit
FeAsic
FeAsic
8/10bit
FADC
8/10bit
FADC
8/10bit
FeAsicFeAsicFeAsic
FeAsicFeAsicFeAsic
FADCFADC
8/10bit
FADC
8/10bit
FADC
8/10bit
FADC
8/10bit
FADC
8/10bit
FeAsic
FeAsic
8/10bit
FADC
8/10bit
FADC
8/10bit
FeAsic FeAsicFeAsic
FeAsic FeAsicFeAsic
FADCFADC
8/10bit
FADC
8/10bit
FADC
8/10bit
FADC
8/10bit
FADC
8/10bit
FeAsic
FeAsic
8/10bit FADC
8/10bit
FADC
8/10bit
FeAsicFeAsic
FeAsicFeAsic
FeAsic
FeAsic
FeAsicFeAsic
FeAsicFeAsic
FeAsic
FeAsic
FeAsicFeAsicFeAsic
FeAsicFeAsicFeAsic
FADCFADC
8/10bit
FADC
8/10bit
R
FADC
8/10bit
FADC
FADC
8/10bit
FADC
8/10bit
FADCFADC
8/10bit
FADC
8/10bit
FADC
8/10bit
Bus
FADC
8/10bit
FADC
8/10bit
8/10bit FADC
8/10bit
FADC
8/10bit
FeAsic
FeAsic
FeAsic
FADCFADC
8/10bit
FADC
8/10bit
FADC
8/10bit
FADC
8/10bit
FADC
8/10bit
FeAsic
FeAsic FeAsic FeAsic FeAsic
FADC
10 bit FADC
10 bit FADC
10 bit FADC
10 bit
FeAsic FeAsic FeAsic FeAsic
FADC
10 bit
FADC
10 bit FADC
10 bit FADC
10 bit
2 der 4 FeASIC Anschlüsse sind belegt
8/10bit
emAsic
PipelineBus System
Kanäle vom Kalorimeter
Kanäle vom Kalorimeter
RemAsic
RemAsic
RemAsic
RemAsicRemAsic
RemAsic
RemAsic
S-Link
Knoten Master
Abbildung 1.4: Auslese des Front-Ends mit Pip elineBus
1.2.1 Front-End
In Abbildung 1.3 ist der Aufbau des Level-1 Triggers zu sehen. Vor der eigentlichen
Triggerlogik, die in Abschnitt 1.1.3 b eschrieb en wurde, b endet sich das Front-End, auf
dem die Auslese der rohen Triggerdaten realisiert ist. Die Aufgab en des Front-End sind
im einzelnen (siehe [7 ]):
Digitalisieren der analogen Kalorimeterpulse mit 10 bit
Energiekalibration
Durchf
uhrung des
Bunch-Crossing Identication
(BCID)
Auslese der rohen Triggerdaten
Serielle
Ub ertragung der Daten zur Triggerlogik
Bereitstellen einer Datenquelle f
ur Testzwecke
Zwischensp eicherung der Daten bis zum Level-1 Accept (Pip eline)
Durch das Front-End gibt es zwei Datenpfade, einen schnellen f
ur die
Ub ertragung der
Kalorimeterdaten an die eigentliche Triggerlogik und einen langsamen f
ur die Auslese des
Front-Ends (siehe Abbildung 1.4). Auf dem Detektor erfolgt die analoge Summation der
Signale aus dem Kalorimeter zu den Trigger Towern. Auerdem wird von einem Pulsformer
(
Shaper
) ein bip olares Signal erzeugt, das sich
ub er mehrere Bunch-Crossings erstreckt.
Die Pulsh
ohe im Maximum ist prop ortional zur dep onierten Energie.
1.2. TRIGGERAUSLESE UND DATENKOMPRESSION
9
Digitalisierung
Die summierten Analogsignale aus den Trigger Towern werden von einem FADC (
Flash
Analog Digital Converter
) digitalisiert. In der bisher existierenden Prototyp Version des
Front-Ends erfolgt die Digitalisierung mit 8 bit, im nalen System kommen 10 bit FADCs
zum Einsatz.
Ub er einen DAC(
Digital Analog Converter
)kann auerdem f
ur jeden Kanal
ein konstanter Oset (
Pedestal
) eingestellt werden. Er dient dazu, die Analogsignale in den
Arb eitsb ereich des FADCs zu bringen und die Nullinie aller Kan
ale m
oglichst anzugleichen.
Der dynamische Bereich des FADC b etr
agt sowohl in der derzeitigen Version mit 8 bit
als auch im nalen System mit 10 bit 256 GeV. Ein LSB
5
entspricht also ungef
ahr 1 GeV,
b eziehungsweise 0.25 GeV. Im weiteren wird der Einfachheit halb er von einem dynami-
schen Bereichvon exakt 256 GeV ausgegangen.
Front-End ASIC
Der Front-End ASIC (FeASIC) ist verantwortlich f
ur Energiekalibration, BCID und die
Auslese der Daten, f
ur welche die Triggerlogik ein Level-1 Accept gibt. Die Energiekalibra-
tion erfolgt
ub er eine Lo ok-Up Table (LUT). Die digitalisierten Energiewerte werden als
Adresse eines Sp eicherbausteins b enutzt, der daraufhin einen an dieser Adresse gesp eicher-
ten Wert, die kalibrierte Energie, abgibt. Da jede Energiedep osition im Kalorimeter einen
Puls erzeugt, der sich
ub er mehrere Bunch-Crossings erstreckt, mu jedem Puls eindeutig
ein Bunch-Crossing zugeordnet werden, in dem das entsprechende Teilchen erzeugt wurde.
Dies geschieht
ub er die BCID Logik, die das Pulsmaximum ndet. Um unerw
unschte zeit-
liche Verschiebungen des Pulsmaximums zu detektieren, ist es sinnvoll, von jedem Puls
nicht nur das Maximum sondern auch die Werte f
ur einige Bunch-Crossings davor und
danach auszulesen. Die Zahl der ausgelesenen Werte wird als Bunch-Crossings pro Event
b ezeichnet. Die Auslese der Daten kann nach jedem Bearb eitungsschritt erfolgen, also vor
LUT und BCID, nach LUT ab er vor BCID o der nach LUT und BCID.
Der am Heidelb erger ASIC-Lab or entwickelte Prototyp b esitzt eine LUT mit 8 bit
Adresse und 10 bit Datenausgang und erm
oglicht eine Auslese von ein, vier o der acht
Bunch-Crossings pro Event [8 ]. Der Nachfolgechip wird eine LUT mit 10 bit Adressen
und 8 bit Datenausgang b esitzen und auch die Auslese von f
unf Bunch-Crossings pro
Event unterst
utzen [9]. Die Zahl F
unf wird favorisiert, da man so zwei Werte vor und
zwei nach dem Maximum erh
alt, was eine optimale Kontrolle erm
oglicht.
Schneller Trigger-Datenpfad
Die im FeASIC vorverarb eiteten Daten werden von einem sp eziellen Baustein, dem
HP
Gigabit-Link
(HP G-Link) [10 ], serialisiert und mit einer Geschwindigkeit von 800 Mbit/s
an die Triggerlogik
ub ertragen. Dies ist der f
ur den Betrieb von ATLAS wichtige Daten-
pfad.
Ub er ihn werden die Daten
ub ertragen, aufgrund derer der Level-1 Trigger seine
Entscheidung f
allt. Da in diesem Pfad keine Datenkompression stattndet, wird nicht
mehr weiter auf ihn eingegangen. F
ur eine genauere Darstellung siehe [6].
5
LSB: Least Signicant B it: Niederwertigstes bit einer Bin
arzahl. Im Gegensatz dazu MSB: Most
S
ignicantBit: H
ochstwertiges bit einer Bin
arzahl.
10
KAPITEL 1. PHYSIKALISCHER HINTERGRUND
Langsamer Auslese-Datenpfad
Die Auslese des Kalorimeter-Triggers erfolgt
ub er den langsamen Datenpfad. Der FeASIC
verf
ugt
ub er eine serielle Schnittstelle,
ub er die nach erfolgtem Level-1 Accept verschie-
dene Daten aus der Pip eline ausgelesen werden k
onnen, die f
ur die Kontrolle des Triggers
wichtig sind. Im nalen System sollen die Daten von jeweils 64 Kan
alen auf einem
Rea-
dout Merger ASIC
(RemASIC) gesammelt, sortiert, komprimiert und
ub er ein Bussystem,
den Pip elineBus, zum Readout Buer
ub ertragen werden. Die derzeit vorhandene Proto-
typversion verf
ugt
ub er vier Anschl
usse (
Ports
) f
ur FeASICs. An jedem der Anschl
usse
k
onnen bis zu vier FeASICs in Reihe geschaltet (
Daisy Chain
) b etrieb en werden, so da
eine Auslese von 16 Kan
alen m
oglich ist. Vor der Kompression werden die Daten so sor-
tiert, da f
ur jeden Kanal die zu einem Event ausgelesenen Bunch-Crossings in einem
Blo ck stehen. F
ur eine genauere Beschreibung des RemASIC siehe Abschnitt 5.1.
1.2.2 Warum Datenkompression?
Im vorangegangenen Abschnitt wurde gezeigt, da die Auslese der rohen Triggerdaten f
ur
Test- und Kontrollzwecke unentb ehrlich ist, und es wurde ein Konzept f
ur diese Auslese,
die auf dem Front-End realisiert ist, vorgestellt. F
ur den Transp ort der Daten vom Front-
End zum Readout Buer wurde das Pip elineBus-Konzept entwickelt.
Die Datenein- und Ausg
ange von jeweils 8 RemASICs, einem Busmaster und einem
S-Link
6
Knoten werden zu einem Ring geschlossen (siehe Abbildung 1.4) . Sowohl Daten
als auch Befehle (
Tokens
) propagieren auf dem Bus von einem Knoten zum n
achsten. Die
RemASICs geb en ihre Daten auf den Bus, wenn der Busmaster ihnen dies durch ein Token
erlaubt. Das Ende eines Datensatzes markiert der schreib ende RemASIC eb enfalls
ub er
ein Token. Der S-Link Knoten sorgt daf
ur, da die Daten wieder vom Bus genommen
werden und
ub er S-Link an den Readout Buer
ub ertragen werden.
Am LHC ndet alle 25 ns ein Bunch-Crossing statt, was einer Rate von 40 MHz ent-
spricht. Um Synchronisation zwischen Datenpro duktion und Verarb eitung zu gew
ahrleis-
ten, wird die Ausleseelektronik, und damit auch RemASIC und Pip elineBus mit demselb en
Takt b etrieb en. Da ein Pip elineBus-Wort 32 bit breit ist, ergibt sich eine maximale Band-
breite von 152 MByte/s. In jedem Bus Ring b enden sich 8 RemASICs, die im nalen
System jeweils 64 Kan
ale auslesen. F
ur jedes Event sollen bis zu f
unf Bunch-Crossings
ausgelesen werden, um zus
atzliche Kontrollm
oglichkeiten zu b esitzen. Bei 100 kHz Trig-
gerrate mu im Schnitt alle 10
s ein Event ausgelesen werden. Damit ergibt sich eine
Datenrate von 250-300 MByte/s, je nachdem ob 8 bit o der 10 bit Daten ausgelesen werden
sollen.
Die Bandbreite des Pip elineBusses reicht also bei 32 bit Datenleitungen ganz oen-
sichtlich nicht aus, um den kompletten Trigger b ei maximaler Triggerrate und maximaler
Anzahl der Bunch-Crossings auszulesen. Es wurde daher die M
oglichkeit diskutiert, nur je-
des f
unfte o der zehnte Bunch-Crossing auszulesen. Sie wurde jedo ch wieder verworfen, da
hierb ei f
ur seltene Ereignisse wichtige Kontrollinformationen verloren gehen k
onnen. Eine
andere M
oglichkeit w
are ein leistungsf
ahigeres Bussystem zu konzipieren. Es ist allerdings
6
Simple Link (siehe [11 ]).
1.2. TRIGGERAUSLESE UND DATENKOMPRESSION
11
technisch nicht unproblematisch Daten mit dieser Bandbreite
ub er gr
oere Entfernungen
zu transp ortieren.
Da die Daten nicht sofort weiterverarb eitet, sondern f
ur eine sp
atere Oine-Analyse
gesp eichert werden, bietet sich die M
oglichkeit der Datenkompression an. Sie bietet zwei
Vorteile gegen
ub er einer Auslese der unkomprimierten Daten. Erstens wird die b en
otigte
Bandbreite des Auslesebusses verringert und zweitens b en
otigt man weniger Sp eicherplatz
auf dem Massensp eicher, der die Daten aufnimmt. Die Bandbreite des Pip elineBusses wird
reduziert durchTokens, die auch
ub er den Bus laufen. Man b en
otigt daher Kompression
um mehr als den Faktor 250
=
152 =1
:
6 bis 300
=
152 =2, der durch die maximale Netto-
Bandbreite des Pip elineBusses gegeb en ist. Angestrebt wurde eine Reduktion der Daten
um etwa einen Faktor 2-3. Die Datenkompression wurde realisiert auf dem RemASIC,
zwischen FeASIC Interface und Pip elineBus Interface.
Kapitel 2
Erzeugung von Testdaten
Vor der Implementation der Kompressionseinheit auf dem RemASIC (siehe Kapitel 5),
wurden verschiedene Kompressionsalgorithmen mit Testdaten auf dem Rechner simuliert
und ihre Leistungsf
ahigkeit b estimmt. In diesem Kapitel wird die Erzeugung der Testda-
ten b eschrieb en. Hierzu wurde das Programm
DATASIM
in C++
1
entwickelt, das den
Einu der wichtigsten Komp onenten zwischen Detektor und Kompressionseinheit auf das
Aussehen der Daten simuliert.
2.1 Mo dell der Datenpro duktion
F
ur die Simulation eines Problems b en
otigt man ein Mo dell, das dieses Problem in geeig-
neter Weise b eschreibt. Bei der Erzeugung von Testdaten sind dies einige relativ einfache
Funktionen und Wahrscheinlichkeitsverteilungen. Sie sollen im folgenden b eschrieb en und
b egr
undet werden.
2.1.1 Energieverteilung
Den Startpunkt der Simulation bildet ein mit Energie gef
ullter Trigger Tower. Die Physik
der Streuung und die Geometrie des Detektors verschwinden in einer Wahrscheinlichkeits-
verteilung f
ur die Energie eines Trigger Towers. Dieses Mo dell reichtvollkommen aus, da
nicht die Herkunft eines Teilchens, o der die Teilchensorte interessiert, sondern lediglich
die Daten die sp
ater komprimiert werden sollen und diese b estehen aus Energiewerten.
Ein Blick auf Abbildung 2.1 zeigt, da die Dichte der sekund
ar pro duzierten Teilchen
gl
ucklicherweise
ub er den
-Bereich, den das Kalorimeter ab deckt, weitgehend konstant
ist. Es ist daher nicht notwendig verschiedene Teile des Kalorimeters getrennt zu unter-
suchen.
Betrachtet man b ereits gewonnene Daten von Exp erimenten bei niedrigen Schwer-
punktsenergien (
p
s
= 546 GeV), so zeigt sich, da die Verteilung des transversalen Im-
pulses p
t
f
ur geladene Teilchen einem Potenzgesetz gehorcht, das f
ur kleine p
t
in einen
exp onentiellen Abfall
ub ergeht [13]. Setzt man dieses Verhalten f
ur die Kurven in Ab-
1
C++ ist eine ob jektorientierte Programmiersprache [12]
12
2.1. MODELL DER DATENPRODUKTION
13
Abbildung 2.1: Teilchendichte in Abh
angigkeit von
f
ur geladene und ungeladene Teilchen
(nach [14 ]). Die senkrechten Balken geb en den vom Kalorimeter abgedeckten
-Bereich
an.
bildung 2.2 an, so erh
alt man eine Absch
atzung f
ur die Verteilung von
Minimum Bias
Ereignissen
2
.
Betrachtet man als typische physikalisch relevante Ereignisse 2 Jets mit einem Radius
in der
,
,
Eb ene von 0.4, so wird ein Bereichvon
A
Jet
=2
0
:
4
2
=1
:
0 (2.1)
von diesen Jets
ub erdeckt. Da jeder Trigger Tower eine Fl
ache von 0
:
1
0
:
1 in der
-
-
Eb ene einnimmtwerden ungef
ahr 100 Trigger Tower durch diese Jets mit Energie gef
ullt.
Die Anzahl der Zellen mit einer b estimmten Energie sollte in etwa quadratisch mit der
Energie abnehmen, da die Jetenergie mit dem Radius abnimmt, die Zahl der zur Verf
ugung
stehenden Zellen jedo ch quadratisch mit dem Radius zunimmt [15]. Dieses Verhalten ist
auch in einer am Institut f
ur Ho chenergiephysik in Heidelb erg simulierten Verteilung in
Abbildung 2.3 zu sehen. Da diese Verteilung nicht normierbar ist, mute f
ur Simulations-
zwecke ein Abschneideparameter gew
ahlt werden, der auf 1 GeV gelegt wurde.
Das Bild, das man bis jetzt erhalten hat, b esagt also, da b ei jedem Bunch-Crossing im
Mittel 100 der 4000 hadronischen o der elektromagnetischen Trigger Tower mit Energien,
die ungef
ahr prop ortional zu E
,
2
T
verteilt sind, gef
ullt sein werden. Zur Ber
ucksichtigung
von Minimum Bias Ereignissen, wurde das Verh
altnis von Trigger Towern mit Energien
ub er 1 GeV zu Trigger Towern mit weniger als 1 GeV abgesch
atzt. Diesem Verh
altnis
entsprechend bleib en in der Simulation dann Zellen leer, o der werden mit einer Energie
aus der Verteilung gef
ullt. F
ur eine Absch
atzung dieses Verh
altnisses (im folgenden mit
Bin0/Rest-Ratio b ezeichnet), wurde in Abbildung 2.2 die Fl
achen unter den Kurven bis
1 GeV mit denjenigen ab 1 GeV verglichen. Eine andere Absch
atzung b eruht auf der
mittleren Energie der Minimum Bias Teilchen, die b ei 400 MeV liegt. Dies b edeutet, da
im Mittel mindestens drei Teilchen in einem Trigger Tower ihre Energie dep onieren m
ussen,
2
Minimum Bias Ereignisse: Untergrund der uninteressanten Ereignisse
14
KAPITEL 2. ERZEUGUNG VON TESTDATEN
Abbildung 2.2: Teilchendichte in Abh
angigkeit von E
T
f
ur geladene und ungeladene Teil-
chen [14 ]
ZELL ENERGY
10 -3
10 -2
10 -1
1
10
0 20 40 60 80 100 120 140 160 180 200
Abbildung 2.3: Simulierte Teilchendichte in Abh
angigkeit von E
T
[16]
2.1. MODELL DER DATENPRODUKTION
15
Abbildung 2.4: Shapingfunktion [2]
um
ub er 1 GeV zu kommen. Bei b eiden Absch
atzungen erh
alt man ein Bin0/Rest-Ratio
von ungef
ahr Neun.
2.1.2 Komp onenten der Elektronik
Die Energieverteilung im Kalorimeter ist nun b ekannt. Es ist also m
oglich eine Simulation
zu schreib en, die einem Trigger Tower eine b estimmte Energie zuweist. Allerdings erh
alt
man durch die Energiedep osition eines Teilchens in einem Trigger Tower keinen Energie-
wert, sondern ein analoges elektrisches Signal, das erst mit Hilfe entsprechender Elektronik
in einen o der mehrere Energiewerte umgewandelt wird, die dann von der Kompressions-
einheit verarb eitet werden. Es ist also notwendig auch die nachfolgende Elektronik zu
mo dellieren. Der anf
anglichf
ur den Trigger Tower erhaltene Energiewert spielt die Rolle
eines Normierungsfaktors, mit dem die Pulsh
ohe des analogen Signals festgelegt wird.
Pulsformung
In den einzelnen Trigger Towern wird eine Ionisationsladung gemessen, die prop ortional
zur darin dep onierten Energie ist. Ein typisches Signal zeigt Kurve (a) in Abbildung 2.4.
Es ist ein Dreiecksimpuls
i
(
t
)=
I
0
1
,
t
t
dr
t
t
dr
;
(2.2)
dessen Abklingszeit
t
dr
der Driftzeit in
ussigem Argon (ca. 400 ns) entspricht. Aus
diesem Puls wird durch den Pulsformer die in Abbildung 2.4 (b) gezeigte Shapingkurve
erzeugt. Das Maximum des bip olaren Signals ist prop ortional zur dep onierten Energie.
Die L
ange des Unterschwingers ist abh
angig von der Driftzeit
t
dr
. Die schwarzen Punkte
kennzeichnen die Bunch-Crossings. Dieses Signal hat gegen
ub er dem Dreieckspuls den
Vorteil, da es die Summe aus elektronischem und Pile-Up
3
Rauschen durch sein scharfes
3
Ub erlagerung zweier um wenige Bunch-Crossings gegeneinander verschobener Signale.
16
KAPITEL 2. ERZEUGUNG VON TESTDATEN
Abbildung 2.5: Rauschen [2]
Maximum verringert. Dadurch, da das zeitliche Integral
ub er diese Kurveverschwindet,
wird auch eine Verschiebung der Nullinie verhindert.
Die Shapingfunktion l
at sich f
ur verschiedene Eingangspulsformen geschlossen an-
geb en [17]. F
ur die Simulation wurde als Eingangssignal der durch
t
dr
parametrisierte
Dreieckspuls angenommen. Das Shaping wird dann b eschrieb en durch einen Satz von
Funktionen, die in Anhang C aufgelistet sind. Parametrisiert wird die Kurve durch die
Driftzeit
t
dr
, die Zeitkonstante des Shap ers
und das Verh
altnis der Zeitkonstanten von
Vorverst
arker und Shap er
.
Rauschen
Eng mit dem Shaping verbunden ist das Rauschen. In Abbildung 2.5 ist die
Anderung der
Summe aus elektronischem und Pile-Up Rauschen mit der Lage des Maximums (Anstiegs-
zeit) der Shapingkurve zu sehen. Da sich mit wachsender Anstiegszeit die Bandbreite
verringert f
allt das elektronische Rauschen. Das Pile-Up Rauschen w
achst hingegen mit
der Anstiegszeit, da die Wahrscheinlichkeit zur
Ub erlagerung zweier Pulse mit der Puls-
breite zunimmt. Legt man das Maximum der Shapingkurve auf circa 50 ns, so wird das
Rauschen minimal und l
at sich durch eine Gaukurve mit
0
:
5 GeV b eschreib en [2].
Im Simulationsprogramm wurde ein Zufallszahlengenerator eingebaut, der gauverteil-
te Zufallszahlen mit b eliebigem
und Mittelwert pro duziert. Damit l
at sich die Breite
des Rauschens variieren. Eine Variation des Mittelwertes ist zwar theoretisch m
oglich,
jedo ch nicht b esonders sinnvoll.
FADC und Pedestal
Die Einstellung des Pedestals wird realisiert
ub er die Addition eines einstellbaren kon-
stanten Wertes zu jeder Energie. Am Schlu erfolgt die Digitalisierung. Hier l
at sich der
Arb eitsb ereich des FADC und die Au
osung in bits w
ahlen. Die eigentliche Digitalisierung
2.2. DAS PROGRAMM
17
erfolgt durch Auf- b eziehungsweise Abrunden der Energien. Liegt ein Wert auerhalb des
Arb eitsb ereiches, so wird diejenige Grenze des Arb eitsb ereiches als Ausgab e gew
ahlt, die
ub erschritten wurde. Am Ende der Verarb eitungskette erh
alt man schlielich eine ganze
Zahl, die eine b estimmte Energie repr
asentiert.
2.2 Das Programm
Aufgab e von DATASIM ist es, ein einfaches Werkzeug f
ur die Pro duktion von Testdaten
zur Verf
ugung zu stellen. Die Variation m
oglichst vieler Parameter ist dab ei b esonders
wichtig. Das Kalorimeter wird simuliert durch die in Abschnitt 2.1.1 motivierte Potenz-
funktion, bei der sich der Exp onent b eliebig w
ahlen l
at. Das Verh
altnis von leeren zu
gef
ullten Trigger Towern wird eingestellt
ub er das Bin0/Rest-Ratio. Auch f
ur Rauschen
und Shaping lassen sich alle wichtigen Parameter frei w
ahlen. Es ist m
oglich die Anzahl
der ausgelesenen Bunch-Crossings und die Anzahl der Bunch-Crossings vor dem Maximum
der Shapingkurvezu b estimmen. Eine Phasenverschiebung zwischen Digitalisierung und
Shap ermaximum ist eb enfalls einstellbar. F
ur die FADCs ist schlielich die Au
osung in
bits und der abgedeckte Energieb ereichw
ahlbar. Diese Einstellungen werden in einem Pa-
rameterle vorgenommen, der von der Simulation eingelesen wird. Ein typisches Beispiel
ist in Abbildung 2.6 zu sehen.
Die einzelnen Schritte der Berechnung eines Events f
ur einen Kanal sind in Abbildung
2.7 dargestellt. Ein Zufallszahlengenerator b estimmtentsprechend dem Bin0/Rest-Ratio,
ob ein Teilchen mehr als 1 GeV in einem Trigger Tower dep oniert hat. Ist dies der Fall, wird
eine Energie aus der Verteilung gew
urfelt, ansonsten wird sie auf Null gesetzt. Nachdem
die Shapingfunktion b erechnet wurde, wird eine Schleife solange durchlaufen, bis die vom
Benutzer eingestellte Anzahl von Werten auf der Kurve b erechnet wurde. Zu jedem Wert
werden Rauschen und Pedestal addiert und zum Schlu wird digitalisiert.
Es wird ein File angelegt, das in bin
arer Form die simulierten Daten enth
alt. Sie
sind so angeordnet, da jeweils die f
ur einen Kanal zu einem Event ausgelesenen Bunch-
Crossings in einem Blo ck hintereinander stehen, und die im Parameterle kongurierten
Kan
ale nacheinander durchlaufen werden. Die Daten hab en somit dasselb e Format, wie
im RemASIC vor der Kompression (siehe 5.1). Auerdem ist eine Variation einzelner
Parameter mit w
ahlbarem Variationsb ereich und b eliebiger Schrittweite m
oglich. In die-
sem Fall kann zus
atzlich zum Datenle eine Tab elle erzeugt werden, die den aktuellen
Parameterwert und die zugeh
orige Entropie enth
alt.
18
KAPITEL 2. ERZEUGUNG VON TESTDATEN
Nov 18 1997 18:05 Page 1 ParameterFile
#Number of Events
1000
#Bin 0 / rest ratio
9
#Energy Cut
0
#Number of parameters for noise
4
#Parameters for noise
-100 # Minimum rnd number
100 # Maximum rnd number
0 # Mean
0.5 # Standard deviation
#Number of parameters for pow
4
#Four fitparameters follow
1 # Minimum rnd number
255 # Maximum rnd number
15.67 # Fit-parameter 1
1.833 # Fit-parameter 2
#Shaper Data
15 # Shaper time constant
400 # Drift time
2 # Lambda
#Sampling data
5 # Number of BunchCrossings per event
25 # Time between two samples
3 # Number of the sample in shaper maximum
0 # Phase-shift
# The following values are only of interest if you use an FADC object
# to digitize the obtained energies
#Number of bits
10
#Maximum energy
255
#Output Mode 0=dec 1=bin
0
#Number of FADCs
1
#Pedestal values for all the FADCs follow
1.5
Abbildung 2.6: Typischer Parameterle f
ur
DATASIM
2.2. DAS PROGRAMM
19
Ende
Energie aus Verteilung?
Würfele E E=0
ja nein
Berechne geshapten Energiewert
Weitere Shapingwerte?
Digitalisiere mit 8 oder 10 bit
Addiere Pedestal
Addiere Noise
ja nein
Abbildung 2.7: Fludiagramm f
ur die Berechnung eines Events in einer Zelle
Kapitel 3
Datenkompression
F
ur einen Test von verschiedenen M
oglichkeiten zur Datenkompression wurde Software
entwickelt, die Datens
atze von DATASIM einlesen und mit verschiedenen Algorithmen
komprimieren kann. Die getesteten Algorithmen wurden dann auf dem RemASIC im-
plementiert. Dieses Kapitel widmet sich einer Darstellung der verwendeten Verfahren,
die zum Teil allgemein bekannt sind (universelle Algorithmen) und zum Teil sp eziell f
ur
die Auslese des Level-1 Triggers entwickelt wurden (sp ezielle Algorithmen). Eine kurze
Beschreibung der Kompressionssoftware bildet den Abschlu dieses Kapitels.
3.1 Eine kurze Einf
uhrung
Zwei Begrie werden im Laufe der weiteren Diskussion immer wieder auftauchen, n
amlich
die Entropie
H
und die mittlere Co dewortl
ange
l
eines Datensatzes. Sie werden hier nur
kurz eingef
uhrt. F
ur eine Einf
uhrung in die Informations- und Co dierungstheorie sei der
Leser an Anhang A verwiesen.
Den Ausgangspunkt der Betrachtungen bildet eine Folge von Energiewerten, die zum
Beispiel mit DATASIM erzeugt wurde, im weiteren als Datensatz b ezeichnet. Ein Ma
f
ur die in diesem Datensatz enthaltene Information ist die Entropie
H
(
S
)=
,
1
ln 2
N
X
k
=1
p
k
ln
p
k
; [
H
]=
bit
(3.1)
N
: Anzahl der verschiedenen Energiewerte
p
k
: Wahrscheinlichkeit des
k:
Energiewertes.
In der Informationstheorie ist es
ublich, die Entropie in der Einheit bit zu messen. Hat
man zum Beispiel die 256 m
oglichen Energiewerte eines 8 bit FADC in einem Datensatz,
so ist die darin enthaltene Information, und damit die Entropie, nur dann 8 bit, wenn alle
Werte gleichwahrscheinlich sind. Ansonsten ist die Entropie kleiner.
Mit geeigneten Co dierungsverfahren (siehe Anhang A) l
at sich dieser Umstand aus-
nutzen. Indem man h
augen Energiewerten kurze Co des, weniger h
augen daf
ur l
angere
zuweist, wird der Umfang des Datensatzes reduziert. Da nun nicht mehr jeder Energiewert
mit der gleichen Anzahl an bits (zum Beispiel 8 bit bei 256 Werten) co diert wird, kann
20
3.2. FORDERUNGEN AN DIE VERFAHREN
21
man nicht mehr von einer Co dewortl
ange sprechen, sondern es mu die mittlere Co de-
wortl
ange verwendet werden. Die mittlere Co dewortl
ange
l
eines Datensatzes ist gegeb en
durch:
l
:=
N
X
k
=1
h
k
l
k
:
(3.2)
l
k
: L
ange des
k
. Co dewortes
h
k
: RelativeH
augkeit des
k:
Energiewertes im Datensatz
Ein Co de ist umso b esser, je n
aher die mittlere Co dewortl
ange an die Entropie heran-
kommt. Es ist nichtm
oglich einen Datensatz mit einer mittleren Co dewortl
ange zu co die-
ren, die kleiner ist als seine Entropie, ohne Information zu verlieren.
Zum Schlu seien no ch kurz die verschiedenen prinzipiellen M
oglichkeiten zur Daten-
kompression aufgef
uhrt. Zun
achst einmal lassen sich die Kompressionsalgorithmen eintei-
len in verlustfreie und verlustb ehaftete. Verlustb ehaftete Verfahren bieten sichvor allem
bei der
Ub ertragung von Audio- und Video daten an. F
ur die Auslese der Triggerdaten
kommen sie jedo ch nichtinFrage, da man keine Information verlieren m
ochte. Deswegen
sollen nur M
oglichkeiten zur verlustfreien Kompression n
aher diskutiert werden.
Die Co dierung der Ausgangsnachricht erfolgt im einfachsten Fall zeichenweise. Das
b edeutet, jedem Zeichen der Ausgangsnachricht wird ein Co dewort zugewiesen, das dann
ub ertragen wird. Beispiele hierf
ur sind:
Human (siehe 3.3.1)
Human-Inspired (siehe 3.4.1)
Shannon-Fano (nachzulesen in [18])
Eine andere M
oglichkeit b esteht darin, b estimmten Zeichenfolgen, die h
aug auftreten,
kurze Co des zuzuweisen. Bekannte Algorithmen sind:
Run-Length (siehe 3.3.2)
Lemp el-Ziv (nachzulesen in [18 ])
Eine dritte Variante ist, die Nachricht an sich zu ver
andern. Dies setzt allerdings eine
genauere Kenntnis der Datenstruktur voraus. Wei man zum Beispiel, da die Dierenzen
aufeinanderfolgender Zahlenwerte stets gering sind, die Zahlenwerte selbst sich jedo ch
ub er
einen groen dynamischen Bereich erstrecken, so kann man statt der Zahlenwerte selbst
die Dierenzen co dieren. Je mehr Wissen man
ub er das Aussehen der Daten b esitzt,
desto eektiver lassen sich solche Metho den gestalten. Der Nachteil liegt allerdings in der
Sp ezialisierung auf b estimmte Datenmuster. Das auf dem RemASIC realisierte
Dierence
Coding
(siehe 3.4.2) ist ein Beispiel f
ur einen solchen Algorithmus.
3.2 Forderungen an die Verfahren
Nicht jedes b eliebige Kompressionsverfahren kam f
ur eine Implementation auf dem Re-
mASIC in Frage. Da die Datenkompression lediglich ein Werkzeug f
ur die Auslese des
22
KAPITEL 3. DATENKOMPRESSION
Level-1 Triggers darstellt, muten b estimmte Forderungen ber
ucksichtigt werden. Das
ideale Kompressionsverfahren m
ute
ub er folgende Eigenschaften verf
ugen
Verlustfreie Kompression
Erhalt von festen Wortgrenzen
Rekonstruktion des Datensatzes ohne zus
atzliche Informationen
Robust gegen
ub er Schwankungen verschiedener Parameter
Hoher Kompressionsfaktor
Die Forderung nach verlustfreier Kompression ist strikt einzuhalten. Kompressionsver-
fahren, b ei denen ein Teil der Daten verloren geht, kamen von vornherein nichtinFrage.
Allerdings wird diskutiert, einen
Energie-Cut
auf die Daten anzuwenden. Das b edeutet,
da alle Energien, die kleiner sind als ein b estimmter Wert, auf Null gesetzt werden. Daher
wurde auch eine f
ur diese Art von Daten optimale Kompressionsm
oglichkeit untersucht.
Die vier folgenden Eigenschaften sind nicht strikt gefordert, es w
are jedo chw
unschens-
wert, ein Verfahren zu nden, das m
oglichst viele dieser Eigenschaften b esitzt. Gibt es
in einem Co de keine festen Wortgrenzen, also Bl
ocke mit wohl denierter L
ange, so f
uhrt
schon ein einziges b ei der
Ub ertragung des Co des ver
andertes bit dazu, da der gesamte
restliche Co de unlesbar wird, o der falsch deco diert wird. Zus
atzliche bits f
ur eine Fehler-
korrektur w
urden hier Abhilfe schaen, allerdings auch die Kompression verschlechtern,
da die Co des l
anger werden. Im Rahmen dieser Arb eit wurde eine Fehlerkorrektur nicht
implementiert. Um den Aufwand bei der Verwaltung der gesp eicherten Daten gering zu
halten, m
ochte man m
oglichst komprimierte Datens
atze erhalten, die ohne zus
atzliche In-
formationen o der Parameter deco dierbar sind. Ein Algorithmus ist oft nur f
ur Datens
atze
mit sp eziellen Eigenschaften geeignet (siehe Abschnitt 4.2). Wird er f
ur die Bearb eitung
von Datens
atzen verwendet, die nicht
ub er diese Eigenschaft verf
ugen, so kann er schlimm-
stenfalls zu einer Aufbl
ahung des Co des f
uhren. Da zum Beispiel die Pedestals von Kanal
zu Kanal schwanken o der sichw
ahrend des Betriebs verschieb en k
onnen, ist es wichtig ein
Verfahren zu nden, das m
oglichst unabh
angig ist von solchen Ein
ussen.
3.3 Universelle Algorithmen
Human und Run-Length Co ding sind allgemein bekannte und h
aug verwendete Ver-
fahren zur Datenkompression. W
ahrend mit Hilfe des Human Co ding b einahe jeder
b eliebige Datensatz (mehr o der minder gut) komprimiert werden kann, l
at sich das Run-
Length Enco ding nur auf solche Daten anwenden, bei denen dasselb e Zeichen m
oglichst
oft hintereinander
ub ertragen wird.
3.3.1 Human Co ding
Es wird erwartet, da h
aug niedrige Energiewerte
ub ertragen werden und die Wahrschein-
lichkeit f
ur ein Auftreten zu hohen Energien rasch abnimmt. Dies b edeutet jedo ch (siehe
3.3. UNIVERSELLE ALGORITHMEN
23
Formel 3.1), da die Entropie deutlich unter ihrem Maximalwert (8/10bit bei 256/1024
Energiewerten) liegen wird.
Es ist nat
urlichw
unschenswert, diesen Umstand auszunutzen, ohne allzu sehr von der
genauen Form der zu verarb eitenden Daten abh
angig zu sein. Dies ist auch der Grund,
warum Human Co ding auf dem RemASIC implementiert wurde. Solange die Energie-
werte nicht gleichverteilt sind, sondern einige h
auger auftreten und andere daf
ur seltener,
wird man eine Kompression erreichen.
Prinzip und Algorithmus
Beim Human Co ding werden h
aug auftretenden Zeichen kurze Co des zugewiesen und
seltenen daf
ur l
angere Co des (siehe Anhang A.2.2). Das Problem b esteht darin, zum
einen einen eindeutig deco dierbaren Co de zu erzeugen, zum anderen mit der mittleren
Co dewortl
ange
l
(
C; S
)m
oglichst nah an die Entropie
H
(
S
)zukommen. Solch einen Co de
b ezeichnet man nach A.2.2 als optimalen Prex Co de. Sie lassen sich sehr gut durch
Baumstrukturen darstellen. Es wird also im folgenden die Konstruktion eines bin
aren
Baumes, der einen optimalen Prex Co de repr
asentiert, vorgestellt.
Das Vorgehen ist in Abbildung 3.1 dargestellt. Zun
achst werden die Zeichen nach
fallender Wahrscheinlichkeit in einer Liste eingetragen. Die letzten b eiden (unwahrschein-
lichsten) Zeichen werden als Bl
atter an einen Knoten geh
angt. Statt den b eiden Bl
attern
wird nun der Knoten in die Liste eingetragen und erh
alt die Summe der Wahrscheinlich-
keiten der b eiden Bl
atter. Die Liste wird neu sortiert, und das ganze solange wiederholt,
bis sie nur no ch ein einziges Elemententh
alt, die Wurzel des Co debaumes. Mit dem dar-
gestellten Algorithmus l
at sichf
ur ein gegeb enes Ensemble der Human Co de erzeugen.
Um mit dem erzeugten Co de einen Datensatz zu co dieren, wird eine Art Co debuch
verwendet. Die Zeichen des Ensembles werden durchnummeriert von 1 bis
N
. Diese
Zahlenwerte dienen als Index f
ur eine Tab elle, die in irgendeiner Form sowohl den eigent-
lichen Co de als auch die Co dewortl
ange enthalten mu, da die Co des verschieden lang
sind. Im Falle der Software ist die Tab elle einfach ein zweidimensionales Array. Mit dem
ersten Index wird das Zeichen selektiert. Der zweite Index kann nur die Werte Null o der
Eins annehmen. Eine Variable enth
alt den Co de als Integer Variable, die andere die Co-
dewortl
ange. Auf dem RemASIC wurde die Tab elle als Lo ok-Up Table realisiert (siehe
5.4.1).
Das Deco dieren eines Datensatzes, der b ereits Human co diert ist, kann zum Beispiel
ub er den Co debaum erfolgen. Man wandert, b eginnend an der Wurzel, solange entspre-
chend den eingelesenen bits den Baum entlang, bis man auf ein Blatt st
ot. Das Zeichen,
das dieses Blatt repr
asentiert, wird dann geschrieb en. Auf diese Weise erkennt man auto-
matisch die Wortgrenzen.
Beispiel
Gegeb en sei ein Datensatz mit vier Energiewerten zwischen 1 GeV und 4 GeV. Die Wahr-
scheinlichkeiten f
ur das Auftreten der Energien und die Co des, die sich mit dem b eschrie-
b enen Verfahren ergeb en sind in Tab elle 3.1 zu sehen. Der Co debaum f
ur dieses Beispiel
24
KAPITEL 3. DATENKOMPRESSION
Sortiere die Liste nach fallender
Wahrscheinlichkeit
Nein
Ist die
Gib diesem Knoten die Summe der
Wahrscheinlichkeiten seiner Blätter.
Der Codebaum ist fertig!!
Füge den Knoten als ein neues Element in
die Liste ein
aus der Liste
Lösche die letzten beiden Einträge
Blätter an einen neuen Knoten.
Hänge die beiden gelöschten Elemente als
Füge alle Zeichen der Nachricht
in eine Liste ein
Wahrscheinlichkeit des Knotens = 1 ?
Ja
Abbildung 3.1: Der Human Algorithmus
Energie (GeV) Co de Wskt.
p
(
E
)
1 0 0.55
2 10 0.20
3 111 0.15
4 110 0.10
Tab elle 3.1: Human Co des f
ur einen Beispieldatensatz
ist in Anhang A abgebildet. Die Entropie dieses Datensatzes b etr
agt
H
(
S
)=
,
1
ln 2
(0
:
55 ln 0
:
55 + 0
:
20 ln 0
:
20 + 0
:
15 ln 0
:
15 + 0
:
10 ln 0
:
10) bit = 1
:
68 bit
:
(3.3)
Die mittlere Co dewortl
ange b etr
agt
l
=(1
0
:
55 + 2
0
:
20 + 3
0
:
15 + 3
0
:
10) bit = 1
:
7 bit
:
(3.4)
Bei der Co dierung mit normalen Bin
arzahlen h
atte man 2 bit b en
otigt. An diesem Beispiel
l
at sich auch eine Gefahr des Human Co ding veranschaulichen, die Aufbl
ahung des
Co des. Wird mit obigem Co de ein Datensatz co diert, der nur aus den unwahrscheinlichen
Energien 3 GeV und 4 GeV b esteht, so w
achst die mittlere Co dewortl
ange
l
auf 3 bit.
3.3. UNIVERSELLE ALGORITHMEN
25
Vor- und Nachteile
Mit dem Human-Verfahren hat man die M
oglichkeit, f
ur ein unver
anderliches Ensemble
einen optimalen Prex Co de zu nden. Der Algorithmus zur Erstellung des Co debaumes
l
at sich relativ einfach auf einem Rechner implementieren. Das Co dieren selbst erfordert
keine zeitaufwendigen Berechnungen, sondern l
at sich durch Abfrage der Werte einer
Tab elle realisieren.
Trotz seiner groen Beliebtheit und seiner vielen Vorz
uge hat diese Metho de auch ei-
nige Nachteile. Sollen die co dierten Daten
ub ertragen werden, so ist man auf die absolute
Zuverl
assigkeit des
Ub ertragungskanals angewiesen, o der mu zus
atzliche bits f
ur eine
Fehlerkorrektur senden, da es keine festen Wortgrenzen gibt. Ver
andern sich die Wahr-
scheinlichkeiten f
ur das Auftreten von Zeichen mit der Zeit, so wird sich die Kompression
verschlechtern, da der erzeugte Co de nur f
ur ein ganz b estimmtes Ensemble optimal ist.
Die Sp eicherung des Co debaumes ist zwingend erforderlich, da nur so die Daten wieder
rekonstruiert werden k
onnen.
3.3.2 Run-Length Enco ding
Run-Length Enco ding wurde implementiert, um Daten nach BCID, Pedestalsubtraktion
und eventuell einem Energie-Cut ezientzukomprimieren. Subtrahiert man n
amlich die
Pedestal und wendet einen mo deraten Energie-Cut (ca. 1 GeV) an, so verschwindet der
Rauschuntergrund der Trigger Tower, in denen keine Energie dep oniert ist. F
ur diese wird
dann immer der Wert Null
ub ertragen. Dies b edeutet, da es lange Folgen von Nullen
geb en wird.
Prinzip
Es ist inezient, dasselb e Zeichen oft hintereinander zu
ub ertragen. Das Run-Length
Enco ding bietet eine einfache M
oglichkeit, das Datenvolumen zu reduzieren. Anstatt ein
Zeichen
n
-mal hintereinander zu schreib en, wird das Zeichen und danach die Anzahl der
Wiederholungen geschrieb en. Die einzige Schwierigkeit ist, b eim Deco dieren zu erkennen,
ob ein Co de nun ein Zeichen o der die Zahl der Wiederholungen repr
asentiert. Es gibt hier
eine groe Vielfalt von M
oglichkeiten, hier soll jedo chnur die Variante b espro chen werden,
die auf dem RemASIC realisiert ist.
Da der einzige Energiewert, der oft hintereinander auftreten wird, Null ist, co diert man
lediglich Folgen von Nullen und
ub ertr
agt alle anderen Energien unver
andert, das heit
als 8 o der 10bit Zahl. Der Wert Null wird als Signal daf
ur b enutzt, da als n
achstes die
Zahl der Wiederholungen eingelesen werden mu. Auch bei einem einmaligen Auftreten
einer Null wird zus
atzlich die Anzahl der Wiederholungen
ub ertragen, das Datenvolumen
wird gr
oer.
Die Lau
ange wird auch als 8 o der 10bit Zahl
ub ertragen, so da es b ei diesem Ver-
fahren denierte Wortgrenzen gibt.
26
KAPITEL 3. DATENKOMPRESSION
Nachricht Co de
27-12-31 27-12-31
255-0-13 255-0-1-13
255-0-0-0-0-13 255-0-4-13
12-..(300 mal 0)..-18 12-0-255-0-45-18
Tab elle 3.2: Run-Length Enco ding f
ur Beispieldaten
Beispiel
Als Beispiel m
ogen einige ausgew
ahlte Folgen von 8 bit Energiewerten dienen. In Tab el-
le 3.2 ist ihre Co dierung, wie sie auf dem RemASIC stattndet, angegeb en. Der erste
Datensatz bleibt unver
andert, da er keine Null enth
alt, der zweite wird aufgebl
aht, denn
es taucht nur eine einzige Null gefolgt von einem anderen Wert auf. Im dritten ndet
eine Kompression statt, aus vier Nullen wird eine Null und eine Vier. Auch der letzte
Datensatz wird komprimiert. Hier ist gezeigt, was passiert, wenn die Zahl der Nullen zu
gro wird, um mit einer 8 bit Zahl co diert zu werden. Es wird einfach bis 255 gez
ahlt und
dann erneut eine Null
ub ertragen und die Z
ahlung b eginntvon vorne.
Vor- und Nachteile
Da es b eim Run-Length Enco ding feste Wortgrenzen gibt, ist die
Ub ertragung des Co des
relativ fehlertolerant. Sollte ein 1bit-Fehler auftreten, ist zwar ein Energiewert falsch,
o der es werden zu viele Nullen rekonstruiert, ab er der restliche Datensatz bleibt davon
unber
uhrt.
Dieses Verfahren ist nur sinnvoll, falls b ereits eine Pedestalsubtraktion stattgefunden
hat, und ein Energie-Cut angewendet wird. Andernfalls ist es sehr wahrscheinlich, da
in den Datens
atzen einzelne Nullen erscheinen. Dies f
uhrt bei dem auf dem RemASIC
implementierten Verfahren dann zu einer Vergr
oerung des Datenvolumens.
3.4 Sp ezielle Algorithmen
Zwei weitere Kompressionsverfahren wurden auf dem RemASIC implementiert. Sie sind
sp eziell f
ur die erwartete Struktur der Kalorimeterdaten entwickelt worden. Beide Ver-
fahren machen sich den Umstand zu nutze, da die Daten sehr h
aug aus einem engen
Bereich um einen b estimmten Wert stammen werden.
3.4.1 Human-Inspired Co ding
Nimmt man an, da das Pedestal
P
(siehe Abschnitt 1.2.1 und 2.1.2) f
ur alle Kan
ale gleich
ist, so hat die Wahrscheinlichkeitsverteilung f
ur die Energiewerte ein scharfes Maximum
bei
P
. Dieses Maximum wird umso mehr verschmiert, je mehr die Pedestals der einzelnen
Kan
ale schwanken. Sind diese Schwankungen nicht allzu gro, so liegen die Energiewerte,
die b ei weitem am h
augsten auftreten, in einem Intervall um eine
Referenzenergie
E
R
.
3.4. SPEZIELLE ALGORITHMEN
27
Zero Message Hea
der
Hea
der
Hea
Zero Message
der
Normal Message
LSB
MSB
Zero Message
LSB
Zero Message
MSB LSB
MSB
Datenwort
Datenwort
Datenwort
Datenwort mit drei kurzen Blockcodes
Datenwort das von einem SkipRest-Token beendet wird
Datenwort mit einem unveränderten Wert
SkipRestUndefiniert
Abbildung 3.2: Datenw
orter b eim Human-Inspired Co ding
Prinzip
Co diert man nun die Energien, die in diesem Intervall um
E
R
liegen mit kurzen Blo ckco des
(siehe Anhang A) und
ub ertr
agt alle anderen Energien unver
andert, so wird sich eine
Reduktion des Datenvolumens ergeb en, ohne da auf Wortgrenzen verzichtet werden mu
[19]. Allerdings mu nun no ch eine M
oglichkeit geschaen werden, zwischen kurzen und
langen Blo ckco des zu unterscheiden.
Es werden immer Datenw
orter gleicher L
ange
l
DW
ub ertragen. Der Index steht f
ur
Data Word
. Jedes Datenwort b eginnt mit einem Header. Er ist ein bit lang und zeigt an,
wie der Rest des Datenwortes zu interpretieren ist. Die verschiedenen M
oglichkeiten zum
Aufbau eines Datenwortes zeigt Abbildung 3.2.
Die kurzen Blo ckco des werden im weiteren als Zero-Message b ezeichnet, ihre L
ange
sei
l
ZM
. Die unver
anderten Energien hab en die L
ange
l
NM
, dab ei b edeutet
NM
Normal
Message
. Es lassen sich also maximal
=
1
2
(2
l
ZM
,
2) =
2
l
ZM
,
1
,
1 (3.5)
Energiewerte um
E
R
durch kurze Co des ersetzen. Mit
l
ZM
bits k
onnen n
amlich maximal
2
l
ZM
Nachrichten co diert werden. Einen Co de braucht man f
ur die Referenzenergie selbst
und einer wird als
SkipRest
-Token reserviert. Das
SkipRest
-Token wird ben
otigt, weil
es m
oglich ist, da weniger kurze Co des hintereinander auftreten, als in ein Datenwort
passen. Tritt also das
SkipRest
-Token auf, so wird der Rest des Datenwortes ignoriert und
der Deco der liest das n
achste Datenwort.
Bisher wurde die Frage oengelassen, wie die kurzen Blo ckco des zustande kommen.
Dazu wird die Dierenz zwischen dem aktuellen Energiewert und
E
R
b erechnet. Liegt
diese innerhalb von , so l
at sie sich durch eine
l
ZM
bit-Zahl ausdr
ucken. Das MSB wird
28
KAPITEL 3. DATENKOMPRESSION
Datensatz: 3-10-15-4
Referenzwert: 15
Datenwortlänge: 12 bit
Länge der kurzen Blockcodes: 4 bit
Länge eines unveränderten Wertes: 10 bit
MSB
Zwei unbenutzte bits
LSB MSB LSB MSB LSB
Datenwort3: 4
1000 0
1101
00001
0000000011 1
0000000100
Datenwort1: 3
15-15=0 -> 1000
10-15=-5 -> 1101
00 00
Header Header
Datenwort2: (-5)-(-0)-SkipRest
Header
Zwei unbenutzte bits
Abbildung 3.3: Human-Inspired Co ding f
ur einen Beispieldatensatz
als Vorzeichen-bit genutzt, der Rest stellt, in bin
arer Form, den Wert dar, um den
E
R
zu vergr
oern, o der zu verkleinern ist. Der Wert Null mit Vorzeichenbit auf Null, also
b0000
1
, wird als SkipRest-Token verwendet, f
ur die Referenzenergie wird b1000 reserviert.
Auf dem RemASIC wurde das Human-Inspired Verfahren mit festen Werten f
ur
l
DW
,
l
NM
und
l
ZM
realisiert. Der Wert f
ur
E
R
l
at sich
ub er ein Register w
ahlen (siehe Kapitel
5).
Beispiel
In Abbildung 3.3 ist die Co dierung nach dem Human-Inspired Verfahren f
ur eine kurze
Folge von Energiewerten zu sehen. Die Energieau
osung b etrage 10 bit, der Werteb ereich
0 GeV bis 255 GeV. Die verwendeten Parameter sind dem Kasten darunter zu entnehmen.
Die Wortl
angen entsprechen den auf dem RemASIC realisierten Werten. Man erkennt,
da b ei 3 LSBs, was b ei 10 bit Au
osung 0.75 GeV entspricht, die Energie unver
andert in
das Datenwort eingesetzt wird. Die Werte 2.5 GeV (10 LSBs) und 3.75 GeV (15 LSBs)
liegen im Bereichum
E
R
=3
:
75 GeV (15 LSBs) und werden mit kurzen Co des co diert.
Dann folgt ein Wert, der nicht mehr in liegt, das angefangene Datenwort wird mit dem
SkipRest-Token (b0000) b eendet und die Energie unver
andert in ein neues Datenwort
eingef
ugt.
Vor- und Nachteile
Beim Human-Inspired Co ding gibt es, im Gegensatz zum Human Co ding, feste Wort-
grenzen. Damit ist es fehlertoleranter. Weiterhin ist es nicht erforderlich einen Co debaum
1
Das f
uhrende b zeigt an, da die nachfolgende Zahl als Bin
arzahl dargestellt ist.
3.4. SPEZIELLE ALGORITHMEN
29
zur Rekonstruktion der Daten zu sp eichern.
Es ist jedo ch immer no ch ein Parameter, der Referenzwert
E
R
n
otig, um die Daten
vollst
andig zu deco dieren. Ist er verlorengegangen, ist eine Rekonstruktion zwar m
oglich,
jedo ch nur bis auf eine additive Konstante. Ein weiterer Nachteil ist die Anf
alligkeit ge-
gen
ub er Pedestalschwankungen (siehe 4.2). F
ur die 16 Kan
ale, die von einem RemASIC
ausgelesen werden k
onnen, l
at sich ein gemeinsamer Referenzwert
E
R
einstellen. Sind
die Pedestals der Kan
ale weit voneinander entfernt, o der ver
andern sie sichw
ahrend des
Betriebs, so wird das Human-Inspired Co ding keine guten Ergebnisse mehr liefern. Theo-
retischw
are es auchm
oglich gewesen,
E
R
f
ur jeden Kanal einzeln einzustellen, dies w
urde
jedo ch der Forderung nach einer m
oglichst einfachen Rekonstruktion der Ausgangsdaten
widersprechen.
3.4.2 Dierence Co ding
Das Dierence Co ding ist eine Weiterentwicklung des Human-Inspired Co ding. Es wer-
den nach denselb en Prinzipien Datenw
orter aus einem Header und mehreren kurzen Blo ck-
co des o der einem unver
anderten Energiewert gebildet. Bei ersterem Verfahren mute je-
do ch ein Referenzenergiewert
E
R
angegeb en werden, um den herum die Energiewerte mit
kurzen Co des liegen.
Prinzip
Die Nachteile des Human-Inspired Verfahrens werden b eim Dierence Co ding b eseitigt,
indem nicht die Dierenz des aktuellen Energiewertes zu einem Referenzwert
E
R
gebildet
wird. Statt dessen zieht man immer zwei aufeinanderfolgende Energiewerte voneinander
ab, und
ub ertr
agt diese Dierenz, wenn sie im Intervall liegt. Ansonsten wird die
aktuelle Energie
ub ertragen.
Beispiel
Es wird dasselb e Beispiel verwendet, wie f
ur das Human-Inspired Co ding. In Abbil-
dung 3.4 ist das Ergebnis zu sehen. W
ahrend das Human-Inspired Verfahren jedo ch
nur in einem b estimmten Bereich um die Referenzenergie
E
R
gute Ergebnisse liefert,
funktioniert das Dierence Co ding in jedem Energieb ereich, vorausgesetzt, da die auf-
einanderfolgenden Energiewerte nur nahe genug b eieinander liegen.
Vor- und Nachteile
Das Dierence Co ding ist das b este der im Rahmen dieser Arb eit untersuchten Verfah-
ren, wenn es darum geht Kalorimeterdaten ohne Pedestalsubtraktion und Energie-Cut zu
komprimieren. Es gibt feste Wortgrenzen, es ist unempndlich gegen
ub er Pedestalschwan-
kungen und liefert gute Kompressionsraten. Die Rekonstruktion der Ausgangsdaten ist
vollkommen ohne zus
atzliche Informationen m
oglich. Dadurch, da nicht ausschlielich
Dierenzen
ub ertragen werden, sondern nur wenn dies einen Platzvorteil bei der Co die-
rung b edeutet, mu nicht eine Verschiebung aller nachfolgenden Energiewerte bef
urchtet
30
KAPITEL 3. DATENKOMPRESSION
Datenwortlänge: 12 bit
Länge der kurzen Blockcodes: 4 bit
Länge eines unveränderten Wertes: 10 bit
Datensatz: 3-10-15-4
MSB
00
LSB MSB LSB MSB LSB
0
0000000011 0000000100 1
1 0101 0111
0000
Datenwort 1: 3
15-10=5 -> 0101
10-3=7 –> 0111
Datenwort 2: 7-5-SkipRest Datenwort 3: 4
Header Header Header
Zwei unbenutzte bits Zwei unbenutzte bits
00
Abbildung 3.4: Dierence Co ding f
ur einen Beispieldatensatz
werden, falls ein
Ub ertragungsfehler auftritt. Lediglich die Folge der dierenzco dierten
Werte, in der der
Ub ertragungsfehler aufgetreten ist, ist davon b etroen.
3.5 Software zur Datenkompression
Auch die Kompressionssoftware
XCompress
wurde in C++ entwickelt. Im Gegensatz zu
DATASIM wurde sie no ch mit einer graphischen Benutzerob er
ache versehen. Hierzu
wurde die Qt Klassenbibliothek von Troll Tech verwendet, die f
ur die Entwicklung nicht
kommerzieller Software frei erh
altlich ist [20 ]. Bei den
Ub erlegungen zum Design der
Software standen folgende Punkte im Vordergrund:
Bereitstellung der Routinen zur Kompression und Dekompression
Einstellbarkeit von m
oglichst vielen Parametern f
ur die Simulation
Lesen und Schreib en von Daten in m
oglichst vielen Formaten
Einfache Bedienung und Fehlertoleranz
Die Kompressionssoftware wurde nichtnur f
ur einen Test der verschiedenen Algorithmen
konzipiert, sondern sie soll auchf
ur die Dekompression von Datens
atzen verwendet werden,
die mit Hilfe des RemASIC erzeugt wurden.
Der Aufbau der Software ist in Abbildung 3.5 zu sehen. Die Benutzerob er
ache (Ab-
bildung 3.6) dient zum Einstellen der Parameter f
ur die Kompressionsalgorithmen. In
der Zwischenschicht erfolgt der Aufruf der gew
unschten Routinen mit den entsprechenden
Parametern. Sie b enutzt zwar den Signal/Slot Mechanismus von Qt
2
(siehe [20 ]), ist ab er
2
Verfahren zur Reaktion auf Ereignisse in der Benutzerober
ache
3.5. SOFTWARE ZUR DATENKOMPRESSION
31
Zwischenschicht
Eigene Widgets
Grafische Benutzeroberfläche
Qt Klassenbibliothek
Kompressionsroutinen
File I/O
C++ Stream Klassen
Bitout Klasse Bitin Klasse
X-Windows-System
Abbildung 3.5: Aufbau der Kompressionssoftware
ansonsten so ausgelegt, da sie mit leichten Mo dikationen auch ohne Qt mit einer tex-
torientierten Schnittstelle eingesetzt werden kann. Die Kompressionsroutinen benutzen
ihrerseits Ob jekte der Klassen
Bitin
und
Bitout
als Schnittstelle zu den Standard Ein-
und Ausgab eklassen von C++.
Ohne auf weitere Implementationsdetails eingehen zu wollen, soll im folgenden eine
Ub ersicht
ub er die erreichte Funktionalit
at gegeb en werden
3.5.1 Ein- und Ausgab e
Um Datenkompression b etreib en zu k
onnen, wird eine M
oglichkeit zum Schreib en und
Lesen einzelner bits o der Bitfolgen ben
otigt. Es wurde eine Schnittstelle f
ur die Benut-
zung solcher
Bitstreams
zur Verf
ugung gestellt, die sich in der Handhabung an die Stan-
dard C++-Streams anlehnt [21 ]. Der Benutzer kann zwischen verschiedenen Formaten
(bin
are Darstellung, Dezimalzahlen o der Hexadezimalzahlen variabler L
ange) ausw
ahlen.
Im Bin
arformat wird ein File direkt als Folge von Nullen und Einsen interpretiert. In die-
sem Mo dus k
onnen zum Beispiel Textles b earb eitet werden. Im Dezimalzahlen-Mo dus
werden Files verarb eitet, die aus einer Folge von Dezimalzahlen b estehen. Die einzelnen
Zahlen werden durch Leerzeichen voneinander getrennt. Intern werden diese Zahlen dann
in Bin
arzahlen umgewandelt, deren L
ange der Benutzer angeb en kann. Hiermit lassen
sich zum Beispiel Files verarb eiten, die eine Folge von Energiewerten in Zahlendarstellung
b einhalten. Der Hexadezimalzahlen-Mo dus ist
aquivalent zum Dezimalzahlen-Mo dus, mit
dem Unterschied, da die Zahlen in hexadezimaler Darstellung erwartet werden.
3.5.2 Erzeugung von Co deb
aumen
Co deb
aume lassen sich auf verschiedene Arten erzeugen, zum einen rekursiv von der Wur-
zel bis zu den Bl
attern (Top Down) o der, angefangen mit einem Blatt, durch immer neues
32
KAPITEL 3. DATENKOMPRESSION
Abbildung 3.6: Benutzerob er
ache der Kompressionssoftware
Zusammenf
ugen von Bl
attern zu Knoten bis hin zur Wurzel (Bottom Up). Das Top Down
Verfahren wird zur Rekonstruktion des Baumes im Sp eicher aus einem File verwendet,
w
ahrend das Bottom Up Verfahren zur Konstruktion eines neuen Co debaumes aus einer
Tab elle b en
otigt wird. Diese Tab elle kann entweder als File zur Verf
ugung stehen und ein-
gelesen werden, o der sie wird durchZ
ahlen der einzelnen Zeichen im zu komprimierenden
File erstellt.
Es stehen somit drei M
oglichkeiten zur Verf
ugung einen Co debaum zu erzeugen. Er
kann direkt aus der H
augkeitsverteilung der Zeichen im zu komprimierenden File erzeugt
werden. Der Co debaum ist dann optimal an den zu komprimierenden Datensatz angepat.
Eine andere M
oglichkeit b esteht darin, den Baum aus einer vorhandenen Tab elle mit den
H
augkeiten der einzelnen Zeichen zu erstellen, o der ab er einen b ereits erzeugten und
gesp eicherten Baum direkt in den Sp eicher einzulesen.
3.5.3 Abschneiden von Co deb
aumen
Beim Human Verfahren l
at sich im Gegensatz zu den
ublichen Kompressionsprogram-
men die maximale Anzahl der bits f
ur ein Co dewort einstellen. Hat man einen b estimmten
Datensatz gegeb en, so erzeugt der Human Algorithmus einen Co debaum, bei dem das
unwahrscheinlichste Zeichen unter Umst
anden mit sehr vielen bits co diert wird. Es ist
3.5. SOFTWARE ZUR DATENKOMPRESSION
33
nun w
unschenswert (siehe 4.2) die maximale L
ange der Human Co des zu limitieren. Da
der Human Co de ein optimaler Co de ist in dem Sinne, da die mittlere Co dewortl
ange
minimal ist (siehe A.2.2), wird sofort klar, da diese Limitierung mit einer wachsenden
mittleren Co dewortl
ange erkauft wird.
Realisiert wurde das Abschneiden
ub er eine
Anderung der Wahrscheinlichkeiten in der
Zeichenliste (Abschnitt 3.3.1). Zun
achst wird der Baum mit der unver
anderten Liste gebil-
det. Ist er zu lang, so werden die Wahrscheinlichkeiten der hinteren, unwahrscheinlicheren
H
alfte alle gleichgesetzt. Dadurch wird erreicht, da in diesem Teil die Co dewortl
ange mi-
nimal wird (siehe Anhang A). Nun wird erneut der Co debaum gebildet und seine L
ange
ermittelt. Ist der Baum immer no ch zu lang, so werden die Wahrscheinlichkeiten der un-
teren H
alfte des unver
anderten Teils der Liste gleichgesetzt. Ist er zu kurz, so wird nur
no ch das untere viertel der gesamten Liste auf dieselb e Wahrscheinlichkeit gesetzt. Es
wird also
ub er einen Intervallteilungsalgorithmus die Stelle in der Liste gesucht, ab der die
restlichen Wahrscheinlichkeiten gleichgesetzt werden m
ussen, um die gew
unschte L
ange
zu erreichen.
Das Ergebnis, das man mit dieser Metho de erzielt ist nicht unb edingt die Variante,
die die minimale mittlere Co dewortl
ange b ei gegeb ener maximaler Baumgr
oe liefert. Da
ein Abschneiden des Co debaumes b ei der Auslese des Level-1 Triggers mit dem RemASIC
selten notwendig sein wird (siehe Kapitel 4.2.1), ist es auch nichtn
otig, diesen Algorithmus
entsprechend zu optimieren.
Kapitel 4
Ergebnisse der Simulationen
In diesem Kapitel werden die Ergebnisse der Simulationen vorgestellt und diskutiert, die
mit DATASIM und XCompress erhalten wurden. Es werden zwei verschiedene Typ en
von Simulationen b ehandelt. Zum einen wird die Entropie der simulierten Datens
atze in
Abh
angigkeit von verschiedenen Parametern untersucht, zum anderen die G
ute der ver-
schiedenen Kompressionsalgorithmen f
ur typische Energieverteilungen. Als Ausgangsbasis
f
ur die Parametervariation werden die in Tab elle 4.1 zusammengestellten Grundeinstellun-
gen verwendet. Es werden also pro Eventf
unf Bunch Crossings ausgelesen, von denen das
dritte genau im Pulsmaximum liegt. Die Form der Shapingkurve wird so gew
ahlt (sie-
he 2.1.2), da das Rauschen minimal wird. In den folgenden Diskussionen werden nur
Parameter angegeb en, die von diesen Standardwerten abweichen.
4.1 Entropie der Daten
Eine erste Untersuchung widmete sich der Entropie der Kalorimeterdaten. Hierzu wur-
den mit der Datensatzsimulation
DATASIM
Datens
atze mit bis zu 10
5
Events erzeugt
und verschiedene Parameter variiert. Anschlieend wurden mit der Kompressionssoftware
die H
augkeiten der Energiewerte gez
ahlt und daraus die Entropie in diesem Datensatz
b estimmt.
4.1.1 Die Energieverteilung
In Anhang A wird gezeigt, da die Entropie eines Datensatzes b estimmt wird durch
die Wahrscheinlichkeitsverteilung der Zeichen. Es ist daher nicht verwunderlich, da die
Entropie von der Wahl des Exp onenten der Verteilung und des Bin0/Rest-Ratio abh
angig
ist. Je gr
oer die Exp onenten werden, desto steiler wird die Energieverteilung. Sehr
wenige kleine Energien werden also immer wahrscheinlicher, die Entropie sinkt. Abbil-
dung 4.1 zeigt den Verlauf der Entropie von
H
=6
:
6 bit f
ur einen Exp onenten von 1.25
bis zu
H
= 3
:
6 bit bei einem Exp onenten von 5 f
ur den Fall, da nur Energien gr
oer
1 GeV auftreten (Bin0/Rest-Ratio = 0). Variiert man den Exp onenten dagegen bei ei-
nem Bin0/Rest-Ratio von 9, so bleibt die Entropie nahezu konstant. Die Zahl der leeren
(E = 0 GeV ) Zellen nimmt mit steigendem Bin0/Rest-Ratio zu. Die Energieverteilung und
34
4.1. ENTROPIE DER DATEN
35
Simulation von mit Parameter
Energieb ereich 0 GeV-255 GeV
Potenzfunktion Exp onent = 1.8
Energiedep osition
Bin0/Rest-Ratio Bin0/Rest = 9
<x>
= 0 GeV
Rauschen Gauverteilung
=0
:
5 GeV
=15
Shaping
f
(
; t
dr
;
)
t
dr
= 400 ns
siehe Anhang C
=2
Bunch Crossings pro Event 5
Sampling
Sample im Pulsmaximum 3. Sample
Pedestal
E
=
E
+
Ped Ped
=1
:
5 GeV
Tab elle 4.1: Grundeinstellungen f
ur die Simulation
damit auch die Entropie wird also mehr und mehr unabh
angig von der Potenzfunktion
und ihrem Exp onenten.
Die Abbildungen 4.2 und 4.3 zeigen den Verlauf der Entropie mit steigendem Bin0/Rest-
Ratio f
ur 8 und 10 bit. Im Grenzfall Bin0/Rest-Ratio
!1
gibt es nur no ch einen einzigen
Energiewert, E = 0 GeV. Das heit die Entropie wird nur no ch b estimmt durch das De-
tektorrauschen.
4.1.2 Entropie und Pedestal
Durch eine Variation des Pedestals l
at sich die Energieverteilung im Fenster
1
des FADC
hin und herschieb en. Wird das Pedestal erh
oht, so wird der relativ unwahrscheinliche
Schwanz abgeschnitten (siehe Abbildung 4.5), wird es erniedrigt, so schneidet man die
Kurve nahe am Maximum ab (Abbildung 4.4). Man erwartet also, da sich die Entropie
mit wachsendem Pedestal solange erh
oht, bis das gesamte Maximum im Arb eitsb ereich
des FADC liegt. Sie sollte dann f
ur l
angere Zeit einen konstanten Wert einnehmen, bis
zuviel vom Schwanz abgeschnitten wurde und die Entropie wieder sinkt. Der Anstieg
der Entropie mit wachsendem Pedestal ist in den Abbildungen 4.6 und 4.7 f
ur 8 und 10
bit Werte zu sehen. Das Pedestal wurde nicht gen
ugend erh
oht, um auch den Abfall b ei
h
oheren Werten zu b eobachten. Es sei an dieser Stelle explizit darauf hingewiesen, da
der Anstieg der Entropie bis zu einem Pedestal von 1.5 GeV daher r
uhrt, da b ei einem
niedrigeren Pedestal ein Teil des Rauschens abgeschnitten wird. Man f
uhrt faktisch einen
Energie-Cut durch, der allerdings nur das Rauschen abschneidet, da b ei
= 0 GeV, also
ohne Rauschen, keine Energien auftauchen, die kleiner sind als das Pedestal. In Abbildung
4.6 ist eine Schwankung der Entropie mit Maximum bei halbzahligen und Minimum b ei
ganzzahligen Pedestalwerten zu b eobachten. Ihre Ursache wird im n
achsten Abschnitt
erkl
art. 4.7).
1
Bereich in dem der FADC arb eitet (0-255 GeV).
36
KAPITEL 4. ERGEBNISSE DER SIMULATIONEN
0
1
2
3
4
5
6
7
1.5 2 2.5 3 3.5 4 4.5 5
fp1
Entropy (bits)
Abbildung 4.1: Entropie vs Exp onentf
ur 10 bit und Bin0/Rest-Ratio = 0
Entropy vs Bin0/Rest-Ratio
0
0.5
1
1.5
2
2.5
3
3.5
0 102030405060708090100
Abbildung 4.2: Entropie vs Bin0/Rest-
Ratio b ei 8bit
Entropy vs Bin0/Rest-Ratio
0
1
2
3
4
5
0 102030405060708090100
Abbildung 4.3: Entropie vs Bin0/Rest-
Ratio b ei 10bit
4.1. ENTROPIE DER DATEN
37
Number of Events vs Energy(GeV)
10
2
10
3
10
4
10
5
0246810
Maximum der Energieverteilung
Schwanz
Dieser Teil der Verteilung wird bei einem
Pedestal von 0 GeV abgeschnitten
Unwahrscheinlicher
Abbildung 4.4: Energieverteilung bei ei-
nem Pedestal von 1.5 GeV
Number of Events vs Energy(GeV)
10
10 2
10 3
10 4
10 5
0246810
Abbildung 4.5: Energieverteilung bei ei-
nem Pedestal von 5.0 GeV
Entropy vs Pedestal
0
0.2
0.4
0.6
0.8
1
1.2
1.4
1.6
1.8
0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5
Abbildung 4.6: Entropie vs Pedestal bei
8bit
Entropy vs Pedestal
0
0.5
1
1.5
2
2.5
3
3.5
0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5
Abbildung 4.7: Entropie vs Pedestal bei
10bit
38
KAPITEL 4. ERGEBNISSE DER SIMULATIONEN
# Samples # Sample im Maximum Entropie (bits)
5 3 3.42
3 2 3.54
1 1 3.19
Tab elle 4.2: Entropie und Anzahl der Samples auf der Shapingkurvef
ur 10 bit
4.1.3 Entropie und Energieau
osung
Vergleicht man Abbildung 4.2 mit 4.3 o der 4.6 mit 4.7, so f
allt auf, da die Entropie b eim
Ub ergang von 8 bit auf 10 bit Au
osung eb enfalls um fast 2 bit zunimmt. Diese Zunah-
me ist praktisch ausschlielich auf das vorhandene Rauschen zur
uckzuf
uhren. Bestimmt
man n
amlich die Entropie der Energieverteilung ohne Rauschen (
= 0 GeV ) f
ur 8 bit
und 10 bit Au
osung so ergibt sich eine Zunahme der Entropie um lediglich0
:
3 bit. Das
b edeutet, da b eim
Ub ergang von 8 bit auf 10 bit b einahe keine physikalisch wichtige In-
formation dazugewonnen, sondern haupts
achlich das elektronisches und Pile-Up Rauschen
digitalisiert wird.
Bei der Digitalisierung treten Rundungsfehler auf. Sie liegen in einem Bereich von
0
:
5 LSBs. Bei einer Au
osung von 8 bit entspricht dies gerade der Breite der Gauver-
teilung f
ur das Rauschen. Die Digitalisierung wird mo delliert durch Aufrunden, falls die
Dierenz zum n
achstgr
oeren Wert kleiner o der gleich einem halb en LSB ist, ansonsten
wird abgerundet. Liegt also bei 8 bit Au
osung das Maximum der Gauverteilung bei
einem halbzahligen Wert, ergeb en sich b ei der Digitalisierung in der N
ahe des Maximums
zwei Werte, einer links vom Maximum, einer rechts davon. Liegt das Maximum hingegen
b ei einem ganzzahligen Wert, so wird nur ein Wert digitalisiert. Dieser Eekt verschwindet
b ei 10 bit Au
osung. Zu b eobachten ist die dadurchverursachte Schwankung der Entropie
b ei 8 bit in Abbildung 4.6.
4.1.4 Anzahl der Samples
F
ur die
Anderung der Entropie mit der Zahl der ausgelesenen Bunch-Crossings gibt es
keine einheitliche Tendenz. Es ist jedo ch oensichtlich, da die Entropie mit der Anzahl
der Samples in der N
ahe des Maximums zunimmt. Werden jedo ch viele Werte hinter dem
Peak, also im achen Unterschwinger digitalisiert, so nimmt die Entropie ab. Die St
arke
der
Anderung h
angt auerdem von der Steilheit der Energieverteilung ab.Verwendet man
die Parameter aus Tab elle 4.1, so spielt sie keine wesentliche Rolle. Tab elle 4.2 zeigt ein
paar Beispielwerte.
4.2 Kompressionsfaktoren
Die bisher vorgestellten Ergebnisse gab en einen
Ub erblick
ub er den Informationsgehalt
der Kalorimeterdaten. In diesem Abschnitt wird die G
ute der Kompressionsalgorithmen
getestet. Hierzu wurden zun
achst verschiedene Datens
atze mit
DATASIM
erzeugt und an-
schlieend mit der Kompressionssoftware komprimiert. Als Ma f
ur die Leistungsf
ahigkeit
4.2. KOMPRESSIONSFAKTOREN
39
der Algorithmen wird im folgenden der Kompressionsfaktor b enutzt.
CF
=
Bytes vor der Kompression
Bytes nach der Kompression
:
(4.1)
Da zu jedem File eine Angab e
ub er seine L
ange existiert, ist er sehr einfach zu b estim-
men. Beim Human Co ding kann etwas anders vorgegangen werden, da hier die mittlere
Wortl
ange
l
f
ur diesen Datensatz einfach zu b estimmen ist. Da jedem Zeichen genau ein
Co dewort zugeordnet wird, ergibt sichf
ur das Human Co ding mit
CF
=
Energieau
osung (bits)
l
(bits)
;
nur f
ur Human Co ding (4.2)
derselb e Wert f
ur
CF
, wie in Gleichung 4.1.
F
ur die Diskussion und Darstellung der Ergebnisse werden h
aug Begrie und Abk
ur-
zungen verwendet, die in Anhang A und Kapitel 3 genauer erl
autert sind. Der
Ub ersicht
halb er wurden sie in Tab elle 4.3 no cheinmal zusammengestellt.
DW Data Word: Ein Datenwort
ZM Zero Message: kurzer Blo ckco de
RLM Run-Length Message: L
ange einer Folge von gleichen Energien
NM Normal Message: unver
anderter Energiewert
E
R
Referenzenergie
Bereich kurzer Co des um die Referenzenergie
H
(
S
) Entropie eines Ensembles von Zeichen
l
mittlere Co dewortl
ange
Tab elle 4.3: Abk
urzungen f
ur nullunterdr
uckende Algorithmen
4.2.1 Human Co ding
F
ur die Realisation eines Humanco ders wird eine Co detab elle ben
otigt. Diese wurde
auf dem RemASIC als Lo ok-Up Table realisiert. Das b edeutet, die Human Co des sind
in einem RAM
2
gesp eichert und werden, durch Anlegen des zu co dierenden Zeichens als
Adresse, ausgelesen (genaueres siehe 5.2). Die Human Co des sind also in ihrer L
ange
limitiert auf die Breite der LUT. Macht man die LUT zu klein, mu der Co debaum unter
Umst
anden abgeschnitten werden (siehe Abschnitt 3.5). Damit sinkt jedo ch die G
ute der
Kompression. Wird die LUT andererseits gr
oer als b en
otigt, verschwendet man unn
otig
Platz auf dem RemASIC und steigert die Pro duktionskosten.
Eine erste Untersuchung widmete sich daher der L
ange der Human Co des f
ur typische
Energieverteilungen. Auerdem war von Interesse, wie sich
l
und damit
CF
andert, wenn
die L
ange der Human Co des auf einen Wert
l
max
limitiert wird. Die Ergebnisse sind
in Tab elle 4.4 zu sehen. Sie wurden f
ur einen Datensatz erhalten, der nur einen Kanal
mit einem Pedestal von 1.5 GeV und 10 bit Au
osung simuliert. Der l
angste Human
2
R
andom Access Memory: Sp eicher mit wahlfreiem Zugri
40
KAPITEL 4. ERGEBNISSE DER SIMULATIONEN
Co de hat, wenn der Co debaum nicht abgeschnitten wird, eine L
ange von 19 bits. Der
Anstieg von
l
mit abnehmendem
l
max
verwundert nicht. Erstaunlich ist hingegen auf den
ersten Blick der Sprung von
l
auf 10 bit b ei
l
max
= 10 bits. Der Grund daf
ur wird jedo ch
sofort klar, wenn man b edenkt, da die Au
osung der Energie in der Simulation 10 bit
b etr
agt. Erlaubt man keine Co dew
orter, die l
anger sind als 10 bit, so mu zwangsl
aug
jedes Co dewort 10 bit lang sein, wenn keine Information verloren gehen soll.
l
max
(bits) 10 11 12 13 14 15 16 17 18 19
l
(bits) 10 5.72 4.98 4.20 3.76 3.60 3.55 3.53 3.52 3.51
CF 1.0 1.7 2.0 2.4 2.7 2.8 2.8 2.8 2.8 2.9
H
(
S
) (bits) 3.47
Tab elle 4.4: Abschneiden des Co debaumes
Bei einem Datensatz, der 8 Kan
ale mit Pedestals von 1 GeV bis 3 GeV enth
alt,
andert
sich lediglich die minimal erreichbare mittlere Co dewortl
ange
l
. F
ur die Darstellung des
l
angsten Human Co des werden auch hier 19 bits ben
otigt. Die LUT auf dem RemA-
SIC sollte also gro genug sein, um 19 bit Co des aufnehmen zu k
onnen. Um
ub er eine
gewisse Sicherheitsreservezu verf
ugen, wurde eine LUT realisiert, die 23 bit lange Co des
aufnehmen kann (siehe Kapitel 5.4.1).
Aus Tab elle 4.4 kann man auerdem entnehmen, da die Entropie
H
(
S
) des Daten-
satzes und
l
sehr nahe b eieinander liegen, falls der Co debaum nicht abgeschnitten wird
(Tab elle 4.4 b ei
l
max
= 19 bits). In der Tat sollte man dieses Verhalten auch erwarten, da
der Co debaum direkt aus den H
augkeiten der Energiewerte im Datensatz gebildet wurde.
In der Realit
at passiert das nat
urlich nicht. Der Co debaum wird vielmehr einmal aufgrund
einer m
oglichst genauen Energieverteilung festgelegt, und dann auf s
amtliche auszulesende
Daten angewandt. Das b edeutet jedo ch, da die Kompression umso schlechter wird, je
weniger die Wahrscheinlichkeitsverteilung der Daten in einem b estimmten Zeitraum der
angenommenen Energieverteilung entspricht.
F
ur den Betrieb der Kompressionseinheit b ei der Detektorauslese ist es nat
urlichinter-
essant zu untersuchen, wie sich der Kompressionsfaktor quantitativ verschlechtert, wenn
die Energieverteilung eines Datensatzes nicht der Verteilung entspricht, mit der der Co-
debaum konstruiert wurde. Hierzu wurde zun
achst ein Datensatz mit einem Pedestal von
P
= 0 GeV erzeugt und gettet (Abbildung 4.8). Dieser Fit ist notwendig, da ein von der
Simulation erzeugter Datensatz nicht unb edingt jeden m
oglichen Energiewert enthalten
mu. W
urde man den Co debaum einfach durch Z
ahlen der H
augkeiten der einzelnen
Energien in diesem Datensatz erzeugen, so g
ab e es nicht zu jedem Energiewert einen Hu-
man Co de.
Aus der getteten Verteilung wurde eine Tab elle mit den H
augkeiten aller vorkom-
menden Energien erzeugt, aus der dann schlielich der Co debaum erhalten wurde. Kom-
primiert man mit dem Baum f
ur
P
= 0 GeV einen Datensatz mit
P
=1
:
5 GeV, so sinkt
der Kompressionsfaktor auf 1.5 (Tab elle 4.5). Auch eine Verteilung mit einem Pedestal
von 5 GeV wurde auf diese Weise komprimiert. Der Kompressionsfaktor liegt nun nahe
b ei eins. Es ist jedo ch b emerkenswert, da selbst b ei dieser Verschiebung no chkeine Auf-
4.2. KOMPRESSIONSFAKTOREN
41
Number of Events vs Energy(GeV)
1
10
10 2
10 3
10 4
10 5
0 50 100 150 200 250
Abbildung 4.8: Energieverteilung und Fit f
ur
P
= 0 GeV und 10 bit Au
osung
bl
ahung b ei der Co dierung auftritt. Ein vielfachge
auertes Argument gegen die Human
Co dierung war die Bef
urchtung, da sich schon bei kleinen Pedestalschwankungen der
Co de stark aufbl
ahen k
onnte, was ganz oensichtlich nicht der Fall ist.
Baum f
ur
P
= 0 GeV
Pedestal (GeV) 0 1.5 5
Entropie (bits) 2.25 3.47 3.47
l
2.36 6.36 9.33
CF 4.24 1.51 1.07
Tab elle 4.5: Kompression mit falschem Co debaum
Der Kompressionsfaktor wurde auerdem b estimmtf
ur eine Verteilung mit einem Pe-
destal von 0 GeV und verschiedenen Energie-Cuts. Diese Untersuchung ist interessant,
um die Leistungsf
ahigkeit von Run-Length Enco ding und Human Co ding vergleichen
zu k
onnen (siehe dort). In Tab elle 4.6 sind die Ergebnisse zusammengestellt. Auf dem
RemASIC werden die Daten aus bis zu 16 Kan
alen komprimiert. Jeder dieser Kan
ale
hat ein separat einstellbares Pedestal, so da eine Energieverteilung f
ur nur einen Kanal
mit konstantem Pedestal zu gute Werte f
ur
CF
liefert. Eine realistische Absch
atzung des
Kompressionsfaktors gibt eine Verteilung f
ur acht Kan
ale mit Pedestals zwischen 1 GeV
und 3 GeV. Man erreicht damit einen Kompressionsfaktor von 2.5 bei 10 bit Au
osung.
Dieser Wert w
urde auch ausreichen, um alle Level-1 Daten auszulesen (siehe 1.2).
42
KAPITEL 4. ERGEBNISSE DER SIMULATIONEN
Energie-Cut (GeV) CF
0 4.4
1 7.6
2 8.4
4 9.0
Tab elle 4.6: Kompression mit Energie-Cut
S
amtliche Untersuchungen zum Human Co ding wurden f
ur 10 bit Energiewerte durch-
gef
uhrt. Wie b ereits erl
autert (4.1) erh
oht sich b eim
Ub ergang von 8 bit auf 10 bit die
Entropie um fast 2 bit. Der Kompressionsfaktor wird also bei 8 bit Daten um einiges
b esser.
4.2.2 Run-Length Enco ding
Wie b ereits b ei der Diskussion der Kompressionsalgorithmen (Kapitel 3) erw
ahnt, eignet
sich das Run-Length Enco ding b esonders f
ur Datens
atze, b ei denen oft hintereinander die
Null
ub ertragen wird. F
ur Datens
atze ohne Energie-Cut sollte daher der Kompressions-
faktor nahe b ei eins o der sogar kleiner sein, was eine Aufbl
ahung statt eine Kompression
der Daten b edeuten w
urde. Deswegen wurde f
ur Daten ohne Energie-Cut zun
achst die
Leistungsf
ahigkeit eines mo dizierten Run-Length Enco dings untersucht. Dab ei wurde
angenommen, da b ereits eine Pedestalsubtraktion stattgefunden hat, ohne die das Run-
Length Enco ding in der auf dem RemASIC realisierten Variante nutzlos ist.
Wird kein Energie-Cut angewandt, so sind die niedrigen Energiewerte von Rauschen
dominiert und die zusammenh
angenden Folgen mit
E
= 0
GeV
werden sehr kurz sein.
Man k
onnte sich nun vorstellen die Lau
ange anstatt als 8 bit o der 10 bit Zahl einfach
mit entsprechend weniger bits zu ko dieren. Auf diese Weise l
at sich selbst f
ur kurze
Nullfolgen eine Kompression erreichen. F
ur l
angere Folgen mu dann unter Umst
anden
mehrmals hintereinander eine Null und die Lau
ange
ub ertragen werden. Die Ergebnisse
der Simulation sind in Tab elle 4.7 zu sehen. Die Wortl
ange f
ur den Lau
angenz
ahler
l
RLM
wurde solange erh
oht, bis der Kompressionsfaktor wieder kleiner wird, so da die optimale
L
ange b estimmtwerden konnte. Bei einer Au
osung von 8 bits b etr
agt sie 4 bit und liegt
damit h
oher als b ei einer Au
osung von 10 bit, wo das Optimum b ei 3 bit liegt. Dies ist
mit dem geringeren Einu des Rauschens auf die Energiewerte b ei niedrigerer Au
osung
zu erkl
aren.
Da die Kompressionsfaktoren nicht b esonders gut sind, und vor allem da keine festen
Wortgrenzen existieren, wurde diese M
oglichkeit der Co dierung verworfen. Tritt zum Bei-
spiel b ei der
Ub ertragung einer Null ein Fehler auf, so wird das nachfolgende Wort als nor-
male Energie interpretiert und der gesamte restliche Datensatz wird falsch rekonstruiert.
Dieses Problem gibt es b eim urspr
unglichen Run-Length Enco ding, b ei dem die Lau
ange
mit der gleichen Anzahl an bits co diert wird, wie die Energiewerte (
l
RLM
=
l
NM
), nicht.
Es wurde daher genauer untersucht und auf dem RemASIC implementiert. In Tab elle
4.8 sind die erreichbaren Kompressionsfaktoren f
ur verschiedene Energie-Cuts dargestellt.
Auch hier wurde angenommen, da eine Pedestalsubtraktion stattgefunden hat.
4.2. KOMPRESSIONSFAKTOREN
43
Au
osung (bits)
l
RLM
(bits) CF
10 2 1.27
10 3 1.33
10 4 1.30
8 2 1.64
8 3 2.12
8 4 2.29
8 5 2.18
Tab elle 4.7: Run-Length Enco ding mit kurzen Co des f
ur die Lau
ange
Au
osung (bits) Energie-Cut (GeV) CF
10 0 1
10 1 8
10 2 18
10 4 34
8 0 2
8 1 13
8 2 27
8 4 33
Tab elle 4.8: Run-Length Enco ding b ei verschiedenen Energie-Cuts
Vergleicht man diese Werte mit denen aus Tab elle 4.6 f
ur das Human Co ding, so
zeigt sich die klare
Ub erlegenheit des Run-Length Enco ding f
ur diese Art von Daten. Die
erreichbaren Kompressionsfaktoren sind unschlagbar. Es mu jedo ch no cheinmal b etont
werden, da dieses Verfahren nur f
ur Daten nach Pedestalsubtraktion und mit einem
Energie-Cut von mindestens 1 GeV sinnvoll ist. Unter diesen Voraussetzungen ist es
allerdings das Mittel der Wahl.
4.2.3 Human-Inspired und Dierence Co ding
In Kapitel 3 wurde erkl
art, da Human-Inspired und Dierence Co ding auf demselb en
Prinzip b eruhen. Beim Human-Inspired Co ding wird die Dierenz zwischen dem aktu-
ellen Energiewert und einem festen Referenzwert
E
R
b etrachtet. Das Dierence Co ding
benutzt die Dierenz zweier aufeinanderfolgender Energiewerte. Aufgrund der
Ahnlichkeit
der b eiden Algorithmen, sind auch die Untersuchungen b einahe identisch und werden da-
her zusammen diskutiert.
Zun
achst einmal wird man daran denken, Datenw
orter mit einer L
ange von
l
DW
= 8 bit
o der
l
DW
= 10 bit zu verwenden und nach der optimalen L
ange der kurzen Blo ckco des
l
ZM
zu suchen. Damit ist die L
ange der Datenw
orter an die L
ange der
Normal Messages
angepat und es wird b ei der
Ub ertragung eines unver
anderten Energiewertes kein Platz
44
KAPITEL 4. ERGEBNISSE DER SIMULATIONEN
verschenkt. Benutzt man jedo ch b ei einer Datenwortl
ange von 10 bit Blo ckco des mit einer
L
ange von b eispielsweise 3 bit, so verschenkt man b ei der
Ub ertragung der Blo ckco des mit
jedem Datenwort 1 bit Platz. Um die optimalen Parameter f
ur die Co dierung zu nden,
m
ussen daher sowohl
l
DW
, als auch
l
ZM
variiert werden.
Die Ergebnisse der Variation von
l
ZM
und
l
DW
sind in Tab elle 4.9 f
ur das Dierence
Co ding mit 10 bit dargestellt. Die Tab elle 4.10 f
ur 8 bit Energiewerte wurde nur der
Vollst
andigkeit halb er angef
uhrt. Da auf dem RemASIC Human-Inspired und Dierence
Co ding nur f
ur 10 bit durchgef
uhrt wird, widmet sich die Diskussion der Kompressionsfak-
toren ausschlielich den Ergebnissen f
ur 10 bit. Man sieht, da der Kompressionsfaktor
bei einer Datenwortl
ange von 12 bit und einer L
ange der kurzen Co des von 4 bit am
b esten ist. Diese Werte wurden mit einem festen Pedestal von 1.5 GeV ermittelt. F
ur
das Human-Inspired Co ding erh
alt man dieselb en Ergebnisse. Allerdings ist dab ei zu
b eachten, da die Kompression nur solange gut ist, wie Referenzenergie
E
R
und Pedestal
m
oglichst genau
ub ereinstimmen. Bei der Verwendung von 12 bit Datenw
ortern werden
keine bits verschenkt, wenn mit kurzen Co des co diert wird, da gerade drei der 4 bit Co des
in ein 12 bit Wort passen. Andererseits bl
aht man den Co de um 2 bits pro Datenwort auf,
falls Energiewerte unver
andert
ub ertragen werden.
l
DW
(bits)
l
ZM
(bits) CF
10 2 1.1
10 3 1.6
10 4 1.7
10 5 1.8
12 3 1.5
12 4 2.0
12 5 1.8
Tab elle 4.9: CF in Abh
angigkeit von Datenwortl
ange und L
ange der kurzen Co des f
ur
10 bit Daten
l
DW
(bits)
l
ZM
(bits) CF
8 2 2.7
8 3 1.7
8 4 1.8
9 3 2.3
10 2 2.6
Tab elle 4.10: CF in Abh
angigkeit von Datenwortl
ange und L
ange der kurzen Co des f
ur
8 bit Daten
Der Eekt einer Verschiebung von Pedestal und Referenzenergie ist in Tab elle 4.11
dargestellt. Schon bei einer Verschiebung um 2.5 GeV wird der Datensatz nicht mehr
komprimiert, sondern aufgebl
aht. In Abbildung 4.9 ist die verwendete Energieverteilung zu
4.2. KOMPRESSIONSFAKTOREN
45
sehen. Man kann sehr gut erkennen, da die Referenzenergie ziemlich genau im Maximum
der Verteilung liegen mu, um eine Kompression zu erreichen. Diese Probleme treten b eim
Dierence Co ding nicht auf, da es unabh
angig vom Pedestal ist.
Sowohl Dierence, als auch Human-Inspired Co ding wurden mit einem Datensatz,
der 8 Kan
ale mit Pedestals zwischen 1 GeV und 3 GeV enth
alt getestet. Er wurde auch
schon b eim Human Co ding verwendet. Man erzielt Kompressionsfaktoren von 2.0, was
no ch gen
ugen sollte, um den Trigger auszulesen (Tab elle 4.12).
E
R
(GeV)
j
P
,
E
R
j
(GeV) (GeV) CF
2.5 2.5 0.75 .. 4.25 0.78
4.5 0.5 3.75 .. 7.25 2.2
5.0 0.0 3.25 .. 6.75 2.1
5.5 0.5 4.. 7.5 2.2
7.5 2.5 5.75 .. 9.25 0.8
Tab elle 4.11: Kompressionsfaktor mit verschob ener Referenzenergie f
ur 10 bit Daten,
l
DW
= 12 und
l
ZM
=4
Pedestals (GeV) CF
Dierence 1.. 3 2.0
Human-Inspired 1.. 3 2.0
Tab elle 4.12: Kompressionsfaktoren f
ur Datensatz mit achtverschiedenen Pedestals
Um das Bild von der Leistungsf
ahigkeit abzurunden, wurde der
CF
f
ur das Die-
rence Co ding no ch in Abh
angigkeit vom Bin0/Rest-Ratio b estimmt. Je niedriger dieses
Verh
altnis wird, desto
ofter b endet sich die b etrachtete Kalorimeterzelle im Radius eines
Jets. In Tab elle 4.13 kann man erkennen, da der Kompressionsfaktor zwar abnimmt,
ab er selbst f
ur die dopp elte Anzahl von Jet-Ereignissen (Bin0/Rest-Ratio =5) no ch bei
2.0 liegt. Eine Aufbl
ahung des Datensatzes ist nichtzubef
urchten. Durchentsprechende
Anpassung von
l
DW
und
l
ZM
,l
at sich der Algorithmus optimal an verschiedene Energie-
verteilungen anpassen (letzte Zeile in Tab elle 4.13).
Bin0/Rest-Ratio
l
DW
(bits)
l
ZM
(bits) CF
0 12 4 1.3
5 12 4 2.0
9 12 4 2.1
0 10 5 1.6
Tab elle 4.13: CF in Abh
angigkeit vom Bin0/Rest-Ratio
Auch die Kompressionsfaktoren f
ur verschiedene Energie-Cuts wurden untersucht(Ta-
46
KAPITEL 4. ERGEBNISSE DER SIMULATIONEN
Number of Events vs Energy(GeV)
1
10
10 2
10 3
10 4
10 5
0 50 100 150 200 250
Abbildung 4.9: Energieverteilung zur Demonstration des Eektes der Pedestalverschie-
bung
b elle 4.14). Wie zu erwarten ergeb en sich nicht die sehr hohen Kompressionsfaktoren, wie
b eim Run-Length Enco ding. Das Dierence Co ding ist jedo ch, wie gezeigt wurde, unemp-
ndlich gegen
ub er Pedestalschwankungen. Auch eine Vergr
oerung der Anzahl getroener
Kalorimeterzellen verkraftet dieser Algorithmus recht gut. Auchunter schlechten Bedin-
gungen ist no ch ein Kompressionsfaktor von 2 erreichbar. Beim Human-Inspired Co ding
ist auf eine gute
Ub ereinstimmung von Referenzenergie und Maximum der Energievertei-
lung zu achten, da sonst eine Co deaufbl
ahung zu b ef
urchten ist. Auch b ei optimaler Lage
von
E
R
lassen sich mit dem Human-Inspired Co ding keine b esseren Resultate erzielen,
als mit dem Dierence Co ding.
Energie-Cut CF
0 2.1
1 2.1
2 2.1
4 2.2
Tab elle 4.14: CF in Abh
angigkeit vom Bin0/Rest-Ratio mit
l
DW
= 12 und
l
ZM
=4
4.2. KOMPRESSIONSFAKTOREN
47
4.2.4 Zusammenfassung
Die Leistungsf
ahigkeit der Kompressionsalgorithmen in Abh
angigkeit verschiedener Para-
meter wurde untersucht und diskutiert. Damit die F
ulle von Daten und Tab ellen nicht
den Blick auf das Wesentliche verstellt, sind in Tab elle 4.15 typische Kompressionsfaktoren
zusammengestellt. Es wurde gezeigt, da alle vorgestellten Algorithmen in der Lage sind
die Bandbreite bei der Auslese so weit zu verringern, da der komplette Level-1 Trigger
ub er den Pip elineBus ausgelesen werden kann.
Algorithmus Parameter typischer CF
Human 8Pedestal von1.. 3 GeV 2.5
Human Energie-Cut 1 GeV 7.6
Human Inspired
Dierence
8Pedestal von1.. 3 GeV 2
Human Inspired
Dierence
Energie-Cut 1 GeV 2
Run-Length Energie-Cut 1 GeV 13
Tab elle 4.15: Typische Kompressionsfaktoren f
ur 10 bit Daten
Die Hintereinanderschaltung verschiedener Algorithmen, wie zum Beispiel das Human
Co ding von Run-Length co dierten Daten, wurde nicht untersucht. Die Implementation
der Kompressionseinheit w
are damit um einiges aufwendiger geworden und h
atte den
eng gesteckten Zeitrahmen f
ur die Implementation gesprengt. Auerdem war eine solche
Dopp elco dierung nicht erw
unscht, da die Rekonstruktion der Ausgangsdaten aufwendiger
geworden w
are. F
ur ein nales System sollte jedo ch die M
oglichkeit des Human Co ding
von b ereits co dierten Datens
atzen in Betracht gezogen werden.
Kapitel 5
Die Kompressionseinheit
Wesentlicher Bestandteil der Diplomarb eit war die Implementation der getesteten Algo-
rithmen auf dem RemASIC. Der Aufbau der Kompressionseinheit und die dab ei verwende-
ten Metho den werden in diesem Kapitel erl
autert. Die Kompressionseinheit ist sehr stark
eingebunden in die Infrastruktur, die von FeASIC Interface und Pip elineBus Interface zur
Verf
ugung gestellt wird. Sie wird
ub er den Pip elineBus konguriert und verf
ugt
ub er keine
eigenen I/O-Pins
1
. Daher wird zun
achst der Aufbau des RemASICs vorgestellt, um dann
die Architektur der Kompressionseinheit im Detail diskutieren zu k
onnen.
5.1 Der RemASIC - ein
Ub erblick
5.1.1 Die Idee
Der Readout Merger ASIC wurde entwickelt, um folgende Funktionalit
at nach auen hin
zur Verf
ugung zu stellen:
Auslese und Konguration von bis zu 16 FeASICs
ub er 4 Anschl
usse (Ports)
Kompression der Daten mit verschiedenen Algorithmen
Pip elineBus Interface f
ur Konguration und Auslese.
Dar
ub er hinaus, sollte der Chip m
oglichst einfach zu testen sein. Es wurde daher b eschlos-
sen auf dem RemASIC drei Testm
oglichkeiten zu integrieren, n
amlich:
Ub erpr
ufung interner Signale
Unterbrechung der Auslese
Datenquelle zum Test ohne FeASIC
In Abbildung 5.1 ist ein Blo ckdiagramm des RemASIC zu sehen. Er ist in drei Funkti-
onsbl
ocke aufgeteilt, das FeASIC Interface, die Kompressionseinheit und das Pip elineBus
Interface. Die Bl
ocke sind in einer pip elineartigen Struktur angeordnet, wo durch sich eine
groe Flexibilit
at f
ur den Test ergibt.
1
Input-/Output-Pins, die Ein- und Ausgangsanschl
usse eines Chips
48
5.1. DER REMASIC - EIN
UBERBLICK
49
Interface
PipelineBus
Daten für die direkte Konfiguration der Speicher
Kontrollregister
Konfiguration
PipelineBus
-Huffman Inspired Token
Interpreter
Main Buffer
PipelineBus
PipelineBus
8/10 bit 8/10 bit 32 bit 32 bit 32 bit
FeASIC Ports
FeASIC Interface Kompressionseinheit
Daten
-NoOperation
-Huffman 8/10 bit
-Difference
-Runlength 8/10 bit
RAM0
RAM1
Encoder RAM
RAM0
RAM1
Event Buffer Pre-Main Buffer
Abbildung 5.1: Blo ckdiagramm des RemASIC
50
KAPITEL 5. DIE KOMPRESSIONSEINHEIT
Bunch-Crossing Nummer
Nummer des FeASIC Ports
Daisy Chain Position
Abbildung 5.2: Struktur der Adressen im Event Buer
FeASIC Interface
Die Daten von bis zu 16 FeASICs werden
ub er die vier
FeASIC Ports
ausgelesen. Im
FeASIC Interface erfolgt dann die Berechnung eines Headerwortes zu jedem Event. An-
schlieend werden die Daten so in einem der b eiden Event Buer abgelegt, da die zu
einem Event ausgelesenen Bunch-Crossings in einem Blo ck direkt hintereinander stehen
(
Event Ordering
). Das Adressschema ist in Abbildung 5.2 zu sehen. Die untersten 3 bit
der Adresse geb en die Nummer des Bunch-Crossings an, dann folgen 2 bits, in denen die
Position in der Daisy Chain steht, und die ob ersten 2 bits geb en die Nummer des FeASIC
Ports an. Durch die Verwendung von zwei RAMs kann das FeASIC Interface ein Event
in einem RAM ablegen, w
ahrend die Kompressionseinheit aus dem anderen RAM das
vorhergehende Event ausliest.
Kompressionseinheit
Auf die Daten aus dem Event Buer wendet die Kompressionseinheit den vorher einge-
stellten Algorithmus an. F
ur das Human Co ding wird der Enco der RAM, der die Tab elle
mit den Human Co des enth
alt, als LUT b en
otigt. Die komprimierten Daten werden in
32 bit Worte formatiert und im Pre-Main Buer abgelegt. Er ist aus zwei RAMs mit
jeweils 48 Datenworten aufgebaut. Auf diese Weise ist es m
oglich zugleich ein fertig kom-
primiertes Event in den Main Buer zu kopieren und mit der Kompression eines neuen
Events zu b eginnen.
Pip elineBus Interface
Der Main Buer ist ein FIFO
2
, der in zwei Richtungen b etrieb en werden kann. Dadurch
ist es m
oglich den RemASIC
ub er den Pip elineBus auszulesen und zu kongurieren. Der
TokenInterpreter erkennt Tokens auf dem Pip elineBus und reagiert entsprechend darauf.
Auer der 32 bit breiten Schnittstelle, die insgesamt 70 Leitungen, jeweils 32 Daten- und
3 Kontrolleitungen f
ur Ein- und Ausgab e, ben
otigt, steht auch ein serielles Interface zur
Verf
ugung. Dadurch wird ein Betrieb mit nur 2 Datenleitung erm
oglicht, was vor allem
f
ur Testzwecke sinnvoll ist (siehe Kapitel 6).
2
First i nfirst o ut: Daten, die zuerst in einem FIFO gesp eichert werden, werden auch als erste ausgelesen.
5.1. DER REMASIC - EIN
UBERBLICK
51
Devices
Der RemASIC enth
alt vier Bl
ocke f
ur die Sp eicherung von Daten, den Event Buer, En-
co der RAM, Pre-Main Buer und die Kontrollregister f
ur die Konguration des Chips.
Sie werden im folgenden als
Devices
b ezeichnet. Jedes Device kann
ub er den Pip eline-
Bus konguriert werden, wenn der Main Buer Daten
ub er den Bus aufnimmt. Damit
ist es zum Beispiel m
oglich den Event Buer mit Testdaten zu b eschreib en und ihn als
Datenquelle f
ur die Kompression zu b enutzen. Auf diese Weise kann der RemASIC ohne
FeASICs b etrieb en werden.
Umgekehrt kann auch jedes Device in den Main Buer kopiert und von dort auf den
Pip elineBus gegeb en werden.
Ub er den Pip elineBus l
at sich auch die Auslese anhal-
ten. FeASIC Interface und Kompressionseinheit arb eiten dann solange weiter, bis sie ein
eventuell angefangenes Event fertig b earb eitet hab en. Auf diese Weise ist die Auslese der
Daten nach jeder Verarb eitungsstufe m
oglich.
SpyBus
Die bisher dargestellte Funktionalit
at erm
oglicht den Ausleseb etrieb und Test mit viel-
f
altigen Kongurationsm
oglichkeiten. Es wird jedo ch vorausgesetzt, da der Chip elek-
trisch fehlerfrei funktioniert. Zum Aunden von Design- o der Pro duktionsfehlern wurde
zus
atzlich ein sogenannter
SpyBus
integriert. Dies ist ein 8 bit breiter Bus auf den
ub er
einen Multiplexer 64 Signale gegeb en werden k
onnen. So ist zum Beispiel die Kontrol-
le von internen Registern m
oglich. Auerdem k
onnen
ub er den SpyBus die Signale der
Selbsttestfunktion der verschiedenen Sp eicher ausgelesen werden. Diese Funktion wird als
BIST (
Built In Self Test
) b ezeichnet.
5.1.2 Das Design
Der RemASIC b esteht aus drei Bl
ocken (siehe Abschnitt 5.1.1), die jeweils einen Teil der
Funktionalit
at zur Verf
ugung stellen. Jeder dieser Bl
ocke wurde von einem Designer im-
plementiert, so da insgesamt drei Leute an der Entwicklung des Chips gearb eitet hab en.
Damit die unabh
angig entwickelten und getesteten Bl
ocke am Schlu zu einem funkti-
onsf
ahigen Chip zusammengesetzt werden k
onnen, wurden zun
achst die Schnittstellen der
einzelnen Bl
ockeuntereinander und nach auen festgelegt.
Die Verilog-Beschreibung
F
ur die Implementation des RemASIC wurde die
Verilog Hardware Description Language
(Verilog HDL) verwendet [22]. Sie bietet die M
oglichkeit das Verhalten einer Digitalschal-
tung inklusive Zeitverhalten (
Timing
), zu mo dellieren. F
ur eine Darstellung der Sprache
siehe [23 ].
Das zentrale Elementvon Verilog ist das Mo dul. Mo dule hab en Verbindungen nach au-
en (Input und Output) und bilden das Verhalten eines kleinen Teils der Gesamtschaltung
nach. In einem Mo dul k
onnen wiederum Mo dule enthalten (instanziiert) sein. Die Mo dule
werden jedo ch nicht nacheinander abgearb eitet wie in einer sequentiellen Programmier-
sprache, sondern parallel. Diese Parallelit
at ist zwingend erforderlichf
ur die Mo dellierung
52
KAPITEL 5. DIE KOMPRESSIONSEINHEIT
einer Schaltung und stellt den Hauptunterschied zwischen einer sequentiellen Sprache wie
C und einer Hardwareb eschreibungssprache dar.
Der RemASIC wurde zun
achst entsprechend den Funktionsbl
ocken in drei Mo dule
unterteilt, von denen die Ein- und Ausganssignale und deren Timing festgelegt wurden.
Die Implementation der gew
unschten Funktionalit
at innerhalb der Bl
ocke blieb jedem
Entwickler selbst
ub erlassen. Um das Timing m
oglichst unkritisch zu gestalten werden bis
auf wenige Ausnahmen im FeASIC und Pip elineBus Interface alle Flipops mit demselb en
System-Takt b etrieb en. Dieses Vorgehen b ezeichnet man als synchrones Design. Der
Sourceco de ohne Kommentare umfat 22 kByte.
Synthese und Layout
Um aus der Verilog Beschreibung einen ASIC zu erstellen, wird eine Netzliste ben
otigt,
die die verwendeten Bauelemente und deren Verbindungen untereinander b einhaltet. Sie
l
at sich graphisch als Schaltplan darstellen. Man erh
alt die Netzliste mit Hilfe von soge-
nannten Synthese-To ols. F
ur die Synthese des RemASIC wurde das Programm
Synergy
verwendet. Es ist b eschrieb en in [24]. Bei der Mo dellierung m
ussen b estimmte Regeln b e-
achtet werden, um ein synthetisierbares Design zu erhalten [25]. So darf zum Beispiel nicht
der gesamte Verilog Sprachumfang verwendet werden und es mu eine strenge Trennung
von Bl
ocken mit sequentieller (getakteter) und rein kombinatorischer Logik eingehalten
werden.
Der Synthesizer verwendet Bibliotheken mit Standardzellen, die von den Halbleiterpro-
duzenten zur Verf
ugung gestellt werden. Standardzellen sind vorgegeb ene h
aug b enutzte
Bauelemente f
ur Digitalschaltungen, wie zum Beispiel Gatter, Flipops und Multiplexer.
Mit diesen Elementen konstruiert der Synthesizer einen Schaltplan, der dieselb e Funktio-
nalit
at wie die Verilog Beschreibung hat. F
ur den RemASIC wurde die ES2 ECPD-07
Bibliothek verwendet, die Standardzellen f
ur den 0.7
m Proze
3
der Firma ES2 enth
alt.
Die Sp eicherbl
ocke stehen nicht als Standardzellen, sondern als
Compiled Megacel ls
von ES2 zur Verf
ugung. Der Benutzer kann mit einem Programm Sp eicherbl
ocke b eliebi-
ger Gr
oe generieren und in seinem Design verwenden. Es wird automatisch eine Verilog
Beschreibung generiert, die f
ur die Simulation verwendet werden kann, jedo ch nicht syn-
thetisierbar ist. Erst b eim Pro duzenten werden diese Bl
ocke dann durch die entsprechende
Schaltung ersetzt. Auf diese Weise sind Event Buer, Enco der RAM, Pre-Main Buer und
Main Buer realisiert worden.
Hat man einen vollst
andigen, funktionsf
ahigen Schaltplan des Chips, folgt das Lay-
out. Es enth
alt alle Informationen, die f
ur die Pro duktion des Chips notwendig sind. Die
Bibliothekselemente der Netzliste werden durch die Standardzellen und deren Verbindun-
gen ersetzt, es entsteht ein Standardzellblo ck. Diese Bl
ocke m
ussen zusammen mit den
Sp eichern und den Anschl
ussen f
ur Eing
ange, Ausg
ange und Betriebsspannung (
Pads
)
so verteilt werden, da die Leitungen zwischen den Transistoren m
oglichst kurz und der
verbrauchte Platz m
oglichst gering ist. Die Generierung des Layouts erfolgt weitgehend
automatisch.
3
Die kleinste Struktur auf dem ASIC ist 0.7
m breit
5.1. DER REMASIC - EIN
UBERBLICK
53
Simulation
Ein Standardzellen Design auf Verilog Basis l
at sich auf verschiedenen Stufen der Ent-
wicklung simulieren. Hierf
ur wird der
Verilog-XL Simulator
verwendet.
Ub er eine sp ezi-
elle Sprache, die
Simulation and Test Language
(STL) [26 ], k
onnen Testvektoren auf die
Eing
ange gegeb en und die Ausg
ange b eobachtet werden.
In einer ersten Stufe wird der Verilog Source Co de vor der Synthese simuliert und
auf korrekte Funktion gepr
uft. Ist dies erfolgreich, wird der Verilog Co de synthetisiert.
Der Synthesizer erzeugt eine neue Verilog Beschreibung, in der auch die Durchlaufzeiten
durch die Gatter, die in der Netzliste benutzt werden, enthalten sind. In einer erneuten
Simulation mu nun
ub erpr
uft werden, ob das synthetisierte Design dasselb e Verhalten
zeigt, wie die Verilog Beschreibung. In einem letzten Schritt l
at sich ein aus dem Layout
gewonnenes
Standard Delay File
(SDF) mit in die Simulation einbinden. Es enth
alt Infor-
mationen
ub er die Verz
ogerungen (
Delays
), die durch die Leitungskapazit
aten verursacht
werden. Dieser Schritt war f
ur den RemASIC leider nicht m
oglich, da das SDF-File zu
gro war, um von der Software eingelesen werden zu k
onnen.
Zus
atzlich gibt es die M
oglichkeit, sich
ub er ein Programm namens
Veritime
die Lauf-
zeiten von verschiedenen Pfaden in der Schaltung anzeigen zu lassen. Pfade lassen sich
gezielt
ub er Angab e von Anfangs- und Endpunkt ausw
ahlen. F
ur jeden dieser Pfade wer-
den maximale o der minimale Laufzeiten b erechnet und angezeigt. Auch die Laufzeiten
zwischen getakteten Bausteinen (Flipops) k
onnen untersucht werden. Da der LHC mit
einer Bunch-Crossing Frequenz von 40 MHz l
auft (siehe Kapitel 1), und damit auch der
Level-1 Trigger Ereignisse mit 40 MHz verarb eiten mu, wurde auch der RemASIC f
ur
einen Betrieb mit 40 MHz ausgelegt. Die Simulationen mit Verilog und Veritime zeigen,
da dies mit dem Design erreichbar ist.
5.1.3 Der Chip
In diesem Abschnitt wird das Resultat des Designprozesses, der fertige Chip, vorgestellt.
Eine Fotograe des Dies unter dem Mikroskop ist in Abbildung 5.3 zu sehen. Man erkennt
in der Mitte einen groen Standardzellblo ck. Die kleineren Bl
ocke ob en und unten sind
die RAM Zellen. Am
aueren Rand liegt ringsherum der Padkranz. Auch die Bonddr
ahte,
die Verbindungen der Pads zu den Anschl
ussen im Geh
ause (
Package
), sind zu erkennen.
F
ur die Verteilung der Clo ck wurde ein einziger groer Clo ckbuer gew
ahlt. Von ihm
aus l
auft jeweils eine Clo ck-Leitung links und rechts am Standardzellblo ck vorb ei und
verzweigt sich dann senkrecht in die einzelnen Standardzellreihen.
Auf dem Chip b enden sich etwa 160000 Transistoren, 800 Flipops und 2.5 kByte
Sp eicher. Er hat eine Fl
ache von etwa 50 mm
2
und 129 Ein- und Ausgangsleitungen. Er
wurde f
ur eine Taktfrequenz von 40 MHz ausgelegt. Eine Zusammenfassung der wichtig-
sten Daten des RemASIC ist in Tab elle 5.1 zu nden.
54
KAPITEL 5. DIE KOMPRESSIONSEINHEIT
Event Buffer
Main Buffer
Encoder RAM
Standardzellenblock
Pre-Main Buffer
Bonddraht
Abbildung 5.3: Vergr
oerte Aufnahme eines RemASICs
5.2. ARCHITEKTUR DER KOMPRESSIONSEINHEIT
55
Design Verilog HDL, Standardzellen
Proze 0.7
m CMOS von ES2
Die Fl
ache 7
:
8mm
7
:
15 mm
Transistoren ca. 160000
Flipops ca. 800
Sp eicher 2.5 kByte
Taktfrequenz
40 MHz (simuliert)
I/O-Pins 129
Tab elle 5.1: Design Ergebnis auf einen Blick
5.2 Architektur der Kompressionseinheit
Die Kompressionseinheit wurde als hierarchisches Verilog Design ausgef
uhrt. Entspre-
chend den einzelnen Funktionsbl
ocken, die in 5.2.2 b eschrieb en werden, wurde sie in Mo-
dule unterteilt, die ihrerseits auch wieder aus Mo dulen b estehen k
onnen. Jede State
Machine
4
b elegt ein eigenes Mo dul.
5.2.1 Anforderungen
Am Anfang der Entwicklung stand eine Liste von Anforderungen an die Kompressionsein-
heit, die Implementation war hingegen no chweitgehend unklar. Folgende Kompressions-
mo di sollten zur Verf
ugung stehen:
NoOp eration (Nop): keine Kompression
Human
Human Inspired
Dierence
Run-Length
Der NoOp eration Mo dus ist hier auch als Kompressionsmo dus aufgef
uhrt, da er sich der
gesamten Infrastruktur der Kompressionseinheit b edient und lediglich als ein sp ezieller Al-
gorithmus implementiert ist, der die Daten unver
andert l
at und nur umformatiert. Jeder
Kompressionsmo dus sollte, soweit m
oglich, sowohl 8 bit als auch 10 bit Daten verarb eiten.
An dieser Stelle wurden jedo ch einige Kompromisse gemacht (siehe Abschnitt 5.4), um
die Kompression nichtzukomplex werden zu lassen. Weitere Anforderungen sind
Auslese der Daten aus dem Event Buer unter Ber
ucksichtigung des Event Ordering
Alle zwei Taktzyklen mu ein Datum aus dem Event Buer ausgelesen werden
Formatierung der komprimierten Daten zu 32 bit W
ortern
4
Zustandsmaschine, siehe 5.5 und [27].
56
KAPITEL 5. DIE KOMPRESSIONSEINHEIT
Konguration und Auslese jedes Sp eichers
ub er den Pip elineBus
Da im Schnitt alle 10
s ein Level-1 Accp et erfolgt, das heit ein Datensatz ausgelesen
werden mu, ist es erforderlich, die Kompression auch im ung
unstigsten Fall, das b edeutet
Kompression von 128 Datenw
ortern, nach h
ochstens 10
s zu b eenden. Daher mu alle
zwei Taktzyklen ein Energiewert b earb eitet werden.
Eine Formatierung der Daten ist notwendig, da die Kompressionseinheit Datenw
orter
mit ganz unterschiedlicher L
ange pro duziert, der Pip elineBus jedo ch eine feste Breite
b esitzt. W
urde man jedes Datenwort einzeln auf den Bus geb en, so w
are die bei der
Kompression gewonnene Reduktion der erforderlichen Bandbreite wieder verschenkt.
Eine Konguration des Enco der RAMs ist in jedem Fall notwendig, um die Co detab elle
f
ur das Human Co ding laden zu k
onnen. Die Konguration des Pre-Main Buers, sowie
eine Auslesem
oglichkeit f
ur b eide Sp eicher ist f
ur Testzwecke w
unschenswert.
5.2.2 Implementation
Ein Blo ckdiagramm der Kompressionseinheit ist in Abbildung 5.4 zu sehen. Sie b esteht aus
vier Funktionsbl
ocken (Event Readout, Compression Mo dules, Shifting Unit und Pre-Main
Buer), drei Sp eicherbl
ocken (RAM0, RAM1 und Enco der RAM) und 4 Kontrollbl
ocken
(CUN Control, Dataow Control, Memory Control und ein Multiplexer).
Event Readout
Der Event Readout ist zust
andig f
ur die Auslese der Daten aus dem Event Buer. Alle
zwei Taktzyklen wird ein Datenwort ausgelesen und in einem Register gesp eichert, damit
es unabh
angig von den Sp eicherzugriszeiten volle zwei Taktzyklen f
ur die weitere Ver-
arb eitung in den Compression Mo dules zur Verf
ugung steht. Auerdem wird ein Signal
generiert, das anzeigt, wann das letzte Datenwort aus dem Event Buer ausgelesen wurde.
Die Auslese erfolgt nicht immer konsekutiv, da sich die Adresse eines Energiewertes zu-
sammensetzt aus Portnummer, Daisy Chain Position und Bunch-Crossing Nummer (siehe
Abschnitt 5.1.1). H
angen zum Beispiel am FeASIC Port 0 und 3 jeweils ein FeASIC, die
pro Event f
unf Bunch-Crossings auslesen, so m
ussen zuerst die Adressen 0x0-0x5
5
, und
dann 0x60-0x65 ausgelesen werden. Die Register
RegPortMask
und
RegDaisyChainCount
enthalten die Konguration der FeASIC Ports. Die Anzahl der Bunch-Crossings stehtin
RegBcPerEvent
.
Ub er diese Register wird festgelegt, an welchen Adressen sich g
ultige
Daten b enden, die auszulesen sind.
Compression Mo dules
In den Compression Mo dules erfolgt die eigentliche Kompression der Daten. Der Kom-
pressionsmo dus wird
ub er das Register
RegComprMode
festgelegt. In
RegComprParameter
wird f
ur das Human-Inspired Co ding die Referenzenergie festegelegt, b eim Run-Length
Enco ding l
at sich so ein Energie-Cut w
ahlen (siehe auch Anhang B).
Jeder Algorithmus ist als eigenst
andiges Mo dul realisiert. Aus dem Register
RegCom-
prMode
wird ein Signal generiert, das das entsprechende Mo dul aktiviert, so da nur einer
5
Das vorangestellte 0x b edeutet, da die folgende Zahl hexadezimal dargestellt ist.
5.2. ARCHITEKTUR DER KOMPRESSIONSEINHEIT
57
RegPortMaskRegBcPerEvent, RegDaisyChainCount, RegPortMask
RegComprMode, RegComprParameter
RegPreMainBufferSel, RegPreMainBufferSource
0000000
000000
0
000000
0
000000
0
000000
0
000000
0
000000
0
000000
0
000000
0
000000
0
0000000
1111111
111111
1
111111
1
111111
1
111111
1
111111
1
111111
1
111111
1
111111
1
111111
1
1111111
000000
000000
000000
000000
111111
111111
111111
111111
0000000
000000
0
000000
0
000000
0
000000
0
000000
0
000000
0
000000
0
1111111
111111
1
111111
1
111111
1
111111
1
111111
1
111111
1
111111
1
00000000
0000000
0
0000000
0
0000000
0
0000000
0
0000000
0
0000000
0
11111111
1111111
1
1111111
1
1111111
1
1111111
1
1111111
1
1111111
1
<<
Event Readout
Kontrollsignale
Adressen
FeEventAvailable
FeEventData
10
10
32 24
32
24 8
6
32
32
Compression Modules
32
Run-
length
Dif-
ference
Huf.-
inspired
6
3 Register + Kontrollogik für die Ausgabe
10
8
Dataflow Control
Shifting Unit
CUN Control
Zum Main Buffer
32
Huffman
RAM0 RAM1
Pre-Main Buffer
Encoder
RAM
Memory
Control
6
Zeigt die Benutzung externer Register
an, die über den PipelineBus geladen werden müssen
Kontrollsignale des PipelineBus Interface
Daten
Zähler
Nop
6
Barrel-
shifter
32 32
Abbildung 5.4: Blo ckdiagramm der Kompressionseinheit
58
KAPITEL 5. DIE KOMPRESSIONSEINHEIT
Wort 4 Wort 3 Wort 2noch ungültig Wort 1
70
831 31 30 29 20 19 10 00
Abbildung 5.5: Verdeutlichung der Formatierung eines 32 bit Wortes
der Algorithmen benutzt wird. Die einzelnen Mo dule erhalten die ausgelesenen Daten-
worte aus dem Event Buer zur Verarb eitung. Die Ausgangssignale des aktiven Mo duls
werden
ub er einen Multiplexer an die Shifting Unit und die CUN Control gegeb en. Je
nach Komplexit
at des Algorithmus erfolgt die Co dierung mit keiner (Nop-Mo dus) bis zwei
(Human-Inspired und Dierence Mo dus) Pip elinestufen. Dadurch ist garantiert, da in
jedem Fall nach zwei Taktzyklen das n
achste Datenwort aus dem Event Readout verar-
b eitet werden kann.
Der Compression Mo dules Blo ckenth
alt auerdem no ch einen 10 bit Subtrahierer, der
f
ur verschiedene Funktionen genutzt wird. Zum einen kann im Run-Length Mo dus ein
Energie-Cut gew
ahlt werden. Ist der aktuelle Energiewert kleiner als der Abschneidewert,
so wird die Energie auf Null gesetzt. Diese Vergleichsop eration wird
ub er das Vorzeichenbit
des Subtrahierers realisiert. Beim Human-Inspired Co ding wird der Subtrahierer genutzt,
um die Dierenz von aktuellem Wert und der Referenzenergie zu b erechnen. F
ur das
Dierence Co ding b erechnet er die Dierenz zweier aufeinanderfolgender Energiewerte.
Beim Human Co ding wird zus
atzlich aus dem ausgelesenen Energiewert eine 8 bit
Adresse und das Memory Enable
6
f
ur den Enco der RAM generiert. Aus dem zur
uckge-
lieferten 24 bit Wort l
at sich der Human Co de und seine L
ange b erechnen (genaueres
siehe 5.4).
Shifting Unit
Die Shifting Unit ist daf
ur zust
andig, den von den Compression Mo dules erzeugten Co de
an die richtige Stelle in einem 32 bit Wort zu setzen, das, sobald es g
ultig ist, in den
Pre-Main Buer geschrieb en wird. Werden zum Beispiel vier 10 bit lange Co dew
orter
erzeugt, so bilden die ersten drei zusammen mit den 2 LSBs des vierten Co des ein g
ultiges
Datenwort. Die ob eren acht bit des vierten Co des sind dann die 8 LSBs eines neuen
Datenwortes, das, bevor es in den Pre-Main Buer geschrieb en werden kann, erst no ch
vollst
andig aufgef
ullt werden mu (siehe auch 5.5).
F
ur ihre Arb eit ben
otigt die Shifting Unit eine Reihe von Informationen und Daten,
die von den Compression Mo dules zur Verf
ugung gestellt werden. Einige Signale gelangen
jedo ch erst nach einem Umweg
ub er die CUN Control in die Shifting Unit. Hier wird zum
Beispiel auf den Sonderfall des letzten Energiewertes eines Events reagiert. Die Shifting
Unit hat einen 32 bit breiten Eingang f
ur die Co dew
orter. Da diese jedo ch verschieden
lang sind, mu zus
atzlich die L
ange des Wortes bekannt sein. Sie gibt an, wieviele LSBs
6
Mit dem Memory Enable wird die Auslese des Datenwortes gestartet, das sich an der Position b endet,
die am Adresseingang sp eziziert ist.
5.2. ARCHITEKTUR DER KOMPRESSIONSEINHEIT
59
des 32 bit Wortes g
ultig sind. Die restlichen bits sind auf Null gesetzt. Auerdem wird
no ch ein Signal b en
otigt, das anzeigt, wann ein g
ultiges Co dewort am Eingang der Shifting
Unit anliegt.
F
ur die Formatierung der Daten werden ein Barrel Shifter, ein Z
ahler und drei 32 bit
Register verwendet. Die Bedeutung der einzelnen Komp onenten und die Arb eitsweise der
Shifting Unit werden in Abschnitt 5.3 erl
autert. Die Shifting Unit stellt an ihrem Ausgang
das fertig formatierte 32 bit Datenwort, wie es in den Pre-Main Buer geschrieb en wird,
zur Verf
ugung. Auerdem wird signalisiert, wann es in den Sp eicher geschrieb en werden
kann.
Pre-Main Buer
Der Pre-Main Buer b esteht aus den zwei RAMs (RAM0 und RAM1), zwei Adressre-
gistern und einem Kontrollblo ck. Es kann gew
ahlt werden, welcher der b eiden RAMs
b eschrieb en werden soll, der andere b endet sich dann automatisch im Lesemo dus. Das
eine Register sp eichert die aktuelle Schreibp osition, das andere die Lesep osition. Dadurch
ist es m
oglich einen Sp eicher zu b eschreib en und den anderen auszulesen.
F
ur die Adressierung des Pre-Main Buers gibt es zwei Mo di. Im normalen Betrieb
wird b ei jedem Schreib- o der Lesezugri die entsprechende Adresse automatisch inkremen-
tiert. Wird die ob erste Adresse erreicht, bleibt der Adressz
ahler stehen. Dieser Mo dus hat
den Vorteil, da er das Beschreib en und Auslesen des Pre-Main Buers b ei der Kompres-
sion wesentlich erleichtert. F
ur den Testb etrieb ist es auch m
oglich in einen wahlfreien
Mo dus umzuschalten, in dem an b eliebigen Adressen gelesen und geschrieb en werden kann.
Die Kontrollbl
ocke
Die Kontrollbl
ocke regeln den Datenu durch die Kompressionseinheit f
ur die verschiede-
nen Kompressions- und Testmo di. Ihre genaue Funktionsweise wird nichter
ortert, da dies
langweilig ist und einer Erkl
arung des gesamten Verilog Sourceco des gleich k
ame. Statt
dessen wird kurz ihre Bedeutung f
ur die Kompressionseinheit vorgestellt.
Die Data Flow Control regelt den globalen Datenu und reagiert auf Signale des
Pip elineBus Interface. Sie ist sozusagen die Ob erkontrollinstanz und steuert s
amtliche
anderen Kontrollmo dule. F
ur einen korrekten Ablauf der Kompression, deren Beginn und
Ende, ist die CUN Control zust
andig, w
ahrend mit der Memory Control der Zugri auf
die verschiedenen Sp eicher geregelt wird. Der Multiplexer schlielich sorgt daf
ur, da
sowohl der Pre-Main Buer, als auch der Enco der RAM,
ub er denselb en Ausgang der
Kompressionseinheit zum Pip elineBus ausgelesen werden kann.
Die Sp eicher
RAM0 und RAM1 sind zwei identische Sp eicherbl
ocke, die jeweils 48 Datenworte mit
einer L
ange von 32 bit aufnehmen k
onnen. Sie verf
ugen
ub er einen eingebauten Selbst-
test (BIST) und
Latches
7
als Ausg
ange. Dadurch bleibt das ausgelesene Datum bis zum
n
achsten Lesezugri stabil. Sie b elegen eine Fl
ache von jeweils 0.57 mm
2
und hab en eine
7
Pegelgesteuerte Sp eicherbausteine (siehe [27 ].
60
KAPITEL 5. DIE KOMPRESSIONSEINHEIT
mittlere Zugriszeit von 4.4 ns. Der Enco der RAM umfat 256 Datenworte zu 24 bit und
verf
ugt eb enfalls
ub er BIST und Latches am Datenausgang. Er b en
otigt eine Fl
ache von
1.84 mm
2
. Die Zugriszeit b etr
agt typischerweise 5.8 ns. Diese Zeiten sind dem Datenle
entnommen, das das Programm zur Erzeugung der Sp eicherbl
ocke ausgibt.
5.3 Formatierung der Daten
Die Formatierung der Co dew
orter in einem 32 bit Wort wird in diesem Abschnitt be-
schrieb en. Bewerkstelligt wird dies von der Shifting Unit. Sie ist das Herzst
uck der ge-
samten Datenkompression, da alle Algorithmen auf die Formatierung angewiesen sind. Die
Schnittstelle der Kompressionsmo dule zur Shifting Unit b esteht aus einem 32 bit breiten
Wort, das den Co de enth
alt, der 6 bit breiten Co dewortl
ange und einigen Steuerleitungen.
Wichtigste Funktionseinheit der Shifting Unit ist der
Barrel Shifter
. Ein Barrel Shifter
dient dazu, ein Datenwort um eine b eliebige Anzahl von bits zu verschieb en. Der Unter-
schied zu einem Schieb eregister b esteht darin, da der Barrel Shifter aus rein kombinato-
rischer Logik b esteht. Das b edeutet, da die Zeit, die f
ur die Schieb eop eration ben
otigt
wird, nur von den Gatterlaufzeizten abh
angt. Die Simulation hat typische Durchlaufzeiten
von einem viertel Taktzyklus, also etwa 7 ns ergeb en. Beim Schieb eregister wird hingegen
pro Schieb eop eration um ein bit ein Taktzyklus b en
otigt. Der hier implementierte Barrel
Shifter hat einen 32 bit breiten Eingang und einen 64 bit breiten Ausgang, der in zwei
jeweils 32 bit breite Ausg
ange unterteilt ist (
DataHigh
und
DataLow
).
Ub er eine 6 bit
breite Steuerleitung (
ShiftBits
) wird festgelegt, um wieviele bits das Eingangswort nach
links verschob en werden soll. F
ur jedes geschob ene bit r
uckt eine Null nach. Es wird also
nicht zyklisch geschob en. Eine Schieb eop eration mit einem 7 bit breiten Datenwort, das
um 28 bits nach links geschob en wird, ist in Abbildung 5.6 zu sehen.
Um aus dem Output des Barrel Shifters ein Datenwort zusammenzusetzen werden
drei 32 bit breite Register verwendet (siehe Abbildung 5.7). Eines ist das aktive, eines
das
Ub erlaufregister und eines wird auf Null gesetzt (Resetregister). Der Ausgang je-
des Registers ist
ub er eine ODER-Verkn
upfung mit der Datenleitung auf den Eingang
zur
uckgekopp elt. Auf der Datenleitung des aktiven Registers liegt der DataLow Ausgang
des Barrel Shifters. Hier wird also das Datenwort f
ur den Pre-Main Buer aus den Co-
dew
ortern zusammengesetzt. Das
Ub erlaufregister ist auf Null gesetzt, seine Datenleitung
ist mit DataHigh des Barrel Shifters verbunden. In dieses Register wird der
Ub erlauf
geschrieb en, der entsteht, wenn ein Datenwort so weit geschob en wird, da ein Teil
ub er
der 32 bit Grenze liegt. Ist dies der Fall, so sind alle 32 bit des aktiven Registers mit
Daten b elegt, das Wort kann in den Pre-Main Buer geschrieb en werden. Nun wird das
Ub erlaufregister zum aktiven Register, das Resetregister wird das neue
Ub erlaufregister
und das aktive Register wird zum Resetregister. Das Resetregister ist n
otig, damit das
Ub erlaufregister stets auf Null gesetzt ist.
Die Ansteuerung des Barrel Shifters und der Register geschieht
ub er den sogenannten
Shift Counter
. Er enth
alt zwei Register. In einem werden die Co dewortl
angen der aktuel-
len Co des aufaddiert. Wird der Wert des Registers gr
oer als 32, ist also ein 32 bit Wort
fertig formatiert, so wird das Signal
Overow
(
Ub erlauf ) gesetzt. Im anderen Register
wird die Anzahl der bits gesp eichert, um die der Barrel Shifter nach links schieb en mu
5.3. FORMATIERUNG DER DATEN
61
0
0
1
000
0
0
0
0
0
0
0
0
0
000
111
1
1
1
1
1
1
1
1
1
111
1
1
DataHigh
0
DataLow
0101
Schiebe um 28 bits nach links
1010101
0
7 bit Code32 bit Datenwort
231 3 0 31 28 27 0
<<
Barrel Shifter
LSB
MSB
31 0
101 0
0
Abbildung 5.6: Veranschaulichung einer Schieb eop eration
32 bit Leitungen
000
00
0
00
0
00
0
00
0
00
0
00
0
00
0
00
0
00
0
00
0
00
0
00
0
00
0
111
11
1
11
1
11
1
11
1
11
1
11
1
11
1
11
1
11
1
11
1
11
1
11
1
11
1
00
0
0
0
0
0
0
0
0
0
0
0
0
0
0
00
11
1
1
1
1
1
1
1
1
1
1
1
1
1
1
11
00
0
0
0
0
0
0
0
0
0
0
0
0
0
0
00
11
1
1
1
1
1
1
1
1
1
1
1
1
1
1
11
00
0
0
0
0
0
0
0
0
0
0
0
0
0
0
00
11
1
1
1
1
1
1
1
1
1
1
1
1
1
1
11
Alle Verbindungen sind
Register
00
00
00
00
00
00
00
00
00
11
11
11
11
11
11
11
11
11
0
0
0
0
0
0
0
0
0
1
1
1
1
1
1
1
1
1
0
0
0
0
0
0
0
0
1
1
1
1
1
1
1
1
0
0
0
0
0
0
0
0
1
1
1
1
1
1
1
1
000
000
000
000
000
000
000
000
000
111
111
111
111
111
111
111
111
111
000
000
000
000
000
000
000
000
111
111
111
111
111
111
111
111
000
000
000
000
000
000
000
000
111
111
111
111
111
111
111
111
Barrel
Shifter
32 bit
OR
32 bit
OR
32 bit
OR
Register Register
Abbildung 5.7: Organisation der Barrel Shifter Auslese
62
KAPITEL 5. DIE KOMPRESSIONSEINHEIT
Clock
Shift
00 32 00 01
ShiftBits 00
10 04 10 04 10
LatchData
Overflow
00 00 00 01 00 02 00 01 00 32 00 01 00 00 05 40
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 40 00 00 00 00
00 00 05 0000 00 00 00
00 30 00 00
00 00 00 01 00 02 00 00
10 14 24 08
00 00 00 01 00 00 00 02 00 00 00 03 00 00 00 04 00 00 00 05
Codewort
Codewort-
länge
DataLow
DataHigh
Zum Pre-Main Buffer
Abbildung 5.8: Timing b eim Formatieren der Daten. Alle Werte der Datenbusse sind als
Hexadezimalzahlen zu verstehen. Damit entspricht eine Zier 4 bit.
(
Shift Bits
). Vor jeder neuen Addition von Co dewortl
angen im ersten Register wird ein-
fach die alte Summe im zweiten Register gesp eichert. Diese entspricht gerade der Anzahl
der zu Schieb enden bits.
Der zeitliche Ablauf (
Timing
) b eim Formatieren eines Datenwortes ist in Abbildung
5.8 zu sehen. Sowohl Co dewort als auch Co dewortl
ange m
ussen f
ur zwei Taktzyklen
g
ultig sein. Das Signal
Shift
bet
atigt den Shift Counter, der ShiftBits b erechnet. Im
Barrel Shifter wird das Co dewort um ShiftBits nach links geschob en, was h
ochstens einen
Taktzyklus b eanspruchen darf, da mit
LatchData
die Ausg
ange des Barrel Shifters in das
aktive und das
Ub erlaufregister gesp eichert werden. Ist ein Datenwort voll, so wird durch
setzen von Overow seine Sp eicherung im Pre-Main Buer veranlat (siehe auch Abschnitt
5.5).
Die Formatierung der Daten wurde auf diese Weise realisiert, um absolute Synchro-
nizit
at der Schaltung zu gew
ahrleisten (siehe Abschnitt 5.1.2). Ohne Forderung nach
Synchronizit
at h
atte die Shifting Unit auch mit zwei 32 bit Registern realisiert werden
k
onnen. Das Resetregister ist bei der gew
ahlten Vorgehensweise notwendig, da in einer
synchronen Schaltung f
ur ein Zur
ucksetzen des Registers ein Taktzyklus ben
otigt wird.
Ohne das Reset Register m
ute das aktive Register zur
uckgesetzt werden, w
ahrend sein
Inhalt no ch in den Pre-Main Buer geschrieb en wird.
5.4 Die Kompressionsmo dule
Alle Kompressionsmo dule hab en nach auen hin das gleiche Interface und stellen Co de-
wort, Co dewortl
ange und Steuersignale f
ur die Shifting Unit zur Verf
ugung. Dab ei m
ussen
sie sich an das in Abschnitt 5.3 dargestellte Timing halten. Die der Implementation zu-
5.4. DIE KOMPRESSIONSMODULE
63
23 14
Header
Encoder RAM Wort mit 14 bit Huffman Code und 10 bit Header
01000111101011
13 0
Huffman Code
1111111111
Abbildung 5.9: Aufbau eines Enco der RAM Wortes
grundeliegenden Ideen werden in diesem Abschnitt erl
autert.
Im NoOp eration (Nop) Mo dus passiert mit den ausgelesenen Daten nichts. Es wird
lediglich die Datenwortl
ange
ub er einen Multiplexer zwischen 8 bit und 10 bit umgeschal-
tet, je nachdem welche Wortl
ange gew
ahlt wurde. Die anderen Kompressionsmo dule sind
etwas komplexer.
5.4.1 Human Co ding
Wichtigster Bestandteil des Human Co ding ist der Enco der RAM. Zu jedem m
oglichen
Energiewert ist ein Pseudo co de gesp eichert, der den eigentlichen Human Co de und seine
L
ange enth
alt. Die Energiewerte dienen als Adresse f
ur den Sp eicher. Man erh
alt dann am
Datenausgang den Pseudo co de. Der Enco der RAM wird also als Lo ok-Up Table b enutzt.
Er umfat lediglich 256 Datenworte. Das b edeutet, da ein echtes Human Co ding f
ur
10 bit Daten nicht m
oglich ist. Es ist jedo ch auch nicht n
otig, da b eim
Ub ergang von
8 bit auf 10 bit die Entropie der Kalorimeterdaten um fast zwei bit ansteigt (siehe 4.1).
Man erh
alt also b einahe dasselb e Ergebnis wie b eim echten Human Co ding, wenn nur die
8 MSBs eines 10 bit Wortes mit den Co des aus dem Enco der RAM co diert werden, und
die zwei LSBs einfach unver
andert an den Human Co de angeh
angt werden. Damit ist
auchkein Wechsel der Co detab elle b eim
Ub ergang von 8 bit auf 10 bit Daten notwendig.
Wie man sich leicht klar macht, entsteht auch durch diese Art der Co dierung ein Prex
Co de (siehe auch Anhang A).
Im Enco der RAM werden die Human Co des so gesp eichert, da man sowohl den
eigentlichen Co de, als auch die Co del
ange erh
alt. Dazu werden die vom Co dewort nicht
b elegten bits des Enco der RAM Wortes mit dem invertierten MSB des Co dewortes auf-
gef
ullt (siehe Abbildung 5.9). Es k
onnen also maximal Co des gesp eichert werden, die ein
bit weniger b en
otigen, als in ein Enco der RAM Wort passen. Die maximale L
ange eines
Human Co des b etr
agt somit 24
,
1 = 23 bit. Um Human Co de und Co del
ange zu
b estimmen ist es nur no ch n
otig, die Stelle zu b estimmen, an der sich, b eginnend vom
MSB, zum ersten Mal ein bit
andert. Realisiert wird dies
ub er eine XOR-Schaltung, die
alle MSBs bis zum ersten ge
anderten bit auf logisch eins setzt, dann folgt eine Null und
der Rest ist unb estimmt. Mit dieser Information kann die Co del
ange b estimmt werden.
Hat man die Co del
ange, lassen sich auch die f
uhrenden ung
ultigen bits auf Null setzten,
man hat den Human Co de zur
uckerhalten.
64
KAPITEL 5. DIE KOMPRESSIONSEINHEIT
Clock
Shift
Energiewert
zwischengespeicherter
Wert
Codewortlänge
Code
0
ff
0
0
ff
0
ff
00ff
8
8
8ff
00 00 00 0000 00 00 ff 00 00 00 00 00 00 ff 02 00 00 00 00
Abbildung 5.10: Timing b eim Run-Length Enco ding. Alle Zahlenwerte sind Hexadezimal
5.4.2 Run-Length Enco ding
Der zeitliche Ablauf des Run-Length Enco ding ist in Abbildung 5.10 zu sehen. Durch
Einf
uhrung einer Pip elinestufe wird der Energiewert solange gesp eichert, bis der nachfol-
gende Wert b ekannt ist. Es gibt einen
Ub erlapp der b eiden Werte von einem Taktzyklus.
Solange keine Null erkannt wird, werden einfach die Energiewerte und deren L
ange (8 bit
o der 10 bit) an die Shifting Unit
ub ergeb en. Auch b eim ersten Auftreten einer Null wird
so verfahren. Die nun folgenden Nullen werden nur gez
ahlt, es werden keine Datenw
orter
an die Shifting Unit gegeb en. Daher wird auch das Shiftsignal nicht mehr gesetzt. Sobald
nun ein anderer Wert als Null folgt, wird an die Shifting Unit ein Wort mit dopp elter
L
ange
ub ergeb en (16 bit o der 20 bit), in dem die Anzahl der Nullen und der neue Ener-
giewert stehen. Dadurch wird erreicht, da b eim Schreib en des Z
ahlers keine zus
atzliche
Zeit ben
otigt wird. Auch wenn mehr Nullen gez
ahlt werden, als mit den zur Verf
ugung
stehenden bits co diert werden k
onnen (also 256 o der 1024), werden Anzahl der Nullen und
nachfolgend eine neue Null in einem Dopp elwort an die Shifting Unit
ub ergeb en, so da
die Z
ahlung wieder b ei eins anfangen kann.
5.4.3 Human-Inspired und Dierence Co ding
Um eine freie Wahl von Datenwortl
ange
l
DW
und L
ange der kurzen Co des
l
ZM
zu imple-
mentieren, w
urde ein zus
atzlicher Barrel Shifter b en
otigt. Da die b esten Werte f
ur diese
Parameter aus der Simulation bekannt sind, und um Chip
ache und damit Kosten zu
sparen, wurden feste Werte f
ur
l
DW
und
l
ZM
vorgegeb en. Auerdem wurde die Energie-
au
osung f
ur b eide Mo di auf 10 bit festgelegt. Bei 10 bit erh
alt man mit
l
DW
= 12 bit und
l
ZM
= 4 bit die b esten Kompressionsfaktoren (siehe 4.2). Mit diesen Parametern wurden
die b eiden Algorithmen daher auch auf dem RemASIC realisiert.
Human-Inspired und Dierence Co ding unterscheiden sichkaum. F
ur das Human-
Inspired Co ding wird die Dierenz von Referenzenergie
E
R
und Pedestal
P
ben
otigt, f
ur
das Dierence Co ding die Dierenz zweier aufeinanderfolgender Energiewerte. Daher wird
dasselb e Mo dul f
ur das Human-Inspired und Dierence Co ding b enutzt. Das Dierence
Co ding braucht zus
atzlich nur no ch ein Register, in dem ein Datenwort aus dem Event
Buer zwischengesp eichert wird, bis ein neues ausgelesen ist, und die Dierenz gebildet
5.4. DIE KOMPRESSIONSMODULE
65
Normal Message
H
Diff
H
H
Normal Message
Normal Message H
Diff H
Diff
Diff
Beispiel 2
Diff H
NULL Diff
13 bits
5 bits
13 bits
13 bits
5 bits
5 bits
4 bits
4 bits
8 bits
Diff: Ein kurzer Blockcode (Differenz)
NULL: SkipRest Token
H: Header
Beispiel 1
Abbildung 5.11: Co dew
orter und -l
angen, wie sie an die Shifting Unit
ub ergeb en werden.
Die Co dewortl
ange l
at sich erst b estimmen, wenn der folgende Energiewert b ekannt ist.
werden kann. Damit die Kompression des ersten ausgelesenen Energiewertes nichtzuei-
nem Sp ezialfall wird, wird hier die Dierenz mit Null gebildet. Auch der erste Energiewert
kann also mit einem kurzen Co de co diert werden.
Das Mo dul, das die eigentliche Co dierung
ub ernimmt, erh
alt den Energiewert aus
dem Event Buer und zus
atzlich eine Dierenz. Wie diese zustande kommt, interessiert
f
ur die Co dierung nicht weiter. F
ur die Realisierung der Co dierung kann man sich zwei
prinzipielle M
oglichkeiten vorstellen. Zum einen k
onnte ein Datenwort zun
achst komplett
im Kompressionsmo dul zusammengesetzt werden und dann an die Shifting Unit
ub ergeb en
werden. Diese Metho de hat jedo ch den Nachteil, da das Kompressionsmo dul Arb eit
erledigt, die eigentlich die Shifting Unit
ub ernehmen sollte, n
amlich die Formatierung der
Daten. Eine andere Metho de ergibt sich, wenn man Abbildung 5.11 b etrachtet. Jede Zeile
entspricht dem Co de f
ur einen Energiewert, Header und abschlieende Nullen (SkipRest)
werden gegeb enenfalls mit in den Co de einb ezogen. Das b edeutet jedo ch, da sich die
Co dewortl
ange erst angeb en l
at, wenn auch der n
achste Energiewert b ekannt ist.
In Abbildung 5.12 ist ein Blo ckdiagramm zu sehen, das den Ablauf b ei der Co dierung
verdeutlicht. Energiewert und Dierenz werden solange zwischengesp eichert, bis auch
der neue Energiewert und die neue Dierenz bekannt sind. Die zwischengesp eicherten
Werte sind in der Abbildung als
alte Werte
b ezeichnet. Aus der alten und der neuen
Dierenz wird
ub er einen Blo ck mit kombinatorischer Logik ein Signal b erechnet, das den
Multiplexer MUX1 b edient.
Ub er ihn kann entweder die Dierenz (der kurze Co de) o der
der unver
anderte alte Energiewert selektiert werden. Ein zweiter Multiplexer MUX2 sorgt
daf
ur, da das ausgew
ahlte Datenwort um ein bit nach links verschob en wird, falls ein
Headerbit gebraucht wird. Dies ist der Fall, f
ur den ersten kurzen Co de eines Datenwortes
o der f
ur einen unver
anderten Energiewert. Wird von MUX1 ein kurzer Co de selektiert, so
sind nur die 4 LSBs des 10 bit Wortes b elegt, die anderen 6 bits enthalten den Wert Null.
An dieser Stelle sollte klar werden, warum gerade die Null signalisiert, da der Rest des
66
KAPITEL 5. DIE KOMPRESSIONSEINHEIT
verwendet werden
Logik, die entscheidet, ob kurze Codes
000
00
0
00
0
00
0
00
0
00
0
111
11
1
11
1
11
1
11
1
11
1
LSB
00000
00000
00000
00000
11111
11111
11111
11111
00000
00000
00000
00000
11111
11111
11111
11111
Alter Energiewert
10
10
10
10 10 11 bit Register mit 1 bit Platz
für das Headerbit
Neue Differenz Alte Differenz
10 10
MUX1
MUX2
ja nein
Wird ein Header benötigt?
MSB
Abbildung 5.12: Blo ckdiagramm des gemeinsamen Teils von Human-Inspired und Die-
rence Co der
Datenwortes
ub ersprungen werden soll. Um eine Null vor ein vorhandenes Co dewort zu
stellen mu man garnichts tun, auer die Co dewortl
ange entsprechend zu erh
ohen. Den
Rest erledigt die Shifting Unit.
5.5 Betrieb der Kompressionseinheit
Bevor die Kompressionseinheit f
ur die Auslese von Daten b etrieb en wird, mu sicherge-
stellt sein, da die Register f
ur die Konguration mit den gew
unschten Werten geladen sind
(f
ur die Konguration siehe Anhang B). Sollen die Daten mit dem Human Algorithmus
co diert werden, so mu zus
atzlich der Enco der RAM mit der gew
unschten Co detab elle
geladen werden. Eine
Anderung der eingestellten Konguration w
ahrend der Kompres-
sion eines Datensatzes ist nicht vorgesehen. Nach der vollst
andigen Verarb eitung eines
Datensatzes k
onnen hingegen ohne Probleme neue Kongurationsdaten geladen werden.
Der Ablauf der Kompression ist vereinfacht dargestellt in Abbildung 5.13 als Zustands-
diagramm zu sehen. Dieses Zustandsdiagramm veranschaulicht die Arb eit von sogenann-
ten
State Machines
(FSMs). Eine State Machine, o der Zustandsmaschine, wechselt ihren
Zustand in Abh
angigkeit vom augenblicklichen Zustand und externen Signalen. Der ak-
tuelle Zustand wird im
State Register
gesp eichert. Dargestellt sind die State Machines
von CUN Control und Event Readout. In der Mitte ist eine State Machine mit nur zwei
Zust
anden zu sehen, die die Kompression symb olisiert.
Gestartet werden CUN Control und Event Readout
ub er das Signal
FeEventAvaila-
ble
, das vom FeASIC Interface gesetzt wird, sobald ein Event Buer mit einem Datensatz
gef
ullt ist. In der CUN Control wird als erstes das Schreib en des Headerwortes in den Pre-
Main Buer erledigt. Im Event Readout wird zur gleichen Zeit die Auslese aus den Event
Buern gestartet und mit dem ersten ausgelesenen Datum das entsprechende Kompressi-
5.5. BETRIEB DER KOMPRESSIONSEINHEIT
67
Signale, die zum Zustandswechsel
führen
Sprung in einen neuen Zustand
Starte Kompression
Fertig
Bereitschaft
Bereitschaft
Warten
Datum
auslesen
Letztes Datum
Ende
FeEventAvailable
FeEventAvailable
Gültiges Datum
32 bit Wort ist gültig
Kompression
Bereitschaft
Schreibe
Headerwort
Warten
Schreibe
Datenwort
in Pre-Main
Buffer
Ende
Compression Modules
und Shifting Unit
Letztes Datum
CUN Control
Event Readout
Abbildung 5.13: Zustandsdiagramm f
ur die Auslese und Kompression eines Datensatzes
68
KAPITEL 5. DIE KOMPRESSIONSEINHEIT
ComprBusy
Clock
FeEventAvailable
ComprEventBusy
MainBufferWriteOutBusy
Abbildung 5.14: Signale b eim Betrieb der Kompressionseinheit
onsmo dul aktiviert. W
ahrend der Kompression werden g
ultige 32 bit W
orter signalisiert,
worauf die CUN Control mit einem Zustandswechsel reagiert und das Datenwort in den
Pre-Main Buer geschrieb en wird. Die Datenw
orter k
onnen nicht direkt von der Shifting
Unit in den Pre-Main Buer geschrieb en werden, da nur
ub er diesen Zwischenzustand auf
den Sonderfall des letzten Datenwortes reagiert werden kann. Tritt n
amlich b eim letzten
Wort ein
Ub erlauf in der Shifting Unit auf, so mu gewartet werden, bis der
Ub erlauf im
aktiven Register steht und in den Pre-Main Buer geschrieb en werden kann. Ansonsten
ginge der eventuell vorhandene
Ub erlauf verloren. Ist der Event Readout fertig mit der
Auslese, so wird dies an das aktive Kompressionsmo dul signalisiert, das daraufhin die
Verarb eitung b eendet und der CUN Control das Ende der Kompression signalisiert. Die
dicken Pfeile deuten an, da die State Machines nach erreichen des Endzustandes wieder
in den Ausgangszustand zur
uckkehren.
W
ahrend ihrer Arb eit werden von der Kompressionseinheit zwei Signale generiert, die
die Aktivit
at nach auen signalisieren. F
ur das FeASIC Interface ist dies
ComprEventBusy
,
f
ur das Pip elineBus Interface
ComprBusy
(siehe Abbildung 5.14). Solange ComprEvent-
Busy gesetzt ist, wird vom FeASIC Interface kein FeEventAvailable gegeb en. ComprE-
ventBusy bleibt auf logisch Eins, solange ein Datensatz komprimiert wird, geht jedo ch auf
logisch Null b evor der Pre-Main Buer in den Main Buer geschrieb en wird. Das Schrei-
ben des Datensatzes in den Main Buer wird in Abbildung 5.14 symb olisiert durch das
interne Signal
MainBuerWriteOutBusy
. Dem Pip elineBus Interface wird
ub er das set-
zen von ComprBusy verb oten die Sp eicher der Kompressionseinheit zu kongurieren o der
eine Auslese derselb en zu starten. Dieses Signal bleibt solange gesetzt, bis ein Datensatz
komplett im Main Buer abgelegt ist.
Es kann passieren, da die Kompressionseinheit nicht auf ein gesetztes FeEventAvaila-
ble reagiert. Um unvorhersehbares Verhalten zu verhindern geschieht dies in folgenden
F
allen:
Es wurde kein FeASIC Port konguriert, also kann auch nichtkomprimiert werden.
Die Kompressionseinheit ist no ch b esch
aftigt.
Ist die Kompressioneinheit no ch mit dem Schreib en eines Datensatzes aus dem Pre-Main
Buer in den Main Buer b esch
aftigt, w
ahrend der n
achste b ereits fertig komprimiert
wurde, so bleibt ComprEventBusy weiterhin gesetzt, um einen Datenverlust zu vermeiden.
5.5. BETRIEB DER KOMPRESSIONSEINHEIT
69
Diese Situation tritt vor allem dann auf, wenn das Schreib en in den Main Buer unterbro-
chen werden mu, weil er voll ist. Das b edeutet allerdings, da die Auslese sto ckt. Man
verliert dann eventuell einen kompletten Datensatz, f
ur den inzwischen ein Level-1 Accept
gegeb en wurde. Daf
ur ist sichergestellt, da ein ausgelesener Datensatz stets komplett im
Main Buer steht. Es werden also keine bruchst
uckhaften Datens
atze ausgelesen, statt
dessen verzichtet man in so einem Fall lieb er auf einen anderen Datensatz.
F
ur den seltenen Fall, da ein Datensatz sich b ei der Kompression so stark aufbl
aht,
da er nicht mehr in den Pre-Main Buer pat, wird die Kompression im NoOp eration-
Mo dus wiederholt, und der Datensatz unkomprimiert
ub ertragen. Angezeigt wird dies
durch setzen eines bits im Headerwort (siehe auch Anhang B).
Kapitel 6
Erster Test des RemASIC
Ein erster Test des RemASIC sollte die prinzipielle Funktionsf
ahigkeit des Chips unter
Beweis stellen. Hierzu wurde ein einfaches Testb oard entwickelt. Die Leistungsf
ahigkeit
des Pip elineBus-Systems zusammen mit der Datenkompression l
at sich jedo ch erst mit
einem Testsystem messen, das zur Zeit von der Elektronikwerkstatt des Instituts f
ur Ho ch-
energiephysik gebaut wird.
6.1 Testaufbau
F
ur den Test wurde ein HP82000 Chip-Tester verwendet. Es standen 48 Kan
ale f
ur die
Bedienung von Eingangs- und die Aufnahme von Ausgangssignalen zur Verf
ugung. Da f
ur
einen parallelen Betrieb des Pip elineBus Interface alleine 70 Leitungen b en
otigt w
urden,
mute f
ur diesen Test auf den seriellen Betrieb ausgewichen werden, in dem
ub er ein Schie-
b eregister die 35 bit eines Pip elineBus-Wortes seriell eingelesen werden. Das b edeutet, da
die Taktfrequenz des seriellen Interface das 35-fache der Bus Clo ck
1
b etragen mu.
Der HP82000 bietet 40 Kan
ale f
ur einen Betrieb mit 100 MHz und 8 Kan
ale, die mit
bis zu 400 MHz b etrieb en werden k
onnen. Die verwendete Software zum Erzeugen von
Testvektoren f
ur den HP82000 l
at eine parallele Nutzung von 100 MHz und 400 MHz
Kan
alen nur eingeschr
ankt zu. F
ur die 400 MHz Kan
ale werden automatisch pro Takt-
zyklus vier identische Testvektoren erzeugt, so da auch die 400 MHz Kan
ale nur bis
maximal 100 MHz b etrieb en werden k
onnen [28]. Damit stehen f
ur den Test also eektiv
48 100 MHz Kan
ale zur Verf
ugung. Daraus ergibt sich eine maximale Taktfrequenz des
RemASIC zu:
f
=
100 MHz
35
=2
:
86 MHz
:
(6.1)
Ein Test des RemASIC bei der f
ur den Betrieb vorgesehenen Taktfrequenz von 40 MHz
ist also erst mit dem in Planung b endlichen Testsystem m
oglich. Ein Test darf maximal
256000 Testvektoren pro Kanal umfassen. Da dies auchf
ur die 400 MHz Kan
ale gilt und
f
ur ein Pip elineBus-Wort 35 Vektoren b en
otigt werden, lassen sichTests mit maximal 1800
Taktzyklen der Bus Clo ck aufsetzen.
1
Bus Clock: Systemtakt von RemASIC und Pip elineBus.
70
6.2. TESTSTRATEGIE
71
Eine Skizze des Testaufbaus ist in Abbildung 6.1 zu sehen. Es gibt einen So ckel f
ur
einen RemASIC und einen f
ur die Aufnahme eines FeASIC (graue Bl
ocke). Der FeASIC ist
an Port 1 angeschlossen. Port0l
at sich
ub er den Tester b edienen. F
ur Port 2 und 3 sind
eb enfalls Verbindungen zum Tester vorgesehen, die jedo ch erst genutzt werden k
onnen,
wenn 16 zus
atzliche Kan
ale f
ur den Tester zur Verf
ugung stehen.
6.2 Teststrategie
F
ur den HP82000 existiert eine Software zum direkten Eingeb en und Editieren von Test-
vektoren. F
ur den Test des RemASIC ist diese allerdings untauglich, da jedes Pip elineBus-
Wort serialisiert und bit f
ur bit eingegeb en werden m
ute. Es wurde statt dessen ein
Programm verwendet, das aus den f
ur die Simulation verwendeten STL-Programmen au-
tomatischTestvektoren f
ur den HP82000 erzeugt [28 ].
Das Verilog-Mo dul f
ur den RemASIC wird in ein Mo dul eingebunden, dessen Ein- und
Ausg
ange genau denen des Testaufbaus entsprechen. F
ur dieses Mo dul wird ein Testpro-
gramm in STL entwickelt und mit der Netzliste des RemASIC simuliert. Im n
achsten
Schritt wird das STL Programm in HP82000 Testerco de
ub ersetzt. Dab ei k
onnen auch
die simulierten Ausgangssignale als sogenannter
Expected Output
miteinb ezogen werden.
L
at man anschlieend den Test auf dem Chip-Tester ablaufen, so kann man sich alle
Abweichungen der Ausg
ange vom Exp ected Output anzeigen lassen. Dadurch wird ein
komfortables Testen m
oglich, denn f
ur die Simulation k
onnen in Verilog Zusatzmo dule ge-
schrieb en werden, die zum Beispiel die Geschehnisse auf dem Bus mitprotokollieren. Mit
Hilfe dieser Mo dule ist eine einfache Verikation der Ergebnisse der Simulation m
oglich.
Anschlieend mu nur no ch die
Aquivalenz von Test und Simulation
ub erpr
uft werden,
was Dank des Exp ected Output aus der Simulation auf Knopfdruck erfolgt.
In STL wird jeder Testvektor mit einem
xv
Befehl erzeugt. Er hat das Format xv(input1
input2 ...). Es werden also einfach die Werte s
amtlicher Eingangssignale hintereinander-
gereiht. Auf diese Weise lassen sichnochkeine aufwendigen Tests programmieren. In STL
kann jedo ch der gesamte Sprachumfang von Skill, einer Lisp
ahnlichen Sprache, verwendet
werden. Damit lassen sich dann ganze Folgen von xv Befehlen zu einem Unterprogramm
zusammenfassen und mit einem Befehl aufrufen. So konnte f
ur den RemASIC eine Te-
stumgebung entwickelt werden, die eine einfache Formulierung der Tests erm
oglicht. Ein
Beispielprogramm f
ur einen Test der Kompressionseinheit ist in Abbildung 6.2 zu sehen.
Ein Test kann nicht mehr als 1800 Taktzyklen der Bus Clo ck umfassen (siehe 6.1).
Alleine zum Kongurieren des gesamten Enco der RAMs w
urden jedo ch
ub er 3000 Taktzy-
klen b en
otigt. Die Tests muten sich daher darauf b eschr
anken jeweils ein wohl deniertes
Teilst
uck der gesamten Funktionalit
at zu
ub erpr
ufen. Das Human Co ding b eispielsweise
kann auch mit einem teilweise kongurierten Enco der RAM getestet werden, wenn b ei der
Auslese nur Energiewerte verwendet werden, f
ur die ein Co de gesp eichert ist. Ein Test,
der die Gesamtfunktionalit
at auf einmal veriziert w
are zwar w
unschenswert, ist jedo ch
mit der eingeschr
ankten Zahl der Testvektoren nicht zu realisieren.
72
KAPITEL 6. ERSTER TEST DES REMASIC
SpyBusOut<0:7> [Pins 73-80, N11-13,P8-12]
Lvl1Accept [Pin 6, G1]
BcClk [Pin 171, B3] Clock 40Mhz [Pin 65]
Lvl1Accept [Pin 64]
SpyBusCtrl<0:2> [Pins 39-37]
FeAsicIoRdy<1> [Pin 13, H2]
FeAsicIoIn<1> [Pin 145, B13]
SerialRdy [Pin 32]
FeAsicIoClk<0,2,3>
FeAsicIoAck<0,2,3>
[Pin 138, D9]
[Pin 142, A11]
[Pin 143, A10]
FeAsicIoOut<0,2,3>
[Pin 8, C2]
[Pin 10, E2]
[Pin 11, F2]
[Pin 134, B15]
[Pin 132, D15]
[Pin 128, B14]
FeAsic
Lvl1Number<0:3> [Pins 174,176,178,180, A7,A5,A3,A1]
SerialOut [Pin 35]
FeAsicIoIn<0,2,3>
FeAsicIoRdy<0,2,3>
ReadDataRdy [Pin 169, B5]
Lvl1Throttle [Pin 17, G3]
*SerialPipeOut [Pin 166, B8]
Input: Links
Output: Rechts
*: 400Mhz Kanal
48 Testerkanäle werden benutzt
SpyBusCtrl<0:2> [Pins 156-158, D6,D5,E8]
SerialPipeEnbl [Pin 160, C8]
*SerialPipeClk [Pin 161, C7]
*SerialPipeAck [Pin 162, C6]
*SerialPipeIn [Pin 164, C4]
ListenFlagIn [Pin 4, E1]
Reset_ [Pin 165, C3]
BistTest [Pin 172, B2]
RemAsic
[Pin 144, A9]
[Pin 146, B12]
[Pin 147, B11]
[Pin 12, G2]
[Pin 14, D3]
[Pin 15, E3]
FeAsicIoOut<1> [Pin 9, D2]
FeAsicIoAck<1> [Pin 140, A13]
FeAsicIoClk<1> [Pin 130, F15]
ListenFlag [Pin 170, B4]
StRegReset [Pin 81, P13]
SyncReset [Pin 168, B6]
[B10-9,C12-9,D8-7]
SerialClk [Pin 33]
SerialAck [Pin 34]
SerialInp [Pin 36]
ListenFlag [Pin63]
StRegReset [Pin 16]
SpyBusOut<0:7>
SyncReset [Pin 15]
[Pins 51-58]
BusClk [Pin 70, N8]
SpyBusIn<0:7> [Pins 148-155]
FeAsicIoIn<0,2,3>
FeAsicIoRdy<0,2,3>
BusParityOut [Pin 18, H3]
BusDataOut<0:5>,<30:31> [Pins 22-25,27,28,67,68, H4,H5,J4,K4,M4,J3,M11,L8]
Abbildung 6.1: Verschaltung von RemASIC und FeASIC im Testaufbau
6.2. TESTSTRATEGIE
73
;--------------------Konfiguration des RemASIC---------------
SpyBusCtrl = 3
DisableSerAck ;---Reset--
Reset 1 1 1
Reset 1 1 1
EnableSerAck
Address = 0 ;--Laden der PipelineBus Adresse
LoadNodeAddress 4
Address = 4
StartInput ;--Laden des Event Buffers mit Daten
ConfigureEventBufferFileCons 3 "./ramdata/rem_evram.dat.old2"
;-----------Konfiguration der Kontrollregister fur------------
;-------------die Auslese im Difference Modus-----------------
StartInput
BeginOfData RD_ControlRegister
PortMask = 0x01
DaisyChainCount = 0x00
BcPerEvent = 0x07
ComprMode = 0x03
ReadoutMode = 0x3
SelectFeWord = 0
EventBufferSource = 1
PreMainBufferSource = 0
PreMainBufferSelect = 0
StopModeEvents = 0x0
ComprParameter = 0x2
ListenFlag = 0
EnableExtListen = 0
ConfigureCtrlRegs
EndOfData
BusIdle 4*9+20
StartReadout ;--Start der Auslese
BusIdle 50
StopReadout ;--Stop der Auslese
GetEventCounter ;--Auslesen des komprimierten Datensatzes uber
FlushMainBuffer ;--den PipelineBus
BusIdle 15
Abbildung 6.2: Ein einfaches STL-Programm f
ur den Test des Dierence Mo dus
74
KAPITEL 6. ERSTER TEST DES REMASIC
6.3 Ergebnisse
Acht RemASICs standen f
ur einen Test zur Verf
ugung. Drei von ihnen wiesen Fehler auf.
Im einzelnen sind dies:
Kurzschlu der Stromversorgung
Fehler in den Compiled Megacells (Main Buer)
Fehler in den Standardzellen (Event Readout der Kompressionseinheit)
Der Kurzschlu wurde festgestellt, da der Chip bei einem Test keine Reaktion zeigte
und b ei einer anschlieenden Messung einen stark erh
ohten Stromverbrauch aufwies. Der
Fehler im Main Buer wurde
ub er den BIST-Test gefunden, der keine korrekten Ergebnisse
lieferte. Ein nachtr
aglich durchgef
uhrter Test zeigte dann auch, da Daten, die durch
den Main Buer liefen, ver
andert wurden. Der Fehler in den Standardzellen
auerte
sich
ub er ein falsches Ergebnis b ei der Kompression von Testdaten. Er konnte
ub er den
SpyBus als Standardzellenfehler im Event Readout identiziert werden. Ein Flipop eines
Adressz
ahlers schaltet von logisch Null auf logisch Eins und bleibt in diesem Zustand bis
zum n
achsten Reset. Eine
Anderung des Zustandes
ub er das Sp eichern einer Null ist nicht
m
oglich. Dadurchwerden Daten an falschen Adressen aus dem Event Buer ausgelesen.
Die restlichen Chips b estanden s
amtliche durchgef
uhrten Tests. Ein Test gilt als be-
standen, wenn keine Abweichungen zwischen den tats
achlich gemessenen und den von der
Simulation her erwarteten Ausgangssignalen b estehen. Ein Bild der Testsoftware mit ei-
nem b estandenen Test ist in Abbildung 6.3 zu sehen. Neb en einem Test von Pip elineBus
und FeASIC Interface wurden f
ur s
amtliche Sp eicher die BIST-Test durchgef
uhrt.
F
ur die Kompressionseinheit wurden s
amtliche Kompressionsmo di und die Funkti-
onsf
ahigkeit des Event Readout exemplarisch getestet. F
ur das Human Co ding wurden
die Zahlen von von 0 bis 15 in aufsteigender Reihenfolge komprimiert. Dadurch war es
m
oglichnur die ersten 16 Adressen des Enco der RAMs mit Co dew
ortern zu b elegen und die
Anzahl der Testvektoren klein zu halten. Beim Human Co ding treten keine Sonderf
alle
auf, die vermuten lassen k
onnten, da dieser Test zur Verikation der Funktionsf
ahigkeit
nicht ausreicht.
Bei den anderen Co dierungsverfahren mute anders vorgegangen werden. Je nach
Aussehen und Reihenfolge der Daten wird die Funktionalit
at der Mo dule mehr o der weni-
ger genutzt. Wird b eispielsweise Run-Length Enco ding mit einem Datensatz ohne Nullen
durchgef
uhrt, so b edeutet eine korrekte Co dierung no ch nicht, da auch ein Run-Length
Enco ding mit Nullen erfolgreich ist. Daher wurde hier der Datensatz 1-255-2-1-255-2
verwendet. Indem man die Referenzenergie
E
R
f
ur das Human-Inspired Co ding und
den Energie-Cut f
ur das Run-Length Enco ding auf zwei einstellt, erh
alt man einen Test
s
amtlicher Sonderf
alle diese Co dierungsarten. Auch b eim Dierence Co ding ist mit diesem
Datensatz ein Test der gesamten Funktionalit
at sichergestellt.
F
ur den Event Readout wurde durch die Verwendung einer Konguration mit Adressen
in nichtkonsekutiver Reihenfolge die korrekte Funktion von Adressspr
ungen getestet. Ein
Fehler in der Kompressionseinheit wurde b ei den Tests allerdings entdeckt. Er ist jedo ch
nicht auf eine Abweichung zwischen Simulation und echtem Chip zur
uckzuf
uhren, sondern
6.3. ERGEBNISSE
75
Ausgangsdaten des PipelineBus
Test wurde ohne
Fehler bestanden
Signale für das seirielle Interface
des PipelineBus
Eingangsdaten des PipelineBus
Abbildung 6.3: Abbildung der Testsoftware mit b estandenem Test
76
KAPITEL 6. ERSTER TEST DES REMASIC
ist in einem Fehler im Verilogco de b egr
undet. Durch diesen Fehler versagt die erneute
Kompression im NoOp eration-Mo dus, falls der Datensatz nicht in den Pre-Main Buer
pat. Dieser Fehler ist
argerlich, stellt ab er kein Hindernis b eim Einsatz des RemASIC
dar, da selbst im ung
unstigsten Fall (es werden nur 23 bit Humanco des pro duziert) 64
Datenw
orter b earb eitet werden k
onnen. Die Auslese von acht Kan
alen bei acht Bunch-
Crossings pro Event ist also selbst dann no chm
oglich.
Zusammenfassung und Ausblick
Datenkompression ist eine M
oglichkeit die ben
otigte Bandbreite f
ur die Auslese eines
Ho chenergiephysik-Exp erimentes zu reduzieren. Dadurch wird die Verwendung kosten-
g
unstiger Bussysteme m
oglich. Auerdem werden Kosten f
ur Massensp eicher-Medien ge-
spart. Mit der Implementation einer Datenkompressionseinheit auf dem Readout Merger
ASIC wurde die prinzipielle Machbarkeit der Kombination aus Datenkompression und
Pip elineBus gezeigt.
Vor der Implementation wurden alle Algorithmen mit Testdaten simuliert. Demnach
k
onnen Kompressionsfaktoren von 2-3 erreichtwerden, wenn die Daten in vollem Umfang
samt Rauschen ausgelesen werden sollen. Akzeptiert man einen Energie-Cut von 1 GeV,
so l
at sich das Datenvolumen um einen Faktor 13 reduzieren. Durch die Implementation
von vier verschiedenen Algorithmen b esteht die M
oglichkeit die Vor- und Nachteile der
einzelnen Verfahren in einem Praxistest zu untersuchen.
In einem ersten Test, der allerdings nur mit knapp 3 MHz durchgef
uhrt werden konnte,
wurde gezeigt, da der RemASIC dieselb e Funktionalit
at aufweist, wie in der Simulation.
Die Konguration der Kontrollregister und eine Kompression einiger ausgew
ahlter Bei-
spieldaten verlief erfolgreich. Ein Test mit der geplanten Taktfrequenz von 40 MHz und
eine Verikation der vorhergesagten Kompressionsraten mit Datens
atzen aus Teststrahl-
Exp erimenten steht no ch aus. Auch eine stabile Funktion b ei der Verarb eitung umfang-
reicher Datens
atze sollte untersuchtwerden.
F
ur einen Einsatz im nalen System sind sicherlich no ch eine ganze Reihe von Ver-
b esserungen des Kompressionskonzeptes m
oglich. So sollte man sichf
ur die Verwendung
eines Algorithmus entscheiden und die Hardware daraufhin optimieren. Die implementier-
ten Verfahren stellen eine Auswahl verschiedener M
oglichkeiten dar, es sollte jedo ch nach
weiteren Alternativen gesucht werden. Zuerst sollte die Entropie der Daten mit einem
geeigneten Verfahren m
oglichst minimiert und der Datenumfang reduziert werden. Hier
bietet sich neb en dem Dierence Co ding auch eine Co dierung der Dierenzen zu einem
fest gesp eicherten Referenzpuls an. Anschlieend k
onnten diese Daten dann mit einem ad-
aptiven Verfahren (zum Beispiel adaptives Human Co ding) weiter komprimiert werden.
Der Vorteil eines adaptiven Verfahrens liegt in der automatischen Anpassung an wechseln-
de Wahrscheinlichkeiten. Bei diesen Verfahren kann auerdem auf die Sp eicherung eines
Co debaumes verzichtet werden, da er im Datensatz integriert ist. Dieses Verfahren wurde
im Rahmen der Diplomarb eit nicht untersucht, da seine Implementation f
ur den knapp
gesteckten Zeitrahmen zu aufwendig ist. Auch
ub er eine Fehlerkorrektur (zum Beispiel
Cyclic Redundancy Check
) sollte nachgedachtwerden.
77
Anhang A
Grundlagen der
Informationstheorie
Die Informationstheorie b esch
aftigt sich mit der mathematischen Beschreibung von Infor-
mation und Kommunikation im weitesten Sinne. Als Begr
under der Informationstheorie
gilt
Claude Shannon
, der in seinem 1948 ver
oentlichten Artikel \A mathematical theory
of communication" [29] die Wahrscheinlichkeitstheorie zur Beschreibung von Kommuni-
kation verwendete. Im folgenden sollen die f
ur das weitere Verst
andnis wichtigen Begrie
erl
autert werden.
A.1 Entropie und Information
Der Begri der Entropie stammt urspr
unglich aus der Physik. Er wurde 1854 von Rudolph
Clausius als Zustandsgr
oe in die Thermo dynamik eingef
uhrt. Mit der Denition der
Entropie als
H
=
,
k
B
X
k
p
k
ln
p
k
(A.1)
k
B
: Boltzmann Konstante
p
k
: Wahrscheinlichkeit des Zustandes mit der Nummer
k
durch Boltzmann
ub ernahm die Entropie eine zentrale Rolle in der statistischen Physik.
Wie sich herausstellen wird, sind die Entropie in der Physik und in der Informationstheorie
bis auf einen Faktor identisch. W
ahrend jedo ch in der Physik Ensembles von Teilchen
in verschiedenen (Quanten-) Zust
anden b etrachtet werden, interessiert man sich in der
Informationstheorie f
ur Ensembles von Zeichen.
Um die weiteren Betrachtungen zu vereinfachen, soll davon ausgegangen werden, da
die Zeichen aus einem endlichen Vorrat stammen. Diesen b ezeichnet man als Alphab et.
Mathematisch b edeutet das folgendes.
Denition A.1
Ein Alphabet
A
=
f
a
1
; :::; a
N
g
ist die Menge al ler Zeichen, die zur Bil-
dung einer Nachricht zur Verf
ugung stehen. Mit
j
A
j
wird die Zahl der Elemente von
A
bezeichnet:
j
A
j
=
N
.
79
80
ANHANG A. GRUNDLAGEN DER INFORMATIONSTHEORIE
Denition A.2
Ein Ensemble
S
ist ein Alphabet
A
mit zugeordneten Wahrscheinlichkei-
ten f
ur das Auftreten der Zeichen
p
k
:=
p
(
a
k
)
. Es gelte auerdem:
P
N
k
=1
p
k
=1
.
Man m
ochte nun gerne ein Ma f
ur die Information hab en, die mit der
Ub ertragung
eines Zeichens aus einem b estimmten Ensemble verkn
upft ist. Oder, um es von der anderen
Seite zu b etrachten, ein Ma f
ur die Unsicherheit vor der
Ub ertragung dieses Zeichens.
Dieses Ma ist die Entropie.
Denition A.3
Die Entropie eines Ensembles
S
ist gegeben durch
H
(
S
)=
,
N
X
k
=1
p
k
log
p
k
:
(A.2)
Die Boltzmann-Konstante, die in der Physik f
ur Identit
at von statistischer und thermo-
dynamischer Entropie makroskopischer Systeme sorgt, ist hier nat
urlich verschwunden.
Auerdem ist die Basis des Logarithmus no ch nichtn
aher deniert.
Die wichtigsten, auch aus der Physik bekannten, Eigenschaften der Entropie werden
im folgenden angef
uhrt. Auf einen Beweis wurde hier, wie auch b ei allen folgenden S
atzen
verzichtet.
Satz A.1
H
(
S
)
0;
H
(
S
)=0
,9
1
k
:
p
k
=1
;p
i
6
=
k
=0
.
Satz A.2
H
(
S
)
log
N:
Das Gleichheitszeichen gilt genau dann, wenn
p
1
=
p
2
=
:::
=
p
N
=
1
N
.
Satz A.3
F
ur zwei unabh
angige Ensembles
S
1
;S
2
gilt
H
(
S
1
;S
2
)=
H
(
S
1
)+
H
(
S
2
)
.
Es stellt sich nun no ch die Frage nach einer zweckm
aigen Wahl f
ur die Basis der
Logarithmen. Da Informationsverarb eitung praktisch immer eine Darstellung der Daten
in bin
arer Form erfordert, ist die Wahl des Zweierlogarithmus sinnvoll:
H
(
S
)=
,
1
ln 2
N
X
k
=1
p
k
ln
p
k
; [
H
]=
bit:
(A.3)
Betrachtet man ein Alphab et, das nur aus zwei Zeichen b esteht, zum Beispiel
A
=
f
0
;
1
g
, so sieht man sofort, was durch diese Normierung erreicht wird. Es gilt n
amlich:
H
1
bit
. Vor einer 0/1-Entscheidung herrscht also ein Informationsmangel
ub er das
System von h
ochstens einem bit. Das b edeutet also, da man nach der (st
orungsfreien)
Ub ertragung der Entscheidung eine Information
ub er das System von h
ochstens einem bit
b esitzt. In diesem Sinne dient also die Entropie als Ma f
ur die in einem System enthaltene
Information.
A.2. CODIERUNGSTHEORIE
81
A.2 Co dierungstheorie
Die Frage im vorangegangenen Abschnitt lautete, wie gro ist der Informationsgehalt eines
Ensembles, also eines Alphab etes mit einer b estimmten Wahrscheinlichkeitsverteilung der
einzelnen Zeichen. Gegenstand dieses Abschnitts ist nun die Co dierung einer Nachricht.
Denition A.4
Eine Nachricht (
Message
)
M
ist eine Folge von Zeichen aus einem En-
semble.
Denition A.5
Unter einem Code sol l eine eineindeutige Abbildung der Zeichen eines
Quel lalphabets
A
auf Zeichen(folgen) des Codealphabets
C
verstanden werden. Diese Zei-
chenfolgen bezeichnet man als Codew
orter. Dabei ist im al lgemeinen
j
A
j6
=
j
C
j
.
Um die weiteren Betrachtungen zu vereinfachen, soll davon ausgegangen werden, da
die Zeichen einer Nachricht unabh
angig voneinander gesendet werden. Eine Nachricht
mit
n
Zeichen ist also nichts anderes, als ein m
ogliches Ergebnis eines
n
-mal hintereinan-
der ausgef
uhrten Zufallsexp eriments. Es gilt
p
(
a
i
a
j
) =
p
i
p
j
. Diese Einschr
ankung trit
nat
urlich in der Realit
at nicht immer zu, so wird zum Beispiel ein
u
nach einem
q
in der
deutschen Sprache viel wahrscheinlicher sein als ein
x
.
Besonders interessant ist die Frage, wieviele Zeichen man zur Co dierung eines Zeichens
aus einem Ensemble
S
braucht, wenn
C
=
f
0
;
1
g
, also wieviele bits b en
otigt werden, um
ein Zeichen aus
S
zu
ub ertragen. Deswegen wird im folgenden der Schwerpunkt b ei der
Bin
arco dierung liegen.
A.2.1 Blo ckco des
Unter einem Blo ckco de versteht man die Co dierung aller Zeichen eines Ensembles mit
Co dew
ortern gleicher L
ange. Der ASCI I-Co de zur Darstellung von Tastaturzeichen im
Computer ist ein Beispiel f
ur einen Blo ckco de.
Bezeichnet man die Zahl der Zeichen im Quellalphab et mit
N
und im Co dealphab et
mit
K
und stellt die Forderung, da f
ur jedes Quellzeichen ein eigenes Co dewort vorhanden
ist, gelangt man zu der Ungleichung:
N
n
K
l
, wob ei
n
die L
ange der Nachricht und
l
die L
ange des Co des b ezeichnet. Eine untere Grenze f
ur die Co del
ange ist also:
l
n
log
N
log
K
:
(A.4)
Diese Ungleichung ist vollkommen unabh
angig von der Entropie der Quelle, also von den
Wahrscheinlichkeiten der einzelnen Zeichen. Betrachtet man hingegen den Limes
n
!1
,
so l
at sich folgender Satz von Shannon b eweisen:
Satz A.4
Im Limes
n
!1
gilt f
ur die Codel
ange
l
n
H
(
S
)
log
K
mit beliebig kleinem Verlust
an Information.
Der Beweis l
at sich nachlesen in [30] o der [31 ]. Dieser Satz stellt eine Verbindung zwischen
der L
ange eines Co dewortes und der Entropie eines Datensatzes her.
82
ANHANG A. GRUNDLAGEN DER INFORMATIONSTHEORIE
A.2.2 Co des mit variabler L
ange
Es sollen nun Co des b etrachtet werden, deren L
ange von Zeichen zu Zeichen variiert. Man
b ezeichnet solche Co des auch als
Variable Length Codes
. Der groe Vorteil von Variable
Length Co des gegen
ub er Blo ckco des liegt in der M
oglichkeit h
aug auftretenden Zeichen
kurze Co des zuzuweisen und seltenen daf
ur l
angere, so l
at sich im Mittel die Anzahl der
zu
ub ertragenden bits pro Zeichen reduzieren. Da man nicht mehr von
der
Co dewortl
ange
sprechen kann, soll das Symbol
l
i
eingef
uhrt werden, das die L
ange des Co dewortes f
ur
a
i
b ezeichnet. Die Betrachtungen in diesem Abschnitt b eschr
anken sich auf bin
are Co des.
Entropie und Wortl
ange werden in bits gemessen.
Wie man sich leicht klar macht, l
at sich nicht aus jedem Variable Length Co de die
Ausgangsnachricht eindeutig repro duzieren. Man stellt deswegen die Forderung der ein-
deutigen Deco dierbarkeit.
Denition A.6
Ein Code wird als eindeutig decodierbar bezeichnet, wenn jede beliebige
Nachricht ihren eigenen Code hat.
Eine f
ur die praktische Anwendung wichtige Klasse von Co des, die diese Forderung erf
ullt,
sind die
Prex Codes
.
Denition A.7
Ein Code heit Prex Code, wenn kein Codewort Pr
ax eines anderen
ist.
Es l
at sich, zum Beispiel durch explizite Konstruktion, zeigen, da nicht jeder eindeutig
deco dierbare Co de ein Prex Co de sein mu. Andererseit gilt folgender Satz, dessen
Beweis sich zum Beispiel in [30 ] ndet.
Satz A.5
Jeder eindeutig decodierbare Code l
at sich durch einen Prex Code ersetzen,
ohne die L
angen der Codew
orter zu ver
andern.
Prex Co des lassen sich sehr gut
ub er bin
are B
aume konstruieren. Ein Blatt b ezeich-
net das zu co dierende Quellzeichen. Der Co de wird durch den Weg zu diesem Blatt re-
pr
asentiert, wob ei eine Verzweigung nach links zum Beispiel eine Null b edeutet, eine nach
rechts eine Eins. Dadurch, da nach einem Blatt keine Zweige mehr kommen k
onnen, hat
man automatisch Bedingung A.7 erf
ullt. Ein Beispielbaum ist in Abbildung A.1 zu sehen.
Als Zeichen wurden Energiewerte verwendet, wie man sie bei der Auslese des ATLAS
Kalorimeter Level-1 Triggers erwartet.
Bis jetzt wurde no chkeine Aussage dar
ub er gemacht, wie gut sich eine Nachricht mit
einem Prex Co de co dieren l
at. Ein Ma f
ur die G
ute der Kompression ist die mittlere
Wortl
ange
l
(
C; S
):=
N
X
k
=1
p
k
l
k
:
(A.5)
Die Argumente
C
und
S
sollen anzeigen, da
l
von der gew
ahlten Co dierung
C
abh
angig
ist und sich die Mittelwertbildung
ub er das Ensemble
S
erstrecken soll. Davon zu un-
terscheiden ist
l
(
C; M
), die mittlere Co dewortl
ange f
ur eine b estimme Nachricht. Die
A.2. CODIERUNGSTHEORIE
83
2GeV
1GeV
Wurzel
1
1
1GeV: 0
2GeV: 10
3GeV: 111
4GeV: 110
01
0
4GeV 3GeV
0
Knoten
Blätter
Abbildung A.1: Co debaum f
ur einen Prex Co de
Mittelwertbildung l
auft hier
ub er die relativen H
augkeiten
h
k
der Zeichen in der Nach-
richt
l
(
C; M
):=
N
X
k
=1
h
k
l
k
:
(A.6)
Es l
at sichnun folgender Satz b eweisen:
Satz A.6
F
ur jedes Ensemble
S
existiert ein Prex Code, f
ur den gilt
H
(
S
)
l
(
C; S
)
H
(
S
)+1
:
(A.7)
Man bezeichnet ihn als optimalen Code.
Den Beweis ndet man wieder in [30]. Dieser Satz b edeutet, da man b ei der Co dierung
mit einem optimalen Prex Co de maximal ein bit
ub er der theoretisch erreichbaren Mini-
mall
ange liegt. W
urde
l
n
amlichunter
H
(
S
) absinken, w
are damit ein Informationsverlust
verbunden, die Nachricht liee sich nicht mehr vollst
andig rekonstruieren.
Nachdem nun bekannt ist, da es einen optimalen Co de gibt, interessiert man sich
als Anwender daf
ur, wie sich ein solcher Co de explizit konstruieren l
at. In der Praxis
verwendet man hierf
ur den
Human Algorithmus
. Er wird b ei der Diskussion der Kom-
pressionsalgorithmen genauer erl
autert.
Um keine Miverst
andnisse aufkommen zu lassen, sei zum Abschlu no ch darauf hin-
gewiesen, da die mittlere Co dewortl
ange f
ur eine sp ezielle Nachricht
l
(
C; M
) nat
urlich
deutlich
ub er
l
(
C; S
) liegen kann. Dies wird immer dann der Fall sein, wenn Zeichen, die
in
S
eine geringe Wahrscheinlichkeit hab en, in der Nachricht
M
mit groer H
augkeit
auftreten. Im Grenzfall unendlich langer Nachrichten gilt:
l
(
C; M
)=
l
(
C; S
) (A.8)
Anhang B
Op erations- und Testmo di der
Kompressionseinheit
Die Bedienung der Kompressionseinheit ist Gegenstand dieses Anhangs. Zun
achst wird
die Konguration
ub er verschiedene Register des RemASIC b eschrieb en und dann die
Kompressions- und Testmo di. Am Schlu wird no ch die Belegung der b eiden SpyBus-
Seiten, die von der Kompressionseinheit genutzt werden vorgestellt.
B.1 Konguration
Es gibt vier Register, die sp eziell der Konguration der Kompressionseinheit dienen. Sie
werden, wie alle Register des RemASIC,
ub er den Pip elineBus konguriert. Dar
ub erhinaus
werden drei weitere Register f
ur den Event Readout ben
otigt, die gleichzeitig der Kon-
guration des FeASIC Interface dienen. Wird Human Co ding gew
ahlt, so mu auerdem
sichergestellt sein, da der Enco der RAM entsprechend b eschrieb en wurde. Die einzelnen
Register hab en folgende Bedeutung:
RegComprMo de[3:0]
Dieses Register stellt den Kompressionsmo dus ein. Die untersten
3 bit geb en die Nummer des Algorithmus an, w
ahrend bit 4 als 8BitSelect dient. Das
b edeutet, da b ei gesetztem 8BitSelect 8 bit Daten im gew
ahlten Kompressionsmo-
dus verarb eitet werden. F
ur das Dierence und Human-Inspired Co ding hat dieses
bit keine Bedeutung, es wird ignoriert. Die Numerierung der Algorithmen ist im
folgenden aufgef
uhrt:
0
NoOp eration
1
Human Co ding
2
Human-Inspired Co ding
3
Dierence Co ding
4
Run-Length Enco ding
RegComprParameter[9:0]
Wird mit dem Human-Inspired Verfahren komprimiert, so
wird in diesem Register der Wert der Referenzenergie
E
R
erwartet. Im Run-Length
84
B.2. HEADERWORT
85
Mo dus werden alle Energien, die kleiner sind als der Wert in RegComprParam auf
Null gesetzt. Auf diese Weise l
at sich ein Energie-Cut w
ahlen.
RegPreMainBuerSource
Wird dieses Flag gesetzt, so wird das Schreib en eines kom-
primierten Events in den Pre-Main Buer unterdr
uckt. Das b edeutet, die Ausle-
se l
auft ganz normal, die vorhandenen Daten im Pre-Main Buer werden jedo ch
nicht mit denen der Auslese
ub erschrieb en. Man kann auf diese Weise die Funkti-
onsf
ahigkeit des Interfaces zwischen Pre-Main Buer und Main Buer testen, indem
der Pre-Main Buer vor der Auslese mit b ekannten Daten b eschrieb en wird.
RegPreMainBuerSel
Dieses Register gibt die Nummer des RAMs an, der im Pre-
MainBuerSource-Mo dus in den Main Buer geschrieb en werden soll.
RegPortMask[3:0]
Dieses Register gibt direkt die Konguration der FeASIC Ports an.
Ist zum Beispiel bit drei gesetzt, so h
angt an Port drei mindestens ein FeASIC.
RegDaisyChainCount[7:0]
RegDaisyChainCount hat zwei bits f
ur jeden FeASIC Port,
die die Anzahl der FeASICs in der Daisy Chain an diesem Port angeb en. Die zwei
LSBs sind f
ur Port 0, die zwei MSBs f
ur Port 3.
RegBcPerEvent[2:0]
In diesem Register steht die Anzahl der pro Event ausgelesenen
Bunch-Crossings.
B.2 Headerwort
Ein fertig komprimierter Datensatz enth
alt einen Header, in dem neb en Informationen
des FeASIC Interface auch der Kompressionsmo dus ko diert ist. Das Headerwort ist das
erste 32 bit Datenwort eines Datensatzes. Die von der Kompressionseinheit b enutzten bits
werden im folgenden aufgelistet:
Headerwort[31]: Rep eat Flag
Das Rep eat Flag ist gesetzt, wenn die Kompression im
gew
ahlten Mo dus abgebro chen wurde, und im NoOp eration Mo dus wiederholt wur-
de. Dies geschieht, wenn sich das Event wider Erwarten so stark aufbl
ahen sollte,
da es nicht mehr in den Pre-Main Buer pat.
Headerwort[30:27]: Kompressionsmo dus
In diesen Teil des Headers wird das Regi-
ster RegComprMo de kopiert.
B.3 Beschreib en der Sp eicher
Das Beschreib en der Sp eicher erfolgt
ub er den Pip elineBus. In welcher Form die Daten
dab ei vorliegen m
ussen, um die Sp eicher korrekt zu kongurieren, wird in diesem Abschnitt
erkl
art.
Enco der RAM
Da der Enco der RAM 24 bit Datenw
orter und 8 bit Adressen hat, ist
seine Konguration b esonders einfach. Adresse und Datenwort k
onnen zusammen
in ein 32 bit Wort des Pip elineBusses gepackt werden.
86
ANHANG B. OPERATIONS- UND TESTMODI DER KOMPRESSIONSEINHEIT
PipelineBusData[23: 0] -> Datenwort
PipelineBusData[24:31] -> Adresse
Pre-Main Buer
Zum Beschreib en des Pre-Main Buers k
onnen b eide Mo di, der kon-
sekutive und der wahlfreie verwendet werden. Das erste Datenwort hat bei b eiden
Mo di dasselb e Format:
PipelineBusData[ 5: 0] -> Adresse des ersten Datenwortes
PipelineBusData[ 6] -> Nummer des RAMs der beschrieben werden soll
PipelineBusData[ 7] -> 0: wahlfrei, 1: konsekutiv
PipelineBusData[31: 8] -> unbenutzt
Im konsekutiven Mo dus folgen nun nur no ch 32 bit Datenw
orter, die aufsteigend ab
der sp ezizierten Adresse abgelegt werden:
PipelineBusData[31: 0] -> Datenwort
Im wahlfreien Mo dus folgt jetzt abwechselnd ein Daten- und ein Adresswort. Bei
jeder Adresse kann auch der Sp eicher gew
ahlt werden:
PipelineBusData[ 5: 0] -> Adresse des Datenwortes
PipelineBusData[ 6] -> Nummer des RAMs der beschrieben werden soll
PipelineBusData[31: 7] -> unbenutzt
Die Auswahl eines Schreibmo dus ist nur einmal zu Anfang des Schreibvorganges
m
oglich.
B.4 Auslese der Sp eicher
Bei der Auslese des Enco der RAMs werden, angefangen mit Adresse Null konsekutiv alle
256 Datenw
orter in den Main Buer geschrieb en. Dab ei werden jeweils die 24 LSBs eines
32 bit Wortes b elegt. Die Adressen werden b ei der Auslese nicht angegeb en.
Wird die Auslese des Pre-Main Buers aktiviert, so wird zun
achst RAM0, dann RAM1
in den Main Buer kopiert. Angefangen wird wieder mit Adresse Null. Die Auslese des
Pre-Main Buers erfolgt immer komplett, eine Auslese nur eines RAMs ist nichtm
oglich.
B.5 SpyBus
Auf den SpyBus k
onnen
ub er einen Multiplexer acht
Seiten
mit jeweils acht internen Si-
gnalen gegeb en werden. Die Kompressionseinheit b elegt zwei dieser Seiten komplett. Eine
Seite ist f
ur die BIST Signale der Sp eicher reserviert, von der die Kompressionseinheit drei
Leitungen b elegt. Die Signale der Kompressionseinheit, die
ub er den SpyBus angeschaut
werden k
onnen, sind im folgenden aufgef
uhrt.
B.5. SPYBUS
87
SEITE 0:
0 BIST RAM0
1 BIST RAM1
2 BIST Encoder RAM
SEITE 6:
4:0 ShiftBits[4:0]
7:5 State Register aus CUN Control
SEITE 7:
0: LSB des Bunch-Crossing Counters
1: LSB des Daisy-Chain Counters
2: LSB des Port Counters
4:3 State Register der Registersteuerung in der Shifting Unit
7:5 State Register aus Data Flow Control
Bunch-Crossing, Daisy Chain und Port Counter werden b eim Event Readout verwen-
det, um die Adressen f
ur die Auslese der Daten aus dem Event Buer ho chzuz
ahlen.
Dadurch, da das LSB herausgef
uhrt ist, l
at sich b eobachten, ob sie an der richtigen
Stelle inkrementiert werden, denn durch Addition einer eins wird das LSB invertiert.
Anhang C
Die Shapingfunktion
F
ur einen Dreieckspuls
i
(
t
)=
I
0
1
,
t
t
dr
t
t
dr
(C.1)
mit der Abklingzeit
t
dr
, b erechnet sich die Shapingfunktion nach [17 ] mit den Formeln:
V
(
x
)
/
h
1
(
x
)
,
1
x
dr
h
2
(
x
) f
ur
x
x
dr
(C.2)
V
(
x
)
/
h
1
(
x
)
,
1
x
dr
(
h
2
(
x
)
,
h
2
(
x
,
x
dr
)) f
ur
x
x
dr
(C.3)
h
1
(
x
) =
2
e
,
x=
(
,
1)
3
,
"
x
2
2
+
x
,
1
+
2
(
,
1)
2
#
e
,
x
,
1
(C.4)
h
2
(
x
) = 1
,
3
e
,
x=
(
,
1)
3
+
"
x
2
2
+
2
,
1
,
1
x
+
3
2
,
3
+1
(
,
1)
2
#
e
,
x
,
1
:
(C.5)
Dab ei wurden folgende Substitutionen verwendet
x
=
t
; x
dr
=
t
dr
;
=
pa
:
(C.6)
Mit
und
pa
werden die Zeitkonstanten von Pulsformer und Vorverst
arker b ezeichnet [17 ].
In der Simulation wird die Shapingfunktion
V
(
x
) dann so normiert, da ihr Maximum der
Energie im Trigger Tower entspricht.
88
Literaturverzeichnis
[1] Perkins, Donald H.
Introduction to High Energy Physics
Addison-Wesley, Menlo Park, 1986
[2] ATLAS Collab oration
Technical Proposal
CERN/LHCC/94-43,LHCC/P2
[3] ATLAS Homepage
ATLAS Figures
http://atlasinfo.cern.ch/Atlas/ATLASFIGS/atlasfigures.html
[4] Kleinknecht, K.
Detektoren f
ur Teilchenstrahlung
B.G. Teubner, Stuttgart, 1992
[5] Homepage der ATLAS-Grupp e des ASIC-Lab ors
Transparents for ATLAS
http://wwwasic.ihep.uni-heidelberg.de/atlas/
[6] Schumacher, C.
Der ATLAS Level-1 Trigger, Auslese des Frontends
Diplomarb eit, Universit
at Heidelb erg, 1997, HD-ASIC-31-0197
[7] Mass, A. et al.
A Front-End Digitisation and Readout System for the ATLAS Level-1 Calorimeter
Trigger
CERN/LHCC/96-39
[8] Mass, A.
Front-End and Fast Readout ASIC: FeAsic. User Manual
HD-ASIC-19-0896
[9] Pfeier, U.
Doktorarb eit in Vorb ereitung
[10] Hewlett Packard
Low Cost Gigabit Rate Transmission/Receive Chipset, Technical Data
89
90
LITERATURVERZEICHNIS
[11] CERN HSI Group
S-Link Homepage
http://www.cern.ch/HSI/s-link/
[12] Stroustrup, B.
The C++ Programming Language
Addison-Wesley, 2nd Ed., 1995
[13] Altarelli, G. et al.
Proton-Antiproton Col lider Physics
World Scientic, 1989
[14] ATLAS Collab oration
Technichal Design Report, Calorimeter Performance
CERN/LHCC 96-40
[15] Wunsch, M.
Pers
onliche Mitteilung
[16] M
uller, C.
Pers
onliche Mitteilung
[17] Chase, R. L.
A Fast Monolthic Shaper for the ATLAS E.M. Calorimeter
ATLAS Internal Note LARG-NO-10
[18] Lelewer, D. A. et al.
Data Compression
http://www.ics.uci.edu./~dan/pubs/DataCompression.html
[19] Mass, A.
Pers
onliche Mitteilung
[20] Troll TechAS
Online Qt Documentation
http://www.troll.no/qt/index.html
[21] Josuttis, N.
Die C++ Standardbibliothek
Addison-Wesley, 1996
[22] Cadence Design Systems Inc.
Verilog XL Reference
Online-Dokumentation, 1997
[23] Thomas, D. E. et al.
The Verilog Hardware Description Language
Kluwer, 1996
LITERATURVERZEICHNIS
91
[24] Cadence Design Systems Inc.
Synergy HDL Command Reference Help System
Online-Dokumentation, 1997
[25] Cadence Design Systems Inc.
Synergy HDL Syntheizer and Optimizer Modeling Style Guide
Online-Dokumentation, 1997
[26] Cadence Design Systems Inc.
Simulation and Test Language User Guide
Online-Dokumentation, 1997
[27] Mano, M. Morris
Digital Design
Prentice-Hall, 1984
[28] Grill, S.
Documentation to the HP82000 Test Pattern Generator
http://www.ihep.uni-heidelberg.de/~keller/cds/chipTester/Documentation.html
[29] Shannon, C. E.
A mathematical theory of communication
Bell Sys. Tech. J., vol.27, pp. 379-423, 623-656, 1948
[30] Jones, D. S.
Elementary Information Theory
Oxford University Press, 1989
[31] MacKay,David
A Short Course in Information Theory - Outline
http://131.111.48.24/pub/mackay/info-theory/course.html
Danksagung
Danken m
ochte ich allen, die, auf die eine o der andere Weise, zum Gelingen dieser Arb eit
b eigetragen hab en.
Prof. Meier f
ur die M
oglichkeit meine Diplomarb eit am ASIC-Lab or durchzuf
uhren.
Prof. Straumann f
ur die
Ub ernahme der Zweitkorrektur.
Alexander Mass f
ur die ausgezeichnete Betreuung und die M
oglichkeit eigene Ideen
zu verwirklichen.
Cornelius Schumacher f
ur viele Anregungen und die Hilfe bei der Einarb eitung in
Cadence und Verilog. Ganz b esonders f
ur eine genaue Durchsicht meiner Diplomar-
b eit.
Ullrich Pfeier f
ur die genaue Durchsicht des Abstracts und die Kl
arung vieler Fra-
gen.
Michael Keller, der eine unersch
opiche Quelle von Tips und Ratschl
agen b ei Pro-
blemen mit UNIX und Cadence war.
Johannes Schemmel f
ur die
ub eraus gr
undliche Durchsicht dieser Arb eit und seine
stete Bereitschaft meine Fragen zu C++ zu diskutieren.
Martin Wunschf
ur seine geduldige Hilfe b ei Fragen der Ho chenergiephysik.
Allen Mitgliedern des ASIC-Lab ors f
ur das gute Arb eitsklima. Ganz b esonders A.
Mass, J. Schemmel und P.Schneider, die meine Begeisterung f
ur das Kaeetrinken
teilten.
Annette Wenig, die mir stets zuh
orte und mit einer Menge Kaee und guter Einf
alle
daf
ur sorgte, da mein Studium nie langweilig wurde.
Karl-Heinz Ap elt und allen Mitgliedern und G
asten des J.C. Scheune f
ur ihre mo-
ralische Unterst
utzung w
ahrend des Studiums.
Meinen Eltern, ohne deren Unterst
utzung mein Studium so nicht m
oglich gewesen
w
are.
93
