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 Operations C’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 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