SF2VHD: A Stateflow to VHDL Translator - PowerPoint PPT Presentation

1 / 22
About This Presentation
Title:

SF2VHD: A Stateflow to VHDL Translator

Description:

Library of datapath functional units based on precisely characterized modules ... MDL file streamed into object-based representation of state machine ... – PowerPoint PPT presentation

Number of Views:84
Avg rating:3.0/5.0
Slides: 23
Provided by: kevinc99
Category:

less

Transcript and Presenter's Notes

Title: SF2VHD: A Stateflow to VHDL Translator


1
SF2VHDA Stateflow to VHDL Translator
  • Kevin CameraBerkeley Wireless Research
    CenterOctober 6, 2000

2
Overview
  • Ultimate goal generate a single-chip radio from
    its algorithmic description by turning the key
  • Fundamental components
  • Library of datapath functional units based on
    precisely characterized modules
  • Intelligent and predictable placement, routing,
    and clock tree generation
  • Accurate prediction of overall hardware
    efficiency (including power, speed, area, etc.)
  • Effortless definition and synthesis of control
    logic

3
Program Characteristics
  • Written in C with flex/bisonfront end
  • Built in UNIX, portable to Win32
  • Execution divided into parsingand code
    generation
  • MDL file streamed into object-based
    representation of state machine
  • Object structure traversed to generate VHDL
  • Stored in SSHAFT CVS repository
  • /tools/sshaft/src/sf2vhd on Sun cluster

4
Design Flow Integration
  • Design flow primarily driven by subsystem
    parameters in Simulink
  • The ICMacro type marks a subsystem as one which
    can be created by a generator
  • Setting the generator to SF2VHD will have the
    flow call the program and synthesize the results
  • All Stateflow charts must be in a separate
    library than the chip design itself
  • Alternatively, can run SF2VHD manually and use
    the generator for synthesizing custom VHDL

5
Stateflow Charts
  • Charts are the highest level of the hierarchy
  • Each chart will become an entity in its own VHDL
    file
  • Charts must have unique names
  • No more than 100 charts in the whole design

6
Stateflow States
  • States can be hierarchical
  • Each parent (including the chart) must have an
    initial transition
  • Only OR decomposition is allowed
  • History junctions are not supported
  • Evaluation is top-down
  • Actions are allowed for entry and during (exit
    not supported)

7
Stateflow Transitions
  • No conditions or junctions are allowed on initial
    transitions
  • Regular transitions can only have conditions and
    condition actions
  • Events are currently not supported (implied
    clocks)
  • Transition-taken actions are not implemented
  • Transitions must be external
  • Junctions are allowed, although not shown here

8
Stateflow Data
  • Data can be
  • Input
  • Output
  • Local
  • Constant
  • Inputs and outputs become ports of the VHDL
    entity
  • Data ranges should be explicitly set on integers
  • Initial values are used to determine reset
    behavior
  • Data could be defined local to each state, but
    SF2VHD flattens all data during parsing

9
Stateflow MDL Syntax
Stateflow chart id 2 name "substates/subs
tates" windowPosition 72 104.25 465
574.5 viewLimits 1.875 423.375 0
538.5 screen 1 1 1280 1024 1.333333333333333
treeNode 0 3 0 0 firstTransition 9 machine
1 decomposition CLUSTER_CHART firstData 19
chartFileNumber 1 state id 3 labelString
"Saturate\n" "entry modeout
0" position 26.75 69.19 342.5
192.82 fontSize 10 chart 2 treeNode 2 4 0
6 firstTransition 10 type OR_STATE decompos
ition CLUSTER_STATE transition
id 9 labelPosition 90.23 26.13 6.75
13.5 fontSize 10 src intersection 0 0
0 0 90.5 15.75 dst id 3 intersectio
n 1 0 -1 0.18 90.5 69.19 midPoint 90.5
32.11019662417016 chart 2 linkNode 2 0
13 dataLimits 88.09 92.90 15.75 69.19
  • Textual description of Stateflow charts is
    included at the end of the MDL file
  • Less than1/3 of statements are used by SF2VHD
  • Mostly graphical information
  • Most important information
  • Node numbers
  • Hierarchy data
  • Label strings and code

