[Mail message about the 'synchronizing' state of the FEE finite-state machine, 
from <4 Nov 97]


 Dear Glenn,

 Over the course of the last month several of us at LANL and ORNL have
 had several go-rounds concerning States, Events, State Transition
 Diagrams, and Mode Bits for MuTrFEE.  We described our desires at our
 CDR last week, and a couple of potentially global issues came up.  So,
 what do you think about the following?

 MuTrFEE would like to use the following STD for their FEE:


 		      POWER_UP |
 		               |
 			       |
 		               \/
 			----------------<-------------
 			| INITIALIZING |             |
 			----------------<----        |
 		  INIT re- |      /\        |        |
 		     moved |       |        |        |
 		           |       |        |        |
 		           |       |        |        |
 			   \/      | INIT   |        |
 			----------------    |        |
 		------->|    HALTING   |    |        |
 		|	----------------    |        |
 		|   RESYNC |      /\        |        |
 		|          |       |        |        |
 		|          |       |        |        |
 		|          |       |        |        |
 		|	   \/      | HALT   |        |
 		|	-----------------   | INIT   |
 		|	| SYNCHRONIZING |----        |
 		|	-----------------            |
 		|      RUN |                         |
 		|          |                         |
 		|          |                         |
 		|          |                         |
 		|	   \/                        |
 		| HALT  -----------------       INIT |
 		--------|    RUNNING    |-------------
 			-----------------


 The idea is that when you are done "ING" then you are "ED" (e.g.,
 when you are done HALTING then you are HALTED).  Also, the purpose
 of the extra SYNCHRONIZING/SYNCHRONIZED state stems from the fol-
 lowing:  The only time Slow Controls serial operations would be
 generally permitted is when one is HALTED --- one typically does
 not want serial clocking of bits through things like preamps during
 normal operations (but we have a special case for allowing that;
 see below).  At the same time, we don't want counters and pointers
 to be automatically reset when HALTING (as Mark claims is now the
 case for EMCal), because that can cover the tracks of a failure
 mode we're trying to diagnose.  Rather, when we issue the HALT
 event we want the system to literally "halt", so that we can then
 use serial ops to peek and poke.  Thus it's during the SYNCHRON-
 IZING state that counters and pointers are reset and we get armed
 for the next RUN.  Basically what we're doing is advocating that
 some of the actions currently a part of HALTING be moved to a
 separate state.  Also, we're saying we can't imagine doing any
 sort of "resync" without first halting.

 This has several effects:  It means the normal loop is HALT-
 RESYNC-RUN.  It implies a particular meaning for RESYNC, and
 therefore probably also implies a minimum delay between issuance
 of a RESYNC and the ensuing RUN (there must be an equivalent
 requirement for EMCal between a HALT and a RUN), in order to al-
 low the resyncing actions to complete.  And most importantly,
 it means that RUN and HALT can't be complements of each other.

 So, asssuming that we use Mode Bits to transmit events, we pro-
 pose the following:


 System-Global Bits
 ------------------

 MB[0:1]  Reset Group
 		NoOp
 		INIT
 		RESYNC
 		SPECIAL_RESET

 MB[4:5]  Run Control Group
 		NoOp
 		RUN
 		HALT
 		Reserved


 Subsystem-Local Bits
 --------------------

 MB[2:3]  Internal-Test Group
 		NoOp
 		INJECT
 		DISABLE_CVSN
 		Reserved

 MB[6:7]  External-Cal Group
 		NoOp
 		INJECT
 		DISABLE-CVSN
 		Reserved


 Like MVD, we might want to use the SPECIAL_RESET as an alternate
 Serial Clock for shifting test patterns through our FEE when we
 are actually in a RUNNING state --- this might be the only way to
 diagnose a failure mode that only occurs in that state!

 The Internal-Test and External-Cal groups are used to distinguish
 between chip-internal test pulse operations and operation of ex-
 ternal calibration circuitry such as for our cathodes system.  We
 assume one HALTs to set up and arm for a test (although a sequence
 of SPECIAL_RESET periods could be exploited here as well) and then
 uses the INJECT bit to fire the associated pulsers/switches.  We
 include a DISABLE_CVSN "gate" because of a specific feature of our
 preamp test-pulse circuitry --- when the INJECT is removed it will
 cause a large abnormal-polarity input to the preamp, so we might
 want to actively gate against its nonsense being injected into the
 data stream by some other subsystem happening to force a GL1 ACCEPT
 just as this is going on.  Yeah, we could "know" this and sort it
 out in the backend/offline, but our feeling is that having a way
 to force all-zero outputs during specific periods can be useful
 beyond even this (i.e., by DISABLE_CVSN we mean "inject all zeroes
 into the output stream but otherwise make a typical FEE packet").

 Since MuTr will have its own granules for each Arm, and it's in the
 Granule Timing Module that the Scheduler lives, I would claim in
 principle we can interpret things like RUN and HALT as we please
 (they're "our" bits, since we've had to load them into our sched-
 uler).  But of course we can't be programming our scheduler for
 sequences that don't mesh properly with those required for proper
 interfacing to the trigger (at least wrt run control and for PPG
 operations).  So, we need to make sure things like a "resync period"
 are globally accepted.

 Therefore, please look this over, call me on the phone for
 clarifications (this could give me a chance to clarify my somewhat
 murky understanding of how Mode Bits are intended), and help us
 figure out how to bring it to the appropriate Online forum.  In fact,
 I'd also like some info on how we're supposed to program the timing
 system, who's developing what services and user interfaces and data
 bases, etc., etc., etc.

 				Sincerely,
 				TomC