Using SystemC to Implement Embedded Software

Transcription

1 Using SystemC to Implement Embedded Software Brijesh Sirpatil James M. Baker, Jr. James R. Armstrong Bradley Department of Electrical and Computer Engineering, Virginia Tech, Blacksburg, VA Abstract This paper investigates the use of SystemC as a language for implementing the software portion of the hardware/software co-design of a system consisting of an embedded processor and some ASIC logic. The SystemC modeling language consists of a set of C++ classes for modeling hardware properties, along with a simulation kernel. SystemC designs include a number of concurrent processes that model the behavior of the system components, and tools are available to synthesize the hardware portion of the design. Since SystemC is based on C++, however, it may also be useful for implementing the software portion of the system. We explore the translation of SystemC into C++ code that is suitable for execution on an embedded processor. We discuss some guidelines and restrictions for developing SystemC code so that it can be easily implemented as software, and we also present a simple scheduler that replaces the SystemC simulation kernel. Finally, we apply this process to the design of a GSM communication system. 1. Introduction With the increasing complexity of today s systems and the move toward System-On-a-Chip (SoC) [1], there is a growing need for System-Level Modeling Languages that can be used to describe systems at a high level of abstraction. To improve time-to-market and help simplify the design process, it would be helpful if a single high-level model of the system could be used to implement both the hardware and the software components of the system. The SystemC language is one such System-Level Modeling language that is currently being used for hardware design [2]. However, since SystemC is based on C++, it may also be useful for developing the software portion of the system. This paper explores the feasibility of this approach, examining the restrictions that must be placed on SystemC models to allow them to be implemented in hardware, software, or a combination. The next section discusses the need for a single model of a system that can be used for both hardware and software implementations. Following that, we present an overview of the SystemC language, and then discuss the use of SystemC for software implementations. Finally, we apply this approach to the design of a SoC-based GSM communication system. 2. The Need for a Single System Model The hardware/software co-design process for SoCs focuses on the development of the system as a whole. An abstract model of the system is developed, and then successive refinements are made. A strong emphasis is placed on rapid design to reduce time-to-market, even at the expense of some system performance. Once the model has been refined, it is partitioned into hardware and software components [3, 4]. The hardware components are implemented in ASIC logic, while the software components are written to execute on an embedded processor. The partitioning is based on the estimated cost and performance of hardware and software implementations of each system component, and typically, after the partitioning is performed, the components are further refined and optimized. In addition, the different components may need to be translated into other languages, such as VHDL or Verilog for the hardware components and C or C++ for the software components. This translation may introduce errors and incompatibilities with the original system model. Also, if the partitioning is performed early in the design process, the cost and performance estimates of the various components may not be accurate, particularly if significant changes are made for implementation. In addition, changes made after the partitioning has been performed are often not propagated back into the original system model, and any changes made at the system level (using a different algorithm, for example) may require a new partitioning of the system, leading to another cycle of refinements and optimizations. Therefore, to help maintain an accurate system-level model and to effectively partition the system, the

