A Design Flow for the Development, Characterization, and Refinement of System Level Architectural Services

1. A Design Flow for the Development, Characterization, and Refinement of System Level Architectural Services Douglas Densmore Dissertation Talk and DES/CHESS Seminar May 15th, 2007 Committee Prof. Alberto Sangiovanni-Vincentelli (EECS) - Chair Prof. Jan Rabaey (EECS) Prof. Lee Schruben (IEOR)

2. Objective • To demonstrate that architecture service modeling in system level design (SLD) can allow abstraction and modularity while maintainingaccuracy and efficiency. #1 #2 #3 Time to Market

3. Outline • Problem Statement • Approach • Contribution • Motivating Factors • Design Trends and EDA Growth • Software Solutions • Programmable Platforms • Naïve Approach • My Improved Approach

4. Motivating Factors Problem Statement Approach Contribution Factor 1: Heterogeneity Year Existing and Predicted First Integration of SoC Technologies with Standard CMOS Processes1 Intel's PXA270 Mypal A730 PDA (digital camera and a VGA-TFT display) Courtesy:http://www.intel.com/design/embeddedpca/applicationsprocessors/302302.htm Solution 1: Modularity • D. Edenfeld, et. al., 2003 Technology Roadmap for Semiconductors, IEEE Computer, January 2004.

5. Motivating Factors Problem Statement Approach Contribution Factor 2: Complexity Courtesy: 1999 International Technology Roadmap for Semiconductors (ITRS) Solution 2: Abstraction

6. Motivating Factors 37% of new digital products were late to market! (Ivo Bolsens, CTO Xilinx) Digital Consumer Devices Set-Top Equipment Automotive Year late effectively ends chance of revenue! 50%+ revenue loss when nine months late. Three months late still loses 15%+ of revenue. Gartner DataQuest. Market Trends: ASIC and FPGA, Worldwide, 1Q05 Update edition, 2002-2008. Courtesy: http://www.ibm.com Problem Statement Approach Contribution Factor 3: Time to Market Solution 3: Accuracy and Efficiency Challenge: Remain modular and abstract

7. Design Trends and EDA Growth Ravi Krishnan. Future of Embedded Systems Technology. BCC Research, June 2005. Richard Goering. ESL May Rescue EDA, Analysts Say. EE Times, June 2005. Problem Statement Approach Contribution

8. Software Tools Solution Meta model language Meta model compiler Front end Abstract syntax trees ... Back end3 Back endN Back end1 Back end2 Simulator tool Synthesis tool Verification tool Verification tool Application Space Application Instance Platform Mapping System Platform (HW and SW) Platform Design-Space Export Platform Instance Architectural Space Problem Statement Approach Contribution • Platform Based Design1 is composed of three aspects: • Top Down Application Development • Platform Mapping • Bottom Up Design Space Exploration • Orthogolization of concerns2 • Functionality and Architecture • Behavior and Performance Indices • Computation, Communication, and Coordination. • Metropolis Meta Modeling (MMM) language4 and compiler are the core components. • Backend tools provide various operations for manipulating designs and performing analysis. Design Technology Improvements and Impact on Designer Productivity3 • A. Sangiovanni-Vincentelli, Defining Platform-based Design, EE Design, March 5, 2002. • K. Keutzer, Jan Rabaey, et al, System Level Design: Orthogonalization of Concerns and Platform-Based Design, IEEE Transactions on Computer-Aided Design, Vol. 19, No. 12, December 2000. • 2004 International Technology Roadmap for Semiconductors (ITRS). • F. Balarin, et al, Metropolis: an Integrated Electronic System Design Environment, IEEE Computer, Vol. 36, No. 4, April, 2003.

9. Programmable Platforms Problem Statement Approach Contribution What devices should the tools target? Programmable Platforms What? Why? A system for implementing an electronic design. Distinguished by its ability to be programmed regarding its functionality. One set of models represent a very large design space of individual instantiations. At extremes: Software Programmable – GPPs, DSPs Bit Programmable – FPGAs, CPLDs Platform FPGAs – FPGA Fabric & Embedded Computation Elements Strengths: Rapid Time-to-Market Versatile, Flexible (increase product lifespan) In-Field Upgradeability Performance: 2-100X compared to GPPs Weakness: Performance: 2-6x slower than ASIC Power: 13x compared to ASICs Next “digital wave” will require programmable devices.1 Courtesy: K.Keuzter • Tsugio Makimoto, Paradigm Shift in the Electronics Industry, UCB, March 2005.

