IN
DEGREE PROJECT ELECTRICAL ENGINEERING, SECOND CYCLE, 30 CREDITS
STOCKHOLM SWEDEN 2021,
MATLAB/Simulink
implementation of ForSyDe
ANDREA SILVESTRO
MATLAB/Simulink
implementation of ForSyDe
ANDREA SILVESTRO
Master in Embedded Systems Date: April 30, 2021
Supervisor: Rodolfo Jordão
Abstract
Nowadays, it is possible to integrate an increasing number of functionalities on a single chip thanks to the state of the art technology in Electronic design automation. However, designing highly complex electronic systems quickly and reliably requires dealing with all such functionalities, which can be dif- ficult as it requires a long and challenging design process because low-level details are necessary to obtain a functional implementation. One approach to deal with this complexity is to tackle SoC design from a high-level abstraction standpoint. Then, the numerous functionalities can be described and possibly addressed at a high level, as long as the newly created abstraction gap is taken care of.
Time-to-market is of crucial importance when designing a product. A design process done at a high-level of abstraction considerably reduces the time re- quired to obtain the final product. ForSyDe was created to address the problem of moving system design (I.E. System on Chip, Hardware, and Software sys- tems) to a higher level of abstraction and bridge the abstraction gap by transfor- mational design refinement. Currently, ForSyDe is implemented in the func- tional language Haskell and SystemC. The design flow starts from executable application models with individual design constraints that are a consistent part of ForSyDe ’s goals and this thesis’s primary focus.
This thesis project presents the implementation of ForSyDe in the widely used modelling software MATLAB/Simulink. This new implementation allows us- ing the ForSyDe methodology together with the powerful simulation tools of- fered by Simulink and Matlab. The thesis describes and analyses the differ- ent Models of Computation (MoCs) used by ForSyDe. It then presents the ForSyDe methodology and its existing Haskell implementation (on which the Simulink implementation is based).
The Simulink simulation engine is introduced to show the differences and similarities with Haskell. The Simulink library developed is based on the ForSyDe-Shallow module (an Embedded Domain-Specific Language part of the Haskell implementation). The limits and opportunities introduced by the Simulink implementation are discussed in this thesis. Like the rest of the docu- mentation, all the existing code is available on the Github repository. The eval- uation and comparison of the ForSyDe-Simulink library are also done with a concrete application model that is an Audio Filter subsystem of an audio equal- izer system. Simulink is concluded to be more efficient in performance con- sidering the execution time and the memory consumption, but it is not suitable to properly accommodate ForSyDe-Shallow due to a lack of expressiveness.
så är det idag möjligt att integrera mer funktionalitet på ett enstaka chip. Att däremot designa komplexa elektroniska system fort och pålitligt så krävs att alla funktioner hanteras korrekt, vilket kan vara svårt eftersom att det kräver en lång och besvärlig design process eftersom en hel del detaljer krävs för att få en fungerande implementation. Ett sätt att handskas med denna komplexitet är angripa problemet för SoC design genom att använda en hög abstraktionsni- vå. Då kan all funktionalitet beskrivas och troligen även adresseras på en hög abstraktionsnivå, så länge man åtgärdar de abstraktions gap som detta orsakar.
Tid-till-Marknad är av yttersta vikt då man designar en produkt och en design- process som utförs på en hög abstraktionsnivå minskar kraftigt tiden till dess att produkten kan framställas. ForSyDe skapades för att adressera problemet med att flytta design av system (t.ex. System on Chip, hårdvara och mjukva- rusystem) till en högre abstraktionsnivå och brygga gapet genom att använda transformationer och förfiningar av designen. Just nu så är ForSyDe imple- menterat i det funktionella språket Haskell och även SyStemC. Designflödet startar med exekverbara modeler av applikationen med individuella design be- gränsningar som är en del av ForSyDe’s mål och detta examensarbetes primära fokus.
Detta examensarbetesprojekt presenterar en implementation av ForSyDe i den välanvända modelleringsmjukvaran MATLAB/Simulnik. Denna nya imple- mentation tillåter användandet av ForSyDe metodologin tillsammans med det kraftfulla simulationsverktyget som tillhandahålls av Simulink och Matlab.
Examensarbetet beskriver och analyserar de olika modeller för beräkning (MoCs) som används av ForSyDe. Sedan så presenteras ForSyDe metodologin och dens nuvarande Haskell implementation (som även Simulink implementation baseras på).
Simulationsmotorn I Simulink introduceras för att påvisa skillnaderna och lik- heterna med Haskell. Biblioteket som utvecklats I Simulink baseras på ForSyDe- Shallow modulen (ett inbäddat och domänspecifikt språk som är en del av Has- kell implementationen). De begränsningar och möjligheter som introduceras I och med Simulink implementationen diskuteras i detta examensarbete. Likt resten av dokumentationen så finns all kod tillgänglig på Github. En utvär- dering och jämförelse av ForSyDe-Simulink biblioteket utförs också med en konkret applikationsmodell som är ett ljudfilter ifrån en ljudutjämnare.
Acknowledgements
The completion of my University career was made possible by many people who have supported me along the road and pushed me when I felt lost and unmotivated. I, therefore, want to thank my supervisor Rodolfo Jordão for the dedication shown towards my job, the numerous suggestions, the construc- tive discussion and my examiner Ingo Sander for allowing me to work on this project.
I thank all my family and, in particular my parents Franco and Mara, for be- lieving in my choices and supporting me emotionally and financially, my sister Alice for understanding and helping me when in need.
A special thanks to Rebecca, who pushed me all the way to this accomplish- ment.
I am grateful to all my friends, and in particular Giannis, for sharing many great experiences, Elaheh for bearing with me and Eric for being a bit crazy.
I cannot forget Andre, Enri, Leo, Rocco, and Simo for sharing a special year.
Last but not least, thank you, Sara, Debby, Michela, Gabri, Ale, Scordo, for being perfect roommates.
.
Abstract . . . iii
Acknowledgements . . . v
List of Figures . . . xiii
1 Introduction 1 1.1 Problem statement . . . 1
1.2 Objectives . . . 3
1.3 Pre-study and method . . . 4
1.4 Overview . . . 4
2 Theoretical background 6 2.1 Formal System Design Methodology . . . 6
2.1.1 The ForSyDe design flow . . . 7
2.2 Signal, process, and process constructors . . . 8
2.3 Models of computations . . . 11
2.4 ForSyDe-Shallow . . . 12
3 Simulink environment 15 3.1 Simulink main strengths . . . 16
3.2 Simulink models of computations . . . 16
4 Simulink’s ForSyDe vs Haskell’s ForSyDe 18 4.1 Comparison of computational models between Simulink and Haskell . . . 18
4.1.1 Simulink discrete vs Haskell synchronous . . . 18
4.1.2 Simulink’s continuous vs Haskell’s continuous . . . . 19
4.2 Supported features and mapping outline . . . 19
4.2.1 What is supported . . . 20
4.2.2 Mapping plan . . . 20
CONTENTS
5 Simulink ForSyDe library 23
5.1 Library architecture . . . 23
5.2 How it was implemented . . . 23
5.2.1 Combinational process constructors . . . 24
5.2.2 Sequential process constructors . . . 27
6 Discussion 36 6.1 Expressiveness . . . 36
6.2 Comparison of a concrete application model: the audio filter . 38 6.2.1 General description . . . 38
6.2.2 The code . . . 38
6.2.3 Simulation performance . . . 39
6.3 Feedback loop testing . . . 44
6.4 Possibility for synthesis and code generation . . . 46
7 Conclusions and future work 50 7.1 Summary . . . 50
7.2 Future work . . . 51
Bibliography 53
A ForSyDe-Shallow Simulink library 56
1.1 The necessity of a time-efficient design phase. Figure from Arena Solutions, a company that helps "you meet today’s prod-
uct launch challenges". . . 2
1.2 Abstraction Level vs Number of possible refined models . . . 2
2.1 The ForSyDe design flow taken from [6] . . . 7
2.2 Interconnection of processes from [11] . . . 9
2.3 ForSyDe process constructors mapSY, zipWithSY, delaySY, scandSY, mooreSY taken from [7] . . . 10
2.4 Concurrent processes communicating through signals and do- main interfaces, taken from [14] . . . 13
2.5 Loading ForSyDe-Shallow and a moore finite state machine, taken from [14] . . . 13
3.1 Preset Simulink blocks libraries and Commonly used blocks . 15 4.1 Equivalent of a process constructor in ForSyDe-Shallow and Simulink. . . 21
4.2 Equivalent of a process in ForSyDe-Shallow and Simulink. . 21
4.3 Declaration of a signal in ForSyDe-Shallow and Simulink. . . 21
5.1 ForSyDe library displayed in the Simulink Library Browser. . 24
5.2 mapSY process constructor . . . 25
5.3 mapSY Function block . . . 25
5.4 Results of the execution of zipWithSY . . . 26
5.5 Comparison of Haskell and Simulink mapxSY process con- structor . . . 27
5.6 delaySY and delaynSY preexisting Simulink’s blocks. . . 28
5.7 scanlSY and scanldSY comparison. . . 29
6.1 Simulink implemented blocks in need of workarounds. . . 37
LIST OF FIGURES
6.2 AudioFilter schematic. . . 39
6.3 Simulink’s AudioFilter. . . 40
6.4 Simulink’s test output. . . 41
6.5 ForSyDe’s test output. . . 41
6.6 Activity Monitor for evaluating the memory consumption of Simulink . . . 43
6.7 Simulink implementation for feedback loop with zero-delay . 45 6.8 Haskell causality problem from feedback loop with zero-delay 45 6.9 Simulink compiler error from feedback loop with zero-delay . 45 6.10 Simulink implementation for feedback loop with delay . . . . 46
6.11 Results of the simulation for the Haskell implementation . . . 46
6.12 Results of the simulation for the Simulink implementation . . 47
6.13 Floating point vs Fixed point . . . 48
6.14 Conversion block and its parameters . . . 48
A.1 mapSY process constructor . . . 56
A.2 mapSY Function block . . . 56
A.3 zipWithSY process constructor . . . 57
A.4 zipWithSY Function block . . . 57
A.5 zipWith3SY process constructor . . . 57
A.6 zipWith3SY Function block . . . 57
A.7 zipWith4SY process constructor . . . 58
A.8 zipWith4SY Function block . . . 58
A.9 mapxSY process constructor . . . 58
A.10 zipWithxSY process constructor . . . 58
A.11 delaySY and delaynSY preexisting Simulink’s blocks. . . 58
A.12 scanlSY process constructor . . . 59
A.13 scanlSY Function block . . . 59
A.14 scanlSY stateflow block . . . 59
A.15 scanl2SY process constructor . . . 59
A.16 scanl2SY Function block . . . 59
A.17 scanl2SY stateflow block . . . 60
A.18 scanl3SY process constructor . . . 60
A.19 scanl3SY Function block . . . 60
A.20 scanl3SY stateflow block . . . 60
A.21 scanldSY process constructor . . . 61
A.22 scanldSY Function block . . . 61
A.23 scanldSY stateflow block . . . 61
A.24 scanld2SY process constructor . . . 61
A.25 scanld2SY Function block . . . 62
A.26 scanld2SY stateflow block . . . 62
A.27 scanld3SY process constructor . . . 62
A.28 scanld3SY Function block . . . 62
A.29 scanld3SY stateflow block . . . 63
A.30 mooreSY process constructor . . . 63
A.31 mooreSY next state function block . . . 63
A.32 mooreSY output function block . . . 63
A.33 mooreSY stateflow block . . . 64
A.34 moore2SY process constructor . . . 64
A.35 moore2SY next state function block . . . 64
A.36 moore2SY output function block . . . 64
A.37 moore2SY stateflow block . . . 64
A.38 moore3SY process constructor . . . 65
A.39 moore3SY next state function block . . . 65
A.40 moore3SY output function block . . . 65
A.41 moore3SY stateflow block . . . 65
A.42 mealySY process constructor . . . 65
A.43 mealySY next state function block . . . 66
A.44 mealySY output function block . . . 66
A.45 mealySY stateflow block . . . 66
A.46 mealy2SY process constructor . . . 66
A.47 mealy2SY next state function block . . . 66
A.48 mealy2SY output function block . . . 67
A.49 mealy2SY stateflow block . . . 67
A.50 mealy3SY process constructor . . . 67
A.51 mealy3SY next state function block . . . 67
A.52 mealy3SY output function block . . . 67
A.53 mealy3SY stateflow block . . . 68
A.54 sourceSY process constructor . . . 68
A.55 sourceSY function block . . . 68
A.56 sourceSY stateflow block . . . 68
A.57 filterSY function block . . . 68
A.58 filterSY process constructor . . . 68
A.59 filterSY stateflow block . . . 69
A.60 fillSY stateflow block . . . 69
A.61 holdSY stateflow block . . . 70
A.62 whenSY stateflow block . . . 70
A.63 zipSY process constructor block . . . 70
LIST OF FIGURES
A.64 zipSY function block . . . 71
A.65 zip3SY process constructor block . . . 71
A.66 zip3SY function block . . . 71
A.67 zip4SY process constructor block . . . 71
A.68 zip4SY function block . . . 71
A.69 zip5SY process constructor block . . . 71
A.70 zip5SY function block . . . 72
A.71 zip6SY process constructor block . . . 72
A.72 zip6SY function block . . . 72
A.73 unzipSY process constructor block . . . 72
A.74 unzipSY function block . . . 72
A.75 unzip3SY process constructor block . . . 72
A.76 unzip3SY function block . . . 73
A.77 unzip4SY process constructor block . . . 73
A.78 unzip4SY function block . . . 73
A.79 unzip5SY process constructor block . . . 73
A.80 unzip5SY function block . . . 73
A.81 unzip6SY process constructor block . . . 73
A.82 unzip6SY function block . . . 74
A.83 fstSY process constructor block . . . 74
A.84 fstSY function block . . . 74
A.85 sndSY process constructor block . . . 74
A.86 sndSY function block . . . 74
A.87 AudioFilter ForSyDe-Shallow Haskell code . . . 75
A.88 FIR filter code . . . 76
6.1 FIR filter coefficients. . . 41 6.2 Time performance results. . . 42 6.3 Memory performance results. . . 43
Listings
6.1 Matlab script for performance measurement . . . 41 6.2 Haskell code for feedback loop application with zero-delay . . 44 6.3 Haskell code for feedback loop with delay . . . 44
Chapter 1 Introduction
This chapter describes the challenges and objectives of this thesis. Further- more, it contains an overview of the thesis structure.
1.1 Problem statement
ForSyDe is a methodology used to model and design Embedded systems, with a high focus on safety-critical embedded systems 1 created to solve several problems faced in the design phase.
Firstly, time-to-market is a fundamental parameter (as shown in Figure 1.1) in the design of both software and hardware that can be improved using method- ologies that increase the level of abstraction in the system design phase.
The designer should focus on functionality, while low-level implementations are left out at the early design stage. To verify that the architecture of the de- sign, the components, and the system-level properties meet a specific system’s requirements, a low-level analysis is required.
A high level of abstraction is necessary to define a specification model that translates a system design requirements into a model. A high level of abstrac- tion is necessary when a system design requirements must be translated into a model. Simulink’s offers a Specification Models for Requirements-based Testing. However, a high level of abstraction also means that there are many possible implementations and that the details of the model are missing. Re- ducing the abstraction level decreases the number of possible implementations by going into many details (as illustrated in Figure 1.2). In order to obtain a working implementation, the design process must reduce the number of poten- tial implementations down to one. A very abstract model usually describes the
1The main target of the publications so far have been SoC.
Figure 1.1: The necessity of a time-efficient design phase. Figure from Arena Solutions, a company that helps "you meet today’s product launch challenges".
Figure 1.2: Abstraction Level vs Number of possible refined models system in a simple way, which simplifies the verification phase, where the ful- filment of the requirements by the specification model is checked. The down- side of a high level of abstraction is that it makes the synthesis of the model
1.2. OBJECTIVES
difficult because a simple model has to become an implementation where many details are required in order to work correctly given the complexity of the em- bedded architectures. It should be clear now that this abstraction gap has to be addressed by some design methodology, I.E. ForSyDe.
The goal of a system design methodology is to allow the designer to model the system with a high level of abstraction and at the same time fill the gap with the actual synthesis of the model in order to obtain the wanted implementation.
The design methodology must support the incorporation of formal methods in order to achieve the mathematical reliability of a design. The verification phase must be taken into account from the very beginning, and the abstraction gap between specification and implementation must be bridged by formal re- finement techniques. The design transformation methods allow obtaining an implementation model from the system model, which is then synthesizable.
The ForSyDe methodology applies to many different scopes for the formal design of both software (C/ C++) and hardware (VHDL).
Translating and implementing this methodology with different programming languages makes it more attractive to other users. Each programming lan- guage, with its architecture, introduces more strengths to exploit. For example, Simulink has its own strengths, and it is part of the broader and more power- ful Matlab suite with which it works in symbiosis. The research group is now focusing on developing different versions of ForSyDe. This thesis presents Simulink’s version.
1.2 Objectives
The objectives of this thesis are:
• The study and understanding of the ForSyDe methodology and its Haskell implementation.
• Obtaining an in-depth insight into the Simulink simulation engine and its implicit MoCs.
• Developing Simulink components to map different MoCs of ForSyDe and their domain interfaces to Simulink.
• Evaluating the ForSyDe-Simulink library with a concrete application, i.e. an audio filter.
• Answering the question: "Can a Simulink implementation of ForSyDe- Shallow introduce the Mathworks environment advantages while con- serving the expressiveness and versatility of Haskell?"
• Documenting in a well-written report and defining future work.
1.3 Pre-study and method
The study of the Haskell functional language has been carried on by following the online tutorial "Learn You a Haskell" [1] and by solving the relevant ex- ercise from "H-99: Ninety-Nine Haskell Problems" [2], which I recommend to the reader approaching Haskell. After learning about the programming lan- guage, a proper study of the Haskell ForSyDe implementation has been done by studying the API documentation, which is open-source, and solving assign- ment number 3 of the course "ForSyDe PhD course" taught by Ingo Sanders at KTH.
In order to obtain a clear understanding of the Simulink simulation engine, the tutorial course "Simulink OnRamp" [3] (embedded in the Simulink en- vironment) and "MATLAB/SIMULINK Bible|Go From Zero to Hero!" [4]
(available on Udemy) have been followed.
To better understand Simulink’s implicit MoCs, I have researched previous studies about modelling flow using the Mathworks environment, such as the one described in the article "Integrating SysML with Simulink using Open- source Model Transformations" by Sindico, Di Natale, and Panci [5].
To develop the Simulink component a step by step "translation" has been per- formed. The evaluation of the ForSyDe-Simulink library has been carried out with the analysis of the pros and cons of the tools used and through the com- parison of the AudioFilter module from [6]. This document is the report of the work done, and it defines future work.
1.4 Overview
The report is divided into six chapters:
1. The current chapter is a brief introduction to the problem and its solu- tion; it defines the objectives and gives an overview of the entire docu- ment.
2. The second chapter introduces the theoretical background necessary and the literature study. In particular, it describes the ForSyDe methodol-
1.4. OVERVIEW
ogy in general, the Models of computation, and the ForSyDe-Shallow library.
3. The third chapter describes Simulink, its main strengths and its implicit model of computation.
4. The fourth chapter analyses the differences of the two parties involved in this thesis project: the programming languages Haskell and the pro- gramming tool Simulink. In particular, it gives details about their MoCs and compares them. A discussion around what is supported and the mapping plan is carried out.
5. The fifth chapter shows the implemented Simulink library and its archi- tecture and describes developing it.
6. The sixth chapter evaluates the results of this thesis project and com- pares the two implementations of ForSyDe with a concrete application model, the AudioFilter module from [6].
7. The seventh and last chapter summarizes the document and discusses future work.
Theoretical background
This chapter summarises the necessary theoretical backgrounds by describing the ForSyDe methodology, the MoCs, and the ForSyDe-Shallow library. The ForSyDe methodology is described in order to give an insight to the inexpe- rienced, and some basic models are shown to the reader. This section’s scope is not to provide complete documentation of ForSyDe, which can be found at [7, 8]. The information contained in this chapter introduces the reader to the methodology and the theoretical assumptions on which it is based, whereas more detailed explanations can be found in [7, 8, 6, 9].
2.1 Formal System Design Methodology
ForSyDe is an acronym for Formal System Design. As pointed out by its name, it is a system design methodology that has been developed during under- going research funded by the Royal Institute of Technology. As stated before, its main objective is to allow a higher level of abstraction in system designing and to bridge the previously described abstraction gap (illustrated in Figure 1.2) thanks to transformational design refinement.
The ultimate research goal is to make ForSyDe able to support the correct- by-construction development of embedded systems. The work done in this thesis is based on the ForSyDe-Shallow library, which, as the name suggests, captures the main modelling concepts of ForSyDe. The systems treated are synchronous systems that are defined as systems "in which transfer of infor- mation between combinational blocks is performed in synchrony with a global clock signal." [10].
2.1. FORMAL SYSTEM DESIGN METHODOLOGY
2.1.1 The ForSyDe design flow
Figure 2.1: The ForSyDe design flow taken from [6]
The ForSyDe design process begins at a high abstraction level with the specification model’s writing (as seen in Figure 2.1). The characteristics of the specification model are its formal and functional characters. The model is formal in syntax (form) and semantics (meaning) in order to be unambiguous and functional because the output is obtained through a mathematical function of the inputs. The mathematical nature of the specification model is based on computation models, which are discussed in Section 2.2.
The following step is the synthesis process, which starts with the development of the implementation model. The implementation model is a more detailed version of the specification model obtained with transformational design re- finement. As shown in Figure 2.1, the specification model and the implemen- tation model belong to the functional domain and share the same verification process. The synthesis process continues with the implementation mapping, which moves the model into the specific architecture. This part of the synthe- sis is the more complex and is left as part of the future work to be done for what it concerns the Simulink version of ForSyDe. At the time of this thesis, the implementation mapping is managed by the ForSyDe-Deep library. In this
phase, the domain is not functional anymore, and it is called the implementa- tion domain.
The design has to be described with languages that can consider the specific architecture on which the system is implemented. The languages used for the synthesis process are synthesizable VHDL for the SoC and C for programs being executed on a micro-controller. The transformational design refinement adds the necessary information about the synthesis process’s implementation when mapping the model on the physical system.
2.2 Signal, process, and process construc- tors
As described in subsection 2.1.1, the first step of the design flow is the defini- tion of a specification model; in this subsection, the process is unpacked and analysed. The core of a specification model is made of signals and processes.
The definition of signals and processes considered for this thesis has been de- fined by Lee and Sangiovanni-Vincentelli [11]. A signal is defined as a set of events:
S = {e0, e1, e2, e3, ...}
The events have a tag t ∈ T and a value v ∈ V , e(t, v). The tags of an event can be used to express different things such as:
• physical time T = R
• discrete time (T is a set ordered and discrete)
• precedence (T is a set partially ordered and discrete).
For some MoCs, it is possible to indicate the absence of an event with the symbol "⊥". This is useful when treating data streams with different frequen- cies. Here is an example of how the bottom symbol is used:
S = {⊥, e0, ⊥, e1, e2, ⊥, ⊥, e3, ...}
Haskell and Simulink interpret signals as infinite series of values of which only the finite amount needed in case of finite signals is defined; more on this in chapter 3.
Processes handle signals. A process P maps x input signals ~i1, ..., ~ixinto y output signals ~o1, ..., ~oy using a certain function:
2.2. SIGNAL, PROCESS, AND PROCESS CONSTRUCTORS
P (~i1, ..., ~ix) = ~o1, ..., ~oy
The combination of processes that constitute a network communicating via signals is a model of the system to represent (an example is shown in Figure 2.2), it can be synthesized as:
Q( ~s1, ~s6) = ( ~s3, ~s4, ~s7, ~s8) where
( ~s3, ~s4, ~s5) = P1( ~s1, ~s2) ( ~s7, ~s8, ~s2) = P2( ~s5, ~s6)
Figure 2.2: Interconnection of processes from [11]
Figure 2.2 also shows how an unambiguous model of computation must be used in order to make any assumption on the model. With a synchronous model of computation (more on this in the next section), we consider the prop- agation time to be null and the processes to work under the perfect synchrony hypothesis [12], resulting in immediate values produced at the output as the input arrives. This avoids that the model becomes non-deterministic and the
well-known race condition.
The role of the ForSyDe library is to create processes using its own process constructors. The functions that we might want to apply to a signal are count- less, and the process constructor allows us to "cleanly separate the computation part of a process from the synchronization and communication part" [7]. A constructor is fundamentally a function that outputs a process given signals as parameters and a function that does not have an internal state. Some of the fundamental process constructors from the ForSyDe-Shallow library are shown in Figure 2.3. The names of these process constructors (e.g. mapSY, zipWithSY) recall their corresponding Haskell functions (e.g. map, zipWith).
Figure 2.3: ForSyDe process constructors mapSY, zipWithSY, delaySY, scan- dSY, mooreSY taken from [7]
"SY" at the end of the names stands for synchronous, which is the compu- tational model these process constructors are based on. The mapSY process constructor (Figure 2.3a) applies a combinatorial function on the input signal’s values. The zipWithSY process constructor (Figure 2.3b) gets two signals as input and returns one signal at the output calculated by applying a combinato- rial function to each input pair of values. Similar to mapSY and zipWithSY, there is zipWithNSY with the only difference that zipWithNSY allows any number of input signals which is fixed for mapSY (1) and zipWithSY (2). The process constructor delaySY The delaySY process constructor (Figure 2.3c) delays a signal i by k clock cycles. The scandSY process constructor (Figure 2.3c) establishes a process modelling a shift register. The mooreSY process
2.3. MODELS OF COMPUTATIONS
constructor (Figure 2.3d) creates a process modelling the moore FSM.
2.3 Models of computations
A fundamental concept of the design phase is the model of computation used and the theoretical mathematical assumptions that are implicit with it. ForSyDe mainly focuses on synchronous systems. Therefore this thesis focuses pri- marily on Synchronous MoC and partially on Synchronous Dataflow MoC, Continuous Time MoC. An unambiguous model of computation is needed be- cause modern embedded systems are, most of the times, heterogeneous, which means that they are built with components with very different characteristics.
A unique way of interfacing them is necessary to obtain the expected results and to avoid unwanted behaviour.
A model of computation can be seen as the set of rules that manages the way results are computed. The systems that ForSyDe permits to model are usually made of many concurrent processes, which means that the computation for different processes happens at the same time. A common mistake is to think of programming languages as computational models which might support dif- ferent computational models implicit in the language structure. In chapter 3, the models of computation related to Haskell and Simulink are compared.
In order to describe and compare the models of computation, this thesis will use the concept introduced by Lee and Sangiovanni-Vincentelli [11] in their tagged-signal model. This model describes systems as a set of concurrent processes that communicate through signals. Signals have tags and values, as previously described in Chapter 2. The difference between a discrete event model and a continuous-time model is that in the former there are a finite num- ber of tags between any two tags while in the latter is not possible to order all the events in a signal from their tags.
Here the models of computation of our interest are described in more details.
• Synchronous model. This model of computation is of central impor- tance in ForSyDe, where the same set of tags is used for every signal to order the events without caring about time. The synchrony hypothesis from [12] states that the computation of the outputs takes no observ- able time, and it is instantaneous, resulting in input and output have the same corresponding tag. The computation is managed by a global clock that allows the use of formal methods and simplifies the communication modelling. In hardware, the synchrony hypothesis is obtained with the help of clocked registers. The abstract circuits can be implemented as-
suming that the combinational blocks are high-speed and that there are not zero-delay feedback loops.
• Synchronous data flow model. This model of computation is a spe- cific case of the synchronous one where the synchrony hypothesis is still assumed to be valid, but the input and output structure change into dataflow. The article [13] defines dataflow process networks as pro- cesses that consist of repeated "firings". The size of each "firing" can change as defined in the rules of dataflow. A challenge of the dataflow process is to find a schedule that allows implementing a network of pro- cesses working together efficiently. The Synchronous dataflow (SDF) model adds some conditions on the flow of data, which results in a fixed amount of consumed and produced bit for each bit-blocks.
• Continuous-time model Continuous time MoCs are mainly needed for dealing with physical systems modelling (physical quantities like tem- perature, pressure produce analogue signals). In CT, the variable time is viewed as a continuous variable, and between any two points on the timeline, there is an infinite number of other points. Mathematical func- tions like sine and cosine produce continuous signals. Discrete-time models have the natural numbers’ density, while continuous-time mod- els have the real numbers’ density. In embedded systems, the CT model is used to model the physical quantities related to a cyber-physical sys- tem.
From the description above, it is clear that there is no universally better MoC and that each MoC comes with its strengths and weaknesses. When trying to combine more MoCs, the result is low-level models that are non- functional.
This thesis project’s focus will be the synchronous MoC because it allows a straightforward mathematical formalism and the feature of time abstraction.
2.4 ForSyDe-Shallow
This thesis project focuses on ForSyDe-Shallow, the first and most enduring library of ForSyDe, written in the functional programming language Haskell, which has been developed to represent the ForSyDe modelling concepts. Its goal is to perform "modelling, simulation and early design validation of het- erogeneous embedded and cyber-physical systems, and builds upon the con- cepts of models of computation (MoC) combined with Haskell’s function pu-
2.4. FORSYDE-SHALLOW
rity and higher-order functions." [14]. Within ForSyDe-Shallow, systems are modelled as networks of concurrent processes ruled by their hierarchy. All
Figure 2.4: Concurrent processes communicating through signals and domain interfaces, taken from [14]
of the concurrent processes work according to the chosen MoC. As it can be seen in Figure 3.1, communication between processes is only possible using signals. Domain interfaces are necessary when two processes with different MoCs must communicate or the resulting math could be wrong because of synchronicity, data dimension, data type, process constructors requirements.
Figure 2.5: Loading ForSyDe-Shallow and a moore finite state machine, taken from [14]
For a quick start with this library visit [14], it explains how to easily ac- quire the ForSyDe-Shallow libraries, for example, using any Haskell package manager to get it from HackageDB. Once ForSyDe-Shallow is installed, it can
be loaded from the Haskell platform and its functions used. The first line of Figure 2.5 shows how the library is loaded, and the rest is the implementa- tion of a moore finite state machine given as an example. On the Github of ForSyDe, there is also a repository of examples where many systems designed with ForSyDe can be accessed and tested to understand the methodology’s functioning.
Chapter 3
Simulink environment
In this chapter, the Simulink modelling software is introduced, its main char- acteristics analyzed together with the implicit models of computation that it supports. Simulink is a graphical programming tool developed by Mathworks and based on MATLAB that is widely used for formal modelling (for both soft- ware and hardware), simulating and analysing dynamic systems. Simulink’s model is used to simulate, verify and synthetize code (more on this in 6.4).
The simple interface is made of preset blocks with the most used functions, but the user can easily customize blocks to model and obtain numerous sys- tems with different applications. It is well integrated with MATLAB, which can control or be controlled by it. The power of Simulink arises from it’s capa- bility of letting one observe results from systems which one wants to research.
Figure 3.1 shows the categories of preset blocks and the most commonly used ones that give a hint of Simulink’s primary focus.
Figure 3.1: Preset Simulink blocks libraries and Commonly used blocks
3.1 Simulink main strengths
Simulink’s main strengths are that it comes with a broad set of systems and blocks that are recyclable, and it is built on top of the Matlab environment.
One of its main strengths is that it can break down complex system designs in many functional blocks that are simple to handle (program, verify, simulate).
The access to the Matlab workspace completes it with more functionalities and an additional library with mathematical, logic control, and signal processing functions. This feature makes Simulink very well known and used in control theory and digital processing for designs that belong to different domains and are model-based.
Another strength of Simulink is its encapsulation. Its subsystems communi- cate through ports connected with signal wires and are well insulated from one another. Simulink allows using the standard types (integers, reals, booleans) or creating the so-called composite types that the user defines.
Last but not least, it allows to perform the verification of a system at an early stage of the system design, thus potentially saving much work in the debugging stage needed to meet the requirements.
3.2 Simulink models of computations
Simulink’s MoCs are not per se explicit, as for other programming languages/- tools, but they can be found out from the MathWorks documentation [15]. As stated before, Simulink allows modelling and simulation of dynamic systems, and it does that using a so-called discrete model of computation. Systems sim- ulated in Simulink consists of blocks that perform like mealy machines, which transforms an input function into an output function. Depending on the input function domain, each block can be fed a discrete-time signal or a continuous- time signal.
In order to deal with the theoretical infinite speed of sampling required by continuous-time MoCs, it uses a solver that executes at the base rate. Each block has a sample time greater than zero1that is a fraction of the base rate but allows to simulate the continuous behaviour. The outputs are evaluated at each step for every block, given the concurrent inputs and the current state.
At the end of the computation, the current block state is updated as a mealy machine. This creates a dependency between blocks, in which outputs are computed instantaneously based on the inputs, which can result in the fixed-
1a sample time equal to zero is the ideal case of continuous time
3.2. SIMULINK MODELS OF COMPUTATIONS
point problem and can cause inconsistency. The computation order rules must be clear to avoid that any block, for which the output is directly dependent on its input, is executed until the blocks driving its inputs are executed. The exe- cution of a block is the process that evaluates its outputs and updates the block state.
Simulink’s ForSyDe vs Haskell’s ForSyDe
4.1 Comparison of computational models be- tween Simulink and Haskell
In the attempt to develop the Simulink version of ForSyDe as corresponding as possible, it has been necessary to consider how the two environments deal with the concept of time and how the computation is performed.
4.1.1 Simulink discrete vs Haskell synchronous
Analysing the behaviour and the mathematical models behind Simulink’s dis- crete model of computation and Haskell’s synchronous model of computation, it can be stated that they are equivalent. The synchronous MoC follows the as- sumption that if there is an input at a certain k in time, then there must be an output at k, where k is the equivalent of the "discrete time", and it follows the mathematical equation:
out(k) = f (in(k))
From Simulink’s perspective, the discrete MoC is seen as a set of discrete sam- ples with a function that produces one output corresponding to the input. In general, in Matlab and, therefore in Simulink, users are more control-oriented and come to expect discrete equations of the form,
x(k + 1) = f (x(k))
4.2. SUPPORTED FEATURES AND MAPPING OUTLINE
The concept of time is somehow hidden, but the output is still evaluated as a result of the mathematical equation:
out(k) = f (in(k))
The difference in the terminology comes from the different approach and back- ground of researchers and using one or the other tool. In the Haskell commu- nity, the concept of time is of primary importance, while in Simulink, the focus is more on how the sampling is performed. As it can be seen, discrete and syn- chronous are basically the same MoC with few differences that emerge from the differences between the functional programming language and the mod- elling software.
4.1.2 Simulink’s continuous vs Haskell’s continuous
Haskell is a purely functional programming language that uses lazy evalua- tion. The latter is a method to evaluate results that defer the result’s evaluation until they are needed by other computations. This way, an infinite sequence can be defined without creating a loop, as it would happen with languages us- ing strict evaluation. Matlab and therefore Simulink, on the other hand, use strict evaluation (with the copy on write resource-management technique1) to approximate continuous functions with numerical methods that convert dis- crete into continuous, such as interpolation. The advantages that come from lazy evaluation are related to performance. For example, when dealing with higher-order functions, where the variables are not evaluated every time, they are declared only when their values are required. Strict evaluation is preferred when the memory cost must be predictable.
4.2 Supported features and mapping outline
The user using the Simulink library will be able to simulate systems design similarly to ForSyDe-Shallow since the concepts introduced before on which ForSyDe-Shallow is based can be mapped into Simulink. Process construc- tor, process, and signal are mapped into Simulink with the corresponding Simulink’s versions. A description of the supported features and the mapping plan is done below.
1resources which are copied have their actual memory storage allocated only when their content is changed
4.2.1 What is supported
Simulink supports the synchronous MoC and the continuous MoC with which ForSyDe-Shallow operates, so a step-by-step mapping of the library is possi- ble. The Simulink library objective is to allow to simulate the same systems that can be simulated in ForSyDe-Shallow. From the features that it provides to the user perspective (independently of the MoC), the Simulink library allows to:
1. Simulate
2. Implement a library to generate the synthesizable code (C or synthesiz- able VHDL)
3. Use for analysis methods (Example PID design, latency analysis).
This library introduces the possibility to implement an additional library to create synthesizable code (C or synthesizable VHDL). From the user perspec- tive, this is a huge step ahead to obtain a correct-by-construction design pro- cess for embedded systems that moves design to a higher level of abstraction.
With ForSyDe-Shallow, only the simulation is currently supported. The im- plementation of the additional library to create synthesizable code is out of this thesis’s scope but is part of future work.
4.2.2 Mapping plan
The mapping of ForSyDe-Shallow into the ForSyDe Simulink library must consider every aspect that can and cannot be "translated" (for example, the absent values explained below). From the modelling perspective, a one-to-one mapping of the fundamental blocks is performed considering the Simulink’s versions corresponding to the basic blocks of ForSyDe-Shallow, which are process constructors, processes, and signals. The core of ForSyDe (Shallow library level) relies on signals, processes, and process constructors.
The core of Simulink relies on signals, blocks, and blocks using function caller.
1. SY Process Constructors in ForSyDe-Shallow are mapped into Simulink blocks that take n functions as arguments and returns a process with x input signals and y output signals. In Figure 4.1, mapSY is the ForSyDe- Shallow process constructor used as an example of a combinational pro- cess. Delay and Sequential processes are mapped similarly.
4.2. SUPPORTED FEATURES AND MAPPING OUTLINE
2. SY Processes in ForSyDe-Shallow are mapped into Simulink Blocks, as shown in 4.2. A process is built by mean of a process constructor that manages the interface and the MoC of the process. A process has m in- put signals as arguments and produces n output signals. Both ForSyDe- Shallow and ForSyDe Simulink processes are deterministic.
3. SY Signals in ForSyDe-Shallow are mapped into Simulink Signals (in Figure 4.3, it can be seen how to declare a simple signal in both envi- ronments). The signal declaration on the right is made in Matlab, which is used to allocate data to use in Simulink.
Figure 4.1: Equivalent of a process constructor in ForSyDe-Shallow and Simulink.
Figure 4.2: Equivalent of a process in ForSyDe-Shallow and Simulink.
Figure 4.3: Declaration of a signal in ForSyDe-Shallow and Simulink.
ForSyDe is required to allow working with more than one clock since this requirement is frequent in embedded systems. In order to do so, it has to take
care of the so-called "absent values", which are the events that are not syn- chronized due to a difference in frequency between 2 or more clocks. The value "⊥" is used to denote an absent value in Haskell’s ForSyDe-Shallow.
In ForSyDe-Shallow, an absent value has a univocal meaning: "Absence of computation here". The corresponding concept is managed by "missing data"
in Matlab, which has more interpretations. In [16], it is clear that the interpre- tation using the value "NaN" (Not a Number) is the most similar denotation of missing data, compared to the absent value of ForSyDe-Shallow. The differ- ence is that in Simulink, the computation will be performed but will return a
"NaN" value instead of directly skipping. The different approaches recall the difference between the lazy and the strict evaluation of Haskell and Simulink.
Chapter 5
Simulink ForSyDe library
5.1 Library architecture
The library is distributed in the form of a Simulink custom library (.SLX file), which can be created inside Simulink and added to the Simulink Library Browser. A user that wants to import the custom ForSyDe Simulink library in the Simulink Library Browser has to download and save the library file inside his Matlab path and execute the following command in the Matlab terminal:
"set_param(gcs, ’EnableLBRepository’ , ’on’ );". The result is that we can now browse the library, as shown in Figure 5.1. Each block/subsystem is the equivalent implementation of a ForSyDe process constructor. In the following section, a brief explanation of each block is given.
5.2 How it was implemented
To implement the Simulink library, each process constructor has been "trans- lated" considering the inputs required and the output generated. In the process, the differences between Haskell and Simulink have emerged, and in Chapter 6, a comparison of what can and cannot be done in each environment is shown.
The model of computation considered is the synchronous MoC that is the im- plicit way Simulink executes blocks.
The process constructors have been translated using a step-by-step translation with the required adjustments discussed in Chapter 6. Different process con- structors need different approaches; for example, some of the blocks in the ForSyDe custom library are preexisting Simulink’s blocks, others are Sub- systems based on a block called "function caller", which executes a function defined elsewhere.
Figure 5.1: ForSyDe library displayed in the Simulink Library Browser.
The blocks regarding finite state machines make use of Stateflow (described here [17]), an additional Simulink’s tool used for modelling systems with finite state machines and flow charts. In the following subsections, there is a brief documentation of each block described similarly to the ForSyDe constructors in the API documentation [18]. The blocks layout and code for each block is found in Appendix A.
5.2.1 Combinational process constructors
The combinational process constructors apply to processes without internal states.
• mapSY
The process constructor mapSY builds a process with one input sig- nal and one output signal. The combinational function is defined in the mapSY function block. The mapSY function block has a default function that sums the input signal with 1, equivalently to the ForSyDe- Shallow Haskell command: mapSY (+1) $ inputSignal. The default function has to be changed by the user when required (see Figure 5.3).
5.2. HOW IT WAS IMPLEMENTED
Figure 5.2: mapSY process constructor
Figure 5.3: mapSY Function block
• zipWithSY
The process constructor zipWithSY builds a process with two input sig- nals and one output signal. The combinational function is defined in the zipWithSY function block. The zipWithSY function block has a default function that sums the two input signals, equivalently to the ForSyDe-Shallow Haskell command: zipWithSY (+) inputSignal1 in- putSignal2. Fig 5.4 shows the results of the equivalent implementa- tion of the ForSyDe-Shallow Haskell command: zipWithSY (+) (signal [1,2,3,4]) (signal[11,12,13,14,15,16,17]).
• zipWith3SY
The process constructor zipWith3SY builds a process with three input signals and one output signal. The combinational function is defined in the zipWith3SY function block. The zipWith3SY function block has a default function that sums the three input signals, equivalently to
Figure 5.4: Results of the execution of zipWithSY
the ForSyDe-Shallow Haskell command: zipWith3SY (\x -> \y -> \z ->
x+y+z) inputSignal1 inputSignal2 inputSignal3.
• zipWith4SY
The process constructor zipWith4SY builds a process with four input signals and one output signal. The combinational function is defined in the zipWith4SY function block. The zipWith4SY function block has a default function that sums the four input signals, equivalently to the ForSyDe-Shallow Haskell command: zipWith4SY (\w -> \x -> \y -> \z -> w+x+y+z) inputSignal1 inputSignal2 inputSignal3 inputSignal4.
• mapxSY
The process constructor mapxSY builds a process network that maps a function defined inside the block (a sum with 1 is the default func- tion) onto all signals in a mux of signals. The default function has to be changed by the user when required directly from inside the block (the library link must be necessarily removed for this operation). The input must be a mux of signals which produces the output being a mux of sig- nals. In Figure 5.5, a comparison of the Haskell and Simulink results is shown. Differently from mapSY of Figure 5.2, mapxSY does not have a function caller because that would require a signal as input, but this block needs to have a vector as input.
5.2. HOW IT WAS IMPLEMENTED
Figure 5.5: Comparison of Haskell and Simulink mapxSY process constructor
• zipWithxSY
The process constructor zipWithxSY derives from zipWithSY, but takes a vector of signals as input. Similarly to mapxSY, it does not make use of the function caller because of the vector at the input and the output.
The default function is a sum of 3 signals. When the default function has to be changed, both the number of inputs in the demux and the sum block must be rearranged accordingly. A dynamic change of the input number is not possible because the sum block does not allow to make the input ports variable, while the demux block does.
5.2.2 Sequential process constructors
The sequential process constructors apply to processes with a state. The initial state is given as an input to the constructor.
• delaySY
The process constructor delaySY has two inputs and one output. As the name suggests, it delays the input signal of one cycle by adding the initial value inputted at the beginning of the output signal. The first event of the output signal does not have a corresponding at the input, but it is necessary for feedback loop applications. This process constructor and delaynSY are the only ones that were a preexisting block in Simulink (see Figure A.11).
• delaynSY
The process constructor delaynSY behaves like delaySY but introduces an additional input for the delay length.
Figure 5.6: delaySY and delaynSY preexisting Simulink’s blocks.
• scanlSY
The process constructor scanlSY is the first constructor that consists of a finite state machine that does not have an output decoder. This cat- egory of process constructors was programmed using Stateflow. This block has two inputs: s1 which is the input signal and inState which is the finite state machine’s initial value.
This process constructor evaluates the output through the function scanl- SYOutf with the current state and the signal current event as arguments, making it a mealy finite state machine. The scanlSYOutf function block has a default function that sums the two arguments (it can be effort- lessly changed outside of the Stateflow environment), equivalently to the ForSyDe-Shallow Haskell command: scanlSY (+) initialState in- putSignal.
• scanl2SY
The process constructor scanl2SY is the same as scanlSY but accepts two input signals. The scanl2SYOutf function block has a default func- tion that sums the three arguments (it can be effortlessly changed outside of the Stateflow environment), equivalently to the ForSyDe-Shallow Haskell command: scanl2SY (\x -> \y -> \z -> x+y+z) initialState inputSignal1 inputSignal2.
• scanl3SY
The process constructor scanl3SY is the same as scanlSY but accepts three input signals. The scanl3SYOutf function block has a default func- tion that sums the four arguments (it can be effortlessly adjusted outside of the Stateflow environment), equivalently to the ForSyDe-Shallow Haskell commands: scanl3SY (\w -> \x -> \y -> \z -> w+x+y+z) initialState in- putSignal1 inputSignal2 inputSignal3.
• scanldSY
The process constructor scanldSY is a finite state machine that does not
5.2. HOW IT WAS IMPLEMENTED
have an output decoder. This block has two inputs: s1, which is the input signal and inState, which is the finite state machine’s initial value.
This process constructor’s output is the current state making it a moore finite state machine. The next state is evaluated through the function scanldSYOutf with the current state and the signal current event as ar- guments. The scanldSYOutf function block has a default function that sums the two arguments (it can be effortlessly changed outside of the Stateflow environment), equivalently to the ForSyDe-Shallow Haskell command: scanldSY (+) initialState inputSignal. With respect to the similar scanlSY process constructor, the same signals produce the same output delayed by one clock cycle (as seen in Figure 5.7).
Figure 5.7: scanlSY and scanldSY comparison.
• scanld2SY
The process constructor scanld2SY is the same as scanldSY but accepts two input signals. This process constructor’s output is the current state making it a moore finite state machine. The scanld2SYOutf function block has a default function that sums the three arguments to calculate the next value (it can be effortlessly changed outside of the Stateflow environment), equivalently to the ForSyDe-Shallow Haskell command:
scanld2SY (\x -> \y -> \z -> x+y+z) initialState inputSignal1 inputSig- nal2.
• scanld3SY
The process constructor scanld3SY is the same as scanldSY but accepts three input signals. The scanld3SYOutf function block has a default function that sums the four arguments to calculate the next value (it can be effortlessly changed outside of the Stateflow environment), equiva- lently to the ForSyDe-Shallow Haskell command: scanld3SY (\w ->\x -
> \y -> \z -> w+x+y+z) initialState inputSignal1 inputSignal2 inputSig- nal3.
• mooreSY
The process constructor mooreSY, as the name suggests, it is used to model finite state machines where the output only depends on the cur- rent state. As seen before, scanldSY behaves similarly, so mooreSY is based on it. The block has two inputs which are the signal and the initial state.
The two function blocks contain the functions to compute the next state
and the output. The next state is evaluated through the function mooreSYNextStatef with the current state and the signal current event as arguments. The out-
put is evaluated through the function mooreSYOutf with the current state as an argument. The mooreSYNextStatef function block has a default function that sums the two arguments to calculate the next value. In constrast, the mooreSYOutf function block has a default function that doubles the current state (it can be effortlessly changed outside of the Stateflow environment), equivalently to the ForSyDe-Shallow Haskell command: mooreSY (+) (*2) initialState inputSignal.
• moore2SY
The process constructor moore2SY is equivalent to mooreSY, but it ac- cepts two input signals. The block has three inputs which are the two signals and the initial state.
The two function blocks contain the functions to compute the next state
and the output. The next state is evaluated through the function moore2SYNextStatef with the current state and the signals current event as arguments of the
function. The output is evaluated through the function moore2SYOutf with the current state as an argument. The moore2SYNextStatef func- tion block has a default function that sums the three arguments to calcu- late the next value while the moore2SYOutf function block has a default function that doubles the current state (it can be effortlessly changed outside of the Stateflow environment), equivalently to the ForSyDe- Shallow Haskell command: moore2SY (\x -> \y -> \z -> x+y+z) (*2) initialState inputSignal1 inputSignal2.
• moore3SY
The process constructor moore3SY is equivalent to mooreSY, but it ac- cepts three input signals. The block has four inputs which are the three signals and the initial state.
5.2. HOW IT WAS IMPLEMENTED
The two function blocks contain the functions to compute the next state
and the output. The next state is assessed through the function moore3SYNextStatef with the current state and the signals current event as arguments of the
function. The output is evaluated through the function moore3SYOutf with the current state as an argument. The moore3SYNextStatef func- tion block has a default function that sums the four arguments to calcu- late the next value. In comparison, the moore3SYOutf function block has a default function that doubles the current state (it can be effort- lessly changed outside of the Stateflow environment), equivalently to the ForSyDe-Shallow Haskell command: moore3SY (\w ->\x -> \y -> \z -> w+x+y+z) (*2) initialState inputSignal1 inputSignal2 inputSignal3.
• mealySY
The process constructor mealySY, as the name suggests, it is used to model finite state machines where the output only depends on the cur- rent state and the input. As seen before, scanlSY behaves similarly so mealySY is based on it. The block has two inputs which are the signal and the initial state.
The two function blocks contain the functions to compute the next state
and the output. The next state is evaluated through the function mealySYNextStatef with the current state and the signal current event as arguments. The
output is evaluated through the function mealySYOutf with the current state and the signal current event as arguments. The mealySYNextStatef function block has a default function that sums the two arguments to cal- culate the next value while the mealySYOutf function block has a default function that multiplies the two arguments (it can be effortlessly changed outside of the Stateflow environment), equivalently to the ForSyDe- Shallow Haskell command: mealySY (+) (*) initialState inputSignal1.
Differently from mooreSY, the output of the process constructor mealySY depends also on the input signal.
• mealy2SY
The process constructor mealy2SY is equivalent to mealySY, but it ac- cepts two input signals. The block has three inputs which are the two signals and the initial state.
The two function blocks contain the functions to compute the next state and the output. The next state and the output are evaluated through the functions mealy2SYNextStatef and mealy2SYOutf that both have the current state and the signals current event as arguments of the func- tion. The mealy2SYNextStatef function block has a default function that
sums the three arguments to calculate the next value while the mealy2SYOutf function block has a default function that multiplies the three arguments (both can be effortlessly changed outside of the Stateflow environment), equivalently to the ForSyDe-Shallow Haskell command: mealy2SY (\x -> \y -> \z -> x+y+z) (\x -> \y -> \z -> x*y*z) initialState inputSignal1 inputSignal2.
• mealy3SY
The process constructor mealy3SY is equivalent to mealySY, but it ac- cepts three input signals. The block has four inputs which are the three signals and the initial state.
The two function blocks contain the functions to compute the next state and the output. The next state and the output are evaluated through the functions mealy3SYNextStatef and mealy3SYOutf that both have the current state and the signals current event as arguments of the func- tion. The mealy3SYNextStatef function block has a default function that sums the four arguments to calculate the next value while the mealy3SYOutf function block has a default function that multiplies the four arguments (both can be effortlessly changed outside of the Stateflow environment), equivalently to the ForSyDe-Shallow Haskell command: mealy3SY (\w ->\x -> \y -> \z -> w+x+y+z) (\w ->\x -> \y -> \z -> w*x*y*z) initial- State inputSignal1 inputSignal2 inputSignal3.
• sourceSY
The process constructor sourceSY takes an initial value and generates an infinite signal by recursively applying the function defined in the func- tion block. The default function adds 1 to the current state, equivalently to the ForSyDe-Shallow Haskell command: sourceSY (+1) 0
• filterSY
The process constructor filterSY introduces a new concept which is ab- sent values. This process filters elements that do not respect a particular predicate defined in the function block. The default function filters ele- ment which is less or equal to 3, equivalently to the command: filterSY (>3) inputSignal.
• fillSY
The process constructor fillSY looks for absent values in a signal and replace them with a given value. In Haskell, it changes the data type of the signal, which is not of the type AbstExt anymore. In Simulink, there is no easy way to manage absent values. This block interprets as absent
5.2. HOW IT WAS IMPLEMENTED
values those events with a specific value (-1 by default). The value to replace the absent values is given as an input of the block, equivalently to fillSY chosenValue inputSignal.
• holdSY
The process constructor holdSY looks for absent values in a signal and replace them with the preceding value. In Haskell, it changes the data type of the signal which is not of the type AbstExt anymore. In Simulink, there is no easy way to manage absent values and this block interprets as absent values those events with a specific value (-1 by default). The value to replace the absent values, in case a preceding value is not avail- able, is given as an input of the block, equivalently to holdSY default- Value inputSignal.
• whenSY
The process constructor whenSY looks for absent values in a signal and synchronize a second signal replacing the values in the latter with absent values for events with absent values in the first. In Simulink, there is no easy way to manage absent values and this block interprets as absent values those events with a specific value (-1 by default), equivalently to sig ‘whenSY‘ clk.
• zipSY
The process constructor zipSY takes two input signals and "zips" them into a matrix having signals in each raw. In Haskell, this process com- bines the inputs in a signal of tuples. The Simulink block’s output ma- trix can be handled as the Haskell ForSyDe’s tuples, equivalently to the command: zipSY inputSignal1 inputSignal2.
• zip3SY
The process constructor zip3SY takes three input signals and works like zipSY. The Simulink block’s output matrix can be handled as the Haskell ForSyDe’s tuples, equivalently to the command: zip3SY inputSignal1 inputSignal2 inputSignal3.
• zip4SY
The process constructor zip4SY takes four input signals and works like zipSY. The Simulink block’s output matrix can be handled as the Haskell ForSyDe’s tuples, equivalently to the command: zip4SY inputSignal1 inputSignal2 inputSignal3 inputSignal4.
• zip5SY
The process constructor zip5SY takes five input signals and works like zipSY. The Simulink block’s output matrix can be handled as the Haskell ForSyDe’s tuples, equivalently to the command: zip5SY inputSignal1 inputSignal2 inputSignal3 inputSignal4 inputSignal5.
• zip6SY
The process constructor zip6SY takes six input signals and works like zipSY. The Simulink block’s output matrix can be handled as the Haskell ForSyDe’s tuples, equivalently to the command: zip6SY inputSignal1 inputSignal2 inputSignal3 inputSignal4 inputSignal5 inputSignal6.
• unzipSY
The process unzipSY, as the name suggests, does the opposite of zipSY, returning two signals from an input matrix. The Simulink block is equiv- alent to the command: unzipSY inputSignalofTuples.
• unzip3SY
The process unzip3SY, as the name suggests, does the opposite of zip3SY, returning three signals from an input matrix. The Simulink block is equivalent to the command: unzip3SY inputSignalofTuples.
• unzip4SY
The process unzip4SY, as the name suggests, does the opposite of zip4SY, returning four signals from an input matrix. The Simulink block is equivalent to the command: unzip4SY inputSignalofTuples.
• unzip5SY
The process unzip5SY, as the name suggests, does the opposite of zip3SY, returning five signals from an input matrix. The Simulink block is equiv- alent to the command: unzip5SY inputSignalofTuples.
• unzip6SY
The process unzip6SY, as the name suggests, does the opposite of zip3SY, returning six signals from an input matrix. The Simulink block is equiv- alent to the command: unzip6SY inputSignalofTuples.
• fstSY
The process constructor fstSY selects the first signal from a matrix with more signals, equivalently to the command: fstSY inputSignalofTuples.
5.2. HOW IT WAS IMPLEMENTED
• sndSY
The process constructor fstSY selects the second signal from a matrix with more signals, equivalently to the command: sndSY inputSignalof- Tuples.