2 partitioning should be performed as late in the design process as possible. This can be accomplished using a representation of the system that can be efficiently implemented in both hardware and software. 3. The SystemC Language SystemC [2, 5, 6] is a modeling language, developed for system-level modeling and hardware design, which may be useful for representing both the hardware and software components of a system. SystemC is based on C++, and includes a set of classes to model hardware components and a simulation kernel. Several tools, such as the Synopsys CoCentric SystemC compiler [7, 8] and the N2C compiler from CoWare [9], are available to synthesize hardware components from a SystemC description. In general, these tools require the use of a restricted subset of the SystemC language in order to be able to synthesize the system. Since SystemC is based on C++, however, an interesting question is whether SystemC can be used to implement the software components of the system in addition to the hardware components. And, in particular, if the restricted subset of SystemC needed for hardware synthesis can be made compatible with a software implementation. If so, then a single system model could be developed in SystemC and after partitioning, few changes would be needed to create synthesizable hardware components and executable software components. This would reduce design time and help designers maintain a single model of the system throughout the design process. To examine the feasibility of this approach, we need to examine the features and characteristics of SystemC SystemC Features Some of the major features of SystemC include modules, processes, ports, and signals [5]. These are illustrated in Figure 1. Modules are used to encapsulate the structure and functionality of objects, and to express the hierarchy of objects in the system. Modules may contain processes, ports, and signals, and modules communicate with each other through ports and signals. Processes are used in SystemC to model concurrency, and they are the basic unit of execution [5]. Conceptually, processes execute in parallel, and they may be triggered by various events in the system. SystemC supports three different types of processes methods, threads, and clocked threads. A method is scheduled whenever an event occurs on a signal that the method is sensitive to. Once activated, the method executes until it returns control to the Module Process Process Signal Signal Module Process Figure 1: SystemC Modules, Processes, s, and Signals simulation kernel. A method may not suspend execution, and it may not contain an infinite loop. In contrast, a thread is a process that can be suspended and reactivated. A thread may contain an infinite loop, and once it is activated, the thread will continue until it suspends execution. A thread may not be preempted by another thread once it begins execution. As with methods, a thread may be made sensitive to events that occur on various signals. A clocked thread is a special type of thread that can only be made sensitive to a clock signal. It is activated and executes once every clock cycle, and all code between calls to the wait() or wait_until() functions execute in a single cycle of simulated time. Typically, a clocked thread will contain an infinite loop that executes for the duration of the simulation. Clocked threads are the only types of processes that are synthesizable, so we will not discuss methods or threads further. When called from a clocked thread, the wait() function will suspend the thread until the next clock cycle. The wait_until() function takes as a parameter a condition to test. The thread will remain suspended until the condition becomes true. Typically, the condition specifies the state of a signal or combination of signals needed for the thread to continue execution. An infinite loop in a clocked thread must contain at least one call to wait() or wait_until(). s represent the inputs and outputs of objects. Threads read and write to their ports to transfer data. s are bound to signals. Signals are used to connect modules and processes to other modules/processes, and they model the communication channels between communicating objects. When a process writes to an output port, the value of the signal that is bound to the port is updated, and the new value may be read by other processes connected to the signal.

3 SystemC supports the concept of delta cycles for updating signal values [6]. To correctly model the concurrent execution of threads, updates to signals are not visible until the next clock cycle. So, if multiple threads read from the same signal during the same clock cycle, they will all read the same value. At the end of the clock cycle, after all threads have executed, the new value for the signal is determined, and any thread that reads the signal during the next clock cycle will read the updated value. By using delta cycles like this, the order that threads execute during a clock cycle will not affect the signal value, and consistent simulation results may be obtained SystemC Scheduler As mentioned earlier, SystemC includes a simulation kernel so that models may be compiled to generate an executable simulator [5, 10]. The kernel contains a scheduler that is responsible for scheduling processes and updating signals during each clock cycle. The scheduler follows the algorithm shown in Figure 2. During each clock cycle, the scheduler will execute each ready method or thread, and then update the signals as necessary Restrictions for Hardware Synthesis Many features of SystemC and the C/C++ languages cannot yet be implemented in hardware [7]. Therefore, to be able to use synthesis tools, hardware designs must use a restricted subset of SystemC and C/C++. For example, clocked threads are the only process type that is supported, so methods and threads may not be used. In addition, global variables, pointers, and dynamic memory allocation are not supported, either. 4. Using SystemC for Software In order to create a model with components that may be implemented in either hardware or software, we must begin with the restrictions that allow hardware synthesis. Then, we will add additional restrictions to the design to ensure that it will be compatible with a software implementation. These additional restrictions are discussed below. The software processes will execute on an embedded processor, so it is necessary to include a scheduler to control their execution. Because we are using a restricted subset of SystemC, we have developed a simplified version of the SystemC simulation scheduler that provides support for clocked threads and signals. The scheduler supports the SystemC execution model of concurrent processes that communicate through signals. It also supports the delta-cycle update of signals and the wait () and wait_until() functions. The scheduler follows the algorithm shown in Figure 3. For each iteration, all threads that are able to execute are executed. Then, any signals that were modified are updated, and all waiting threads that are now able to execute are activated. The sequence then repeats. Note that, similar to the SystemC simulation kernel, the order that threads are executed during a particular iteration is not specified. However, once a thread suspends, it is guaranteed that all other active threads will execute before that thread is rescheduled. It is also guaranteed that the signals will be updated before the thread is rescheduled. So, each iteration of the scheduler is similar to a clock cycle in the SystemC simulation kernel, although there is no implication that individual software cycles will take the same amount of time. However, given this execution model, designs that execute correctly as hardware components with the SystemC simulation kernel will also execute correctly as software components Software Implementation of Signals To support the concept of delta cycles for updating signal values, each signal must include a current value (current_val) and a next value (next_val). In addition, there are three methods or functions associated with 1. Execute active threads and methods according to sensitivity list 2. Update output signals 3. Activate waiting clocked threads that are now ready (due to changes in signal values) 4. Repeat steps 1-3 until no more signals change value 5. Execute activated clocked threads 1. Execute all active threads 2. Update signals 3. Activate waiting clocked threads that are now ready (due to changes in signal values) 4. Repeat steps 1-3 Figure 2: SystemC Scheduler Figure 3: Modified Scheduler

