1. The Garp Architecture and C Compiler Brought to you by Liao Jirong liaojiro@comp.nus.edu.sg http://www.comp.nus.edu.sg/~liaojiro T.J. Callahan J.R. Hauser & J. Wawrzynek, U.C. Berkeley

2. Outline Background The Garp Architecture The Compiler for the Garp Simulation result Summary

3. Background Emergence of reconfigurable hardware, FPGA,etc. Impressive speedups for various tasks DNA sequence matching, encryption,etc. Obstacles to be overcome configuration time, size, floating-point operations, compatibility of various implementations in the market ….. Past works -- PRISC, NAPA, PRISM, etc limited to specific application domains non full automatic compliation

4. The Big Picture Computation Kernel Processor (CPU) Coprocessor (FPGA, ASIC, etc) Application Non-Computation Kernel Compilation Compilation/synthesis communication

5. Working Flow of the Execution of the Kernel 1. Load a configuration 2. Copy any initial register data to coprocessor 3. Start execution on coprocessor 4. Copy result back to the processor 1, 2 & 4 are overhead.

6. Motivation Integrate reconfigurable hardware more closely with the processor Long reconfiguration times Low- bandwidth paths for data transfer Hardware design expertise

7. Assumption A few cycles of overhead for register data transferring is acceptable Coprocessor need its own direct path to the processor ’ s memory system impossible for the processor to do this Coprocessor need to be rapidly reconfigurable.

8. The Garp Architecture Single-issue MIPS processor core with reconfigurable hardware (coprocessor) Coprocessor is on the same die with processor Coprocessor and Processor share the same memory The reconfigurable hardware architecture and interfaces are designed Does not exist as real silicon (simulation only)

9. The Blueprint

10. The Garp Arch. (Cont) For general purpose applications Fit into an ordinary processing environment The main thread of control through a program is managed by the processor 1. configuration can be loaded only when coprocessor is idle 2. coprocessor can work independently 3. coprocessor execution can be halted or resumed 4. can not load configuration or access the coprocessor while it is active

11. The reconfigurable hardware Two-dimensional array of Blocks No. of row is implementation-specific upward-compatible fashion Interconnected by programmable wiring A fixed global clock - sequencer Configuration cache Memory buses Memory queues

13. Blocks Configurable Logic Block (CLB) 2-bit width 16 CLBs in a row is a 32-bit data path each up to 4 2-bit inputs (a<<10)|(b&c) can be implemented in one row Control blocks one for each row in the leftmost column serve as liaison Boolean Values for if-conversion used in hyperblock

14. Wires Vertical wire communicate blocks in the same column Horizontal communicate blocks in the same or adjacent rows Built-in carry chain support for addition, subtraction and comparison. Make multiplication and division by constant fairly efficient by multi-bit shift across a row The wire network is passive value cannot jump from one to another without passing through a logic block

15. Memory tricks Configuration cache hold recently displaced configurations reloading from cache requires 5 cycles only. can hole 4 full-sized configurations Wide path betwn coprocessor and memory data transfer and configuration load Memory bus 4 32-bit data bus and 1 32-bit address bus coprocessor is master of memory buses when active initiate one access every cycle Memory Queues

16. Compare Garp with other arch. VLIW Garp resemble VLIW Advantage over VLIW but doesn ’ t have VLIW ’ s per-cycle limits on instruction issue, functional units, or register file bandwidth. pipeline in Garp is more straightforward than software pipelining on VLIW: no function units competition problem for Garp maintain high performance for sequential code in processor Disadvantage over VLIW kernel size limit can not exploit ILP outside of loops

17. Garp V.S. Vector Garp resemble a memory-to-memory vector processor when synthesizing a vectorizable loop. Feedback loops can be constructed arbitrarily while vector units can handle only very speciallized recurrences Garp can easily handle data-dependent loop exits, which is a problem for vector arch.

18. Garp V.S. Superscalar Because of the modest number of instruction issue slots, Superscalar processor can not compete with the Garp coprocessor in cases with a large amount of ILP.

19. Any Question About Garp? For further details: Garp: A MIPS Processor with a Reconfigurable Coprocessor J.R. Hauser, J. Wawrzynek, IEEE FCCM 1997,

20. Automatic Compilation Standard ANSI C as input SUIF C compiler for the front-end phase parsing and standard optimizations Full automatic compliation

21. Compilation Flow Application Kernel selection Optimization & Synthesis Optimization kernel Non-kernel coprocessor processor Bit-stream Executable file

22. Kernel selection Loops The whole loop? -- NO loop size – too large contain some infrequent executed code -- longer load time -- longer interconnects operations cannot be implemented ILP limitation in basic block

23. Hyperblock Join all the basic blocks of a loop body by using prediction – boolean value Increase ILP Precedence edges array subscript analysis inter-procedural pointer analysis Contain the loop back edges avoid switching control from time to time

25. Hyperblock (Cont) Reject loops that speedup doesn ’ t make up the overhead by profiling and execution time estimate Exceptional exit cases execution continue on processor occur only a small fraction

26. Optimization Techs. Speculative loads crucial for pipelining Pipelining loop-carried dependencies simultaneous memory access Memory queues 3 memory queues buffering and reading ahead, writing behind non-cache-allocating

27. Configuration Synthesis Module mapping mapping groups of nodes in the DFG to compound modules in the configuration, minimize the size and its critical path Placement connect modules close to one another Generating the bit-stream file

28. Simulation Results 32-row array Adapted Ultrasparc processor Cycle-accurate simulator Model cache misses and interlocks.

29. Wavelet image compression

30. Gzip compression Gzip have irregular memory accesses reduce parallelism and prevent pipelining Each loop execute only a few cycles overhead cost more significant The overhead negates the benefit

31. Compilation time & Code expansion Compilation time typically much less than double that of compiling for software only Code size typically increase from 10 to 50 percent wavelet benchmark – 16 percent

32. Garp V.S. Ultrasparc Ultrasparc a four-way superscalar, 167Mhz Garp implemented using the same VLSI process 133Mhz Wavelet Garp is 68% faster than Ultrasparc Gzip Ultrasparc is 14% faster than Garp

33. Garp V.S. Ultrasparc (Cont) Hand-coded functions Garp has great potential

34. Future More experiments over a broader range of benchmark Development of new optimizations Find out strengths and weaknesses of the Garp architecture

35. Summary The Garp Architecture processor + coprocess configuration cache memory queues high-bandwidth, low-latency data access Synthesis Compiler for Garp

36. The End Thank you! Any feedback will be appreciated liaojiro@comp.nus.edu.sg http://www.comp.nus.edu.sg/~liaojiro