Re: TCD issues

Date view Thread view Subject view Author view Attachment view

From: Frank Geurts (geurts_at_rice.edu)
Date: Fri Jan 24 2003 - 18:50:42 EST


Hi Tonko and Hank,
  below you can find our answers (and a question) for the TOF system.

John M. & Frank

Tonko A. Ljubicic wrote:
> On Thu, 23 Jan 2003, crawford wrote:
>
>
>>Hello -- Fred has just given me this nice document describing the TCD. I
>
> have a
>
>>question for each subsystem - If we issue a Level0 trigger, but for some
>
> reason
>
>>do NOT issue either a Level2 accept or abort, what does your system do?
>

If STAR Trigger issues a L0 trigger that results in a TOF event (either
physics or pulser), the TOF system will drop its LIVE signal to the TCD.
  That is, it will go BUSY. It will stay BUSY until it either receives
the corresponding L2 (accept or abort) or exceeds a time-out interval.
This interval is currently set to 100 ms. If a corresponding L2 is
received the TOF system will raise its LIVE signal to the TCD. The
TOF DAQ will then respond by sending data on ACCEPT or flushing it on
ABORT.

We assume that each L0 will be followed by a L2. If a TOF event is
generated by a L0 and the time-out interval is exceeded, we assume that
the TOF DAQ failed to respond to an L2 that was sent. We then send the
TOF data that we read out to STAR as a good event using the token of the
valid L0. (Our understanding of last year's operation was that not
sending data after a L2_ACCEPT is a capital crime.) Thus if STAR Trigger
sends a L0 that generates a TOF event but does not send the
corresponding L2, TOF will send data back to STAR with the token of that L0.

If STAR Trigger issues a L0 trigger that does not result in a TOF event
(i.e. no coincidence with our local trigger and not a CMD 4) and no L2
is issued then TOF DAQ does not respond in any way.

> --
>
> I would like to expand this question:
>
> a) At which point in time (relative to L0 or L2 or ...) does your system
> ship data to DAQ?

We ship data following a L2_ACCEPT or, if we trigger and do not see the
L2, right after the time-out (which is now set at 100ms after the L0
that generated the TOF event).

>
> b) What are the points in time where a L2_ACCEPT or a L2_ABORT would
> cause problems - either total lunacy or ignored/corrupted events?

In general, there is almost no time when L2_ACCEPT or L2_ABORT should
cause a problem.

- L2 Aborts:
L2_ABORTs are ignored if they are not related to the L0 token in the
system. If we do have an associated L0 token then that event is
discarded, the DAQ busy is cleared and the local trigger reset.

- L2 Accepts
L2_ACCEPTs are always served:
* if there is an associated L0 event, then that data will be shipped to
STAR-DAQ (the busy is cleared and local logic is reset)
* if there is no L0 event which means that we missed the L0 or simply
did not generate a TOF trigger: an empty (filled w/ 0s, but similar
sized) event is shipped to STAR-DAQ

>
> c) At which points in time does your system need to be protected
> by the internal TCD BUSY?

We are not sure that we know the capabilities of the internal TCD BUSY.
  We assume that this can be set on some Trigger action and acts to stop
transmission of L0 information. Is this correct? If so, what are its
parameters? For example, can the internal TCD BUSY be set to act for
some fixed time interval following a specific Trigger action?

> d) What about L1_ACCEPTS? Currently unused, but one never knows...

We read out L1 but do not take any action.

---

Date view Thread view Subject view Author view Attachment view

This archive was generated by hypermail 2.1.4 : Thu Jul 24 2003 - 00:39:34 EDT