Register access problem in Belle2Link M. Shoji (KEK) and S. Nishida (KEK)

ARICH Electronics (FE) Merger FE ASIC FE FPGA Belle2Link (B2L)

Use of slow control in ARICH We use B2L slow control for Parameter setting of the FE Data volume : ~ 16 Kbit Download of FE FPGA firmware Data volume : ~ 3 Mbyte

Problem observed in the slow control in the ARICH Failure in reading the register value. The problem occurs randomly; it occurs even when the data readout is not done. Once the problem happens, the read out value becomes always the same. The recovery can be done only by re- downloading the HSLB firmware. (Here, I call “hang-up” problem)

Read/Write test of the slow control normal condition Logic analyzer(FEE monitor) (Read/Write the lower 8bit) write write value = 0x05 read read value = 0x05 PC monitor write value = 0x05 read value = 0x05 Read value is consistent.

Read/Write test of the slow control when the problem happens Logic analyzer(FEE monitor) (Read/Write the lower 8bit) write write value = 0x05 read read value = 0x05 PC monitor write value = 0x05 read value = 0x01 Read value is inconsistent.

Check the HSLB status with “staths” command Normal condition During the problem Error Once the problem happens, the returned value from HSLB is always the same For recovery, HSLB firmware needs to be downloaded again.

COPPER Driver The hang-up problem might be dependent to the COPPER driver (?) /dev/copper/fngeneric : more frequently happened. /dev/copper/hslb : ARICH is now using this driver.

Other problem : access too slow We send FE FPGA firmware using the slow control. Data volume : ~ 3 Mbyte We add 10 usec of usleep() at each access (to avoid the hang-up problem). Runtime : 5h30m Too slow !! With SiTCP operation, it takes only 1 min or so. If “Batch mode” helps, we want to try (but DAQ people don’t know about it).

Hand-shake access Another possible solution may be to check the status of HSLB after sending slow control data: ( i.e. write operation  check HSLB status  send next bit if OK, otherwise usleep() for a while). Concern: the register access to check the HSLB status may cause the slow control hang- up problem. Not tried yet, but this method work only if we can drastically reduce usleep() in the program.