CAL Syntax and Semantics

Lexical tokens

Lexical tokens help the user to understand the functionality provided by any language. They are a string of indivisible characters known as lexemes. The CAL lexical tokens, also summa- rized in Table 3.2, are described in the following:

• Keywords Keywords are a special type of identifiers. They are already reserved by default in the programming language. These keywords can never be used as identifiers in the

code. Some of them areaction,actor,procedure,function,begin,if else,

end,foreach,while,do,procedure,in,list,int,uint,float,bool,true

andfalse.

• Operators Operators usually represent mathematical, logical or algebraic operations. Operators are written as any string of characters!,%,ˆ,&,*,/,+,-,=,<,>,?,˜and|.

• Delimiters Delimiters are used to indicate the start or the end of this syntactical element in the CAL. Following elements are used as delimiters:(,),[,],{and}.

• Comments Comments in CAL language are the same as in Java, C and C++. Single line

comments start with//and multiple line comments start with/*and end with*/.

Actions

The simplest actor that can be described using CAL is thePassthroughactor defined in

3.3. CAL Actor Language

Table 3.2 – CAL lexical tokens

Kind Symbols

Keywords action,actor,procedure,function,begin,if,else,end,

foreach,while,do,procedure,in,list,int,uint,float,

bool,true,false

Operators !,%,ˆ,&,*,/,+,-,=,<,>,?,˜,|

Delimiters (,),[,],{,},==>,->,:=

Comments //,/*. . .*/

The actor header is defined in the first line, which contains the actor name, followed by a list of parameters provided inside the()construct (empty, in this case), and the declaration

of the input and output ports. The input ports are those in front of the==>construct and

the output ports are those after it. In this case the input and output ports set are defined as

P_Passthroughi n = {I} and P_Passthroughout = {O} respectively. For each parameter and port, the

data type is specified before the name (all defined with anintdata type, in this case). This

actor contains only one action, labeled aspassas defined in second line. In this case, the

actions set is defined asλPassthrough= {pass}. Actionpassdemonstrates how to specify

token consumption and production. The part in front of the==>, which defines the input

patterns, it specifies how many tokens to consume from which ports and what to call those

tokens in the rest of the action. In this case, there is one input pattern:I:[v]. This pattern indicates that one token is to be read (i.e. consumed) from the input portI, and that the token is to be calledvin the rest of the action. Such an input pattern also defines a condition that must be satisfied for this action to fire: if the required token is not present, this action will not be executed. Therefore, input patterns do the following:

• They define the number of tokens (for each port) that will be consumed when the action is executed (fired).

• They declare the variable symbols by which tokens consumed by an action firing will be referred to within the action.

• They define a firing condition for the action, i.e. a condition that must be met for the action to be able to fire.

The output patterns of an action are those defined after the==>construct. They simply define the number and values of the output tokens that will be produced on each output port by each firing of the action. In this case, the output patternO:[v]says that exactly one token will be generated at output portO, and its value isv.

Listing 3.1 – Passthrought.cal

actor Passthrought() int I ==> int O :

pass: action I:[v] ==> O:[v] end

end

Action Guard

So far, the only firing condition for actions was that there be enough tokens to consume, as specified in their input patterns. However, in many cases it is possible to specify additional criteria that need to be satisfied for an action to fire. Conditions, for instance, that depend on the values of the tokens, or the state of the actor, or both. These conditions can be specified using guards, as for example in theSplitactor, defined in Listing 3.2. This actor defines one

input portI, two output portsO1andO2, and two actionsAandB. Those actions require

the availability of one token inI. However their selection is guarded by the value of the input tokenvalread fromI. In this example, ifval >= 0then the actionAis selected, otherwise actionB.

Listing 3.2 – Split.cal

actor Split() int I ==> int O1, int O2 :

A: action I:[val] ==> O1:[val] guard

val >= 0 end

B: action I:[val] ==> O2:[val] guard

val < 0 end

end

In thePingPongMergeactor, reported in Listing 3.3, a finite state machine schedule is used

to sequence the two actionsAandB. The schedule statement introduces two statess1ands2.

Contrarily, in theBiasedMergeactor, reported in Listing 3.4, the selection of which action

to fire is not only determined by the availability of tokens, but also depends on the priority statement.

Actors composition

In CAL, it is possible to define a composition of actors or a network of interconnected actors as the one illustrated in Figure 3.2. It is composed by three actorsA,BandC, and by five

queuesb1andb2. Two different representations approach are supported: the first one is

3.3. CAL Actor Language

Listing 3.3 – PingPongMerge.cal

actor PingPongMerge() T In1, T In2 ==> T O :

A: action In1:[val] ==> O:[val] end

B: action In2:[val] ==> O:[val] end

schedule fsm s1: s1(A) --> B; s2(B) --> A; end end Listing 3.4 – BiasedMerge.cal

actor BiasedMerge() T In1, T In2 ==> T O :

A: action In1:[val] ==> O:[val] end

B: action In2:[val] ==> O:[val] end

priority A > B end

on eXtensible Markup Language (XML) (Listing 3.6) known as XML Dataflow Format (XDF), which in most of the case is edited by visual editor.

Listing 3.5 – BasicNetwork.nl

network BasicNetwork () int I ==> int O :

entities A = ActorA(maxValue = 3); B = ActorB(); B = ActorC(); structure I --> A.I1; A.O --> B.I; B.O1 --> O; B.O2 --> C.I; C.O --> A.A2; end

3.4 Standardization

A subset of the CAL programming language has been standardized by the ISO MPEG comity and is called RVC-CAL. The MPEG Reconfigurable Video Coding ISO/IEC 23001-4 has as a purpose to offer more flexible use and faster path to innovation of MPEG standards in a way that is competitive in the current dynamic and evolving environment. Thus, MPEG standards give an edge over its competitors by substantially reducing the time for which technology is developed and the time the standard is available for market applications. The RVC initiative is based on the concept of reusing commonalities among different MPEG standards and provide possible extensions by using appropriate higher level specification formalisms. Thus, the objective of the RVC standard is to describe current and future codecs in a way that makes such commonalities explicit, reducing the implementation burden by providing a specification that its starting point is closer to the final implementation. To achieve this objective, RVC provides the specification of new codecs by composing existing components and possibly new coding tools described in modular form.

The MPEG-B standard defines the language that is used to build the MPEG RVC framework. The RVC-CAL dataflow programming language is the core of the system; it is used to describe the behavior description of each module called Functional Unit (FU). With the specification of the FU network topology, the functional behavior of a video decoder is specified. An FU network topology is also called abstract decoder module. The term abstract refers to the fact that FUs are only characterized by the I/O behavior and the firing rules embedded in the RVC- CAL language. Thus, the interaction of each FU other FUs is fully specified by abstracting the time and by only defining dependencies of data production and consumption. The MPEG-C standard defines the Video Tool Library, a library of video coding tools. Figure 3.4 illustrates the concept that any abstract decoder model, which is constituted by an FU network description,