S PEC E DIT

MODELLING AND

CDFG

TRANSLATION

preliminary report Ciprian Teodorov Bernard Pottier LESTER/AS FRE CNRS 2734 – U.B.O. August 28, 2007

Contents 0.1

0.2

0.3 .1 .2 .3

Introduction . . . . . . . . . . . . . . . . . . . . . . . 0.1.1 MORPHEUS CDFG processes . . . . . . . . . 0.1.2 SpecEdit introduction . . . . . . . . . . . . . 0.1.3 Process composition and System behaviour . . 0.1.4 Work overview . . . . . . . . . . . . . . . . . CDFG support for SpecEdit . . . . . . . . . . . . . . . 0.2.1 Model description . . . . . . . . . . . . . . . 0.2.2 XML input, parsing and support . . . . . . . . 0.2.3 CDFG generation and equivalences . . . . . . 0.2.4 Crossroad light example . . . . . . . . . . . . Status and Perspectives . . . . . . . . . . . . . . . . . Model Classes . . . . . . . . . . . . . . . . . . . . . An Example of XML Specification . . . . . . . . . . . The generated STEP file for the traffic lights controller

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

1 1 2 2 4 4 4 4 4 7 9 11 24 28

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 description of index reqDTT description of reqDTT reqMTT description of reqMTT

Protocol for visiting accept: aSpecVisitor ˆaSpecVisitor acceptRequirement: self

Protocol for initialize-release initialize super initialize. index := nil. ˆself

11

Protocol for accessing (has been shortened) Protocol for printing printOn: aStream aStream nextPutAll: ’req ’, self title asString.

SEDTTRow class name superclass instance variable names class instance variable names shared variable names imports category

SEDTTRow SEData index weight value values none none none SpecEditSM-specifications-model

SEDTTRow represents a row in a DTT description Instance Variables: equations description of equations index description of index value description of value weight description of weight

Protocol for accessing (has been shortened) Protocol for visiting accept: aSpecVisitor ˆaSpecVisitor acceptDTTRow: self

Protocol for initialize-release initialize super initialize. weight := nil. value := nil. values := OrderedCollection new. ˆself

Protocol for printing printOn: aStream aStream nextPutAll: ’value ’ , self value asString , ’;’; cr

SEDTTRow class

12

class name superclass instance variable names class instance variable names shared variable names imports category

SEDTTRow class SEData class none thisClass none none SpecEditSM-specifications-model

Protocol for instance creation new ˆsuper new initialize

SERequirementDTT class name superclass instance variable names class instance variable names shared variable names imports category

SERequirementDTT Object signal default dtt equations none none none SpecEditSM-specifications-model

SERequirementDTT represents a SpecEdit DTT Instance Variables: default description of default dtt description of dtt signal description of signal

Protocol for accessing (has been shortened) Protocol for visiting accept: aSpecVisitor ˆaSpecVisitor acceptRequirementDTT: self

Protocol for initialize-release initialize signal := nil. default := nil. dtt := OrderedCollection new. equations := OrderedCollection new. ˆself

Protocol for printing printOn: aStream aStream nextPutAll: ’DTT ’, self signal asString.

13

SERequirementDTT class class name superclass instance variable names class instance variable names shared variable names imports category

SERequirementDTT class Object class none thisClass none none SpecEditSM-specifications-model

Protocol for instance creation new ˆsuper new initialize

SEType class name superclass instance variable names class instance variable names shared variable names imports category

SEType Object name arrayEnabled record enumeration range array none none none SpecEditSM-specifications-model

SEType represents an SpecEdit type declaration Instance Variables: array description of array arrayEnabled description of arrayEnabled enumeration description of enumeration name description of name range description of range record description of record

Protocol for accessing (has been shortened) Protocol for initialize-release initialize name := nil. arrayEnabled := nil. record := nil. enumeration := OrderedCollection new. range := SERange new. array := SEArray new. ˆself

Protocol for visiting accept: aSpecVisitor ˆaSpecVisitor acceptType: self

14

Protocol for printing printOn: aStream aStream nextPutAll: ’t ’, self name asString.

