|Thread Links||Date Links|
|Thread Prev||Thread Next||Thread Index||Date Prev||Date Next||Date Index|
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.
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.
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.