1. Peter W. PhillipsSCT/Pixel RODDAQ workshop, UCL, July 2002 SCT Needs for Full User Evaluation Peter W Phillips Rutherford Appleton Laboratory

2. Peter W. PhillipsSCT/Pixel RODDAQ workshop, UCL, July 2002 Contents Introduction Assumptions Foundations Configuration File Format “SCT API” Specific Concerns

3. Peter W. PhillipsSCT/Pixel RODDAQ workshop, UCL, July 2002 Introduction Most of the initial tests can be made, and are being made, using TestStand - but when it gets to the point where we wish to test SCT modules with ROD, rather than the other way round, we may need something more closely coupled to an environment suited to data analysis. It seems unlikely that a data acquisition using all elements of DAQ-1 could be made to function on a time scale suited to the ROD FDR - but maybe we don’t need it. What is most appropriate way forward?

4. Peter W. PhillipsSCT/Pixel RODDAQ workshop, UCL, July 2002 Assumptions That a valid route forward may be to take the analysis routines from SCTDAQ and to build a relatively simple ROOT based application running directly on the RCC, linked directly to the ROD and TIM libraries, which can perform arbitrary scans upon SCT modules and store the histogrammed data for further analysis. The scope of such a system would be limited to a relatively small number of modules, probably no more than one ROD. That the transfer of functionality from RCC to ROD will be staged. For instance, s-curves may initially be fitted by software running in RCC. Only when test systems come to be assembled on a large scale does it become important to implement this fitting in ROD. What are the boundaries and interfaces between DSP code, the ROD Library, “user” code (command layer) and DAQ-1?

5. Peter W. PhillipsSCT/Pixel RODDAQ workshop, UCL, July 2002 Foundations We have a structure to store ABCD configuration information. We have an efficient command generator for ABCD chips, outputting data in a format directly compatible with existing ROD primitives. We have utilities to read/write the contents of the configuration structure from/to ASCIIfiles, and to manipulate elements of the structure as may be required during scans. All of this was written in simple C code As shown this morning, much of this functionality has already been integrated into the ROD code. Under these circumstances, maybe TestStand is all we need?

6. Peter W. PhillipsSCT/Pixel RODDAQ workshop, UCL, July 2002 Configuration File Format Objectives To store calibration data and the contents of all ABCD registers of one module together in one simple ASCII file To keep the information in a form that can be easily read by machine or by the human eye, whilst keeping the size of the file to a minimum (6k) DCS information was deliberately omitted We end up with a cup of (SC)T that may not suit all tastes, but it should work. However, in the light of Gareth’s comments earlier today, we should perhaps think carefully about this format before its use becomes widespread!

7. Peter W. PhillipsSCT/Pixel RODDAQ workshop, UCL, July 2002 Configuration File Format Module active 1 select 0 Chip 00 address 0x20 active 1 config 1 0 0 0 0 0 0 0 0 0 1 mask 0xffffffff 0xffffffff 0xffffffff 0xffffffff vthr 0x28 vcal 0x18 delay 0x10 preamp 0x18 shaper 0x19 rc_function 0 p0 0.00e+000 p1 0.00e+000 p2 0.00e+000 c_factor 1.00 trim 00-1f 01234567 89abcdef 01234567 89abcdef trim 20-3f 00000000 00000000 00000000 00000000 trim 40-5f 00000000 00000000 00000000 00000000 trim 60-7f 00000000 00000000 00000000 00000000 Chip 01…. Is this sensible?

8. Peter W. PhillipsSCT/Pixel RODDAQ workshop, UCL, July 2002 SCT API This is an attempt to further define the functionality needed in order to be able to fully test SCT detector modules using RODs. The functionality is important, but the detail of its implementation is not. Some ideas are shown about how the very top level might appear, at least at a first pass, really just to help make clear the required functionality and processes. Only after further dialogue between those writing code at all levels will the final form of the system become clear.

9. Peter W. PhillipsSCT/Pixel RODDAQ workshop, UCL, July 2002 SCT API - Operator Requirements  To be able to read in system configuration information from persistent storage.  To be able to read in module configuration and calibration information from persistent storage.  To be able to vary the parameters of a module’s registers, from the system level down to the level of one chip.  To configure trigger parameters  To configure BOC parameters  To configure and execute scans  To retrieve, save, analyse and display scan data  To be able to define arbitrary groupings of modules and treat them differently when changing parameters, executing scans etc.

