MoGURA is a general-purpose deadtime-free data acquisition electronics developed for solar CNO neutrino observation with KamLAND. One of the main features is dead-time free recording of successive signals, owing to free-running high-speed flash ADC's (FADC) and large transient data buffer embedded in FPGA's. It was also designed to be useful for general application, such as small-scale measurements and middle-scale high-rate experiments.

We will use the MoGURA system for the KamLAND backup system, which aims to collect all neutrons after muons. The number of neutrons after a muon can reach 60~100, therefore capability of collecting multiple (upto 100) signals is crucial. Since huge signals by muons disturb the baseline, quick baseline stabilization is also very important. The system includes signal divider that divide the PMT signal to the main KAMFEE system and the backup system, trigger card with GPS synchronization, and trigger command distributor card. We will install the backup system for all 17-inch PMT's (1325 ch), but not for 20-inch PMT's due to budget limit.

Features

• Quick baseline restoration
• Dead-time free recording of successive signals (upto ~200 hits within 1 msec)
• Long trigger dicision time torelable (upto ~10 usec)
• On-board data reduction
• Complete synchronization with GPS time
• Stand-alone (single card) operable

Quick Review

• Review Slides [PPT (10.9 MB)]-[PDF (2.4 MB)]
• KamLAND Collaboration Meeting Slides (Sep 2007 @ Bordeaux) [PPT (8.8 MB)]-[PDF (1.5 MB)]

Contents

• Overview
• Main Card Design Details
• Analog Front-end
• FPGA Logic
• Performance Estimation
• Signal Divider Card
• Installation to KamLAND
• Status and Timeline
• References

• PMT output waveforms were directly measured with an oscilloscope.
• Typical small signal is; 2 mV amplitude, 20 nsec width, 1.6 pC charge.
• If 1/4 p.e. threshold is used, it will be ~0.5 mV.

• The dominant frequency component is from ~1 MHz to ~10 MHz, fastest component is ~100 MHz

Scopetrace of Muon Signal

• Typical muons signal is: ~1V amplitude, few 100 nsec width, ~10000pC charge.

• Maximum muon signal can reach: ~10V amplitude, ~100000pC charge

Scopetrace of Noise(?) Signals after Muon and Baseline Shift after Muon

• There are lots of noise(?) signals after muon, within 1~10 usec.

• AC coupling inside the PMT make overshoot after large signal output
• The amplitude of the overshoot can reach ~10 mV.
• The time constant of the overshoot is ~500 usec, which is consistent with the time constant of the AC coupling (4.7 nF * 100 kOhm).

Outline

Signal Divider (MoGURA BLR)

This card receives PMT signal and makes two outputs; one is an identical copy of input signal that will be fed into the main KAMFEE cards, and the other is for the backup system (MoGURA). The branch for the backup side has an analog preprocessor that stabilize baseline fluctuation (Baseline Restorer; BLR).

Main Digitizer (MoGURA FADC)

VME 9U card that receives analog input and sends digitized data. This card also generates HITSUM output and accepts commands from the trigger card.

Trigger Board (MoGURA Trigger)

VME card that receives 12-bit HITSUM signal from the main digitizer cards and outputs trigger command. This also generates the 50 MHz master clock that is synchronized with the GPS global clock.

Trigger Command Distributor (MoGURA Piggy Back)

VME piggy back card that is attached on the backside of VME P2/J2 backplane. This card receives clock signal and trigger command from a connector and distribute them to the all main digitizer card in the subrack through VME P2 user pins.

Signal Divider Card

• Output to the main system is directly connected to the input
• Output to the backup system is connected to the input through high-impedance connection.
• The PMT/KAMFEE signal lines and ground are isolated from the backup system through AC coupling.

• The backup side branch is equipped with Baseline restorer (BLR).
  • Input to BLR is spilt into two; raw signal and baseline.
  • Baseline is calculated by taking ~1 usec average of input, after clipping signals.
  • Output is calculated by subtracting the calculated baseline from the raw signal.
  • A trick is implemented so that the baseline can follow the quick leading edge of the overshoot; the time constant for charge is fast (~1 usec), while the time constant for discharge is kept slow (~1 msec)

Main Digitizer Card

