Presentation is loading. Please wait.

Presentation is loading. Please wait.

Workshop - November 2011 - Toulouse L. Maillet-Contoz, STMicroelectronics.

Similar presentations


Presentation on theme: "Workshop - November 2011 - Toulouse L. Maillet-Contoz, STMicroelectronics."— Presentation transcript:

1 Workshop - November 2011 - Toulouse L. Maillet-Contoz, STMicroelectronics

2 © STMicroelectronics System Platforms Group 10 years experience in SoC modeling Definition of ESL methods and tools Deployment in ST & ST-Ericsson product groups since 2003 Contributions to projects of the various products groups Drive standards Corporate Member, OSCI and Accellera Represents ST at both Boards of Directors Several donations to the Technical Working Groups TLM1 & TLM2, CCI IP-Xact Former Chair of OSCI board & TLM WG, current Chair of OSCI Verification WG Current chair of Accellera IP-Xact TSC Vice Chair of IEEE 1666-2011 Technical Committee Workshop - November 20112

3 © STMicroelectronics Agenda Motivations for SoC TLM modeling Languages and abstractions for System Level Design Current standards for interoperability ST TLM Framework Discussion and conclusion 3

4 © STMicroelectronics Objectives: face SoC increasing complexity A camera-telephone? Version 1998 Version 2008 4

5 © STMicroelectronics HDL simulation - Too late - Too slow + Accurate FPGA prototype - Too late - Too costly + Accurate Motivations for Virtual Prototyping Pre-silicon software developmentFunctional validation environment SoC architecture exploration Soc Virtual Prototype 5

6 © STMicroelectronics SoC Virtual Prototyping Input devices SW Transaction Level Models (HW blocks) H.M.P. SoC Output devices 6

7 © STMicroelectronics Agenda Motivations for SoC TLM modeling Languages and abstractions for System Level Design SystemC and IP-Xact Loosely and Approximately Timed modeling styles Impact on modeling effort and simulation speed Current standards for interoperability ST TLM Framework Discussion and conclusion 7

8 © STMicroelectronics Different platforms for different use models All activities do not require cycle accuracy Engineering effort to be balanced with benefits Fast / precise trade-off 8

9 © STMicroelectronics Languages for System Level Design General Purpose Languages C, C++, Java, … Well known Standard  Not appropriate for hardware modeling Dedicated Languages SpecC, HardwareC, … Well defined semantics  Proprietary  Lack of support  No model exchange Hardware Description Languages VHDL, Verilog, … Nice for hardware modeling Not appropriate for high level modeling Slow 9

10 © STMicroelectronics Different abstraction levels prior to HW/SW partition Level of Abstraction RTL Register Transfer Level PVT – Approximately Timed Programmer’s View + Timing PV – Loosely Timed Programmer’s View CA Cycle Accurate Level AL Algorithmic Model post HW/SW partition models bit-true behavior, register bank, data transfer, system synchronization PV plus timing annotation timed IP models refined communication models models state at each clock edge ASIC flow entry point synthesizable model TLM supported abstraction levels 10

11 © STMicroelectronics Transaction Level Models (LT) Model IPs/subsystems at the transaction level Bit true behavior Bit true communication System synchronization points No clock/cycle, but functional timing (e.g. timer) Fast to implement and simulate Details of interconnect are abstracted TAC router TLM models often built using C reference model TLM wrapper Model registers serve read/write accesses 11

12 © STMicroelectronics Transaction Level Models (AT) Targetting performance evaluation Hardware architecture Software Captures micro-architecture information/timing Several technical options LT Model refinement -> rewriting LT Model annotation Intrusive Lightweight effort Composition of LT and T models 12

13 © STMicroelectronics Comparing abstraction levels TLM LT TLM AT RTL Same functional behavior Same timed behavior Same functional behavior 13

14 © STMicroelectronics Options for processor models (1/2) Native compilation Compile the embedded software on the workstation No model of the core micro-architecture/Instruction set No assembly code for target processor, nor binary code Source code level compatibility Sometimes requires to use a HAL Advantages & drawbacks Fast execution No dependency on low level processor dependent features Can not be used for performance evaluation 14

