Metro II A NextGeneration Framework for Platformbased Design

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 Meeting

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

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

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

Heterogeneous IP Import in Metropolis Collection of Heterogeneous IP n n n Metropolis Design Different design teams Different languages Different Mo. Cs IP rewritten in Metamodel n Excessive time spent in design import ¨ Redefining and implementing classes and methods ¨ Memory allocation, data types, templates, etc n Challenges in Infineon case study ¨ 802. 11 a February 14, 2007 on Mu. SIC (multiple SIMD core) architecture CHESS Winter Meeting 5

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

Behavior-Performance Separation in Metropolis 3. Granting of requests Phase 1 Phase 2 Global Time P 2 P 1 Resource Scheduler R 2. Quantity Resolution 1. Explicit quantity requests n n Processes make explicit requests for annotation Annotation/scheduling are intertwined ¨ n 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 February 14, 2007 CHESS Winter Meeting 7

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

Operational/Denotational Specification in Metropolis void func() { int a; event e 1; int b; event e 2; } n n sync(e 3, e 4, b <= d) Constraints break operational encapsulation ¨ ¨ n sync(e 1, e 2, a == c) void arch() { int c; event e 3; int d; event e 4; } 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 MXP 5800 heterogeneous multiprocessor Keeping track of events, values, and constraints requires separate data structure ¨ Hard to debug local variables involved in synchronization constraints ¨ ¨ February 14, 2007 CHESS Winter Meeting 9

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

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

Events An event is the fundamental concept in the framework n Fields: n E = <p, V, T> ¨ Process: Generator of event ¨ Value Set: Variables exposed along with event ¨ Tag Set: Quantity annotations February 14, 2007 CHESS Winter Meeting 12

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

Phases and Events n Each phase is allowed to interact with events in a limited way ¨ Keep responsibilities separate Phase Events Tags Values Propose Disable Read Write Base Yes Yes Annotation Scheduling February 14, 2007 Yes Yes Yes CHESS Winter Meeting Yes 14

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

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

Metro II System Architecture Mapper Adaptor m 2_manager Scheduler m 2_port m 2_component m 2_interface Annotator Constraints m 2_method m 2_event Metro II Core Implementation Platform: System. C 2. 2 sc_module sc_event Not currently implemented Implementation started February 14, 2007 CHESS Winter Meeting 17

Implementation: System. C 2. 2 Interface Declaration Component Declaration Port Declaration Component has 1 Process Call methods When to switch to 2 nd phase February 14, 2007 CHESS Winter Meeting 18

Design Drivers n Transceiver ¨ DF + CT ¨ Adaptors n h. 264 decoder ¨ System. C IP import ¨ Mappers February 14, 2007 CHESS Winter Meeting 19

Development Plan Pre-alpha § Basic 3 -phase execution § h. 264 System. C model in Metro II 3/07 February 14, 2007 Alpha Beta § Mapping § Adaptors between different Mo. Cs § h. 264 mapping § Transceiver model 6/07 9/07 CHESS Winter Meeting 20

Summary n Motivation and Characteristics ¨ Heterogeneous IP Import Coordination Framework ¨ Behavior/Performance Separation 3 -phase ¨ Operational/Denotational Specification Event-based n DVCon conference paper at: http: //embedded. eecs. berkeley. edu/metropolis/wiki February 14, 2007 CHESS Winter Meeting 21