1. Instructor: Dr. Phillip Jones
CPRE 583 Reconfigurable Computing Lecture 6: Wed 10/21/2009 (Design Patterns)
Instructor: Dr. Phillip Jones
Reconfigurable Computing Laboratory
Iowa State University
Ames, Iowa, USA

2. Overview
Class Projects
Common Design Patterns

3. Project Grading Breakdown
60% Final Project Demo
30% Final Project Report
30% of your project report grade will come from your 5 project updates. Friday’s midnight
10% Final Project Presentation

4. Initial Project Proposal Slides (5-10 slides)
Project team list: Name, Responsibility (who is project leader)
Project idea
Motivation (why is this interesting, useful)
What will be the end result
High-level picture of final product
High-level Plan
Break project into mile stones
Provide initial schedule: I would initially schedule aggressively to have project complete by Thanksgiving. Issues will pop up to cause the schedule to slip.
System block diagrams
High-level algorithms (if any)
Concerns
Implementation
Conceptual
Research papers related to you project idea

5. Project Update The current state of your project write up
Even in the early stages of the project you should be able to write a rough draft of the Introduction and Motivation section
The current state of your Final Presentation
Your Initial Project proposal slides (Due Fri 10/23). Should make for a starting point for you Final presentation
What things are work & not working
What roadblocks are you running into

6. Projects Expectations DAC (Design Automation Conference)
Working system
Write up that can potentially be submitted to a conference
Will use DAC format as write up guide line
15-20minute PowerPoint Presentation
DAC (Design Automation Conference)
Due Date: 5pm (MT) Monday 12/8/2008?
Cash Prizes

7. Projects: Relevant conferences
FPL
FPT
FCCM
DAC
ICCAD
Reconfig
RTSS
RTAS

8. Projects: Target Timeline
Teams Formed and Idea: Wed 10/21
Project idea in Power Point 3-5 slides
Motivation (why is this interesting, useful)
What will be the end result
High-level picture of final product
Project team list: Name, Responsibility
High-level Plan: Fri 10/23 (9pm)
Power Point 5-10 slides
System block diagrams
High-level algorithms (if any)
Concerns
Implementation
Conceptual

9. Projects: Target Timeline
Work on projects: 10/ /12
Weekly update reports
More information on updates will be given
Presentations: Last Wed Fri of class
Present / Demo what is done at this point
15-20 minutes (depends on number of projects)
Final write and HW turn in: Day of final (TBD)

10. What you should learn
Introduction to common Design Patterns & Compute Models

11. Outline
Design patterns
Why are they useful?
Examples
Compute models

12. Outline
Design patterns
Why are they useful?
Examples
Compute models

13. References Reconfigurable Computing (2008) [1]
Chapter 5: Compute Models and System Architectures
Scott Hauck, Andre DeHon
Design Patterns for Reconfigurable Computing [2]
Andre DeHon (FCCM 2004)
Type Architectures, Shared Memory, and the Corollary of Modest Potential [3]
Lawrence Snyder: Annual Review of Computer Science (1986)

14. Design Patterns
Design patterns: are a solution to reoccurring problems.

15. Reconfigurable Hardware Design
“Building good reconfigurable designs requires an appreciation of the different costs and opportunities inherent in reconfigurable architectures” [2]
“How do we teach programmers and designers to design good reconfigurable applications and systems?” [2]
Traditional approach:
Read lots of papers for different applications
Over time figure out ad-hoc tricks
Better approach?:
Use design patterns to provide a more systematic way of learning how to design
It has been shown in other realms that studying patterns is useful
Object oriented software [93]
Computer Architecture [79]

16. Common Langue
Provides a means to organize and structure the solution to a problem
Provide a common ground from which to discuss a given design problem
Enables the ability to share solutions in a consistent manner (reuse)

17. Describing a Design Pattern [2]
10 attributes suggested by Gamma (Design Patters, 1995)
Name: Standard name
Intent: What problem is being addressed?, How?
Motivation: Why use this pattern
Applicability: When can this pattern be used
Participants: What components make up this pattern
Collaborations: How do components interact
Consequences: Trade-offs
Implementation: How to implement
Known Uses: Real examples of where this pattern has been used.
Related Patterns: Similar patterns, patterns that can be used in conjunction with this pattern, when would you choose a similar pattern instead of this pattern.

