Do It Later

In designing a protocol architecture there are two aspects to the work; the flow and connection of messages, and the use of state variables. Some protocols can potentially have some complex state handling that needs to be done. For example, designing a complete behavioral protocol for a translation lookaside buffer (TLB) may require tracking the addresses which arrive with a least recently used (LRU) algorithm.

But what if the protocol designer wants defer the details of the LRU algorithm and proceed with designing the flow of messages (signals and bus transactions)? It would be nice to have a way of rapidly prototyping these state functions.

Just the Facts

The ProtoCollum tool uses a special expression evaluator when determining the result of a guard Event expression. The evaluator uses facts to replace a 0 or 1 for any function that is not defined. In other words, the evaluator does not accept an "<fcn> is undefined" error. If the function is undefined, its result is set to 1 if a fact has been defined in the Binder Fact List, otherwise the result is set to 0.

This window shows how a function, with its passed in parameter values, can be put on the Binder Fact List. If the functions shown here are called with the given parameter values then they will return a 1. Any call with different parameter values or any function called not listed here will return a 0.

Forcing the Issue

Writing code to calculate the values of the parameters being sent in the messages is another activity that we may want to defer. These parameter values are needed during simulation, they are sent inside of delivered messages. ProtoCollum has two ways it helps to defer parameter calculation.

The first way is by automatically deriving parameter values for those that are not yet defined. For example, this message, ConnReq(name,id), is defined as having two parameters: name and id.

If the protocol designer does not write code to create values for these parameters, then during simulation, ProtoCollum will automatically generate some values. The first instance of this message will pass the parameter values name1 and id1, the second instance will pass the values name2 and id2, and so on.

The second way to defer writing code to calculate parameter values is to directly force the parameter value in the Test sheet during simulation. In a Test scenario, a message object has its "normal" values and it can also have "forced" values.

The use of a Fact List and of parameter forcing is shown in the sample protocol tlb_mem.mps which comes in the demo/ area of the download package.