• Analog circuitry is detached to analog mini-cards, for several reasons;
  • We thought we would fail to make perfect analog circuitry for the first production.
  • Different experiment may require different analog front-end, while the main digitizer function is more general and FPGA's are reconfigurable.
  • Analog front-end is generally the most vulnerable part (by inputting huge signal etc.)
• One analog mini-card makes four amplified signal outputs with different gains, and one discriminator output.
• One analog mini-card has three reference voltage inputs, which are connected to DAC's on the main card. These are used for 1) baseline biasing, 2) discriminator threshold, and 3) not used.
• Precautions are taken not to make overshoots after large signals.

• Each input channel is equipped with four 8-bit FADC's (one 1 GSPS (giga samples-per-second) plus three 200 MSPS), each of which is connected to a different analog gain channel
  • 1 GSPS FADC (P-ch): input range +5 mV to -20 mV, 0.1 mV step
  • 200 MSPS FADC (H-ch): input range +25 mV to -100 mV, 0.5 mV step
  • 200 MSPS FADC (M-ch): input range +250 mV to -1000 mV, 5 mV step
  • 200 MSPS FADC (L-ch): input range +2.5 V to -10 V, 50 mV step
• One Front-end FPGA (Xilinx Spartan3) is assigned to two input channels
• Front-end FPGA has two buffers;
  • Ring buffer to hold digitized data for 10 usec
  • FIFO buffer to hold triggered data (more than 256 data blocks)
• Each Front-end FPGA is connected to a System FPGA (Xilinx Spartan 3) through an exclusive 32-bit line

• System FPGA has an external 64 MB memory (DDR SDRAM) for data storage
• System FPGA is connected to VME through bus drivers

• User-programmable FPGA (User FPGA, Xilinx Vertex II-Pro) is connected to System FPGA through exclusive 32-bit line.
• User FPGA has an embedded CPU (PowerPC)
• User FPGA has an external 64 MB memory (DDR SDRAM) for general use
• User FPGA can be configured from VME through System FPGA
• User FPGA is connected to VME through bus drivers (shared with System FPGA, except for interrupt lines)

• HIT signal is generated from the Front-end FPGA by analyzing the digitized waveform
• Local HITSUM, which is a sum of HIT signals on a card, is calculated at every clock cycle.

• Each card is equipped with two HITSUM_IN and one HITSUM_OUT connectors on the backside (LVDS twist-pair connector)
• HITSUM_OUT is a sum of the local HITSUM and HITSUM_IN. By making daisy chain of the HITSUM signals, the global HITSUM is automatically calculated at every clock cycle.
• HITSUM_OUT is propagated to the next node (card) at every clock cycle. The propagation latency at each chain node is scanned at the beginning of run, and the latency is corrected on summing the HITSUM.

Trigger Card

• Trigger card outputs the 50 MHz master clock
• The master clock is synchronized with the GPS time
• Trigger card receives 12-bit HITSUM signal
• Trigger card generates 8-bit trigger command signal
• The HITSUM input and the trigger command output are connected to Trigger Logic FPGA (Xilinx Spartan3)
• The Trigger logic FPGA is connected to Trigger System FPGA (Xilinx Spartan 3) to exchange system parameters and to send trigger data records.
• Trigger System FPGA is used for parameter setting through VME and trigger data recording through VME
• Trigger logic FPGA can be configured through VME
• Trigger System FPGA has 64 MB DDR-SDRAM for data buffering

• The 50 MHz clock is generated from 10 MHz clock provided from an external Rb clock
• The external Rb clock (10 MHz) is synchronized with the GPS time
• Rb clock details: SRS FS725

Trigger Command Distributor Card

• Attached to a VME backplane and distributes the trigger command and clock
• The clock signal is distributed to every card with equal delay
• The Trigger command can be passed through a daisy chain
• The Latency switch tells the propagation latency of the command.
• User Output from the main card is connected to Local Logic FPGA for future extension (single crate system etc.).
• Local clock source is placed for single-crate use.

Trial with MiniLAND

• The prototype card (Mini-MoGURA) was actually used by the MiniLAND system.
• The Mini-MoGURA system was used in the Stand-Alone mode, which does not require external trigger card.
• Waveforms from the P, H, M and L channels were recorded as designed.
• Time and Charge spectra are calculated after a simple offline waveform analysis.

