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