In the List Config state machine (8.6.9.3)::
The rules (b) & (c) use the 'GateEnabled' to imply whether the current schedule is stopped or running, as below,
though the definition does not imply any relationship of the 'GateEnabled' with the current schedule. It will
increment ConfigChangeError counter incorrectly, as explained below.
***begin: excerpt from the 802.1qbv***
b) If:
(AdminBaseTime < CurrentTime) and (GateEnabled = FALSE)
(i.e., AdminBaseTime specifies a time in the past, and the current schedule is stopped)
Then:
ConfigChangeTime = (AdminBaseTime + N*AdminCycleTime)
where N is the smallest integer for which the relation
ConfigChangeTime >= CurrentTime
would be TRUE.
c) If:
(AdminBaseTime < CurrentTime) and (GateEnabled = TRUE)
(i.e., AdminBaseTime specifies a time in the past, and the current schedule is running)
Then:
Increment ConfigChangeError counter (12.29.1)
ConfigChangeTime = (AdminBaseTime + N*AdminCycleTime)
where N is the smallest integer for which the relation
ConfigChangeTime >= CurrentTime
would be TRUE.
***end: excerpt from the 802.1qbv***
However, the 'GateEnabled' is defined as below, which either enables or disables all the FSMs but has no sense of the 'CurrentSchedule'.
8.6.9.4.14 GateEnabled
A Boolean variable that indicates whether the operation of the state machines is enabled (TRUE) or disabled
(FALSE). This variable is set by management. The default value of this variable is FALSE.
Coming to the practical scenario:: the 'GateEnabled' is asserted to start all the FSMs but the CSR writes to the Admin variables take some time, during which
the the current schedule is not running - thus, we need to be in rule b) by the spirit of the design. However, we need to follow the rule c)
by the protocol because the 'GateEnabled' is asserted - which is wrongly indicating that the current schedule is running though not running in effect.
It will thus, increment ConfigChangeError counter incorrectly
Hence, let us define another variable: 'CurrentSchedule' under the control of the Cycle Timer state machine(8.6.9.1) because this state machine controls the.
When the Cycle Timer state machine has calculated 'CycleStartTime' and has asserted 'CycleStart',
the variable 'CurrentSchedule' is asserted, indicating that the schedule is operating from now on in a periodic fashion.
The key point here is that using 'GateEnabled' as the condition in the rules (b) & (c) of the clause 8.6.9.3.1 will miss indicating the practical happening -
After GateEnabled is asserted to enable the state machines to operate, there is no current schedule for some time
till the List config state machine is in a position to assert 'CycleStart', thus leading to incrementing ConfigChangeError counter incorrectly.
Hence, we need another variable 'CurrentSchedule' under the control of the Cycle Timer state machine (8.6.9.1) to replace 'GateEnabled'
for the rules b) & c) in the section 8.6.9.3.1. Of all the state machines, the Cycle Timer state machine is in the best position to control
assertion and deassertion of the variable 'CurrentSchedule' as it is the state machine initiating the gating schedule with its assertion of 'CycleStart'.