• Power Distribution (PDF 180 kB)
• Clock Distribution (PDF 256 kB)
• Schematic (PDF 1.7MB)

Power Distribution

• Only standard VME64x power supply is used.
• VME64x 3.3V supply and a number of DC-DC converters are heavily used
• Each line is equipped with a fuse and DC filter
• +/- 10V and +/- 5V are provided for the analog mini-cards.
• Regurators are used for the analog mini-card powers
• Total power consumption is ~90 W/card (measured).

FPGA Configuration

• The System FPGA is configured from an EPROM, which is programmed through JTAG.
• The Front-End FPGA's are configured from a NOR-Flash (with a special ASIC), which is programmed through VME.
• The User-FPGA is configured from an EPROM, which is programmed through VME.
• There are front-panel LED's to show FPGA's configuration status.

Clock Distribution and Global Synchronization

• There are three clock sources, selectable by jumpers;
  • Master clock provided by the trigger card.
  • Local oscillator
  • External clock
• The local oscillator is used for the stand-alone mode
• The external clock is supposed to be connected to another card to form a daisy chain; This configuration is used for multi-card stand-alone system.

• A local PLL is placed to protect the clock signal from external clock instability.

• FADC sampling clocks (200 MHz and 500 MHz) are synthesized from the system clock with keeping the phase fixed (thus synchronized).
• Clock lines on the card are isometric.

Hit-Sum Output and Global Hit-Sum Chain

• The number of hits on a card, HITSUM, is calculated at every clock.
• The total number of hits, global HITSUM, is summed up all over cards through a daisy chain.
• There are two HITSUM_IN connectors in one card, in order to form a "tree"-structured chain.
• The tree structured chain reduces the number of steps in the sum-up chain.
• The propagation latency of the HITSUM summing chain is corrected at every node by accommodating delay with the latest (longest) branch.

Trigger Interface / Generic Control Input

• There are four trigger sources;
  • Command from the trigger card (VME P2 user pins)
  • Register writing from the VME (Trigger Command Register)
  • NIM input into a front-panel connector (Generic Control Input)
  • Hit signal on ch 11
• Trigger commands are used to;
  • Command to acquire waveform
  • Initialize the system (clearing the timestamp etc.)
  • Run special sequences (scanning FADC baseline, scanning HITSUM chain, etc.)
  • Broadcast a trigger parameter (trigger latency including HITSUM latency)

• Access to the VME Trigger Command Register can be broad-cast; all cards in one crate receive the command simultaneously.
• VME broadcasting is useful for multiple-card stand-alone system.
• Issuing trigger from the generic control input is useful for stand-alone system.
• Similar to generic control input, issuing trigger from ch11 input is useful for stand-alone system; this is even more useful for application that requires precise trigger time recording, since the trigger pulse itself is recorded.

VME Interface

• VME lines are simply connected to FPGA pins, through bus drivers/receivers and level adapters (i.e., not chipset is used).
• All VME bus logic is implemented in FPGA; this allows us to upgrade the bus interface in the future, such as VME64 2e cycles and VME64x PnP.
• VME chipset is not available anyways.

• Some VME P2 user pins are used for trigger commands (LVDS 8+1 bit).
• Some VME P2 user pins are connected to the System FPGA pins for future use (16 single end lines).
• Some VME P2 user pins are connected to analog discriminators for future use.

Direct Readout Port

• There is a 8-bit LVDS header (Direct Readout Port), pins of which are connected to the User FPGA.
• The port is general output for future use; high-speed ethernet connecter was in mind and space is reserved for it.

Analog Hit-Sum Output

• The analog discriminator outputs are analog-summed and be output from a front-panel connector (Analog Hit-Sum).
• The amplitude ranges from 10mV to 120mV, proportional to the number of hits.
• This is useful for the stand-alone mode.

Front Panel LED's

• Power
• Clock
• System FPGA Configured
• Front-End FPGA Configured
• User FPGA Configured
• Running (Status Register Bit)
• Error
• User LED's (8bit)
• 7-segment digit LED

• The analog mini-card has the following functions;
  • Input signal line termination (50 Ohm)
  • Signal splitting and amplification for the P, H, M and L channel
  • DC removal and biasing (FADC pedestal)
  • Differential line driving for the 1 GHz FADC
  • Analog discriminator
