1. CADENCE CONFIDENTIAL Design Methodologies for the Nanotechnology Era Alberto Sangiovanni-Vincentelli

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

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

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

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

8. 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 ASV Platforms (2001) 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. Upper layer of abstraction Lower layer of abstraction Constraints Performance Annotation In general, a platform is an abstraction layer that covers a number of possible refinements into a lower level. Platform Mapping Tools Platform Platform stack {

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

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. Picoradio Sensor Networks (BWRC) u Control Environmental parameters (temperature, humidity…) u Minimize Power consumption u Cheap (<0.5$) and small ( < 1 cm 3 ) u Large numbers of nodes — between 0.05 and 1 nodes/m 2 u Limited operation range of network — maximum 50-100 m u Low data rates per node — 1-10 bits/sec average u Low mobility (at least 90% of the nodes stationary) sensor actuator controller 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 Network Design Using Platforms Application components Requirements Components Adaptation Communication Refinement (Protocol Stack + Gateways) On-Chip Networks

14. Network Platforms event trace: e s11, e s12, e s13 e r 1 1, e r 1 2 e r21, e r22, e r23 e s21, e s22 node link port I/O port 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)

15. 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 PP NP’ 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. 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 P1P2U1U2 read write

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

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 1Protocol 2 Are the two protocols compatible? Interface Theories [de Alfaro and Henzinger]

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

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

23. Communication Synthesis Platform P2P Specification Communication Implementation

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

25. Constraints –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” Abstract Model

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

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

28. Communication Implementation Lib nr l1 l2

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

30. Metropolis meta-model 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 Concurrent specification with a formal execution semantics: Key difference with respect to Ptolemy, UML, SystemC, …!!! Concurrent specification with a formal execution semantics:

31. Meta-model : function netlist process P{ port reader X; port writer Y; thread(){ while(true){... z = f(X.read()); Y.write(z); }}} 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(){... } } interface reader extends Port{ update int read(); eval int n(); } interface writer extends Port{ update void write(int i); eval int space(); } M P1 X Y P2 X Y Env1 Env2 MyFncNetlist R I FA M

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. 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 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))); ]] } … scheduler BusArbiter extends Quantity implements BusArbiterService { update void request(event e){ … } update void resolve() { //schedule } } interface BusMasterService extends Port { update void busRead(String dest, int size); update void busWrite(String dest, int size); } interface BusArbiterService extends Port { update void request(event e); update void resolve(); } BusArbiter Bus R I FA M

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

35. Meta-model: platforms interface MyService extends Port { int myService(int d); } medium AbsM implements MyService{ int myService(int d) { … } } B(thisthread, AbsM.myService) B(P1, M.read); E(thisthread, AbsM.myService) E(P2, M.write); refine(AbsM, MyMapNetlist); MyArchNetlistMyFncNetlist M P1 P2 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); MyMapNetlist1 MyArchNetlistMyFncNetlist M P1 P2 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); MyMapNetlist1 B(…) B(…); E(…) E(…); refine(AbsM, MyMapNetlist1) MyArchNetlistMyFncNetlis t M P1 P2 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); MyMapNetlist2 M B(…) B(…); E(…) E(…); refine(AbsM, MyMapNetlist2) A set of mapping netlists, together with constraints on event mappings, constitutes a platform (constrained set of possible implementations) with a given interface. R I FA M R I FA M

36. Meta-model: recursive platforms S N N' 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); MyArchNetlistMyFncNetlist M P1 P2 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); RTOSNetlist MyArchNetl ist MyFncNe tlist M P1 P2 B(P2, M.read) B(P2, mP2.readCpu); E(P2, P2.f) E(mP2, mP2.mapf); M RTOS

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

38. Motivation Optimality?Exploration?

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 Behavioral models – Matlab, Excel, … – Define Block requirements Circuit design – Size, Simulate and iterate Layout design – Verify and iterate System Level Exploration Circuit Sizing & Synthesis

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

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

45. Analog Platforms The Analog Platform (AP) concept applies at different levels of abstractions –Custom circuits – APs can be derived by automatic characterization of 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 r in, i 2 noise, g 1, g 2, g 3, f -3dB, r out ? –Feasible (compatible) values depend on the real implementation of the platform optimization v out v in gain Behavioral Model Ideal 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 ) {W 1, W 2, …, L 1, L 2, …, I B1, …, V B1,..} –  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  

51. Constraint Relations (II) Operatively –define  and  (define architectural space) –get  = f(  ) –build a relation  (x)=1  x    needs to sample the image of  –  is a n-dimensional space –Limit n by proper definition of  –Keep granularity as low as possible –Trade-offs with composition modeling –Design of Experiments –Capture designer experience to prune  –Build a constraints graph for the circuit   W L G NF 

52. Generating f(  ) Given the definitions of  and , and a constraint graph, f (  ) is randomly sampled Operatively, Ocean scripts templates are available to automate the process Sampling is computationally expensive but requires no man- power –On the order of 1000 samples may be necessary depending on the accuracy and on the “size” of 

53. Example Example: –Original,  7   7 –Shown, projection in  3

