[Halld-tracking-hw] fADC125 FE firmware

[Naomi Jarvis]

Hi Cody, Gerard,

Yes I think it does need a head-start of 5 samples. When upsampling a smaller chunk of the data, 20 samples total was enough, starting 10 before the initial hit threshold.  There is a little more info here https://halldweb1.jlab.org/wiki/index.php/LE_algo  and Gerard's original code is still here http://npvm.ceem.indiana.edu/~gvisser/GlueX/rdat.c  I'll send you (Cody&Beni) my c++ code when I've cleaned it up a bit. 

Naomi.


On Aug 6, 2013, at 12:50 PM, Gerard Visser wrote:

> Hi Cody,
> 	If the upsampling is done continuously then the processing has to be done in 
> the frontend FPGA's, obviously you don't want to send 4-5x as much data over the 
> daisy-chain to "processor" FPGA.
> 	Perhaps you will find that you can fit all the required processing in the 
> frontend FPGA's. This would be nice, and would remove any concerns about the 
> readout daisy-chain bandwidth. In this case it is simplest to upsample 
> continuously. And probably to process on-the-fly (although you'll have to think 
> how you will handle overlapping windows from closely spaced triggers, e.g. will 
> need multiple copies of the integrator/accumulator).
> 	If that is not the plan, if you would put the processing in the "processor" 
> FPGA and send raw samples from the frontend to the processor FPGA as was the 
> original intention, then the upsampling needs to be done on a small region. I 
> think this will be perfectly feasible... Upsampling just consists of replicating 
> samples and then passing through an FIR filter so if the filter is short enough 
> not many original samples are needed to fully prime the pipeline. Perhaps as 
> little as 5 or so? Clearly the FIR coefficient vector needs to be chosen 
> carefully. Naomi is probably (?) still using the original one that I calculated 
> but a shorter one may give good enough performance. Of course this can and 
> should be investigated offline with a given raw data set analyzed with varying 
> algorithms.
> 
> 	- Gerard
> 
> p.s. Details on the frontend to processor daisy-chain: I expect this to be able 
> to run at 80MHz, possibly 100MHz or more. There are 18 bits, but let's say 2 are 
> just used as flags to manage the transfer, so this is >160 MB/s. There is one of 
> these per main/mezzanine set of 36 channels, i.e. total data rate into 
> "processor" FPGA is limited to 320 MB/s (or 400 MB/s if you can get 100 MHz, etc.)
> 
> p.s.2. For filter design I have used "meteor" which is available at 
> http://www.cs.princeton.edu/~ken/meteor.html .
> 
> On 8/6/2013 11:25 AM, Cody Dickover wrote:
>> 
>> Hi Gerard,
>> 
> ...>
>> 1. There was some question at the tracking meeting about up-sampling on a constant basis vs. some small region and the headroom involved for that. I assume we are in the green on that, but am not familiar with the code nor the implementation. Do you have some detail on that?
> 
> _______________________________________________
> 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/20130806/43288299/attachment.html