1. C to VHDL Translation Within the HybridThreads System Presented by: Fabrice Baijot Jim Stevens

2. Overview Goals Initial Research Hardware Thread Model C-- GCC HIF Future Work

3. 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

4. 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

5. Initial Research Related Work – SPARK Their approach – Good or bad? – Others Their approach – Good or bad?

6. Initial Research Initial Considerations – C Starting point Most familiar among system programmers/designers – Context Hardware Threads HybridThreads System FPGA

7. Initial Research – Primitive Operations C’s Set of Operators – Arithmetic – Assignment – Logical/Relational – Bitwise Reduced Complexity – Integers and booleans only

8. Initial Research – Control Flow If-else Loops Switch – Side Effects ?

9. 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

10. Initial Research – Finite State Machines Methodology – Parallelizable operations become one state – State transitions Complexity – Simple – Follows control flow – Overhead: storing state

11. Hardware Thread Model FSMs Function call model Use of hardware thread interface Compile-time analysis Limitations

12. 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

13. Function Call Model Compiling C without functions is of limited usefulness Desire a general purpose function model to make porting applications to HybridThreads easier

14. 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)

15. 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

16. Compile Time Analysis Eventual goal is to have the compiler analyze the program and generate a custom architecture for that program

17. 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

18. C-- QuickC-- Compiler – AST Parsed tokens including: – Scope information – Annotations Example Analysis – Redundant and superfluous information for our purposes – Need control flow information

19. 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

20. 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

21. C-- Examples

22. C-- Limitations – Weak documentation – Messy compiler internals (3 different languages!) – Hard to parse – No PowerPC backend – Slow development – Unpredictable output from LCC

23. C-- Lessons Learned – Need easy access to variables – Need predictable intermediate form – Control flow information is valuable – Avoid redundancy – Keep it simple

24. 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

25. GCC Flow of program through compiler Diagram goes here

26. GCC Compiler Internals – GIMPLE Nodes – SSA Annotations – Scope, size, type, length, etc. Macros – Traverse GIMPLE tree – Return important information

27. GCC Current Status – Supports: Primitive operations Control flow operations One-dimensional arrays Structs Function calls System calls Integers only!

28. GCC Examples

29. 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

30. HIF Why a HIF HIF Specifications Expressive Power HIF2VHDL Examples

31. 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

32. C2VHDL Description – Flow – Interfaces – Assumptions Translator Status Examples Related Work – Compare and Contrast Publications References

33. 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

34. Acknowledgements David Andrews Ron Sass Erik Anderson Jason Agron Wesley Peck Ed Komp Lance Feagan