Notes

Outline

SpecC Presentation CS269 Seminar in Embedded System Jiani Guo

Compiling SpecC for Simulation Jianwen Zhu, Daniel D. Gajski Introduction of System Level Architecture Exploration Using the SpecC Methodology L. Cai, D. Gajski,  M. Olivarez

Compiling SpecC for Simulation Present a SpecC-language-based approach for systme level simulation of SOC(Systems-on-chip) Pros and cons of this approach is compared against the existing library-based approaches. Discuss in detail the various design considerations for the SpecC simulation API as well as our reference implementation.

Introduction      Systems-on-chip calls for the use of executable system level design language(SLDL). Due to the pressure of time-to-market, it is not realistic any more to design system-on-chip completely from scratch. Hence the reuse of the so-called intellectual property(IP) components becomes an absolute necessary. It is critical for IP-centric design methodology to use a language to help the design specification and design exploration of an end application.

Library-based Approach The library-based method has been adopted to extend the C language to model IPs, in which a C++ class library provides features for hardware modeling. For example, Cynlib announced by CynApps, SystemC by Open SystemC Initiative,OCAPI library developed by IMEC. The semantic gaps still exist between the specifiers and the implementors: The mapping from system functionality in the specification to the system architecture is not trivial.  The mapping from the algorithmic representations of IP components from the providers to the RTL representations of IP integrators relies on behavioral synthesis tools which are not yet mature.

Language-based Approach:  SpecC The SpecC Technology Open Consortium(STOC) was founded in 1999 to promote the adoption of SpecC as the specification language for system level design. The SpecC language was developed in a different way:  First identifying the requirements of SOC design and then carefully devising a set of constructs with well-defined semantics.These constructs are an extension of the existing ANSI-C language. When a SpecC specification is simulated, the extended constructs are expanded into a set of simulation API calls. The user interacts with the constructs and the library is hidden. SpecC is a C-based SLDL designed to embrace the IP-centric design methodology

Library-based VS Language-based SpecC is better  Higher abstraction and stronger expression power from the specifier’s side The synthesis tools have a much easier task of analyzing and understanding the specification, where it is hard to differentiate the code used for specification from the code used for simulation.

A Short SpecC Tutorial A SpecC program consists of a set of behavior, channel and interface declarations. Behavior: a class consisting of a set of ports,a set of component instantiations, a set of private variables and functions, and a public main function. Through its ports, a behavior can be connected to other behaviors or channels to communicate. Channel: a class that encapsulates communication. It consists of a set of variables and functions, called methods, which defines a communication protocol. Interface: an interface represents a flexible link between behaviors and channels.

A Simple SpecC Program

SpecC Simulation API Goal: To separate simulator implementation from compiler implementation. Advantages: C++ code produced by any SpecC compiler can be linked with any SpecC API compliant simulation library to produce an executable. A wrapper library can be developed to wrap around existing simulation library, such as SystemC, or Cynlib library, to make them work with SpecC.

Deisgn issue of smulation API      How to divide the work of implementing SpecC semantics between SpecC compiler and SpecC simulator? One extreme ------ Letting the SpecC compiler to generate all the low level code and eliminating the need for simulation library      Comments: heavy compiler implementation; inflexible system The other extreme ------ Embedding as much functionality as possible in the simulation library and thus leaving the compiler simply translating the SpecC constructs into API calls      Comments:  Due to the limitation on the expressive power of C++, it is not always possible to find a concise correspondent of SpecC construct.

Our criterion To make the simulation API as simple as possible and let the compiler to perform the trivial yet tedious    work of translation. Results: API is surprisingly samll, only consumes 6 names in the C++ name space and 10 functions.

API Functions

Compiling SpecC for Simulation              Compiling SpecC Classes

Compiling SpecC for Simulation              Compiling Basic Data Types

Compiling SpecC for Simulation              Compiling Statements

Simulation Library Reference Design A reference design, called SpecSim, is developed for the simulation library to demonstrate the implementation of the SpecC system. The implementation is divided into three abstraction layers: API layer Discrete Event Layer Thread Layer

Simulation Library Reference Design Thread Layer Purpose:     To abstract away the implementation detail of different multi-threading packages we might use. It only offers a simple abstraction of execution context and the mechanism to perform non-preemptive context switch. Implemented by the three COM interfaces: Inative, Ithread, Ischeduler. Since choices of the multi-threading package to use on different platforms may vary, an multi-threading API is established to wrap around different packages.

Simulation Library Reference Design Discrete Event Layer Implemented by the COM interface IDeEngine. A scheduler maintains a priority queue, called the timing wheel. The time wheel contains a set of timed Events sorted by their time stamps. Each event contains a set of Threads and Closures(atomic functions) suspended for execution for a delay equal to the time stamp of the event. The interface functions such as waitfor,wait, notify add threads and closures to existing events, or newly generated timed events Insert events to the timing wheel The time wheel is empty when the simulation is over.

Simulation Library Reference Design        API Layer    Implementing the SpecC simulation API. Implements the classes defined in the API. Implements the API functions. Since the second layer provides the bulk of the simulation semantics, the implementation of the API functions only involves thread management.

Implementation and Experiments

Conclusion    The implementation of SpecC simulator strikes a balance between compiler complexity and simulator complexity,and is considerably smaller than alternative solutions.

Introduction of System Level Architecture Exploration Using the SpecC Methodology System level architecture exploration Focuses on changing the implementation from one target architecture to another target architecture, at the specification level of abstraction. Allows the designer to compare implementations on different target architectures and make trade-off decisions at the highest level of design abstraction. Defines a method to improve the current implementation by changing some part of the target architecture to meet design needs.

System Level Architecture Exploration with SpecC

JPEG Encoder Example

System Level Execution Time Concept and Simulation Enviroment At the system level, the total execution time of the design should be the dynamic sum of the estimation time of leaf function nodes,without going into any more granularity of timing. It is crude, but very useful in the early stages of designing. Profiling tools of chosen processors can achieve the execution time of leaf nodes. After using profiling tools and estimation tools, the estimation time should be written back to SpecC model using the waitfor keyword. This step will take the untimed system level specification model into a timed one. Estimates for communication are also needed.

System Level Execution Time Concept and Simulation Enviroment

System Level Architecture Exploration Process Five target architecture models are explored: Pure_SW model:  four leaf nodes are implemented in the SW. SW_HW sequential model: a HW is used to run DCT block while other leaf nodes remain in SW. SW_HW parallel model: SW and HW are scheduled to run different 8*8 pixel blocks input concurrently. SW_2HW parallel model: two HW and one SW are used to run different 8*8 pixel blocks input concurrently. SW_2HW shared memory  parallel model: a global memory is used to implement shared memory communication,instead of message passing communication.

Result