10. Programmable Platform Focus Problem Statement Approach Contribution What do MY system level models need to capture? K. Bondalapati, V. Prasanna, Reconfigurable Computing Systems, USC IBM’s CoreConnect Architecture Xilinx Virtex II XC2VP30 MicroBlaze Xilinx Virtex II ML310 Board PowerPC P. Schaumont, et al, A Quick Safari Through the Reconfigurable Jungle, DAC, June 2001.

11. Naïve Approach Architecture Model Estimated n Abstract o Performance i I t a Data l m Modular u m p · Datasheets i SLD Tools S l · Expertise e m Manual e Bridge the Gap !! Disconnected n t “ C ” Model Inaccurate ! a t 2 . Synthesis i o Manual n w RTL “ Golden o G l F Model ” a l o p o Lengthy Feedback ! T c i t a m o t u Implementation A e Platform l b Inefficient i x e Miss Time to Market ! l f n I Problem Statement Approach Contribution 1 . Design Space Exploration

12. My Improved Approach Abstract Refined Problem Statement Approach Contribution Functional level blocks of programmable components Technique 1: Modeling style and characterization for programmable platforms Real Performance Data Estimated Performance Data Abstract Modular SLD From characterization flow Narrow the Gap Actual Programmable Platform Description New approach has improved accuracy and efficiency by relating programmable devices and their tool flow with SLD (Metropolis). Retains modularity and abstraction. Technique 2: Refinement Verification Formal Checking Methods Manual Informal Correct!!

13. Approach Statement Problem Statement Approach Contribution Problem: SLD of architecture service models potentially is inaccurate and inefficient. My Approach: A PBD approach to Architecture Service Modeling which allows modularity and abstraction. By relating service models to: • programmable platforms, • platform characterization, • and refinement verification, they will retain accuracy and efficiency.

14. Outline Revisited • Problem Statement • Approach • Contribution • My Improved Approach • Approach Statement • Architecture Service Descriptions • Metropolis Overview   • Programmable Architecture Service Modeling • Programmable Platform Characterization • Example of Techniques Focus:Modularity

15. Architecture Service Taxonomy Add DCT CPU C F C F C F Multi FFT Bus C F C F C F Problem Statement Approach Contribution Services are library elements, <F, C> where F is a set of interface functions (capabilities) and C is a set of cost models. Single Component, Single Interface (SCSI) – One provided interface and one simple cost model General Purpose Processor Xilinx Virtex II Pro Multiple Component, Multiple Interface (MCMI) – Two or more provided interfaces, zero or more internal interfaces, one or more simple cost functions, and zero or more complex cost functions. Abstract Multiple Component, Single Interface (MCSI) – One provided interface, one or more internal interfaces, and one or more complex cost functions. Services also classified as active or passive.

16. Service Based Arch. Styles Problem Statement Approach Contribution Assemble collections of services to provide larger sets of capabilities and cost functions. Branching Style – Allows for the usage of all types of services Ring Style – Allows for the usage of Single Interface (SI) services only MCMI Both Styles – Allow for the usage of active/passive and single/multiple component services. Hierarchy – Each style can be abstracted into composite services.

17. Metropolis Objects Proc1 P1 P2 Media1 I1 I2 QM1 Problem Statement Approach Contribution • Metropolis elements adhere to a “separation of concerns” ideology. • Processes (Computation) Active Objects Sequential Executing Thread • Media (Communication) Passive Objects Implement Interface Services • Quantity Managers (Coordination) Schedule access to resources and quantities

