Difference: RunControlStates (1 vs. 4)

Revision 4
02 Jun 2005 - Main.SimonLang
Line: 1 to 1
Added:
>
>
META TOPICPARENT name="RunControl"
 

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.
Revision 3
16 Feb 2005 - Main.MathiasMuench
Line: 1 to 1
 

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.
Line: 75 to 75
 

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.
Changed:
<
<
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 deugging state.
>
>
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...
Line: 105 to 105
  -- MichaelTraxler - 11 Feb 2005


Added:
>
>

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
Revision 2
11 Feb 2005 - Main.MichaelTraxler
Line: 1 to 1
 

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.
Line: 67 to 67
 

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.
Changed:
<
<
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 forst input seen on the active input lines is the "begin run trigger".
>
>
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.
Line: 79 to 79
 

The paper is open for discussion...
Added:
>
>
  -- MathiasMuench - 11 Feb 2005
Added:
>
>


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


 
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Hades Wiki? Send feedback
Imprint (in German)
Privacy Policy (in German)