YARR issueshttps://gitlab.cern.ch/YARR/YARR/-/issues2024-02-02T00:22:41+01:00https://gitlab.cern.ch/YARR/YARR/-/issues/178Remove duplicated code in initHW2024-02-02T00:22:41+01:00Matthias WittgenRemove duplicated code in initHWMatthias WittgenMatthias Wittgenhttps://gitlab.cern.ch/YARR/YARR/-/issues/177Global FrontEnd and local database are set twice in ScanConsole2022-11-14T20:52:41+01:00Zhengcheng TaoGlobal FrontEnd and local database are set twice in ScanConsoleThe code for setting up local database and global FE is duplicated in [`ScanConsoleImpl::initHardware`](https://gitlab.cern.ch/YARR/YARR/-/blob/devel/src/libYarr/ScanConsoleImpl.cpp#L391-418) and [`ScanConsoleImpl::configure`](https://gi...The code for setting up local database and global FE is duplicated in [`ScanConsoleImpl::initHardware`](https://gitlab.cern.ch/YARR/YARR/-/blob/devel/src/libYarr/ScanConsoleImpl.cpp#L391-418) and [`ScanConsoleImpl::configure`](https://gitlab.cern.ch/YARR/YARR/-/blob/devel/src/libYarr/ScanConsoleImpl.cpp#L231-258). I suppose this is not intentional?https://gitlab.cern.ch/YARR/YARR/-/issues/176ItkPixV1.1: threshold distributions shifted by -100/200e from the target thre...2023-10-19T19:01:32+02:00Matthias SaimpertItkPixV1.1: threshold distributions shifted by -100/200e from the target thresholdas discussed on mattermost:
somewhat a follow-up of https://gitlab.cern.ch/YARR/YARR/-/issues/68 for ITkPixV1.1, where the situation looks worse.
we see systematically a lower threshold than the target by 100 or 200+ electrons when the...as discussed on mattermost:
somewhat a follow-up of https://gitlab.cern.ch/YARR/YARR/-/issues/68 for ITkPixV1.1, where the situation looks worse.
we see systematically a lower threshold than the target by 100 or 200+ electrons when the target is 1000e. It may be an issue with the threshold tuning algorithm?
A few example plots are below. All these chips are in the PDB, chip config files can be accessed from here:
https://gitlab.cern.ch/SaclayITk/yarr-apps/module-scans (just request access)
tagging @theim and @fcrescio
![Screenshot_from_2022-11-10_09-42-33](/uploads/88f2dc61b235976bc25f3016e1520cbf/Screenshot_from_2022-11-10_09-42-33.png)
![Screenshot_from_2022-11-10_09-42-24](/uploads/53ccb0419ec2679204e9c1f55a28122f/Screenshot_from_2022-11-10_09-42-24.png)
![Screenshot_from_2022-11-10_09-42-14](/uploads/27803478ff0aa3dc5ed5c78aa267e83d/Screenshot_from_2022-11-10_09-42-14.png)
![Screenshot_from_2022-11-10_09-42-05](/uploads/88624610e0887d9d35a0be3ab7c6e3ab/Screenshot_from_2022-11-10_09-42-05.png)
![Screenshot_from_2022-11-03_10-17-55](/uploads/4753825bc11f3283c2ac571e6ad4ec0c/Screenshot_from_2022-11-03_10-17-55.png)
![Screenshot_from_2022-11-03_10-17-45](/uploads/21b4ed7b5a5cffa577f400f1a6d7431c/Screenshot_from_2022-11-03_10-17-45.png)
![Screenshot_from_2022-11-03_10-17-37](/uploads/120ca836e9caa6e89c7948de4236f0e9/Screenshot_from_2022-11-03_10-17-37.png)
![Screenshot_from_2022-11-03_10-17-27](/uploads/5da0d4a0b6fc4a5338746c2d09f2a458/Screenshot_from_2022-11-03_10-17-27.png)
![Screenshot_from_2022-10-13_12-17-31](/uploads/e10994ec7c27c25e6536b87e54f8cff4/Screenshot_from_2022-10-13_12-17-31.png)
![Screenshot_from_2022-10-13_12-17-18](/uploads/64719e0487b37abe60f20ac4aa446a67/Screenshot_from_2022-10-13_12-17-18.png)
![Screenshot_from_2022-10-13_12-17-08](/uploads/9cda74c471f0048e4e16a70de0675d93/Screenshot_from_2022-10-13_12-17-08.png)https://gitlab.cern.ch/YARR/YARR/-/issues/175Add links to devel in documentation2023-02-06T17:02:01+01:00Bruce Joseph GallopAdd links to devel in documentationWould it be useful to add the following links in the standard documentation:
* Future docs: https://yarr.web.cern.ch/yarr/devel/
* Developer docs: https://yarr.web.cern.ch/doxygen/devel/
* Coverage: https://yarr.web.cern.ch/yarr/devel/c...Would it be useful to add the following links in the standard documentation:
* Future docs: https://yarr.web.cern.ch/yarr/devel/
* Developer docs: https://yarr.web.cern.ch/doxygen/devel/
* Coverage: https://yarr.web.cern.ch/yarr/devel/coverage/
Though some of these are already linked from the README.md file.https://gitlab.cern.ch/YARR/YARR/-/issues/174Integration of Strips SR1 code2024-01-30T16:38:38+01:00Bruce Joseph GallopIntegration of Strips SR1 codeThere is currently a branch devel_SR1 (see !553), which implements several scans/analyses for
Strips testing at SR1. For instance this is the status to which #173 refers.
I don't think it's practical to merge as is, the main things that...There is currently a branch devel_SR1 (see !553), which implements several scans/analyses for
Strips testing at SR1. For instance this is the status to which #173 refers.
I don't think it's practical to merge as is, the main things that should be fixed
are:
* Need to load calibration information from a previous test into the histogram clipboard for fit functions etc. (see StarJsonData and HistoFromDisk). This should instead be done by putting the calibration information into the FrontEnd configuration.
* In order to have a noise occupancy scan with a variable number of triggers, the analysis includes code to communicate directly with the StarCounterLoop to change the number of triggers to be sent. Instead the analysis should use the existing feedback mechanism to request more triggers, and find a way to communicate how many triggers were actually sent.
The plan is to split the above branch into smaller pieces to be merged in turn. For
instance, the following (subject to change as things go ahead):
- [x] Strobe delay analysis !564
- [x] Put calibration parameters into the configuration !584
- [ ] Initial throttle trigger loop, maybe rebased !366
- [ ] Make trigger throttle loop more robust
- [ ] Implement stripped down noise analysis (without the trigger throttle loop code) (depends on !584). Originally in !497.
- [ ] Port the n-point gain analysis (with updates to fill configuration in !584), see !689
- [ ] Port the trim analysis (original: !490, new: !667)
- [ ] Feedback configuration of Strobe Delay (not part of devel_SR1 as it's done externally), with correct chip mapping related to #169 (the input channel mapping check)
- [x] Loop action StarTrimDacLoop, should be possible to use StdParameterLoop instead
- [x] Use Fuse ID to set HCC communications ID !665
Other things that are in the branch that may or not be merged (might not be exhaustive). Mostly the code has been presented in other merge requests:
- [ ] Addition to ScurveFitter to allow extra analysis !452 and !453
- [ ] Adding integral to histo (I think this is redundant) !513
- [ ] Mutex in TxCore (basically pairing command mask and send fifo, maybe add a function ```writeFIFOToCommand(mask, buffer)```) !556
- [ ] NetIO/TxCore writeFifo 8-bit. Not sure why bytes, rather than 16-bit words are required? !391
- [ ] Report of burst timing for StarCounterLoop
- [ ] Histogram file name changes ('_' vs '-' as separator) !455
- [ ] Addition of LoopStatus to OccupancyMaps !437
- [ ] HistoFromDisk which I think is not needed if calibration information is added to configuration !432
- [ ] Broadcast write in StdParameterLoop (and prescan) potentially invalidating register fields (!477)
- [ ] Some handling of fuse IDs (needed to set up HCC communication ID). Currently m_sn is in StarChips.h but never set (!665 including rename to make it clear SN is different)https://gitlab.cern.ch/YARR/YARR/-/issues/173Differences between YARR and ITSDAQ2023-10-02T10:28:48+02:00Elise Maria Le Boulicaut EnnisDifferences between YARR and ITSDAQSome detailed studies were done to compare scan results between YARR and ITSDAQ. Some of the main findings possibly requiring action are listed below:
- The trimming algorithm is different between YARR and ITSDAQ. In YARR (!490 ), we sc...Some detailed studies were done to compare scan results between YARR and ITSDAQ. Some of the main findings possibly requiring action are listed below:
- The trimming algorithm is different between YARR and ITSDAQ. In YARR (!490 ), we scan over TrimDAC and BVT and we optimize the target BVT value such that a maximum number of channels can be trimmed to it. We then select the TrimDAC for each channel such that they get as close as possible to the target. There is also an option to optimize the trim range (BTRANGE), although in practice it is fixed to 6. In the ITSDAQ pedestal trim (code [here](https://gitlab.cern.ch/atlas-itk-strips-daq/itsdaq-sw/-/blob/master/macros/abc_star/NoiseTrimPlot.cpp)), BVT and BTRANGE are fixed to 15 and 6, respectively. TrimDAC values are scanned and the optimal ones are taken to be those that lead to an occupancy as close as possible to 50%. In principle, these two approaches should be equivalent, provided the trim target optimized in YARR is close to 15. It was found however, that these targets were higher than 15, leading to higher TrimDAC values. As a test, the YARR algorithm was modified such that the chosen trim target is as close as possible to 15 while still maximizing the number of trimmable channels (see [this commit](https://gitlab.cern.ch/arnaez/YARR/-/commit/4f3670a6f1cf7e9f72f2bd897e8f44ce81470914)). The results were then found to be very similar between YARR and ITSDAQ. Below are plots showing a comparison of optimal TrimDAC values before and after the modification in the YARR algorithm.
![trim_comparison_mod13_defaultAlg_YARR_007355_vs_ITSDAQ_20220902](/uploads/c90f12ec1e4c822e0132fe83b785ada0/trim_comparison_mod13_defaultAlg_YARR_007355_vs_ITSDAQ_20220902.png)
![trim_comparison_mod13_modifiedAlg_YARR_007399_vs_ITSDAQ_20220920](/uploads/5d4d8d5f5e0c00ee00b70c8bdb409a4d/trim_comparison_mod13_modifiedAlg_YARR_007399_vs_ITSDAQ_20220920.png)
It can also be noted that this modification led to smaller differences in the N-point gain results.
The question is then whether we want to keep the optimization of the target as originally implemented, or if we want to switch to the approach that is closer to ITSDAQ.
- In the N-point gain scan, the conversion of injected charge values from DAC to fC is different between YARR and ITSDAQ. In YARR, a conversion factor of 0.0195 is used (see [this line](https://gitlab.cern.ch/arnaez/YARR/-/blob/devel_SR1/src/libStar/StarAnalysis.cpp#L142)), whereas in ITSDAQ the conversion is hard-coded for each charge, based on simulation (see [here](https://gitlab.cern.ch/atlas-itk-strips-daq/itsdaq-sw/-/blob/master/macros/abc_star/ThreePointGain.cpp#L46)). As a test, the same "hard-coded" conversion was in YARR. This led to a reduction in the differences in gain. Below are plots showing the gain distribution for the same module, first without modifying the trimming algorithm or the charge conversion, then modifying only the trimming, then modifying both the trimming and the charge conversion.
![Gain_13_ITSDAQ_5_vs_YARR_007357](/uploads/478febfdde59bece6a5ab8715ff62771/Gain_13_ITSDAQ_5_vs_YARR_007357.png)
![Gain_13_ITSDAQ_5_vs_YARR_007444](/uploads/f7eb7e0f4e1f8d370eebe8e3b764998a/Gain_13_ITSDAQ_5_vs_YARR_007444.png)
![Gain_13_ITSDAQ_5_vs_YARR_008194](/uploads/0f81acd27f8eea27ba720bfa412930fd/Gain_13_ITSDAQ_5_vs_YARR_008194.png)
The charge conversion issue is addressed in Zhengcheng's MR !584
- The noise occupancy scan has many differences between YARR and ITSDAQ. The YARR code is found in MR !497 and the ITSDAQ code is [here](https://gitlab.cern.ch/atlas-itk-strips-daq/itsdaq-sw/-/blob/master/macros/abc_star/NOPlot.cpp). The image below shows a comparison of the noise curves, which is the log of the mean relative occupancy vs threshold squared (note there seems to be a bug in the ENC calculation in ITSDAQ):
![comparison_NO_08.31.2022](/uploads/526d78418a22c0c8bdd307483b83ce9d/comparison_NO_08.31.2022.png)
Firstly, because this scan uses the results of a previous N-point gain scan, any differences there will translate to different mV to fC conversions. The second difference which significantly affects the scan is the triggering. ITSDAQ sends bursts of 248 triggers with zero spacing, which effectively corresponds to a short trigger burst at 40 MHz. YARR sends trigger commands one-by-one at a frequency of 15kHz (configurable). Hence, the maximum number of triggers can be made much higher in ITSDAQ (64 million) compared to YARR (usually 1 million). The way that error bars are calculated for the noise curve are also different.
YARR:
![YARR](/uploads/33f56ac90a0b8a345e4e380f442eb568/YARR.png)
ITSDAQ:
![ITSDAQ_1](/uploads/9ed276435790c26251954fee3b30aa11/ITSDAQ_1.png)
![ITSDAQ_2](/uploads/0361058387d72f9329a42d243f2c4fa6/ITSDAQ_2.png)
This leads to the following questions:
1. Do we want to implement a functionality in YARR to send bursts of triggers instead of one trigger at a time?
2. How do we want to calculate the error bars? Personally, I think it makes more sense to apply binomial statistics to each channel individually rather than the mean, because it's not necessarily a given that the mean will behave in the same way as a single channel. Also, we cannot at the moment use asymmetric error bars as in ITSDAQ, since this is not supported in `GraphErrors` or `lmcurve_tyd`. Perhaps it would be worth adding this?https://gitlab.cern.ch/YARR/YARR/-/issues/172Verify scan description2022-11-09T14:53:49+01:00Bruce Joseph GallopVerify scan descriptionIt might be useful for scan console to look at the description of the scan and warn about things being missing/out of order.
Examples of things to warn about might be:
* Multiple trigger loops
* Multiple data loops
* (Strips) register c...It might be useful for scan console to look at the description of the scan and warn about things being missing/out of order.
Examples of things to warn about might be:
* Multiple trigger loops
* Multiple data loops
* (Strips) register counter loop in the wrong place
* Parameter loop inside data/trigger loop
* Missing Trigger loop
This should help with the "Trigger is not enabled, will get stuck here!" error in StdDataLoop.https://gitlab.cern.ch/YARR/YARR/-/issues/171Make the doxygen pages look better2022-11-02T15:30:41+01:00Bruce Joseph GallopMake the doxygen pages look betterDoxygen output is now available here:
https://yarr.web.cern.ch/doxygen/devel/html/index.html
Currently, many classes are not effectively documented.
Note that some things are more suitable to be documented via the docs folder.Doxygen output is now available here:
https://yarr.web.cern.ch/doxygen/devel/html/index.html
Currently, many classes are not effectively documented.
Note that some things are more suitable to be documented via the docs folder.https://gitlab.cern.ch/YARR/YARR/-/issues/170Increase FrontEnd register size to 32bit to match Star registers2022-11-01T17:46:19+01:00Timon HeimIncrease FrontEnd register size to 32bit to match Star registersIncrease FrontEnd register size to 32bit to match Star registers.Increase FrontEnd register size to 32bit to match Star registers.https://gitlab.cern.ch/YARR/YARR/-/issues/169Missing checkCom for StarChips2022-11-04T14:13:00+01:00Bruce Joseph GallopMissing checkCom for StarChipsCurrently checkCom is not implemented in the StarChips class.
This means that scanConsole will assume communication is possible.
The code should report quickly as it's implementation
A simple read register might be enough, but it cou...Currently checkCom is not implemented in the StarChips class.
This means that scanConsole will assume communication is possible.
The code should report quickly as it's implementation
A simple read register might be enough, but it could be useful to verify other things at this stage.
Things that could be part of this check:
* Read HPRs (check lock/sync etc)
* Read an HCC register (could be address register, but fuse check is separate)
* Write value associated with communications ID to an ABC register
* Read register and check input channel mapping (in other words checking we can feed back histogram data to the right ABC)
* Restore value
* Send trigger readout request
Much of this could be done in a single sequence (depending on the "restore register value" bit being well known).https://gitlab.cern.ch/YARR/YARR/-/issues/168Make sure scanConsole and write-register command return value follow the same...2023-10-19T17:36:54+02:00Elisabetta PianoriMake sure scanConsole and write-register command return value follow the same convention (<0 error)https://gitlab.cern.ch/YARR/YARR/-/issues/167Regread broken for ITkPix2023-01-27T18:01:55+01:00Matthias SaimpertRegread broken for ITkPixall in the title. the regread functionality is broken in RD53B, problem reported originally on mattermost on July.
Just opening an issue now to keep track.
tagging @theimall in the title. the regread functionality is broken in RD53B, problem reported originally on mattermost on July.
Just opening an issue now to keep track.
tagging @theimhttps://gitlab.cern.ch/YARR/YARR/-/issues/166Efuse decoding incorrect for some wafers2024-01-31T15:33:33+01:00Timon HeimEfuse decoding incorrect for some wafersThe efuse encoding for some wafers is different than the algorithm which decodes it in Yarr.
Need to collect wafer numbers for which this is true and see if we can code an exception in.The efuse encoding for some wafers is different than the algorithm which decodes it in Yarr.
Need to collect wafer numbers for which this is true and see if we can code an exception in.Francesco CrescioliFrancesco Cresciolihttps://gitlab.cern.ch/YARR/YARR/-/issues/165YARR does not run properly when using clang based compilers2024-02-02T01:45:33+01:00Matthias WittgenYARR does not run properly when using clang based compilershttps://godbolt.org/z/zcsM6nK5h
The register maps are using pointer to member functionality that is not portable.
See compiler explorer example. Works with gcc and MSV, fails with clang and icx.
The compiler does not call the derived v...https://godbolt.org/z/zcsM6nK5h
The register maps are using pointer to member functionality that is not portable.
See compiler explorer example. Works with gcc and MSV, fails with clang and icx.
The compiler does not call the derived virtual function rather the base class.
```
Base Test::* r2 = reinterpret_cast<Base Test::*>(&Test::reg2);
```
I am not sure yet if this is a gcc exploit or clang has a bug.https://gitlab.cern.ch/YARR/YARR/-/issues/164Output file doesn't contain frontEnd name (or ID)2022-08-16T15:10:09+02:00Bruce Joseph GallopOutput file doesn't contain frontEnd name (or ID)This came up in the context of !432, but I think is a more general issue. Currently the name is to be found in the histogram file name, but not inside.
At some point a reference to the configuration used might be useful as well, but tha...This came up in the context of !432, but I think is a more general issue. Currently the name is to be found in the histogram file name, but not inside.
At some point a reference to the configuration used might be useful as well, but that's for later.https://gitlab.cern.ch/YARR/YARR/-/issues/163scan_cli/ScanConsole classes are broken after restructuring the data processi...2024-02-02T01:46:25+01:00Matthias Wittgenscan_cli/ScanConsole classes are broken after restructuring the data processing codeFrom this merge on `scan_cli` is broken
https://gitlab.cern.ch/YARR/YARR/-/commit/3d880c6c2778bcccf3985241bb6f53b559aa11e7
3d880c6c breaks scan_cliFrom this merge on `scan_cli` is broken
https://gitlab.cern.ch/YARR/YARR/-/commit/3d880c6c2778bcccf3985241bb6f53b559aa11e7
3d880c6c breaks scan_cliTimon HeimTimon Heimhttps://gitlab.cern.ch/YARR/YARR/-/issues/162Issue with building controllers2022-08-11T11:40:36+02:00Elise Maria Le Boulicaut EnnisIssue with building controllersAfter pulling from devel (latest commit: 195d45e0b945c222ec15d361da72965848182c91), we are having some issues with building controllers in cmake.
The command we use is `cmake3 -j10 --DYARR_CONTROLLERS_TO_BUILD="Spec;Emu;NetioHW" ..` fro...After pulling from devel (latest commit: 195d45e0b945c222ec15d361da72965848182c91), we are having some issues with building controllers in cmake.
The command we use is `cmake3 -j10 --DYARR_CONTROLLERS_TO_BUILD="Spec;Emu;NetioHW" ..` from the build directory. However, when we run this, the controllers Spec and Emu are built, while NetioHW is not.
Similarly, when we use `--DYARR_CONTROLLERS_TO_BUILD="all"`, only Spec and Emu are built.
Our temporary solution has been to add it by hand: `set(CONTROLLERS "NetioHW")` but this is not desirable.
Any ideas? @bgallop @wittgenhttps://gitlab.cern.ch/YARR/YARR/-/issues/161Updates for PPA/PPB2022-08-20T00:25:07+02:00Bruce Joseph GallopUpdates for PPA/PPBAfter !542 some things still need updating for PPA/PPB.
In particular:
* Read register (StarRegDump.cpp)
* test_star (uses explicit register values for pulse input setup)After !542 some things still need updating for PPA/PPB.
In particular:
* Read register (StarRegDump.cpp)
* test_star (uses explicit register values for pulse input setup)https://gitlab.cern.ch/YARR/YARR/-/issues/160ITkpix ToT Memory Test2022-08-02T18:00:17+02:00Lingxin MengITkpix ToT Memory TestNot existing yet, to be developed.Not existing yet, to be developed.https://gitlab.cern.ch/YARR/YARR/-/issues/159write-register does not allow proper IMUX reading2022-11-10T09:47:22+01:00Matthias Saimpertwrite-register does not allow proper IMUX readingI am trying to read IMUX using `write-register` tool.
Here are the issues I observe:
- turn on module
- start by sending full config using `scanConsole` with e.g.
- chip1: MonitorV: 1 , MonitorI: 0
- chip2: MonitorV: 63, MonitorI:...I am trying to read IMUX using `write-register` tool.
Here are the issues I observe:
- turn on module
- start by sending full config using `scanConsole` with e.g.
- chip1: MonitorV: 1 , MonitorI: 0
- chip2: MonitorV: 63, MonitorI: 0
- chip3: MonitorV: 63, MonitorI: 0
- chip4: MonitorV: 63, MonitorI: 0
- **here I read IREF on chip1 correctly**
- leaving the module ON, I use`write-register` to:
- chip1: MonitorV: 63
- chip3: MonitorV: 63
- chip4: MonitorV: 63
- chip2: MonitorV: 1
- chip2: MonitorI: 0
- **I do not read the correct value**
this can be fixed by instead sending:
- leaving the module ON, I use`write-register` to:
- chip1: MonitorV: 63
- **chip2: MonitorV: 63**
- chip3: MonitorV: 63
- chip4: MonitorV: 63
- chip2: MonitorV: 1
- chip2: MonitorI: 0
- I do read the correct value
then I can read any IMUX value on chip 2.
However I did not find a way to read IMUX values on the other chips apart from rerunning `scanConsole`.
@fcrescio commented: "I think that write-register should read the chip register first, then perform the named register write, this should fix everything"
Thanks in advance