SEType class class name superclass instance variable names class instance variable names shared variable names imports category

SEType class Object class none thisClass none none SpecEditSM-specifications-model

Protocol for instance creation new ˆsuper new initialize

SEMTTRow class name superclass instance variable names class instance variable names shared variable names imports category

SEMTTRow SEData index weight from to values none none none SpecEditSM-specifications-model

SEDTTRow represents a row in a MTT description Instance Variables: equations description of equations from description of from index description of index to description of to weight description of weight

Protocol for accessing (has been shortened) Protocol for visiting accept: aSpecVisitor ˆaSpecVisitor acceptMTTRow: self

Protocol for printing printOn: aStream aStream

15

nextPutAll: self from asString , ’ −> ’ , self to asString , ’;’; cr

Protocol for initialize-release initialize super initialize. weight := nil. from := nil. to := nil. values := OrderedCollection new. ˆself

SEMTTRow class class name superclass instance variable names class instance variable names shared variable names imports category

SEMTTRow class SEData class none thisClass none none SpecEditSM-specifications-model

Protocol for instance creation new ˆsuper new initialize

SERequirementMTT class name superclass instance variable names class instance variable names shared variable names imports category

SERequirementMTT Object state mtt equations none none none SpecEditSM-specifications-model

SERequirementMTT represents a SpecEdit MTT Instance Variables: mtt description of mtt state description of state

Protocol for accessing (has been shortened) Protocol for visiting accept: aSpecVisitor ˆaSpecVisitor acceptRequirementMTT: self

16

Protocol for printing printOn: aStream aStream nextPutAll: ’MTT ’, self state asString.

Protocol for initialize-release initialize state := nil. mtt := OrderedCollection new. equations := OrderedCollection new. ˆself

SERequirementMTT class class name superclass instance variable names class instance variable names shared variable names imports category

SERequirementMTT class Object class none thisClass none none SpecEditSM-specifications-model

Protocol for instance creation new ˆsuper new initialize

SERequirementGroup class name superclass instance variable names class instance variable names shared variable names imports category

SERequirementGroup SEData requirements none none none SpecEditSM-specifications-model

SERequirementGroup represents a SpecEdit RequirementGroup Instance Variables: requirements



description of requirements

Protocol for accessing (has been shortened) Protocol for visiting accept: aSpecVisitor ˆaSpecVisitor acceptRequirementGroup: self

17

Protocol for initialize-release initialize super initialize. requirements := OrderedCollection new. ˆself

Protocol for printing printOn: aStream aStream nextPutAll: ’rg ’, self title asString.

SEData class name superclass instance variable names class instance variable names shared variable names imports category

SEData Object id changer timeChanged abstract title none none none SpecEditSM-specifications-model

SEData is used to keep different informations about some parts of the specification. Instance Variables: abstract A description of the specified component changer The username of the user that did the last changes id The id of the object timeChanged The time when the last changes took place title A title for this part of the specification

Protocol for accessing (has been shortened) Protocol for visiting accept: aSpecVisitor ˆaSpecVisitor acceptData: self

Protocol for initialize-release initialize id := nil. changer := nil. timeChanged := nil. abstract := nil. title := nil. ˆself

SEData class

18

class name superclass instance variable names class instance variable names shared variable names imports category

SEData class Object class none thisClass none none SpecEditSM-specifications-model

Protocol for instance creation new ˆsuper new initialize

AbstractSpecVisitor class name superclass instance variable names class instance variable names shared variable names imports category

AbstractSpecVisitor Object none none none none SpecEditSM-specifications-model

AbstractSpecVisitor is the class that should be inherited in order to visit the generated internal model. Subclasses must implement the following messages: visiting acceptArray: acceptData: acceptDTTRow: acceptMTTRow: acceptNameDefinition: acceptRange: acceptRequirement: acceptRequirementDTT: acceptRequirementGroup: acceptRequirementMTT: acceptSpecification: acceptType:

Protocol for visiting acceptArray: anSEArray ˆself subclassResponsibility acceptData: anSEData ˆself subclassResponsibility acceptDTTRow: anSEDTTRow ˆself subclassResponsibility acceptMTTRow: anSEMTTRow ˆself subclassResponsibility

