Transaction Level Model of the USB On-The-Go controller IP core

Update: Cadence Completes Acquisition of Evatronix IP Business (Jun 13, 2013)

By Marek Podeszwa, Filip Rak
Evatronix S.A.
Bielsko-Biala, Poland

Wojciech Sakowski
Institute of Electronics, Silesian University of Technology
Gliwice, Poland

Abstract

The paper describes a transaction level model of the serial bus controller compliant to USB On-The-Go specification [1]. The model has been developed as an abstraction of an existing IP core, written in VHDL. The possible use in the development or testing of a software driver was addressed too.

Purpose of the work

Transaction Level Modeling paradigm (addressed in more detail in the next section) creates a solid foundation for an effective concurrent design of software / hardware components of System-On-Chips. On the other hand wide IP reuse has become a common practice in System-On-Chip design and a source of substantial productivity gains.

Taking an advantage of both these technologies (Transaction Level Modeling and IP reuse) calls for availability of transaction level models as a standard element of virtual components (IP cores) deliverables.

At the same time for quite a few classes of electronic virtual components (if not all of them) supporting software is perceived by the users as important value adding component of the total solution offered by a provider of these cores. Such software may range from simple hardware abstraction layers that hide hardware details to the application programmer to multiplayer software stacks supporting complex protocols.

During development of the software supporting IP core such as the USB OTG controller availability of the transaction level model of this controller provides software developer with a virtual testing environment that enables effective debugging even before the hardware is available.

Originally the software stack supporting the USB OTG controller was developed before the work on the transaction level model was available. Experiences gained during the development of this software were a valuable source of requirements for debug support features of the TLM model.

Transaction Level Modeling (TLM)

TLM [2,3] is gaining interest because of its flexibility in handling different abstraction levels and separating on chip communication issues from functionality of the submodules (whether they are created in hardware or in software). Supported with a new breed of hardware description languages (like SystemC [4,5] and to some extent SystemVerilog) it has becoming an important technique that enables  shifting the design activities above the RTL abstraction level.

Thanks to the proper abstraction view of the underlying hardware, simulation times of TLM models may be orders of magnitude shorter than simulation of RTL models describing equivalent functionality, written in “classic” hardware languages like Verilog or VHDL. This makes feasible to test interaction of the hardware modeled with TLM and software that is meant to control this hardware.

As SystemC is simply a C++ [6] class library it is possible to link the hardware model described in SystemC with arbitrary C++ functions.

Elements of SystemC that support TLM paradigm are channels and their interfaces as well as ports. Channels represent resources responsible for communication between system modules. They enable to access them by direct call of methods provided by interfaces. When this approach is used simulation in so-called native mode is possible.

TLM models may support one of the two major abstractions: PV (programmer’s view) and PVT (programmer’s view with timing). The former focus on functionality features relevant to the programmer such as accessible registers and data and control interactions between software running on embedded processor and the modeled hardware, abstracting details of hardware implementation. The latter annotates this functionality with timing properties useful in system (or module) performance analysis.

Main features of the model

The model described in this paper (named USBHS-OTG-TLM) is a transaction-level model of Evatronix synthesizable USBHS-OTG-MPD serial bus interface controller core. This core complies to USB2.0 with OTG Supplement to USB 2.0 standard. Model was developed as transactional PV+T (Programmer's View with Timing) model using C++ language and SystemC library. Its main goal is to help in embedded software design and verification process, and in system architecture / performance analysis process.

USBHS-OTG-MPD features included in USBHS-OTG-TLM)

USBHS-OTG-TLM functionality includes subset of USBHS-OTG-MPD core features.

• Supports Host Negotiation Protocol and Session Request Protocol
• Supports Low-Speed, Full-Speed, or High-Speed peripheral devices in Host mode
• Supports Full-Speed and High-Speed data transfer in Peripheral mode
• Supports 16 IN and 16 OUT fully programmable endpoints
• Supported transmission modes: bulk/control, interrupt and isochronous
• Suspend and resume power managements functions
• Remote Wakeup function
• Interrupts
• USB protocol-aware multichannel DMA

Programmer's View USB HS-OTG-TLM features

Since TLM PV+T model should meet particular requirements, which are supported by USBHS-OTG-TLM :

