TLM and its evolution Copyright © 2007 Tata Elxsi Ltd. Shwetha Pai

Agenda Transaction Level Modeling Modeling OSCI Support Tools Case studies Future Challenges

Transaction Level Modeling MODEL A MODEL A MODEL B MODEL B Transaction Exchange of data or event between two components of a modeled or simulated environment. Model A representation of a person or thing, typically on a smaller scale Something used as an example A simplified mathematical description of a system or process used to assist calculation and prediction A figure made in clay or wax which is then reproduced in a more durable material. Model A representation of a person or thing, typically on a smaller scale Something used as an example A simplified mathematical description of a system or process used to assist calculation and prediction A figure made in clay or wax which is then reproduced in a more durable material.

TLM evolution Evolution A process by which something passes by degrees to a different stage, especially to a more advanced or matured stage Evolution A process by which something passes by degrees to a different stage, especially to a more advanced or matured stage 2000 AD: Presentation of communication mechanism of a system Developed into SystemC 2.0 standard “Transaction based modeling” concepts was showcased Level was introduced later on in order to follow Register Transfer Level Behavioral Level Level was introduced later on in order to follow Register Transfer Level Behavioral Level Birth of Transaction Level Model

Agenda Transaction Level Modeling Modeling OSCI Support Tools Case studies Future Challenges Why modeling? Different abstraction models Why SystemC?

Testing Functional validation Enable quantitative comparison of alternatives Guide engineering trade-offs Making design decisions Narrow the design space Establish credible and feasible alternatives Why modeling? Required during all the phases of system development High level design Micro-architectural definition Design Implementation

Better debug capability 3 – 6 months time frame Software development is the critical path Moves software development and debugging earlier in the project life cycle Reduce overall development cycle Why modeling? Early software development Quick prototype of the hardware Determine correctness and efficiency of design

Agenda Transaction Level Modeling Modeling OSCI Support Tools Case studies Future Challenges Why modeling?  Different abstraction models Why SystemC?

A B F Un- timed Approximate- timed Cycle- timed Approximate- timed Cycle- timed COMPUTATION COMMUNICATION D C E A.ALGORITHMIC MODEL SPECIFICATION MODEL UNTIMED FUNCTIONAL MODEL A B.COMPONENT ASSEMBLY MODEL ARCHITECTURAL MODEL TIMED FUNCTIONAL MODEL B A C.PROGRAMMER’S VIEW MODEL (PV) BUS ARBITRATION MODEL TRANSACTION MODEL C B D.PROGRAMMER VIEW TIMED MODEL (PVT) BUS-FUNCTIONAL MODEL COMMUNICATION MODEL BEHAVIOR LEVEL MODEL D C E.CYCLE ACCURATE COMPUTATION MODEL PIN ACCURATE MODEL E D F.IMPLEMENTATION MODEL F E Abstraction models

CORE SYS BUS MEMORY GIO TIMER CLOCK RESET IOPINS ADDR nRW DATA INTR TLM for an example system

CoreSys GIOTimer Variables Implementation Functional implementation of modules Intercommunication is through shared variables Execution and data transport in 0 time Abstractions done No state No memory No address decoding Modules not present at this stage Bus Memory Algorithmic model

CoreSys GIOTimerMemory CH1 CH2 CH3CH4 Implementation Models are concurrently executing entities Wait statements are implemented Intermodule communication is through channels Abstractions done Channels are message passing channels without any bus / protocol implementation Communication is un-timed Computations are approximately timed Modules not present at this stage Bus Component assembly model

CoreSys GIOTimerMemory BUS ARBITER CH3CH2CH4 CH1 Implementation Simplified bus protocol Address decoding Bus priority implementation Abstractions done Bus implementation is not cycle accurate Wait states are inserted between transactions Computations continue to be approximately times Modules not present at this stage Bus Programmer view model

CoreSys GIOTimer Memory BUS ARBITER ADDR DATA nRW INTR Implementation Precise bus protocol – time / cycle accurate Data transferred following accurate protocol sequence Abstractions done Computations continue to be approximately times Modules not present at this stage Bus Programmer view timed model

Timer BUS ARBITER CH3CH2CH4 CH1 MEMORY GIO SYSCORE Implementation Computation models are pin accurate and execute cycle accurately Wrappers that convert data transfers from high level abstraction to low level abstraction are inserted to bridge the arbiter and other modules Abstractions done Bus implementation is not cycle accurate Wait statements are inserted between transactions Some modules can only be computational Cycle accurate computation model

SYS BUS ARBITER ADDR DATA nRW INTR CORE Timer MEMORY GIO Implementation Cycle accurate computation Cycle accurate communication Modules can be re-used from earlier models Implementation model