• Performance goals are set as;
  • Dynamic range from 0.01 mV to 8 V
  • Pass-band frequency from 100 kHz to 80 MHz
  • Noise level less than 0.2 mV
  • No ringing for step pulse input
  • Not to be disturbed by large signal input
• Spacial care was taken not to introduce overshoot after large signals

• A number of major changes was made from the current prototype; Final design was evaluated with SPICE simulation and partial modification to the current prototype.

• Schematic (PDF 89kB)

SPICE Simulation

• Overshoot after 10 V signal input is less than 5% of small signal amplitude (2 mV), which is as small as FADC LSB (0.1 mV input equivalent).
• Baseline shift due to pile-up of overshoots is calculated to be less than 0.1 mV for 100 MHz of small signals.

• The Front-End FPGA controls the FADC's and read digitized waveform
• The Front-End FPGA generates HIT by watching the waveform
• The Front-End FPGA hold the waveform in a ring buffer for up-to 10 usec
• The System FPGA collects the HIT signal from all the Front-End FPGA's and calculates HITSUM on every clock
• The System FPGA daisy chain calculates the global HITSUM and send it to the trigger card

• The trigger card watches the global HITSUM and issues trigger commands
• The system FPGA receives the trigger command and distributes it to all the Front-End FPGA's
• The Front-End FPGA transfers waveform from the ring buffer to another buffer (Channel Buffer) based on the trigger command.
• The trigger command should arrive at the Front-End FPGA with fixed latency. Position and length of transferred waveforms are specified by register setting (Trigger Latency and Event Window Length).

• Waveforms in the channel buffer is transferred to the System FPGA through an exclusive 32-bit line.
• The system FPGA receives the waveform and temporarily store them in channel FIFO, and then send to external DDR SDRAM.

• Data in the SDRAM is transferred to VME on VME request
• Computers that are to read the SDRAM data are supposed to tell the System FPGA which address is to be read in advance; The system FPGA transferres corresponding data fragments to a cache (VME Cache).
• Sequential read from the SDRAM does not require updating the cache setting. The system FPGA keeps sending subsequent data unless explicitly specified.

• Data in the SDRAM is transferred to the User FPGA on request from the User FPGA
• Priorities of using the SDRAM are set to; Channel FIFO > VME Cache > User FPGA

Data Format

• The waveform in the ring buffer is continuous, while wavefom in the channel buffer is segmented and framed.
• A set of triggered data forms data frame train
• Data frame train is a set of variable number of data frames

• One data frame contains waveforms of two clock cycles (40 nsec)
• In one frame, each waveform block can be abbreviated and the frame is truncated (see Zero Supression below)

• The header two words contains;
  • Launch Offset; time between the trigger and first waveform point in the frame (16 bit)
  • Data Flags; tells which channel of waveforms are recorded in the frame
  • Hit Flags; tells if the corresponding HIT exists or not
  • Format Flags; tells the contents of the frame (see Buffer Almost Full below)
  • Event Counter; the count of triggers since initialization
• The trailer word contains;
  • Event ID; 8-bit number comes with trigger commands
  • Timestamp; lower 16-bit of clock counts since initialization
  • Frame continuition flag; tells if the frame train is completed or not
  • The frame continuition flag also tells us if the frame is invalid (broken) or not.

• Events are identified by the 32-bit Event Counter
• Event ID is used to ensure no trigger commands are missed
• The 16 bit Timestamp is used for consistency check between the trigger card and the digitizer cards.

Trigger Command

Initialize [b1000_0001]

Clear the clock counter (timestamp) and event counter

Clear SDRAM data pointers

Transfer the register values stored in the System FPGA to the Front-End FPGA

Output the DAC value

Clear error status

ScanLatency [b1000_0010]

Determine the position in the HITSUM sumup chain by

1. Output the global HITSUM chain latency to the HITSUM_OUT based on momentary HITSUM_IN value
2. Wait until stabilized
3. Remember the value

SetLatency [b1000_0100]

Set the trigge decision latency to a value provided with this command

ScanBaseline [b1000_1000]

Determine the FADC baseline positions by

