Design Methodologies for the Nanotechnology Era Alberto Sangiovanni-Vincentelli

1. Design Methodologies for the Nanotechnology EraAlberto Sangiovanni-Vincentelli

2. Outline • Motivation • Design Challenges • Platform-based Design • Communication-Based Design • Implementation Platforms: Constructive Fabrics • Analog Platforms

3. EDA Platform Based Design Fabrics Interfaces Disaggregation:Electronic Systems Design Chain System Design Implementation IP Manufacturing

4. ASIC Design Trend -27% Design Starts Source: IBS

5. Electronic Design: A Vision • Embedded Software will be increasingly critical in the Electronic Industry • Embedded Software Design must not be seen as a problem in isolation, it is an, albeit essential, aspect of EMBEDDED SYSTEM DESIGN • Our vision is to change radically the way in which ESW is developed today by linking it: • Upwards in the abstraction layers to system functionality • Downwards in the programmable platforms that support it thus providing the means to verify whether the constraints posed on Embedded Systems are met. • Programmable Platforms must be developed efficiently leveraging IP-reuse and Application Space knowledge • The future of the industry is pinned on the success of this plan

6. Outline • Motivation • Design Challenges • Platform-based Design • Communication-Based Design • Implementation Platforms: Constructive Fabrics • Analog Platforms

7. Application Programming Model: Models/Estimators Kernels/Benchmarks Architecture(s) Microarchitecture(s) G V V S S S Cycle-speed, power, area Functional Blocks, Interconnect Circuit Fabric(s) Manfacturing Interface Delay, variation, SPICE models Basic device & interconnect structures Silicon Implementation A Discipline of Platform-Based Design (ASV, GSRC 2000) Architectural Platform V S G S V S Silicon Implementation Platform S V S G V S

