| Syrf tools for combination of synchronous formalisms |
|---|
In DC code, programs are expressed by equation systems handling valued flows and clocks in a data flow style. Esterel language has a clear constructive semantics into boolean equation systems and an internal compilation format SC to represent such systems. To compile Esterel programs into DC a processor scdc has been defined and is avalaible from this page.
Synchronous reactive languages can be compiled into hardware description
languages and we implement a dchdl processor dedicated to this translation.
The processor generates either
Vhdl or Verilog code for reactive
programs written in DC.
esterel -sc game.strl
scsort game.sc > game.scs
scsdc game.scs > game.dc or scsdc -B game game.scs
| -version | Print the version name on the standard error output stream and terminate ignoring all other arguments. | ||
| -info | Print various informations about the processor compilation on the standard error output stream and terminate, ignoring all other arguments. | ||
| -access | Print access rights to the processor on the standard error output stream and terminate, ignoring all other arguments. | ||
| -s | Silent mode: perform parsing and type-checking but do not generate the sc code. | ||
| -v | Verbose mode: print the name of each input module on the standard error stream. | ||
| -B <name> | Specify an output file base name. The suffix ".dc" is added automatically (and possibly a working directory name --see the following option). If this option is omitted the output code is printed in file scdc_out.dc. | ||
| -D <directory> | Specify a directory where the output file will be placed. The default is the current directory. | ||
| -import_action | Import the SC action table in the DC code and generate actcall statements in the DC definition table instead of inserting actions from action table into SC boolean equations. | ||
| -header | Generate an additional file (named game.header) to get the prototype of the node created in order to import it in a surround application. |
This report describes the scdc processor principles.
This paper illustrates the use of the common format DC to program an
application in combining several synchronous formalisms.
Abstract:
This paper describes a multi-formalism experiment design in the domain
of real-time control systems. It uses several synchronous languages on
a case study which is a realistic industrial example. Co-simulation is
provided though the use of a common format, and automatic distributed code
generation is experimented in the context of the graphical environment
of the data-flow language Signal.
The DC format belongs to the family of common formats for synchronous
languages. It is a high level format dedicated to both the representation
of data flow synchronous programs, and to boolean equational representation
of imperative languages. It is used as internal format for programs written
in Lustre, Signal and Esterel and so allows tools to be shared.
The main object handled in DC format are flows. A program receives
input flows and computes output flow, possibly using internal flows; each
flow being computed wrt an activation condition(i.e. a boolean flow) acting
as clock. Systems of flow definitions are structured into \fInodes\fR and
nodes are themself gathered into packages.
The dchdl processor translates each node of a package into a Verilog module or a Vhdl pair entity/architecture. For the time being, full DC format is not translated into HDL code. Some restrictions occur concerning procedure calls and sub node calls. Nevertheless, the DC format remains "abstract" since it supports external user defined types, constants and functions. So, concrete definitions of these external objects must be provided to complement the HDL code generated. Moreover, each external function call generates a verilog module call or a Vhdl function call, and so the user must supply the definition of such modules and functions. By default, dchdl generates Verilog code. Typical use is:
dchdl game.dc
| -datafile | Generates an include directive to import definitions of user types and constants declared in the DC node. The included file is named: node_name_data.v | ||
| -8bit | Declares integer being 8 bits length using a `define directive --Verilog only. | ||
| -16bit | Declares integer being 16 bits length using a `define directive --Verilog only. | ||
| -32bit | Declares integer being 32 bits length using a `define directive --Verilog only. | ||
| -initial | Generates an initial statement in order to initialize registers. This option is useful to enter simulators and some verification tools as smv model checker. --Verilog only. | ||
| -sorted | Generates the combinatorial part of the output code as a concurrent statement (within a process in Vhdl and within an always statement in Verilog). This option requieres the DC equation system to be sorted. Default is to generate a concurrent statement for each equation (i.e concurrent signal assignment in Vhdl and continous assignement in Verilog) which don't need the DC equation system being sorted. | ||
| -vhdl | Generates Vhdl output code instead of Verilog code (the default). |
This paper gathers the dchdl processor principles.
Abstract:
This paper suggests how synchronous reactive languages can be compiled
into hardware description languages. We implemented a dchdl processor
dedicated to this translation.
DC format is a common compilation format for synchronous reactive languages,
either data flow oriented or imperative. The processor can generates either
Vhdl and Verilog code for reactive programs expressed in DC. Synchronous
reactive languages are well suited to design hardware systems, as they
have a clear mathematical semantics on one hand, and they share a number
of notions (Mealy machine interpretation, logical clocks, ....). Popular
model-checkers used in the domain of hardware verification actually restrict
the expressive power of the HDL designs they accept to something very close
to the target space of our translations, and so essentially to synchronous
reactive designs. In addition to interface to these model-checkers for
synchronous programs the dchdl processor also allows connections
to hardware simulators and synthesis tools accepting Vhdl or Verilog code
like the one we produce, with obvious applications in electronic CAD design.