[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Questions about fadc and libFADC (fwd)





---------- Forwarded message ----------
Date: Fri, 26 Jul 2002 20:13:12 -0500 (CDT)
From: Craig P Steffen <craig@craigsteffen.net>
To: Elliott Wolin <wolin@jlab.org>
Cc: Craig P Steffen <craig@craigsteffen.net>, Paul Smith <ptsmith@indiana.edu>,
     Vardan Gurjyan <gurjyan@jlab.org>, Dave Abbott <abbottd@jlab.org>,
     Elton Smith <elton@jlab.org>
Subject: Re: Questions about fadc and libFADC

Quoting Elliott Wolin <wolin@jlab.org>:

> Is it possible to use the card in "continuous" mode?  I.e. signals are
> coming in
> all the time.  You reset the card and give it new parameters, then read
> out
> events in small groups while the card continues to accept triggers and
> store
> pulses.  This process continues indefinitely.  If this is possible can
> the
> drivers be modified to do this?

Elliot,

As far as I know, the card _can_ be read out at the same time that triggers are
being taken.  We didn't particularly have any way to test that capability at IU,
but as far as we know, the hardware, the driver, and the readout library should
all support this capability. 

When you call the gluex_fadc_read_whole_data_buffer_without_verify function, the
card first reads the length register, which tells it how many longwords are in
the whole data FIFO.  If there's at least one, it reads that longword.  It
extracts from the longword how many additional longwords are in _that event_. 
It checks those two numbers against each other--the assumption is that if the
length register indicates that the whole output data FIFO is shorter than the
event header word indicates, then the event was truncated, and the event is
corrupt.  It then reads to the end of the buffer, and increments the count of
corrupt events.  After reading the event, and moving it to the output buffer in
memory if the event is not corrupt, it then repeats the process (read length
register, read first word, check lengths together, etc.).  

I guess now that I think about it, there would be a problem if there was a
trigger during readout of an event.  Say there was a trigger while the last
event in the data FIFO was being read out.  When the loop came around to check
to see if there was data, the length register would indicate that there was
data, but if the event wasn't finished extracting, then the length would look
like it was less than an event, and would be declared corrupt.  

An interim solution would be to remove this check from the library.  The
function would check to see if the length was greater than 0.  If so, then read
the words out of the header, and use the length from the header longword as the
number of words to read.  Even if you're reading the event simultaneously with
it being written into the data FIFO, at this point, the extractor should be
moving faster than the PCI read, so it shouldn't be a problem.  If you'd like, I
can implement this fix and put the code on the web, although someone else will
have to test it.

Ultimately, the extractor will become slower because it's doing more work
(fitting and so on), and the readout will be faster (doing block reads).  So in
more advanced versions of the prototype, perhaps we can set a bit when the
extractor is busy, or only increment the output FIFO length register when the
extractor is finished, or something like that.  Actually, this is probably the
block transfer problem.  With a little more sophisticated readout (target
terminated block transfer, or the card does the transfer as master), then the
card just stops after the last fully extracted event.  

Craig Steffen
(now working for the NCSA on cluster computing and loving every minute)

--
http://www.craigsteffen.net/contact/
current goal: get network access from home
   via cable modem using a Linux machine
career goal: be the first Vorlon Time Lord