18. Metro. Netlists and Events QM1 Problem Statement Approach Contribution • Metropolis Architectures are created via two netlists: • Scheduled – generate events1 for services in the scheduled netlist. • Scheduling – allow these events access to the services and annotateevents with quantities. Scheduled Netlist Scheduling Netlist Proc1 Proc2 P1 P2 Global Time I1 Media1 I2 • E. Lee and A. Sangiovanni-Vincentelli, A Unified Framework for Comparing Models of Computation, IEEE Trans. on Computer Aided Design of Integrated Circuits and Systems, Vol. 17, N. 12, pg. 1217-1229, December 1998

19. Services in Design Flow Problem Statement Approach Contribution Metropolis Media

20. Programmable Arch. Modeling Problem Statement Approach Contribution • Computation Services • Communication Services • Other Services Services are organized by orthogonal aspects of the system. All services created here are XCMI with more than two provided interfaces each. Leverage function level granularity; 1-to-1 model/IP correspondence • Transaction Level • IP Parameters • I/O Interfaces PPC405 MicroBlaze SynthMaster SynthSlave Computation Interfaces Read (addr, offset, cnt, size), Write(addr, offset, cnt, size), Execute (operation, complexity) Processor Local Bus (PLB) On-Chip Peripheral Bus (OPB) Communication Interfaces addrTransfer(target, master) addrReq(base, offset, transType, device) addrAck(device) dataTransfer(device, readSeq, writeSeq) dataAck(device) BRAM Mapping Process OPB/PLB Bridge Task Before Mapping Read (addr, offset, cnt, size) Task After Mapping Read (0x34, 8, 10, 4)

21. Sample Metropolis Service Problem Statement Approach Contribution Each service profiled manually and given a set of cost models Non-Ideal

22. Programmable Arch. Modeling Problem Statement Approach Contribution • Coordination Services PPC Sched MicroBlaze Sched PLB Sched OPB Sched BRAM Sched General Sched • PostCond() • Augment event with information • (annotation). This is typically the • interaction with the quantity manager • Request (event e) • Adds event to pending • queue of requested events • Resolve() • Uses algorithm to select an • event from the pending queue GTime

23. Sample Metropolis QM Problem Statement Approach Contribution Each resolve() function is unique

24. Architecture Extensions for Preemption 4 . Update the FSM to track the state of the transaction . Event Initial State S 1 S 2 S 3 Transaction ( i . e . Read ) A 1 1 . A transaction is B 2 S1 introduced into the architecture model . 1 2 3 C 3 A B C 3 . Dispatch the atomic transaction ( AT ) Trans 1 FSM 1 to the quantity manager ( individual 2 . Decoder transforms events which make up the AT ). the transaction into atomic transactions Trans 0 FSM 0 setMustDo () 6 . Use Stack data structure to store SM setMustNotDo () transactions and FSMs 5 . Communication with preempted processes through StateMedia Problem Statement Approach Contribution • Some Services are naturally preempted • CPU context switch, Bus transactions • Notion of Atomic Transactions • Prior to dispatching events to a quantity manager via the request() method, decompose events in the scheduled netlist into non-preemptable chunks. • Maintain status with an FSM object (counter) and controller. Process Service ( Media ) ( Task ) Decoder ( Process) Quantity Manager FSM .

25. Architecture Extensions for Mapping Operations Ability to perform available operations Export information service from Export information from associated with service associated with Task Affinity Task Affinity mapping process mapping process Execute 0 / 100 Execute 50 / 100 100 / 100 DCT DCT 20 / 100 FFT 0 / 100 FFT 2 / 100 Dedicated HW General Purpose DCT uProc Only can perform DCT ! Problem Statement Approach Contribution • Programmable platforms allow for both SW and HW implementations of a function. • Need to express which architecture components can provide which services and with what affinity. public HashMap getCapabilityList() Mapping Mapping Process Process ( Task ) ( Task ) HW DCT uBlaze ( Service ) ( Service ) Can perform multiple operations Potential Mapping Strategies Greedy Best Average Task Specific

