[ Home | Contents | Search | Post | Reply | Next | Previous | Up ]
From: AUGUSTINUS@vsdeol.cern.ch
Date: 10/21/99
Time: 7:16:55 AM
Remote Name: 137.138.115.180
As it was discussed in todays DAQ meeting, we will soon (=early next week)
circulate a questionnaire to the various subdetectors. If you have any
comments to it, please let us know at latest by this weekend (24/10).
You can find the questionnaire in:
http://delonline.cern.ch/~augustinus/lhcb/DCStoFE_Q.html
For those who want to edit it, we append it as plain ascii text.
Thanks,
Clara Gaspar
Andre Augustinus
NOTE1: we only want comments to the questions that are in the questionnaire,
not yet the answers to these questions.
NOTE2: please remarks/suggestions to clara.gaspar@cern.ch AND
andre.augustinus@cern.ch
--------------------------------------------------------------------------------
draft 0.3
Questionnaire for DCS interface to readout electronics.
The aim of this questionnaire is to gather information and requirements to be used as input in the
evaluation of a possible fieldbus interface between DCS (Detector Control System) and the
readout electronics. Although the questionnaire was put together having in mind the interface
between DCS and the front-end electronics (on-detector boards, L0 and L1 electronics, etc.) we
would very much appreciate feedback from other fields as well (eg. the more ‘classical Slow
Control’ like High Voltage, etc.). So feel free to circulate this questionnaire to anyone who might
have input for us.
When answering these questions do keep in mind that it is very likely that the DCS will be the
only path into the readout electronics.
NOTE: Where I say 'board', I mean an entity that will need to have a connection with the DCS
1. General
1.1 Could you give a general discription of the major usage that you foresee of the DCS, for
your subsystem ?
(functionality, what do you think the DCS can or should do for you)
2. The number of boards an their location
2.1 How many different type of boards will you have ?
(functionally different, thus different needs with respect to DCS; a schematic drawing could
maybe help)
2.2 How many units of each type will you have ?
2.3 How will they be grouped ?
(eg. per detector module, number of boards per crate, stand-alone)
If in a crate:
2.3.1 What kind of crate ?
(VME, any crate just for mechanics and power, ...)
2.3.2 Will there be a central processor accessing all units ?
2.4 Where will they be located ?
(eg. on detector, behind the wall, ...)
3. Technical aspects
For each type of board:
3.1 Do you have a (or more) preferred interface(s) from the DCS to your board ?
(eg. dual port memory, I2C, JTAG, I/O lines, ...)
3.2 Is there an on-board CPU, FPGA that could be (partly) used by the DCS interface ?
3.3 Could you, if possible, give an indication of the following constraints ?
- board space
- radiation hardness
- power consumption
- implementation (eg. integrated in design, plug-on card, Front-end connector
limitation,…)
3.4 Does the board have intelligent selftest features ?
(ie. do you need a 'selftest' command from DCS)
3.4b If yes, what would be needed from DCS?
(eg. how may read/write operations, how many bits or bytes ?)
4. Functionality and performance aspects
The idea is to use the DCS for downloading parameters (such as gain, threshold, lookup-
tables, ...), monitoring operation, giving asynchronous commands (change of operation mode,
reset, ...) ,...
For each type of board:
4.1 Could you give an estimate of the number of bytes to be downloaded, or at least an
order of magnitude ?
(eg, ranging from a few bytes when loading a few registers, or a few Mbytes when loading
lookup-tables; are there units that only require a few bit information?).
4.2 Could you give an estimate of the number of bits or bytes to be read for monitoring ?
4.3 Do you see a need to read big amounts of data from your board via the DCS link ?
(eg. dump of (part of) an event, dump of memory, ...)
4.4 How long can you allow the downloading or reading of parameters to take ?
4.5 How often do you expect parameters to be downloaded and read back?
(eg. once a 'run', once so many seconds, ...)
4.6 If DCS is to be used for calibration runs, could you give an indication on how a typical
calibration run would look like ?
(including how many parameters to be downloaded, data to be read)
5. Other aspects
5.1 Could you give an indication of timescales ?
(eg. is there a prototype ? when will design be 'frozen' ?)
5.2 Could you give an indication of your needs for test beam activities ?
(eg. timescale, what would you need)
5.3 Are there any other aspects that might be of interest for the DCS interface ?
last updated 20-oct-1999
Clara Gaspar, André Augustinus