Can you flatten HSMs with entry and exit behavior? - state-machine

Is there a way to flatten this Hierarchical State Machine (HSM) to a Finite State Machine (FSM)? I have read HSMs can be flattened to FSMs, but I can't think of a way to do it with entry and exit behavior.

This is no problem. I consider HSMs to be a special case of FSMs (with a "smart" convention how to draw/specify them).
As for the entry and exit actions, UML2 specifies in which order to sort them.

Related

Handling Failures in State diagram

I have a system with 3 states. I wanted to handle failures. That is, when the system reboots, it doesn't know the state it's in. Is the following state diagram correct?
This not a valid UML State Machine Diagram for several reasons:
The start node is the wrong symbol. It should be a bullet.
The arrows fork. Each arrow (transition) should begin and end on a node.
The Y and N don't have square brackets.
Regarding the semantics:
The decisions don't have meaningful text (should refer to previously stored state). They may be combined to one decision "storedState = " which has four outgoing transitions guarded as [S1], [S2], [S3] and [empty].
The actions to store the state in persistent storage, in order to be restored in case of crash, are not present.
In case all decisions yield N, the object is destroyed immediately, instead of ending in some default state.
I don't understand the intention of A1, A2 and A3.
Perhaps it would be good to first show the diagram without reboot logic and then tell us what you try to add to that diagram to handle the failures.

Is it possible to have two instance have same name in the netlist?

Is it possible to have two flops/any other instances have the same name in the netlist?
Considering that there is no hierarchy, say I have a design of 10M instances and there exists an flop called foo, is it possible that another flop have same name 'foo'?
No. Within a single scope, you cannot re-use the same identifier for another purpose,
As Dave says, no. But if you had 10M instances, you wouldn't have coded that manually, your logic synthesiser would have. And it won't output an illegal netlist.
The only way your question makes sense is to consider one large verilog file - obviously, here there can't be more than one reg/logic with the name foo. This is fundamental to the verilog scoping rules.
If there is any iteration or local scope of any form in your design, the elaboration process will construct a form of heirarchy to handle this iteration. If you flatten the resulting netlist (by default or design), then each element will either gain an abstract unique identifier (n1, n2, n3...), or be pre/post fixed with some heirarchical information (gen_1_foo, gen_2_foo...).
After the netlist generation, it may be non-trivial to relate a specific flop to it's syntactic source in the verilog - but you brought this on yourself by the lack of heirarchy and structure in the design.

In a UML state machine, can an initial pseudostate have incoming transitions?

In UML 2.5.1, the initial pseudostate of a state machine is defined as follows:
An initial Pseudostate represents a starting point for a Region; that
is, it is the point from which execution of its contained behavior
commences when the Region is entered via default activation. It is the
source for at most one Transition, which may have an associated effect
Behavior, but not an associated trigger or guard. There can be at
most one initial Vertex in a Region.
In other words, a UML state machine should almost always contain exactly one initial pseudostate, which should have exactly one outgoing transition.
However, can an initial pseudostate have incoming transitions as well? For example:
I cannot find anything forbidding it in the UML specification, yet I cannot find any example online where this case happen, therefore I was wondering whether or not I overlooked anything.
EDIT: To go into more detail, if we look into the OCL constraints stated in the specification, we can only find the following one that affects outgoing transitions (section 14.5.6.7):
inv: (kind = PseudostateKind::initial) implies (outgoing->size() <= 1)
but I cannot find any constraint regarding incoming transitions
EDIT2: I have just realized that my model is wrong! Considering this sentence of the specification (cited above): "It is the source for at most one Transition, which may have an associated effect Behavior, but not an associated trigger or guard."
Therefore the transition between init and s1 should actually have zero triggers, instead of having e1 as a trigger.
Note that while this does not invalidate the initial question.
I see nothing in the UML 2.5.1 Specification that prohibits a transition whose target is the initial pseudostate.
Such a transition would be meaningless at best and confusing at worst, which is likely why no examples are found.
Edit: see the comments!
On p. 423 UML 2.5:
15.7.18 InitialNode [Class]
15.7.18.4 Constraints
• no_incoming_edges
An InitialNode has no incoming ActivityEdges.
inv: incoming->isEmpty()
N.B. If you intend to have a self-transition for e1 then why not just using that? The Initial can anyway have only on singular outgoing edge, namely to the first state (here s1).
No this is not allowed. And why would one Do that? As you already stated in the cited text,it can only have one outgoing edge without any guard. So what is the added value, as you cannot reuse anything.
I think the text is pretty clear as-is: "[An initial Pseudostate] is the point from which execution of its contained behavior commences when the Region is entered via default activation." If you connect a transition back around to the initial psuedostate, the initial psuedostate is no longer "the point from which execution of its contained behavior commences," it is something else, and is therefore undefined.

Can a Finite Automata exist without any final state?

It doesn't make sense to construct a language acceptor which does not able to accept any language. I specifically talking about FA which accept languages not transducer or translator which translate languages.
People build them all the time. You have a set of states, and each state is accessible ultimately from every other, and there is no final state, so it never halts, though it might get stuck in a cycling loop. No issue with that at all.
Do a search on "busy beaver".
The mathematical model of a FSM, as described on the wikipedia page, notes that the set F of final states may be empty. While an empty set of final states isn't much use if the FSM is used as a recogniser, FSMs can also be used as transducers.
For example, a Mealy machine doesn't include a set of final states, since it the output from the machine as the input is processed which is of interest.
It is not just that it can exist - it is even necessary: how else would one accept the empty set, which is one of the regular languages. Unless you use an automaton with unaccessible states, which is pretty similar to not having a final state.

Finite State Machine: One State to Multiple States

I'm writing a simple finite state machine and realized that there are situations where an event can take a state to more than one possible results. Basically, from state A, if Event E happens, the state could be either C or D.
I'm currently using the Javascript Finite State Machine code written here: https://github.com/jakesgordon/javascript-state-machine
From the documentation I don't see an obvious way that makes this possible. More so, I feel like maybe this is actually a flow in my original design.
Essentially, in a Finite State Machine, should there be a situation where a transition happens, and based on some logic result in one of multiple states (1 to many), or should it be that we check the logic to see which transition needs to takes place (1 to 1)?
Congratulations, you've just discovered non-deterministic finite state machines! The ideas are similar to that of a deterministic state machine, except that there may be multiple ways to transition from a state given the same input symbol. How this is actually done is unspecified (randomness, user input, branch out and run them all at once, etc.).

Resources