PETRI NET APPROACH FOR ALGORITHMS DESIGN AND IMPLEMENTATION

The paper deals with the design of a new hybrid RISC computer architecture, with the computation driven by a Petri net. A class of Petri nets, suitable for the purpose is proposed within the paper, based on Colored Petri nets. The design of the architecture follows structure and memory organization, control unit and processing elements. The architecture is implemented using emuStudio emulation platform and its operation is demonstrated by an example at the end of the paper.


INTRODUCTION
Petri nets today are well-known and widely accepted formal method for the design and analysis of discrete systems, including those with parallel and distributed nature.Modeling capabilities are easy accessible thanks to their graphical representation, which supports imagination of the system designer.Very valuable and unique are analytical properties too, including automatic calculation of system invariants based on a net structure [1].Although Petri nets have a lot of unique properties supporting modeling and analysis of systems, the process of implementation of the system designed usually is not as straightforward as in case of some other formal methods.Methods like B-Method [2] or Perfect developer [3] offer the support for generating the implementation form the specification directly and this feature can be considered as an advantage compared to Petri nets.System implementation thus can be time consuming and error-prone task, so our intention here is to address this problem and propose solutions to mitigate it.
We believe a suitable solution could be a new computer architecture, with the computation driven by an associated Petri net.Architecture named APNA is a hybrid one, with the idea of separating the program control-flow from the performing of calculations, which will lead to better support of concurrent programming.APNA is a parallel architecture and its ISA (Instruction Set Architecture) is of RISC type.Hybridity of the architecture results from eventbased calculation of Petri net, which is combined with the control-flow execution of a segment of code associated with the Petri net's event.

RELATED WORKS
There exist some system implementations based on Petri nets.However, Petri nets are mostly used as formal tool for analysis and verification of systems under development.Systems based acting like some kind of Petri net simulators are available too -it is a different idea of utilizing Petri nets in system design and development.
Within [4], authors present an asynchronous implementation of a Petri net based discrete event control system (DECS), using a Xilinx field programmable gate array (FPGA).The paper reports on the implementation of a Petri net based DECS for an experimental manufacturing system.
They aim to provide a guideline to show how to obtain very high speed, concurrent and asynchronous Petri net based controllers.
Another approach is used in [5], where Petri nets are used for controlling and operating flexible manufacturing system (FMS).At the beginning, the paper describes how to synthesize such Petri nets with properties like liveness, boundedness, and reversibility.Then the FMS is described and a hybrid methodology for the design of PN model of the manufacturing system is illustrated.Finally, a PN description language and a PN execution algorithm for supervisory control are shown.
Discussion of implementing a Petri net in VHDL is presented in [6].The paper discusses how the FPGA architectures affect the implementation of Petri net specifications.Authors propose a method for obtaining VHDL descriptions amenable to synthesis, and tested against other standard methods of implementation.
The works mentioned above are concentrating on hardware implementation of systems based on Petri nets.However, there exists another solution, namely a tool for automatic generation of controllers' implementation code from Petri nets models, presented in [7].The generated code is amenable to be deployed into common platforms using widely used high level programming languages, such as C, C++, and Java.The generated code is linked with platform specific functions, supporting different types of implementation platforms, ranging from low-cost microcontrollers to workstations, and including microcontroller IPs (Intellectual Property) to be embedded into FPGAs (Field Programmable Gate Arrays).The system controller behavior is modeled using IOPT (Input-Output Place-Transition) Petri Nets models, which are represented through PNML (Petri nets Mark-up Language) notation.

PROGRAM FLOW OF ALGORITHMS AND PETRI NETS
Algorithms can be expressed in many ways: algebraically [8], using flowchart diagrams [9] or programming language constructions.Every programming language has defined its own set of control structures for controlling the program flow.According to [10,11] every computable function can be expressed by using the three basic control structures only: • Sequence (Fig. 1); • Alternative/branching (Fig. 2); • Loop/iteration (Fig. 3).
Ordinary Petri nets however are not suitable for deterministic expressing of them, since branching and iteration cause non-determinism (see Fig. 2 and Fig. 3).Using some of high level Petri nets, with higher modeling power we can solve the problem.instr. 1 instr.2 Three basic control structures may not be still enough, if we consider real problems connected with programprogram communication, or (at lower level) with programoperating system communication.There exists 'technical' control structures, which are used to solve these kinds of problems: • Procedure calling (including passing parameters and recursion); • Exception and interrupt processing.
There exist some sorts of Petri nets that allow modelling of such control structures, however with very limited analytical properties, or they are too complex.
For example, procedure calling introduces a stack that would contain returning addresses.The stack could be modelled in Petri nets in a case when so-called time marks could be used, ie.tokens with the age attribute.When a token is 'pushed' into a place, the age of all tokens already in the place is increased.New token would have the age 0. With that, we can model pushing and popping values to/from the stack: pushed tokens would have the lowest age in the place, and in a case of the 'pop' operation, tokens with the lowest age will be popped (similarly it is possible to model a FIFO queue).Within concurrent procedure execution, there are even more complex questions how to solve racing.We can see that ordinary Petri nets cannot be used.Questions about procedure calls is discussed for example in [12].
Next example -in case of Petri nets, expressing the interrupts would cause spontaneous generation of tokens in some places that would correspond to incoming external signals representing given event.These questions are discussed in works like [13,14].

