RAMP Summer Retreat 2008 Breakout Reports RAMP Summer

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 2

Embody commodity computing concept Start with current RAMPants: What is useful to us? Conceptually, one researcher aiding another via shared resources and expertise. q q 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. 1. Software environment q Ease builds with service like ec 2 from Amazon q Optimize results: launch 100 concurrent builds and take best of batch q Minimize local hardware (PC/server) investment q Maintain SW version consistency and rollback possibility 2. Proposed BEE 3/RAMP 2 shared HW pool infrastructure q Nicer experience for users q One researcher aiding another q Experts maintain working pool, up-to-date system q Division of labor more compatible with skill-set of potential users q Offload maintenance to others 3

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

Counterpoints § Are there better models, e. g. Net. FPGA which pairs experts and novices? § Does this forward the goal of a Simple. Scalar-style abstraction for RAMP? § Step one should be to learn how to (easily) migrate from a single deskside board to a multichip one like BEE 3—shared HW approach may be looking too far ahead. 5

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

What is RAMP Good For? 7

What is RAMP good for? n 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 ¨ n Open. SPARC RTL simulation

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

Infrastructure n 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 ¨ n Alternatives: Single set of standard interfaces ¨ Framework for using a variety of alternative interfaces ¨

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

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

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

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

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

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

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