lpgbt_control_lib issueshttps://gitlab.cern.ch/lpgbt/lpgbt_control_lib/-/issues2023-07-03T16:40:33+02:00https://gitlab.cern.ch/lpgbt/lpgbt_control_lib/-/issues/13Byte order swapped in the chipid readout2023-07-03T16:40:33+02:00Szymon KulisByte order swapped in the chipid readoutWhile investigating the question by @solodkov in https://lpgbt-support.web.cern.ch/t/burning-e-fuses/950 I noticed a inconsistency in the way how the chipid is being handled (RAM vs FUSES):
```python
In [1]: tester.lpgbt.set_bootcnf_pin...While investigating the question by @solodkov in https://lpgbt-support.web.cern.ch/t/burning-e-fuses/950 I noticed a inconsistency in the way how the chipid is being handled (RAM vs FUSES):
```python
In [1]: tester.lpgbt.set_bootcnf_pins(Lpgbt.BootConfig.LOAD_FUSES_NO_CRC)
In [2]: tester.lpgbt.generate_reset_pulse()
In [3]: "%08x"%tester.lpgbt.fuses_read_bank(0)
Out[3]: '2428d47d'
In [4]: tester.lpgbt.read_regs(0,4)
Out[4]: [125, 212, 40, 36]
In [5]: tester.lpgbt.get_chipid_fuses()
Out[5]:
{'chipid': '2428D47D',
'chipid_raw': '2428D47D',
'hamming_errors': 0,
'redundancy_detected': True,
'voting_errors': {}}
In [6]: tester.lpgbt.get_chipid_ram() <- PROBLEM
Out[6]:
{'chipid': '39146CE4',
'chipid_raw': '39146CE4',
'hamming_errors': 0,
'redundancy_detected': True,
'voting_errors': {4: {'voted': 0, 'bits': [0, 1, 0, 0, 1]},
5: {'voted': 1, 'bits': [1, 0, 1, 1, 0]},
6: {'voted': 1, 'bits': [0, 1, 0, 1, 1]},
7: {'voted': 1, 'bits': [0, 1, 0, 1, 1]},
8: {'voted': 0, 'bits': [0, 0, 1, 0, 1]},
10: {'voted': 1, 'bits': [0, 1, 1, 0, 1]},
12: {'voted': 0, 'bits': [0, 1, 0, 0, 1]},
14: {'voted': 1, 'bits': [0, 1, 0, 1, 1]},
20: {'voted': 1, 'bits': [1, 0, 1, 1, 0]},
21: {'voted': 0, 'bits': [0, 1, 0, 0, 1]},
22: {'voted': 0, 'bits': [1, 0, 1, 0, 0]},
23: {'voted': 0, 'bits': [1, 0, 1, 0, 0]},
24: {'voted': 1, 'bits': [1, 1, 0, 1, 0]},
26: {'voted': 0, 'bits': [1, 0, 0, 1, 0]},
28: {'voted': 1, 'bits': [1, 0, 1, 1, 0]},
30: {'voted': 0, 'bits': [1, 0, 1, 0, 0]}}}
```Szymon KulisSzymon Kulishttps://gitlab.cern.ch/lpgbt/lpgbt_control_lib/-/issues/12BERT Timeout to be dynamic2022-02-03T10:09:12+01:00Daniel Hernandez MontesinosBERT Timeout to be dynamicIn [lpGBT line 1310](https://gitlab.cern.ch/lpgbt/lpgbt_control_lib/-/blob/master/lpgbt_control_lib/lpgbt.py#L1310), the timeout is not dynamically set depending on the meas_time based time. This should be changed as for every BER going ...In [lpGBT line 1310](https://gitlab.cern.ch/lpgbt/lpgbt_control_lib/-/blob/master/lpgbt_control_lib/lpgbt.py#L1310), the timeout is not dynamically set depending on the meas_time based time. This should be changed as for every BER going above 32 M clock cycles we exceed the timeout.https://gitlab.cern.ch/lpgbt/lpgbt_control_lib/-/issues/11Update register map2022-01-18T10:55:38+01:00Szymon KulisUpdate register mapUpdate lpGBTv1 register map to include changes from https://gitlab.cern.ch/lpgbt/lpgbt_rtl/-/merge_requests/683Update lpGBTv1 register map to include changes from https://gitlab.cern.ch/lpgbt/lpgbt_rtl/-/merge_requests/683Szymon KulisSzymon Kulishttps://gitlab.cern.ch/lpgbt/lpgbt_control_lib/-/issues/10Missing constants for number of registers (similar to READ_WRITE_REGS)2022-02-21T08:07:43+01:00Stefan BiereigelMissing constants for number of registers (similar to READ_WRITE_REGS)By request from @nguettou.
It would be convenient to have constants similar to `READ_WRITE_REGS` for the number of registers for R/W/F, R/W, RO, and total.By request from @nguettou.
It would be convenient to have constants similar to `READ_WRITE_REGS` for the number of registers for R/W/F, R/W, RO, and total.https://gitlab.cern.ch/lpgbt/lpgbt_control_lib/-/issues/9Unified, machine-digestible status reporting2021-11-09T16:21:57+01:00Stefan BiereigelUnified, machine-digestible status reporting(Request via piGBT)
It would be nice to have a way of getting status results (locked EPRX channels, phase shifter configuration etc) in a machine-digestible form, instead of just the strings the current `*_status` methods return. Also, ...(Request via piGBT)
It would be nice to have a way of getting status results (locked EPRX channels, phase shifter configuration etc) in a machine-digestible form, instead of just the strings the current `*_status` methods return. Also, we should keep a consistent way of obtaining the string representation and the logging wrappers.
Affected methods:
* `log_pusm_status`
* `phase_shifter_status`
* `eprx_group_status`
* `(log_eprx_group_status)`
* `(log_all_eprx_groups)`
* `eptx_group_status`
* `(log_eptx_group_status)`
* `(log_all_eptx_groups)`
* `eclk_status` (log_ counterpart is missing!)
* `gpio_status`
* `(log_gpio)`
* `chip_status`
* `eprx_ec_status`, `eptx_ec_status` currently missing (requested by Nour)https://gitlab.cern.ch/lpgbt/lpgbt_control_lib/-/issues/8Send 16 bytes address and data command2021-10-18T18:23:14+02:00Nour El Houda GuettoucheSend 16 bytes address and data commandAfter discussion with Pedro, the i2c master must take into account the method of writing data and address on 16 bytes which includes the register address + data nbytes. Which means that the supported I2C write length must be 16 (range 17...After discussion with Pedro, the i2c master must take into account the method of writing data and address on 16 bytes which includes the register address + data nbytes. Which means that the supported I2C write length must be 16 (range 17).
[Here](https://gitlab.cern.ch/lpgbt/lpgbt_control_lib/-/blob/master/lpgbt_control_lib/lpgbt.py#L2311) data should be asserted from 0 to 16 and register address + data from 0 to 17.
Same comment [here](https://gitlab.cern.ch/lpgbt/lpgbt_control_lib/-/blob/master/lpgbt_control_lib/lpgbt.py#L2259).https://gitlab.cern.ch/lpgbt/lpgbt_control_lib/-/issues/7Exception types should be differentiated2021-10-07T13:49:15+02:00Stefan BiereigelException types should be differentiatedFor exception handling, it would be nicer to have a bunch of exception subclasses that allow differentiating different errors.
List of what LpgbtException is currently used for:
* Control pin access error (should be `KeyError` or `Att...For exception handling, it would be nicer to have a bunch of exception subclasses that allow differentiating different errors.
List of what LpgbtException is currently used for:
* Control pin access error (should be `KeyError` or `AttributeError`?)
* "Delay out of range" for phase shifter (should be just `ValueError`?)
* "BERT Timeout"
* "EOM Timeout"
* "ADC Timeout"
* Incorrect fuse bank provided (should just be `ValueError`?)
* Unexpected Error during Fusing
* Fusing timeout
* Timeout while waiting for PUSM state
* I2C master:
* SDA is low before xaction
* transaction not acknowledged
* timeout
* procmon timeout
I propose a list of additional exceptions as follows:
* `LpgbtTimeoutError`: for BERT, EOM, ADC, Fusing, Procmon and I2C master timeouts
* `LpgbtI2CMasterBusError`: for I2C master SDA fault condition
* `LpgbtI2CMasterNAKError`: for I2C master transaction NAK error
* `LpgbtFuseError`: for unexpected error during fusing
@nguettou @pevicent does this address all the needs you have to differentiate exceptions? Is handling all the timeouts in a single exception type sufficient or would we need to have more granular exception types available here (possibly as subtypes of `LpgbtTimeoutError`)?https://gitlab.cern.ch/lpgbt/lpgbt_control_lib/-/issues/6Missing i2cmaster 10bits addressing support2021-09-02T11:45:51+02:00Nour El Houda GuettoucheMissing i2cmaster 10bits addressing supportSlave sends a Not Acknowledge bit in 10-bit addressing modeSlave sends a Not Acknowledge bit in 10-bit addressing modeNour El Houda GuettoucheNour El Houda Guettouchehttps://gitlab.cern.ch/lpgbt/lpgbt_control_lib/-/issues/5Calling eprx_group_status runs into TypeErrors: 'type' + 'int' - an int group...2021-06-18T15:15:55+02:00Alex ToldaievCalling eprx_group_status runs into TypeErrors: 'type' + 'int' - an int group_id is being added to a class EPRX0CONTROLI set up the library to work with smbus2 as the i2c backend. To confirm that the library works I call `LpgbtV0(...).read_mode()` method. It works fine and returns the correct mode. But `.eprx_group_status(0)` runs into errors like this o...I set up the library to work with smbus2 as the i2c backend. To confirm that the library works I call `LpgbtV0(...).read_mode()` method. It works fine and returns the correct mode. But `.eprx_group_status(0)` runs into errors like this one:
```
.../lpgbt.py", line 969, in eprx_group_status
control_reg = self.read_reg(self.EPRX0CONTROL + group_id)
TypeError: unsupported operand type(s) for +: 'type' and 'int'
```
There is a class and an int `EPRX0CONTROL` in `lpgbt_register_map_v0.py` (and v1). The int does look like an address. And it is accessible with `self.Reg.EPRX0CONTROL`. So, I changed the 969 line in `lpgbt.py` like this. Now the same error happens further in the method:
```
.../lpgbt.py", line 994, in eprx_group_status
locked_reg = self.read_reg(self.EPRX0LOCKED + 3 * group_id)
TypeError: unsupported operand type(s) for +: 'type' and 'int'
```
Could you check what should be done here? Should I just use `self.Reg.` to get these registers? If so, I could patch this up and open a merge request.Szymon KulisSzymon Kulishttps://gitlab.cern.ch/lpgbt/lpgbt_control_lib/-/issues/4Add a function to configure the test outputs feature2021-06-15T17:08:38+02:00Nour El Houda GuettoucheAdd a function to configure the test outputs featureIs it possible to add a feature to the test output parameters? We need some way to pass the index of the test output .
Depending on the selected pin (CMOS or differential), it would be helpful to be able to set the following values : the...Is it possible to add a feature to the test output parameters? We need some way to pass the index of the test output .
Depending on the selected pin (CMOS or differential), it would be helpful to be able to set the following values : the drive strength, the pre-emphasis mode, pre-emphasis strength, the pre-emphasis pulse and the invert data option.
It would be nice to have this feature for the piGBT as well. Here is the current implementation:
https://gitlab.cern.ch/lpgbt/pigbt/-/blob/master/backend/apiapp/api.py#L1825Szymon KulisSzymon Kulishttps://gitlab.cern.ch/lpgbt/lpgbt_control_lib/-/issues/3Implement(extend) the low level driver for lpGBTv12021-09-27T10:25:02+02:00Szymon KulisImplement(extend) the low level driver for lpGBTv1Szymon KulisSzymon Kulishttps://gitlab.cern.ch/lpgbt/lpgbt_control_lib/-/issues/2Make this repo a proper Python Package2021-03-23T14:25:38+01:00Stefan BiereigelMake this repo a proper Python PackageRemember: also expose the LpgbtException class so users can handle errors!Remember: also expose the LpgbtException class so users can handle errors!https://gitlab.cern.ch/lpgbt/lpgbt_control_lib/-/issues/1Refactor Registers, Constants and Argument Sanitization2021-06-03T09:02:52+02:00Stefan BiereigelRefactor Registers, Constants and Argument SanitizationSzymon KulisSzymon Kulis