• Register-bit accuracy to achieve seamless software connection. USBHS-OTG-TLM
• implements full USBHS-OTG-MPD register set and provides set of convenient user methods to access them.
• Communication and functionality separation to ease reusing and further refinements.
• USBHS-OTG-TLM can use blocking communication at model boundary to meet data consistency requirements, while using non-blocking communication between submodules to gain high simulation speed.
• Microarchitectural details decreased to minimal for increase simulation speed – USBHS-OTG-TLM is developed as algorithm model. SystemC constructions are used to allow concurrency and commu-nication (between distinct devices and within single device between submodules).

Additionally, as OTG functionality is strictly related to time behavior on USB bus, there is a separated module, which generates all necessary events for OTG algorithm.

This sub-module is used only when environment doesn't support own functions for event generation needed by OTG algorithm. When usb_timers is not used then USBHS-OTG-TLM is fully PV model, but it loses some functionality of USBHS-OTG-MPD that is part of timeout detection.

Model architecture

Division into sub modules

USBHS-OTG-TLM is divided into two sub modules to differentiate PV algorithms from time relations on USB bus.

Architecture overview of the model is shown in the Figure 1 below.

Figure 1. Top level view of USBHS-OTG-TLM

The functionality modeled by the components usb_pv and usb_timers referred to in the Fig. 1 are named below.

usb_pv models the following:

• SFR registers and convince functions for communication  with HOST device
• Forming and decomposing packets
• USB, DMA, Wakeup interrupt control functions
• OTG algorithm.
• Host Transaction Scheduler
• Device and Host transfer controllers
• CRC checking/generation
• Basic testing abilities
• Wakeup detection
• Suspend mode

usb_timers models the following:

• Upstream and downstream timeout events generation and USB bus reset generation/detection.
• SOF events generation
• OTG timeout events generation
• Interrupt timeout events generation

Communication between modules/sub modules

Communication between modules/sub modules is done by using sc_port to sc_export binding. Each submodule has corresponding interface with methods that are available to others and this interface is published using sc_export port. Communication inside of each sub-module is done through events.

Interaction with environment

Model uses non-blocking communication to exchange data with model and ULPI / UTMI  part.

Control information is transferred via functions through port with UtmiOut interface. These functions are used to control indirectly USB bus.

Packets are transferred with use of the following two functions.

status Send (const TPackage &tPackage)  

This function transfers structure of one packet from controller to USB bus.

status Receive(TPackage &tPackage)

This function transfers one packet in direction from USB bus to model.

There are also transfer handshake functions:

These functions are responsible for information about transmission of package on USB bus.

Status of USB bus is transferred via port with UtmiIn interface, example functions that are used in controlling OTG algorithm are shown below.

status SetIddig (int iValue)   

Function sets Iddig signal to choose controller between Host and Peripheral

status SetbValid (int iValue)

Function informs that USB Host starts session and model goes to Peripheral mode.

The USBHS-OTG-TLM provides three interrupt request controllers, one for USB and OTG algorithms, one for DMA and one for wakeup. These interrupts are provided to CPU as port with a set of convenience functions.

CPU can use to communication with USBHS-OTG-TLM AHB slave interface. Another interface is AHB Master interface to system RAM for data transfers. This interface is driven by internal very flexible and useful DMA controller. The DMA controller can work in several modes:

• Ringpointer – In this mode DMA treats reserved memory area in the system RAM as a circular buffer.
• Incremental – burst transmission with incremental address (typical AHB transmission)

Once initialized endpoint, then controller automatically service it until all bytes are transferred.

On both AHB interfaces have similar basic functions for communication:

Figure 2. USBHS-OTG-TLM submodule architecture

Testing environment for the model

In order to ease testing and verification process appropriate environment was developed – it consists of stimulus module that contains:

• Input stimuli text-based script files parser written using Flex/Bison lexical/grammar analyzer and accompanying Flex lexer, that generates command sequence that is passed to appropriate BFM (CPU or UTMI),  parser itself, software stack and automatic test generator

• CPU BFM submodule which decodes CPU commands and applies proper stimuli to the USBHS-OTG-TLM model along with checking model responses

• UTMI submodule, whose role is similar to CPU submodule – that is, UTMI part receives UTMI-related commands from parser, decodes them and passes to model

• Software stack, which acts as ANSI-C-compliant implementation of higher protocol layers to provide easy API for embedded software developers

• Automatic test generator, which is responsible for verification process automation by generating complex stimuli sequence

CUSB_OTG_TLM model at PV abstraction level was designed to ease embedded software development and verification process.  Along with USBHS-OTG-MPD software stack was being developed and from the beginning software engineers took advantage from hardware-software cosimulation.

