particular, through high-level discrete time system simulations. Towards the same ..... arrival rates, service times and processor loads may suffice to model the ...
DTNS: a Discrete Time Network Simulator for C/C++ Language Based Digital Hardware Simulations KIMMO KUUSILINNA, JOUNI RIIHIMÄKI, TIMO HÄMÄLÄINEN, and JUKKA SAARINEN Digital and Computer Systems Laboratory Tampere University of Technology Hermiankatu 12 C, FIN-33720 Tampere FINLAND
Abstract: - This paper introduces a way to enhance digital system design, and multimedia hardware design in particular, through high-level discrete time system simulations. Towards the same end, bus based interconnection architecture is utilized for intellectual property interfacing. The emphasis is on architecture design, design space exploration, and hardware/software co-simulation. A Discrete Time Network Simulator (DTNS) is described as a novel extension to current simulators. DTNS simplifies many aspects of architecture exploration and supports technology optimization for continuous-media applications. Design re-use is facilitated by the use of a common programming language and data transmission efficiency by using the Heterogeneous IP Block Interconnection (HIBI) scheme. The fixed time increment, discrete time, approach allows rapid model development and fast simulations. Long simulations can be run to obtain statistical performance information. A video encoder (H.263) based simulation is used to demonstrate these capabilities. Key-Words: - Simulation, Modeling, Intellectual Property, Computer Aided Design, and Multimedia.
1 Introduction The paradigm shift from desktop applications to real-time, continuous-media, mobile computing is challenging contemporary digital design practices [6]. The shrinking size drives whole electronic systems into a single integrated circuit (IC). These solutions are called systems-on-a-chip (SoC). To cope with the complexity and time-to-market constraints some design objects are prepared for reuse and called intellectual property (IP). These IP blocks can be shared within an organization or obtained from external sources. Architecture exploration is a quite laborious task with current design tools. The most important decisions during the design process are made at the highest levels. However, acquiring reliable information to form a basis for these decisions is difficult. The traditional system simulation tools for signal processing applications use heavy abstractions for communication between functional blocks. These abstractions are fine for algorithm design but cannot be considered valid for hardware design in systems where the communication between blocks forms a significant portion of the complexity of the design. In addition, the lack of hardware models for processors and interconnection architectures seems to be of a paramount importance.
Contemporary design tools have many other weak points as well. If the detailed models are used, simulation times for complex designs can easily become prohibitive. Hardware description languages (HDLs), like VHDL (VHSIC Hardware Description Language), and their simulators are a representative example of simulation environments that are capable of representing designs in necessary detail but they may be too slow in the architectural design phase. In addition, their expressive power is quite limited compared to contemporary object oriented programming languages like C++ or Java. Thus, describing architectures and their communications can be very time consuming. To solve the aforementioned problems, one design tool or a specific technology is not enough. Thus, we propose an interconnection based design flow. We propose an interconnection, Heterogeneous IP Block Interconnection (HIBI), which is capable of exploiting the predictable nature of continuousmedia processing [7]. Therefore, HIBI should be able to provide the same throughput with less signal lines than the conventional bus architectures. In addition, we propose a tool for architectural exploration and interconnection parameter optimization; the Discrete Time Network Simulator (DTNS). DTNS is a C (C++) language based extension to current simulators. It is intended for the highest level of design and it exploits the fact that many of contemporary multimedia algorithms are
specified in C language, thus bridging the oftenencountered tool flow gap between specifications and the first behavioral implementation. In addition, using standardized interconnection architectures, from a library of such components, this tool facilitates design reuse. DTNS is based on the discrete event simulation methodology, which enables fast simulations while retaining the correct logical operation of the interconnection structure. Furthermore, we describe a top-down, simulation based, design flow for SoC designs. The paper is organized as follows. Section 2 describes the design flow that is required for efficient use of simulations in SoC designs. In Section 3 the DTNS simulation details are explained. Section 4 is about applying the Discrete Time Network Simulator with the HIBI bus to a H.263 video encoder. Finally, in Section 5 the conclusions are given.
2 Simulation Based Design Flow There is no single way to classify hardware/software simulators. Our classification is based on [1] and [5], and uses the design abstraction level as the main distinguishing factor. It is usually possible and desirable to mix components from different abstraction levels to perform multi-level simulations. During different phases of the design flow, different simulation levels are used. Notable is the fact that non-trivial designs need to be simulated in several levels. Usually the contemporary simulation environments are different from one level to another. Therefore, to avoid making completely different descriptions to all simulation levels a flexible and continuous tool flow is necessary. Statistical simulations describe the problems as high-level mathematical models. This type of simulators are useful for validating generic concepts. They do not necessarily provide any detailed information about a specific system. Despite the lack of exact information, the growing complexity of SoC designs requires designers to adopt design tools, which operate at this level. However, most simulators dealing with data transfers are so called network simulators. These simulators are mainly intended for multicomputer or multiprocessor simulations, thus limiting their usability for embedded designs. Typical for simulators at this level is their use of statistical distributions and some generic simulators are heavily biased towards solving differential equations. This may be useful in modelling complex physical systems, in which the embedded design must operate.
Data flow simulations are very similar to statistical simulations. However, their data flow is based on the actual application run on the system and not just statistical models of system inputs. This approach is more suitable for embedded designs because the special nature of custom computational nodes can be better accommodated. The down side is that systems can no longer be conveniently analytically analyzed. Algorithm level simulations are essentially simulations of the specifications or simulations of behavioural implementations of specifications. Communication between different components is usually abstracted as streams of information in a communication channel. The division between hardware and software parts need not have been performed. Typically, very little, if any, timing information is available. At instruction level, the design has been divided into hardware and software parts. The software part is simulated in an Instruction Set Simulator (ISS), which, at this point, typically uses very little timing information. The hardware either is in algorithm level or described in behavioural hardware description language (HDL). If component communications are deemed less important, they can still be very abstract. Otherwise, communications can be described in HDL. Approximate instruction order and clock cycle based timing information may be available. Architecture level simulations describe the functionality of the hardware in detail. This requires the design to be specified at least in behavioural HDL. Intellectual property blocks may have been instantiated. The communication between components is also specified in corresponding level. Thus, relatively accurate clock cycle based timing information should be available. Register transfer level (RTL) describes hardware that can be synthesised. Timing information is available in terms of clock cycles. Simulation times for large systems are very long. We can see four major problems with this traditional design flow. (1) The lack of timing information in algorithm level descriptions, even though it may be present in the original specifications. (2) The design description and tool gap between specifications / algorithm and the instruction / architecture level implementation. (3) The abstraction of inter-component communications to communication streams. Due to the difficulty of describing communication structures and the prohibitive simulation times the possibility for architectural exploration is limited to the highest abstraction levels. However, the communication stream abstraction makes the performance
evaluation of different architectures difficult. This criticism is directed to dedicated, embedded applications, where statistical load estimates cannot be considered valid. (4) Simulation times with the more accurate simulators may become prohibitive. Thus, architectural design must be performed in higher levels, typically with less information than would be available in the lower abstraction levels.
interconnection are resolved. Then, all agents are run with the current interconnection values. The agents, thus, produce the interconnection values for the next phase. The values from all agents are combined together and the final signal values resolved. D T N S Library Interc onnec tion M odels Agent M odels M athem atic al F unc tions O ther S upport F unc tions
3 Discrete Time Network Simulator The Discrete Time Network Simulator can be used as a stand-alone simulator. However, it is mainly a C language function library intended to support synchronous interconnection design and analysis. DTNS supplements any C or C++ language based simulator. The actual simulator provides the framework for the simulations. In DTNS, all signal transitions are tied to the system clock, making it a fixed time increment or time driven simulator. If used with a proper simulator, this software may support event driven simulation mechanics. The discrete time and fixed time increment approximations are done to make the simulation update cycle uncomplicated and, thus, faster. However, these approximations are accurate enough for many logical simulations in systems based on a global clock. The framework for using DTNS in a stand-alone configuration is depicted in Fig. 1. The DTNS main function can also be viewed as a top-level testbench. It is responsible for keeping the simulation running and instantiating the simulation modules. A typical DTNS simulation consists of an interconnection model, one or more agents for the interconnection, a monitor object to track and preprocess simulation variables and collection of assorted support functions. The support functions perform, for example, translations between hexadecimal and binary numbers. All signalling in the interconnections is based on a signal model analogous to the IEEE std_logic signal type in VHDL. Properly designed interconnection models, agents, and other functions are re-usable in other designs and they form the DTNS Library. A pseudocode for a DTNS main() function is depicted in Fig. 2. First, the interconnection model is defined and initialized. The actual simulation occurs in a loop that is executed for the specified number of simulation cycles. One loop corresponds to half a clock cycle in the system. In the loop, first the control for the simulation is read from a file. This control can take the form of, for example, interconnection values. The current values for the
Input Vec tors
Agent M onitor O bjec ts Agents (for every Interfac e) m ain () S im ulation Control instances: Interc onnec tion Arc hitec ture Interfac e Bloc ks Interfac e M onitor
S tatis tic s
Interfac e s ignals
S tatis tic s Interfac e s tatis tic s
S tatis tic s
An al ys i s 100 80 Protocol 3 60 Protocol 2
40
Protocol 1
20
Protocol 1
0 Agent 1 Agent 2 Agent 3 Agent 4
W ave W indow
M athem atic al S oftw are
Fig. 1. DTNS simulation flow.
Protocol 2 Protocol 3
P rotoc ol Chec k & Analys is
The multi-type logic signals can conveniently be used to catch errors, such as multiple agents driving the interconnection at the same time. The clock phase count is advanced by one. Current interconnection information is saved into files. Finally, in the loop, the next phase values are assigned as the current interconnection values. When all the simulation loops are done, statistical information gathered during the simulation is saved to a file. If multiple clock signals are desirable, the methodology for such descriptions is briefly discussed in [4]. main() initialize interconnection do read testvectors and control resolve current cycle interconnection for (each interconnection agent) { run agent with current values } resolve next cycle interconnection increment clock phase count by one output interconnection info assign current values
