Re: [802.3_MAINT] Summary of maintenance adhoc call on MAC interface
RE figure 4-6: The issue with the figure is the ambiguous
meaning of calling a psuedo-Pascal function from a state
machine state with a UCT exit condition.
Correct. This is the root of the problem. We are mixing our
traditional state-machine conventions with the Pascal rules,
and in this case the two do not work together.
Some read it as an action that doesn't complete until the
function returns a result (as a program would act when it
made a function call). Others read it as the action being
complete as soon as the function is called. Therefore you
leave the state almost immediately. If read the second way,
you could get another MA_DATA.request and enter the state
to try to call Function transmitFrame again while transmit
Frame is still processing the last call.
Right, and either one of them can be a valid interpretation.
Since this is a mix of a state-machine and Pascal, we do not
know which one should take precedence, unless we are explicit
about it.
One way to make the state machine operation unambiguous
would be to add an exit condition that keeps the machine
in the GENERATE_TRANSMIT_FRAME state until TransmitFrame
has returned a result.
That would be one way of fixing it. Unfortunately, as currently
defined, TransmitFrame does not return a good exit condition as
part of TransmitStatus that we could use. We would have to add
a global variable "transmit_Done" to it, but I am reluctant to
make any changes to the MAC Pascal. Every time we tried to fix
this, we opened another can of worms. Also, this would only
work if we define the primitive MA_DATA.request as persistent.
I don't believe this is specified anywhere, and it is another
major ambiguity.
The more I think about it, the more I am leaning towards just
documenting this behavior in a note somewhere in clause 4, where
we explain why it "just works".
Shimon.