1. Acquire several waveforms with avoiding signals
2. Calculate average value
3. Remember the result

AcquireRange [b0110_PHML]

Acquire waveforms

PHML bit flags are to specify which gain channels to read

The position and length of the waveform are specified by registers (TriggerLatency and EventWindowLength)

AcquireHit [b0101_PHML]

Acquire waveforms with signal search (zero-supression).

PHML bit flags are to specify which gain channels to read

The position and length of the waveform are specified by registers (TriggerLatency, EventWindowLength and MaximumSignalLength)

Reject [b0100_PHML]

Abort acquiring waveforms initiated by a previous AcquireHit command.

PHML bit flags are to specify which gain channels to abort.

• Trigger commands consist of two 8-bit words, except for the SetLatency trigger.
• The first word is the command value shown above, and the second word is EventId
• The trigger card can send any value for EventId; simple counter values might be used if there is no special reason.
• The SetLatency trigger uses the second and third words to send the 16-bit TriggerLatency value.

Front-End FPGA

• Control the FADC's and read data from FADC's
• Perform simple pulse height analysis and generates HIT signal
• Temporarily stores the waveform in the ring buffer
• Transfer the data segments in the ring buffer to the channel buffer on commands from the System FPGA
• Generate data frames on transfer to the channel buffer
• Send data in the channel buffer to the System FPGA

• If Acquire triggers are issued when the channel buffer is almost full, record leading edge 4 samples and sum of the waveform (i.e., area), instead of recording whole waveform (Buffer Almost Full Mode)
• If Acquire triggers are issued when the channel buffer is full, send a HIT_MISSED signal to the System FPGA (Buffer Full Mode)

Hit Detection

• The Front-End FPGA can generate HIT based on the analog discriminator output (Analog HIT)
• The Front-End FPGA can generate HIT based on FADC waveforms (Digital HIT)
• Any of four FADC's (P,H,M and L) can be used for hit discrimination
• Discriminators (P,H,M,L or A) are selected with register setting (Discriminator Select register)

• If the analog discriminators is selected, threshold is set by a DAC (Analog Threshold register).
• If any of the digital discriminators is selected,
  • threshold is set by a register (Digital Threshold register)
  • hysteresis is set by a register (Digital Threshold Hysteresis register)
• Generation of the HIT signal can be inhibited by the Chanel Hit Disable register.

Valid Signal Searching (Zero supression)

• A state machine to find valid signal region is started by a AcquireHit trigger.
• There are three states corresponding to signal position;
  • Seeking; Waveform is around the baseline and machine is seeking a signal
  • Recording; Waveform is a part of signal, which needs to be recorded
  • Suspended; Waveform is overflown and no need to record
• There are three events corresponding to state transition;
  • Start; Waveform crosses the Digitization Start Threshold from lower to upper
  • Stop; Waveform crosses the Digitization Stop Threshold from upper to lower
  • Suspend; Waveform reaches the FADC maximum (zero).

• Recording will not be stopped unless it goes down to Digitization Stop Threshold. The Abort event condition is prepared to prevent from recording too long signal;
  • Abort is issued on the Reject trigger
  • Abort is issued when recorded length exceeds the Maximum Signal Length
• In order to record leading and trailing edges completely, the range of recording can be prolonged based on register settings (Preceding Context Length and Proceeding Context Length)

• The state machines work for each gain channel (P, H, M and L) independently. The Threshold and Context Length registers are prepared for every gain channel.

Left: without signal searching (AcquireRange)
Right: with signal searching (AcquireHit)

Channel Buffer Almost Full Mode

• If the channel buffer usage exceeds the Channel Buffer Fullness Value, the state machine transit to Buffer Almost Full mode.
• In the Buffer Almost Full mode, only two 32-bit words are recorded instead of waveform;
  • four P-ch leading edge samples (4 x 8bit)
  • number of sample points to the leading edge samples (8 bit)
  • sum of the waveform values (i.e., area) of the largest non-saturating gain channel (16 bit)
  • number of sample points used to calculate the sum (8 bit)
• The gain channel used to calculate the sum can be identified by looking at the frame header (Data Flags)

Channel Buffer Full Mode

