Industry Articles

Archana Shetty, Lucent Technologies
Nisha Nair, Lucent Technologies
Shilpa R, Siemens Communications Software
Nagendra Gulur, Texas Instruments
Bangalore India

Abstract :

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:

1. efficient input of the standard parts of a peripheral specification
2. flexibility to implement any behavioral specification via ANSI ‘C’
3. simple representation format
4. support for multiple output ‘styles’:
1.  C model
2.  SystemC model
3.  Others
5. 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.

i. INTRODUCTION

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.

ii. BACKGROUND

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 [1]) 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 b. protocol

The recent TLM standard [2] proposes a classification scheme based on the above considerations.

We classify the above attributes into 2 categories:

1. attributes that can be represented in a higherlevel format amenable to easy input and processing by tools
2. 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:

1. proprietary implementation tied to the language (lack of an independent specification language definition)
2. 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:

1. Many producers of PSL outputs, including graphical front-ends
2. 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.

Header specification:

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.

Register specification:

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
Bit_field Name Size Position Read Write Reset	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.

Interface specification:

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.

‘C’ specification:

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 [3].

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 [4]. The timer has two signaling modes and can be clocked by an internal or an external clock source.

The basic usage of timer involves :

1. programming the control and period registers according to the requirements (clock source selection, counting period, output type, automatic re-start, etc)
2. starting the timer by writing to the control register’s activation bits
3. clocking the timer from the selected clock source
4. 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

Timer registers:

The timer is comprised of 3 registers:

1. CTL – timer operation control register; this register must be programmed to configure and control timer operations
2. CNT – the timer counter register; this register displays the current timer count
3. 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.

Timer Interfaces:

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

‘C’ implementation:

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.

vi. CONCLUSIONS

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.

vii. REFERENCES

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
Interface Section	Name	External Clock
	Direction	IN
	Type	PIN
	Function	Model activation condition	((state==active) && (ctl.clksrc==0))
		Model function	count
	Name	TINT
	Direction	OUT
	Type	PIN
State Machine Section	State	Source	Idle
		Destination	Active
		Transition	Transition Cause	Cause	Name
				Register Write	ctl
			Transition activation condition	((ctl.go==1) && (ctl.hld==1))
Behavior Section	Behavior	Name	Count
		Path	..\timer_user_code.cpp