Beker, H

Carena, W

Csató, P

Divià, R

Harangozo, G

Kiss, T

Macowicz, M

Meggyesi, Z

Novák, I

Rubin, G

Szendrei, L

Van de Vyvre, P

Vascotto, Alessandro

Vesztergombi, G

CERN Document Server

Preprint submitted to Elsevier Preprint 14 February 1997Report on the ALICE Detector Data Link: method used,protocol and design statusP.Csató, T.Kiss, Z.Meggyesi, G.Rubin, L.Szendrei, G.VesztergombiResearch Institute for Particle and Nuclear Physics (RMKI), Budapest, HungaryG.Harangozó, J.Harangozó, I.NovákTechnical University of Budapest (BME), HungaryH.Beker, W.Carena, R.Divià, M.Macowicz, A.Vascotto, P.Vande VyvreCERN, Geneva, SwitzerlandALICE COLLABORATIONThe future LHC experiments are planning to use more than 200.000 links for the connection ofthe different layers of the front-end electronics (FEE) and the data-acquisition system. Thereare several applications where industrial products can be used. However, in case of specificrequirements special solutions are needed by the experiments. CERN, RMKI and BME aredeveloping a new link (called detector data link or DDL) for the special needs of the ALICEexperiment. This link will provide high-speed transmission of data blocks (e.g. event data,thresholds, pedestals) in both directions between the FEE and the data-acquisition system. TheDDL can also be used as a transmission medium for the remote control of the FEE during thenormal operation and for the remote debugging during the system integration of the ALICEdetector. In this paper we present the concept of the DDL and the methods used for itsdevelopment.1. IntroductionThe ALICE [1] detector data link (DDL) will interface the front-end electronics (FEE) of allthe sub-detectors to the read-out receiver cards (RORC) of the data-acquisition system. Thesource interface units (SIU) are connected to the FEEs and placed inside the detector. Thedestination interface units (DIU) are connected to the RORCs, located in the counting roomabout 200 meters from the detector. The two DDL interface units are connected through thephysical medium which is a duplex optical fibre. The complete ALICE data-acquisitionsystem will consists of about 700 DDLs. Figure 1 shows the DDL concept.Front-EndElectronics(FEE)Front-EndElectronics(FEE)SourceInterfaceUnit (SIU)DestinationInterfaceUnit (DIU)Read-OutReceiverCard(RORC)Read-OutReceiverCard(RORC)DDL DIU-RORC InterfacePhysical and Signalling InterfaceDDL SIU-FEE InterfaceDDL  Hardware = Source Interface Unit + Physical Medium + Destination Interface UnitPhysical MediumDDL Specification = DDL Interface Control Document + Physical and Signalling Interface SpecificationALICEDETECTORCOUNTINGROOMFigure 1 The DDL concept2. Development MethodA formal approach is being followed for the specification and development of the DDL. TheESA PSS-05 software engineering standard [2] has been used for the preparation of the User2Requirement Document [3], the Interface Control Document [4] and the Physical andSignalling Interface Specification Document [5].The LOTOS formalism [6] has been chosen for the formal description, simulation andverification of the DDL protocol The VHDL hardware description language [7] is being usedfor the simulation of the DDL.2.1 User RequirementsThe main data flow will take place from the FEE to the RORC. The 700 DDLs shall transmitin total 2.5 GByte/s event data from the FEE to the RORC with a detected bit error rate of< 10-15. Each DDL shall be able to transmit data at a rate of 100 MByte/s. As the zerosuppression algorithm requires downloading blocks of data into the FEE, a throughput of10 MByte/s is needed in the opposite direction.Both the FEE and the SIU shall be remotely controlled by the RORC through the DDL, sincetheir placement inside the detector will not allow using any other cabling apart from the DDLmedium. Therefore, commands and status information shall also be transmitted between theFEE and the RORC. Figure 2 shows the required information transfer between the DDL andthe external systems.ALICE-DDLFEE RORCFront-end StatusFront-end CommandData BlockData BlockData BlockData BlockFront-end CommandInterface CommandInterface Error StatusCommand Transmisssion StatusData Transmission StatusFront-end StatusFigure 2 The information transfer between the DDL and the external systemsSince the SIU is located inside the detector, the requirements for the lifetime (> 10 years), thepower consumption (< 5W) and the footprint (< 50 cm2) of this unit are key issues. Morestrict requirements have been identified for the ITS sub-detector [1] where radiation tolerantelectronics is needed and the maximum footprint of the SIU shall be less than 15 cm2.To achieve the high reliability of the experimental apparatus, efficient test of all thesub-systems shall be provided. The DDL shall allow to test the FEE remotely by using JTAGBoundary-scan Testing procedure [8]. The DDL itself shall also have a powerful self-testmode.2.2 Interface SpecificationThe FEE-SIU and RORC-DIU interfaces are described in the Interface Control Document.The definition includes the physical and electrical description of the interface units, theinterface signal description, the definition of the information structures, the interface protocoland the interface timing.2.3 Physical Medium SpecificationIn the Physical and Signalling Interface Specification Document the different layers of thecommunication protocol on the physical medium have been described. The Fibre Channelstandard (FCS) has been chosen [9] for the first implementation. The choice of FCS wasmotivated by its very robust physical and coding layers and by the availability of cheaphigh-performance components.32.4 Protocol Simulation and VerificationOne of the most important phases of the DDL development is the test of the data transmissionprotocol used between the FEE and the RORC. It allows us to verify whether:• the protocol is capable of serving all the requirements of the information transfer;• the protocol is properly defined;• there is any inconsistency or redundancy in the protocol.We intend to study the DDL protocol using LOTOS: no deadlocks or endless cycles shouldoccur on any error condition and the system should be able to recover from any illegal stateafter a given time-out period.VHDL will be used to check whether the DDL level protocol can be mapped to the physicalmedium protocol and to study how the timing of the physical medium level informationtransfer influences the DDL level. The VHDL model will then be used in the digital systemdesign and simulation phase of the DDL development project.2.4.1 Formal Description of the DDL Protocol using LOTOSThe LOTOS language and the LOTOS tools are used for the formalisation and the validationof the protocol. The DDL protocol has been described in an informal way [6]. A validationmodel shall be constructed from this informal description. In the formal description of theDDL protocol, the FEE and the RORC are the service users and the DDL is the serviceprovider. The ports between the SIU - FEE and the DIU - RORC will be defined as serviceaccess points. In the first design step (called physical decomposition) the FEE, RORC andDDL components will be specified as black boxes. These components will be defined asLOTOS processes with their mutual gates synchronised in all events (see Figure 3).FEE DDL RORCmutual gates mutual gatesDDL protocolFigure 3 The physical decompositionThe next design step is a functional decomposition of the black-box models and theirinterfaces into more complex (white box) models following the stepwise refinement process.The highest level procedures will be the data transmission protocol between the FEE and theRORC as well as the self-test protocol of the DDL. The highest procedures will use lowerlevel processes which are the data block transmission protocol with flow control, thecommand transmission protocol and the status read-out protocol. For the validation of theformal description of the protocols, all the components must be able to generate no validcommands and data blocks as well as wrong or missing answers.2.4.2 Simulation of the DDL by using VHDLThe VHDL hardware description language supports different abstraction levels to modeldigital electronic systems. In the DDL simulation, we three levels: the test environment, thesignals of the DDL interfaces and the physical medium. The simulation model of the DDL isshown in Figure 4.4FEEsourcefileFEEdestin.fileFEESIUDIURORCRORCsourcefileRORCdestin.filePhysical medium levelDDL levelTest environmentFigure 4 Simulation model of the DDL protocol testThe physical medium level simulation is conforming to the DDL Physical and SignallingInterface Specification Document [5]. The test of the DDL includes the test of the physicalmedium. The physical medium layer shall carry all the information provided by the DDLlayer. The DDL level simulation is conforming to the Interface Control Document [4]. Thetest environment provides a convenient way to control the information transfer on the DDLand to test the proper operation of the DDL signals. The stimuli are read from source filesand the results are written to destination files on both sides of the DDL. The stimuli consist ofcombinations of commands and data blocks. The results consist of status words and datablocks according to the response of the simulation model.3. ConclusionsThe development phase of the DDL project has just started. Therefore it is too early to giveconclusions on the usage of LOTOS and VHDL for the protocol design, simulation andverification. Our first experience with a formalised way of collecting user's requirements hasbeen very stimulating. The definition of the interface has been an iterative processaccomplished in close contact with the users.4. References1. The ALICE Technical Proposal; CERN/LHCC 95-71, ISBN 92-9083-077082. Software Engineering Standard; ESA PSS-05, ISBN 0-13-106568-83. ALICE-DDL User Requirement Document; ALICE/96-42, Internal Note/DAQ, 12.12.19964. ALICE-DDL Interface Control Document; ALICE/96-43, Internal Note/DAQ, 12.12.19965. ALICE-DDL Physical and Signalling Interface Specification Document; ALICE/97-04,Internal Note/DAQ, 14.02.19976. LOTOS - Formal Description Technique based on the Temporal Ordering of ObservationalBehaviour, ISO/IEC 88077. VHDL Harware Description Language; IEEE-10768. Test Access Port (TAP) and Boundary-scan Architecture; IEEE 1149.19. Fibre Channel Physical and Signalling Interface; ANSI X3.230-1994

Report on the ALICE Detector Data Link: method used, protocol and design status

Report on the ALICE Detector Data Link: method used, protocol and design status

Abstract

Similar works

Full text

Available Versions

CERN Document Server