Skip to content
This repository has been archived by the owner on Jan 31, 2022. It is now read-only.

Feature/ge21 compatibility #119

Conversation

mexanick
Copy link
Contributor

Description

Implements GE2/1 compatibility. All new parameters are backed with default values set to GE1/1 defaults. Thus the rest of the software should be able to work unchanged. Requires cms-gem-daq-project/ctp7_modules#132 to work with GE2/1

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)

Motivation and Context

Need to be able to use the current legacy software for GE2/1 integration stand

How Has This Been Tested?

Tested with GE2/1 integration stand.

Screenshots (if appropriate):

Checklist:

  • My code follows the code style of this project.
  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.
  • I have added tests to cover my changes.
  • All new and existing tests passed.

jsturdy
jsturdy previously approved these changes Jun 13, 2019
Copy link
Contributor

@jsturdy jsturdy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cursory

@bdorney
Copy link
Contributor

bdorney commented Jun 13, 2019

Are all the commits in your development area uploaded here?

E.g. many files remain unmodified and I would expect some changes are needed to calibration functions, VFAT functions, optohybrid functions (broadcast read/write come immediately to mind). I recall that there are multiple locations in which array sizes are checked; while empty elements for VFATs from 13-23 are not an issue they are a potential memory overhead. Not sure if that should be addressed here or wait for cmsgemos and retirement of this branch completely.

Not sure if these were also updated in the ctp7_modules repo...? On my phone so it’s hard to check.

@@ -458,9 +458,15 @@ DLLEXPORT uint32_t getmonVFATLink(struct VFATLinkMonitor *vfatLinkMon, uint32_t
for(int vfatN = 0; vfatN < 24; ++vfatN){
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nvfats missing here I think.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't this still outstanding?

@@ -174,7 +175,7 @@ DLLEXPORT uint32_t readVFAT3ADCMultiLink(uint32_t ohMask, uint32_t *ohVfatMaskAr
return 1;
}

const uint32_t size = 12*24;
const uint32_t size = 12*nvfats;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we want this 12 to be replaced with an nohs? I'm fine with the answer being "no". But again this would present a potential issue for a setup driven by GLIB.

Copy link
Contributor

@bdorney bdorney left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Still a few places where nvfats or NGBT's is not used appropriately.

@@ -115,7 +115,7 @@ DLLEXPORT uint32_t getVFAT3ChipIDs(uint32_t * chipIDData, uint32_t ohN, uint32_t
}

std::string regBase = "GEM_AMC.OH.OH" + std::to_string(ohN) + ".GEB.VFAT";
for(int vfat=0; vfat < 24; ++vfat)
for(int vfat=0; vfat < nvfats; ++vfat)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if you're changing to ensure signed/unsigned comparisons, probably you want to change here too.
also comment made here re unsigned int vs unsigned vs uintX_t

@jsturdy
Copy link
Contributor

jsturdy commented Jun 27, 2019

Needs rebase (preferably after addressing @bdorney's comments), and within the rebase preferably some cleanup of the commit history

@mexanick
Copy link
Contributor Author

mexanick commented Jul 3, 2019

I've rebased. The compatibility in the daq_monitor part deserves a separate issue in my opinion, as this also concerns the cmsgemos part and in general is not currently used, but will be used later eventually with refactored version of ctp7 modules, where the corresponding changes have to be implemented.

@mexanick mexanick requested review from jsturdy and bdorney July 3, 2019 15:39
Copy link
Contributor

@jsturdy jsturdy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cursory

@mexanick
Copy link
Contributor Author

mexanick commented Jul 5, 2019

@bdorney please see my comment considering outstanding issues

Copy link
Contributor

@bdorney bdorney left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Still seems like some outstanding issues have not been addressed, comments here

@bdorney
Copy link
Contributor

bdorney commented Jul 8, 2019

I've rebased. The compatibility in the daq_monitor part deserves a separate issue in my opinion, as this also concerns the cmsgemos part and in general is not currently used, but will be used later eventually with refactored version of ctp7 modules, where the corresponding changes have to be implemented.

The SCA function I agree is a separate issue due to HW changes between boards; but the other issues I pointed out in daq_monitor.cc just require using nVFAT or nGBT in for loops and should be addressed before this is merged.

@mexanick mexanick merged commit 721e3e8 into cms-gem-daq-project:legacyPreBoost Jul 8, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants