Single Flow for Interconnecting IP

• A complex central Interconnect Matrix
• Auto generation of a diverse range of system design views

While, suppliers of Interconnect Matrix components provide complex architectures for hardware, the SoC team is also responsible for producing other associated design view outputs such as documentation and code for software development, test and verification. Ultimately the team is responsible for delivering a fully tested, documented and usable product " on time.

A central Interconnect Matrix allows a designer to create multiple memory maps and control communications paths based on specific master and slave combinations easily and quickly. The design and creation of an Interconnect Matrix component is well defined and tools providing suitable architectures are available, from companies such as Sonics, ARM, Arteris etc.

Auto design view generation
SoC design teams now realize the benefits of storing register address map information in a central repository and use auto-generation techniques to create a diverse range of design views for software developers, hardware designers, verification engineers and documentation teams. Initiatives such as SPIRIT (IP-XACT) and industry proven EDA companies provide out-of-the-box solutions for the capture of IP and system interface information (in a generic form) and the auto-generation of design views. Figure 1 shows a typical usage model.

1. Typical use model of EDA tool for capture and auto generation.

The breadth of designs views that can be generated depends upon the depth of information that is captured and stored. Consider how a typical auto view generator might work.

To create an RTL representation of a typical system containing many located (instanced) IP blocks with inter-block connectivity, a generator 'program' needs to understand (as a minimum):

• IP core boundaries and physical interfaces (ports)
• System hierarchy and component instantiations
• Point to point connections, for example automatic connections based on like named ports or capture of actual signals.
• Format and syntax of the required output.

If you are then required to generate a SW API view from the same captured data sources you need to consider what additional information is needed, for example:

• Local offset and base addresses
• Addressing schemes & data transfer sizes
• Allowable communication paths (memory maps)

1. Physical interfaces: discrete ports, point-to-point signals and connections
2. Physical memory map: register, bitfield and memory definitions
3. Transaction level: base addresses for located IP and allowable initiator/slave communications

Interconnect Matrix - more than a black box
The architecture of an Interconnect Matrix is typically hidden from the SoC designer " indeed this is one of its advantages. Unfortunately, this means that for auto-generation purposes an Interconnect Matrix is typically captured as an IP core with just physical interface information, i.e. only one of the essential elements required.

This means that you effectively have a black box IP core in your system, to which other cores are physically connected, from which you need to auto-generate a complete set of system views. The physical interface information permits auto-generation of some hardware outputs (such as RTL representation of system connectivity), but precludes most software and verification views.

The success of a design flow incorporating auto generation tools depends upon capturing the minimum amount of information that will permit generation of the maximum number of different design views. So the solution to incorporating an Interconnect Matrix component into such a flow is to treat it as a 'grey' rather than a black box.

Interconnect Matrix - a grey box
For a scaleable and generic solution, the Interconnect Matrix component should be viewed as a grey box. This means that when one or more such components are instanced in a system, visibility of the transaction-level communication paths through them is known.

Taking Beach Solutions EASI Tools^TM as an example, an Interconnect Matrix is captured as an EASI database 'System' object (similar to IP-XACT component). This component not only consists of physical ports (Physical interface points) but also includes internal transaction level information.

For example, consider an interconnect that allows Master M1 and M3 to access S2 but Master M2 to only access S1. At a transaction level this could be represented by a series of high level communication paths as shown in Figure 2.

2. An example of interconnect matrix.

IP core representation
Other IP cores are captured as components (or in the case of Beach Solutions EASI Tools™ - 'IP Block' objects), each having a corresponding transaction interface(s) to the Interconnect Matrix component. Details of physical interface points (ports) are also stored, along with address map Information about memory mapped registers, bitfields and memories.

Combined, this provides the three essential elements needed for the maximum breadth of output view generation for each captured IP core.

System representation
A further component (or in the case of Beach Solutions EASI Tools™ - a 'System object) is also used to represent the top-level of the final system. Each system can contain:

• Instantiations of components
• Transaction-level communication paths
• Point-to-point connections

Proposed design flow
Figure 3 shows an iterative design flow that allows for auto-generation of multiple design views for a system with a complex Interconnect Matrix. EDA vendors can support the back bone of such a flow, while complex interconnect architectures are easily obtained from commercial vendors. The following sections describe the 5 main steps in this typical generic flow.

3. Outline of generic flow.

Step 1. Auto create Interconnect block
Capture the Interconnect Matrix component as a system with physical ports, parameters and transaction level communication paths. Ensure each master and slave interface type is stored (for example OCP or AXI) together with any associated interface constraints (parameters).

Step 2. Auto-generate Interconnect description
Supply Interconnect Matrix component information to a third party vendor, for example:

• By auto-generating documentation describing the Interconnect Matrix component. This can then be supplied to a vendor as a requirement specification for the component RTL architecture.
• Generate a custom view that will interface directly with the third party tools and thus achieve an electronic transfer of the requirements.

Step 3. Capture final System description
Having captured the interconnect matrix as a System in a central repository, other IP can be similarly stored. A 'top level' system can then be created that contains instances of the Interconnect Matrix component and other IP, together with the transaction-level communication paths between the IP and the Interconnect Matrix. At this stage two of the 3 essential elements are available so generation of software, documentation and some test views become possible.
A step further, is the capture of point-to-point connections; signals between discrete ports of the instanced IP. This is the final essential element required for maximum auto-generation. Typical auto generation tools might provide clever automated graphical utilities for connecting ports together using a single 'click'. These often include:

• Auto connecting bus signals with a single click
• Auto connecting ports based on name or alias
• Auto connect ports based on their type

Step 4. Auto-generate all views
Once checked, the data is used as a reliable source for the automatic generation of design files for use by all members of a development team. This is now possible because the complete path from the top-level system down through the Interconnect matrix to individual registers and bitfields is captured in the central repository (remember the 3 essential elements).

Step 5. Integrate Matrix architecture
Receive the matrix architecture (HDL) from a third party or internal source and include this in the generated system HDL to create a complete system description. As all 3 essential elements have been captured it is possible to generate a system level RTL connectivity view that contains declarations and fully connected instantiations for all IP in the final system, including the matrix component i.e. an RTL description with fully interconnected 'sockets'.
When the matrix architecture is received, it can be simply referenced by the generated connectivity RTL i.e. it is inserted into the generated matrix 'socket'. RTL descriptions for the architectures of the other IP Cores can also be referenced to create a full model for simulation.

Summary
This article has highlighted the challenges associated with using a complex Interconnect Matrix component in a SoC design flow that utilizes auto generation techniques to shorten project cycles.

It describes the need for certain essential elements to captured and presents a simple generic flow showing how these essential items can be used to maximum effect.