Online clock software status T.Blažek, V.Černý, M.Krivda, R.Lietava, M.Mojžiš Bratislava, Birmingham Brussels meeting, September 2010 1

Trigger and LTU (local trigger unit) Triggers L0 processor 40 MHz clock source Trigger inputs CHOKE/ ERROR Clock + Triggers TTC partition LTU + TTCex LTU + TTCex LTU + TTCex LTU + TTCex . . . . . . . . . . . . . . . . . . . . . . . TTCrx TTCrx TTCrx TTCrx . . . . . . . . . . . . . . . . . . . . . . . QPLL QPLL QPLL QPLL FEE FEE FEE FEE 2

LTU: where it sits devel. phase: in the lab, where the subdetector is developed prod. phase: in the experimental area, all LTU’s together VME processor LTU 4

LTU access VME processor VME driver LTU Outer world communicates with VME processor via TCP/IP LTU access VME processor VME driver LTU VME driver maps VME address space into pc address space LTU is controlled be reading and writing registers in the VME address space 5

LTU software supports 1.testing : support for testing the produced LTU boards for hardware errors 2.run-time: support for run-time control mechanisms 3.slow control: support for communication with slow control system 4.standalone: support for subdetector control and development L0 emulation and communication monitoring 5.expert :support full access of an expert to the LTUs 7

DIM client server architecture VME processor VME driver LTU development phase DIM server 8

VME processor VME driver LTU LTU LTU LTU LTU LTU DIM architecture DIM clients DIM clients DIM clients VME processor VME driver LTU LTU LTU LTU LTU LTU DIM server DIMserver DIM architecture DIM server DIM server DIM server DIM server 9

beta.cern.ch alpha.cern.ch gamma.cern.ch

beta.cern.ch alpha.cern.ch nohup start_dns gamma.cern.ch

export DIM_DNS_NODE=alpha.cern.ch nuhup start_server LTU/CEDAR 1000 beta.cern.ch alpha.cern.ch gamma.cern.ch

export DIM_DNS_NODE=alpha.cern.ch start_client beta.cern.ch alpha.cern.ch export DIM_DNS_NODE=alpha.cern.ch start_client gamma.cern.ch

slow-control requirements needed

Third party software The slow control software client could contain the following code snippet: DimRpcInfo lt("LTU/CEDAR/TEMPERATURE",0xff00000000LL); out=lt.getLonglong(); 23

LTU server API

LTU access VME processor VME driver LTU Outer world communicates with VME processor via TCP/IP LTU access VME processor VME driver LTU VME driver maps VME address space into pc address space LTU is controlled be reading and writing registers in the VME address space 5

vme driver In production phase all LTU centralized in two vme crates, so two vme processors needed each with a vme driver In a developement phase LTUs probably distributed in labs, so more vme crates with vme processors needed NA62 vme driver standard has to be defined Marco circulated our note in e-mail on May 6, no reaction

vme driver CERN (Atlas, Alice) supports vme processors by Concurrent Technologies with vmercc driver developed at CERN by Markus Joos vme processors can be borrowed from CERN pool for the development phase Markus Joos promised NA62 will be given his support For the production phase we suggest to wait for the new Concurrent Technologies product. Markus has already a prototype and works on adapting his vmercc driver. To be available in January. Side remark: vme processor can be diskless. In that case we would need NA62 boot server

Side remark: computer coordinator computer TCP/IP registration computer security management diskless computer support (if any) central NA62 servers (like DIM DNS server) wiki ?

Side remark: resource management Our DMI drivers serve as resources for running the experiment. Run control software should chcek (before starting a new run) that all needed resources are available and in proper state. If not so, action should be taken to make resources available (like start the daemons, put the electronics into a proper state) In our case it might mean that DMI drivers are running and LTUs are in a global state What techniques to be used for resource management SMI++ (?)

SMI++ Run-time Environment Device Level: Proxies C, C++, PVSS ctrl scripts drive the hardware: deduceState handleCommands Abstract Levels: Domains Internal objects Implement the logical model Dedicated language User Interfaces For User Interaction Obj SMI Domain Obj SMI Domain Proxy Proxy Proxy Hardware Devices

Conclusions LTU software in good progress It is time to discuss the whole software chain Comments to: cerny@fmph.uniba.sk (Vlado Cerny) rl@hep.ph.bham.ac.uk (Roman Lietava) 24

SPARE SLIDES

LTU modes of operation Global mode Standalone mode Receive triggers from L0 processor and send them to TTC Standalone mode Emulate L0 processor – triggers Snapshot memory – 27 ms Counters Data for slow control 3

Our development system We have started software development using VME crate in Birmingham Linux VME processor with vme_rcc driver Alice LTU’s in the crate Alice’s LTU will be changed to Marian Krivda’s NA62 LTU when ready. Similar system must be set-up in the each lab where the subdetectors are developed to use LTU in the standalone mode emulating trigger sequences 6

DIM architecture VME processor VME driver LTU development phase DIM clients DIM clients DIM clients VME processor VME driver LTU development phase DIM server 8

DIM structure One DIM Name Server (DNS) for the whole NA62 One DIM server for each LTU The server runs as daemon on the VME processor in the LTU rack. All the LTU server are the same, differing just by the server names. The server is registered by the DNS with a unique server name like LTU/CEDAR Many services run on the LTU server Each service is registered by the DNS by a unique name like LTU/CEDAR/TEMPERATURE Each client asks the DNS who provides the service like LTU/CEDAR/TEMPERATURE and registers for the service. This is done by the DIM system and is completely transparent for the user 11

Core DIM LTU service READ and WRITE An expert can interactively do anything with LTU already now Everything can be done by writing data to proper registers and reading back the register values DIM server provides services LTU/????/WRITE LTU/????/READ as DIM RPC’s (remote procedure call) 15