26. Programmable Arch. Modeling 1 . Assemble Netlists Structure Extractor 5 . Gather information and C Mapping T o parse into appropriate Process 4 . Extractor o n MicroBlaze MicroBlaze p tool format n Sched Script Tasks o e l c o t A . Identify parameters for File for Programmable OPB Sched i OPB g o y service . For example MHZ , Platform Tool Flow n Scheduled Netlist Scheduling Netlist s cache settings , etc . ( MHS ) Top Level Netlist Public netlist XlinxCCArch • Type XilinxCCArchSched schedNetlist ; XilinxCCArchScheduling schedulingNetlist • Parameters SchedToQuantity [] _ stateMedia • Etc B . Examine port C . Examine address D . Check port names , connections to mapping for bus , I / O , instance names , etc for determine topology . etc . instantiation . 2 . Provide Service Parameters 3 . Simulate Model Decide on final topology . Problem Statement Approach Contribution • Compose scheduling and scheduled netlists in top level netlist. • Extract structure for programmable platform tool flow. ModularModeling Style Accurate & Efficient

27. Characterization in Design Flow Problem Statement Approach Contribution Work with Xilinx Research Labs • Douglas Densmore, Adam Donlin, A.Sangiovanni-Vincentelli, FPGA Architecture Characterization in System Level Design, Submitted to CODES 2005. • Adam Donlin and Douglas Densmore,Method and Apparatus for Precharacterizing Systems for Use in System Level Design of Integrated Circuits, Patent Pending.

28. Prog. Platform Characterization Problem Statement Approach Contribution Need to tie the model to actual implementation data! 1. Create template system description. Process from Structure Extraction 2. Generate many permutations of the architecture using this template and run them through programmable platform tool flow. 3. Extract the desired performance information from the tool reports for database population.

29. Prog. Platform Characterization Problem Statement Approach Contribution Create database ONCE prior to simulation and populate with independent (modular) information. 1. Data detailing performance based on physical implementation. 2. Data detailing the composition of communication transactions. 3. Data detailing the processing elements computation. From Char Flow Shown From Metro Model Design From ISS for PPC

30. Characterized Data Organization } Index System 1 System N Method } 4 . 2 ns 3 . 8 ns Physical 4 ns 3 . 2 ns Timing ISS uProc 1 FFT 20 Cycles } Filter 35 Cycles Computation Timing ISS uProc 2 FFT 10 Cycles Filter 30 Cycles } Transaction Timing Problem Statement Approach Contribution Metro Characterizer Model Each system interface function characterized has an entry. These indices can be a hashed if appropriate. ? ? Entries can share data or be independent. ? ? NULL ? Entries can have all, partial, or no information. ? ? How is the data associated with each service interface function?

31. Prog. Platform Characterization ModularCharacterization Accurate & Efficient Problem Statement Approach Contribution Why can’t you just use a static estimation? • Design from rows 1, 3, and 5 of the table. • Three abstraction levels: 1, 3, and 10 cycle transactions. • Metropolis JPEG version: 112,500 write transactions for 3 MegaPixel, 24 bit color depth, 95% compressed image. • 19% difference between intuition and characterization. • As resource usage increases system frequency generally decreases. • Not linear nor monotonic. • 15% change is a speed grade for the devices. Created database once prior to simulation. PLB Write Transfer Performance Comparison

32. Modeling & Char. Review Problem Statement Approach Contribution Branching Architecture Example Scheduling Netlist Task1 Task2 Task3 Task4 DEDICATED HW DedHW Sched MCMI PPC PPC Sched Global Time MCMI PLB PLB Sched MCMI BRAM Sched BRAM SCSI Scheduled Netlist Characterizer Media (scheduled) Process Enabled Event Quantity Quantity Manager Disabled Event

33. Outline Revisited • Problem Statement • Approach • Contribution • Architecture Refinement Verification • Vertical Refinement • Horizontal Refinement • Surface Refinement • Depth Refinement • Design Flow Examples • Summary and Conclusions Focus:Abstraction

34. Arch. Refinement Verification Architectures often involve hierarchy and multiple abstraction levels. Limited if it is not possible to check if elements in hierarchy or less abstract components are implementations of their counterparts. Asks “Can I substitute M1 for M2?” Representing the internal structure of a component. Recasting an architectural description in a new style. Applying tools developed for one style to another style. Problem Statement Approach Contribution D. Garlan, Style-Based Refinement for Software Architectures, SIGSOFT 96, San Francisco, CA, pg. 72-75.

