[Halld-tracking-hw] F125ADC what do we want / need

[Gerard Visser]

hi all,
	A firmware version field is also an excellent thing, but please consider an 
explicit data format version field. In most of the readout boards I've been 
involved with in STAR, we include both of these things. Of course, the average 
event size in STAR is probably much bigger than in GlueX so maybe we just have 
less reason to make really bare-bones headers. I don't have a good feel for what 
is really best here. But a format version is very nice, the data reader software 
can keep up with all data with complete backwards compatibility.
	Most firmware revs of course are not going to be changing the data format (one 
would hope!). And few bits are needed for format code, whereas you should allow 
a large number like 12 at least for firmware rev, maybe 16 better.
	Actually, things like the firmware version and other housekeeping parameters 
might not be needed in each event or each block. What I have done on other 
projects is define a generic "housekeeping" field that cycles between several 
functions, of course with some of the bits dedicated to identifying which it is. 
With this you can have many status words that rarely or never change during a 
run, but compactly encoded in the header.
	The data format version I would leave directly in the header in a simple way, 
so that you don't need to see more than one event or block to know what to do 
with the data. Only the parameters that the reader doesn't really need to do 
anything with, would be compacted into the "housekeeping" field.
	Anyway, this is just my 2 cents for consideration; it's probably not a good 
idea to diverge to far from existing work on the other boards, maybe it is too 
late for some of this discussion.

	- Gerard

p.s. The data format code _might_ even be allowed to vary dynamically, e.g., to 
distinguish a raw-mode event from a normal one.

On 7/17/2013 7:54 PM, Naomi Jarvis wrote:
> Hi Gerard,
>
> Thankyou, that was very helpful for our discussion this morning
> https://halldweb1.jlab.org/wiki/index.php/July_17,_2013_Tracking_CDC/FDC
>
> For the CDC, if the leading edge algorithm fails then I was planning to make it
> return the initial threshold crossing time minus a constant (TBD, something like
> 40ns), and flag this in the quality factor, so that the error on the hit time
> can be increased in the tracking.
>
> Including the firmware version is a great idea, David thought the best place for
> it would be the block header.
>
> Best regards,
>
> Naomi.