Discussion: How to Switch SBIT Registers OH 3.X.Y.C and OH 3.X.Y.1C FW After Programming?

bdorney commented 6 years ago

Brief summary of issue

Present tools do not allow multiple OH's on the same AMC to be programmed with different FW.

Promless method forces the same FW onto all links after a TTC hard reset. Using the SCA path through jtag could be one method, but it is very "slow." Additionally a straight forward python script may also be "slow" to execute (although in uhal it may be possible...but I don't know if uhal address tables for v3 electronics have been generated)

One "short-term" solution would be to write these registers in a dedicated RPC module at the time of configuration. The hope would be a "long-term" solution could be achieved next week at the camp...?

The registers in question are:

GEM_AMC.OH.OHX.FPGA.TRIG.TIMING.TAP_DELAY_VFATY_BITZ, SBIT Tap Delays, there are NOH * NVFAT * 8 registers in total (each VFAT has 8 sbits)
GEM_AMC.OH.OHX.FPGA.TRIG.TIMING.SOT_TAP_DELAY_VFATY, SOT Tap Delay; there are NOH * NVFAT registers
GEM_AMC.OH.OHX.FPGA.TRIG.CTRL.SOT_INVERT, there are NOH registers
GEM_AMC.OH.OHX.FPGA.TRIG.CTRL.VFATY_TU_INVERT, there are NOH * NVFAT registers

Where X, Y and Z are integers respectively specifying OH number, VFAT position, and SBIT (e.g. BIT above) number.

Types of issue

[ ] Bug report (report an issue with the code)
[ ] Feature request (request for change which adds functionality)
[X] Discussion

Expected Behavior

The remote rpc module would take the form of. This would be called once per VFAT

void setOHTrigRegisters(std::vector<uint32_t>  sbitTapDelay, std::vector<uint32_t>  sotTapDelay, std::vector<uint32_t>  sotInvert, std::vector<uint32_t> vfatInvert, uint32_t ohMask=0xfff){
   // Expect vector lengths to be
   // sbitTapDelay.size() == NOH * NVFAT * 8
   // sotTapDelay.size() == NOH * NVFAT
   // sotInvert.size() == NOH
   // vfatInvert.size() == NOH * NVFAT

   //get keys from rpc request

  //Get the VFAT mask for each OH
  const uint32_t NOH = read number of OH's from GEM_AMC.GEM_SYSTEM.CONFIG.NUM_OF_OH register;
  uint32_t vfatMask[NOH] = getOHVFATMaskMultiLink( ... );

  //Loop over unmasked NOH, skipping masked ones, call 4 methods:
  setSbitTapDelays(ohN, vfatMask[ohN], sbitTapDelay);
  setSotTapDelays(ohN, vfatMask[ohN], sotTapDelay);
  setSotInvert(ohN, vfatMask[ohN], sotInvert);
  setVfatInvert(ohN, vfatMask[ohN], vfatInvert);

  //Call the 4 local methods
}

void setSbitTapDelays(int ohN, uint32_t vfatMask, std::vector<uint32_t>  sbitTapDelay){
   Raise an exception if length of sbitTapDelay does not meet expectation?

   loops over unmasked vfats,
      loop over bits in VFAT
         idx = ohN * 24 + vfat + bitN
         write sbit tap delay for this bit

   return
}

void setSotTapDelays(int ohN, uint32_t vfatMask, std::vector<uint32_t> sotTapDelay){
   rase an exception if length of sotTapDelay doesn't meet expectation?

   loop over unmasked vfats
     idx = ohN * 24 + vfat
     write sotTapDelay[idx]

   return
}

void setSotInvert( ... ){
   as above
}

void setVfatInvert( ... ){
   as above
}

These functions would go in optohybrid.h.

This would be an optional step in the detector configuration (since if the chamber has the right type, i.e. long or short, for the FW file in the CTP7 it is not needed).

Additionally we may find in the future that we need this function with a database interaction. Unknown...?

Current Behavior

No such functionality exists.

Context (for feature requests)

Need short term solution for writing trigger registers.

Also need a long term solution. Opening this issue for discussion before starting coding.

jsturdy commented 6 years ago

Decoupling from the text file solution proposed in the mail thread...

This would be called once per VFAT

VFAT -> OH?

   loops over unmasked vfats,
      loop over bits in VFAT
         idx = ohN * 24 + vfat + bitN
         write sbit tap delay for this bit

probably should loop over all VFATs, or at least make sure the indexing is correct in the alternative
idx = ohN * 24 + vfat + bitN does not probably give you the indexing you are hoping for, you would probably need something like idx = (ohN * 24 + vfat) * 8 + bitN

andrewpeck commented 6 years ago

Hi all,

The constants used by the firmware are derived from simple python files...

https://raw.githubusercontent.com/cms-gem-daq-project/OptoHybridv3/master/tools/timing_constants_geb_v3a_short.py

https://raw.githubusercontent.com/cms-gem-daq-project/OptoHybridv3/master/tools/timing_constants_geb_v3b_short.py

https://raw.githubusercontent.com/cms-gem-daq-project/OptoHybridv3/master/tools/timing_constants_geb_v3c_long.py

https://raw.githubusercontent.com/cms-gem-daq-project/OptoHybridv3/master/tools/polarity_swaps.py

Developing these rpc modules would be a matter of porting these constants from the linked python files into the desired format (keeping in mind that these are all in hardware numbering, and the numbering of VFATs needs to be reversed for compatibility with the software)

Also remember that v3b short and v3c short have the same configurations.

The files should be relatively self-explanatory... but to add some details for the record:

in the timing constants files, as an example:

v3c_long_trig_tap_delays = [
  2           , # TU_OFFSET[0][0]
  5           , # TU_OFFSET[0][1]
  5           , # TU_OFFSET[0][2]
  3           , # TU_OFFSET[0][3]
  3           , # TU_OFFSET[0][4]
  3           , # TU_OFFSET[0][5]
  1           , # TU_OFFSET[0][6]
  2           , # TU_OFFSET[0][7]

These are GEM_AMC.OH.OHX.FPGA.TRIG.TIMING.TAP_DELAY_VFATY_BITZ for VFAT23 bits 0-7. The numbering of the VFATY is reversed (23-i) but the numbering of BITZ does not change.

In the polarity swaps file, note that the sectors are counting from 1 (as it does in the hardware)..

lpetre-ulb commented 4 years ago

Moved to the new GitLab repository (cmsgemos#89).

cms-gem-daq-project / ctp7_modules