Home

HELP

Collaboration

Subsystems

Physics

Documents

lhcblogo.gif (8544 bytes)
General
Search
News
Email
BWHO
Forthcoming Events
Site Map
Subsystems
Vertex Detector
Trackers
RICH
Calorimeters
Muon
Trigger
Computing
Electronics
Expt. Area
Magnet
Infrastructure
Detector Geometry
Test Beam
Gas
Computing
Project Planning
SICB
Simulation
Reconstruction
Analysis
DAQ
Controls
Operations
Comp. Systems
Sw Components
GAUDI
Sw Support
Readout unit
GRID

 

Questionnaire for ECS 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 ECS (Experiment Control System) and the readout electronics. Although the questionnaire was put together having in mind the interface between ECS and the front-end electronics (on-detector boards, L0 and L1 electronics, etc.) we would very much appreciate feedback from other fields as. 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 ECS will be the only path into the readout electronics.

NOTE: By 'board' we mean an entity that will need to have a connection with the ECS

 

1. General

We would like to understand specifically which part of LHCb you will be referring to. If you first read all the questions before answering, you will better understand the view that we would like to get.

1.1 Could you now describe the subsystem you will be referring to ?

1.2 Could you try to describe in a few sentences the major usage and interactions that you foresee with the ECS, for your subsystem ?
(functionality, what do you think the ECS should do for you)

 

2. The number of boards and their location

2.1 How many different type of boards will you have ?
(functionally different, thus different needs with respect to ECS; 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 control processor in the crate accessing all units and where will it be used for ?

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) ways to control the hardware on your board (and that need to be interfaced to the ECS) ?
(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 ECS interface ?

3.3 Could you, if possible, give an indication of the following constraints ?

  • board space (that could be made available to the ECS interface)
  • radiation hardness (should the ECS interface be ‘radiation hard’)
  • 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 ECS)

3.4b If yes, what would be needed from ECS?
(eg. how may read/write operations, how many bits or bytes ?)

 

4. Functionality and performance aspects

The idea is to use the ECS for downloading parameters (such as gain, threshold, lookup-tables, ...), monitoring operation of the board (typically a small amount of data), giving asynchronous commands (change of operation mode, reset, ...) ,...
For each type of board:

I. initialization and downloading.

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 bits information?).

4.2 How long can you allow the downloading of parameters to take ?

4.3 How often do you expect parameters to be downloaded (and, if needed, read back) ?
(eg. once a 'run', once so many seconds, ...)

II.monitoring.

4.4 Could you give an estimate of the number of bits or bytes to be read for monitoring and at which rate ?

4.5 Do you see a need to read big amounts of data from your board via the ECS link ?
(eg. dump of (part of) an event, dump of memory, …)

4.5b If yes, please explain
(why reading this data, what should ECS do with this data)

III. Calibration, testing or other functionalities.

4.6 If ECS is to be used for calibration runs, could you give an indication on how a typical calibration run would look ?
(including how many parameters to be downloaded, data to be read)

4.7 Do you expect to test and debug your board through ECS ?
(eg. do you need to write and read back from memory, …)

4.8 Do you see any other task the ECS should perform ?
(eg. reset or other asynchronous commands)

 

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 ECS interface ?

 

last updated 29-oct-1999
Clara Gaspar, André Augustinus