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 Embody commodity computing conceptconcept

Start with current RAMPants: Start with current RAMPants: What is useful to us?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 dauntingBuilding HW still daunting, even to good researchers, and more so now than ever before., even to good researchers, and more so now than ever before. Sharing model uses Sharing model uses common hardware, expertise, funding, and skills common hardware, expertise, funding, and skills across entire across entire

community.community.

1.1. Software environmentSoftware environment Ease builds with service like ec2 from AmazonEase builds with service like ec2 from Amazon Optimize results: launch 100 concurrent builds and take best of batchOptimize results: launch 100 concurrent builds and take best of batch Minimize local hardware (PC/server) investment Minimize local hardware (PC/server) investment Maintain SW version consistency and rollback possibilityMaintain SW version consistency and rollback possibility

2.2. Proposed BEE3/RAMP2 shared HW pool infrastructureProposed BEE3/RAMP2 shared HW pool infrastructure Nicer experience for usersNicer experience for users One researcher aiding anotherOne researcher aiding another Experts maintain working pool, up-to-date systemExperts maintain working pool, up-to-date system Division of labor more compatible with skill-set of potential usersDivision of labor more compatible with skill-set of potential users Offload maintenance to othersOffload maintenance to others

4

Broad considerationsBroad considerations

Variations in HW system topologyVariations in HW system topology Host-attached via PCIe?Host-attached via PCIe? 10GB switch?10GB switch? PCIe ring?PCIe ring?

(Likely to initially be 10Gig Ethernet due to low cost and ease of initial use.)(Likely to initially be 10Gig Ethernet due to low cost and ease of initial use.)

Consider HPC-style management mechanisms:Consider HPC-style management mechanisms: Scheduling and reservation tools such as CondorScheduling and reservation tools such as Condor Ability to checkpoint and restart (possible issues across designs, etc., maintain sync; Ability to checkpoint and restart (possible issues across designs, etc., maintain sync;

some considerations orthogonal to original design goals)some considerations orthogonal to original design goals) Other features? Consult that community for suggestionsOther features? Consult that community for suggestions

Target Goal: Target Goal: Lower barrier of entry by sharing HW and expertiseLower barrier of entry by sharing HW and expertise

5

CounterpointsCounterpoints

Are there better models, e.g. NetFPGA which pairs experts and novices?Are there better models, e.g. NetFPGA which pairs experts and novices?

Does this forward the goal of a SimpleScalar-style abstraction for RAMP?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-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.chip one like BEE3—shared HW approach may be looking too far ahead.

6

Final issueFinal 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