35. Refinement Verification in Design Flow Problem Statement Approach Contribution • Surface Refinement1 • Interface Based • Control Flow Graph • Focus on introducing new behaviors (Reason 1) • Vertical Refinement1 • Horizontal Refinement1 • Event Based • Event Based Properties • Focus on abstraction & synthesis (Reasons 2 & 3) • Depth Refinement • Compositional Component Based • Labeled Transition Systems • Focus on reasons 1, 2, and 3 1. Douglas Densmore, Metropolis Architecture Refinement Styles and Methodology, University of California, Berkeley, UCB/ERL M04/36, 14 September 2004.

36. Vertical Refinement Mapping Process Rtos PPC405 Cache PLB BRAM Problem Statement Approach Contribution Rtos Sched Mapping Process • Definition: A manipulation to the scheduled netlist structure to introduce/remove the number or origin of events as seen by the scheduling netlist. Cache Sched Sequential New origins and amounts of events scheduled and annotated PPC Sched PLB Sched Concurrent BRAM Sched Scheduling Netlist Scheduled Netlist

37. Horizontal Refinement Mapping Process Control Thread Rtos PPC405 Arb Cache PLB BRAM Problem Statement Approach Contribution Rtos Sched Mapping Process PPC Sched • Definition: A manipulation of both the scheduled and scheduling netlist which changes the possible ordering of events as seen by the scheduling netlist. PPC405 Cache Sched Ordering of event requests changed PPC Sched PLB Sched BRAM Sched Scheduling Netlist Scheduled Netlist *Contains all possible orderings if abstract enough

38. Event Based Properties Properties expressed as event sequences as seen by the scheduling netlist. Problem Statement Approach Contribution E1 (CPUExe) E2 (CPUExe) E3 (CPUExe) E4(CPURead) Resource Utilization Latency

39. Macro and MicroProperties Data Precision ( DP ) No Overflow ( NO ) Level 3 Sufficient Bits ( SB ) 1 2 Write Access ( WA ) Sufficient Space ( SS ) 1 0 Data Consistency ( DC ) Level 2 Read Access ( RA ) Data Valid ( DV ) 1 0 Data Coherency ( DCo ) Level 1 Snoop Complete ( SC ) 0 Problem Statement Approach Contribution MicroProperty - The combination of one or more attributes (or quantities) and an event relation defined with these attributes. MacroProperty – A property which implies a set of MicroProperties. Defined by the property which ensures the other’s adherence. The satisfaction (i.e. the property holds or is true) of the MacroProperty ensures all MicroProperties covered by this MacroProperty are also satisfied.

40. Event Petri Net Problem Statement Approach Contribution Model Event Petri Net – One transition set which represents events of interest, tEN. Transitions also are used to indicated interface functions. Link the two event petri nets together such that select tENs feed connection transitions, tCN, which produce the needed tokens for the property EPN. Two Petri Nets – One for the service model and one for the events of interest. Property Event Petri Net – Initial marking vector is empty. One place per Macroproperty, p<prop>. Created such that in order to create a token in each MacroProperty place, all transitions must fire once and only once.

41. Surface Refinement Def. Problem Statement Approach Contribution • Defined as in Hierarchical Verification1 • Model: An object which can generate a set of finite sequences of behaviors, B • Trace: a B • Given a model X and a model Y, X refines the model, denoted X < Y if given a trace a of X then the projection a[ObsY] is a trace of Y. • Two models are trace equivalent, X  Y if X < Y and Y < X. • The answer to the refinement problem (X,Y) is YES if X refines Y, otherwise NO TraceM – Trace in Metropolis = a finite set of function calls to media via interfaces 1. T.Henzinger, S.Qadeer, S.K. Rajamani, “You Assume, We Guarantee: Methodology and Case Studies”, 10th International Conference on Computer Aided Verification (CAV), Lecture Notes in Computer Science 1427, Springer-Verlag, 1998, p.440-451.