19

acceptNameDefinition: anSENameDefinition ˆself subclassResponsibility acceptRange: anSERange ˆself subclassResponsibility acceptRequirement: anSERequirement ˆself subclassResponsibility acceptRequirementDTT: anSERequirementDTT ˆself subclassResponsibility acceptRequirementGroup: anSERequirementGroup ˆself subclassResponsibility acceptRequirementMTT: anSERequirementMTT ˆself subclassResponsibility acceptSpecification: anSESpecification ˆself subclassResponsibility acceptType: anSEType ˆself subclassResponsibility

Protocol for initialize-release initialize ˆself

AbstractSpecVisitor class class name superclass instance variable names class instance variable names shared variable names imports category

AbstractSpecVisitor class Object class none thisClass none none SpecEditSM-specifications-model

Protocol for instance creation new “Answer a newly created and initialized instance.” ˆsuper new initialize

SESpecification class name superclass instance variable names class instance variable names shared variable names imports category

SESpecification SEData name description filePath types vars requirementGroup none none none SpecEditSM-specifications-model 20

SESpecification is the entry level of the specification Instance Variables: description description of description filePath description of filePath name description of name requirementGroup description of requirementGroup types description of types vars description of vars

Protocol for accessing (has been shortened) Protocol for visiting accept: aSpecVisitor ˆaSpecVisitor acceptSpecification: self

Protocol for initialize-release initialize super initialize. name := nil. description := nil. filePath := nil. types := OrderedCollection new. vars := OrderedCollection new. requirementGroup := OrderedCollection new. ˆself

Protocol for printing printOn: aStream aStream nextPutAll: ’Spec ’, self title asString.

SERange class name superclass instance variable names class instance variable names shared variable names imports category

SERange Object leftRange rightRange none none none SpecEditSM-specifications-model

SERange Instance Variables: leftRange rightRange

description of leftRange description of rightRange

21

Protocol for visiting accept: aSpecVisitor ˆaSpecVisitor acceptRange: self

Protocol for initialize-release initialize leftRange := nil. rightRange := nil. ˆself

Protocol for accessing (has been shortened)

SERange class class name superclass instance variable names class instance variable names shared variable names imports category

SERange class Object class none thisClass none none SpecEditSM-specifications-model

Protocol for instance creation new ˆsuper new initialize

SEArray class name superclass instance variable names class instance variable names shared variable names imports category

SEArray Object leftBound rightBound type none none none SpecEditSM-specifications-model

SEArray is representing one the types that can be defined by the user in SpecEdit. Instance Variables: leftBound description of leftBound rightBound description of rightBound type description of type

Protocol for visiting accept: aSpecVisitor ˆaSpecVisitor acceptArray: self

22

Protocol for initialize-release initialize leftBound := nil. rightBound := nil. type := nil. ˆself

Protocol for accessing (has been shortened)

SEArray class class name superclass instance variable names class instance variable names shared variable names imports category

SEArray class Object class none thisClass none none SpecEditSM-specifications-model

Protocol for instance creation new ˆsuper new initialize

SENameDefinition class name superclass instance variable names class instance variable names shared variable names imports category

SENameDefinition Object id name mode type initValue abstract ModeTypes none none SpecEditSM-specifications-model

SENameDefinition represents a signal declaration Instance Variables: abstract description of abstract id description of id initValue description of initValue mode description of mode name description of name type description of type

Protocol for visiting accept: aSpecVisitor ˆaSpecVisitor acceptNameDefinition: self

23

Protocol for initialize-release initialize id := nil. name := nil. mode := nil. type := nil. abstract := nil. ˆself

Protocol for accessing (has been shortened) Protocol for printing printOn: aStream aStream nextPutAll: self name asString.

SENameDefinition class class name superclass instance variable names class instance variable names shared variable names imports category

SENameDefinition class Object class ModeTypes thisClass none none SpecEditSM-specifications-model

Protocol for accessing (has been shortened) Protocol for instance creation initializeModeTypes ModeTypes := #(#internal #internal timed #input #outp

