[Halld-online] Adoption of front-end board data format

Tue Mar 5 15:25:09 EST 2013

  There is nothing in the data format document that precludes allowing 32bit data.
The restriction is that you will need to generate a custom "type defining word" that
indicate the type and quantity of data that follow.

   Ben come discuss it with me if you do not understand....

    David

----- Original Message -----
From: "Elliott Wolin" <wolin at jlab.org>
To: "Benjamin Raydo" <braydo at jlab.org>
Cc: "Scott Kaneta" <skaneta at jlab.org>, "Hai Dong" <hdong at jlab.org>, "jeff wilson" <wilson at jlab.org>, "nick Nganga" <nganga at jlab.org>, "Cody Dickover" <dickover at jlab.org>, halld-online at jlab.org
Sent: Tuesday, March 5, 2013 3:18:49 PM
Subject: Re: [Halld-online] Adoption of front-end board data format

Hi Ben,

The whole topic is a little beyond me, since I don't understand the 
ramifications in all the boards.  In any case it must be discussed in an 
Electronics meeting.

Chris...can you discuss this at the next meeting and get back to me?

Thanks,

On 03/05/2013 02:35 PM, Benjamin Raydo wrote:
> Hi Elliott,
>
> That document is in need of an amendment before I'll agree to conform to it. The lacking ability of the protocol to support a 32bit quantity for event readout is pretty ridiculous. With that said I've suggested that a "User defined" data type should be allowed to include in it the number of words to follow that should not be interpreted by the protocol, as currently defined. I understand that it is likely desired to define a protocol that doesn't depend on "user defined" values to figure out how to decode where data for a module starts and stops, but in reality you must understand the data format of the modules anyway so this shouldn't a crazy request.
>
> Alternatively I suppose a special firmware for Hall D where 32bit scalers are made 31bits could be done (or with no change a penalty for allowing scalers to count beyond 31bits could be in the form of event builder corruption :) ).
>
> Can we get that document to reflect this? The discriminator, fADC250, as well as the SSP (probably many other Hall D boards and the other boards Hall B boards I've done that probably you're not worried about) will be using 32bit scalers (unless there's a big push to cut in half the time it takes to overflow these by enforcing 31bit scalers).
>
> Ben
>
> ----- Original Message -----
> From: "Elliott Wolin"<wolin at jlab.org>
> To: halld-online at jlab.org, "Chris Cuevas"<cuevas at jlab.org>, "Ed Jastrzembski"<jastrzem at jlab.org>, "Hai Dong"<hdong at jlab.org>, "William Gu"<jgu at jlab.org>, "Ben Raydo"<braydo at jlab.org>, "Scott Kaneta"<skaneta at jlab.org>, "Fernando Barbosa"<barbosa at jlab.org>, "jeff wilson"<wilson at jlab.org>, "Cody Dickover"<dickover at jlab.org>
> Cc: "nick Nganga"<nganga at jlab.org>
> Sent: Tuesday, March 5, 2013 2:03:33 PM
> Subject: Adoption of front-end board data format
>
> Hi,
>
> Having 1) sent out my original note (see below), 2) talked with many of the relevant parties, and 3) having received no feedback to the contrary, it is my understanding that all involved agree:
>
> a) To implement Dave and Ed's VME readout format in their modules.
>
> b) The modules will be ready by the time Hall D needs to read them out (start this summer).
>
> If you do NOT agree with both of these please get back to me ASAP, as we are proceeding with online and offline programming as if this is the case.
>
> I note that this VME format may differ from that used by some previously released modules (e.g. discriminators), but that having a uniform format across all modules is more important.
>
> Thanks,
>
>
> On 03/01/2013 03:07 PM, Elliott Wolin wrote:
>
> Hi,
>
> Attached is Dave A's and Ed's proposal for a consistent data format for all JLab front-end modules. At the last Online meeting we were led to believe all JLab modules that get read out over the VME backplane would implement this format (FADC25, FADC125, F1TDC, TI, TS, etc). We are proceeding as if this is the case.
>
> Further, we expect to begin reading out detectors this summer, probably BCAL and FCAL first (check with Fernando for our crate installation schedule). We would very much like this format to be implemented by the time the crates are installed.
>
> FPGA programmers: please let me know ASAP if you are NOT planning to implement this format, or if you won't be able to implement it by the time your modules get installed in Hall D and we begin reading them out. We very much do not want to have to deal with multiple formats for the same module (e.g. the June 2013 format, the Mar 2015 format, whatever).
>
> Finally, we are developing simulation, readout and analysis code that expects this format, so we need to know ASAP if it will change.
>
> Thanks,
>
>
>
> _______________________________________________
> Halld-online mailing list Halld-online at jlab.org https://mailman.jlab.org/mailman/listinfo/halld-online

-- 

				Sincerely,
					Elliott

================================================================================

  Those raised in a morally relative or neutral environment will hold
		    no truths to be self-evident.

Elliott Wolin
Staff Physicist, Jefferson Lab
12000 Jefferson Ave
Suite 8 MS 12A1
Newport News, VA 23606
757-269-7365

================================================================================

_______________________________________________
Halld-online mailing list
Halld-online at jlab.org
https://mailman.jlab.org/mailman/listinfo/halld-online

-- 
---------------------------------------------------------
David Abbott                      Jefferson Lab
Data Acquisition Group            Suite #10
F268 Cebaf Center                 12000 Jefferson Ave.
MailStop 12B3                     Newport News, VA  23606
EMAIL: abbottd at jlab.org
Tel: (757) 269-7190
FAX: (757) 269-6331             URL: http://coda.jlab.org/
----------------------------------------------------------