1. RAMP Breakout Reports Krste Asanovic, Derek Chiou, James Hoe, Christos Kozyrakis, Mark Oskin, Chuck Thacker, John Wawrzynek 1/11/2007 (Composed by Greg Gibeling)

2. What are Breakouts? Focused group discussion of open issues Wednesday dinner and Thursday lunch--- one topic each table Report findings on Thursday afternoon Feel free to choose your topic; feel free to change group/topic between tonight and tomorrow

3. What does success mean? Leaders: None, no interest Topic  Every EE/CS department owns an RAMP: teaches courses and does research on it?  Papers appear in ISCA that use RAMP?  What should be the key milestones for RAMP?

4. ISCA / FCRC Tutorial Planning Leaders: None, no interest Topic  Intended audience? ISCA / PLDI  What better work by then? primetime versus late-night edition?  Format? 1/2 day RAMP presentations (who?) 1/2 day “hands on” with XUP +BYOLaptop (who?)  Outcome / goal?

5. RAMP-White Breakout Leaders: Derek Chiou & Mark Oskin Topic  Suggestions on architecture, implementation, OS We are the furthest behind, have the most flexibility Tell us what we are missing, what else is available  Generalized ISAs Working on PowerPC, will soon try Leon What are the issues, concerns? How can we make it easier to target?  Generalized components Can we share many more modules than we have been?

6. RAMP Hardware (1)  Leaders: John Wawrzynek & Chuck Thacker  Outline  While we are far along on the high-level design of the RAMP2 hardware,it is not too late to make some changes, and certainly not too late to think about future generations of hardware and how we interact with hardware vendors.  Topic  Thacker/Chang BEE3 design:  Is the single FPGA board option still an important avenue in the development and deployment of RAMP?  How do we plan for the future of new FPGAs and new module designs?  Are Spartans and interesting alternative for RAMP?  Planning on success, should we spin out a venture to serve the needs of the RAMP community?

7. RAMP Hardware (2) Minor BEE3 Redesign  Outgrowth of Altera involvement  Possible future after BEE3?

8. RAMP Hardware (3) Altera is interested in participating, however, easier (but not manditory) for them to donate funds if we are using their chips. Altera doesn't see RAMP as a market - so it's unlikely they would build and donate boards. (Does give them high visibility within universities, however). Perhaps RAMP can be HW agnostic. (Altera, IBM, participation, etc.) A free market for RAMP hardware. For RAMP developers, this means that we absolutely need to design to a virtual machine model. Most thought our idea of attracting a 3rd party to manufacture boards (with the opportunity to make money on commercial offering) as a good model. Enabling an existing FPGA board vendor should also work.

9. RAMP Hardware (4) Long term (maybe even short term) sustainability of 3rd party may be a problem. Is there sufficient market/profit- margin to keep them going? Discussed idea of a farm of modules (large installation) remote accessable - IBM has experience with this. Mixed opinion if this will work (need finger on reset switch). Perhaps a large installation for occasional runs. For applications beyond RAMP - that add acceleration to conventional processors - may need a new design. As for sticking to the standard form factor (EATX): Do thermal and layout analysis first then decide. Stick to standards, unless there is a good reason not to.

10. RAMP Hardware (5) Ownership of design. MS will own the schematic/layout. If UC wants to do new versions, can they? What about others? This should be settled ASAP. Putting the BEE3 design in the public domain will release MS from liability. Some concern about partitioning of control board design and big dumb board design. BWRC could probably not keep up with Celestica. Perhaps move control board design to Celestica and have them do both. How long is Celestica committed to supplying the boards? Is the 1K total BEE3 volume correct? What happens after the initial MS+RAMP order?

11. RDL & Programming (1)  Leader: Krste Asanovic  Outline  The RDL framework is the glue that holds the RAMP components together. After several major revisions, it has a lot of capability, but there is an endless amount of possible additional functionality  Topic  If you’ve used RDL, what are user experiences?  If you haven’t, why not?  What do you think is missing from the RAMP Design Framework?  What is the priority order for any missing features?  Is there anything RDL is trying to do that it shouldn’t? Are there pieces we can get from elsewhere?

