Skip to content

All the processors we need for the VCU128 deployment

Rocco Ardino requested to merge rardino-processors-for-vcu128 into main

This MR introduces few new configuration entries, flags and (most importantly) processors needed to understand+process what the VCU128 is sending.

New configurations:

  • source_id: the source ID of the received stream is not anymore hard-coded in config.h, since I don't think it is a scalable solution if we can receive ~20 different streams (1 GMT, 4 CALO, 1 GT, 12 BMTF), it would require a huge and ugly multi-if. But I am free to implement that if you think it would be better...
  • dthHeaders: the processing logic works differently with what the VCU128 is sending, since we have few more headers for every block and packet that we need to take into account. Similarly for cmsswHeaders, this flag introduces the support to process both DMA and TCP/IP input streams
  • output_filename_suffix: in case we have more TCP/IP streams, the output files need to have a different extension as CMSSW is requesting. For instance, for the GMT files we would have .raw, for the calo ones .raw_1, .raw_2, .raw_3, raw_4, and so on for BMTF and GT...
  • primitive_type: depending on what we are acquiring, the block size might be different. In particular, this flag is introduced because of the new calo processor, which needs to know at construction time the ET shifts/masks (different for jet,egammas, taus, sums) and block size (different between calo objects and calo sums). This primitive type variable will is used in the orbit_processor constructor

New processors:

  • calo_obj_orbit_processor: needed to process the calo objects streams, namely jets, egammas and taus
  • calo_sum_orbit_processor: same as before, but for the sums. It could have been merged to the previous processor, but the sums are global quantities and so the processing is a bit different (it would not be optimal with the logic of the previous processor)
  • bmtf_orbit_processor: for the bmtf stubs
  • ugt_orbit_processor: for the ugt bits, it just dumps to the file the 512b/BX it gets plus an orbit and BX word of 32b

At the moment, I have tested in the lab:

  • I was using the VCU128 bitfile for UGMT+BMTF
  • starting an instance of SCDAQ for the UGMT with 1 stream
  • starting on the same machine another SCDAQ instance for the BMTF with 12 streams
  • working as expected (even though I had to run with very minimal generated orbit size since the machine has only 12 logical cores...)
Edited by Rocco Ardino

Merge request reports