COLORED PETRI NET FOR PROGRAM FLOW DESIGN
As it was mentioned above, within the APNA architecture, the flow of computation is driven by a Petri net.But what kind of Petri net it should be?Since we want the Petri net with the modeling power suitable for full program flow control, ordinary Petri nets thus are not suitable due to inability to model deterministic versions of two of three basic control structures (branching, looping).Resulting type of net should be autonomous too, because we want the formal analysis remain possible.
As most interesting of Petri net dialects we consider the Colored Petri nets.Their modeling power goes over the requirements for the APNA architecture and in case of expressing power, they are equal to ordinary Petri nets, so valuable analytical properties are still available.Colored Petri net however is equipped with a modeling language, which can be Turing-powerful.So the original language should be developed for net-expressions and code segments (a basis for performing calculations running on the APNA architecture).
Some restrictions are introduced here to the original concept of Colored Petri nets in order to simplify and speedup the APNA's control unit.In the APNA architecture, one Petri net will correspond to one procedure.Petri net will be used to control the calculations only, not to perform the calculations itself or data transfers.So we are looking for a kind of CPN, with the modeling power as low as possible, but still able to express all the basic control structures in procedures, including the concurrency.The list of restrictions follows: • Petri net will contain ordinary places only (UNIT type), with the capacity restricted by the architecture implementation.
• Within every procedure, flags (represented by places of a BOOL type) can be used in guards.
• Guarding expressions will consist of one or more simple comparisons using the '=' operator only.
• CPN variables can be used to transfer values of flags only.
• Reference variables will serve as processor registers or addresses in data memory.
• No arc expressions will be used.All the actions will be performed within code segments.
• Simple arcs (no weights) are allowed only.
Another properties correspond to those of standard (non-hierarchical, non-timed) CPN according to the definition found in [15].The language used in code segments of transitions will be described later on.Definition 4.1.CPN for APNA is a net CPN APNA = (CPN, F), where CPN is standard CPN, defined as 9-tuple CPN = (Σ, P, T, A, N,C, G, E, I) (according to [15]) and it holds further: • F is a subset of a set of reachable markings, F ⊆ R(CPN) ∪ / 0, called the set of final markings.Final markings bring the net into deadlock state; • Σ is a set of colors, Σ = {UNIT, BOOL}, where UNIT = {()} and BOOL = {0, 1}; • P is a set of places, P = P ∪ P G , where: -P are places of color C(P ) = UNIT with the capacity K1 ; -[a = {0, 1}]; • All arc expressions except those connecting places from P G express to carry only a single simple token () (it's identity is from UNIT color) with no variables involved.Variables however can be used in arc expressions connecting places from P G .In this case, variables a, b, and c are bound with a token from G 0 , G Definition 4.2.CPN APNA = (CPN, F) computation is defined in the same way as in the case of standard CPN.

Example: Algorithm for Factorial Computation
Algorithm of a factorial computation in ordinary programming languages has two variants -recursive one and non-recursive one.Within this example, we will show how to build CPN APNA for the implementation of nonrecursive algorithm for factorial computation.The algorithm is shown in Algorithm 1.

Algorithm 1 Non-recursive algorithm for factorial computation
Transcription of the algorithm into CPN APNA must hold to a sequence of steps.The first step is to find a program flow in a graph form, that will be then redrawn into Petri net.The APNA architecture also allows the design of recursive programs, but it is not visible in Petri net structure.Program flow graph of the algorithm introduced above is shown in Fig. 4.
Next step is a transcription into Petri net.The transcription in fact holds to standard transcription schema, shown in figures 1, 2 and 3. Within the program flow graph, it is possible to see two of three fundamental control structuressequence and loop.According to the standard transcription schema, it is possible to use proposed Petri net structures.However, a non-determinism must be solved.For this purpose, the CPN APNA allows to use guard expressions near the transitions.The guard expressions express required state of one or more places within a P G set.If the guard conditions are met, the transition can be fired.
Resulting Petri net is shown in Fig. 5.
Fig. 4 Program flow of non-recursive algorithm for factorial computation The designed Petri net is not complete, however.It must be supplied with code segments, one for each transition.By code segments, actions and side-effects of the Petri net are specified.The side effects in fact are computations performed by the algorithm itself.Therefore, computation of the algorithm does not affect the behavior of Petri net.A code segment, assigned to each transition t, is a block of sequential code (instructions) that will be executed when the transition t is fired.
Method shown above is good to be used within analyzing existing algorithms, for example determining if a deadlock can be achieved in the procedure, or in what circumstances the procedure would halt.
We can take the problem also from the other point of view.If a researcher is designing a new algorithm, he can use Petri nets for visualizing algorithm flow and naturally design parallel algorithms, what is enabled by the nature of Petri nets.The visualization can be the language of our imagination.
However, implementation possibilities, described in short in the next section, restrict the programmer to creating only limited structures of such Petri nets.

THE APNA ARCHITECTURE
Basic property of APNA architecture is that it separates control of program flow from the computation.The program control is represented by Petri net (CPN APNA ) and the computation is represented by sequential code within code segments.Each transition of the Petri net has assigned a single code segment.The code segment is executed when the assigned transition is fired.
APNA is a multiprocessor architecture, therefore all transitions that can be fired concurrently will be really concurrently fired.The architecture has a few other properties, too: • Parallel modified Harvard RISC architecture enabling more coarse-grained parallelism; • Programming is relative high-level -program flow is separated from computation; • Supports procedure calling including recursion.
The APNA architecture consists of two parts -control unit (CU) and from eight process elements (PE) that are performing the computation.The control unit does: • Loading Petri nets' representations dynamically from main memory; • Mapping of code segments onto given PE's; • Realization of Petri net computation (simulation), what includes detection of fireable transitions; detection of concurrent transition firing possibility; firing all concurrently fireable transitions -by mapping and execution of PE's; and computation of new marking of given Petri net.
Process elements perform the computation itself, using simple RISC instructions that do not include jumps 2 .Each process element has its own private program memory that is filled with mapped code segment.Abstract schema of structure organization of the APNA architecture is shown in Fig. 6.A virtual machine of the APNA architecture was implemented, within the emuStudio emulation platform [17].The emulator performs all necessary computations and communicates with virtual program and data memories.CPU, and both memories are implemented as plug-ins for the emuStudio platform.A user besides executing the virtual machine, can also write and compile programs for the APNA, using designed and implemented compiler that is included.The language is similar to standard assembly languages, but it includes also Petri net textual representation.The compiler translates the source codes into binary representation, that can be loaded directly into program memory.

DISCUSSION/CONCLUSIONS
The CPN APNA , i.e.Colored Petri net for APNA architecture, excluding the assembly language, is autonomous net that is intended for representation of program flows.This restrict the net usage and it can be stated that the net itself cannot express an algorithm, only its control flow.This is ensured by possibility of modelling of three fundamental control structures (sequence, branching, loop).The computation of the algorithm is expressed in separated code segments with independent language that is a kind of assembler.
The APNA architecture, implemented as virtual machine, combines control and event driven program flow approaches.It is a RISC and multiprocessor architecture that simulates CPN APNA Petri nets, located in memory.It is also modified Harvard architecture, therefore binary forms of Petri nets and code segments are located in the read-only program memory, while data manipulation is performed upon the read-write data memory.
The architecture should help implementing parallel and sequential algorithms allowing to express the program flow using Petri nets.The advantage of this approach is the ability of program flow visualization, simple expression of concurrent program blocks and their synchronization, and formal analyzability of expressed flows, e.g.detection of deadlocks (or procedure halt conditions).
This architecture is designed for researchers and should be improved in the future.We wish to implement it in FPGA chip, and allow interconnect the APNA computation with host processes.Another improvement we want achieve is to create a visual tool for creating algorithms that would allow translate the visual diagram into the assembly language.

Fig. 6
Fig. 6 Modified Harvard architecture for APNA are places of color C(P G ) = BOOL with the capacity K G = 1.These places are initialized with a token f alse;• G is a guarding function; every guard expression G(t) can use only 3 variables (associated from arc expressions) a, b, c ∈ BOOL.Every guard expression thus can have one form of the following (supposing pre-places •t ∈ P G and arc expressions bound the variables):