experiences of modeling soft ip's at high level of ...

EXPERIENCES OF MODELING SOFT IP’S AT HIGH LEVEL OF ABSTRACTION USING SYSTEMC: A CASE STUDY Suryaprasad Jayadevappa Imad Mahgoub Ravi Shankar Florida Atlantic University, FL, USA ({sjayadev, imad, ravi} @cse.fau.edu) Abstract Shortening time to market and increased design complexity of present day electronic systems have forced designers to model at higher levels of abstraction and support design reuse. Functionally accurate, high level abstract models so far have been designed typically using C/C++, Matlab, similar languages and tools. A major drawback of using C/C++ is its inability to model concurrency that is crucial in modeling hardware as well as its failure to support design reuse. SystemC is a system level design language. It is an extension of C++ and supports concurrency by threads ands methods. SystemC has many other additional features. One such main feature of SystemC is its ability to support modeling at different levels of abstraction. In this paper we discuss our experiences of modeling a Watchdog timer at transaction level in SystemC. The model developed is functionally accurate and cycle approximate. We use an organized and simple approach for modeling at higher level of abstraction, above register transfer level (RTL), in SystemC. The developed approach is easy to follow and implement. We discuss all the steps followed starting from specification, to identifying the interfaces and ports, to developing the test case, to design and verification of the model. Our approach is based on the interesting test first methodology followed in recent software design. Finally, we also showcase the ease of integrating the model developed with the simple bus model. The complete SystemC code is freely available for download from our website. This paper shares our experiences, results and lessons learnt in design and verification of the soft IP’s at higher level of abstraction. Our experiences helps plan soft IP development using SystemC at higher levels of abstraction.

1. Introduction To accelerate hardware design, designers use software models of the hardware they build. These models are used to validate the functionality and evaluate

performance. SystemC is a new language that is aimed at facilitating model development above the register transfer level [1,2]. SystemC 2.0 provides one with the capability to capture designs at various levels of abstraction. Built around the C++ language, SystemC has the necessary support to migrate designs seamlessly from higher-level design abstraction to the register transfer level. The single language ability to express designs at different levels of abstraction makes SystemC a strong contender for system level design language. Before SystemC, a typical design at system level was created using C/C++ or some variant. Then these designs had to be manually translated into register transfer level. This conversion would typically lead to many design errors. Present days design methodology for embedded systems and system on chip design is often platform based [3]. Intellectual property blocks play an important role in designs involving high complexity. Our study concentrates on experience of soft IP development at high level of abstraction typically above that of RTL. Verkest et al. [4] discuss the usage of C++ for system level design. They have considered system level design to involve two activities: (a) IP creation, involving IP implementation and refinement from an abstract algorithm to RTL design, and (b) IP integration, which ensures correct IP interaction with its environment. To support HW design, Pasko et al. [5] consider an extension of C++ based design methodologies with meta-language concepts. Doucet et al. [6] use C++ for describing components, and a scripting language for performing the dynamic composition of components in a design. In this paper we present our experiences in developing watchdog timer (WDT) a simple peripheral soft IP module. In section2 we present a case study discussing

Copyright © 2008 Center for Systems Integration, Florida Atlantic University.

the steps followed in modeling and testing the WDT in sufficient detail. In section3 we present results and in section4 we present observations.

Textual Specification Block & State Diagram

2.0 THE CASE STUDY Typically a watchdog timer (WDT) peripheral is used in a system to prevent system lock-up. For example, if software becomes trapped in a deadlock. In normal operation the user restarts the watchdog at regular intervals before the timer counts down to zero. If the timer does reach zero and the watchdog is enabled, one or a combination of the following signals are generated: - A system reset - An interrupt - An external signal The watchdog timer’s time-out period and the duration of different output signals are programmable. Figure 1 presents the different steps involved in modeling soft IP’s. The WDT module developed is modeled at a higher level of abstraction above that of the register transfer level (RTL) namely at the transaction level (TLM). TLM can be defined as a high-level approach of modeling digital systems where details of communication among modules are separated from the details of the implementation of the functional units or of the communication architecture [1]. At transaction level one is more interested in the functionality of the data transfers and less in the actual implementation. In a TLM though the model developed would be clock accurate, they tend to simulate faster than the RTL model due to less implementation details. The following steps are followed in developing the WDT module. Step1: Develop high-level block diagram and state diagram from textual specification document. Step2: Identify modules, ports, channels, interfaces and data types. Key- model need not be pin-accurate. Step3: Develop the necessary test cases, which would suffice to verify the model to be developed. Step4: Develop SystemC code for the model Step5: Create the test bench in SystemC for functional verification.

Develop Test cases

Develop SystemC module

Unit Testing

