1 / 73

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

CPRE 583 Reconfigurable Computing Lecture 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/. Announcements/Reminders. Midterm:

fleta
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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.

More Related