1. PROGRESS User Committee Meeting, December 11, 20021 On the Fundamental Design Gap in Complex Systems Mark Verhappen mav@zurich.ibm.com Piet van der Putten Jeroen Voeten IBM Zurich Research Laboratory Eindhoven University of Technology

2. PROGRESS User Committee Meeting, December 11, 20022 Motivation Most next generation designs of complex systems are evolutionary Thoroughly evaluate each previous design assumption to avoid wrong design decisions for a next generation Design time is too short to evaluate fresh ideas in detail Challenge: development of a design method to manage the risk of major architecture changes in large complex systems, so that we can design a competitive system in a timely manner time bandwidth demand integration density today last decade PRIZMA Sometimes, an incremental design is not a competitive solution anymore!

3. PROGRESS User Committee Meeting, December 11, 20023 New Insights Start system-level analysis at a higher level of abstraction than most high-level synthesis methods do –No known system-level synthesis tools that can handle such a complex system in one model –Collection of models for different aspects (performance, cost, …) The design gap is fundamental, language-independent, and cannot be crossed automatically by a tool: models are not complete enough We present a terminology to better define the gap and a method to cross it in a structured way is under development hardware description languages transformation and refinement (system-level synthesis) e.g. VHDL,Verilog,... e.g. LOTOS, SDL,... system-level design languages DESIGN GAP... collection of models e.g. POOSL,...

4. PROGRESS User Committee Meeting, December 11, 20024 Definitions Primary purpose: Analysis Different models for different questions Keep implementation solutions open Models are not suitable for synthesis Primary purpose: Synthesis Complete enough to serve as input to synthesis tools Rules for transformation and refinement found in synthesis tools ModelingDescription All information required to synthesize a system Description component Tool chain component DESIGN GAP (system-level synthesis) Conceptual Modeling Description

5. PROGRESS User Committee Meeting, December 11, 20025 Design Gap: Example switch packets... scheduler WRR Question: selective flow control concepts disturbs weighting? memory resource flow-control line card wrr_scheduling()() par send_packets(1)() and send_packets(2)() and... and send_packets(N)() rap. line card switch packets WRR simultaneous parallel access memory resource Question: selective flow control concepts disturbs weighting? flow-control... Interpretation of system- level concept Models is ambiguous! Abstraction from WRR scheduler

6. PROGRESS User Committee Meeting, December 11, 20026 The Design Gap is an Interpretation Gap The interpretation of Models is ambiguous –Models are not complete enough to be synthesized without their intended interpretation –Only guidelines for stereotypical interpretations exist Shortcoming of the modeling language? –No! The interpretation gap is necessary for Modeling: –Different compositions of powerful language concepts give freedom to interpret models in various ways –Choose a model-composition and interpretation such that the model is compact and comprehensible: faster iterations! The opposite is typically true and desired for languages that are used for Description

7. PROGRESS User Committee Meeting, December 11, 20027 Conclusions Analysis of new conceptual solutions requires Modeling before Description We cannot afford to use only existing system-level synthesis methods Differences between Modeling and Description cause an interpretation gap that –differs from system-level synthesis gap –is fundamental, language-independent, yet desired for Modeling! –should be avoided if your next generation system design allows it! An automatic way to translate conceptual Models to Descriptions for complex systems (like PRIZMA) does not exist A structured transfer of design knowledge remains necessary! –Convey questions, Models, interpretation, answers to assist development partners –Interpretations are context-specific modeling purposes and abstraction decisions

8. PROGRESS User Committee Meeting, December 11, 20028 Current and Future Work Design Patterns: OO-Software world Document a recognizable design strategy –Yielded good implementations in the past –Recognized by experienced designers –Find satisfying solutions under changing requirements Describe Modeling patterns using a template –Name, applicability, consequences, examples of use, stereotypical interpretation Assess usability of Modeling patterns –Are they a sufficient vehicle? –Can we develop patterns for typical question about aspects of queueing, scheduling, routing, flow & congestion control, … ?