Using IP-XACT Metadata for a TLM Modeling Flow

Jack Donovan, Edwin Dankert (Duolog Technologies)

Abstract:

Many design organizations are evolving their flows to an Executable Live Specification (ELS) driven methodology and making huge gains in designer productivity because of increased and coherent communications among all the SoC design disciplines (RTL design, Functional Verification, Software Development, TLM modeling, ....). The ELS methodology has metadata at its core where the design data common to the different flows of the SoC design process are centrally stored.

A metadata driven methodology allows automatic generation of netlists and design IP skeletons from a central database that contains registers, ports, interfaces, and other common design data. IP-XACT is commonly used to store the metadata. This paper explores how to use IP-XACT to represent the necessary data to generate SystemC/TLM netlists and components

The results of this paper are the outcome of analyzing two use cases :

• Designs originally intended for RTL
• Designs originally intended for TLM/SystemC

The goal was to generate SystemC/TLM leaf cells and SystemC/TLM interconnect. We primarily focused on these two use cases although there are several other desirable use cases. The majority of our recommendations resulted from the second use case: designs originally intended for TLM/SystemC.

We will start by summarizing the TLM/SystemC requirements that we derived from the use cases; we will then visit the necessary IP-XACT background information, and then present our conclusions.

TLM and SystemC Requirements

There are two sets of requirements for representing TLM and SystemC models in a metadata format:

• SystemC ports
• TLM sockets

SystemC Ports

Figure 2 has a few port examples that illustrate the cases necessary to generate SystemC components and designs.

As shown in figure 2, the non-TLM communication of a SystemC component can be via two port types: sc_port or sc_export. Associated with each port type is an interface that describes the API for communication with a SystemC channel. The interfaces can be standard SystemC interfaces including sc_signal_in_if, sc_signal_out_if, sc_fifo_in_if, sc_fifo_out_if. Other interfaces can be custom types that are specific to an IP, SoC, a company or department specific methodology. Additionally, many interfaces have nested templating of data types. These data types can be any SystemC data type like sc_uint or sc_logic or they can be any C++ data type like int or bool or any user defined data type with the appropriate supporting class methods .

Figure 3 illustrates how a standard Verilog pin might be modeled with SystemC.

In addition to the sc_port and sc_export parameters outlined above, there are additional sc_port template parameters that sometimes need to be specified as illustrated in Figure 4.

myif is described in the previous section with possible nested templating. max_bind and con_policy together define the maximum number of port bindings allowed to port_name. A value of 0 implies unlimited binding. The con_policy connection policy for the port can be the following:

• SC_ONE_OR_MORE_BOUND
• SC_ZERO_OR_MORE_BOUND
• SC_ALL_BOUND

TLM Socket Requirements

TLM sockets add another level of complexity because there are variations in:

• socket types
• BUS_WIDTH
• protocol type
• other template parameters

Several TLM sockets are offered with the SystemC and TLM reference implementation and include:

• standard TLM sockets
• simple sockets
• tagged sockets
• passthrough sockets
• combinations or custom sockets

The BUS_WIDTH is consistent between all of the socket types but there are also several other template parameters including the protocol type, connection policies, etc. In addition most of these port types are only useful in limited situations.

Typically most of the information previously discussed is required to be represented in IP-XACT in order to generate or analyze different design views. Some of the data is methodology dependant and the assumption is that the majority of it can be fixed for a particular organization or design type.

Relevant IP-XACT Background

“IP-XACT enables the use of a unified structure for the meta specification of a design, components, interfaces, documentation, and interconnection of components. This structure can be used as the basis of both manual and automatic methodologies."2

IP-XACT allows the specification of information related to components, instantiations of these components and connectivity (designs). The component allows ports, memory-maps and registers to be specified. A framework has been put in place to map multiple ports together into interfaces and to reference memory-map information from these interfaces. Interface functionality like bus and abstraction-definitions (which formally describe the signals in the interface) have been introduced to support different levels of abstraction.

IP-XACT information is stored using the XML format and is structured like Figure 5 that has been abbreviated to the areas that concern our implementation for SystemC and TLM.

The IP-XACT Port

The IP-XACT port, Figure 6, can be specified on a component as either of type wire or transactional.

A wire type port defines a port which resolves to simple bits like ports that are bound to the built-in SystemC interfaces. Per the IP-XACT specification: “A transactional type port implements or uses a service that can be implemented with functions or methods.”

Transactional Port

The transactional type of port is the type of port that can be used to specify the TLM and SystemC information for ports that have user defined interfaces as illustrated in Figure 7.

An IP-XACT development goal was to be language independent, to document existing models, handle connectivity and create netlists. At the time of the IP-XACT standardization, the TLM and SystemC standards were in process and it was not envisaged to generate full SystemC headers or specify all possible method/function signatures. The following section describes how we have used IP-XACT to represent the required SystemC metadata despite this shortcoming.

IP-XACT 1685-2009 For TLM

A Port Example

IP-XACT allows us to represent SystemC port functionality using the transactional port mechanism.

To specify a port with a name of 'my_port_name', the transTypeDef typeName would be used to specify sc_port, the service type defs would be used to specify the my_if information and the maxConnections, minConnections properties would be used to specify both the con_policy and the max_bind. Figure 8 illustrates the resulting IP-XACT XML:

IP-XACT 1685-2009 Port Limitations

IP-XACT cannot specify all possible methods and parameters needed such as the following more complex SystemC construct that uses a SystemC fixed data type:

It is not possible to specify the W, I, Q, O, N parameters. We would like to produce IP-XACT that looks similar to Figure 10 but the XML in the figure creates incorrect IP-XACT. We need to use the vendor-extension mechanism of IP-XACT as illustrated in Figure 11.

Besides not being able to specify the parameters, the IP-XACT text also disallows creating connections for different transTypeDef info such as sc_port and sc_export”. In addition, any transactional port with different serviceTypeDef information such as sc_signal_in_if and sc_signal_out_if is not allowed to be connected.

Unfortunately these are standard connections for SystemC netlists.

A TLM Socket Example

Figure 12 illustrates the IP-XACT required for a TLM socket. The vendor extensions indicate that this socket has a BUS_WIDTH of 16 and uses a generic payload.

IP-XACT 1685-2009 SystemC Solution Summary

To solve the issues highlighted previously, we recommend the following approach:

1. Use vendor-extensions to store the SystemC interface parameter information.
2. Disregard the documented restrictions in relation to connectivity and instead provide separate Vendor Extensions (VEs) which allow for the support of the following socket-types (port, export, socket, simple_socket, multi_socket and custom), width and protocol information. The documented restrictions would need to be replaced with new restrictions for connections between 2 ports:
   1. socket-type’s must be compatible:
      1. initiator sc_port connects to target sc_port or sc_export (type: port or export)
      2. initiator_socket connects to target_socket’s (type: socket, simple_socket or multi_socket)
   2. width is identical
      1. compatible protocol
      2. the protocol-type must be identical
      3. the payload-type must be identical
      4. the mandatory payload extension must be identical

The information and functionality above is expected to be available in the next version of IP-XACT.

Conclusions

It is possible to represent TLM and SystemC metadata in IP-XACT as outlined in this paper with a set of vendor extensions and relaxation/adaptation of the rules, thereby enabling higher productivity for the SoC modeling team and tighter communication with the other SoC design disciplines.