ramp summer retreat 2008 breakout reports ramp summer retreat 2008 attendees (compiled by greg...
Post on 19-Dec-2015
215 views
TRANSCRIPT
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