15 © STMicroelectronics Instruction Set Simulator Instruction Accurate Captures the Instruction Set Suitable for LT modeling style Cycle Accurate Represents the micro-architecture of the core Suitable for AT modeling style Various simulation technologies Instruction interpretation Dynamic translation Advantages and drawbacks Uses the target tool chain Binary code compatibility Slow for interpreted ISS 15 Options for processor models (2/2)

16 © STMicroelectronics 1st dimension: precision TIME OF PROJECT TIMING PRECISION TLM / LT bit-true RTL PAPER SPEC EXEC. SPEC DESIGNING RTL RTL EVOLVES UNTIL PG FIRST COMPLETE RTL TLM-Timed / AT CA 16

17 © STMicroelectronics RTL CA 2nd dimension: effort Time of project Effort PAPER SPEC EXEC. SPEC DESIGNING RTL RTL EVOLVES UNTIL PG FIRST COMPLETE RTL TLM/LT AT PVT optional AT Optional 17

18 © STMicroelectronics CA 3rd dimension: speed RTL TLM / LT AT AT+ X10-x100 x100 SoC Speed Chip reference speed x10 Speed-ups are very design-dependent… to be used as rule of thumb !!! 18

19 © STMicroelectronics Agenda Motivations for SoC TLM modeling Languages and abstractions for System Level Design Current standards for interoperability Supporting and adopting ESL standards SystemC/TLM IP-Xact ST TLM Framework Discussion and conclusion 19

20 © STMicroelectronics Motivations Complex Virtual Platform integration requires Model to model interoperability Model to tool interoperability A certain level of interoperability is achieved by standards… But full interoperability is not reached though… And user layers are required to have operational solution taking concrete benefits from bare standards 20

21 © STMicroelectronics Rationale to support standards Model-to-model interoperability Integrate models coming from different IP suppliers Deliver subsystems and/or virtual platforms to customers Model-to-tool interoperability Benefit from CAD tools support Benefit from best-in-class tools from various providers without migration campaigns SystemC and IP-XACT standards are required and complementary 21

22 © STMicroelectronics Adopting standards OSCI/SystemC A single language for modeling hardware/software systems Support multiple abstraction levels An object-oriented approach built on top of C++ as a set of classes SPIRIT/IP-Xact Covers HW IP interfaces, register banks and configurations Support RTL and TLM abstractions Based on XML Benefits of standards Enable competition between suppliers Avoid dependency to proprietary format of suppliers Enable adoption of new approaches inside the company 22

23 © STMicroelectronics IEEE 1666-2005 SystemC standards evolution 2005 2008 2011 IEEE 1666-2011 OSCI TLM1 PV, PVT Core TLM I/F transport put, get Payload REQ, RESP OSCI TLM2 LT, AT TLM I/F b_transport nb_transport Payload tlm_transaction Extension Complements Incl TLM1 and TLM2 23

24 © STMicroelectronics SystemC TLM: Just add water? Models and tools Must be compatible But not dependent ESL tool selection Depending on added value perceived by users No need to validate a model against all tools No-tool / minimal tool option to be considered as baseline? Model-to-model interfaces TLM2 Mem map, interrupt, etc tbd Model-to-tools interfaces CCI (on going) Other to be defined Progress still to be done in standards arena Memory Map TLM2 Interrupt TLM2 CCI 24

25 © STMicroelectronics IP-Xact objectives Ensure delivery of compatible component descriptions from multiple component vendors, Enable exchanging complex component libraries between electronic design automation (EDA) tools for SoC design (design environments), Describe configurable components using metadata Enable the provision of EDA vendor-neutral scripts for component creation and configuration (generators, configurators) 25

26 © STMicroelectronics A standardized XML description Component/Protocol identification and versioning mechanisms Component interface descriptions Bus interfaces (ports) Model parameters (to provide at instantiation) Software interface: IP register bank descriptions Hierarchy description Enable component instantiation and interconnection in standard compliant Design Environments Enables interconnect description 26

27 © STMicroelectronics A standardized XML description Verification Defines the possibility to plug monitors in the design Design Automation XML IP descriptions can include references to IP specific executable configurators/generators Example: bus matrix interconnect generator The standard also includes a language agnostic communication interface between CAD tools and the generators Since IPXACT 1.4, the interface is based on Web Services technologies that enables inter-application remote procedure calls 27