.2 An Example of XML Specification 11841538012698540 info 1184154978 New Spec <html><head><meta name="qrichtext" content="1" /></head><body style=" font-size:8pt;font-family:Helvetica"><p> trafficLights</p></body></html> 24

colors 0 green orange red 0 0 0 boolean 3 clk Input boolean 4 current_state Output colors red 6 count Internal integer 0
7 info 1184154838 +1 <html><head><meta name="qrichtext" content="1" /></head><body style=" font-size:8pt;font-family:Helvetica"> <p><span style="font-size:12pt">behaviour</span></p> 25<br /> <br /> </body></html> 8 info 1184154772

sds< /p> +1 current_state <html><head><meta name=" qrichtext"content="1" /></ head><body style="font-size:8pt; font-family:Helvetica"><p>< span style="font-size:12pt">stateChanging </span></p></body></html> 9 info 1184154711 +1 red orange (count mod 20) = 0 T 10 info 1184154749 +1 orange green 26

(count mod 20) = 0 T
11 info 1184154772 +1 green red (count mod 20) = 0 T
12 info 1184154978 count 0 +1 <html><head><meta name="qrichtext" content="1" /></head><body style=" font-size:8pt;font-family:Helvetica"><p>< span style="font-size:12pt">count </span> </p></body></html> 13 info 1184154978 +1 count + 1 clk @T 27



.3 The generated STEP file for the traffic lights controller ISO-10303-21; HEADER; FILE_NAME(’trafficLights.step’, ’August 1, 2007 8:14:02 am’, (’Ciprian TEODOROV’), (’LESTER’), ’’, ’’, ’’); FILE_DESCRIPTION((’’,’’), ’’); FILE_SCHEMA(()); ENDSEC; DATA; #1=HCDFGNODE((#2),(#21),(#23),(#44)); #2=DATA((#3),’clk’,$,#7); #3=ALIASDATA((#4,#15,#16,#17,#18,#19,#20),’clk’,$,#7,#2); #4=ALIASDATA((#5),’clk’,$,#7,#15); #5=ALIASDATA((#6,#8,#9),’clk’,$,#7,#4); #6=ALIASDATA((),’clk’,$,#7,#5); #7=BOOL(.F.); #8=ALIASDATA((),’clk’,$,#7,#5); #9=COMPUTENODE((#10,#8),(#13),’AND’); #10=DATA((),’’,#11,#12); #11=COMPUTENODE((#6),(#10),.event.); #12=BOOL(.F.); #13=DATA((),’’,#9,#14); #14=BOOL(.F.); #15=ALIASDATA((),’clk’,$,#7,#16); #16=ALIASDATA((),’clk’,$,#7,#17); #17=ALIASDATA((),’clk’,$,#7,#18); #18=ALIASDATA((),’clk’,$,#7,#19); #19=ALIASDATA((),’clk’,$,#7,#20); #20=ALIASDATA((),’clk’,$,#7,#3); #21=DATA((),’current_state’,$,#22); #22=FULLENUM(); #23=DATA((#24,#33,#38,#39,#40,#41,#42,#43,#30,#31,#32) ,’count’,$,#29); #24=ALIASDATA((#25),’count’,$,#29,#30); #25=COMPUTENODE((#26,#24),(#28),’mod’); #26=CONSTDATA((#25),20,$,#27); #27=INT(0,.F.); #28=DATA((),’t11’,#25,#29); #29=INT(0,.F.);

28

