SF2VHD: A Stateflow to VHDL Translator

1
SF2VHD A Stateflow to VHDL Translator
wait_for_next_reader
Motivation BWRC single-chip radios can be
designed entirely in Simulink using the SSHAFT
design flow methodology. However, on-chip
control blocks cannot be directly mapped and
characterized like datapath components. SF2VHD
provides a path from Stateflow control
descriptions to VHDL, which can then be
synthesized and integrated using standard
techniques with Design Compiler. Role in Design
Flow ICMake calls SF2VHD on each Simulink file
that contains Stateflow. With respect to the
design flow, the translator will be fired if an
ICMacro subsystem has Stateflow in its
generator property. Please refer to the design
flow posters or ask for more informationon how
the flowhandles differenttypes of macrocells.
Functionality sf2vhd infile.mdl out_dir/ The
program takes an MDL file containing Stateflow
definitions as an input. One VHDL file is
generated for each Stateflow chart in the design
and placed in the specified argument directory.
Each VHDL file and its corresponding entity are
named after the Stateflow chart (which implies
that chart names must be unique). VHDL Code
Structure The entitys port declaration is taken
directly from the Stateflow chart interface. The
clock and reset ports are implicit in the flow,
and are added automatically. The components
behavior is defined in a single architecture
block, composed of two processes. A logical
process uses a case statement to define all
next-state and output actions. It also includes
a synchronous reset which forces all signals to
their Stateflow initial values. The other
process handles the clocking operation. The
overall state machine architecture is
Mealey-style with persistent (latched) outputs.

• Limitations
• Stateflow is a very rich and complex language
  with many redundant or hardware-unfriendly
  features like C function calls. To reduce the
  complexity of the translator itself and to
  encourage efficient VHDL, several Stateflow
  features are not supported.
• State hierarchy is allowed, but transitions
  across hierarchy levels are discouraged to
  preserve semantics
• AND decomposition (concurrent processes) of
  substates is not supported whatsoever
• History junctions are not allowed
• Asynchronous events are not supported (although
  implementation could be straightforward with
  external support in the design flow)
• State exit actions and transition-taken actions
  are not supported for simplicity (features are
  redundant)
• Results
• SF2VHD has been successfully used and verified on
  a digital decimation filter test chip and a
  physical-layer radio for the TCI project.

Conclusions The design process of this tool
clearly demonstrated the tradeoffs between
convenience for the chip designer and
straightforward mapping to hardware. Most
Stateflow features are redundant and are provided
simply to reduce the size of the description.
However, they made the tool and potentially the
hardware more complex. The approach taken here
was to start from the Stateflow side, favoring
full support for the designer. This proved to be
a difficult task, particularly with respect to
dynamic inter-expression data type conversion. A
much simpler tool could have been designed if a
Stateflow template was chosen to match a
well-known VHDL format, but this would be even
more difficult for the designer than hand-writing
VHDL code. With all said and done, it was shown
that efficient hardware can be derived from a
complex Stateflow description. One exception,
the Pilot machine, shows that the designer
still must show some caution in the use of
arithmetic in a design. In this case,
comparisons on multiple addition results caused a
severe critical path delay.
!(interested)
interested