1 RAMP Breakout 1 Question 3 What are the standard distribution target machines? In what form should they be distributed? or What kind of infrastructure should the RAMP group ship, support, and maintain?

2 A Bright-Eyed User Receives a BEE3… What else do they get? A board bring-up (not our focus) Reference Documentation Tutorials Reference Design (our focus) Hold on a second… Lots of different motivations Let’s go a little bit more in depth…

3 Different Layers, Users, Goals Physical Platform (XUP, BEE3, etc) “Bare-Metal” interface (DDR, Ethernet MAC, etc) RAMP/RDL interface (Load/Store DDR controller, etc) “Application” layer (RAMP Red, Blue, White, etc) Software layer (SPEC, Layer: User: BEE3 architects, Xilinx, etc. Domain experts: Xilinx, Microsoft, Intel RAMP/RDL Implementors Computer Architects Programmers, OS Researchers Goal: Ship physical board Interface with physical devices Make interfacing easy Explore a whiz-bang widget Get great performance

4 Goals of a Reference Design Should: Show off features of the physical platform Give users confidence in the interfaces Give the users a “taste” of what the system can do Get users excited about RAMP/BEE3! (Me) Should not: Physically test the board Be overly complicated or intimidating Be the be-all and end-all system Lock users in to a particular organization

5 RAMP Clear: Sample Reference Design Taking all of these issues into account we propose RAMP Clear 2-4 cores per FPGA 8-16 per board 32+ per rack Microblaze the best (?) Small cache Running Linux Software app? “knobs”: cache miss rate/miss penalty

6 RAMPBEE3 Issue 1: RAMP vs BEE3 Are RAMP and BEE3 the same thing? Where do they overlap/differ?

7 Issue 2: Board Independence? Is board independence a goal of the RAMP project? Boards have different interfaces, different devices Should gateware be distributed in a board- dependent + middleware package? Is this something RAMP should strive for? Is this even possible? Long-term: Migration path to assist users: XUP -> BEE3 -> Beyond Generational: BEE3 -> BEE4->…

8 Issue 3: Systems vs Simulations Is the reference design a System or a Simulation? Should we strive to have tweakable “knobs” that the user can play with Should RDL be used in the reference design? Does the reference design need to show off virtualizing the clock?

9 Issue 4: Interfaces vs APIs “Bare-Wire” interfaces are notoriously difficult Should we try to standardize a “middleware” interface to abstract out some of this detail Example: RAS/CAS DDR2 vs Load/Store Is this an interface or an API? Is the burden of standardizing too high? Is this beyond the scope of the reference design?