A Simple Round Robin Scheduler

This project is to design and verify a round robin scheduler, using one of
the formal verification systems that we have studied:  Alloy or NuSMV.

Following is a description of a distributed round robin scheduler and a
first attempt at a design.  This design has a flaw, which your systems should detect.
(The next step, which is not described here, would be to
revise the design so that it is correct.  Your systems should not detect
any flaws in the revised design.)

The scheduler outputs two kinds of messages:
start messages a1,...,an
finish messages b1,...,bn

The requirements are:

1. For i=1,...,n, after sending ai, it must send bi before it can send ai
again, and after sending bi, it must send ai before it can send bi again.

2. For i=1,...,n, after sending ai, it must send a((i mod n)+1) before it
can send any aj, j != (i mod n)+1.

3. Any sequence of outputs satisfying conditions 1. and 2. must be a possible
sequence of outputs of the scheduler.

A restriction on the design is that the scheduler must be constructed from
n identical units connected in a ring. Each unit has four ports labeled
a, b, c, d. The a and b ports of unit i send signals ai and bi respectively.
The c port of unit i is connected to the d port of unit (i mod n)+1.

For our first attempt at building the scheduler, the units will behave as
follows. Each unit has four states A, B, C, D. The time it stays in a given
state can vary, but its action will always be the same.

In state A: it eventually sends message a and goes to state C.

In state C: if it is unit i in the ring and unit (i mod n)+1 is in state D,
then i eventually performs a handshake with (i mod n)+1 by sending a message c
to (i mod n)+1 and receiving a message d from (i mod n)+1, and then i goes
to state B.

In state B: it eventually sends message b and goes to state D.

In state D: if it is unit i and unit (i-2 mod n)+1 is in state C, then i
eventually performs the handshake as described above and goes to state A.

Here are the objectives:

1. Formalize the description of the design of the scheduler.
2. Formalize the three requirements.
3. Establish whether or not the design meets the requirements.

------------------------------------------------------------------------------

Here are some hints:

You don't necessarily need to specify a starting configuration, but if you do,
a good choice is where unit 1 is in state A, and the rest of the units are in
state D.

The state changes must be nondeterministic. For example, if a unit is in state
A, it can stay in state A indefinitely or it can output message a and go to C.

You don't want to let a unit stay in one state forever.  In NuSMV, this can be
prevented with a FAIRNESS condition.  For example, to guarantee that some
process doesn't get stuck in state A forever, you could say something like this:
FAIRNESS !(state = A)

FAIRNESS says the following condition will be true infinitely often, so
the above statement says that state will not be A infinitely often.

Since the architecture is symmetric (all units behave in the same way), you
don't need to verify the three requirements for all units. All you need to do
is verify that they hold for i=1.

Some things can be easy to do in one verification system and hard (or even
impossible) to do in another.

Requirements 1. and 2. can be expressed as LTLSPECs in NuSMV.  I think the best
way to handle Requirement 3. is with a FAIRNESS condition.