Home

Der RemFPGA des ATLAS Level-1 Kalorimeter Triggers

1. Dot 199110904 99 1000 199110904 1991 09 REES eee Abbildung 27 Schema des gesamten RemFPGA 50 Kapitel 6 Datenformate und Register des RemFPGA Dieses Kapitel erl utert die verschiedenen Formate der Daten welche ber die VME Schnittstelle oder den Pipelinebus empfangen oder ausgegeben werden k nnen Auch die Funktionen und die Inhalte der verschiedenen internen Register des RemFPGA werden darge legt 6 1 ReadOUT Daten und ihre Kompression In diesem Abschnitt werden zun chst kurz die Ergebnisse der Untersuchungen zu verschiedenen Kompressionsverfahren f r ReadOUT Daten von Bernhard Niemann 9 und Volker Schatz 10 er rtert Im Anschluss wird die von RemFPGA ei
2. 384 1 384 1 3 43 3 43 Data rate 75 kHz 24848 1 72 222 16 128 94 Abbildung 47 1 BCID 3 RAW Level 1 Rate 75kHz Data type Bits Multiplier Total Bits Compress MB s MB s BCID Sample 8 512 4096 2 36 62 18 31 BCID Algorithm 3 512 1536 1 13 73 13 28 RAW Sample 50 512 25600 2 2 228 88 104 04 RAW Ext BCID 5 512 2560 1 22 89 22 89 Flags per channel 1 512 1 4 58 4 58 Flags per 18 8 144 1 1 29 1 29 32 8 256 1 2 29 2 29 384 1 384 1 3 43 3 43 Data rate 75 kHz 35088 1 84 313 71 170 56 Abbildung 48 1 BCID 5 RAW Level 1 Rate 75kHz Data type Bits Multiplier Total Bits Compress MB s MB s BCID Sample 8 512 4096 2 48 83 24 41 BCID Algorithm 3 512 1536 1 18 31 18 31 RAW Sample 0 512 0 2 2 0 0 RAW Ext BCID 0 512 0 1 0 0 Flags per channel 1 512 512 1 6 1 6 1 Flags per PPM 18 8 144 1 1 72 1 72 32 8 256 1 3 05 3 05 PBus per ROD 384 1 384 1 4 58 4 58 Data rate 100 kHz 6928 1 42 82 59 58 17 Abbildung 49 1 BCID 0 RAW Level 1 Rate 100kHz Data type Bits Multiplier Total Bits Compress MB s MB s BCID Sample 8 512 4096 2 48 83 24 41 BCID Algorithm 3 512 1536 1 18 31 18 31 RAW Sample 30 512 15360 2 2 183 11 83 23 RAW Ext BCID 5 512 2560 1 30 52 30 52 Flags per channel 1 512 512 1 6 1 6 1 Flags per PPM 18 8 144 1 1 72 1 72 32 8 256 1 3 05 3 05 PBus per ROD 384 1 384 1 4 58 4 58 Data rate 100 kHz 24848 1 72 296 21 171 9
3. PFLILILILA FETII LILIT LT MEEA t Taig 5 40 iii 5 Du Entity TestTop_1 Architecture Date Tue Apr 09 09 19 13 CEST 2002 Row 1 1 5 Abbildung 45 PC Kommunikation 90 label anal EM 5 iii 5 Kapitel 8 Zusammenfassung Diese Arbeit hat die Entwicklung der Funktionalit t des Readout Merger zum Mittelpunkt Dieser Baustein dient erstens der zentralen Steuerung aller Komponenten des Pr prozessormo duls und zweitens dem Empfang und der Weiterleitung von ReadOUT Daten der PPrASICs Um ver nderten Anforderungen der Zukunft Rechnung tragen zu k nnen wird f r diese Funkti onalit t ein FPGA Chip verwendet Folglich muss der im Rahmen dieser Diplomarbeit erstelle Programmcode m glichst modular aufgebaut sein um zuk nftige nderungen mit Hilfe von minimalem Arbeitsaufwand zu erm glichen Es wurde lediglich die Programmierung des RemFPGA entwickelt und ausf hrlich getestet Die umgebende Hardware ist zum Zeitpunkt dieser Arbeit noch nicht existent weshalb der RemFP GA nicht in der Praxis getestet werden konnte S mtliche Tests waren mit Ausnahme der seltsamen Mapping Probleme siehe Abschnitt 7 1 2 fehlerlos und haben keine Probleme des erstellten Programmcodes aufzeigen k nnen Die wenige Tage vor Abschluss der Arbeit zum ersten Mal aufgetretenen Mapping Fehler m ssen
4. Das Modul arbeitet mit einer umfangreichen State machine deren Zyklus mit dem Empfang des ersten ReadOUT Headers nach einem ReadBACK Wort beginnt siehe Abbildung 26 Flags Data Readback channel PPrAsic Channel 0 PPrAsic Channel 1 Abbildung 26 serielles Datenformat Jeder Zyklus f hrt zur Speicherung eines Datenpakets von variabler L nge im 32 Bit RAM Dieses Datenpaket besteht aus einem Header von 18 Bit L nge siehe Tabelle 4 und einem darauf folgenden Bitstrom von variabler L nge Die im empfangenen ReadOUT Header enthal tenen Werte f r BCID Nummer und Eventnummer werden im 18Bit Header abgelegt 20 Bei jedem Taktzyklus wird genau eine von mehreren m glichen Aktionen ausgef hrt abh ngig von einer Zu standsvariablen state Jede Aktion kann einen neuen Zustand f r die Ausf hrung bei dem n chsten Taktzyklus festlegen 43 Bit Bedeutung 0 7 L nge in Bits inkl Header 8 11 BCID Nummer 12 15 Eventnummer 16 falsche BCID Nummer 17 falsche Eventnummer Tabelle 4 interner 18Bit ReadOUT Header Diesen ersten 18 Bits folgt ein Kanal Header von variabler L nge Um die gesamte Datenl nge zu minimieren besitzt der Kanal Header eine variable L nge An diesen Kanal Header schlie en die komprimierten ReadOUT Daten f r den ersten Kanal des seriellen Interfaces an Daraufhin folgen die Daten f r den zweiten Kanal ebenfalls bestehend aus einem
5. Sal ZK Na RUPRECHT KARLS UNIVERSITAT HEIDELBERG Sek ei H Il Se Dominique Kaiser Der Readout Merger des Praprozessors des ATLAS Level 1 Kalorimeter Triggers Diplomarbeit HD KIP 05 02 KIRCHHOFF INSTITUT FUR PHYSIK Fakult t f r Physik und Astronomie Ruprechts Karls Universit t Heidelberg Diplomarbeit Im Studiengang Physik Vorgelegt von Dominique Kaiser Aus Konstanz April 2002 Der Readout Merger des Pr prozessors des ATLAS Level 1 Kalorimeter Triggers Die Diplomarbeit wurde ausgef hrt von Dominique Kaiser am Kirchhoff Institut f r Physik der Universit t Heidelberg unter Betreuung von Herrn Prof Dr Karlheinz Meier Der RemFPGA des Pr prozessors des ATLAS Level 1 Kalorimeter Triggersystems Thema dieser Arbeit ist der Entwurf und die Entwicklung des Readout Mergers f r den Pr prozessor des Level 1 Kalorimeter Trigger des ATLAS Detektors Dieser Baustein des Pr prozessors wird mit Hilfe FPGA Technologie realisiert Aufbauend auf den Resultaten des Tests eines Prototyps wurde ein vollst ndig neues Design entworfen Die Aufgabe des so genannten RemFPGA ist die Steuerung und Konfiguration aller anderen Komponenten des Pr prozessormoduls wie auch die Kompression und Weiterleitung von Readout Daten des Pr prozessors Bei dem FPGA handelt es sich um einen Virtex E 1000 der Firma Xilinx In der HDL Sprache Verilog wurde ein komplettes Design f r diesen FPGA Baustein entwickelt und
6. 00 Arbitrary Command word Data word Abbildung 23 Pipelinebus W rter Ein Befehlswort besteht aus einer 6 Node Adresse einem 8 Bit Befehlscode einem 16 Bit Befehlsargument und zwei Flagbits Jedem Pipelinebus Slave sind jeweils eine eindeutige Node Adresse und eine Gruppen Adresse zugeordnet Dar ber hinaus ist noch eine Broadcast Adresse definiert welche jeden Slave auf dem Bus anspricht Die verschiedenen Pipelinebus Befehle werden durch den 8 Bit Code identifiziert und jedem Befehl steht das 16 Bit Argument zur beliebigen Verwendung zur Verf gung Empf ngt eine Slave Node ein an sie gerichtetes Befehlswort und erkennt und verarbeitet dieses als solches so setzt sie das Accept Bit auf 1 und schickt den damit akzeptierten Befehl weiter auf seinem Weg durch den Ring zur ck zum Bus Master Bei fehlerfreier Funktion des Pipeli nebusses darf niemals ein Befehlswort ohne gesetztes Accept Bit zur ck bei Master eintreffen Erkennt ein Slave einen Fehler auf dem Pipelinebus wie zum Beispiel einen Parityfehler oder ein ung ltigen Befehlscode so ersetzt dieser Slave das fehlerhafte Wort welches zum Beispiel auch ein Datenwort mit fehlerhafter Parity sein kann durch ein Befehlswort mit gesetztem Error Bit In diesem Fall enth lt der Befehlscode eine Beschreibung des aufgetretenen Fehlers siehe Kaptitel 6 7 Daten bertragung ber den Pipelinebus Wie zuvor erw hnt ist es nur dem Pipelinebus Master erlaubt
7. Der Pipelinebus besitzt eine Datenbreite von 32 Bit womit sich eine mindestens erforderliche Busfrequenz von 142 MHz ergibt Innerhalb des Crates sind die einzelnen PPM und ROD Module ber eine nur teilweise abge schirmte Backplane miteinander verbunden wobei einzelne Leitungen L ngen von bis zu 30 cm erreichen Bei diesen Randbedingungen ist der Betrieb des Pipelinebusses mit 142 MHz tech nisch nicht m glich 40 Ein Prototyp des Pipeline Bus wurde erfolgreich mit 40 MHz betrieben 8 Ein Betrieb mit 60 MHz erscheint ebenfalls m glich wurde jedoch noch nicht getestet Um somit die generierten ReadOUT Daten bermitteln zu k nnen ist eine Kompression dieser Daten erforderlich Verschiedene Algorithmen zur Reduktionen des Datenumfangs wurden untersucht 9 und 10 Das vom RemFPGA letztendlich verwendete Kompressionsverfahren ist von den Ergeb nissen dieser Untersuchung inspiriert und wird in Kapitel 6 1 ausf hrlich erl utert 5 2 Design des RemFPGA Programmcodes Dieser Abschnitt erl utert den logischen Aufbau der Programmcodes der RemFPGA Der Code des RemFPGA besteht aus einer Vielzahl von logischen Bl cken Einzelne Pro grammbl cke werden bei Verilog als Module bezeichnet Ein und Ausgabesignale von Modulen werden Ports genannt Dem Design der einzelnen Module der RemFPGA wurden einige Grundprinzipien zu Grunde gelegt die auch aus der Welt der konventionellen Softwareprogrammierung bekannt sind siehe Abb 77 a Zw
8. Weiterhin verbindet RemSerMerge die 8 getrennten Datenbl cke der RemSerRbCollect Modu le Hierbei kann das resultierende Gesamtpaket jedoch nicht in einem weiteren Speicherblock abgelegt werden da die m gliche Gesamtl nge dieses Pakets die zur Verf gung stehenden RAM Ressourcen des Virtex bersteigt Stattdessen wird das resultierende Gesamtdatenpaket dynamisch w hrend der Auslese aus den Daten der acht einzelnen RemSerRbCollect Module zusammengesetzt Dies ist m glich da hier keine Synchronisations berpr fungen n tig sind Auch sind die L ngen der acht einzelnen Datenpakete immer ein Vielfaches von 32 was das Aneinanderf gen der Daten wesentlich erleichtert Die ReadOUT Daten wie auch die ReadBACK Daten werden ber einen FIFO Mechanismus bergeordneten Modulen zur Auslese zur Verf gung gestellt ber einen weiteren FIFO Mechanismus leitet RemSerMerge eingehende Daten weiter an die Instanz von RemSerOut Control um sie so als Ausgabe an die 32 seriellen Schnittstellen weiterzuleiten Als Endresultat liefert RemSerMerge Datenleitungen f r alle 32 seriellen Schnittstellen welche direkt mit Ein Ausgabe Pins des FPGA verbunden werden k nnen Die Aktivit t dieser Daten leitungen wird gesteuert durch drei einfache FIFO Mechanismen und einige Konfigurationslei tungen welche mit internen Registern des RemFPGA verbunden werden Die Verbindung der 32 seriellen Schnittstellen mit den 16 RemSerRoCollect und mit den 8 RemSerRbCollec
9. bytes acknowledge Abbildung 14 Datentransfer Slave zu Master PC Adressierungsschema und Besonderheiten des Phos4 Chips Einige Adressen des PC Busses haben spezielle Bedeutungen sie sind im Folgenden ohne weitere Erl uterungen aufgef hrt Adresse R W Bit Bedeutung 0000 000 0 General Call 0000 000 1 START byte 0000 001 x CBUS Adresse 26 0000 010 x Reserviert f r andere Busformate 0000 011 x Reserviert f r zuk nftige Erweiterungen 0000 1xx x verwendet von High Speed PC 1111 Ixx x Reserviert f r zuk nktige Erweiterungen 1111 Oxx D 10 Slave Adresse Tabelle 1 2 Sonderadressen Einer General Call Adresse folgt ein weiteres Byte mit spezieller Bedeutung Erw hnenswert ist hier der Wert 00000110 welcher einen Reset an alle angeschlossenen Ger te signalisiert Die Beachtung dieses Resetsignals ist jedoch f r jedes 2 optional Der Phos4 Chip 5 besitzt einige Besonderheiten in seiner Implementierung des I C Busses Falls in zuk nftigen Versionen des PPMs andere Chips au er dem Phos4 an PC angeschlossen werden sollen m ssen einige Einschr nkungen beachtet werden Der Phos4 Chip besitzt nur vier Pins um die PC Adresse zu definieren die restlichen drei Bits sind teilweise statisch definiert und werden teilweise ignoriert Dar ber hinaus kann der Chip nur beschrieben aber nicht ausgelesen werden Adressbit A6
10. 15 14 87 0 7 Bit C Adresse 8 Bit I C Daten Datenwort x reserviert Null Abbildung 38 Datenformat f r PC Ausgabe An den PC Bus werden voraussichtlich 32 Phos4 Chips angeschlossen die jeweils mit einem einzigen PC Wort konfiguriert werden Somit sind f r eine vollst ndige Konfiguration 33 16 Bit Worte n tig Der interne Speicher des RemFPGA kann bis zu 511 16 Bit Worte aufnehmen Neue Daten werden erst nach vollst ndiger Verarbeitung der vorigen Daten akzeptiert Der PC Bus wird mit einer Geschwindigkeit von 95kBit s betrieben 6 5 Datenformat f r die SPI Schnittstellen Die Eingangsdaten f r die Ausgabe auf den vier SPI Bussen bestehen im Gegensatz zu PC oder serieller Ausgabe aus 32 Bit W rtern Der Header besitzt dieselbe L nge wie auch in Abschnitt 6 3 und in Abschnitt 6 4 beschrieben und verwendet den ID Code 5 Er wird durch 16 weitere Bits Null auf die erforderliche L nge von 32 Bit gebracht An einen SPI Bus sind im allgemeinen durch Hintereinanderschaltung mehrere Ger te ange schlossen Im Falle des Pr prozessormoduls sind vier MAX529 Digital Analog Wandler hintereinander geschaltet auch daisy chaining genannt Die Daisyl nge spezifiziert diese Anzahl und sollte daher im Falle der Pr prozessormoduls immer auf vier gesetzt werden Der Programmcode des RemFPGA RemSpiControl erfordert f r alle vier SPI Schnittstellen die gleiche Daisyl nge Auf den 32 Bit Header folge
11. A5 AA 2 Al AO R W Bedeutung 0 Pin20 Pin21 Pin22 Pin23 x x 0 Tabelle 2 Adressschema des Phos4 Zusammen mit Tabelle 1 ergibt sich somit zwingend die Einschr nkung dass f r jeden Phos4 zumindest eines der drei Bit A5 A4 und gesetzt sein muss da der Chip ansonsten auch auf einige Sonderadressen reagieren w rde Es empfiehlt sich auch eventuelle weitere PC Ger te nur mit Adressen mit gesetztem A6 Bit zu versehen Werden diese beiden zus tzlichen Randbe dingungen beachtet so bleibt der PC Standard weiterhin gewahrt 3 3 2 Das SPI Protokoll Bei dem SPI Protokoll handelt es sich um ein u erst einfaches Protokoll welches drei Daten leitungen verwendet Die SPI Schnittstelle wird ausschlie lich von den DAC Chips MAX529 von Maxim 6 auf den Analog Input Modulen verwendet Es handelt sich um ein serielles Schiebeprotokoll bei dem mehrere MAX529 optional hinter einander geschaltet werden k nnen Im Falle des Einsatzes auf den Analog Input Modulen werden jeweils vier MAX529 zusammen geschaltet daisy chaining Die drei Leitungen bertragen das Datensignal DIN die Clock CLK und das Ladesignal CS Jeder 529 verf gt zus tzlich ber einen Pin DOUT der mit dem DIN Eingang des n chsten MAX529 verbunden wird Jeder MAX529 implementiert ein 16 Bit Schieberegister Bei jedem Clocksignal wird der Wert von DIN in das unterste Bit des Schieberegisters geschoben Da
12. Ich m chte mich bei Allen bedanken die mir durch sachliche Hilfe oder moralische Unterst tzung bei der Abfassung meiner Diplomarbeit geholfen haben Prof Meier f r die M glichkeit am KIP meine Diplomarbeit zu erstellen Weiterhin f r die regelm ige Teilnahme an den Gruppenbesprechungen trotz vie ler anderweitiger Verpflichtungen Prof Lindenstruth erkl rte sich bereit die Zweitkorrektur zu bernehmen Klaus Schmitt f r eine stets freundliche und immer kompetente Hilfestellung bei Problemen aller Art Paul Hanke f r die zielgerichtete aber trotzdem stets humorvolle Leitung der Gruppenbesprechnungen Thomas Nirmaier f r die stets gute Laune im Institutsraum Ralf Achenbach und Kambiz Mahboubi f r die Hilfe beim Verst ndnis des PPr ASIC und den Humor bei Gruppenbesprechungen Robert Weiss f r die kompetente und schnelle Hilfe bei Netzwerkproblemen Den Vision Leuten hinten rechtes f r die Hilfe bei ModelSim Problemen Meinen WG Mitbewohnern f r die Geduld und R cksichtnahme Dem HP LaserJet 8100 DN Drucker f r seine schnelle und unerm dliche Arbeit 95 Literaturverzeichnis 1 rn N kal The LFAN Test Specification http www kip uni heidelberg de atlas DATA docs LFAN Test pdf Xilinx Corporation http www xilinx com xInx xil_prodcat_product jsp title ss_vir Philips PC Bus http www semiconductors philips com i2c Spezifikation http www se
13. In der zweitletzten Spalte ist die Datenrate bei deaktivierter Kompression aufgef hrt die letzte Spalte enth lt die komprimierten Zahlenwerte Es wird von einer fehlerfreien Funktion der PPrASICs ausgegangen daher ist der variable Kanal Header nur ein Bit breit Der Header des gesamten Datenstroms verf gt ber 18 Flagbits Jede Slave Node schlie t die Ausgabe mit einem EndOfData Befehl ab daher 32 Bits pro Pr prozessormodul Der Master muss leere W rter ausgeben bis die EndOfData Befehle aller acht PPMs angekommen sind dies bedingt 9 32 288 Bits Hinzu kommen der BeginOfData Befehl am Anfang der Sequenz und zwei weitere Taktsignale die der ROD zur Verarbeitung der Daten ben tigt 91 Data type Bits Multiplier Total Bits Compress MB s MB s BCID Sample 8 512 4096 2 36 62 18 31 BCID Algorithm 3 512 1536 1 13 73 13 28 RAW Sample 0 512 0 2 2 0 0 RAW Ext BCID 0 512 0 1 0 0 Flags per channel d 512 512 1 4 58 4 58 Flags per PPM 18 8 144 1 1 29 129 PBus per PPM 32 8 256 1 2 29 2 29 PBus per ROD 384 1 384 1 3 43 3 43 Data rate 75 kHz 6928 1 42 61 94 43 63 Abbildung 46 1 BCID 0 RAW Level 1 Rate 75kHz Data type Bits Multiplier Total Bits Compress MB s MB s BCID Sample 8 512 4096 2 36 62 18 31 BCID Algorithm 3 512 1536 1 13 73 13 73 RAW Sample 30 512 15360 22 137 33 62 42 RAW Ext BCID 5 512 2560 1 22 89 22 89 Flags per channel 1 512 512 1 4 58 4 58 Flags per PPM 18 8 144 1 1 29 1 29 PBus per PPM 32 8 256 1 2 29 2 29
14. lich immer ein gleichm iges 50 50 Signal 4 1 3 Der Entwicklungsprozess Die Entwicklung eines digitalen Designs f r einen FPGA unterteilt sich in mehrere Einzelschrit te Zu Beginn wird das gew nschte Verhalten des FPGA in einer so genannten Hardware Descrip tion Language HDL programmiert Im professionellen Einsatz stehen zwei verschiedene Sprachen zur Verf gung Verilog und VHDL Beide Sprachen sind entfernt an die Software sprache C angelehnt und bieten grunds tzlich die gleichen M glichkeiten F r die Programmie rung des RemFPGA wurde Verilog verwendet da alle anderen Hardwareprojekte der ATLAS Gruppe in Heidelberg ebenfalls mit dieser Sprache arbeiten Nach Abschluss der Programmierung folgt die so genannte Synthese Hierbei wird das HDL Programm kompiliert und in eine Netlist umgewandelt Diese Netlist repr sentiert das HDL Design auf der Ebene von logischen Verkn pfungen UND ODER X ODER usw Zum Abschluss wird die Netlist von einem so genannten Place and Route Werkzeug PAR analysiert welches wieder eine neue Netlist erzeugt Die Aufgabe des PAR ist die Zuordnung Verkn pfung und Positionierung der real im FPGA existierenden CLBs um die von der Synthe se Netlist geforderte Funktionalit t zu implementieren Diese PAR Netlist wird dann in einem letzen Schritt in einen Bitstream umgewandelt welcher direkt in die FPGA Hardware geladen werden kann Nach jedem dieser drei Schritte kann das Design mit spezielle
15. 7 2 Simulation und Test des 8 Zusammenfassung 8 1 Absch tzung der Read Datenrate 8 2 EE tes tegt ee IR OUT D teratureerzeichuts ageet NEEN Eege dE Einleitung Im Rahmen der Grundlagenforschung der Physik werden immer detailliertere Modelle unseres Universums entwickelt Diese Modelle und Theorien postulieren physikalische Vorg nge und Gesetzm igkeiten die in normalen Experimenten nicht zug nglich und berpr fbar sind da sie eine sehr hohe Energie der beteiligten und untersuchten Komponenten erfordern Aus diesem Grund erfindet und baut die physikalische Forschung immer neue und leistungsf higere Teil chenbeschleuniger um in immer h here Energiebereiche vordringen zu k nnen Auf Grund der so durchgef hrten Experimente werden neue Erkenntnisse gewonnen und neue Theorien entwickelt Diese ben tigen f r ihre Verifizierung jedoch in vielen F llen neue Experimente bei noch h heren Energien Eine der momentan zu berpr fenden Theorien betrifft die Existenz des so genannten Higgs Teilchens Mit aus diesem Grund wird in Genf am Institut f r Hochenergieforschung CERN ein neuer Beschleuniger gebaut Der Large Hadron Collider LHC wird Protonen mit einer Energie von bis zu 7 TeV zur Kollision bringen Mi
16. PPrASICs 7 und die Diplomarbeit zum PPrASIC 12 Eingabew rter des PPrASIC ber die serielle Schnittstelle k nnen sowohl Befehle wie auch Daten f r die internen Speicher bereiche und Register an den PPrASIC bermittelt werden Der Wert des h chsten Bits ent scheidet dabei um welche Art von Eingabe es sich handelt Der RemFPGA dieser Diplomarbeit erzeugt und sendet keine eigenen Befehle oder Daten ber die serielle Schnittstelle zum PPrA SIC Es werden lediglich Datenbl cke ber die VME Schnittstelle siehe Abschnitt 3 3 4 oder den Pipelinebus siehe Abschnitt 3 3 5 entgegen genommen und unver ndert an die ange schlossenen PPrASICs geschickt siehe Abschnitt 6 3 Ausgabew rter des PPrASIC Abh ngig vom Wert des h chsten Bits bertr gt der PPrASIC ReadOUT oder ReadBACK Daten Als ReadOUT bezeichnet man Daten die zur berpr fung des Verhaltens des Triggers bei jedem Level 1 Accept generiert werden und die ber die beiden ROD Readout Treiber weitergeleitet werden Als ReadBACK werden Daten aus den internen Registern und Speicher bereichen des PPrASIC bezeichnet Wird zum Beispiel der PPrASIC mit Hilfe des Eingabe Befehls StartReadback 0010000100011 zur Auslese des Registers Nummer 2 aufgefordert so sendet der PPrASIC den Registerinhalt als ReadBACK Daten ReadOUT Daten dagegen setzen sich aus so genannten RAW und BCID Werten in Verbindung mit einem vorangehenden Header zusammen Ein solches Paket aus Header BCID
17. Playback aktiv Pipeline gestoppt reserviert Null L nge in 32 Bit Einheiten Abbildung 35 Header der gesamten ReadBACK Daten Die Flagbits 5 bis 9 entstammen den letzten empfangenen ReadBACK Statusworten Wenn mindestens eine der 32 seriellen Schnittstellen ein gesetztes Bit ausweist so wird dies hier angezeigt Die auslesende Instanz kann dann ber Registerinhalte des RemFPGA den genauen Status aller 32 Schnittstellen ermitteln und eine genauere Fehlersuche betreiben Da w hrend des normalen Betriebs in regelm igen Abst nden ReadBACK Daten ausgelesen werden Kann durch diese Headerinformationen ein st ndiges Polling des gesamten RemFPGA Status vermie den werden Stattdessen k nnen weitere Aktionen gezielt nur bei Auftreten eines Fehlers durchgef hrt werden 250 258 259 260 261 262 SL 20 119 10 9 413 0 Dezimal 263 100 10 31 16 15 11 10 0 Dezimalwert 514 0001 1 LUT Header 31 24 23 16 15 8 7 0 LUT 3 LUT 2 LUT 1 LUT 0 31 24 23 16 15 8 7 0 LUT 1023 LUT 1022 LUT 1021 LUT 1020 31 VOWS 11 10 0 Dezimalwert 3 00101 Reg Header 31 16 15 11110 0 0 0 Reg Inhalt 31 16 15 11110 0 Dezimalwert 6 10001 Rate Header 16 15 11110 0 0 Ratemeter 2 0 Ratemeter 1 31 16 15 11 10 0 0 Ratemeter 4 0 Ratemeter 3 Abbildung 36 ReadBACK Beispiel 59 Das resultierende Format des g
18. Xilinx Mapping Report File for Design RemTop Design Information Command Line map p xcv1000e bg560 6 cm area k 4 c 100 tx off remtop ngd Target Device xvl000e Target Package bg560 Target Speed S Mapper Version virtexe Revision 1 58 5 Mapped Date Tue Apr 09 08 32 40 2002 Design Summary umber of errors 1 umber of warnings 1 umber of Slices 24 746 out 12 288 201 umber of Slices containing unrelated logic 1 502 out of 24 746 6 umber of Slice Flip Flops 16 035 out of 24 576 65 Total Number 4 input LUTs 43 178 out of 24 576 175 Number used as LUTs 41 886 Number used as a route thru 1 292 umber of bonded IOBs 243 out of 404 60 umber of Block RAMs 88 out of 96 91 umber of GCLKs 2 out of 4 75 umber of 1 5 3 out of 4 75 umber of DLLs 3 out of 8 37 umber of Startups 1 out of 1 100 80 Total equivalent gate count for design 1 893 322 Additional JTAG gate count for IOBs 11 808 Table of Contents Errors Warnings Informational Section Removed Logic Summary Section Removed Logic Section 1 2 3 4 5 Section 6 Properties T 8 9 1 Section Section Section RPMs Section Guide Report Section Area Group Summary Section 10 Modular Design Summary Section 1 Errors ERROR Pack 18 The design is too large for the given device and package Please check the Design Summary section to see which resource
19. selbst K nnen eingehende Daten mit ausreichender Geschwindigkeit verarbeitet werden Sollte dies in Extremsituationen nicht der Fall sein so wird das deshalb unverarbeitete Datenwort durch ein Fehlerwort Bit 3 Eingabedaten konnten nicht schnell genug verarbeitet werden ersetzt und die Verarbeitung des momentanen Datenblocks wird abgebrochen Schon empfan gende Daten dieses unvollst ndigen Blocks werden verworfen Der RemFPGA geht zur ck in Eingabebereitschaft Dem Autor dieser Diplomarbeit sind keine F lle bekannt in denen eine solche Situation auftreten k nnte und sie ist in Simulationen nicht aufgetreten Sollte dies jedoch trotzdem vorkommen so sollte der Pipelinebus Master den abgebrochenen Datenblock erneut senden und dabei nach jedem zweiten Datenwort einen NOP Befehl einf gen Nach Abschluss aller Eingabebl cke wird der Bereitschaftszustand durch den Befehl StopData verlassen 6 7 5 Besonderheiten und Anwendungsbeispiel Die Verwendung verschiedener Signale f r die interne Taktung des RemFPGA und den Betrieb des Pipelinebusses bedingt einige Besonderheiten der internen Verarbeitung von Pipelinebus Befehlen durch den RemFPGA e Zwei an denselben RemFPGA adressierte Pipelinebus Befehle d rfen niemals direkt nacheinander folgen Um eine direkte Folge zu vermeiden k nnen bei Bedarf NOP Befehle eingef gt werden welche nicht dieser Beschr nkung unterliegen e Bei der Datenauslese kann es hin und wieder zu Synchronisationssc
20. und RAW ReadOUT Datenw rtern wird von dem PPrASIC bei jedem Level 1 Accept f r jeden der vier Kan le generiert und ohne Aufforderung ber die beiden seriellen Schnittstellen ausgegeben Bei den RAW Werten handelt es sich um die unverarbeiteten Rohdaten die von dem PPrASIC als 10 Bit Worte von den FADCs empfangen werden Aus jedem RAW Wert wird ber mehrere Algorithmen ein 8 Bit BCID Wert abgeleitet Diese BCID Daten sind das Endresultat des PPrASIC und werden auch in leicht ver nderter Form ber den so genannten Echtzeitdaten pfad an den Cluster Prozessor und den Jet Energy Sum Prozessor des Level 1 Triggers weiter geleitet Die einzelnen BCID Werte werden dabei nicht nur von einem RAW Wert abgeleitet sondern sind auch abh ngig von vorangegangenen RAW Daten ReadOUT Daten und ReadBACK Daten werden in einer unver nderlich definierten Reihenfol ge gesendet siehe Abbildung 15 Zuerst wird ein einzelnes ReadBACK Wort gesendet Dieses wird gefolgt von einem EventHeader Wort f r den ersten Kanal welches weiter gefolgt wird von einem oder mehreren BCID Werten bis zu 31 St ck Standardeinstellung 1 BCID Wort Nach dem den BCID Werten folgen 0 bis 7 RAW Werte Standardeinstellung 5 RAW Werte Anschlie end folgen die ReadOUT Daten des zweiten Kanals 28 channel PPrAsic Channel 0 PPrAsic Channel 1 24 aa KE Abbildung 15 Abfolge der seriellen Datenausgabe Die Anzahl z
21. Eventfilter v llig nutzlos Grunds tzlich existieren die folgenden Teilaufgaben des Pr prozessors Empfang des differentialen analogen Signals Das Signal muss in ein unipolares Signal umgewandelt werden Ein programmierbarer 10 Bit DAC erlaubt die Justierung des Nullniveaus e Digitalisierung des analogen Signals Ein kommerzieller 10 Bit Flash ADC wird verwendet um das Signal mit der globalen LHC Frequenz von etwa 40MHz zu digitalisieren e Phasenjustierung des Eingangssignals Mit einem ASIC Phos4 der CERN Microelectronics Group kann die Clock des FADCs gegentiber der LHC Clock in Schritten von einer Nanosekunde in der Phase verschoben werden 17 e Identifikation des Bunch Crossings Das eingehende Signal muss einem bestimmten Bunch Crossing zugeordnet werden damit bei einem Level 1 Accept die Detektordaten des korrekten Events ausgelesen werden Dies erfolgt mit Hilfe zweier verschiedener Algorithmen einer f r ges ttigte und einer f r unges ttigte Signale Diese Analyse wird von einem dedizierten ASIC durchgef hrt dem Pre Processor ASIC PPrASIC Zus tzlich kann ein so genanntes External BCID Signal zur Identifikation verwendet werden e Kalibrierung des digitalisierten Signals ber eine frei konfigurierbare Lookup Tabelle wird das 10 Bit Rohsignal RAW auf einen 8 Bit Wert abgebildet nach der BC Identifikation e Berechnung von Jetelementen Der Jet Energy Sum Trigger arbeitet mit nochmals gr beren Ei
22. Logging Ausgabe der Testbench dargestellt 7 2 1 Dekodierung des Eingangssignals einer seriellen Schnittstelle Der folgende Ausschnitt zeigt den Empfang eines ReadBACK Wortes gefolgt von einem ReadOUT Header einem BCID Wert und zwei RAW Werten Das Modul RemSerSyncDecode ist mit der zu verarbeitenden Anzahl von BCID und RAW Werten konfiguriert ganz oben Direkt darunter sind die Signale der seriellen Leitung zu sehen Weiter unter sind die Signale aufgef hrt welche ein empfangenes Wort identifizieren und weiterleiten 82 SU 0092 SU 0022 2002 1539 29 10 60 60 1dy syeq 1 Au SU 0089 0 0 100000000001 111100001000 010001000000 0 01000000010 Ld L 9 L Byeqyoeqpeey snyejgyoeqpesy Apeo
23. PC serielles Datenprotokoll mit 2 Leitungen Industriestandard siehe Kapitel 21 Das CAN Bus Modul 1 St ck pro PPM Das CAN Bus Protokoll ist ein Industriestandard und wird im ATLAS Experiment f r die berwachung des Zustands der verschiedenen Crates Module und Chips auf dem Modulen verwendet Es werden Parameter wie Spannung Stromaufnahme L ftergeschwindigkeit und Temperatur bermittelt Dabei steht es jedem Modul frei welche Parameter es ber den CAN Bus verf gbar macht Das VME Bus Modul 1 St ck pro PPM Der VME Bus ist ein Industriestandard zur asynchronen Daten bertragung Jedes einzelne Modul der verschiedenen Pr prozessor Crates kann ber VME angesprochen werden Der VME Bus dient hierbei vor allem der Steuerung und Konfiguration der einzelnen Komponenten der verschiedenen Pr prozessor Module Jedes Crate Modul besitzt eine eindeutige Adresse im Adressraum des VME Busses Der VME Bus des PPM wird von einem Xilinx CPLD implementiert Das VME Modul ist weiterhin f r die Konfiguration des RemFPGA zust ndig Mit der Hilfe eines Flash RAM kann das CPLD den RemFPGA mit einer von zwei m glichen Konfiguration laden siehe auch das Kapitel ber FPGA Technologien Das CPLD k mmert sich um alle Detailaspekte des komplizierten VME Bus Protokolls und stellt dem RemFPGA einen stark vereinfachten Zugang zur VME Kommunikation zur Verf gung Der Readout Merger FPGA 1 St ck pro PPM Dieser FPGA der Gegensta
24. Place and Route Schritten in eine weitere detailliertere Netzliste umgewandelt Diese neue Netzliste weist jedem internen Baustein des FPGA Chips eine spezifische Funktion zu und verwirklicht somit das in Verilog definierte Design mit Hilfe der verf gbaren Hardware 7 1 1 Kompilation mit FPGA Compiler II Innerhalb der grafischen Bedienoberfl che des FPGA Compiler II muss zun chst ein Projekt angelegt werden und s mtliche Quelldateien des RemFPGA zu diesem hinzugef gt werden Dies umfasst neben dem eigentlichen Programmcode des Designs auch Quellencode welcher von der Xilinx Software ISE Alliance 4 11 erzeugt wurde Die Hardware spezifischen Kompo nenten wie SelectRAM oder die Eingabe Ausgabebl cke des Virtex werden auf diese Weise in den RemFPGA Programmcode eingebunden F r die Generierung dieses Quellcodes dient das ISE Programm Core Generator Der Compiler ben tigt dar ber hinaus noch Informationen wie die verwendete Hardware Xilinx Virtex E 1000 oder die maximale Taktrate des Designs Weiterhin k nnen optionale Randbedingungen f r den Compiler definiert werden so genannte Constraints Einige dieser Constraints beeinflussen den Compiler in seiner Arbeitsweise andere werden lediglich in die erzeugte Netzliste eingetragen und von sp teren Arbeitsschritten wie dem Place and Route verwendet Constaints umfassen viele verschiedene Angaben wie zum Beispiel Pinzuordnungen Positionen von Speicherbl cken besondere Taktfrequ
25. Schnittstelle 17 60 R_REG_RB_STATUSOI letztes empfangenes ReadBACK R Bit0 9 Statuswort der entsprechenden seriellen Schnittstelle R_REG_RB_STATUS32 Tabelle 6 Register des RemFPGA 67 6 7 Die Verwendung des Pipelinebusses Die Grundz ge des Pipelinebusses werden in Kapitel 3 3 5 und in 8 dargelegt In diesem Abschnitt werden die einzelnen Pipelinebus Befehle des RemFPGA erl utert und die Vorge hensweise zur Dateneingabe und zur Datenauslese beschrieben 6 7 1 Die Befehle des Pipelinebusses Tabelle 7 f hrt alle Befehle des Pipelinebusses auf Ein Befehl enth lt neben dem Befehlscode dem so genannten Token und der Zieladresse auch ein 16 Bit Argument Die Bedeutung dieses Arguments ist in der Tabelle bei Bedarf ebenfalls aufgef hrt Soweit m glich wurden dieselben Befehle und Befehlscodes verwendet wie von dem Prototyp des RODs siehe 8 Einige Befehle sind jedoch neu w hrend andere nicht mehr existieren Die Befehlscodes von veralteten Befehlen wurden nicht wieder verwendet wodurch L cken im Nummerierungsschema der Codes entstehen Jedem Befehlscode ist eine Verilog Konstante zugeordnet welche in der Include Datei IncRemPLBus definiert ist Token Konstante Bedeutung h00 PBT_NOP Dummy Befehl es wird keine Aktion ausgef hrt Das Argument wird als neue Pipelinebus Node 101 PBT_LoadNodeAddress Bit 0 5 Adresse bernommen der Wert w
26. belegt Der Bereich von h100 bis h17F erlaubt den direkten Zugriff auf die internen Register des RemFPGA VME Bus und Pipelinebus k nnen gleichzeitig auf die Register zugreifen sollte ein gleichzeitiger Schreibzugriff auf dasselbe Register erfolgen so hat der Wert des VME Busses Vorrang der Wert des Pipelinebusses wird ohne Fehlermeldung verworfen Zus tzlich dienen sechs weitere Adressen zur Abwicklung der Dateneingabe und Datenausgabe Diese sind in Tabelle 13 aufgef hrt und werden im folgenden Text weiter erl utert Auch f r diese Adressen sind Verilog Konstanten in der Include Datei IncRemGlobals definiert Addr Konstante Zugriff Bedeutung 200 R VME_READFIFO R Zugriff auf das n chste Ausgabewort h201 R VME_WRITEFIFO W Zugriff auf das n chste Eingabewort Status der beiden FIFO Elemente Bit 0 ReadOUT ber FIFO aktiv Bit 1 ReadBACK ber FIFO aktiv h210 R_VME_FIFOSTATUS R Bit 2 Eingabe ber FIFO aktiv Bit 16 ReadOUT ber FIFO erlaubt Bit 17 ReadBACK ber FIFO erlaubt Bit 18 Eingabe ber FIFO erlaubt Steuerung der ReadOUT Auslese ber VME Bit0 15 Anzahl ReadOUT Daten Bit 16 ReadOUT Zyklus wurde initiiert h211 R_VME_STARTREADOUT Bit17 ReadOUT Zyklus ist aktiv Bit 18 FIFO enth lt letztes Wort Nullwert Startet einen neuen ReadOUT Zyklus nicht Null Bricht einen ReadOUT Zyklus ab 75 Addr Konstante Zugriff Bedeutung Steuerung der ReadBACK Auslese ber
27. berpr ft werden Dies gilt nat rlich auch f r die Dateneingabe ber den Pipelinebus Im Unterschied zum Pipelinebus k nnen beide FIFOs des VME Busses gleichzeitig aktiv sein 77 Kapitel 7 Synthese und Test des RemFPGA Das Pr prozessormodul welches der RemFPGA steuern wird existiert zum Zeitpunkt dieser Diplomarbeit noch nicht als funktionierende Hardware Daher erfolgten s mtliche Tests des Programmcodes ausschlie lich mit der Hilfe von Software Simulationswerkzeugen Auch eine Synthese des RemFPGA in seiner endg ltigen Form war nicht m glich da externe Parameter wie die Pinbelegung des FPGA noch nicht bekannt waren Es ist noch nicht vollst n dig gekl rt ob auf dem PPM f r die seriellen Leitungen zu den PPrASICs differentielle LVDS Signale oder unipolare Signale verwendet werden sollen was eine abschlie ende Synthese der RemFPGA ebenfalls ausschlie t Jedoch erfordert eine Anpassung an diese Parameter lediglich eine Modifikation des Top Level Moduls RemTop Der eigentliche Programmcode des RemFPGA bleibt von diesen nderungen unber hrt 7 1 Synthese des RemFPGA Die Synthese eines Xilinx FPGA Designs besteht aus mehreren Schritten Der erstellte Verilog code wird zun chst in eine so genannte Netzliste kompiliert Hierzu wurde der FPGA Compiler von Synopsys 13 verwendet Die erzeugte Netzliste wurde daraufhin mit Hilfe der Xilinx Software ISE Alliance 4 1i 15 und 16 in den so genannten Translate Map und
28. dem Level 1 Trigger m glich mit einer ausreichenden Geschwindigkeit Entscheidungen zu treffen Der Pr prozessor ist die erste signalverarbeitende Instanz und hat als solche die Aufgabe die eingehenden analogen Signale zu digitalisieren und zu kalibrieren Dar ber hinaus liefert der Pr prozessor ber Readout Daten die M glichkeit die Integrit t des Level 1 Trigger Systems zu berpr fen Insbesondere k nnen die unverarbeiteten Rohdaten direkt nach der Digitalisierung ausgelesen werden Hiermit kann man die korrekte Funktion der analogen Summation und die korrekte Kalibrierung der Daten berpr fen Auch die Zuverl ssigkeit der Algorithmen zur Identifikation des Bunch Crossings kann getestet werden Im Folgenden hat der Pr prozessor folgende Detailaufgaben 3 1 Aufgaben des Pr prozessors Wie erw hnt ist die gesamte alle 25 Nanosekunden vom ATLAS Detektor generierte Daten menge zu gro um direkt bew ltigt werden zu k nnen Daher kommt dem gesamten Level 1 Trigger System eine besonders wichtige Bedeutung zu Es ist die erste Instanz in der gesamten Triggerkette und muss ordnungsgem arbeiten Sollte der Level 2 Trigger oder der Eventfilter ausfallen kann man als Notbehelf den Level 1 Trigger mit hohen Energiegrenzwerten betrei ben Die auf diese Weise stark reduzierte Level 1 Accept Rate kann dann als behelfsm iges endg ltiges Triggersignal verwendet werden Umgekehrt jedoch sind ohne Level 1 Trigger der Level 2 Trigger und der
29. des Pr ASIA 28 3 3 4 Die Schnittstelle zum WVME CPLD essen 31 3 3 5 Das Pipelinebus Protokoll des AAA 32 4 Field Programmable Gate Arrays FPGA 37 4 1 Technischer Hintefgrund 2 2 2u 2 Re 37 4 1 1 Grundstruktur eines PPA 37 4 1 2 Der Virtex E von Xilinx BEA ee 38 4 1 3 Der Entwicklungsprozess i 2 39 5 Der Readout Merger FPGA RemFPGA 40 5 1 Grunds tzliche Aufgabenstellung eecceseeeeneeeeeeseeeseecseecaaecaecaecsseesseeeseeeseeeseeeees 40 5 1 1 Notwendigkeit der Kompression der Readout Daten 40 5 2 Design des RemFPGA Programmcodes 41 5 3 Re begeestert Etgen 42 5 3 e TE 42 5 3 2 RemSerS ync Decode eendeitege 42 3 3 3 kan sek 43 5 3 4 45 RemSerRoOCollect EE 45 536 untl denen 46 5 3 RemSerOut Omtrol E 46 3 3 8 RemserMerge ee EENS NEES AEN 46 5 39 Rem cCOntrO ee 5 32 10 RemS pre 3 321 RemSpiControl occ es EEN Eu MR a 3 32 12 RemREe Control 3 3 13 Rem V IMEC OLE m ge SERA EES RemPipe EE 531 RemMain
30. diese Datenmenge h n R_LREG_RB_DATAREADY R ReadBACK Daten werden monentan Bit 20 ausgelesen Bit 8 19 bleiben in dieser Phase konstant siehe Kapitel 6 8 Zur Entscheidung ob ReadBACK Daten zur Auslese bereit sind sollte WICHTIG immer Bit 8 19 mit Null verglichen werden Bit 7 0 sollten hierf r nicht verwendet werden Bit 0 ReadOUT ber PL Bus erlaubt Bit 1 ReadBACK ber PL Bus erlaubt Bit 2 Dateneingabe ber PL Bus erlaubt Bit 3 Register lesen ber PL Bus erlaubt Bit 4 Reg schreiben ber PL Bus erlaubt Bit 5 ReadOUT ber VME Bus erlaubt 40 R_REG_FPGA_STATUS R Bit 6 ReadBACK ber VME Bus erlaubt Bit 7 Dateneingabe ber VME Bus erlaubt Bit 8 Datenausgabe ber PL Bus aktiv Bit 9 Dateneingabe ber PL Bus aktiv Bit 10 Datenausgabe ber VME Bus aktiv Bit 11 Dateneingabe ber VME Bus aktiv 2 PL Bus Abk rzung f r Pipelinebus 64 Verilog Konstante Zugriff Bedeutung Dieses Register konfiguriert das Interrupt Signal der Easy VME Schnittstelle LOW aktiv e Interrupt wenn ReadOUT Daten Bit 0 verf gbar sind Interrupt wenn ReadBACK Daten Bit 1 verf gbar sind Interrupt wenn keine serielle Ausgabe 41 R_REG_VME_INTRMASK Bit 2 aktiv ist SerOutControl Speicher ist leer Interrupt wenn keine Ausgabe ber den PC Bus aktiv ist Bit 4 Interrupt wenn keine Ausgabe tiber den SPI Bus aktiv ist F Interrupt wenn ber den PL Bus kei
31. diesem Fall werden die eingehenden 55 Bits auf 38 Bits komprimiert was einer Kompressionsrate von 1 4 entspricht 53 19 17 16 13 12 98 5 4 110 kurze Codefolge 111 2 0 716 2 10 mittleres Codewort E RAW 01 1211 Pl 0 volles Codewort E RAW 11 Ian 17 16 13 12 ais 5 4 1 0 Beispiel 1 lelo o 1 1 1 ole o 1 n 00000 19 14 12 9 5 1 0 Beispiel 2 00111 001 11 1 1 10 01 000 34 33 22 20 101 0 0101101101 11 Abbildung 28 ReadOUT RAW Kompression Kompression von BCID Werten BCID Werte wurden in keiner der erw hnten Arbeiten analysiert da es keine statistischen Werte f r ihre Struktur gab bzw gibt Trotzdem bietet sich ebenfalls eine Huffmann inspirierte Kodie rung an denn auch hier besteht der Gro teil aus Nullwerten BCID Werte sind lediglich 8 Bit breit daher wurden lediglich zwei Codetypen verschiedener L nge gew hlt Der erh hte Bitbedarf zur Unterscheidung dreier Codetypen f hrt bei einer maximalen Codel nge von 8 Bits zu keiner Verbesserung der Kompression Die Unterscheidung der beiden Typen kann daher durch nur ein Flagbit erfolgen welches jedem Codewort vorange stellt wird Eine Verwendung von Endcodes wie bei kurzen RAW Codes ist nicht erforderlich BCID Werte sind 8 Bits breit wozu jedoch pro Wert noch drei Flagbits kommen we
32. gespeichert werden jedoch ReadBACK Statusworte Diese werden vom PPrA SIC immer dann gesendet wenn keine anderen ReadBACK Daten auszugeben sind Das Modul stellt das jeweils zuletzt empfangene Statuswort f r bergeordnete Module zur Verf gung 5 3 5 RemSerRoCollect Dieses Modul instanziiert zwei RemSerInReadout Module und stellt diesen Zugriff auf einen 32 Bit RAM Block zur Verf gung Weiterhin liefert es bergeordneten Modulen einen Mecha nismus zur Auslese dieses Speichers Selbst bei deaktivierter Komprimierung betr gt die Gr e eines Blocks an ReadOUT Daten im Normalfall nicht mehr als 6 Speicherworte bei zwei Kan len mit je einem Header einem BCID und f nf RAW Werten zu je 13 Bit ergeben sich 182 Bits Ein SelectRAM des Virtex FPGA besitzt jedoch eine Kapazit t von 4096 Bits Um ein 32 Bit RAM zur Verf gung zu stellen sind zwei SelectRAMs n tig somit ergibt sich eine Kapazit t von 8192 Bits welche zur Speicherung von ber 40 ReadOUT Events ausreicht Daher wird der Speicherblock in zwei gleich gro e Teile unterteilt und so von zwei RemSerInReadout Instanzen genutzt Das SelectRAM des Virtex ist dual ported es erlaubt zwei komplett unabh ngige gleichzeitige Zugriffe auf seinen Inhalt Einen Port teilen sich die beiden untergeordneten Module der zweite Port wird verwendet um einem bergeordneten Modul die Auslese des Speicherinhaltes zu erm glichen 45 Die komplette Verwaltung dieser Speicherzugriffe wird von di
33. im so genannten Pr prozessor Hier werden die Signale digitalisiert und kalibriert Au erdem analysiert der Pr prozessor die Eingangssignale um das bunch crossing zu identifizieren welches das Signal verursacht hat Diese Daten werden weitergeleitet an den Cluster Prozessor und den Jet Energy Sum Prozessor Eine genauere Erl uterung des Pr prozessors folgt in Kapitel 3 Der Cluster Prozessor CP erkennt einzelne Elektronen Photonen und Hadronen oberhalb einer definierbaren Energie Hierzu wird eine 4x4 Nachbarschaftsmatrix mit der Matrix der 7296 Eingangssignale multipliziert und auf diese Weise nach isolierten Energiemessungen gesucht Der Jet Energy Sum JEP Prozessor erkennt Jets und berechnet die fehlende transversale Energie Hierzu wird eine gr ere Matrix mit der Eingangsmatrix multipliziert Die Matrix ist so gew hlt dass nur Zellen erkannt werden in deren direkter Nachbarschaft sich weitere Zellen mit positiver Energiemessung befinden Die Anzahl der erf llten Bedingungen z B berschrittene Mindestenergien wird an den Central Trigger Prozessor bermittelt welcher die Level 1 Trigger Entscheidung trifft Bei einer positiven Level 1 Entscheidung Level 1 Accept Signal werden Regions of Interest RoI Informationen an den Level 2 Trigger bertragen Dies sind die Regionen die zum Level Accept gef hrt haben und vom Level 2 Trigger weiter analysiert werden Um die korrekte Funktionsweise und Kalibrierung des Kalorimeter Level
34. mit ausreichender Geschwindigkeit verarbeitet und ber den Pipelinebus bertragen werden Dies ist eine wesentliche Anforderung an das Leistungsprofil des RemFPGA 93 8 2 Fazit W hrend der Auslese von ReadOUT Daten k nnen parallel dazu ber den VME Bus beliebige Konfigurationsoperationen ausgef hrt werden Auch k nnen die Register und ReadBACK Daten der PPrASICs ohne Unterbrechung des ReadOUT Zyklus beliebig ausgelesen und ver ndert werden Weiterhin bieten der VME Bus und der Pipelinebus die exakt gleiche Funktionalit t alle Bereiche des RemFPGA k nnen beliebig ber beide Schnittstellen angesprochen werden Somit ist auch der Testbetrieb eines RemFPGA oder eines ganzen PPM mit nur einem Kommunikati onsbus m glich Bei der Entwicklung des RemFPGA wurde auf eine saubere Hierarchie des erstellten Pro grammcodes Wert gelegt Dies sichert zusammen mit den im Quellcode enthaltenen Kommenta ren die zuk nftige Anpassung des RemFPGA an neue Bed rfnisse mit Hilfe eines vertretbaren Arbeitsaufwands Auch wurde der Quellcode als ausschlie licher Informationstr ger verwendet Die Verwendung von propriet ren Werkzeugen mit eigenen zus tzlichen Projektdateien wurde soweit m glich vermieden Die durchgef hrten Tests und Simulationen des RemFPGA belegen das ordnungsgem e Funktionieren des Designs ausf hrlich Jedoch bleibt ungekl rt ob die Kapazit t des Virtex E 1000 eventuell nicht ausreichend f r dieses Design ist oder ob es
35. sie ist als Broadcast Adresse definiert und jeder angeschlossene Slave verarbeitet einen Befehl mit dieser Adresse Anschlie end kann jeder Node mit dem Befehl LoadGroupAddress eine zus tz liche Gruppenadresse zugeordnet werden Jede Node reagiert somit auf seine Node Adresse seine Gruppenadresse und die Broadcast Adresse h3F 6 7 3 Datenauslese ber den Pipelinebus ber den Pipelinebus k nnen drei verschiedene Arten von Daten ausgelesen werden ReadOUT Daten ReadBACK Daten und RemFPGA Register Die grunds tzliche Art der Daten bertra gung mit Hilfe von BeginOfData EndOfData Befehlen ist in allen drei F llen identisch und in Kapitel 3 3 5 erl utert Dieser Abschnitt erl utert den f r einen Ausgabezyklus n tigen Konfigu rationsvorgang 70 F r jeden der drei Datentypen existiert ein entsprechender Pipelinebus Start Befehl Start Readout StartReadback und StartReadRegister Bei Empfang eines solchen Befehls geht der RemFPGA in den Bereitschaftszustand f r die Ausgabe der gew nschten Daten Ein Start Befehl wird jedoch nur akzeptiert wenn sich der RemFPGA nicht schon im Wartezustand f r die Verarbeitung einer anderen Datenart befindet Sollte dies der Fall sein so lehnt der RemFP GA den Befehl ab und erzeugt ein Fehlerwort mit gesetztem Bit 10 Befehlscode nicht zul ssig Im Falle von ReadOUT oder ReadBACK wird der Befehl auch abgelehnt falls diese Datenart in diesem Moment ber den VME Bus ausgelesen wird Wird der
36. siehe Abbildung 11 SCL SCL 5 START condition STOP condition ee Abbildung 11 START und STOP Bedingungen Der Master initiiert einen Datentransfer durch das Generieren eines START Signals Hierzu zieht der Master SDA auf LOW w hrend SCL HIGH ist Danach wird SCL ebenfalls auf LOW gezogen Ben tigt ein an den PC Bus angeschlossenes Ger t Zeit um auf Aktivit t auf Bus zu reagieren so kann es ein vom Master auf LOW gezogenes SCL Signal ebenfalls aktiv auf LOW ziehen Dadurch bleibt SCL LOW selbst wenn der Master die Leitung wieder freigibt Der Master erkennt dies und wartet auf eine Freigabe des SCL Leitung durch das andere Ger t Auf diese Weise kann jedes PC Ger t einen Wartezustand auf dem Bus erzwingen Bei einer nicht ordnungsgem en Funktion eines angeschlossenen Ger ts kann dies andererseits aber auch den kompletten Bus dauerhaft blockieren Nach der START Bedingung sendet der Master 8 Bits auf den Bus und generiert anschlie end einen neunten Clockimpuls auf SCL SDA wird w hrend dieses neunten Impulses jedoch nicht vom Master getrieben Stattdessen ist es die Aufgabe des angesprochenen Slave Ger tes die SDA Leitung auf LOW zu ziehen um den Empfang zu best tigen im PC Jargon Acknowl edgement genannt siehe Abbildung 12 25 DATA OUTPUT S BY TRANSMITTER ae not acknowledge BY RECEIVER acknowledge 5 dock pulse for acknowledgem
37. stellen die Beziehungen und Abh ngigkeiten zu anderen Modulen dar Es werden die grundlegenden Ideen und Motivationen f r die Wahl der Struktur des jeweiligen Moduls dargelegt ohne dabei zu sehr ins technische Detail zu gehen Einige Illustrationen zur Hierar chie dieser Module folgen in Abschnitt 5 4 Grunds tzlich arbeitet der RemFPGA intern mit einer Taktfrequenz von 64 MHz Dieses Taktsignal wie auch ein 40 MHz Signal welches f r die seriellen Schnittstellen ben tigt wird werden auf dem PPM erzeugt und von dem VME CPLD an der RemFPGA geliefert 5 3 1 RemSerCore Dieses Modul implementiert die Grundfunktionalit t einer seriellen Schnittstelle der PPrASIC Dieses Modul implementiert jeweils ein Schieberegister f r die Ausgabe und den Empfang von seriellen 13 Bit Worten des PPrASIC Es arbeitet mit einem 40 MHz Taktsignal welches gleich zeitig auch das Taktsignal der 32 seriellen Schnittstellen darstellt Ebenfalls erzeugt wird das Frame Signal welches dem PPrASIC die Ausgabe bzw den Empfang eines kompletten 13Bit Wortes anzeigt 5 3 2 RemSerSyncDecode Dieses Modul nimmt eingehende 13Bit Worte von einem RemSerCore Modul entgegen und synchronisiert diese zur internen RemFPGA Clock von 64 MHz Jedes RemSerSyncDecode enth lt jeweils eine RemSerCore Instanz Der Typ eines empfangenen Wortes wird anhand der Flagbits in Bit 12 und 11 und der Reihen folge im Vergleich zu vorigen W rtern bestimmt Auch der Kanal eines ReadOUT Wortes wir
38. variablen Kanal Header und komprimierten ReadOUT Daten Das Modul RemSerInReadout erwartet f r jeden Kanal eine bestimmte ber Register konfigu rierbare Anzahl an BCID und RAW Werten Sendet ein PPrASIC eine andere Menge an ReadOUT Worten so werden die empfangenen Daten f r beide Kan le der betroffenen seriellen Schnittstelle verworfen und lediglich die Informationen der beiden ReadOUT Header verarbei tet Lediglich bei aktiviertem Debug Modus siehe unten werden beliebige Mengen an Rea dOUT Daten akzeptiert Die Gesamtl nge des resultierenden Datenpakets darf 256 Bits nicht berschreiten was jedoch ausreichend f r s mtliche m glichen ReadOUT Konfigurationen des PPrASICs ist Das genaue Bitschema das zur Speicherung und Komprimierung verwendet wird ist in Kapitel 6 1 darge legt Bei ordnungsgem er Synchronisation aller Bausteine des Pr prozessormoduls werden von allen 32 PPrASICs f r jedes Level 1 Accept Signal ReadOUT Daten mit identischer BCID Nummer und identischer Eventnummer erzeugt Somit m ssen statt 2 32 4 256 Bits nur 8 Bits bertragen werden Die BCID Nummer und die Eventnummer des ersten Kanals der seriellen Schnittstelle werden im 18 Bit Header abgelegt und w hrend des direkt folgenden Empfangs der Daten f r den zweiten Kanal mit diesen auf bereinstimmung berpr ft Bei fehlerhafter Synchronisation wird das entsprechende Fehlerbit im Header gesetzt Diese Informationen werden weiter verwendet von dem Mo
39. zur n chsten Node Abbildung 21 32 BusClk To From Node Abbildung 21 Latch Register des Pipelinebusses Injection Control Jeweils 8 PPMs sind mit einem ROD verbunden Dabei agiert der ROD als Master welcher als einziger neue Datenw rter auf den Bus ausgibt und sie nach einem kompletten Zyklus durch den Ring am Eingang wieder entgegen nimmt und im Normalfall vom Bus entfernt Somit steht neben dem Paritysignal eine weitere M glichkeit zur Fehlererkennung zur Verf gung vom ROD auf dem Pipelinebus ausgegebene Daten m ssen nach 9 Clockzyklen wieder am Eingang des ROD ankommen In diesem Abschnitt soll lediglich die Grundstruktur des Pipelinebusses erl utert werden Die Details des Pipelinebusses werden in einem folgenden Kapitel ausf hrlich dargelegt Struktur der Pipelinebus Daten Die beiden Kontrollleitungen des Pipelinebusses erm glichen die Unterscheidung von verschie denen Typen von 32 Bit Datenw rtern die ber den Bus bertragen werden Es wird zwischen Befehlsw rtern Command words Datenw rtern Data words und leeren W rtern Empty words unterschieden Zwei Kontrollsignale erm glichen insgesamt vier Typen der Pipelinebus definiert jedoch nur drei und der verbleibende Typ ist reserviert f r zuk nftige Erweiterungen des Protokolls siehe Abbildung 22 und Abbildung 23 1 Parity Bit 2 Control Bits 32 Data Bits Abbildung 22 Datenbreite des Pipelinebusses 33 Empty slot
40. 0000010001 cffe8011 VME R_REG_RB_DATAREADY Status 00000000000000000001000111111111 000011ff VME R_REG_RB_MEMFULL Status 00000000000000000000000000000000 00000000 E FIFO status bin 00000000000001100000000000000000 hex 00060000 ReadBACK started length of data 0011 ReadBACK 00000000 bin 00000001000100000000000001000010 01100042 VME ReadBACK 00000001 bin 00000000000000110000000010000010 hex 00030082 VME ReadBACK 00000002 bin 00000000000000000000101111111111 hex VME ReadBACK 00000003 bin 00000000000000110000100010000010 hex 00030882 VME ReadBACK 00000004 bin 00000000000000000000101111111111 hex VME ReadBACK 00000005 bin 00000000000000110001000010000010 hex 00031082 VME ReadBACK 00000006 bin 00000000000000000000101111111111 hex VME ReadBACK 00000007 bin 00000000000000110001100010000010 hex 00031882 VME ReadBACK 00000008 bin 00000000000000000000101111111111 hex VME ReadBACK 00000009 bin 00000000000000110010000010000010 hex 00032082 VME ReadBACK 0000000a bin 00000000000000000000101111111111 hex VME ReadBACK 0000000b bin 00000000000000110010100010000010 hex 00032882 VME ReadBACK 0000000c bin 00000000000000000000101111111111 hex VME ReadBACK 0000000d bin 00000000000000110011000010000010 hex 00033082 VME ReadBACK 0000000e
41. 00010000111100000001000101010101 hex 10 01155 VME Input Status 00000000000000100000000000000011 00020003 VME completing Input cycle VME Input Status 00000000000000000000000000000011 00000003 VME Input Status 00000000000000000000000000000011 00000003 DEBUG i2c_slave 10 start condition detected at 2747000 DEBUG i2c_slave 11 start condition detected at 2747000 DEBUG i2c_slave 11 command byte received write at 4028000 DEBUG i2c_slave 11 data write 66 DEBUG i2c_slave 10 stop condition detected at 5836000 DEBUG i2c_slave 11 stop condition detected at 5836000 DEBUG i2c_slave 10 start condition detected at 5992000 DEBUG i2c_slave 11 start condition detected at 5992000 DEBUG i2c_slave 10 command byte received write at 7273000 DEBUG i2c_slave 10 data write ff DEBUG i2c_slave 10 stop condition detected at 9080000 DEBUG i2c_slave 11 stop condition detected at 9080000 DEBUG i2c_slave 10 start condition detected at 9236000 DEBUG i2c_slave 11 start condition detected at 9236000 DEBUG i2c_slave 11 command byte received write at 10518000 DEBUG i2c_slave 11 data write ff DEBUG i2c_slave 10 stop condition detected at 12325000 DEBUG i2c_slave 11 stop condition detected at 12325000 DEBUG i2c_slave 10 start condition detected at 12481000 DEBUG i2c_slave 11 start condition detected at 12481000 DEBUG i2c_slave 11 command byte received write at 13762000 89 l2cSda l2cScl Nat
42. 00100010000100001111101001 hex c88843e9 PlBus Data 00000045 bin 00010001000011111010100000111011 hex 110fa83b PlBus Data 00000046 bin 10000100001111101001011001000010 hex 8439642 PlBus Data 00000047 bin 11111010100000111011110010001000 hex fa83bc88 PlBus Data 00000048 bin 11101001011001000010000100010000 hex e9642110 PlBus Data 00000049 bin 00111011110010001000100001000011 hex 3bc88843 PlBus Data 0000004 bin 01000010000100010000111110101000 hex 42110fa8 PlBus Data 0000004b bin 10001000100001000011111010010110 hex 88843896 PlBus Data 0000004c bin 00000000000000101000001110111100 hex 000283bc PlBus EndOfData Addr 01 Arg 0001 Accept 1 Clk L PlBusClkOut PlBusin 601150000 1000000000 631010000 1000000000 PIBusOut 000000000 641151000 000000000 1271010000 1710188801 1241000001 14 96421 III EEE LU II UL LU 1 13560 ns 13600 5 13640 ns Entity TestTop_1 Architecture Date Tue Apr 09 09 13 22 CEST 2002 Row 1 Page 1 Abbildung 42 Datenverkehr ber den Pipelinebus 85 7 2 3 Auslese von ReadBACK Daten ber Es folgt das Log einer Auslese von ReadBACK Daten ber VME Der Auslesezyklus wurde dabei ausgel st durch das konfigurierbare VME Interrupt Signal des RemFPGA In diesem Fall ist das Signal auf die Meldung von verf gbaren ReadBACK Daten konfiguriert Getting ReadBACK data via VME VME R_REG_DATA_STATUS Status 1100111111111110100000
43. 1 Triggers gew hr leisten zu k nnen liefern alle drei Subsysteme zus tzlich zu den direkten Entscheidungsdaten noch so genannte Readout Daten Der Pr prozessor erm glicht die Auslese von Rohdaten direkt nach der Digitalisierung und Daten nach der Vorverarbeitung CP und JEP liefern ihre jeweili gen Eingangsdaten und die Ergebnisse der Analyse Der Datenpfad des gesamten Level 1 Kalorimeter Triggers ist in Abbildung 4 dargestellt FPGA Field Programmable Gate Array siehe Kapitel 4 12 Cluster Processor CP Rol data Preprocessor PPr to LVL 2 Phi duplication Calorimeter 0 1x0 1 em and had N Jet Energy Sum JEP multiplicity of thresholds passed 7200 anal electr signals gt em amp had readout Rol data to LVL 2 readout Phi duplication 0 2 x 0 2 jet elem em and had multiplicity of thresholds passed readout Abbildung 4 Schema der Level 1 Kalorimeter Triggers 2 1 2 Der Myontrigger Auch der Myontrigger arbeitet nicht mit der vollen Granularit t des Detektors Die Eingangsda ten des Myontriggers stammen jedoch im Gegensatz zum Kalorimetertrigger nicht vom norma len Myondetektor Driftkammern sondern von spezieller Detektorhardware die nur f r die Triggerentscheidung verwendet wird Resistive Plate Chambers und Thin Gap Chambers Der Myontrigger verf gt ber sechs verschiedene programmierbare Grenzwerte f r Myonim pulse Wie auch beim Kalo
44. 11 offioio Abbildung 33 Beispiel eines ReadOUT Datenstroms 6 2 ReadBACK Daten Dieser Abschnitt beschreibt die Datenformate zur bertragung von ReadBACK Daten Diese Datenauslese ist nicht zeitkritisch weshalb auf Kompression verzichtet wird Anders als bei ReadOUT Daten wird bei einer bertragung der gesamte Inhalt des RemFPGA internen ReadBACK Speichers ausgelesen Der gesamte ReadBACK Datenblock besteht somit aus mehreren Unterbl cken Die Abschnitte 6 2 1 und 6 2 2 beschreiben das Format dieser Untereinheiten Abschnitt 6 2 3 beschreibt das Gesamtformat 57 6 2 1 Format der Lookup Tabelle des PPrASIC Der PPrASIC besitzt f r jeden Kanal eine interne Lookup Tabelle um den eingehenden 10 Bit Rohdaten einen kalibrierten 8 Bit Wert zuzuweisen unter anderem Nullstellenkorrektur und Rauschunterdr ckung siehe 12 Diese Tabelle besteht folglich aus 1024 8 Bit Werten F r die Auslese dieser Tabelle verwendet der RemFPGA ein spezielles Format Der Beginn eines Unterblocks beginnt mit einem Headerwort das eine Breite von 32 Bit besitzt Diesem Header schlie en sich die empfangenen 8 Bit Werte der Lookup Tabelle direkt an siehe Abbildung 34 und Abbildung 36 31 16 10 0 16 Bits 5 Bits 11 Bits ReadBACK Header ID der seriellen Schnittstelle L nge in 16 Bit Einheiten Abbildung 34 Header von ReadBACK Unterbl cken Die unteren 11 Bits enthalten den originalen ReadBACK Header wie er vom PPrASIC
45. 1111010100000111011 hex 110fa83b PlBus Data 0000000d bin 10000100001111101001011001000010 hex 843e9642 PlBus Data 0000000e bin 11111010100000111011110010001000 hex fa83bc88 PlBus Data 0000000 bin 11101001011001000010000100010000 hex 9642110 PlBus Data 00000010 bin 00111011110010001000100001000011 hex 3bc88843 PlBus Data 00000011 bin 01000010000100010000111110101000 hex 42110fa8 PlBus Data 00000012 bin 10001000100001000011111010010110 hex 88843e96 PlBus Data 00000013 bin 00010000111110101000001110111100 hex 10fa83bc PlBus Data 00000014 bin 01000011111010010110010000100001 hex 43 96421 PlBus Data 00000015 bin 10101000001110111100100010001000 hex a83bc888 PlBus Data 00000016 bin 10010110010000100001000100001111 hex 9642110f PlBus Data 00000017 bin 10111100100010001000010000111110 hex bc88843e PlBus Data 00000018 bin 00100001000100001111101010000011 hex 2110fa83 PlBus Data 00000019 bin 10001000010000111110100101100100 hex 88438964 PlBus Data 0000001 bin 00001111101010000011101111001000 hex Ofa83bc8 PlBus Data 0000001b bin 00111110100101100100001000010001 hex 38964211 PlBus Data 0000001c bin 10000011101111001000100010000100 hex 83bc8884 PlBus Data 0000001d bin 01100100001000010001000011111010 hex 642110 PlBus Data 0000001 bin 11001000100010000100001111101001 hex c88843e9 PlBus Data 0000001 bin 00010001000011111010100000111011 hex 110
46. 16 LVDS Signale f r Jet Energy Sum Prozessor erzeugt Allerdings m ssen einige dieser Signale doppelt an zwei verschiedene CP oder Module gesendet werden weshalb sechs LFANs nicht ausreichen und acht Chips verwendet werden m ssen Die neueren Entwicklungen auf dem FPGA Sektor f hren auch zu berlegungen eventuell statt relativ teuren LFAN Chips neue g nstige FPGAs einzusetzen die ebenfalls in der Lage sind differentielle Signale mit der entsprechenden St rke zu erzeugen W hrend jedoch die Eignung der LFAN Chips schon ausf hrlich getestet wurde 1 muss die Eignung der FPGAs noch ausgiebig analysiert werden Das TTCdec Modul 1 St ck pro PPM Das Timing Trigger and Control Modul TTC Modul siehe Kapitel 3 2 2 empf ngt ber eine optische Verbindung Signale die ber die gesamte ATLAS Architektur verteilt werden Diese optischen Signale werden vom TTC Modul empfangen und ber die Backplane elektrisch an die anderen Crate Module verteilt wo sie von jeweils einem TTCdec Tochtermodul empfan gen werden Dazu von Bedeutung f r das PPM ist unter anderem die so genannte LHC Clock welche die Protonen Bunch Crossings taktet und das Level 1 Trigger Accept Signal Die TTC Signale sind die einzige M glichkeit Module und verschiedene Crates miteinander zu synchro nisieren Dieses Tochtermodul wurde nicht speziell f r den Pr prozessor entwickelt sondern es findet Verwendung in fast allen Modulen des ATLAS Experiments 8
47. 2 Abbildung 50 1 BCID 3 RAW Level 1 Rate 100kHz 92 Abbildung 51 1 BCID 5 RAW Level 1 Rate 100kHz Das Resultat dieser Berechnungen ist die Erkenntnis dass der Pipelinebus nicht wie urspr ng lich geplant mit einer Frequenz von 40MHz betrieben werden kann Datenrate 160 MB s F r den Transport der anfallenden Datenmenge ist in fast allen Konfigurationen eine Datenrate von 60MHz mit einer Datenrate von 240 MB s erforderlich Bei einer maximalen Datenrate von 227 41 MB s wird eine noch h here Taktrate nicht ben tigt Der Pipelinebus wurde in der Vergangenheit mit einer Frequenz von 40MHz erfolgreich getestet 8 Dieser Test erfolgte mit v llig ungesch tzten Leitungen und mit einem ROD Prototyp und einer Testversion der Readout Mergers in ASIC Design RemASIC Beide verwendeten ein sehr starres und wenig robustes Timing Modell f r die Taktung des Busses und f r die bertra gung von Daten Im Besonderen wertete der ROD Prototyp das Eingangssignal synchron mit dem Ausgabetakt des Pipelinebusses aus Eine relative einfache Anpassung erm glicht die Taktung der Auswertung des Eingangs mit Hilfe des ber die Back plane bertragenen Taktsig nals Dieses unterliegt derselben Verz gerung durch Leitungseffekte wie das Datensignal Somit kann sehr einfach ein Synchronisations und Geschwindigkeitsproblem eliminiert werden Weiterhin werden die Datensignale wie in Abbildung 21 Seite 33 gezeigt durch ein Latch Register geleitet Di
48. Befehl jedoch erfolgreich verarbeitet so setzt der RemFPGA das Accept Flag und geht in Ausgabebereitschaft Um Fehler zu vermeiden sollte der Master ber den Befehl GetStatus die momentan m glichen Ausgabe modi erfragen und entsprechend reagieren siehe auch Abschnitt 6 7 5 Befindet sich der RemFPGA in Ausgabebereitschaft so werden wie erw hnt andere Start Befehl abgelehnt andere Befehle wie zum Beispiel GetDataOutInfo werden jedoch weiterhin verarbeitet Empf ngt der RemFPGA einen BeginOfData Befehl so werden folgende leere W rter mit den entsprechenden Daten gef llt siehe Kapitel 3 3 5 Seite 34 Nach Abschluss der Ausgabe f gt der RemFPGA einen EndOfData Befehl ein und geht wieder in Ausgabebe reitschaft Diese bedeutet dass f r einen weiteren Ausgabezyklus derselben Datenart kein erneuter Start Befehl n tig ist Dies hat auch den erw nschten Nebeneffekt dass der VME Bus w hrend dieser Phase komplett f r die Ausgabe dieser Datenart gesperrt bleibt Um die Bereitschaftsphase zu verlassen sendet der Master den Befehl StopData danach werden wieder beliebige neue Start Befehle akzeptiert Befindet sich der RemFPGA nicht mehr nur in Bereitschaft sondern ist aktiv mit der Datenaus gabe besch ftigt so werden s mtliche Start Befehle mit einem Fehler Bit 1 Fehler wegen aktiver Datenausgabe quittiert W hrend dieser Phase d rfen auch keine Datenw rter ber den Pipelinebus empfangen werden da der RemFPGA selbst Datenw
49. HC wird der erste Beschleuniger sein welchem der gesamte Energiebereich der postulierten Higgs Masse zug nglich sein wird Abbildung 2 zeigt die verschiedenen Wirkungsquerschnitte LHC und macht deutlich dass nur etwa eine von 10 Kollisionen ein Higgs Teilchen erzeugen wird vergleiche totalen Querschnitt Ga mit Higgs Querschnitt Somit muss viel Sorgfalt auf die Erkennung einiger weniger besonderer Ereignisse innerhalb von vielen eher uninteressanten Ereignissen gelegt werden Dies ist die Aufgabe eines so genannten Triggersystems siehe Kapitel 2 7 ALICE A Large Ion Collider Experiment 8 LHC Bottom Quarks Experiment w Constituent CM Energy GeV Accelerators e electron EES EP Higgs boson Ho t quark W Z bosons Eee E 1960 1970 1980 1990 20 2 Starting Year Abbildung 1 Geschichte der Teilchenbeschleuniger Fermilab CERN LHC 1 y T E A 1 Hb o Die 7 gt 0 25 TeV GG 5 a S ow ty amp 1 2 je gt UI 1 pb 0 001 0 01 0 1 1 0 10 100 Vs TeV Abbildung 2 LHC Proton Proton Wirkungsquerschnitt 1 3 Das ATLAS Experiment Als einer der beiden Mehrzweck Detektoren wurde ATLAS entworfen um durch Kollisionen erzeugte Teilchen in dem gesamten m glichen En
50. Huffmann Verfahren erzielt siehe Tabelle 5 absolutes Verfahren Differenzverfahren Nullstelle 0 5 10 Nullstelle 0 5 10 Rauschen J Rauschen 6 I 2 2 84 2 52 1 74 2 2 62 2 34 2 22 4 2 80 2 43 1 86 4 2 52 2 15 2 01 6 2 74 2 39 1 94 6 2 41 2 05 1 88 Tabelle 5 Kompressionsraten des verbesserten Verfahrens nach 10 Neuere Untersuchungen der zu erwartenden Energiewerte und die M glichkeit einer Nullstel lenkorrektur durch die Analog Input Module siehe 3 2 1 stellen sicher dass die Nullpunktver schiebung der Messwerte garantiert kleiner als 5 wahrscheinlich sogar kleiner als 2 sein wird Das Rauschen wird ebenfalls kleiner als 5 sein Somit ergibt sich als bestes Kompressionsver fahren f r die RAW Werte der ReadOUT Daten die verbesserte Huffmann inspirierte Kodierung im absoluten Verfahren 52 6 1 2 Kompressionsverfahren des RemFPGA Kompression von RAW Werten Das von Volker Schatz entwickelte Verfahren wird unver ndert bernommen Es wird eine per Registerwert definierte Anzahl von aufeinander folgenden RAW Werten komprimiert in den folgenden Beispielen werden f nf RAW Werte verwendet Der Algorithmus verwendet drei verschiedene Codel ngen Der lange und der mittlere Typ werden durch zwei jedem dieser Codew rter vorangestellte Flagbits identifiziert Im Gegensatz dazu wird eine Folge von aufeinander folgenden kurzen Codes nur du
51. INTEGRATIOUN o 2000110 11002000 00009000 oobooooof 00009000 2 002000 212000 012000 M WA yO Abbildung 44 ReadBACK Auslese ber VME Teil 2 88 7 2 4 Verwendung des PC Busses Zuletzt wird der Einsatz des DC Masters von OpenCores org demonstriert An der RemFPGA angeschlossen sind zwei Slave Ger te mit den Adressen 60010000 und 60010001 Die gestrichelten Linien in dem Wave Schaubild stellen den Effekt eines innerhalb des FPGA instanzierten PullUp Elements dar Auf diese Weise muss keine externere Schaltung f r diese Funktion des PC Busses verwendet werden Writing 5 words onto I2C via VME VME FIFO Status 00000000000001110000000000000000 00070000 VME Input Status 00000000000000000000000000000000 00000000 VME starting Input cycle VME Input Status 00000000000000110000000000000000 00030000 VME Input Status 00000000000000100000000000000000 00020000 VME Input writing data six 16 Bit words gt three 32 Bit VME words VME Wrote to 000201 bin 00010001011001100000000001100101 hex 11660065 VME Wrote to 000201 bin 00010001111111110001000011111111 hex 11ff10ff VME Wrote to 000201 bin
52. LBs des Virtex und den externen Anschl ssen des FPGA Pins Die Virtex IOBs bieten eine gro e Auswahl an verschiedenen VO Standards unter anderem auch den differentiellen Standard LVDS Jeder Pin kann als Eingabe Ausgabe oder zur bidirektionalen Kommunikation verwendet werden Dabei kann jeder Ausgabepin auch in einen neutralen hochohmigen Zustand versetzt werden Die maximale Ausgabe liegt bei 24mA f r unipolare Signale Block SelectRAM Alle Virtex Modelle verf gen ber mehrere interne RAM Bl cke Der Aufbau eines solchen RAM Blocks ist bei jedem Virtex Modell identisch lediglich die Anzahl der zur Verf gung stehenden Bl cke ist unterschiedlich Jedes SelectRAM bietet eine Speicherkapazit t f r 4096 Bits Dabei kann das RAM wahlweise mit einer Datenbreite von 1 2 4 8 oder 16 Bits verwendet werden SelectRAM ist vollst ndig dual ported was bedeutet dass zwei gleichzeitige Zugriffe auf das RAM m glich sind Dabei kann der erste Kanal mit einer anderen Taktung und Bitbreite arbeiten als der zweite F r den RemFPGA des PPM wird ein Xilinx Virtex E 1000 verwendet welcher ber 96 Se lectRAM Bl cke verf gt also ber 48kB internes RAM 38 Delay Locked Loop Die acht DLLs des Virtex E erm glichen neben einen Stabilisierung des eingehenden Clock Signals auch eine optionale Phasenverschiebung um 90 180 oder 270 Grad als auch eine Verdopplung oder Halbierung der Taktrate Das Ausgangssignal eines Virtex DLL ist grunds tz
53. Module besitzt einen Baustein zur Steuerung aller Unterkomponenten dieses Moduls und zur Kommunikation mit der Au enwelt Dieser so genannte Readout Merger oder RemFPGA ist Gegenstand dieser Diplomarbeit Kapitel 1 erl utert die Motivation zum Bau des LHC und die grundlegende Funktionsweise des ATLAS Detektors Kapitel 2 erkl rt die Funktion des ATLAS Triggersystems Die Arbeitsweise des Pr prozessorsystems wird in Kapitel 3 dargelegt Kapitel 4 gibt einen Einblick in die f r den RemFPGA verwendete Hardware Kapitel 5 erl utert die Funktionsweise und das im Rahmen dieser Arbeit entwickelte interne Design des RemFPGA Kapitel 6 beschreibt die Anwendung und Leistung des RemFPGA Kapitel 7 widmet sich den Tests des entwickelten RemFPGA und Kapitel 8 fasst die Resultate dieser Arbeit zusammen und gibt einen Ausblick auf die weiteren Schritte in der Entwicklung des ATLAS Systems Kapitel 1 LHC und das ATLAS Experiment Dieses Kapitel gibt einen berblick ber den physikalischen Kontext f r den Large Hadron Collider LHC und das Arlas Experiment A Toroidal LHC Apparatus entwickelt wird und das Experiment selbst 1 1 Physikalischer Kontext Die fundamentale Beschreibung unserer Welt und des Universums folgt letztendlich aus dem theoretischen Grundger st welches die fundamentalen Teilchen und ihre Interaktionen be schreibt Dieses Grundger st wird zurzeit durch das so genannte Standardmodell repr sentiert 1 1 1 Das Standardmodell Das
54. Standardmodell ist das Resultat von ca 50 Jahren theoretischer und experimenteller Forschung in der Teilchenphysik Die immer genaueren und neuen experimentellen Befunde der letzten Jahrzehnte konnten letztlich immer mit dem Standardmodell erkl rt werden oder das Modell konnte an die neuen Ergebnisse durch Verfeinerungen angepasst werden Das Standardmodell vereinheitlicht drei der vier elementaren Wechselwirkungen Die starke die schwache und die elektromagnetische Die Gravitation ist nicht einbezogen da sie zu schwach ist um auf die bisher durchgef hrten Experimente eine messbare Auswirkung zu haben Bis heute wurde noch kein einziges eindeutiges Resultat eines physikalischen Experiments gefunden welches das Standardmodell widerlegen k nnte Dieser Abschnitt soll lediglich einen groben berblick vermitteln und auf Schw chen des Standardmodells hinweisen Fundamentale Teilchen Es gibt zwei grunds tzliche Klassen fundamentaler Teilchen Es gibt Fermionen Spin 2 und Vektorbosonen Spin 1 Dabei vermitteln die Vektorbosonen die drei Grundkr fte indem sie zwischen Teilchen ausgetauscht werden Die Fermionen unterteilen sich weiter in Quarks und Leptonen Diese Fermionen kann man anhand der aufsteigenden Masse der Teilchen in drei so genannte Familien oder Generationen einordnen Vektorbosonen Wechselwirkung koppelt an Typ Masse rel St rke stark Farbe 8 Gluonen 0 20 elektromagnetisch el Ladung Photon 0 1 schwach
55. Sum Prozessor 1 LVDS Baustein des Level 1 Triggers e 1 Phos4 Chip zur Feinjustierung der Phase der LHC Clock welche als Digitalisie rungssignal f r die FADCs fungiert Der Phos4 Chip wird ber ein PC Interface pro grammiert e 1 PPrASIC Pr prozessor ASIC Der PPrASIC wurde am Kirchhoff Institut in Heidel berg entwickelt und erbringt die eigentliche Vorverarbeitungsleistung des Pr prozessors Er verarbeitet gleichzeitig die Signale von vier Kan len Der PPrASIC liefert auch die in Kapitel 3 1 erw hnten Readout Daten ber zwei spezielle serielle Schnittstellen sie he Kapitel 3 3 3 Das LFAN Modul 1 St ck pro PPM Aufgabe dieser speziellen ASIC Chips ist die bertragung der von den LVDS Ausg ngen der PPrMCMs empfangenen Daten an die entsprechenden Module des Cluster Prozessors und des Jet Energy Sum Prozessors der Level 1 Triggers Die Verbindung zu diesen Modulen erfolgt ber Kabel mit einer L nge von bis zu 20 Metern Die Signale m ssen daher mit entsprechender St rke getrieben werden was f r die kleinen LVDS Chips auf dem PPrMCM nicht m glich ist Hierzu werden acht so genannte LFAN ASICs verwendet welche in Packageform nicht als Die auf einem Tochtermodul platziert werden Der LFAN ist ein speziell in Heidelberg entwickelter ASIC Chip der jeweils 8 Ausgangskan le mit einer Datenrate von bis zu 480 Megabyte pro Sekunde realisiert Von den PPrMCMs werden insgesamt 32 LVDS Signale f r den Cluster Prozessor und
56. VME Funktion identisch zu STARTREADOUT h212 R_VME_STARTREADBACK R W Steuerung der Dateneingabe ber VME Bit0 15 Anzahl empfangender Daten Bit 16 Eingabezyklus wurde initiiert R h213 R_VME_STARTINPUT Bit17 Eingabezyklus ist aktiv Bit 18 Daten berlauf Abbruch erforderlich Nullwert Startet einen neuen Eingabezyklus nicht Null Beendet einen Eingabezyklus Tabelle 13 Datentransfer ber VME 6 8 1 Datenauslese ber die VME Schnittstelle Uber den VME Bus k nnen zwei verschiedene Datentypen ausgelesen werden ReadOUT Daten und ReadBACK Daten Der Datentransfer erfolgt mit der Hilfe eines so genannten FIFO Mechanismus F r beide Datentypen ist der FIFO an der Adresse READFIFO zust ndig Uber die beiden Adressen STARTREADOUT und STARTREADBACK wird der Datentransfer gesteuert Im Ruhezustand liefert ein Lesezugriff auf den FIFO den Wert 0 Um einen Auslesezyklus zu starten wird der Wert 0 an die Adresse STARTREADOUT oder STARTREADBACK geschrie ben Der RemFPGA geht daraufhin in Ausgabebereitschaft Dies ist jedoch nur m glich wenn nicht schon ein anderer Ausgabezyklus aktiv ist und wenn der angeforderte Datentyp nicht in diesem Moment fiir die Ausgabe ber den Pipelinebus konfiguriert ist Der Inhalt von FIFOSTATUS gibt Auskunft tiber den momentanen Zustand der VME FIFOs Nach Schreibzugriff mit dem Wert 0 auf die FIFO Steuerung ReadBACK oder ReadOUT liefert ein darauf folgen
57. W rter auf dem Bus auszugeben Der Master initiiert und kontrolliert somit jeglichen Datenverkehr ber den Bus Eine Slave Node kann nicht aus eigener Initiative Gebrauch von dem Pipelinebus machen sondern muss auf die Initiierung einer Kommunikation durch den Master warten Allerdings muss es f r einen Slave nat rlich eine M glichkeit nicht nur zum Empfang sondern auch zur Ausgabe von Daten geben Zu diesem Zweck ist es einem Slave erlaubt leere W rter durch Datenw rter zu ersetzen Im Folgenden wird das Ausf hren einer Lese und einer Schreiboperation ber den Pipelinebus kurz n her erl utert Schreiboperation Daten bertragung von Master zu Slave s Zuerst gibt der Master ein spezielles Befehlswort auf den Bus den so genannten BeginOfData Befehl Seine Adresse bestimmt den oder die Slaves die die folgenden Daten entgegennehmen sollen Mehrere Slaves k nnen durch die Verwendung einer Gruppenadresse oder der Broad cast Adresse angesteuert werden Die so adressierten Slaves gehen daraufhin in Empfangsbe reitschaft Der BeginOfData Befehl wird direkt gefolgt von einer beliebigen Anzahl von Datenw rtern welche von den entsprechenden Nodes eingelesen werden und unver ndert ber den restlichen Bus weitergeleitet werden Der Datenstrom wird abgeschlossen durch einen EndOfData Befehl Grunds tzlich m ssen Datenw rter immer von umgebenden BeginOfData und EndOfData Befehlen eingeschlossen sein 34 Leseoperation Daten be
58. W rter zu warten welche in diesem Fall nach dem vom ersten Slave ausgegeben EndOfData folgen Direkt hinter EndOfData f gt also der zweite angesprochene Slave seine Daten ein und schlie t diese wiederum durch ein eigenes EndOfData ab siehe Abbildung 24 Step Two El IE Step Three 1 2 Abbildung 24 Datentransfer vom Slave zum Master 35 Auf diese Weise kommen die verschiedenen angesprochenen Slaves nacheinander an die Reihe Sollte der Master alle acht Slave PPM angesteuert haben so empf ngt er auf seinem Eingang nach 9 Zyklen zuerst sein eigenes BeginOfData gefolgt von acht Datenbl cken die jeweils durch ein EndOfData abgeschlossen werden Danach empf ngt der Master unver nderte leere W rter so wie er sie auf dem Ausgang erzeugt hat Erst jetzt wenn der Master nach dem Empfang des kompletten Datenpakets wieder seine eigenen leeren W rter empf ngt kann er statt dieser leeren W rter wieder andere Befehle oder Daten auf den Pipelinebus ausgeben 36 Kapitel 4 Field Programmable Gate Arrays FPGA Die Aufgabe dieser Diplomarbeit war die Realisierung eines so genannten Readout Mergers durch die Programmierung eines FPGAs Dieses Kapitel erl utert die allgemeine technische Natur von FPGAs als auch die Details eines Xilinx Virtex E FPGA Chips Des Weiteren werden die verwendeten Software Werkzeuge vorgestellt und
59. ahlmaske 15 12 11 0 Datenwort 000 13 Datenwort Ausgabewort reserviert Null Datenende Abbildung 37 Datenformat fiir serielle Ausgabe Der Header des gesamten Eingabedatenstroms besitzt eine Breite von 16 Bit der in den ersten vier Bits enthaltene D Code 3 lenkt diese Daten innerhalb des RemFPGA an das Modul RemSerOutControl Jeder Unterblock beginnt mit einer 32 Bit Auswahlmaske worin jedes Bit eine serielle Schnitt stelle repr sentiert Die nachfolgenden Daten werden gleichzeitig an alle durch ein gesetztes Bit ausgew hlten Schnittstellen gesendet Auf diese Weise ist es zum Beispiel m glich bei allen 32 PPrASICs synchron die Datenverarbeitung zu aktivieren Das Ende eines Unterblocks wird durch ein gesetztes h chstes Bit des letzten Datenworts angezeigt Die einzelnen 13 Bit Daten worte werden ohne weitere Analyse oder Verarbeitung direkt an die PPrASICs gesendet Der interne Speicher des RemFPGA kann bis zu 4092 16 Bit Worte aufnehmen Bei ausreichen der verbleibender Kapazit t k nnen weitere Daten in den Speicher geschrieben werden noch w hrend ltere Daten ausgeben werden 60 6 4 Datenformat f r die PC Schnittstelle Eingangsdaten f r die Ausgabe auf den DC Bus bestehen aus einen Header mit einer L nge von 16 Bit siehe auch Abschnitt 6 3 und einer beliebigen Anzahl von 16 Bit Datenw rtern Der Header tr gt den ID Code 4 15 12 11 4 3 0 Gesamtheader 0 0 0 L nge in 16 Bit Einh 0 100
60. alisieren In der Praxis bietet ein einzelner Logikblock allerdings meist wesentlich mehr Funktionen als lediglich UND ODER X ODER Die reine Bestimmung wie Logikbl cke miteinander verkn pft werden m ssen um eine gege bene Logikaufgabe zu implementieren ist jedoch nur ein Teilaspekt der korrekten Programmie rung eines FPGA Ebenso bedeutsam ist die Platzierung der verwendeten Komponenten und ihrer Verdrahtung Es muss darauf geachtet werden dass die Verbindungen zwischen den einzelnen Komponenten innerhalb des FPGA so kurz wie m glich sind um so die Laufzeitverz gerungen von Signalen so weit als m glich zu minimieren 4 1 2 Der Virtex E von Xilinx Inc Der erste kommerzielle FPGA wurde von der Firma Xilinx 1985 auf dem Markt gebracht und bis heute ist Xilinx Marktf hrer in den meisten Bereichen des rasch wachsenden FPGA Markts In der Nomenklatur von Xilinx wird ein Logikblock CLB Configurable Logic Block genannt ein Eingabe Ausgabeblock wird Input Output Block genannt Speicherbl cke werden als Block SelectRAM bezeichnet Dar ber hinaus verf gt jeder Virtex E ber acht Delay Locked Loops DLL zur Anpassung von eingehenden Clock Signalen Zur m glichst synchronen Verteilung von Clock Signalen bietet der Virtex vier globale Clock trees somit kann intern mit bis zu vier verschiedenen unabh ngigen Taktsignalen gearbeitet werden Input Output Block IOB Die IOBs fungieren als Schnittstelle zwischen den internen C
61. als umkomprimierte 11 Bit Worte abgespeichert Dieser Modus ist besonders n tzlich wenn die ReadOUT Daten des Pr prozessormoduls von Hand analysiert werden sollen oder falls die Software zur Auswertung der Daten in einer noch unvollst ndigen Form vorliegt 5 3 4 RemSerInReadback Dieses Modul verarbeitet die ReadBACK Daten einer seriellen Schnittstelle Die eingehenden Daten werden nicht zu einem Bitstrom komprimiert da die Menge an anfal lenden ReadBACK Daten w hrend des Triggerbetriebs sehr gering ist Nur w hrend der Konfi gurationsphase vor einem Datenlauf des ATLAS Detektors fallen gr ere Mengen an ReadBACK Daten an Jedoch ist die Geschwindigkeit der Daten bertragung in dieser Phase nicht von Bedeutung Der Verzicht auf Komprimierung vereinfacht den Programmcode erheblich was zu einem wesentlich geringeren Verbrauch von FPGA Ressourcen f hrt Ein empfangenes Datenwort besitzt eine Breite von maximal 13 Bits Der Verzicht auf Komprimierung beinhaltet auch das Fehlen eines Bitschieberegisters und somit werden die empfangenen Daten auf 16 Bit Breite aufgef llt und jeweils in Paaren in einem 32 Bit RAM abgelegt Dabei teilen sich vier RemSe rInReadback Module einen RAM Block Somit werden insgesamt 16 Virtex SelectRAMs ben tigt siehe auch Abschnitt 5 3 3 Der Programmcode erkennt und verarbeitet Bl cke von ReadBACK Daten bestehend aus einem ReadBACK Header gefolgt von einer beliebigen Anzahl von ReadBACK Daten Nicht im RAM
62. be von Daten Der Ausgabe FIFO dient der Auslese von ReadOUT und ReadBACK Daten der Eingabe FIFO nimmt Daten f r die DC Bus f r die SPI Schnittstellen und f r die Ausgabe ber die seriellen Schnittstellen entgegen RemVmeCore steuert lediglich den Datentransfer der Inhalt der Daten und der Weitertransport innerhalb des RemFPGA wird von dem bergeordneten Modul Rem MainControl gesteuert Das Easy VME Protokoll definiert zus tzlich eine Interrupt Leitung Diese wird nicht von RemVmeCore kontrolliert sondern von RemRegControl ber den Inhalt von verschiedenen Registern gesteuert 5 3 14 RemPipeCore Dieses Modul implementiert den Pipelinebus Dieser Bus arbeitet mit einem vom ROD erzeug ten Taktsignal dessen Frequenz hnlich der des RemFPGA ist Eine der Hauptaufgaben dieses Moduls ist daher eine sichere Synchronisation selbst bei einer sich st ndig ndernden Phasen verschiebung zwischen den beiden Taktsignalen 2 PC Code verwaltet von Richard Herveille http www opencores org people rherveille 48 RemPipeCore verarbeitet alle eingehenden Pipelinebus Befehle Es empf ngt oder sendet Daten mit Hilfe von BeginOfData EndOfData Befehlen und erkennt und verarbeitet Parityfehler hnlich wie RemVmeCore transportiert dieses Modul lediglich Datenpakete sowohl der Inhalt als auch der Zielort wird vom bergeordneten Modul RemMainControl bestimmt 5 3 15 RemMainControl Dieses Modul kontrolliert die VME Schnittstelle un
63. ber die serielle Schnittstelle gesendet wurde Er beschreibt den Typ der folgenden ReadBACK Daten eindeutig siehe Kapitel 3 3 3 Die n chsten 5 Bits enthalten die Nummer der seriellen Schnitt stelle welche diesen Unterblock geliefert hat Die L nge des Unterblocks einschlie lich des Headers wird in 16 Bit Einheiten in den verbleibenden Wertebereich eingetragen 6 2 2 Alle anderen ReadBACK Daten Alle anderen ReadBACK Daten werden vom RemFPGA in 16 Bit Worten abgespeichert Die Breite der eigentlichen Daten betr gt lediglich 11 Bit die restlichen 5 Bits werden mit Nullen gef llt Diesen Daten geht ebenfalls der in 6 2 1 beschriebene Header voran Der darin enthalte ne ReadBACK Header erlaubt die Unterscheidung zwischen Lookup Tabelle und anderen Daten 6 2 3 Resultierendes ReadBACK Datenformat Den einzelnen Unterbl cken geht ein Gesamtheader voraus welcher eine ReadOUT hnliche Struktur besitzt siehe Abbildung 35 Diesem Header schlie en sich die einzelnen Unterbl cke mit ihren eigenen Headern an Dabei wird mit einer Datenbreite von 32 Bit gearbeitet Ein neuer Unterblock beginnt immer an einer 32 Bit Adresse der Zwischenraum wird mit Nullen aufge f llt siehe Abbildung 36 58 31 20 19 1019 4 3 0 12 Bits 10 Bits 0010 ID Wert 2 Speicher voll Histogramm verf gbar Ratemeter verf gbar Phos4 Frequency Lost
64. bin 00000000000000000000101111111111 hex O0000bff VME ReadBACK 0000000f bin 00000000000000110011100010000010 hex 00033882 VME ReadBACK 00000010 bin 00000000000000000000101111111111 hex VME ReadBACK status bin 00000000000001000000000000010001 hex 00040011 ReadBACK cycle successfully completed VME R_REG_DATA_STATUS Status 11001111111111100000000000000000 cffe0000 VME R_REG_RB_DATAREADY Status 00000000000000000000000000000000 00000000 VME R_REG_RB_MEMFULL Status 00000000000000000000000000000000 00000000 VME R_REG_RB_DATALOSS Status 00000000000000000000000000000000 00000000 86 au osre sy ose ha DDELE MOY 2002 1530 62 92 60 60 Jdy ant ejeq eunpanysay Ootsat mu eu osete Su 0022 OOHHH 00000000 4110000 08 0000000 BE 621000 ve loool ee Loop 1000 1000 Abbildung 43 ReadBACK Auslese ber Teil 1 87 2002 1539 12 22 60 60 Jdy ont ayeq 40159 su 07912 su 00 co su 09915 su 02912 su 08718 NENNEN
65. d bestimmt zur Erinnerung jedes serielle Interface bertr gt Daten f r zwei Trigger Kan le Ein eingegangenes Wort wird eingeordnet als e ReadOUT Header e ReadOUT BCID e ReadOUT RAW e ReadBACK Status e ReadBACK nicht Status Gleichzeitig wird ein von einem h heren Modul geliefertes Wort ber RemSerCore auf der seriellen Schnittstelle ausgegeben und nach vollst ndiger bertragung jeweils ein neues Wort vom h heren Modul angefordert 42 5 3 3 RemSerInReadout Dieses Modul verarbeitet die ReadOUT Daten von einem RemSerSyncDecode Modul also die Daten von einer seriellen Schnittstelle welche Informationen f r zwei Kan le bertr gt Dieses Modul komprimiert die eingehenden ReadOUT Daten und leistet damit eine der Hauptaufgaben des RemFPGA Die komprimierten Daten werden in einem RAM mit einer Datenbreite von 32 Bit abgelegt Der Virtex E 1000 verf gt ber 96 SelectRAM Bl cke mit einer maximalen Datenbreite von 16 Bit F r 32 Bit sind somit zwei parallel geschaltete SelectRAMs n tig Der RemFPGA implementiert 32 serielle Schnittstellen die unabh ngig parallel arbeiten Somit w rden 32 RemSerInReadout Module insgesamt 64 von 96 SelectRAM Bl cken ben tigen Um den RAM Bedarf zu verringern teilen sich aus diesem Grund jeweils zwei Module ein 32 Bit RAM Somit werden insgesamt nur noch 32 Bl cke ben tigt Das RAM befindet sich im Modul RemSerRoCollect siehe 5 3 5 welches jeweils zwei RemSerRoCompress Module kontrolliert
66. d den Pipelinebus Hierzu wird jeweils eine Instanz von RemVmeCore und RemPipeCore erzeugt Es verbindet die Teile des RemFPGA die lokale Schnittstellen auf dem Pr prozessormodul kontrollieren seriell PC und SPI mit den Schnittstellen die der Kommunikation mit anderen Einsch ben des Pr prozessor Crates dienen Pipelinebus mit ROD Einschub und mit Crate Controller Somit bildet dieses Modul das Zentrum des gesamten Programmcodes auch wenn die Haupt aufgaben des RemFPGA wie zum Beispiel Kompression von anderen Modulen erfiillt werden 5 3 16 RemMain Dieses Modul fasst den gesamten Programmcode des RemFPGA zusammen Es implementiert selbst keinerlei eigene Funktionalit t sondern verbindet die Datenleitungen der f nf Schliissel module RemSerMerge RemI2cControl RemSpiControl RemRegControl und RemMainControl und stellt somit den Funktionsumfang des gesamten RemFPGA zur Verf gung Die Portdefinitionen von RemMain sind die Eingangs und Ausgangssignale des RemFPGA und m ssen lediglich noch mit Pins des FPGA Chips verbunden werden 5 3 17 RemTop Dieses Modul verbindet die Datenleitungen von RemMain mit Xilinx Virtex IOB Komponenten und konfiguriert die DLLs des Xilinx f r die Verarbeitung und Chip weite Verteilung der verschiedenen Clocksignale Es stellt das so genannte Top Level Modul dar welches alle anderen Module des Programmcodes enth lt Innerhalb dieses Moduls k nnen zum Beispiel wahlweise differentielle LVDS E
67. d somit bei verst rkter Verwendung Energie absorbieren und die Kalorime termessung verf lschen Andererseits sind diese Detektoren sehr teuer und es ist nicht vollst ndig gesichert wie resistent diese Bauteile gegen ber jahrelanger harter Strahlung sind Bei einer typischen Kollision durchl uft jedes Streuteilchen drei Punktschichten acht Streifen schichten und 36 Drahtkammern was eine sehr hohe Genauigkeit der Orts und Impulsmessung erm glicht Insgesamt verf gt der Innere Detektor ber rund 146 Millionen Kan le 1 3 2 Das Kalorimeter Die Aufgabe des Kalorimeters ist die Messung der Energie aller in einer Kollision erzeugten Teilchen Lediglich Myonen und Neutrinos k nnen nicht gemessen werden da sie das Kalori meter durchdringen ohne Spuren zu hinterlassen Da das Kalorimeter aus mehreren Schichten besteht k nnen auch die Richtungen der gemessenen Teilchen bestimmt werden Diese Schichten bestehen abwechselnd aus einem Absorbermaterial und detektierendem Materi al Die zu messenden Teilchen verlieren in den Absorberschichten Energie was zur Paarproduk tion von weiteren Teilchen f hrt Diese sekund ren Teilchen produzieren auf ihrem Weg durch das Kalorimeter wiederum weiter Teilchen Auf diese Weise entsteht ein so genannter Teilchen schauer Je nach Typ der prim ren Teilchen entstehen unterschiedliche Arten von Schauern In den detektierenden Schichten erzeugen all diese Teilchen Signale proportional zu ihrer Energie Die D
68. der Lesezugriff das Resultat des Startversuchs Bei Erfolg sind die Bits 16 und 17 gesetzt und die Anzahl auszulesender Daten wird im niederwertigen Wort zurtickgeliefert Sequentielle Lesezugriffe auf den Auslese FIFO liefern den angeforderten Datenblock Befindet sich im FIFO das letzte Wort des auszulesenden Datenblocks so ist Bit 18 in der FIFO Steuerung gesetzt Bit 16 ist lediglich direkt nach dem Start eines Zyklus vor der Auslese des ersten Wortes aus dem FIFO gesetzt Danach ist lediglich Bit 17 gesetzt bis dieses nach der Auslese des letzten Wortes ebenfalls gel scht wird Die Auslese des letzten FIFO Wortes beendet den Zyklus und der RemFPGA geht wieder in den Ruhezustand ber Dies bedeutet dass sofort nach der Auslese des letzten Wortes der gerade ausgelesene Datentyp auch wieder ber den Pipelinebus angefordert werden kann Im Unterschied dazu geht der Pipelinebus nicht nach einem EndOfData wieder in den Ruhezustand sondern erst nach Emp fang eines StopData Grunds tzlich ist es irrelevant ob eine Ausleseoperation die Anzahl auszulesender Worte aus der FIFO Steuerung bezieht und verwendet oder ob immer abwechselnd Auslese FIFO und FIFO Steuerung ausgelesen werden bis schliesslich in der FIFO Steuerung Bit 18 gesetzt wird Woraufhin ein weiterer letzter Zugriff auf den Auslese FIFO zu erfolgen hat Sollte der Auslesezyklus durch einen Schreibzugriff auf die FIFO Steuerung mit einem Wert ungleich Null abgebrochen werden so verwir
69. der generelle Designprozess skizziert 4 1 Technischer Hintergrund Vor der Einf hrung von FPGAs gab es zur L sung von komplexeren Logikaufgaben im Allge meinen zwei verschiedene L sungsans tze Im Falle von einfacher Logik aber hohen Geschwindigkeitsanforderungen realisierte man die L sung mit Hilfe von ASIC Chips Diese Chips werden ausschlie lich f r einen bestimmten Zweck entwickelt und hergestellt Sie werden durch Standard Industrieprozesse auf Siliziumba sis erzeugt Es handelt sich also um eine reine Hardwarel sung Bei sehr komplexer Logik und oder nicht zu hohen Geschwindigkeitsanforderungen empfiehlt sich dagegen die Verwendung von kommerziellen Mikroprozessoren Ein Programmcode ist einfacher und schneller zu entwickeln als das Hardwaredesign eines ASIC Dar ber hinaus kann ein Programm auch beliebig ge ndert erweitert oder von Fehlern befreit werden Es handelt sich also um eine Softwarel sung Die Verwendung eines FPGA stellt dagegen eine Art Vermischung von beiden Welten dar Ein FPGA l sst sich dynamisch programmieren sein programmiertes Verhalten und seine hohe Geschwindigkeit entsprechen allerdings viel mehr dem eines ASIC als dem eines Mikroprozes Sors Dazu geh rt unter anderem dass ein Prozessor einem einzigen sequentiellen Logikstrang folgt seinem Programm w hrend ein FPGA oder ASIC beliebig viele Schaltungen parallel ausf h ren kann 4 1 1 Grundstruktur eines FPGA Grunds tzlich besteht ei
70. die Xilinx Softwareumgebung importiert Anschlie end erfolgt das Map ping in welchem dem in der Netzliste definierten Design die verf gbaren Ressourcen des Virtex E 1000 zugewiesen werden Nach diesem Schritt ist die Auslastung der FPGA Hardware bekannt Aus unbekannten Gr nden ergab sich als Resultat der Analyse einige wenige Male eine gravie rende Erh hung der FPGA Ressourcen Ein Auszug der Mapping Logdatei eines solchen Falles ist unten aufgef hrt Bei komplett neuen Kompilierungs und Mapping Schritten nach geringen von der Funktionalit t her unerheblichen nderungen des Quellcodes ist dieses Ph nomen wieder verschwunden und sp ter nicht reproduzierbar wieder aufgetaucht Der Autor vertritt die Auffassung dass dies eventuell von FPGA Compiler II verursacht wird da dieser nach einem Syntheseschritt manchmal unverst ndlich viel Arbeitsspeicher belegt und selbst nach Abschluss der Kompilierung nicht wieder freigibt Auch musste grunds tzlich die ltere von zwei verf g baren verschiedenen internen Verilog Compilern des FPFA Compiler II verwendet werden da die neuere Version nachweislich Probleme bei sp teren Optimierungs Schritt des FPGA Compi ler II verursachte Die ltere Version f hrt dagegen zum stets erfolgreichen Abschluss der Kompilierungsvorgangs Da das Mapping Ph nomen jedoch erst wenige Tage vor Abschluss dieser Diplomarbeit auftrat konnte die letztendliche Ursache nicht mehr ermittelt werden Release 4 1i Map E 30
71. dul RemSerMerge siehe Abschnitt 5 3 8 Das Modul RemSerInReadout kann die empfangenen ReadOUT Daten je nach Konfiguration in drei unterschiedlichen Formaten abspeichern Bei normaler Operation werden die empfangenen Daten komprimiert und auf Korrektheit berpr ft Die G ltigkeits berpr fung ist sehr gr ndlich und soll eventuelle Datenverf lschun gen durch Cross talk der seriellen Leitungen auf dem Pr prozessormodul erkennen helfen Folgende Fehler werden vom Programmcode erkannt e Jeder ReadOUT Zyklus muss mit einem ReadOUT Header nach einem ReadBACK Wert beginnen e falsche Reihenfolge von ReadOUT Header BCID und RAW Werten e mehr als zwei ReadOUT Header zwischen zwei ReadBACK Werten e ReadOUT Header f r 2 Kanal vor dem Header des 1 Kanals e Falsche Anzahl von BCID und oder RAW Werten 44 Bei Debug Operation werden die eingehenden ReadOUT Daten weder auf Korrektheit siert noch komprimiert Angefangen mit dem ersten ReadOUT Wert nach einem ReadBACK Wert werden die vollen 13 Bit Werte abgespeichert Der Bitstrom wird durch das den ReadOUT Daten folgende ReadBACK Wort abgeschlossen Dieser Modus empfiehlt sich vor allem zur berpr fung der seriellen Kommunikation und zur Erkennung von eventuellen Cross talk zwischen verschiedenen Leitungen Bei vereinfachter Operation werden die eingehenden Daten auf Korrektheit berpr ft jedoch nicht komprimiert Die eingehenden BCID und RAW Werte werden
72. e Daten flie en also von der Back Plane zum RemFPGA und von dort zur ck zur Backplane weiter zum n chsten RemFPGA oder ROD Das Design des RemFPGA sieht f r das Taktsignal denselben Pfad vor ohne Latch Register welches jedoch keine Verz gerung bedingt um die Signale synchron zu halten Die Testversionen des RemASIC wurden im Test jedoch mit einem parallelen unverz gerten Taktsignal gespeist Zus tzlich arbeitet der Eingang des neuen RemFPGA mit der positiven Flanke des Taktsignals w hrend neue Daten mit der negativen Flanke ausgegeben werden Dies wurde vom RemASIC nur unsauber reali siert was zu einer weiteren Synchronisationsschwierigkeit f hrte Trotz all dieser potentiellen Probleme funktionierte der Pipelinebus im Test mit 40 MHz Zieht man die Verwendung einer teilweise abgeschirmten Back Plane und die Elimination zweier erheblicher Synchronisationsprobleme in Betracht so sollte sich der Pipelinebus nun ohne weitere Probleme mit einer Geschwindigkeit von 60 MHz betreiben lassen Ein weiteres potentielles Problem bei der Datenauslese ist die Tatsache dass die maximale Level 1 Accept Rate nur ein Durchschnittswert ist Daher k nnen einige Ereignisse auch mit einer deutlich h heren Frequenz auftreten Der RemFPGA kann intern ReadOUT Daten von bis zu ungef hr 40 Level 1 Accept Ereignissen speichern Damit ist auch in diesen F llen die korrekte Verarbeitung aller Daten sichergestellt Somit k nnen alle anfallenden ReadOUT Daten
73. ehler entdeckt 1 Fehler wegen aktiver Datenausgabe 2 nicht verwendet 3 Eingabedaten konnten nicht schnell genug verarbeitet werden 4 nicht verwendet 5 Falsche Daten bertragungsrichtung 6 nicht verwendet 7 Fehler wegen aktiver Dateneingabe 8 Unbekannter Befehlscode 9 nicht verwendet 10 Befehlscode nicht zul ssig 11 15 nicht verwendet Tabelle 8 Fehlerwort des Pipelinebusses f r Definitionen von Konstanten f r die Fehlerbits siehe IncRemPLBus 6 7 2 Konfiguration der Pipelinebus Node Adresse Nach einem Systemneustart ist jede Slave Node mit der Adresse h3F und der Gruppenadresse h3E konfiguriert Die erste Aufgabe des Masters ist die Detektion der Anzahl angeschlossener Slave Nodes und die Konfiguration der Adressen aller Slaves Dies geschieht durch die Verwendung des Befehls LoadNodeAddress Der Master f llt das Adressfeld mit dem Wert h3F und Argument mit dem Wert 0 Da alle Slaves auf diese Adresse reagiert konfiguriert sich der erste Slave mit der Node Adresse 0 Er inkrementiert sodann den Wert des Arguments und schickt den Befehl an die zweite Node Diese konfiguriert sich daher mit der Node Adresse 1 Nach einem vollen Umlauf sind alle Node mit von Null ansteigenden Adressen konfiguriert und der urspr ngliche LoadNodeAddress Befehl erreicht den Master mit der Anzahl der angeschlossenen Slave Nodes im Argument Der Adresse kommt auch nach dieser Konfiguration eine besondere Bedeutung zu
74. ent MBC602 START condition Abbildung 12 Acknowlegement Die bermittelten 8 Bits des Masters enthalten die Adresse des angesprochenen Slaves und die Richtung f r den darauf folgenden Datentransfer Im Anschluss generiert der Master weitere 9 Impuls auf SCL Je nach Datenrichtung sendet oder empf ngt der Master hierbei Daten von bzw zu dem angesprochenen Slave Der neunte Clo ckimpuls dient wieder der Best tigung des Empfangs falls der Master Daten von einem Slave ausgelesen hat wird dieses Acknowledgement Signal vom Master generiert Beliebig viele weitere 9Bit Zyklen schlie en sich optional an Um den Datentransfer zu beenden sendet der Master ein STOP Signal nach einer 9Bit Daten bertragung Alle Ger te m ssen daraufhin auf dem PC Bus zur ck in den Bereitschaftszustand gehen Um statt dessen einen weiteren Datentransfer anderer Richtung oder Adresse einzuleiten sendet der Master statt des STOP Signals ein neues START Signal mit nachfolgend gesendeter Adresse des neuen Slaves Siehe auch Abbildung 13 und Abbildung 14 data transferred Tai 0 write bytes acknowledge from master to slave acknowledge SDA LOW acknowledge SDA HIGH 5 START condition MESS STOP condition Abbildung 13 2 Datentransfer Master zu Slave from slave to master 1 SLAVE ADDRESS RWJ DATA DATA V data transferred el
75. enzen f r bestimmte Bereiche des Designs und vieles mehr Diese Angaben k nnen innerhalb des Compilers gemacht werden genauso k nnen sie jedoch im Top Level Modul des Designs spezifiziert werden oder in einer zus tzlichen Textdatei oder auch bei der Verwendung anderer Werkzeuge wie zum Beispiel dem Place and Route Schritt Innerhalb der Xilinx Software gibt es ein spezielles visuelles Werkzeug zur Definition beliebiger Constraints den so genannten Floor Planer Letztendlich steht es dem Anwender frei wo und wie er diese Randbedingungen spezifiziert 79 Die Festlegung der meisten Constraints kann wegen der erw hnten Unkenntnis der wichtigsten Randparameter nicht im Rahmen dieser Diplomarbeit erfolgen und bleibt einem sp teren Benutzer berlassen Grunds tzlich wurde jedoch bei der Erstellung des Programmcodes des RemFPGA strikt darauf geachtet so wenig propriet re Softwarewerkzeuge wie m glich zu verwenden So weit m glich wurden s mtliche Definitionen und Einstellungen innerhalb des Quellcodes in Textform vorgenommen Somit wird empfohlen die zus tzlichen Constraints soweit m glich im Top Level Modul RemTop des RemFPGA zu platzieren Als weiteres komfortables Werkzeug bietet sich der Floor Planer an die Verwendung des Constraints Editors des FPGA Compiler II sollte dagegen minimiert werden 7 1 2 Mapping des Designs Nach der Kompilation durch den FPGA Compiler II wird die erstellte Netzliste im so genannten Transform Schritt in
76. er 32 Phos4 Chips die Synchronisation mit den LHC Taktsignal verloren hat Diese Fehlerinformation erh lt der RemFPGA als Teil der ReadBACK Statusworter Es wird hier den ReadOUT Daten hinzugef gt da davon auszugehen ist dass bei verlorener Synchronisation der PPrASIC fehlerhafte Daten erzeugt Abbildung 33 zeigt die ersten drei 32 Bit Worte wie sie bei einer Auslese ber den Pipelinebus oder auch den VME Bus entstehen Es sind die empfangenen und komprimierten Daten der beiden Kan le der ersten seriellen Schnittstelle abgebildet Es wurden jeweils ein BCID Wert und f nf RAW Werte empfangen Die Eventnummer aller 64 Kan le betr gt 8 0100 die BC Nummer ist ebenfalls 8 Der variable Kanal Header besitzt in den beiden abgebildeten F llen nur die Minimall nge 1 was durch den Bitwert 0 angezeigt wird Darauf folgt der BCID Wert des ersten Kanals mit einem Wert von 33 100100001 und gesetztem Flagbit B Daraufhin folgen die f nf RAW Werte 3 6 7 256 5 Bei dem letzten RAW Wert ist das E Flag gesetzt Der Kanal Header des zweiten Kanals besitzt ebenfalls nur die L nge 1 Daraufhin folgen in analoger Weise die Auslesedaten der restlichen 63 Kan le BCID1 erster Kanal BC Nr Eventnr Flags ID Wert 001000100001 10010001000000000001 RAWA voll RAWS mittel Ende RAW2 RAW1 1 11 1 Ende RAw2 RAW1 BCID1 2 Kanal RAw5 011111 1 Km 10000
77. ergiebereich messen zu k nnen Dabei wurde sehr viel Wert auf eine m glichst hohe und genaue Aufl sung der gemessenen Orts und Ener giewerte gelegt Da LHC mit sehr hohen Luminosit ten und Energien arbeitet mussten Detek torkomponenten entwickelt werden die die hohe entstehende radioaktive Strahlung ber Jahre hinweg aushalten k nnen Vor allem integrierte elektronische Schaltungen sind sehr strahlungs empfindlich Dies hatte ma geblichen Einfluss auf das Grunddesign des Detektors Der Detektor an sich besteht aus mehreren eigenst ndigen Komponenten welche im Folgenden kurz erl utert werden Der Detektor ist in Abbildung 3 schematisch dargestellt 1 3 1 Der Innere Detektor Der Innere Detektor hat die Aufgabe den Ursprungsort einer Kollision und den Weg der dabei produzierten Teilchen mit extrem hoher Genauigkeit zu messen Da sich der Detektor dar ber hinaus auch in einem Magnetfeld parallel zur Strahlachse befindet k nnen mit Hilfe von Energiemessungen der weiter au en liegenden Kalorimeter auch die Impulse von geladenen Teilchen bestimmt werden Der innerste Teil dieses Detektors besteht aus Schichten von Halbleiter Bausteinen zur punktge nauen Detektion Etwas weiter au en befinden sich Halbleiterschichten zur Streifen Detektion und zum Schluss folgen Gasz hler Drahtkammern gef llt mit Xenongas Halbleiter Detektoren werden nicht berall eingesetzt da sie einerseits einen relativ hohen Wirkungsquer schnitt besitzen un
78. es solchen Befehls Schickt der Pipelinebus Master einen Befehl auf den Pipelinebus so l scht er sowohl das Accept Flag als auch das Error Flag Das Adressfeld kann entweder mit der Adresse einer bestimmten Slave Node belegt werden oder auch mit einer Gruppenadresse siehe auch Ab schnitt 6 7 2 Empf ngt und erkennt eine adressierte Slave Node einen Befehl so f hrt er die entsprechende Aktion aus wobei unter Umst nden das Befehlsargument ver ndert wird und reicht das Befehlswort mit gesetztem Accept Flag weiter an die n chste Node Kommt das Befehlswort nach einem vollen Umlauf wieder beim Pipelinebus Master an so kann dieser erkennt ob mindestens eine Slave Node den Befehl verarbeitet hat Fehlerworte des Pipelinebusses Kann eine Slave Node einen Befehl nicht verarbeiten oder erkennt eine Node einen Parity Fehler so wird das fehlerhafte Wort durch ein Befehlswort mit gesetztem Error Flag ersetzt Die Slave Node tr gt in das Adressfeld seine eigene Node Adresse ein und f llt das Argument mit einem Fehlerwert Der Inhalt des Befehlsfeldes bleibt unver ndert Die Bedeutung der verschiedenen Bits wird in den folgenden Abschnitten n herer erl utert 129 16 15 0 6 Bits 8 Bits 16 Bits 3 Argument Befehlscode Node Adresse Accept Flag Error Flag Command ID Abbildung 40 Format eines Pipelinebus Befehls 69 Bit Bedeutung 0 Parityf
79. esamten Datenblocks wird in einem Beispiel in Abbildung 36 gezeigt Der RemFPGA hat Daten von drei verschiedenen Schnittstellen empfangen Eine komplette Lookup Tabelle von Schnittstelle Nummer 3 den Inhalt eines PPrASIC Registers ber Schnittstelle 5 und eine Ratemeterinformation ber Schnittstelle 17 Die Registerdaten ben tigen nur drei 16 Bit Worte daher wurde ein weiteres leeres 16 Bit Wort eingef gt Damit beginnt der letzte Unterblock Ratemeter wie gefordert an einer 32 Bit Adresse 6 3 Serielle Datenausgabe an die PPrASICs Dieser Abschnitt beschreibt das Format in welchem der RemFPGA Daten f r die Ausgabe auf den seriellen Schnittstellen der PPrASICs erwartet Sowohl die VME Schnittstelle wie auch der Pipelinebus verf gen ber einen generalisierten Mechanismus zum Empfang von beliebigen Eingangsdaten Erst eine Analyse des Headers dieser Daten teilt dem RemFPGA mit f r welche interne Komponente sie bestimmt sind Der RemFPGA in der vorliegenden Version akzeptiert Daten f r die seriellen Schnittstellen den PC Bus und den SPI Bus Die Unterscheidung erfolgt anhand des Wertes der ersten vier Bits des Datenstroms Ein Datenstrom f r die seriellen Schnittstellen kann aus mehreren Unterbl cken bestehen Jeder einzelne Unterblock kann gleichzeitig an eine beliebige Auswahl der 32 Schnittstellen gesendet werden 15 4 3 0 Gesamtheader L nge in 16 Bit Einheiten 0 0 1 1 31 0 Unterheader 32 Bit Ausw
80. esem Modul realisiert Die Verwendung von einem geteilten RAM anstelle von zwei unabh ngigen Bl cken ist dabei sowohl f r die ber wie auch untergeordneten Instanzen nicht ersichtlich und ohne Belang 5 3 6 RemSerRbCollect Dieses Modul hat hnlich wie RemSerRoCollect die Aufgabe einen Speicherbereich f r ber und untergeordnete Instanzen zu verwalten In diesem Fall werden vier SelectRAMs zu einem Speicherblock zusammengefasst Vier untergeordnete RemSerInReadback Instanzen teilen sich den Zugriff auf dieses RAM und im Unterschied zu RemSerRoCollect kann jeweils nur ein untergeordnetes Modul Zugriff auf diesen Speicher erlangen Ein solcher Zugriff besteht aus dem Empfang und der Speicherung eines kompletten ReadBACK Datenblocks bestehend aus einem ReadBACK Header und einer Anzahl von ReadBACK Daten Sollten w hrend dieser Phase auch die anderen drei PPrASICs ReadBACK Daten senden so k nnen diese nicht abgespeichert werden und gehen verloren Ausgenommen sind lediglich Statusworte welche von RemSerInReadback separat verarbeitet werden siehe Abschnitt 5 3 4 Diese Vorgehensweise wird haupts chlich von der Art der vom PPrASIC gesendeten Daten motiviert Die Anzahl an ReadOUT Daten die ein einzelner Auslesebefehl produziert kann bis zu 8192 Bits betragen Auslese der PPrASIC Lookup Tabelle Vier SelectRAM Bl cke bieten 16384 Speicherbits und somit k nnen die Daten von vier seriellen Schnittstellen nicht gleichzei tig abgespeichert
81. etektionsschichten sind in eine Vielzahl von einzelnen Zellen unterteilt was die r umliche Aufl sung innerhalb des Kalorimeters erm glicht Jede dieser Zellen liefert ein Signal dessen St rke proportional zur Energie des gemessenen Teilchens ist Eine Teilaufgabe des Kalorimeters ist also die m glichst starke Absorption und Paarproduktion von Teilchen Dies bedeutet dass das gesamte Kalorimeter einer sehr starken Strahlung ausge setzt ist wodurch sehr hohe Anforderungen an die verwendeten Materialen und elektronischen Schaltungen gestellt werden Das Kalorimeter des ATLAS Experiments besteht aus drei verschiedenen Einheiten Das elektromagnetische Kalorimeter Das EM Kalorimeter dient der Messung von Elektronen und Photonen Als Absorptionsmaterial wird Blei verwendet welches von Hadronen relativ ungehindert durchdrungen wird Elektronen und Photonen dagegen erzeugen starke Bremsstrahlung Als Detektionsmaterial wird fl ssiges Argon verwendet welches gute Messeigenschaften und hohe Unempfindlichkeit gegen ber der starken Strahlung in sich vereint Das elektromagnetische Kalorimeter besteht aus ber 200 000 einzelnen Zellen was eine extrem hohe r umliche Aufl sung erlaubt Das hadronische Kalorimeter Als Absorptionsmaterial f r Hadronen wird Eisen Stahl verwendet zur Detektion werden Plastikszintillatoren eingesetzt Die Absorption von hadronischen Teilchen ist wesentlich schw cher als im Vergleich die von Elektronen oder P
82. eunigern liegen um Gr enordnungen tiefer Der LHC besteht aus zwei getrennten Synchotronringen mit einem Durchmesser von 8 6 Kilometern Er wird am CERN bei Genf in den schon bestehenden Tunnel des beendeten LEP Experiments installiert und wird voraussichtlich 2006 in Betrieb gehen In den beiden Be schleunigungsringen k nnen entweder Pakete von Protonen oder von Schwerionen beschleunigt und an vier verschiedenen Stellen zur Kollision gebracht werden Wird der Beschleuniger mit Protonen betrieben treffen die Pakete alle 25 ns aufeinander bei Schwerionen alle 100 ns Beim Betrieb mit Protonen finden durchschnittlich pro Paketdurchdringung 25 Kollisionen statt Die vier Kollisionspunkte sind die Standorte von unterschiedlichen Experimenten ATLAS und CMS stellen Mehrzweck Experimente dar die ungef hr die gleichen Zielsetzun gen haben Die jeweiligen Detektoren sind von der Technik her jedoch deutlich unterschiedlich konzipiert Die Luminosit t beschreibt die Anzahl an Teilchenkollisionen pro Fl che und Zeiteinheit CERN Centre Europ enne pour la Recherche Nucl aire 7 LEP Large Electron Proton Collider das Durchdringen der beiden Teilchenwolken nennt man bunch crossing gt ATLAS A Torodial LHC Apparatus 6 CMS Compact Muon Solenoid ALICE ist ein Schwerionen Experiment und untersucht Kern Kern Wechselwirkungen bei sehr hohen Energien Die Kollisionen finden hier unter Bedingungen statt wie sie mit dem Uni
83. eutend 3 leeres Wort unbekannt unbedeutend 4 leeres Wort StartWriteRegister mit Accept von h00 5 BeginOfData an h00 leeres Wort 6 Datenwort Register h21 leeres Wort 7 Datenwort Register 122 leeres Wort 8 Datenwort Register 123 BeginOfData mit Accept von h00 9 EndOfData an 00 Datenwort Register h21 10 leeres Wort Datenwort Register 122 11 leeres Wort Datenwort Register 123 12 leeres Wort EndOfData mit Accept von h00 13 StopData an h00 leeres Wort 74 Takt Ausgabe Empfang 14 StartWriteRegister an hOl Arg h41 leeres Wort 15 leeres Wort leeres Wort 16 leeres Wort StopData mit Accept von h00 17 leeres Wort Fehlerwort mit Bit 10 von 18 Reaktion auf Fehler leeres Wort Tabelle 12 Pipelinebus Register Beispiel 6 8 Verwendung der VME Schnittstelle Die Signalabfolge zur Kommunikation ber die Easy VME Schnittstelle ist in Kapitel 3 3 4 dargelegt Dieser Abschnitt soll dagegen Auskunft geben tiber das Adressierungsschema der VME Implemetation des RemFPGA geben Grunds tzlich kann ber die 22 Adressleitungen des RemFPGA ein Adressraum von 4 MB mit einer Datenbreite von 32 Bit angesteuert werden Der RemFPGA macht jedoch nur von einem kleinen Bruchteil dieser Kapazit t gebrauch Lediglich die unteren 10 Adressbits werden verwendet und belegen so den Adressraum von 1000 bis h3FF Von diesem kleinen Bereich ist nur etwa ein Achtel mit Funktionen
84. fa83b PlBus Data 00000020 bin 10000100001111101001011001000010 hex 843e9642 PlBus Data 00000021 bin 11111010100000111011110010001000 hex fa83bc88 PlBus Data 00000022 bin 11101001011001000010000100010000 hex e9642110 PlBus Data 00000023 bin 00111011110010001000100001000011 hex 3bc88843 PlBus Data 00000024 bin 01000010000100010000111110101000 hex 42110fa8 PlBus Data 00000025 bin 10001000100001000011111010010110 hex 88843e96 PlBus Data 00000026 bin 00010000111110101000001110111100 hex 10fa83bc PlBus Data 00000027 bin 01000011111010010110010000100001 hex 43 96421 PlBus Data 00000028 bin 10101000001110111100100010001000 hex a83bc888 PlBus Data 00000029 bin 10010110010000100001000100001111 hex 9642110f PlBus Data 0000002a bin 10111100100010001000010000111110 hex bc88843e PlBus Data 0000002b bin 00100001000100001111101010000011 hex 2110fa83 PlBus Data 0000002c bin 10001000010000111110100101100100 hex 8843 964 PlBus Data 0000002d bin 00001111101010000011101111001000 hex Ofa83bc8 PlBus Data 0000002e bin 00111110100101100100001000010001 hex 3e964211 PlBus Data 0000002f bin 10000011101111001000100010000100 hex 83bc8884 PlBus Data 00000030 bin 01100100001000010001000011111010 hex 642110 PlBus Data 00000031 bin 11001000100010000100001111101001 hex c88843e9 PlBus Data 00000032 bin 00010001000011111010100000111011 hex 110fa83b PlBus Data 00000033 b
85. ft der RemFPGA die restlichen Auslesedaten in seinem internen Speicher und geht in den Ruhezustand ber 25 FIFO First In First Out 76 6 8 2 Dateneingabe ber die VME Schnittstelle Die Dateneingabe ber VME erfolgt fast vollst ndig analog zur Datenauslese In diesem Fall wird der Eingabe FIFO an der Adresse WRITEFIFO verwendet Die VME Schnittstelle des RemFPGA behandelt alle Eingabedaten gleich die Unterscheidung von seriellen Daten C Daten und SPI Daten erfolgt in anderen Teilen des RemFPGA Der Start und der Abbruch eines Eingabezyklus erfolgt absolut identisch zur Datenauslese Nach Start der Operation werden die Eingabedaten sequentiell in den Eingabe FIFO geschrieben Nach der bertragung des letzten Wortes wird der Zyklus durch das Schreiben eines Wertes ungleich Null in die FIFO Steuerung beendet Daraufhin geht der RemFPGA wieder in den Ruhezustand Vor der Beendigung eines Eingabezyklus sollte der Wert der Eingabesteuerung auf ein gesetztes Bit 18 berpr ft werden In diesem Fall war die Daten bertragung nicht erfolgreich und die eingegebenen Daten wurden verworfen Auch ein solcher fehlerhafter Zyklus muss durch einen Schreibzugriff auf die Eingabesteuerung nicht Null beendet werden Dieser Fehler tritt nur auf wenn der Adressat innerhalb des RemFPGA die Daten mangels Speicherplatz nicht empfangen konnte Der Zustand des Adressaten innerhalb des RemFPGA sollte daher zuvor durch die Auslese des Registers IN_STATUS
86. g 1 1 LHC und das ATLAS Experiment 3 1 1 Physikalischer ives eos cei ies hes Reise 3 REN RE Ee ue EE 3 1 2 Der Large Hadron Eollider EHG 2eu0222 nannte 5 1 3 Das EE 8 3 Der Innere Detektor ENEE 8 1 3 2 Das Kalorimeter eg Eed 48822 a run Beten 8 1 3 3 Das Myon Spektrometer 9 2 Das ATLAS Triggersystem 11 2 1 Der Level Trg seri eine ee DREI I 11 2 1 1 Der Trigger des Kalorimeters 00 0 0 cee ceecesccesseeeneeeeeeseeeseecaecsaecsaecsaecnseeeeeeneeeseeees 12 24 2 Der MN Ota nee nests ee i ENEE Senn 13 2 1 3 Der Central Trigger Prozessor nase 13 22 Der Beyel 2 Trigger 14 2S Der VENUS EE 14 3 Der Level 1 Kalorimetertrigger Pr prozessor 17 3 1 Aufgaben des PraproZessors ie aa 17 3 2 Design des Pr prozessorsystems a e 18 3 2 1 Die Struktur des Pr prozessormoduls PPM 19 3 2 2 Das FECModyl innn ee a len ein aan 22 3 2 3 Der Crate Controller des Pra prozessorsystems nennen 23 3 2 4 Der Readout Driver des Pr prozessorsysteMs ern 23 3 3 Schnittstellen des RemPPGA u nennen sinn Le ne 24 ope E BERA PC 24 3 3 2 Das SPI Protok ll un un RER es ee 27 3 3 3 Die serielle Schnittstelle
87. he Tabelle 1 Alle Steuersignale sind grunds tzlich low aktiv Signal Richtung Bedeutung Interrupt out Programmierbares Interruptsignal des RemFPGA Select 1 in Ein g ltiger Wert liegt an der Adressleitung an Select 2 in reserviert f r zuk nftige Verwendung R W in Schreib Lese Zugriff DS in Ein g ltiger Wert liegt an der Datenleitung an bei Schreiboperation RDY out Ein g ltiger Wert liegt an der Datenleitung an bei Leseoperation Tabelle 3 Steuersignale von Easy VME 31 Eine Leseoperation funktioniert schrittweise wie folgt VME CPLD legt einen 22 Bit Wert auf die Adressleitung VME CPLD setzt R W HIGH Leseoperation VME CPLD zieht Select 1 auf LOW RemFPGA verarbeitet die Anfrage RemFPGA legt einen 32 Bit Wert auf die Datenleitung RemFPGA zieht RDY auf LOW VME CPLD verarbeitet die Eingabe VME CPLD setzt Select 1 zur ck auf HIGH RemFPGA setzt RDY zur ck auf HIGH Eine Schreiboperation funktioniert schrittweise wie folgt VME CPLD legt einen 22 Bit Wert auf die Adressleitung VME CPLD legt einen 32 Bit Wert auf die Datenleitung VME CPLD zieht R W auf LOW Schreiboperation VME CPLD zieht DS auf LOW Daten stehen bereit VME CPLD zieht Select 1 auf LOW RemFPGA verarbeitet die Eingabe RemFPGA zieht RDY auf LOW VME CPLD setzt Select 1 zuriick auf HIGH RemFPGA setzt RDY zuriick auf HIGH S mtliche Signale sind vollst ndig asynchron Das Interruptsignal des RemFPGA wird ber i
88. hotonen Daher ist das hadronische Kalorimeter wesentlich dicker als das EM Kalorimeter Die Szintillatoren bestehen aus etwa 35 000 einzelnen Zellen Das Vorw rts Kalorimeter F r Teilchen mit Bahnen nahe an der Strahlachse gibt es das so genannte Vorw rts Kalorimeter Da in diesem Streubereich eine besonders starke Strahlung herrscht wird als Detektionsmaterial wieder fl ssiges Argon eingesetzt Etwa 11 000 Zellen dienen der r umlichen Aufl sung 1 3 3 Das Myon Spektrometer Da Myonen nur elektroschwach wechselwirken durchdringen sie das gesamte Kalorimeter fast ungehindert Das gesamte Kalorimeter ist von supraleitenden Magneten umgeben welche ein zylindersym metrisches toroidales Magnetfeld erzeugen Die von dem Feld abgelenkten Myonbahnen werden durch Driftkammern detektiert Da der gr te Teil der restlichen Teilchen im Kalorimeter absorbiert wird ist das Myon Spektrometer nur einer wesentlich schw cheren Strahlung ausgesetzt Dies macht die Verwen dung von wesentlich komplexeren elektronischen Schaltungen m glich Die Driftkammern des Myon Spektrometers produziert Messdaten aus ungef hr 440 000 einzelnen Kan len Detector characteristics Muon Detectors Electromagnetic Calorimeters 4 Ze SC A D et r V V Weight 70001 Solenoid CURN AC ATLAS veer Forward Calorimeters End Hadronic Calorimeters Abbildung 3 Schema des ATLAS Detektors 10 Kapitel 2 Das ATLAS Trigger
89. http atlasinfo cern ch Atlas Welcome html CMS Outreach http cmsinfo cern ch Welcome html CMSdocuments CMSdocuments html ATLAS Homepage des Kirchhoff Instituts http web kip uni heidelberg de atlas PPrASIC User Manual http web kip uni heidelberg de atlas DATA docs pprasic pprasicman ps 97
90. hwierigkeiten zwi schen den beiden Taktsignalen kommen In diesem Fall f gt der RemFPGA zwischen einzelnen Datenw rtern einen NOP Befehl ein Der ROD sollte daher NOP Befehle in nerhalb eines BeginOfData EndOfData Blocks grunds tzlich ignorieren Die folgenden Beispiele veranschaulichen die Anwendung des Pipelinebusses Dabei wird zur Vereinfachung von einem Bus mit einem Master und zwei Slaves ausgegangen Nach drei Taktzyklen empf ngt also der Master ein von im ausgegebenes Pipelinebus Wort wieder auf seinem Eingang Der erste Slave empf ngt ein Master Wort nach einem Taktzyklus der zweite Slave nach zwei Zyklen Auslese von ReadOUT Daten Die folgende Tabelle 9 listet die einzelnen Aktionen der drei beteiligten Pipelinebus Nodes Dabei wird davon ausgegangen dass die Slaves sich im Ruhezustand befinden und keine Fehler verursachen Wartet der Master auf Reaktionen der Slaves so sendet er in dieser Zeit leere W rter In diesem Beispiel sendet der erste Slave zwei Datenw rter und der zweite Slave drei W rter Tabelle 10 zeigt die resultierenden Datenstr me auf dem Ausgang und dem Eingang des Pipelinebus Masters Takt Aktion des Masters Aktion von Slave Aktion von Slave 1 1 sendet StartReadout an im Ruhezustand im Ruhezustand Ben geht in Ausgabebereitschaft wartet auf Best tigung geht in Ausgabebereitschaft 2 3 4 empf ngt StartReadout wartet auf BeginOfData
91. ieser Werte wie zum Beispiel die Masse haben je nach Teilchen einen bestimmten Wert aus einem kontinuierlichen Spektrum Andere Eigenschaften wie zum Beispiel der Spin k nnen lediglich diskrete Werte annehmen Diese diskreten Eigenschaften unterliegen speziellen mathematischen Symmetriebedingungen Diese Bedingungen erlauben es einen Zusammenhang zwischen verschiedenen fundamentalen Teilchen herzustellen und sie als verschiedene Auspr gungen ein und desselben Grundobjekts anzusehen Diese Auspr gungen werden auch Zust nde genannt Sie k nnen mathematisch als Vektoren in einem multidimensionalen Raum ausgedr ckt werden welche durch Symmetrie operationen ineinander bergef hrt werden k nnen Vereinfacht ausgedr ckt erfordert zum Beispiel die Existenz eines Teilchens mit schwachem Isospin 1 das W Vektorboson auch die Existenz von einem weiteren Zustand mit dem Wert 1 das W Vektorboson und einem dritten Zustand mit dem Wert 0 das so genannte W zusam men bilden sie ein so genanntes Triplett Weiterhin legt es auch die Existenz eines vierten Zustands mit nochmals dem Wert 0 nahe das so genannte B es bildet ein so genanntes Singu lett Diese Symmetrieregeln besagen jedoch lediglich dass es zwei verschiedene Zust nde mit schwachem Isospin 0 gibt also zwei verschiedene unabh ngige Vektoren Nun kann man jedoch aus zwei unabh ngigen Vektoren durch eine Drehung eine Linearkombination wieder zwei unabh ngige andere Vekt
92. igt keine externe Konfiguration und ist auch gegen ber Rauschen unempfindlich solange dieses nicht st rker als der Wertebereich des kurzen Codes ist Das Verfahren ist allerdings anf llig gegen ber einer Nullpunktsverschiebung der Daten Je gr er die Verschiebung desto wirkungsloser wird die Verwendung des kurzen Codes da ein immer gr erer Teil des kurzen Wertebereichs nicht mehr genutzt wird Huffmann inspirierte Kodierung Differenzverfahren Dieses Verfahren ist eine angepasste Form von vorigem Algorithmus Um auch robust gegen ber von Nullpunktsverschiebungen zu werden wird jeweils die Differenz zum vorangegange nen Wert gebildet und in einem kurzen oder langen Code abgelegt Allerdings ist dieses Verfahren anf lliger gegen ber von Nullpunktrauschen halbierter Wertebereich Verbesserte Huffmann inspirierte Kodierung beide Verfahren Volker Schatz befasst sich in seiner Diplomarbeit 10 unter anderem mit der Analyse der obigen Komprimierungsverfahren und schl gt als Verbesserung unter anderem die Verwendung von drei Codes kurz mittel voll vor Hinzu kommen noch einige Details zur m glichst sparsamen Identifizierung dieser drei Typen durch Flagbits Fazit der verschiedenen Verfahren Die ersten beiden Kompressionsverfahren k nnen aufgrund ihrer starken Instabilit t gegen ber u eren Einfl ssen nicht sinnvoll zur Kompression eingesetzt werden Die beste Leistung wird nach V Schatz 10 durch das verbesserte
93. in 10000100001111101001011001000010 hex 843e9642 PlBus Data 00000034 bin 11111010100000111011110010001000 hex fa83bc88 PlBus Data 00000035 bin 11101001011001000010000100010000 hex e9642110 PlBus Data 00000036 bin 00111011110010001000100001000011 hex 3bc88843 PlBus Data 00000037 bin 01000010000100010000111110101000 hex 42110fa8 PlBus Data 00000038 bin 10001000100001000011111010010110 hex 88843e96 PlBus Data 00000039 bin 00010000111110101000001110111100 hex 10fa83bc PlBus Data 0000003a bin 01000011111010010110010000100001 hex 43 96421 PlBus Data 0000003b bin 10101000001110111100100010001000 hex a83bc888 PlBus Data 0000003c bin 10010110010000100001000100001111 hex 9642110f PlBus Data 0000003d bin 10111100100010001000010000111110 hex bc88843e PlBus Data 0000003e bin 00100001000100001111101010000011 hex 2110fa83 PlBus Data 0000003f bin 10001000010000111110100101100100 hex 8843 964 84 PlBus Data 00000040 bin 00001111101010000011101111001000 hex Ofa83bc8 PlBus Data 00000041 bin 00111110100101100100001000010001 hex 38964211 PlBus Data 00000042 bin 10000011101111001000100010000100 hex 83bc8884 PlBus Data 00000043 bin 01100100001000010001000011111010 642110fa PlBus Data 00000044 bin 110010
94. in ReadBACK DataLoss h33 Bit 16 27 freier serieller Ausgabespeicher 43 Bit 28 serieller Ausgabespeicher voll h43 Bit 29 serielle Ausgabedaten verworfen h43 Flag wird bei Auslese nicht gel scht Bit 30 PC Bus ist frei h43 Bit 31 SPI Bus ist frei h43 Bit0 5 Pipelinebus Node Adresse h45 R_REG_PIPE_ADDR R Bit8 16 Pipelinebus Node Gruppenadresse Bit 0 Sende Reset an ReadOUT Module Bit 1 Sende Reset an ReadBACK Module Bit 2 Sende Reset an SerOutControl Modul h46 R_REG_SIGNALS W Bit 3 Sende Reset an PC Module Bit 4 Sende Reset an SPI Module Bit 5 Softreset des gesamten RemFPGA 66 Addr Verilog Konstante Zugriff Bedeutung Anzahl zu verarbeitender BCID Werte Ee See des ersten Kanals der Schnittstelle 01 Anzahl zu verarbeitender RAW Werte h51 R_REG_SAMPLES0218 Bit3 7 des ersten Kanals der Schnittstelle 01 Anzahl zu verarbeitender BCID Werte 138 EES Ee des zweiten Kanals der Schnittstelle 01 Bit 13 15 Anzahl zu verarbeitender RAW Werte i z des zweiten Kanals der Schnittstelle 01 R W Bit 16 20 Anzahl zu verarbeitender BCID Werte des ersten Kanals der Schnittstelle 17 Anzahl zu verarbeitender RAW Werte EE E des ersten Kanals der Schnittstelle 17 2 Anzahl zu verarbeitender BCID Werte ROREG SAMRLES1531 VE des zweiten Kanals der Schnittstelle 17 Anzahl zu verarbeitender RAW Werte HE RRB OES MET ES 1632 des zweiten Kanals der
95. ingabe Ausgabebl cke instanziiert werden oder normale unipolare IOBs Auch die genau Pinbelegung kann hier spezifiziert werden Diese Einstellungen haben jedoch keinen weiteren Effekt auf die anderen Module des RemFPGA und k nnen beliebig ge ndert werden 5 4 Schematische Illustration des Designs des RemFPGA Abbildung 27 zeigt ein Schema des gesamten RemFPGA In dieser Zeichnung sind alle Instan zen der verschiedenen Module enthalten Es ist weiterhin dargestellt welche Module welche Instanzen anderer Module enthalten Ebenfalls dargestellt sind die wichtigsten Modulverbin dungen und die Richtung des Datenflusses in ihnen Nicht enthalten sind die Virtex spezifischen Elemente innerhalb des Topmoduls RemTop 49 NVHREIOS E 2
96. ipelineBus ReadOUT To DAQ S Link Calorimeter serial gt Trigger Processors interfaces serialized data LVDS link analog signals L1Accept TTC Abbildung 9 Verbindungen der einzelnen Crate Module TTC nicht dargestellt 3 3 Schnittstellen des RemFPGA Im Folgenden sollen die Strukturen und Protokolle der verschiedenen Schnittstellen erl utert werden die mit dem RemFPGA verbunden sind Dabei ist grunds tzlich zu unterscheiden zwischen Protokollen die von verwendeten anderen Chips z B Phos4 oder PPrASIC festgelegt werden und Schnittstellen deren Implementierung teilweise oder ganz von der Programmierung des RemFPGA bestimmt werden 3 3 1 Das PC Protokoll Dieses Protokoll ist ein von Philips entwickelter Industriestandard 3 Das PC Protokoll ben tigt lediglich zwei Leitungen und erm glicht die Kommunikation von einer gro en Anzahl von Slaves mit mehreren Mastern Ein Master ist hierbei definiert als ein angeschlossenes beliebiges Ger t ASIC FPGA Mikro prozessor welches einen Datentransfer aktiv einleitet Ein Slave ist eine Instanz die sich auf dem PC Bus passiv verh lt bis sie von einem Master zur Kommunikation aufgefordert wird Dabei ist jedem Slave je nach verwendetem optionalem Zusatzprotokoll eine eindeutige Adresse von 7 oder 10 Bit L nge zugeordnet Die Daten bermittlung erfolgt in Bytes von 8 Bit L nge Das DC Protokoll ist definiert f r drei verschiede
97. ird um eins erh ht und weitergeschickt siehe Abschnitt 6 7 2 h02 PBT_StartInput Dateneingabe ber PL Bus wird aktiviert siehe Abschnitt 6 7 4 h03 PBT_StartReadout PL Bus ReadOUT Auslese wird aktiviert siehe Abschnitt 6 7 3 PBT_GetStatus Bit 0 15 Se SE PBT_SendSignal Bit 0 15 e PBT_BeginOfData Beginnt einen Datenblock siehe Kapitel 3 3 5 h10 PBT_EndOfData Beendet einen Datenblock siehe Kapitel 3 3 5 1 PBT_LoadGroupAddress Bit0 5 _ Konfiguriert die Node Gruppenadresse siehe 6 7 2 12 PBT_GetAddress Bit0 5 Enth lt die Node Adresse Bit8 13 Enth lt die Node Gruppenadresse h13 PBT_StartReadback PL Bus ReadBACK Auslese wird aktiviert siehe Abschnitt 6 7 3 14 PBT_StopData Beendet Dateneingabe ausgabe ber den PL Bus Ierzen exons IEB des Realen Auslese von Registern ber PL Bus wird aktiviert siehe 6 7 3 h17 PBT_StartReadRegister Bit0 6 Register Startadresse Bit8 14 Anzahl auszulesende Register 68 Token Konstante Bedeutung Auslese von Registern ber PL Bus wird aktiviert siehe 6 7 4 118 PBT_StartWriteRegister Bit0 6 Register Startadresse Tabelle 7 Befehle des Pipelinebusses Ein Pipelinebus Befehl wird ber den Bin rwert 10 in den beiden h chstwertigen Bits eines 34 Bit Pipelinebus Wortes identifiziert die Parity Information in Bit 35 nicht mitgerechnet Abbildung 40 zeigt die Bitbelegung ein
98. ischen den einzelnen Modulen bestehen jeweils nur so genannte horizontale und ver tikale Verbindungen und Abh ngigkeiten Diagonale Abh ngigkeiten sind zu vermei den b Mehrere Instanzen eines Modultyps werden nur in ausschlie lich einer einzigen hori zontalen Ebene verwendet c Daten flie en in wohl definierte Richtungen sie ndern auf ihrem Weg durch mehrere Module nicht die Richtung d Erfolgt ein Datenfluss ber mehrere horizontale Ebenen so werden nach M glichkeit keine Module bersprungen e Horizontaler Datenfluss ist erlaubt allerdings soweit als m glich zu minimieren f Der interne Zustand eines Moduls ist nur abh ngig von direkt verbundenen anderen Modulen Modul C Modul C Instanz 1 Instanz 2 d Modul B Modul B Instanz 1 Instanz 2 Modul A Modul A Modul A Instanz 1 Instanz 2 Instanz 3 Abbildung 25 Designregeln 41 Grunds tzlich enth lt jedes Verilog Modul umfassende Kommentare zu der Funktion des Moduls als Ganzem und den erwarteten Eingangs und Ausgangssignalen Zusammen mit diesen Designregeln und der folgenden Skizzierung der einzelnen Module ist sichergestellt dass sich bei nderungsbedarf am bestehenden Programmcode die Einarbeitungszeit in akzeptablen Grenzen h lt 5 3 Module des RemFPGA Die folgenden Abschnitte erl utern kurz die Funktion eines jeden Verilog Moduls des RemFP GA und
99. jedoch weiter untersucht werden Die logische Korrektheit des erstellten Programmcodes wurde im Rahmen dieser Diplomarbeit ausf hrlich getestet und analysiert Es muss jedoch noch abschlie end verifiziert werden ob das erstellte Design auch mit der verf gbaren Kapazit t des Virtex E 1000 realisiert werden kann 8 1 Absch tzung der ReadOUT Datenrate Die wichtigste Funktion des RemFPGA neben der Konfiguration des Pr prozessormoduls ist die Kompression von ReadOUT Daten und die bertragung ber den Pipelinebus Die Betrachtun gen in lteren Publikationen zu Kompressionsleistungen und zu erwartenden Datenraten sind aufgrund von Ver nderungen im Design des PPrASIC berholt Die bertragung von drei Flagbits mit jedem BCID Wert und von einem Flagbit mit jedem RAW Wert konnte in den lteren Untersuchungen noch nicht ber cksichtigt werden Auch wurde die Existenz des BCID Wertes von den meisten Arbeiten nicht betrachtet oder komplett ignoriert Im Folgenden werden einige detaillierte Kalkulationen zu den zu erwartenden Datenraten vorgestellt Dabei werden zwei unterschiedliche Level 1 Accept Raten 100kHz und 75kHz und verschiedene Mengen an ausgelesenen BCID und RAW Werten ber cksichtigt In diesen Berechnungen werden sehr konservative Werte f r die G te der Kompression verwendet RAW Werte werden beispielsweise mit einer Rate von nur 2 2 komprimiert w hrend die zu erwarten de Rate bei mindestens 2 4 liegen d rfte siehe Kapitel 6 1
100. kann fiir jedes einzelne Signal eine individuelle Nullstellenkorrektur durchgef hrt werden Au erdem wird f r jedes Signal bei berschreiten einer ebenfalls individuell konfigurierbaren Schwelle ein digitales so genanntes externes BCID Signal erzeugt F r die Konfigurierung der Nullstellenkalibrierung und des BCID Schwellenwertes werden pro Kanal zwei verwendet Als DACs im Speziellen werden vier kommerzielle MAXIM MAX529 verwendet Jeder MAX529 stellt acht 8Bit DACs zur Verf gung die ber die so genannte SPI Schnittstelle programmiert werden k nnen Das Pr prozessor Multi Chip Modul 16 PPrMCMs pro PPM Dieses Modul enth lt die wichtigsten Komponenten des Pr prozessors Jedes PPrMCM verar beitet vier Kan le Die vier analogen Eingangssignale werden von einem der Line Receiver Module vorverarbeitet und danach direkt zu einem der 16 PPrMCMs weitergeleitet Das PPrMCM verrichtet angefangen bei der Digitalisierung der analogen Signale alle Aufgaben die in Kapitel 3 1 erw hnt werden 16 Digital Analog Konverter 17 SPI serielles Datenprotokoll mit 3 Leitungen n heres sie Kapitel 3 3 2 20 Hierzu befinden sich auf dem PPrMCM mehrerer Chips in Die Form 4 Flash ADCs zur Digitalisierung der Eingangssignale e 3LVDS Bausteine zur differentiellen Weiterleitung der seriellen Ausgangssignale Die se Daten sind die Eingangsdaten f r den Cluster Prozessor 2 LVDS Bausteine und den Jet Energy
101. lche nicht komprimiert werden k nnen hier bezeichnet als A B und C Abbildung 29 illustriert die beiden Codetypen BCID Werte sind nicht mit Rauschen behaftet daher wurde der kurze Typ mit einem sehr kleinen Wertebereich versehen um die Nullmessungen der Detektorkan le optimal komprimieren zu k nnen ee kurzes Codewort 0 gt volles Codewort CB BCID 1 Abbildung 29 ReadOUT BCID Kompression 54 Bei Betrieb des PPrASIC mit Standardparametern wird ein BCID Wert pro ReadOUT Datensatz generiert Damit ergibt sich ein Kompressionsfaktor von 1 8 oder 0 9 je nach verwendetem Codetyp Kompression des ReadOUT Headers und des Kanal Headers Abbildung 30 zeigt das Format des vom PPrASIC f r jeden Kanal gesendeten ReadOUT Headers Die kombinierten Headerdaten aller 64 Kan le eines Pr prozessormoduls enthalten viele redundante Daten Wie in Kapitel 3 3 3 und Kapitel 5 3 3 erl utert m ssen die Werte der 64 Eventnummern und der 64 BC Nummern bereinstimmen Das Kanalbit Channel ist f r die weitere Verarbeitung unwichtig da der RemFPGA alle 64 Kan le in einer definierten Reihenfolge kodiert Das Lossflag ist durch einen Designfehler des PPrASIC immer null und kann daher ignoriert werden Somit verbleibt nur das Headers Only Flag Channel Loss Flag Headers Only Flag BC Number Event Number 10 9 8 7 4 3 D Bit Abbildung 30 Format der ReadOUT Header
102. legtem Speicher verwirft der RemFPGA alle Daten au er dem ReadOUT Header e Ung ltige Daten wird gesetzt wenn der RemFPGA Daten in einer ung ltigen Anzahl oder Reihenfolge empf ngt siehe auch Kapitel 5 3 3 e Speicher ersch pft wird gesetzt wenn der interne Eventspeicher des Moduls RemSer RoCollect zur Neige geht siehe Kapitel 5 3 3 und 5 3 5 6 1 3 Resultierendes ReadOUT Datenformat Die Komprimierung der ReadOUT Daten erfolgt innerhalb des Moduls RemSerInReadout in Verbindung mit dem Modul RemSerMerge siehe 5 3 Bei der Auslese eines ReadOUT Datenpakets ber die VME Schnittstelle oder den Pipelinebus verbindet der RemFPGA 32 von jeweils einer Instanz von RemSerInReadout erzeugten Datenpakete zu einen gesamten Bitstrom und versieht diesen mit einem vorangestellten Header von 18 Bit L nge siehe Abbildung 32 17 1413 10 BC Event gt 3 0 0001 ID Wert 1 Speicher voll Speicher fast voll x x x x x Phos4 Frequency lost falsche Eventnummer falsche BC Nummer reserviert Eventnummer BC Nummer Abbildung 32 Header der gesamten ReadOUT Daten Jeder Datenstrom der ber VME oder Pipelinebus transportiert wird enth lt in den ersten vier Bits einen ID Code welcher die folgenden Daten typisiert Einem RemFPGA ReadOUT Datenblock ist der ID Wert 1 zugeordnet Die acht h chstwertigen Bits enthalten die Event und Bunch Crossi
103. lnen Bunch Crossings des LHC Beschleunigers Dieses Signal ist f r die Synchronisation des gesamten ATLAS Sys tems unerl sslich Level 1 Kalorimeter Accept Dieses Signal zeigt eine positive Entscheidung des Le vel 1 Kalorimeter Triggers an Viele Triggerkomponenten erzeugen daraufhin Readout Daten zur Kontrolle der Performance des Triggers 22 e Reset der BC Nummer Bei jedem LHC Clock Signal inkrementieren Komponenten wie zum Beispiel der PPrASIC einen internen Z hler Mit Hilfe dieses Signals wird die so genannte BC Nummer zur ckgesetzt und so gew hrleistet dass alle Komponenten des ATLAS Systems global und synchron mit derselben Nummer arbeiten e Reset der Level 1 Event Nummer Ebenso wie f r die obige BC Nummer existiert auch ein Reset Signal f r die so genannte Event Nummer Jede positive Level 1 Trigger Entscheidung inkrementiert diese Zahl 3 2 3 Der Crate Controller des Pr prozessorsystems Bei diesem Crate Einschub handelt es sich um einen am Kirchhoff Institut in Heidelberg entwickelten AMD Athlon PC mit angeschlossenem VME Interface Der PC verf gt ber eine Festplatte einen Ethernet Netzwerk Anschluss S mtlich Kommunikation ber den VME Bus wird von diesem Crate Controller gesteuert 3 2 4 Der Readout Driver des Pr prozessorsystems F r jedes Pr prozessor Crate werden zwei Readout Driver Module ROD verwendet Jeweils acht PPMs sind ber den am Kirchhoff Institut entwickelten Pipeline Bus mit jeweils ei
104. lteten Ent scheidungsschritten Der Level 1 Trigger der Level 2 Trigger und der Eventfilter Jeder der drei Einzeltrigger verringert die Datenmenge f r die folgenden Triggersysteme Der Level 1 Trigger arbeitet auf der vollen LHC Rate von 25ns Diesem Triggersystem steht eine fest definierte Zeit Latenz zur Entscheidung zur Verf gung Bei einem positiven Resultat werden die Detektordaten bis zur Entscheidung des Level 2 Triggers aus den Pipeline Memories in einen Readout Speicher bertragen Auf diese Weise wird die Gr e der kostspie ligen Pipeline Memories minimiert Der Eventfilter schlie lich rekonstruiert und analysiert das komplette ATLAS Event und entscheidet ob dieses von physikalischem Interesse ist und abgespeichert werden soll Der Level 1 Trigger hat die Aufgabe die Datenrate von 40MHz auf maximal 100kHz zu reduzieren Der Level 2 Trigger reduziert die Rate nochmals auf maximal 1kHz Der Eventfilter schlie lich akzeptiert Ereignisse mit einer H chstrate von 100Hz Die verbleibende Datenmen ge ist noch immer sehr gro kann jedoch mit der verf gbaren Hardware bew ltigt werden 2 1 Der Level 1 Trigger Die Aufgabe des Level 1 Triggers ist es mithilfe einer m glichst schnellen Entscheidungslogik die Datenrate um den Faktor 400 zu reduzieren Der Entscheidungslogik steht dabei ein Zeit raum von 2us zur Verf gung inklusive Verz gerung durch L nge von Leitungen was 80 bunch crossings Proton Proton Durchdringungen ents
105. mFPGA Registern In diesem Beispiel werden die Register 121 bis h23 des ersten Slaves mit neuen Werten beschrieben Anschlie end werden die Register 141 und h42 des zweiten Slaves gesetzt Der zweite Slave sei jedoch schon f r die Ausgabe von ReadBACK Daten konfiguriert Siehe Tabelle 11 und Tabelle 12 73 Takt Aktion des Masters Aktion von Slave 0 Aktion von Slave 1 1 EE e im Ruhezustand 2 Great Be en geht in Eingabebereitschaft 3 in Ausgabebereitschaft f r 4 empf ngt StartWriteRegister wartet auf BeginOfData ReadBACK Daten 5 sendet BeginOfData an 100 6 sendet Datenwort Reg 121 geht in aktiven Modus 7 sendet Datenwort Reg h22 setzt Register h21 8 sendet Datenwort Reg h23 setzt Register 122 9 sendet EndOfData h00 setzt Register h23 10 wartet auf EndOfData und empf ngt EndOfData 11 sendet leere W rter in Ausgabebereitschaft f r 12 empf ngt EndOfData wartet auf BeginOfData 13 sendet StopData 100 14 See geht in Ruhezustand e wartet auf Best tigung wee 16 empf ngt StartWriteRegister 17 empf ngt Fehlerwort im Ruhezustand sendet Fehlerwort Bit 10 18 verarbeitet Fehlerzustand S EE u Tabelle 11 Pipelinebus Register Beispiel Takt Ausgabe Empfang 1 StartWriteRegister an 100 Arg h21 unbekannt unbedeutend 2 leeres Wort unbekannt unbed
106. miconductors philips com acrobat various I2C_BUS_SPECIFICATION_3 pdf Phos4 Spezifikation http bonner ntserver rice edu cms phos4 pdf Maxim MAX529 http pdfserv maxim ic com arpdf MAX528 MAX529 pdf PPrASIC http www kip uni heidelberg de atlas docs chips html B Stelzer A Read Out Driver Prototype http www kip uni heidelberg de Veroeffentlichungen ps bstelzer diplom ps gz Niemann Datenkompression f r die Auslese des ATLAS Level 1 Triggers http www kip uni heidelberg de Veroeffentlichungen ps niemann diplom ps gz Schatz Test of a Readout and Compression ASIC http www kip uni heidelberg de Veroeffentlichungen ps schatz diplom ps gz OpenCore I C Controller http www opencores org projects i2c Dan Husmann Der ATLAS Level 1 Trigger Preprozessor ASIC http www kip uni heidelberg de Veroeffentlichungen ps husmann dipl ps gz Synopsys FPGA Compiler http www synopsys com products fpga fpga_solution html Xilinx ISE 4 11 Dokumentation http support xilinx com support sw_manuals xilinx4 Xilinx ISE Alliance 4 1i http support xilinx com xInx xil_prodcat_landingpage jsp title Design Tools ModelSim 5 5 SE http www model com products default asp Povh Rith Scholz und Zetsche Teilchen und Kerne Springer Verlag 3 Aufl ATLAS Level 1 Trigger Homepage http atlas web cern ch Atlas GROUPS DAQTRIG LEVEL 1 levell html ATLAS Homepage
107. mit Hilfe von Software Simulationswerkzeugen ausgiebig getestet Der erstellte Programmcode ist modular aufgebaut um Anpassungen an zuk nftige Gegebenheiten zu erleichtern F r die effektive bertragung der anfallenden Readout Daten wurde ein in fr heren Arbeiten entwickeltes Kompressionsverfahren wesentlich verfeinert und weiterentwickelt The RemFPGA of the pre processor of the ATLAS Level Calorimeter trigger system Subject of this work is the planning and implementation of the Readout Merger that is to be used by the pre processor of the Level 1 Calorimeter Trigger of the ATLAS Detector This part of the pre processor is to be carried out with the help of FPFA technology Based on the results of research done in the past with a prototype a totally new design was developed The RemFPGA is to control and configure all other components of the pre processor module as well as to compress and transfer Readout data produced by the pre processor The used FPGA is a Virtex E 1000 from Xilinx Using the HDL language Verilog a complete design was developed for this FPGA chip und subsequently it was tested thoroughly with the help of software simulation utilities The produced Sourcecode is very modular to allow easy and effortless adjustments to changed conditions in the future To allow for effective transfer of the accumulating Readout data an existing compression schema was refined and improved significantly Inhaltsverzeichnis Einleitun
108. n Bit 5 Datentransfer erfolgt Die Bitbelegung ist mit der des obigen Registers R identisch Wenn ein Interrupt ausgel st wurde so ist sind in diesem Register die Ursache Ursachen 42 R_REG_VME_INTRFLAG abgelegt Ein Schreibzugriff l scht das Interrupt Signal Der Datenwert des Schreibzugriffs wird ignoriert 65 Addr Verilog Konstante Zugriff Bedeutung freier Speicher f r die serielle Ausgabe Bit0 11 SerOutControl Modul nur g ltig wenn Bit 12 gel scht ist Bit 12 Serieller Speicher ersch pft Serielle Ausgabedaten wurden seit der Bit 13 letzten Auslese dieses Registers verworfen Speicher war ersch pft Bit 14 Serielle Datenausgabe ist aktiv PC Daten wurden seit der letzten h43 R_REG_IN_STATUS R Bit 15 Auslese dieses Registers verworfen Datenausgabe war noch aktiv PC Bus ist frei keine Datenausgabe Bit 16 aktiv Neue Daten k nnen eingegeben und ber PC gesendet werden SPI Daten wurden seit der letzten Bit 17 Auslese dieses Registers verworfen Datenausgabe war noch aktiv SPI Bus ist frei keine Datenausgabe Bit 18 aktiv Neue Daten k nnen eingegeben und ber SPI gesendet werden Dieses Register enth lt die wichtigsten Daten der vorigen Statusregister des RemFPGA Bit0 11 ReadBACK Datenl nge h35 Bit 12 ReadOUT Daten verf gbar h26 Bit 13 mind ein ReadOUT LowMem h24 Bit 14 mind ein ReadOUT Overflow h25 h44 R_REG_DATA_STATUS R Bit 15 mind e
109. n 4 lt Daisyl nge gt 16 Bit Worte die an die vier SPI Schnittstellen gesendet werden Da es sich bei dem SPI Bus um ein serielles Schiebeprotokoll handelt landen die ersten vier Werte in den jeweils letzten angeschlossenen Ger ten Die letzten vier Werte werden zuletzt auf den Bus geschoben und werden somit in die ersten Ger te der vier Schnitt stellen geladen 61 Gesamtheader Datenwort 1 Datenwort 2 15 109 413 0 Daisybl cke Daisy nge 0 10 1 31 16 15 0 SPI Schnittstelle 2 SPI Schnittstelle 1 31 16 15 0 SPl Schnittstelle 4 SPI Schnittstelle 3 Abbildung 39 Datenformat f r SPI Ausgabe Der gesamte Datenblock kann aus mehreren dieser Daisybl cke bestehen Um alle MAX529 vollst ndig zu konfigurieren sind neun Bl cke n tig woraus sich eine Gesamtl nge von 73 32 Bit Worten ergibt Der interne Speicher des RemFPGA kann bis zu 255 32 Bit W rter aufnehmen Neue Daten werden erst nach vollst ndiger Verarbeitung der vorigen Daten akzeptiert Der SPI Bus wird mit einer Geschwindigkeit von 1MBit s betrieben 62 6 6 Die Register des RemFPGA Dieser Abschnitt erl utert die internen Register des RemFPGA S mtliche Register werden vom Modul RemRegControl verwaltet und k nnen ber VME als auch ber den Pipelinebus ange sprochen werden Bei einem gleichzeitigen Schreibzugriff auf dasselbe Register ber VME und Pipelinebus erh lt die VME Schnittstelle Vorrang der We
110. n FPGA aus einer Vielzahl von vier verschiedenen Grundkomponenten Logikbl cke bieten die Grundarchitektur f r die logische Verarbeitung von beliebigen Signalen zum Beispiel die Verkn pfung von zwei Eingangssignalen durch ein logi sches UND Ein und Ausgabebl cke erm glichen die Kommunikation ber die zu Verf gung ste henden Pins des FPFA Hardwarechips mit der angeschlossenen externen Elektronik Speicherbl cke erm glichen die Speicherung von Informationen innerhalb des Chips e Das Routing Network erm glicht die dynamische Verbindung der obigen drei Kom ponenten und die Verteilung von globalen Takt und Resetsignalen 1 ASIC Application Specific Integrated Circuit 37 Diese Komponenten sind innerhalb eines FPGA in einer Art regelm igem Gitter angeordnet Ein FPGA erm glicht nun die dynamische Programmierung dieser Komponenten und ihre dynamische Verdrahtung durch das Routing Network Diese Programmierung des FPGA erfolgt im Normalfall ein einziges Mal nach jedem Power up der entsprechenden Elektronik Danach ist die Programmierung als statisch anzusehen und kann w hrend des Betriebes des FPGA nicht mehr ge ndert werden So k nnen zum Beispiel mehrere Logikbl cke auf bestimmte Weise miteinander verbunden werden Zusammen mit der Einstellung welche dieser Bl cke als UND ODER oder Exklusiv ODER fungieren sollen l sst sich so beispielsweise die Addierung zweier Integer zahlen re
111. n Werkzeugen simuliert werden um das ordnungsgem e Funktionieren sicherstellen zu k nnen Hierbei simuliert das Werkzeug das komplette FPGA Design welches in eine so genannte Testbench eingebettet wird Aufgabe der Testbench ist die Generierung von Eingangssignalen f r die Simulation um so die Reaktion und Verarbeitung der eingehenden Signale analysieren zu k nnen Eine solche Testbench wird ebenfalls in HDL erstellt Dabei kommen das gleiche Simulationswerkzeug und die exakt gleiche Testbench f r alle drei Testschritte zum Einsatz Von Schritt zu Schritt erh ht sich lediglich die Detailtreue der Simula tion des FPGA Designs Wird nur der HDL Code simuliert so wird lediglich die logische Funktion des Designs simu liert Eine Simulation der Netlist nach Place and Route dagegen ber cksichtigt s mtliche Verz ge rungen durch Leitungsl ngen innerhalb des FPGA und teilweise auch kapazitive Effekte 39 Kapitel 5 Der Readout Merger FPGA RemFPGA Gegenstand dieser Diplomarbeit ist die Entwicklung des Verilog Programmcodes f r den RemFPGA des Pr prozessormoduls PPM Der RemFPGA ist verantwortlich f r s mtliche Konfigurationsprozesse auf dem PPM wie auch den Empfang und die anschlie ende Komprimierung von ReadOUT Daten F r die erforderli che Kommunikation mit der Au enwelt verf gt der RemFPGA ber die beiden voneinander unabh ngigen Schnittstellen VME Bus und Pipeline Bus Somit ist der RemFPGA von zentraler Bede
112. nd dieser Diplomarbeit ist befindet sich direkt auf dem PPM und nicht auf einem Tochtermodul Es handelt sich um einen Xilinx Virtex E 1000 in einem Ball Grid Array Package 560 2 An der Virtex direkt angeschlossen ist ein 2 MB Speicher chip er wird jedoch von dem in dieser Diplomarbeit vorgestellten Programmcode nicht ben tigt Er steht f r sp tere Erweiterungen zur Verf gung Der RemFPGA ist mit beinahe allen anderen Modulen des PPM verbunden und kontrolliert und steuert diese Die Kommunikation mit der Au enwelt erfolgt einerseits ber den VME Bus mit Hilfe des VME Moduls und ber den speziell entwickelten Pipeline Bus welcher vom RemFPGA direkt gesteuert wird Seine Hauptaufgaben bestehen in der Konfiguration des gesamten PPM und der bertragung von Readout Daten ber wahlweise den VME Bus oder den Pipeline Bus Die genaue Funktion wird in den folgenden Kapiteln dargestellt 3 2 2 Das TTC Modul F r die Synchronisation des gesamten ATLAS Experiments dienen eine Reihe von globalen ATLAS Signalen die ber optische Verbindungen an die einzelnen Komponenten des ATLAS Systems verteilt werden Zum Empfang dieser Daten und der Konvertierung in elektrische Signale dient das TTC Modul Die empfangenen TTC Signale werden an alle anderen Module des jeweiligen Crates verteilt Jedes Crate des Level 1 Triggers verf gt ber ein solches Modul Zu den Signalen geh ren unter anderem LHC Clock Dieses Signal taktet die einze
113. ne Geschwindigkeitsstufen von 100kBit Normal 400kBit Fast und 3 4MBit Highspeed pro Sekunde Dabei ist der 400kBit Modus abw rtskompatibel zum Normalmodus w hrend der Highspeed Betrieb einer hierzu inkompa tiblen Spezifikation folgt Im Falle der PPM wird lediglich der 100kBit Modus verwendet und der RemFPGA fungiert als einziger Master Daher werden im Folgenden nur die vom PPM ben tigten I C Funktionalitaten kurz erl utert F r eine ausf hrlichere Darstellung sei auf die Spezifikation von Philips verwie sen 4 24 Die PC Datenleitungen und Master Server Kommunikation Die beiden Leitungen des PC Busses bestehen aus bidirektionalen Leitungen die an einen Pull Up Widerstand angeschlossen sind Wenn kein Ger t den DC Bus anspricht ist der Zustand der beiden Leitungen somit HIGH Eine Leitung fungiert als Clocksignal SCL und die zweite Leitung als Datensignal SDA Bei dem Transfer von Datenbits muss der Zustand von SDA w hrend der HIGH Periode von SCL stabil sein F r jedes zu bertragende Bit wird vom PC Master ein Clocksignal generiert siehe Abbildung 10 data line change stable of data data valid allowed MBC621 Abbildung 10 Datentransfer auf dem PC Bus Zus tzlich definiert der DC Bus die Generierung zweier spezieller Befehlssignale namens START und STOP Diese werden durch einen HIGH LOW START bzw einen LOW HIGH STOP bergang auf SDA generiert w hrend SCL HIGH ist
114. nem ROD verbunden Der ROD verf gt dar ber hinaus ber einen Anschluss an den VME Bus Jedoch wird dieser nicht f r die Kommunikation zwischen ROD und PPM verwendet sondern ausschlie lich f r Datenverkehr zwischen Crate Controller und ROD Die von den verschiedenen PPrASICs generierten Readout Daten werden vom ROD Modul empfangen und ber eine Anzahl von so genannten S LINK Verbindungen an das Datenverar beitende System des ATLAS Level 1 Kalorimeter Triggers weitergeleitet S LINK Verbindun gen existieren in verschiedenen Geschwindigkeitsausf hrungen und die genaue Zahl und Art der zu verwendenden Verbindungen war zum Zeitpunkt dieser Diplomarbeit noch nicht endg ltig festgelegt Der Gro teil der Funktionalit t des ROD wird ebenfalls von einem Xilinx Virtex E 1000 implementiert werden Zum Zeitpunkt dieser Arbeit existiert lediglich eine ltere Version des Programmcodes des ROD FPGAs welcher f r einen Prototyp des Readout Mergers entwickelt wurde Dieser Prototyp war in einem ASIC implementiert RemASIC Der neue RemFPGA der im Rahmen dieser Arbeit entwickelt wurde ist mit dem Interface des RemASIC nicht mehr kompatibel Der noch zu erstellende neue Code des ROD FPGA kann jedoch voraussichtlich zu weiten Teilen von dem bestehenden Programmcode abgeleitet werden 23 Crate Controller 1 per crate ia VME Bus ReadBACk ReadoutDriver Module 2x1 per crate SCH a Crate Controller PreProcessor Modules 2x8 per crate P
115. ng Nummer des ersten Kanals der ersten seriellen Schnittstelle Die Werte der anderen Kan le werden wie im vorigen Abschnitt erl utert nicht bertragen da sie bei korrekter Synchronisation identisch sein m ssen Sollte eine bereinstimmung nicht gegeben sein so wird das entsprechende falsche Nummer Fehlerbit im Header gesetzt Sollten die Eventnum mern nicht korrekt sein so verwirft der RemFPGA alle ReadOUT Daten und bertr gt lediglich den 18 Bit Header 56 Die Speicher Fehlerbits werden gesetzt wenn Daten von mindestens einer seriellen Schnittstelle nicht abgespeichert werden konnten da der entsprechende interne Speicherblock des RemFPGA voll oder fast voll war siehe 5 3 3 und 5 3 5 Diese beiden Bits beziehen sich nicht auf den Zustand des Speichers zurzeit des Empfangs der ReadOUT Daten die dieser Header beschreibt Stattdessen werden diese beiden Bits erst zum Zeitpunkt der Auslese ber den VME Bus oder den Pipelinebus gesetzt Sie informieren daher ber den momentanen Zustand des RemFPGA Bei einer v llig ersch pften Speicherkapazit t werden neue ReadOUT Daten komplett verwor fen In diesem Zustand ist es f r auslesende Instanzen nicht ersichtlich ob und wie viele ReadOUT Datens tze verworfen wurden Bei einer lediglich nahezu ersch pften Speicherkapa zit t speichert der RemFPGA lediglich die Informationen aus ReadOUT Headern BCID und RAW Werte werden verworfen Das Phos4 Fehlerbit gibt Auskunft ob mindestens einer d
116. ngangsdaten Hierzu werden jeweils 4 der 7296 vorverarbeiteten Signals aufsummiert e Serielle differentielle Daten bertragung Die vorverarbeiteten Daten werden ber eine serielle LVDS Verbindung an den Cluster Prozessor und den Jet Energy Sum Prozessor zur weiteren Verarbeitung ber tragen e Readout von Trigger Daten Um die korrekte Funktion des Pr prozessors zu berpr fen k nnen die unverarbeiteten Rohdaten RAW ausgelesen werden e Readout von Histogramm und Ratemeter Informationen Der PPrASIC verf gt zus tzlich ber die M glichkeit ein Histogramm und Ratenmes sungen zu erstellen Auch diese Informationen m ssen bei Bedarf ausgelesen werden 3 2 Design des Pr prozessorsystems Dem gesamten Level 1 Trigger stehen 80 Bunch Crossings 2us an Zeit zur Verf gung um eine Einscheidung zu treffen dies beinhaltet Signalverz gerungen durch Kabelverbindungen Dem Pr prozessor des Triggers stehen maximal 18 Bunch Crossings zur Verf gung Diese sehr kurze Zeitspanne macht den Einsatz von hochintegrierten Schaltungen wie dem PPrASIC Pre Processor ASIC n tig Der Hauptteil der Aufgaben des Pr prozessorsystems wird von so genannten Pr prozessormo dulen PPM ausgef hrt Jedes einzelne PPM kann 64 analoge Eingangssignale verarbeiten Das gesamte System verwendet 128 identische PPMs welche somit insgesamt bis zu 8192 Kan le anbieten Jeweils 16 PPMs werden in einem Elektronik Crate untergebracht zusammen mit 4 weiteren Kont
117. ngesetzte Kompression ausf hrlich erl utert und das daraus resultierende Datenformat erkl rt Der RemFPGA kann mehrere komplette ReadOUT Datenbl cke in seinem internen Speicher ablegen je nach Kompression 15 bis 30 St ck Jede Aufforderung an den RemFPGA dOUT Daten auszulesen f hrt jedoch nur zur bertragung eines solchen Datenblocks Bei korrekter Synchronisation der PPrASICs liefert somit ein Auslesezyklus die Daten eines Level Accept Ereignisses 6 1 1 Untersuchte Kompressionsverfahren Bernhard Niemann entwickelt und untersucht in seiner Diplomarbeit vier verschiedene Algo rithmen ausschlie lich zur Kompression von ReadOUT RAW Werten Huffmann Kodierung Dieses Verfahren bildet eine der Grundlagen der auf Personal Computern weit verbreiteten zip oder 27 Kompression ber einen Bin rbaum wird jedem m glichen Wert ein bin rer Code von variabler L nge zugewiesen H ufig auftretende Werte erhalten einen kurzen Bin rcode seltene Werte einen l ngeren Code Dieses Verfahren ist bei einem optimal gew hlten Bin rbaum u erst leistungsstark Dieser Bin rbaum stellt jedoch im Fall des RemFPGA ein Problem dar Ein FPGA verf gt nicht ber ausreichende Leistung um einen korrekten Bin rbaum selbst dynamisch errechnen zu k nnen Dies bedeutet dass der Baum ber einen Konfigurationsschritt dem RemFPGA mitgeteilt werden muss Ein Bin rbaum basiert auf der statistischen Analyse der zu erwartenden Werte Soll
118. nittstellen der PPrASICs werden mit Hilfe von Programmcode simuliert welcher direkt dem Verilogdesign des PPrASIC entnommen wurde Somit ist eine perfekte bereinstimmung mit der reellen Hardware gew hrleistet F r die Simulation von PC Slave Ger ten wurde ein Testmodell verwendet welches ebenfalls im Quellcode von www OpenCores org 11 enthalten ist Es wurde leicht angepasst um den Betreib mehrerer PC Slaves an einem Bus zu erm glichen ModelSim erlaubt die Simulation mit Hilfe der Daten einer Netzliste wie sie am Ende der FPGA Synthese entstehen Eine solche timing back annotated Simulation ber cksichtigt s mtliche Signalverz gerungen durch Leitungsl ngen innerhalb des FPGA und liefert somit eine sehr realistische Simulation der Hardware Die unten aufgef hrten Simulationsergebnisse wurden jedoch mit einer normalen statischen Timing Simulation erstellt die Unterschiede bei den folgenden Beispielen sehr gering sind die Simulationsgeschwindigkeit jedoch um etwa den Faktor 30 bis 40 absinkt Auch stellt sich wegen der oben erw hnten seltsamen Mapping Fehlschl gen die Frage wie zuverl ssig die Synthese des Designs ist Aus diesem Grund wurde auf die Simulation auf RTL Level zur ck gegriffen Es bleibt jedoch zu sagen dass sich der RemFPGA nach erfolgreichem Mapping und Place andRoute bisher fehlerfrei simulieren lie Die Darstellungen der Simulationen auch Wave genannt werden im Folgenden jeweils zusam men mit der gleichzeitigen
119. nterne Register des FPGA gesteuert Eine Beschreibung der Adresszuordnung der VME Schnittstelle folgt in Kapitel 6 8 3 3 5 Das Pipelinebus Protokoll des RemFPGA Der Pipelinebus wurde speziell f r den Transport von ReadOUT Daten des Pr prozessors entwickelt Er vereint eine hohe Durchsatzrate bei geringer St ranf lligkeit mit einer relativ einfach zu implementierenden Schnittstelle und speziell auf den Bedarf des Pr prozessors zugeschnittene Steuersignale Der Bus verwendet einen 32 Bit Datenbus zuz glich zweier Steuersignale einem Paritysignal und einem Clocksignal F r diese Signale existieren jeweils getrennte Eingangs und Ausgangs leitungen Entsprechend Abbildung 9 Seite 24 ist jede Pipelinebus Einheit im weiteren Node genannt jeweils mit der vorigen Node und der nachfolgenden Node verbunden Dabei ist jeweils der Pipelinebus Ausgang einer Node mit dem Eingang der n chsten Node verbunden bis ein geschlossener Ring entsteht Dieser Ring ist unidirektional durch die geschlossene Ring form kann allerdings trotzdem jede Node mit jeder anderen Node kommunizieren Die Pipeline bus Nodes sind also nicht parallel auf den Bus aufgeschaltet was einen wesentlichen Beitrag zu St rsicherheit des Systems leistet Bei jedem Clocksignal wird das Eingangssignal in ein internes Latch Register bertragen w hrend der vorige Inhalt des Registers auf den Ausgang gestellt wird Somit wandert ein Datenwort mit jedem Clocksignal von einer Node weiter
120. og und VHDL Modulen zur freien Verwendung Der verwendete DC Master Quellcode steht seit zwei Jahren zur Verf gung und ist ausf hrlich getestet worden Er wird von RemI2cControl unver ndert bernommen 5 3 10 RemSpiCore Dieses Modul implementiert einen SPI Bus Der SPI Bus kann lediglich Daten senden aber nicht empfangen Das Modul sendet daher ein 16 Bit Wort auf den Bus und fordert nach Ab schluss des Zyklus von einem bergeordneten Modul ein neues Ausgabewort an Der SPI Bus wird mit einer Geschwindigkeit von 1 MBit s betrieben 5 3 11 RemSpiControl Dieses Modul verwaltet vier SPI Schnittstellen implementiert durch vier RemSpiCore Instan zen Ein mit RemI2cControl identischer FIFO Mechanismus wird zum Empfang maximal eines Datenblocks verwendet 5 3 12 RemRegControl Dieses Modul implementiert und verwaltet s mtliche internen Register des RemFPGA Alle Register besitzen eine Breite von 32 Bit und k nnen ber ein Adressschema angesteuert werden Um die Register sowohl ber den VME Bus wie auch den Pipelinebus lesen und schreiben zu k nnen bietet RemRegControl zwei identische Zugriffsschnittstellen 5 3 13 RemVmeCore Dieses Modul implementiert die Easy VME Schnittstelle siehe 3 3 4 und synchronisiert den Datenverkehr mit der internen Clock des RemFPGA RemV meCore definiert einen Adressraum f r den direkten Zugriff auf die internen Register des RemFPGA und jeweils einen FIFO Mechanismus zur Eingabe und Ausga
121. ontrol sect i aieeao ea e RE EEEN EE O Rem Malin ae A A Ge N 532 KT EE 5 4 Schematische Illustration des Designs des AAA 6 Datenformate und Register des RemFPGA 6 1 ReadOUT Daten und ihre Kompresston essen ern 6 1 1 Untersuchte Kompressionzvertfabren essen nn 6 1 2 Kompressionsverfahren des RemFPGA AAA 6 1 3 Resultierendes ReadOUT Datenformat nen 6 2 ReadBACK Datem eose EE 6 2 1 Format der Lookup Tabelle des 6 2 2 Alle anderen Read ACK Daten 6 2 3 Resultierendes ReadBACK Datenformat nennen 6 3 Serielle Datenausgabe an die PbrASlCe nennen 6 4 Datenformat f r die I C Schnittstelle AAA 6 5 Datenformat f r die SP Schnttstellen A 6 6 Register d s RemPPGA a BER ei REDE en ls 6 7 Verwendung des Pipelinebusses ern 6 7 1 Die Befehle des Pipelinebusses AAA 6 7 2 Konfiguration der Pipelinebus Node Adresse AAA 6 7 3 Datenauslese ber den Dpelebus AAA 6 7 4 Dateneingabe ber den Prpoelmcehbus essen 6 7 5 Besonderheiten und 1 1 1 6 8 Verwendung der VME Schnittstelle A 6 8 1 Datenauslese ber die VME Schnittstelle AAA 6 8 2 Dateneingabe ber die VME Schnnittstelle AAA 7 Synthese und Test des RemFPGA 7 1 Synthese des RemEPGA un 2 2 22 ea an 7 1 1 Kompilation mit FPGA Compiler U N TAD get eege RR TT
122. oren ableiten Welche Drehung nun zu zwei Teilchen f hrt die in der Natur existieren ist wiederum nicht das Ergebnisse einer mathematischen Operation sondern muss als weitere Konstante im Standardmodell enthalten sein Im hier angef hrten Beispiel bestimmt der so genannte Weinberg Winkel die Mischung aus W und und beschreibt so das dritte Vektorboson der schwachen Kraft 7 und das Vektorboson der elektromagnetischen Kraft das Photon Y E E e 0 ly Gleichzeitig wird auf diese Weise auch ein Zusammenhang zwischen der Einheit der elektri schen und der schwachen Ladung hergestellt und auch zwischen der relativen St rke der beiden Kr fte Somit kann die elektromagnetische Kraft und die schwache Kraft in der so genannten elektroschwachen Vereinheitlichung zusammengefasst werden Das postulierte Higgs Boson Leider hat die oben beschriebene elektroschwachen Vereinheitlichung einen gravierenden Sch nheitsfehler Eine Vermischung von verschiedenen Zust nden ist nach den gegebenen Gesetzm igkeiten nur m glich wenn die beteiligten Zust nde vergleichbare Massen besitzen Leider besitzt das W jedoch eine nicht unerhebliche Masse von ca 100GeV w hrend das Photon masselos ist Der Widerspruch kann durch die Postulierung von vier verschiedenen Higgs Feldern gel st werden Jedem der vier Vektorbosonen wird ein solches Feld zugeordnet Die Kraft des Felde
123. pricht Um diesen Zeitrahmen einhalten zu k nnen arbeitet der Level 1 Trigger mit Messdaten von reduzierter Genauigkeit des Myon Spektrometers und des Kalorimeters Die Entscheidungslo gik wird von spezieller Hardware implementiert wof r haupts chlich ASICs und FPGAs eingesetzt werden 9 25 ns beim Betrieb mit Protonen 100 ns beim Betrieb mit Schwerionen 10 ASIC Application Specific Integrated Circuit eigens entwickelte Hardware Chips 11 Der Level 1 Trigger ist in mehrere unabh ngige Untereinheiten unterteilt Die Entscheidungen der einzelnen Subsysteme werden vom Central Trigger Prozessor CTP zusammengef hrt und verarbeitet 2 1 1 Der Trigger des Kalorimeters Um die Eingangsdatenmenge zu reduzieren werden die Daten der etwa 250 000 Zellen des hadronischen und elektromagnetischen Kalorimeters zu 7296 gr beren Zellen summiert Dies geschieht mit analogen Schaltungen direkt auf dem Detektor Die summierten Signale werden analog elektrisch ber rund 60m Kabel zur Level 1 Trigger Elektronik bertragen Der Kalori meter Trigger erf llt folgende Aufgaben Vorverarbeitung der Eingangssignale Pre processing siehe Kapitel 3 Triggerentscheidung f r Elektronen und Photonen Triggerentscheidung f r einzelne Hadronen und Tau Teilchen Triggerentscheidung f r Teilchen Jets Berechnung der gesamten Energie im Kalorimeter um eine Entscheidung aufgrund der fehlenden Transversalenergie zu treffen Die Vorverarbeitung erfolgt
124. rInReadout Modulen vereinfachter Modus siehe Kapitel 5 3 3 ReadOUT Speicher fast ersch pft 24 R REG RO LOWMEM R bit mask SerInReadout speichert nur noch Header Informationen ReadOUT Speicher v llig ersch pft h25 R_LREG_RO_OVERFLOW R bit mask SerInReadout verwirft alle neuen Daten Gibt die Lange des n chsten auszule 26 RO DATALEN R Bit 0 7 senden ReadOUT Datenblocks in 32 Bit Einheiten an Gesetzt wenn im entsprechenden 30 ALERT R bit mask ReadBACK Statuswort mindestens ein Bit aktiviert ist Gesetzt wenn SerInReadback momen 1 R_REG_RB_ACTIVE R bit mask tan ReadBACK Daten vom PPrASIC empf ngt 23 gt h bezeichnet in Verilog einen Hexadezimalwert b definiert einen Bin rwert 63 Verilog Konstante Zugriff Bedeutung 5 Aktiviert die Datenverarbeitung in den h32 R W bit mask SerInReadback Modulen ReadBACK Daten wurden verworfen 33 R_REG_RB_DATALOSS R bit mask da der Speicher ersch pft ist oder kein Zugriff auf den Speicher erfolgen konnte siehe auch Kapitel 5 3 6 6 Speicher im entsprechenden der acht ME REG RB MEMPULE SE SerRbCollect Module ist ersch pft Bit 7 0 Der Speicher im entsprechenden SerRbCollect Modul ist nicht leer Gesamtanzahl an ReadBACK Daten in Bit 8 19 allen acht SerRbCollect Modulen in 32 Bit Einheiten Eine folgende Auslese liefert
125. rch ein einzelnes der gesamten Folge vorangestelltes Flagbit gekennzeichnet Ein spezieller reservierter Bitwert der kurzen Codew rter fungiert als Endcode und kennzeichnet das Ende eine solcher Folge siehe Abbildung 28 Ist jedoch der letzte RAW Wert als ein kurzer Code abgelegt so entf llt dieser Zusammen mit jedem 10 Bit RAW Wert sendet der PPrASIC auch das so genannte External BCID Flagbit welches nicht komprimiert werden kann und welches daher zu jedem der drei Codetypen als zus tzliches Bit hinzugef gt werden muss In der Illustration ist dieses Bit jeweils mit E bezeichnet Lediglich der Endcode 111 eines kurzen Codes verf gt ber kein weiteres E Bit Abbildung 28 illustriert das Verfahren mit zwei Beispielen In Beispiel 1 werden 5 RAW Worte mit den Werten 0 2 3 6 1 komprimiert Alle Werte werden als kurze Codes abgelegt und da das letzte Wort kurz ist ist Endcode erforderlich Somit werden 55 originale Bits auf nur 21 Bits komprimiert was einer Kompressionsrate von 2 6 entspricht In Beispiel 2 werden die Werte 2 6 7 365 6 kodiert Die ersten beiden Werte werden kurz kodiert mit einem darauf folgenden Endcode Der dritte Wert wird als mittlerer Typ abgelegt da der Wert 7 bei kurzen Codes als Endzeichen reserviert ist Der vierte Wert wird als voller Code gespeichert und der letzte Wert wiederum als kurzer Code Auch hier folgt am Ende kein Endcode f r den kurzen letzten Wert 6 In
126. requirement for your design exceeds the resources available in the device the slice count exceeds device resources you might try to disable register ordering r Also if your design contains AREA_GROUPs you may be able to improve density by adding COMPRESSION to your AREA_GROUPs if you haven t done so already Bei normal verlaufendem Mapping ben tigt der RemFPGA knapp 11 000 der verf gbaren Virtex SLICES 7 1 3 Place and Route Der so genannte Place and Route Schritt die im Mapping Schritt ermittelten n tigen FPGA Ressourcen auf die verf gbare Hardware des Chips Dabei wird die Plazierung und Verbindung der einzelnen Kompontenten anhand vielerlei teilweise von Xilinx patentierten Regeln opti miert um eine m glichst synchrone Zusammenarbeit aller FPGA Ressourcen innerhalb des Chips zu erreichen Nach diesem Schritt kann ein so genanntes Bit File erstellt werden welches direkt in die Hardware geladen werden kann und den Chip so f r seine zugedachte Aufgabe konfiguriert 7 2 Simulation und Test des RemFPGA Die Simulation und der Test des RemFPGA erfolgte mit Hilfe der Software ModelSim 5 5f von Model Technology 14 F r die verschiedenen Tests wurde eine modulare Testbench in rein in Verilog entwickelt Sie simuliert die f nf verschiedenen Schnittstellen des RemFPGA Pipeline VME seriell PC und SPI und erlaubt die Erzeugung beliebiger Zugriffzyklen ber VME oder Pipelinebus 81 Die seriellen Sch
127. rieller ReadOUT RAW Wert Bit 12111 1098 76 5 4 3 2 1 0 ololol 0 0 1 i CfgAddress Di Data i Readback Status Readback Header Readback Data Abbildung 19 serielle ReadBACK Daten 30 Frequency Lost Playback Active Bcid Result Pipeline Stopped Channel 2 Raw Data Pipeline Stopped Channel 2 Bcid Result Pipeline Stopped Channel 1 Raw Data Pipeline Stopped Channel 1 Bit 9 8 7 6 5 4 3 2 1 D Histogram Available Channel 2 Histogram Available Channel 1 Rate Available Channel 2 Rate Available Channel 1 Abbildung 20 serielles ReadBACK Statuswort Die genaue Bedeutung der verschiedenen Bits dieser seriellen Datenw rter wird in 12 und in 7 eingehend erl utert 3 3 4 Die Schnittstelle zum VME CPLD Die eigentliche Implementation der VME Schnittstelle erfolgt durch das CPLD des VME Moduls Die ber VME zu bermittelnden Daten werden allerdings vom RemFPGA generiert bzw entgegengenommen Die Kommunikation zwischen CPLD und RemFPGA erfolgt ber eine VME CPLD spezifische Schnittstelle namens Easy VME Dar ber hinaus liefert das CPLD auch das Clocksignal und das Resetsignal f r den RemFPGA Der VME Bus wird im Fall des PPM mit einer Datenbreite von 32 Bit und einer Adresstiefe von 22 Bit betrieben Hinzu kommen eine Reihe von Steuersignalen die im folgenden aus der Sicht des RemFPGA n her beschrieben werden sollen sie
128. rimetertrigger wird die Anzahl der erf llten Bedingungen an den Central Trigger Prozessor bertragen und im Falle eines Level 1 Accept Signals die Rol Informationen an den Level 2 Trigger 2 1 3 Der Central Trigger Prozessor Der Central Trigger Prozessor CTP erfasst s mtliche Entscheidungsdaten des Kalorimetertrig gers des Myontriggers und einer optionalen externen Datenquelle Diese Daten werden mit 96 verschiedenen programmierbaren Bedingungen verglichen Erf llen die Daten mindestens einen der 96 Bedingungen wird ein Level 1 Accept Signal generiert Eine einzelne Bedingung kann zum Beispiel erfordern dass zwei bestimme Myon Grenzwerte nicht erf llt sein d rfen aber bestimmte Elektron oder Hadron Grenzwerte berschritten sein m ssen Ein positives Level 1 Accept wird ber das globale ATLAS Timing Trigger and Control System TTC im gesamten System verteilt Es enth lt Informationen des ausgel sten Trigger Typs der identifizierten bunch crossing Nummer und der fortlaufenden Nummer des Level 1 Events Auch die untergeordneten Level 1 Trigger Subsysteme erhalten diese Informationen und nutzen diese unter anderem um Readout Daten zur optionalen Auslese verf gbar zu machen so dass die Trigger Entscheidung nachtr glich auf Ihre Richtigkeit berpr ft werden kann 13 Central Trigger Calorimeter Calorimeter Trigger Processor 7 200 apa electr signals thresholds passed Rol data to LVL 2 Readout a Calibra
129. rollmodulen Ein Kontrollmodul beherbergt einen AMD Athlon Personal Compu ter der als Kontroll und Steuerungsinstanz f r das gesamte Crate dient Ein weiteres Modul empf ngt das globale TTC Signal und verteilt es an alle anderen Module des Crates Wie im vorigen Kapitel erw hnt bermittelt das TTC Signal unter anderem das Level 1 Accept Signal Die beiden letzten Kontrollmodule sind identisch und dienen dem Empfang und Weitertransport von Readout Daten von jeweils 8 PPMs siehe Abbildung 7 Im Folgenden werden die einzel nen Einsch be dieses Crates n her erl utert 12 bunch crossing das Aufeinandertreffen zweier Protonenwolken erfolgt alle 25 ns LVDS low voltage differential signaling 18 14 15 16 17 18 19 20 21 to ATLAS to ATLAS DAQ Abbildung 7 Layout eines Pr prozessor Crates 3 2 1 Die Struktur des Pr prozessormoduls PPM Ein Pr prozessormodul besteht aus einem mehrschichtigen 9U Printed Circuit Board PCB mit einer Vielzahl von so genannten Tochtermodulen Ein Tochtermodul ist ein Multi Chip Modul MCM welches ebenfalls ein kleines PCB darstellt auf welchem eine Anzahl von Chips in Die Form untergebracht sind Diese Tochtermodule werden auf das gro e PPM aufgesteckt Die Verwendung von MCMs bringt den Vorteil gr erer Flexibilit t bei gleichzeitig einfacherer Herstellung Sollte bei der Fertigung ein fehlerhafter Chip verwendet werden oder w hrend des Betriebs ausfallen
130. rt des Pipelinebusses wird ohne Fehlermeldung ignoriert Die Adresse der Register ist 7 Bit breit die Register befinden sich im Adressbereich von h00 bis h7F Die Datenbreite eines jeden Registers betr gt 32 Bit F r jedes Register ist in der Verilog Include Datei IncRemGlobals eine Konstante mit dem entsprechenden Adresswert definiert Die Spalte Zugriff gibt an ob das entsprechende Register lesbar R schreibbar W oder beides R W ist Manche Register haben je nach Zugriffsart eine unterschiedliche Bedeu tung in diesem Fall sind zwei getrennte Tabelleneintr ge f r dasselbe Register vorhanden Ist in der Spalte Bedeutung der Begriff bit mask eingetragen so steht jedes der 32 Bits dieses Registers f r eine serielle Schnittstelle Auf einige der Register wird auch in den folgenden beiden Abschnitten noch n her eingegangen Wird die Adresse eines nicht existierenden Registers ausgelesen so wird der Wert 0 zugegeben ein Schreibzugriff wird ohne Fehler ignoriert Addr Verilog Konstante Zugriff Bedeutung Gesetzt wenn SerInReadout momentan 20 R_REG_RO_ACTIVE R bit mask ReadOUT Daten vom PPrASIC empf ngt und verarbeitet Aktiviert die Datenverarbeitung in den Hee BREG RO ENABLE EN pit miask RemSerInReadout Modulen Aktiviert den Debugmodus in den h22 R_REG_RO_DEBUG R W bit mask SerInReadout Modulen Deaktiviert die Kompression in allen h23 R W Bit 0 Se
131. rter auf dem Bus ausgibt Der Empfang eines Datenwortes wird daher ebenfalls mit diesem Fehlerwort markiert 6 7 4 Dateneingabe ber den Pipelinebus ber den Pipelinebus k nnen zwei verschiedene Arten von Daten eingegeben werden so genannte Eingabe Daten und RemFPGA Register Die grunds tzliche Art der Daten bertragung mit Hilfe von BeginOfData EndOfData Befehlen ist in beiden F llen identisch und in Kapitel 3 3 5 erl utert Dieser Abschnitt erl utert den f r einen Eingabezyklus n tigen Konfigurations vorgang Ein Eingabedatenblock eingeschlossen von Begin End kann Daten f r die Ausgabe ber die seriellen Schnittstellen den PC Bus oder die SPI Schnittstellen enthalten Der Pipelinebus selbst unterscheidet diese Untertypen jedoch nicht eine Zuordnung erfolgt durch andere Pro grammteile des RemFPGA Analog zur Datenausgabe existieren auch hier entsprechende Start Befehle StartInput und StartWriteRegister Das Vorgehen ist analog zur Ausgabe auch hier werden Start Befehle abgelehnt falls eine Eingabe ber den VME Bus aktiv sein sollte oder der Pipelinebus gerade f r Datenausgabe konfiguriert sein sollte Daher sollte der Master zuvor den Befehl GetStatus verwenden 71 Befindet sich der RemFPGA in Eingabebereitschaft so wird eine beliebige Anzahl von Daten bl cken eingeschlossen durch BeginOfData EndOfData vom RemFPGA entgegen genommen und verarbeitet Da der Pipelinebus etwas langsamer getaktet sein wird als der RemFPGA
132. rtragung von Slave s zu Master Auch hier beginnt der Master wieder mit einem entsprechend adressierten BeginOfData Befehl Es handelt sich hierbei um exakt das gleiche Befehlswort wie f r die Initiierung einer Schreib operation das Befehlsargument wird nicht verwendet Dies bedeutet dass die Datenrichtung durch zus tzliche Befehle gesteuert werden muss ebenso wie die Auswahl der Art und Bedeu tung der zu bertragenden Daten Diese Befehle werden in der Referenz des Pipelinebusses siehe Kapitel 6 7 erl utert Der oder die angesprochenen Slaves gehen daraufhin in Ausgabebereitschaft Der BeginOfData Befehl wird gefolgt von leeren W rtern Der erste adressierte Slave ersetzt diese leeren W rter durch die von ihm auszugebenden Datenw rter Der Slave schlie t seine bertragung ab durch ein von ihm erzeugten EndOfData Befehl Die 6 Bit Adresse dieses Befehls enth lt die diesem Slave zugeordnete eindeutige Adresse welche somit den Ursprung des vorigen Datenblocks identifiziert Nach dem Abschluss der Ausgabe geht der Slave zur ck in den Ruhezustand Sollte der Master mehr als einen Slave angesteuert haben so warten auch diese Slaves auf leere W rter die sie mit Datenw rtern ersetzten k nnen Da jedoch der erste Slave die direkt auf den BeginOfData Befehl folgenden leeren W rter durch Datenw rter ersetzt hat m ssen die folgenden Slaves auf das Ende dieser Daten warten Dies geschieht automatisch jeder Slave hat einfach auf leere
133. s Die Verarbeitung der Daten durch den RemFPGA erfordert allerdings die Verwendung einiger zus tzlicher Flagbits pro Kanal Bei all diesen Bits handelt es sich um Fehlerflags oder Bits f r besondere Betriebsmodi Im normalen fehlerfreien Betrieb sind alle Bits nicht gesetzt Daher wird vom RemFPGA f r jeden Kanal ein Header variabler L nge erzeugt Im fehlerfreien Fall ist lediglich ein alles in Ordnung Bit n tig siehe Abbildung 31 und Kapitel 5 3 3 0 keine Fehler 0 10 Debugmodus 11 0 Fehlermodus 01 keine Daten ung ltige Daten interner Speicher ersch pft Abbildung 31 Header eines ReadOUT Kanals 55 Ist der Debugmodus aktiviert so werden alle empfangenen ReadOUT Daten unver ndert und unkomprimiert abgespeichert Da somit die verarbeitenden Schritte innerhalb des RemFPGA deaktiviert sind sind auch keine weiteren Flagbits n tig Bei Debugmodus kommen bei Fehlern w hrend der Datenverarbeitung vier m gliche Flagbits zum Einsatz e Keine Daten wird gesetzt falls von einem PPrASIC f r einen Kanal berhaupt keine Daten gesendet wurden e Headers Only erf llt zusammen mit Speicher ersch pft zwei Funktionen Ist Speicher platz vorhanden so ist dieses Bit identisch mit dem Headers Only Flag des ReadOUT Header Es wurde f r diesen Kanal nur ein Header und keine RAW oder BCID Werte empfangen Bei fast vollst ndig be
134. s wird durch jeweils ein weiteres Boson bermittelt Es gibt somit vier Higgs Bosonen Die postulierte Theorie besagt nun dass unterhalb einer bestimmten Temperatur Energie welche jeweils f r die vier Felder unterschiedlich sein kann jeweils ein Higgs Boson von einem Vektorboson absorbiert wird In der Higgs Theorie sind alle vier Vektorbosonen masselos w hrend alle vier Higgs Bosonen eine Masse besitzen Es wird nun weiter postuliert dass bei der aktuellen Temperatur des Universums die drei Higgs Bosonen von W W und Z absorbiert werden und diesen somit eine Masse verleihen Das Photon hat sein Higgs Boson jedoch nicht absorbiert und ist daher masselos Es muss also ein freies Higgs Boson geben Die Masse dieses Higgs Bosons l sst sich grob absch tzen und liegt in einem Energiebereich der mit bisherigen Teilchenbeschleunigern nicht erreichbar ist Der Beweis der Existenz oder Nichtexistenz des Higgs Teilchens ist von fundamentaler Bedeu tung f r die Konsistenz des Standardmodells Bei einer Nichtexistenz w ren v llig neue theore tische Konzepte erforderlich Eine der Hauptmotivationen f r den Bau des Large Hadron Collider LHC ist die Produktion und der Nachweis von Higgs Bosonen 1 2 Der Large Hadron Collider LHC Der Large Hadron Collider wird gebaut um bei Proton Proton Kollisionen Schwerpunktsener gien von bis zu 14 TeV bei einer Luminosit t von 10 cms erzeugen zu k nnen Die Energiebereiche von bisherigen Beschl
135. s oberste Bit wird auf DOUT ausgeben und dient so als Eingangssignal f r den n chsten MAX529 in der Kette Bei einer Kettenl nge von Vier kann jedes Bit in jedem MAX529 auf einen eindeutigen Wert gesetzt werden indem nacheinander 64 Bits auf dem SPI Bus ausgegeben werden Ein nachfol gendes Ladesignal CS veranlasst alle MAX529 den momentanen Inhalt ihrer Schieberegister als neue Programmierung zu bernehmen Die Geschwindigkeit des SPI Busses betr gt im Falle des PPM 1 MHz 27 3 3 3 Die serielle Schnittstelle des PPrASIC Jeder PPrASIC verf gt ber zwei identische serielle Schnittstellen Jede steuert zwei der vier Kan le der PPrASIC Somit sind auf dem gesamten PPM 32 serielle Schnittstellen vorhanden Diese werden mit einer Geschwindigkeit von 40MHz betrieben wobei das Taktsignal vom RemFPGA zu erzeugen ist Das Protokoll ist spezifisch f r den PPrASIC und verwendet vier Datenleitungen namens Clock Frame Dataln und DataOut Die Bitl nge betr gt 13 Bit Durch die getrennten Leitungen f r Eingabe und Ausgabe k nnen verschiedene Daten in beide Richtungen gleichzeitig bertragen werden Der Beginn eines neuen Datenwortes wird dabei durch das Frame Signal angezeigt welches somit zusammen mit jedem dreizehnten Clocksignal erzeugt wird Hier soll im Folgen den lediglich das Datenformat der bertragenen 13 Bit Worte kurz erl utert werden F r eine eingehendere Beschreibung der seriellen Schnittstelle siehe das Benutzerhandbuch des
136. schwache Ladung W Z 100GeV 107 Gravitation Masse Gravitron 0 10 Quarks Leptonen Fam Typ Ladung Farbe Masse MeV Typ Ladung Masse 1 down 7 r b g 5 16 MeV 7 1 0 05 1 5 eV up r b g 2 8 MeV e 0 511 eV 2 strange r b g 100 MeV 1 0 05 8 4 eV charm r b g 1 3 GeV H 0 105 7 MeV 3 bottom r b g 4 3 GeV 7 1 0 05 8 4 eV top r b g 175 GeV t 0 1777 1 MeV Zu all diesen Teilchen gibt es auch entsprechende Antiteilchen mit gleicher Masse aber entge gengesetzter elektrischer Ladung Farbe und schwacher Isospin F r die Gravitation f gt man eine vierte Wechselwirkung mit dem Gravitron als Vektorboson hinzu welches an die Masse koppelt Es gibt allerdings noch keine eindeutigen Beweise f r die Existenz des Gravitrons Warum es gerade drei Familien gibt ist unbekannt Seit der Entdeckung der Neutrinomasse ist es auch denkbar dass es noch weitere Familien gibt All diese Teilchen werden als fundamental und nicht weiter unterteilbar angesehen sie besitzen keine innere Struktur und keine Ausdehnung Eigenschaften der fundamentalen Teilchen und ihre Symmetrien Alle diese Teilchen werden im Standardmodell und darauf aufbauenden Modellen mit ver schiedenen Eigenschaften versehen Zu diesen Eigenschaften geh ren die Masse die elektrische Ladung die schwache Ladung der Spin der schwache Isospin die Farbe und Weitere mehr Manche d
137. sich um einen Systemfehler oder Anwendungsfehler bei der verwendeten Software handelt 8 3 Ausblick Zusammen mit dem Abschluss dieser Arbeit tritt die Entwicklung der anderen Komponenten des Pr prozessormoduls ebenfalls in die Endphase ein Eine Gammaversion des PPrASICs wurde gefertigt und geliefert und auch das zugeh rige PPrMCM wurde fertig gestellt und erste Exemplare wurden produziert Auch die anderen Komponenten des PPM stehen in Vorversionen zur Verf gung Die einzelnen Komponenten werden nun getestet und ein erster Prototyp des Pr prozessormoduls wird erstellt Diese Arbeit wird noch einige Monate in Anspruch nehmen Einer der n chsten Schritte ist das Design des Readout Driver Moduls ROD In diesem Bereich muss vor allem der Programmcode des auf dem ROD enthaltenen FPGAs erstellt und getestet werden ebenfalls ein Xilinx Virtex E 1000 Das gr ere Ziel ist die Durchf hrung des so genannten SLICE Tests in Heidelberg Bei diesem Test werden einige der 7296 Kan le des gesamten Level 1 Kalorimeter Triggers angefangen beim analogen Dateneingang bis hin zur Erzeugung des finalen Level 1 Accept Signals aufge baut und getestet Dies dient der berpr fung des ordnungsgem en Zusammenarbeitens aller Komponenten des Kalorimeter Triggers da die einzelnen Teile in verschiedenen Physikinstitu ten in ganz Europa entwickelt werden Schlie lich soll im Jahr 2006 der Large Hadron Collider seine Arbeit in Genf aufnehmen 94 Danksagung
138. so muss nur das eine betroffene MCM gegen ein funktionierendes Exemplar ausgetauscht werden anstatt des gesamten Pr prozessormoduls Auf diese Weise sinken der Ausschuss und damit die Kosten deutlich Auch ist die Herstellung und Best ckung eines so gro en PCBs durchaus nicht trivial weshalb die Unterbringung fast aller vitalen Bauteile auf wesentlich kleineren Tochtermodulen sicherer ist Die einzelnen Komponenten des abgebildeten PPMs und ihre Funktion sollen im Weiteren kurz dargestellt werden siehe auch Abbildung 8 Die f r diese Diplomarbeit entscheidenden Komponenten werden im Anschluss noch einmal genauer erl utert 14 QU U ist hier ein Gr enstandard f r PCBs und Crates 9U entsprechen 36 6 5 die ein roher Silikonchip ohne Verpackung oder Geh use dadurch sehr klein 19 Pre Processor Module lt 40 cm gt Standard LE VME64x_J1 Control c1 Monitor for 64 chans Jaux c2 TTC in Standard LV VME64x_J2 amp Srow LED FE s Fast ReadOut 36 6 cm PipeLineBus on user def c3 Min Requ for 8 LFAN AMP Connectors 16 4 mm 64 mm To CP 32 Drivs 8 FO k 10cm To JP EI MCM16 4 chs 16 Drivs 3 FO Abbildung 8 Schema der Pr prozessormoduls PPM Das Analog Input Modul 4 Stiick pro PPM Dieses Modul nimmt jeweils 16 differentiale analoge Signale entgegen und wandelt sie in unipolare Signale um gelbe Module in Abbildung 8 Dabei
139. stehen Er wird ber ausreichend Rechenkraft verf gen um anhand der kompletten ATLAS Detektordaten das erfolgte Event vollst ndig zu rekonstruieren Das analysierte Event wird dann wiederum mit mehreren S tzen von Bedingungen verglichen und bei bereinstimmung zur sp teren offline Analyse abgespeichert Der Eventfilter befindet sich momentan noch in der Planungsphase da die Prozessorfarm mit der leistungsf higeren Hardware der Jahre 2005 und 2006 implementiert werden soll Heutige Hardware kann die erforderliche Rechenkraft mit den verf gbaren Geldmitteln nur schwer bis gar nicht leisten Bei weiterer G ltigkeit von Moores Gesetz wird die n tige Leistung bis zum Jahr 2005 allerdings problemlos erh ltlich sein In Abbildung 6 ist der gesamte Datenpfad des ATLAS Experiments dargestellt 14 ATLAS Detector 40 MHz MHz 40 MHz lt 2us LevellAccept Regions of Interest lt 2ms Level2Accept 1 10 GB s Complete Events SEC 10 100 MB s Abbildung 6 Datenpfad der ATLAS Triggersystems 15 Kapitel 3 Der Level 1 Kalorimetertrigger Pr prozessor Der Pr prozessor erh lt als Eingang alle 25 Nanosekunden 7296 analoge Signale vom ATLAS Kalorimeter Diese 7296 Signale werden direkt auf dem Detektor durch analoge Summation aus den Signalen der ber 200 000 Zellen des elektromagnetischen und hadronischen Kalorimeters generiert Nur durch diese stark reduzierte Granularit t ist es
140. system Alle Kan le aller Detektorkomponenten des ATLAS Experiments produzieren alle 25ns Daten die komplett zur weiteren Verarbeitung und Speicherung ausgelesen werden m ssen Dies ergibt ungef hr 6x10 Einzelsignale pro Sekunde Eine solche extreme Datenmenge kann weder mit heutigen noch mit f r die n here Zukunft absehbaren Technologien auf Datentr gern abgespei chert werden Da wegen der starken Strahlung direkt am Detektor nur einfache und robuste elektronische Komponenten verwendet werden k nnen ist es sogar unm glich die gesamte Datenmenge mit der n tigen Geschwindigkeit vom Detektor zu einer weiteren Verarbeitungs einheit zu bertragen Nicht jede Proton Proton Kollision erzeugt jedoch Ergebnisse von physikalischem Interesse Aus diesem Grund verwendet man einen so genannten Trigger um aus der gro en Menge von Ereignissen nur diejenigen von Interesse auszufiltern Nur im Falle einer positiven Triggerent scheidung werden s mtliche Kan le des ATLAS Detektors ausgelesen und zur sp teren Analyse gespeichert Eine solche Triggerentscheidung kann nicht innerhalb von 25ns getroffen werden und daher m ssen die Daten aller Kan le in Pipeline Memories auf dem Detektor zwischengespeichert werden Aus Kostengr nden und aus Gr nden der technischen Machbarkeit dieser Pipeline Memories muss die Latenzzeit des Triggersystems m glichst kurz gehalten werden Das Triggersystem des ATLAS Experiments besteht aus drei nacheinander gescha
141. t Hilfe von vier komplexen Detektoren die teilweise die Gr e von mehreren Reihenh usern bertreffen werden diese Kollisionen untersucht Einer dieser Detektoren ist der so genannte ATLAS Detektor Selbst bei diesen extrem hohen Energien treten die gew nschten Ereignisse nur sehr selten auf Ein Higgs Teilchen wird beispielsweise nur bei einer von 10 Kollisionen erzeugt Der Gro teil der anderen Kollisionen erzeugt Resultate die schon mit schw cheren Beschleunigern ausf hr lich untersucht werden konnten Daher verf gen die Detektoren ber ein Triggersystem wel ches die interessanten Ereignisse identifizieren und zur weiteren Analyse extrahieren soll Das Triggersystem des ATLAS Detektors besteht aus drei Stufen Jede Stufe verringert die zu verarbeitende und zu analysierende Datenmenge und erm glicht somit den sp teren Triggerstu fen eine immer ausf hrlichere Analyse ATLAS besteht aus mehreren verschiedenen Detektor Untertypen welche jeweils andere Messungen vornehmen Daher bestehen die verschiedenen Triggerstufen auch aus mehreren verschiedenen Unterkomponenten Diese Arbeit besch ftigt sich mit einem Teil des so genannten Pr prozessors des Level Kalorimeter Triggers also einem Teil der ersten Triggerstufe Dieser Pr prozessor arbeitet mit 7296 Messsignalen des Kalorimeter Detektors Er besteht aus einer Vielzahl von identischen Komponenten genannt Pr prozessormodule welche jeweils 64 Messsignale verarbeiten Jedes dieser
142. t Modulen ist in Abbildung 27 zu erkennen Gem einer Modulodivision werden die beiden Schnittstellen 01 17 mit RoCollectOl verbunden 02 18 mit RoCollect02 bis zu 16 32 mit RoCollect16 Ebenso wird 01 09 17 25 mit RbCollectO1 verbunden bis hin zu 08 16 24 32 mit RbCollect08 Somit k nnen zum Beispiel gleichzeitig ReadBACK Daten von den Schnittstellen 01 bis 08 oder von auch 01 02 11 20 29 06 07 32 empfangen werden Nicht jedoch von 01 02 03 04 05 06 07 09 da die Schnittstellen 01 und 09 beide mit RbCollect01 verbunden sind somit werden die Daten von 09 oder 01 verworfen ReadOUT Daten werden immer verarbeitet siehe Abschnitt 5 3 5 und Abschnitt 5 3 6 5 3 9 RemI2cControl Dieses Modul verwaltet den DC Bus Uber einen FIFO Mechanismus nimmt das Modul maxi mal einen Datenblock entgegen welcher an angeschlossene PC Slaves gesendet wird Nach der kompletten Ausgabe des Datenblocks kann ein weiterer verarbeitet werden Der Empfang von Daten ber die C Schnittstelle wird nicht unterst tzt da die anzusteuernden Phos4 Chips keine Ausgabedaten erzeugen 21 FIFO First In First Out ein Mechanismus zur Pufferung von Daten 47 RemI2cControl implementiert den Speicherblock bestehend aus zwei SelectRAMs und die Ansteuerung ber den FIFO Mechanismus Der eigentliche PC Master wird implementiert durch kostenlosen und lizenzfreien Programmcode von www OpenCores org 11 Dieses Internetportal bietet eine ganze Reihe von kostenlosen Veril
143. tControl Modul 46 RemSerMerge verbindet die 16 getrennten Datenbl cke der RemSerRoCollect Module zu einem gesamten Bitstrom welcher ber den Pipelinebus oder die VME Schnittstelle ausgelesen werden kann Bei der Erstellung dieses Gesamtdatenstroms berpr ft der Programmcode die erw hnte bereinstimmung der BCID und Eventnummern der einzelnen Datenpakete siehe Abschnitt 5 3 3 Bei fehlerhafter Synchronisation der BCID Nummer wird dies lediglich mit einem Fehlerbit im Header des resultierenden Gesamtbitstroms angezeigt Bei fehlerhafter Eventnum mer jedoch wird das gesamte Datenpaket verworfen und lediglich der Header mit der Fehlerin formation abgespeichert Die weiteren Daten verarbeitenden Instanzen wie der ReadOUT Treiber ROD des Crates oder die auswertende Software verwerten lediglich synchronisierte Eventdaten Die fehlerhaften Daten werden aus diesem Grund schon innerhalb der RemFPGA verworfen um so die Anzahl der zu bertragenden und zu speichernden Daten nicht unn tig zu erh hen RemSerMerge verwendet f r die Speicherung eines gesamten ReadOUT Datenpakets einen 32 Bit Speicherblock bestehend aus zwei SelectRAM Bl cken Dies bietet ausreichend Platz f r die von den einzelnen RemSerInReadout Instanzen erzeugten Datenstr me RemSerMerge verf gt ber zwei dieser Speicherbl cke und kann somit w hrend der Auslese eines Datenblocks durch ein bergeordnetes Modul das n chste Datenpaket im zweiten Spei cherblock vorbereiten
144. ten sich die Bedingungen des Detektors und damit die Statistik der Werte auch nur leicht ndern so bricht das gesamte Huffmann Verfahren zusammen da der Algorithmus sehr empfindlich gegen ber nderungen des Bin rbaumes ist L ngenkodierung Dieses Verfahren ersetzt aufeinander folgende identische Werte durch die Angabe der L nge der Folge und ihren Wert Tausend Nullen werden somit durch nur zwei Werte 1000 0 repr sen tiert 51 Nur sehr wenige Einzelkan le werden bei jedem Bunch Crossing durch auftreffende Teilchen ausgel st Somit eignet die L ngenkodierung hervorragend f r die Kompression der Kan le welche lediglich einen Nullwert gemessen haben Allerdings funktioniert dieses Verfahren ausschlie lich in der Abwesenheit von Nullpunktrauschen Huffmann inspirierte Kodierung absolutes Verfahren Dieses Verfahren ist speziell auf die Struktur der RAW Daten zugeschnitten und orientiert sich an der Idee Huffmanns h ufige Werte durch kurze Codes zu repr sentieren Besonders h ufig treten niedrige Energiewerte auf vor allem Nullpunktrauschen und die leeren oberen Bits dieser Werte k nnen ausgelassen werden Der so entstandene Algorithmus verwen det zwei verschiedene Codetypen ein Codewort voller L nge f r hohe Energiewerte und ein Codewort kurzer L nge f r niedrige Energiewerte Die Unterscheidung zwischen den beiden Typen kann zum Beispiel durch ein vorangestelltes Flagbit erfolgen Dieses Verfahren ben t
145. tion and test u Chambers Muon Trigger triggers multiplicity of 800 000 electr signals thresholds d passed lend cap amp barrel E S Rol data to LVL 2 Readout Readout Abbildung 5 Schema der ATLAS Level 1 Triggers 2 2 Der Level 2 Trigger Die Aufgabe des Level 2 Triggers ist es die Datenrate um den Faktor 100 auf 1kHz zu reduzie ren Hierzu erh lt der Level 2 Trigger Region of Interest RoI Informationen von der Level 1 Trigger Logik Mit der Hilfe dieser Informationen w hlt der Level 2 Trigger die entsprechenden Zellen des ATLAS Detektors und liest diese aus dem Readout Speicher mit der vollen Genauig keit aus Die Logik verwendet diese Daten um so weit als m glich Bahn Impuls Masse und Typ von Teilchen zu bestimmen Dies ist nicht immer vollst ndig m glich da auch hier die zur Verf gung stehende Zeit stark begrenzt ist Die auf diese Weise identifizierten Teilchen werden dann hnlich wie im Level 1 Central Trigger Prozessor mit einer Anzahl von S tzen von Bedingun gen verglichen und bei Erf llung mindestens einer Bedingung erfolgt das Level 2 Accept Signal Eine Bedingung k nnte zum Beispiel ein auftretendes Higgs Teilchen sein Auch f r den Level 2 Trigger wird dedizierte Hardware in Form von FPGAs eingesetzt 2 3 Der Eventfilter Die Aufgabe des Eventfilters ist eine weitere Reduktion der Datenrate um den Faktor 10 Der Eventfilter wird aus einer Farm von kommerziell erh ltlichen Prozessoren be
146. u sendender BCID und RAW Werte kann f r jeden Kanal einzeln ber interne Register des PPrASIC eingestellt werden In der Grundeinstellung werden f r jeden Kanal 1 BCID und 5 RAW Werte bertragen Ein RAW Wort besteht aus einem 10 Bit Wert und einem Flagbit namens External BCID Ein BCID Wort besteht aus einem 8 Bit Wert und 3 Flagbits Jedes Header Wort enth lt die jeweils unteren 4 Bits des PPrASIC internen Event und Bunch Crossing Z hlers Bei einer ordnungsgem en Synchronisation des Pr prozessorsystems sind diese Werte f r alle 7296 Kan le identisch F r eine n here Beschreibung der Bedeutung der einzelnen Daten siehe die Spezifikation des PPrASIC 7 Channel Loss Flag Headers Only Flag BC Number Event Number 10 9 8 7 4 3 0 Bit Abbildung 16 serieller ReadOUT Header 29 Bit External BCID FIR algorithm BCID Result Saturation algorithm Abbildung 17 serieller ReadOUT BCID Wert External BCID RAW value Bit Falls mangels eines Level 1 Accept Signals keine ReadOUT Daten gesendet werden sollten werden einfach nur ReadBACK Worte direkt nacheinander gesendet Falls keine ReadBACK Daten zu senden sind unabh ngig von eventuell zwischen einzelnen ReadBACK Worten eingef gten ReadOUT Worten wird als ReadBACK fortlaufend ein so genanntes ReadBACK Statuswort gesendet Dieses gibt ber Flagbits Auskunft ber einige grundlegende Zust nde des PPrASICs 10 9 Abbildung 18 se
147. utung f r die Funktion des Pr prozessors Ohne RemFPGA sind die einzelnen PPMs f r die Au enwelt unerreichbar und die Komponenten des PPM nicht konfigurierbar 5 1 Grunds tzliche Aufgabenstellung Der RemFPGA hat folgende Aufgaben zu erf llen e Implementierung von vier SPI Schnittstellen zur Konfiguration der MAX529 DACs der Analog Input Boards e Implementierung eines IP C Masters zur Konfiguration der Phos4 Chips der 16 PPrMCMs e Implementierung von 32 seriellen Schnittstellen zur Konfiguration und Auslese von ReadOUT Daten von 16 PPrASICs e Komprimierung der ReadOUT Daten der PPrASICs e Implementierung eines Pipelinebus Slave Nodes zur bertragung der komprimierten ReadOUT Daten e Implementierung einer Schnittstelle zum VME CPLD zur Kommunikation ber den VME Bus 5 1 1 Notwendigkeit der Kompression der Readout Daten Die PPrASICs des Pr prozessors erzeugen bei jedem positiven Level 1 Accept fiir jeden einzelnen Kanal ReadOUT Daten Diese Daten bestehen beim Betrieb mit Standardeinstellun gen aus einem ReadOUT Header Wert einem BCID Wert und f nf RAW Werten Jedes PPM verarbeitet 64 Kan le somit erzeugt jedes PPM 728 Bytes an ReadOUT Daten pro Level Accept Bei einer vollen Level 1 Accept Rate von 100 kHz ergibt sich somit eine Datenrate von etwa 71 MB s pro PPM An den fiir die Ubertragung von ReadOUT Daten bestimmten Pipeline Bus sind 8 PPMs angeschlossen somit betr gt die gesamte Datenrate etwa 568 MB s
148. versum direkt nach dem Urknall vergleichbar sind LHC B untersucht CP Verletzung beim Zerfall von B Mesonen Der Detektor untersucht ausschlie lich die Vorw rtsstreuung bei sehr kleinen Winkeln da in diesem Bereich B und Anti B Mesonen besonders zahlreich auftreten Eine der Hauptaufgaben von LHC besteht in der Produktion und Detektion von Higgs Bosonen LHC wird der erste Detektor sein der Energien erreicht die zur Produktion von Higgs Bosonen in gro en Mengen n tig sind Der Vorg nger von LHC das LEP Experiment hat erste Indizien von Higgs Bosonen geliefert welche darauf hindeuten dass die Masse des Higgs Bosonen sich am unteren Ende des vorhergesagten Bereichs befindet Daher sollte LHC Higgs Bosonen in sehr gro en Mengen erzeugen k nnen Weiterhin wird nach bisher unbeobachteten supersymmetrischen Teilchen gesucht welche einen Beleg f r die Erweiterung des Standardmodells durch Supersymmetrie liefern w rden Au erdem sollen mit Hilfe von LHC B Pr zisionsmessungen von CP Verletzungen durchge f hrt werden um so einige Naturkonstanten des Standardmodells genauer zu bestimmen Cabbibo Kobayashi Maskawa Matrix Dar ber hinaus ist bei diesen hohen Energien eventuell auch mit der Produktion von bisher v llig unbekannten Teilchen zu rechnen die das Standard modell in seiner jetzigen Form berholen werden Abbildung 1 zeigt eine einfache historische bersicht verschiedener Teilchenbeschleuniger und ihren maximalen Energien Der L
149. wartet auf BeginOfData 5 sendet BeginOfData an 72 Aktion des Masters Aktion von Slave 0 Aktion von Slave 1 wartet auf Datenw rter 7 und EndOfData und sendet leere W rter geht in aktiven Modus sendet Datenwort Al geht in aktiven Modus sendet Datenwort A2 9 empf ngt Datenwort Al sendet EndOfData Addr 0 10 empf ngt Datenwort A2 wartet auf BeginOfData wartet auf leere W rter 11 empf ngt EndOfData 0 12 empf ngt Datenwort Bl 13 empf ngt Datenwort B2 14 empf ngt Datenwort B3 15 empf ngt EndOfData 1 sendet Datenwort B1 sendet Datenwort B2 sendet Datenwort B3 sendet EndOfData Addr 1 wartet auf BeginOfData Tabelle 9 Pipelinebus ReadOUT Beispiel Takt Ausgabe Empfang 1 StartReadout an unbekannt unbedeutend 2 leeres Wort unbekannt unbedeutend 3 leeres Wort unbekannt unbedeutend 4 leeres Wort StartReadout mit Accept Flag 5 BeginOfData an leeres Wort 6 leeres Wort leeres Wort 7 leeres Wort leeres Wort 8 leeres Wort BeginOfData mit Accept Flag 9 leeres Wort Datenwort Al 10 leeres Wort Datenwort A2 11 leeres Wort EndOfData von h00 12 leeres Wort Datenwort B1 13 leeres Wort Datenwort B2 14 leeres Wort Datenwort B3 15 leeres Wort EndOfData von hOl Tabelle 10 Pipelinebus ReadOUT Beispiel Setzen von Re
150. werden Daher ist ein paralleler Zugriff wie bei RemSerRoCollect schon aus Kapazit ts berlegungen nicht ratsam Da ein PPrASIC ReadBACK Daten jedoch nur als Reaktion auf ber die serielle Schnittstelle gesendete Befehle erzeugt kann der Verlust von Daten vermieden werden Die Steuerungssoft ware darf daher nicht alle 32 PPrASICs eines Pr prozessormoduls gleichzeitig zur Ausgabe von ReadBACK Daten auffordern sondern in vier getrennten Schritten jeweils nur jeden vierten PPrASIC RemSerRbCollect 8 Instanzen und RemSerRoCollect 16 Instanzen verwenden somit insge samt 64 der 96 verf gbaren Speicherbl cke des Virtex E 1000 5 3 7 RemSerOutControl Dieses Modul nimmt Datenbl cke von einem bergeordneten Modul entgegen und leitet ihren Inhalt an die Ausgabe der 32 seriellen Schnittstellen weiter Die Datenbl cke werden in einem 32 Bit Speicher abgelegt Dieser Speicher besteht aus 16 SelectRAM Bl cken und bietet somit eine Kapazit t von 65536 Bits Der Inhalt eines Datenpakets kann wahlweise auf einer bestimmten seriellen Schnittstelle ausgegeben werden oder auch auf allen 32 gleichzeitig Die M glichkeit der parallelen Ausgabe der gleichen Daten an alle Schnittstellen erm glicht die perfekte Synchronisation der PPrASICs 5 3 8 RemSerMerge Dieses Modul fasst die gesamte Funktionalit t der seriellen Schnittstellen zusammen Es instanziiert 32 RemSerSyncDecode Module 16 RemSerRoCollect Module 8 RemSerRbCollect Module und ein RemSerOu
151. yjnopeey Apesyypeapeay DIOMUUeS SWEI19S AIDES eCloguinn LMYHUINN AD Abbildung 41 serieller Dateneingang ber das Modul RemSerSyncDecode 83 7 2 2 Auslese von Readout Daten ber den Pipelinebus Es folgt die Logging Ausgabe und ein Wave Schaubild welches den obersten Teil des loggten Vorgangs darstellt Getting ReadOUT data via PLBus PlBus GetDataOutInfo Addr 01 Arg 0001000000000000 Accept 1 PlBus BeginOfData Addr 3f Arg 0000 Accept 1 PlBus Data 00000000 bin 00010000111110001000100000000001 hex 10 88801 PlBus Data 00000001 bin 01000011111010010110010000100001 hex 43 96421 PlBus Data 00000002 bin 10101000001110111100100010001000 hex a83bc888 PlBus Data 00000003 bin 10010110010000100001000100001111 hex 9642110f PlBus Data 00000004 bin 10111100100010001000010000111110 hex bc88843e PlBus Data 00000005 bin 00100001000100001111101010000011 hex 2110fa83 PlBus Data 00000006 bin 10001000010000111110100101100100 hex 8843 964 PlBus Data 00000007 bin 00001111101010000011101111001000 hex Ofa83bc8 PlBus Data 00000008 bin 00111110100101100100001000010001 hex 3e964211 PlBus Data 00000009 bin 10000011101111001000100010000100 hex 83bc8884 PlBus Data 0000000a bin 01100100001000010001000011111010 hex 642110fa PlBus Data 0000000b bin 11001000100010000100001111101001 hex c88843e9 PlBus Data 0000000c bin 0001000100001

Der RemFPGA des ATLAS Level-1 Kalorimeter Triggers

Contents

Download Pdf Manuals

Related Search

Related Contents