|
|
|
|
|
|
 |
||||||||||
|
Transaction Level Model of the USB On-The-Go controller IP coreUpdate: Cadence Completes Acquisition of Evatronix IP Business (Jun 13, 2013) By Marek Podeszwa, Filip Rak Evatronix S.A. Bielsko-Biala, Poland Wojciech Sakowski 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.
Programmer's View USB HS-OTG-TLM features Since TLM PV+T model should meet particular requirements, which are supported by USBHS-OTG-TLM :
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:
usb_timers models the following:
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: eCommStatus TransferACK() eCommStatus SendReq() eCommStatus ReceiveReq() 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:
Once initialized endpoint, then controller automatically service it until all bytes are transferred. On both AHB interfaces have similar basic functions for communication: TSlaveDataType Read( TSlaveAddrType* tRegAddr, int *pugData, eCommStatus* pStatus=NULL) void Write(TSlaveAddrType tRegAddr, TSlaveDataType gValue, int iInfo, eCommStatus pStatus=NULL)
Testing environment for the model In order to ease testing and verification process appropriate environment was developed – it consists of stimulus module that contains:
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 :
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) : @PRINT "Randomizing array" #ENDL @RAND(arr, 0, 9, 0, 100) @PRINT "Array contents :" #ENDL i = 0 :label @PRINT "arr[" i "] = " arr[$i] #ENDL @LOOP i++<10 label @END 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) : set irqtype usbintreq rise set irqtype dmaintreq rise set hsize 8 waitfor 500 ns APPLY_B_PERIPH 1 SISO_OUT 1 0x100 64 16 1 1 60 32 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 :
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 :
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) : TFieldWrap<u8> oReg; oReg = 0x1000; *oReg = 0xFF; u8 ucVal = *oReg; 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
|
|
||||||||
|
|
|
|
|
Home | Feedback | Register | Site Map |
|
|
|
All material on this site Copyright © 2017 Design And Reuse S.A. All rights reserved. |
