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

2. 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

3. 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

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

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

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

7. 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

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

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

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

12. 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

15. slow-control requirements needed

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

18. LTU server API

19. 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

20. 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 on May 6, no reaction

21. 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

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

23. 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++ (?)

24. 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

25. Conclusions LTU software in good progress
It is time to discuss the whole software chain
Comments to:
(Vlado Cerny)
(Roman Lietava) 24

28. SPARE SLIDES

29. 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

30. 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

31. 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

32. 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

33. 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