[Fwd: Re: FADC progress]

[Elliott Wolin <wolin@jlab.org>]

Hi Elliott & Elton,

Thanks for keeping me up to date on your meetings at JLab.

I have been able to reduce the FADC baseline noise by about a factor of
2 through additional bypassing and filtering.  See:

http://k9.physics.indiana.edu/tof/fadc/status.php


The next thing I'd like to try is to reconfigure the fpga so that it
only uses one clock.  Currently the fadc data get written at 125 MHz
while the extractor runs at 66.6 MHz.  The beating between 125 MHz and
133 MHz (66.6 MHz x 2) results in the 8 MHz structure on top of the 125
MHz ripple.  I want to divide the 125 MHz by two inside the fpga and
use the 62.5 MHz to run the extractor.


We're looking at real PMT pulses with the fadc now; I want to include a
plot in the CDR.

Other things that could be looked at with the current prototype are:

	Read data at the same time triggers are coming in.

	Include additional processing in the fpga; sum the samples for
	example.

	Fancier formatting of the data.

	Suppressing data when no pulse present.

The first one could be done with the prototype as is; the others would
require reprogramming the fpga with a new PROM and modifying the driver
code to handle the new features.


A multi channel prototype is obviously the next thing to try.  This is
spelled out explicity in the IU MOU addendum from February, 2002.  By
the way, I wouldn't call the problems you mention "unexpected" - I do
expect new problems to show up in the multi channel version, which is a
good reason to do it.

The other thing from the IU MOU addendum competing for my time is an
updated FCAL PMT base.  The game plan is for me to switch to that when
CD-0 appears imminent - we could start building the real bases and
begin long term testing of them as soon as we can spend real
construction money and the robot becomes available.

You mention getting a DSP on board.  A couple of years ago I was in
favor of DSPs, but I'm not so sure now.  Is there experience with DSPs
at JLab?  There are probably 100 different types.  I wonder about
programming a DSP - someone has to learn how to do this, and remain in
the collaboration long enough to implement the inevitable changes in
the algorithm when data taking starts.  I kind of favor doing the FADC
compression and fitting in a "general purpose" processor - there will
still be changes as we get experience, but there is a lot more C
expertise than DSP expertise in the collaboration.


My current thinking is to have the cheapest fpga with enough memory for
each fadc channel, and then to have something like a Virtex II Pro on
each board.  This part includes a PPC processor, dedicated multipliers,
and an programmable logic section.  The programmable logic section can
implement DSP functions like multiplier-accumulators.  Cores are
available which implement "peripherals" like a PCI interface and
Ethernet.  The board could then be read over PCI or it could generate
IP packets which go out over a "switched serial fabric".  The fadc data
processing algorithm could be initially implemented in software, and
the slowest parts of the algorithm could be migrated to dedicated
hardware within the chip.

There is an article about this technology in the August 2002 Linux Journal,
page 48.



You ask about fadc chip improvements.  The "driver" for fadcs these
days is "software radio".  The RF or IF signal is digitized and the tuning
and demodulation take place in software.  The main manufacturers of
fast fadcs are:


SPT
http://www.spt.com/datasheets/datasht1.html

Analog Devices
http://www.analog.com/technology/RFComms/designTools/selectionGuides/wireless.html

TI
http://www.ti.com

Maxim
http://para.maxim-ic.com:80/compare.asp?Fam=Fast_ADC&Tree=ADConverters&HP=ADCDACRef.cfm


You can look at what's available.  The fastest one is the MAX108 which
is 8 bits at 1.5 Gsps.  However, it takes over 5 watts, and they don't
list the price.  The fastest 10 bit fadc seems to be 105 Msps.  8 bits
at 250 Msps or 10 bits at 100 Msps seems to be the current "sweet
spot", they are CMOS and the price and power are reasonable.  I'd
hesitate to guess about 2 years from now, although I would say software
radio will continue to be the driver.

-+-+-+-+-+-+-+-+-+-

I have some questions for the JLab people and Dave Doughty:

What is the current thinking about the track counts for the level 1
trigger?  Will this be part of the TDC boards or on a separate board?
Any idea of how to do the summing of boards and crates?


Is there at least a first pass on the new chapter 8?  I'd like to read
what you have so far.  I'm expanding chapter 7 at Alex's request & will
send out a new version on Friday.


-+-+-+-+-+-+-+-+-+-



>Date: Wed, 31 Jul 2002 16:21:50 -0400
>From: Elliott Wolin <wolin@jlab.org>
>
>Hi Paul,
>
>A few questions came up at our Hall D mtg this morning.
>
>What do you see as your near-term game plan for FADC development?  E.g. is
>removing the noise ripple the top priority, or getting a DSP on board?  Where
>does making a multi-channel board fit in?
>
>Some of us think a multi-channel board should not be too far down the list due
>to unexpected problems related to having many adc chips and associated circuitry
>close together.  Most agree that eliminating the noise should be near the top.
>
>Other issues were possible fadc chip improvements.  What is pushing the
>technology these days?  What will be pushing it in say two years?  Will future
>chips have more bits, or a faster sampling rate (i.e. for the same cost).   Will
>it be possible to get more bits or faster sampling if you're willing to pay a
>lot more per chip (e.g. if a group needs a small number of boards for some expt
>they may be willing to pay more per channel)?
>
begin:vcard 
n:Wolin;Elliott 
tel;fax:757-269-5800
tel;home:757-229-2724
tel;work:757-269-7365
x-mozilla-html:FALSE
org:Jefferson Lab;Physics Department
version:2.1
email;internet:wolin@jlab.org
title:Physicist
note:A218 CEBAF Center
adr;quoted-printable:;;12000 Jefferson Ave MS12H=0D=0A;Newport News;VA;23606;US
x-mozilla-cpt:;21408
fn:Elliott Wolin
end:vcard