ModelsCommunicatio n time Computation time Communicatio n scheme A. Algorithmic model No Variable B. Component- assembly model NoApproximateVariable C. Programmer view model Approximate Abstract bus channel D. Programmer view timed model Time/cycle accurate ApproximateProtocol bus channel E. Cycle accurate computation model ApproximateCycle accurateAbstract bus channel F. Implementation model Cycle accurate Bus (wire) Models B, C, D and E can be classified as transaction level models Characteristics of abstraction models

Objects TLM: Made of Compositions & Computation objects Communication objects Read/Write Abstract Data Types Thus helping in Object independence - each object can be modeled independently Abstraction independence -different objects can be modeled at different abstraction level TLM definition

Agenda Transaction Level Modeling Modeling OSCI Support Tools Case studies Future Challenges Why modeling? Different abstraction models  Why SystemC?

Challenges faced in regular high level language Notion of time Concurrency Hardware data type: ‘Z’ value for tri-state busses Reactivity Hierarchy Synthesis Solution provided by SystemC System design language for HW/SW co-design A library of C++ classes that address the challenges faced Processes for concurrency Clocks for timing Hardware data types Waiting and watching: reactivity Modules, ports, signals: hierarchy Abstract ports and protocols A light weight simulation kernel Why SystemC?

Agenda Transaction Level Modeling Modeling OSCI Support Tools Case studies Future Challenges OSCI SystemC TLM standards OSCI SystemC TLM roadmap

OSCI TLM WG OCP-IP June 2004: OSCI / OCP-IP TLM standardization alliance May 2005: OSCI releases SystemC TLM standard 1.0 TLM kit, whitepaper, examples publicly available at TLM standards already in use in the industry TLM 2.0 draft 2 in progress for public review IEEE standardization process on cards OSCI SystemC TLM standards

Focus on SystemC interface class Generic reusable TLM interface Different components implement same interface Same interface can be implemented Directly within a c/C++ function Via communication with other modules / channels in system Object passing semantics Similar to sc_fifo, effectively pass-by-value Avoids problems with raw C/C++ pointers Leverage C++ smart pointers and containers where needed Unidirectional vs. bi-directional data flow Unidirectional interfaces similar as sc_fifo Bi-directional can be easily and cleanly layered on unidirectional Separates requests from responses Blocking vs. non-blocking OSCI SystemC TLM standards Key concepts

Modeling with OSCI TLM standard API

Courtesy : OSCI SystemC TLM progression

Agenda Transaction Level Modeling Modeling OSCI Support Tools Case studies Future Challenges OSCI SystemC TLM standards  OSCI SystemC TLM roadmap

Courtesy : OSCI SystemC TLM roadmap

Courtesy : OSCI SystemC TLM roadmap

Agenda Transaction Level Modeling Modeling OSCI Support Tools Case studies Future Challenges

Error Injection Mechanism Channel Interface Host Interface Protocol Operation Control Frame & Symbol ProcessingClock synchronizing process CODECTimers Media Access Control TEL FlexRay TLM – Automotive IP  Timed model with respect to data transactions in the channels.  Complete clock synchronization implemented.  Inter-module communications done with the TLM techniques.  Pin-level channel interface  The host side is API interface to provides configuration points  Add-on to normal behaviour capable of generating error frames and conditions  Capable of generating random packets/scenarios  Error logic is capable of generating all the errors present in conformance test specs  The model is capable to do the synchronizations with the DUT. Case Study1: TLM IP development & usage

Use case scenario – RTL verification Verification environment FlexRay RTL model (DUT) Channel A Channel B FlexRay TLM Verification IP Host interface Test case / Configuration Score board FlexRay TLM can be configured using function calls. provided error injection function calls that can be used by the score board to compare the transmitted and received frames. Case Study1: TLM IP development & usage

Bus Model ISS - 1ISS - 2 IP TLM - 1MemoryDMAIO Vendor bought TEL developed Multiprocessor OCP based system prototype for image processing Memory Memory architecture – cache/ ram/ rom details Memory size & type – shared/ distributed Data size Data Traffic Bus Bus Bandwidth Bus throughput Bus hierarchy & priority Number of cores required Hardware software partitioning Types and number of DMAs Interrupt type and latency details Complete architecture analysis and design decisions Case Study2: TLM to build a system

Agenda Transaction Level Modeling Modeling OSCI Support Tools Case studies Future Challenges

Compilers All C++ compilers Simulators SystemC simulator Most of HVL simulators VCS Modelsim NCS SuperC Converters Verilator – Verilog to SystemC converter VHDL – SystemC converter Support tools

Agenda Transaction Level Modeling Modeling OSCI Support Tools Case studies Future Challenges

More standardization from modeling perspective IP sales of systemC models Cost effective licenses required for systemC support. Simulator for TLMs Standardized interfacing into HVL OS scheduler modeling Synthesizable systemC Future challenges

Thank You