1 / 54

System On Chip modeling with SystemC/TLM

System On Chip modeling with SystemC/TLM. L. Maillet-Contoz , 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

meris
Download Presentation

System On Chip modeling with SystemC/TLM

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. System On Chip modeling with SystemC/TLM L. Maillet-Contoz, STMicroelectronics

  2. 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 2011

  3. 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. Version 1998 Version 2008 Objectives: face SoC increasing complexity • A camera-telephone? 4

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

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

  7. 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. Differentplatforms for different use models • All activities do not require cycle accuracy • Engineering effort to be balanced with benefits • Fast / precise trade-off 8

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

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

  11. 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. Transaction Level Models (AT) • Targetting performance evaluation • Hardware architecture • Software • Captures micro-architecture information/timing • Severaltechnical options • LT Model refinement -> rewriting • LT Model annotation • Intrusive • Lightweight effort • Composition of LT and T models 12

  13. Comparing abstraction levels TLM LT Same functional behavior Same functional behavior TLM AT Same timedbehavior RTL 13

  14. 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. Options for processor models (2/2) • 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

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

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

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

  19. 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. 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. 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. 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. SystemC standards evolution OSCI TLM2 IEEE 1666-2011 LT, AT TLM I/F b_transport nb_transport Payload tlm_transaction Extension Complements OSCI TLM1 Incl TLM1 and TLM2 PV, PVT Core TLM I/F transport put, get Payload REQ, RESP IEEE 1666-2005 2005 2008 2011 23

  24. 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 TLM2 TLM2 TLM2 TLM2 TLM2 TLM2 CCI Interrupt MemoryMap SystemC TLM: Just add water? 24

  25. 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. 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. 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. 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. 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. 2008 OSCI TLM 2.0 Standard 2010 Alignment to OSCI TLM 2.0 Standard 2005 OSCI TLM 1.0 Standard 2005 Alignment to OSCI TLM 1.0 Standard 2001 TLM Development 1998 – 2000 Various Experiments TransactionalLevel Modeling@ST Where do we come from? 2003 Proposal of TLM 1.0 Standard to OSCI cycle accurate models TAC v2TLMmodels TAC v3 TLMmodels TAC v1TLMmodels co-verification platforms:RTL models Performance/temporal models 30

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

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

  33. 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. Pre-Silicon software development • Enableearlydevelopment of functionalembedded software • Same model isused for verificationactivities and software development • Hardware blocks modeledwith bit truebehaviour and communication • Processor modelswrapped in SystemC • Native compilation • Instruction accurate • Cycle accurate • Debugger connection 34

  35. Advantages of virtual prototypes for software development • Full control on simulation execution • Full observability • Non regression tests • Easydeployment over large software development teams • Easyevolutions 35

  36. 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. TLM Modeling Framework Platform automation kit Ip-Xact flow VSoC STudio TLM model portfolio TransactionMonitoring Messaging and configuration Build environment TLM modelingmethodology Repository Infrastructure kit TLM modeling kit 37

  38. TLM key technology items TLM platformassembly TLM modelingmethodology IPXact IEEE 1685 SystemC IEEE 1666 Registerbanksupport Configuration capabilities TLMModel OSCI CCI TLM communication protocols Monitoringcapabilities OSCI TLM 2 SCV Buildinfrastructure (tlm_infra) 38

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

  40. Platform compilation VSoC udio Platform assembly Configuration editor Process Activation Chart Resource browser VSoCSTudio

  41. TAC stands for Transaction Accurate Communication 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 41

  42. Register map support • Increase model developerproductivity • No standard availableyet for simulations • Register map is constructed • From IP-Xact description • Manually • Main features • Registerdecoding • Register and bitfieldaccess control, setters & getters • Registermeta data (synchronization points) • Unifiedreportingmechanism (usingtlm_message) • Interactions with • bus interface • Model • Tools 42

  43. TLM Model/tool interactions Bus model Trans.Monitoring Transactiondatabase Bus Interface CAD Tool Register bank Registerintrospection Model Configuration SystemCKernel Upcoming OSCI CCI standard 43

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

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

  46. TLM model generation and platform assembly IP FunctionalSpecification IP-XactDescription Register Description ExistingModel Other inputs Other output TLM/RTL platform assembly Header files SW development TLM Model Skeleton Behavior Register tests Validation TLM model generation HLS 46 RTL

  47. Questions related to IP-Xact and HDS IP/SoC FunctionalSpecification • Consistency of descriptions? • Specification • IP-Xact • TLM model & software • Level of modularity • Separatedeliveries? • Expressivity of the description • E.g. Sideeffects for registers • Connection to higherlevel information? • E.g. end user scenarios, non functionalproperties IP-Xact IP/SoC Description TLM Model Software Driver 47

  48. 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. License cost HW OSS SW Open Source tools # of users ESL ecosystem CAD Tools CAD Tools • Standards and Tools for • Model developers • Virtual Platform integrators • Virtual Platform users • ESL doesn’t mean only EDA! Standards & Examples SW Tools SW Tools 49

  50. From enablers to mass market Architectureexploration License cost HW/SW integration • Experts: • Very focused needs • Sensitive setup • Niche market VP profiler eSW Debug New flowsNew standards • Mass market: • Functional • Affordable HLS Demontrators 1st success story Enablers: - Early adoption - Assess migration effortfrom in house solutions 50 # of users

More Related