Chapter 9 Embedded Software Generation from SystemC for Platform Based Design

1. Chapter 9Embedded Software Generation from SystemC for Platform Based Design Team 7 陳志展 吳昭男 黃雪婷

2. Outline • 9.1 Introduction • 9.2 System Specification Methodology • 9.3 SW Generation • 9.4 SW/SW Communication and Driver Generation • 9.5 Example of Software Generation in SystemC 2.0 • 9.6 Impact of SystemC 3.0 Release • 9.7 Conclusions

3. 9.1 Introduction • Embedded software has a strong interaction with the environment • Existing general purpose software design techniques are not suitable • During the 1970s and 1980s • Hand written in C or assembler code • Throughout the 1990s • Time to market pressure increased • Integration of the complete embedded system on a chip (SoC) • Close relationships between hardware and software • New co-design techniques have been proposed

4. ‘describe and synthesize’ methodology (1/3) • Originally these were based on a “describe and synthesize” methodology • Two models are used to describe software • State oriented models • Use a set of states, transitions, and actions associated with state and transitions • Activity oriented models • Describe a set of operations related by data or execution dependencies • Frequently used in DSP applications

5. ‘describe and synthesize’ methodology(2/3) • Software synthesis begins with the scheduling of the software concurrent tasks • The schedule can be • Static • Defined during the software synthesis process • Dynamic • Defined at execution time by a RTOS • Software synthesis is often used for static schedulers • Increasing execution speed • Reducing the memory usage

6. ‘describe and synthesize’ methodology (3/3) • Disadvantages • The lack of a code reuse methodology • The problems caused by the input description modification (software debugging difficulties) • In the late 1990s it was not able to survive • It did not fulfil the time to market constraints • A new methodology, based on the ‘specify–explore–refine’ paradigm was proposed

7. ‘specify–explore–refine’ methodology(1/2) • The methodology points out • Design reuse • Platform based design • Effective platform based design • The software development environment (compiler, linker, assembler, debugger, simulator) • A set of tools -- API • After mapping, the re-used hardware and software component are added to the design

8. ‘specify–explore–refine’ methodology (2/2) • SystemC play an important role • System level specification (which integrates SW and HW) • Performance analysis • Verification • Use consists of a set of processes and communication channels • The process schedule is dynamic and is normally controlled by the platform RTOS • An open source RTOS, eCos is used to implement the SystemC kernel library • The same code can be used in SystemC simulation as well as for platform compilation

9. 9.2 System Specification Methodology • General Characteristic of SystemC as a Specification Language • Structure • Functionality • Communication • SystemC Fundamental Computational Model • Timed Models of Computation • Untimed Models of Computation

10. General Characteristics of SystemC as a Specification Language • Which system langrage to be choose • Must cover as many levels of abstraction as possible, ideally all levels of abstraction • An executable specification of design must be possible • Simulation speed has to be improved over that of traditional HDLs • Separating functionality from communication in design • SystemC accomplishes these requirement.

11. System level specification methodology for the functional part - Structure • The main constraint applied is that functionality and communication have to be clearly separated • Functionality is encapsulated in functions and processes included in modules • Communication is encapsulated in channels

13. System level specification methodology for the functional part – Functionality (1/3) • To ensure the intended separation between communication and functionality • No event objects are supported inside processes • Event object is the core object for synchronization and communication in SystemC • Event objects will be included in channels which will be in charge of supporting communication and synchronization between processes

14. System level specification methodology for the functional part – Functionality (2/3) • SC_THREAD • Because no event object is allowed, the notify or wait primitives are not permitted inside processes • One exception wait(absolute_time)

15. System level specification methodology for the functional part – Functionality (3/3)

16. System level specification methodology for the functional part - Communication(1/2) • Communication between processes is performed through channels • The processes can access methods defined in channels and declared in the interfaces of the channel • When the processes are in different modules the access to the channel has to be performed through ports

17. System level specification methodology for the functional part - Communication(2/2)

18. Computational Model • Timed Models of Computation • Untimed Models of Computation

19. Timed Models of Computation (1/3) • General characteristic of timed models • T is a totally ordered set • For any two events e1 and e2 either one precedes the other or they are synchronous (both take place at the same time) • Types of timed models • In continuous time systems ,T = R • In discrete event systems, T = N • In some of these systems transactions in time are allowed

20. Timed Models of Computation (2/3) • If T represents physical time (seconds) • Strict-timed systems • Strict, continuous time ex: Simulink, VHDL-AMS and SPICE • strict, discrete time ex : VHDL , Verilog

21. Timed Models of Computation (3/3) • If T does not represents physical time • Providing more implementation freedom • Relaxed timed systems • Relaxed, discrete time ex : Lustre, Esterel, and Signal

22. Untimed Models of Computation (1/2) • General characteristic of untimed models • T is a partially ordered set • Events e1 and e2 in which none precedes the other

