Metro II : A Next-Generation Framework for Platform-based Design

1. 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

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

3. Outline • Metro II Features • Heterogeneous IP Import • Behavior/Performance Separation • Operational/Denotational Specification • Execution Model • Building Blocks • Implementation CHESS Winter Meeting

4. Metropolis Framework • Functionality What does it do? • Architecture Platform How is it done? At what cost? • Mapping Binding between the two MetaModel language Metamodel Compiler MetropolisInteractiveShell Front end Abstract syntax trees ... Back endn Back end1 Back end2 Simulator tool Verification tool … tool CHESS Winter Meeting

5. Metropolis Design Collection of Heterogeneous IP IP rewrittenin Metamodel 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 • 802.11a on MuSIC (multiple SIMD core) architecture • Different design teams • Different languages • Different MoCs CHESS Winter Meeting

6. Heterogeneous IP Import in Metro II Metro II Design • 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 Wrappers CHESS Winter Meeting

7. 3. Granting of requests Phase 1 Phase 2 Global Time P2 P1 Resource Scheduler 2. Quantity Resolution R 1. Explicit quantity requests 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 CHESS Winter Meeting

8. 4. Enable some processes Phase 3 Phase 1 Phase 2 Logical Time P2 P1 Physical Time 3. Sched. Resolution R Resource Scheduler 1. Block processes at interfaces 2. Annotations 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 CHESS Winter Meeting

9. sync(e1, e2, a == c) sync(e3, e4, b <= d) Operational/Denotational Specification in Metropolis void func() { int a; event e1; int b; event e2; } void arch() { int c; event e3; int d; event e4; } • 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 CHESS Winter Meeting

10. 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 Meeting

11. 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 3-Phase Execution Event-oriented Framework CHESS Winter Meeting

12. 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 = <p, V, T> CHESS Winter Meeting

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

14. Phases and Events • Each phase is allowed to interact with events in a limited way • Keep responsibilities separate CHESS Winter Meeting

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

16. Mappers • 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 Func. Comp Arch. Comp Mapper CHESS Winter Meeting

17. m2_manager Mapper Adaptor Annotator Scheduler m2_port m2_interface m2_component m2_method m2_event Not currently implemented Implementation started Metro II System Architecture Constraints Metro II Core Implementation Platform: SystemC 2.2 sc_module sc_event CHESS Winter Meeting

18. Interface Declaration Component Declaration Port Declaration Component has 1 Process Call methods When to switch to 2nd phase Implementation: SystemC 2.2 CHESS Winter Meeting

19. Design Drivers • Transceiver • DF + CT • Adaptors • h.264 decoder • SystemC IP import • Mappers CHESS Winter Meeting

20. Beta Alpha Pre-alpha Development Plan • Basic 3-phase execution • h.264 SystemC model in Metro II • Mapping • Adaptors between different MoCs • h.264 mapping • Transceiver model 6/07 9/07 3/07 CHESS Winter Meeting

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