Hi George, Yair,
It's possible to come up with erroneous behavior for nearly every I-type variable, because the state diagram wasn't designed to handle those getting changes while running.
There are many ways to tackle this issue, I'm not hung up on the type assignments I'm proposing, but I do like the uniformness of this solution.
What I could see as an alternative is (so, not introduce types, but I'll refer to the types to see how we should treat each):
A-type: Specifically say that this variable can be set at any time. There aren't that many of these.
D-type and R-type are similar, these need to be variables, but clearly state the rules in the description
F-type: also simple, this is not to be written outside of the function
F/S-type: not sure
I-type: move to the constants section if they can only be written in IDLE, otherwise keep as variable and list states that allow writes
P-type: no issue
S-type: keep in variables section, this will become the default behavior - not writeable by the PSE
All in all, we'd be doing pretty much the same thing.
George and all,
Changing the variables that we want to set in IDLE only and named them “xxxx_latched”, I personally
prefer to avoid it unless there is no other option.
What if we do the following options:
Each variable that we want to set only in IDLE and not change it later, to consider adding to this variable definition where it defines only (IDLE) and it can’t change after IDLE
Add text with a “shall” in the text belong to the state machine clause and link to the state machine that says “The
following variables shall not be changed after they where set in IDLE : x, y, z …”
On Sun, 2017-10-29 at 15:53 +0000, George Zimmerman wrote:
This text may or may not clarify the state diagram. However, the example you point out would ordinarily be considered an error in our state diagram, which can be remedied in a conventional way without a new set of rules. In fact, without
that remedy, our state diagram allows the behavior you describe and is perfectly OK but broken.
The problem you described should be solved as follows:
Define a new variable (pse_alternative_latched)
In IDLE, add the assignment pse_alternative_latched <= pse_alternative
In all other states and arcs replace pse_alternative with pse_alternative_latched
You want to make all such variables that can be set externally and asynchronously to the state diagram only set in IDLE, and then constant while the state diagram is operating, unless they are error or global reset (pse_reset + iclass_lim_det
+ error_condition) escapes returning to IDLE, or the pse_disable escape to DISABLE. If a variable needs to be constant throughout the state diagram, then it should be constant. If, for some reason, it should be set in a particular state other than IDLE,
because it is, for example, a sensed value, then, either it really should be the return of a function which is called in that state and otherwise not set, or the latched variable approach described above should be used.
Not to say that sometimes we don’t need to invent new rules, but consistency with the rules in IEEE Std 802.3 should be tried first. After we follow the normal rules, then we should figure out whether and why we might invent new ones.
If we don’t we could end up making a mess of IEEE Std 802.3 and destroying clarity. Not saying you’ve done that yet – but the example listed can and should be easily fixed conventionally.
From: Lennart Yseboodt [mailto:lennartyseboodt@xxxxxxxxx]
Sent: Sunday, October 29, 2017 7:47 AM
Subject: [802.3_4PPOE] Rules for state diagram variables
Consider the following example:
- pse_alternative is set to "a" and pse_enable is set to "enable"
- The PSE goes from IDLE to START_DETECT
- does detect on Alt A (which results in valid)
- at this point the PSE changes pse_alternative to "both"
- proceeds to classify and turns on both pairsets.
Is this allowed ? Ofcourse not. We all know that pse_alternative can only be set in IDLE.
It doesn't say that. There is no indication whatsoever that this variable can only be set in IDLE.
This is just one example of clearly undesired behavior that is possible if there is a violation against the implicit access rules for variables.
Attached baseline proposed to assign each variable to a certain "type" that provides rules on when and by what entity the variable may be written.