Hello,

On Mon, 6 Jan 2003, Albert Zwart wrote:
> First of all I wish you a Happy New Year!
Thank you! Happy New Year to all!

> [...] I can acces all I2C
> registers, only registers 18 and 19 are always 00 when read.
These are the play back registers. Each play back register is able
to store 28 bytes of data representing 32bit HitMask plus 32 drift
times (6bit wide). As the play back registers are organised as shift
registers, one first needs to program 28 bytes before one can read
back a byte not equal zero.


> I did not
> figure out what the latency register (7) is doing.
The value stored to the latency register determines the distance
between memory write and read pointer. Values greater than 0xA3
translate to 0xA3 internally. The memory pointers only adapt to a
new latency after a reset.


> After applying the trigger (and no hit input connected), I get data
> from the 4 OTIS chips! Hurray!
>
> data: 003 fed43010 11111110110101000011000000010000     Otis #3 Header
> data: 012 72102009 01110010000100000010000000001001     Otis #2 header
> data: 021 72105081 01110010000100000101000010000001     Otis #5 header
> data: 030 72104081 01110010000100000100000010000001     Otis #4 header
Am I right that the righmost bit of each line is the LSB of the first
byte of each chips data output stream? If so, chips #2, #4 and #5 show
the same BX Counter - good. Chip #3 shows a different BX Counter, a
strong indication that synchronisation failed. Apart from this the two
status bits 'DLL Lock lost' and 'Single Event Upset' are set for chip
#3. This is another hint for failed reset/synchronisation because
during operation these bits cannot be set in the current version of
the OTIS chip.
A third point is that the 'PlayBack Busy' bit is set in the data
stream of chip #3. This could explain the drift times for chip #3 but
the synchronisation problem would remain because of the different
content of the BX Counter register compared to the other chips.

If I interpret the bit patterns correct, you should check if all chips
recieve the same clock and reset signals in order to synchronise
correctly.


> It appeared that the reset is active when pad Reset = low and pad notReset
> = high, which is different as I could expect from the documentation.
Reset is active when the LVDS pad (pads 35/36) recieves levels
representing zero (IIRC 1.0V @ Pad 36 and 1.4V @ Pad 35).


> Furthermore; there is no timing requirement between clock and reset to be
> met according to the documentation, does this mean that the reset is
> asynchroneous? If so, I do not think this is a good idea.
A DLL test chip needed special timings to be met between clock and
reset. This requirement does not exist anymore for OTIS1.0.


> The I2C register 3 (ReceivedT) is not reset by reset.
Correct6. Registers #2, #3 and #4 can be cleared in two ways:
 * Power Up Reset clears all these registers.
 * Any I2C write access clears the adressed register


> Can I generate a powerup reset by pulling down the PwrUpReset pad?
Yes, this is possible. But you need to (re)program the registers
afterwards and it is important to (re)synchronise the chips with a
(fast) reset.



> Best Regards, Albert

Best regards,
   Uwe

P.S.: I moved the discussion to our otis-user mailing list - hope this
      is OK.

--
Uwe Stange
Physikalisches Institut der Universitaet Heidelberg
c/o Kirchhoff-Institut fuer Physik, ASIC Labor,
    INF 227, 69120 Heidelberg,  Tel: 06221/549151
    http://wwwasic.kip.uni-heidelberg.de/lhcbot/about.html