| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Putting it in the variable definition makes the state diagram behavior no obvious, and is not a good idea. Definitions should not contain the dynamics - they should just define.
The other option is to make the ones that can only change in idle (really only on exit from reset or disable) constants.
Let’s hit pause until Monday and see what David Law or others have to say, but I believe the principle is that the diagram should contain all the dynamic behavior. Putting shalls elsewhere or in variable definitions subverts the diagram and creates arguments
about potential conflicts between text and the diagram (which the diagram always wins)
George A. Zimmerman, Ph.D.
CME Consulting, Inc.
Experts in PHYsical Layer Communications
310-920-3860
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:
Yair From: George Zimmerman [mailto:george@xxxxxxxxxxxxxxxxxxxx]
EXTERNAL EMAIL 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]
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... <image001.png> 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 |