18. Example Design Pattern
Coarse-grain Time-multiplexing
Template Specialization

19. Coarse-grain Time-MultiplexingB M3 M1 M2 M1 M2 A B M3
Temp M3
Temp
Configuration 1
Configuration 2

20. Coarse-grain Time-Multiplexing
Name: Coarse-grained Time-Multiplexing
Intent: Enable a design that is too large to fit on a chip all at once to run as multiple subcomponents
Motivation: Method to share limited fixed resources to implement a design that is too large as a whole.

21. Coarse-grain Time-Multiplexing
Applicability:
Configuration can be done on large time scale
No feedback loops in computation
Feedback loop only spans the current configuration
Feedback loop is very slow
Participants:
Computational graph
Control algorithm
Collaborations: Control algorithm manages when sub-graphs are loaded onto the device

22. Coarse-grain Time-Multiplexing
Consequences: Often platforms take millions of cycles to reconfigure
Need an app that will run for 10’s of millions of cycles before needing to reconfigure
May need large buffers to store data during a reconfiguration
Known Uses:
Video processing pipeline [Villasenor]
“Video Communications using Rapidly Reconfigurable Hardware”, Transactions on Circuits and Systems for Video Technology 1995
Automatic Target Recognition [[Villasenor]
“Configurable Computer Solutions for Automatic Target Recognition”, FCCM 1996

23. Coarse-grain Time-Multiplexing
Implementation:
Break design into multiple sub graphs that can be configured onto the platform in sequence
Design a controller to orchestrate the configuration sequencing
Take steps to minimize configuration time
Related patterns:
Streaming Data
Queues with Back-pressure

24. Coarse-grain Time-MultiplexingB M3 M1 M2 M1 M2 A B M3
Temp M3
Temp
Configuration 1
Configuration 2

25. Template Specialization
Empty LUTs
A(1)
A(0)
LUT
LUT
LUT
LUT - - - -
C(3)
C(2)
C(1)
C(0)
Mult by 3
Mult by 5
A(1)
A(1)
A(0)
A(0)
LUT
LUT
LUT
LUT
LUT
LUT
LUT
LUT 3 6 9 1 1 1 1 5 10 15 1 1 1 1
C(3)
C(2)
C(1)
C(0)
C(3)
C(2)
C(1)
C(0)

26. Template Specialization
Name: Template Specialization
Intent: Reduce the size or time needed for a computation. (note primary difference from Template pattern is this pattern aims to minimize run-time reconfiguration)
Motivation: Use early-bound data and slowly changing data to reduce circuit size and execution time.

27. Template Specialization
Applicability: When circuit specialization can be adapted quickly
Example: Can treat LUTs as small memories that can be written. No interconnect modifications
Participants:
Template cell: Contains specialization configuration
Template filler: Manages what and how a configuration is written to a Template cell
Collaborations: Template filler manages Template cell

28. Template Specialization
Consequences: Can not optimize as much as when a circuit is fully specialize for a given instance. Overhead need to allow template to implement several specializations.
Known Uses:
Multiply-by-Constant
String Matching
Implementation: Multiply-by-Constant
Use LUT as memory to store answer
Use controller to update this memory when a different constant should be used.

29. Template Specialization
Related patterns:
CONSTRUCTOR
EXCEPTION
TEMPLATE

30. Template Specialization
Empty LUTs
A(1)
A(0)
LUT
LUT
LUT
LUT - - - -
C(3)
C(2)
C(1)
C(0)
Mult by 3
Mult by 5
A(1)
A(1)
A(0)
A(0)
LUT
LUT
LUT
LUT
LUT
LUT
LUT
LUT 3 6 9 1 1 1 1 5 10 15 1 1 1 1
C(3)
C(2)
C(1)
C(0)
C(3)
C(2)
C(1)
C(0)

31. Next Lecture
Compute Models

32. Slides in Progress
Need to revise this lecture with figures, and useful animations
Add some non-FPGA systems, maybe not since GARP, and PipeRench were discussed in last lecture. Perhaps just mention again
Main reason other archs are not used is economy of scales. Lots of FPGAs are manufacture, thus lowing cost and enable the use of state of the art fab technology (given high performance

33. Reducing Configuration Transfer Time
Arch approach
Partial reconfiguration
Compression

34. Configuration Security
Arch approach
Partial reconfiguration
Compression