Metro II : A Next-Generation Framework for Platform-based Design Abhijit Davare, Douglas Densmore, Trevor Meyerowitz, Alessandro Pinto, Alberto Sangiovanni-Vincentelli, Guang Yang, Haibo Zeng, Qi Zhu CHESS Winter Meeting February 14, 2007

CHESS Winter Meeting2 February 14, 2007 Approach Use lessons learned from Metropolis test cases to drive features for next-generation Metro II framework

CHESS Winter Meeting3 February 14, 2007 Outline Metro II Features  Heterogeneous IP Import  Behavior/Performance Separation  Operational/Denotational Specification Execution Model Building Blocks Implementation

CHESS Winter Meeting4 February 14, 2007 Metropolis Framework Metamodel Compiler … tool Verification tool Front end MetaModel language Simulator tool... Back end 1 Abstract syntax trees Back end 2 Back end n Metropolis Interactive Shell  Functionality What does it do?  Architecture Platform How is it done? At what cost?  Mapping Binding between the two

CHESS Winter Meeting5 February 14, 2007 Heterogeneous IP Import in Metropolis Excessive time spent in design import  Redefining and implementing classes and methods  Memory allocation, data types, templates, etc Challenges in Infineon case study  a on MuSIC (multiple SIMD core) architecture Collection of Heterogeneous IP Metropolis Design IP rewritten in Metamodel Different design teams Different languages Different MoCs

CHESS Winter Meeting6 February 14, 2007 Heterogeneous IP Import in Metro II Pros  Framework easier to develop and maintain  Leverage existing compilers/debuggers  Quicker import for most IP Cons  Framework has limited visibility Collection of Heterogeneous IP Metro II Design Wrappers

CHESS Winter Meeting7 February 14, 2007 Phase 1Phase 2 Behavior-Performance Separation in Metropolis Processes make explicit requests for annotation Annotation/scheduling are intertwined  Iteration between multiple quantity managers Challenges in GM case study  Vehicle stability application on distributed CAN architecture  Interactions between global time QM and resource QM difficult to debug P1P1 P2P2 R Global Time Resource Scheduler 2. Quantity Resolution 1. Explicit quantity requests 3. Granting of requests

CHESS Winter Meeting8 February 14, 2007 Behavior-Performance Separation in Metro II Pros  Phase 1 objects no longer explicitly request annotation  Separation of quantity managers into annotators and schedulers “Global time” separates into physical time (annotation) and logical time (scheduling) Cons  Additional phase introduced into execution model Phase 1 P1P1 P2P2 R Phase 2 Physical Time 1. Block processes at interfaces 2. Annotations Phase 3 Logical Time Resource Scheduler 3. Sched. Resolution 4. Enable some processes

CHESS Winter Meeting9 February 14, 2007 Operational/Denotational Specification in Metropolis Constraints break operational encapsulation  Constraints between arbitrary pairs of events  Any state in scope of event may be used in constraints No special declarative constructs for mapping Challenges in Intel case study  JPEG encoding on MXP5800 heterogeneous multiprocessor  Keeping track of events, values, and constraints requires separate data structure  Hard to debug local variables involved in synchronization constraints void func() { int a; event e1; int b; event e2; } void arch() { int c; event e3; int d; event e4; } sync(e1, e2, a == c) sync(e3, e4, b <= d)

CHESS Winter Meeting10 February 14, 2007 Operational/Denotational Specification in Metro II Accessible events are beg/end of interface methods  Values are either parameters or return values Mapping allocates functional components to architectural components  Coarser granularity

CHESS Winter Meeting11 February 14, 2007 Summary: Features for Metro II Import heterogeneous IP  Different languages  Different models of computation Behavior-Performance Separation  No explicit requests for annotation  Annotation separated from scheduling Operational/Denotational Separation  Restricted access to events and values  Mapping carried out at component level Coordination Framework Event-oriented Framework 3-Phase Execution

CHESS Winter Meeting12 February 14, 2007 Events An event is the fundamental concept in the framework Fields:  Process: Generator of event  Value Set: Variables exposed along with event  Tag Set: Quantity annotations E =

CHESS Winter Meeting13 February 14, Phase Execution 1.Base  Each process proposes events and suspends  Multiple events can be proposed simultaneously by one process 2.Annotation  Tag proposed events with quantities 3.Scheduling  Rejection of some proposed events  At most 1 enabled event per process Scheduling Annotation Base

CHESS Winter Meeting14 February 14, 2007 Phases and Events Each phase is allowed to interact with events in a limited way  Keep responsibilities separate PhaseEventsTagsValues ProposeDisableReadWriteReadWrite BaseYes AnnotationYes SchedulingYes

CHESS Winter Meeting15 February 14, 2007 Component IP Wrapper Components, Ports, and Connections required port provided port view port Ports  Coordination: provided, required  View ports Connections  Each method in interface for provided-required connection associated with begin and end events IP is wrapped to expose framework-compatible interface Components encapsulate wrapped IP

CHESS Winter Meeting16 February 14, 2007 Mappers Mappers are objects that help specify the mapping  Bridge syntactic gaps only  E.g. Missing method parameters Mapper Func. Comp Arch. Comp Mapping occurs at the component level  Between components with compatible interfaces  Possibly many functional components mapped to a single architectural component

CHESS Winter Meeting17 February 14, 2007 Metro II System Architecture sc_eventsc_module m2_method m2_port m2_event m2_interface MapperAdaptor m2_component Constraints Annotator Scheduler m2_manager Implementation Platform: SystemC 2.2 Metro II Core Not currently implemented Implementation started

CHESS Winter Meeting18 February 14, 2007 Implementation: SystemC 2.2 Component Declaration Port Declaration Component has 1 Process Call methods When to switch to 2 nd phase Interface Declaration

CHESS Winter Meeting19 February 14, 2007 Design Drivers Transceiver  DF + CT  Adaptors h.264 decoder  SystemC IP import  Mappers

CHESS Winter Meeting20 February 14, 2007 Development Plan Pre-alphaAlphaBeta  Basic 3-phase execution  h.264 SystemC model in Metro II 3/07 6/07 9/07  Mapping  Adaptors between different MoCs  h.264 mapping  Transceiver model

CHESS Winter Meeting21 February 14, 2007 Summary Motivation and Characteristics  Heterogeneous IP Import  Coordination Framework  Behavior/Performance Separation  3-phase  Operational/Denotational Specification  Event-based DVCon conference paper at: