Re: Trigger bits for Hall D front-end boards

[Gerard Visser <gvisser@indiana.edu>]

Hall D Electronics:

Hi Elliott,
	Well, I'd hope to settle somewhat one can of worms before opening 
another... So let's not get this into the discussion tomorrow please!
	But, to comment on your points below...
	I had in mind maybe four to six bits of trigger command information 
that could go to the front end boards. Twelve is probably more than you 
need - unless you ever want to make a trigger command with variable 
latency. But that is probably not directly useful, it would have to have 
an upper bound, so you could build a box to form a fixed latency trigger 
from a variable latency trigger decision tree, and so simplify your 
trigger distribution. _So_ I think only a handful of trigger commands 
are needed, e.g., 4 bits would allow 15 commands plus the null state.
	How to get the bits to the front ends quickly? Not a big deal... since 
we are already planning to distribute trigger synchronously using the 
sample clock. If we used two trigger data lines, at 125 MHz sample clock 
you can send 4 bits in 16 ns, i.e. you can send two triggers separated 
in time by 16 ns. That is 0.32% dead at 200 kHz, should be ok. But if 
that's not, then send 4 bits in parallel. There is no way to get below 
0.16% deadtime at 200 kHz rate and 125 MHz synchronous trigger distribution.
	My current plan for the ADC125 is to have 4 trigger data lines, 
received synchronously to the sample clock. All come differentially, as 
does the sample clock, through P2 from the hub board, along the lines of 
the usual plan as I understand it. The receiving flip-flop is probably 
discrete (for best setup/hold) but after that it all goes into an FPGA, 
we can decide the protocol details later, and change our minds. If it's 
just one line, no further data content, that is compatible with the 
board. If it is up to 16 bits or so on up to 4 data lines, that is also 
compatible with the board.
	I copy here, from my earlier email to you, a brief list of some trigger 
commands that might be useful:
     cmd=1 --> normal physics trigger
     cmd=2 --> physics trigger but read raw (maybe several flavors of this)
     cmd=3 --> scalers capture & read (goes into regular datastream)
     cmd=4 --> fire test pulsers (channels enabled/disabled, amplitudes 
setup ahead of time via slow controls)
     cmd=5 --> syncronize timestamps
	About the scalers, ok maybe you want to read in other ways, that's 
fine, but I think there is value in capturing them synchronously. And 
that requires something of a "trigger command". Unless of course you 
only plan to get scaler data after the run ends, that works.
	I put this email on halld-electronics, this discussion should 
definitely be on the list I think. (Maybe on halld-online too, but I 
hope most parties who care about these hardware details are on the 
electronics list. I don't want to generate volumes of extra email...)

	- Gerard

p.s. You will note too, the current ADC250 has already something of the 
"trigger command" word in it, two trigger data lines called SYNC and 
TRIG, both of which are (I believe) synchronously received at the board. 
I don't know what is the behaviour is SYNC and TRIG are asserted 
together. If that is illegal, then anyway you have two trigger commands, 
plus a null state: trig and sync. I just propose to generalize the use 
of this a little bit, allowing 3 or 15 trigger commands...


Elliott Wolin wrote:
> Hi Gerard,
> 
> There are two types of trigger bits we can send to the crates, one for 
> the front-end boards, the other to the read-out controller.  The latter 
> are easy, and I believe Ed is allowing for any number of bits to be sent 
> to the cpu's from the trigger supervisor.  With these the controller can 
> determine which boards to read out, what to do with the data, etc.
> 
> But sending bits to the front-end boards themselves is trickier, as it 
> must be done quickly.  Ed says the TS, trigger interface card, and 
> protocols allow for 16 total fast bits, with a few reserved, so perhaps 
> as many as 12 are possible.  Problems include how to get the bits from 
> the TI card to the front-end boards, presumably in parallel.  Some 
> backplane lines are available, or an auxiliary distribution system could 
> be designed, depending on how many bits we want to send.
> 
> The big question is what we might do with the fast bits.  Some of the 
> things you mentioned in your note are better done by the cpu via the 
> slower system (read out scaler modules, synchronize, etc).
> 
> I agree this needs to be discussed further, as most front-end boards 
> need to accept and use whatever trigger bits we send them, and we are 
> now designing the boards.  This subject sort of falls between 
> electronics and DAQ, although the need comes from the DAQ side, so 
> perhaps it is best discussed within the DAQ/Online/Controls group.  
> However it would not be crazy to deal with this in Electronics group 
> meetings, with DAQ folks in attendance.
> 
> What does everyone think?
> 
> Aside...the TI design needs to be discussed, probably in the DAQ venue, 
> as we'll need the new version fairly soon, perhaps as early as next summer.
>