Presentation is loading. Please wait.

Presentation is loading. Please wait.

Communication-Based Design 2 Motivation: System-on-a-Chip Design s Migration of the system from board to chip s Complexity of chip design increases s.

Similar presentations


Presentation on theme: "Communication-Based Design 2 Motivation: System-on-a-Chip Design s Migration of the system from board to chip s Complexity of chip design increases s."— Presentation transcript:

1

2 Communication-Based Design

3 2 Motivation: System-on-a-Chip Design s Migration of the system from board to chip s Complexity of chip design increases s “IP reuse”- based design methodology u DSM technologies:

4 3 Communication Design u Determine a protocol so that no matter what the communication topology and the nature of the IP’s the functionality of the overall system is guaranteed (TCP/IP like) u Given the IP set and the interconnections, automatically synthesize protocols and macro-shells u Given the IP set and a set of time-varying interconnections, automatically synthesize adaptive protocol and macro-shells that optimize “performance” according to the current topology

5 4 12/09/1999 Communication Refinement u abstract from implementation concerns : s multi-target VC, s bus-independent VC system transaction, «ANY» data structure (e.g. video line) hardware or software ANY BUS» operation (data, address...) « ANY BUS» operation (data, address...) VSI-Alliance OCB Group. Virtual Component Interface (VCI) Physical Bus (e.g. PIBus) fixed bus-width, detailed protocol Bus Wrapper Communication Interface (e.g. bounded FIFO)

6 5 Communication-based Design MacroShells (the Protocol Interface) Communication Channels MicroShells (the IP Requirements) P1 P2 P3 P4 P5 P6 P7 Pearls (the IP Processes)

7 6 Motivation u System-level verification of large component-oriented designs will be very costly. u We cannot afford to debug interface mismatches between internal components u... especially considering that there will be many, many interfaces between so many components. u Current situation is unacceptable s Interfaces are not specified precisely s No clear specification formalism exist. s Tools to create, debug, and make maximal use of the specifications don’t exist.

8 7 The dream: formalize first! u Formal specifications will be written, conformed to, and used. u Standards will be precise and unambiguous u Specifications will be used for s Simulation s Formal verification s Semiformal verification s Synthesis u Same specification will be used for all these purposes

9 8 Basic Goals u Identify precisely and formally the concept of communication, its level of abstraction and of the corresponding models of computation. u New theories to combine different models of computation u Determine a set of properties that characterizes each level of abstraction. u Provide methods and tools to extract formal properties and specifications from informal ones and existing, ambiguously specified standards.

10 9 Basic Goals u Formal synthesis of protocols u Bus architectures analysis and verification s formal specs s monitors s semi-formal analysis u Abstract the notion of communication architectures and include estimation processes to quickly evaluate different architecture u Protocol design for the Pico-radio and the Universal Spectrum Radio u Formalize the specs of PCI and other busses and propose new ways of verifying them

11 10 Coping with Complexity u Decomposition s of the problem: separation of concerns s of the object: exploit compositionality u Formalization s precise unambiguous semantics s properties and formal techniques u Abstraction s eliminate unnecessary details u Incremental Refinement s include details while preserving properties

12 11 Why separating computation and communication? u Verification (debugging). If not: s Communication hard-wired with computation s Often hard to tell who is at fault s Bugs may be distributed, difficult to track down s Changes in the system may require rewriting of entire blocks, often leading to new bugs u Reuse s Component may be plugged in different environments s Functions and interface behavior are difficult to separate u Architecture exploration s Design components with abstract communication primitives s Explore different implementations without touching the component

13 12 Orthogonalizing Communication from Behavior u Historically lots of work on Behavior s hierarchy well established s several descriptions available (with variable levels of precision) s synthesis u Communication less well investigated s hard to separate from behavior, usually intertwined s telecomm protocols are the best existing example u Need to understand Formalism, Abstraction, and Refinement for communication

14 13 Formalism, Abstraction, and Refinement u Formalism for Communication s Precise semantics for complex transactions s Multi-way communication, arbitration, addressing s Distributed control u Abstraction and Refinement s Complex transaction mapped onto more primitive transactions s Elements of transaction refined onto concrete resources (pins, times)

15 14 Phone call

16 15 Decomposition of Phone Call Connect Talk Disconnect ATM Cell Bus Write

17 16 Refinement - Simple substitute repartition

18 17 Refinement - More Complex 0 1 200 1000

19 18 Abstraction u Performance Model Abstraction Levels s Budget number, constant s Stochastic model with variation s Estimation based on approximate use of lower level abstraction s Actual simulation using lower level abstraction

20 19 Properties and Refinement u Each model of computation guarantees some properties u Protocols also imply properties s out of order, error correction, reliable packet delivery u As you refine, must preserve properties s if order must be preserved s can refine to out-of-order communication method (like ethernet) s but have to reassemble in proper order

21 20 Elements of Refinement u Time vs Space s fewer resources means spreading out over time s extra handshaking means spreading out over space u Arbitration s sharing resource between independent communication paths s data dependent arbitration u Uneven source/sink speeds may require buffering u Access to & storage for buffer memories may be shared s address computation s arbitration again

22 21 MPEG Algorithm Audio In Audio Decode Video In Video Decode Frame buffer Onscreen Display Host I/F Video out

