Download “FREJA”
Transcript
“FREJA” A programmable board for TFC system components testing Andrea Borga ABSTRACT The TFC (Timing and Fast Control) system of the LHCb experiment is getting close to the preproduction phase. The need for a tool able to make detailed and precise tests of all the boards is for that reason essential. The TFC test board (Freja) is a general purpose board based on an FPGA capable to produce, receive and process stimuli from and to the TFC boards and return test results via a dedicated user interface. The test principle in based on “predicted event comparison” (what we get is what we expect?). The fact that Freja is absolutely general purpose makes it much more than a simple prototype tester board. Its flexibility allows it to be used in future application for instance as a powerful tool for production and commissioning testing as well as a monitor board during the whole life time of experiment. Prepared By: A. Borga, Politecnico di Torino, Torino, Italy Project supervisor: R. Jacobsson, CERN, Geneva, Switzerland LHCb Online Group Academic supervisor: D. Trinchero, Politecnico di Torino, Torino, Italy Dipartimento di Elettronica CERN “Freja”, A.Borga Reference: LHCb 2004-XX Control INDEX 1 INTRODUCTION .......................................................................................................................................................1 2 ME AND MY WORK AT CERN ..............................................................................................................................3 3 TFC SYSTEM OVERVIEW ......................................................................................................................................5 3.1 3.2 3.3 3.4 3.5 3.6 3.7 4 THE LHCB DETECTOR ............................................................................................................................................5 LHCB READOUT SYSTEM .......................................................................................................................................6 THE TFC SYSTEM ARCHITECTURE .........................................................................................................................7 READOUT SUPERVISOR: “ODIN” ...........................................................................................................................9 TFC SWITCH: “THOR”........................................................................................................................................11 THROTTLE SWITCH AND THROTTLE OR: “MUNIN” AND “HUGIN” ...................................................................11 TTC DISTRIBUTION SYSTEM ................................................................................................................................12 TESTING METHODOLOGIES..............................................................................................................................13 4.1 INTRODUCTION TO HARDWARE TESTING ..............................................................................................................13 4.2 TESTING THEORY .................................................................................................................................................14 4.3 TFC TEST SETUP...................................................................................................................................................14 4.4 APPLICATION OF FREJA ........................................................................................................................................16 4.4.1 Prototype testing..........................................................................................................................................16 4.4.2 Pre-production and production testing .......................................................................................................16 4.4.3 Commissioning ............................................................................................................................................16 4.4.4 Experiment monitoring................................................................................................................................16 5 TFC TEST BOARD: “FREJA” ...............................................................................................................................17 5.1 OVERVIEW OF THE BOARD....................................................................................................................................17 5.2 CREDIT CARD PC .................................................................................................................................................18 5.2.1 The ECS interface and the CCPC................................................................................................................18 5.2.2 PCI Interface ...............................................................................................................................................19 5.3 GLUE CARD..........................................................................................................................................................22 5.3.1 PCI slave .....................................................................................................................................................22 5.3.2 I2C Bus.........................................................................................................................................................25 5.3.3 JTAG Bus.....................................................................................................................................................29 5.3.4 Local Bus.....................................................................................................................................................34 5.4 GENERAL PURPOSE INPUT/OUTPUTS ....................................................................................................................37 5.4.1 Introduction .................................................................................................................................................37 5.4.2 LVDS technology .........................................................................................................................................37 5.4.3 ECL technology ...........................................................................................................................................39 5.4.4 I/O interface technologies on the test board................................................................................................40 5.5 CONTROL LOGIC: ALTERA APEX FPGA..............................................................................................................41 5.5.1 Introduction .................................................................................................................................................41 5.5.2 The evolution of FPGAs ..............................................................................................................................41 5.5.3 Choice of the FPGA for Freja .....................................................................................................................42 5.5.4 APEX 20K Family .......................................................................................................................................43 5.5.5 FPGA programming....................................................................................................................................43 5.5.6 STAPL language for In System Programming.............................................................................................44 6 PCB DESIGN.............................................................................................................................................................47 6.1 6.2 6.3 6.4 6.5 INTRODUCTION.....................................................................................................................................................47 BOARD SCHEMATICS ............................................................................................................................................47 FRONT PANEL VIEW ..............................................................................................................................................48 BOARD LAYER CONFIGURATION ...........................................................................................................................49 ROUTING TIPS AND TECHNIQUES ..........................................................................................................................50 I “Freja”, A.Borga 7 VHDL PROGRAMMING ........................................................................................................................................53 7.1 INTRODUCTION TO VHDL....................................................................................................................................53 7.1.1 Language basic elements.............................................................................................................................54 7.1.2 RTL-to-gate process ....................................................................................................................................55 7.2 VHDL CODE FOR TFC TEST BOARD .....................................................................................................................57 7.2.1 Board debug: SELF-TESTS.........................................................................................................................57 7.2.2 Alternative TFC switch implementation ......................................................................................................57 7.2.3 TFC full system testing ................................................................................................................................58 7.3 REGISTER LIST......................................................................................................................................................61 7.4 CODE SIMULATION ...............................................................................................................................................62 8 BOARD CONTROL .................................................................................................................................................65 8.1 EXPERIMENT CONTROL SYSTEM ..........................................................................................................................65 8.2 CONTROL SOFTWARE FRAMEWORK ......................................................................................................................67 8.2.1 PVSS II ........................................................................................................................................................67 8.2.2 DIM .............................................................................................................................................................68 8.2.3 SMI++.........................................................................................................................................................68 8.3 THE TFC LOCAL CONTROL SYSTEM......................................................................................................................69 8.3.1 Freja control panels ....................................................................................................................................72 9 RINGRAZIAMENTI ................................................................................................................................................75 10 REFERENCES ......................................................................................................................................................77 11 APPENDIX A - BOARD SCHEMATICS ...........................................................................................................79 12 APPENDIX B - REGISTERS LIST.....................................................................................................................90 13 APPENDIX C - BACKUP CD..............................................................................................................................91 14 APPENDIX D – NORSE MYTHOLOGY...........................................................................................................93 II Per tutto ciò che è incrocio perfetto fra arte e scienza varrà ancora la pena alzarsi domani. “Freja”, A.Borga 1 Reference: LHCb 2004-XX Control Introduction «What are we? Where do we come from? Where are we going? » Those could be the usual starting questions of a scientific treatise, interrogations that mankind’s curiosity always tried to answer, sometimes with good results but often without any sure certainties. This introduction doesn’t aim at the explanation of those tricky queries, it focus instead on giving an answer of a more simple question that can still turnout to be complex due to the hundreds of “faces” that the subject of analysis can show: «What is CERN? And what do people do there? ». An obvious answer that is related with the previous questions could be: «Well… At CERN people try to find the answers to the above questions! ». Too vague maybe. «It is the place where the WEB was born than! », this is true, but internet is just a small invention comparing to CERN’s final goal. Let’s proceed with order then, and try to reply stating facts. CERN was founded in 1954 just after the end of the Second World War by a group of scientists with the aim to study and reveal the building blocks of matter, the forces that bind nature and, not least, to gather people with a common love and passion for science, innovative technologies and, of course, particle physics. To discover and study matter physicist use particle colliders: like children try head-on colliding cars to see how much they can resist, scientists “play” with atomic and sub-atomic particles at high energies to see what “comes out”. By experimental experience it was possible to prove the existence of the quarks, much smaller than the bricks of Bohr’s atom model which are electrons, protons or neutrons; but studies at CERN also revealed the existence of particles which don’t exist in the actual universe… how is this possible? There are no mysteries apparently, the physicists found a way to also “travel back in time” using particles accelerators: even if absent in the present days’ nature and space, matter created and studied at very high energy existed in the universe at its early stages when it was no older than a fraction of a second. The more energy that is put in the collisions the more far back in time physicists can look: the LHC (Large Hadron Collider), CERN’s new particle accelerator that will start working in 2007, will operate at an energy of 7TeV. At the energy of LHC, a small-scale reconstruction of the universe at a time of 10-10 second after its birth will be analyzed. Greedy machines, the four detector of the experiments (Atlas, CMS, Alice and LHCb), installed in the 27km under ground ring will observe from different point of view what happens at the collision points. The Universe started out 13.7 billion years ago as an extremely hot, dense and homogenous soup of energy and particles. The energy was continuously converted into pairs of matter and antimatter. As the matter and antimatter collided they annihilated each other recreating energy. Hence there was a perfect balance between matter and antimatter. After the big bang the universe started its expansion and cooling. These phenomena provoked a series of drastic changes in its composition which led matter to take over antimatter. Nowadays then, we live in a “matter dominated” world, but why did this happen? The LHCb (Large Hadron Collider Beauty) experiment [3] will try to find the explanation to this preference of nature by operating measurements on particular particles, the beauty quarks. Like their predecessors, LHCb and all the other experiments require ultra-modern technology to operate in the most efficient way. The Web for example was invented in 1992 at the time of the LEP (Large Electron Positron collider) experiment to exchange and share, in a completely new fashion, information and data between the physicists working at CERN. As history tell us, the idea of the project turned out to be so powerful that it was then shared and extended to the whole world. 1 “Freja”, A.Borga Engineers and computer scientists work in close contact with physicists to help with their knowledge the development of what can sometimes appear to be “crazy thoughts” or “science fiction ideas” only. Researchers are working hard trying to make dreams come true, seeking answers to millenary questions. “Maybe there is just the hand of a god behind all that… who knows…”, though, what has been discovered up to now need strong confirmations, no body has the arrogance to state that man is capable to create something that never existed. Scientists are sceptic by definition and for that reason will keep patiently looking for reasonable explanations. And then… we will see… 2 “Freja”, A.Borga 2 Me and my work at CERN I came to CERN in June 2003 after three years of Telecommunication engineering at the Politecnico di Torino to start a technical studentship focused on electronics design. My high school background in electronics allowed me to start learning with good basis while the engineering approach, learnt at university, helped on facing problems in a more structured way… but still, more than one year “of CERN” taught me many things about ultra-modern electronics both theoretical and practical. Beside the pure scientific knowledge that I gathered since the day I came, CERN gave me the opportunity to work with international people in an international environment contributing to open my mind toward many cultures and realities completely different from mine. When I first arrived I spent a few weeks taking over the work of Ramy Abdel-Rahman, which drew the first sketches of the schematics of the test board. Together with my supervisor Richard Jacobsson, lots of revisions, modifications and improvements were implemented before the layouting process started. The board has been routed taking into consideration the base lines of 9U VME board standard and the precious suggestions of Zbigniew Guzik who designed all the others TFC boards. I also gave support and supervision during the whole PCB manufacturing and mounting process to improve the board according to the indications and needs of the workshop personnel. The development of the firmware and control software has been done in parallel with the board debugging in a bidirectional manner: test software was developed to debug hardware and hardware has been used to debug software. The integration of the board inside the system architecture started from the development of self-test routines to debug the hardware and then moved step by step toward the whole chain testing incrementing the functionalities of which the board is capable. Once software and hardware were sufficiently developed many prototype and pre-production tests were done in the lab giving me the possibility to spend time measuring and “hacking” on all the TFC boards, building small devices to improve the tests and developing other tiny ideas which led to satisfying results. Two versions of Freja were produced: a first “final prototype” including two PCB manufactured and one mounted, and “final version”, with two PCB both mounted, differing from the first one by little bug fixes and small improvements. Those four boards will provide the necessary functionalities to the TFC system for the whole experiment life. 3 “Freja”, A.Borga 4 “Freja”, A.Borga 3 TFC System Overview 3.1 The LHCb detector The LHCb detector will be installed about 100m underground in the cavern of LHC Pit 8, around one of the collision points of the LHC collider. The detector is structured as a sequence of sub-detectors organized like a lying pyramid. In total it measures 20m in length and 10m in height. The sub-detectors are based on different technologies and detection principles in order to reconstruct fully the particle reaction; in particular they provide information about the structure of the collision through particle tracking, the particle energies and momenta, and their identities. The information comes out of the detector as electronic signals which are recorded by the data acquisition system. Figure 1: Schematic view of the LHcb detector. 5 “Freja”, A.Borga 3.2 LHCb readout system The figure below (Figure 2) shows a simplified picture of the entire LHCb readout system architecture [4]. Detector VELO ST OT RIC H ECAL HCAL MUON L0 FE L0 FE L0 FE L0 FE L0 FE L0 FE L0 FE L1 FE L1 FE L1 FE L1 FE L1 FE L1 FE L1 FE TFC SYSTEM SWITCH L1 SORTER SWITCH L1 SWITCH Event building L0 LHC CLK L1 SWITCH READOUT NETWORK SFC SFC SFC SFC SFC Front-End L0 TRIGGER SFC SWITCH SWITCH SWITCH SWITCH SWITCH SWITCH C C C C C C C C P P P P P P P P U U UU U UUU C C C C P P P P U UU U C C C C P P P P U UUU C C C C P P P P U UUU CC C C PP P P UUUU CPU farm Figure 2: A simplified picture of the LHCb readout system architecture Collisions taking place inside the detector are read out from the Front End electronics at a rate of 40 MHz. The big amount of data is too heavy to handle entirely and lots of events are not of physics interest; for those reasons the readout system features two levels of high-rate triggers: a Level 0 (L0) trigger that brings down the physics interaction rate of 10 MHz to an event accept rate of maximum 1.1 MHz, and a Level 1 (L1) trigger with an accept rate of maximum 40 kHz. The L0 trigger processing is carried out in a dedicated hardware module whereas the L1 trigger processing takes place in the CPU farm. The architecture of the Front-End (FE) electronics reflects this two level structure in that it consists of a L0 part and a L1 part. The L0 Front-End (L0 FE) electronics samples the signals from the detector (at a rate of 40 MHz) and stores them during the L0 trigger processing (4 µs). The event data are subsequently de-randomized before being handed over to the L1 FE electronics. The L1 FE has two channels to the event building network, one of which is used to transmit event data to the L1 trigger processing and the other which is used for the complete readout after the L1 trigger decision. Thus, upon receiving event data from the L0 FE, the L1 FE electronics sends a part of the data over the event building network for the L1 trigger processing and buffers the complete event data during the L1 trigger latency (58 ms). Upon receiving a positive decision the L1 FE de-randomizes the events, zero-suppresses the data, and finally sends the complete event data to the CPU farm for the High Level Trigger processing. 6 “Freja”, A.Borga 3.3 The TFC System architecture The Timing and Fast Control (TFC) system is responsible for controlling the LHCb readout by distributing timing, trigger and synchronous commands to the LHCb front-end electronics (Figure 3). It is different from the equivalent systems of the other LHC experiments in that it has to support the two levels of high-rate triggers. As the name itself suggests the system is responsible for: 1. Timing: the system must provide a clock, with minimum jitter, for means to archive timing alignment of the front-end electronics. 2. Fast control: provides trigger control and distribution and data routing. The system must also incorporate functionality to prevent buffer overflows in the entire readout chain, and provide means of different types of auto-triggering for tests and calibration. In order to simplify the implementation of a partitionable system, the TFC master ship of a configurable ensemble of front-end electronics is centralized in one module: the Readout Supervisor [5]. RS RS Throttle OR/Switch VELO FE Clock L0 / L1 Orbit Clock L0 / L1 Orbit Clock L0 / L1 Orbit Orbit Clock RS ST FE RS Clock L0 / L1 Orbit Local trigger (Optional) Physics trigger RS TFC Switch OT FE RICH FE ECAL FE ... Event building network Figure 3: The logical layout of the TFC architecture showing an example of partitioning. The sub-system VELO FE is driven by the leftmost RS triggered internally. The other sub-systems are driven by the RS in the centre connected to the LHCb trigger system. The other RS’ are unused. For separate local runs of sub-systems a programmable patch panel, the TFC Switch, allows associating sub-systems to the different optional Readout Supervisors: they may thus be configured to sustain completely different timing, triggering, and control, and can also be connected to local trigger sources. 7 “Freja”, A.Borga The TFC Switch distributes in parallel the information from the Readout Supervisors to the Front-End electronics of the different sub-systems. The information transmitted by the Readout Supervisors to the Front-End electronics via the TFC Switch and the TTC distribution network consists specifically of: 1. The LHC reference clock at ~40 MHz as received from the LHC timing generators. This is the master clock of all the electronics. 2. The two levels of high-rate trigger decisions (L0 and L1). 3. Commands resetting event related counters in the Front-End electronics used to identify the accepted events and to check synchronisation. 4. Commands resetting the Front-End electronics in order to prepare it for data taking or to recover from an error condition. 5. Calibration commands activating specific calibration systems in the Front-End electronics or in the sub-detectors. 6. IP/Ethernet addresses assigning the CPU farm destinations to the L1 trigger data and the full event readout. If the physics trigger rate gets abnormally high or data congestion occurs in the event building network, there is a potential risk of overflow in the buffers of the Front-End electronics. In order to prevent this, the Readout Supervisor controls the trigger rates according to the status of the buffers. Whereas the status of the fast buffers can only be known by emulating them centrally in the Readout Supervisor, slower buffers are monitored locally. In case they are monitored locally, imminent overflows are signalled via a dedicated throttle network. The Throttle Switch feeds back the buffer overflow warning signals from the slower buffers in the readout to the appropriate Readout Supervisor. Figure 4 shows a detailed view of the TFC architecture. The Throttle ORs function as concentrators of buffer overflow warning signals from the FE electronics and make a logical OR of the signals within the same sub-system. The TTC modules in Figure 4 are all standard components of the CERN TTC system (see Section 3.7). L0 L1 Clock receiver and fanout LHC clock Trigger splitter Trigger splitter L1 Readout Supervisor Readout Supervisor L0 Throttle switch TTCtx Readout Supervisor L1 Throttle switch TFC switch TTCtx TTCoc TTCtx TTCoc TTCoc TTCoc TTCrx TTCrx TTCrx TTCrx TTCrx TTCrx TTCrx TTCrx TTCrx TTCrx TTCrx TTCrx VELO VELO L1 L1FE FE TTCtx TTC system ECAL VELO VELO VELO L0 FE L0 FE L0 L0FE FE Throttle OR VELO VELO VELO VELO L0 FE L0 FE L0 L0FE FE TTCtx ECAL VELO L1 L1FE FE Throttle OR L0 Local trigger (optional) Figure 4: Overview of the TFC architecture. 8 “Freja”, A.Borga Summarizing, the TFC controls the readout part of the system accomplishing three main tasks using three main boards: 1. Control, monitoring and test runs: control is done by one of the Readout Supervisors in the pool and monitoring and test runs can be done by the others. 2. Partitioning: implemented via the TFC switch with the aim of easing the accomplishment of different task at the same time (e.g. physics taking and detector debugging), focused monitor testing on detector sub-parts without stopping a run. 3. Feedback: done by the Throttle Switch in order to give back-pressure to maintain the readout speed below the throughput limit of the Data AcQuisition system (DAQ). In the next paragraphs a more detailed description of each sub-part is given. 3.4 Readout Supervisor: “ODIN” The Readout Supervisor is a complex board responsible for a multitude of functions (Figure 5). The speed requirements and the multifunctionality of the readout supervisor necessitate optimal technological solutions. At the same time the logic must be modifiable to support extensions or changes in the running modes. Throttles ECS L0 LHC clock L1 Trigger generator ECS interface L1 broadcast generator Trigger controller Cmd broadcast generator Front-End TTC Encoder Event building TTC Figure 5: Simplified logical diagram of the Readout Supervisor showing the basic functions. The TTC encoder circuit incorporated in each Readout Supervisor receives directly the LHC clock and the LHC orbit signal via a TTC machine interface (TTCmi). The clock is distributed on the board in a star fashion and is transmitted to all synchronous destinations via the TTC system. The Readout Supervisor receives the L0 trigger decision from the central L0 trigger Decision Unit (L0DU), or from an optional local trigger unit, together with the Bunch Crossing ID. In order to adjust the global latency of the entire L0 trigger path to a total of 160 cycles (4 µs), the Readout Supervisor has a pipeline of programmable length at the input of the L0 trigger. Provided no other changes are made to the system, the depth of the pipeline is set once and for all during the commissioning with the first timing alignment. The Bunch Crossing ID received from the L0DU is compared to the expected value from an internal counter in order to verify that the L0DU is synchronized. 9 “Freja”, A.Borga For each L0 trigger accept, the source of the trigger (3-bit encoded) together with a 2-bit Bunch Crossing ID, a 12-bit L0 Event ID (number of L0 triggers accepted), and a “force bit” is stored in a FIFO. The force bit indicates that the trigger has been forced and that consequently the L1 trigger decision should be made positive, irrespective of the L1 physics trigger. The information in the FIFO is read out at the arrival of the corresponding L1 trigger. The RS receives the L1 trigger decision with a 2-bit Bunch Crossing ID and a 12-bit L0 Event ID. If the force bit is set the decision is converted to positive. The 3-bit trigger type and 2 bits of the L0 Event ID are subsequently transmitted as a short broadcast according to the format in Table 1. The Readout Supervisor controls the trigger rates according to the status of the buffers in the system in order to prevent overflows. Due to the distance and the high trigger rate, the L0 FE buffer occupancy cannot be controlled in a direct way. However, as the buffer activity is completely deterministic, the RS has a state machine to emulate the occupancy. This is also the case for the L1 FE buffers. In case an overflow is imminent the RS throttles the trigger, which in reality is achieved by converting trigger accepts into rejects. The slower buffers and the event-building components feed back throttle signals via the dedicated throttle network to the RS (Figure 4). Data congestion at the level of the High Level Trigger farm is signalled via the Experiment Control System (ECS) to the onboard ECS interface, which can also throttle the triggers. For monitoring and debugging, the RS has history buffers that log all changes on the throttle lines. The RS provides several means for auto-triggering. It incorporates two independent uniform pseudo-random generators of L0 and L1 triggers according. The RS also has a unit running several state machines synchronized to the LHC orbit signal for periodic triggering of a single or a specified number of consecutive bunch crossings (timing alignment), triggering at a programmable time after sending a command to fire a calibration pulse, triggering at a given time on command via the ECS interface etc. The source of the trigger is encoded in the 3-bit L1 trigger qualifier. The RS has also the task of transmitting various reset commands. For this purpose it has a unit running several state machine, also synchronized to the orbit signal, for transmitting Bunch Counter Resets, Event Counter Resets, L0 FE electronics reset, L1 + L0 FE electronics reset, L1 Event ID resets etc. The RS can be programmed to send the commands regularly or solely on command via the ECS interface. The RS transmits the IP/Ethernet destination for the L1 event data and for the complete readout as long broadcasts. The transmission of the various broadcasts is handled according to a priority scheme. The Bunch Counter and the Event Counter Reset have highest priority. Any clashing broadcast is postponed until the first broadcast is ready (L1 trigger broadcast, IP/Ethernet destination) or until the next LHC orbit (reset, calibration pulse, and all miscellaneous commands). The RS keeps a large set of counters that record its performance and the performance of the experiment (dead-time etc.). In order to get a consistent picture of the status of the system, all counters are sampled simultaneously in temporary buffers waiting to be read out via the onboard ECS interface. The RS also incorporates a series of buffers analogous to a normal Front-End chain to record local event information and provide the Data AcQuisition (DAQ) system with the data on an event-by-event basis. The “RS data block” contains the “true” bunch crossing ID and the Event Number, and is merged with the other event data fragments during the event building. 10 “Freja”, A.Borga Pool of Readout Supervisors ECS MULTIPLEXERS ECS interface DELAYS V SOR E TT I L C O H ... as TTC encoded electrical TFC Switch: “THOR” TTC information 3.5 Figure 6: Diagram of the TFC switch. As mentioned before, the TFC Switch (Figure 6) realises the partitioning of the TFC system. It is a programmable patch panel (not a switch in the network sense) that allows distribution of the synchronous information to the different parts of the Front-End electronics. From the architecture of the TFC system, it follows that the Front-End electronics that is fed by the same output of the TFC Switch is receiving the same timing, trigger and control information. The connectivity provided by the board is not necessarily one-to-one: the TFC Switch should allow setting up several partitions, by associating a number of partition elements (e.g. sub-detectors), to several Readout Supervisors in order to accomplish different tasks. For example while the main RS is controlling the detectors for data taking, the optional Readout Supervisors have the possibility of running separately on other detector parts for test and debugging purposes. The TFC Switch has been designed as a 16x16 switch and thus allows the LHCb detector to be divided in 16 “atomic” sub-systems. To increase the partition granularity an option exists whereby four TFC Switches are deployed in order to divide the LHCb detector into 32 sub-systems. The TFC switch configuration setup is done remotely by software via the control system interface. 3.6 Throttle Switch and Throttle OR: “MUNIN” and “HUGIN” Pool of Readout Supervisors OR logic and history buffer V S O R E T T I L C O H ECS interface Throttle signals ECS ... Figure 7: Diagram of the Throttle Switch. Opposite to the data flow provided through the TFC switch, a Throttle Switch (Figure 7) has been designed with the aim of providing backward paths of throttle signals (in case of imminent buffer overflows) from the end buffers in the L1 front end electronics to the appropriate Readout Supervisor. The functionality of this module is specular to the one used in the TFC switch: several input signals are OR'ed to produce a single output signal. 11 “Freja”, A.Borga The module has both 16 electrical and optical inputs and 16 electrical outputs. Besides providing the ORing and the routing of the throttle signals the Throttle Switch also trace the behaviour of all input and output signals with a good time resolution. In addition to the Throttle Switch, a Throttle OR will be designed to group throttle lines belonging to the same partition elements. It is identical to the Throttle Switch in all aspects except that it ORs 20 L0 and 20 L1 throttle inputs and transmits then on a L0 and a L1 output. Those components too are software configurable via the control system interface. 3.7 TTC Distribution System The TFC distribution network is based on the RD12 Trigger, Timing and Control (TTC) system: a CERN standard optical network used by all four LHC experiment [7]. The TTC system distributes information optically on two serial channels: • • Channel A: transmits the LHCb L0 trigger decisions to the Front-End electronics in the form of an accept/reject signal at 40 MHz. Channel B: transmits framed and formatted broadcasts, including Hamming code. Two types of broadcasts are available: 16 bit frames which have 8 bits of user information, so called short broadcasts (Table 1), and 42 bit frames which have 16 bits of user information (8 bit data/8 bit address), so called long broadcasts (Table 2). It is used for several functions like: transmission of the commands to reset the Bunch Counters (BCR) and the Event Counters (ECR) in the Front-End electronics and the trigger systems; transmission of the L1 trigger decision and of the Front-End control commands (e.g. calibration pulse triggering). Table 1: Summary of the short broadcasts in LHCb. L1 trigger 7 1 6 5 Trigger type 4 3 2 1 0 0 0 L0 FE ECR BCR 0 0 0 0 L0 EvID Reset 0 1 R L1 EvID Calibration 0 0 0 1 Command 0 0 1 L1 FE Pulse type Command type Table 2: Summary of the long broadcasts for the IP destination assignments in LHCb. L1 IP destination 15 1 14 0 13 0 12 Flush 11 R 10 R HLT IP destination 1 0 1 Flush R R 9 8 7 6 5 4 3 2 Ethernet/IP address 1 0 Ethernet/IP address The two channels are time division multiplexed (TDM) and bi-phase mark encoded before being converted to an optical signal. The bi-phase signal also allows transmitting the clock with low jitter. The encoding is done in the Readout Supervisor with the TTC Readout Supervisor (TTCrs) module and the electrical to optical conversion is done by the TTC Transmitter (TTCtx) modules, which have 14 high-power transmitters. The optical fan-out TTC Optical Couplers (TTCoc) allows distributing the signal to 32 destinations, which means that one TTCtx can drive up to 448 destinations. The TTC Receiver (TTCrx) ASIC reconstructs the 40 MHz clock and converts the encoded signal into the user information. The TTCrx also provides means to adjust the timing of the TTC information in order to time-align all Front-End boards. A version of the TTCrx, mounted on a mezzanine (TTCrm), is also available if an easier access to the chip is needed, like for example, for debugging purposes. Another TTC module, the TTC machine interface (TTCmi), interfaces the local experiment TTC system with the accelerator timing system. It’s responsible of providing the LHC clock and the LHC orbit signal. 12 “Freja”, A.Borga 4 Testing methodologies 4.1 Introduction to hardware testing Although standard testing methodologies were initially developed for software debugging, the definitions described below can fit perfectly hardware testing. Two main categories of test setups are widely used: 1. Black box testing: functional testing. Stimuli T E S T B O A R D BLACK BOX Black box focuses on purely functional testing. Test routines are written knowing only the system requirements, the inputs and the outputs (the box is “closed”). The internal structure and implementation are therefore ignored by the tester. To give a better hardware view, these kinds of test are called “in the crate”. Response Figure 8: Black box configuration. 2. Glass (white) box testing: focused testing. Stimuli T E S T B O A R D GLASS BOX Glass box testing applies a more direct strategy by focusing on testing the implementation. The internal structure and composition is accessible (the box is “transparent”). Knowing it, the tester can try to find out which is the best testing approach. Information about the system can be also used to test particular features or to obtain specific results. Again for a good hardware analogy these tests are called “on the table”. Response Figure 9: Glass box configuration. White box testing can be split in other subcategories: a. Static: the system is not running. This is the case for onboard measurements to detect for examples bad contacts between pins and pads, transmission lines malfunctioning, etc. b. Dynamic: this is “common” testing. It involves probing the system while it’s running. Testing rarely only involves one of the methods: a complete verification is achieved only by a good combination of both. 13 “Freja”, A.Borga 4.2 Testing theory In a mathematical form testing can be expressed in the following way: R = f (S , C ) A Response (R) of a system is the result of a function (f) fed with a Stimuli (S) and Configurations (C) selected by the user inside a multi-dimensional space. Figure 10 shows a response of the system in a test space with one stimulus and one configuration: Figure 10: Three dimensional plot of the system test space. The stimuli are selected according to the type of test that is performed. The test can either be constructive or destructive: stimuli can be within the range of correct values to test normal running behaviour or the system can be exposed to faulty stimuli to test error recovery. A stimulus can be either purposive (periodic) or random to ensure coupling and decoupling of the system from its previous stimuli. The configuration axis is scanned in discrete steps: it is in fact often useless or not possible to setup the board in certain combination of configurations. According to the allowed configurations and the chosen range of stimuli, which are often selected according to the configuration in use, it is possible to define existence regions for the testing function which are represented by the rectangles on the above plot. It is very important to define the test (Stimuli and Configurations) carefully to optimize the test procedure, not to end up testing all combination. 4.3 TFC test setup With Section 4.2 in mind the aim has been to implement a test bench which has a unit to produce stimuli and receive responses. In order to make verification the unit emulates functionalities of the system in test. A control system configures and sets up the test procedures. The test unit, called Freja, of the TFC test bench is the subject of this report. All its functionalities and a detail description are following in the next chapters. 14 “Freja”, A.Borga Two kind of test are made for the TFC: 1. Single board test. Since the Readout Supervisor is the most complex board of the TFC system it requires focused tests. Referring to the device description made in Section 3.4 the test will concentrate on debugging the following features: • L0 trigger path • L1 trigger path • Buffer level control • IP destination broadcasting Figure 11: Single board test configuration. 2. Full TFC system testing. electrical optical L1 path (LVDS) L0 path (LVDS) Throttle path (LVDS) Figure 12: Full TFC system test configuration. The test board emulates both the L0 and L1 decision units (L0 trigger and L1 trigger in Figure 2) sending decisions to the Readout Supervisor; the decisions are then transmitted to the Front-end electronics (L0 and L1 FE emulated by the test board) via the whole TFC chain: TFC switch and TTC distribution network. The test board can speed up the decision sending in order to overflow the buffers in the Readout Supervisor or in the Front End: this technique is used to check the throttle backward path and the buffer emulation (via the throttle switch). The aim of Freja is to perform black box testing of all the functionality of the boards in the setups listed above. As mentioned before black box testing and glass box testing are complementary and black box testing will help the testers to discover bugs which will be subsequently debugged using glass box testing. For example: a test aim is to check if a data bus is clean, complete (no bits missing), well driven and arbitrated and pass all the way trough its designed path. A black box test done with the test board will consist in feeding data pattern and driving the control bus lines of the target board via a known bus input and receive them back from a known bus output. Afterwards the board will compute the received signal (checks the data integrity, delays, etc) and decide if it’s correct or not. If the result is correct the test is over and successful. If not one must switch to glass box tests: measurements can start from the path check to make sure that signals are propagated properly all the way down, if the path is interrupted somewhere the test focus then on the chip or line that causes interruptions, if the signals shapes are ruined but none on the chip driving has an odd behaviour, the test can move to neighbouring parts of the board. A careful combination between the two tests and a bit of method and intuition will always drive a tester to a solution. 15 “Freja”, A.Borga 4.4 Application of Freja Freja is a general purpose board which allows it to be used in the TFC system in several applications for a very long time. Many different purposes were conceived and studied already in the early stages of the conception. Here after they are discuss in more details. 4.4.1 Prototype testing Prototyping phase is the most critical part of all. The complete set of features of the TFC has to be tested extremely carefully in order to lunch the production of a 100% working product. Prototype testing involves tests on parts that will not be changed (except in case of future development and improvements), like the hardware. Another point to concentrate on during prototype testing is to find a good set of “well known” problems that will ease life on production testing: for example if a particular component follows a difficult mounting technique (like dense, impedance matched connectors, fine pitch ICs, etc) and problems are discovered during prototype testing, it will be important to check carefully it on all the produced boards. Error recovery testing is fundamental as well in this phase: it’s important to know how the system reacts and recover from certain error conditions, how long it takes and if afterwards it can be considered stable again. 4.4.2 Pre-production and production testing This phase makes use of all the experience gathered during prototype testing. Test bed contains a full set of testing and debugging tools (see following chapters) in order to speed the procedures. 4.4.3 Commissioning “You have a board perfectly working on your lab table… you bring it down to the pit, plug it into the crate… and suddenly everything goes wrong!” this is a nightmare that very often scares technicians, engineers and physicists and the reason why a test board can be very useful to test board-to-board functioning and compatibility during commissioning. In situ architecture and installation tests aim at solving these kinds of problems: Freja will perform the standard test routines, developed in the lab environment, on the TFC boards in the barracks of Pit 8 (LHCb installation site). Since the TFC installation will take place long before the installation of the detectors with their electronics, Freja will allow the TFC system to be tested without the final front-ends. 4.4.4 Experiment monitoring Freja will be an independent implementation of a Front End electronics to perform system tests together with idle Readout Supervisors. The test board will also perform simple TTC system monitoring, tuning alignment between detectors and cross checking of the connectivity of the entire TFC system. 16 “Freja”, A.Borga 5 TFC test board: “FREJA” 5.1 Overview of the board Figure 13: A block diagram of the TFC test board. The board consists of seven main blocks with different functions and using different electronics: 1. Control interface [Section 5.2 and Section 5.3]: a Credit Card PC is accessible via remote connection in an Ethernet network. From the CCPC the hardware is accessible via a 33MHz PCI bus. An interface card (Glue card) translates the PCI bus to the proper bus formats to reach specific devices on board (such as FPGAs, memories, etc). Four types of conversions are made by the Glue card: a. JTAG: dedicated lines for the FPGA programming and boundary scan of devices. b. I2C: standardized serial bus used to configure small devices (e.g.: serial ID E2PROM, I2C port, TTCrx). c. LBUS: the PLX Local Bus is a 32-bit bus used to configure, control and monitor the functions implemented in the FPGA. d. GPIO: general purpose input/output lines. Used in Freja to drive JTAG lines to program the Altera configuration device (EEPROM) for the FPGA. 2. External general purpose electric I/O [Section 5.4]: to interface the test board with the rest of the system in order to make tests, it’s important to have as many input/output ports as possible. Two different electrical transmission techniques are used to transmit data over the system: single ended ECL (Emitter Coupled Logic) and differential LVDS (Low Voltage Differential Signalling). 3. Optical transmitter and receiver: the optical I/O interface of Freja is used in a standalone mode to test the optical path of the throttle network (Munin) and to transmit throttle signals when Freja acts like a front end board. 4. FPGA [Section 5.5]: together with an external FIFO buffer this is the core part of the board. A programmable logic device with 168 IO ports is used to perform all functions of Freja, drive and receive test signals, perform calculation and checks on them and make results available to the user interface. A device configuration EEPROM is implemented to speed up the programming process of the device at start-up. 17 “Freja”, A.Borga Clock sources: in order to run the board in different modes a clock selection multiplexer, accessible via I2C, has been implemented giving the possibility to select between: a. Internal clock: 40MHz quartz generated clock. b. TTCrm clock: clock generated by the TTC system (experiment official clock). c. TTCrs clock: internal or external clock coming from the TTCrs mezzanine. d. External clock: allows the board to run with an external clock source. 6. TTCrs: TTC encoder and transmitter. 7. TTCrm: optical TTC system receiver. 5. 5.2 Credit Card PC 5.2.1 The ECS interface and the CCPC The electronics boards in LHCb will all be controlled from the LHCb Experiment Control System (ECS). In order to access the actual board resources, an ECS interface will be located on each board. The ECS interface is connected to the control network and performs directly all programming, configuration, control and monitoring of each electronics board. Three ECS interfaces have been proposed for different applications: the SPECS (Serial Protocol for the Experiment Control System) and the ELMB (Embedded Local Monitor Board) will be used for electronics boards situated in the radiation area close to the experiment; for the electronics situated in the counting rooms behind the shielding wall, the ECS interface is based on a commercial small (credit-card size) embedded PCs used to provide the necessary local intelligence on electronic boards [12]. They are connected to the central ECS via a conventional Ethernet. The core of the Credit-Card PC (CCPC) is a SM520PC Smart Module produced by DigitalLogic, Inc [13]. This module comprises a PC-on-a-chip also known as micro-controller, the Elan520 from AMD, an Ethernet interface and a Flash RAM. It can run any standard PC operating system and runs Linux in LHCb. The CCPC is equipped with a 33 MHz PCI bus which is used for all access to the board logic. Figure 14: Picture of the "Glue light" board (right) together with the Credit Card PC (left). 18 “Freja”, A.Borga 5.2.2 PCI Interface Currently by far the most popular local I/O bus, the Peripheral Component Interconnect (PCI) bus, was developed by Intel and introduced with the version 1.0 in 1992. Since then several updates (revision 2.0, revision 2.1, version 2.2 [17] and PCI-X [18]) have been made to improve not only the bus speed but also the overall performance (bus arbitration, transmission, etc). It was geared specifically to fifth- and sixth-generation systems (e.g. Intel Pentium and Pentium II), although the latest generation 486 motherboards were already using it as well. Like its predecessor, the VESA (Video Electronics Standards Association) Local Bus, PCI 1.0 was a 32-bit bus running at a maximum frequency of 33 MHz. Since then its wide usage in electronic devices led this technology to nowadays’ extreme edges. The PCI bus is used to interface devices requiring fast access to each other and/or system memory and that can be accessed by the processor at a speed close to its internal bus. A key feature of PCI is the capability to transmit data in bursts (a single address phase is followed by two or more data phases) whose length is set by the master. The target device receives information about the transaction type and the start signal, but not the transfer length: while the master makes a burst of data transactions, it signals the target device when the last word transfer occurs. The typical PCI device includes a complete peripheral adapter encapsulated within an IC package or implemented on an expansion card: the most famous interface device is the PLX 9030 whose functions have inspired the development of the firmware for the Glue card (see Section 5.3). Reflected-wave switching At the time when bus speeds were low (below 1 MHz) the characteristics of transmission lines were neglected by designers and the choice of the power of the driving device was selected according to the electric characteristics (in particular the input capacitance) of the devices connected to the lines. Using buses with clock frequencies higher than 25 MHz, traces acts as transmission lines and the electrical characteristics of the trace must also be taken into account solving the equation that defines the characteristics of the output driver: an impedance, varying between 50 and 110 Ohm, is presented to the driver trying to drive a voltage change onto the line and also imposes a time delay in the transmission of the voltage change along the trace. An old method used to eliminate the annoying effect of the line impedance is called IncidentWave Switching. It involves the use of strong output drivers with the capability of switching close to the driving point of the device (point of incidence). The main disadvantage of this method is that connecting several devices on one trace increase immediately the driving current required. This limits the packing of drivers in chips and increases the heat on board. Incident-wave switching also requires termination on the lines. Since this technique turned out to be inefficient, another was introduced for PCI called Reflected-Wave Switching: no termination is required and the reflected wave is used as an advantage. A carefully selected, relatively weak output driver is used to drive the signal line partially towards the desired logic state. The driver only has to drive the signal line partially towards its final state, rather than completely (as a strong incident-wave would). No inputs along the trace will sample the signal until the next rising-edge of the clock. When the wavefront arrives at the unterminated end of the bus, it is reflected back and doubled. Upon passing each device input again during the wavefront’s return trip down the trace, a valid logic level registers at the input on each device. The signal is not sampled, however, until the next risingedge of the PCI clock. Finally the wave front is absorbed by the low-impedance within the driver. This method cuts driver size and lower by half the current needed using incident-wave witching technique. Diode terminations are integrated inside devices to limit reflections and correct the propagation 19 “Freja”, A.Borga delay. Even though Reflected-wave switching has improved a lot the signal characteristic in PCI, it is always better to swap to more versatile bus techniques as soon as possible. With the last statement in mind the Glue card has been developed. Bus signals The PCI interface requires a minimum of 47 pins for a one-target device to handle data, addressing, interface control, and system functions. Two additional pins, routed directly to a bus arbiter, are required in the case of multi-master configuration for each device that intends to act as a master on the bus. Required pins Address & Data Optional pins AD [31...0] AD [64...32] nC/BE[3..0] nC/BE[7..4] PAR PAR64 nREQ64 nACK64 nFRAME nTRDY nIRDY nSTOP nDEVSEL IDSEL Interface Control Error Reporting nPERR nSERR Arbitration (master only) nREQ nGNT System CLK nRST PCI COMPLIANT DEVICE 64-Bit Extension nLOCK nINTA nINTB nINTC nINTD Interface Control Interrupts TDI TDO TCK TMS nTRST JTAG (IEEE 1149.1) Figure 15: PCI bus signal organization. As shown in the figure above PCI pins are organized in different groups. Below a more detailed description of the most important pin’s function: 1. System pins: a) CLK: provides timing for all transaction on PCI and is an input of every PCI device. The CCPC can operate up to 33 MHz or 66 MHz (according the specification of rev 2.2); though it must be kept in mind that newer specification, like PCI-X foresee operations of devices at a frequency up to 133 MHz. b) nRST: PCI’s reset line. 2. Address and Data pins: a) AD [31...0]: Address and Data are multiplexed on the same PCI pins. A bus transaction consists of an address phase followed by one or more data phases. As mentioned before PCI supports both read and write bursts. b) nC/BE [3...0]: Bus Command and Byte Enables are multiplexed on the same PCI 20 “Freja”, A.Borga 3. 4. 5. 6. pins. During the address phase the pins are used to define Bus Commands (the type of transaction the bus is requesting). In the data phase they are used as Byte Enables (determine which bytes are valid in the bit stream on the bus). c) PAR: Parity is even parity across AD [31...0] and C/BE [3...0]. Parity generation is required by all PCI devices. Interface Control pins: a) nFRAME: Cycle Frame is driven by the current master to indicate the beginning and duration of an access. b) nIRDY: Initiator Ready indicates the initiating devices’ ability to complete the current data phase of the transaction. During write mode it indicates that valid data is present on the address bus. During read mode it indicates that the master is prepared to accept data. c) nTRDY: Target Ready indicates the target devices’ ability to complete the current data phase of the transaction. During a write operation it indicates that the target is prepared to accept data. During a read operation it indicates that valid data is present on the bus. d) nSTOP: Stop indicates that the current target is requesting the master to stop the current transaction. e) nLOCK: Lock indicates an atomic operation to a bridge that may require multiple transactions to complete. f) IDSEL: Initialization Device Select is used as a chip select during configuration read and write transaction. g) nDEVSEL: Device Select, when actively driven, indicates that the driving device has decoded its address as the target of the current access. As an input it indicates whether any device on the bus has been selected. Arbitration pins: a) nREQ: Request indicates to the arbiter that this device desires use of the bus. This is a point-to-point signal. b) nGNT: Grant indicates to the device that access to the bus has been granted. This is a point-to-point signal too. Error Reporting pins: a) nPERR: Parity Error is only for the reporting of data parity errors during all PCI transaction. It is mandatory to use this control signal because the devices driving the bus must assume that the receiver will check the correctness of the information and flags back in case of errors. It can be neglected in case of Special Cycles (a broadcast message to one ore more PCI devices). b) nSERR: System Error is for reporting address parity errors, data parity errors during a Special Cycle and critical errors (usually even catastrophic) other than parity. Optional pins: a) 64-Bit Extension: PCI bus can be extended up to 64-bits. This requires more control logic of course. The PCI extension is not analyzed in detail because for TFC purposes the 32-bit wide bus is sufficient. b) Interrupt pins: 4 interrupt lines are reserved on the PCI bus to allow devices to request attention from its device driver. 21 “Freja”, A.Borga 5.3 Glue Card Since PCI is a complex and difficult bus to handle (require special attention when routing due to tight timings and many control line) a small device is used to convert the PCI bus after a short distance on board to more simple ones; the conversion unit is the Glue Card (the name comes from the fact that glue logic consists of a simple circuit used to interface different devices, like the CCPC to the board logic) implemented in a “light” version by TFC system [19]. The mezzanine is entirely based on a single FPGA which is interfaced with the PCI bus of the CCPC and emulates a PLX 9030 (an ASIC chip that produces a simple PLX local bus) [14]. Figure 16: Block diagram of the Glue card. As mentioned before the Glue Card translates the PCI bus into different bus protocols (JTAG, I2C and Local Bus) allowing access to many different types of devices. Next each bus type is described in more details. 5.3.1 PCI slave The PCI interface implemented in the FPGA of the Glue Card is compliant with the PCI Local Bus Specification Revision 2.2 and emulates a PLX 9030. The target supports a 33 MHz and 32-bit PCI bus. Table 3: Implemented PCI bus commands. 22 CBEN [3 ... 0] Bus Command Cycle Note 0110 0111 1010 1011 1100 1110 1111 Memory Read Memory Write Configuration Read Configuration Write Memory Read Multiple Memory Read Line Memory Write and Invalidate fully implemented fully implemented fully implemented fully implemented substituted by Memory Read substituted by Memory Read substituted by Memory Write “Freja”, A.Borga Table 3 summarizes the PCI bus commands that are supported by the Glue Card. Table 4 presents the PCI Configuration Registers. These registers are accessed by the commands “Configuration Read” and “Configuration Write”. Only the shaded fields are implemented. Read accesses to the other fields always return zero. The Configuration Registers can be accessed either in byte, word or double word transfers. The first two Base Address Registers (BAR0 and BAR1) are reserved for system use. BAR2 holds the base address of the local resources described below. Table 5 shows the values assigned by default to the Configuration Registers. Table 4: PCI Configuration Registers. Shaded registers have been implemented. Address 31 ... 24 23 ... 16 15 ... 8 7 ... 0 00h 04h 08h 0Ch 10h 14h 18h 1Ch 20h 24h 28h 2Ch 30h 34h 38h 3Ch 40h - FCh Device ID Vendor ID Status Register Command Register Class Code Revision ID BIST Header Type Latency Timer Cache Line Size Base Address 0 (BAR0) Base Address 1 (BAR1) Base Address 2 (BAR2) Base Address 3 (BAR3) Base Address 4 (BAR4) Base Address 5 (BAR5) Cardbus CIS Pointer Subsystem ID Subsystem Vendor ID Expansion ROM Base Address Reserved Reserved Max_Lat Min_Gnt Interrupt Pin Interrupt Line Reserved Table 5: Default settings of the PCI Configuration Registers. Name Offset Vendor ID Device ID 00h 02h Command Register 04h Status Register 06h Revision ID Class Code 08h 09h BAR0 – BAR2 10h Subsystem Vendor ID Subsystem ID 2Ch 2Dh Value 1172h (Altera ID) 0001h Read/Write bits: Bit 1 – MEM_ENA Bit 6 – PERR_ENA Preset bits: Bit 7 – STEP_IMPL (forced to HIGH) Other bits hardwired to LOW Updated Read/Write bits: Bit 27 – TAR_ABORT (Set when no slave response) Bit 31 – DET_PAR_ERR (Detected parity error) Preset bits: Bits 26..25 – DEVSEL_TIM (Set to 10) Other bits return LOW 01h 118000h (Data acquisition + Other + None) Bit 0 - MEM_IND (hardwired to LOW) Bit 2..1 - MEM_TYPE (hardwired to LOW) Bit 3 - PRE_FETCH (hardwired to LOW) Bits 15..4 - hardwired to LOW Bits 31..16 - r/w accessible 201Ch 0000h 23 “Freja”, A.Borga Seen from the PCI bus, the entire user memory occupies an address range of 64 KB (16 address lines). As shown in Table 6, the block is divided into two regions: the first 64 bytes (16 double words) hold the Internal Registers and the rest of the space is used for the local bus accesses to the registers on the motherboard. Accesses to the Internal Registers and the local bus transfers may only be done as 32-bit double words via the Base Address Register 2 (BAR2) in the PCI Configuration Register. Table 6: Assignment in the local memory of the device. Offset 31 .. 24 23 .. 16 00h ... 03Fh 040 ... FFFFh 15 .. 8 7 .. 0 Internal Registers (r/w) (Table 5) Local Bus (r/w) The Internal Registers of the Glue Card controls three areas of activity: the JTAG and the I2C busses and the General Purpose I/O lines. In addition the Internal Registers contains a Control and Status Register (CSR) which allows configuring several functions of the Glue card. A summary of all the Internal Registers is given in Table 7. All unused (not shadowed) registers return zero during read access. In the current version of the Glue Card, the CSR (Table 8) allows enabling and disabling the JTAG and the I2C bus and the General Purpose I/O lines. Disabling a bus puts the output pins in the high-impedance state. The CSR also allows selecting the width of the local bus and configuring the abort method when a time out occurs on the local bus. When a smaller local bus than 32 bits is used, it always starts from the least significant bit. Table 7: Assignment of the Internal Registers. Offset 31 .. 24 00h 04h 08h 0Ch 10h 14h 18h 1Ch 20h – 3Fh 23 .. 16 15 .. 8 7 .. 0 CSR (Table 6) JTAG_CON (Table 8) I2C_CON (Table 9) I2C_DAT PIO_PORT (Table 10) PIO_OE (Table 10) PIO_SSET (Table 10) PIO_SCLR (Table 10) Reserved Table 8: Bit assignment in the Control and Status Register (CSR). (Offset 00h in the Internal Registers). Bits Mnemonics Description 24 1...0 BSIZE [1..0] 2 TMO_ABORT 3 BRST_ENA 4 5 6 7 JTAG_ENA PIO_ENA I2C_ENA JTAG_TRST 00 – 8 bits bus 01 – 16 bits bus 10 -- 24 bits bus 11 – 32 bits bus When set Target Abort is generated on a time out, this is missing slave response. When zero a dummy cycle is generated When set enables burst operation on the local bus, otherwise only single data cycles are performed Enables/disables the JTAG bus Enables/disables the General Purpose I/O port Enables/disables the I2C bus JTAG reset line (active in low) Access Selecting the size of the local bus: r/w r/w r/w r/w r/w r/w r/w “Freja”, A.Borga 5.3.2 I2C Bus Although serial buses don’t have the throughput capability of parallel buses, they require less wiring and fewer IC connecting pins. It must be remarked that a bus is not merely an interconnecting wire but it embodies all the format and procedures for communication within the system. Devices communicating with each other on a serial bus must have some form of protocol which avoids all possibilities of confusion, data loss and blockage of information. The communication system must not be dependent on the devices connected to it, otherwise modifications or improvements would be impossible. A procedure has also to be devised which device will be in control of the bus and when. If different devices with different clock speeds are connected to the bus, the bus clock source must be defined. I2C specifications take care of all requirements in detail. Figure 17: Generic I2C bus configuration. I2C (Inter-Integrated Circuit) [20] is a simple bi-directional 2-wire bus developed by Philips in order to control efficiently integrated circuits interconnected with few signals on electronics boards. One line feeds the clock to the devices (Serial Clock Line, SCL) and the other carries data (Serial Data Line, SDA). Bi-directional data transfers can be made at up to 100kbit/s in Standard-mode, up to 400kbit/s in Fats-mode or up to 3.4Mbit/s in the High-speed mode but the last mode requires special routing techniques. Each device is recognized by a unique peripheral address and can operate as either a transmitter or receiver, depending on the function of the device. A master is the device which initiates a data transfer on the bus and generates the clock signals to permit the transfer; any device addressed is considered a slave. The I2C bus is a multi-master bus: more than one device capable of controlling the bus can be connected to it; that means that more than one device master could try to initiate a data transfer at the same time. To avoid the chaos that might ensue from such an event, an arbitration procedure is implemented. This procedure relies on the wired-AND connection of all I2C interfaces to the I2C bus. A master can operate both as master-transmitter or master-receiver. Since on Freja the master of the I2C bus is always the FPGA on the Glue Card, bus arbitration is not discussed in more detail. All I2C bus compatible devices incorporate an on-chip slow interface which allows them to be addressed directly between each other. 25 “Freja”, A.Borga Bit structure Bit transfer structure on I2C is similar to many other serial buses. Unique situations are defined as START and STOP conditions: • • A HIGH to LOW transition on the SDA line while SCL is HIGH indicates a START. A LOW to HIGH transition on the SDA line while SCL is HIGH defines a STOP. SDA SCL START condition STOP condition Figure 18: I2C START and STOP conditions. START and STOP conditions are always generated by the master. The data on the SDA line must be stable during the HIGH period of the clock. The HIGH or LOW state of the data line can only change when the clock signal on the SCL line is LOW. Every data transaction put on the SDA line must be 8-bits long. Each byte has to be followed by an acknowledge bit. Data is transferred with the most significant bit (MSB) first. By holding the clock line LOW a slave can force a master into a wait state. SDA SCL Data line stable data valid Change of data allowed Figure 19: Valid Data line transaction according to Clock status. Freja uses the format with 7-bit peripheral address (a 10-bit is available too) which is structured as follows: Master-transmitter addressing a slave receiver Master to slave S SLAVE ADDRESS R/W A DATA A DATA A/A P Slave to master Master reads a slave immediately after first byte S SLAVE ADDRESS R/W A DATA A DATA A P A = Acknowledge (SDA LOW) /A = not Ack (SDA HIGH) S = START condition Sr = repeated START condition P = STOP condition R/W = ‘1’ read , ‘0’ write Combined format S SLAVE ADDRESS R/W A DATA A/A Sr SLAVE ADDRESS R/W A DATA A/A P Figure 20: I2C data information structure for sequential memory access. 26 “Freja”, A.Borga Many I2C devices allow to access more than one I2C register in a non sequential mode, in this case the structure is: Master to slave Slave to master Byte write to target register in a device S SLAVE ADDRESS 0 A WORD ADDRESS A DATA A P A = Acknowledge (SDA LOW) /A = not Ack (SDA HIGH) S = START condition Sr = repeated START condition P = STOP condition R/W = ‘1’ read , ‘0’ write Random read to target register in a device S SLAVE ADDRESS 0 A WORD ADDRESS A S SLAVE ADDRESS 1 A DATA A/A P Figure 21: I2C data information structure for random memory access. I2C on the glue card The operation of the I2C bus on Freja is controlled via the PCI bus by accessing two 8-bit wide registers in the Internal Registers: I2C_CON and I2C_DAT. The I2C_CON register provides an interface to the I2C state machine implemented in the Glue Card FPGA. The procedure to operate the bus follows the standard specification described before and the bit assignment in the I2C_CON register is shown in Table 9. Table 9: Bit assignment in the I2C control register I2C_CON (Offset 08h in the Internal Registers). Bits 0 1 2 3 4 5 6 7 Notes: Mnemonic Description Access Error bit. Set after a bus request access failed (unsuccessfully writing START, STOP or data or reading data). Cleared after the first valid transfer. NOACC Note: Writing or reading the data register I2C_DAT when DONE is low will ro cause this error. Also reading data while in “sending” mode or writing data while in “receiving” mode will generate this error. The bit indicates that the slave acknowledged the address phase (for read or ACK ro write). For write transfers ACK = ‘1’ when byte is accepted. Set after completion of the start, the data or the stop phase . Cleared after DONE ro setting the START or the STOP and reading or writing the register I2C_DAT. The bit indicates that the I2C bus is being used. It is set after setting the BUSY ro START bit and it is cleared when the stop condition occurs. When I2C_RESET is set, a reset of the entire I2C controller is performed. I2C_RESET The reset is a momentary action and extends only over two system clock mom cycles. Can be set only if DONE has been asserted. Forces no read acknowledge LAST r/ws while sending data. Cleared after the stop condition occurs. Can only be set if DONE has been asserted. It generates a stop condition. It STOP r/ws is cleared when the access has been completed. Can be set if either BUSY is LOW or DONE is HIGH. It generates the start START r/ws condition. When BUSY is asserted, repeated start conditions may be generated. Cleared after the acknowledgment in the address phase Bits 3 ... 0 are read only Bit 4 is a momentary write-only action bit and it doesn’t retain its value. Bits 7... 5 are special action read/write bits. Writing a logic one to the bit sets the appropriate bit in the register. Writing a logic zero has no effect. Data are transferred to and from the I2C bus by writing and reading the I2C_DAT register (Table 7). The register holds the address byte during the address phase, and a byte of data to be transferred in write mode or a received data byte in read mode. 27 “Freja”, A.Borga The least significant bit of the address byte contains the direction flag. A “0” means a write transfer and a ‘1’ a read transfer. The bus frequency is approximately 100 kHz by default for compatibility. It can be configured to run four times faster for devices that support the higher speed. I2C on Freja Three I2C devices are used on Freja (Figure 22): Figure 22: Block diagram of the devices connected to I2C bus on Freja. a) EEPROM 24LC00: small non volatile memory that stores board identification information. This information is used by the control system to identify different types of boards (see Section Error! Reference source not found.). The EEPROM ha a storage capacity of 128 bits organized as 16 words of 8 bits. The memory structure is shown in Table 10. Table 10: EEPROM physical address and internal structure. Physical or peripheral address If X bit is: 0xAX 0. Write memory 1. Read memory: whether random or sequential Command byte 0x00 28 Description System ID [TFC] 0x01 Board Type 0x02 Board Revision [Ver 1, Ver 2] [Freja, Odin, etc.] 0x03 Board Number [0, 1, 2, 3, etc.] “Freja”, A.Borga b) I2C REGISTER PCA9554: device used to drive the control lines of simple components on the board. Each output line is associated and driven by an internal register (Table 11). Table 11: I2C register physical address and control lines structure. Physical or peripheral address If X bit is: 0x4X 0. Write memory 1. Read memory: whether random or sequential Command Description byte Value Comments I/O configuration register 0x00 All I/O lines set to output 0x03 X { X { X { X { X { FPGAreset not used TTCrs reset H _ EXT * TTCrx reset [ SRESn1] [ SRESn 2] X { X { 123 X { SEL 2 SEL1 not used Clock selection * clock source on TTCrs 0x01 Output port register 0x14 [10100] Internal clock 0x12 [10010] External clock 0x10 [10000] TTCrm clock 0x16 [10110] TTCrs external clock 0x06 [00110] TTCrs internal clock c) TTCrx: the configuration of the TTC receiver chip is done via I2C. The I2C bus of this device is based on a double register configuration: an address is written to an address register in order to target a memory location, while data are transferred through a data register. This access mode is thus slightly different from the one implemented with the other devices used on the TFC boards. More details can be found in [8]. 5.3.3 JTAG Bus Boundary-Scan Testing (industry standard IEEE 1149.1 [22]) was developed in the mid-1980s by the Joint Test Action Group (JTAG) to detect physical faults on PCBs caused by increasingly crowded assemblies due to novel packaging technologies, such as today’s BGA packages. In space-constrained environments, or high-speed designs, it’s not always possible to incorporate test pads that link the PCB to an ATE (Automatic Test Equipment) bed-of-nails interface. Boundaryscan embeds test circuitry at chip level to form a complete board-level test protocol. With boundaryscan is it possible to access even the most complex assemblies for finding and diagnosing hardware problems but also perform In System device Programming (ISP). Figure 23 shows a block diagram of the JTAG components integrated inside boundary-scanable devices. The test logic consists of an instruction register and a controller and is accessed through a Test Access Port (TAP). The boundary scan technique involves the inclusion of a shift-register stage (contained in a boundary-scan register cell) connected to each component pin so that signals at component boundaries can be driven and read using scan testing principles. 29 “Freja”, A.Borga JTAG Instructions: BSR Core logic TDI 1. Extest 2. Bypass 3. Read-ID 4. Private TDO Instruction register TMS TAP controller TCK Figure 23: Internal structure of JTAG boundary-scanable IC. An overview of JTAG building blocks follows: 1. Test Access Port (TAP): it is a general purpose port that provides access to all the test support functions integrated in a boundary-scanable device. Four signals are used to configure and communicate to and from a TAP: a) Test Clock Input (TCK): a clock separate from the system clock. b) Test Data In (TDI): data is shifted into the JTAG-compliant device via TDI. c) Test Data Out (TDO): data shifted out the JTAG-compliant device via TDO. d) Test Mode Select (TMS): TMS commands select test modes as defined in the JTAG specification. IC1 TDI IC2 TDO TDI ICn TDO TDI TDO TMS TCK TDO Figure 24: Configuration of JTAG devices with a serial connection. 2. TAP controller: the TAP controller is a state machine that provides access to the functions built into the JTAG-compliant device. The state machine controls all operations for the JTAG-compliant device. A user can sequence through the state machine functions via the TCK and TMS inputs. 30 “Freja”, A.Borga Figure 25: Configuration of the termination resistors of the JTAG line. 3. Instruction register: instructions used to select the test to be performed or the data register to be accessed are shifted into the design by the instruction register. A number of mandatory operations are defined by JTAG specification but design-specific instruction can be added as well to extend the functionalities of the test logic. The instruction register allows selection of the following compulsory registers and their relative functions: a. Bypass: reduces the BSC shift path through the device to a single bit register. This instruction is used when a direct operation into only some devices of the chain has to be done: bypass allows the user to bypass BSCs inside an IC to pass data directly into another chip. b. Sample/preload: instruction used either to sample the data currently contained in the BSCs, or to preload data into the BSCs. c. Extest: when extest is performed the BSCs attached to the JTAG device input pins act as sensors while the BSCs attached to output pins propagates data to interconnecting devices. The interconnecting devices may or may not be JTAG-compliant. Optional instructions which are very often implemented by chip designers are: d. Usercode/Idcode: instructions used to serially read a code from a target component. Use of the Idcode will provide information on the base component, while use of the Userdcode will provide information on the particular programming of an on-board component (e.g. used to program TFC FPGAs). 4. Test data registers: the test logic architecture contains a minimum of two test data registers. Selection of the register that forms the serial path at a given time is controlled from the instruction register (Figure 26). 31 “Freja”, A.Borga Figure 26: Test data registers. a. The bypass register: provides a single-bit connection through the circuit when none of the other test data register is selected. This register can, for example, be used to allow test data flow through a device without affecting his BSCs. b. The boundary-scan register: this allows testing of board interconnections, detecting typical production defect such as opens, shorts, etc. It also allows access to the inputs and outputs of components when testing their system logic or sampling of signals flowing through the system input and outputs. c. The device identification register: optional test data register used determine for example device’s manufacturer, part number, etc. d. The design-specific test data register: optional registers may be provided to allow access to design-specific test support features. The manufactures of programmable devices use this register to implement the programming interface. This will be discussed in more details in Section 5.5.5 and 5.5.6. 5. Boundary-Scan Register (BSR): each IO pin of an Integrated Circuit (IC) is connected to three cells, each known as Boundary-Scan Cell (BSC), of a shift-register ( 6. Figure 27). The cells link the JTAG circuitry to the IC’s I/O logic. All BSCs of a particular device constitute a Boundary-Scan Register (BSR). BSR logic becomes active when performing JTAG testing, otherwise under normal IC operation it remains passive. si Input Cell Control Cell I/O Output Cell so Figure 27: Structure of a Boundary-Scan Register. 32 “Freja”, A.Borga JTAG on the glue card The JTAG bus of the Glue Card is driven directly via the PCI bus by accessing the JTAG_CON register (Table 12) in the Internal Registers (Table 7). In a read access the first four bits reflects the state of the JTAG bus lines. Transactions on the JTAG bus are performed by writing to the register. The states of the TCK, the TDI and the TMS output lines are set by writing commands to the three two-bit registers that in a write access are associated with the three lines. The set/clear operations are defined in Table 12. JTAG transactions are thus made by putting data on the TMS and the TDI lines and toggle the clock line TCK, and by reading the TDO line. Table 12: Bit assignment in the JTAG control register JTAG_CON (Offset 04h in the Internal Registers). Bits Read Access 0 Read state of TCK line 1 Read state of TMS line 2 Read state of TDI line 3 Read state of TDO line 4 0 5 0 6 0 TMS 7 0 TDI Note 1: Write Access 00 – no action 01 – selective clear TCK bit 10 – selective set TCK bit 11 – no action 00 – no action 01 – selective clear TMS bit 10 – selective set TMS bit 11 – no action 00 – no action 01 – selective clear TDI bit 10 – selective set TDI bit 11 – no action Generate bus sequence (see Note 1) When during write access all bits in the field 5 ... 0 are set to “1”, a four clock sequence is generated with the TMS and the TDI lines set according to bit 6 and 7, respectively. The Glue Card also allows making a full JTAG transaction for every PCI write access by generating a sequence of JTAG levels. The sequence is invoked when the six bits J2C_CON [5...0] are all HIGH. The sequence consists of four clock cycles. At the first cycle the level of the clock line TCK is de-asserted. At the second cycle the levels of the TMS and the TDI lines are set according to the state of bit 6 and 7, respectively, in the JTAG_CON register (Table 12). The TCK is asserted during the third and the fourth cycle, and is finally de-asserted at the end of the fourth cycle. The states of the TMS and the TDI lines remain until they are changed. Holding the TMS line in the high state during more than four clock cycles resets the TAP controller of the remote JTAG interface. After power up the TMS line is set to HIGH by default. 33 “Freja”, A.Borga 5.3.4 Local Bus The Local Bus (L_BUS) on the TFC boards provides a data path for configure, control and monitor data between the PCI Bus and non-PCI devices such as FPGAs, FIFO memories, etc. The implemented local bus functionality is a subset of the PLX 9030 Local Bus. The Glue Card provides a 32-bit multiplexed synchronous bus. At the back-end, the local bus width can be tailored to 8, 16, 24 or 32 bits, always occupying the least significant bits. The Glue Card board acts as a Local Bus Master with a permanent bus ownership. The memory range between address 0040h and FFFFh in BAR2 is designated for the local bus transfers. Table 13: List of the Local Bus signals. Signal Name Type LCLK LRESETn Local Bus Clock Local Bus Reset Out O O LAD [31...0] Address/Data Bus I/O LADSn Address Strobe O LW_Rn LWAITn Write/Read Wait Out O O LRDYn Local Ready Input I LLASTn Burst Last Data O LTERMn Burst Terminate I Function Local bus clock, up to 40 MHz Asserted when the CCPC is reset During the address phase, the bus carries the address of the device on the [15...2] lines. During the data phase the bus carries 32-bit data words Indicates a start of a new bus access and valid address. Asserted during the first clock cycle of the bus transaction LOW for read accesses and HIGH for write accesses Asserted by the master to insert wait states Indicates valid read data on the bus in a read access or that write data is accepted in a write access. The signal is not sampled until LWAITn is de-asserted Asserted by the master to indicate the last data transfer in a bus access Asserted by the slave to terminate a burst access Four types of bus transactions can occur on the Local Bus: • • Read and Write Read and Write Burst A Local Bus transaction is bounded by the assertion of the LADSn (address strobe) at the beginning and by the de-assertion of the LLASTn (last data transfer) or by the de-assertion of LTERMn (terminate) at the end. The access consists of an address cycle followed by one or more data transfers. During each clock cycle of the access, the Local Bus is in one of the four basic states as defined below. A clock cycle consists of one LCLK clock period. Local Bus Clock The Local Bus clock LCLK is generated externally to the Glue Card. All Local Bus signals except for the LRESETn are driven and sampled on the rising edge of the LCLK. With respect to the LCLK, the following time constraints must be observed: Tsetup Thold ≤ 7 ns ≥ 1 ns - setup time - hold time The current version runs at a frequency up to 40 MHz which allows easy attachment of relatively distant devices located on 9U VME motherboards. 34 “Freja”, A.Borga Basic Bus States The four basic states are idle, address, data/wait, and recovery. Upon request from the PCI target, the Local Bus Master starts a bus access by entering the address state while presenting a valid address on the address/data bus and asserting the LADSn for one clock period. Data is subsequently transferred in the data/wait state. The LRDYn is used by the slave to indicate that data is written or that data is available for reading. It may also be used to insert wait states by temporarily de-asserting the signal. The LWAITn may be asserted by the master to suspend the slave, which in this condition should not sample data during a write access and should not update data during a read access. The LLASTn is asserted by the master to indicate the last data transfer of the access. To terminate a burst access the slave may assert the LTERMn signal instead of only de-asserting the LRDYn. The direction of the data transfer is determined by the LW_Rn signal, which is low for a read and high for a write access. The LW_Rn must be kept either asserted or de-asserted during the entire transaction. After the data transfer, the bus enters the recovery state to allow the bus device to recover. The bus then enters the idle state and waits for another access. Write data are accepted by the slave on the rising edge of the LCLK when the LW_Rn is high, the LWAITn is high, and either the LRDYn or the LTERMn is low. The master accepts the read data on the rising edge of the LCLK when the LW_Rn is low, and either the LRDYn or the LTERMn is low. This process repeats until the transaction is terminated either by the master or by the slave. Acknowledgement by the Slave In a bus transaction, the presence of the slave is signalled to the master by a low level on the LRDYn line or the LTERMn line. When multiple slaves are attached to the local bus, the device selection is based on internal decoding of the address lines by all slaves. Only one slave at a time may drive the LRDYn and the LTERMn. Consequently the slaves which are not selected must drive the LRDYn line in a tri-state. The same rule applies to the LTERMn. Internal on-board pull-up resistors have been implemented on these two lines on the Glue Card. When no slave responds in a predefined period of time with either the LRDYn or the LTERMn asserted, the PCI interface completes the transaction with either a TARGET ABORT or with a valid dummy cycle. The method depends on the configuration of the TMO_ABORT bit in the CSR (see Table 8). In the case of a dummy cycle nothing happens in a write access and a read access returns all zeros. Examples of Local Bus Timing Figure 28 shows an example of two Local Bus transactions. The first transaction is a burst read access of four words with one wait state inserted by the master and one data phase delayed by the slave. The transaction is terminated by the master. The second transaction is a single write access which is also terminated by the master. Figure 29 shows a burst write access of four words which is terminated by the slave. The second transaction is single word read access where the master attempts a burst read but the slave forces a single cycle by terminating the transaction. 35 “Freja”, A.Borga LCLK LADS# LW/R# LAD LWAIT# LLAST# LRDY# LTERM# address phase address phase 4 data words from slave single data word to slave Figure 28: Timing diagram showing an example of a burst read and a single write transaction. LCLK LADS# LW/R# LAD LWAIT# LLAST# LRDY# LTERM# address phase address phase 4 data words to slave 1 data word from slave Figure 29: Timing diagram showing an example of a burst write and a single read. 36 “Freja”, A.Borga 5.4 General purpose Input/Outputs 5.4.1 Introduction New signaling technologies for cable transmission and critical on board paths were introduced to avoid the bottle neck represented by the TTL and CMOS technology used in all IC devices capable of computing power. Current state-of-the art TTL and CMOS logic families have attained performance levels which require controlled impedance interconnect for even relatively short distances between source and load. As a result system designers who are using state-of-the-art TTL or CMOS logic are already forced to deal with special requirements of high speed logic. In addition the large output swings and relatively fast output slew rate of today’s high performance CMOS/TTL devices increases the problems of cross talk and EMI radiation. This problem, along with common mode noise and signal amplitude losses, can be alleviated to a great degree with the use of differential signalling. Even though conversion devices are required (which slightly increases the board costs for example) the gain in terms of throughput, signal quality at the receiver side and reachable distances is incomparable. Board design is simplified as well since termination techniques are easy to implement and well described by every standard definition. With this idea in mind differential signaling technology was implemented on all the TFC boards to provide a safe communication path both on board and on cable connections. 5.4.2 LVDS technology Low Voltage Differential Signaling (LVDS) is a communication technique introduced by National Semiconductor [23] with the aim to transmit data using a very low voltage swing (about 350mV) over a differential transmission line (both PCB traces and balanced cables). The advantage of the differential approach is that the noise is coupled onto the two wires as common mode (appears on both lines equally) and is thus rejected by the receivers which looks at only the difference between the two signals. The differential signals also tend to radiate less noise than single-ended signals due to the cancelling of magnetic fields. It is the fact that differential technologies, such as LVDS, have less noise which allows operating with lower signal voltage swing. The low swing nature of the driver means data can be switched very quickly (bit rates up to hundreds of Mbps). Figure 30: Simplified diagram of LVDS driver and receiver connection. 37 “Freja”, A.Borga National’s LVDS outputs consist of a current source (nominal 3.5 mA) which drives one of the differential pair lines. The receiver has high DC impedance (it doesn’t source or sink DC current), so the majority of the driver current flows across the 100 Ohm termination resistor (that represents a very easy termination technique) generating about 350 mV across the receiver inputs. Different topologies are available to configure LVDS devices. The TFC boards equipped with LVDS usually use point to point configurations. Special cases is represented by the LVDS I/O ports of the test board in which a bi-directional half-duplex configuration is used with LVDS transceiver chips in order to save I/O pins on the FPGA. Figure 31, Figure 32 and Figure 33 show the different configurations: Figure 31: LVDS point-to-point configuration. Figure 32: LVDS multidrop configuration. Figure 33: LVDS bi-directional half-duplex configuration. LVDS represents the most suitable solution for the TFC high speed data transmission (40 MHz) over quite long distances (2 to 10 meters). Due to its extreme simplicity, reliability and high-end performance in terms of power consumption and speed, LVDS is getting more and more a good candidate for all kinds of future applications. 38 “Freja”, A.Borga 5.4.3 ECL technology Emitter Coupled Logic (ECL) in all its variations Positive (PECL), Negative (NECL) or Low Voltage (LVECL) is another largely used differential transmission technology [24, AN1672/D]. While LVDS adopts a common solution for line termination, ECL offers the opportunity to choose between several different solutions. A standard ECL output driver typically uses a current switching differential with an emitter follower for level shifting the output. For a proper static and dynamic emitter operation, the emitter follower must remain in the active region of operation, which means that an external resistive path should be provided from the output pin voltage, operating at a level more negative than the worst case VOL, such as VEE. The resistor terminations can be considered a DC termination of the Emitter Follower output structure. Terminations are used to match the characteristic line impedance to prevent reflections, jitter and skew over long lines. ⎛ R2 ⎞ ⎟⎟ VTT = VCC − 2.0V = VCC ⎜⎜ R R + 2 ⎠ ⎝ 1 Figure 34: Thevenin termination for ECL lines and VTT computation formula. For all the TFC differential and single ended lines driven by ECL logic the terminations implemented are of the Thevenin Equivalent (or parallel termination) type [24, AND8020/D]. Two reasons led to this choice: easy and precise calculation of the partition ratio to adjust the receiver input voltage, elegant design implementation by using resistor termination networks (specific designs for ECL logic are nowadays available on the market). The VTT supply is used to sustain the emitter follower output transistor in its active operating region under all operating conditions. A minimum continuous current occurs for the most negative VOL, therefore the VTT supply must remain more negative than the worst case VOLmin and always sink current (Figure 35). While a Thevenin Parallel technique dissipates more termination power, it does not require an additional external VTT supply. This additional power is consumed entirely in the external resistor divider network and thus will not change the current being sourced by the device, hence it does not alter the IC reliability of lifetime. Figure 35: State levels of VOH and VOL. 39 “Freja”, A.Borga The Thevenin equivalent of the two resistors needs to be equal to the characteristic impedance of the signal transmission line. ⎛ V − VEE ⎞ ⎟⎟ R2 = Z 0 ⎜⎜ CC − V V TT ⎠ ⎝ CC ⎛ V − VTT ⎞ ⎟⎟ R1 = R2 ⎜⎜ CC − V V EE ⎠ ⎝ TT PECL LVPECL ⎛5−0⎞ R2 = 50⎜ ⎟ = 125Ω ⎝5−3⎠ ⎛5−3⎞ R1 = 125⎜ ⎟ = 83.3Ω ⎝3−0⎠ ⎛ 3.3 − 0 ⎞ R2 = 50⎜ ⎟ = 82.5Ω ⎝ 3.3 − 1.3 ⎠ ⎛ 3.3 − 1.3 ⎞ R1 = 82.5⎜ ⎟ = 126Ω ⎝ 1.3 − 0 ⎠ The theoretical values don’t match any real value. As a sufficiently well approximated value R1=81Ω and R2=130Ω were chosen using BURNS 803 Series ECL Termination Networks. To provide DC insulation to some receivers, capacitive coupling (Figure 36) has been also implemented and tested in different solutions [24, AND8020/D]. AC signal have the line DC blocked and requires then a DC restoration voltage which can be provided using the VBB pin integrated in most of the actual ECL devices (Figure 37). Figure 36: Single ended configuration with 96Ω cable matching and DC blocking capacitor. Figure 37: Single ended configuration with DC level recovery using VBB. A precise evaluation of the terminations is extremely important to ensure a good signal transmission (as experienced during tests, without termination transmitter devices will not even work!). None of the chips used in this project use on-chip integrated terminations; for that reason termination are always implemented on-board. 5.4.4 I/O interface technologies on the test board ECL and LVDS technologies were chosen to allow full access to all the functionalities of the TFC boards during test routines. ECL is used to handle the TTC network and the TFC switch via the TTCrs. Six additional ECL lines, organized in three transmitters and receivers, are used for general tests. LVDS is instead used to connect Freja to both the L0 and L1 trigger path of the Readout Supervisor and to send and receive throttles from the throttle switch. In total 34 bi-directional LVDS lines have been implemented for this purpose. 40 “Freja”, A.Borga 5.5 Control logic: Altera APEX FPGA 5.5.1 Introduction As introduced in the previous section (Section 5.1), the core part of the logic of the test board, is the FPGA. This is of great interest because of the importance gained by these devices in the last years. The whole idea of the board was developed around the implementation of such a device: the use of an FPGA allows the users to build a tool which is a very good compromise between high performances in terms of speed and computing power (which best is achieved using specific hardware designs) and extreme flexibility. It must be remarked that: • • • All the electronics on the test board is organized around this chip. All the control and monitoring is done via the FPGA. Most of the configurations are dedicated to setup the functionalities of this device. The advent of FPGAs caused a slow revolution in the way in which hardware is developed. In the past board designers were constantly struggling to solve complicated Boolean functions and trying to fit impossible numbers of chips on a board with few chances to repair and reconfigure the boards in case of bugs, malfunctions or design upgrades. Using FPGAs these days are over. Compactness and flexibility are the common denominators of all programmable devices. The design starts from the choice of the programmable device itself: according to the number of I/Os needed, the size of the code to run in the chip, etc. Most of the planning phase can be done via software with compilers, synthesizers, simulators, etc; saving time and resources. If money is not a crucial issue, an over sized chip (“fat and fast” compared to the code size and the speed requirement predicted) will ensure a good safety margin even for future improvements. If, on the other hand, money represents a design limitation (as is often the case) code software simulation during the planning phase will assure a precise choice of the chip to invest in. 5.5.2 The evolution of FPGAs Before the advent of programmable logic, custom logic circuits were built at the board level using standard components, or at the gate level in expensive Application-Specific Integrated Circuits (ASIC). A Field Programmable Gate Array (FPGA) is an integrated circuit that contains many identical logic cells that can be viewed as standard components. Each logic cell can independently take single customized functions using a small set of primitives (building blocks) such as Look-Up Tables (LUT), logic gates (AND, OR, etc.), flip-flops, etc. The logic cell architecture varies between different device families. Generally speaking, each logic cell combines a few binary inputs (typically between 3 and 10) to one or two outputs according to a Boolean logic function specified in the user program. In most families, the user also has the option of registering the combinatorial output of the cell, so that clocked logic can be easily implemented. The cell's combinatorial logic may be physically implemented as a small look-up table memory (LUT) or as a set of multiplexers and gates. LUT devices tend to be a bit more flexible and provide more inputs per cell than multiplexer cells at the expense of propagation delay. 41 “Freja”, A.Borga The individual cells are interconnected by a matrix of wires and programmable switches. A user's design is implemented by specifying the simple logic function for each cell and selectively closing the switches in the interconnect matrix. The array of logic cells and interconnects form a fabric of basic building blocks for logic circuits. Complex designs are created by combining these basic blocks. It’s immediately clear how one of the points of strength of an FPGA is the fact that it allows users to implement complex functions in an integrated circuit by simply programming it directly on the field after manufacture. This concept is summarized in the expression “Field Programmable”. Depending on the particular device, the program is either 'burned' in permanently or semipermanently as part of a board assembly process, or is loaded from an external memory each time the device is powered up, or it can be part of an In System Programming sequence. FPGA capacities have been growing year after year and modern devices can provide something like two million gates in a single chip. This is about the level of complexity of the first Intel Pentium microprocessors! When originally introduced FPGAs only had a handful of gates and designs were specified as logic equations connecting them up. Nowadays they are programmed in high level Hardware Description Languages (HDLs) such as VHDL, which superficially resembles high level programming languages such as C. On the other edge of modern programmable devices CPLDs (Complex Programmable Logic Devices) can be found, with their PAL-derived, easy-to-understand AND-OR structure, offering single-chip solutions with fast pin-to-pin delays, even for wide input functions. Once programmed, the design is stored in non volatile memories and thus made secure. The limited complexity (<500 flip-flops) makes CPLDs the best choice, for example, for “glue logic" functions. In older families, the high static (idle) power consumption prohibits their use in battery-operated equipment. Modern CPLD chips such as CoolRunner [26] devices are nowadays a notable exception, as they offer the lowest static power consumption (less than 50 µA) of any programmable device. FPGAs offer much higher complexity and their idle power consumption is reasonably low, although it is sharply increasing in the newest families. Since the configuration bit stream must be reloaded every time power is re-applied, design security is an issue, but the advantages and opportunities of dynamic reconfiguration, even in the end-user system, are an important advantage. FPGAs offer more logic flexibility and more sophisticated system features than CPLDs: clock management, on-chip RAM, DSP functions, (multipliers), and even on-chip microprocessors and Multi-Gigabit Transceivers. Briefly summarizing: CPLDs has still a good future employment, especially with technologies like CoolRunner devices, for small designs, where "instant-on", fast and wide decoding, ultra-low idle power consumption, and design security are important (e.g., in batteryoperated equipment); while the use of FPGAs will grow in larger and more complex designs. 5.5.3 Choice of the FPGA for Freja The TFC project was started in 2000 by a small group of people. At that time the idea of using FPGAs as the base line device of the main board (the Readout Supervisor) still required feasibility tests. In the past this type of system was typically implemented using discrete logic due to the tight timing constraints. A few pre-studies were done on the Readout Supervisor on using older families of programmable devices like Altera’s MAX and Flex chips. The tests showed sufficient performance but since these chips are small in terms of number of gates, it was decided to go to a new family to reduce the number of chips. The final choice fell on the recently added Apex 20K family, which had many more gates and speeds comparable to the MAX and Flex chips. Thus, since this family was already used in the TFC project, the choice of the chip for the test board was then quite natural. 42 “Freja”, A.Borga 5.5.4 APEX 20K Family The APEX 20K devices [30] incorporate in one chip innovative features such LUT-based logic and integrated memory. Signal interconnections within APEX 20K devices (as well as to and from pins) are proved by the FrastTrack Interconnect: a series of fast, continuous row and column channels that runs the entire length and width of the device (Figure 38). Each I/O pins is fed by an I/O Element (IOE) located at the end of each row and column of the FastTrack Interconnect; each IOE contains a bi-directional I/O buffer and a register that can be used as either an input or output register to feed input, output, or bi-directional signals. IOE provide a variety of features such as JTAG boundary-scan support and tri-state buffers. APEX 20KE series (used in the design of the test board) offer enhanced I/O support including LVCMOS, LVTTL, LVPECL and LVDS [31]. Figure 38: APEX 20K device block diagram. A variety of memory functions can be implemented in the chip: CAM, RAM, dual-port RAM, ROM and FIFO. Embedding the memory directly into the die improves performance in terms of read and write access speed. APEX 20K devices provide two dedicated clock pins and four dedicated input outputs pins that drive control inputs. These signals ensure efficient distribution of high-speed, low-skew control signals. These signals use dedicated routing channels to provide short delays and low skews. Four of the dedicated inputs drive four global signals; these signals can also be driven by internal logic. The dedicated clock pins featured on the APEX 20K devices can also feed logic. “X”-devices also integrate two Phase Locked Loops (PLL) for operations on clock signals. APEX 20KE devices provide two additional dedicated clock pins. 5.5.5 FPGA programming Several different programming modes are implemented: 1. Configuration EEPROM: an EPC2 stores a basic configuration code to program the FPGA in order to make the power up sequence faster. 2. JTAG standard programming: a JTAG bus from the glue card to the FPGA allows its configuration directly via the ECS interface. 43 “Freja”, A.Borga 3. GPIO programming lines: JTAG over GPIO is used to reprogram the configuration EEPROM via the ECS. Figure 39: Diagram of the different programming options. 4. Programming header: a connector on board allows users to reprogram the EPC2 directly via PC using a Byte Blaster Cable provided by Altera. In normal condition this method is not used (the header can’t be accessed comfortably if the board sits in the crate) it is so far disabled by default to prevent also wrong behave on the bus. If intent to use, this option has to be enabled manually via a jumper. 5.5.6 STAPL language for In System Programming The Standard Test And Programming Language (STAPL) is a JEDEC standard [32] designed to support the programming of programmable devices and testing of electronic systems via JATG. Figure 40: Flow of STAPL Composer and Player. The use of this standard is highly recommended in In System Programming (ISP) designs [33], such as in the TFC system, where embedded programming devices are used to program other logic on board. STAPL support the programming of any JTAG compliant programmable device. STAPL is based on a STAPL file which is a sequence of program statements. The STAPL file contains the programming data and the programming algorithm. A single STAPL file may perform several different functions, such as programming, verifying and erasing programmable devices. STAPL file makes these different high-level functions available through ACTION statements that correspond to user controls in an interactive system. 44 “Freja”, A.Borga The STAPL Composer and the STAPL Player are software programs that write and interpret STAPL files (Figure 40). Using STAPL for Altera devices, a STAPL Composer (writer) is integrated in the manufacturer software (Quartus II 4.0 described in Section 7.1.2) replacing the original Jam Language. The STAPL composer generates the STAPL files in accordance to its standard specifications. The STAPL Player is the interpreter that reads and executes STAPL files. STAPL may be implemented as either an interpreted or a compiled language. In an interpreted implementation, the STAPL file statements are executed directly without first compiling these statements into binary executable code. In a compiled implementation, the STAPL file statements are first pre-processed and then executed. In the TFC board a STAPL player is integrated in the CCPC which executes binary code STAPL files compiled with Quartus II 4.0. When a STAPL player executes a STAPL file, only one ACTION will be executed. Because a STAPL file may contain multiple ACTION statements, execution of a STAPL file begins by searching the STAPL file for the ACTION statement whose name matches the one specified by the user. Execution continues with calls to the list of PROCEDURE blocks listed in the ACTION statement. Execution terminates either when the end of the ACTION statement is reached or when an EXIT statement is processed. The flow of execution within each of the called PROCEDURE block is controlled using three methods: • • • Branches: a GOTO statement is used to jump into the file. Using IF statements in combination with GOTO to create conditional branches. The branching technique improves the programming times. Calls: the CALL statement causes the execution to jump to a PROCEDURE and the location of the CALL statement is saved in a stack. An IF statement can be used with the CALL to call a subroutine conditionally. FOR loops: the FOR statement is used for iteration. Combined with compressed byte code this feature ensures very small files, which suit the requirement of programming memory constrained designs. 45 “Freja”, A.Borga 46 “Freja”, A.Borga 6 PCB DESIGN 6.1 Introduction PCB (Printed Circuit Board) design is a very delicate part of the process to realize a board. Years of developments in all fields of production (board design, manufacturing, mounting and testing) led the technology to extreme edges: boards manufactured at CERN can reach 16 layers, 100µm nets and clearance, 300µm vias and other impressive specification and tolerances. 9U VME standard boards [34] are used for all the TFC sub-parts almost exclusively SMD (Surface Mount Devices) ICs are implemented in designs using the latest SMD packages (like TQFP, SSOP, TSSOP, etc) avoiding the use of more delicate packages such as Ball Grid Arrays (BGA). The fact that the I/O needs on the TFC boards permitted the use of Quad Flat Packs (QFP) also render routing and hardware debugging easier. Still, even SMD components mounting needs to follow a precise and specific procedure, special tools (automatic placing machines, reflow ovens) to guarantee proper contact and fixation with high precision between pads and pins. Some sub-parts are implemented as mezzanines, like for example the Glue Card or the TTC modules. The main advantage of using this kind of solution is that a mezzanine can be easily replaced by new corrected or improved versions. The disadvantage is that signals pass through connectors which can impair high speed signals and induce noise. All the TFC board are designed using Protel 99SE and its updated version DXP. Protel is a complete CAD tool that allows the user to fully manage the design from the schematic drawings to the gerber files, passing trough board routing (both manual and automatic), creation of libraries for custom footprints, schematics components, etc. 6.2 Board schematics In APPENDIX A - Board Schematics the board schematics are shown. As a general aim the same type of components are used on the different TFC boards to the maximum extent possible. The goal using similar or common solutions is to reduce the probability of mistake during the design phase. Using well known devices eases the implementation, allows the use of common design “tips and tricks” as well as common hardware debugging techniques. All the components used in the TFC project are kept in a specific TFC Protel library. Figure 41: Screen shot of the working enviroment of Protel DXP. 47 “Freja”, A.Borga 6.3 Front panel view TTCrs mezzanine: 1. Bunch clock input 2. Bunch clock output 1 3. Bunch clock output 2 4. TTC channel A+B output 5. TTC channel A output 6. TTC channel B output Board external clock input ECL transmitter* (dual lemo connector): TX3 - TX4 TX1 - TX2 *seen from the front, lower value is on the left ECL receiver* (dual lemo connector): RX1 - RX2 RX3 - RX4 *seen from the front, lower value is on the left Optical TRANSMITTER Optical RECEIVER Front panel support LVDS transceivers*: 1. Connector 1 (3M 17 pair connector): Pair 16: Ground Pairs 0 to 15: Signals 2. Connector 2 (3M 17 pair connector): Pair 16: Ground Pairs 0 to 15: Signals 3. Connector 3 (RJ9): Pairs 0 to 15: Signals The LVDS lines are driven by 4 transceiver chips (DS92LV090A) with 9 channels each. *seen from the front, negative pin is on the left Credit Card PC reset push button Credit Card PC Ethernet RJ45 connector TTCrx optical input bulk adapter 48 TTCrs Monitoring LEDs (top to bottom): 1. Power: GREEN when board is on Power monitoring: blinking RED when voltage is out of range (4.7÷5.3 V) 2. TTCrx clock is present and PLL is locked goes GREEN 3. General purpose RED LED from FPGA 4. General purpose GREEN LED form FPGA 5. Configuration GEEN LED when FPGA is programmed “Freja”, A.Borga 6.4 Board layer configuration A carefully studied layer configuration prevents noise injection into signals due to power planes and provides EMI shielding, ground coupling and even a better mechanical rigidity. The first studies on the board structure were done with 6 layers. However, in order to separate routing and power planes to avoid noise injection on the signal nets due to regulators and dc/dc converters, it was decided to use an 8 layers board with two uniform ground plains separating Figure 42: Layer stack manager (Protel DXP screen shot). 3.3V and 5V planes from the others (Figure 42). The 5V supply is provided directly from the crate back plane which means that there is no particular attention to pay for what concerns the 5V current consumption. On the other hand 3.3V is supplied by voltage regulators on board. Thus it’s important to compute carefully the 3.3V overall consumption to avoid overloading and overheating the regulators. The FPGA with its PLLs requires a very clean and stable voltage. It is therefore important to use separate regulators for this device. Two supply planes, 3.3V for IO and 1.8V core logic, have been implemented through cut-outs on the power planes (Figure 43 and Figure 44). Figure 43: Internal 5 V power plane Figure 44: Internal 3.3 V power plane (Protel DXP screen shot). (Protel DXP screen shot). High speed differential lines, like LVDS, need particular attention during the routing stage to avoid crosstalk and to optimize ground coupling. The design rules as defined by the chip manufacturer include the distance between the nets and the ground plane and the type of dielectric in between (Figure 45). 49 “Freja”, A.Borga • • • • • S < 2W S<h x ≥ 2S (distance between pairs) x ≥ 2W x >> 2S (between different voltage supplied pairs) Figure 45: Rules for the calculation of line thickness and clearance. The Microstrip solution is adopted for all the differential lines since they are routed on the top layer of the board. A polygon ground plane has been added underneath to adjust the ground coupling. The dielectric constant is specified (Table 14) by the CERN manufacture atelier (εr=4.4 ÷ 4.8). The tolerance is due to the fact that the thickness of the glue between the two layers can’t be controlled to a precision higher than 185±85µm. Table 14: board specifications given by the CERN PCB work shop. Layer Signal layers Thickness core 200 µm glue 185 ± 85 µm core 500 µm glue 2 x 185 µm core 500 µm glue 185 ± 85 µm core 200 µm Power layers As seen before, the terminations on the ECL differential lines are essential for them to work. The use of SMD resistor such as the 1206 packages for that purpose can sometimes represent a problem. Even the smallest packages occupy a considerable amount of space considering that the differential line distance must be kept constant and that the line length should be short. Vias also introduce noise and length differences between the pairs so it’s not recommended either to put termination resistors on the other face of the board. For those reasons Single In Package (SIP) Thevenin termination networks were chosen and implemented in the design. 6.5 Routing tips and techniques Once the layer stack is defined, the next step is the effective placing and routing of the components. First thing to decide is the dimension of the board which is directly related to the front panel size. Since the test board has many IO ports, a 9U was needed. This was also the natural choice since all TFC boards are based on 9U. As mentioned before the FPGA is the central device. Thus it is important to keep it in a central position on the board and surround it with all the other devices paying attention to routing direction and the most delicate nets (like clock lines). Placement of components on the bottom layer is limited by the tight height limit (less than 1 mm). It’s recommended just to place very thin components on the bottom (0805, 1206, 0603 or SOT only). The routing was done completely manually using the DRC to check clearance and other design specifications and rules. 50 “Freja”, A.Borga Figure 46: Picture of Freja Version 1. Figure 47: Picture of Freja Version 2. 51 “Freja”, A.Borga 52 “Freja”, A.Borga 7 VHDL PROGRAMMING 7.1 Introduction to VHDL VHDL stands for VHSIC (Very High Speed Integrated Circuit) Hardware Description Language. Beside the complicated acronym VHDL is a language to describe the structure and behaviour of digital electronic in hardware design (Figure 48). Figure 48: VHDL integration into hardware design flow. VHDL for analog electronics is not very well developed, although, because of the language flexibility it has been stretched to handle analog and switch level simulation in limited cases. VHDL can be used to describe digital electronics hardware at many different levels of abstraction (Figure 49). When considering the application of VHDL to ASIC or FPGA design it’s important to understand the three levels of abstraction listed below: 1. Algorithm: a pure algorithm consists of a set of instructions that are executed in sequence to perform some task. A pure algorithm has neither a clock nor detailed delays. Some aspects of timing can be extracted from partial ordering of operations within the algorithm. 2. RTL (Register Transfer Level): this description has an explicit clock. All operations have been scheduled to occur in specific clock cycles, but there are no detailed delays below the cycle level. 3. Gate: a gate level description consists of a network of gates and registers instanced from a technology library, which contains technology-specific delay Figure 49: VHDL level of abstraction schema. information for each gate. 53 “Freja”, A.Borga VHDL is a high level programming language completely specified in two Language Reference Manuals (IEEE 1076 [36] and IEEE 1164). The first defines the language while the second specifies standard data types in order to describe logical components and other crucial aspects. Being a standard set apart VHDL from other hardware description languages, which are to some extent defined in an ad hoc way by the specificity of the tools that use them (like for example the AHDL language by Altera). 7.1.1 Language basic elements Like any high level programming language, VHDL allows to split an algorithm in several small pieces to make the problem easier. The outer most block is the entity which represents a block of hardware with well defined inputs and outputs and a well defined function. The main entity in the case of the TFC test board is the whole FPGA but it can also be a PCB, an ASIC, a microprocessor and so on. A design entity is split in two parts: • • The entity declaration which represents the external interface of the design entity. The architecture body which represents the internal description of the design entity (behaviour, structure or both). Inside the architecture body, signals for both internal and external use, are used to connect components: a component (self designed or picked up from libraries) can be “plugged” in a design by making three operations: • • • Declaration: is the operation that declares a component, whose function is defined elsewhere, inside an architecture. Instantiation: is a local copy of the corresponding design entity to make use of a component; in other terms making an instantiation is like plugging a chip in a board socket. Port mapping: links the ports of the component to the signals of the logic in which it is instantiated. In other words, a port map makes an electrical connection between “pieces of wire” (signals) in an architecture and pins on a component (ports). The same signal may be associated with several ports. Figure 50: VHDL allows splitting a problem in several sub-problems in a nested manner. 54 “Freja”, A.Borga 7.1.2 RTL-to-gate process Once the VHDL code is written, the next sequence of steps transform the algorithm in an optimized way into an implementation which is based on the primitive gates of the FPGA which has been selected. Figure 51: VHDL code synthesis flow. The first step is to compile the VHDL source code with a logic synthesis tool that makes the optimization of the implemented functions (state machines, memories, etc) at a high-level, such as Synplify (Figure 51). In a project all the piece of code written are linked. By selecting a clock signal the program will make a first attempt to satisfy the timing constrains. Selecting the FPGA used a rough approximation of the inside chip occupation will be done. Synplify for example uses a proprietary Behaviour Extracting Synthesis Technology (B.E.S.T.) which converts the HDL into small, high-performance, design netlists that are optimized for popular technology vendors. With the new Altera FPGAs, VQM (Verilog Quartus Mapping) as output files should be used to transfer the RTL file to the placer and router: this standard was developed by Synplicity together with Altera in order to make the first steps of compilation more efficient. For the latest families like Apex, Cyclone and Stratix, Altera suggests to only use this format to produce synthesis files. Optionally, the software can write post-synthesis VHDL and Verilog netlists that can be used to verify functionalities through simulation. Once the synthesis is done the phase of placing and routing starts: since the internal gate structure is known just by the manufacturer, placing and routing has to be done using proprietary software. Altera Quartus II 4.0 is used for all TFC boards (Figure 53). Since the FPGA dimension (in terms of gates) were well defined during the design phase and the timing delays after a few test were considered fine, there was no need to go into the details of the placing. It is important to keep in mind that with Quartus it’s possible to manually place and route the logic inside the chip. Once the code is placed and routed the last part of the job consists in creating the file that will be loaded in the chip. Quartus can produce several types of output files. STAPL (Standard Test and Programming Language) the high level language described in Section 5.5.5 is used in the TFC system for In System Programming (ISP). 55 “Freja”, A.Borga Clock frequency VHDL project scripts FPGA type LOG window Figure 52: A screen shot of the Synthesis tool, Synplify. Figure 53: A screen shot of the placer and router, Quartus II 4.0. 56 “Freja”, A.Borga 7.2 VHDL code for TFC test board In the next sections the code written for the FPGA in the test board is described in details. In summary three applications were developed: 1. Self-test code [Section 7.2.1]: small test routines to debug the hardware of the test board. 2. Feasibility test code [Section 7.2.2]: to test the capabilities of modern test FPGAs some feasibility test code has been written. 3. TFC system testing code [Section 7.2.3]: code written to accomplish the main task of the board. For the time being the code is sufficiently developed. Future improvement on the TFC board might require code expansions. 7.2.1 Board debug: SELF-TESTS In order to discover and fix bugs efficiently it’s important to approach the board with a good debugging scheme. Simple code was written to self-test all the different hardware functions of the board. Hereafter is listed the strategy used for Freja: 1. ECS interface test: starting from the access to the credit card PC via Ethernet up to the Glue Card via PCI. 2. Peripherals connected directly to the ECS interface: debug of all the buses (I2C, JTAG, Local BUS) using low level C routines to read and write hardware registers. 3. Clock distribution to on board devices. Measurements of signal quality and propagation with oscilloscope. 4. Input/output interfaces (ECL and LVDS) debugging both with lab instruments and driving them from the FPGA using dedicated code. 7.2.2 Alternative TFC switch implementation TTC rs ECL Freja as a TFC switch TTC rx Readout Supervisor TTC rx ECL optical TTC tx fan out optical Figure 54: A diagram of the configuration for the TFC switch emulation test. As widely underlined in the previous chapters the use of FPGA in electronics boards is increasing rapidly. New families of devices are more and more fast and reliable from the point of view of timing (propagation delay, skew, jitters, etc). The TFC Switch is currently implemented in fast discrete logic based on ECL in order to satisfy the strict requirements on the timing characteristics of the switch. The application requires that the skew between any combinations of inputs-outputs is no more than 50 ps. In addition, the TFC Switch must not introduce more jitter than 50ps. However, for several reasons it would be advantageous to implement the TFC Switch function in an FPGA. It would allow building easily a bigger switch than 16x16, it would simplify the implementation and reduce significantly the power consumption. 57 “Freja”, A.Borga A feasibility test was done using the FPGA on the test board (Figure 54): a small piece of code was written in order to implement the functionalities of the TFC switch. Four 4:1 multiplexers provide the full combinational logic of a 4x4 switch to make the test. The results of the measurements revealed rather astonishingly that with the actual technology available it is possible to build an equivalent of the TFC switch using programmable devices only. However, it would probably demand some manual placing and routing of the logic in the FPGA to minimize the differences in propagation delay. The information gathered by this experience will be kept in mind for a future upgrade of the board, in particular if the partitioning has to be improved such that the switch must support 32 destinations. 7.2.3 TFC full system testing Detector L0 decision unit VELO ST OT RIC H ECAL HCAL MUON L0 FE L0 FE L0 FE L0 FE L0 FE L0 FE L0 FE L1 FE L1 FE L1 FE L1 FE L1 FE L1 FE L1 FE Emulated blocks TFC SYSTEM SWITCH SWITCH L1 L1 SORTER SWITCH SWITCH READOUT NETWORK SFC SFC SFC SFC SFC Front end electronics Event building L0 LHC CLK L1 Front-End L0 TRIGGER SFC SWITCH SWITCH SWITCH SWITCH SWITCH SWITCH C C C C C C C C P P P P P P P P U U UU U UUU L1 decision unit C C C C P P P P U UU U C C C C P P P P U UUU C C C C P P P P U UUU CC C C PP P P UUUU CPU farm Figure 55: Emulated modules of the LHCb readout system. In Section 3.1 an overview of the LHCb readout system has been given. In order to test the full TFC system the test board needs to emulate three different LHCb sub-parts (Figure 55): 58 “Freja”, A.Borga 1. L0 Decision Unit: in order to test the L0 trigger path, the test board should generate L0 triggers by emulating the L0 Decision Unit. The L0 Decision Unit emulator in Freja includes a random trigger and a periodic trigger generator. It also has the Bunch ID counter which produces the 12 bit trigger ID used to check the synchronization of the trigger in the Readout Supervisor. Freja transmits the trigger words to the Readout Supervisor via LVDS lines (L0 trigger path). Figure 56: Block diagram of emulated L0 DU. 2. L1 Decision Unit: in order to test the L1 path in the TFC system, Freja should also emulate the function of the part of the computer farm responsible for L1 decision taking. The “L1 Decision Unit” is directly interfaced with the L0 Decision Unit emulation in order to produce L1 decisions for every L0 triggers accept. The unit incorporates a random and a periodic trigger generator. The L1 Decision Unit also has an Event ID counter (12 bits) in order to transmit the L1 trigger Figure 57: Block diagram of emulated L1 DU. ID which allows the Readout Supervisor to check the trigger synchronization. In order to emulate properly the timing and the operations, L1 Decision Unit is controlled by a state machine. Two bits of L0 bunch ID are received for each L0 trigger accept from the L0 Decision Unit. The decision words are transmitted to the Readout Supervisor via the optional LVDS interface on the Readout Supervisor (L1 trigger path). 3. L0 and L1 Front End electronics: In order to check the operation of the full TFC system, Freja should also emulate the L0 and the L1 Front End electronics. The Front End electronics store the event data temporarily while the decisions are taken, and reject event data according to the trigger decisions. Thus the contents of the Front End buffers at different stages are a function of the trigger decisions and the operation of the TFC system. By emulating the Front End electronics in addition to the trigger decision units, Freja can verify the correct functioning of the TFC system. The front end emulation generates Event IDs and Bunch IDs in the place of event data. The IDs are derandomized, buffered and selected by the trigger decisions exactly like in the standard front end up to the L1 buffer. 59 “Freja”, A.Borga The IDs are readout from the L1 buffer at every L1 decision sent from the Readout Supervisor and compared with the 2 bit of L1 Event ID transmitted with the L1 decision for error checking. In total the Front End emulator consists of an Event ID (2 bits) and a Bunch ID (12 bits) counter, a 160 deep pipeline, a 16 deep derandomizer and output links to the external FIFO acting as a L1 buffer. Figure 58: Block diagram of emulated FE EL. Each sub-module has fine tuning settings and delay lines for time alignment to ensure a precise synchronization and a correct emulation of the real system. The code is organized in several files to increase readability and modularity. A scheme of the structure follows (Figure 59): Figure 59: VHDL code structure of Freja. A top architecture (FREJA) incorporates the module which is responsible for handling the bus between the FPGA and the ECS interface, the local bus slave (lbus_slave). The top architecture also instantiate the different sub-parts (L0_DU, L1_DU and FE_EL) and a counter module (FREJA_counters) in which most of the system’s general counters are located. A few special counters are placed directly inside the modules for convenience. Two more modules are implemented for testing purposes: a channel B long and short broadcast decoder and an orbit signal generator (ODIN_orbit). The purpose of these modules is the monitoring of the TTC system. 60 “Freja”, A.Borga During the first testing phase it was discovered that some of the optical devices were affected by jitter and skew under heavy load conditions. These test sequences provides the tools to monitor permanently the optical system. Due to the extreme modularity of the VHDL language the structure can be easily modified, reorganized, upgraded or stripped for future application. Single purpose modules (like the orbit generator for example) can be cut and paste in and from another codes with sufficient simplicity. The list below gives an idea of the structure from a different point of view: 1. 2. 3. 4. 5. 6. 7. 8. 7.3 FREJA [FREJA.vhd] Local bus Orbit generator [lbus_slave.vhd] [ODIN_orbit.vhd] [One_shot.vhd] [Edge_detect.vhd] [L0_du.vhd] [triggen.vhd] [Edge_detect.vhd] [count_12.vhd] [l0acc_count.vhd] [ODIN_rnd_generator.vhd] [ODIN_rnd_cell.vhd] [fifo16k4.vhd] L1 Decision Unit a. Latency counter b. Read out counter c. L1 periodic trigger generator d. Event ID counter e. L1 accept counter Front End Electronics a. Bunch ID counter b. Crossing ID counter c. Event ID counter d. Synchronization counter e. Derandomizer f. Read out counter CH B long and short broadcast decoder L1 trigger decoder Counters • Bcntres • Evcntres • All commands • All triggers • L1 destinations • L1 MEP flush counter • HLT destinations • HLT MEP flush counter [L1_DU.vhd] [L1_LATENCY.vhd] [downcount.vhd] [l1_yn_cnt.vhd] [count_12basic.vhd] [l1acc_count.vhd] [FE_el.vhd] [count_12basic.vhd] [count_12basic.vhd] [count_12basic.vhd] [count_32.vhd] [fifo16.vhd] [downcount.vhd] • One shot • Edge detect L0 Decision Unit a. L0 periodic trigger generator • Edge detect b. Bunch ID counter c. L0 accept counter d. L0 and L1 random generator • Random cell e. Internal interface FIFO [FREJA_counters.vhd] [count_32.vhd] [count_32.vhd] [count_32.vhd] [count_32.vhd] [count_32.vhd] [count_32.vhd] [count_32.vhd] [count_32.vhd] Register list All the functions on board are accessed via readings and writings in registers inside the FPGA. The registers can both be accessed “manually” using low level C routines via a remote connection (usually using telnet) on the CCPC; or via the user interface (DIM plus PVSS) described in Section 0. The list of registers of the test board with all the information and comments is reported in APPENDIX B - Registers list. 61 “Freja”, A.Borga 7.4 Code simulation When the code grows bigger, finding bugs via hardware measurements and intuition might become a nightmare… for that reason software simulation frameworks were developed achieving nowadays impressive results. The TFC full system emulation has been implemented at clock level in Visual Elite 3.5.1 and then simulated (Figure 60 and Figure 61). Simulation eases life of designers during the phase of time alignment and synchronization of signals: by simply plotting a set of signals over a certain time period it’s possible to find the exact delay (in term of clock cycles) between them and find out which is the best delay compensation setting to implement (Figure 62). It’s also easer to find out hiccups in the functions following the signal flow (source to destination or vice versa). Figure 60: A screen shot of the working environment in Visual Elite 3.5.1. 62 “Freja”, A.Borga Figure 61: A screen shot of the construction of a simulated board in Visual Elite 3.5.1. Figure 62: A screen shot of the timing plot in Visual Elite 3.5.1. 63 “Freja”, A.Borga 64 “Freja”, A.Borga 8 Board control 8.1 Experiment Control System Figure 63: Scope of the Experiment Control System. The Experiment Control System (ECS) [12] is responsible for the handling of the configuration, monitoring and operation of all experimental equipment involved in the different activities of the experiment: • • • • Data acquisition system: timing, trigger, front-end electronics, readout network, Event Filter Farm, storage etc. Detector operations (DCS): Gases, high voltages, low voltages, temperatures, etc. Experimental infrastructure: Magnet, cooling, ventilation, electricity distribution, detector safety, etc. Interaction with the outside world: Accelerator, CERN safety system, CERN technical services, etc. The ECS provides a unique interface between the users and all experimental equipment (Figure 63). The ECS tasks for the detector’s hardware equipment management are mainly accomplished by sending commands and settings, and reading back information. The control system can take decisions on its own (like recovering from errors) and let the operator interact with the system by presenting the information and accepting commands. The ECS is interfaced with two databases: a Configuration database that stores all the information regarding the equipment (geographical location, access addresses, default settings for different running modes, etc.) and a Conditions database which gather a subset of data needed for the offline analysis of the recorded data. From the hardware point of view (Figure 64), the control system consists of a small number of PCs (high end servers) on the surface connected to large disk servers. These supervise other PCs that are installed in the counting rooms and provide the interface to the experimental equipment (see Chapter 5.2.1). 65 “Freja”, A.Borga Figure 64: ECS hardware architecture. From the software point of view the ECS has a hierarchical, tree-like structure to represent subdetectors, sub-systems and hardware components. Two types of nodes compose the tree: Device Units which are capable of driving the equipment to which they are associated and Control Units which can monitor and control the sub-tree below (Figure 65). Figure 65: ECS Software architecture. 66 “Freja”, A.Borga 8.2 Control software framework The requirements of an ECS system can be summarized with the definition of framework given in the LHCb on line system TDR [4]: “An integrated set of guidelines and software tools used by detector developers to realize their specific control system application. The framework should include, as far as possible, standard elements and functions required to archive a homogeneous control system and to reduce the development effort as much as possible for the developers”. The framework tools which are specified by the LHCb on-line system group for hardware control are briefly described in the next chapters. 8.2.1 PVSS II The Supervisory Control And Data Acquisition (SCADA) is a standard system largely used in industry to monitor wide scale systems. As the name indicates, it is not a full control system, but rather focuses on the supervisory level. PVSS II (ProzessVisualisierungs-und Steuerungs System) [37] is a SCADA product used for the development of control systems at CERN [38]. PVSS II is a software tool for visualization, control and monitor based on device-oriented modelling. Device orientation is a high-level abstraction that allows the description of complex equipments in simple terms. The device description contains all the data and the high level commands that are needed in order to operate the equipment, even though the equipment could be composed of many channels. PVSS II is structured in a modular manner. The individual tasks are handled by special program modules called managers, and communication is based on the client-server principle. User Interface layer User Interface Manager (UI): visualizes process states and handles user inputs. Processing layer Control (CTRL): an event-driven, multi-tasking language specific to PVSS II, capable of processing several function block at once. Its many applications include creating complex control functions, or performing testing and simulation tasks. Application Program Interface (API): for interfacing external programs. Existing software packages can be integrated using class libraries, or dedicated managers developed for implementing industry-specific packages. Communication and storage layer Event Manager (EV): this forms the centre of the system, receiving messages, evaluating and distributing them. Database Manager (DM): saves process changes in a high-speed database, archives data and generates analyses and reports. Driver layer Drivers (D): the interface between PVSS II and peripheral devices. Figure 66: Schematic structure of PVSS II. PVSS II is based on the principle of Data Point Types which are similar to structures in C. The data point type describes the structure and the format of its data point variables. The data point structure reflects the real-life situations: logically associated variables describing for instance a hardware board are grouped into hierarchically structured data points. This means, for instance, that a 67 “Freja”, A.Borga TFC test board is managed internally in PVSS as a single data point containing all of the hardware registers in a structured manner according to the implementation in the hardware and the functionality to which they belong. 8.2.2 DIM PVSS is connected to the hardware via the Distributed Information Management (DIM) [40], a tool based on the Client-Server paradigm across TCP/IP. The basic concept in the DIM approach is the concept of Service which is a set of data (of any type or size) and recognized by a name (named services). Servers provide services to clients. Services are normally requested by the client only once (at start-up) and they are subsequently automatically updated by the server either at regular time intervals or whenever the conditions change (according to the type of service requested by the client). The client updating mechanism can be of two types, either by executing a call-back routine or by updating a client buffer with the new set of data, or both. The last type works as if the clients maintain a copy of the server's data in cache, the cache coherence being assured by the server. A special type of service, called Command allows a client to send a command to a server. Upon receiving a request from the client, the server executes a call-back routine in which actions can be taken based on the data which is sent by the client along with the command. In order to allow transparency (a client does not need to know where a server is running) as well as to allow easy recovery from crashes and migration of servers, a Name Server was introduced. Servers publish their services by registering them with the name server (normally once, at start-up). Clients subscribe to services by asking the name server which server provides the service and then contacting the server directly, providing the type of service and the type of update as parameters. The name server keeps an up-to-date directory of all the servers and services available in the system. PVSS can behave as a DIM Client (i.e. receive information from or send commands to DIM servers) or as a DIM Server (i.e. send information to or receive commands from DIM clients). Figure 67: DIM components interaction. 8.2.3 SMI++ Control units are typically implemented using Finite State Machines (FSM), which is a technique for modelling the behaviour of a component using the states that it can occupy and the transitions that can take place between those states. PVSS II does not provide for FSM modelling and therefore another tool SMI++ [42] has been integrated with PVSS for this purpose. SMI++ provides for rulesbased automation and error-recovery. 68 “Freja”, A.Borga 8.3 The TFC local control system Figure 68: Schematic view of the TFC local control hierarchy. Freja has been integrated in the TFC local control system. Figure 68 shows a schematic view of the local control hierarchy which follows the same structure as the global ECS described earlier. The Credit-Card PC accesses the board electronics via its PCI bus as described in Section 5.2. In order to receive commands, such as read and write registers, from user interfaces in PVSS and to return values of readings, a Credit-Card PC runs a server which publishes a set of DIM services and commands: • • • • ReadWriteRegister (command) ReadRegister (service) SubscribeCounters (command) ReadCounters (service) The ReadWriteRegister command has five arguments: access method (I2C, JTAG, Local bus), register address, data, a mask in order to effect only selected bit in a register, and a read/write bit whether the command is requesting a write or only a read. A write action always consists of a read of the register, followed by a write of the new data and last another read in order to send back the data that was actually written. In this way, the control system can verify that the write action was properly performed. After a read the data is returned by updating the ReadRegister service, which consists of three arguments: method, address and data. The SubscibeCounters command allows a client to ask for a set of registers, typically counters, to be sent to the client regularly. The command has three arguments: access method, the address of the register and the interval at which the server should update the value. The server will thus send the values of the counters at the requested intervals by updating the ReadCounters service. The ReadCounters service consists of a dynamic array of two arguments: the address of the register that is updated and the value. The Credit-card PC of each hardware board publishes its own set of these services and commands. The service and the commands are distinguished by having the name of the board in the service and the command name. The PVSS system can send commands to and receive data from the boards by subscribing to these services and commands. As mentioned in the previous section, the PVSS database contains a data point list which reflects the entire register structure of the board. Table 15 shows the Freja data point list as an example. The structure is common to all TFC boards. In order to verify the writings automatically in PVSS, the registers exist in two copies: Register Settings and Register Readings. In addition, since there may not always be a one-to-one relation between physical registers (always 32-bits) and functional parameters such as “enable random generator”, “L0 readout time”, the data point also stores the values of the functional parameters, again as both Parameter Settings and Parameter Readings. 69 “Freja”, A.Borga Table 15: Data Point List file for Freja. FREJA_P2.FREJA_P2 State Q_MODs_loaded Locked Ready Running Paused Error Monitored Register Readings Q1 R000 R004 R008 R00C ... I2C QA0 R00 R01 R02 R03 Q40 R00 R01 R02 R03 QFF R00 R01 R02 R03 Settings Q1 R000 R004 R008 R00C ... I2C QA0 ... Q40 ... QFF ... Parameter Readings L0DU R_L0PER_ENB R_L0RND_ENB … L1DU P_L1_LATENCY P_L1_SPACE … FEEL R_FE_ROTIME FIFOMON R_L0FIFO_MON R_L0FIFO_FULL 70 1. Name of the data point list corresponding to one single board. 2. States stores the status of the board 3. Register contains the contents of the whole 32 bit words stored inside the corresponding hardware registers. Reading and Settings are handled separately in order to cross check settings. ← Identifies a module (FPGAs or I2C devices) ← Identifies a register ← Identifies an I2C device according to its physical address (EEPROM, I2C register or TTCrx) 4. Since a single register can contain several different pieces of configuration data, Parameters are used to identify each one inside the 32 bit register. Parameters are grouped according to mnemonic structures specified during the User Interface design phase. Again Reading and Settings are treated separately. “Freja”, A.Borga … R_FEFIFO_MON … Settings L0DU R_L0PER_ENB … L1DU P_L1_LATENCY … FEEL R_FE_ROTIME FIFOMON R_L0FIFO_MON … R_FEFIFO_MON … Apply Action ReadReg Data ReadCnt Data ReadWriteReg Method Address RegValue Mask Write SubscribeCnt Address Interval ← Identifies the set of parameters following ← Identifies a parameter 5. Actions are data points used to exchange data between the board and PVSS. The data point of each board also contains a set of Data Point Items which are associated with the DIM services and commands in order to transmit and receive data: • • • • ReadReg: associated to the ReadRegister service to receive data. ReadCnt: associated to the ReadCounters service to receive the counter values. ReadWriteReg: associated to the ReadWriteRegister command to request writing or reading of registers. SubscribeCnt: associated to the SubscribeCounters command to request counter values at regular intervals. PVSS allows associating call-back routines with changes on data points. Whenever the content of a Data Point changes a function in a script file, structured like a C program, is called to perform a set of actions associated with the change. This is the means by which data is received via the DIM services. For instance, when the server running in the CCPC updates the ReadRegister service upon a read request, the data is written into the ReadReg data point item. A call-back routine associated with the data point item decodes the address and writes the data to the proper register in the data point. The script is also handling the translations between parameters and registers during write requests and read requests. Figure 69 shows the sequence of actions during a write request. A user requests a change of the value of a parameter in the user interface. Upon applying the value, the value will be written to the appropriate parameter under Parameter Settings in the data point. A call-back routine in the script associated with the action will change the value of the parameter in the register in which it is located and write the new value of the register to the register under Register Settings and also write the new value, access method, address and mask to the data point item ReadWriteReg which is associated with the ReadWriteRegister DIM command. 71 “Freja”, A.Borga The server will react by reading the register, modifying the value of the parameter and writing the new register value. The value is then read again and returned via the ReadRegister DIM service. As mentioned above the data is received by the ReadReg data point item and written to the appropriate register according to the received address under Register Readings. In addition to updating the parameters of the register under Parameter Readings, the script will also verify that the return value of the register matches the requested value. Since the user interfaces can subscribe to the parameters, the display is automatically updated with the latest settings. Figure 69: Flow of the Reading and Writing from and to TFC boards. 8.3.1 Freja control panels The graphical interface has been designed using the Graphical Editor of PVSS II. A main panel Freja_P1.pnl and Freja_P2.pnl is used to control all board functions on both versions. An Expert panel is used to access all the board registers by inserting directly Hexadecimal addresses and values. In Version 2 the control panels have been implemented to allow users to access the features in a more intuitive and user friendly manner. The panel of the first prototype includes the following features: • • • • • 72 A General monitor displays the contents of the principal test registers and parameters. A Channel B decoder which displays the contents of the short TTC broadcasts. A Channel B long TTC broadcast monitor which shows the contents of the long TTC broadcasts. Both L1 Trigger and High Level Triggers and the number of times the buffers relative to each type of triggers inside the Readout Supervisor is emptied (Multi Event Packet, MEP flush). A number of buttons allows performing basic operations on the board like resets, subscription and update of registers. An Expert panel allows users to access directly registers on board using Hexadecimal addresses and data. Both Local bus and I2C functions are supported, by default the expert panel acts on Local bus, by selecting the proper button operations via I2C are enabled. “Freja”, A.Borga Figure 70: Screen shot of Freja V2 panel. The main panel of the final prototype is not different from the one of the previous version described above. Configuration menus have been added to allow the setup of the different emulated functions of the test board. 73 “Freja”, A.Borga The enabling and disabling of functions is visualized by “LEDs”. Each parameter can be set to any acceptable value. A Current button retrieves information of the actual content of a register. A Default button retrieves the default settings for each parameter. An Apply button sends the settings to the board. Figure 71: L0 DU configuration and monitor menu. Boxes to display Current values and insert settings are kept separate for readability. The enabling and disabling of functions is immediate as soon as the tick box is checked. To send the configuration parameters to the board the clicking of the Apply button is necessary. Figure 72: L1 DU configuration menu. In the expert panel all the registers must be set in either 32-bit or hexadecimal format. To simplify the calculation and the visualization of results a small converter has been implemented in the panel. Figure 73: FE EL configuration and monitor menu. 74 “Freja”, A.Borga 9 Ringraziamenti E così… sembra che tu stia crescendo... Piccola mia... Ringraziamenti... Ovvero pensieri a ruota libera! Scritti in italiano, dopo un prolisso parlare in lingua straniera, senza un motivo specifico... o forse perchè pensieri a ruota libera si esprimo nella lingua che più si avvicina a quella del cuore... Primi ringraziamenti ai miei due supervisori, per avermi supportato e soprattutto sopportato durante tutta la mia permanenza al CERN. A Richard Jacobsson: non ci sono parole per esprimere la mia gratitudine nei confronti di una persona che non solo si è rivelata un “capo” gentile, ma anche un collega con cui ridere in ufficio, anche nei momenti meno felici, ed un amico col quale trascorrere e condividere piacevoli momenti al di fuori dell’orario lavorativo... cenazze, birrette e tutto il resto! A Daniele Trinchero la cui presenza “nell’ombra degli uffici del poli” mi ha permesso di arrivare alla fine del mio stage senza alcun intoppo. A tutto lo staff dell’LHCb, in particolare ai colleghi del gruppo che si occupa della parte on-line dell’esperimento, per tutto quello che ho potuto vedere, conoscere, imparare ed apprezzare grazie a loro. Cito e ringrazio in particolare i colleghi con cui sono stato più a stretto contatto. Ramy Abdel-Rahman per le lunghissime “nargila nights” e tutti i bei discorsi accompagnati dal gorgoglio della pipa che mi hanno portato all’incontro con una faccia della cultura medio orientale che non conoscevo. A Zbigniew Guzik (Zbig) la cui conoscienza nel campo dell’elettronica è superata solo dalla sua passione per la stessa. Alla sua Vodka Polacca, le sue celebrazioni per qualsiasi motivo e tutte le sue tecniche di pasteggio alcolico accompagnate da sane risate... A Grzegorz Kasprowicz (Gregory) per l’ispirazione nel creare apparecchiature elettroniche con mezzi di fortuna (cfr. lo sviluppo di PCB con l’uso di riviste per donne!). Al suo incredibilie robot ed alla sua ancora più incredibile macchina foto digitale per fotografia astronomica. Ad Artur Barczyk e Benjamin Gaidioz inguaribili “computer boys”... per tutte le discussioni su sistemi operativi, editor di testo e quant’altro... probabilmente non imparerò mai! A Jean-Pierre Dufey, un signore in camicia e barba bianca, il cui sguardo dice spesso più di mille parole. Gli insegnamenti di vita, di fronte a caffè e brioche, mi hanno aiutato ad osservare con più criticità ciò che mi circonda. Cercherò di tenere a mente tutto ciò che è stato detto... Alla disarmante tenerezza di Xxx, studente del Madagascar. Alla mia famiglia, mamma e papà per primi, per l’amore trasmesso anche a distanza, la pazienza nel sopportare i miei sbalzi d’umore e nel prendersi cura della mia salute in qualsisi circostanza. Non ci sono parole per esprime la gratitudine per avermi dato la possibilità di venire qui senza difficoltà. Ad Isa e Yann poi, per tutto quello che hanno fatto per me durante quest’anno via da casa... A partire dai sorrisi sinceri e al sostegno morale per finire con i bei momenti trascorsi insieme e tutto il resto. Non basteranno un paio di inviti a cena al Thai dietro casa per sdebitarmi! Ai miei amici e compagni d’università per i piacevoli momenti trascorsi insieme negli ultimi anni. Un grazie particolare a Giulio Coluccia “il capo” le cui ripetizioni nel tempo libero (unite alla passione, la pazienza e la meticolosità trasmessa durante gli incontri) mi hanno spesso permesso di superare ostacoli che sembravano insormontabili. Arriverò alla laurea anche grazie a te! Ai miei amici, bambini cattivi, con i capelli lunghi e gli orecchini... siete parte di me. Mi prostro infine di fronte alla potenza di Google... lo zerbino sulla porta di un mondo virtuale. Se non fosse stato inventato, a quest’ora, il mio lavoro sarebbe ancora a metà! 75 “Freja”, A.Borga 76 “Freja”, A.Borga 10 References INTRODUCTION: [1] www.cern.ch [2] user.web.cern.ch [3] http://lhcb-public.web.cern.ch/lhcb-public CERN public home page CERN users home page Introduction to LHCb SYSTEM OVERVIEW: [4] http://lhcb.web.cern.ch/lhcb/TDR/TDR.htm [5] Readout Supervisor specifications [6] L1 trigger path note LHCb TDRs In the CD In the CD TTC system: [7] http://ttc.web.cern.ch/TTC [8] TTCrx users manual TTC system homepage In the CD TEST: [9] http://www.issco.unige.ch/ewg95/node80.html [10] http://www.cse.fau.edu/~maria/COURSES/CEN4010-SE/C13/glass.htm [11] http://www.cse.fau.edu/~maria/COURSES/CEN4010-SE/C13/black.html CCPC: [12] http://lhcb-online.web.cern.ch/lhcb-online/ecs/ccpc/default.htm [13] http://lhcb-online.web.cern.ch/lhcb-online/ecs/ccpc/docs/SM520PCX.pdf [14] PLX 9030 data sheet PCI: [15] http://www.pcguide.com/ref/mbsys/buses/types/pci.htm [16] http://www.techfest.com/hardware/bus/pci.htm [17] MindShare inc, “PCI System Architecture revision 2.2”, Addison Wesley [18] MindShare inc, “PCI-X System Architecture”, Addison Wesley GLUE CARD: [19] The Glue light user manual CERN CCPC/ECS site CCPC user manual In the CD PCI small introduction PCI standard specifications In the CD 2 I C: [20] Philips I2C standard specification In the CD JTAG: [21] http://www.jtag.com [22] IEEE 1149.1 standard specification JTAG official website In the CD LVDS: [23] http://www.national.com/appinfo/lvds LVDS home page ECL: [24] http://www.onsemi.com/ [25] http://www.lemo.com/techlibrary/index.jsp Material on ECL technology in application notes LEMO company technical libraries FPGA: [26] http://www.xilinx.com [27] http://www.xenatera.com/bunnie/xi/rec.html [28] http://www.synplicity.com [29] http://www.altera.com [30] http://www.altera.com/products/devices/apex/apx-index.html [31] http://www.altera.com/literature/ds/apex.pdf Xilinx FPGA vendor Link on MIT web site Synplify home page Altera FPGA vendor Altera APEX 20k family APEX family data sheet STAPL: [32] www.jedec.org/download/search/jesd71.pdf [33] www.actel.com/documents/ISP_STAPL.pdf JEDEC standard specification ISP and STAPL 77 “Freja”, A.Borga 78 VME: [34] IEEE 1101 Standard specification for VME boards mechanic In the CD VHDL: [35] http://vhdl.org/vi [36] IEEE 1076 VHDL Standard specifications VHDL home page In the CD PVSS: [37] http://www.pvss.com/english [38] http://itcobe.web.cern.ch/itcobe/Services/Pvss/Documents/welcome.html [39] http://itcobe.web.cern.ch/itcobe/Services/Pvss/Documents/PvssIntro.pdf PVSS official website CERN PVSS web page CERN PVSS Introduction course to PVSS DIM: [40] http://dim.web.cern.ch/dim [41] http://clara.home.cern.ch/clara/fw DIM web site PVSS interface to DIM SMI++: [42] B. Franek and C. Gaspar, “SMI++ - An Object Oriented Framework for Designing Distributed Control Systems” CERN Technical note about SMI++ D C B A C2 0.01uF 1 11 Blocking capacitors.SCHDOC Blocking capacitors 10 Clock business.SCHDOC Clock business 09 ECL transmitters RP.SCHDOC ECL transmitters 08 ECL receivers RP.SCHDOC ECL_RX2 2 1 2 2 ECL_TX4 ECL_TX3 LEMO_DUAL_PCB 1 ECL_TX2 P9 ECL_TX1 LEMO_DUAL_PCB ECL_RX4 ECL_RX3 L_LED+ L_LEDR_LED+ R_LED- LEMO_DUAL_PCB P6 2 RJ-45 GROUND GROUND RX+ CT RD- TX+ CT TX- P3 1 ECL Transmitter lemons P8 4 5 2 3 1 8 6 7 C1 0.01uF ECL_RX1 2 LEMO_DUAL_PCB 2 ECL receivers 1 07 LVDS transceivers.SCHDOC P4 ECL Receivers lemons RX100- R2 120 RX100+ TX100- R1 120 TX100+ CCPC Ethernet LVDS transceivers 06 Q MP Supermodule.SCHDOC Q MP Supermodule 05 Glue Card.SCHDOC Glue Card 04 Credit Card PC.SCHDOC Credit Card PC 03 TTCrx TTCrs I2C and FIFO.SCHDOC TTCrx TTCrs I2C and FIFO 02 Power supply and resets.SCHDOC Power supply and resets FREJA 1 9 10 12 11 3 VME_POWER EXTclkLEM P12 FP_SUPPORT BULK_ADAPTER Front pannel support LEMO LM1 GND GND GND GND GND GND GND GND GND GND GND GND GND GND GND GND SYSRESET GND GND +5V_EXT +5V_EXT +5V_EXT +5V_EXT +5V_EXT +5V_EXT +5V_EXT +5V_EXT +5V_EXT +5V_EXT +5V_EXT +5V_EXT VME_P1 External ClockLemo C18 A4 B4 C4 A3 B3 C3 A2 B2 C2 A1 B1 C1 +5V_EXT VME_RESET VME connector P11 Adapter for TTCrx 3 4 4 A16 B16 C16 A15 B15 C15 A14 B14 C14 A10 B10 C10 A9 B9 C9 A8 B8 C8 RIGIDITY_BAR RB1 Rigidity bar 6 5 Date: File: B Size Title GP_LVDS32GP_LVDS32+ GP_LVDS33GP_LVDS33+ GND GP_LVDS16+ GP_LVDS17+ GP_LVDS18+ GP_LVDS19+ GP_LVDS20+ GP_LVDS21+ GP_LVDS22+ GP_LVDS23+ GP_LVDS24+ GP_LVDS25+ GP_LVDS26+ GP_LVDS27+ GP_LVDS28+ GP_LVDS29+ GP_LVDS30+ GP_LVDS31+ GND GP_LVDS0+ GP_LVDS1+ GP_LVDS2+ GP_LVDS3+ GP_LVDS4+ GP_LVDS5+ GP_LVDS6+ GP_LVDS7+ GP_LVDS8+ GP_LVDS9+ GP_LVDS10+ GP_LVDS11+ GP_LVDS12+ GP_LVDS13+ GP_LVDS14+ GP_LVDS15+ LVDS Connector RJ9 -A +A -B +B P10 IDC34 P2 IDC34 P1 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 GND GP_LVDS16GP_LVDS17GP_LVDS18GP_LVDS19GP_LVDS20GP_LVDS21GP_LVDS22GP_LVDS23GP_LVDS24GP_LVDS25GP_LVDS26GP_LVDS27GP_LVDS28GP_LVDS29GP_LVDS30GP_LVDS31- GND GP_LVDS0GP_LVDS1GP_LVDS2GP_LVDS3GP_LVDS4GP_LVDS5GP_LVDS6GP_LVDS7GP_LVDS8GP_LVDS9GP_LVDS10GP_LVDS11GP_LVDS12GP_LVDS13GP_LVDS14GP_LVDS15- 6 Number Revision REV 2.2 by Andrea Borga 29-Jul-04 Sheet of 1/11 Z:\TFC\..\01 project sheet and connectors.SCHDOC Drawn By: Ramy Abdel-Rahman Project Sheet & Connectors 1 2 3 4 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 TFC Test Board 5 D C B A “Freja”, A.Borga 11 APPENDIX A - Board Schematics As mentioned in Section 6.2, in the next pages the board schematics are shown. All used components are TFC standard and kept in a specific Protel library. 79 D C B A T2 1 MMBT2222A SW1 Manual RESET Circuitry 1K R133 R9 1K 6 4 CP15 10uF R3 10K R12 30K +5V R6 10K R13 750K 3 2 TL7705 1 3 8 6 5 1 2 SET1 HYST1 R4 10K /RESET J2X1 J2 B2 SET2 HYST2 6 5 2 R7 10K R14 910K JTAGEPC2 prog enable C3 0.01uF 0.01uF ICL7665 +5V_EXT LVCC_RX1 U2 1 +5V VME_RESET R132 10K R79 10K LVCC_RX1 SENSE VCC RSTIN RESET CT RESET GND REF U1 NL27WZ04 U51 7 2 3 4 Power Supply Monitoring JTAG_ENn B1 0.01uF 2 8 R15 27K +5V R8 10K T1 MMBT2222A R10 1K +5V_EXT +5V GND GND +12V 3 1 2 3 4 4 3 2 1 2 1 10A F1 NE555 GND TRIG OUT RESET 10A F2 PR1 U3 Ground Probes +5V_EXT VCC DISCH THRES CONT 8 7 6 5 2 1 3 1 CP5 47uF +5VDCDC Negative voltage DC/DC Converter PWR_HEADER Y1 +5V_EXT Power Header 3 CP1 3.3K NL27WZ04 U18 2 4 6 CP6 47uF R11 C4 0.01uF PR2 47uF 1 4 CP14 47uF B3 0.01uF CP8 47uF Comm +Output PR3 BAD_PWRn BAD_PWR R5 10K +5V_EXT CP7 47uF 2 1 UWR-5/1600-D5 -Input +Input DC/DC1 4 5 3 CP9 47uF 2 1 PR4 47uF CP2 +5V -5V 5 5 Date: File: B Size Title 6 1 2 1 2 SHDN IN Q4 OUT 5 4 5 4 OUT 3 3 CP12 47uF CP10 47uF LVCC_RX CP13 47uF CP11 47uF LVCC_RX1 CP4 47uF VCCINT CP3 47uF LVCC_B 6 Number Revision REV 2.2 by Andrea Borga 29-Jul-04 Sheet of 2/11 Z:\TFC\..\02 Power supply and resets.SCHDOCDrawn By: Ramy Abdel-Rahman FB OUT LT1764-3.3 FB OUT LT1764-3.3 IN Q2 LT1963AEST-1.8 IN Q1 LT1963AEST-3.3 SHDN IN Q3 1 1 Power Supply & Resets +5V +5V Generic 3.3V Power +5V FPGA Power Supply Regulators TFC Test Board GND 4 GND FREJA 1 OUT1 GND 3 GND 3 V+ GND 4 OUT2 7 GND 2 GND 2 80 4 1 D C B A “Freja”, A.Borga D C B A SDA SCL R19 R20 1K 1K 1 SDA SCL A2 A1 A0 U4 nBUFFER_RESET 57 49 18 21 24 59 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 64 63 BUFFER_IN0 BUFFER_IN1 BUFFER_IN2 BUFFER_IN3 BUFFER_IN4 BUFFER_IN5 BUFFER_IN6 BUFFER_IN7 BUFFER_IN8 BUFFER_IN9 BUFFER_IN10 BUFFER_IN11 BUFFER_IN12 BUFFER_IN13 BUFFER_IN14 BUFFER_IN15 BUFFER_IN16 BUFFER_IN17 B5 0.01uF 19 20 INT I/O7 I/O6 I/O5 I/O4 I/O3 I/O2 I/O1 I/O0 PCA9554 LVCC_RX1 FICLK nBUFFER_WE 15 14 3 2 1 B4 0.01uF LVCC_RX1 BUFFER I2C I/Oport FREJA 16 VDD GND 8 1 SEL2 SEL1 H_EXT CY7C4275 RS# SMODE# FL#/RT WXI# RXI# LD# D0 D1 D2 D3 D4 D5 D6 D7 D8 D9 D10 D11 D12 D13 D14 D15 D16 D17 WCLK WEN# U6 13 12 11 10 9 7 6 5 4 R18 1K 3 1 3 1 RXO# WXO#/HF# EF# FF# PAE# PAF# OE# Q0 Q1 Q2 Q3 Q4 Q5 Q6 Q7 Q8 Q9 Q10 Q11 Q12 Q13 Q14 Q15 Q16 Q17 RCLK REN# R80 1K 2 27 26 54 25 17 23 58 28 29 31 32 34 36 37 38 39 41 42 44 45 47 48 50 52 53 61 60 4 6 4 6 nTTCrx_RESET SRESn2 SRESn1 nBUFFER_EMPTY nBUFFER_FULL BUFFER_OUT0 BUFFER_OUT1 BUFFER_OUT2 BUFFER_OUT3 BUFFER_OUT4 BUFFER_OUT5 BUFFER_OUT6 BUFFER_OUT7 BUFFER_OUT8 BUFFER_OUT9 BUFFER_OUT10 BUFFER_OUT11 BUFFER_OUT12 BUFFER_OUT13 BUFFER_OUT14 BUFFER_OUT15 BUFFER_OUT16 BUFFER_OUT17 nBUFFER_RE NL27WZ04 U19 NL27WZ04 U5 2 CLOCK40DES2 TTCrx Mezzanine 33 3 R17 R25 10K R26 10K A1 A2 A3 TTC_BRCST5 A4 TTC_BRCST4 A5 TTC_BRCST3 A6 TTC_BRCST2 A7 TTC_BRCSTSTR1 A8 TTC_DBERRSTR A9 TTC_SINERRSTR A10 TTC_SUBADDR0 A11 TTC_SUBADDR1 A12 TTC_SUBADDR2 A13 TTC_SUBADDR3 A14 TTC_SUBADDR4 A15 TTC_SUBADDR5 A16 TTC_SUBADDR6 A17 TTC_SUBADDR7 A18 A19 A20 A21 A22 A23 TTC_DOUTSTR A24 A25 TTC_DOUT0 A26 TTC_DOUT1 A27 TTC_DOUT2 A28 TTC_DOUT3 A29 TTC_DOUT4 A30 TTC_DOUT5 A31 TTC_DOUT6 A32 TTC_DOUT7 A33 nTTCrx_RESET A34 TTC_READY A35 A36 A37 A38 A39 A40 A41 A42 A43 A44 A45 A46 A47 A48 A49 A50 R16 33 CHA CHB 5 6 7 8 100EPT22 LVTTL LVPECL U28 TTCRX_MEZZ Clock40 Clock40Des1 Brcst<5> Brcst<4> Brcst<3> Brcst<2> Clock40Des2 BrcstStr1 DbErrStr SinErrStr SubAddr<0> SubAddr<1> SubAddr<2> SubAddr<3> SubAddr<4> SubAddr<5> SubAddr<6> SubAddr<7> DQ<0> DQ<1> DQ<2> DQ<3> DoutStr GND Dout<0> Dout<1> Dout<2> Dout<3> Dout<4> Dout<5> Dout<6> Dout<7> Reset_b TTCReady GND GND GND GND GND GND GND GND GND GND GND GND GND GND GND GND M1 LVCC_RX1 TTCrs Mezzanine CLOCK40DES1 3 R88 R89 82 82 4 BrcstStr2 ClockL1Accept Brcst<6> Brcst<7> EvCntRes L1Accept EvCntLStr EvCntHStr BcntRes GND BCnt<0> BCnt<1> BCnt<2> BCnt<3> BCnt<4> BCnt<5> BCnt<6> BCnt<7> BCnt<8> BCnt<9> BCnt<10> BCnt<11> JTAGTMS JTAGTRST_b JTAGTCK JTAGTDO SDA JTAGTDI BCntStr Serial_B_Channel GND GND GND GND PIN_Preamp_VCC PIN_Preamp_VCC PIN_Preamp_VCC PIN_Preamp_VCC NC SCL GND GND TTCrx_VDD TTCrx_VDD TTCrx_VDD TTCrx_VDD GND GND GND GND 4 3 2 1 R84 R85 120 120 LVCC_RX 4 B1 B2 B3 B4 B5 B6 B7 B8 B9 B10 B11 B12 B13 B14 B15 B16 B17 B18 B19 B20 B21 B22 B23 B24 B25 B26 B27 B28 B29 B30 B31 B32 B33 B34 B35 B36 B37 B38 B39 B40 B41 B42 B43 B44 B45 B46 B47 B48 B49 B50 +5V 10k R21 LVCC_RX1 SCL SDA 10k R22 TTC_BCNTRES 1 2 3 4 5 6 7 8 9 10 +5V TTC_BRCST6 TTC_BRCST7 TTC_EVCNTRES TTC_L1ACCEPT R141 R142 82 82 R86 R87 120 120 LVCC_RX 10k R24 10k R23 100EP17 VBB VCC U21 6 +5V GND VCC 5 Date: File: B Size Title +5V 20 19 18 17 16 15 14 13 12 11 B1 B2 B3 B4 B5 B6 B7 B8 B9 B10 B11 B12 TTCRS_MEZZ GND -BCLK GND +BCLK GND GND GND CH_B GND GND GND CH_A GND H_EXT GND RESETn LVCC CLK_OKn LVCC VCC -5V VCC -5V VCC M2 GND GND GND GND GND GND GND GND GND Z1 Z2 Z3 Y1 Y2 Y3 X1 X2 X3 6 Revision REV 2.2 by Andrea Borga 29-Jul-04 Sheet of 3/11 Z:\TFC\..\03 TTCrx TTCrs I2C and FIFO.SCHDOC Drawn By: Ramy Abdel-Rahman Number TTCrx mezzanine & FIFO buffer BCLK+ BCLK- +5V -5V LVCC_RX SRESn2 H_EXT A1 A2 A3 A4 A5 A6 A7 A8 A9 A10 A11 A12 TFC Test Board 5 D C B A “Freja”, A.Borga 81 82 D C B A +5V AD0 AD1 AD2 AD3 AD4 AD5 AD6 AD7 AD8 AD9 AD10 AD11 AD12 AD13 GND P_DATA5 P_DATA6 P_DATA7 P_ACK_ P_BUSY P_PE P_DATA0 P_DATA1 1 P_AUTO_ P_ERROR_ XA1 XA2 XA3 XA4 XA5 XA6 XA7 XA8 XA9 XA10 XA11 XA12 XA13 XA14 XA15 XA16 XA17 XA18 XA19 XA20 XA21 XA22 XA23 XA24 XA25 XA26 XA27 XA28 XA29 XA30 XA31 XA32 XA33 XA34 XA35 XA36 XA37 XA38 XA39 XA40 XA41 XA42 XA43 XA44 XA45 XA46 XA47 XA48 XA49 XA50 XA51 XA52 XA53 XA54 XA55 XA56 XA57 XA58 XA59 XA60 CC_PC_NEW VCC GND M3A FREJA 1 RTC_BATTERY XB1 XB2 XB3 XB4 XB5 XB6 XB7 XB8 XB9 XB10 XB11 XB12 XB13 XB14 XB15 XB16 XB17 XB18 XB19 XB20 XB21 XB22 XB23 XB24 XB25 XB26 XB27 XB28 XB29 XB30 XB31 XB32 XB33 XB34 XB35 XB36 XB37 XB38 XB39 XB40 XB41 XB42 XB43 XB44 XB45 XB46 XB47 XB48 XB49 XB50 XB51 XB52 XB53 XB54 XB55 XB56 XB57 XB58 XB59 XB60 2 AD16 AD17 AD18 AD19 AD20 AD21 AD22 AD23 AD24 AD25 AD26 AD27 AD28 AD29 DCD DSR RXD RTS TXD CTS DTR RI 2 GND TX100+ TX100RX100+ RX100- /RESET FRAME_ TRDY_ DEVSEL_ AD14 AD15 C-BE0_ C-BE1_ C-BE2_ C-BE3_ +5V PCI-CLK XA61 XA62 XA63 XA64 XA65 XA66 XA67 XA68 XA69 XA70 XA71 XA72 XA73 XA74 XA75 XA76 XA77 XA78 XA79 XA80 XA81 XA82 XA83 XA84 XA85 XA86 XA87 XA88 XA89 XA90 XA91 XA92 XA93 XA94 XA95 XA96 XA97 XA98 XA99 XA100 XA101 XA102 XA103 XA104 XA105 XA106 XA107 XA108 XA109 XA110 XA111 XA112 XA113 XA114 XA115 XA116 XA117 XA118 XA119 XA120 +3.3V VCC VCC CCPC_MEZZ 3 LCD VCC OUT (3.3V) CORE GND VCC-SUSPEND +5V +3.3V LAN TX+ LAN TXLAN RX+ LAN RX- VCC M3B 3 XB61 XB62 XB63 XB64 XB65 XB66 XB67 XB68 XB69 XB70 XB71 XB72 XB73 XB74 XB75 XB76 XB77 XB78 XB79 XB80 XB81 XB82 XB83 XB84 XB85 XB86 XB87 XB88 XB89 XB90 XB91 XB92 XB93 XB94 XB95 XB96 XB97 XB98 XB99 XB100 XB101 XB102 XB103 XB104 XB105 XB106 XB107 XB108 XB109 XB110 XB111 XB112 XB113 XB114 XB115 XB116 XB117 XB118 XB119 XB120 PERR_ +5V IRDY_ STOP_ PAR SERR_ PCI-RST_ +5V AD30 AD31 GND +5V 4 YA1 YA2 YA3 YA4 YA5 YA6 YA7 YA8 YA9 YA10 YA11 YA12 YA13 YA14 YA15 YA16 YA17 YA18 YA19 YA20 YA21 YA22 YA23 YA24 YA25 YA26 YA27 YA28 YA29 YA30 YA31 YA32 YA33 YA34 YA35 YA36 YA37 YA38 YA39 YA40 YA41 YA42 YA43 YA44 YA45 YA46 YA47 YA48 YA49 YA50 YA51 YA52 YA53 YA54 YA55 YA56 YA57 YA58 YA59 YA60 4 CCPC_MEZZ GND VCC M3C YB1 YB2 YB3 YB4 YB5 YB6 YB7 YB8 YB9 YB10 YB11 YB12 YB13 YB14 YB15 YB16 YB17 YB18 YB19 YB20 YB21 YB22 YB23 YB24 YB25 YB26 YB27 YB28 YB29 YB30 YB31 YB32 YB33 YB34 YB35 YB36 YB37 YB38 YB39 YB40 YB41 YB42 YB43 YB44 YB45 YB46 YB47 YB48 YB49 YB50 YB51 YB52 YB53 YB54 YB55 YB56 YB57 YB58 YB59 YB60 6 5 Date: File: B Size Title GND GND GND GND CCPC_MEZZ GND GND GND GND M3D Reserved GND GND GND 4/28/2004 C:\Andy\..\04 Credit Card PC.SCHDOC Number Credit Card PC YA61 YA62 YA63 YA64 YA65 YA66 YA67 YA68 YA69 YA70 YA71 YA72 YA73 YA74 YA75 YA76 YA77 YA78 YA79 YA80 YA81 YA82 YA83 YA84 YA85 YA86 YA87 YA88 YA89 YA90 YA91 YA92 YA93 YA94 YA95 YA96 YA97 YA98 YA99 YA100 YA101 YA102 YA103 YA104 YA105 YA106 YA107 YA108 YA109 YA110 YA111 YA112 YA113 YA114 YA115 YA116 YA117 YA118 YA119 YA120 GND GND GND 6 Revision REV 2.0 by Andrea Borga Sheet of 4/11 Drawn By: Ramy Abdel-Rahman YB61 YB62 YB63 YB64 YB65 YB66 YB67 YB68 YB69 YB70 YB71 YB72 YB73 YB74 YB75 YB76 YB77 YB78 YB79 YB80 YB81 YB82 YB83 YB84 YB85 YB86 YB87 YB88 YB89 YB90 YB91 YB92 YB93 YB94 YB95 YB96 YB97 YB98 YB99 YB100 YB101 YB102 YB103 YB104 YB105 YB106 YB107 YB108 YB109 YB110 YB111 YB112 YB113 YB114 YB115 YB116 YB117 YB118 YB119 YB120 TFC Test Board 5 D C B A “Freja”, A.Borga D C B A +5V AD0 AD1 AD2 AD3 AD4 AD5 AD6 AD7 AD8 AD9 AD10 AD11 AD12 AD13 GND P_DATA5 P_DATA6 P_DATA7 P_ACK_ P_BUSY P_PE P_DATA0 P_DATA1 XA4 XA5 XA6 XA7 XA8 XA9 XA10 XA11 XA12 XA13 XA14 XA15 XA16 XA17 XA18 XA19 XA20 XA21 XA22 XA23 XA24 XA25 XA26 XA27 XA28 XA29 XA30 XA31 XA32 XA33 XA34 XA35 XA36 XA37 XA38 XA39 XA40 XA41 XA42 XA43 XA44 XA45 XA46 XA47 XA48 XA49 XA50 XA51 XA52 XA53 XA54 XA55 XA56 XA57 XA58 XA59 XA60 XA1 XA2 P_AUTO_ P _ E R R O R _ XA3 XB1 XB2 XB3 XB4 XB5 XB6 XB7 XB8 XB9 XB10 XB11 XB12 XB13 XB14 XB15 XB16 XB17 XB18 XB19 XB20 XB21 XB22 XB23 XB24 XB25 XB26 XB27 XB28 XB29 XB30 XB31 XB32 XB33 XB34 XB35 XB36 XB37 XB38 XB39 XB40 XB41 XB42 XB43 XB44 XB45 XB46 XB47 XB48 XB49 XB50 XB51 XB52 XB53 XB54 XB55 XB56 XB57 XB58 XB59 XB60 1 CC_GLUE_NEW VCC GND J2-top M6A FREJA 1 AD16 AD17 AD18 AD19 AD20 AD21 AD22 AD23 AD24 AD25 AD26 AD27 AD28 AD29 DCD DSR RXD RTS TXD CTS DTR RI XA69 XA70 XA71 XA72 XA73 F R A M E _ XA74 T R D Y _ XA75 D E V S E L _XA76 XA77 XA78 XA79 XA80 XA81 XA82 XA83 XA84 XA85 XA86 XA87 XA88 XA89 XA90 XA91 XA92 XA93 XA94 XA95 XA96 XA97 XA98 XA99 XA100 XA101 XA102 XA103 XA104 XA105 GND XA106 XA107 XA108 XA109 XA110 XA111 XA112 XA113 XA114 XA115 XA116 XA117 XA118 XA119 XA120 XA61 AD14 XA62 AD15 C - B E 0 _ XA63 C - B E 1 _ XA64 C - B E 2 _ XA65 C - B E 3 _ XA66 XA67 +5V P C I - C L KXA68 GLUE_MEZZ GND 3.3 3.3 VCC VCC VCC J2-bot M6B 2 XB61 AD30 XB62 AD31 XB63 XB64 XB65 XB66 XB67 +5V XB68 XB69 XB70 XB71 XB72 XB73 +5V XB74 IRDY_ XB75 STOP_ XB76 PAR XB77 SERR_ XB78 PCI-RST_ XB79 XB80 XB81 XB82 XB83 XB84 XB85 XB86 XB87 P E R R _ XB88 XB89 XB90 XB91 XB92 XB93 XB94 XB95 XB96 XB97 XB98 XB99 XB100 XB101 XB102 XB103 XB104 XB105 XB106 XB107 XB108 XB109 XB110 XB111 XB112 XB113 XB114 XB115 XB116 XB117 XB118 XB119 XB120 2 GND GPIO5 GPIO6 GPIO7 GPIO8 GND GND GND GND LRESETn LLASTn LCLK LRDYn GND LAD0 LAD1 LAD2 LAD3 LAD4 LAD5 LAD6 LAD7 GND LAD8 LAD9 LAD10 LAD11 LAD12 LAD13 LAD14 LAD15 GND LADSn LW/Rn +5V ZA1 ZA2 ZA3 ZA4 ZA5 ZA6 ZA7 ZA8 ZA9 ZA10 ZA11 ZA12 ZA13 ZA14 ZA15 ZA16 ZA17 ZA18 ZA19 ZA20 ZA21 ZA22 ZA23 ZA24 ZA25 ZA26 ZA27 ZA28 ZA29 ZA30 ZA31 ZA32 ZA33 ZA34 ZA35 ZA36 ZA37 ZA38 ZA39 ZA40 ZA41 ZA42 ZA43 ZA44 ZA45 ZA46 ZA47 ZA48 ZA49 ZA50 ZA51 ZA52 ZA53 ZA54 ZA55 ZA56 ZA57 ZA58 ZA59 ZA60 GLUE_MEZZ VCC GND LAD0 LAD1 LAD2 LAD3 LAD4 LAD5 LAD6 LAD7 GND LAD8 LAD9 LAD10 LAD11 LAD12 LAD13 LAD14 LAD15 GND ADS# LW/R# ALE NC READYi# CS0# CS1# NC GND LRESETo# BLAST# LCLK LINTIi1 GND LINTi2 LA6 LBE0# LBE1# LBE2# LBE3# GND LA7 LA8 LREQ LGNT LA11 LA12 GND GPIO4 GPIO5 GPIO6 GPIO7 GPIO8 LA18 GND LA19 LA20 RD# WR# LA23 M6C 3 GND LAD16 LAD17 LAD18 LAD19 LAD20 LAD21 LAD22 LAD23 GND LAD24 LAD25 LAD26 LAD27 LAD28 LAD29 LAD30 LAD31 GND NC NC NC NC NC GND TCK1 TDO1 TMS1 TDI1 TRES1 GND TCK2 TDO2 TMS2 TDI2 TRES2 GND GND GND GND NC NC GND GND VCC I2C1D I2C1C GND I2C2D I2C2C GND I2C3D I2C3C GND I2C4D I2C4C GND GND LA21 LA22 3 ZB1 ZB2 ZB3 ZB4 ZB5 ZB6 ZB7 ZB8 ZB9 ZB10 ZB11 ZB12 ZB13 ZB14 ZB15 ZB16 ZB17 ZB18 ZB19 ZB20 ZB21 ZB22 ZB23 ZB24 ZB25 ZB26 ZB27 ZB28 ZB29 ZB30 ZB31 ZB32 ZB33 ZB34 ZB35 ZB36 ZB37 ZB38 ZB39 ZB40 ZB41 ZB42 ZB43 ZB44 ZB45 ZB46 ZB47 ZB48 ZB49 ZB50 ZB51 ZB52 ZB53 ZB54 ZB55 ZB56 ZB57 ZB58 ZB59 ZB60 SDA SCL TCK TDO TMS TDI GND LAD16 LAD17 LAD18 LAD19 LAD20 LAD21 LAD22 LAD23 GND LAD24 LAD25 LAD26 LAD27 LAD28 LAD29 LAD30 LAD31 ZA61 ZA62 ZA63 ZA64 ZA65 ZA66 GND ZA67 +5V ZA68 ZA69 GND ZA70 ZA71 ZA72 ZA73 ZA74 ZA75 ZA76 ZA77 ZA78 ZA79 ZA80 ZA81 ZA82 ZA83 ZA84 ZA85 ZA86 GND ZA87 ZA88 ZA89 ZA90 GND ZA91 ZA92 GND ZA93 GND L W A I T n ZA94 ZA95 ZA96 ZA97 ZA98 ZA99 ZA100 ZA101 +5V ZA102 GND ZA103 GND ZA104 +5V ZA105 ZA106 ZA107 ZA108 LTERMn ZA109 ZA110 ZA111 ZA112 GND ZA113 GND ZA114 GND ZA115 ZA116 ZA117 ZA118 ZA119 ZA120 GND GND 4 GLUE_MEZZ GND DCDV1 MODE RXDV1 NC TXDV1 NC DTRV1 NC GND GND DSRV1 VCC RTSV1 NC CTSV1 GND RTV1 reserved GND reserved STROBE reserved AUTO reserved ERROR reserved INIT reserved SLCTIN reserved GND reserved DATA0 reserved DATA1 reserved DATA2 reserved DATA3 reserved DATA4 reserved DATA5 reserved DATA6 reserved DATA7 reserved GND GND ACKNOWL LA2 BUSY LA3 PAPERend LA4 SELECT GND VCC +3.3V in +3.3V in GND VCC GND GND GPIO0 VCC LA5 GND LA9 VCC LA10 GND LA13 RESET# NC GND NC NC VCC GND GND GND GND GND VCC +3.3V in GPIO1 +3.3V in GPIO2 +3.3V in GPIO3 +3.3V in BTERMi# +3.3V in LA14 +3.3V in LA15 +3.3V in LA16 NC GND GND GND VCC GND GND LA17 TCK3 BCLKo TDO3 JPWR1 TMS3 JPWR2 TDI3 JPWR3 TRES3 GND GND M6D 4 ZB61 ZB62 ZB63 ZB64 ZB65 ZB66 ZB67 ZB68 ZB69 ZB70 ZB71 ZB72 ZB73 ZB74 ZB75 ZB76 ZB77 ZB78 ZB79 ZB80 ZB81 ZB82 ZB83 ZB84 ZB85 ZB86 ZB87 ZB88 ZB89 ZB90 ZB91 ZB92 ZB93 ZB94 ZB95 ZB96 ZB97 ZB98 ZB99 ZB100 ZB101 ZB102 ZB103 ZB104 ZB105 ZB106 ZB107 ZB108 ZB109 ZB110 ZB111 ZB112 ZB113 ZB114 ZB115 ZB116 ZB117 ZB118 ZB119 ZB120 GND GND +5V LVCC_RX1 6 5 1 19 2 4 6 8 11 13 15 17 11 13 15 17 74HC244 1G 2G 1A1 1A2 1A3 1A4 2A1 2A2 2A3 2A4 U53 74HC244 1G 2G 1A1 1A2 1A3 1A4 2A1 2A2 2A3 2A4 U52 24LC00 nc nc nc GND U8 1Y1 1Y2 1Y3 1Y4 2Y1 2Y2 2Y3 2Y4 1Y1 1Y2 1Y3 1Y4 2Y1 2Y2 2Y3 2Y4 29-Jul-04 Z:\TFC\..\05 Glue card.SCHDOC Number Glue Card LVCC_RX1 19 JTAG_ENn 1 R147 1K GPIO6 2 GPIO7 4 GPIO5 6 GPIO8 8 R83 R131 1K 1K Date: File: B Size Title TMS TCK TDO TDI LVCC_RX1 LVCC_RX1 R32 1K R30 R31 1K 1K LVCC_RX1 Byte blasters for JTAG lines 1 2 3 4 ID EEPROM VCC nc SCK SDA 18 16 14 12 9 7 5 3 18 16 14 12 9 7 5 3 I2_TMS I2_TDO I2_TCK I2_TDI I1_TMS I1_TCK I1_TDO I1_TDI 6 Revision REV 2.2 by Andrea Borga Sheet of 5/11 Drawn By: Ramy Abdel-Rahman R139 33 R148 33 R81 33 LVCC_RX1 8 7 6 SCL 5 SDA TFC Test Board 5 D C B A “Freja”, A.Borga 83 D C B A 1 148 143 138 136 135 134 133 131 130 129 126 125 124 123 121 TTC_DOUTSTR TTC_SUBADDR7 TTC_SUBADDR6 TTC_SUBADDR5 TTC_SUBADDR4 TTC_SUBADDR3 TTC_SUBADDR2 TTC_SUBADDR1 TTC_SUBADDR0 TTC_BRCSTSTR1 TTC_BRCST2 TTC_BRCST3 TTC_BRCST4 TTC_BRCST5 LVCC_B 180 178 174 173 172 171 170 169 166 164 163 161 160 157 156 151 154 177 TTC_BRCST7 TTC_BRCST6 TTC_L1ACCEPT TTC_EVCNTRES TTC_BCNTRES TTC_READY TTC_DBERRSTR TTC_DOUT7 TTC_DOUT6 TTC_DOUT5 TTC_DOUT4 TTC_DOUT3 TTC_DOUT2 TTC_DOUT1 TTC_DOUT0 CLK CLK LVCC_B FREJA LVCC_B U9A 199 VCCIO7 I/O, DEV_OE (90) I/O, LOCK2 (98) I/O (108) I/O, LOCK4 (110) I/O (116) I/O (123) I/O (128) I/O (130) I/O (134) I/O (140) I/O (146) I/O (152) I/O (158) I/O (164) I/O (2) I/O (8) I/O (12) I/O (14) I/O (18) I/O (20) I/O (24) I/O, DATA6 (26) I/O, DATA7 (32) I/O, nWS (38) I/O (44) I/O, nRS (50) I/O, nCS (56) I/O, CS (69) I/O, DEV_CLRn (71) CLK2p (82) CLK4p (77) VCCIO8 VCCIO6 VCCIO6 LVCC_B 2 2 3 EP20K200EQC240-1X 3 LVCC_B 229 SRESn1 nBUFFER_RESET 212 209 FAST1 (447) FAST2 (454) I/O (168) I/O (169) I/O (170) I/O (171) I/O (173) I/O (175) I/O (176) I/O (177) I/O (179) I/O (180) I/O (181) I/O (183) I/O (184) I/O (185) I/O (186) I/O (187) I/O (190) I/O (191) I/O (193) I/O (194) I/O (195) I/O (197) I/O (198) I/O (200) 119 118 117 116 115 114 113 112 111 110 109 107 106 105 104 103 102 101 100 99 98 96 95 94 I/O (215) I/O (216) I/O (217) I/O (218) I/O (220) I/O (221) I/O (222) I/O (223) I/O (224) I/O (226) I/O (227) I/O (229) I/O (231) I/O (232) I/O (233) I/O (234) I/O (235) I/O (238) I/O (240) I/O (242) I/O (244) I/O (245) I/O (247) VCCIO1 181 BUFFER_OUT3 182 BUFFER_OUT2 183 BUFFER_OUT1 184 BUFFER_OUT0 185 BUFFER_OUT4 186 BUFFER_OUT5 187 BUFFER_OUT6 189 nBUFFER_FULL 190 nBUFFER_WE 191 BUFFER_OUT7 192 BUFFER_OUT8 193 BUFFER_OUT9 194 BUFFER_OUT10 195 BUFFER_OUT11 196 BUFFER_OUT12 197 BUFFER_OUT13 198 BUFFER_OUT14 200 BUFFER_OUT15 201 BUFFER_OUT16 202 BUFFER_OUT17 203 BUFFER_IN0 204 BUFFER_IN1 205 BUFFER_IN2 206 BUFFER_IN3 207 BUFFER_IN4 I/O, DATA5 (489) I/O (488) I/O (487) I/O (486) I/O, DATA4 (485) I/O (483) I/O (482) I/O, DATA3 (481) I/O (480) I/O (478) I/O (476) I/O (475) I/O (474) I/O, DATA2 (472) I/O (471) I/O (470) I/O (469) I/O, DATA1 (465) I/O (464) I/O (463) I/O (462) I/O, CLKUSR (461) I/O, RDYnBSY (459) I/O, INIT_DONE (458) I/O (457) LADSn LW/Rn LRDYn LRESETn LLASTn LWAITn LAD0 LAD1 LAD2 LAD3 LAD4 LAD5 LAD6 LAD7 LAD8 LAD9 LAD10 LAD11 LAD12 LAD13 LAD14 LAD15 LAD16 LAD17 120 97 215 BUFFER_IN5 216 BUFFER_IN6 217 BUFFER_IN7 219 BUFFER_IN8 220 BUFFER_IN9 221 BUFFER_IN10 222 BUFFER_IN11 223 BUFFER_IN12 224 BUFFER_IN13 225 BUFFER_IN14 226 BUFFER_IN15 227 BUFFER_IN16 228 BUFFER_IN17 230 nBUFFER_RE 231 nBUFFER_EMPTY 232 GP_LED1 233 CONF_FREJA 234 CHA 235 CHB 236 ECLTX4 237 ECLTX3 238 ECLTX2 239 ECLTX1 VCCIO3 I/O (322) I/O (319) I/O (318) I/O (311) I/O (305) I/O (301) I/O (299) I/O (295) I/O (293) I/O (287) I/O (281) I/O (279) I/O (275) I/O (269) I/O (264) I/O (259) I/O (257) I/O (251) I/O (407) I/O (401) I/O (395) I/O (391) I/O (389) I/O (385) I/O (383) I/O (377) I/O (371) I/O (365) I/O (359) I/O (357) I/O (353) I/O (351) I/O (347) I/O (345) I/O (341) I/O (333) VCCIO4 CLK1p (329) CLK3p (324) I/O (444) I/O (443) I/O (442) I/O (439) I/O (437) I/O (436) I/O (435) I/O (434) I/O (432) I/O (431) I/O (430) I/O (429) I/O (427) I/O (424) I/O (423) I/O (422) I/O (420) I/O (419) I/O (417) I/O (415) I/O (413) I/O (412) I/O (411) LAD18 85 LAD19 84 LAD20 83 82 LAD21 81 LAD22 80 LAD23 79 LAD24 77 LAD25 76 LAD26 75 LAD27 74 LAD28 73 LAD29 72 LAD30 71 LAD31 TTC_SINERRSTR 70 GP_LVDS IO33 69 GP_LVDS IO32 68 GP_LVDS IO31 66 GP_LVDS IO30 65 GP_LVDS IO29 64 GP_LVDS IO28 63 GP_LVDS_DE/RE3 62 GP_LVDS IO27 61 LVCC_B 45 31 34 LVCC_B GND LCLK 4 144 159 142 GND GND GND GND GND GND GND GND GND GND GND GND GND GND GND GND GND GND GND GND GND GND GND GND EP20K200EQC240-1X GND_CKLK2 (86/87) GND_CKLK4 (67/68) GND_CKOUT2 (92) VCC_CKLK2 (89) VCC_CKLK4 (66) VCC_CKOUT2 (91) VCCINT VCCINT VCCINT VCCINT VCCINT VCCINT VCCINT VCCINT VCCINT VCCINT VCCINT VCCINT VCCINT VCCINT VCCINT VCCINT U9C CLKLK_FB2p (75) CLKLK_OUT2p (93) CLKLK_ENA (328) DCLK (81) CONF_DONE (201) DATA0 (80) nCONFIG (327) nSTATUS (202) EP20K200EQC240-1X nCEO (446) nCE (83) MSEL0 (331) MSEL1 (330) TDI (84) TDO (455) TCK (213) TMS (214) TRST (445) U9B 1 5 14 27 39 52 60 90 122 127 140 145 168 176 179 210 VCCINT VCC_CKOUT VCC_CKIN GP_LVDS IO11 GP_LVDS_DE/RE1 GP_LVDS IO12 GP_LVDS IO13 GP_LVDS IO14 GP_LVDS IO15 GP_LVDS IO16 GP_LVDS IO17 GP_LVDS IO18 GP_LVDS IO19 GP_LVDS IO20 GP_LVDS_DE/RE2 GP_LVDS IO21 GP_LVDS IO22 GP_LVDS IO23 GP_LVDS IO24 GP_LVDS IO25 GP_LVDS IO26 35 36 37 40 41 43 44 46 47 48 49 50 53 54 55 57 58 59 LVCC_B ECLRX1 ECLRX2 ECLRX3 ECLRX4 OPTO_TX OPTO_RX GP_LVDS IO0 GP_LVDS IO1 GP_LVDS IO2 GP_LVDS_DE/RE0 GP_LVDS IO3 GP_LVDS IO4 GP_LVDS IO5 GP_LVDS IO6 GP_LVDS IO7 GP_LVDS IO8 GP_LVDS IO9 GP_LVDS IO10 2 3 4 7 8 9 10 11 13 16 17 18 20 21 22 23 24 25 12 LVCC_B 29 30 R27 10K 213 150 149 208 87 86 214 I1_TDI I1_TDO I1_TCK I1_TMS 4 147 158 141 6 15 19 26 28 38 42 51 56 78 89 108 128 132 137 146 162 165 167 175 188 211 218 240 VCC iVCC1 iVCC2 iVCC3 oVCC4 nc 3STn 5 Date: File: B Size Title L_SMD L2 L_SMD L1 GND EPC2 2 4 8 9 13 12 29-Jul-04 Z:\TFC\..\06 Q MP Supermodule.SCHDOC 1 3 5 7 9 0.01uF BAS16 D1 R134 10K nCONFIG DATA0 DCLK nSTATUS CONF_DONE VCCINT R29 10K HED_VCC J2X5 2 4 6 8 10 HED_VCC 0.01uF 0.1uF J1 C8 C6 VCC_CKOUT C7 0.1uF VCC_CKIN C5 6 Revision REV 2.2 by Andrea Borga Sheet of 6/11 Drawn By: Ramy Abdel-Rahman R28 10K R137 R138 1K 1K LVCC_RX1 R135 1K 100 R136 HED_VCC CP19 2.2uF CP17 10uF B48 0.01uF CP18 2.2uF CP16 10uF VCC DATA VPP DCLK VCCSEL OE VPPSEL nCS nINIT_CONF TMS nCASC TDI TDO TCK U54 Number +5V J3 J1X3 14 TCK 13 TDO TMS 12 11 TDI 10 9 8 JTAG_ENn Q MP Supermodule 10 19 11 1 3 LVCC_RX1 C9 20 0.01uF 18 5 14 +5V MAX3392E VL oVL1 oVL2 oVL3 iVL4 nc GND LVCC_RX1 LVCC_B VCCINT I2_TMS I2_TDI I2_TDO R82 33 I2_TCK LVCC_RX1 1 2 I2_TCK 3 I2_TMS 4 I2_TDI 5 I2_TDO 6 7 U32 VCCINT DCLK CONF_DONE DATA0 nCONFIG nSTATUS Programming EEPROM 155 139 32 152 93 153 33 92 6 TFC Test Board 5 3 VCCIO2 VCCIO5 67 FAST4 (203) FAST3 (212) 91 88 GP_LED2 LTERMn 1 84 2 1 D C B A “Freja”, A.Borga D C B A GP_LVDS_DE/RE1 GP_LVDS IO9 GP_LVDS IO10 GP_LVDS IO11 LVCC_RX GP_LVDS IO12 GP_LVDS IO13 GP_LVDS IO14 GP_LVDS IO15 GP_LVDS IO16 GP_LVDS IO17 GP_LVDS_DE/RE0 GP_LVDS IO0 GP_LVDS IO1 GP_LVDS IO2 LVCC_RX GP_LVDS IO3 GP_LVDS IO4 GP_LVDS IO5 GP_LVDS IO6 GP_LVDS IO7 GP_LVDS IO8 1 1 58 59 60 61 62 63 2 3 6 7 12 13 10 4 18 19 20 21 22 23 29 28 8 11 5 9 15 32 33 16 17 1 58 59 60 61 62 63 2 3 6 7 12 13 10 4 18 19 20 21 22 23 29 28 8 11 5 9 15 32 33 16 17 DS92LV090A NC Din 0 Rout 0 Din 1 Rout 1 Din 2 Rout 2 Din 3 Rout 3 Din 4 Rout 4 Din 5 Rout 5 VCC GND Din 6 Rout 6 Din 7 Rout 7 Din 8 Rout 8 AVcc AGND NC NC GND GND VCC AVCC AGND DE RE U12 DS92LV090A NC Din 0 Rout 0 Din 1 Rout 1 Din 2 Rout 2 Din 3 Rout 3 Din 4 Rout 4 Din 5 Rout 5 VCC GND Din 6 Rout 6 Din 7 Rout 7 Din 8 Rout 8 AVcc AGND NC NC GND GND VCC AVCC AGND DE RE U10 FREJA 1 R9 D9 R1 D1 R9 D9 R1 D1 NC AVCC AGND DO+/RI+ 0 DO-/RI- 0 DO+/RI+ 1 DO-/RI- 1 DO+/RI+ 2 DO-/RI- 2 DO+/RI+ 3 DO-/RI- 3 DO+/RI+ 4 DO-/RI- 4 VCC GND DO+/RI+ 5 DO-/RI- 5 DO+/RI+ 6 DO-/RI- 6 DO+/RI+ 7 DO-/RI- 7 DO+/RI+ 8 DO-/RI- 8 AVCC AGND NC VCC GND AVCC AGND VCC GND NC AVCC AGND DO+/RI+ 0 DO-/RI- 0 DO+/RI+ 1 DO-/RI- 1 DO+/RI+ 2 DO-/RI- 2 DO+/RI+ 3 DO-/RI- 3 DO+/RI+ 4 DO-/RI- 4 VCC GND DO+/RI+ 5 DO-/RI- 5 DO+/RI+ 6 DO-/RI- 6 DO+/RI+ 7 DO-/RI- 7 DO+/RI+ 8 DO-/RI- 8 AVCC AGND NC VCC GND AVCC AGND VCC GND 39 52 53 55 54 51 50 47 46 45 44 41 40 64 56 37 36 35 34 31 30 27 26 48 49 38 57 25 42 43 24 14 39 52 53 55 54 51 50 47 46 45 44 41 40 64 56 37 36 35 34 31 30 27 26 48 49 38 57 25 42 43 24 14 2 LVCC_RX LVCC_RX 2 R65 100 R51 100 R49 100 R33 100 R64 100 R53 100 R47 100 R35 100 R63 100 R55 100 R45 100 R37 100 R61 100 R57 100 R43 100 R39 100 3 3 GP_LVDS12+ GP_LVDS12GP_LVDS11+ GP_LVDS11GP_LVDS10+ GP_LVDS10GP_LVDS9+ GP_LVDS9- R59 100 GP_LVDS13- GP_LVDS13+ GP_LVDS17+ GP_LVDS17GP_LVDS16+ GP_LVDS16GP_LVDS15+ GP_LVDS15GP_LVDS14+ GP_LVDS14- GP_LVDS3+ GP_LVDS3GP_LVDS2+ GP_LVDS2GP_LVDS1+ GP_LVDS1GP_LVDS0+ GP_LVDS0- R41 100 GP_LVDS4- GP_LVDS4+ GP_LVDS8+ GP_LVDS8GP_LVDS7+ GP_LVDS7GP_LVDS6+ GP_LVDS6GP_LVDS5+ GP_LVDS5- GP_LVDS_DE/RE3 GP_LVDS IO27 LVCC_RX GP_LVDS IO28 GP_LVDS IO29 GP_LVDS IO30 GP_LVDS IO31 GP_LVDS IO32 GP_LVDS IO33 GP_LVDS_DE/RE2 GP_LVDS IO18 GP_LVDS IO19 GP_LVDS IO20 LVCC_RX GP_LVDS IO21 GP_LVDS IO22 GP_LVDS IO23 GP_LVDS IO24 GP_LVDS IO25 GP_LVDS IO26 1 58 59 60 61 62 63 2 3 6 7 12 13 10 4 18 19 20 21 22 23 29 28 8 11 5 9 15 32 33 16 17 1 58 59 60 61 62 63 2 3 6 7 12 13 10 4 18 19 20 21 22 23 29 28 8 11 5 9 15 32 33 16 17 4 DS92LV090A NC Din 0 Rout 0 Din 1 Rout 1 Din 2 Rout 2 Din 3 Rout 3 Din 4 Rout 4 Din 5 Rout 5 VCC GND Din 6 Rout 6 Din 7 Rout 7 Din 8 Rout 8 AVcc AGND NC NC GND GND VCC AVCC AGND DE RE U13 DS92LV090A NC Din 0 Rout 0 Din 1 Rout 1 Din 2 Rout 2 Din 3 Rout 3 Din 4 Rout 4 Din 5 Rout 5 VCC GND Din 6 Rout 6 Din 7 Rout 7 Din 8 Rout 8 AVcc AGND NC NC GND GND VCC AVCC AGND DE RE U11 4 R9 D9 R1 D1 R9 D9 R1 D1 NC AVCC AGND DO+/RI+ 0 DO-/RI- 0 DO+/RI+ 1 DO-/RI- 1 DO+/RI+ 2 DO-/RI- 2 DO+/RI+ 3 DO-/RI- 3 DO+/RI+ 4 DO-/RI- 4 VCC GND DO+/RI+ 5 DO-/RI- 5 DO+/RI+ 6 DO-/RI- 6 DO+/RI+ 7 DO-/RI- 7 DO+/RI+ 8 DO-/RI- 8 AVCC AGND NC VCC GND AVCC AGND VCC GND NC AVCC AGND DO+/RI+ 0 DO-/RI- 0 DO+/RI+ 1 DO-/RI- 1 DO+/RI+ 2 DO-/RI- 2 DO+/RI+ 3 DO-/RI- 3 DO+/RI+ 4 DO-/RI- 4 VCC GND DO+/RI+ 5 DO-/RI- 5 DO+/RI+ 6 DO-/RI- 6 DO+/RI+ 7 DO-/RI- 7 DO+/RI+ 8 DO-/RI- 8 AVCC AGND NC VCC GND AVCC AGND VCC GND 39 52 53 55 54 51 50 47 46 45 44 41 40 64 56 37 36 35 34 31 30 27 26 48 49 38 57 25 42 43 24 14 39 52 53 55 54 51 50 47 46 45 44 41 40 64 56 37 36 35 34 31 30 27 26 48 49 38 57 25 42 43 24 14 LVCC_RX LVCC_RX 6 5 Date: File: B Size Title R52 100 R50 100 R34 100 R140 100 R56 100 R46 100 R38 100 R62 100 R58 100 R44 100 R40 100 GP_LVDS22+ 6 Revision REV 2.0 by Andrea Borga Sheet of 7/11 Drawn By: Ramy Abdel-Rahman GP_LVDS28+ GP_LVDS28GP_LVDS27+ GP_LVDS27- R60 100 GP_LVDS29- GP_LVDS29+ GP_LVDS33+ GP_LVDS33GP_LVDS32+ GP_LVDS32GP_LVDS31+ GP_LVDS31GP_LVDS30+ GP_LVDS30- GP_LVDS21+ GP_LVDS21GP_LVDS20+ GP_LVDS20GP_LVDS19+ GP_LVDS19GP_LVDS18+ GP_LVDS18- R42 100 GP_LVDS22- 4/28/2004 C:\Andy\..\07 LVDS transceivers.SCHDOC Number LVDS Tranceivers R54 100 R48 100 R36 100 GP_LVDS26+ GP_LVDS26GP_LVDS25+ GP_LVDS25GP_LVDS24+ GP_LVDS24GP_LVDS23+ GP_LVDS23- TFC Test Board 5 D C B A “Freja”, A.Borga 85 D C B A 1 2 VEE- 5 VBB 4 0.1uF 100EL16 6 B17 3 8 7 R77 2.7k VCC+ 2 R76 50 U25 ECL_RX4 1 VEE- 5 VBB 100EL16 4 0.1uF B16 6 3 R73 50 R74 2.7k 7 8 +5V 3 2 3 +5V 4 7 8 9 5 6 Q1 Q1 Q0 Q0 100LVEL92 D2 Q2 D2 Q2 PECL->LVPECL Vbb Vbb D1 D1 D0 D0 U31 VCC+ Q1 Q1 Q0 Q0 RN1 D2 Q2 D2 Q2 PECL->LVPECL Vbb Vbb D1 D1 D0 D0 U30 U24 2 ECL_RX3 1 4 7 8 9 5 6 2 3 100LVEL92 VEE- 5 VBB +5V +5V 100EL16 4 0.1uF B15 6 7 3 VCC+ 8 2 R70 50 U23 100EL16 R71 2.7k 1 ECL_RX2 0.1uF 5 VEE- 6 VBB 4 R67 50 3 B14 R68 2.7k 7 8 2 VCC+ ECL_RX1 1 U22 +5V 1 2 3 4 5 6 7 8 FREJA 10 86 9 3 R2 81 2 R1 130 C 1 13 12 16 15 19 18 13 12 16 15 19 18 4 4 10 9 8 7 6 5 4 3 2 LVCC_RX 1 R2 81 R1 C 130 RN2 6 5 Date: File: B Size Title 3 4 4 4 4 3 Number 33 R66 33 R69 33 R72 5 6 7 33 R75 LVCC_RX 8 5 6 7 LVCC_RX 8 5 6 7 LVCC_RX 8 5 6 7 LVCC_RX 8 29-Jul-04 Z:\TFC\..\08 ECL receivers RP.SCHDOC VEE NC TTL LVCC 100EPT21 Vbb PECL NC U17 VEE NC TTL LVCC 100EPT21 Vbb PECL NC U16 VEE NC TTL LVCC 100EPT21 Vbb PECL NC U15 VEE NC TTL LVCC 100EPT21 Vbb PECL NC U14 ECL Reveivers 0.01uF B9 2 1 0.01uF B8 3 2 1 0.01uF B7 3 2 1 0.01uF B6 2 1 6 Revision REV 2.2 by Andrea Borga Sheet of 8/11 Drawn By: Ramy Abdel-Rahman ECLRX4 ECLRX3 ECLRX2 ECLRX1 TFC Test Board 5 D C B A “Freja”, A.Borga D C B A R95 R96 R97 ECLTX2 ECLTX3 ECLTX4 1 R93 ECLTX1 33 33 33 33 5 6 7 LVCC_RX 8 5 6 7 LVCC_RX 8 100EPT22 LVTTL LVPECL U38 100EPT22 LVTTL LVPECL U37 4 3 2 1 4 3 2 1 2 RN5 10 9 8 7 6 5 4 3 2 LVCC_RX 1 R2 81 RN6 R1 C 130 R1 C 130 FREJA R2 81 2 3 +5V 1 2 3 4 5 6 7 8 9 10 +5V 3 1 2 3 4 5 6 7 8 9 10 1 100EP17 VBB VCC U39 GND VCC +5V 20 19 18 17 16 15 14 13 12 11 4 4 +5V +5V +5V +5V 100EL12 5 4 3 -GND 2 6 1 7 + +5V U36 100EL12 -GND 3 4 2 6 1 7 + +5V U35 100EL12 4 3 6 -GND 2 1 7 + +5V U34 100EL12 -GND 3 4 2 6 1 7 + +5V U33 6 Date: File: B Size Title ECL_TX4 +5V ECL_TX3 +5V ECL_TX2 +5V ECL_TX1 29-Jul-04 Z:\TFC\..\09 ECL transmitters RP.SCHDOC Number ECL Transmitter 120 R101 82 R100 120 R99 82 R98 120 R94 82 R92 120 R91 82 R90 +5V 6 Revision REV 2.2 by Andrea Borga Sheet of 9/11 Drawn By: Ramy Abdel-Rahman TFC Test Board 5 D C B A “Freja”, A.Borga 87 D C B A Internal clock 1 +5V 7 14 100nF C21 C22 0.1uF EXTclkLEM BCLKBCLK+ TTCrs clock External clock CLOCK40DES1 TTCrmclock 1 8 R127 R128 120 120 R121 R122 82 82 +5V B26 100EL16 0.1uF 4 1 4 3 2 2 2 GND- R S VCC+ R106 R107 82 82 R102 R103 120 120 LVCC_RX1 100EL31 U48 5 6 8 3 VEE- VCC+ 7 VBB U42 4 3 2 1 TRASL1 TRASL2 2 1 100EPT22 LVTTL LVPECL U45 80 MHz U49 R118 240 R117 62 +5V 5 6 7 8 LVCC_RX1 FREJA Clocktanslators 5 6 7 8 +5V R126 120 R123 82 +5V R119 R120 120 120 R115 R116 82 82 4 3 2 1 VBB U43 FICLK 100EL16 5 6 7 8 LVCC_RX1 B27 0.1uF VEE NC TTL LVCC 100EPT21 Vbb PECL NC U40 B23 0.01uF +5V 4 3 2 1 VEE- VCC+ 5 6 7 8 +5V TRASL3 TRASL4 3 R129 R130 120 120 R124 R125 82 82 3 B28 0.1uF 4 7 8 9 5 6 2 3 R108 R109 82 82 R104 R105 120 120 4 3 2 1 Q1 Q1 Q0 Q0 B24 0.01uF 100LVEL92 13 12 16 15 19 18 VEE NC TTL LVCC 100EPT21 Vbb PECL NC U41 D2 Q2 D2 Q2 PECL->LVPECL Vbb Vbb D1 D1 D0 D0 U44 LVCC_RX1 5 6 7 8 4 CLK LVCC_RX1 4 8 9 6 7 4 5 2 3 10 9 8 7 6 5 4 3 2 LVCC_RX1 1 100EP57 U46 GND VCC R2 81 VBB1 VBB2 SEL1 SEL2 RN7 F_LCLK1 F_LCLK2 5 Local bus clocksource R1 C 130 13 12 16 15 19 18 6 Date: File: B Size Title 1 2 3 4 GND 1/2 U26 3 4 5 TERMF_LCLK1 F_LCLK2 4 3 2 1 10 9 8 7 6 2 LVCC_RX1 1 TERM+ LVCC_RX1 8 7 6 5 1 100LVEP14 SEL GND VBB VCC VCC 0 100EPT22 U47 29-Jul-04 Z:\TFC\..\10 Clock business.SCHDOC Number Clock business VBB 100EP32 U20 RES VCC 0.01uF B25 20 19 18 17 16 15 14 13 12 11 LVCC_RX1 LVCC_RX1 R114 1K R112 R113 82 82 R110 R111 120 120 LVCC_RX1 1 2 3 4 5 6 7 8 LCLK 6 Revision REV 2.2 by Andrea Borga Sheet of 10/11 Drawn By: Ramy Abdel-Rahman VEE NC TTL LVCC_RX1 R1 C 130 RN8 TRASL1 TRASL2 TRASL3 TRASL4 F_LCLK1 F_LCLK2 SEL2 SEL1 LVCC 100EPT21 Vbb PECL NC U7 R2 81 1 2 3 4 5 6 7 8 9 10 8 7 6 5 LVCC_RX1 TFC Test Board 5 TERM+ TERM- 88 LVTTL LVPECL 1 D C B A “Freja”, A.Borga D C B A 1 B121 0.01uF B40 0.01uF B81 0.01uF B70 0.01uF B29 0.01uF BAD_PWRn BAD_PWR CLOCK40DES2 GP_LED2 GP_LED1 CONF_FREJA +5V LED driver VCCINT LVCC_RX1 LVCC_RX1 LVCC_RX +5V Blocking capacitors 1 2 3 4 5 6 7 8 9 10 B59 0.01uF 0.01uF B83 74LS641 DIR A1 A2 A3 A4 A5 A6 A7 A8 GND U50 B123 0.01uF B96 0.01uF B84 0.01uF B92 0.01uF B33 0.01uF VCC VCC G B1 B2 B3 B4 B5 B6 B7 B8 B31 0.01uF B102 0.01uF B122 0.01uF B73 0.01uF B82 0.01uF B74 0.01uF B30 0.01uF FREJA 20 19 18 17 16 15 14 13 12 11 +5V B35 0.01uF B98 0.01uF B86 0.01uF B94 0.01uF B124 0.01uF B97 0.01uF B85 0.01uF B93 0.01uF B34 0.01uF LED1 LED2 LED3 LED4 LED5 LED6 2 B125 0.01uF B10 0.01uF B87 0.01uF B95 0.01uF B36 0.01uF 2 B126 0.01uF B13 0.01uF B89 0.01uF B38 0.01uF B127 0.01uF B60 0.01uF B90 0.01uF B41 0.01uF a-r LED5 a-r a-r General purpose LED not OK LED2 D3 a-g D5 a-g a-g Power Supply monitor LED D2 B12 0.01uF B88 0.01uF B19 0.01uF B37 0.01uF LED4 OK LED1 B120 0.01uF B61 0.01uF B42 0.01uF B20 0.01uF B62 0.01uF B43 0.01uF B49 0.01uF a-r 3 a-r FPGA programmed Clockpresent B50 0.01uF a-g D6 a-g D4 B117 0.01uF B65 0.01uF B128 0.01uF B116 0.01uF B64 0.01uF LVCC_B B115 0.01uF B63 0.01uF B44 0.01uF 3 LED6 LED3 B129 0.01uF B118 0.01uF B103 0.01uF B51 0.01uF +5V B53 0.01uF 330 RP2 330 RP1 B76 0.01uF B105 0.01uF B130 0.01uF B75 0.01uF B104 0.01uF B52 0.01uF B131 0.01uF B77 0.01uF B106 0.01uF B54 0.01uF 4 LED5 LED6 LED1 LED2 LED3 LED4 B56 0.01uF B79 0.01uF B119 0.01uF B132 0.01uF B78 0.01uF B107 0.01uF B55 0.01uF 4 B108 0.01uF B100 0.01uF B58 0.01uF B134 0.01uF B109 0.01uF B101 0.01uF B32 0.01uF OPTO_TX GND 2 1 3 74F5300 IN ENB 0.1uF U29 VCC 3 2 OUT SFH551/1-1V P7 33 R78 +5V B46 +5V B110 0.01uF 5 6 B112 0.01uF B111 0.01uF +5V 5 OUT Date: File: B Size Title 1 2 3 4 5 6 7 MAX3392E VL oVL1 oVL2 oVL3 iVL4 nc GND U27 4 R145 B67 0.01uF LVCC_RX 14 13 GND 12 GND 11 GND 10 9 8 R143 90 +5V B66 0.01uF B22 0.01uF VCC iVCC1 iVCC2 iVCC3 oVCC4 nc 3STn B114 0.01uF B21 0.01uF B136 120pF 14 R144 B113 0.01uF B137 0.01uF B18 0.01uF 06-Aug-04 Z:\TFC\..\11 Blocking capacitors.SCHDOC Number Blocking Capacitors and LED +5V 6 10uF B71 B47 0.01uF B11 0.01uF B72 0.01uF B45 0.01uF 33 R146 OPTO_RX SFH750 O1 6 Revision REV 2.2 by Andrea Borga Sheet of 11/11 Drawn By: Ramy Abdel-Rahman 1 2 B91 10uF B68 0.01uF TFC Test Board B135 0.01uF B39 0.01uF B69 0.01uF Optical Transmitter and Receiver B133 0.01uF B80 0.01uF B99 0.01uF B57 0.01uF 1 +5V 8 +5V 1 D C B A “Freja”, A.Borga 89 90 104 108 10C 110 114 200 204 208 20C 210 214 218 21C 220 224 228 22C 230 234 238 23C 240 244 248 24C 250 254 258 25C 260 2FC 02C 030 034 038 050 054 058 05C 060 080 084 100 00C 010 014 020 024 028 008 Address 000 004 Bits 0 0 1 2 3 11 … 4 0 1 2 3 3 ... 0 3…0 31 … 0 12 … 0 0 5…0 13 … 8 15 … 0 15 … 0 11 … 0 11 ... 0 23 … 0 5…0 5…0 15 … 0 15 … 0 5 ... 0 11 … 0 0 1 13 … 0 1…0 3…0 11 … 0 1…0 31 ... 0 31 ... 0 31 ... 0 31 ... 0 31 ... 0 31 ... 0 31 ... 0 31 ... 0 11 ... 0 31 ... 0 31 ... 0 31 ... 0 31 ... 0 31 ... 0 31 ... 0 31 ... 0 31 ... 0 31 ... 0 31 ... 0 31 ... 0 31 ... 0 31 ... 0 31 ... 0 31 ... 0 15 ... 0 15 … 0 Register i_update ALL_COUNTER_RESET TTCRX_RESET EXT_BUFFER_RESET L0FIFO_RESET COUNTRES_REG R_L0PER_ENB R_L0RND_ENB R_L1PER_ENB R_L1RND_ENB ECL_W_ENABLE LVDS_RW_ENABLE TEST_REG P_BID_ERR_INJ R_L0FIFO_GUARD_EN P_TRNUM P_TRSPC P_L0RND_SEED P_L0RND_THRESH P_BID_L0DU_OFFSET P_ORBIT_LEN P_L1_LATENCY P_L1_SPACE P_L1_ACCEPT_RATIO P_L1RND_SEED P_L1RND_THRESH P_FE_ROTIME R_SYNCH_CHECK R_L0FIFO_EMPTY R_L0FIFO_FULL R_L0FIFO_OCC R_FE_FIFO_MON R_FE_FIFO_OCC R_FE_FIFO_DATA R_EXT_FIFO_MON C_BCNTRES C_EVCNTRES C_L0ACCEPT_LOW C_L0ACCEPT_HIGH C_L0TRIGGER_LOW C_L0TRIGGER_HIGH C_L1TRIGGER_LOW C_L1TRIGGER_HIGH C_BID C_CMD_L0ERST C_CMD_L01ERST C_CMD_L1TRG C_CMD_CALIB C_CMD_OTHERS C_L1TRG_REJECT C_L1TRG_PHYSICS C_L1TRG_RANDOM C_L1TRG_PERIODIC C_L1TRIG_CALIB C_L1TRG_OTHERS C_L1_DEST_MO C_L1_DEST_FLUSH_MO C_HLT_DEST_MO C_HLT_DEST_FLUSH_MO C_LONG_BROADCAST C_VERSION bit 0: fifo empty bit 1: fifo full (both active LOW) Front End EXTERNAL fifo monitor Bunch counter reset counter Event counter reset counter Total number of L0 trigger accepts L0 triggers SENT from Freja L1 triggers SENT from Freja Bunch IDs generated by Freja CHB decoder CHB decoder CHB long broadcast decoder Full long broadcast Release version control register RO RO RO RO RO RO RO RO RO RO RO L1 destination assignmennt counter L1 MEP flush counter HLT destination assignment counter HLT MEP flush counter L0 front end electronics reset L0 + L1 front end electronics reset L1 trigger broadcast Calibration command Other type of trigger bit 0: fifo empty bit 1: fifo full (both active LOW) Depending on the cable: 10 mt [25]; short [23] Can be switched off when running L0s only, to force overflows Check plus or minus bits Check plus or minus bits 1' transmitters '0' receivers bit 0: l0accept bit 1: bcntres bit 2: evcntres bit 3: l0trg bit 4: cmd bit 5: trg bit 6: l1trg bit 7: Lbrcst Front End INTERNAL fifo (derandomizer) monitor RO trigger generator trigger generator trigger generator trigger generator Remark Updates in both read and write (not sensible to write) FREJA registers (Base address 0x1000) ECL transimetters enable LVDS transceivers enable Local bus 32 bit test register Error injector for bunch ID check Overflow L0/L1 interface buffer control Number of L0 triggers (L0 DU) Number of L0 spaces (L0 DU) L0 random generator starting seed L0 random generator threshold Programmable offset for L0 DU bunch counter Adjustable orbit length for L0 DU bunch counter and orbit generator L1 periodic trigger generator latency (Latency timer) L1 periodic trigger generator spaces (RO timer) L1 periodic trigger generator threshold L1 random generator starting seed L1 random generator threshold Derandomizer read out timer (FE) Crossing & Bunch ID synchronization check L0 to L1 interface fifo flags L0 periodic L0 random L1 periodic L1 random Read/Write Explanation Update registers Clear all counters in freja's modules TTC rx reset line [DEB] 20 [14] 35 [23] 25 [19] [CAFE] [F5C1] 35 [23] 0 01 [01] 34 [22] [CAFE] [F998] 0 15 [F] Default 0 “Freja”, A.Borga 12 APPENDIX B - Registers list “Freja”, A.Borga 13 APPENDIX C - Backup CD The CD contains the whole software material developed for the project: • • • • • • PCB project: both board version complete from schematics to gerber files VHDL source code of the TFC full system simulation C++ test scripts PVSS control interface project Excel table for the register configuration Electronic version of this note It also contains most of the documents, application notes and manuals mentioned in the note grouped by topics in different folders. You will also find additional information about me and my hobbies in a CV and in the “personal interests” folder. 91 “Freja”, A.Borga 92 “Freja”, A.Borga 14 APPENDIX D – Norse Mythology A bit of Scandinavian mythology to give a better understanding of all the fancy names given to the TFC boards. Figure 74: Swedish gods’ family tree. Scandinavian deities live in the garden of gods named Asgård. Odin is the supreme god: his wisdom came when his drank from the source of knowledge. Freja is his mistress, deity of beauty and fertility. But not without a bit of trickiness to test Odin’s patience! Thor is his son riding in the sky. With his enchanted chariot he creates lightings, and with his legendary hammer he makes thunders. Odin has two ravens, Munin and Hugin, which he sends all over the world to collect information. Figure 75: Odin the god of all gods. For more information about the topic refer to http://en.wikipedia.org/wiki/Main_Page . 93