Two sets of code from CERN to support their DAB64x board:
Plus a patch to the latter code that makes it nominally Quartus-compatible. Maybe this is that version already patched?
I know which code base I would rather work with, but the application logic (stacking, beam synch) from Jean Jaques may be closer to what the LUMI/BRAN project needs.
Some comments I wrote up in August 2007 for what LUMI/BRAN needs to do on the signal processing side:
Each DAB64x board has 2 x 40 MS/s 12-bit ADCs
April 2008 the system should be ready and useful for LHC,
although not necessarily with all final features.
LHC runs with main RF of 400.8 MHz, with capture RF at 200.4 MHz
minimum bunch separation "25" ns, so it is an unverified
assertion that all bunches are synchronous with a 40.08 MHz clock.
Ring harmonic is 35640, so there are 3564 potential bunches.
DAB64x needs a bunch-zero hardware input from the timing system.
LHC turn on plans to increase the number of filled bunches
from 1 to 43 to 2808, always leaving abort gaps.
Application FPGA on the DAB64x is an EP1S20, containing:
18460 LEs (4-input LUT)
194 M512 (32x18 RAM)
82 M4K (128x36 RAM)
2 M-RAM (4096x144 RAM)
40 Multipliers (18x18)
Assume all acquisitions are double-buffered (ping-pong), so
there is no dead time. Guess that LabVIEW can handle one
buffer (~32 Kbytes) in no more than 0.364 seconds, allowing
buffers to accumulate for no more than 4096 turns. This number
is important for setting the bit-width of counters/accumulators.
70% of the on-board memory is in the form of M-RAM.
There are 36 bits/bucket/ping-pong/ADC, enough to hold
both a 4096-turn sum of the 12-bit ADC reading (24 bits)
and a 4096-turn count of the number of ADC readings above
a threshold. Other allocations of these bits are possible,
especially in early stages of LHC turn-on when fewer buckets
are active.
Could also use 4096 x 24 to accumulate a histogram (Pulse
Height Spectrum) of raw (or slightly filtered, see below)
ADC readings. With a little squeezing that might fit in
the M4K hardware. This histogram should have a programmable
input gate, so it can apply to either all bunches or a single
bunch (e.g., the one live bunch in initial LHC operation).
Need to study bucket-to-bucket crosstalk, and low frequency
droop. Although the analog system is designed to minimize
these effects, fine adjustment/compensation can be added
after the ADC with digital filters.
DAB64x has on-board memory of 3 x 128K x 32 SRAM. Organized
as 512K x 12 x 2, this could be used for raw waveform capture
of 147 turns. Can be set up as circular fault trace buffer.
One DAB64x will be connected to the sum signal of the two
TAN detectors. This will allow coincidence counting, as
well as individual counts. Because of memory limits (at
least when running in the full 2808 bunch mode), one of the
other signals (left or right stack, left or right count) has
to be dropped. Could also consider counting coincidence
(L*R) and anticoincidence (L+R), in place of L and R.
Suggest two parallel (subject to manpower availability) efforts:
1. Hardware test simple data acquisition of 2 x ADC channels,
single turn, and transfer through VME and USB to LabVIEW host.
2. Programming, simulation, and synthesis (but no hardware test)
of a moderately complete data processor, including digital input
filters, baseline restoration, histogram, stacking, and above-
threshold pulse counting. All "constants", like threshold,
harmonic number, turns accumulated per buffer, and turns between
buffer starts, will be settable from the host.
These two tasks can be listed as independent milestones.
Integrating the two (with LabVIEW support) should be "easy"
and low-risk. This integration needs to be nominally complete
for the April 2008 turn-on, although at that time the digital
input filters and baseline restoration are optional.
Programming of the DAB64x off-chip memory has lower priority,
will probably not happen until after April 2008.
Larry Doolittle
April 2, 2008