42. Control Flow Graph Hypothetical Automaton for X variable 1 2 3 X = 0 X = 1 X = 2 Control Location 1 1 Group Node Type : ProcessDeclNode Graph for Model Initial Control Location X = 0 Control Location 2 2 Group Node Type : LoopNode while loop X < 2 X > = 2 Control Location 3 Control Location 7 Group Node Type : 3 7 Group Node Type : ThisPortAccessNode ThisPortAccessNode Port 1 . callRead ()+ Port 2 . callWrite ()+ Control Location 4 Control Location 8 4 8 Group Node Type : None Group Node Type : None Ending of basic block Ending of basic block Port 1 . callRead () - Control Location 5 Port 2 . callWrite () - 5 Group Node Type : Collection of Variable Nodes X ++(+) Control Location 9 9 Control Location 6 Group Node Type : None 6 Group Node Type : Variable Sink State Node ( collection ) - End X ++( - ) 10 Control Location 10 Group Node Type : None Bookend of LoopNode Problem Statement Approach Contribution • Defined much like* • Tuple <Q, qo, X, Op, > • Q – Control Locations • qo – initial CL • X – set of variables • Op – function calls to media, basic block start and end •  - transition relation //sample code Process example{ port Read port1; port Write port2; Void thread(){ int x = 0; while (x < 2){ port1.callRead(); x++;} port2.callWrite(); }} *”Temporal Safety Proofs for Systems Code”, Henzinger et al.

43. Surface Refinement Domains Problem Statement Approach Contribution <C, P, OP>

44. Surface Refinement Example Problem Statement Approach Contribution Trace containment check for single threaded processes • Douglas Densmore, Sanjay Rekhi, A. Sangiovanni-Vincentelli, MicroArchitecture Development via Successive Platform Refinement, Design Automation and Test Europe (DATE), Paris France, 2004.

45. Surface Refinement Flow Metropolis Model (. mmm ) 1 3 2 CFG Backend Reactive Module Visual of CFG ( X ) ( automatic ) Representation Witness ( for debugging ) Module ( W ) 4 Kiss file of CFA 3 a £ Answer to X Y SIS Edit and Parallel FORTE 4 c Composition state _ assign script ( automatic ) ( manual ) 4 a Mode . exe file X || W BLIF file 3 b 4 b MOCHA Manual Edits to BLIF and NEXLIF 2 EXE Answer £ to X Y CFA ( Y ) developed in BLIF file developed in previous iteration previous iteration Problem Statement Approach Contribution Three primary branches: 1. Visual representation for debugging 2. CFG conversation to a reactive module. Works with the MOCHA tool flow. Requires manual augmentation of a witness module since Y has private variables. 3. CFG conversation to a KISS file. Works with the SIS and Forte tool flows. Requires manual edits to BLIF to EXLIF.

46. Depth Refinement - LTS Service Write Read Read2 Write2 Problem Statement Approach Contribution • Depth Refinement – Want to make inter-component structural changes. • Definition: A Labeled Transition System (LTS) is a tuple <Q, Q0, E, T, l> where: • Q is a set of states, • Q0  Q is a set of initial states, • E is a finite set of transition labels or actions, • T  Q x E x Q is a labeled transition relation, and • l : is an interpretation of each state on system variables. • But in LTS there is no notion of input signals • When we compose LTS, a transition can be triggered when another LTS is in a given state. Olga Kouchnarenko and Arnaud Lanoix. Refinement and Verification of Synchronized Component-Based Systems. In FME 2003: Formal Methods, Lecture Notes in Computer Science, volume 2805/2003, pages 341–358. Springer Berlin / Heidelberg, 2003

47. Refinement Rule 1 Problem Statement Approach Contribution Strict transition refinement • If there is a transition in the refined LTS from one state to another, then there must be the same transition in the abstract • Note: The two transitions must have the same label!

48. Refinement Rule 2 Problem Statement Approach Contribution Stuttering transition refinement • If there is a new (tau) transition in the refinement LTS, then its beginning state and ending state must correspond to the same state in the abstract

49. Refinement Rule 3 Problem Statement Approach Contribution Lack of τ-divergence • There are no new transitions in the refinement that go on forever

50. Refinement Rule 4 Problem Statement Approach Contribution External non-determinism preservation • If there is a transition in the abstract and the corresponding refined state does not have any transition then • there must be another refined state that corresponds to the abstract • it must take a transition to another refined state and in the abstract must exist a state so that these two are glued together.