Mapping Chart Semantics to HDL

On this page…
Software Realization of Chart Semantics Hardware Realization of Stateflow Semantics Restrictions for HDL Realization

Software Realization of Chart Semantics

The top-down semantics of a chart describe how the chart executes. chart semantics describe an explicit sequential execution order for elements of the chart, such as states and transitions. These deterministic, sequential semantics map naturally to sequential programming languages, such as C. To support the rich semantics of a chart in the Simulink environment, it is necessary to combine the state variable updates and output computation in a single function.

Consider the example model shown in the following figure. The root level of the model contains three blocks (Sum, Gain and a Stateflow chart) connected in series.

The chart from the model is shown in the following figure.

The following Real-Time Workshop^® C code excerpt was generated from this example model. The code illustrates how the chart combines the output computation and state-variable update.

/* Output and update for atomic system: '<Root>/Chart' */
void hdl_ex_Chart(void)
{
  /* Stateflow: '<Root>/Chart' */
  switch (hdl_ex_DWork.Chart.is_c1_hdl_ex) {
   case hdl_ex_IN_Off:
    if (hdl_ex_B.Gain >= 100.0) {
      hdl_ex_DWork.Chart.is_c1_hdl_ex = (uint8_T)hdl_ex_IN_On;
    }

    break;

   case hdl_ex_IN_On:
    if (hdl_ex_B.Gain < 100.0) {
      hdl_ex_DWork.Chart.is_c1_hdl_ex = (uint8_T)hdl_ex_IN_Off;
    } else {
      hdl_ex_B.y = hdl_ex_B.Gain;
    }

    break;

   default:
    hdl_ex_DWork.Chart.is_c1_hdl_ex = (uint8_T)hdl_ex_IN_On;
    break;
  }
}

The preceding code assigns either the state or the output, but not both. Values of output variables, as well as state, persist from one time step to another. If an output value is not assigned during a chart execution, the output simply retains its value (as defined in a previous execution).

Back to Top

Hardware Realization of Stateflow Semantics

The following diagram shows a sequential implementation of Stateflow semantics for output/update computations, appropriate for targeting the C language.

A mapping from Stateflow semantics to an HDL implementation demands a different approach. The following requirements must be met:

• Requirement 1: Hardware designs require separability of output and state update functions.

• Requirement 2: HDL is a concurrent language. To achieve the goal of bit-true simulation, execution ordering must be correct.

To meet Requirement 1, an FSM is coded in HDL as two concurrent blocks that execute under different conditions. One block evaluates the transition conditions, computes outputs and speculatively computes the next state variables. The other block updates the current state variables from the available next state and performs the actual state transitions. This second block is activated only on the trigger edge of the clock signal, or an asynchronous reset signal.

In practice, output computations usually occur more often than state updates. The presence of inputs drives the computation of outputs. State transitions occur at regular intervals (whenever the chart is activated).

The following diagram shows a concurrent implementation of Stateflow semantics for output and update computations, appropriate for targeting HDL.

The HDL code generator reuses the original single-function implementation of Stateflow semantics almost without modification. There is one important difference: instead of computing with state variables directly, all state computations are performed on local shadow variables. These variables are local to the HDL function update_chart. At the beginning of the update_chart functions, current_state is copied into the shadow variables. At the end of the update_chart function, the newly computed state is transferred to registers called collectively next_state. The values held in these registers are copied to current_state (also registered) when update_state is called.

By using local variables, this approach maps Stateflow sequential semantics to HDL sequential statements, avoiding the use of concurrent statements. For instance, local chart variables in function scope map to VHDL variables in process scope. In VHDL, variable assignment is sequential. Therefore, statements in a Stateflow function that uses local variables can safely map to statements in a VHDL process that uses corresponding variables. The VHDL assignments execute in the same order as the assignments in the Stateflow function. The execution sequence is automatically correct.

Back to Top

Restrictions for HDL Realization

Some restrictions on chart usage are required to achieve a valid mapping from a chart to HDL code. These are summarized briefly in Quick Guide to Requirements for Stateflow HDL Code Generation. The following sections give a more detailed rationale for most of these restrictions.

Self-Contained Charts

The Stateflow C target allows generated code to have some dependencies on code or data that is external to the chart. Stateflow charts intended for HDL code generation, however, must be self-contained. Observe the following rules for creating self-contained charts:

• Do not use C math functions such as sin and pow. There is no HDL counterpart to the C math library.

• Do not use calls to functions coded in any language other than HDL. For example, do not call MATLAB functions for a simulation target, as in the following statement:

  ml.disp("hello") 

• Do not use custom code. There is no mechanism for embedding external HDL code into generated HDL code. Custom C code (user-written C code intended for linkage with C code generated from a Stateflow chart) is ignored during HDL code generation.

  See also Interfacing Subsystems and Models to HDL Code.

• Do not use pointer (&) or indirection (*) operators. Pointer and indirection operators have no function in a chart in the absence of custom code. Also, pointer and indirection operators do not map directly to synthesizable HDL.

• Do not share data (via Data Store Memory blocks) between charts. The coder does not map such global data to HDL, because HDL does not support global data.

Charts Must Not Use Features Unsupported by HDL

When creating charts intended for HDL code generation, follow these guidelines to avoid using Stateflow features that cannot be mapped to HDL:

• Avoid recursion. While charts permit recursion (through both event processing and user-written recursive graphical functions), HDL does not allow recursion.

• Do not use Stateflow and local events. These event types do not have equivalents in HDL. Therefore, these event types are not supported for HDL code generation.

• Avoid unstructured code. Although charts allow unstructured code to be written (through transition flow diagrams and graphical functions), this usage results in goto statements and multiple function return statements. HDL does not support either goto statements or multiple function return statements.

• Select the Execute (enter) Chart At Initialization chart property. This option executes the update chart function immediately following chart initialization. The option is needed for HDL because outputs must be available at time 0 (hardware reset). You must select this option to ensure bit-true HDL code generation.

Back to Top

Quick Guide to Requirements for Stateflow HDL Code Generation

Using Mealy and Moore Machine Types in HDL Code Generation

© 1984-2010- The MathWorks, Inc.    -   Site Help   -   Patents   -   Trademarks   -   Privacy Policy   -   Preventing Piracy   -   RSS