10
Mapping Methodology
  • Every local and output datum has a latched
    signal, a next signal, and a variable
  • Boolean data is implemented as BIT
  • All uint and int data is implemented as INTEGER
    with range as specified in Stateflow
  • Selection of data types limits available
    operations, will be changed to IEEE types later

constant limit integer 16 signal mode_SIG
bit signal count_NEXT integer range 0 to
15 variable modeout_VAR bit
11
Mapping Methodology
  • Each state is represented in a case statement
  • If/Elsif block checks all transitions top-down
  • Junctions result in cascaded if/else statements
  • Else statement contains during actions for
    current state and all parents

case state_SIG is when 0 gt -- State
State1 if ( trans1 ) then -- Enter new
state elsif ( trans2 ) then -- Junction
reached if ( trans3 ) then -- Enter new
state end if else -- During
actions end if
12
Mapping Methodology
  • For each successful transition
  • All transition conditional actions are performed
  • Destination state is found (may traverse child
    states)
  • All state entry actions are performed for
    destination state and all parent states

if ( trans1 ) then -- Conditional actions --
Set destination state -- All parent entry
actions -- New state entry actions elsif (
trans2 ) then -- Conditional actions -- Set
destination state -- All parent entry
actions -- New state entry actions . . .
13
VHDL Code Structure Entity
  • Entity declaration
  • Ports for each input and output, plus clock and
    reset

entity substates is port(signal mode in bit
signal modeout out bit signal count
out integer range 0 to 15 signal SFRESET
in bit signal BCLK in bit) end
substates
14
VHDL Code Structure Behavior
process logical(all_signals) . . . mode_VAR
mode_SIG count_VAR count_SIG state_VAR
state_SIG . . . case STATE_VAR is . . . if
(mode_VAR 1) then count_VAR
count_VAR 1 state_VAR 3 . .
. end case . . . count_NEXT lt
count_VAR state_NEXT lt state_VAR . . . end
process
  • Logical process (sensitive to all data signals)
  • Initialize all variables to the previously
    latched signal value
  • Make all next state and output operations on
    variables
  • Assign outputs and next state signals to results

15
VHDL Code Structure Behavior
process sync(BCLK) if (rising(BCLK)) then if
(SFRESET 1) then . . . count_SIG
lt count_NEXT state_SIG
lt state_NEXT . . . else . .
. count_SIG lt 0 state_SIG lt 0 . .
. end if end if end process
  • Synchronous process (sensitive to only the clock)
  • Latch all output and next state values to
    registers
  • or if reset is asserted low, latch initial
    conditions

16
Design Limitations
  • Limited number of objects can be handled
  • No conditions can be placed on initial
    transitions
  • No support for events (yet?)
  • State exit and transition-taken actions ignored
  • History junctions and AND states not supported
  • Transitions must be external and must be
    contained in the parent state
  • Shifting is not supported with current data types

17
Synthesis
  • Synthesis is performed within the flow using
    Design Compiler
  • Rough estimates of area and timing
  • VHDL should be compatible with other synthesis
    tools
  • No Synopsys-specific statements or packages are
    used

18
State Machine Architecture
  • Extended finite state machine
  • Almost any C operator can be used in action
    statements
  • Z A B C could be placed on any transition?
  • Mealy-style outputs
  • Outputs are pure combinational functions of
    inputs and current state
  • However, outputs and local data are latched to
    preserve previous values

19
Logical Verification
  • Design flow generates an HSPICE netlist from the
    EDIF output of Design Compiler
  • EPIC simulations are compared with Simulink test
    vectors
  • Simulink vectors converted to EPIC format via
    m2epic.pl
  • Verification script reports all mismatches
    between Simulink and EPIC outputs
  • Early support for direct VHDL simulation with
    Synopsys VSS

20
Reference Design SCF1
  • Digital decimation filter designed by Paul Husted
  • Four verified charts
  • Data_Control (28 states)
  • Pilot_Control (25 states)
  • Pilot_Ack_Control (11 states)
  • PLL_Control (6 states)

21
Hardware Efficiency
22
Future Work
  • Better data structures within the program to
    eliminate the limited number of objects
  • IEEE data types in VHDL to allow the full range
    of operators
  • Improved error checking and reporting
  • Support for events
  • More reference designs!
  • Investigate new applications (i.e. protocol
    stacks)
Write a Comment
User Comments (0)
About PowerShow.com