28 © STMicroelectronics IP-Xact roadmap December 2004: first release of the schema Made for RTL descriptions 1.2 : added verification information, but still RTL specific 1.4: Added ESL (TLM) description capabilities Defined new tool/generator communication interface: TGI 1.5: basis for the IEEE standard Evolutions mainly concern register bank descriptions December 2009: IEEE P1685 standard Now: the Spirit consortium has merged with Accellera A new technical committee has been created (chaired by ST) Progress on recognized limitations and possible new evolutions 28

29 © STMicroelectronics Agenda Motivations for SoC TLM modeling Languages and abstractions for System Level Design Current standards for interoperability ST TLM Framework Brief history Use models TLM Toolbox with SystemC and IP-Xact Discussion and conclusion 29

30 © STMicroelectronics Where do we come from? Transactional Level Modeling @ST TAC v1 TLM models 2001 TLM Development 2003 Proposal of TLM 1.0 Standard to OSCI 2008 OSCI TLM 2.0 Standard TAC v3 TLM models 2010 Alignment to OSCI TLM 2.0 Standard TAC v2 TLM models 2005 OSCI TLM 1.0 Standard 2005 Alignment to OSCI TLM 1.0 Standard co- verification platforms: RTL models Performance/ temporal models cycle accurate models 1998 – 2000 Various Experiments 30

31 © STMicroelectronics Virtual Prototypes with TLM Applied in the industry for complex SoCs System architecture exploration Anticipation of RTL functional verification Pre-silicon software development LT Models AT Models Functional Embedded Software Functional Verification TLM/RTL Co-simulation Architecture Analysis Embedded Software Optimization LT: Loosely TimedAT: Approximately Timed 31 IPTG

32 © STMicroelectronics Functional verification IP Verification TLM IPs In-system Verif. TB Master Memory Abstract interconnect C/C++ Input expected Testbench Adapter RTL DUT TLM DUT 32

33 © STMicroelectronics TLM for functional verification Home Video Ips (by IPs Verification Manager) About 10 chips have now benefited from the TLM approach, resulting in about 4 times less bugs in our designs. Our improved efficiency relies on faster simulations, reuse of test vectors during the whole verification process (TLM, RTL, co-emulation, emulation), and the ability to quickly develop system-oriented functional tests. 33

34 © STMicroelectronics Pre-Silicon software development Enable early development of functional embedded software Same model is used for verification activities and software development Hardware blocks modeled with bit true behaviour and communication Processor models wrapped in SystemC Native compilation Instruction accurate Cycle accurate Debugger connection 34

35 © STMicroelectronics Advantages of virtual prototypes for software development Full control on simulation execution Full observability Non regression tests Easy deployment over large software development teams Easy evolutions 35

36 © STMicroelectronics TLM for firmware development Mobile Video Accelerator (by Video Subsystem Verification Manager) For 2nd generation subsystem, we saved 30% of our verification time (in months) by anticipating the firmware verification on TLM platform before any RTL platform, and by concentrating our verification effort only on pure HW 36

37 © STMicroelectronics TLM Modeling Framework TLM modeling kit Infrastructure kit TLM modeling methodology TLM model portfolio Transaction Monitoring Build environment Repository Ip-Xact flowVSoC STudio Messaging and configuration Platform automation kit 37

38 © STMicroelectronics TLM key technology items TLM Model TLM communication protocols Build infrastructure (tlm_infra) Monitoring capabilities Configuration capabilities Register bank support TLM modeling methodology SystemC IEEE 1666 SCV OSCI TLM 2 IPXact IEEE 1685 TLM platform assembly OSCI CCI 38

39 © STMicroelectronics SystemC Add-ons : modeling layers and IP models libraries SystemC SystemC ChannelsOSCI TLM Standard OCB Models TAC Protocol CPU models ST Cores ( STxP70, ST40, etc) External Cores (ARM, etc) TLM IP Library ST IPsExternal IPs 39

40 © STMicroelectronics 40 VSoCSTudio udioVSoC Platform assembly Platform compilation Configuration editor Resource browser Process Activation Chart

