Some thoughts about init/reset/start/stop

In the original definition of the run control states it was well definied what transitions from state to state are possible. Interesting enough, only the transitions (init, reset, start, stop) were defined, but not the states themselfs. Additionally, the behaviour during the transitions and inside the states was undefined.

For existing electronics, this writeup may be too late, but for future developments, some clarification may be helpful.

Transition Diagram

                     +----------+
                     | Unknown  |
                     +----------+
                          |
                          | init
       +---------------+  |   +----+
       |               |  |   |    |
       |             +-v--v---v-+  | reset
       |             | Reset    |--+
       |             +----------+  |
       |                  |        |
       | reset            | start  | reset
       |                  |        |
  +----------+       +----v-----+  |
  | Error    <-------| Running  |--+
  +----------+ error +----------+  |
                          |        |
                          | stop   | reset
                          |        |
                     +----v-----+  |
                     | Stopped  |--+
                     +----------+

Transition Matrix

State	Unknown	Reset	Running	Stopped	Error
Unknown	-	init	-	-	-
Reset	-	reset	start	-	-
Running	-	reset	-	stop	error
Stopped	-	reset	-	-	-
Error	-	reset	-	-	-

Meaning of the states

Unknown

As the name says. This state is normally reached after a power cycle or hardware reset, i.e. no configuration is loaded yet.

Reset

The "Reset" state only plays a role as a predessor for the "Running" state. Its importance lies in reaching a well defined state while at the same time being "deaf", so that this state cannot be changed from the outside.

Running

The measure mode, the module reacts to signals and generates signals itself.

Stopped

The "Stopped" state actually is quite undefined. It is introduced only to allow for the "stop" transition.

Error

The module is "deaf" again, but allows for access of status and debugging registers via slow control software. This state is important to allow for a "post mortem" analysis.

Behavior during the transitions

init

brings the module into the "Reset" state after a power cycle. Since it should be necessary only after switching on the system, it may be a slow procedure.

reset

brings the module into the "Reset" state from any other state (except "Undefined"). It is necessary for each start of the acquisition, so it should be a quick operation.

start

switches the hardware into measurement mode, so that triggers from the CTU can be processed.

stop

flushes the buffers in each module and transports the reset of the data to storage. This transition was never implemented for most of the systems.

error

halts the system, but preserves as much of the internal state as possible.

Input/Output during the transitions

transition	inputs	outputs
init	deaf	undefined
reset	deaf	undefined
start	active	quiet
stop	undefined	undefined
error	deaf	quiet

Remarks: The above defined behavior shall allow for maximum parallelism during the setup of the hardware for measurement. During init and reset, all modules may put arbitrary signals on their output lines, but since no input is accepted during these phases, they may be done completely in parallel.

The transition into measurement mode switches the inputs to active (per definition). Therefore, during this phase, no module shall generate any output on its output lines. Since all modules are quiet, the start transition can also be done in parallel. The first input seen on the active input lines is the "begin run trigger".

While the measurement mode is reached via a two step procedure (reset/start), the halt of the system is only one step. Therefore during that phase, the modules shall put themselfs into deaf mode in order not to change their internal state. Also, for not disturbing other modules that may still be in state "Running", the modules shall be quiet on their output lines.

Discussion

Compared to the former scheme, in this document a new state "Error" is introduced. This follows the current practice of saying "don't stop the acquisition, I first want to check for the error". On the other hand, the stop transition was never properly implemented and is quite a twaddle also in this document.

It may be worth a thought if it wouldn't be reasonable not to introduce a new state, but to change the meaning of the existing "Stop" state so that it becomes the debugging state.

The paper is open for discussion...

-- MathiasMuench - 11 Feb 2005

---

Concerning the Remarks:

"Therefore, during this phase, no module shall generate any output on its output lines. Since all modules are quiet, the start transition can also be done in parallel. "

From my point of view, this is not possible. We have a chain of modules and a logical chain of operations to transport data. Therefore, it is not possible to keep the outputs of a module "idle" (three-state) and start all modules in parallel.

For example (also apply for Shower-IPC and Shower-LM):

First the IPUs have to put their outputs to a defined idle state (no data) and accept inputs (addressing from the MU). Then the MU should start and listen to the data sent by the IPUs (must start listening to the IPUs after they are started, as during the start transition they could accidentally send data (this could be prevented)) and then start the data-transport by actively addressing the IPUs. As the MU has no connection to the Trigger-Bus, it can not wait for a begin-run-trigger and then start addressing (this would be the only purpose for such a connection, but I think it is not needed at all!).

This requires a special start-procedure for the MU and LM: start after the IPUs are started... The rest can be done in parallel, as the modules don't have a physical connection to each other. (The CTU for sure is the last one to be started and provides the required "order".)

Concerning the "debugging" state:

What should the electronics do to get into a debugging state? From my point of view: nothing! As I want to find an "untouched" system, when I want to find out, why it stopped running. Therefore, I don't see any reasonable transition from "running" to "debugging".

-- MichaelTraxler - 11 Feb 2005

---

My point is that during reset, most systems produce noise on their outputs, which is impossible to suppress. So it is important that the modules stay deaf until the begin of the start phase, so that one resetting system cannot influence another resetting system.

Probably we have to be a little bit more "honest" how the stuff is really started. Actually we already have one operation that can never be done "in parallel", the start of the CTU. This always has to be the last operation. Now we have other candidates, e.g. the MU, but also the DAQ software. So for the time being, I agree that the start phase may not be possible to do in parallel. On the other hand, we have to be careful not to run into a "chicken and egg" situation, where one system needs to be started before the other and the other has to be started before one.

Concerning the debugging state, some systems (at least the shower) do not allow to access any registers during running state. This was my motivation to think about such an transition. Of course one can argue, that for debugging a really unchanged system ist best and if anybody wants information e.g. from shower, he knwos that a special operation is necessary.

-- MathiasMuench - 16 Feb 2005