CPRE 583 Reconfigurable Computing Lecture 13: Fri 10/8/2010 (System Architectures)

1. CPRE 583Reconfigurable ComputingLecture 13: Fri 10/8/2010(System Architectures) Instructor: Dr. Phillip Jones (phjones@iastate.edu) Reconfigurable Computing Laboratory Iowa State University Ames, Iowa, USA http://class.ee.iastate.edu/cpre583/

2. Announcements/Reminders • Midterm: • Take home portion (40%) given Friday 10/15, due Tue 10/20 (midnight) • In class portion (60%) Wed 10/20 • Distance students will have in class portion given via a timed WebCT (2 hour) session (take on Wed, Thur or Friday). • Start thinking of class projects and forming teams • Submit teams and project ideas: Mon 10/11 midnight • Project proposal presentations: Fri 10/22 • MP3: PowerPC Coprocessor offload (release by Sat noon) • Problem 2 of HW 2 (released by Sat noon)

3. Initial Project Proposal Slides (5-10 slides) • Project team list: Name, Responsibility (who is project leader) • Team size: 3-4 (5 case-by-case) • 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

4. Projects Ideas: Relevant conferences • Micro • Super Computing • HPCA • IPDPS • FPL • FPT • FCCM • FPGA • DAC • ICCAD • Reconfig • RTSS • RTAS • ISCA

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

6. Weekly Project Updates • 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 presentation (Due Fri 10/22). Should make for a starting point for you Final presentation • What things are work & not working • What roadblocks are you running into

7. Projects: Target Timeline • Teams Formed and Idea: Mon 10/11 • 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/Proposal: Fri 10/22 • Power Point 5-10 slides • System block diagrams • High-level algorithms (if any) • Concerns • Implementation • Conceptual • Related research papers (if any)

8. Projects: Target Timeline • Work on projects: 10/22 - 12/8 • 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 up and Software/Hardware turned in: Day of final (TBD)

9. Project Grading Breakdown • 50% Final Project Demo • 30% Final Project Report • 30% of your project report grade will come from your 5-6 project updates. Friday’s midnight • 20% Final Project Presentation

10. Common Questions

11. Common Questions

12. Common Questions

13. Overview • Common System Architectures • Plus/Delta mid-semester feedback

14. What you should learn • Introduction to common System Architectures

15. Outline • Design patterns (previous lecture) • Why are they useful? • Examples • Compute models (Abstraction) • Why are they useful? • Examples • System Architectures (Implementation) • Why are they useful? • Examples

16. Outline • Design patterns (previous lecture) • Why are they useful? • Examples • Compute models (Abstraction) • Why are they useful? • Examples • System Architectures (Implementation) • Why are they useful? • Examples

17. References • Reconfigurable Computing (2008) [1] • Chapter 5: Compute Models and System Architectures • Scott Hauck, Andre DeHon

18. System Architectures • Compute Models: Help express the parallelism of an application • System Architecture: How to organize application implementation

19. Efficient Application Implementation • Compute model and system architecture should work together • Both are a function of • The nature of the application • Required resources • Required performance • The nature of the target platform • Resources available

20. Efficient Application Implementation Application (Image Processing) Platform 2 (FPGA) Platform 1 (Vector Processor)

21. Efficient Application Implementation Application (Image Processing) Compute Model System Architecture Platform 2 (FPGA) Platform 1 (Vector Processor)

22. Efficient Application Implementation Application (Image Processing) Compute Model System Architecture Platform 2 (FPGA) Platform 1 (Vector Processor)

23. Efficient Application Implementation Application (Image Processing) Data Flow Compute Model Streaming Data Flow System Architecture Platform 2 (FPGA) Platform 1 (Vector Processor)

24. Efficient Application Implementation Application (Image Processing) Data Flow Compute Model Streaming Data Flow System Architecture Platform 2 (FPGA) Platform 1 (Vector Processor)

