FEM Mode Bits

• These are the 8 Mode Bits, out of 24 Mode Bits total generated by
Granule Timing Modules at 10 MHz, that are transmitted to FEMs via
optical link

• Old Mode Bit Version II.b note on WWW; updated/revised proposal
9/18/97

(see phenix-online-l archives on WWW) (GRY)

• MB4 Run / Halt

• MB 0/1 01 Initialization reset (power up)

10 Resync reset

11 Special reset (e.g., integrator)

00 No-op

• MB 2/3 Fire regular on board pulser

Perform any other resets

00 No-op

• MB 5/6 Subsystem use, e.g., TOF precision pulser

00 No-op

• MB 7 Inject [Al]{.underline}ignment bit for LVL-1 {BB, TOF, RICH,
EMCal, MVD, MUID} only

• They \"belong\" to subsystem; above is (a) guidance,

\(b\) attempt at \"uniformity\"

\(c\) what wise subsystem people will do

Pad Chamber Use of Mode Bits

(Melissa Smith: WWW, see www.ic.ornl.gov/rd-groups/msd/phenix/pc.html)

[MB4]{.underline} Run / Halt

[MB1]{.underline} [MB0]{.underline}

0 0 No-op

0 1 Resync reset

1 0 Init reset

1 1 TGLD reset (all)

[MB3]{.underline} [MB2]{.underline}

0 0 No-op

0 1 Test pulse (include TGLD reset)

1 0 DMU reset

1 1 TGLD + DMU reset

[MB7]{.underline} [MB6]{.underline} [MB5]{.underline} Mask set - ROC
rows

0 0 0 No-op //

0 0 1 Row A //

0 1 0 Row B //

0 1 1 Row C // // // // which ROC row executes MB2/3 above

1 0 0 Row D //

1 0 1 Row E //

1 1 0 -- undefined -- //

1 1 1 Global //

Invalid patterns 2 MB4­= 1, all others = 0 2 Run (only)

Note: scheduler program should check for invalid patterns, BUT, to guard
against transmission errors, heap manager should also check for valid
mode bit patterns.

Recommend: any invalid pattern be set to MB4­= 1, all others = 0. This
means Run.

The \"Other\" 16 Mode Bits Output by GTM (see GTM page on WWW)

(J. Mead, BNL)

• 8 go to LVL-1 (F. Wohn, ISU, Ames Lab)

• Mode Control MB0 MB1 LL-1 boards:

0 0 Use input from FEM

1 0 Go to +5 V

0 1 Go to 0 V

1 1 Use next slice of test pattern input

(test pattern loaded via VME)

• \"FEM unreliable\" bit: flag LL-1 that FEM is doing something so as to
make its data unreliable (being reset, interference by neighboring
detector)

Two taken for inputs to GL1 input vector (2 per granule)

\(a\) Forced accept request (i.e., fire a pulser, 3 request a trigger)

\(b\) GL1 disable request (my data are no good, there is some other
problem, etc.)

A programmer can choose to observe or ignore this warning, of course.

• Alignment bit to LL1 --- equivalent of alignment bit sent to a FEM.

(Fred to circulate proposed list of LL-1 mode bit usage.)

• 8 go to PPG (J. Fried, BNL)

> Available as needed, [particularly]{.underline} for firing external
> devices under scheduler control, with control of mask + time delay
> (\<1 ns adjustment steps); for example,

PbGl uses 4: 3 LEDs

1 PIN preamp pulser

PbSc uses 2: 1 laser

1 PIN preamp pulser

PbSc laser needs 2: flash lamp

trigger it

Mode Bit Exercises for Fun and Profit

(e.g., Fire MVD pulser, request a trigger @ GL1)

MBs: [FEM]{.underline} [LL1]{.underline} [PPG]{.underline}

00010100 00000000 00000000

00010000 00000000 00000000 4↑

00010000 00000000 00000000 \"23 tick\" latency between

. TGV32 & GL1 timing

. \|

. \|

\"20\" more of the same \|

. \|

. \|

. \|

00010000 01000000 00000000 4↓

 4­  ­  4 ­

Run/halt    \|

      \| \|

\| \|

Fire TGV32 Request GL1 accept, MVD granule

pulser ([assume]{.underline} LL-1 bit 6 used for this purpose)

This assumes all serial-string setup of MVD, TGV \... is already done.

We [guess]{.underline} here at 23 beam crossing \"ticks\" (10 MHz)
between when charge injects into TGV32 from a particle and the
corresponding \"normal\" LL1 information finally reaches the GL1 input
stage where LL1 mode bits emerge and enter GL1 (may need to adjust for
latency in when MVD FEM actually responds to FEM-MB2 going true, which
tells it to fire its pulser)

For example, reset PC TGLD input stages

(assume **for this example** 20 ticks are needed)

MBs: [FEM]{.underline} [LL1]{.underline} [PPG]{.underline}

11110011 (none sent) 00000000 ­5 ­5

00010000 00000000 \| \| 20 ticks of reset operations

. \| \|

. \| \|

. \| \|

