3 Specific Requirements

3.1 Capability Requirements

3.1.1 - Data Input Requirements

3.1.2 - Level-2 Trigger Requirements

3.1.3 - Level-3 Trigger and Event Builder Requirements

3.1.4 - Run Control Requirements

3.1.5 - Error Handling

3.1.6 - Global System Requirements

UR DI-RATE Fragment Arrival Rate

The ROB-IN shall be able to handle a fragment arrival rate of up to 100 kHz without deadtime losses. Incoming fragments will not be de-randomised in time and so, at peak times, fragments can arrive immediately following each other. However, there are some limitations and, in particular, there can be no more than 16 fragments in any 16 ms period.

Need Essential.
Priority Prototype.
Stability Unlikely to change.
Source Level-1 Trigger and Front-end.
Clarity Clear.
Verifiability To be tested during prototype -1 program.

UR DI-EFS Event Fragment Size

The ROB-IN shall be able to receive event fragments of various sizes as described in Table 3

Need Essential.
Priority Prototype.
Stability Fragment sizes will change as experiment develops.
Source Front-end.
Clarity Clear.
Verifiability To be tested during prototype -1 program.

UR DI-IDR Input Data Rate

The Read-out Link will transfer data to the ROB-IN at a rate of 100 MByte/sec. The ROB-IN shall be able to handle such an input data rate.

Need Essential.
Priority Prototype.
Stability The input data rate may increase.
Source Front-end.
Clarity This rate is the peak rate which is attained during actual data transfers. There may be idle periods between the transfer of fragments when no data is transferred and so the average rate may be lower. However, there is no implication of idle periods - the ROLs could transfer data continuously.
Verifiability To be tested during prototype -1 program.

UR DI-FC Flow Control

The ROB-IN must be able to control the flow of input data on the Read-out Link in the event that its buffer becomes full.

Need Essential.
Priority Prototype. It is desirable that both strategies noted below (XOFF and L1_inhibit) be implemented in the prototype.
Stability The flow control mechanism may change.
Source Dataflow.
Clarity Flow control could be implemented by a signal to the Read-out Link (XOFF) causing it to stop transfers or by a signal to the Level-1 Trigger (L1_inhibit) causing it to stop issuing L1_accepts.
Verifiability To be tested during prototype -1 program.

UR DI-EXP Data Expansion

Data sent from the front-ends may be compressed before transmission. Since the ROB-IN may be required to reformat and pre-process the data, it may have to apply expansion to data coming in from the ROD. This would only be performed on fragments which were selected by an RoI_request.

Need Negotiable.
Priority Final system.
Stability This requirement may change or be removed.
Source Level-2 Trigger.
Clarity No expansion algorithms have been defined.
Verifiability To be decided.

UR DI-ALLO Buffer Space Allocation

The ROB-IN must allocate a buffer space for each incoming fragment.

Need Essential.
Priority Prototype.
Stability Size of buffer required may change.
Source Dataflow.
Clarity Clear.
Verifiability To be decided.

3.1.2 Level-2 Trigger Requirements

UR L2-BS Buffer Size

The ROB-IN must be able to store incoming fragments until the Level-2 Trigger has issued an L2_accept or L2_reject. It must, thereafter, continue to store accepted fragments until they have been sent to Level-3. The minimum buffer size is given by:

BS: Buffer Size

EFS: Event Fragment Size

FAR: Fragment Arrival Rate

L2pt: Level-2 Trigger processing time (time to get an L2_accept or L2_reject)

L2ar: Level-2 Trigger accept rate (rate of L2_accepts)

L3rt: Level-3 Trigger read-out time (includes event building time)

SF: Safety Factor to be derived from modelling

Need Essential.
Priority Prototype.
Stability All parameters in the equation are likely to change therefore the buffer size is likely to change.
Source Dataflow.
Clarity It has to be decided whether the parameters in the calculation are minimum, maximum or average.
Verifiability To be decided.