25. Efficient Application Implementation Application (Image Processing) Compute Model System Architecture Platform 2 (FPGA) Platform 1 (Vector Processor)

26. Efficient Application Implementation Application (Image Processing) Data Parallel Compute Model Vector System Architecture Platform 2 (FPGA) Platform 1 (Vector Processor)

27. Efficient Application Implementation Application (Image Processing) Data Flow Compute Model Streaming Data Flow System Architecture Platform 2 (FPGA) Platform 1 (Vector Processor)

28. Efficient Application Implementation Application (Image Processing) Data Flow Compute Model Streaming Data Flow System Architecture Platform 2 (FPGA) Platform 1 (Vector Processor)

29. Efficient Application Implementation Application (Image Processing) X X Data Flow Compute Model + Streaming Data Flow System Architecture Platform 2 (FPGA) Platform 1 (Vector Processor)

30. Implementing Streaming Dataflow • Data presence • variable length connections between operators • data rates vary between operator implementations • data rates varying between operators • Datapath sharing • not enough spatial resources to host entire graph • balanced use of resources (e.g. operators) • cyclic dependencies impacting efficiency • Interconnect sharing • Interconnects are becoming difficult to route • Links between operators infrequently used • High variability in operator data rates • Streaming coprocessor • Extreme resource constraints

31. Data Presence X X +

32. Data Presence X X data_ready data_ready + data_ready

33. Data Presence X X FIFO FIFO data_ready data_ready + FIFO data_ready

34. Data Presence X X stall stall FIFO FIFO data_ready data_ready + FIFO data_ready stall

35. Data Presence X X stall stall FIFO FIFO data_ready data_ready + FIFO data_ready stall Flow control: Term typical used in networking

36. Data Presence Increase flexibility of how application can be implemented X X stall stall FIFO FIFO data_ready data_ready + FIFO data_ready stall Flow control: Term typical used in networking

37. Implementing Streaming Dataflow • Data presence • variable length connections between operators • data rates vary between operator implementations • data rates varying between operators • Datapath sharing • not enough spatial resources to host entire graph • balanced use of resources (e.g. operators) • cyclic dependencies impacting efficiency • Interconnect sharing • Interconnects are becoming difficult to route • Links between operators infrequently used • High variability in operator data rates • Streaming coprocessor • Extreme resource constraints

38. Datapath Sharing X X +

39. Datapath Sharing Platform may only have one multiplier X X +

40. Datapath Sharing Platform may only have one multiplier X +

41. Datapath Sharing Platform may only have one multiplier REG X REG +

42. Datapath Sharing Platform may only have one multiplier REG X FSM REG +

43. Datapath Sharing Platform may only have one multiplier REG X FSM REG + Important to keep track of were data is coming!!

44. Implementing Streaming Dataflow • Data presence • variable length connections between operators • data rates vary between operator implementations • data rates varying between operators • Datapath sharing • not enough spatial resources to host entire graph • balanced use of resources (e.g. operators) • cyclic dependencies impacting efficiency • Interconnect sharing • Interconnects are becoming difficult to route • Links between operators infrequently used • High variability in operator data rates • Streaming coprocessor • Extreme resource constraints

45. Interconnect sharing X X +

46. Interconnect sharing Need more efficient use of interconnect X X +

47. Interconnect sharing Need more efficient use of interconnect X X +

48. Interconnect sharing Need more efficient use of interconnect X X FSM +

49. Implementing Streaming Dataflow • Data presence • variable length connections between operators • data rates vary between operator implementations • data rates varying between operators • Datapath sharing • not enough spatial resources to host entire graph • balanced use of resources (e.g. operators) • cyclic dependencies impacting efficiency • Interconnect sharing • Interconnects are becoming difficult to route • Links between operators infrequently used • High variability in operator data rates • Streaming coprocessor • Extreme resource constraints

50. Streaming coprocessor • See SCORE chapter 9 of text for an example.