From pwp@v2.rl.ac.uk Fri Jul  3 23:04:09 1998
Date: Fri, 3 Jul 1998 13:04:31 +0100
From: "P.W.Phillips@rl.ac.uk" <pwp@v2.rl.ac.uk>
To: UNNO@post.kek.jp, GARETH.MOORHEAD@cern.ch
Subject: Re: efficiency problem in reading 3 chips

Hi Nobu,


>  The GAL 1234 which I use now is "SLL GAL 1234 rev.01".  I have one set
> (4 IC's) of "ABC GAL1234 rev.01".  Should I swap the SLL GAL to the 
> ABC GAL?

Putting the ABC GAL into the socket nearest the front (connector end) of the LL 
card should solve most of your problems.  I have read up to five chips with the 
new GALs with only 1% errors, and these are not errors which would lead to 
excess occupancy.

With the old SLL GALs things _should_ work for up to 3 chips, but it would 
appear that I do not set counter value correctly in the three chip case. 

>   The outLog_daq.txt says "Missed Trailer Pattern" in every events.
> Although it says "Missed...", the daq run smoothly.  We bonded the
> "datain0/datain0B" of the 3rd chip to the "DGND/VDD" as was done for
> the reading 2 chips.  Any suggestion to detect the "Trailer"?  Is 
> the "ABC GAL" solving the problem?

>					Nobu
 

What is happening is probably that counter val is set to too small a value, the 
LL card stops reading in the data partway through the third chip.  If a valid 
header pattern occurs later, the old GAL starts reading in the data again - but 
a portion of the data has been missed.  This problem will not occur with the new 
ABC GALs.

The decode routine will work correctly until it reaches the point at which the 
data is corrupt.  The bit which signifies "continued strip data" is missing, so 
the decoding falls out to the loop which looks for a trailer, a chip address or, 
if it fails, a "MISSED TRAILER".  It then interprets the remaining data somehow 
as strip data for the first chip.

> Main Loop: word 0 of 252
>  Found event 1 l1 1 bc 0
>   Data for channel 0
>   Data for channel 128
>   Data for channel 256
>          debug 3a2010
>       ** MISSED TRAILER **
>          debug e8806800 22222220 e88068 888888
>     385 hits this event
> Main Loop: word 50 of 252
>  Found event 2 l1 3 bc 3
>   Data for channel 0
>   Data for channel 128
>   Data for channel 256
>          debug 83a4030
>       ** MISSED TRAILER **
>          debug e900e800 22222222 222020e9 e80088
>     385 hits this event
> Main Loop: word 151 of 252
>  Found event 3 l1 0 bc 2
>   Data for channel 136
>   Data for channel 128
>   Data for channel 256
>          debug 3a5050
>       ** MISSED TRAILER **
>          debug e9416800 22222000 e9416800 88888888
>     381 hits this event
> Main Loop: word 201 of 252
>     0 hits this event
>       Leaving decode routine

(deleted)

> events:   101 missed trailers: 99
> l1 stats: 36 5 4 5 4 4 4 4 6 4 4 4 4 4 5 4
> bc stats: 20 14 46 19 0 1 0 0 0 0 0 0 0 0 0 0 ...
> DoCalibrate completed

In principle the last section should be more like:

events: 100 missed trailers: 0
l1 stats: 7 7 7 7 6 6 6 6 6 6 6 6 6 6 6 6 
bc stats: 20 20 20 20 20 0 0 0 0 0 0 0 0 0 0 0 ...

Similarly the events should have l1 in ascending order (1,2,3,4,...) and bc
(0, 1, 2, 3, 4, 0, 1, 2, 3, 4, 0, 1, 2, 3, 4...).  This is not what you are 
getting.  You have events starting at words 0, 50, 151 and 201 - what the old 
GALs are judging to be a valid event at word 100 is being "missed" by the 
decoding.

Change to the new GAL and let me know what happens.  I will also look at the 
decoding to see if I can make it more robust.  It could be that there is still a 
problem somewhere, either with your clock phasing or else with my decoding 
routine....

Cheers,

Peter.