Transcript RAMP Breakout Reports

RAMP Breakout Reports
Krste Asanovic, Derek Chiou, James
Hoe, Christos Kozyrakis, Mark Oskin,
Chuck Thacker, John Wawrzynek
1/11/2007
(Composed by Greg Gibeling)
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
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?
ISCA / FCRC Tutorial Planning


Leaders: None, no interest
Topic

Intended audience?


What better work by then?


primetime versus late-night edition?
Format?



ISCA / PLDI
1/2 day RAMP presentations (who?)
1/2 day “hands on” with XUP +BYOLaptop (who?)
Outcome / goal?
RAMP-White Breakout


Leaders: Derek Chiou & Mark Oskin
Topic

Suggestions on architecture, implementation, OS



Generalized ISAs




We are the furthest behind, have the most flexibility
Tell us what we are missing, what else is available
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?
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?
RAMP Hardware (2)

Minor BEE3
Redesign


Outgrowth of Altera
involvement
Possible future
after BEE3?
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.
RAMP Hardware (4)




Long term (maybe even short term) sustainability of 3rd
party may be a problem. Is there sufficient market/profitmargin 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.
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?
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?
RDL & Programming (2)

How to speed up RDL adoption?




Need dedicated funding for RAMP development



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
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
RDL & Programming (3)

Profile activity on channels, then feedback into next
configuration to allocate link bandwidth to various channels


Will probably want to have different parts of host run at
different clock rates to optimize performance, increase
compatibility of modules




A separate tool outside RDL generates RDL configurations
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…
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; …
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
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
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

RAMP IP Repository (4)

Classify the classes of IPs we share/offer





Don’t over aggressively lock-down design parameters (ISA,
OS, application)


hosting platform, e.g., BEE3
gateware, i.e., reusable components
complete systems, e.g., RAMP red-white-blue
infrastructure and tools, e.g., RDL
give people ways to build what they care about
Compatibility is a must (at the language level vs. at the
interface level)?
RAMP IP Repository (5)

Build a repository



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



need a technical czar
need a administrative czar
retreat for students
regular student phone meetings
RAMP repository

could support a larger community beyond architects (e.g., DSP)
RAMP IP Repository (6)

Don’t over optimize performance. Get it to
work, correct and simple




Set a performance target so no one overdesigns
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