Accelerating the Development of TLM-2.0 Models Using Model Authoring Kits (MAKs)

By Markus Willems, Sam Tennent; Synopsys Inc.
Aachen/Germany & Livingston/United Kingdom

Abstract :

Model authoring kits (MAKs) enable the rapid development of transaction-level models, TLMs, of a given functionality or protocol. MAKs include base functionalities that are common to all models independent of the RTL implementation in a well-structured way, allowing for maximum reuse. The DesignWare System-Level Library provides MAKs for UART and USB. Taking the example of a USB 2.0 EHCI controller model using MAKs, this paper explains the significant design time reduction that can be achieved.

1. Motivation

SoC design complexity drives the widespread use of virtual platforms, with use cases ranging from pre-silicon software development, architectural exploration, all the way to software-driven hardware verification. Modeling a virtual platform typically goes beyond the SoC, but would include almost all elements that one would find on a hardware board, be it functionality implemented by an FPGA, I/O capabilities to get real data in and out the system, as well as user interface components such as displays and keyboards.

The value of virtual platforms is closely linked to the early availability of the building blocks. These are typically modeled at the transaction level, therefore they are often referred to as TLM models. With the ratification of the SystemC TLM-2.0 standard integration of TLM models became significantly easier. TLM-2.0 has triggered a whole new market to evolve, with more and more IP providers offering TLM-2.0 views of their implementation IP. The DesignWare System-Level Library [1] from Synopsys featuring TLM 2.0 views of the popular DesignWare Cores, or ARM’s Fast Models [2] are good examples for this.

While commercial IP users might be able to rely on readily available TLM offerings, the situation is different for most inhouse-IP. Some options exist to reuse existing RTL-IP by either automatically translating it to SystemC, or by co-simulation. In either case, the results will suffer from poor simulation performance, so developers eventually need to invest in the manual creation of TLM-2.0 models of their IP. This is a tedious and error-prone task. Tool vendors have come up with solutions to help with the creation of TLM-2.0 models. This includes the semi-automated creation of the register configuration including IP-XACT import, as well as creating the appropriate, software driven test bench that would help to check the correct configuration of the registers, and can serve for regressions. Component Creator, a feature of Innovator [3] is one of these dedicated solutions. All these tools significantly help to describe the register interface, but offer limited value on describing the model’s behavior, though.

For given protocols a large degree of the behavioral description can be decoupled from the actual implementation. As an example, different implementations of a USB host might look fairly different from an RTL perspective, but can share a lot of the behavioral description as required for a TLM-2.0 model. Significant time can be saved if such base functionality is readily available, and does not have to be implemented from scratch. The term “model authoring kit”, or short, MAK, reflects the idea: MAKe your own model, by taking advantage of proven base functionality.

This paper is structured as follows: Section 2 reviews the concept of transaction level models. Section 3 addresses the topic of model features that allow a virtual platform can interact with the environment. The topic of TLM model shell creation is covered in section 4, followed by an overview of the DesignWare System-Level Library, which includes an initial set of MAKs. Section 6 takes a detailed look of how to deploy MAKs to develop a USB 2.0 Host Controller, with section 7 providing a summary.

2. Transaction Level Modeling (TLM)

The concept of Transaction-Level Modeling is well described in the literature. Citing from [4]:

“Transaction level modeling is a high level approach to modeling digital systems where details of communication among modules are separated from the details of the implementation of the functional units or of the communication architecture. Communication mechanisms such as busses or FIFOs are modeled as channels, and are presented to modules using SystemC interface classes. … in other words, at the transaction-level, the emphasis is more on the functionality of the data transfers – what data is transferred to and from which locations – and less on their actual implementation”.

This definition gives some indication of the requirements for TLM models for a given protocol:

• TLM models need to come with the IP-specific register description (the “location” for the data transfer). So for any different implementations of the same protocol (e.g. USB) dedicated TLM models need to be developed
• For a given protocol, different TLM models can share a lot of functionality, even if implemented in different ways. Anything that can be abstracted from the actual register and timing configuration can be reused across models of the same protocol.