8. In general, a platform is an abstraction layer that covers a number of possible refinements into a lower level. Upper layer of abstraction Constraints Performance Annotation { Platform Platform stack Mapping Tools Lower layer of abstraction Platform For every platform, there is a view that is used to map the upper layers of abstraction into the platform and a view that is used to define the class of lower level abstractions implied by the platform. ASV Platforms (2001) The design process is meet-in-the-middle: • Top-down: map an instance of the top platform into an instance of the lower platform and propagate constraints • Bottom-up: build a platform by defining the “library” that characterizes it and a performance abstraction (e.g., number of literals for tech. Independent optimization, area and propagation delay for a cell in a standard cell library) The library has elements and interconnects

9. f1 f2 f3 System Behavior System Platform ECU-1 ECU-2 ECU-3 Mapping Evaluation of Architectural and Partitioning Alternatives Performance Simulation Bus Refinement Design Methodology: Orthogonalize Concerns Software ComponentsVirtual Architectural Components IPs C-Code Buses CPUs Buses Buses Matlab ASCET Operating Systems Analysis Specification Development Process Implementation Calibration After Sales Service

10. Consequences • There is no difference between HW and SW. Decision comes later. • HW/SW implementation depend on choice of component at the architecture platform level. • Function/Architecture co-design happens at all levels of abstractions • Each platform is an “architecture” since it is a library of usable components and interconnects. It can be designed independently of a particular behavior. • Usable components can be considered as “containers”, i.e., they can support a set of behaviors.

11. Outline • Motivation • Design Challenges • Platform-based Design • Communication-Based Design • Analog Platforms

12. Control Environmental parameters (temperature, humidity…) • Minimize Power consumption • Cheap (<0.5$) and small ( < 1 cm3) • Large numbers of nodes — between 0.05 and1 nodes/m2 • Limited operation range of network — maximum 50-100 m • Low data rates per node — 1-10 bits/sec average • Low mobility (at least 90% of the nodes stationary) actuator sensor controller Picoradio Sensor Networks (BWRC) • Key challenges • Satisfy tight performance and cost constraints (especially power consumption) • Identify Layers of Abstraction (Protocol Stack) • Develop distributed algorithms (e.g. locationing, routing) for ubiquitous computing applications • Design Embedded System Platform to implement Protocol Stack efficiently

13. Embedded System Platform On-Chip Networks Network Design Using Platforms Application components Requirements Components Adaptation Communication Refinement (Protocol Stack + Gateways)

14. Network Platforms node link • Network Platform (NP): Library of communication resources (protocols, channels…) • Network Platform Instance (NPI): selection of NP resources • Structure: set of resources and topology • Behavior: set of event traces (events model send or receive actions) port I/O port er11, er12 es11, es12, es13 es21, es22 er21, er22, er23 event trace:

15. NP P P NP’ Communication Refinement • Replace components in abstract NPI with set of resources or NPIs • Select resources from NP library and compose them to create NP with new Communication Services • NP resources • Channels (C ): transfer messages • Protocols (P): adapt Communication Services • Gateways (G): interface NPs • Check refined NPI satisfies constraints NP G NP2 NP1

16. Design of a Platform Layer: Ulysses • Protocol Synthesis from Scenario-based (UML) Specifications • Avoid early partitioning into components • Problems: optimality, scenario interactions • Specify scenarios independently • Compose scenarios

17. U1 P1 P2 U2 Ulysses • Pattern-based Design • Library of Protocol Patterns: framing, retransmissions • Multiple levels of abstraction (and Models) • UML Message Sequence Charts (MSCs) • Petri Nets (PNs) • PNs Synthesis from MSCs • Protocol synthesis and optimization driven by PN algorithms read write

18. Embedded System Platform On-Chip Networks Network Design Using Platforms Application components Requirements Components Adaptation Communication Refinement (Protocol Stack + Gateways)

19. Adaptation of Component Behavior: The essence of IP-reuse (GSRC) • The components in the NP library must come with specified abstract interfaces • The composition of components can either be direct, when the interfaces are compatible, or through an adaptor, if they can be made compatible • We provide a formulation of the problem that can be used to both verify compatibility and to synthesize the adapter

20. Interface Compatibility Protocol 1 Protocol 2 Are the two protocols compatible? Interface Theories [de Alfaro and Henzinger]

21. Interface Adaptability Protocol 1 Adapter Protocol 2 Can the two protocols be made compatible? Interface Synthesis [Passerone, Rowson, ASV]

22. Interface Synthesis Protocol 1 Adapter Protocol 2 Specification What does compatible really mean? [Passerone, de Alfaro, Henzinger, ASV]

23. Communication Synthesis Platform P2P Specification Communication Implementation

24. Communication Synthesis Platform Stack (bw1,d1) (bw3,d3) Communication Specs (bw4,d4) (bw2,d2) (bw5,d5) (x3,y3) (x4,y4) Links (x1,y1) (x2,y2) bw3+bw4 bw1+bw2 Comm. nodes Relay Stations Processes + Shells l=1 l=1 Wires Buffers CkSkew

25. Abstract Model • System modules communicate by means of point-to-point unidirectional channels • Each channel is characterized by a set of communication constraints(distance, minimum bandwidth) • The specific functionality of each module is “abstracted away” Constraints

26. b1 Cs(b) cost b2 Cs(b) Length Cr(b) Relay Station Switches clk Library This is the basic library of Communication Components

27. Synthesis of Communication Architecture Point-to-Point Channel Communication Constraints Synthesis Communication Architecture Implementation Library of Pre-designed Communication Components

28. Communication Implementation Lib l1 l2 n r

29. Application-specific methodologies Multi-media, wireless communication, mechanical controls, processors Meta-model Library • Models of computation Meta-model Library • Architecture platforms Tools … Simulator STARS PIG SPIN QSS Metropolis Framework Infrastructure • Metropolis meta-model - language - modeling mechanisms • Meta-model compiler

30. Concurrent specification with a formal execution semantics: Key difference with respect to Ptolemy, UML, SystemC, …!!! Metropolis meta-model Concurrent specification with a formal execution semantics: • Computation : f : X  Z • Communication : state evaluation and manipulation • Coordination : constraints over concurrent actions - process : generates a sequence of events - medium : defines states and methods - quantity: annotation of each event (time, energy, memory, …) - logic : relates events and quantities, defines axioms on quantities - quantity-manager : algorithm to realize annotation subject to relational constraints

31. MyFncNetlist P1 Y X M P2 Y X Env2 Env1 F A M I R Meta-model : function netlist process P{ port reader X; port writer Y; thread(){ while(true){ ... z = f(X.read()); Y.write(z); }}} interface reader extends Port{ update int read(); eval int n(); } interface writer extends Port{ update void write(int i); eval int space(); } medium M implements reader, writer{ int storage; int n, space; void write(int z){ await(space>0; writer ; writer) n=1; space=0; storage=z; } word read(){ ... } }

32. Meta-model: execution semantics • Processes take actions. • statements and some expressions, e.g. y = z+port.f(), port.f(), i < 10, … • An execution of a given netlist is a sequence of vectors of events. • event : the beginning of an action, e.g. B(port.f()), the end of an action, e.g. E(port.f()), null (no-op) N • the i-th component of a vector is an event of the i-th process • synchronous trace-based semantics • time and other quantities elapse and actions are executed in states • no assumption on atomicity whatsoever (unless explicitly modeled) • An execution is feasible if • it satisfies all coordination constraints, and • it is accepted by all action automata defining meta-model semantics

33. interface BusArbiterService extends Port { update void request(event e); update void resolve(); } interface BusMasterService extends Port { update void busRead(String dest, int size); update void busWrite(String dest, int size); } medium Bus implements BusMasterService…{ port BusArbiterService Arb; port MemService Mem; … update void busRead(String dest, int size) { if(dest== … ) Mem.memRead(size); [[Arb.request(B(busRead)); GTime.request(B(memRead), BUSCLKCYCLE + GTime.annotation(B(busRead))); ]] } … F A scheduler BusArbiter extends Quantity implements BusArbiterService { update void request(event e){ … } update void resolve() { //schedule } } M I R Bus BusArbiter Meta-model: architecture components An architecture component specifies services, i.e. • what it can do • how much it costs : interfaces : quantities, annotation, logic of constraints

34. MyArchNetlist … … F A … M Bus Arbiter I Bus R CPU + OS Arbiter Mem Mem Cpu OsSched Master Slave Meta-model: architecture netlist Architecture netlist specifies configurations of architecture components. Each constructor - instantiates arch. components, - connects them, - takes as input mapping processes.

35. medium AbsM implements MyService{ int myService(int d) { … } } refine(AbsM, MyMapNetlist2) B(…) <=> B(…); E(…) <=> E(…); B(thisthread, AbsM.myService) <=> B(P1, M.read); E(thisthread, AbsM.myService) <=> E(P2, M.write); refine(AbsM, MyMapNetlist); refine(AbsM, MyMapNetlist1) B(…) <=> B(…); E(…) <=> E(…); MyMapNetlist2 MyMapNetlist1 F F A A B(P1, M.write) <=> B(mP1, mP1.writeCpu); B(P1, P1.f) <=> B(mP1, mP1.mapf); E(P1, P1.f) <=> E(mP1, ) B(P2, M.read) <=> B(P2, mP2.readCpu); E(P2, P2.f) <=> E(mP2, mP2.mapf); B(P1, M.write) <=> B(mP1, mP1.writeCpu); B(P1, P1.f) <=> B(mP1, mP1.mapf); E(P1, P1.f) <=> E(mP1, ) B(P2, M.read) <=> B(P2, mP2.readCpu); E(P2, P2.f) <=> E(mP2, mP2.mapf); M M I I P1 P2 P1 P2 MyFncNetlist MyArchNetlist MyFncNetlist MyArchNetlist M M R R MyMapNetlist1 M B(P1, M.write) <=> B(mP1, mP1.writeCpu); B(P1, P1.f) <=> B(mP1, mP1.mapf); E(P1, P1.f) <=> E(mP1, ) B(P2, M.read) <=> B(P2, mP2.readCpu); E(P2, P2.f) <=> E(mP2, mP2.mapf); P1 P2 MyFncNetlist MyArchNetlist M Meta-model: platforms A set of mapping netlists, together with constraints on event mappings, constitutes a platform (constrained set of possible implementations) with a given interface. interface MyService extends Port { int myService(int d); }

36. B(Q2, S.cdx) <=> B(Q2, mQ2.excCpu); E(Q2, M.cdx) <=> E(mQ2, mQ2.excCpu); B(Q2, Q2.f) <=> B(mQ2, mQ2.mapf); E(Q2, P2.f) <=> E(mQ2, mQ2.mapf); N' N S RTOSNetlist B(P2, M.read) <=> B(P2, mP2.readCpu); E(P2, P2.f) <=> E(mP2, mP2.mapf); P1 P2 MyFncNetlist MyArchNetlist B(P1, M.write) <=> B(mP1, mP1.writeCpu); B(P1, P1.f) <=> B(mP1, mP1.mapf); E(P1, P1.f) <=> E(mP1, ) B(P2, M.read) <=> B(P2, mP2.readCpu); E(P2, P2.f) <=> E(mP2, mP2.mapf); M M P1 P2 MyFncNetlist MyArchNetlist M Meta-model: recursive platforms RTOS

37. Outline • Motivation • Design Challenges • Platform-based Design • Communication-Based Design • Analog Platforms

38. Motivation Exploration? Optimality?

39. Focus • Focus on System Level Design • Enable effective design exploration • Evaluate tradeoffs while proceeding top-down • Allow integration of third-party components • Move design optimization as high as possible • Co-design with the digital part (BB+Protocol) • Not HW/SW co-design, but HW/SW/Analog!

40. Analog Design Flow • System Specs SystemLevelExploration • Behavioral models • Matlab, Excel, … • Define Block requirements • Circuit design • Size, Simulate and iterate Circuit Sizing &Synthesis • Layout design • Verify and iterate

41. Analog Design Flow • System Specs SystemLevelExploration • Behavioral models • Matlab, Excel, … • Define Block requirements Analog Platform • Circuit design • Size, Simulate and iterate Circuit Sizing &Synthesis • Layout design • Verify and iterate

42. Analog Platforms • An Analog Platform is a library of analog components and interconnects that implements a set of functionalities • An Analog Platform consists of: • Behavioral models – provide an efficient way to simulate mapping effects at the current platform level • Performance models – constrain the possible behaviors to the considered platforms

43. Analog Platforms • Classic top-down approaches suffer for limited predictability of performances  Introduce a new level of abstraction • Platforms abstract underlying components providing: • Estimation mechanisms (i.e. models) for platform level optimization • Mapping mechanisms to propagate constraints to next level • Platforms provide accurate exploration mechanisms by limiting the search space • Platforms may encapsulate synthesis paths

44. Sw.Cap Cont.T. Mapping Tools OpAmp Performance Estimation Diff. S.Ended OpAmp Lib1 OA Lib2 Analog Platform Stacks • APs allow efficient top-down flows for analog systems • At each level of abstraction in the platform stack, performance models allow transforming requirements into satisfiable next-level constraints • Any platform instance is implementable by definition Filter • Platform stacks allow the selection of optimal architectures and topologies for analog components

45. Analog Platforms • The Analog Platform (AP) concept applies at different levels of abstractions • Custom circuits – APs can be derived by automatic characterizationof the circuit • IPs – APs can be used to encapsulate and characterize Intellectual Properties (possibly customizable Synthesizable Cores) • Programmable cores – Field Programmable Analog Arrays (FPAA) provide the first example of generic analog platform

46. Behavioral Models • A behavioral model is a mathematical parameterized representation of a circuit/component • still a functional model, no notion of architecture • How to select rin, i2noise, g1, g2, g3, f-3dB, rout? • Feasible (compatible) values depend on the real implementation of the platform optimization vin vout gain Ideal Model Behavioral Model

47. Behavioral Models Hierarchy • Behavioral models should be organized in form of trees, one for each functional block • the root node represent the universal model for the functionality • deeper nodes represent refined models, which already have some architectural assumption • leaf nodes represent the most detailed behavioral models specific for implementation architectures

48. Model Representation • Right now, continuous time prototypes in Matlab/Simulink • easy to use and powerful prototyping environment • integration with external code • de facto standard among analog system designers • However, HDL-A languages may represent a viable alternative • more industrial environment • tool integration • Co-simulation/co-verification?

49. Performance Models • Top-down flows need to estimate performances • Constrain behavioral models parameters • set of compatible {gain, noise, dist.,…} n-tuples • Architectural constraints can be represented through mathematical relations • (Power, Gain, NF, IIP3, P-1dB, DR, …) = 1 {Power, Gain, NF,…} are feasible with the current Platform • No need for considering actual design variables that achieve specific performances • Abstract away unnecessary implementation details

50. Constraint Relations (I) • Approximate  off-line through sampling • Build estimation methods bottom-up • Let’s define: •  is the set of n-tuples (  n) {W1, W2, …, L1, L2, …, IB1, …, VB1, ..} •  is the set of m-tuples (  m){Power, Gain, NF, IIP3, P-1dB, DR,…} • AP Evaluation defines a function f: n m • f() can be evaluated in different ways • analytical expressions • simplified models/simulations • Spice accurate simulations  