Integration Testing Figure 1. Steps in Soft IP development and Testing 2.1 Develop High level Block diagram and State diagram from specification The complete functional and detail description was available as a textual document. The textual document consisted of user information and technical information separately. Together the documents accounted to around 50 pages. After understanding the behavior of the WDT module, a high level block diagram created as presented in Figure 2. Bus_Interface

Cpu_debug

Reset_Signal

Watchdog Timer

Interrupt_Signal

Tclk External_Signal

Figure 2. Watchdog Timer Block Diagram The block diagram created does not provide pin level details, but helps in identify the distinction between communication and functional part of the WDT module. To better understand the functionality a simple state diagram is created. The state diagram captures the various possible states of the WDT module as presented in Figure 3.

The watchdog timer module includes the following signal interfaces: - WDT external and control signals Bus interface All timings of the interfaces are specified relative to the target clock, Tclk (main_clock). p_n_reset

Idle

Output Signals

Reset Values

done Restart

start

Timer = 0

Update Timer Value

Count = 0

Update Prescale Count

Figure 3. Watchdog Timer State diagram The bus interface is responsible for decoding the address and ensuring that the watchdog timer gets selected when an appropriate address is present on the address bus. The SystemC watchdog timer model developed is independent of this bus interface. The watchdog timer has four internal registers 2.2 Develop suitable test scenarios: After developing the high-level block diagram and the state diagram from the specification. Twenty test scenarios testing important features are developed. Here we follow the test first design as mentioned in extreme programming [7]. In the test first design approach no code is developed until the unit test is developed. Further code is written that satisfies the test developed. Simple test scenarios include, writing appropriate values with and without suitable key value to the different registers and reading it back. To verify the functionality of the correct working of the WDT developed, scenarios testing different signals being output for different timer values were also developed. This step further emphasized the need to develop the module such that it suitable values are written into the respective registers for the above test scenarios. It helps the module developer better target the module development. The actual implementation of the testbench itself is done in step 4. It involves both unit testing and integration testing with the bus.

2.3 Developing the SystemC code for the WDT module: This step can be further divided into sub-steps involving development of suitable communication and functionality of the WDT module. This provides a distinction or separation of concerns and helps support module reuse. If the bus interface changes, then only the communication part of the WDT module needs to be suitably updated and the rest remains unchanged. Also, by suitable parameterization: reusability, flexibility, and modularity can be supported. The important ports identified includes, the clock port, power-on-reset, and cpu-debug as input ports. The output ports identified include reset, external signal and interrupt signal. The bus interface is treated as a SystemC channel for connecting to the bus. Figure 4 provides the SystemC code snippet of the WDT module and the port description. SC_MODULE (WDTimer): public transfer_if { //Ports and interfaces sc_in_clk clock; sc_in cpu_debug; sc_in pow_n_reset; sc_port > bus_port; sc_out reset, extrn_signal, intrpt_signal; … }; Figure 4. SystemC code snippet of various ports and channels for WDT module. After identifying the ports, channels and interfaces, the processes were identified. The higher level of abstraction used to model the WDT helped in reducing unnecessary details. We modeled three SystemC processes, two as sc_thread’s and one as sc_method. The sc_method and sc_thread processes supported in SystemC help in modeling concurrency. The choice of sc-method and scthread is done based on the modeling requirement. The reset_wdt ( ) is modeled as a sc_method as the statements are to be executed and is sensitive to the power on reset signal. The other two processes modeled as sc-threads and are important in implementing the actual WDT model. It is sensitive to the WDT system clock and uses wait () statement.

In SystemC the wait ( ) statement can be used only with in a sc_thread. Reducing the number of parallel threads modeled helped in achieving higher simulation speeds. It took less than 3.4secs to verify the WDT model and a more detailed comparison with RTL verilog model is presented in [8]. Figure 5 presents the SystemC code snippet of the different processes used in modeling the WDT model. The holdSignal () process outputs the correct output signal (ResetSignal, InterruptSignal, ExternalSignal) for the duration of time that it was programmed for. This is a slightly complicated process, since one or more of the signals need to be set high simultaneously. The time duration is programmable and could be different. In this sc-thread process it uses three local variables which would store the time duration for keeping each of the output signals high. It has an infinite loop similar to the one in the main_thread() process. The different count values for the signals are updated on every positive edge of the clock. The signals are held high until their respective count values reach zero. SC_MODULE (WDTimer) : public transfer_if { … void reset_wdt (); void main_thread ();. void holdSignal (); void transfer_data (unsigned int adrs,int* data,bool rdwr); SC_HAS_PROCESS (wdtimer); //Constructor wdtimer (sc_module_name name) : sc_module(name) { SC_METHOD (reset_wdt); sensitive_pos