17 more of these \| \|

. \| \|

. \| \|

. \| \|

000 1 0000 00000000 \|  5 ↓

000 1 0000 00000000 \| 22 tick latency for event to reach

000 1 0000 00100000 00000000 5 ­5↓GL1 input

000 1 0000 00100000 00000000 \|

­­­­     ­­    5­     .                    \|

Global \| \| \| \| . \| 20 ticks of \"PC data unreliable\"

ROC Row \| \| \| \| . 5 ↓crossings reaching GL1

(encoded) \| \| \| \| 18 more of these

\| \| \| \|

Run/halt \| \| \|

\| \| GL1 disable request from

\| \| Pad Chamber Granule(s)

TGLD reset (assume LL1 MB5 used for this purpose)

(encoded)

\"Don\'t worry\" about the \"none sent\" note under LL1. Although PC has
no LL1 system, two of its LL1 Mode Bits [are]{.underline} wired over to
the GL1 input, for [each]{.underline} PC granule. (Ditto for all
granules.)

Note the 20 ticks of reset sent to FEM equal the 20 ticks of \"PC
unreliable\" sent ot GL1. The latter come later to allow for LVL-1
latency. We [will have to determine this latency once Online is
built.]{.underline}

The \"20\" comes from a present estimate that TGL98 preamp needs 2 µsec
(i.e., 20 ticks at 10 MHz) to completely reset all stages in TGL98.

For example, Fire LL1 alignment bit in MVD (EMCal, RICH, \...)

MBs: [FEM]{.underline} [LL1]{.underline} [PPG]{.underline}

10010000 00000000 00000000 ­     

00010000 00000000 00000000 \| 3 tick latency of FEM vs. LL1

00010000 00000000 00000000 \| (assumed here for example)

00010000 10000000 00000000 6↓

­6  ­ ­6  6 

\| \| \|

\| Run/halt \|

\| Al bit on LL1

\|

\|

Al bit on FEM

For example, Fire PbGlass Avalanche Yellow LED (timing check)

MBs: [FEM]{.underline} [LL1]{.underline} [PPG]{.underline}

00010000 00000000 00010000 ­      

00010000 00000000 00000000 \| Assume 21 tick latency from time

. \| of LED firing to when LL1 data

. \| would normally reach GL1 input

. \| \_ \|

19 more of these \|

. \|

. \|

. \|

000 1 0000 01000000 00000000 7↓

 7 ­    ­        7­

\| \| \|

\| \| Fire A.Y.

Run/halt \| LED

\|

GL1 Forced Accept Request

For example, Coordinated Resets over Several Subsystems

MBs: [FEM]{.underline}~EMCal~ [FEM]{.underline}~MVD~
[FEM]{.underline}~PC~ [LL1]{.underline}~PC~

00010011 00010011 00010011 00000000   ­  8

00010000 00010000 00010000 00000000 \| 22 tick latency to . \| first
arrival at GL1

. \| input

. \|

19 more of these \|

\|

000 1 0000 00010000 00010000 00000000 ­ 8  8↓

000 1 0000 00010000 00010000 00100000 \|

000 1 0000 00010000 00010000 00100000 \|

 8 ­      ­­88   .     8 ­ \| 23 tick duration

\| \| \|   .         \| \|

Run/Halt \| \| . \| \|

\| \| 21 more of these \| 8↓

Special reset . \|

(encoded) . \|

. GL1 disable request  

Q: Why merge requests?

• Less overall dead time for partition using EMCal, MVD, PC \...

• Only 1 bit to test @ GL1

8 reserve bit-width @ GL1 cross bars for \"physics\"

Q: Why 23 tick duration?

• For illustration, assume EMCal and MVD need 10 ticks, and PC needs 20
ticks, to complete any and all settling after a reset

• **Also** assume \"reset integrator\" takes 3 ticks longer to \"set
up\" for PC vs. EMCal. Thus, the \"or\" of the disable requests at GL1
lasts for 3 ticks (relative latency of EMCal/MVD vs. PC) + 20 ticks (PC
duration).

Comment: Assume here that (EMCal, MVD, PC) all share a partition.
Therefore, if any one of them is unavailable on a given crossing to
trigger an event, then [all]{.underline} are taken to be unavailable to
trigger an event. That is, their dead-time is indeed common.

For example, Serial Downloading / Uploading

--- if serial line / ARCnet activity does not disturb your FEM, then, in
principle, you could download while running, then latch the resulting
data into FEE while only \"knocking out\" 1 crossing

For example: FEM 00010000 always

LL1 00000000 always, except for

LL1 01000000 on 1 \"appropriate tick\"

GRY prefers to stop taking data

For example: FEM 00000000 i.e., \"Halt\" = True

> until serial download / read back / compare--verify steps are
> completed

We recommend serial download/readback ONLY be done when you are not
trying to take data.

Note: If you are just \"cycling the DAQ\" and don\'t care about the data
taken, then you can, of course, download serial at any time. Some groups
want to do this to see if any interference results. However, for serious
physics data-taking, stop first.