C to VHDL Translation Within the HybridThreads System

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 • 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