RAMP Sharing (Playing well with others) John Davis, Christos Kozyrakis, Chuck Thacker, Takefumi Miyoshi, Shinya Takamaeda, Phillip Jones, Tayo Oguntebi, Jared Casper, Andrew Putnam, Michael Papamichael, Eric Chung, Rodric Rabbah, Manuel Saldana, Hari Angepat, Hong An, Angshuman Parashar, David Penry, Kevin W. Rudd, Ralph Wittig

Sharing in RAMP Who? – Content producers and consumers What can we share? – Low to high level components Where do we get/put the shared components? How do we share? Why? When?

System/Platform

Sharing models Top down Larger chunks of infrastructure e.g., ProtoFlex An example of application level sharing Useful if application mostly fits reusable scenario (e.g., processor simulation): can tweak and tailor May tie you to other subcomponents, harder to reuse but certainly can be mined Bottom up Smaller components e.g., interfaces, firmware, controllers Self-encapsulated, easier to understand, faster path to reuse Easier to reuse in contexts that are not simulation- inclined

Sharing dimensions Many RAMP projects: universities, students, industry, purposes Dimensions: platforms, application domains (e.g., type of simulation)

Useful Components to Share Communications models: – scalar operands, cache line transfers, dmas, notifications (control) What goes in the FPGA: – caches, memory, pipelines Software side in CPU: – fifo queues, mpi, stmc Application level: – Not clear what goes there Missing features: – configuration, reconfiguration

Using tools Tools are good Useful tools are maintained by individuals with “skin in the game” – Harder to adopt tools if grad students, once they graduate, abandon platform Tools should be well documented

Sharing with transparency Be upfront about status of component being released State assumptions and dependencies clearly

Centralized repository for sharing Someone needs to do this – Consolidate repositories, packages, etc. – Mailing lists, forums, wiki What RAMP technologies are mature enough for sharing