41 © STMicroelectronics What is TAC Protocol? A useful protocol for functional verification and embedded software development through transaction-accurate communications Characteristics: Dedicated to memory mapped bus communication point-to-point with no broadcast requires address and data supports single and block transfers supports byte-enable for single and block transfers provide control operations routers are often used in conjunction with TAC models TAC stands for Transaction Accurate Communication 41

42 © STMicroelectronics Register map support Increase model developer productivity No standard available yet for simulations Register map is constructed From IP-Xact description Manually Main features Register decoding Register and bitfield access control, setters & getters Register meta data (synchronization points) Unified reporting mechanism (using tlm_message) Interactions with bus interface Model Tools 42

43 © STMicroelectronics TLM Model/tool interactions Model Register bank Bus Interface Bus model CAD Tool Transaction database SystemC Kernel Trans. Monitoring Configuration Register introspection Upcoming OSCI CCI standard 43

44 © STMicroelectronics TLM SoC Analysis and Debugging Tools Software Analysis Hardware Analysis Statistics Platform assembly 44

45 © STMicroelectronics Using IP-Xact description as the reference IP-Xact descriptions SoC Top Arch IP Functional Spec Datasheet export IP verification testcase (.h &.c) Netlist RTL Design Validation (.h) Software (.h) TLM model skeleton (.h &.cpp) Board spec package 45

46 © STMicroelectronics TLM model generation and platform assembly IP Functional Specification IP-Xact Description TLM Model Skeleton Behavior TLM model generation TLM/RTL platform assembly Register Description Existing Model Other inputs Header files Register tests SW development Validation Other output RTL HLS 46

47 © STMicroelectronics Questions related to IP-Xact and HDS Consistency of descriptions? Specification IP-Xact TLM model & software Level of modularity Separate deliveries? Expressivity of the description E.g. Side effects for registers Connection to higher level information? E.g. end user scenarios, non functional properties Software Driver TLM Model IP-Xact IP/SoC Description IP/SoC Functional Specification 47

48 © STMicroelectronics Agenda Motivations for SoC TLM modeling Languages and abstractions for System Level Design Current standards for interoperability ST TLM Framework Discussion and conclusion ESL Ecosystem TLM value chain Conclusions 48

49 © STMicroelectronics ESL ecosystem Standards and Tools for Model developers Virtual Platform integrators Virtual Platform users ESL doesn’t mean only EDA! Standards & Examples CAD Tools SW Tools # of users License cost HW SW Open Source tools OSS 49

50 © STMicroelectronics From enablers to mass market Enablers: - Early adoption - Assess migration effort from in house solutions Mass market: - Functional - Affordable Experts: - Very focused needs - Sensitive setup - Niche market License cost # of users Architecture exploration Demontrators HW/SW integration VP profiler New flows New standards 1st success story eSW Debug HLS 50

51 © STMicroelectronics Transaction Level Model Value Chain IEEE 1666-2005 C++ class library TLM1.0, TLM 2.0 incl. in IEEE 1666-2011 revision TLM Modeling Methodology SystemC TLM Communication APIs Modeling Engineers Expertise IP Specification TLM Model Bit accurate Register accurate Functionally correct Communicates through transactions Variable timing accuracy SOC Specification Interconnect TLM model IP High added value on top of standards SoC Virtual Prototype 51

52 © STMicroelectronics Conclusion Virtual platforms are key for pre-silicon software development Functional verification Automation of the IP-Xact based flow Generation of TLM model skeleton Generation of software header files Connection to other sources of high-level information still to be done 52

53 © STMicroelectronics More about it Read the book: Ghenassia, F. (ed.): 2005, Transaction-Level Modeling with SystemC. TLM Concepts and Applications for Embedded Systems. Springer. ISBN 0-387-26232-6 Several publications in international conferences and PhD thesis (Moy 2005, Fiandino 2007, Helmstetter 2007, Cornet 2008, Revol 2008, Funchal 2011)

54 Workshop - November 2011 - Toulouse Questions? 54 (C) STMicroelectronics, 2010


Download ppt "Workshop - November 2011 - Toulouse L. Maillet-Contoz, STMicroelectronics."

Similar presentations


Ads by Google