Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [802.3_4PPOE] Rules for state diagram variables

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:

  1. 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 cant change after IDLE state. OR
  2. 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 …”




From: George Zimmerman [mailto:george@xxxxxxxxxxxxxxxxxxxx]
Sent: Sunday, October 29, 2017 5:54 PM
To: STDS-802-3-4PPOE@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_4PPOE] Rules for state diagram variables



Lennart –

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
To: STDS-802-3-4PPOE@xxxxxxxxxxxxxxxxx
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)

- goes to DETECT_EVAL


- 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.


Kind regards,