• If the channel buffer becomes full, the state machine stops and no waveform will be recorded into the channel buffer.
• If any waveform needs to be recorded, the Front-End FPGA sends HIT_MISSED signal to the System FPGA with fixed delay from the corresponding trigger command
• If the system FPGA receives a HIT_MISSED signal, it generates an empty data frame with header info (Channel, Event Counter, Event Id and Timestamp) and inserts it into the data stream (SDRAM).

• If the SDRAM becomes full, the System FPGA stops accepting Acquire commands and set the Buffer Full error flag. The SDRAM is still accessible from VME under this condition, and the error is cleared by next initialize trigger.

System FPGA

• Programs the Front-End FPGA Flash memory with data written from VME
• Programs the User FPGA EPROM with data written from VME
• Manage the registers accessed from VME and the User FPGA
• Control the DAC's for analog reference voltages
• Send pamameters and commands to the Front-End FPGA
• Receive HIT and calculate local HITSUM
• Receive HITSUM_IN's and calculate global HITSUM, then output it
• Receive trigger commands and process them
• Receive data frames from the Front-End FPGA's
• Manage data frames in the SDRAM
• Send SDRAM data to VME and the User FPGA

VME Address Mapping

• 16MB VME address space is assigned for one card
• The System FPGA uses a half, and the User FPGA uses the other half
• Registers are gathered to the begining of the VME space, for software convenience (saves mapping windows)
• The 64 MB SDRAM is window-mapped to 4MB + 2MB VME address space

VME - SDRAM Interface

• Valid SDRAM data area is indicated by two pointers; Read Position(start position) and Write Position(end position)
• When new data frames are send to the SDRAM, it will be written to the point specified by the Write Position. The System FPGA update the Write Position value after transfer.
• The software or the User FPGA read the SDRAM data from the Read Position. The Read Position register value will be updated by the reader.
• Since there are two data readers (VME and User FPGA), there are two Read Position registers
• New data frames will not be written over the read position. This rule can be disabled by clearing the VME/UserFPGA Data Request register bits.

• Arbitrary length of Test Pattern can be inserted between frame trains

• VME reads the SDRAM through VME Cache
• In prior to SDRAM access from VME, Cache Address register needs to be set by software.
• The cache data will be automatically updated by transferring successive data from the SDRAM; Successive readout does not require explicit updating of the Chche Address register
• If the cache cannot keep up with VME readout, VME error (or timeout) will be issued and an error flag will be set. Software detects the error condition and restart reading.

Single-Hit Timestamp Recording Capability

• Using the HIT signal provided by the Front-End FPGA, timestamps of every HIT is recorded in a similar way to the waveform data
• One bank of the SDRAM (16 MB) is dedicated for this data
• Single-Hit recording can be disabled on channel-by-channel basis
• Single-Hit recording can be prescaled at any record and skip lengthes.

Baseline Level Scanning

• For digital discriminators, baseline level of each FADC need to be known by the Front-End FPGA's
• The Scan Baseline trigger commands initiates the sequence of baseline level scanning
• Baseline levels are determined by collecting a number of waveforms and taking average of them.
• The waveforms used for this must not contain signals
• To avoid signals, discriminators are used, baseline levels needs to be known....

• The baseline scan sequence consists of two stages;
  1. The first stage does not rely on the digital discriminator. Simply collect a number of waveforms that do not saturate.
  2. With using the waveforms, calcurate tentative baseline level.

  3. The second stage uses the digital discriminator, with the tentative baseline level
  4. Collect a number of waveforms that does not contain HIT, and calculate the average.

  5. If the final baseline level is too much different from the tentative baseline level, start over from the begining.

Trigger Latency Scanning

• If we construct a HITSUM sumup three, tracing and setting of the propagation latencies will be too complicated and troublesome.
• The Scan Latency trigger command initiates a sequence that do this all automatically.

• When the Scan Latency trigger is issued, the HITSUM_IN and HITSUM_OUT connectors are used to exchange the latency information.
• HITSUM_IN tells the latency of the card. The System FPGA calculates the own latency and output it to HITSUM_OUT
• After a while, the latency values will be converged. The System FPGA record the value.

Registers

