Minutes: BOM (Beetle & Otis Meeting) 24.01.2002 14:00 ASICLab

Participants: Harald Deppe, Sven Loechner, Dirk Wiedner,
              Ulrich Trunk, Uwe Stange

Otis:
=====

1) Harald Deppe is working on the multiplexer. For DLL, hitregisters
(32 channels), decoder (1 channel) and PrePipelineLogic (1 channel)
the LVS is OK.

2) Power estimation:    DLL:            10mA
                        Decoder:        45mA (32 channels, 50% occ)
                        PPL/Mux:         ?
                        Control alg:    65mA (rough estimation from
                                              Beetle data)
                        Memory:         50mA (w/o DBuffer)
                        GOL:           400mW (@ 1.6GBit incl VCSEL)

Without the GOL chip this roughly sums up to 200mA (i.e. 500mW). With
a safety factor of 2 this leads to an estimated upper bound of 1W per
Otis.

3) Uwe Stange is working on the simulation of the control algorithm:
Simulation consists of all parts that will be synthesized and all
additional parts (pre pipeline registers, pipeline, derandomizing
buffer, I2C bus, ...). There are some wiring bugs left. First
results expected next week.
Synthesis of the first modules has started - no problems so far.

4) The OTIS prototype will provide a power up reset (resetting all
programmable registers) and a (fast) reset (resetting BX- and Trigger
counter, all state machines and DLL). The use of a synchronisation
reset (resetting only BX- and trigger counter) should be considered
for next versions of the OTIS chip. Also a reset via slow control
resetting the DLL (which needs the clock signal to lock).

5) Jan Knopf and Dirk Wiedner try to reactivate the derandomizing
buffer test setup. Two new boards (one fully equipped) will be
available next week.


Beetle:
=======

1) Sven Loechner is changing the multiplexer which then will
not have problems at low trigger rates.

2) Sven Loechner is simulating the new frontends in order to compare
the results with measurements from Nikhef and Zurich.

3) Measurements from Nikhef do now also state that the new frontends
will have no saturation problems.


Misc:
=====
1) Canopus (Sun Fire 280R) is ready to work with. Canopus is
integrated in the ADSM backup system. Remaining problems ("response
time") are considered to result from exporting the display to the
desktop PC.
There should be a discussion defining an user policy for canopus and
polaris.

2) ES (boot server for dreisam) was hacked. After restoring all data
the computer will be switched of. When es and dreisam will be needed
again their network should have no connection to other networks.

--
Uwe Stange                 http://www.uwe-stange.de
Physikalisches Institut der Universitaet Heidelberg
c/o Kirchhoff-Institut fuer Physik, ASIC Labor,
    Schroederstr. 90, 69120 Heidelberg,  Tel: 06221/544357
    http://wwwasic.kip.uni-heidelberg.de/lhcbot/about.html