10. Peter W. PhillipsSCT/Pixel RODDAQ workshop, UCL, July 2002 SCT API - Configuring Modules "set"- upload parameters from the SBC to the ROD sct->setModuleBasicRegisters(); sct->setModuleTrimRegisters(); sct->setModuleMaskRegisters(); sct->setModuleCalParameters(); sct->setModuleAll(); sct->setModuleVariable(typ,val); sct->setChipVariable(chip,typ,val);

11. Peter W. PhillipsSCT/Pixel RODDAQ workshop, UCL, July 2002 SCT API - Configuring Modules "send"- request the RODs to send the formatted command strings, derived from the set structures, to the modules. The strings are probably assembled within the ROD, but this need not be the case notably in the early days. sct->sendModuleBasicRegisters(); sct->sendModuleTrimRegisters(); sct->sendModuleMaskRegisters(); sct->sendModuleAll();

12. Peter W. PhillipsSCT/Pixel RODDAQ workshop, UCL, July 2002 SCT API - Configuring Modules "get"- request the RODs to return to the SBC the current states of the relevant parameter or struct sct->getModuleBasicRegisters(); sct->getModuleTrimRegisters(); sct->getModuleMaskRegisters(); sct->getModuleCalParameters(); sct->getModuleAll(); sct->getModuleVariable(typ,&val); sct->getChipVariable(chip,typ,&val);

13. Peter W. PhillipsSCT/Pixel RODDAQ workshop, UCL, July 2002 SCT API - Configuring a Scan sct->setModuleAll(); sct->sendModuleAll(); sct->setTriggerType( trigger_group, trigger_type); sct->setTriggerMask( trigger_group); sct->resetTriggerMask( trigger_group); sct->setDataMode( data_group, data_type); sct->setFitParams( data_group, params[]); Might look something like this:

14. Peter W. PhillipsSCT/Pixel RODDAQ workshop, UCL, July 2002 SCT API - Configuring and Executing a Scan sct->setCalEnable( data_group, cal_mask); sct->setTimebinEnable( data_group, timebin_mask); sct->setScan( npoints, typ[], val[]); sct->setScan( npoints, typ, start, stop, step); sct->startScan(); sct->stepScan(); sct->getData( data_group, &size, &data_buffer ); sct->resetScan(); sct->resetData();

15. Peter W. PhillipsSCT/Pixel RODDAQ workshop, UCL, July 2002 SCT API - Notes Data Modes Each data group should process the data from its assigned links according to defined accumulation algorithms including: 1. Occupancy histogram (nhits x strip, for each plane) 2. Multiplicity histogram (nevents x nhits, for each plane and for each chip separately) 3. Occupancy per event (OPE) histogram (nhits x event, for each plane and each chip separately) 4. Fit Results Tables (params x strip, for each link) (Modes listed in order of desirability: they are not all needed now!)

16. Peter W. PhillipsSCT/Pixel RODDAQ workshop, UCL, July 2002 SCT API - Notes Trigger Groups Each output datalink can receive trigger bit streams from TIM, or from the master DSP serial ports 1 and 2. Data from both DSP serial port 1 and TIM is routed to the modules through the same mask register - we may need to store two values for this mask and to swap between them according to which stream is in use. Trigger Type We define an extensible number of predetermined trigger patterns from which the patterns loaded to each trigger source can be selected. Data Groups Each SCT module is assigned to one of a number of Data Groups. Each data group has its own settings to define how data from its members is processed. Ideally these groups would be arbitrary across a system of RODs, but we need to consider any restrictions that may be imposed by the ROD architecture.)

17. Peter W. PhillipsSCT/Pixel RODDAQ workshop, UCL, July 2002 Specific Concerns Buffer Sizes What is the largest event that can be handled without loss? Is this good enough? Histogramming Speed How long will it take to perform a calibration? Digital Configuration “Eye” plots SEUs and RESETs Error corrections Operation with Multiple Modules at 100kHz mean trigger rate When will we be in a position to try this? Scanning DCS values; External Triggering Do any event sizes fall through?

18. Peter W. PhillipsSCT/Pixel RODDAQ workshop, UCL, July 2002 References Characterisation Requirements Document: http://sctpixel.home.cern.ch/sctpixel/Workshop2002/charac007.pdf Operation of Barrel Modules - Present and Future: http://hepwww.rl.ac.uk/atlas-sct/documents/Operating_modules_06.pdf Electrical Tests of SCT Hybrids and Modules: http://hepwww.rl.ac.uk/atlas-sct/documents/Electrical_Tests.htm SCT Module Test DAQ home page: http://atlas.web.cern.ch/Atlas/GROUPS/INNER_DETECTOR/SCT/testdaq/testdaq.html SCT System Test home page: http://asct186.home.cern.ch/asct186/systemtest.html