• Board Identification (Magic Number, Version, etc)
• Control, Status, (En/Dis)able, etc
• VME Trigger, Broadcast Address, ACK Flag
• DAC Control
• Baseline Level
• Digital Threshold, Hysteresis, Discriminator Select, etc
• Trigger Latency, Event Window Length, etc
• Acquisition Threshold, Context Length, FIFO Fullness Value, etc
• Data Flow Control (SDRAM Pointers, Data Request Flags, etc)
• General Control Input Usage, Ch11 Usage, etc
• Single Hit Rate
• Single Hit Recording Control ((En/Dis)able, Prescaling, etc)
• Test Pattern Parameters

User FPGA

• Receive data frames from the System FPGA
• Manage data frames in the SDRAM
• Send data in the SDRAM to VME and Direct Readout Port
• Implement user logic
• Run on-board processing software with embedded CPU

Frequency Characteristics

Recovery after Huge Signal Input

Total Throughput

• Data transfer speed becomes slower as it goes downstream.
• The speed from the System FPGA to SDRAM is 200 MB/s (50 MHz * 16 bit DDR)
• One five-frame train (100 nsec waveform event) can be transferred to the SDRAM within 5 usec (70% SDRAM time assumed)
• 200 kHz signals can be processed to the SDRAM continuously

• VME readout speed is ~10 MB/s, which is 5% of SDRAM speed
• VME cache prevents the SDRAM from being disturbed by slow VME access
• ~10 kHz signals can be processed continuously without on-board reduction.

• If one computer handles 20 cards, the maximum continuous rate becomes ~500 Hz
• Computer speed is typically much slower than this

• The continuous throughput is good enough for supernovae (all events will be contained in the SDRAM)
• The intensive signals after muons are discussed next

Front-End FPGA Buffering

• Data transfer performance from the Front-End FPGA to the System FPGA SDRAM was evaluated with Monte-Calro (MC) simulation
• Input signals are generated randomly as follows;
  • 1000 nsec large pulse (muon)
  • 100 of 50 nsec small signals (neutron) occuring with the time constant of 210 usec
• The peak of channel buffer usage in one MC case is only ~20%
• The chance of channel buffer overflow is extremely small, deduced after 1000 MC cases tested.

VME Readout Speed

• VME DMA cycles were monitored with a logic analyzer
• One block data transfer cycle (256 byte) completes within 23 usec
• This scales to 10 MByte/sec data transfer rate (hardware only)

• The signal divider card receives PMT signal from the input and simply transfers it to KAMFEE output
• The signal divider card samples the PMT signal and send it to the backup system after baseline restoration
• Schematic (PDF 33kB)

Signal Duplication

• The KAMFEE output is directly connected to the PMT signal input
• The PMT signals are sampled through high impedance probing

Signal Deformation on KAMFEE output

• The signal shapes before and after the divider card are compared with an oscilloscope and the MoGURA digitizer.
• No deformation greater than 1% is observed (except for delay).

Signal Reflection

• Signal reflection at the divider card was measured with a long cable (7m) and the MoGURA digitizer.
• The red line is the waveform without the divider card. Some reflections by "I" connectors are seen.
• The green line is the waveform with the divider card (One "I" connector was replaced with the divider card). The reflection at around 130 nsec is due to the divider card. The amplitude of the reflection is less than 0.5% of the input signal amplitude (900 mV).

Baseline Restoration

• The baseline fluctuation is corrected by an active baseline subtraction method
• The baseline holder is an asymmetric low-pass filter, with lower roll-off frequency (slow) for discharging the capacitor, and with higher roll-off frequency (fast) for charging the capacitor.
• The asymmetric filter works as;
  • Baseline holder by averaging the input with ~10 usec window
  • Signal clipper by preventing the capacitor from discharging quickly
  • Overshoot follower owning to the fast capacitor charging

Issues / Trade-Offs

• Due to the real-diode behavior or due to Op-amp behavior (nor really understool), few per-cent overshoot accompanies every signal (including 1 p.e. signal).
• Due to a nature of the filter, baseline restoration after huge signal takes some time (few micro-sec).
• The overshoot amplitude and restoration time are trade-offs, unless the real cause is understood and removed.
• The current trade-off is: 5% overshoot, 2 usec restoration time.

• ATMEL 1GSPS FADC
• National Semiconductor 200 MSPS FADC
• SRS Rubidium Frequency Standard