23 22 MPEG Architecture Audio In Audio Decode Video In Video Decode Onscreen Display Host I/F Video out MMU/AGU Memory buffers + frame buffer shared bus Registers

24 23 Description Method Audio In Audio Decode Video In Video Decode Onscreen Display Host I/F Video out MMU/AGU Memory Registers Architecture Audio In Audio Decode Video In Video Decode Frame buffer Onscreen Display Host I/F Video out Algorithm Map

25 24 VCC Key Technology Communication Refinement Communication Refinement Flow To Implementation Mapping System Behavior System Architecture Performance Simulation Behavior Simulation 21 3 4 Refinement from abstract tokens to articulated signals Value s Design and simulate at the level of abstraction at which designers think (e.g. ATM cell, GSM frame) s hide implementation details of the communication until it is required (but simulate it’s overhead!) s refine from abstract token level down to implementation of interface signals s evaluate performance trade offs of communication effects

26 25 CPU VCC Model VCC Model to RTOS Protocol Component CPU to Bus Protocol Component Bus Bus Slave to VCC Model Component Bus Model Bus VCC Model Bus to Bus Slave Component Bus Slave RTOS RTOS to CPU Protocol Component Communication Refinement Flow To Implementation Mapping System Behavior System Architecture Performance Simulation Behavior Simulation 21 3 4 VCC Key Technology Communication Interface Synthesis Synthesize communication pattern through architecture Value s Choose from comprehensive set of communication pattern s Pattern for HW-SW, SW-HW, HW-HW and SW-SW communication available s move function between HW and SW boundaries and re-synthesize the communication interface s customize platform communication environment through JAVA scripts

27 Metropolis etropolis

28 27 Metropolis Point Tools: Analysis/Verification Metropolis Framework Design of Communication Media Design of Function Processes Design of Architecture Components Metropolis Infrastructure Model of computation Design methodology - Abstraction levels - Refinement Base tools - Design imports - User interface - Simulation Metropolis Point Tools: Synthesis/Refinement

29 28 What is Communication? SR Isosiror Os = Fs(is)Or = Fr(ir)

30 29 What is Communication? SR Isosiror Os = Fs(is) Or = Fr(ir) u Connection C enables the interaction between the behaviors S and R Connection C

31 30 What is Communication? SR’ IsosIr’Or’ Os = Fs(is) Or’ = Fr’(ir’) FsFr Fc Ideal Connection

32 31 What is Communication? SR’ IsosIr’Or’ Os = Fs(is) Or’ = Fr’(ir’) u S restricts the behavior of R to R’ FsFr’ Fc Ideal Connection

33 32 Behavior Adaptation SR Isosiror Os = Fs(is) Or = Fr(ir) FsFr Fc u R not defined for some output of S: behavior mismatch Ideal Connection

34 33 Behavior Adaptation SR Isosiror Os = Fs(is) Or = Fr(ir) FsFr Fc u Behavior Adapter Z maps outputs of S into the domain of R Z = Z’ o Z’’ Fz

35 34 Behavior Adaptation Is’ Ir’ Or’ Os’ = Fs’(is’) = Fs o Z’(is’)Or’ = Fr’(ir’) = Fr o Z’’(ir’) u Behavior Adapter encapsulates S and R u S’ and R’ communicate successfully over an ideal connection S’ R’ Os’ Z’ Z’’

36 35 Physical Channels Is’ Ir’ Or’ Os’ = Fs’(is’)Or’ = Fr’(ir’) u Invalid Channels may introduce mismatch due to their physical properties (noise, interference…) u Valid Channels satisfy QoS requirements s QoS-equivalent to the ideal connection ( Fs’ o Fc o Fr’ ~ Fs’ o Fr’ ) S’ R’ Os’ C Fs’Fr’ Fc = id

37 36 SC Channel Adapter Is’Or’ Os’ = Fs’(is’)Or’ = Fr’(ir’) u Choose SC and CR such that C’ is valid  Fs’ o Fsc o Fc o Fcr o Fr’ ~ Fs’ o Fr’ u Channel Adapter may introduce behavior mismatch s need a Behavior Adapter S’ R’ C CR C’

38 37 FIFOs as Behavior Adapters SR u FIFOs adapt the rates of S and R u Unbounded FIFOs s ideal adapter u Bounded FIFOs s to prevent overflow, restrict S using blocking write (Req/Ack) S’

39 38 Z’’ Protocol Design SR SR SR C = id S (Ideal) Connection S C = id Behavior Adaptation Physical Channel selection Channel Adaptation Behavior Adaptation Z Z’ SC Z’SC CRZ’’ CRZ’’ R R Z’’’Z’’’’

40 39 Protocol Design (Ideal) Connection S S SR S S R S SR C = id S S S R S R Behavior Adaptation Physical Channel selection Channel Adaptation Behavior Adaptation

41 Metropolis: Model of Computation u System function: a network of processes s process: sequential function + ports u Do not commit to particular communication semantics s ports: interconnected by communication media s communication media: define communication semantics e.g. queues, shared memory, …, generic,... u Do not commit to particular firing rules of processes s a special construct to define interaction between processes and media CM


Download ppt "Communication-Based Design 2 Motivation: System-on-a-Chip Design s Migration of the system from board to chip s Complexity of chip design increases s."

Similar presentations


Ads by Google