Efficient creation of peripheral simulation from specifications

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:

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

Table 1 Attributes represented in higher-level format

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:

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.

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.

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.

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

ix. APPENDIX B