An Analysis of Hardware Generation with Stateflow and VCC

1
An Analysis of Hardware Generation with Stateflow
and VCC

• Kevin CameraEE249 Course Project12/9/2000

2
Project Goals

• Would like to answer the following questions
• How do hierarchical descriptions affect hardware?
• How do CFSM/Stateflow models of computation
  affect hardware?
• Can the tools do any better?

3
Background VCC

• ModelCFSM
• HierarchyNo
• GeneratorbuildVlog

4
Background buildVlog

• Pre-beta development release for VCC 2.0
  (provided by Roberto Passerone)
• Still a couple lingering bugs
• Generates Verilog for any cell with a Clearbox
  STD view
• Separate tasks for the next-state and each output
  function

5
Background Stateflow

• ModelStateCharts
• HierarchyLots
• GeneratorSF2VHD

6
Background SF2VHD

• Masters project with BWRC design flow group
• Generates VHDL for any Stateflow chart
• Doesnt support AND-decomposition (concurrency)
• Apparently has severe syntax limitations
• Flattens design according to complex Stateflow
  semantics

7
Evolution of a Benchmark

• Proprietary automatic gain controller

8
Evolution of a Benchmark

• Problems with AGC
• SF2VHD choked on all the unanticipated syntax
• Actually only one level of hierarchy!
• VCC porting time would be significant

9
Evolution of a Benchmark

• Custom-made transceiver arbiter

10
Evolution of a Benchmark

• VCC translation of arbiter

11
Evolution of a Benchmark

• Benefits of custom arbiter
• Offered first look at relative efficiencies and
  synthesized hardware
• Done in feasible amount of time (few days)
• Problems
• Too small to show any significant effects

12
Evolution of a Benchmark

• TCI transmitter/receiver controllers

13
Evolution of a Benchmark

• Approximated Stateflow translation

14
Evolution of a Benchmark

• Benefits of TCI example
• VCC already implemented
• Good example of merging CFSMs into synchronous
  hierarchy
• Larger example than homemade arbiter
• Problems
• No time to convert MAC or Transport layers
• Couldnt translate Whitebox C blocks

15
Results
16
Interpretation

• Arbiter design came out much smaller and faster
  using VCC CFSMs
• Verilog code was cleaner and more directly
  mapped
• Hierarchy in Stateflow added phantom states
• Stateflow implementation uses a synchronous reset
  which added plenty of gates

17
Interpretation

• Merged Stateflow translation of the TCI
  controllers was much smaller and faster
• Independent, communicating CFSMs each require
  their own state logic and registers
• Stateflow design is statically scheduled and
  eliminates much communication overhead
• VCC design was made with software in mind not
  hardware

18
Conclusions

• Never use tools in development for a class
  project
• Even worse when you are the one who has to recode
  and debug one
• 33-50 of time was spent fixing code or
  hand-patching HDL for synthesis

19
Conclusions

• It is extremely difficult to create benchmarks
  for this type of analysis
• Very time consuming to convert someone elses
  design
• Building your own results in almost identical
  implementations in either format

20
Conclusions

• Deep hierarchy does not seem useful for
  direct-mapped designs
• Couldnt even think of an example with depth
• Nested state doesnt propagate much further than
  one or two levels

21
Conclusions

• Statically scheduled, hierarchical state machines
  can be much more efficient than event-driven,
  communicating equivalents
• Reduced resources for state management
• Reduced state for managing input order
• Fewer inputs and outputs for acknowledgments
• Possibly artifact of software or hardware
  targeted design