UR L2-ROI RoI_request Handling

The ROB-IN must receive an RoI_request and use it to select either RoI_data or the full fragment from memory. This data is then sent to the Level-2 Trigger. The RoI_request may also contain parameters which define further processing which may be required on the fragment. These are described in the following URs.

Need Essential.
Priority Prototype.
Stability The amount of RoI_data required could vary from a subset of the fragment to the full fragment.
Source Level-2 Trigger.
Clarity It is not yet defined how the RoI_request will be received: via a broadcast system which could be shared with the TTC or, via a separate bi-directional data channel that connects the ROB-IN to Level-2 or, via a local bus connecting several ROBs to an interface module.
Verifiability To be verified during the prototype -1 program.

UR L2-REJ L2_reject Handling

The Level-2 Trigger generates an L2_reject signal for unwanted fragments which should cause the ROB-IN to release the buffer space relating to that fragment.

Need Essential.
Priority Prototype.
Stability Unlikely to change.
Source Level-2 Trigger.
Clarity The L2_reject signals may be accumulated by Level-2 and so may arrive at the ROB-IN in batches of 100 or so. This has some implications for the buffer size calculation.
Verifiability To be verified during the prototype -1 program.

UR L2-ACC L2_accept Handling

For selected fragments, the ROB-IN receives an L2_accept which causes it to retain the fragment in memory until the data has been transferred to the Level-3 Trigger.

Need Essential.
Priority Prototype.
Stability Unlikely to change.
Source Level-2 Trigger.
Clarity The protocol with Level-3, which ensures that a fragment has been successfully transferred, has yet to be defined.
Verifiability To be verified during the prototype -1 program.

3.1.3 Level-3 Trigger and Event Builder Requirements

UR L3-OUT L3 Data Output

On an L2_accept or an L3_request, the ROB-IN must pass the event fragment to the Event Builder. An indication of the total Data Output Rates from all ROBs is given in Table 4.

Need Essential.
Priority Prototype.
Stability Unlikely to change.
Source Level-3 Trigger.
Clarity It is not clear whether L2_accept and L3_request are the same thing. There may not be a one-to-one mapping between them.
Verifiability To be verified during the prototype -1 program.

UR L3-WAIT Wait for L3_done

The ROB-IN may have to wait for successful completion of the data transfer to the Level-3 Trigger before deleting an accepted fragment from memory (i.e. it may have to wait for an L3_done or until local data collection has completed).

Need Negotiable.
Priority Final system.
Stability This requirement may change if the dataflow architecture is changed.
Source Dataflow.
Clarity Clear.
Verifiability To be decided.

3.1.4 Run Control Requirements

UR CTL-SC State Changes

The ROB-IN must respond to commands from Run Control. These will consist of commands to change to one of a series of defined states. An example of a series of states and allowed transitions is given in Figure 2.

Figure 2 Example of states and transitions in the ROB.

Need Essential.
Priority Final system.
Stability The states and state changes required will change frequently.
Source Run Control.
Clarity None of the states have been defined.
Verifiability To be decided.

UR CTL-CONF Configuration

The ROB-IN will be configured on power-up by an external controller. This controller could load programs and parameters.

Need Essential.
Priority Prototype.
Stability The amount and nature of the data to be transferred to the ROB-IN during the configuration is likely to change frequently.
Source Run Control.
Clarity The configuration data depends heavily on the hardware used for the ROB.
Verifiability To be decided.

3.1.5 Error Handling

UR ERR-TRANS Transmission Error

The ROB-IN must be able to detect a transmission error. This is when a data error occurs during transmission over the ROL.

Need Essential.
Priority Final system.
Stability Unlikely to change.
Source Front-end.
Clarity The action has to be decided. This could be to add an error flag to the fragment or to signal (somehow) to the ROL to re-transmit
Verifiability To be decided.

UR ERR-FBIG Fragment Too Big Error

