[Halld-tracking-hw] F125ADC what do we want / need
Naomi Jarvis
nsj at cmu.edu
Tue Jul 16 23:07:03 EDT 2013
Hello,
For the CDC:
With B field and some deformation in some of the straws we need to allow for max drift time of 1240ns.
Pulse is not needed. Understood that the FDC does need it though.
Time.
If we output time as integer number of 0.1ns this will fit into 13 bits. Clearly we need to have the time measurement from the flash better than the drift chamber's time resolution; I think we already have this with 1ns (12 bits), but if there is room for 13 bits, great.
Integral.
Ok with 17 bits. Also ok with 16.
Integer resolution for the integral is OTT but we do need the range. I would prefer to trade in some precision and divide the integral by 4 (or more) before storing, that would be 17 bits (or less). For saturated events see the 3rd row of https://halldweb1.jlab.org/wiki/index.php/CDC_odd_events Most of the channels are saturated but there are a few which look ok. From looking at this I would put 3500 as the limit for a reasonable sustained maximum. With max drift 1.24ns, 155 samples x (3500-pedestalof50)=534750 which needs 19 bits at integer precision, or 17 if divided by 4. Minimum integral would be a peak only just over threshold ~80 high, ~6 samples wide = 240 ish.
Pedestal
I did not explain this well. My reasons for recording pedestal are to keep an eye on pedestal drifts (alarm points) and indicate if the present hit is sitting on the tail of another. We do not need full precision for this and I think it will be ok to monitor pedestal divided by 4. If we also set an upper recording limit eg 500 (range 0-4095) then when divided/4 this will fit into 7 bits. I would use the upper limit because if a pedestal that high would probably be the tail of an earlier hit.
QF - time
1 bit to indicate when my algorithm has run on past the original threshold time and a less accurate time is being returned
1 extra bit to flag when the leading edge gradient is low (indicates noise, useful for small amplitude signals).
QF - integral
The preamp saturates at ~0.5V but the behaviour of the flash is more complicated because it is also a shaper.
Anyway, OK with counting up to 15 samples.
QF - extra?
It might be a good idea to keep some spare room in the QFs in case we find that we need something extra when the algorithms have been coded onto the flash.
Best,
Naomi.
On Jul 16, 2013, at 9:42 PM, David Lawrence wrote:
>
> Hi All,
>
> Based on Gerard's comments and a discussion with Elton, I have updated the bit assignments.
> Given the larger number of bits in the time field, it made sense to move it to the second word
> so that it is not split between the first and second words. Other significant changes from the
> previous iteration:
>
> 1.) pulse time increased to 14 bits
>
> 2.) pulse integral reduced from 19 to 17 bits. Since it is a 12bit ADC, this still gives enough
> range to record a pulse with (17-12 = 5bits =) 32 samples in saturation. This should more
> than exceed any reasonable sized signal.
>
> 3.) pedestal increased from 8 bits to 9 bits
>
> 4.) Q.F. reduced from 6 bits to 4 bits. This will still allow up to 15 samples to be in saturation
> corresponding to the signal being over 1V for more than 120 ns. Again, a signal this large
> probably has something wrong with it and should be discarded anyway.
>
> We can discuss this at the Wed. tracking meeting if there is time.
>
> Regards,
> -David
> <gfhaahhe.jpg>
> On 7/16/13 1:42 PM, Curtis A. Meyer wrote:
>> At least for the CDC, the most important measurement is the time, so I do not want to
>> compromise there. As for the pulse integral, the real issue is dynamic range. What is the
>> smallest meaningful amplitude that we want to measure, and what is the largest sensible
>> amplitude that we could measure.
>>
>> curtis
>> -------
>> Prof. Curtis A. Meyer Department of Physics
>> Phone: (412) 268-2745 Carnegie Mellon University
>> Fax: (412) 681-0648 Pittsburgh, PA 15213
>> curtis.meyer at cmu.edu http://www.curtismeyer.com/
>>
>>
>>
>>
>>
>> On Jul 16, 2013, at 12:22 PM, Gerard Visser <gvisser at indiana.edu> wrote:
>>
>>> hi all,
>>> Although I'm now not directly involved in the effort to define & design the
>>> ADC125 algorithms and data format, I would like to comment here that in my
>>> opinion there are too many bits devoted to pulse amplitude (19) and too few
>>> devoted to time (11). You will never get an amplitude measurement with 19
>>> significant bits, I think. I would suggest flip a few more bits over to time,
>>> for instance make it 16 bits amplitude and 14 bits time. In particular, it
>>> should be possible to have time resolution down to 1/2 ns or 1/4ns, at least it
>>> is less of a stretch to believe in the significance of those digits than in the
>>> significance of an amplitude measurement to 2 ppm (19 bits).
>>> Sincerely,
>>>
>>> Gerard
>>>
>>> On 7/16/2013 12:05 PM, David Lawrence wrote:
>>>>
>>>> Hi Naomi,
>>>>
>>>> Thanks for the feedback. I have some comments on your suggestions below:
>>>>
>>>> On 7/15/13 4:27 PM, Naomi Jarvis wrote:
>>>>> Hello,
>>>>>
>>>>> I prefer option 1, the coupled words with pedestal, as it packs more info into
>>>>> the same space.
>>>>>
>>>>> First word
>>>>>
>>>>> Do we need the 2bits for 'pulse'? From looking through the spec it seems that
>>>>> this is to label up to 4 pulses for which time data is to be sent. For the
>>>>> CDC this would always be 1, just 1 pulse, so could we dispense with it?
>>>>>
>>>> I think there should be enough room in the 64 bits to keep the 2 bits for this.
>>>> I would hate to give this up unless we really have to. Since we'll be using
>>>> these for the FDC cathodes which will have a much higher rate, it could be very
>>>> useful.
>>>>
>>>>> We would like to increase the bits available for time data from 10 to 11 bits,
>>>>> as an integer # of ns, that gives us 0-2047 ns. This allows some headroom for
>>>>> slower drift times.
>>>>>
>>>> This seems reasonable to me. If we move the 3 bits for the Q.F. down to the
>>>> second word as you suggested, we can use one of those.
>>>>
>>>>>
>>>>> Second word
>>>>>
>>>>> Pedestal. I would indeed like to include this but it is not necessary to have
>>>>> full range 0-4095 available in integer steps. We will set the pedestals to
>>>>> something low, ~55-60. How about outputting pedestal/8 to cover the subrange
>>>>> pedestal=0-504 as pedestal/8=0-63 in 6 bits. ?
>>>>>
>>>> I'm not sure if I fully understand your notation of pedestal/8, but I think your
>>>> main point is that we can just limit the range of the pedestals to be within
>>>> that defined by 6 bits. Either by adjusting voltage offsets or applying an
>>>> offset parameter to the FPGA. Just to be clear though, the 6bits of pedestal
>>>> would have the same resolution as the integral right? (i.e. changing the
>>>> pedestal by 1 is equivalent to changing the pulse integral by 1)
>>>>
>>>>> Integral. OK.
>>>>
>>>> Actually, I'm thinking we could reduce this by a couple of bits. With a 12bit
>>>> ADC, storing 19 bits for the integral means we could have up to 7bits=128
>>>> samples in saturation without overflowing. This would correspond to a pulse that
>>>> is over 1V high for more than 1 microsecond. That seems unlikely to provide
>>>> anything useful (correct me if I'm wrong here.) We could move 2 bits from this
>>>> to the Q.F. allowing use to keep 8 bits for the pedestal.
>>>>>
>>>>> Integral quality factor.
>>>>> I would like to include a count of the number of overflowed samples
>>>>> contributing to the integral, this could count up to 63 samples (504ns) in the
>>>>> 6 bits freed up from the pedestal.
>>>>
>>>> OK
>>>>
>>>>
>>>> Here is a revised diagram which incorporates your suggestions and then my
>>>> modifications to those. Let me know what you think.
>>>>
>>>>
>>>> Regards,
>>>> -Dave
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Halld-tracking-hw mailing list
>>>> Halld-tracking-hw at jlab.org
>>>> https://mailman.jlab.org/mailman/listinfo/halld-tracking-hw
>>>>
>>> _______________________________________________
>>> Halld-tracking-hw mailing list
>>> Halld-tracking-hw at jlab.org
>>> https://mailman.jlab.org/mailman/listinfo/halld-tracking-hw
>>
>>
>>
>> _______________________________________________
>> Halld-tracking-hw mailing list
>> Halld-tracking-hw at jlab.org
>> https://mailman.jlab.org/mailman/listinfo/halld-tracking-hw
>
> _______________________________________________
> Halld-tracking-hw mailing list
> Halld-tracking-hw at jlab.org
> https://mailman.jlab.org/mailman/listinfo/halld-tracking-hw
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://mailman.jlab.org/pipermail/halld-tracking-hw/attachments/20130716/4d990e69/attachment-0001.html
More information about the Halld-tracking-hw
mailing list