Obviously, reuse does not happen by accident, but requires authoring the TLM model in a well structured, layered way.

3. Virtual I/O and Real-world I/O

Virtual platforms might be used as a standalone simulation. But more often, they are interacting with the environment. Be it through a user interface that emulates a keyboard, a display, switches etc., or be it through streaming data in and out of the virtual platform. Two concepts, virtual I/O and real-world I/O can be applied, if supported by the corresponding TLM model. These two options shall be explained in more detail.

Virtual I/O:

A virtual platform can be used to model a device like a digital still camera, a USB video camera or a media player. Using Virtual I/O capabilities for software emulation of device I/O, the virtualized product can be connected to a Windows or Linux host on which the host controller resides and connects to the USB device. This process is illustrated in Figure 1.

In this case the virtual platform simulates the USB device in question. The USB Device Controller model is part of the virtual platform and an ARM processor runs the device driver and application software within the virtual platform. A software debugger can be attached to the processor in the virtual platform and the function of the device driver can be developed and verified on the virtual platform long before RTL or silicon are available. In addition, the USB application software running on the device – a data transfer program for media files in the example of Figure 1 – can be developed, debugged and verified.

Figure 1 – USB Device in virtual platform connected to real-world host

Pushing the button “USB Cable Input” connects the virtual platform to the USB Host Controller on the host PC on which the virtual platform executes. In effect, all the steps happening when the real device is connected will happen in this case as well, i.e., the Windows operating system will inform the PC user that a new hardware device has been detected – the hard disk of the media player. For its USB device TLM models, Synopsys provides a virtual USB Hub Driver. This Hub Driver interfaces to the Windows USB driver environment connecting the virtual hard disk in the media player to the Windows application (in this case Windows Explorer) in which the virtual hard disk appears as a new disk to interact with.

Real-World I/O:

Figure 2 illustrates another use model. This time the virtual platform simulates the USB host environment and the Host PC is connected to a real-world USB device. The real-world device, a memory stick, is connected the Host PC using the Host Controller Driver and Hub Driver provided by the Windows operating system.

Figure 2 – USB host in virtual platform connected to real-world device

Synopsys provides a USB Client Device Driver to connect this real-world device to the host executing in the virtual platform. In this way it is easy to develop, debug and verify host controller drivers and applications for different host operating systems.

4. Model Creation using Innovator’s Component Creator

As seen in section 2, a TLM model has to match the register configuration of the corresponding implementaton IP. With often 100 or more registers to be modeled, the development and testing of these registers is an error prone and tedious approach.

Innovator, Synopsys’ virtual platform development and simulation tool, provides an efficient way to author memory-mapped peripherals, using Component Creator. The model development follows a graphically guided process. It starts with the initial specification of ports, parameters and design interfaces. Next, registers and memory maps are specified as shown in Figure 3.

Figure 3 – Register Configuration Using Component Creator

As an alternative to the graphical design entry, the user can also provide an IP-XACT description of the RTL-IP.

Based on the information provided, Component Creator automatically creates the model shell, all register files, plus the corresponding address decoder, resulting in a significant reduction of the time spent on writing a model.

Just as important is the support for model validation. Component Creator automatically generates the the software template that triggers all registers (figure 4). Using the VPTest platform as provided in the DesignWare System-Level Library (see section 5), it is possible to cross-compile the template code and check for the correct register configuration.

Figure 4 – Software template as automatically generated by Component Creator

Component Creator also allows to generate an HTML-based documentation of the generated model, keeping it in sync with the actual model.

5. DesignWare System-Level Library

Figure 5: DesignWare System-Level Library

The DesignWare System-Level library provides TLMs to accelerate the development of virtual platforms. Written in SystemC, these models are designed to work in any IEEE-1666 compliant SystemC simulation environment. Models feature the SystemC TLM-2.0 standard API for easy integration, model interoperability and reuse.

The portfolio contains more than 100 models, including

