Specification of Reactive Hardware/Software Systems - Electronic ...

6.3 Communication 179
Clocks
An interesting example of a multicast communication that we will require for hardware
and for co-design is a clock message. A clock message is a synchronisation message
to all clocked modules. A clock multicast must enforce synchronisation in the form of
immediate involuntary reception. Enforcement could make us think about interrupts as
a mechanism. This mechanism is inappropriate. We want to enforce that the receivers
themselves take their responsibility to be ready for reception of a clock message. This is
exactly what synchronous hardware systems demand. Before the clock tick all modules
must be ready and have stable signals. A violation of this requirement can lead to severe
problems such as meta-stability. So we always want to verify that this requirement is
met. An elegant construct can be achieved by giving the receivers the responsibility to
send a ready message to the clock. By doing so we can be sure that all receivers are
ready simultaneously before we send the clock multicast message. We want to verify
that all receivers are ready in time (to check set-up and hold times) and that all receivers
receive the clock in time. A timely reception is related to transport time. A variation in
reception time, called clock skew, must be held within limits. These aspects cannot be
modelled adequately yet with the proposed forms of behaviour description.
A dedicated multicast primitive together with a real-time primitive are expected to offer
a solution. The integration of such primitives in the formal semantics has priority in our
future research program.
6.3.8 Communication with Object-Multiples
A multiple object is a collection of objects from the same class connected to the same
channels (see Subsection 4.4.4). A multiple represents a collection of equivalent objects.
These objects have in principle independent states. Communication with a multiple
Multiple X
Figure 6.13: Communication with a Multiple Process Object
looks like a multi-way communication, however, it is not. A message flow to a multiple
(see Figure 6.13) must be interpreted as a single flow to one of the objects in the collection.
So the pair-wise character of the communication flows is respected. When more
that one object is ready to perform a rendezvous for a message then one object is chosen
non-deterministically. This is a convenient way to model communication with collections
of identical resources, such as collections of mailboxes and buffers. During the
development of the model for the case in Chapter 12 we found two ways to communicate
with multiples.