ADC125 data format, 2nd try --- and FDC hit limit

[Gerard Visser <gvisser@indiana.edu>]

Hall D Electronics:

Hi,
	Since I had obviously given little consideration to the event size in 
my 1st attempt to define a data format for the 125MSPS ADC board 
(emailed to Elliot, Dave, Chris on 5/9/07), I have completely reworked 
it for compact/minimal form. I have included in on the portal as part of 
GlueX-doc-855.
	All interested parties, please examine and complain if there are any 
problems. This document will be used in designing the FPGA's (not yet, 
but someday soon I hope).
	The executive summary of byte counts:
	- Every board generates a 4 byte header for every event.
	- Every hit generates a 6 byte record including channel number, pulse 
time, and pulse amplitude. If there were multiple, distinguishable 
pulses in the window for a given channel, and the algorithm was set up 
to deal with this, there will be 6 bytes for each of them. Could be from 
two events, or could be a scraggily pulse.
	- Every module with one or more hits will generate on average 6 more 
bytes of header/trailer.
	So, if the FDC has N cathode-strip-clusters of M strips >ZS each, the 
FDC data volume will be 512+N*M*6+N*6, assuming that most clusters don't 
split across ADC boards and most boards don't see >1 cluster. This is 
probably true, but depends on details of cable map, of course, and other 
things.
	For <50 bytes average per event per board (--> VME running 160 MB/s @ 
200 kHz trigger rate), we need roughly <785 average FDC hits. That's 
assuming a strip cluster size of 4. This is somewhat of a margin  above 
Dave's simulated hit counts presented yesterday, but not a lot. If 
on-board cathode position fitting were developed (a large effort I'm 
sure, but probably possible), it would raise the limit at least by a 
factor of 2-3. Probably should be considered a fallback option, pending 
tests with full-scale FDC.

	Gerard

p.s. If it is required to enlarge the trigger timestamp (10 bits) or the 
event number (7 bits) that's fine but will certainly imply 8 bytes used 
for every board, i.e., 1024 bytes of FDC header data.

p.p.s. 	A hit which the algorithm identifies as exceptional (weird pulse 
shape, for instance) can either be dropped or reported in raw mode. 
Additionally some small fraction of events (0.1% ??) should be triggered 
for raw-mode readout to check & calibrate the algorithms. Raw-mode will 
add 2 bytes per sample point per hit, e.g. probably 40-80 bytes per hit.