1. Transaction Level Modeling with SystemC Adviser ：陳少傑 教授 Member ：王啟欣 P92943008 Member ：陳嘉雄 R92921126 Member ：林振民 P92921003

2. Outline Transaction level modeling Simple bus example Conclusion Reference

3. 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

4. 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

5. 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

6. 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

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

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

9. “Simple” =  No pipelining  No split transactions  No master wait states  No request/acknowledge scheme Simple Bus Example

10. Simple Bus Example (cont.)

11. 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

12. 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);

13. 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);

14. 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);

15. Simple Bus – Slave Interface unsigned start_address(); address unsigned end_address(); mapping status read(data*, address); regular status write(data*, address); I/O status direct_read(data*, address); debug status direct_write(data*, address); interface

16. 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);

17. Simple Bus – Simulation Simulation timeDirect interfaceMemory Position (hex) Memory Value (hex)

18. 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

19. 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.