™
Previous Chapter | Table of Contents | Next Chapter

Chapter 2 - Basic Concepts

This chapter describes the basic objects and organizational aspects of ProtoCollum.

Objects

ProtoCollum is an object oriented tool. The graphical items seen on Edit and Test Sheets, such as PEs, Messages, and Rules, are program objects that have state and methods that can be invoked. Figure 2.1 shows how a graphical class is wrapped around the base class of each object so that a user can interact with the objects via the ProtoCollum graphical user interface (GUI).

Object Classes
Figure 2.1 Object Class Diagram

The important implication of this object organization is that the ProtoCollum tool can be run as a shell or batch program without the graphical classes. (See the demo/uproc/ area of the download for an example.) Thus, if a protocol architecture in ProtoCollum was being used as a Checker for a lower-level RTL model, one could run hundreds of batch jobs overnight, and then in the morning, come in and debug any mismatched jobs in the GUI version of ProtoCollum.

For information on how to write code using ProtoCollum objects, see the advanced topic Writing Tcl Code.

Binders

A Binder object is the top level object that contains the protocol architecture description consisting of PE, Message, Rule, and other objects. A Binder also contains any number of Test Sheets, which are directly related to the architecture description.

When a Binder object is saved to a file, it uses an XML format, and is organized such that the graphical properties of objects are kept seperate from architectural properties. This allows the same .mps file to be used by the shell and the GUI version of ProtoCollum.

A Binder object has a one to one correspondence to a .mps file.

Edit Sheets

The key to understanding the Edit Sheet is to know that the fundamental principle upon which it is based is the simple state machine.

Figure 2.2 shows a simple state machine which can be used to model a message passing system. An incoming message, possibly containing parameters, causes the system to use the current state and combinational logic to determine if the state should be updated and if one or more output messages should be sent.

State machine system
Figure 2.2 State machine system

In Figure 2.3, the state machine is labeled and organized into smaller discrete pieces to form a Rule:

Rule based system
Figure 2.3 Rule based system

A Guard event is written as a true/false expression (in terms of message reception or state). When all Guard events are determined to be true, then the Action events of the Rule will occur. This is known as "triggering" or "firing" the Rule.

In order to create a protocol model, you identify the Processing Entities (PE) in the system and define Rules which describe each distinct behavior that happens when a Message is received and each behavior that causes a Message to be sent.

This type of rule based description is well suited to the demands of protocol specification; the rules can be very general initially and, due to their encapsulated nature, it is easy to refine and modify them over time.

Figure 2.4 shows how a Rule model (really a state machine model) matches up with the graphical items on the Edit Sheet. So each Rule is really a small state machine which looks at incoming Messages and current State, to determine whether Messages should be sent or State updated.

ProtoCollum Rule
Figure 2.4 ProtoCollum Rule

The events Begin, Mid, and End exist in order to facilitate grouping of the Guard and Action events. They also provide symmetry and cleanness of implementation for the graphical editor, but are not part of the execution model.

Another four objects are used to model message connection; Message, Gate, Segment, and Pin. (The Pin object is discussed later.) Note that an Edit Sheet only shows the relationships or connectedness of Messages and Rules, there is no implication of ordering or time in the diagrams. Figure 2.5 and the discussion below summarizes each object used on the Edit Sheet.

Objects used to create a model
Figure 2.5 Objects used to create a model
1 Processing Entity
A Processing Entity represents a unit in the model which actually does some work and which communicates with other Processing Entities in order to complete assigned tasks.
2 Rule
A Rule object is attached to the stem portion of a Processing Entity and represents a specific behavior that occurs within the Processing Entity. As part of this behavior, certain actions or results are triggered depending on the state of the Processing Entity and the incoming messages being received.
3 Event
An event object encapsulates the specific state changes and message actions that are to take place within a Rule. The two most important event types are Guard and Action. A Guard event represents a message being received or specifies a state expression that acts as a precondition to the triggering of the Rule. When a Rule is triggered, an Action event represents a message being sent and/or state changes being committed.
4 Message
A Message object originates from an Action event and arrives at a Guard event to indicate that some event has completed and/or to pass on information contained within its parameters.
5 Gate
6 Segment
The Gate and Segment objects work together to link all of the rules that have an interest in the Message to which the Gate is attached.
For example, in Figure 2.5 the Gate and Segment indicate that both rule_1 and rule_2 contain the Guard event "msg_0 is received", and both will be evaluated when msg_0 is received by pe_1.
In a correctly constructed model, only one rule will trigger (for any given input and current state, there is only one result in a deterministic system). Which rule triggers is dependent on the current state of the Processing Entity and the triggering conditions within each Rule.

For more information on Edit sheets, see Using Edit Sheets.

Test Sheets

A Test Sheet is where the behavior of a protocol design is exercised. On a Test Sheet you can outline a chain of events for each Processing Entity (PE) in the protocol architecture by controlling the connection of messages. By creating various sequences of events, the PE can be tested for correct behavior. The collection of PE, message, and event objects on a Test Sheet are organized as pieces of a scenario object. There is one scenario object per Test sheet.

As messages are sent from one Processing Entity to another, the protocol model defined on the Edit sheets is executed. The arrival of a message and its parameter values may cause a state change in the PE, or it may cause other messages to be sent. These actions are added to the display while the messages are interactively connected.

Since the Test Sheet or scenario object is a representation of how messages were actually sent and received in a particular instance, there is a time ordering implied in the diagram. Time flows from top to bottom in the diagram. So messages sent/received at the top of the diagram happened earlier than messages sent/received at the bottom of the diagram.

Figure 2.6 shows an example of a simple test scenario. In this scenario, an initial message arrives at PE 0 (instantiated as petest_0). This arrival of this message causes rule_0 to trigger. One action of rule_0 is send another message to PE 1 (instantiated as petest_1). The arrival of that message causes rule_2 to trigger.

Objects found on a Test sheet
Figure 2.6 Objects found on a Test sheet

The various objects found in a test scenario are as follows:

1 PE Test
A PE Test object represents an instance of a corresponding Processing Entity found in the design. A Test sheet may have multiple PE Tests, each of which is an instance of a single Processing Entity in the design.
2 Node
A Node is an organizer object and can be thought of as a little bulletin board onto which everything gets tacked. When a Message Test arrives at a PE Test, a Node is created and attached to the PE Test. A pointer to the guard Event associated with the Message arrival is then stored in the Node. If the Message causes a Rule to trigger, that information is also stored in the Node, along with the actions associated with the Rule.
3 Message Test
A Message Test object represents an instance of a corresponding Message found in the design. Message Test objects are connected between PE Test objects to create a specific chain of events. The numbered suffix attached to the message label represents either a sequence number or the context of the Message Test object.
4 Action
When a Rule has triggered, an Action object is created for each action Event in the Rule. An action Event with no outgoing message is shown in red; otherwise, it is shown in white and a Message Test can originate from the Action object.
5 Whitehole
A Message Test may originate from a Whitehole object. This represents the appearance of a Message which is not the direct result of another event.
Blackhole (not shown)
A Message Test may terminate at a Blackhole object. This represents the disappearance of a Message that is not being sent to any PE Test object in the test scenario.

For more information on Test sheets, see Using Test Sheets.

Previous Chapter | Table of Contents | Next Chapter
Copyright © 2003-2005 by Bellum Software™
last updated on 29 May 2005