HomeProjectsPeoplePublicatons
Search:
   
 

SF2VHD - A Stateflow to VHDL Translation Tool

The master's thesis behind SF2VHD is complete, and you can read or download the PDF version for complete information about the tool. The thesis corresponds to version 3.0 in the SSHAFT CVS repository.

The following page will mostly cover the usage and design limitations of the tool, and should be used as a reference for users of the SSHAFT design flow.

Purpose:

Our design flow at BWRC starts with the algorithmic design and simulation of a radio system using Simulink (part of the Matlab suite of tools). The ultimate goal of our design environment is to achieve top-to-bottom synthesis of an entire Simulink description to a number of targets. Some typical targets are executable and source coded C programs, physical layout, and FPGA designs. The C code and executables can be provided by the Matlab target language compiler, which is used internally in the tool for simulation, or for compiling onto an embedded microprocessor. The physical layout is provided by our own custom scripts and cell libraries, which are used in the Cadence and Synopsys design environments and developed by the module / design flow group here at BWRC.  The FPGA target is still early in development, but will be the fundamental tool used by the BEE platform once it has been produced.

Within Simulink is another tool used for finite state machine design called Stateflow. Stateflow has its own rules and its own syntax, but is included as part of the same MDL file used by Simulink. Since the Stateflow machines in each design cannot automatically be referenced to existing modules in our cell library, it will have to synthesized by an HDL tool, such as Design Compiler, to be part of an ASIC or FPGA target.  The SF2VHD tool translates the Stateflow machine syntax into standard VHDL, so it can be incorporated into our existing design flow and maintain a turnkey synthesis of Simulink models into real-time prototypes or physical IC devices.

Limitations on Stateflow Design:

There are limitations to the features of Stateflow that are supported by the translator. Some are not supported because of fundamental inefficiencies in their equivalent hardware limitations, and others because they would require complex code to translate, and I am saving them for last (if at all).

The following features are not supported by SF2VHD, and will either cause the program to generate errors or will result in non-functional VHDL. Note that not all errors are trapped yet, so be careful to follow these guidelines.

  • Hierarchical substates are supported, under the following constraints:
    • You should not create any transitions across levels of hierarchy. This includes "sibling" states, which are at the same depth but with different parents. This restriction is a safety precaution due to the way Stateflow processes transitions. Stateflow evaluates transitions in hierarchical order of the destination state, starting from the top. The translator's VHDL code does not make this distinction in generating the if-then-else logic. It currently does not detect this situation, either. This issue may be fixed in a later version if it is a major hassle for the designer.
    • Only OR decomposition can be used for all states. This is due primarily to a lack of interest in AND decomposition, and the amount of work required to redesign the data structures to allow such states.
    • History junctions are not implemented, and may cause parse errors.
  • You may not put junctions on any default transitions (these are the ones with the dot that are activated when entering a state), and there can only be one default transition per state. This implies that there are no conditions on default transitions as well, since a single default transition cannot be prevented.
  • States may contain entry and during actions, but exit actions will be ignored.
  • All Stateflow action language is supported, but calling subroutine functions is not.
  • Events are not implemented. A warning will be printed if events are defined, but the program will continue to generate VHDL with an implied clock. Event support may be added later, but is not currently in progress.
  • Transitions may have condition expressions (those within square brackets '[]') and conditional actions (those within curly braces '{}') only. Transition-taken actions (the ones after a slash '/') are ignored, and will generate a non-fatal warning.
  • You cannot use any VHDL keywords for names of Stateflow objects. I don't have a list of them to post here, but some common names to avoid are BEGIN, END, WAIT, and SWITCH.
  • You must have a unique name for each Stateflow chart in a design. Although Matlab will let you use the same chart name at different levels in the subsystem hierarchy, the translator uses the chart name for the VHDL filename, and files will be overwritten without warning.

Usage:

The SF2VHD program takes two arguments: the name of a Simulink/Stateflow *.mdl file and the name of a directory in which all the corresponding VHDL files (one for each Stateflow chart in the design) will be written.  The paths can be absolute or relative, and the trailing slash on the directory name is optional. For complete instructions on how to use Stateflow with the BWRC design flow, take a look at this (useful, although outdated) tutorial.

Output:

A file will be generated for each Stateflow chart defined in the Simulink design, and placed in the directory specified by the last command line argument. It follows a standard synthesizable form of VHDL, with no optimizations for a particular synthesis tool.

Examples:

The latest "stable" release of the code is stored in the /tools/sshaft CVS repository. You will have to check the BWRC SSHAFT design flow documentation for how to set up CVS to get access to these files.