23. Untimed Models of Computation (2/2) • The most appropriate for system specification • Reflect concurrent nature of embedded system • Potential problems can be detected more easily and fixed • Problems derived from concurrency, such as non-determinism • An untimed specification is less prone to over-specification • Untimed model examples : Java , Ada

24. SystemC(1) • The first versions of SystemC were based on a relaxed timed, discrete time computational model including time transactions.

25. SystemC(2) • This computational model changed with version 2.0. • In its current version SystemC is based on a strict-timed, discrete even computational model including time transactions.

26. SystemC(3) In order to facilitate the integration of IP blocks modeled at gate level with logic delays, the main time tag represents exact time in sc_time_units.

27. SystemC(4) • In an opposite direction the synchronization mechanisms wait and notify based on events were added, increasing the flexibility of the communication and synchronization among processes.

28. 9.3 SW Generation • Single-Source SW Generation • Software Implementation Library: SC2RTOS • Hierarchy Support • Concurrency Support and Execution Control • Timed Specification • Data Types

29. Single-Source SW Generation • SW synthesis step is eliminated • The same specification code is used for binary code generation • System level specification code and SW code • High correlation • Similar constructing elements • Advantage • Facilitates SW generation process and debugging

30. Single-Source SW Generation- Solution 1 • Substitute each C++ SystemC construct with an equivalent C code • Ensures a wide availability of crosscompilers to different microprocessors

31. Single-Source SW Generation- Solution 2 (1/3) • SC2RTOS library • SystemC library elements are replaced by behaviorally equivalent elements of a SW implementation library • Library uses a platform RTOS API and defines some C++ supporting structures • Single C++ description for specification and SW code

32. Single-Source SW Generation- Solution 2 (2/3) • SYSTEMC has to be replaced by • LEVEL : define description abstraction level • IMPLEMENTATION : specifies partition (SW or HW) in which modules are assigned • LEVEL • SPECIFICATION • System level specification before partition • ALGORITHM • SW part : executed with the platform RTOS support • HW part : executed with the SystemC simulation kernel support • Develop a specific implementation of the SW/HW and HW/SW communication channels to allow co-simulation • GENERATION • SW partition be isolated from HW to enable platform compilation

33. Single-Source SW Generation- Solution 2 (3/3)

34. Software Implementation Library: SC2RTOS • Software generation performed at library level • Hidden from designer • sc_start() : in SC2RTOS,resume all the system tasks under the RTOS control • Development of SC2RTOS library is relatively easy • Number of SystemC elements that have to be redefined is very small • File structure similar to SystemC library structure • Porting of library can be systematically performed • SystemC elements to translate

35. SC2RTOS - Hierarchy Support (1/2) • Implementation library declare the same elements as SystemC library macros • With a SW oriented implementation

36. SC2RTOS - Hierarchy Support (2/2)

37. SC2RTOS - Concurrency Support and Execution Control • Use RTOS API calls for concurrency support • SystemC threads map to underlying RTOS threads • register_thread_process • cyg_thread_create • Store process list for Some structures • exec_context

38. SC2RTOS - Timed Specification • Use delay services offered by underlying RTOS API • sc_time_unit type • sc_time class • wait(sc_time) function • Call RTOS function for thread delay service • Delay parameter calculated from sc_time and system clock period

39. SC2RTOS - Data Types • C++ types are directly compiled • SystemC types • Use SystemC data type implementation • Maintains intact data behavior of system level specification • Replace with a SW oriented implementation • For efficient SW code • Use C++ types at specification level

40. 9.4 SW/SW Communication and Driver Generation (1/2) • Every primitive channel can have three types of SW oriented implementation • SW/SW -- implementation only depends on the RTOS API • HW/SW implementation is also dependent on the platform architecture • SW/HW • The type of implementation could be specified by • the designer or • automatically generated by a source code analyzer • Additionally every type can have different codings depending on the RTOS communication services

41. 9.4 SW/SW Communication and Driver Generation (2/2)

42. 9.5 Example of Software Generation in SystemC 2.0 (1/3) • Some assumptions • The platform has only one processor • The partition is performed at module level in the top hierarchical module • Every module is assigned to only one partition • Hierarchical modules are assigned to the same parent module partition • Only the channels instantiated in the top hierarchical module can communicate processes assigned to different partitions

43. 9.5 Example of Software Generation in SystemC 2.0 (2/3)

44. 9.5 Example of Software Generation in SystemC 2.0 (3/3)

45. 9.6 Impact of SystemC 3.0 Release • Most of these new features are oriented • SW modeling • Efficient SW generation • Another important aspect is related to the SystemC scheduler • up to the present this scheduler has some limitations • It is non-preemptive • It cannot take into account resource sharing • It defines no specific order for the choice of a process of the ready to execute queue • All this means that a SystemC execution does not represent the actual execution on a specific target

46. 9.7 Conclusions • SW generation from SystemC can be simple based on the substitution and redefinition of SystemC class library construction elements • Typical RTOS functions • C++ supporting structures • Designer concentrate the design effort on a single specification • Preventing errors • Raising the abstraction level • Allowing early verification • Gaining in productivity