• high-performance models of processors from the ARM7, ARM9 and ARM11 families, IBM’s PowerPC and MIPS.
• Transaction-level models of DesignWare connectivity IP including USB 3.0, USB 2.0, USB 2.0 OTG, SATA, Ethernet and PCIe cores.
•  Transaction-level models featuring the AMBA® and CoreConnect on-chip bus standards, featuring busses, as well as peripherals such as interrupt controllers, DMA controllers, I2C, etc.
• Infrastructure models which are generic models that are required in almost any virtual platform, but are time-consuming to develop from scratch, such as VT100 terminal, generic interrupt controllers, generic RAM models, component stubs, etc.

The DesignWare System-Level Library also contains pre-assembled platforms that can be utilized both as reference examples or starting points for larger virtual platforms.

Finally, it also includes Model Authoring Kits (MAK) for rapid development of customer-specific TLM models, currently featuring UART, USB Host, and USB EHCI.

Section 6 will cover the USB MAKs in more detail, so some details on the UART MAK: it allows the model developer to create UART Models quickly by encapsulating UART functionality in abstract classes.

Figure 6: UART Model Authoring Kit

A UART model consists of two sub-components, the register model and the port model. The UART MAK is used to link these two components together by providing receive and transmit FIFOs and the functions required to move data in and out of the FIFOs.

On the register model side, the WriteTx () and ReadRx() functions are used to add and remove data from the FIFOs.

For the port model several functions are provided to handle reception and transmission of data. PortReceivedData() and PortTransmitData() are used to handle UART receive and transmit pins whilst Poll(), PollRx() and PollTX() are used to handle real world I/O.

The UART MAK contains RealWorld I/O support, enabling the UART models to connect to real world devices to allow the model developer to test against a physical serial device using either the host COM port or a TCP connection along with the user’s own I/O methods. A Virtual Serial Port driver is supported on Windows platforms. The driver provides further serial ports which are fully Windows API compliant, in addition to any hardware ports on the host computer. I/O from the UART MAK can be directed to these virtual ports. This enables you to connect another application running on the same host computer to the UART being modeled. Also it is possible for the model to communicate with e.g. simple VT100 terminals (available in the DesignWare System-Level Library) via Tx/Rx transactions. The I/O method can be can be selected by runtime configuration parameters.

6. Example: Developing a USB 2.0 EHCI model using Model Authoring Kits (MAK)

USB enables cost-effective “outside-the-box” connectivity with hot-swap capability for industrial, consumer, embedded, PC, and PC peripheral products. USB requires a host to manage and control bus traffic to and from USB peripherals such as hard drives, cameras, flash card readers, printers, and scanners.

Included in the DesignWare System-Level Library, Synopsys provides TLM-2.0 models for its market-leading DesignWare Cores. These are fully compliant to the register configuration of the DesginWare core. For customers with a need to develop their own USB TLM models, the USB Model Authoring KIT (MAK) included in the DesignWare System-Level Library enables a head-start, accelerating the development of the transaction-level model. Separated according to the provided functionality, the Enhanced Host Controller Interface (EHCI) and Host Model Authoring Library provide generic USB functionality which can be extended by model developers to implement specific model characteristics like the actual register definitions. The libraries support C++ and SystemC model development and contain support for connecting to real-world devices.

Figure 7: USB Model Authoring Kits

USB Host Model Authoring Kit

The USB Host Model Authoring Kit (MAK) allows developers to create USB Host models faster by providing a simple abstract interface for communicating with USB Devices. The library provides for communication with real world devices, allowing developers to test their models against physical USB Devices.

The USB Host Model Authoring Kit has the following features.

• Support for communication with real world devices attached to the PC/Workstation.
• A protocol independent interface allowing any type Host model to be created.
• An asynchronous communications interface which makes implementing models easier.

USB EHCI Model Authoring Kit

The Enhanced Host Controller Interface (EHCI) is a high speed controller standard which is publicly specified. EHCI only provides high speed USB functions. It relies on a “companion controller”, either OHCI or UHCI, to handle full and low speed devices.

The EHCI Model Authoring Kit implements the EHCI specification (revision 1.0). Developers using this library are only required to implement the functionality that is specific to their component (e.g. extra registers for PHY control), greatly reducing development effort.

The EHCI Model Authoring Kit presents its API as a simple single class for ease of integration into a range of model technologies. It has the following features