4 signal.read() { return current_val; signal.write(val) { next_val = val; signal.update() { current_val = next_val; Figure 4: Signal Functions each signal read, write, and update. As shown in Figure 4, the signal.read() function returns the current value of the signal, the signal.write() function updates the next value of the signal, and the signal.update() function synchronizes the current and next values. For proper operation, all accesses to signals by threads should be through the read and write functions. This is done by binding signals to the thread s ports, so that when the thread reads from a port, the signal.read() function will be invoked. Similarly, writing to a port will invoke the signal.write() function. The signal.update() function should only be called by the scheduler. This function is used to implement the deltacycle update of the signal value. The scheduler must maintain a list of all signals in the system so that it can update them during each software clock cycle. The constructor for the signal must register the signal with the scheduler, adding it to the list. During each cycle, the scheduler will traverse this list, invoking the signal.update() function for each signal Software Implementation of Clocked Threads Threads may be in an ACTIVE state, meaning that wait() { suspend current thread switch to next active thread Figure 5: wait() Function wait_until( condition ) { suspend current thread if (condition is false) { current thread state = WAITING remove current thread from Active List add current thread to Waiting List switch to next active thread Figure 6: wait_until() Function the thread is ready to execute, or in a WAITING state, meaning that the thread is waiting for an event on a signal or combination of signals. The scheduler must maintain two lists of threads, an Active list and a Waiting list. When a thread is created, it is initially added to the Active list. During each cycle, the scheduler will, in turn, execute each Active thread. An Active thread will execute until it reaches a call to the wait() or wait_until() function. As shown in Figure 5, the wait() function will cause a switch to the next Active thread. The calling thread will suspend execution, but will remain in the Active state. A call to the wait_until() function, illustrated in Figure 6, will also cause a switch to the next Active thread. However, the thread calling wait_until() will also include as a parameter a boolean condition to test. If the condition is false, the thread is changed to the WAITING state, and it is removed from the list of Active threads and placed on the list of Waiting threads. After the scheduler has executed all Active threads in a cycle, it updates the signals, as shown in Figure 7. Next, as illustrated in Figure 8, the scheduler will test the condition for each Waiting thread. If the condition is now true, the thread s state is changed back to ACTIVE, and the thread is removed from the Waiting updatesignals() { for (each signal) { call signal.update() Figure 7: updatesignals() Function activatewaitingthreads() { for (each waiting thread) { if (thread s condition is true) { thread state = ACTIVE remove thread from Waiting List add thread to Active List Figure 8: activatewaitingthreads() Function

5 list and returned to the Active list. It will then be executed, along with the other Active threads, during the next cycle. If the thread s condition test still evaluates as false, the thread remains in the WAITING state. Other functions called by the scheduler are shown in Figures Notice that only the functions suspendthread() and restorethread() are dependent on the processor being used. These functions must save and restore the current state of a thread, which includes the values stored in the processor s registers, the instruction pointer, the stack pointer, and any other status information. Since this information is processor dependent, these functions would have to be reimplemented to port the scheduler to a different processor Additional Restrictions for Software Execution The restrictions necessary to allow hardware synthesis of the model were discussed earlier. To allow a software implementation, we must add one additional restriction. Because of the concurrent execution of threads in the system, we need to synchronize access to shared data and signals. suspendthread() { save register values save instruction pointer save thread status Figure 9: suspendthread() Function switchtonextthread() { if (no more active threads) { update signals activate waiting threads current thread = head of Active List else { current thread = next thread in Active List restore current thread All communication between modules must use signals and ports. The delta-cycle update of the signals will ensure that threads in both modules see consistent values of the signals. In addition, transfers of data should use a twohandshake scheme, as shown in Figure 12. Notice that only the Sender thread writes to the Data Ready signal, and only the Receiver thread writes to the Ack signal. With the scheduler executing both threads every cycle and updating the signals using delta cycles, this handshake ensures the proper synchronization between the threads. The Receiver will not access the data until the Sender has written it, and the Sender will not overwrite the data before the Receiver has read it. Transfers between threads in the same module should also use the two-handshake scheme. However, only Data Ready and Ack must be implemented with signals. The data can be implemented with member objects of the module, since both threads would be able to access the objects. The handshakes rely on the deltacycle updates, though, so they must use signals. Synopsys recommends that handshaking be used for hardware implementations as well because the CoCentric compiler may insert additional cycles in order to properly schedule and synchronize the threads [7]. There is no guarantee that the number of clock cycles needed for the synthesized circuit will be the same as for the simulated model. If handshaking is used, however, the threads will be properly synchronized. 5. GSM System Model To demonstrate the use of SystemC for the software in an embedded system, a model of a GSM communication system [11] was developed. Details of the model are presented in [12]. A block diagram of the GSM encoder is shown in Figure 13. A SystemC model of each block was developed. To manage the synchronization and transfer of data between blocks, Input and Output processes were included in a module with each Compute process, as shown in Figure 14. Data is transferred between the processes in the Sender Receiver Figure 10: switchtonextthread() Function restorethread() { restore register values restore instruction ptr restore thread status <write data> send DataReady <wait for Ack> DataReady Ack <wait for DataReady> <read data> send Ack Figure 11: restorethread() Function Figure 12: Two-way Handshake

6 Speech Speech Enc Parity Enc Conv Enc Modulate Interleave Burst Cipher Channel Data Figure 13: GSM Encoder Block Diagram RTR START DIA RAK Input STOP IACK IDR IDP module, and between the Input and Output processes of adjoining modules, using a handshaking scheme as described above and in [12]. Using a tool under development at Virginia Tech, the model was partitioned into hardware and software components. The chosen partition implemented the Speech Encoder in hardware, with the other blocks implemented in software. The software portion of the system was compiled for the Motorola StarCore DSP processor, and executed using an instruction-set simulator to measure execution time. For comparison purposes, another version of the software blocks was developed that implemented the functionality of the Compute threads of each block, but without the overhead of threads, the scheduler, or signal handshakes. Comparison of the two versions shows that the SystemC version incurs an overhead cost of approximately 10%. However, the advantage of the SystemC version is that very few changes to the original system model were necessary. In fact, we envision that the process could be automated, allowing designers to develop a single model that could be automatically partitioned into hardware and software components, each of which would both then be synthesized. 6. Conclusions Compute STOP ODR OACK RTS Output RAR Figure 14: Input, Compute, Output Processes DOA This paper has investigated the use of SystemC as a language for implementing the software component of an embedded system. The design of a simple scheduler that can execute SystemC threads was presented, and we also discussed some restrictions to the SystemC language that should be followed to allow both hardware and software implementations of the system components. Preliminary results show that a reasonably efficient implementation can be obtained. By following this approach, implementations of both the hardware and software portions of the system can be derived from a single model of the system, allowing for faster system development and quicker time-tomarket. 7. References [1] G. Martin and B. Salefski, "System Level Design for SOC s: A Progress Report, Two Years On," International HDL Conference and Exhibition, 2000, pp [2] December [3] D. Engels and S. Devadas, "A New Approach to Solving the Hardware-Software Partitioning Problem in Embedded System Design," Proceedings of the 13 th Symposium on Integrated Circuits and Systems Design (SBCCI 00), September 2000, pp [4] J. Straunstrup and W. Wolf, Hardware/Software Co- Design: Principles and Practice, Kluwer Academic Publishers, pp [5] Synopsys, Inc, CoWare, Inc, and Frontier Design, Inc., SystemC, Version 1.0 User s Guide, [6] S. Swan, et. al., Functional Specification for SystemC 2.0, October 5, [7] Synopsys, Inc, CoCentric SystemC Compiler, Behavioral Modeling Guide, December [8] Synopsys, Inc., CoCentric SystemC Compiler, User Guide, December [9] December [10] W. Mueller, J. Ruf, D. Hoffmann, J. Gerlach, T. Kropf, W. Rosenstiehl, "The Simulation Semantics of SystemC," Proceedings Design Automation and Test in Europe, 2001, pp [11] T. S. Rappaport, Wireless Communications, Principles and Practice, Prentice Hall PTR, [12] A. Varma, J. Armstrong, J. Baker, "A SystemC GSM Model for Hardware/Software Co-Design," to be presented at the International HDL Conference and Exhibition (HDLCon 2002), March 2002.