0.1 Introduction The motivation for this work was to build an accurate representation for SpecEdit in the framework of MORPHEUS spatial design. SpecEdit tool is built around a formalism called ADeVa[2] from Alcatel Lucent. Its aim is to allow to specify and verify complex state machines from simple composition of processes interacting with the environment. This formalism has been represented as a set of Smalltalk 80 classes that is been targeted from an XML output of SpecEdit. As a practical result it is now possible to generate CDFG representing the SpecEdit specification.The example of a traffic lights controller is used to illustrate this translation.
0.1.1 MORPHEUS CDFG processes MORPHEUS Spatial Design provides a two step set of tools for multi-target architecture synthesis. The intermediate format is a Control Data Flow Graph (CDFG), addressed from the high level tools, to be translated into circuit descriptions. The upper specification tools were initially the data flow oriented SPEAR methodology, and the CASCADE tools for function specifications. SPEAR is in charge of memory addressing (arrays, in fact), while functions are represented by ARM binaries operating on data flows to produce other data flows. On the CDFG point of view, SPEAR introduces the notion of connector, represented by a CDFG Process reading and writing a local memory, fetching and passing data through CDFG ports. CASCADE in turns produces computing CDFG Processes bound to these ports. These processes form a local pipeline operating on local memories (called DEB) containing data buffers. A local controller receives end of computation acknowledge from the processes, switch buffers, making the pipeline to advance, then release them for a new cycle. So called half connectors receive and send data to a DMA controller closing the loop on main memory.
1
Connectors
mem ports mem
mem
mem Functions Figure 1: SPEAR connector interface memories while CASCADE functions implement data processing
0.1.2 SpecEdit introduction SpecEdit is oriented for control rather than data transformations, therefore complementing nicely the MORPHEUS toolset. SpecEdit focus is complex state machines built by composing states together. In fact, a specification can be seen as a group of processes passing control from one to other(s) process(es). These processes hold an internal state and receive information from the environment. Process transitions produce a change in the internal state, possibly passing the control to another stage, and feeding a production process to produce an output. The specification makes the transition process and the production process explicit in the form of tables filled by the programmer to define a behaviour. Two kinds of tables can be identified: Mode Transition Tables (MTT) and Data Transformation Tables (DTT). The definition of these tables in itself is called ADeVA[2]. The control flow is modelled by asynchronous parallel automata interacting using a shared memory model. Figure 2 is showing a MTT and a DTT, both of them have read access to all the signals. The MTT has write access to the state variables. Each DTT has write access to one of the other signals. In the current status, MTT and DTT will be mapped to CDFG Process and synthesis will be achieved on a coordination of such process group. The question of memory access from the processes is to be solved with the question of memory allocation for variables and communication with other entities on the SoC. Data referenced in the tables associate a name and a data type for primitive elements (such as: integer, natural, boolean), or higher level types (such as: records, enumerations, ranges, arrays)
0.1.3 Process composition and System behaviour Composing processes together is another important element in an application description. The SpecEdit Requirement groups (RG) can compose together at a higher level by exchanging data on ports as it is the case for SPEAR and CASCADE processes. This is the case if several RG are configured locally to implement a processing chain. Another case is processing on local buffers. One can imagine that data appears in local memories to be processed by one or several RGs. An example that we have in mind is a network processing application where packets are passed into buffers to be analysed and to take decisions(see figure 3). In MORPHEUS, we need to deal with very different situations. But a fact is that the process organisation and the simplicity to manipulate this organisation is very important.
2
Figure 2: Exemple of a SpecEdit requirement group.
DMA actions
System handshakes
Memoire
Memoire SpecEdit processes
control
Memoire
Memoire
Figure 3: SpecEdit state machines interact with memories to fetch and store variables. A system controller starts the processes and wait for their end status allowing buffer moves to take place.
3
0.1.4 Work overview The motivation for this document is to explain how SpecEdit specifications are mapped to CDFGs. This work has been achieved as a set of Smalltalk classes representing an intermediate model. The SpecEdit application is presented to a parser as an XML file coming from the initial tool. After parsing, the model is instantiated from the classes, and rewritten in the form of an internal CDFG representation. From this stage, a STEP file is produced for further processing (composing with other processes or architecture synthesis).
0.2 CDFG support for SpecEdit The mapping of SpecEdit specifications to CDFG is realized following the flow presented in figure 4. According to the figure the flow starts with some requirements which are implemented in ADeVA using SpecEdit. A XML file containing the specifications is produced by SpecEdit. This file is then parsed by SpecBuilder class in order to instantiate an internal specification according to an internal model defined in the following section (see Section 0.2.1). CDFGBuilder will use this internal structure to build a CDFG representing the initial requirement (for details on this step see Section 0.2.3). Once the CDFG is build we are able to save it to a STEP file using CDFGStepExport class.
0.2.1 Model description Figure 5 is showing the UML diagram of the internal model used to represent a SpecEdit Specification. An instance of SESpecification class is intended to contain the whole specification. The declared types, the declared signals and the requirement groups are stored into collections (types, vars and, requirementsGroups respectively). The class SEType is used to store information about the types declared for the current specification. The class SENameDefinition is used to store the declaration of a signal. The class SERequirementGroup contains a collection of requirements represented by the class SERequirement. Each SERequirement can contain a MTT and a DTT. The MTTs are represented by the class SERequirementMTT. The DTTs are represented by the class SERequirementDTT. These two classes contain the actual rows of the tables representing the MTTs and DTTs along with the specific characteristics of each of them ( the “state” for MTT; the “signal” and the “default” value for DTT). The Smalltalk implementation of this model can be found in Appendix .1.
0.2.2 XML input, parsing and support All the specification information in SpecEdit are stored in a XML format file. This file is used as an entry to the framework that will parse the file and will generate the internal model described in the last section. In order to do that a class named SpecBuilder was build. This class, with the help of the XMLParser class (a class available in Cincom VisualWorks Smalltalk distribution), will create the hierarchy of objects representing the specification described in the XML file. For example the XML specification found in Appendix .2 is used to generate the CDFG in figure 8.
0.2.3 CDFG generation and equivalences From the internal model, described in the first section, a CDFG, representing the specification, is build. The structure of the generated CDFG is as following: • An HCDFGNode is created for a SpecEdit Specification. The inputs, outputs and local variables of this node are built according to the Defined Names list. The mode of the signal gives the list where the signal will be inserted. So an input signal will be present in the node’s inputs list. An output signal in its outputs list. An internal signal in its local variables list. This node has only one element in the subOperators list, a ParallelNode, that is the placeholder for the Specification’s Requirement Groups.
4
Figure 4: Flow diagram.
5
Figure 5: Internal Model diagram
6
• All the Requirement Groups(RG) are to be executed in parallel. Each RG is represented by an SequencialNode with two ParallelNode nodes as subOperators. The first ParallelNode is used to precalculate the values of all the conditions present in the RG MTT’s and/or DTT’s. The outputs of this first ParallelNode, as well as some of the declared signals, are the inputs of the second ParallelNode (used as a placeholder for the Requirements). • Each Requirement is implemented as an ParallelNode containing as subOperators a MTT and/or a DTT representation. • An MTT is represented by a SequentialNode with two subOperators: a ParallelNode (used to precalculate the event function of a condition signal) and a FSMNode. The inputs of this FSMNode are the result of the conditions and events results for the conditions. The outputs of the FSMNode is the signal storing the state of the system. Each line of a MTT is represented by a Transition with the activationSignals set according to the expected value for each condition (T, F, @T, @F). The outputSignal of each Transition is encoding the “to” state of the Transition. • Every DTT that modifies the value of a internal signal is represented by an AccumulatorNode. The init value is equal to the initValue, in the Defined Names table, for the signal. The first subOperator of this AccumulatorNode is the default value for the signal. The other subOperators are TestNode nodes representing each line of the DTT table. The cond of these TestNode nodes are the a combination of the results of the precalculated conditions from the DTT and the output of these nodes are the new value of the signal. • Every DTT that calculate the value of the output signals is represented by a SequentialNode. The first subOperator of this node is the default value. The others are TestNodes representing each line of the DTT. • The constants found in the specification are represented by ConstNode nodes. • The signals are represented by Data nodes. The fact that all the MTTs and DTTs, as well as the RGs, representation are executed in parallel ensures the asynchronous parallel automaton model of execution of the specified architecture. The signals are represented as objects with 2 instance variable: currentValue, oldValue. These objects respond to the message “event” returning “true” if the currentValue 6= oldValue and “false” otherwise. The next section will present a simple example of a generated CDFG.
0.2.4 Crossroad light example A simple traffic lights controller is used to illustrate the flow presented in this paper. This simple traffic lights controller can be described as a system that receives a signal in input, counts this signal and each time the count reaches 20 it will change it’s internal state (representing the current color). The output of this controller is it’s current internal state. The figures 6 and 7 are presenting the SpecEdit interface. In figure 6 we can see the principal window of SpecEdit, with the requirements hierarchies at left, an MTT table and defined names in the middle. The figure 7 represents an example of DTT table. Both figure 6 and figure 7 are screen-shots taken while specifying the traffic lights controller that is used as an example in this paper. In figure 8 we can see a graphical representation (realized using GraphViz framework[1]) of the CDFG generated from the XML file found in Appendix .2. This is a simplified specification of a traffic lights controller. In this figure the green ellipses are representing the ComputeNode nodes, the lightblue ones are representing the ConstNode nodes and the blue ones are representing the Data nodes. The small boxes represent AliasNode nodes. The diamond nodes are used for the MergeNode nodes. The hierarchies are represented by using embedded rectangles (each having the node represented as a label on the top). The yellow pentagonal nodes are drawn just for visualisation purposes (marking a condition in TestNodes). In the figure 8 we can identify ParallelNodeNode 11 (the upper part of the figure) as being the node that contains the conditions that are precalculated beforehand, AccumulatorNode 46 as the a node representing
7
Figure 6: SpecEdit cockpit. In the left we have an hierarchy of requirements. In the center we can see a MTT table and the defined signals for the current specification. At the bottom we see a status window.
Figure 7: An example of a DTT table
8
the DTT used to increment the count variable, the sequential node on the right of the image as the node that represents the MTT for the traffic lights controller. The STEP file associated to this CDFG can be found in Appendix .3.
0.3 Status and Perspectives This preliminary report was produced to provide a status of the work at UBO related to SpecEdit, and related to global structure of applications. • A mapping of SpecEdit to a Smalltalk model then to CDFG has been proposed with the capability to translate SpecEdit XML into CDFG files, following Ciprian Teodorov ideas, • Among the future problems to deal with, there are the interfaces to memories, and the global control of an application system. This implies to define some way to associate high level data appearing somewhere in the system to variables used by SpecEdit processes. Possible applications that we see are system monitoring and packet processing: filtering, routing etc... • Effort related to logic and architecture synthesis has just been started by Ciprian Teodorov in relation with Loic Lagadec back end for CDFGs on M2000. A release of a reduced version of Madeo for logic synthesis is currently proposed by Thierry Goubier (Madeolite, [email protected]).
9
System count INT ParallelNodeNode_4
INT SequentialNode
INT ParallelNodeNode_11
INT
20 INT INT mod
0
clk
INT INT
INT
BOOL
= BOOL
BOOL
BOOL
BOOL
BOOL
BOOL
ParallelNodeNode_21
INT
BOOL
BOOL
ParallelNodeNode_43
ParallelNodeNode_25
INT
BOOL
BOOL
AccumulatorNode_46 SequentialNode 0 INT
BOOL
BOOL
SequentialNode
ParallelNodeNode_29
INT
BOOL
BOOL
SequentialNode 0
event INT
BOOL
BOOL
BOOL
TestNode
INT
BOOL BOOL
BOOL FSMNode Inputs
1
red
INT INT +
BOOL BOOL
INT
1-/010
event
1-/100
BOOL
orange
1-/001
AND
2
1
current_state FullEnum
green
FullEnum
Merge_Node_71
FullEnum
INT
FullEnum
INT
INT
INT
INT
INT
Figure 8: A CDFG example. MTT at left, DTT at right.
10
Bibliography [1] Emden R. Gansner and Stephen C. North. An open graph visualization system and its applications to software engineering. Software — Practice and Experience, 30(11):1203–1233, 2000. [2] Haas, W. Heinkel, U. Gossens, Stefan. Behavioral specification for advanced design and verification of asics (adeva). GI/ITG/GMM-Workshop Methoden und Beschreibungssprachen zur Modellierung und Verifikation von Schaltungen und Systemen T¨ubingen, Februar 2002.
.1
Model Classes SERequirement
class name superclass instance variable names class instance variable names shared variable names imports category
SERequirement SEData index reqMTT reqDTT none none none SpecEditSM-specifications-model
SERequirement represents an SpecEdit requirement Instance Variables: index
Aug 28, 2007 - The upper specification tools were initially the data flow oriented SPEAR .... using embedded rectangles (each having the node represented as a label on the top). ... An open graph visualization system and its applications to.
Jul 5, 2013 - Examiner's Office in Phoenix determined the firefighters died from burns and inhalation problems. The. 20th member of the crew was serving as ...
Jul 5, 2013 - Examiner's Office in Phoenix determined the firefighters died from burns and inhalation problems. The. 20th member of the crew was serving as ...
of the University of Indianapolis, whose keen interest in archaeology provided the initial impetus and funding for the. Rantidi Forest Excavations; thanks go also ...
Beddoes et al., Preliminary report on international engineering education ... Background information about the workshops and participant feedback are presented ... Delft University of Technology (TU Delft) in Delft, The Netherlands, June ...
Mar 13, 2014 - https://play.google.com/store/apps/details?id=com.webrosoft.election_watch_reporter. Analysis of Declared ...... Join us on Social-Media.
There was a problem previewing this document. Retrying... Download. Connect more apps... Try one of the apps below to open or edit this item. Main menu.
Figure 3.4: Inclined Mechanic ily Raked Bar Screen. 40 .... Professor T. Casey, University College, Dublin., ..... is best achieved on the contaminated stream.
Figure 3.4: Inclined Mechanic ily Raked Bar Screen. 40 .... Professor T. Casey, University College, Dublin., ..... is best achieved on the contaminated stream.
Keynote lecture by Dr. Andrew P.E. York, (Johnson Matthey's corporate research centre, United Kingdom). Topics âAutomotive Emissions Control in the Present ...
MOSFET gate drive. Non-critical pushbutton. Voltage boost flyback. Tuned LRC tank inductor. High power piezo tweeter. Class-E amp digital switch. Price.
DC blocking signal cap. Voltage boost flyback. Tuned LRC tank inductor. High power piezo tweeter. Class-E amp digital switch. Non-critical pushbutton. Price.
Non-critical pushbutton. Voltage boost flyback. Tuned LRC tank inductor. High power piezo tweeter. Class-E amp digital switch. MOSFET gate voltage divide.
Michael Petty, PhD, RN. Michael Rosenberg, MD. Scott Sakaguchi, MD. Jamie Santilli, MD. Jason Bartos, MD. Fellow in Interventional Cardiology, University of ...
The mass fragmentation studies revealed the presence ... The free hand cut transverse sections of the seed were taken and ... Statistical analysis was performed using GraphPad In Stat software. RESULTS ..... Email: [email protected].
1 (2007). Whoops! There was a problem loading this page. (CCG-NLUD) Ujwala Uppaluri, Freedom of Speech & Google Search- Preliminary Notes for India.pdf.