Archana Shetty, Lucent TechnologiesNisha Nair, Lucent TechnologiesShilpa R, Siemens Communications SoftwareNagendra Gulur, Texas InstrumentsBangalore India
Simulation-based tools have become increasingly prevalent in the electronic system-level design (ESL) process, addressing a spectrum of needs spanning architecture exploration, design synthesis, design verification and pre-silicon embedded software development. This, coupled with growing complexity of modern embedded processing platforms, brings up the issue of efficient construction of simulation platforms.
In this paper, we discuss a method of efficiently constructing peripheral simulation models from simple & easy-to-use representations. The method achieves multiple objectives:
- efficient input of the standard parts of a peripheral specification
- flexibility to implement any behavioral specification via ANSI ‘C’
- simple representation format
- support for multiple output ‘styles’:
- C model
- SystemC model
- generation of test bench
This paper discusses the method in detail, including the specification representation format termed the ‘peripheral specification language’ (PSL), and a detailed case study highlighting improved development productivity.
Simulation-based tools are being increasingly applied to the electronic system-level design process addressing the diverse areas of architecture exploration, design synthesis, design verification and software development.
At the front-end, system definition is being carried out via high-level exploratory analyses driven by performance oriented simulations. Later on, as the architecture gets defined, detailed simulation models are created to quantitatively measure and validate the system performance on realistic application scenarios. Once the architecture has been specified, functional and/or timing-aware (timing-approximate or timingaccurate) models are created to enable pre-silicon software development and design verification (or, even design synthesis in a few cases, especially those designs involving co-processors and accelerators).
At the same time, hardware systems are becoming increasingly sophisticated, comprising multiple CPU cores (control processors and DSPs), multi-level memory hierarchies (caches, & external memory interfaces), DMAs, co-processors & accelerators, custom logic and a rich set of I/O peripherals (such as audio, video, communication, & disk controllers). Further, derivative platforms are being put together at a rapid rate to integrate multiple different functions onto system-onchip (SoC) devices.
This motivates consideration for tools and techniques that enable building simulation models quickly.
Our paper is organized as follow: section ii discusses related background of our work. Section iii describes the overall peripheral model generation approach. In section iv, we present the peripheral specification language (PSL). Section v presents a detailed case study involving the TI 32-bit timer peripheral. We conclude in section vi.
Our focus was to setup a framework for rapid creation of simulation models conforming to given specifications. By a ‘simulation model’, we mean an executable implementation of a hardware IP specification. Such an executable implementation could conform to industry standards (such as SystemC ) and/or company-specific standards. The model should be capable of exhibiting adequate correctness w.r.t given IP specification. This includes:
- functional correctness –
- correct transformations of inputs to outputs (i.e., correct behavior)
- correct programming support (register programming, memory map, etc)
- timing correctness –
- approximate or exact timing of transformations
- interface correctness –
- correctness of the pins & bus interfaces of the IP model
Thus, a typical IP model has to implement the below attributes:
|Category || Attributes |
|Functionality (‘Untimed’ Behavior) ||a. user visible registers |
b. register accesses
c. internal data and functions that transform inputs to outputs
d. correct ordering of responses to requests
e. functional state machine
|Timing || a. pipelining |
b. resource contention model (banks, busses etc)
c. timing state machine
d. communication attributes (transaction burst size, width etc)
|Interface || a. pins, busses |
The recent TLM standard  proposes a classification scheme based on the above considerations.
We classify the above attributes into 2 categories:
- attributes that can be represented in a higherlevel format amenable to easy input and processing by tools
- attributes that are best represented in a general purpose programming language
|Attributes represented in higher-level format |
|Register set Specification |
|Interface Specification |
|State transition model Specification |
Table 1 Attributes represented in higher-level format
|Attributes represented in a general purpose programming language |
|Functions that transform inputs to outputs |
|Timing specifications |
Table 2 Attributes implemented in general purpose programming language
Note that the above classification is one possible classification ; formal standardization of the specification can lead to additional attributes (aspects of behavior functions and timing specifications) to be represented in the higher-level format.
While related work on IP model generation exists in the industry, they suffer from two significant shortcomings:
- proprietary implementation tied to the language (lack of an independent specification language definition)
- insufficient expressivity (or, alternately, new language & semantic constructs are imposed)
Our work addresses both the shortcomings via a simple, open language (decoupled from implementations) as well as the use of ANSI ‘C’ code for expressive power. In our work, attributes in Table 1 are specified via the proposed Peripheral Specification Language (PSL), while attributes in Table 2 are implemented in ANSI ‘C’ style.
iii. OVERALL GENERATION METHODOLOGY
As outlined above, the generation methodology involves a combination of input in PSL format and the rest in standard ANSI ‘C’ format. To keep the generation framework open and flexible, all that we standardize is the PSL language specification in Comma Separated Variables (CSV) format (see next section), thereby allowing:
- Many producers of PSL outputs, including graphical front-ends
- Many consumers (typically, scripts) of PSL inputs, that may generate SystemC and/or other implementations
iv. PERIPHERAL SPECIFICATION LANGUAGE (PSL)
The PSL is specified as a series of key, value pairs represented in the commonly understood MS Excel Comma Separated Variables (CSV) format. The choice of the CSV format enables simple manual input, support for graphical front-ends as well as easy parsing of the specification for model generation in various styles. Below, we outline the key sections defined in the PSL and their contents.
This section captures helpful information concerning the IP model being specified. Fields are listed in Table 3:
|Field Name || Description |
|Name || IP name |
|Version || IP version implemented |
|Date || IP model creation/update date |
Table 3 Header Section Fields
Typically, this information is useful in releasing updated versions of the model in PSL format, and to track defect reports against specific versions.
This section specifies the set of registers, their bit fields, allowed read-write permissions and reset values.
|Field Name || Description |
|Name || Register name |
|Size || Size of register in bits |
|Is_Readable || Flag to denote if register is readable by software |
|Is_Writeable || Flag to denote if register is writeable by software |
Name of bit field
Length of field in bits
Starting position of bit field in register
Flag to denote if bit field is readable by software
Flag to denote if bit field is writeable by software
Reset value of bit field upon initialization
Table 4 Register Section Fields
This information is used by model generators to output register read, write functions with appropriate read, write masks; the reset value information is used to initialize the model to appropriate state.
This section specifies the set of interfaces, their names, directions, associated value types and behavior functions. The fields are described in Table 5.
|Field Name || Description |
|Name || Interface name |
|Direction || Input (to the model) or Output (from the model) |
|Type || Pin, Standard Bus, or Custom Bus Pin – no value associated with interface Standard bus – standard value types (ints, shorts, bool etc) Custom bus – arbitrary ‘structure’ types |
|Activation condition || ANSI ‘C’ Boolean expression which would be evaluated to trigger associated model function corresponding to the interface |
|Model function || Implementation function in the model that is to be notified upon evaluating activation condition to true |
Table 5 Interface Section Fields
This section is utilized by model generators to hook up model functions to corresponding interfaces. Note that the activation condition is any valid ANSI ‘C’ expression and the activated function is any ANSI ‘C’ implementation. This mechanism provides flexibility to the implementer of the model.
State machine specification:
This section captures the overall state transition and associated behavior activation & outputs of the model. Capturing the state transition in the PSL ensures that the model’s implementation structure is well understood at the time of PSL input. Fields are described in Table 6.
|Field Name ||Description |
|Source || Source state of transition |
|Destination ||Destination state of transition |
|Transition activation condition ||Condition(s) that activate the state transition (eg: register writes with specific values, input interface activation, implementation function return value, etc) |
|Output events ||List of output events or interfaces to be activated upon state transition |
Table 6 State machine Section Fields
This section governs the overall structure of the model and essentially ties the PSL input with the ANSI ‘C’ implementation of the behavior and timing parts of the model.
This section captures the file paths and function names of the ANSI ‘C’ implementation of the model. This information helps verifying and binding the PSL represented input and ANSI ‘C’ implementation.
v. CASE STUDY
The case study discusses the PSL specification and generation of ‘C’ source code for the TI 32-bit timer peripheral specification .
Overview of 32 bit Timer:
The 32-bit general-purpose timer is used to time events, count events, generate pulses, interrupt the CPU and send synchronization events to the DMA . The timer has two signaling modes and can be clocked by an internal or an external clock source.
The basic usage of timer involves :
- programming the control and period registers according to the requirements (clock source selection, counting period, output type, automatic re-start, etc)
- starting the timer by writing to the control register’s activation bits
- clocking the timer from the selected clock source
- upon counting the programmed period, the timer generates a DMA event or CPU interrupt
An "interfaces-and-registers" view of the timer is depicted below :
Figure 1 Block diagram of 32-bit timer
The timer is comprised of 3 registers:
- CTL – timer operation control register; this register must be programmed to configure and control timer operations
- CNT – the timer counter register; this register displays the current timer count
- PRD – the timer period register; this register is programmed with the clock period that the timer should count
Detailed bit-field descriptions are specified in Appendix A.
The timer is comprised of the following interfaces:
- Register read
- Register write
- External clock input
- Internal clock input
- Interrupt output to CPU (tint)
- Event output to DMA (tstat)
Timer State Machine:
The timer is started by writing the value of ‘1’ to the GO and HLD* bits of the CTL register, after programming the necessary control fields and setting up the required period. For the purpose of illustration, we model the timer as a simple 2-state machine, comprising:
- idle state – when the timer is not counting
- active state – when the timer is counting
We implement a simple count(.) function in ANSI-C, that implements the basic timer operation of counting up or down and generating interrupt (event) upon completing the programmed period.
The PSL specification of the timer is shown in Appendix B. Note the conditional state transition from ‘idle’ to ‘active’ based on the values of GO and HLD* bits while writing to the CTL register. Also note the call to the user implemented count(.) function from the internal and external clock interfaces (conditioned by clock selection and the timer state being ‘active’).
The generated ‘C’ code snippet is included in Appendix C.
We have been able to successfully test various timer counting modes and bring up test software over the generated model. It may be observed that the PSL representation format is simple and straight-forward, thereby facilitating quick & easy capture of IP models.
This paper presented a language and approach for rapid construction of simulation models of IP specifications. We chose a CSV based specification format for both ease of input as well as ease of generations of various kinds of outputs. Coupled with the flexibility of ANSI-C based specification of behavioral and timing aspects, this method achieves the dual objectives of improved efficiency as well as full control of the implementation. This method has been experimented on a handful of peripheral simulation models, and has demonstrated improved model development productivity.
1. SystemC – www.systemc.org
2. SystemC TLM reference – www.systemc.org
3. TI Timer peripheral specification (spru582a.pdf ) http://dspvillage.ti.com
4. TI DMA peripheral specification (spru577.pdf ) http://dspvillage.ti.com
viii. APPENDIX A
|Register Name || Bit position/Bit -Range ||Bitfield || Description |
|Timer Control (CTL) ||31 – 12 ||Rsvd ||Reserved |
|11 ||TSTAT || Timer status. Value of timer output |
|10 ||Rsvd ||Reserved |
|9 || CLKSRC ||Timer input clock source. |
CLKSRC = 0, External clock source
CLKSRC = 1, Internal clock source
|8 ||C/P* ||Clock/Pulse mode |
C/P* = 1,clock mode
C/P* = 0,pulse mode
|7 ||HLD* ||Hold Counter read or written regardless of HLD* value |
HLD* = 0, Counter is disabled and held in the current state
HLD* = 1, Counter is allowed to count
|6 ||GO ||GO bit. Resets and starts the timer counter |
GO = 0, No effect on the timers,
GO = 1 and HLD* = 1, the counter register is zeroed and begins counting on the next clock
|5 || Rsvd ||Reserved |
|4 || PWID ||Pulse width. Only used in pulse mode (C/P* = 0) |
|3 || Rsvd || Reserved |
|2 || Rsvd ||Reserved |
|1 ||Rsvd ||Reserved |
|0 ||Rsvd ||Reserved |
|Timer Period (PRD) ||31 – 0 || PRD ||Contains the number of timer input clock cycles to count. This number controls the TSAT/TINT signal frequency. |
|Timer Counter (CNT) || 31 – 0 ||CNT ||Current value of the timer counter |
ix. APPENDIX B
|Header Section ||Name ||TI 32_bit Timer |
|Version ||1.0 |
|Date ||14th October 2004 |
|Register Section ||Name ||Ctl |
|Size ||32 |
|Is_Readable ||Yes |
|Is_Writeable ||Yes |
|Bitfields ||Name ||Size ||Read/Write ||Position ||Reset |
|Rsvd ||20 ||R ||12 ||0 |
|TSTAT ||1 ||R ||11 ||0 |
|Rsvd ||1 ||R ||10 ||0 |
|CLKSRC ||1 ||RW ||9 ||0 |
|C/P* || 1 ||RW ||8 ||0 |
|HLD* ||1 ||RW ||7 ||0 |
|GO ||1 ||RW ||6 || 0 |
|Rsvd ||1 ||R ||5 ||0 |
|PWID ||1 || RW ||4 || 0 |
|Rsvd ||1 ||R ||3 ||0 |
|Rsvd ||1 ||R ||2 ||0 |
|Rsvd ||1 ||R ||1 ||0 |
|Rsvd ||1 ||R ||0 ||0 |
|Name ||External Clock |
|Direction ||IN |
|Type ||PIN |
|Function ||Model |
|((state==active) && (ctl.clksrc==0)) |
| ||Model |
|Name ||TINT |
|Direction ||OUT |
|Type ||PIN |
|State ||Source ||Idle |
|Destination ||Active |
|Transition ||Transition Cause ||Cause ||Name |
|((ctl.go==1) && (ctl.hld==1)) |
|Behavior Section ||Behavior ||Name ||Count |
|Path ||..\timer_user_code.cpp |