CTB fragment generator M. Roda Class implementation - - PowerPoint PPT Presentation

CTB fragment generator

• M. Roda

Class implementation

• TriggerBoardReader

– Creates the Fragment generator from a

buffer of words

• CTB_Controller

– Simply send the control commands to the

board

• CTB_Receiver

– Handles the receiving threads and fills the

buffer of words

TriggerBoardReader

+getNext_() +start() +stop()

CTB_Controller

+send_config() +send_start() +send_stop() +send_reset()

CTB_Receiver

+Buffer()

CommandableFragmentGenerator

Receiver stream

• There are two threads that create a

the buffer of word

1)One that fills a raw buffer – currently a boost::spsc_queue of uint8_t from whatever is coming from a TCP socket 2)The other reads the previous queue and fills a spsc_queue of 16 byte words

• The second buffer is consumed by the

fragment generator whenever getNext_() is called

TCP socket queue<uint8_t> queue<trigger_word> 1st thread 2nd thread

Returned fragments

• Right now, whenever a getNext_() is called, the whole content of the buffer

is put into a Fragment

– The time stamp associated with the fragment is the timestamp of the first available

word in the buffer

• The decision of which fragments are added to the event is not on the

FragmentGenerator, it’s happening in a higher level of ArtDAQ.

– It is based on the timestamp of the fragment – The fragmentGenerator will continuously send fragment as the board sends

triggers at all times

Fragments, to be changed soon

• After a discussion with Nuno we decided to create fragments more regularly

– The Board is sending regularly a timestamp word – Whenever this word is seen, a new fragment is created and its associated timestamp

will be the one of the word

– At the present board configuration we create a fragment every 10 μs if there is at least a

triggerword

• John already raised the issue of the number of sent fragments

– Possible solution: combine together more words – Drawback: we increase the number of lost trigger words (see next slide)

Leak of trigger words at the edges

• f the 5 ms readout window
• The trigger words sent by the board are timestamped

– Ideally we would like to store all the words whose TS is within the

5ms readout window

• Since the selection is not based on the TS of the single word,

a strange thing is happening at the edges – see the diagram of an example

– Possible solution: redundancy

• I don’t really like this idea

– The diagram is just an example, something similar might happen at

the end of the readout window

• According to a quick discussion we had with Karol, it’s not a

problem if we loose something at the edge

– According to Nuno, it is a problem – I’m happy to go both ways but I guess we need an agreement first – What I want to stress is that this is unavoidable with the current

system as we don’t know the 5 ms start and end while we create the fragment

– There might be the possibility to fix this using some fcl file options to

be passed by the FragmentGenerator, I have to check with Kurt

word word word Fragment single TS 5 ms window

All these words are lost as The fragment TS is out of the 5ms But we would have liked to save the last word

• f the fragment as its TS is within the 5 ms

time

Calibration stream

• We still want a calibration stream of the things received by the board reade

– Not implemented yet

• The stream has no defined usage at the moment – it’s supposed to be an internal cross

check

– It’s going to be a simple file (binary or txt) for every 5 minutes of run or so – It will contain every trigger word received from the BoardReader

• Concerning its implementation

– The natural place for this implementation is the thread which is filling the word_buffer – Every word pushed into the buffer will also be printed into the file