• Implements all Host Controller Capability registers (except for HCSP-PORTROUTE).
• Implements all Host Controller Operational Registers.
• Supports up to 15 ports.
• Supports all types of transaction including split transactions.

The EHCI Model authoring Kit sits on top of the USB Host MAK.

In addition to the MAKs, the DesignWare System-level Library includes an example virtual platform which contains a simple USB EHCI Host Controller model created using the USB EHCI MAK. Full source code and the build environment are provided for this example.

Creating an USB EHCI Host Controller Model

This section will describe the steps required to create a simple USB EHCI Host Controller using the EHCI MAK. To do this we will reference the example platform described above.

Step 1 – Create your basic component

In this step you need to create your basic component. In the example platform this is called ExampleEHCI. Since it’s a SystemC model it inherits from the standard SystemC and TLM classes.

Notice that one of the classes specified is IUsbEHCI_MAK_Callbacks. We will come back to that later.

Step 2 – Instantiate the MAK objects in your basic component.

As previously described, the USB EHCI MAK is built on top of the USB Host MAK and so instantiating the USB EHCI MAK is all that’s required to access the facilities of both. In our example this is done in the constructor for the ExampleEHCI object.

Instantiation of the MAK is achieved by calling the GetInstance function as shown above.

Step 3 – Initialize and configure the MAK object

Having created an instance of the EHCI MAK the next step is to initialize and configure it. The code in the ExampleEHCI constructor illustrates this process.

Firstly, the number and type of ISB ports supported by your device is established.

For the ExampleEHCI model, two ports are established of type:

REAL_WORLD_CONNECTION.

Next, the standard EHCI registers implemented by the MAK are initialized to the required values.

Finally, the MAK’s InitializeComponent method is called. After this call, the facilities of the MAK are ready for use.

Step 4 – Implement MAK Callback Routines

The USB EHCI MAK needs access to some of the facilities provided by the model in which it is included – for example it needs to be able to raise interrupts and to access external memory. The IUsb_EHCI_MAK_Callbacks class provides the MAK with a standard interface for accessing these facilities by defining a set of virtual functions for which the model author needs to provide implementations. A pointer to the object implementing these functions is passed to the GetInstance routine which creates the MAK.

In the ExampleEHCI model, the model object itself implements these functions. For example, shown below is the callback routine which provides the MAK with the ability to raise an interrupt.

Step 5 – Implement standard model functionality

Now that the EHCI MAK is instantiated and configured, its facilities are available to implement the model functionality. Since many of the functional details are already implemented in the MAK, the actual model code can be very simple comprising of calls to the MAK APIs.

In the ExampleEHCI model we can see this in the model’s main execution routine which is called when the model is scheduled to run by the underlying simulation engine. This consists largely of calls to the core MAK routines which handle incoming and outgoing USB transfers.

Step 6 – Implement proprietary model functionality

In this step, the model author must add any additional functionality that is not implemented in the standard EHCI MAK. For example, the model may have proprietary registers which need to be added.

7. Summary

Virtual platforms require the early availability of TLM models. Model Authoring Kits (MAKs) offer fastest time to a TLM model for given protocols and functionality, by providing ready-to-use classes that are independent from any RTL implementation decision. Such capabilities include advanced features such as virtual I/O and real-world I/O. The DesignWare System-Level Library from Synopsys offers dedicated MAKs, with support for the TLM-2.0 standard. The example of a USB EHCI host model was given in this paper, illustrating the six simple steps to come to a full-featured TLM model using the USB MAK functionality.

References:

[1] DesignWare System-Level Library: data sheet http://www.synopsys.com/Tools/SLD/VirtualPlatforms/Pages/SLLibrary.aspx

[2] ARM Fast Models Enablement Program http://www.design-reuse.com/news/21195/arm-fast-models-enablement-program.html

[3] Innovator: data sheet http://www.synopsys.com/Tools/SLD/VirtualPlatforms/Pages/Innovator.aspx

[4] System Design With SystemC, Groetker/Liao/Martin/Swan, Kluwer Academic Publishers, ISBN 1-4020-7072-1