sim2imp (simulation to implementation) breakout j. wawrzynek, k. asanovic, g. gibeling, m. lin, y....
Post on 20-Dec-2015
227 views
TRANSCRIPT
Sim2Imp (Simulation to
Implementation) BreakoutJ. Wawrzynek, K.
Asanovic, G. Gibeling, M. Lin, Y. Lee, N. Patil
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”
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 XSystem System
SpecificatiSpecificationon
ASIC gate synthesizable modelFPGA gate synthesizable model
FPGA simulation modelSoftware simulation model
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.
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.
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.
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
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.