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



Hi Lennart and all,

It is not clear from where the list below came from? It looks to me even more complex.

It looks that per the proposal below I will need a code book to figure out i.e. encode the state machine.

We need to be careful here and not to drawn to oscillations mode at the last mile of the project. This is a small issue and need simple solution.

A text with shall that lists all the variables that cant be changed after IDLE or make them constants defined in IDLE is a simple solution. It also helps with maintenance of it i.e. not further touching the state machine but only a limited text area.

Yair

From: Lennart Yseboodt [mailto:lennartyseboodt@xxxxxxxxx]
Sent: Sunday, October 29, 2017 10:57 PM
To: STDS-802-3-4PPOE@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_4PPOE] Rules for state diagram variables

 

EXTERNAL EMAIL

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.

 

Preferences ?

 

Lennart

 

 

Yair said:

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 …”

Yair

 

On Sun, 2017-10-29 at 15:53 +0000, George Zimmerman wrote:

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.

-george

 

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

 

Hi,

 

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

- goes to CLASSIFICATION

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

 

However...

 

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,

 

Lennart