1 / 17

RAMP Summer Retreat 2008 Breakout Reports

RAMP Summer Retreat 2008 Breakout Reports. RAMP Summer Retreat 2008 Attendees (Compiled by Greg Gibeling). RAMP as a Service. Dave Patterson, Kees Vissers, Dave Donofrio, Chuck Thacker, Greg Gibling, Farzad Fatollahi-Fard, Michael Papamichael, John Davis, Dan Burke.

pascale-frank
Download Presentation

RAMP Summer Retreat 2008 Breakout Reports

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. RAMP Summer Retreat 2008Breakout Reports RAMP Summer Retreat 2008 Attendees (Compiled by Greg Gibeling)

  2. RAMP as a Service Dave Patterson, Kees Vissers, Dave Donofrio, Chuck Thacker, Greg Gibling, Farzad Fatollahi-Fard, Michael Papamichael, John Davis, Dan Burke

  3. Embody commodity computing conceptStart with current RAMPants: What is useful to us? • Conceptually, one researcher aiding another via shared resources and expertise. • Building HW still daunting, even to good researchers, and more so now than ever before. • Sharing model uses common hardware, expertise, funding, and skills across entire community. • Software environment • Ease builds with service like ec2 from Amazon • Optimize results: launch 100 concurrent builds and take best of batch • Minimize local hardware (PC/server) investment • Maintain SW version consistency and rollback possibility • Proposed BEE3/RAMP2 shared HW pool infrastructure • Nicer experience for users • One researcher aiding another • Experts maintain working pool, up-to-date system • Division of labor more compatible with skill-set of potential users • Offload maintenance to others

  4. Broad considerations • Variations in HW system topology • Host-attached via PCIe? • 10GB switch? • PCIe ring? • (Likely to initially be 10Gig Ethernet due to low cost and ease of initial use.) • Consider HPC-style management mechanisms: • Scheduling and reservation tools such as Condor • Ability to checkpoint and restart (possible issues across designs, etc., maintain sync; some considerations orthogonal to original design goals) • Other features? Consult that community for suggestions • Target Goal: Lower barrier of entry by sharing HW and expertise

  5. Counterpoints • Are there better models, e.g. NetFPGA which pairs experts and novices? • Does this forward the goal of a SimpleScalar-style abstraction for RAMP? • Step one should be to learn how to (easily) migrate from a single deskside board to a multi-chip one like BEE3—shared HW approach may be looking too far ahead.

  6. Final issue Some concern expressed that Prof. Wawrzynek is too harsh in grading; we would like to appeal for higher score on report card.

  7. What is RAMP Good For? 7

  8. What is RAMP good for? Render target concurrency directly in FPGA host to avoid sequential simulation slowdown Very exact timing of microarchitectures Realistic multicore behaviors with good enough timing Very, very large parallel systems OpenSPARC RTL simulation

  9. Infrastructure, Sharing and Layers Hong, Joel EMER, GUO Rui, Christos KOZYRAKIS, Patrick LYSAGHT, Angshuman PARASHAR, Dave PENRY, Tom VAN COURT 9

  10. Infrastructure Usage models: Most users – work within a provided framework of models and interfaces - replacing individual components (CPU, Branch Predictor) Some users – create completely new models and new interfaces Alternatives: Single set of standard interfaces Framework for using a variety of alternative interfaces

  11. Model components and sharing Highest level need means to specify the constituent components of a model Characteristics Probably should be stable Should not dictate specific interfaces Should facilitate sharing Alternatives Makefiles, Repositories and Copying AWB and Repositories

  12. Major components Attributes: Major components of the system that have standardized interfaces Candidates: System components e.g., CPU, memory hierarchy, interconnection Prototype Model Functional model Timing model Hardware platform

  13. Interfaces Attributes: Signature of the communication interface with a module Usage scenarios: Timing model inter-module communication FPGA to GP processor communication General inter-module communication

  14. Timing Model Communication Attributes: Support for intra-module communication in timing models Alternatives: RDL channels FAST connectors HAsim A-ports

  15. FPGA to CPU communication Attributes: Provide convenient communication between FPGA and GP processor Alternatives: FAST mechanism Protoflex mechanism HAsim RRR

  16. Inter-module communication Attributes Allows for hierarchical and/or peer communication between modules Alternatives: Hierarchical Port maps Bluespec module interfaces Peer HAsim soft connections (currently Bluespec-only)

  17. Discussed, but uncategorized Multi-FPGA considerations Inter-chip communication Auto-partitioning Multiplexing/Replication considerations Single code – auto decision

More Related