12. RDL & Programming (2) How to speed up RDL adoption?  Developers will only spring from adopters  Need single complete working system from top to bottom (compilers, OS, core, memory, timing models) that has sufficient scope for modification to be interesting => RAMP Blue first?  Debugging alone could be enough to “sell” adoption Need dedicated funding for RAMP development  Otherwise, everyone does the minimum necessary to get their next funded deliverable done  Need more Gregs How restrictive is RDL model?  Maybe hard to rip apart legacy designs, but what’s the alternative?  For new designs, seems fine so far, need lots more examples

13. RDL & Programming (3) Profile activity on channels, then feedback into next configuration to allocate link bandwidth to various channels  A separate tool outside RDL generates RDL configurations Will probably want to have different parts of host run at different clock rates to optimize performance, increase compatibility of modules  In RDL, treat each patch on an FPGA running at a given host clock rate as a separate “platform”  Already functional (not well supported) Global, latency-insensitive wires might want to get added to transactor/RDL Lots of thoughts on what would be good debugging features, ways to help somewhat automate mappings, etc…

14. Software Bring Up Breakout Leader: Christos Kozyrakis Outline  A new HW system is a useful as its software infrastructure.  While the top SW layers for any design mapped to RAMP will be specific to the design, it is important to build a practical and flexible infrastructure for the low level SW layers necessary to get any project started. Topic  What is the right starting point for system software? Linux on host PC/control FPGA and lightweight VMM on other cores (MISP-style)? How about SMP Linux on RAMP?  Does system software force us support a single ISA in practice?  Which are the critical devices to support initially?  What is the SW infrastructure for pervasive debugging, monitoring, fault injections,… Integration with RDL, chipscope/identify, gdb, dtrace,...?  How do we support seamless code transition between FPGA and SW emulation?  How do we deal with scalability from the system software perspective?  How do we support effective sharing of system software modules between users?  Miscellaneous features Support partitioning; support for availability/reliability; …

15. RAMP IP Repository (1) Leader: James Hoe Topic  What goes in and how to control quality?  Who gets to access it? and how? What must they give in return?  Copyright  Maintenance and user support  Schedule to build up the IP repository

16. RAMP IP Repository (2) People  Kurt Akeley, Eric Chung, Michael Dalton, Joel Emer, Jiri Gaisler, James C. Hoe, Martha Mercaldi, Andrew Putnam, Stephen Smith, Ivan Sutherland, Durgam Vahia, Kees Vissers, Perry Wang, Seewook Wee

17. RAMP IP Repository (3) Executive Summary  What is being shared/offered in RAMP? Not RAMP Red/White/Blue It is the composible modules  more effort architecting the modules and interfaces  Build a “real” team RAMP Red/White/Blue are not coordinated efforts the students from different university have no stake on what each other does  more deliberate effort to integrate students/efforts  Build a culture of IP and doc review/repository tag check-in’s by level of readiness version and archive all progress  review each other’s work, early rather than late

18. RAMP IP Repository (4) Classify the classes of IPs we share/offer  hosting platform, e.g., BEE3  gateware, i.e., reusable components  complete systems, e.g., RAMP red-white-blue  infrastructure and tools, e.g., RDL Don’t over aggressively lock-down design parameters (ISA, OS, application)  give people ways to build what they care about Compatibility is a must (at the language level vs. at the interface level)?

19. RAMP IP Repository (5) Build a repository  need a technical czar  need a administrative czar Repository for IP/SW/documents  version and archive all steps and progress  it is okay to check in pre-releases, tagged it as so if it is not ready  get review and discussion started as early as possible Build student community  retreat for students  regular student phone meetings RAMP repository  could support a larger community beyond architects (e.g., DSP)

20. RAMP IP Repository (6) Don’t over optimize performance. Get it to work, correct and simple  Set a performance target so no one over- designs Should look at ASIM hierarchical metatype for module interface specification Create a wanted list of modules (after agreeing on their interfaces) Take advantage of OpenCore