C to VHDL Translation Within the HybridThreads System
description
Transcript of C to VHDL Translation Within the HybridThreads System
C to VHDL Translation Within the HybridThreads System
Presented by:
Fabrice Baijot
Jim Stevens
Overview
Goals Initial Research Hardware Thread Model C-- GCC HIF Future Work
Goals
Develop a system to automatically generate hardware threads that can operate in the HybridThreads system
Make it easier to for software engineers to take advantage of FPGA
Keep the system as simple as possible Get it working
– Implementation language– Constraints on model
Initial Research
Programming Languages vs. HDLs– Similarities
Both “compiled” (software compiler vs. logic compiler) Instructions and control flow
– Differences HDLs for formal description of electronic circuits Programming language: CPU Explicit time and concurrency notations in HDLs
Initial Research
Related Work– SPARK
Their approach– Good or bad?
– Others Their approach
– Good or bad?
Initial Research
Initial Considerations– C
Starting point Most familiar among system programmers/designers
– Context Hardware Threads HybridThreads System FPGA
Initial Research
– Primitive OperationsC’s Set of Operators
– Arithmetic– Assignment– Logical/Relational– Bitwise
Reduced Complexity– Integers and booleans only
Initial Research
– Control Flow If-else Loops Switch
– Side Effects ?
Initial Research
Structural VHDL or FSMs?– Structural
Methodology– Simple operations as entities or processes– Go/Done Signals
Complexity– Complex compiler analysis– Go/Done introduces timing issues– Difficult to program
Initial Research
– Finite State Machines Methodology
– Parallelizable operations become one state– State transitions
Complexity– Simple– Follows control flow– Overhead: storing state
Hardware Thread Model
FSMs Function call model Use of hardware thread interface Compile-time analysis Limitations
Finite State Machines
Selected because it is closer to C We are favoring thread level parallelism
versus instruction level parallelism Operating under the assumption that C can
only be parallelized up to a certain point due to its sequential programming model
Function Call Model
Compiling C without functions is of limited usefulness
Desire a general purpose function model to make porting applications to HybridThreads easier
Function Call Model (continued)
Developed a stack-based model for run-time support of function calls
Was done as a class project for EECS 700: Reconfigurable Computing (w/ Lance Feagan)
Use of Hardware Thread Interface
Hardware Thread Interface provides two primary services:– Seemless abstraction of memory
Local memory in BRAM Global memory in DDR
– HybridThreads system calls
Compile Time Analysis
Eventual goal is to have the compiler analyze the program and generate a custom architecture for that program
Limitations
Very tedious to program by hand Large programs can take up too much FPGA
real-estate Synthesis time is large
– Compile-Test-Debug cycles take a long time
C--
QuickC-- Compiler – AST
Parsed tokens including:– Scope information– Annotations
Example Analysis
– Redundant and superfluous information for our purposes– Need control flow information
C--
– CFG Tree format with nodes describing:
– Operations inside functions– Stack and frame information– Control flow derived from edges
Example Analysis
– Hard to understand and parse– Does not include
Variable names, declarations, types Function names! Stack and section data
C--
– Extras Further modification of the compiler yielded
– Section names and data– Stack data– Local variables (names, types)– Function names– Example
LCC– Translation from C to C--– Written by Norman Ramsey
C--
Examples
C--
Limitations– Weak documentation– Messy compiler internals (3 different languages!)– Hard to parse– No PowerPC backend– Slow development– Unpredictable output from LCC
C--
Lessons Learned– Need easy access to variables– Need predictable intermediate form– Control flow information is valuable– Avoid redundancy– Keep it simple
GCC
Capabilities/Advantages– Many languages
C, C++, Objective-C, Fortran, Java, and Ada
– Many platforms Alpha, Linux, MIPS, PowerPC, Microsoft, etc.
– Get to pick compilation stage GENERIC, GIMPLE, RTL Anywhere inside and in between stages
GCC
Flow of program through compiler
Diagram goes here
GCC
Compiler Internals– GIMPLE
Nodes– SSA
Annotations– Scope, size, type, length, etc.
Macros– Traverse GIMPLE tree– Return important information
GCC
Current Status– Supports:
Primitive operations Control flow operations One-dimensional arrays Structs Function calls System calls Integers only!
GCC
Examples
GCC
Two-step HIF Generation– GCC HIF
Generated from GIMPLE tree Limited by GIMPLE structure
– Syntactically Correct HIF Generated from GCC HIF Python script Applies simple transformations
HIF
Why a HIF HIF Specifications Expressive Power HIF2VHDL Examples
Why a HIF?
Simple– The syntax is easy to parse– The semantics are closing related to the
underlying state machine model while hiding the low-level details
Stable starting point for back end– We have already moved from QC– to GCC– Back end is independent from the front end
C2VHDL
Description– Flow– Interfaces– Assumptions
Translator Status Examples Related Work
– Compare and Contrast Publications References
Future Work
Hifgen optimization and expansion– Redesign with efficiency in mind– Reduce the work of HIF preprocessor and
translator– Support greater subset of GIMPLE
Memory Model HIF to other HDLs Patches
Acknowledgements
David Andrews Ron Sass Erik Anderson Jason Agron Wesley Peck Ed Komp Lance Feagan