Testing environment with TLM model is shown in the Fig. 3.

Parser and stimuli script syntax

Parser takes input script file (written as an ordinary text file) and decomposes it into commands, that are stored in internal array, then processed and passed to appropriate environment component. Not only low- and high-level stimuli ones, but also more complex constructions, like :

• Scalar and array variables

• Flow control statements (conditional and loop statements)

• Randomization expressions

• Textual console output statements

Thanks to listed features scenario generation flexibility is ensured – there are no limits on events order declared in bus activity script (they are not processed as simple sequence), so there is possibility to develop non-standard sequence in order to check software behavior in incorrect situations.

Figure 3. Simulation environment for software development

Access to internal environment state values (for example current simulation time or USB speed mode) is possible via set of parser built-in read-only variables.

Sample script below shows some advanced constructions (randomization and displaying 10-element array) :

Automatic test generator

Automatic test generator is an overlay over low level parser – it takes high level statements and generates series of low-level commands, that are pased to CPU/UTMI BFM or executed directly by parser. The intention of introducing automatic test generator is to allow easy transmission validation by means of parametrized commands, as shown on script sample below (it shows complete script that performs single device, full speed ISO OUT transmission through endpoint #1 with error rate of 60% using ring pointer facility) :

Interaction with USB software stack

Software stack is a high-level protocol layers implementation written in pure ANSI-C. It consists of three logical parts :

• User layer interface (User API)

• Hardware-independent stack functionality

• Hardware Abstraction Layer (HAL)

For using together with USBHS-OTG-TLM, native cosimulation was used, instead of ISS-based approach – that means, software stack is compiled together with TLM component module to achieve very high simulation speed (much higher than possible to achieve when using ISS). The main drawback is that native cosimulation misses all architecture-dependent details, that are could be important to stack functionality. The other problem is interfacing TLM model with software stack. In order to complete such a task, stack should be written in  “layered” way (with clearly separated hardware-independent functionality and both interfaces – API user and hardware interaction routines), while retaining following rules :

• It should be possible to control both external interfaces (API and HAL) from within TLM model

• All infinite loops (eg for pooling flags / interrupts) should contain synchronization points to allow SystemC to switch to other TLM model threads

In case of USBHS-OTG-MPD software stack, register access is done by means of pointers , which are mapped directly to USB device SFR address space – to create link between stack and model, some workaround needed to be done : templated class that behaves as pointer does, but instead of reading / writing memory it calls read/write functions, as in code sample below (it shows pointer wrapper declaration, address assignment, sample value write and read) :

Interrupt handling is implemented in separate SC_THREAD in environment, which is sensitive to interrupt event, which calls stack service function.

Future model usage

First step of further TLM model evolution will be to develop simple model of remote standalone USB-like device, that will be will be capable of responsing for incoming packets and will emulate particular physical device (eg keyboard or mouse), that will replace environment UTMI BFM activity.

At the advance, TLM to RTL transactors will be prepared (written in half in SystemC and in half in VHDL) to run USBHS-OTG-MPD IP-core together with TLM environment – in such a case all performance measurements will be fully reliable, without including any environment overhead.

Conclusions

Transaction model of USBHS-OTG-TLM controller makes initial testing of the USB related software very convenient thanks to model debugging features (in particular: possibility of checking the state of each submodule).

Achievable simulation speed of the model makes such approach a viable alternative to testing the software with the hardware prototype. This enables parallel development of software and hardware.

Usage of native compilation method of simulating TLM module together with accompanying software stack shows easy and straightforward way to perform debugging and testing process. It also reveals some problems with software-TLM integration, which requires developing wrappers, but benefits of having both model and stack as one piece of C/C++ code (and thus being able to inspect internal state of both modules) is worth some additional job. Easiest way to quickly validate developed software is to use TLM model with an ISS.

Literature

1. Universal Serial Bus Revision 2.0 specification with 1.0a revision to USB On-The-Go Supplement, 2003

2. OSCI Standard for SystemC TLM, available at http://www.systemc.org

3. Frank Ghenassia (Editor), Transaction-Level Modeling with SystemC : TLM Concepts and Applications for Embedded Systems, Springer, 2005

4. SystemC Language Reference Manual, ver, 2.1 © Open SystemC International, May 2005

5. David C. Black, Jack Donovan, SystemC: From the Ground Up, Kluwer Academic Publishers, 2004

6. Bjarn Stroustrup, The C++ Programming Language, Addison Wesley, 2000