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