1. Modeling and Simulation for Architecture: Breakout Arun R. Krste A. Dave M. Doe H.Y. Derek C. Lizy J. Kevin L. Dean K. Karen B. Shekhar B. Mike P. Chris C. Jim K. John H. Sudhakar Y. Luiz C. Steve R. Wilf P. Jim K.. Participants Moderator and Scribe Darren K. and Arun R.

2. High level Lots of discussion about the SW Issues & Apps Major concern on interaction & interfaces – between communities – “common language” Good at iterative development – Need good starting points – Need an informed path Lots of discussion of HW Design space – Caution over multiple metrics – Know performance well – Weaker on power – don’t know about reliability – Cost very hard, but very important “Cultural” Barriers & IP Issues

3. 1. Object of Modeling: What to Model Goal: “Make Design Decisions” – Gain Insight – “Common Language” “Shared Testbed” Need to Support Co-design Loop – Arch. want Application models – Apps. want Architecture models Abstraction is needed to deal with Complexity Different goals for different times/audiences – Design exploration in terms of power, performance, reliability, and cost – Design validation – SW development Lots of parameters in the design space

4. 2. Can we do it now Good at iterative refinement Lots of discussion on need for abstract model w/ parameters & trend lines (abstract machine model) – Iteratively approaches – Iterative series of definitions (multiple scopes, levels of abstraction) – Good at evolutionary approaches – captures key parameters – capture disruptive changes – Correct abstractions are CRITICAL Caution: radical changes make things difficult, uncertain – Hard to jump 10+ years out

5. 3. Gaps Some research gaps, some interactional gaps “Cultural Barriers” – IP: what is precompetitive? what can we share? – App. vs. HW vs. compiler vs. OS etc... Skeleton Applications & Skeleton Architectures – Multiple levels – Correct abstractions – Not assume a single execution model Need way to interact between HW & SW Fidelity vs. Time vs. Scale tradeoffs (decomposability) Methodology – What scale? what abstractions? – Need community consensus of what is needed Roadmap of Modeling capabilities

6. Gaps (cont.) Infrastructure – Technology models – Lots of discussion for tech. models for disruptive technologies and how we trust them Modeling Testbed – Bring together architecture & application skeletons @ Multiple levels of abstraction w/ Technology Modeling Resources – Access to state of art machines for simulation – Access to state of art machines for validation

7. 4. Community of Interaction Application Teams (Co-Design Centers) – Also, OS, Runtime, Compiler Different facets within architecture teams – Memory – Processor – Network – Device-level & High level Need lots of cross-cutting interaction

8. 5. Measure for Success #1: No Surprises in Deployed Machine Infrastructure is available, used, and broadly accepted Influence is demonstrated – Impact of methodology is demonstrated – We know which gaps we filled