#30=ALIASDATA((),’count’,$,#29,#31); #31=ALIASDATA((),’count’,$,#29,#32); #32=ALIASDATA((),’count’,$,#29,#23); #33=ALIASDATA((#34),’count’,$,#29,#38); #34=COMPUTENODE((#35,#33),(#37),’+’); #35=CONSTDATA((#34),1,$,#36); #36=INT(0,.F.); #37=DATA((),’t48’,#34,#29); #38=ALIASDATA((),’count’,$,#29,#39); #39=ALIASDATA((),’count’,$,#29,#40); #40=ALIASDATA((),’count’,$,#29,#41); #41=ALIASDATA((),’count’,$,#29,#42); #42=ALIASDATA((),’count’,$,#29,#43); #43=ALIASDATA((),’count’,$,#29,#31); #44=PARALLELNODE((#32,#20),(#45),(),(#71)); #45=ALIASDATA((),’current_state’,$,#22,#46); #46=ALIASDATA((#45),’current_state’,$,#22,#47); #47=ALIASDATA((#46),’current_state’,$,#22,#48); #48=ALIASDATA((#47),’current_state’,$,#22,#49); #49=DATA((#48),’current_state’,#50,#22); #50=FSMNODE((#51,#58),(#49),$,(#68,#69,#70), (’red’,’orange’,’green’)); #51=ALIASDATA((#50),’t12’,$,#52,#53); #52=BOOL(.F.); #53=ALIASDATA((#54,#51),’t12’,$,#52,#60); #54=ALIASDATA((#55),’t12’,$,#52,#53); #55=COMPUTENODE((#54),(#56),’event’); #56=DATA((#57),’t21’,#55,#59); #57=ALIASDATA((#58),’t21’,$,#59,#56); #58=ALIASDATA((#50),’t21’,$,#59,#57); #59=BOOL(.F.); #60=ALIASDATA((),’t12’,$,#52,#61); #61=ALIASDATA((),’t12’,$,#52,#62); #62=ALIASDATA((#53,#60,#61),’t12’,$,#52,#63); #63=ALIASDATA((#62),’t12’,$,#52,#64); #64=DATA((),’t12’,#65,#52); #65=COMPUTENODE((#66,#28),(#64),’=’); #66=CONSTDATA((#65),0,$,#67); #67=INT(0,.F.); #68=TRANSITION(’red’,(’1’,’-’),’orange’,(’0’,’1’,’0’)); #69=TRANSITION(’orange’,(’1’,’-’),’green’,(’0’,’0’,’1’)); #70=TRANSITION(’green’,(’1’,’-’),’red’,(’1’,’0’,’0’)); #71=SEQUENTIALNODE((#31,#19),(#46,#72),(),(#83,#85)); #72=ALIASDATA((),’’,$,#29,#73); #73=ALIASDATA((#72),’’,$,#29,#74); #74=ALIASDATA((#73),’’,$,#29,#75); #75=ALIASDATA((#74),’’,$,#29,#76); #76=ALIASDATA((#75),’’,$,#29,#77); #77=ALIASDATA((#76),’’,$,#29,#78); #78=DATA((#77),’’,#79,#29); #79=TESTNODE((#5,#38),(#77),(),(),#13,*,#82,$,#80); #80=TESTMERGENODE((),(#78),(#81),()); #81=ALIASDATA((),’t48’,$,#29,#37); #82=HIERARCHICALNODE((#33),(#81),(),(#34)); 29

#83=PARALLELNODE((#30),(#62),(),(#84)); #84=HIERARCHICALNODE((#24),(#63),(),(#65)); #85=PARALLELNODE((#61,#18,#43),(#47,#73),(),(#86,#89)); #86=PARALLELNODE((#60),(#48),(),(#87)); #87=SEQUENTIALNODE((#53),(#48),(),(#88,#50)); #88=PARALLELNODE((#54),(#57),(),(#55)); #89=PARALLELNODE((#17,#42),(#74),(),(#90)); #90=ACCUMULATORNODE((#16,#41),(#74),(),(#91),#95,#97); #91=SEQUENTIALNODE((#15,#40),(#75),(),(#92)); #92=SEQUENTIALNODE((#4,#39),(#76),(),(#93,#79)); #93=CONSTDATA((),0,$,#94); #94=INT(0,.F.); #95=CONSTDATA((),0,$,#96); #96=INT(0,.F.); #97=ALIASDATA((),’count’,#90,$,$); ENDSEC; END-ISO-10303-21;

30

preliminary report

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.

615KB Sizes 2 Downloads 334 Views

Recommend Documents

72 Hour Preliminary Report Yarnell Hill Fire.pdf
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 ...

72 Hour Preliminary Report Yarnell Hill Fire.pdf
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 ...

PRELIMINARY
Type. 9v Transistor Radio Battery. Radial Ceramic Capacitor. Radial Ceramic Capacitor. Radial Ceramic Capacitor. Carbon Film Resistor. Momentary ...

