Transaction Level Modeling with SystemC

Adviser ： 陳少傑 教授 Member ： 王啟欣 P92943008 Member ： 陳嘉雄 Member ： 林振民 R92921126 P92921003

Outline

 Transaction level modeling  Simple bus example  Conclusion  Reference

Transaction

 Definition  Exchange of data or event between two components of a modeled and simulated system  Types of transactions  Data transaction  Can be a single word/series of words/complex data structure that is transferred over the bus, e.g. DMA read/write transaction  Event transaction  Models synchronization aspects that ensure correct operation of the SOC model, e.g. interrupts

Transaction Level Model (TLM)

 Definition  Models of HW at high level of abstraction  New design & verification abstraction above RTL  Protocol based comm.

 Characteristics  Comm. with each other by transaction requests  Can be developed and ready as soon as the initial functional specs. of the systems are decided  Can incorporate timing detail  Performance estimation and arch. exploration

TLM

(cont.)

 Advantages  HW/SW teams share a common abstraction and verification environment  Early HW/SW integration  Enable high speed simulation  Early development and verification of embedded SW  Reduce design iterations  Design reuse

TLM vs. SystemC

 TLM requirements  Communication ensured by primitive channel  Synchronization based on events  Accuracy for a given task at high simulation speed  SystemC provides  Channels  Interfaces  Events

TLM vs. SystemC

(cont.)

 Channel  Serves as a container object for comm. and sync.

 Implements one or more interfaces  Interface  Specifies access methods to be implemented within a channel, but does not provide the implementation  Event  Flexible, low-level sync. primitive used to construct other forms of sync. mechanism

TLM Applications

 HW signals  Queues (FIFO, LIFO, message queues, etc.)  Semaphores  Mutexes  Timer  Memories  Busses

Simple Bus Example

 “Simple” =  No pipelining  No split transactions  No master wait states  No request/acknowledge scheme

Simple Bus Example

(cont.)

Simple Bus

–

Master Interfaces

 Blocking:  Complete bursts  Used by high-level models  Non-blocking:  Cycle-based  Used by processor models  Direct:  Immediate slave access  Put SW debugger to work

Master

–

Blocking Interface

 “Blocking” because call returns only after complete transmission is finished  Master is identified by its unique priority  status burst_read(unique_priority, data*, start_address, length=1, lock=false);  status burst_write(unique_priority, data*, start_address, length=1, lock=false);

Master

–

Non-blocking Interface

 “Non-blocking” because calls return immediately.

 Less convenient than blocking API but caller remains in control (needed e.g. for most processor models).

 status get_status(unique_priority);  status read(unique_priority, data*, address, lock=false);  status write(unique_priority, data*, address, lock=false);

Master

–

Direct Interface

 Provides direct access to slaves (using the bus’ address map)  Immediate access simulated time does not advance  No arbitration  Use for SW debuggers or decoupling of HW and SW  status direct_read(data*, address);  status direct_write(data*, address);

Simple Bus

–

Slave Interface

 unsigned start_address();  unsigned end_address(); address mapping  status read(data*, address);  status write(data*, address); regular I/O  status direct_read(data*, address);  status direct_write(data*, address); debug interface

Simple Bus

–

Arbiter Interface

 Arbitration rules:  If the current request is a locked burst request, then it is always selected  If the last request had its lock flag set and is again 'requested', this request is selected from the collection Q and returned, otherwise:  The request with the highest priority (i.e. lowest number) is selected from the collection Q and returned simple_bus_request *arbitrate(const simple_bus_request_vec &Q);

Simple Bus

–

Simulation

Simulation time Direct interface Memory Position (hex) Memory Value (hex)

Conclusion

 What we have talked about  Importance of TLM  SystemC 2.0 enables efficient platform modeling   Get executable platform as soon as possible Simulation speed  What we can do in the future  More complex bus design  Incorporate the CPU/Memory module

Reference

       Thorsten Grötker, Stan Liao, Grant Martin and Stuart Swan, System Design with SystemC, Kluwer Academic Publishers Group, 2002. ISBN: 1-4020 7072-1.

Open SystemC Initiative, http://www.systemc.org/.

Wander O. Cesario, et al. “Multiprocessor SoC Platforms: A Component Based Approach”, IEEE Design & Test of Computers, pp. 52-63, Vol. 19, No. 6, 2002.

Jon Connell, “Capturing design intent and evaluating performance with SystemC”, Embedded Systems West Proceedings, Class 201, 2003.

ARM, “RealView Model Library”, http://www.arm.com/devtools/RVModelLibrary/.

ARM, “AMBA AHB Cycle-Level Interface Specification”, http://www.arm.com/armtech/AHBCLI/.

Filip Thoen “Prototyping Technologies for Early Embedded Software Development”, Information Quarterly, pp. 17-21, Vol. 1, No. 1, 2002.