RAMP Summer Retreat 2008 Breakout 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 concept Start with current RAMPants: What is useful to us? Conceptually, one researcher aiding another via shared resources and expertise. 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. 1. 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 2. 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?

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

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

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

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

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

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

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

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)

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