1. Sim2Imp (Simulation to Implementation) Breakout J. Wawrzynek, K. Asanovic, G. Gibeling, M. Lin, Y. Lee, N. Patil

2. Why do this? To force honesty in emulation. Makes it more difficult (or at least possible to check) feasibility of design decisions. Pushing a design all the way through to ASIC implementation is a good way to get energy / area / performance “estimates”. Can we eliminate the verification problem inherent in the current design methodology. “Correct by Construction”

3. Redefining the Idea Simulation to implementation maybe the wrong idea: Rather we want one common system specification from which we generate multiple different implementations. Spec 2 X System Specificatio n ASIC gate synthesizable model FPGA gate synthesizable model FPGA simulation model Software simulation model

4. Old idea We’ve witnessed similar ideas in other domains. Parallel software generation. One high-level specification drives multiple different implementations on different types of machines.

5. How do we organize such a system? Building on a single architectural “template” might be too limiting. We can identify a set of “architectural” or “design patterns”. These become the organizing principles. Ex: Pipelined processors (single issue, OoO), microcoded machines, vector, VLIW,... similarly for interconnection networks: message passing, shared coherent memory,... and for memory systems: cache protocols.

6. Dealing with Complexity The combination of all possible design patterns is a LARGE space. Perhaps moving down one level of abstraction (sub-patterns) will reduce the overall complexity: Basic design patterns: pipelining, synchronization, reductions,... Each high-level design pattern has a set of “operation sematics” for describing the desired function.

7. How to Build This Need extensibility - can’t get stuck with one architecture model. We envision a set of parameterized “structure generators” for moving from a high-level specification to a variety of implementations. The parameterization captures design alternatives (i.e., cache size) and operational sematics (i.e., ISA, cache policy) Apply this idea hierarchically

9. Finally Compiler verification problem pops up. A burden of the pattern builder is to be able to abstract back to the operational semantics - help deal with verification. Generators should also be able to make quick efficient energy models. Organizing designs so that they admit multiple implementation is a good idea even without automatic compilation. More discussions about this in a graduate seminar at Berkeley this fall.