The ROB-IN must be able to detect and respond if the front-end sends a fragment which is bigger than a pre-defined "maximum fragment size".

Need Essential.
Priority Final system.
Stability Unlikely to change.
Source Front-end.
Clarity The action has not been defined. This could be to truncate the fragment and add a flag or to send an error fragment instead.
Verifiability To be decided.

UR ERR-FERR Fragment Contains Error

The ROB-IN may have to be able to detect if an incoming fragment has an error flag set by the ROD (i.e. the fragment already contains an error before transmission to the ROB). Note that this is not the same as UR ERR-TRANS.

Need Negotiable.
Priority Final system.
Stability Unlikely to change.
Source Front-end.
Clarity It may not be necessary for the ROB-IN to detect this. The error flag will be contained in the fragment and so, as long as it is transmitted intact when the fragment is passed on, the ROB-IN may not need to be aware of it.
Verifiability To be decided.

UR ERR-MON Error Monitoring

The ROB-IN must be able to monitor all kinds of error conditions and keep statistics.

Need Negotiable.
Priority Possibly prototype only.
Stability Errors to be monitored and statistics to be accumulated may change frequently.
Source Dataflow.
Clarity Errors to be monitored and statistics to be accumulated have not been defined.
Verifiability To be decided.

UR ERR-DATA Dataflow Errors

The ROB-IN must recognise and recover from the set of dataflow error conditions defined in Table 5

Need Essential.
Priority Final system.
Stability Additional error conditions are likely to appear. Actions on existing error conditions may change.
Source Dataflow.
Clarity Clear.
Verifiability To be decided.

UR ERR-REC ROB-IN Recovery

The ROB-IN must be able to be `rebooted' without interrupting data-taking. The ROB-IN should regain synchronisation by making use of the event_ID and bunch_crossing_ID and rejoin the data flow.

Need Essential.
Priority Final system.
Stability Unlikely to change.
Source Dataflow.
Clarity This would require a start_of_event marker in the fragment to allow the ROB-IN to re-start cleanly.
Verifiability To be decided.

3.1.6 Global System Requirements

UR GBL-MON Monitor Data Handling

The ROB-IN must respond to user request to send selected data to a parallel (to the dataflow) server for monitoring of data quality. User requests will take the form of random or occasional tagging of events which must then be packaged and sent along the monitoring data path.

The fragments could be selected according to event_ID, bunch_crossing_ID, Level-1 trigger type, Level-2 Trigger type, etc.

Data monitoring should not introduce latency or dead-time in the data flow.

Need Negotiable.
Priority Final system.
Stability Data required and selection criteria are likely to change frequently.
Source Dataflow.
Clarity The user may need to receive all fragments relating to a particular event from all ROBs.
Verifiability To be decided.

UR GBL-HIST History Maintenance

The ROB-IN must keep a history record of all signals and messages received.

Need Negotiable.
Priority Possibly only in prototype.
Stability Items to be recorded may change.
Source Dataflow.
Clarity It is not clear how this could be done.
Verifiability To be decided.

UR GBL-PERF Performance Recording

The ROB-IN must maintain statistics on performance parameters such as buffer occupancy.

Need Negotiable.
Priority Final system.
Stability Statistics required may change.
Source Dataflow.
Clarity It is not clear how this data is to be accessed.
Verifiability To be decided.

UR GBL-ACC External Access

The ROB-IN must be accessible from an external processor for monitor and control.

Need Essential.
Priority Prototype.
Stability Type of interface may change.
Source Dataflow.
Clarity It is not clear what commands will be issued from the processor.
Verifiability To be decided.

UR GBL-AUTO Auto-Test Mode

On request, the ROB-IN must carry out self-tests and report the results to some other system.

Need Negotiable.
Priority Possibly only in prototype.
Stability This requirement may be removed.
Source Dataflow.
Clarity The tests required have not been defined.
Verifiability To be decided.

Generated with CERN WebMaker