PRELIMINARY
P647-ND. 445-8516-ND. BC2683CT-ND. 445-2855-ND. CF18JT22K0CT-ND. (Any random pushbutton). 445-3778-1-ND. TC4421AVPA-ND. Clone of Motorola/CTS KSN-1005 (not DigiKey). Circuit Function. System power. Power supply bypass. Feedback phase-shift C. Frequen

Preliminary report on new echinoderm Lagerstätten ...
Preliminary report on new echinoderm Lagerstätten from the Upper ..... for their help in the field. ... Mémoires du Service géologique du Maroc, 240, 1–114. 29 ...

Preliminary Candidate Report for Lok Sabha (INC BJP)
Mar 13, 2014 - ... elections download the Election Watch Reporter (Android App) ..... 19. Ananth Kumar. Hegde. Uttara Kannada. Uttara Kannada. BJP. 3.

The Rantidi Forest Excavations Preliminary Report
of the University of Indianapolis, whose keen interest in archaeology provided the initial impetus and funding for the. Rantidi Forest Excavations; thanks go also ...

Preliminary report on two meetings designed to ...
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 ...

Preliminary Candidate Report for Lok Sabha (INC BJP)
Mar 13, 2014 - https://play.google.com/store/apps/details?id=com.webrosoft.election_watch_reporter. Analysis of Declared ...... Join us on Social-Media.

2016-2016 - Preliminary Report, AAIS Case AIFN-0008-2016 - A6 ...
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.

PRELIMINARY TREATMENT
Figure 3.4: Inclined Mechanic ily Raked Bar Screen. 40 .... Professor T. Casey, University College, Dublin., ..... is best achieved on the contaminated stream.

PRELIMINARY TREATMENT
Figure 3.4: Inclined Mechanic ily Raked Bar Screen. 40 .... Professor T. Casey, University College, Dublin., ..... is best achieved on the contaminated stream.

Preliminary Programs.pdf
Keynote lecture by Dr. Andrew P.E. York, (Johnson Matthey's corporate research centre, United Kingdom). Topics “Automotive Emissions Control in the Present ...

preliminary -
MOSFET gate drive. Non-critical pushbutton. Voltage boost flyback. Tuned LRC tank inductor. High power piezo tweeter. Class-E amp digital switch. Price.

preliminary plat
SECTION 14, TOWNSHIP 42 SOUTH, RANGE 15 WEST, SALT LAKE BASE ... OF SAID CURVE 38.62 FEET THROUGH A CENTRAL ANGLE OF 88°30'38”, ...

preliminary -
DC blocking signal cap. Voltage boost flyback. Tuned LRC tank inductor. High power piezo tweeter. Class-E amp digital switch. Non-critical pushbutton. Price.

preliminary-quiz.pdf
(a) ©. −3,3. a. (b) 3 (c) ; (d) none of the above. 15. Let f be the exponential function and g be the logrithmic function with the same base (4). a. Then (f g)(1) = (a) a (b) 1. (c) 0 (d) cannot be determined. 16. In the figure if TP and TQ are ta

preliminary -
Non-critical pushbutton. Voltage boost flyback. Tuned LRC tank inductor. High power piezo tweeter. Class-E amp digital switch. MOSFET gate voltage divide.

pharma science monitor pharmacognostical, preliminary ...
www.pharmasm.com. 90. PHARMA SCIENCE MONITOR. AN INTERNATIONAL JOURNAL OF PHARMACEUTICAL SCIENCES. PHARMACOGNOSTICAL ...

Lillehei Preliminary Agenda.pdf
Michael Petty, PhD, RN. Michael Rosenberg, MD. Scott Sakaguchi, MD. Jamie Santilli, MD. Jason Bartos, MD. Fellow in Interventional Cardiology, University of ...

pharma science monitor pharmacognostical, preliminary ...
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].

Preliminary Notes for India.pdf
1 (2007). Whoops! There was a problem loading this page. (CCG-NLUD) Ujwala Uppaluri, Freedom of Speech & Google Search- Preliminary Notes for India.pdf.