54. Proposed Methodology Separate the design of single blocks from the system optimization –Third party’s platforms –Largest performance improvements come from new topologies –Do not limit designer’s creativity Generate functional models Generate performance models Perform system optimization at the behavioral level –use hierarchical models and refinement to select topology

55. Analog Design Flow Mapping Performance Eval/ System Optimization PLL Behavioral Models Int. APsExt. IP’s Performance Models New APs Behavior Refinement Architecture Refinement

56. Constraints Interpolation Given a set of samples, build an approximation for  –because of the generality of the evaluation scheme, few properties can be leveraged Assume the evaluation to define a continuous function –reasonable while exploring “working” circuits Assume  to be a connected set Then,  is a connected set in  m –given x 1 and its nearest neighbor x 1N, if they are “close enough” then all the points in the segment x 1 -x 1N satisfy  Therefore, approximate  with the smallest connected set containing the sample points

57. Support Vector Machines Statistical learning machinery to infer  from data SVM’s belong to the class of large margin classifiers –pioneered by Vapnik and Chervonenkis in the Sixties Simple conceptual model: hyperplane classifiers –Separate data into classes using hyperplanes –Can manage complex models –Still mathematically analyzable –Good control on (over)fitting

58. Operations on Platforms Analog Platforms stacks require three operations to be defined: Abstraction – Given a detailed platform, generate constraints for an abstracted AP Composition – Given constraints for two connected APs, derive constraints for the composition Merge – Given different platforms for the same functionality, generate constraints considering the union of  s

59. Abstraction Top-down flows and model hierarchies require to derive multiple abstraction for one block Use relations  where some of the parameters are free –  {Power, Gain, NF} =  {Power, Gain, NF, , ,  } –  {Power, Gain, NF} =1   IIP3 *, P -1dB *, DR *,… s.t.  {Power, Gain, NF, IIP3 *, P -1dB *, DR *,…}=1 –  are obtained from  by projection onto a smaller  This happens when the model is more general than the implementation

60. Projection on SVMs Need an efficient way to compute  –maximize with respect to x  (x=[x x  ]   m ) –global optimization of a nonlinear function –simulated annealing –ad hoc technique –optimum in the neighborhood of some SV –complexity o(nl) –2 orders of magnitude faster than SA

61. Composition Composability is a key requirements for building complex (hierarchical) models Behavioral models don’t have any intrinsic notion of loading effects Need to include interface characterization parameters in the relation  –include ancillary parameters in  –check compatibility of interfaces –Dynamic Range, Bias point… –automatic insertion of converters? Similar to Communication Based Design for the digital world

62. Composition Define: –x = [x ], y=[y, ], z=[x y] –  AB ([x y] ) = 1  s.t.  A ([x ] ) =  B ([y ] ) = 1 In terms of SVM’s Block A  A (x) Block B  B (y)

63. Merge Merge is defined in terms of performance relations building a new relation:  =  1 +  2 +…  k –  i are constraints for different Analog Platforms (e.g. for a single ended LNA, a differential LNA, cascoded and so on) –‘+’ is the logical OR function Architecture selection is achieved selecting platform instances in . The mapping process will then select  i

64. Closure Closure is a composition that involves a transformation in the abstraction space Closure defines a new platform that is non-trivially related to the composing ones –E.g., in a PLL, jitter of single components, non linearities and transfer functions get transformed into locking range, acquisition time, phase noise, … Closure is implemented through the same process used for AP generation on the first instance LF VCO PLL

65. Top-down with APs Complex optimization strategies can be used at system level –#params at top level is moderate to low –behavioral models reasonably fast Optimize the system and refine the architectural blocks At the end, a set of specs is provided for each Platform  Platform Instance –Constraints achievable by construction Generate the actual circuits –Designers, IP providers, Automatic tools … Proceed with appropriate bottom-up verification

66. Sensor Interface Example MEMS Pressure Sensor ADC Converter Signal Conditioning 10 bit 1 kSamples/s Input range: 0.5-1.5V Bandwidth: 500 Hz FSO: 200 mV R: 1000-2300   R/  T: 1800ppm Bridge Linearization Temperature Compensation Amplification DC Offset Nyquist Filter Comm. Adapter Synthesize and Map on Proper Platform Off-the-Shelf Components Field Programmable Analog Arrays Custom Solutions

67. Performance Representation Platform performance spaces are derived bottom-up by sampling platform instances u u Performances can be represented using Support Vector Machines (SVMs)

68. Fundamental Question and the Role of Platform-Based Design Question: –Will design and manufacturing become intertwined as in the past? Analysis: –Productivity higher if clean separation among layers of abstraction –Can we afford inefficiency in silicon? –If yes, what is the price to pay? Platform-based design is a disciplined methodology based on clean separation of layers of abstraction but favoring communication among different groups to mitigate negative impacts

69. Concluding Remarks Change in technology and market conditions will force a major design style shift towards IP re-use and programmable solutions Platforms will dominate many applications ASIC’s design starts will decrease further due to mask and NREs costs Embedded software will be a major emphasis in design Communication on chip and off chip will be the dominant part of design Analog will continue to be a major worry!